RODO a AI: 4 pytania przed automatyzacją w n8n (podstawa prawna, umowa powierzenia i transfer danych do USA)

Dlaczego typowy poradnik RODO dla AI nic nie wnosi

Wpiszcie w wyszukiwarkę „RODO a ChatGPT” i dostaniecie dziesięć artykułów, które powtarzają to samo: trzeba mieć podstawę prawną, trzeba mieć umowę powierzenia, trzeba uważać na transfer danych poza EOG. Wszystko prawda, ale kompletnie nieużyteczne, kiedy siedzisz przed scenariuszem w n8n i musisz zdecydować, czy wolno Ci wrzucić treść maila od klienta do node'a OpenAI, żeby AI wyciągnęła z niego dane kontaktowe i temat zapytania.

W praktyce problem nie leży w teorii RODO, tylko w tym, że automatyzacje z AI mają specyficzną cechę: dane osobowe lecą przez kilka podmiotów naraz. Sam n8n albo Make jest podprocesorem, model językowy (OpenAI, Anthropic, Google) jest kolejnym podprocesorem, a czasem dochodzi jeszcze baza wektorowa albo CRM po drugiej stronie. Jeśli w tym łańcuchu nie sprawdzisz każdego ogniwa, to formalnie masz podpisaną umowę powierzenia z jednym dostawcą, a realnie dane i tak trafiają do USA przez kogoś, kogo nawet nie wymieniłeś w rejestrze.

Podstawa prawna: zanim w ogóle pomyślisz o AI

Zanim ktokolwiek zapyta o klauzule w umowie z OpenAI, trzeba odpowiedzieć na prostsze pytanie: na jakiej podstawie w ogóle przetwarzasz te dane. Automatyzacja niczego tu nie zmienia, tylko przyspiesza skalę błędu. Jeśli firma zbierała leady na podstawie zgody ograniczonej do „kontaktu handlowego”, a teraz chce te same dane wrzucać do modelu AI w celu profilowania czy scoringu leadów, to najczęściej ta zgoda nie pokrywa nowego celu przetwarzania. Trzeba albo rozszerzyć zgodę, albo oprzeć się na uzasadnionym interesie administratora (art. 6 ust. 1 lit. f RODO) i przejść przez test równowagi interesów, dokumentując go na piśmie.

W wielu wdrożeniach, które robiliśmy przy automatyzacji obsługi klienta, klienci zakładali, że skoro dane już legalnie mają w CRM, to mogą je swobodnie przepuszczać przez dowolny model AI. To błędne założenie. Zasada celowości działa niezależnie od tego, czy dane przetwarza człowiek, czy automat z promptem. Jeśli automatyzacja robi coś nowego z danymi (np. tworzy profil klienta, ocenia ryzyko, generuje rekomendacje), to jest to nowy cel przetwarzania i wymaga własnej podstawy prawnej, nawet jeśli dane wejściowe są te same.

Umowa powierzenia z dostawcą AI: co realnie sprawdzamy

Art. 28 RODO nakłada obowiązek zawarcia umowy powierzenia z każdym podmiotem przetwarzającym dane w Twoim imieniu. OpenAI, Anthropic i Google mają gotowe wzory takich umów (Data Processing Addendum, w skrócie DPA), które można podpisać samodzielnie z poziomu panelu administracyjnego konta biznesowego. Problem w tym, że większość osób klika „akceptuję” i na tym kończy weryfikację. My przed każdym wdrożeniem sprawdzamy konkretnie sześć rzeczy.

• Czy dane wysyłane przez API są wykorzystywane do trenowania modelu. W przypadku API OpenAI domyślnie nie są, ale trzeba to potwierdzić dla konkretnego planu i konkretnej usługi, bo inne zasady dotyczą ChatGPT Enterprise, a inne standardowego API.
• Jaka jest lista subprocesorów dostawcy i czy jest publicznie dostępna oraz aktualizowana. Jeśli dostawca dokłada nowego podprocesora bez powiadomienia, to Ty jako administrator tracisz kontrolę nad łańcuchem przetwarzania.
• Jaki jest okres retencji danych po stronie dostawcy AI i czy można wymusić szybsze usunięcie (opcja zero data retention w API OpenAI dla wybranych klientów biznesowych).
• Czy umowa przewiduje prawo do audytu i w jakiej formie (zwykle jest to raport SOC 2 albo ISO 27001 zamiast realnego audytu na miejscu, co i tak jest standardem w branży).
• Jaki jest czas i sposób powiadomienia o naruszeniu ochrony danych po stronie dostawcy. To istotne, bo od tego zależy, czy zdążysz dopełnić własny obowiązek zgłoszenia do UODO w 72 godziny.
• Czy DPA obejmuje mechanizm transferu danych do USA, czyli certyfikację DPF albo Standardowe Klauzule Umowne jako załącznik.

Sam podpis DPA nie zwalnia z niczego, jeśli nikt w firmie tego dokumentu nie przeczytał. W kilku projektach spotkaliśmy się z sytuacją, w której klient miał podpisaną umowę powierzenia z dostawcą AI sprzed dwóch lat, a w międzyśczasie dostawca zmienił listę subprocesorów i dopisał firmę hostingową spoza UE, o czym nikt się nie zorientował, bo nikt nie subskrybował powiadomień o zmianach.

Transfer danych do USA: kiedy DPF wystarczy, a kiedy trzeba SCC

To jest punkt, w którym najwięcej osób się gubi, bo przepisy zmieniały się kilkukrotnie w ostatnich latach. Aktualnie podstawowym mechanizmem legalizującym transfer danych osobowych do USA jest Data Privacy Framework (DPF), decyzja o adekwatności Komisji Europejskiej dla firm amerykańskich, które się do niego certyfikowały. OpenAI, Anthropic i Google mają certyfikację DPF dla części swoich usług, ale nie zakładaj tego automatycznie. Trzeba sprawdzić status konkretnego podmiotu na oficjalnej liście DPF prowadzonej przez amerykański Departament Handlu, bo certyfikacja dotyczy konkretnej spółki i konkretnego zakresu usług, a nie całej marki.

W praktyce przy wdrożeniach z n8n często pojawia się dodatkowa pułapka: sam n8n w wersji cloud jest hostowany w Europie, ale node podłączony do OpenAI i tak wysyła zapytania do amerykańskich serwerów. To znaczy, że masz dwa niezależne transfery do sprawdzenia, nie jeden. Dlatego część naszych klientów świadomie wybiera n8n self-hosted na własnej infrastrukturze w UE właśnie po to, żeby ograniczyć liczbę podmiotów w łańcuchu do samego dostawcy modelu, zamiast dokładać jeszcze warstwę platformy automatyzacji jako osobnego podprocesora.

Rejestr czynności przetwarzania: nowa automatyzacja to nowy wpis

To punkt, który najczęściej ginie w projektach automatyzacyjnych, bo dział IT albo agencja wdrożeniowa traktuje go jako „coś dla prawnika”, a prawnik nie wie, że w ogóle powstała nowa automatyzacja. Każdy nowy scenariusz w n8n czy Make, który przetwarza dane osobowe w nowy sposób, powinien trafić do rejestru czynności przetwarzania z opisem: jakie kategorie danych, w jakim celu, jaka podstawa prawna, jacy odbiorcy (w tym dostawca AI), jak długo dane są przechowywane i jakie środki bezpieczeństwa zastosowano.

W praktyce dobrym nawykiem, który wprowadzamy u klientów, jest dodanie tego punktu do checklisty wdrożeniowej samej automatyzacji, a nie do osobnego procesu compliance, który dzieje się „kiedyś później”. Jeśli automatyzacja obsługi leadów przekazuje treść formularza kontaktowego do modelu AI w celu klasyfikacji intencji, ten fakt musi być w rejestrze zanim scenariusz trafi na produkcję, nie po miesiącu działania.

Jak to wygląda przy realnych wdrożeniach

Przy automatyzacji faktur dane osobowe pojawiają się częściej, niż ludzie myślą: imię i nazwisko osoby kontaktowej, numer telefonu na dokumencie, czasem dane pracownika w treści noty. Jeśli scenariusz w n8n wysyła skan faktury do modelu AI w celu ekstrakcji danych (OCR plus parsing), to ten model przetwarza dane osobowe, nawet jeśli głównym celem jest wyciągnięcie kwoty netto i numeru NIP. W tym przypadku sprawdzamy dwie rzeczy dodatkowo: czy da się zminimalizować dane wysyłane do modelu (np. maskując fragmenty dokumentu niepotrzebne do ekstrakcji) oraz czy dostawca AI oferuje tryb, w którym dane wejściowe nie są logowane na dłużej niż to konieczne do wygenerowania odpowiedzi.

Przy automatyzacji leadów sytuacja jest inna, bo tam dane osobowe są sednem procesu, nie efektem ubocznym. Model AI, który klasyfikuje zapytanie klienta i sugeruje odpowiedź, przetwarza imię, e-mail, czasem treść wiadomości zawierającą wrażliwe informacje (np. dane zdrowotne przy zapytaniu do kliniki). Tu podstawą prawną zwykle jest uzasadniony interes administratora połączony z jasną informacją w polityce prywatności, że część obsługi jest wspierana przez AI. Bez tej informacji nawet poprawna podstawa prawna nie spełnia zasady przejrzystości z art. 13 RODO.

Nie każdą automatyzację da się w pełni zautomatyzować pod kątem zgodności. Ocena skutków dla ochrony danych (DPIA) przy automatyzacjach na dużą skalę, które profilują klientów albo wpływają na decyzje wobec nich, wciąż wymaga ręcznej analizy prawnej. Automat robi 80% pracy przy mapowaniu przepływu danych i identyfikacji podprocesorów, ale decyzję, czy dana automatyzacja wymaga pełnej DPIA, zostawiamy zawsze osobie odpowiedzialnej za compliance po stronie klienta, nie botowi.

Co konkretnie sprawdzić przed uruchomieniem scenariusza z AI

Zbierając powyższe w jedną listę kontrolną, przed każdym wdrożeniem automatyzacji z AI w n8n lub Make sprawdzamy: podstawę prawną przetwarzania dla nowego celu, aktualność i zakres DPA z dostawcą modelu, status DPF dla konkretnej usługi dostawcy, konieczność SCC jeśli DPF nie obejmuje danego podprocesora, listę wszystkich podmiotów w łańcuchu (platforma automatyzacji, model AI, ewentualna baza wektorowa), wpis w rejestrze czynności przetwarzania oraz aktualizację informacji dla osób, których dane dotyczą, jeśli AI bierze udział w decyzjach ich dotyczących. To nie jest lista do odhaczenia raz na zawsze, bo dostawcy zmieniają warunki, a certyfikacje wygasają, więc powinna wracać przy każdej większej zmianie scenariusza albo minimum raz w roku.