2 sierpnia zaczęła obowiązywać większość przepisów AI Act - unijnego rozporządzenia regulującego używanie sztucznej inteligencji - ale polski organ nadzorujący ich stosowanie ma powstać dopiero za kilka miesięcy. W sierpniu rząd ogłosił budowę tzw. piaskownicy AI, czyli środowiska, gdzie polskie firmy mają uczyć się budowy systemów w zgodzie z AI Act. Nie jest więc do końca pewne, czy muszą już stosować nowe regulacje i czy ich naruszenia będą karane wstecz. Jednak - jak ocenia Piotr Polus z krakowskiego software house Miquido - w branży IT nie widać kombinowania, jak ominąć AI Act. - “Unijne przepisy nie krępują. Są sensowne i często już dawno zaimplementowane” - zauważa ekspert.
- Od 2 sierpnia obowiązują już wymogi art. 50 AI Act dot. transparentności (oznaczanie treści generowanych przez AI, deepfake'i, informowanie o interakcji z chatbotem, o rozpoznawaniu emocji itd.)
- Polska ustawa implementująca AI Act została przyjęta z opóźnieniem (prezydent podpisał ją w lipcu), a 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; eksperci szacują, że realnie zacznie działać dopiero wiosną 2027.
- W efekcie firmy podlegają obowiązkom i grożą im kary (do 15 mln euro lub 3% obrotu), ale żadna instytucja tego jeszcze nie kontroluje; nie jest jasne, czy KRiBSI będzie mogła karać retroaktywnie za naruszenia z okresu przejściowego.
- Piaskownica AI, czyli utworzone przez Ministerstwo Cyfryzacji środowisko do testowania polskich systemów IT na zgodność z AI Act została zapowiedziana dopiero w sierpniu.
- Firmy stają przed dylematem: wdrażać kosztowne procedury compliance już teraz, czy zaczekać, aż instytucje zaczną rzeczywiście kontrolować rynek.
Komentuje Piotr Polus, Head of Technology 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.
To, co utrudnia nam pracę, to fakt, że nie możemy 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. 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 konewncjonalnego 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.
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.
Za sam temat zgodności z AI Act u nas 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.
Przejrzałem zapytania ofertowe z drugiego kwartału tego roku – konieczność zapewnienia zgodności z AI Act pojawiała się tylko w jednym na dziesięć wymaganiach od klientów i to wyłącznie w zapytaniach pochodzących z rynku polskiego. Nie napotkaliśmy takiego wymogu w zapytaniach z innych krajów Unii Europejskiej. Zastrzegam przy tym, że to obserwacja tylko z jednego kwartału, nie całościowe badanie rynku IT.
Ten brak konieczności uzwględniania zgodności z AI Act nie znaczy, że mało kto na rynku się tym przejmuje. To bardziej pokazuje, w którym momencie zakupu ten 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. Nieobecność w briefie mówi więc tak naprawdę najwięcej o procesie zakupowym, a nie o poziomie świadomości klienta. 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.
Patrząc z perspektywy klientów firm IT widać, że najmniej gotowe 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.
O Miquido
Miquido to polska firma technologiczna, która od 2011 roku dostarcza kompleksowe rozwiązania software'owe o lokalnym i globalnym zasięgu, realnie zmieniające sposób działania biznesu klienta. Specjalizuje się w aplikacjach mobilnych i rozwiązaniach opartych na sztucznej inteligencji. Z aplikacji stworzonych przez Miquido korzysta łącznie ponad 100 mln osób.
Zespół ponad 200 ekspertów Miquido pracuje z wiodącymi markami z branż takich jak medtech, fintech, travel, telekomunikacja, rozrywka, ecommerce czy energetyka, oferując im wsparcie technologiczne dostosowane do konkretnych potrzeb.
