Dane firmowe a AI: umowa powierzenia i podstawa prawna

Firma instaluje asystenta AI do obsługi klientów. Model odpowiada na pytania, cytuje procedury z wewnętrznej bazy wiedzy, czasem widzi imię i numer zamówienia klienta. Pytanie prawne pada po tygodniu użytkowania, a nie przed wdrożeniem: czy podpisaliśmy umowę z dostawcą modelu? Odpowiedź „nie wiemy" to najczęstsza luka, którą znajdujemy podczas audytów. Tej luki nie ma w systemach projektowanych od pierwszej linijki z myślą o zgodności.

RODO rozróżnia administratora (decyduje o celach i sposobach przetwarzania) od podmiotu przetwarzającego (przetwarza dane wyłącznie na polecenie administratora). Wasza firma jest administratorem danych swoich klientów i pracowników. Dostawca AI, który dostaje te dane, żeby wykonać usługę, jest podmiotem przetwarzającym.

Art. 28 RODO mówi wprost: każde takie powierzenie musi być udokumentowane umową lub innym instrumentem prawnym, który określa przedmiot, czas trwania, charakter i cel przetwarzania, rodzaj danych, kategorie osób, obowiązki i prawa administratora.

Obowiązek pojawia się, gdy do danych osobowych ma dostęp podmiot zewnętrzny działający na Wasze zlecenie. W kontekście AI to konkretnie:

• Dostawca modelu językowego (API chmurowe), który widzi treść promptów zawierających dane użytkowników.
• Platforma automatyzacji (n8n w chmurze, Make, Zapier), przez którą przepływają dane z CRM lub poczty.
• Dostawca infrastruktury (AWS, Azure, GCP), na której działa Wasz system AI i gdzie przechowywane są logi konwersacji.
• Firma wdrożeniowa (taka jak nasza), która ma dostęp do danych podczas konfiguracji, testów i utrzymania systemu.

Umowa nie jest potrzebna, gdy zewnętrzny podmiot przetwarza dane jako odrębny administrator (np. bank realizujący płatność) albo gdy dane nigdy nie opuszczają Waszej infrastruktury (architektura self-hosted, modele lokalne).

Standardowe DPA ma sekcje wymagane przez art. 28 RODO. Przy wdrożeniach AI dochodzą klauzule, których brakuje w szablonach pisanych przed erą modeli językowych.

Klauzula „zakaz trenowania na danych klienta" to punkt, który odróżnia poważnych dostawców AI od tych, którzy wchłaniają Wasze dane do globalnego modelu. Przy API chmurowych wiele dostawców taką klauzulę oferuje w umowach enterprise — ale domyślnie często jest odwrotnie. Zawsze sprawdzaj warunki API przed pierwszym requestem produkcyjnym.

Dostawca modelu AI nie zawsze jest procesorem. Granica zależy od tego, czy i jak może używać Waszych danych we własnych celach.

Czysty procesor (umowa powierzenia wystarczy): dostawca uruchamia model wyłącznie na Wasze zlecenie, nie używa danych do własnych celów, nie trenuje na nich, nie retencjonuje poza uzgodnionym TTL.

Współadministrator (potrzebna umowa o współadministrowaniu, art. 26 RODO): dostawca ma własny interes w danych, np. prowadzi własną analitykę na zapytaniach, buduje na nich produkty, profiluje Waszych użytkowników. Sytuacja rzadsza przy modelach AI, ale możliwa przy platformach SaaS z wbudowaną AI.

Odrębny administrator: dostawca przetwarza dane do własnych, niezależnych celów, Waszej umowy nie obejmuje. W tej sytuacji RODO wymaga, żebyście poinformowali osoby, że ich dane trafiają do tego podmiotu, który sam określa cele.

W praktyce zdecydowana większość API modeli językowych w trybie enterprise to procesorzy — i właśnie dlatego DPA jest standardowym wymogiem przetargów IT od 2023 roku.

Modele językowe działają często na serwerach poza Europą. Transfer danych osobowych poza Europejski Obszar Gospodarczy jest dozwolony, ale wymaga podstawy prawnego transferu: standardowych klauzul umownych (SCCs), decyzji o adekwatności lub wiążących reguł korporacyjnych (BCRs).

W praktyce przy wdrożeniu AI musisz:

1. Zidentyfikować, gdzie fizycznie przetwarzane są dane (region serwerów dostawcy API).
2. Sprawdzić, czy dostawca oferuje SCCs lub działa w regionie z decyzją o adekwatności (np. EOG, Wielka Brytania, Japonia).
3. Udokumentować podstawę transferu w rejestrze czynności przetwarzania (RCP).
4. Rozważyć, czy dane-residency w EU (wymuszone contractualnie lub przez self-hosting) eliminuje problem transferu.

Architektura self-hosted z lokalnym modelem i lokalną bazą wektorową (Qdrant, BGE-M3) eliminuje pytanie o transfer, bo dane osobowe nigdy nie opuszczają Waszej infrastruktury. To szczególnie istotne dla firm z danych wrażliwych: kancelarie, podmioty medyczne, fintech.

Zgodność prawna i zgodność techniczna to dwie strony tej samej monety. Umowa powierzenia daje ramy prawne, ale system musi je respektować technicznie. Konkretnie:

Maskowanie PII przed modelem. Zanim tekst z danymi osobowymi trafi do LLM, nasz router maskuje zmienne wrażliwe (imiona, numery, e-maile). Model widzi [IMIĘ] zamiast „Jan Kowalski". Jeśli odpowiedź nie wymaga tych danych, model ich nie dostaje.

Zero-retention po stronie modelu. Przy API chmurowych wybieramy endpointy z potwierdzoną polityką zero retencji promptów. Przy architekturze lokalnej dane nie wychodzą poza serwer. Guardrails blokują odpowiedzi zawierające dane, o które model nie powinien być pytany.

TTL na logach. Logi konwersacji (potrzebne do debugowania i audytu jakości) mają zdefiniowany czas życia i procedurę purge. Osoby mogą żądać usunięcia swoich danych — system obsługuje to żądanie end-to-end, włącznie z wektorami w bazie i logami.

Human-gate na akcjach nieodwracalnych. Agenci AI, którzy mogą wysyłać e-maile, tworzyć dokumenty lub modyfikować dane, przechodzą przez potwierdzenie człowieka. Żadna akcja dotykająca danych osobowych nie jest w pełni autonomiczna bez explicite zdefiniowanego zakresu. To wymóg techniczny wzmacniający nadzór ludzki z AI Act.

Więcej o samej architekturze bezpieczeństwa agentów AI w artykule bezpieczeństwo agentów AI.

AI Act i RODO to dwa różne reżimy, ale w obszarze danych nakładają się na siebie. AI Act dodaje do umów z dostawcami AI dodatkowe elementy:

• Dokumentacja techniczna systemu — dostawca systemu wysokiego ryzyka musi ją udostępnić. Dla niskiego ryzyka wystarczy transparentność.
• Rejestr — systemy wysokiego ryzyka wymagają rejestracji w bazie EU i dokumentacji zarządzania ryzykiem.
• DPIA — gdy system AI profiluje, ocenia lub podejmuje zautomatyzowane decyzje o ludziach, RODO wymaga oceny skutków, a AI Act wymaga analizy ryzyka. W praktyce: jeden dokument pokrywający oba wymogi.

W umowie z dostawcą AI warto wprost zapisać, który poziom ryzyka AI Act reprezentuje system, kto odpowiada za dokumentację techniczną i jak obsługiwane są incydenty bezpieczeństwa AI. Bez tego administratorowi (Wam) trudno wykazać zgodność przy ewentualnej kontroli.

Szczegółowe omówienie AI Act dla firm wdrażających AI w Polsce znajdziesz w artykule AI Act i RODO 2026.

Zanim podpiszesz umowę z dostawcą modelu, platformy lub infrastruktury:

• Czy dostawca oferuje DPA zgodne z art. 28 RODO? (Jeśli nie — rezygnuj lub prowadź dane anonimowo.)
• Czy umowa zawiera klauzulę zakazu trenowania na Waszych danych?
• Czy określono regiony przetwarzania i podstawę transferu poza EOG?
• Czy jest lista podprocesorów z obowiązkiem informowania o zmianach?
• Czy TTL logów i procedura purge są precyzyjnie określone?
• Czy określono jak dostawca obsługuje żądania osób (dostęp, usunięcie)?
• Czy w razie incydentu masz prawo do raportu w ciągu 72h (wymóg RODO)?

Jeśli Wasza umowa zawiera wszystkie te punkty, macie solidną podstawę. Jeśli nie — warto to uzupełnić przed startem produkcji, nie po pierwszym zapytaniu od UODO.

Gotowość organizacji pod kątem danych i zgodności możesz wstępnie sprawdzić w ocenie gotowości AI lub obliczyć koszt właściwej architektury w kalkulatorze ROI. Szczegóły architektury omówimy na bezpłatnym pilocie.

Opisz swój przypadek wdrożenia AI, a model wskaże, które elementy umowy powierzenia są krytyczne i na co zwrócić uwagę przy wyborze dostawcy. To punkt wyjścia do weryfikacji z prawnikiem, nie porada prawna. PII maskowane przed modelem, zero retencji.

Obowiązek pojawia się, gdy zewnętrzny podmiot styka się z danymi osobowymi i przetwarza je wyłącznie na Wasze polecenie. W praktyce AI: gdy API modelu językowego, platforma automatyzacji lub dostawca hostingu widzi treść zawierającą dane Waszych klientów lub pracowników. Brak DPA w tej sytuacji to naruszenie art. 28 RODO niezależnie od tego, czy incydent w ogóle wystąpił.

Większość dużych dostawców API ma DPA dostępne w programach enterprise. Problem polega na tym, że domyślne warunki konsumenckie lub darmowych planów często nie zawierają DPA lub zawierają klauzule pozwalające na trenowanie na danych. Przed użyciem jakiegokolwiek API produkcyjnego z danymi osobowymi należy pobrać i podpisać DPA z dostawcy, nie zakładać, że standardowe ToS wystarczy.

Tak, w zakresie modelu i infrastruktury, która jest w całości pod Waszą kontrolą. Jeśli model językowy, baza wektorowa i logi konwersacji działają na Waszych serwerach i żadne dane osobowe nie opuszczają Waszej sieci, nie ma podmiotu przetwarzającego, któremu musisz powierzać dane. Umowa powierzenia jest nadal potrzebna z firmą wdrożeniową, która ma dostęp do systemu podczas instalacji i utrzymania. Więcej o architekturze self-hosting.

To zależy od architektury. Modele generatywne nie „zapamiętują" konwersacji między sesjami, ale dostawcy API mogą retencjonować logi promptów do 30 dni (lub dłużej) na potrzeby debugowania i bezpieczeństwa. W umowie powierzenia należy określić TTL logów i mechanizm ich usunięcia. Przy lokalnym LLM i zero-retention po stronie modelu dane konwersacji nie wychodzą poza Waszą infrastrukturę. Wektory embeddingów w bazie wektorowej są osobnym zasobem wymagającym osobnej polityki retencji i purge.

Nie zawsze. DPIA jest wymagana, gdy przetwarzanie może powodować wysokie ryzyko dla praw osób: profilowanie na dużą skalę, przetwarzanie danych wrażliwych, zautomatyzowane decyzje o ludziach. Asystent, który tylko odpowiada na pytania z Waszej bazy wiedzy i nie profiluje użytkowników, zwykle DPIA nie wymaga. Asystent, który ocenia nastroje klientów, kategoryzuje ich lub kieruje do różnych ścieżek na podstawie profilu, prawdopodobnie tak. Granicę wyznacza prawnik, nie vendor AI.