Od 2 sierpnia 2026 stosuje się art. 50 AI Act, czyli obowiązki przejrzystości: informowanie o rozmowie z botem, oznaczanie treści generowanych przez AI, ujawnianie deepfake’ów. Przesunięto natomiast to, co większości wdrożeniowców nie dotyczy: reżim systemów wysokiego ryzyka wylądował na grudniu 2027 i sierpniu 2028. Jeśli budujesz automatyzacje z LLM w n8n, oznacza to w praktyce kilka konkretnych ustawień w przepływie, a nie wielki projekt zgodności.
Stan prawny na wrzesień 2026, ze źródłami pierwotnymi. To nie jest opinia prawna: przy wątpliwościach idź do prawnika. I zastrzeżenie wprost: ten artykuł powstaje z pomocą AI w opisywanym tu procesie, a redakcję i odpowiedzialność za treść ponosi człowiek. Ujawniamy to dobrowolnie, nie z obowiązku: tekst po ludzkiej redakcji korzysta z wyjątku redakcyjnego.
Z tego artykułu dowiesz się:
- co dokładnie weszło 2.08.2026, a co przesunięto (z tabelą dat z EUR-Lex),
- kiedy integrator API jest providerem, a kiedy tylko deployerem i co z tego wynika,
- jakie 7 rzeczy sprawdzić w automatyzacji z LLM, żeby spełnić art. 50,
- jaką politykę danych per model zastosować (DPA, retencja, ZDR, darmowe endpointy).
1. Co weszło 2 sierpnia 2026, a co przesunięto
Na rynku krąży skrót myślowy: „AI Act przesunięty, można poczekać”. To pół prawdy, które wprowadza w błąd. Przesunięto obowiązki dla systemów wysokiego ryzyka, żeby dać czas na normy zharmonizowane i ocenę zgodności. Ale art. 50, czyli przejrzystość, która może objąć typową automatyzację z LLM, stosuje się od 2 sierpnia 2026. Komisja Europejska potwierdziła to wprost w wytycznych opublikowanych 20 lipca 2026.
Od tej samej daty ruszył nadzór. Zakazane praktyki, kompetencje AI z art. 4 i przejrzystość z art. 50 egzekwują krajowe organy nadzoru rynku, a AI Office ma własny, węższy zakres dotyczący modeli ogólnego przeznaczenia.
Co dokładnie przesunął Omnibus
Rozporządzenie UE 2026/1744 zmieniło art. 113 AI Act i odsunęło terminy dla systemów high-risk: załącznik III (HR, edukacja, scoring, usługi publiczne) na 2 grudnia 2027, a produkty z załącznika I na 2 sierpnia 2028. Art. 50 nie został odsunięty ani o dzień.
Jest też jeden wąski okres przejściowy. Oficjalne FAQ AI Act Service Desk podaje, że dotyczy on wyłącznie systemów wprowadzonych na rynek przed 2 sierpnia 2026 i tylko obowiązku oznaczania oraz wykrywalności treści z art. 50 ust. 2, z terminem dostosowania do 2 grudnia 2026. Podstawą jest art. 111 ust. 4. Nowe wdrożenia tego okresu nie mają.
Tabela: kiedy co obowiązuje
| Data | Co obowiązuje | Czy dotyczy typowej automatyzacji z LLM |
|---|---|---|
| 2.02.2025 | zakazane praktyki + art. 4 (AI literacy) | tak, art. 4 |
| 2.08.2026 | art. 50 przejrzystość + start egzekwowania | tak, kluczowa data |
| 2.12.2026 | termin art. 50 ust. 2 dla systemów sprzed 2.08.2026 | tylko dla starszych systemów |
| 2.12.2027 | high-risk z załącznika III | tylko przy zastosowaniach high-risk, np. HR lub edukacji |
| 2.08.2028 | high-risk wbudowane w produkty z załącznika I | rzadko |
Co to zmienia w Twoim workflow
Praktyczna konsekwencja: typowy przepływ z chatbotem albo generowaniem treści sprawdzasz dzisiaj, bo art. 50 już działa. Klasyfikację high-risk badasz osobno i ona nie parzy, dopóki automatyzacja nie wchodzi w HR, edukację, scoring albo usługi publiczne. Przy każdym wdrożeniu z LLM sprawdź, czy art. 50 go dotyczy: zależy to od roli, funkcji i sposobu użycia.
Kolejność: najpierw art. 50, potem analiza high-risk tam, gdzie kontekst na to wskazuje.
2. Provider czy deployer: kiedy integrator API odpowiada za art. 50
Najczęstsze pytanie brzmi: „skoro wołam API OpenAI z n8n, to czy jestem dostawcą modelu GPAI?”. Nie. Dostawcą modelu GPAI jest ten, kto model stworzył lub znacząco zmodyfikował. W FAQ Komisji o obowiązkach GPAI zapisano, że podmiot fine-tunujący istniejący model staje się providerem modelu GPAI tylko wyjątkowo, gdy modyfikacja zużywa więcej niż jedną trzecią training compute modelu pierwotnego. Samo wywoływanie endpointu, nawet z własnym promptem, tej granicy nie przekracza.
To nie koniec analizy: art. 50 rozróżnia dwie inne role, dostawcę systemu AI i deployera.
- Provider systemu: rozwija system AI albo zleca jego rozwinięcie, a następnie wprowadza go do obrotu lub oddaje do użytku pod własną nazwą lub znakiem towarowym (art. 3 pkt 3).
- Deployer: używa systemu pod swoją kontrolą w ramach działalności. Ta sama organizacja może występować w obu rolach przy różnych elementach jednego wdrożenia. Przy chatbocie budowanym dla klienta rozstrzyga to, pod czyją nazwą system trafia do użytku. Idzie pod marką klienta, więc zwykle to klient jest dostawcą, a Ty wykonawcą technicznym. Sprzedajesz tego samego bota jako własny produkt pod swoją marką, więc dostawcą jesteś Ty.
Drzewko decyzyjne
- Rozwijasz system lub zlecasz jego rozwinięcie i wprowadzasz go do obrotu albo oddajesz do użytku pod własną nazwą lub znakiem? Nie → nie jesteś z tego powodu providerem; sprawdź, czy używasz systemu pod własną kontrolą jako deployer, czy tylko świadczysz usługę techniczną. Tak → jesteś dostawcą systemu AI.
- System wchodzi w bezpośrednią interakcję z osobą fizyczną? Tak → sprawdź art. 50 ust. 1: informacja o rozmowie z AI przy pierwszej interakcji.
- System generuje syntetyczny tekst, obraz, audio lub wideo? Tak → jako provider odpowiadasz za art. 50 ust. 2 (oznaczanie), jako deployer sprawdzasz ust. 4 (ujawnianie deepfake’ów i tekstów o sprawach interesu publicznego).
Kto za co odpowiada
Przy własnym produkcie ust. 1 dotyczy informacji o interakcji z AI, na przykład pierwszej wiadomości bota, a ust. 2 technicznego oznaczania wyników. Art. 50 AI Act nakazuje dostawcom systemów AI generujących syntetyczny tekst, audio, obraz lub wideo zapewnienie oznaczenia outputów w formacie maszynowo odczytywalnym i wykrywalnym jako sztucznie wygenerowane.
Ust. 4 obciąża deployera: publikując deepfake albo tekst o sprawach interesu publicznego, musisz ujawnić, że treść została wygenerowana. Dla tekstu działa wyjątek redakcyjny: jeśli treść przeszła ludzką weryfikację, a ktoś ponosi odpowiedzialność redakcyjną, obowiązek znika. Stąd prosty proces akceptacji i wskazana osoba lub podmiot ponoszący odpowiedzialność redakcyjną.
3. Checklista 7 punktów: art. 50 w praktyce w n8n
Zamiast abstrakcyjnych obowiązków, oto siedem rzeczy do sprawdzenia w każdym wdrożeniu z LLM. Stan prawny: wrzesień 2026.
- Ustal rolę w każdym workflow. Zapisz w dokumentacji wdrożenia, kto jest dostawcą systemu, a kto deployerem. Od tego zależy, które obowiązki z art. 50 spadają na którą stronę, a ta notatka ułatwia potem wykazanie, dlaczego przyjęliście taką kwalifikację.
- Poinformuj o interakcji z AI. Chatbot lub voicebot informuje najpóźniej przy pierwszej wiadomości: „Rozmawiasz z asystentem AI”. W n8n to zwykle statyczny węzeł przed pierwszym wywołaniem modelu. Wyjątek stosuj tylko wtedy, gdy kontakt z AI jest oczywisty dla rozsądnie uważnej osoby.
- Zapewnij maszynowe oznaczanie outputów. Jeśli jesteś dostawcą systemu generującego syntetyczny tekst, obraz, audio lub wideo, sprawdź, czy metadane, znak wodny albo inne rozwiązanie jest skuteczne i wykrywalne zgodnie z art. 50 ust. 2.
- Dodaj widoczne ujawnienie tam, gdzie odpowiadasz jako deployer. Dotyczy przede wszystkim deepfake’ów i tekstów o sprawach interesu publicznego. Do etykietowania można użyć zestawu ikon UE z Code of Practice.
- Zaprojektuj rzeczywisty human review. Przy publikowanych tekstach ustaw w workflow węzeł akceptacji: osoba z wiedzą i uprawnieniami redakcyjnymi zatwierdza treść przed publikacją. Sprawdzenie pisowni nie wystarcza do wyjątku redakcyjnego.
- Prowadź log źródeł i wersji. Zapisuj model, wersję, datę, identyfikator promptu i wynik ludzkiej weryfikacji. Formalnie nie jest to samodzielny obowiązek z art. 50, a taki log pomaga udokumentować, że weryfikacja faktycznie się odbyła.
- Informuj o rozpoznawaniu emocji i biometrii. Jeśli automatyzacja używa rozpoznawania emocji lub kategoryzacji biometrycznej, osoby poddane działaniu systemu muszą o tym wiedzieć.
Czy oznaczać własny blog, shorta i e-mail?
- Blog: ujawnienie z art. 50 ust. 4 dotyczy tekstu publikowanego w celu informowania o sprawach interesu publicznego. Jeśli treść przeszła ludzką weryfikację i ktoś ponosi odpowiedzialność za publikację, wyjątek redakcyjny działa. Udział AI w tym artykule ujawniamy więc dobrowolnie, jako element przejrzystości procesu.
- Short: widoczne ujawnienie jest potrzebne, jeśli materiał stanowi deepfake. Niezależnie od tego dostawca systemu odpowiada za techniczne oznaczanie z ust. 2.
- E-mail: zwykła wiadomość do klienta to nie publikacja dla społeczeństwa. Osobno oceń tylko obowiązek informowania o rozmowie z botem. Podawanie nazw użytych modeli nie jest wymagane przez art. 50, ale nic nie stoi na przeszkodzie robić to dobrowolnie. Jeśli routerujesz modele, pamiętaj, że to, który z nich faktycznie odpowiedział, odczytasz dopiero z odpowiedzi API: natywny węzeł w n8n tego nie pokazuje, więc log budujesz po stronie żądania HTTP.
4. Dane osobowe klienta per model: DPA, retencja, ZDR i darmowe endpointy
Jedno rozgraniczenie: art. 50 reguluje przejrzystość systemów AI, a przetwarzanie danych osobowych nadal rządzi RODO. Oznaczenie bota „jestem AI” nie załatwia legalności przetwarzania danych, które ten bot zbiera. Obie ścieżki trzeba mieć domknięte.
Cztery rzeczy do ustalenia przed pierwszym produkcyjnym runem
- Umowa powierzenia. Ustal, kto jest procesorem, a kto dalszym procesorem, i czy Twoja umowa obejmuje cały łańcuch razem z listą podprocesorów. Przy routerze nie zakładaj, że jedna umowa pokrywa wszystko.
- Lista sub-procesorów. Sprawdź, kogo dostawca angażuje dalej i jak o tym informuje.
- Okres retencji. Ile dni dane leżą u dostawcy i czy da się to skrócić.
- Podstawa transferu poza EOG. Jeżeli dane opuszczają EOG, potrzebujesz mechanizmu transferu opisanego u dostawcy. Miejsce przetwarzania zależy od dostawcy i endpointu, więc sprawdź je, zamiast zakładać.
OpenAI: co realnie dostajesz
OpenAI podaje w dokumentacji platformy, że od 1 marca 2023 dane wysyłane przez API nie są domyślnie używane do trenowania modeli, ale logi monitoringu nadużyć mogą zawierać prompty i odpowiedzi i są domyślnie przechowywane do 30 dni. Czyli: trening wyłączony, ale nie zero retencji. Dostępność Zero Data Retention zależy od zatwierdzenia konta i funkcji, więc potwierdź ją przed wdrożeniem z danymi osobowymi.
OpenRouter: zasada zamiast listy
Przy routerze modeli obowiązuje jedna zasada: sprawdzasz politykę konkretnego dostawcy i endpointu, nie samej platformy. W dokumentacji OpenRouter o ZDR zapisano, że jeśli platforma nie potrafi ustalić jasnej polityki dostawcy lub endpointu, przyjmuje konserwatywnie, że taki endpoint retencjonuje dane i trenuje na nich, i tak go oznacza. Brak informacji to najgorszy scenariusz. Tam, gdzie ZDR jest dostępne, wymuszaj je w routingu.
Darmowe endpointy a dane klienta
Darmowy model nie jest automatycznie niedopuszczalny. Kryterium brzmi inaczej: do danych klienta nie używaj endpointu, dla którego nie potrafisz potwierdzić zasad treningu, retencji i udziału podwykonawców. Do prototypu używaj danych syntetycznych: bezpieczniej przetestujesz wtedy także modele o mniej przewidywalnej polityce danych. Regulaminy dostawcy obowiązują dalej.
W praktyce, w samym workflow
Trzy ustawienia, które stosuję w każdym przepływie z danymi osobowymi: osobny klucz API dla takich przepływów, pseudonimizacja przed wysłaniem promptu (imiona, adresy i numery zastąpione tokenami; dopóki da się je odwrócić, to nadal dane osobowe) i wyłączenie tych danych z logów n8n, bo log wykonania bywa źródłem wycieku, o którym nikt nie pamięta.
Podsumowanie
Stan na wrzesień 2026: art. 50 stosuje się od 2 sierpnia 2026, a nadzór już ruszył. Omnibus (rozporządzenie 2026/1744) przesunął głównie reżim high-risk: załącznik III na 2.12.2027, produkty z załącznika I na 2.08.2028. To akurat ta część, która nie dotyczy większości typowych automatyzacji z LLM.
Nie każde wdrożenie ma identyczne obowiązki. Zanim cokolwiek ustawisz, ustal trzy rzeczy: swoją rolę, czy system kontaktuje się z człowiekiem i jakie treści generuje.
Trzy działania na dziś:
- Dodaj informację o AI do pierwszej interakcji każdego właściwego bota.
- Przypisz role provider/deployer w dokumentacji każdego wdrożenia.
- Sprawdź polityki danych (DPA, retencja, ZDR) modeli używanych przy danych klienta. Przejdź tę checklistę u siebie. Jeśli konkretny przypadek budzi wątpliwości, skonsultuj go z prawnikiem. To nie opinia prawna, ale te ustawienia w przepływie możesz zrobić już dziś.
Jakie są kary za naruszenie art. 50?
Do 15 mln euro albo do 3% całkowitego światowego rocznego obrotu za poprzedni rok obrotowy (art. 99 ust. 4). Dla MŚP obowiązuje dodatkowa reguła z art. 99 ust. 6: kara nie może przekroczyć niższej z tych dwóch wartości, czyli kwoty stałej albo procentu obrotu. Traktuj to jako kontekst, nie jako główny argument: podane kwoty są maksimami, a nie stawkami startowymi.
Kto kontroluje w Polsce i od kiedy realnie?
Polska ma ustawę wdrażającą: Ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003), ogłoszoną 27 lipca 2026, która weszła w życie 11 sierpnia 2026. Przepisy o kontroli, postępowaniu i karach wejdą w życie 28 października 2026. Ustawa tworzy Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji jako krajowy organ nadzoru rynku, a narzędzia kontrolne uruchamiają się pod koniec października.
Czy obowiązek AI literacy nadal mnie dotyczy?
Tak, ale w złagodzonej formie. Rozporządzenie 2026/1744, przyjęte 8 lipca 2026, opublikowane w Dz.Urz. UE 24 lipca 2026 i obowiązujące od 27 lipca 2026, zmieniło art. 4 tak, że dostawcy i podmioty stosujące mają podejmować środki wspierające rozwój kompetencji AI, zamiast je zapewniać. Udokumentowane szkolenie albo instrukcja mogą być elementem takich środków, choć nie dają automatycznej gwarancji zgodności.
Od kiedy realnie egzekwuje się AI literacy?
Sam obowiązek nie jest nowy, ale jego egzekwowanie tak. Na stronie Komisji o AI literacy wskazano, że art. 4 AI Act wszedł w stosowanie 2 lutego 2025, natomiast nadzór i egzekwowanie przez krajowe organy nadzoru rynku ruszyły dopiero 2 sierpnia 2026. Praktycznie: dokumentuj te środki dziś, bo ktoś może o nie zapytać.
Źródła
Stan prawny na wrzesień 2026. Twierdzenia o treści i terminach przepisów opierają się na źródłach pierwotnych: EUR-Lex, dokumentach Komisji Europejskiej i AI Act Service Desk. Uwagi praktyczne o umowach powierzenia, podprocesorach i transferach danych to doświadczenie wdrożeniowe, nie wykładnia prawa. Poniżej pełna lista z krótkim opisem, do czego każde źródło było użyte.
Akty prawne
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), rozporządzenie zmieniające AI Act: przesunięcie terminów high-risk, okres przejściowy z art. 111 ust. 4, złagodzenie art. 4 (AI literacy). Podstawa tabeli timeline.
- Ustawa z dnia 3 lipca 2026 r. o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003), polska ustawa wdrażająca AI Act, tworząca KRiBSI jako organ nadzoru rynku.
Przepisy AI Act (AI Act Service Desk)
- Article 3 AI Act, definitions, definicje pojęć, w tym systemu AI, dostawcy i podmiotu stosującego. Podstawa analizy ról w sekcji 2.
- Article 50 AI Act, pełny tekst przepisu o transparentności, punkt po punkcie: ust. 1 (informacja o interakcji), ust. 2 (maszynowe oznaczanie), ust. 4 (deepfake’i i teksty o sprawach publicznych), ust. 5 (forma i moment informacji).
- Article 99 AI Act, penalties, widełki kar, w tym reguła ochronna dla MŚP z ust. 6, cytowana w FAQ.
- When does enforcement start? | AI Act Service Desk, oficjalne FAQ o starcie egzekwowania od 2 sierpnia 2026 i o zakresie okresu przejściowego dla art. 50 ust. 2.
Wytyczne i kody dobrej praktyki (Komisja Europejska)
- Guidelines on transparency obligations for providers and deployers of AI systems, wytyczne z 20 lipca 2026 wyjaśniające zakres art. 50, role w łańcuchu wartości i przykłady tego, co podlega, a co nie.
- Code of Practice on Transparency of AI-generated Content, dobrowolny kod potwierdzony przez Komisję i AI Board jako odpowiedni sposób wykazania zgodności z obowiązkami oznaczania i etykietowania treści.
- Guidelines on obligations for General-Purpose AI providers, FAQ o granicy między integratorem API a dostawcą modelu GPAI, w tym próg modyfikacji dla fine-tuningu.
- AI talent, skills and literacy, strona Komisji o AI literacy, z datami stosowania i egzekwowania art. 4.
Polityki danych dostawców modeli
- Data controls in the OpenAI platform, dokumentacja OpenAI: domyślny brak treningu na danych z API, 30-dniowa retencja logów, warunki Zero Data Retention.
- Zero Data Retention | OpenRouter, dokumentacja OpenRouter: zasada konserwatywna dla endpointów bez ustalonej polityki oraz sposoby wymuszania ZDR w routingu. Tekst rozporządzenia 2024/1689 (AI Act) we wszystkich językach UE znajdziesz na EUR-Lex, a bieżące pytania i odpowiedzi na platformie AI Act Service Desk. Przy decyzjach klasyfikacyjnych dla konkretnego wdrożenia podstawą jest zawsze tekst rozporządzenia, a nie streszczenia, łącznie z tym artykułem.
