Czy użytkownik wie, że rozmawia z AI? Art. 50 AI Act dla chatbotów i SaaS

SaaS-y, software house’y i e-commerce: czy użytkownik Waszego chatbota wie, że rozmawia z AI?

Jeżeli chatbot jest systemem AI, użytkownik powinien otrzymać taką informację najpóźniej przy pierwszej interakcji. Wyjątek działa wtedy, gdy w konkretnych okolicznościach jest oczywiste, że po drugiej stronie nie siedzi człowiek.

Od 2 sierpnia 2026 r. obowiązki dotyczące przejrzystości z art. 50 AI Act już się stosują.

Nie jest to temat przeznaczony wyłącznie dla twórców wielkich modeli albo systemów wysokiego ryzyka. Przepisy mogą objąć również całkiem zwyczajne rozwiązania działające w produktach i procesach firm:

1. chatboty oraz voiceboty obsługujące klientów;
2. agentów AI prowadzących korespondencję;
3. asystentów w aplikacjach i produktach SaaS;
4. generatory tekstów, obrazów, audio albo wideo;
5. marketing wykorzystujący deepfake’i;
6. niektóre treści generowane przez AI dotyczące spraw publicznych.

Art. 50 nie wymaga jednego uniwersalnego oznaczenia „created with AI” dla każdego przypadku. Obowiązek zależy od funkcji systemu, rodzaju treści i roli konkretnej organizacji.

Informacja schowana w regulaminie może nie wystarczyć

Jeżeli użytkownik zaczyna rozmowę z chatbotem, informacja o kontakcie z AI powinna pojawić się tam, gdzie zaczyna się sama interakcja.

Ogólne zdanie schowane na 28. stronie regulaminu raczej nie spełni swojego zadania. Użytkownik powinien otrzymać komunikat w odpowiednim czasie, czyli najpóźniej przy pierwszym kontakcie z systemem.

Może to być na przykład informacja wyświetlona:

1. w oknie powitalnym chatbota;
2. bezpośrednio nad polem wpisywania wiadomości;
3. przy rozpoczęciu rozmowy z voicebotem;
4. w pierwszej wiadomości wysyłanej przez agenta AI;
5. przy funkcji produktu, w której rozpoczyna się bezpośrednia interakcja z systemem.

Nie oznacza to, że komunikat musi zajmować pół ekranu albo straszyć użytkownika prawniczym ostrzeżeniem. Powinien być jasny, widoczny i zrozumiały.

Przykładowe brzmienie może wyglądać tak:

„Rozmawiasz z asystentem wykorzystującym sztuczną inteligencję”.

Samo użycie nazwy „asystent” albo nadanie chatbotowi fantazyjnego imienia nie zawsze pokaże odbiorcy, że kontaktuje się z systemem AI. Informację warto przetestować także od strony UX: czy przeciętny użytkownik faktycznie ją zauważy i zrozumie?

Kiedy informacja nie będzie potrzebna?

Art. 50 przewiduje wyjątek, gdy dla rozsądnie poinformowanej, uważnej i ostrożnej osoby jest oczywiste, że ma kontakt z systemem AI.

Nie warto jednak traktować tego wyjątku zbyt szeroko.

To, że twórca produktu doskonale wie, jak działa jego funkcja, nie oznacza jeszcze, że będzie to równie oczywiste dla użytkownika. Znaczenie może mieć nazwa narzędzia, wygląd interfejsu, treść komunikatów, sposób prowadzenia rozmowy i cały kontekst interakcji.

Jeżeli agent AI odpowiada z adresu wyglądającego jak skrzynka pracownika, podpisuje się imieniem i prowadzi naturalną korespondencję, sztuczny charakter interakcji może wcale nie być oczywisty.

Gdy firma ma wątpliwości, czy wyjątek działa, krótki i czytelny komunikat będzie zwykle bezpieczniejszy niż budowanie całego rozwiązania na założeniu, że „przecież każdy się domyśli”.

Najpierw ustalcie, kto jest providerem

Przy art. 50 duże znaczenie ma rozróżnienie providera i deployera.

Provider to podmiot, który rozwija system AI albo zleca jego rozwój i wprowadza go na rynek lub oddaje do użytku pod własną nazwą albo znakiem towarowym.

Nie zawsze będzie nim twórca podstawowego modelu.

Providerem może być również:

1. dostawca SaaS-u oferujący własnego asystenta AI;
2. software house sprzedający system pod własną marką;
3. firma, która zamówiła rozwiązanie i uruchamia je jako własny produkt;
4. klient, który wprowadził istotne zmiany albo nadał systemowi nowe przeznaczenie i przez to przejął obowiązki providera.

Deployer to natomiast podmiot, który używa systemu AI w ramach swojej działalności, ale nie wprowadza go na rynek pod własną nazwą jako dostawca.

Firma korzystająca z gotowego chatbota w obsłudze klienta będzie często deployerem. Dostawca narzędzia może być providerem. Nie należy jednak przypisywać ról wyłącznie na podstawie nazwy umowy albo deklaracji dostawcy. Liczy się rzeczywisty sposób stworzenia, oferowania i używania systemu.

Kto odpowiada za informację przy chatbocie?

W przypadku systemu przeznaczonego do bezpośredniego kontaktu z ludźmi podstawowy obowiązek spoczywa na providerze.

Powinien on zaprojektować i rozwinąć system tak, aby zainteresowana osoba została poinformowana, że wchodzi w interakcję z AI. Można to określić jako transparency by design: przejrzystość ma być elementem produktu, a nie dodatkiem przygotowanym po zakończeniu wdrożenia.

Provider powinien więc zadbać o to, aby system:

1. miał przewidziane miejsce na odpowiedni komunikat;
2. pozwalał wyświetlić go we właściwym czasie;
3. uwzględniał różne kanały kontaktu, na przykład czat, głos i e-mail;
4. nie wprowadzał użytkownika w błąd co do tego, czy rozmawia z człowiekiem;
5. zachowywał komunikat również po zmianach interfejsu albo konfiguracji.

W praktyce deployer również nie powinien przechodzić obok tego tematu obojętnie. To on wdraża narzędzie w swoim procesie i może zmienić komunikaty, branding, kanał kontaktu albo sposób działania funkcji.

Dlatego umowa między dostawcą a klientem powinna określać, kto odpowiada za przygotowanie treści komunikatu, jego wdrożenie w interfejsie, tłumaczenia, aktualizacje i kontrolę po zmianach produktu.

Sformułowanie „klient sam odpowiada za zgodność z prawem” może nie wystarczyć, jeżeli dostawca nie daje technicznej możliwości wykonania obowiązku.

Techniczne oznaczanie treści to osobny obowiązek

Inaczej wygląda sytuacja systemów generujących albo istotnie modyfikujących tekst, obraz, audio lub wideo.

Provider takiego systemu powinien zapewnić, aby jego wyniki były oznaczone w formacie maszynowo odczytywalnym i możliwe do wykrycia jako wygenerowane albo zmienione przez AI. Rozwiązanie powinno być skuteczne, interoperacyjne, odporne i wiarygodne w zakresie technicznie wykonalnym.

Nie chodzi tutaj wyłącznie o widoczny napis pod obrazem. Techniczne oznaczenie może dotyczyć metadanych, znaków wodnych, informacji o pochodzeniu albo innych metod pozwalających wykryć, że treść powstała z udziałem AI.

Trzeba więc rozróżnić:

1. informację przeznaczoną dla człowieka;
2. techniczne oznaczenie przeznaczone do maszynowego wykrywania pochodzenia treści.

W niektórych przypadkach potrzebne mogą być oba elementy.

Deepfake: obowiązek po stronie deployera

Jeżeli firma publikuje albo w inny sposób udostępnia deepfake, jako deployer powinna ujawnić, że treść została sztucznie wygenerowana lub zmanipulowana.

Deepfake może obejmować obraz, audio albo wideo, które przypomina istniejącą osobę, przedmiot, miejsce, podmiot albo zdarzenie i może zostać błędnie uznane za autentyczne.

Wyobraźmy sobie kampanię, w której wygenerowana postać wygląda i mówi jak rzeczywisty człowiek. Techniczne oznaczenie zapewnione przez dostawcę systemu może być potrzebne, ale nie zastąpi czytelnej informacji dla odbiorcy publikowanej treści.

Przy utworach ewidentnie artystycznych, satyrycznych, fikcyjnych lub podobnych obowiązek można wykonać w sposób, który nie utrudnia odbioru i nie psuje samego dzieła. Nadal jednak trzeba zachować odpowiednią przejrzystość.

Teksty dotyczące spraw publicznych

Osobny obowiązek może dotyczyć tekstów generowanych albo modyfikowanych przez AI, które są publikowane w celu informowania społeczeństwa o sprawach leżących w interesie publicznym.

Deployer powinien ujawnić sztuczne pochodzenie takiego tekstu.

Wyjątek może mieć zastosowanie, jeżeli treść przeszła proces weryfikacji przez człowieka albo kontrolę redakcyjną, a osoba fizyczna lub prawna ponosi odpowiedzialność redakcyjną za jej publikację.

Nie każda korekta wykonana przez człowieka wystarczy. Powierzchowne sprawdzenie pisowni, formatowania albo gramatyki nie musi oznaczać rzeczywistej kontroli redakcyjnej. Człowiek powinien faktycznie zweryfikować treść i wziąć odpowiedzialność za jej publikację.

Dlatego firma publikująca artykuły, raporty, komentarze albo materiały dotyczące spraw publicznych powinna ustalić:

1. czy tekst został wygenerowany albo istotnie zmieniony przez AI;
2. jaki człowiek go zweryfikował;
3. na czym polegała kontrola redakcyjna;
4. kto ponosi odpowiedzialność za publikację;
5. czy potrzebne jest widoczne oznaczenie dla odbiorcy.

Jedna treść może oznaczać dwa obowiązki

Wyobraźmy sobie SaaS pozwalający klientom generować realistyczne materiały wideo.

Provider systemu może odpowiadać za techniczne, maszynowo odczytywalne oznaczenie generowanego materiału. Klient, który publikuje film będący deepfake’em, może jako deployer odpowiadać za czytelną informację dla odbiorcy.

Jedna treść może więc uruchomić dwa różne obowiązki:

1. techniczne oznaczenie wyniku po stronie providera;
2. ujawnienie sztucznego charakteru treści przez deployera.

Jeżeli umowa i sam produkt nie rozdzielają tych zadań, każda strona może zakładać, że obowiązek wykonuje ktoś inny.

Co z okresem przejściowym do 2 grudnia 2026 r.?

Art. 50 stosuje się od 2 sierpnia 2026 r. Od tego dnia providerzy i deployerzy powinni wykonywać odpowiednie obowiązki dotyczące przejrzystości.

Istnieje wąski okres przejściowy dla systemów wprowadzonych na rynek przed 2 sierpnia 2026 r. Ich providerzy mają czas do 2 grudnia 2026 r. na dostosowanie się do technicznego oznaczania wyników przewidzianego w art. 50 ust. 2.

Ten wyjątek:

1. dotyczy tylko systemów wprowadzonych na rynek przed 2 sierpnia 2026 r.;
2. obejmuje wyłącznie techniczne oznaczanie i wykrywalność wygenerowanych albo zmienionych treści;
3. nie przesuwa całego art. 50;
4. nie zwalnia z informowania użytkownika, że rozmawia z chatbotem AI;
5. nie przesuwa obowiązków dotyczących deepfake’ów i określonych treści dotyczących spraw publicznych.

Treści wygenerowanych i opublikowanych przed 2 sierpnia 2026 r. nie trzeba oznaczać wstecz, choć dobrowolne oznaczenie może nadal mieć sens.

Co powinny teraz sprawdzić firmy?

W praktyce zacząłbym od inwentaryzacji, nie od pisania nowej polityki na kilkadziesiąt stron.

Warto sprawdzić:

1. jakie chatboty, voiceboty, agenty i generatory działają w organizacji;
2. które z tych narzędzi rzeczywiście są systemami AI;
3. kto pełni rolę providera, a kto deployera dla każdej funkcji;
4. czy użytkownik otrzymuje informację przy pierwszej interakcji z AI;
5. czy sztuczny charakter interakcji jest rzeczywiście oczywisty;
6. czy system generuje albo istotnie modyfikuje tekst, obraz, audio lub wideo;
7. czy provider zapewnia techniczne oznaczenie wyników;
8. czy firma publikuje deepfake’i albo teksty dotyczące spraw publicznych;
9. kto odpowiada za kontrolę redakcyjną i widoczne oznaczenia;
10. czy umowy regulują odpowiedzialność za komunikaty, interfejs, metadane, aktualizacje i dalsze użycie treści;
11. czy zmiana brandingu, przeznaczenia albo sposobu oferowania systemu nie wpływa na rolę firmy;
12. czy zespół potrafi wykazać, w jaki sposób obowiązki zostały wykonane.

Po inwentaryzacji trzeba przejść przez produkt, proces i umowy. Sam regulamin nie naprawi komunikatu, którego nie ma w interfejsie. Z kolei świetnie zaprojektowany baner nie rozwiąże problemu, jeżeli umowa nie mówi, kto ma go aktualizować po zmianie funkcji.

Art. 50 trzeba wdrożyć tam, gdzie użytkownik rzeczywiście spotyka AI: w interfejsie, pierwszej wiadomości, głosowym powitaniu, metadanych albo procesie publikacji.

AI ma się przedstawić. Najlepiej zanim użytkownik zdąży uznać, że po drugiej stronie siedzi człowiek.