AI ma się przedstawić. Co art. 50 AI Act zmienia od 2 sierpnia 2026 r.?

Od 2 sierpnia 2026 r. AI w wielu produktach musi zrobić coś zaskakująco ludzkiego: przedstawić się.

Jeżeli klient rozmawia z chatbotem, powinien wiedzieć, że po drugiej stronie nie siedzi człowiek. Gdy firma publikuje deepfake albo określony tekst wygenerowany przez AI, samo zdanie schowane w regulaminie może nie wystarczyć. Informacja ma pojawić się w odpowiednim miejscu, czasie i formie.

20 lipca 2026 r. Komisja Europejska opublikowała wytyczne dotyczące art. 50 AI Act. Strona z wytycznymi została zaktualizowana 31 lipca. Materiał przyda się zespołom SaaS, software house’om, e-commerce, marketingowi i organizacjom wdrażającym agentów AI, bo obowiązki przejrzystości nie dotyczą wyłącznie systemów wysokiego ryzyka.

Stan prawny i źródła sprawdzono 3 sierpnia 2026 r. Wytyczne Komisji pomagają interpretować przepisy, ale nie zastępują rozporządzenia ani wiążącej wykładni sądów.

Art. 50 AI Act nie wymaga jednej etykiety „created with AI”. Obowiązek zależy od funkcji systemu, roli organizacji i tego, co dzieje się z wynikiem.

Czego dowiesz się z tego tekstu?

W skrócie

• Od 2 sierpnia 2026 r. część providerów i deployerów musi stosować obowiązki przejrzystości z art. 50 AI Act.
• Provider interaktywnego systemu powinien zaprojektować go tak, aby człowiek wiedział, że rozmawia z AI, chyba że jest to oczywiste w konkretnym kontekście.
• Provider systemu generującego treści może odpowiadać za techniczne, maszynowo odczytywalne oznaczenie wyniku.
• Deployer może mieć własny obowiązek informacyjny przy rozpoznawaniu emocji, kategoryzacji biometrycznej, deepfake’ach i określonych tekstach o sprawach publicznych.
• Regulamin może wyjaśniać zasady, ale nie zastąpi komunikatu w interfejsie ani procesu oznaczania publikowanych treści.

Od kiedy stosuje się art. 50 AI Act?

Art. 50 AI Act stosuje się od 2 sierpnia 2026 r. Od tego dnia providerzy i deployerzy systemów objętych przepisem powinni realizować odpowiednie obowiązki przejrzystości. Potwierdzają to zarówno wytyczne Komisji, jak i oficjalny AI Act Service Desk.

Jest jeden wąski wyjątek czasowy. Rozporządzenie 2026/1744, czyli Digital Omnibus on AI, przewiduje okres przejściowy do 2 grudnia 2026 r. dla providerów systemów generujących syntetyczne treści, które zostały wprowadzone na rynek przed 2 sierpnia 2026 r. Wyjątek dotyczy obowiązku technicznego oznaczania i wykrywalności z art. 50 ust. 2. Nie przesuwa całego art. 50 dla wszystkich firm i wszystkich zastosowań.

Treści wygenerowanych i opublikowanych przed 2 sierpnia 2026 r. nie trzeba oznaczać wstecz. Komisja zachęca jednak do dobrowolnego oznaczania, jeżeli jest to możliwe.

Czy art. 50 dotyczy tylko systemów wysokiego ryzyka?

Nie. Art. 50 AI Act może objąć system niezależnie od tego, czy jest on systemem wysokiego ryzyka. Liczy się funkcja: bezpośrednia interakcja z człowiekiem, generowanie treści syntetycznych, rozpoznawanie emocji, kategoryzacja biometryczna albo wykorzystanie deepfake’u czy określonego tekstu o sprawach publicznych.

To ważne rozróżnienie dla firm, które uznały, że skoro ich chatbot nie podejmuje decyzji kredytowej ani nie ocenia kandydatów do pracy, AI Act ich nie dotyczy. System może nie być high-risk, a mimo to podlegać obowiązkom przejrzystości. Trzeba więc sprawdzać konkretną funkcję produktu, nie tylko ogólną klasyfikację ryzyka.

Jakie obowiązki wprowadza art. 50 AI Act?

Art. 50 rozdziela cztery podstawowe sytuacje. Każda ma innego adresata i inny sposób wykonania obowiązku.

1. Bezpośrednia interakcja człowieka z AI

Provider systemu przeznaczonego do bezpośredniej interakcji z człowiekiem powinien zaprojektować go tak, aby użytkownik wiedział, że ma kontakt z AI. Wyjątek działa wtedy, gdy sztuczny charakter interakcji jest oczywisty dla rozsądnie poinformowanej, uważnej osoby, z uwzględnieniem okoliczności i kontekstu użycia.

2. Generowanie albo istotna manipulacja treścią

Provider systemu generującego syntetyczny tekst, obraz, audio lub wideo powinien zapewnić, aby wynik był oznaczony w formacie maszynowo odczytywalnym i możliwy do wykrycia jako wygenerowany albo zmieniony przez AI. Rozwiązanie ma być skuteczne, interoperacyjne, odporne i wiarygodne w zakresie technicznie wykonalnym.

3. Rozpoznawanie emocji i kategoryzacja biometryczna

Deployer systemu rozpoznawania emocji lub kategoryzacji biometrycznej powinien poinformować osoby poddane jego działaniu. Nadal trzeba też przestrzegać przepisów dotyczących danych osobowych.

4. Deepfake i określone teksty o sprawach publicznych

Deployer systemu generującego albo zmieniającego obraz, audio lub wideo stanowiące deepfake powinien ujawnić sztuczne pochodzenie lub manipulację. Podobny obowiązek może dotyczyć tekstu publikowanego w celu informowania opinii publicznej o sprawach publicznych.

Informacja dla człowieka i techniczne oznaczenie treści rozwiązują dwa różne problemy. Jedno nie zastępuje automatycznie drugiego.

Kiedy chatbot lub agent AI powinien się przedstawić?

Chatbot, voicebot albo agent AI przeznaczony do bezpośredniej interakcji z człowiekiem powinien ujawnić swój charakter najpóźniej przy pierwszej interakcji lub ekspozycji. Informacja ma być jasna, odróżnialna od pozostałej treści i dostępna.

W praktyce dotyczy to między innymi:

• chatbotów obsługujących klientów,
• voicebotów przyjmujących zgłoszenia lub reklamacje,
• asystentów w aplikacji SaaS,
• agentów umawiających spotkania, prowadzących korespondencję lub składających zamówienia,
• cyfrowych doradców używanych w finansach, ubezpieczeniach, zdrowiu i usługach prawnych.

Nie opierałbym całego rozwiązania na zdaniu w regulaminie, polityce prywatności albo help center. Użytkownik powinien zobaczyć informację tam, gdzie rzeczywiście zaczyna kontakt z systemem.

Praktyczny komunikat może brzmieć:

Rozmawiasz z asystentem AI. Może popełniać błędy. W każdej chwili możesz poprosić o kontakt z człowiekiem.

Pierwsze zdanie realizuje podstawowy cel informacyjny. Pozostała część nie zawsze będzie wymagana przez art. 50, ale często ma sens z perspektywy UX, zarządzania ryzykiem i obsługi reklamacji.

Czy nazwa „asystent” wystarczy?

Samo określenie narzędzia jako „asystent” może być zbyt niejasne. Asystentem może być człowiek, prosty bot oparty na regułach albo system generatywny. Nazwa „Smart Support” też nie odpowiada wprost na pytanie, z kim rozmawia klient.

Przy ocenie, czy charakter systemu jest oczywisty, sprawdziłbym:

• grupę użytkowników i ich rozsądne oczekiwania,
• treść, wygląd i długość interakcji,
• możliwość pomylenia systemu z człowiekiem,
• skutek decyzji podjętej na podstawie odpowiedzi,
• język, kanał i dostępność komunikatu.

Im bardziej system naśladuje człowieka, przejmuje korespondencję albo podejmuje działania w imieniu firmy, tym słabszy jest argument, że użytkownik „powinien się domyślić”.

Czym różni się oznaczenie dla człowieka od oznaczenia dla maszyny?

Etykieta widoczna w interfejsie informuje człowieka. Oznaczenie maszynowo odczytywalne ma pozwolić narzędziom technicznym wykryć, że treść została wygenerowana lub zmieniona przez AI. Firma może potrzebować obu warstw, ale z różnych powodów i na różnych etapach procesu.

Provider systemu generującego syntetyczny tekst, obraz, audio lub wideo powinien co do zasady zadbać o techniczne oznaczenie wyniku i jego wykrywalność. Kodeks praktyk dotyczący przejrzystości treści generowanych przez AI opisuje dobrowolną ścieżkę wspierającą wykazywanie zgodności. Sam obowiązek ustawowy nie jest jednak dobrowolny.

Dla firmy tworzącej produkt oznacza to pytania:

• czy wynik zawiera metadane, content credentials, watermark albo inny znacznik,
• czy znacznik przetrwa eksport, kompresję, konwersję i publikację na zewnętrznej platformie,
• czy użytkownik może łatwo usunąć oznaczenie,
• jakie narzędzie pozwala zweryfikować pochodzenie treści,
• kto dokumentuje skuteczność, interoperacyjność, odporność i wiarygodność rozwiązania.

Art. 50 ust. 2 przewiduje wyjątek dla systemów wykonujących funkcję pomocniczą przy standardowej edycji albo takich, które nie zmieniają istotnie danych wejściowych lub ich znaczenia. Zwykła korekta pisowni czy formatowanie nie powinny być więc automatycznie traktowane tak samo jak wygenerowanie nowej treści.

Kiedy trzeba oznaczyć deepfake albo tekst o sprawach publicznych?

Deployer powinien ujawnić, że obraz, audio lub wideo stanowi deepfake. Przy dziełach ewidentnie artystycznych, kreatywnych, satyrycznych lub fikcyjnych sposób ujawnienia może być dostosowany tak, aby nie utrudniał odbioru utworu, ale informacja o sztucznym pochodzeniu nadal powinna się pojawić.

Obowiązek może też dotyczyć tekstu wygenerowanego lub zmienionego przez AI, który jest publikowany w celu informowania opinii publicznej o sprawach publicznych. Przepis przewiduje wyjątek, gdy materiał przeszedł proces kontroli człowieka lub kontroli redakcyjnej, a osoba fizyczna albo prawna ponosi odpowiedzialność redakcyjną za publikację.

Nie wystarczy więc nazwać każdej szybkiej akceptacji „human review”. Proces powinien pozostawić ślad:

• kto sprawdził materiał,
• jaki był zakres kontroli,
• czy zweryfikowano fakty i źródła,
• kto zatwierdził publikację,
• gdzie znajduje się finalna wersja i historia zmian.

Kazus: SaaS z agentem AI do obsługi reklamacji

To realistyczny kazus modelowy, nie historia klienta.

Polski SaaS wdraża dla sklepów internetowych agenta AI. Agent czyta zgłoszenie klienta, sprawdza dane zamówienia, proponuje rozwiązanie, wysyła odpowiedź i w prostych sprawach sam przyznaje kupon.

Na stronie widnieje tylko nazwa „Smart Support”. Regulamin wspomina ogólnie, że usługa może korzystać z automatyzacji. Sklep zakłada, że dostawca produktu odpowiada za wszystkie komunikaty. Dostawca uważa, że to sklep jest deployerem i sam powinien dodać informację.

No i mamy problem, bo trzeba ustalić co najmniej cztery rzeczy:

• role dostawcy SaaS i sklepu dla poszczególnych funkcji,
• miejsce oraz treść informacji o interakcji z AI,
• moment, w którym agent eskaluje sprawę do człowieka,
• odpowiedzialność za wdrożenie komunikatu, jego utrzymanie po zmianach interfejsu i dowody zgodności.

Sam status providera lub deployera zależy od konkretnej funkcji, celu i podziału odpowiedzialności. Szerzej wyjaśniam to w artykule o tym, kiedy organizacja jest deployerem, a kiedy może wejść w rolę providera.

Co software house powinien wpisać do umowy wdrożeniowej?

Umowa dotycząca produktu z AI powinna opisywać realny podział zadań. Ogólne zdanie, że „każda strona odpowiada za własną zgodność z prawem”, niewiele daje, gdy przed wdrożeniem komunikatu trzeba zmienić UI, przygotować tekst i dostać dane od dostawcy modelu.

W praktyce sprawdziłbym w umowie:

• zamierzony sposób użycia i grupy użytkowników,
• role stron na gruncie AI Act dla konkretnych funkcji,
• wymagania dotyczące informacji w interfejsie,
• obsługiwane metody technicznego oznaczania treści,
• ograniczenia modelu i dostawców zewnętrznych,
• odpowiedzialność za tekst komunikatu, jego lokalizację, testy i utrzymanie,
• procedurę zmian, gdy model, UI albo use case ulega istotnej modyfikacji,
• dokumentację odbiorową i dowody wykonania obowiązków.

Wdrożenie łączy pracę productu, UX, marketingu, supportu, bezpieczeństwa i osób zarządzających dostawcami. Prawnik może pomóc rozpisać odpowiedzialność, ale nie zaprojektuje w próżni zachowania systemu.

Co zrobić, jeżeli firma nie zdążyła przed 2 sierpnia?

Najpierw trzeba ustalić, które funkcje rzeczywiście wchodzą w zakres art. 50. Nie każdy element produktu z AI wymaga tego samego komunikatu, a okres przejściowy do 2 grudnia dotyczy tylko określonych systemów i obowiązku z art. 50 ust. 2.

Praktyczna kolejność działań wygląda tak:

• zmapuj chatboty, voiceboty, agentów, generatory treści, deepfake oraz narzędzia do rozpoznawania emocji i kategoryzacji biometrycznej,
• przypisz rolę providera i deployera osobno dla każdej funkcji,
• sprawdź, gdzie użytkownik po raz pierwszy spotyka AI,
• zaprojektuj komunikaty w produkcie i sprawdź ich dostępność,
• przejrzyj proces marketingowy i redakcyjny,
• zbierz od dostawców informacje o technicznym oznaczaniu wyników,
• zaktualizuj umowy, instrukcje, checklisty odbiorowe i rejestr systemów AI,
• zapisz decyzje, wyjątki i osoby odpowiedzialne.

Jeżeli firma nadal nie wie, z jakich narzędzi korzysta zespół, trzeba zacząć krok wcześniej. W tekście o Shadow AI i praktycznym AI governance opisuję, jak zbudować mapę narzędzi i podstawowe zasady używania AI.

Przejrzystość trzeba zaprojektować w produkcie

Informacja o AI nie może żyć wyłącznie w dokumentach prawnych. Musi działać w interfejsie, procesie publikacji, relacji z dostawcą i dokumentacji technicznej.

Regulamin może wyjaśnić zasady, lecz komunikat musi pojawić się wtedy, gdy klient zaczyna rozmawiać z agentem. Osobny proces powinien zatrzymać nieoznaczony deepfake przed publikacją. Art. 50 AI Act jest więc dobrym testem, czy legal, product i UX rzeczywiście pracują na tym samym produkcie.

Wdrażacie chatbota, agenta AI albo generator treści?

Pomagam firmom technologicznym, produktom SaaS i startupom ustalić role z AI Act, zaprojektować obowiązki informacyjne, uporządkować umowy z dostawcami oraz przygotować dokumentację wdrożenia.

Umów 30-minutową konsultację