Weryfikacja dostawcy chatbota: DPA, podprzetwarzający i transfery do państw trzecich

Dostawca chatbota może zaprezentować przekonujące demo, region serwerów w UE i gotową umowę powierzenia przetwarzania danych (DPA) – a mimo to kluczowe pytania pozostają bez odpowiedzi. Widoczny chatbot to nie jedyny element przetwarzający dane. W świadczeniu usługi często biorą udział API modeli, hosting, wektorowe bazy danych, systemy analizy błędów, narzędzia wsparcia technicznego, usługi e-mail oraz kopie zapasowe. Dla właścicieli witryn internetowych liczy się zweryfikowany łańcuch przetwarzania, a nie hasła marketingowe o RODO umieszczone na stronie sprzedażowej.

Ta lista kontrolna pomaga w ustrukturyzowanej ocenie dostawcy przed zakupem i wdrożeniem. Służy ona jako praktyczna wskazówka, a nie porada prawna. Role, podstawy prawne, obowiązki informacyjne i mechanizmy transferu muszą zostać przeanalizowane dla konkretnego przypadku użycia; w przypadku podwyższonego ryzyka, szczególnych kategorii danych lub otwartych kwestii umownych należy skonsultować się z Inspektorem Ochrony Danych lub wykwalifikowanym doradcą prawnym.

Najpierw zrozum przepływ danych, potem oceń umowę

Kluczowe pytanie brzmi nie tylko „Gdzie znajduje się serwer?”, ale przede wszystkim: jakie dane osobowe, kiedy, do jakiego podmiotu prawnego trafiają, w jakim celu i jak długo są przechowywane? Użytkownik w oknie czatu może podać imiona, adresy e-mail, numery klientów lub tekst swobodny. Dodatkowo generowane są adresy IP, znaczniki czasu, informacje o urządzeniu, identyfikatory sesji, historia rozmów, oceny oraz logi techniczne. Nawet rzekomo anonimowa rozmowa może stać się danymi osobowymi po połączeniu kilku atrybutów.

Przed analizą umowy sporządź prostą mapę przepływu danych. Powinna ona obejmować co najmniej: widget w przeglądarce, platformę chatbota, bazę wiedzy, dostawcę modelu, usługi analityczne i błędów, dostęp wsparcia technicznego, kopie zapasowe oraz ścieżki usuwania danych. Dla każdego etapu należy zarejestrować operatora, kraj, cel, kategorie danych, okres przechowywania i możliwy dostęp zdalny. Deklaracja o „hostingu w UE” nie odpowiada na przykład na pytanie, czy zespół wsparcia zlokalizowany poza Europejskim Obszarem Gospodarczym ma dostęp do logów produkcyjnych.

Określenie ról w ochronie danych dla każdego celu

To, czy dostawca jest podmiotem przetwarzającym (procesorem), czy odrębnym administratorem dla poszczególnych celów, wynika z faktycznie wykonywanych czynności. Wytyczne 07/2020 Europejskiej Rady Ochrony Danych szczegółowo wyjaśniają to rozróżnienie. Dostawca może na przykład przetwarzać dane rozmów na udokumentowane polecenie, ale dla własnych celów bezpieczeństwa, rozliczeń czy rozwoju produktu rościć sobie rolę administratora. Upewnij się, że każdy cel, rola i podstawa prawna są jednoznacznie przypisane. Umowa DPA nie obejmuje automatycznie własnych, niezależnych celów dostawcy.

Sprawdzenie DPA: obowiązkowa treść musi odpowiadać realiom usługi

Artykuł 28 RODO wymaga, aby administratorzy korzystali wyłącznie z usług podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych. Umowa musi określać m.in. przedmiot i czas trwania, charakter i cel, rodzaj danych, kategorie osób, których dane dotyczą, oraz obowiązki i prawa administratora. Do tego dochodzą udokumentowane polecenia, poufność, bezpieczeństwo, wsparcie w realizacji praw osób, których dane dotyczą, i obowiązków w zakresie ochrony danych, usuwanie lub zwrot danych oraz udostępnianie informacji i współpraca przy audytach.

Przeanalizuj umowę DPA nie tylko pod kątem listy wzorcowej, ale w odniesieniu do mapy przepływu danych i faktycznie wybranego planu. Dobra umowa w jasny sposób opisuje obsługę czatu, trenowanie lub indeksowanie bazy wiedzy, logowanie, dostęp wsparcia oraz funkcje opcjonalne. Ogólne i nieprecyzyjne sformułowania, takie jak „doskonalenie usług”, powinny zostać rozbite na konkretne dane, cele, opcje wyboru i role.

• Polecenia: Czy jest jasne, że treści i metadane są przetwarzane wyłącznie w udokumentowanych celach klienta? Jakie konfiguracje są traktowane jako polecenie?
• Wykorzystanie do modeli: Czy prompty, odpowiedzi lub przesłane pliki są wykorzystywane do ogólnego trenowania modeli lub ulepszania produktów? Jeśli nie, powinno to być jednoznacznie potwierdzone umownie i technicznie; jeśli tak, rola i podstawa prawna wymagają osobnej oceny.
• Usuwanie danych: Czy istnieją konkretne terminy usuwania historii czatów, logów, indeksów wektorowych, kopii zapasowych i kopii roboczych wsparcia technicznego? Co dzieje się po zakończeniu umowy?
• Bezpieczeństwo: Czy opisano kontrolę dostępu, separację danych klientów (multi-tenancy), szyfrowanie, logowanie, zarządzanie podatnościami oraz procedury obsługi incydentów?
• Wsparcie: Czy DPA w sposób praktyczny reguluje kwestie eksportu, sprostowania, usuwania, dostępu do danych, incydentów bezpieczeństwa i ewentualnych ocen skutków dla ochrony danych (DPIA)?
• Dowody: Czy dostępne są raporty z audytów, certyfikaty lub inne wiarygodne dowody i czy odnoszą się one dokładnie do używanych usług i lokalizacji?

Certyfikaty i raporty z audytów stanowią cenne wskazówki, ale nie zastępują weryfikacji konkretnego procesu przetwarzania ani odpowiednich klauzul umownych. Standardowe DPA jest tylko tak dobre, jak jego wypełnione załączniki i ich zgodność z rzeczywistością techniczną.

Podprzetwarzający: kontrola nazw, zadań i zmian

Zgodnie z art. 28 ust. 2 RODO podmiot przetwarzający nie korzysta z usług innego podmiotu przetwarzającego bez uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora. W przypadku ogólnej zgody musi informować o wszelkich zamierzonych zmianach i dać możliwość wyrażenia sprzeciwu. Ponadto Pytania i Odpowiedzi Komisji Europejskiej dotyczące Standardowych Klauzul Umownych precyzują, że podawanie samych kategorii nie wystarczy: poszczególni podprzetwarzający muszą być wymienieni z nazwy.

Zażądaj aktualnej, możliwej do wyeksportowania listy zawierającej pełną nazwę prawną, kraj, konkretną usługę oraz zakres przetwarzanych danych. Sprawdź również, czy dana firma jest tylko partnerem umownym, czy faktycznie przetwarza dane w wielu lokalizacjach. Szczególnie istotni są dostawcy modeli i osadzeń (embeddings), hosting chmurowy, bazy danych, CDN, monitoring, analiza błędów, wsparcie techniczne, e-mail oraz backup. Dla każdego wpisu powinno być jasne, czy dane są przechowywane, jedynie przesyłane, czy też pracownicy mają do nich wgląd.

Procedura wprowadzania zmian również wymaga oceny: jak klienci są powiadamiani, jaki jest czas wyprzedzenia i co dzieje się w przypadku uzasadnionego sprzeciwu? Wiadomość e-mail wysłana w dniu wdrożenia zmiany, bez możliwości podjęcia działań technicznych lub umownych, ma znikomą wartość. Upewnij się, czy możliwa jest alternatywna konfiguracja, wyłączenie danej funkcji lub – w razie potrzeby – sprawne rozwiązanie umowy wraz z eksportem danych. W stosunku do kolejnych podprzetwarzających muszą zostać przekazane te same obowiązki w zakresie ochrony danych; pierwotny procesor pozostaje odpowiedzialny wobec administratora za wywiązywanie się przez nich z tych zobowiązań.

Transfery do państw trzecich: weryfikacja mechanizmu i realnego wpływu

Rozdział V RODO ma zastosowanie do przekazywania danych osobowych do państw trzecich oraz do ich dalszego przekazywania. Transfer następuje nie tylko poprzez trwałe przechowywanie; dostęp administracyjny, wsparcie techniczne lub odczyt danych przez usługę spoza EOG również stanowią transfer. Z tego względu do każdej strzałki na mapie przepływu danych należy przypisać kraj docelowy, odbiorcę oraz mechanizm transferu.

1. Decyzja stwierdzająca odpowiedni stopień ochrony: Sprawdź na bieżąco aktualizowanej liście Komisji Europejskiej, czy decyzja obejmuje dany kraj, terytorium, sektor i konkretnego odbiorcę. W przypadku ograniczonych ram prawnych samo posiadanie siedziby w danym kraju nie wystarczy.
2. Odpowiednie zabezpieczenia: W przypadku braku decyzji o odpowiednim stopniu ochrony, w zależności od konfiguracji, stosuje się instrumenty z art. 46 RODO. Najczęściej wykorzystywane są Standardowe Klauzule Umowne Komisji Europejskiej (SCC). Moduł, strony, załączniki, opis transferu i środki techniczne muszą odpowiadać rzeczywistemu łańcuchowi przetwarzania.
3. Ocena skuteczności: Podpisany dokument SCC nie kończy automatycznie procesu weryfikacji. Ostateczne Rekomendacje EROD 01/2020 opisują proces oparty na analizie ryzyka: zidentyfikowanie transferów, wybór instrumentu, ocena prawa i praktyki państwa trzeciego, wdrożenie ewentualnych środków dodatkowych, dopełnienie formalności oraz regularny przegląd.

Dodatkowe środki techniczne muszą być dostosowane do konkretnego ryzyka. Szyfrowanie można właściwie ocenić tylko wtedy, gdy uwzględnia się zarządzanie kluczami, prawa dostępu i cel przetwarzania. Dostawca modelu, który musi przetwarzać tekst w formie jawnej i sam posiada dostęp do kluczy, znajduje się w zupełnie innej sytuacji niż podmiot dostarczający jedynie zaszyfrowany magazyn kopii zapasowych. Ogólne deklaracje typu „AES-256” lub „zgodność z RODO” nie zastępują takiej analizy. Wyjątki z art. 49 RODO również nie stanowią właściwej podstawy dla rutynowego, powtarzalnego przetwarzania w modelu SaaS.

Przykład praktyczny: region UE z globalnym łańcuchem usług

Załóżmy, że chatbot przechowuje swoją główną bazę danych w Frankfurcie. Jednak odpowiedzi generuje API modelu dostarczane przez firmę z USA, raporty o błędach trafiają do innej usługi zewnętrznej, a globalny zespół wsparcia może otwierać logi rozmów w przypadku zgłoszeń serwisowych. W takim scenariuszu hasło „przechowywanie danych w UE” opisuje tylko fragment całego systemu.

Procedura due diligence rozdziela ten proces na cztery pytania: jakie treści opuszczają EOG w celu wygenerowania odpowiedzi? Czy prompty są tam zapisywane lub wykorzystywane do innych celów? Czy raporty błędów zawierają jawny tekst i identyfikatory, czy tylko zminimalizowane dane techniczne? Na jakich warunkach zespół wsparcia spoza EOG może uzyskać dostęp? Dopiero po odpowiedzi na te pytania można ocenić instrument transferu, środki dodatkowe oraz ryzyko rezydualne.

Właściciel strony internetowej często może ograniczyć ryzyko od strony technicznej: wyłączyć zbędne pola w logach, maskować dane wejściowe przed wysłaniem zapytania do zewnętrznego API, ustawić krótkie okresy przechowywania, odseparować strefy wrażliwe od publicznego bota, odizolować bazy wiedzy dla poszczególnych tenantów oraz wymagać autoryzacji i logowania każdego dostępu wsparcia. Sposób na bezpieczne rozdzielenie publicznego bota od portalu klienta opisano w artykule Publiczny chatbot AI a portal klienta. W kwestii przesyłania plików przydatna będzie lista kontrolna Przesyłanie dokumentów, ochrona danych i przejmowanie rozmów.

Decyzja w oparciu o system świateł zamiast intuicji

Punkt kontrolny	Zielony	Żółty	Czerwony
Przepływ danych	Pełny, aktualny i dostosowany do planu	Brak jasności co do wybranych dostępów lub lokalizacji	Tylko deklaracje marketingowe o regionie UE
DPA	Cele, dane, terminy i wsparcie precyzyjnie określone	Wymagane uzupełnienia przed uruchomieniem	Brak wiążących poleceń lub zasad usuwania danych
Podprzetwarzający	Imienna lista z podaniem kraju i roli	Niepraktyczna procedura zmian	Tylko ogólne kategorie lub nieznany łańcuch
Transfer do państwa trzeciego	Mechanizm, zakres i ocena w pełni udokumentowane	Środki wymagają dodatkowej weryfikacji	„Serwer w UE” ma tłumaczyć wszystkie transfery
Utrzymanie i eksploatacja	Właściciel, harmonogram przeglądów i procedura wyjścia przetestowane	Brak stałego harmonogramu przeglądu dowodów	Brak monitoringu po podpisaniu umowy

Żółte światło nie musi automatycznie przekreślać dostawcy. Wymaga jednak wyznaczenia osoby odpowiedzialnej, określenia terminu i weryfikowalnych kryteriów odbioru. Czerwone światło w kluczowym elemencie łańcucha przetwarzania powinno blokować wdrożenie produkcyjne do momentu dostosowania umowy, konfiguracji lub zmiany dostawcy. Należy również udokumentować zaakceptowane ryzyko rezydualne wraz ze wskazaniem osoby, która podjęła taką decyzję.

Krótka lista kontrolna przed uruchomieniem dla właścicieli stron

• Mapa przepływów danych oraz role dla każdego celu zostały zatwierdzone.
• DPA i załączniki odpowiadają wybranemu planowi, funkcjom, kategoriom danych i okresom przechowywania.
• Wszyscy podprzetwarzający zostali zidentyfikowani z nazwy, z uwzględnieniem kraju, roli oraz procedury zgłaszania zmian.
• Każdy transfer do państwa trzeciego posiada odpowiedni, aktualnie zweryfikowany mechanizm oraz, w razie potrzeby, środki dodatkowe.
• Kwestia trenowania modeli lub innego wykorzystania danych z czatu na własne potrzeby dostawcy została wyjaśniona i skonfigurowana zgodnie z ustaleniami.
• Logowanie, dostęp wsparcia, eksport danych, usuwanie oraz procedura zakończenia umowy zostały przetestowane w praktyce.
• Polityka prywatności i interfejs czatu w przejrzysty sposób wyjaśniają zasady przetwarzania; użytkownicy nie są zachęcani do wprowadzania niepotrzebnych danych wrażliwych.
• Przeanalizowano, czy dla danego zastosowania wymagane jest przeprowadzenie oceny skutków dla ochrony danych (DPIA).
• Wyznaczono osobę odpowiedzialną za nadzorowanie zmian u podprzetwarzających, mechanizmów transferu, funkcji oraz certyfikatów bezpieczeństwa.

Warto również zapoznać się z ogólnym przeglądem Chatbot AI a RODO oraz instrukcją dotyczącą analityki chatbota zoptymalizowanej pod kątem minimalizacji danych. Dzięki temu proces zakupu, konfiguracja techniczna i codzienna eksploatacja nie będą traktowane jako odrębne, niepowiązane ze sobą projekty.

Konieczność ciągłej weryfikacji po podpisaniu umowy

Due diligence to nie jednorazowy plik PDF odłożony na półkę. Ustal stały harmonogram przeglądów oraz procedury reakcji na określone zdarzenia. Czynnikami wyzwalającymi weryfikację są: pojawienie się nowych podprzetwarzających, zmiana dostawcy modelu, nowe funkcje produktu, zmiana lokalizacji przechowywania danych, incydent bezpieczeństwa, wygaśnięcie certyfikatów lub zmiany w decyzjach o odpowiednim stopniu ochrony. Aktualna lista podprzetwarzających oraz kluczowe wersje umów powinny być archiwizowane wraz z datą, aby zapewnić pełną rozliczalność zmian.

Praktyczny sprawdzian jest prosty: czy Twój zespół potrafi wyjaśnić dla każdego istotnego przepływu danych, kto, co i dlaczego przetwarza, gdzie się to odbywa, jak długo dane są przechowywane, jakie środki ochrony zastosowano i jak wygląda procedura wyjścia? Jeśli odpowiedzi na te pytania są poparte dowodami, ogólne zapewnienia o ochronie danych zamieniają się w przemyślaną decyzję zakupową. Dopóki kluczowe etapy przetwarzania pozostają nieznane, chatbot nie powinien pracować na realnych danych użytkowników.