Kto naprawdę odpowiada za AI Act w projektach IT. „Obowiązek po stronie klienta, wykonanie po naszej"

2 sierpnia zaczęła obowiązywać większość przepisów AI Act, unijnego rozporządzenia regulującego używanie sztucznej inteligencji. Polski organ nadzorczy, Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI), ma formalnie powstać w ciągu 2–3 miesięcy od wejścia ustawy w życie, a eksperci szacują, że realnie zacznie działać dopiero wiosną 2027. W sierpniu rząd ogłosił też budowę tzw. piaskownicy AI, czyli środowiska do testowania systemów IT pod kątem zgodności z rozporządzeniem.

W efekcie firmy podlegają obowiązkom i grożą im kary do 15 mln euro lub 3 proc. obrotu, ale żadna instytucja tego jeszcze nie kontroluje. Nie jest też jasne, czy KRiBSI będzie mogła karać wstecz za naruszenia z okresu przejściowego. Firmy stają przed dylematem: wdrażać kosztowne procedury compliance teraz, czy zaczekać, aż instytucje zaczną kontrolować rynek.

Sytuację w branży IT komentuje Piotr Polus, Head of Technology w krakowskim software house Miquido.

„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. Jedyny wyjątek dla Miquido to nasz open source, w tym wypadku framework Draive, ale on sam nie jest systemem AI: nie wnioskuje, tylko organizuje pracę modeli, które wykonują pracę za niego. W praktyce ważniejsze jest jednak coś innego – 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".

„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".

Polus zwraca uwagę, że firma IT nie może stwierdzić za klienta, czy jego system jest wysokiego ryzyka w rozumieniu AI Act. To decyzja klienta i jego marki. „W naszych produktach, np. 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. (...) 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".

W okresie przejściowym Miquido działa dwutorowo: sprawdza po kolei, co zapisują już działające systemy, i dokłada brakujące elementy. Tam, gdzie w grę wchodzą wymogi dla systemów wysokiego ryzyka, jest jeszcze czas, grudzień 2027 albo sierpień 2028, zależnie od kategorii. Nowe produkty firma sprawdza na etapie discovery, przed budową architektury. Wtedy, jak mówi Polus, 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 w interfejsie. „W ostatnich tygodniach obserwujemy zgłoszenia klientów o większej potrzebie otwartego komunikowania o użyciu AI".

Za zgodność z AI Act w firmie odpowiada zespół produktowy, a nie osobna rola. „AI Act, w przeciwieństwie do RODO z inspektorem ochrony danych, żadnej nowej funkcji nie wymaga. Artykuł 4 i art. 26 ust. 2 stawiają wymogi kompetencyjne wobec ludzi wykonujących pracę, nie wobec działu. Dział prawny jest więc tylko wsparciem przy interpretacji, ale właścicielem tematu jest dział produktowy".

Ciekawa jest obserwacja rynku. Polus przejrzał zapytania ofertowe z drugiego kwartału i konieczność zapewnienia zgodności z AI Act pojawiała się tylko w jednym na dziesięć wymaganiach od klientów, wyłącznie w zapytaniach z rynku polskiego. „Nie napotkaliśmy takiego wymogu w zapytaniach z innych krajów Unii Europejskiej". Zastrzega, że to obserwacja z jednego kwartału, nie całościowe badanie rynku.

Jego zdaniem nie oznacza to braku świadomości, tylko moment, w którym temat jest podnoszony. „Zapytania ofertowe są pisane przez działy produktu albo działy zakupów. W zasadzie nigdy nie przygotowują ich działy prawne. Wymóg zgodności z regulacjami pojawia się więc zwykle później: przy due diligence, przy negocjowaniu umowy czy przy ankiecie bezpieczeństwa. (...) Podejrzewam, że powtórzy się schemat znany z RODO: w 2016 nikt nie pytał o zgodność z RODO, a w 2019 pytali wszyscy. Ta zmiana wydarzyła się nie dzięki samemu rozporządzeniu, tylko przez konieczność dostosowania do niego umów i szablonów zakupowych".

Wśród klientów firm IT najmniej gotowe na sierpniowe zmiany są, zdaniem Polusa, część e-commerce 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".

Materiał pochodzi od Miquido, polskiej firmy IT specjalizującej się m.in. w rozwiązaniach opartych na AI.

Źródła: komentarz ekspercki Piotra Polusa, Head of Technology w Miquido