Wdrożenie unijnych regulacji AI. Dlaczego e commerce i branża rozrywkowa ryzykują najwięcej

Drugiego sierpnia weszła w życie przeważająca część unijnego rozporządzenia regulującego kwestie sztucznej inteligencji, w tym rygorystyczny artykuł 50 dotyczący transparentności. Choć krajowy organ nadzorczy ma rozpocząć kontrole dopiero za kilka miesięcy, przedsiębiorstwa już podlegają restrykcyjnym wymaganiom oraz potencjalnym sankcjom finansowym. Eksperci z krakowskiego software house Miquido, spółki zajmującej się tworzeniem zaawansowanego oprogramowania, wskazują, że na rynku nie widać prób omijania przepisów, jednak poziom gotowości poszczególnych sektorów jest mocno zróżnicowany.

Nowe prawo nakłada obowiązek jednoznacznego oznaczania materiałów generowanych przez algorytmy, w tym technologii deepfake, a także informowania odbiorców o kontakcie z botem konwersacyjnym czy wykorzystaniu mechanizmów rozpoznawania emocji. Za niestosowanie się do tych zasad grożą dotkliwe kary finansowe sięgające 15 mln euro lub 3% rocznego obrotu przedsiębiorstwa.

Sytuację na polskim rynku komplikuje harmonogram powoływania odpowiednich instytucji. Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI) ma powstać w ciągu dwóch do trzech miesięcy od wejścia w życie krajowej ustawy, a realną działalność rozpocznie prawdopodobnie dopiero wiosną 2027 roku. W rezultacie firmy funkcjonują obecnie w stanie niepewności co do ewentualnego wstecznego egzekwowania naruszeń z okresu przejściowego.

– Unijne przepisy nie krępują. Są sensowne i często już dawno zaimplementowane – zauważa Piotr Polus, Head of Technology w Miquido.

Kto ryzykuje najwięcej na rynku cyfrowym

Podczas gdy sektory bankowy oraz medyczny posiadają bogate doświadczenie w dostosowywaniu się do złożonych norm prawnych, inne gałęzie gospodarki wykazują znacznie mniejszą czujność. Na szczególne ryzyko narażone są podmioty prowadzące działalność w handlu cyfrowym oraz w branży rozrywkowej, które masowo korzystają z generatywnych modeli do tworzenia opisów produktów, grafik, syntetycznych głosów czy wirtualnych postaci. Wiele z nich błędnie zakłada, że nowe unijne regulacje ich nie dotyczą.

– Bankowość i zdrowie są przygotowane na regulacje najlepiej, przechodziły to już wielokrotnie, mają procesy, słownik i ludzi od tego. Ale to nie one dziś najbardziej ryzykują. Patrząc z perspektywy klientów firm IT widać, że najmniej gotowa na nowe zmiany jest część ecommerce i rozrywki. Obowiązek, który wszedł w życie w sierpniu, obejmuje ich szczególnie, bo to one najczęściej korzystają z dobrodziejstw generatywnego AI, chatbotów, generowanych opisów i zdjęć produktów, syntetycznych głosów w reklamach, wirtualnych influencerów. Tymczasem ecommerce i rozrywka zwykle zakładają, że AI Act ich nie dotyczy – komentuje Polus.

Odpowiedzialność prawna klienta a rola dostawcy oprogramowania

Istotnym zagadnieniem jest rozgraniczenie ról w procesie tworzenia i wdrażania systemów opartych o sztuczną inteligencję. Przedsiębiorstwa technologiczne występują przeważnie w roli wykonawców, natomiast to zamawiający wprowadza gotowy produkt na rynek pod własnym szyldem i ponosi pełną odpowiedzialność prawną za zgodność z artykułem 50. Spełnienie tych wymogów jest jednak bezpośrednio uzależnione od technicznych fundamentów przygotowanych przez dostawcę kodu.

– Firmy IT, jak nasza, zazwyczaj są wykonawcą, a nie providerem AI. Rozwiązanie wykorzystujące AI wchodzi na rynek pod marką klienta, więc to klient odpowiada za obowiązki z art. 50. W praktyce najważniejsze jest to, że obowiązek jest po stronie klienta, ale techniczna możliwość jego spełnienia po naszej. Jeśli ujawnienie, że rozmawiasz z AI nie jest wbudowane w architekturę, a system po drodze zgubi metadane o pochodzeniu treści, klient nie będzie działał zgodnie z przepisami. O to więc musimy zadbać my, jako dostawca usługi IT – wyjaśnia Polus.

Audytowalność kodu i architektura systemów nowej generacji

Główne założenia techniczne sprowadzają się do dwóch kluczowych obszarów, którymi są transparentność interfejsu oraz audytowalność całego środowiska. O ile poinformowanie użytkownika o obecności algorytmu wymaga najczęściej zaledwie prostego komunikatu, o tyle rejestrowanie operacji musi być zaplanowane już na etapie projektowania struktury bazy danych.

– Dla uproszczenia w praktyce chodzi o dwa główne wymogi wobec systemu, audytowalność oraz informowanie o wykorzystaniu AI. Audytowalność systemu to duży temat. Zapisywanie tego, co się w systemie dzieje, to decyzja podejmowana już przy projektowaniu bazy danych, musi się więc wydarzyć na starcie projektu. Z ujawnianiem, że AI to AI, jest odwrotnie, zmiana jest mała, bo w wielu przypadkach wystarczy zaledwie statyczny komunikat – dodaje Polus.

Konieczność ciągłego logowania zdarzeń wynika także ze specyfiki modeli językowych LLM, które ze względu na swoją nieprzewidywalność wymagają ciągłej analizy jakościowej. Rozwiązania tego typu, zaimplementowane chociażby w aplikacji mobilnej Diagnostyka, od początku powstawały w oparciu o pełną rejestrację operacji ze względów czysto inżynierskich.

– W naszych produktach, na przykład w chatbotach, jak ten używany w aplikacji mobilnej Diagnostyka, na tę pierwszą część, logowanie i audytowalność, jesteśmy gotowi od dawna, bo bez tego nie bylibyśmy w stanie poprawiać jakości naszych usług. Robimy to odkąd budujemy takie rozwiązania, zresztą z powodów czysto inżynierskich, a nie prawnych. Rozwiązania oparte na LLM są po prostu nieprzewidywalne, ten sam prompt daje raz lepszą, raz gorszą odpowiedź i nie da się ich przetestować tak, jak konwencjonalnego kodu. Jedyny więc sposób, żeby realnie pracować nad jakością, to wszystko logować, by mieć do czego wrócić i móc zmodyfikować. Okazało się, że ta regulacja wymaga w zasadzie tego samego. Tę trudną część, czyli audytowalność, mieliśmy więc już zrobioną. Ten drugi aspekt, czyli poinformowanie użytkownika, że rozmawia z AI też był przed 1 sierpnia i był jednym z fundamentów naszego podejścia do projektowania interfejsów opartych o AI – podkreśla Polus.

Weryfikacja projektów i perspektywa kolejnych terminów

Dla systemów zakwalifikowanych jako rozwiązania wysokiego ryzyka harmonogram przewiduje dłuższy czas na pełne dostosowanie, z ostatecznymi terminami przypadającymi na grudzień 2027 roku lub sierpień 2028 roku. W obecnym okresie przejściowym kluczowe staje się badanie działających instalacji oraz weryfikowanie nowych projektów już na etapie wstępnych analiz koncepcyjnych.

– W przejściowym okresie działamy dwutorowo. Sprawdzamy po kolei, co faktycznie zapisują systemy, które już działają i dokładamy do nich elementy, których może brakować. Tam, gdzie w grę wchodzą wymogi dla systemów wysokiego ryzyka, mamy jeszcze czas, grudzień 2027 albo sierpień 2028, zależnie od kategorii. Nowe produkty sprawdzamy natomiast jeszcze na etapie discovery, przed budową architektury. Wtedy wystarczają trzy pytania, czy system zapisuje zdarzenia, czy człowiek ma w nim realny moment na podjęcie decyzji i czy informacja o AI jest częścią sesji, a nie czymś dorysowanym na siłę w interfejsie. I faktycznie to, co obserwujemy w ostatnich tygodniach, to zgłoszenia klientów o większej potrzebie otwartego komunikowania o użyciu AI – podsumowuje Polus.