AI governance dla agencji marketingowych, kreatywnych i deweloperskich

Dlaczego ryzyko AI w agencji to głównie cudze dane

Typowa firma zarządzająca AI martwi się wyciekiem własnych sekretów. Agencja uruchamia te same narzędzia na portfelu klientów, a niemal wszystko w oknie promptu należy do jednego z nich: brief, licencjonowane brand assets, lista klientów będąca danymi osobowymi klienta, codebase będący jego własnością intelektualną. To zmienia ryzyko na trzy sposoby. Zobowiązania są umowne i prawne, nie tylko rozsądne, bo umowy z klientami niosą klauzule poufności i często umowę powierzenia (DPA) określającą, dokąd dane mogą trafić. Blast radius jest szerszy, bo jeden nieostrożny prompt może ujawnić dane w poprzek granicy między dwoma klientami, którzy mogą być konkurentami. A ludzie, którzy wklejają, to kreatywni i deweloperzy pędzący pod deadline, gdzie narzędzie, które pomaga im dowieźć, to to samo narzędzie, które wynosi dane na zewnątrz. AI governance w agencji to mniej ochrona jednego perymetru, a bardziej kontrola tego, co przechodzi, per klient, do narzędzi, których nie jesteście właścicielem.

Poufność klienta i NDA, kiedy dane trafiają do narzędzi AI

Klauzula poufności, którą podpisaliście, nie ma wyjątku „chyba że narzędzie AI było wygodne". Kiedy wklejacie niewydaną kampanię klienta, dane finansowe albo źródło do usługi AI, ujawniacie ten materiał stronie trzeciej, czyli dostawcy AI, a to, czy to naruszenie, zależy od warunków dostawcy i od tego, co dopuszcza wasza umowa z klientem.

Decydują o tym dwa pytania. Czy dostawca zatrzymuje albo trenuje na tym, co przesyłacie, o czym w kolejnej sekcji. I czy umowa z klientem pozwala na dalsze ujawnienie procesorom, i na jakich warunkach. Wiele NDA dopuszcza ujawnienie podwykonawcom tylko wtedy, gdy są związani równoważnymi warunkami poufności. Konsumenckie konto AI, którego warunki pozwalają dostawcy wykorzystywać wasze dane wejściowe do ulepszania modeli, to nie jest równoważna poufność, więc przepuszczanie przez nie danych klienta może postawić was w naruszeniu, nawet jeśli nic nigdy publicznie nie wycieknie. Praktyczny ból pojawia się, kiedy klient pyta, które narzędzia AI dotykają jego danych, kiedy coś wycieka i rusza zegar powiadomienia o naruszeniu, albo kiedy projekt się kończy, a klient chce potwierdzenia, że jego materiał nie siedzi w oknie retencji.

Warunki dostawców dotyczące trenowania na waszych danych

Najważniejsze rozróżnienie w wykorzystaniu AI przez agencję to narzędzia, które domyślnie trenują na waszych danych wejściowych, i te, które tego nie robią. Zwykle pokrywa się to z granicą między planem konsumenckim a biznesowym, i wyznaczają je warunki dostawcy, nie wygląd interfejsu.

OpenAI deklaruje, że nie trenuje na danych wejściowych ani wyjściowych ze swoich produktów biznesowych, w tym ChatGPT Team, ChatGPT Enterprise i API, chyba że organizacja wyraźnie się na to zgodzi. Jego plany konsumenckie zachowują się inaczej: rozmowy w planach darmowym i indywidualnym mogą być wykorzystywane do ulepszania modeli, chyba że użytkownik to wyłączy w ustawieniach. Ten sam schemat powtarza się u głównych dostawców, gdzie płatny plan biznesowy albo enterprise niesie domyślny brak trenowania i umowę powierzenia (DPA), a plan darmowy albo osobisty nie. Dla agencji plan i umowa liczą się bardziej niż marka na ekranie logowania.

Co ustalić, zanim dane klienta dotkną jakiegokolwiek dostawcy AI:

• Czy dostawca domyślnie trenuje na danych wejściowych? · Dlaczego to ważne dla agencji: Jeśli tak, materiał klienta może trafić do zbioru treningowego i nie da się go odzyskać.
• Czy istnieje umowa powierzenia i plan biznesowy? · Dlaczego to ważne dla agencji: Zwykle potrzebujecie podpisanej DPA, żeby używać narzędzia jako procesora RODO dla danych klienta.
• Jak długo przechowywane są prompty i outputy, i gdzie? · Dlaczego to ważne dla agencji: Okna retencji i lokalizacja danych zasilają kwestionariusze klientów i zasady transferu.
• Czy dane wejściowe są przeglądane przez ludzi w ramach monitoringu nadużyć? · Dlaczego to ważne dla agencji: Nawet narzędzia bez trenowania mogą dopuszczać przegląd przez personel, co wciąż jest ujawnieniem stronie trzeciej.
• Kim są podprocesorzy stojący za narzędziem? · Dlaczego to ważne dla agencji: Model może działać na infrastrukturze innego dostawcy, wydłużając łańcuch.

Najczystsza zasada działania to ta, do której zbiega wiele agencji: standaryzujcie się na planach biznesowych albo enterprise z domyślnym brakiem trenowania i DPA dla każdej pracy dotykającej danych klienta, a prywatne darmowe konta traktujcie jako niedostępne dla materiału klienta.

Transparentność AI Act: oznaczanie treści generowanych przez AI, które produkujecie

To obowiązek z AI Act wymierzony najbardziej wprost w rodzaj pracy, który sprzedają agencje. Artykuł 50 ustala obowiązki transparentności dla niektórych systemów AI i zaczyna obowiązywać od 2 sierpnia 2026 na mocy artykułu 113. Dwie jego części dotyczą agencji produkującej media generowane przez AI.

Pierwsza to obowiązek oznaczania po stronie dostawcy. Artykuł 50(2) wymaga od dostawców systemów AI generujących syntetyczne audio, obraz, wideo lub tekst oznaczania outputów w formacie czytelnym maszynowo, wykrywalnym jako wygenerowane lub zmanipulowane sztucznie, przy użyciu rozwiązań skutecznych, interoperacyjnych, solidnych i niezawodnych na tyle, na ile jest to technicznie wykonalne. Ten obowiązek spoczywa na dostawcy systemu generatywnego, w większości przypadków dostawcy narzędzia, nie na agencji, która z niego korzysta, i nie ma zastosowania tam, gdzie system pełni funkcję wspomagającą przy standardowej edycji albo nie zmienia istotnie danych wejściowych deployera. Dla agencji istotne jest to, że narzędzia wbudowane w wasz pipeline mają nosić to oznaczenie, więc sprawdzenie, czy narzędzie je wspiera, zamiast je usuwać, jest częścią wyboru dostawcy.

Druga część spada bezpośrednio na agencję jako deployera. Artykuł 50(4) wymaga od deployerów systemu AI, który generuje lub manipuluje obrazem, audio lub wideo stanowiącym deepfake, ujawnienia, że treść została sztucznie wygenerowana lub zmanipulowana. Jeśli produkujecie syntetycznego rzecznika, zamianę twarzy lub głosu albo zmanipulowane wideo prawdziwej osoby na kampanię klienta, ten obowiązek ujawnienia spada na was. Ustawa zawęża go dla pracy kreatywnej: tam, gdzie treść jest częścią ewidentnie artystycznego, kreatywnego, satyrycznego lub fikcyjnego dzieła, obowiązek ogranicza się do ujawnienia istnienia treści generowanej, w sposób, który nie psuje dzieła. Równoległa zasada obejmuje tekst generowany przez AI publikowany, by informować publicznie w sprawach interesu publicznego, który musi być ujawniony, chyba że przeszedł ludzki przegląd i kontrolę redakcyjną, przy której nazwana osoba lub podmiot ponosi odpowiedzialność redakcyjną.

Dla agencji pytanie o ujawnienie należy do briefu kreatywnego, nie do momentu dostawy. Czy dany materiał jest deepfake'iem w rozumieniu artykułu 50(4), czy kwalifikuje się jako ewidentnie artystyczny i kto ponosi odpowiedzialność redakcyjną za tekst wspomagany przez AI w sprawach interesu publicznego, to decyzje do podjęcia i zapisania w trakcie tworzenia pracy.

Uwaga co do terminów. Data 2 sierpnia 2026 z artykułu 50 to obowiązujący tekst prawny na lipiec 2026. Digital Omnibus, przyjęty przez Parlament i Radę w czerwcu 2026, koryguje część harmonogramu AI Act, głównie daty dla systemów wysokiego ryzyka, ale wchodzi w życie dopiero po publikacji w Dzienniku Urzędowym, wciąż oczekującej, więc data 2 sierpnia 2026 dla artykułu 50 obowiązuje.

Pochodzenie i IP: kto jest właścicielem outputu AI, który dostarczacie

Agencje sprzedają deliverables i przenoszą do nich prawa na klientów. Output generowany przez AI komplikuje prawa, które faktycznie możecie przenieść, bo w niektórych jurysdykcjach może po prostu nie być prawa autorskiego do przeniesienia.

Najjaśniejsze aktualne stanowisko pochodzi ze Stanów Zjednoczonych. Amerykański Copyright Office, w swoich wytycznych i raporcie o zdolności do ochrony z 2025 roku, stoi na stanowisku, że do ochrony wymagane jest ludzkie autorstwo. Materiał wygenerowany wyłącznie przez AI, bez ludzkiego autora decydującego o elementach wyrazowych, nie jest chroniony. Urząd stwierdza też, że samo podanie promptu nie daje użytkownikowi wystarczającej kontroli, by być autorem, choć prawo autorskie może obejmować ludzkie części utworu zawierającego materiał generowany przez AI, takie jak twórczy wybór, aranżacja czy modyfikacja. Od wnioskodawców oczekuje się ujawnienia treści generowanych przez AI przy rejestracji.

Konsekwencja dla agencji jest konkretna. Jeśli deliverable jest w znacznej mierze wygenerowany przez AI, a za nim stoi tylko prompt, czysto maszynowo wygenerowana część może nie być czymś, co da się posiadać, a klauzula przenosząca obiecująca klientowi pełną, wyłączną własność wszystkich praw może obiecywać coś, czego nie ma. Ekspozycja działa w obie strony: klient, który później odkryje konkurenta wykorzystującego ponownie logo wygenerowane przez AI i przekona się, że nie może wyegzekwować prawa autorskiego, o którym myślał, że je posiada, wróci wzrokiem do umowy.

To, co działa, to uczynienie wykorzystania AI widocznym w umowie, zamiast przemilczanym. Ujawniajcie, gdzie narzędzia AI wyprodukowały deliverable. Prowadźcie zapisy pochodzenia, które assety były wygenerowane przez AI, wspomagane przez AI albo zrobione przez człowieka, żeby móc później odpowiedzieć na pytanie o własność. Dopasujcie język gwarancji i cesji IP do tego, co faktycznie prawdziwe, zamiast gwarantować czyste ludzkie autorstwo i pełne, zbywalne prawo autorskie do pracy, która tego progu nie spełnia. Prawa do materiału generowanego przez AI pozostają nieustalone i różnią się jurysdykcją, więc trwałym posunięciem jest dokładne ujawnienie i zapisy, nie ogólna obietnica.

Kwestionariusze bezpieczeństwa klientów dotyczące AI

Klienci coraz częściej dodają pytania o AI do kwestionariuszy bezpieczeństwa dostawców, a agencja stale jest po odbiorczej stronie tych pytań. Są przewidywalne: jakich narzędzi AI używacie na naszych danych, czy te narzędzia trenują na danych wejściowych, czy macie z nimi umowy powierzenia, czy możecie ujawnić wykorzystanie AI w deliverables, i czy oznaczacie treści generowane przez AI. Agencja, która nie potrafi odpowiedzieć konkretnie, zwykle traci albo zawiesza deal.

To, co pozwala na nie odpowiedzieć, to ten sam inwentarz, który i tak produkuje dobry governance: aktualna lista zatwierdzonych narzędzi AI, ich plany i domyślne ustawienia trenowania, podpisane DPA i zapis, gdzie AI było użyte w danym projekcie. Agencje, które dobrze radzą sobie z kwestionariuszami, traktują pakiet odpowiedzi jako aktualizowany na bieżąco, wielokrotnego użytku asset, więc każdy kwestionariusz zajmuje godziny, zamiast wykolejać tydzień. Kwestionariusz to też użyteczny mechanizm wymuszający. Pytania, które zadaje wyrobiony klient, to dobra mapa kontroli, warto je mieć wdrożone, zanim zapyta.

Kiedy budowanie AI dla klientów czyni was dostawcą

Wiele agencji przeszło od używania AI do jej budowania: chatbot na stronie klienta, funkcja AI wewnątrz produktu klienta, dostrojony model pod treści klienta. To przekracza linię w AI Act, bo budowanie i dowożenie może zmienić waszą rolę z deployera na dostawcę.

Artykuł 25 ustala odpowiedzialność wzdłuż łańcucha wartości. Dystrybutor, importer, deployer lub inna strona trzecia staje się dostawcą systemu AI wysokiego ryzyka, z obowiązkami dostawcy, w trzech sytuacjach: umieszczenia własnej nazwy lub znaku towarowego na systemie wysokiego ryzyka, wprowadzenia istotnej modyfikacji systemu wysokiego ryzyka, która utrzymuje go w tej kategorii, albo zmiany przeznaczenia systemu tak, że staje się on wysokiego ryzyka. Przeklasyfikowanie następuje z mocy prawa, niezależnie od tego, co mówi umowa.

Dla agencji realistyczne triggery to: budujecie funkcję do screeningu rekrutacyjnego albo związaną z kredytem, czyli przypadki wysokiego ryzyka z Załącznika III, i dowozicie ją pod swoją marką albo marką klienta; istotnie modyfikujecie system wysokiego ryzyka; albo przeznaczacie ogólne narzędzie do zastosowania wysokiego ryzyka. Większość pracy AI w agencji, chatbot marketingowy, generator treści, wewnętrzny asystent, nie jest wysokiego ryzyka i tego nie triggeruje. Chodzi o to, żeby wiedzieć, gdzie jest granica, zanim projekt ją przekroczy, bo dostawca dźwiga ocenę zgodności, dokumentację techniczną, system zarządzania jakością i obowiązki rejestracyjne, których deployer nie ma.

Równoległa zasada tkwi w reżimie modeli ogólnego przeznaczenia. Jeśli dostroicie model ogólnego przeznaczenia i zaoferujecie wynik komercyjnie innym, możecie stać się dostawcą tego zmodyfikowanego modelu, z dołączonymi obowiązkami dokumentacyjnymi, informacyjnymi wobec dalszego łańcucha, prawnoautorskimi i podsumowania treningu z artykułu 53. To dużo poniżej progu ryzyka systemowego 10^25 operacji zmiennoprzecinkowych mocy obliczeniowej treningu, którego agencja dostrajająca na treściach klienta nie zbliży się do osiągnięcia, ale wciąż czyni was dostawcą modelu, który dowozicie. Praktycznym posunięciem jest checkpoint przy przyjęciu projektu: przypadek wysokiego ryzyka, dostrajanie modelu pod dostawę albo umieszczenie waszej marki na cudzym systemie to moment na przegląd prawny, nie po starcie.

Praktyczny setup governance dla agencji

Nic z tego nie wymaga ciężkiego programu. To, co działa dla agencji, to mały, egzekwowany zestaw zasad, których mogą przestrzegać zespoły kreatywne i deweloperskie.

Zatwierdzone narzędzia, według planu. Utrzymujcie krótką listę usankcjonowanych narzędzi AI na planach biznesowych albo enterprise z domyślnym brakiem trenowania i podpisanymi DPA, i jasno komunikujcie, że prywatne darmowe konta nie są dla materiału klienta. Dajcie ludziom dobre narzędzia, żeby przestali sięgać po niekontrolowane.

Zasady dotyczące danych, które ludzie zapamiętają. Prosta linijka bije długą politykę: poufny materiał klienta i dane osobowe trafiają wyłącznie do zatwierdzonych narzędzi, nigdy na prywatne albo darmowe konto. Usuwajcie dane identyfikujące tam, gdzie zadanie ich nie wymaga.

Ujawnienie wobec klientów, ustalone z góry. Uzgodnijcie z każdym klientem, jak traktowane jest wykorzystanie AI: czy narzędzia AI mogą być używane na jego danych, jak ujawniane są deliverables wspomagane przez AI i kto dźwiga obowiązki oznaczania i odpowiedzialności redakcyjnej za treści syntetyczne albo dotyczące interesu publicznego. Wpisanie tego do zaangażowania na starcie usuwa niezręczną rozmowę później.

Zapisy pochodzenia. Prowadźcie lekki zapis per projekt, które assety były wygenerowane przez AI, wspomagane przez AI albo zrobione przez człowieka, i jakich narzędzi użyto. To zasila odpowiedzi na kwestionariusze, pytania o własność i decyzje o oznaczaniu z jednego źródła.

Pakiet odpowiedzi na kwestionariusze. Trzymajcie aktualny, wielokrotnego użytku zestaw odpowiedzi o waszych narzędziach AI, domyślnych ustawieniach trenowania, DPA i praktyce oznaczania, żeby przeglądy bezpieczeństwa u klientów były szybkie i spójne.

Checkpoint budowa kontra użycie. Kierujcie każdy projekt, który buduje funkcję AI, dostraja model pod dostawę albo brandinguje cudzy system, przez szybki przegląd pod kątem ekspozycji na status dostawcy z AI Act, zanim wystartuje.

Kompetencje AI dla zespołu. Artykuł 4 AI Act, obowiązujący od 2 lutego 2025, wymaga od dostawców i deployerów zapewnienia wystarczającego poziomu kompetencji AI wśród personelu obsługującego systemy AI. Dla agencji to głównie kwestia praktyczna: zespół powinien wiedzieć, które narzędzia są zatwierdzone, dlaczego prywatne konta są niedostępne dla pracy klienckiej, i jakie są obowiązki oznaczania i ujawniania.

Celem jest, żeby ścieżka objęta governance była tą łatwiejszą. Kiedy zatwierdzone narzędzia są dobre, a zasady krótkie, ludzie ich przestrzegają, a dane przestają wychodzić bocznymi drzwiami.

Źródła

• Regulation (EU) 2024/1689 (EU AI Act), Article 50 (obowiązki transparentności) · https://artificialintelligenceact.eu/article/50/ (oznaczanie treści syntetycznych, ujawnianie deepfake, wyjątki artystyczne i redakcyjne, zastosowanie od 2 sierpnia 2026)
• EU AI Act, Article 25 (odpowiedzialność wzdłuż łańcucha wartości) · https://artificialintelligenceact.eu/article/25/ (kiedy deployer staje się dostawcą)
• EU AI Act, Article 4 (kompetencje AI) · https://artificialintelligenceact.eu/article/4/ (w mocy od 2 lutego 2025)
• European Commission, Code of Practice on marking and labelling of AI-generated content · https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content (status wdrożenia artykułu 50)
• OpenAI, How your data is used to improve model performance · https://openai.com/policies/how-your-data-is-used-to-improve-model-performance/ (produkty biznesowe i API bez domyślnego trenowania, opt-out dla planu konsumenckiego)
• OpenAI Enterprise privacy · https://openai.com/enterprise-privacy/ (domyślny brak trenowania dla produktów biznesowych)
• US Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (2025) · https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf (wymóg ludzkiego autorstwa, prompt niewystarczający)
• US Copyright Office, Works Containing Material Generated by Artificial Intelligence (policy guidance) · https://www.copyright.gov/ai/ai_policy_guidance.pdf (ujawnianie treści AI przy rejestracji)
• GDPR Article 28 (Processor) · https://gdpr-info.eu/art-28-gdpr/ (udokumentowane instrukcje, autoryzacja podprocesora)
• EDPB Guidelines 07/2020 on controller and processor concepts · https://www.edpb.europa.eu/system/files/2023-10/EDPB_guidelines_202007_controllerprocessor_final_en.pdf