RODO a agenci AI: jak legalnie zlecić automatyzacji przetwarzanie danych klientów (checklista dokumentów przed pierwszym wdrożeniem)

Większość poradników o RODO i AI kończy się na ogólnym „skonsultuj się z prawnikiem” albo na strasznym wyliczeniu kar. To prawda, ale nikomu nie pomaga uruchomić agenta w piątek po południu. My patrzymy na to od strony wdrożeniowej: co realnie trzeba mieć podpisane, zaznaczone albo zmienione w panelu dostawcy, zanim agent dostanie dostęp do bazy klientów, historii zamówień albo treści maili z reklamacjami.

Gdzie w praktyce jest dziura w dokumentacji

Typowy scenariusz wygląda tak: dział obsługi klienta albo księgowość chce przyspieszyć pracę, ktoś w firmie ma konto ChatGPT Plus albo Claude Pro i zaczyna wklejać tam fragmenty korespondencji z klientami, żeby dostać gotową odpowiedź albo podsumowanie. To już jest przetwarzanie danych osobowych poza infrastrukturą firmy, bez żadnej umowy powierzenia, bo konta konsumenckie (Plus, Pro, darmowe) w większości przypadków w ogóle nie oferują takiej umowy do podpisania. Dostawca może w takim modelu wykorzystywać treści rozmów do trenowania kolejnych wersji modelu, chyba że użytkownik ręcznie wyłączy tę opcję w ustawieniach prywatności, o czym rzadko kto pamięta.

Druga wersja tego samego problemu pojawia się już przy properszych wdrożeniach: firma buduje agenta na API OpenAI albo Anthropic, ma nawet podpisaną jakąś umowę, ale nikt nie sprawdził, czy to jest umowa powierzenia zgodna z art. 28 RODO, czy tylko standardowy regulamin API. To nie jest to samo. Regulamin usługi mówi, na jakich zasadach korzystasz z serwisu. Umowa powierzenia (Data Processing Addendum, DPA) mówi, kto jest administratorem, kto procesorem, jakie są zabezpieczenia i co się dzieje z danymi po zakończeniu współpracy. Bez DPA firma, która wysyła dane osobowe klientów do modelu AI, przetwarza je bez podstawy prawnej wobec podmiotu trzeciego, nawet jeśli sam agent działa poprawnie technicznie.

Umowa powierzenia przetwarzania z dostawcą modelu (art. 28 RODO)

Zanim agent AI dostanie dostęp do jakichkolwiek danych osobowych klientów, potrzebna jest podpisana umowa powierzenia z dostawcą modelu. OpenAI, Anthropic i Google oferują takie umowy w ramach kont biznesowych (odpowiednio API biznesowe, Anthropic dla firm, Google Cloud / Vertex AI), ale trzeba je aktywnie zaakceptować, nie są domyślną częścią każdego konta. Umowa powinna określać co najmniej: zakres i cel przetwarzania, kategorie danych, czas trwania, obowiązki zabezpieczenia danych, zasady zgłaszania incydentów oraz, co często pomijane, listę podpowierzających (subprocessors), czyli firm trzecich, którym dostawca modelu dalej zleca część infrastruktury (np. hosting u AWS czy Azure).

W praktyce przy wdrożeniach dla klientów sprawdzamy trzy rzeczy w tej umowie: czy w ogóle istnieje i jest podpisana (nie „zaakceptowana kliknięciem” w regulaminie, tylko realnie zawarta), czy pokrywa dokładnie ten produkt, którego używamy (API czy inny endpoint, bo różne produkty tego samego dostawcy mogą mieć różne warunki), i czy jest aktualna wersja, bo dostawcy modeli zmieniają te dokumenty częściej niż firmy zdążają je czytać.

Podpowierzenie i łańcuch odpowiedzialności

Jeśli budujesz agenta na platformie no-code, która pod spodem woła API OpenAI, masz dodatkowe ogniwo w łańcuchu: firma (administrator) → platforma automatyzacji (procesor) → dostawca modelu (podprocesor). Każde ogniwo powinno mieć umowę powierzenia z poprzednim. W praktyce oznacza to, że wybierając narzędzie do automatyzacji, warto zapytać dostawcę wprost, czy ma podpisane DPA ze wszystkimi podprocesorami i czy udostępni tę listę. Jeśli dostawca nie potrafi na to odpowiedzieć konkretnie, to sygnał ostrzegawczy, niezależnie od tego, jak dobrze wygląda demo.

Transfer danych poza EOG: co realnie zmienił Data Privacy Framework

Większość dużych dostawców LLM (OpenAI, Anthropic, Google) przetwarza dane na serwerach w USA. Do lipca 2023 roku transfer danych osobowych z UE do USA opierał się na niepewnym gruncie prawnym po unieważnieniu wcześniejszych mechanizmów przez Trybunał Sprawiedliwości UE. Sytuację uporządkował Data Privacy Framework (DPF) z 2023 roku: firmy amerykańskie, które certyfikują się w tym programie, mogą legalnie odbierać dane osobowe z UE bez dodatkowych mechanizmów typu standardowe klauzule umowne.

To, co warto sprawdzić przy wyborze dostawcy modelu, to czy konkretna spółka (nie firma-matka w ogóle, tylko podmiot, z którym faktycznie podpisujesz umowę) jest wpisana na listę certyfikowanych podmiotów DPF. Certyfikacja nie jest automatyczna i nie obejmuje z automatu wszystkich produktów danej firmy. Jeśli dostawca nie jest certyfikowany albo certyfikacja nie obejmuje danego produktu, transfer danych wciąż może być legalny, ale wymaga dodatkowego mechanizmu, najczęściej standardowych klauzul umownych (SCC) wraz z oceną skutków transferu (transfer impact assessment). To dodatkowa praca prawna, którą trzeba wykonać przed startem, nie po.

Wybór dostawcy LLM: nie każde API jest takie samo

Przy wyborze modelu do agenta przetwarzającego dane klientów decyzja nie powinna zapadać wyłącznie na podstawie jakości odpowiedzi. Kluczowe jest to, jaką wersję produktu wybierasz: konsumencką czy biznesową, bo różnice w polityce danych są ogromne.

Opcja „zero data retention” zasługuje na osobne zdanie, bo to jest ta konkretna rzecz, którą realnie trzeba włączyć, a nie tylko wiedzieć, że istnieje. W standardowym trybie API dostawcy modeli przechowują dane wejściowe i wyjściowe przez pewien czas (zwykle do 30 dni) do celów nadzoru nad nadużyciami. Zero data retention (dostępne u części dostawców dla wybranych produktów, po spełnieniu określonych warunków, często wymaga osobnego wniosku) oznacza, że zapytania nie są przechowywane po przetworzeniu. Przy agentach obsługujących dane wrażliwe, np. treści reklamacji zawierające dane o zdrowiu klienta albo dokumenty finansowe, to jest ustawienie, które warto mieć włączone, a nie zostawione na „domyślnie”.

Checklista dokumentów przed uruchomieniem agenta

To jest lista, którą realnie przechodzimy przy każdym wdrożeniu, w którym agent AI ma dostęp do danych osobowych klientów. Jeśli którejś pozycji brakuje, wdrożenie się nie uruchamia, niezależnie od tego, jak dopracowany jest sam prompt czy scenariusz automatyzacji.

• Podpisana umowa powierzenia (DPA) z dostawcą modelu, aktualna dla używanego produktu i endpointu
• Weryfikacja certyfikacji Data Privacy Framework dla konkretnego podmiotu prawnego dostawcy, a przy braku certyfikacji: standardowe klauzule umowne plus ocena skutków transferu
• Wyłączone trenowanie modelu na danych firmowych w ustawieniach konta API (sprawdzone, nie założone)
• Włączona opcja zero data retention tam, gdzie dane są szczególnie wrażliwe i dostawca to umożliwia
• Lista podprocesorów dostawcy modelu i, jeśli używasz platformy pośredniej (no-code, iPaaS), także jej podprocesorów
• Rejestr czynności przetwarzania zaktualizowany o nowe narzędzie (art. 30 RODO), bo agent AI to nowy proces przetwarzania, nie techniczny detal
• Jeśli agent podejmuje decyzje wpływające na klienta bez udziału człowieka (np. automatyczna odmowa reklamacji), sprawdzenie, czy nie wchodzimy w zakres art. 22 RODO dotyczącego zautomatyzowanego podejmowania decyzji

Ostatni punkt bywa niedoceniany. Jeśli agent tylko przygotowuje odpowiedź, którą zatwierdza konsultant, ryzyko jest znacznie mniejsze niż wtedy, gdy agent samodzielnie i ostatecznie decyduje, np. o przyznaniu rabatu albo odrzuceniu reklamacji. W większości wdrożeń, które robimy przy automatyzacji obsługi klienta, zostawiamy człowieka w pętli decyzyjnej właśnie z tego powodu: nie chodzi tylko o jakość odpowiedzi, ale o to, żeby nie wpaść w reżim art. 22 bez świadomości, że się w nim jest.

Gdzie automatyzacja nie zdejmuje z ciebie odpowiedzialności

Trzeba to powiedzieć wprost: żadne narzędzie, żaden dostawca modelu i żadna platforma automatyzacji nie przejmuje na siebie roli administratora danych. Nawet jeśli dostawca ma świetną politykę prywatności, certyfikat DPF i podpisaną umowę powierzenia, to firma, która zleca agentowi przetwarzanie danych klientów, wciąż odpowiada za to, komu te dane trafiają, w jakim celu i na jakiej podstawie prawnej. Automatyzacja może załatwić 80% pracy dokumentacyjnej i technicznej, ale ostateczna decyzja o tym, czy dany proces w ogóle powinien być zautomatyzowany z użyciem danych osobowych, zostaje po stronie firmy.

To samo dotyczy sytuacji, w której firma korzysta z biura rachunkowego albo zewnętrznego dostawcy do obsługi faktur. Jeśli w tym procesie pojawia się agent AI czytający dokumenty księgowe zawierające dane osobowe kontrahentów, umowa powierzenia musi obejmować cały łańcuch, nie tylko relację firma-biuro rachunkowe, ale też biuro-dostawca AI. Przy wdrożeniach związanych z automatyzacją biura rachunkowego to jeden z pierwszych punktów, które sprawdzamy, zanim w ogóle zaczniemy mówić o samej automatyzacji obiegu dokumentów.

Co realnie robimy przy wdrożeniu, żeby to nie wisiało w powietrzu

W praktyce sprowadza się to do sekwencji, którą warto trzymać w tej kolejności, a nie odwrotnie. Najpierw ustalamy, jakie kategorie danych osobowych w ogóle będą przechodzić przez agenta (imię, nazwisko, e-mail to jedno, ale numer PESEL, dane o zdrowiu czy dane finansowe klienta to zupełnie inna kategoria ryzyka). Potem wybieramy dostawcę modelu i produkt (konto biznesowe, nie konsumenckie) pod kątem dostępności DPA i certyfikacji DPF. Dopiero na końcu projektujemy sam scenariusz automatyzacji, prompt, integracje. Odwrócenie tej kolejności, czyli najpierw zbudowanie działającego agenta, a potem „ogarnięcie RODO”, to najczęstszy błąd, jaki widzimy przy audytach cudzych wdrożeń. Skutkuje tym, że firma ma gotowe, działające narzędzie, którego formalnie nie powinna była uruchamiać w takiej formie, i teraz stoi przed wyborem: przebudować proces czy ryzykować.