AI Act sprawdzasz zawsze wtedy, gdy Twoja aplikacja ma funkcje oparte na sztucznej inteligencji. Nie ma znaczenia, że nie zbudowałeś własnego AI, tylko korzystasz z gotowego modelu, np. od OpenAI albo Anthropic. Od 2 sierpnia 2026 obowiązują także wymogi transparentności z art. 50: użytkownik, który wchodzi w interakcję z AI, musi o tym wiedzieć, a treści wygenerowane przez AI muszą być oznaczone w przypadkach określonych w AI Act.
Ten poradnik powstał z naszej rozmowy z adwokatką Dominiką Królik, która przygotowała dokumentację prawną naszej aplikacji i przejrzała ten tekst przed publikacją. Przechodzimy przez AI Act od strony twórcy aplikacji: kogo dotyczy, co oznaczać i jak ustalić, czy nie jesteś dostawcą systemu AI.
01. Co to jest AI Act i od kiedy obowiązuje?
AI Act (akt w sprawie sztucznej inteligencji) to unijne rozporządzenie regulujące tworzenie i wykorzystywanie systemów AI. Weszło w życie 1 sierpnia 2024, ale obowiązki nakłada etapami:
- 2 lutego 2025 - większość zakazanych praktyk AI oraz obowiązki w zakresie AI literacy,
- 2 sierpnia 2025 - obowiązki dostawców modeli AI ogólnego przeznaczenia (GPAI, general-purpose AI),
- 2 sierpnia 2026 - większość przepisów AI Act, w tym wymogi transparentności z art. 50,
- 2 grudnia 2026 - termin dostosowania do art. 50 ust. 2 dla systemów generujących treści syntetyczne, które wprowadzono do obrotu przed 2 sierpnia 2026; od tej daty stosuje się też nowe zakazy dodane w 2026,
- 2 sierpnia 2027 - termin dostosowania dla dostawców modeli GPAI wprowadzonych do obrotu przed 2 sierpnia 2025,
- 2 grudnia 2027 - wymogi dla systemów wysokiego ryzyka z art. 6 ust. 2 i załącznika III, m.in. w zatrudnieniu, edukacji, biometrii czy infrastrukturze krytycznej,
- 2 sierpnia 2028 - wymogi dla systemów wysokiego ryzyka z art. 6 ust. 1 i załącznika I, czyli systemów AI związanych z produktami objętymi unijnymi przepisami bezpieczeństwa produktów.
Pełny harmonogram znajdziesz w timeline wdrożenia AI Act. Praktyczny wniosek: jeżeli Twoja aplikacja ma chatbota albo generuje treści, obowiązki oznaczania nie są już "przyszłością". Obowiązują od sierpnia 2026.
Dla twórcy aplikacji, który konfiguruje gotowe modele, najważniejsze są trzy rzeczy: transparentność i oznaczanie, ustalenie własnej roli (czy nie jesteś dostawcą systemu AI albo nie pełnisz innej roli, z którą AI Act wiąże obowiązki) oraz sprawdzenie, czy funkcje aplikacji nie ocierają się o zakazane praktyki. Tak to układa Dominika Królik, adwokatka z kancelarii Królik Legal, z którą przygotowaliśmy dokumentację prawną naszej aplikacji Nawykometr.
02. Kogo dotyczy AI Act: dostawca czy podmiot stosujący?
AI Act rozróżnia dostawcę systemu AI od podmiotu, który tylko z niego korzysta. Zakres obowiązków zależy też od rodzaju systemu. Najdalej idące wymogi dotyczą przede wszystkim systemów wysokiego ryzyka.
Typowy scenariusz z naszej społeczności: aplikacja nie ma własnego modelu, tylko korzysta przez API z gotowego rozwiązania, np. ChatGPT albo Claude'a. Kto wtedy jest dostawcą? Dostawcą modelu pozostaje jego producent, ale jeśli na jego bazie tworzysz własny system AI i oferujesz go użytkownikom jako część swojego produktu, możesz być dostawcą tego systemu.
Z rozmowy z Dominiką: znaczenie ma to, co faktycznie budujesz na bazie modelu, pod czyją marką oferowany jest system, jakie ma przeznaczenie i czy nie wchodzi w obszar systemów wysokiego ryzyka. Da się przekroczyć linię i zostać dostawcą, nawet jeśli model kupujesz z półki.
Osobna sprawa: aplikacja nie staje się systemem AI tylko dlatego, że została napisana z pomocą AI. Vibekodowana apka bez chatbota i bez generowania treści nie jest systemem AI. Liczy się to, jak działa finalny produkt, a nie sposób napisania jego kodu.
03. Jak ustalić swoją rolę przy integracji gotowego AI?
Cztery zasady, które Dominika przekazuje twórcom konfigurującym gotowe modele:
- Sprawdź, co faktycznie tworzysz. Korzystanie z gotowego modelu przez API nie oznacza, że stajesz się dostawcą tego modelu. Możesz jednak tworzyć na jego bazie własny system AI.
- Ustal, kto rozwija i oferuje system. Jeżeli rozwijasz system AI lub zlecasz jego rozwój, a potem udostępniasz go pod własną nazwą lub marką, możesz zostać uznany za jego dostawcę.
- Nie myl dostawcy modelu z dostawcą systemu. OpenAI czy Anthropic mogą pozostać dostawcami modelu, a Ty jednocześnie możesz być dostawcą aplikacji, która ten model wykorzystuje.
- Sprawdź, czy system nie jest wysokiego ryzyka. Szczególnej analizy wymagają m.in. zastosowania AI w rekrutacji, edukacji, biometrii, dostępie do istotnych usług czy wymiarze sprawiedliwości. Wtedy zakres obowiązków dostawcy jest dużo szerszy.
Te cztery punkty brzmią prosto, ale realnie mogą decydować o tym, w którym reżimie obowiązków ląduje Twoja aplikacja.
04. Co musisz oznaczać w aplikacji z AI?
Od 2 sierpnia 2026 wymogi transparentności z art. 50 AI Act obejmują kilka sytuacji.
Interakcja z AI. Gdy użytkownik rozmawia z chatbotem albo asystentem AI, powinien zostać poinformowany, że ma do czynienia z systemem AI. Informację przekazujesz najpóźniej przy pierwszej interakcji, chyba że wynika to jasno z okoliczności.
Treści generowane przez AI. Systemy generujące obrazy, wideo, audio lub tekst powinny oznaczać wyniki w formacie odczytywalnym maszynowo, tak żeby dało się wykryć, że treść została wygenerowana lub zmanipulowana przez AI. Częste pytanie z naszej społeczności: czy wpis "to jest AI" w metadanych pliku wystarczy? Odpowiedź Dominiki: metadane mogą być jednym ze sposobów, ale rozwiązanie musi być skuteczne, interoperacyjne, odporne i niezawodne. Nie ma więc zasady, że samo dodanie wpisu do metadanych zawsze wystarczy. W grę wchodzą też watermarking i rozwiązania kryptograficzne. Szczegóły techniczne warto skonsultować z kimś od cyberbezpieczeństwa.
Deepfake i określone treści publikowane publicznie. Tutaj obowiązki mogą ciążyć również na podmiocie, który z systemu korzysta. Deepfake wymaga ujawnienia, że treść została sztucznie wygenerowana lub zmanipulowana. Podobny obowiązek może dotyczyć tekstów publikowanych w celu informowania o sprawach interesu publicznego.
A gdy aplikacja publikuje materiał na koncie użytkownika, na jego polecenie? Nie ma jednej zasady, że zawsze odpowiada za to dostawca aplikacji. Trzeba ustalić, kto w danym przypadku jest dostawcą systemu, a kto podmiotem stosującym, oraz jaki rodzaj treści jest generowany i publikowany.
05. Zakazane praktyki i systemy wysokiego ryzyka
Zanim wdrożysz funkcję AI, sprawdź ją pod dwoma kątami.
Zakazane praktyki. AI Act zakazuje konkretnych zastosowań, a nie po prostu "autonomicznego AI". Uważaj m.in. na określone formy manipulowania użytkownikiem, wykorzystywanie jego podatności, social scoring czy rozpoznawanie emocji w miejscu pracy i edukacji. Sam scoring albo podejmowanie decyzji przez AI nie są automatycznie zakazane.
Systemy wysokiego ryzyka. Tutaj decyduje przeznaczenie systemu. Do tej kategorii mogą należeć m.in. systemy wykorzystywane w rekrutacji, ocenie pracowników, decyzjach o warunkach zatrudnienia, edukacji czy dostępie do określonych podstawowych usług.
Częste pytanie z naszej społeczności: czy wystarczy, że AI tylko rekomenduje, a ostateczną decyzję podejmuje człowiek? Nie zawsze. Jeżeli wynik AI realnie wpływa na decyzję dotyczącą człowieka, system nadal może być wysokiego ryzyka. Sam "człowiek w pętli" (human-in-the-loop) nie wyłącza tej kwalifikacji.
Praktyczna rada: klasyfikację ryzyka zrób już na etapie projektowania funkcji. Zmiana koncepcji na papierze jest dużo prostsza niż przebudowa gotowego systemu.
06. Co w interfejsie, a co w polityce prywatności?
Te informacje trzeba rozdzielić między interfejs aplikacji i dokumentację prawną.
W interfejsie aplikacji: przede wszystkim informacja, że użytkownik wchodzi w interakcję z systemem AI. Jeżeli aplikacja generuje treści, dochodzą obowiązki ich oznaczania z art. 50, o których pisałem wyżej. Informację przekazujesz najpóźniej przy pierwszej interakcji lub kontakcie z taką treścią.
W polityce prywatności: opisujesz, jakie dane trafiają do funkcji AI, w jakim celu i na jakiej podstawie są przetwarzane, jak długo są przechowywane, komu są ujawniane oraz czy dochodzi do transferu danych poza EOG. Jeżeli zewnętrzny dostawca AI dostaje dane osobowe użytkownika, trzeba też prawidłowo opisać jego rolę w przetwarzaniu. RODO wymaga informacji o odbiorcach lub ich kategoriach, więc nie w każdym przypadku musisz wskazać konkretnego dostawcę z nazwy.
Do tego dochodzi regulamin: opis funkcji AI, zasady korzystania z nich, ich ograniczenia i uregulowanie odpowiedzialności. Nie chodzi o wrzucenie disclaimeru "AI może się mylić", tylko o prawidłowe rozdzielenie odpowiedzialności między dostawcę aplikacji, dostawcę zewnętrznego rozwiązania i użytkownika.
Jak usłyszałem od Dominiki, przy aplikacji z AI dokumentacja wymaga dodatkowej analizy: kancelaria sprawdza nie tylko RODO i regulamin, ale też Twoją rolę na gruncie AI Act, sposób działania funkcji AI i obowiązki transparentności. Konstrukcja dokumentów ma odpowiadać temu, kto faktycznie kontroluje działanie systemu i za jaki element usługi odpowiada.
Najczęstsze pytania
Czy aplikacja napisana z pomocą AI podlega AI Act?
Czy informacja o AI w metadanych pliku wystarczy jako oznaczenie?
Kto odpowiada za oznaczenie, gdy aplikacja publikuje treści na koncie użytkownika?
Czy chatbot pomagający nawigować po stronie to duży problem prawny?
Od kiedy obowiązują wymogi oznaczania treści AI?
07. Podsumowanie
Checklist AI Act dla twórcy aplikacji z funkcjami AI: poinformuj użytkownika o interakcji z AI, zadbaj o wymagane oznaczanie generowanych treści, ustal swoją rolę (w tym, czy jesteś dostawcą własnego systemu AI), opisz przepływ danych do zewnętrznych dostawców AI w polityce prywatności i sprawdź funkcje aplikacji pod kątem praktyk zakazanych oraz systemów wysokiego ryzyka.
Dwa tipy na koniec:
- Rób klasyfikację ryzyka AI na etapie projektowania funkcji, nie po wdrożeniu. Zmiana koncepcji na papierze jest darmowa, przeróbka działającego produktu nie.
- Jeżeli przepuszczasz dane użytkowników przez API modeli, ograniczaj ich zakres jeszcze przed wysłaniem. Rozważ maskowanie, anonimizację lub pseudonimizację i sprawdź zasady retencji, wykorzystywania danych do trenowania modeli oraz transferów poza EOG. Samo szyfrowanie transmisji chroni dane "w drodze", ale dostawca API i tak może je odczytać po odebraniu.