DPA dla AI vendora: 8 klauzul, których brak wywróci audyt

Czas czytania: ok. 8 minut. Klaster: compliance. Autor: Fryderyk.

Odpowiedź najpierw

Umowa powierzenia przetwarzania (DPA) z dostawcą AI to nie formalność do podpisania na końcu. To dokument, na którym audytor NIS2 albo RODO opiera pytanie: kto, gdzie i na jakich zasadach przetwarza wasze dane w tym systemie AI. Standardowy wzór DPA od dostawcy zwykle nie odpowiada na pytania specyficzne dla AI: czy wasze prompty i dokumenty zasilają trening modelu, kto jest podprocesorem stojącym za API modelu, jak odzyskujecie i kasujecie dane na koniec. Poniżej osiem klauzul, których brak najczęściej wywraca audyt albo zostawia lukę w łańcuchu dostaw. Dla każdej: co musi zawierać i co się psuje, gdy jej nie ma. To nie jest porada prawna.

Spis treści

1. Dlaczego DPA dostawcy AI różni się od zwykłego
2. Osiem klauzul po kolei
3. Tabela: klauzula i ryzyko przy braku
4. Jak używać tej listy w praktyce
5. FAQ
6. Disclosure i biases
7. Czego tu nie pokrywam
8. Powiązane notatki

Dlaczego DPA dostawcy AI różni się od zwykłego

Dwie rzeczy odróżniają je od klasycznej umowy powierzenia. Po pierwsze, łańcuch podprocesorów jest głębszy i mniej oczywisty: za jednym API modelu stoi często dostawca chmury, czasem osobny dostawca modelu, czasem obaj naraz. Po drugie, pojawia się pytanie, którego klasyczny DPA nie zna: co dzieje się z waszymi danymi, promptami i odpowiedziami po stronie modelu. Czy służą tylko do obsłużenia zapytania, czy także do ulepszania albo trenowania. Wzór skopiowany od dostawcy zwykle milczy w obu miejscach, a audytor tego nie przeoczy.

Osiem klauzul po kolei

1. Przedmiot, cel i udokumentowane instrukcje

Co musi zawierać: określony przedmiot, czas, charakter i cel przetwarzania oraz zapis, że dostawca przetwarza dane wyłącznie na wasze udokumentowane polecenie. Co się psuje przy braku: blankietowe „na potrzeby świadczenia usługi" nie pozwala wykazać, że panujecie nad zakresem, a audytor czyta to jako utratę kontroli administratora nad procesorem.

2. Rejestr podprocesorów i notyfikacja zmian

Co musi zawierać: aktualną listę podprocesorów, w tym dostawcę infrastruktury i dostawcę modelu, obowiązek uprzedniego informowania o zmianach oraz prawo sprzeciwu. Co się psuje przy braku: nie wiecie, kto realnie dotyka danych, więc nie ocenicie ani łańcucha dostaw pod NIS2, ani transferów. To najczęstsza cicha luka przy publicznych API modeli.

3. Lokalizacja przetwarzania i transfery poza EOG

Co musi zawierać: wskazanie, gdzie dane są przetwarzane i przechowywane, oraz podstawę i zabezpieczenia dla transferów poza Europejski Obszar Gospodarczy. Co się psuje przy braku: transfer do kraju trzeciego bez podstawy to klasyczne ustalenie audytu RODO, a przy AI łatwo o niego, gdy model albo jego zaplecze stoi poza EOG.

4. Wykorzystanie danych do trenowania modeli

Co musi zawierać: jednoznaczne wyłączenie użycia waszych danych, promptów i odpowiedzi do trenowania lub ulepszania modeli, albo, jeśli świadomie na to zezwalacie, wyraźną i ograniczoną zgodę. Co się psuje przy braku: milczenie umowy działa na waszą niekorzyść, bo nie zapewnicie, że wrażliwa treść nie osiądzie w modelu. To klauzula, której zwykły DPA w ogóle nie ma, a dla systemu AI jest kluczowa.

5. Konkretne środki techniczne i organizacyjne

Co musi zawierać: wymienione wprost środki, czyli szyfrowanie w spoczynku i w tranzycie, kontrolę dostępu, rozdział środowisk i logowanie, nie samo odesłanie do „polityki bezpieczeństwa dostawcy". Co się psuje przy braku: odesłanie do wewnętrznego dokumentu, którego nie widzicie i nie kontrolujecie, nie jest dowodem, który obroni się przed audytorem.

6. Rejestrowanie zdarzeń, dostęp do logów i prawo do audytu

Co musi zawierać: zakres logowanych zdarzeń, wasz dostęp do logów lub raportów oraz realne prawo do audytu albo inspekcji, nie tylko okazanie certyfikatu. Co się psuje przy braku: bez dostępu do śladu zdarzeń nie odtworzycie, co system zrobił i na jakich danych, a to jest dokładnie to, czego oczekuje reżim NIS2.

7. Zgłaszanie naruszeń w określonym oknie czasowym

Co musi zawierać: obowiązek zgłoszenia naruszenia bez zbędnej zwłoki, w oknie czasowym mieszczącym się w waszym własnym zegarze wobec organu. Co się psuje przy braku: jeśli dostawca zgłasza „w rozsądnym czasie", możecie nie zdążyć z własnym obowiązkiem notyfikacyjnym, a opóźnienie po stronie procesora staje się waszym problemem.

8. Retencja, zwrot i trwałe usunięcie danych

Co musi zawierać: co dzieje się z danymi na koniec umowy, termin i sposób zwrotu lub usunięcia oraz potwierdzenie usunięcia, także z kopii zapasowych i logów. Co się psuje przy braku: dane zostają u dostawcy po zakończeniu współpracy, co jest jednocześnie ustaleniem RODO i realnym elementem vendor lock-in.

Tabela: klauzula i ryzyko przy braku

Klauzula	Co musi zawierać	Co się psuje przy braku
Cel i instrukcje	Przetwarzanie wyłącznie na udokumentowane polecenie	Utrata kontroli administratora nad procesorem
Podprocesorzy	Lista plus notyfikacja zmian i prawo sprzeciwu	Nieznany łańcuch dostaw, ślepa plamka NIS2
Lokalizacja i transfery	Miejsce przetwarzania i podstawa transferu poza EOG	Nieuprawniony transfer, ustalenie audytu RODO
Trening modeli	Wyłączenie użycia danych do treningu	Wrażliwa treść osiada w modelu
Środki bezpieczeństwa	Konkretne środki wymienione wprost	Odesłanie bez dowodu, brak weryfikowalności
Logi i audyt	Zakres logów, dostęp, prawo inspekcji	Brak odtwarzalności zdarzeń pod NIS2
Zgłaszanie naruszeń	Okno czasowe zgodne z waszym zegarem	Spóźniona notyfikacja do organu
Retencja i usunięcie	Zwrot, usunięcie i potwierdzenie	Dane zostają u dostawcy, lock-in

Jak używać tej listy w praktyce

Nie negocjuj ośmiu klauzul osobno na końcu procesu. Wpięcie ich do zapytania ofertowego i do oceny dostawcy jeszcze przed wyborem oszczędza całą rundę renegocjacji. Praktyczna kolejność: najpierw ustal podprocesorów i lokalizację (2 i 3), bo one przesądzają, czy w ogóle wchodzicie w transfer i głębszy łańcuch. Potem trening modeli (4), bo to pytanie, na które wielu dostawców nie ma gotowej odpowiedzi, więc lepiej zadać je wcześnie. Reszta to klauzule, które i tak powinny być w każdej dojrzałej umowie powierzenia, ale przy AI trzeba je doczytać pod kątem tego, co specyficzne. Cały ten ślad, ocena dostawcy, DPA i mapa przepływu, zwykle obsługuje naraz kilka reżimów, więc warto wytwarzać go raz, a nie osobno pod RODO i osobno pod NIS2.

FAQ

Czy wystarczy wzór DPA od dostawcy?

Rzadko. Wzór dostawcy jest pisany pod dostawcę i zwykle milczy w dwóch miejscach krytycznych dla AI: pełnej liście podprocesorów za API modelu oraz użyciu danych do trenowania. Te dwa punkty trzeba dopisać albo wynegocjować.

Czym to różni się od zwykłej umowy powierzenia?

Rdzeń jest ten sam, bo DPA to instytucja RODO. Różnica leży w głębszym łańcuchu podprocesorów i w klauzuli o treningu modeli, której klasyczny DPA nie zawiera.

Czy on-prem zdejmuje potrzebę DPA?

Zależy od modelu wdrożenia. Jeśli dane nie opuszczają waszego środowiska i nie ma zewnętrznego procesora, rola DPA maleje, bo nie ma komu powierzać. Gdy w grę wchodzi zewnętrzny dostawca lub jego infrastruktura, DPA jest potrzebne, a on-prem głównie skraca listę podprocesorów.

Co, jeśli dostawca nie zgadza się na prawo do audytu?

Częste przy dużych dostawcach. Akceptowalnym kompromisem bywa dostęp do niezależnych raportów z badań i do logów zamiast fizycznej inspekcji, o ile zakres raportu realnie pokrywa to, co musicie wykazać.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc naturalnie akcentuję kontrolę przepływu danych i krótszy łańcuch podprocesorów. Starałem się opisać klauzule niezależnie od modelu wdrożenia, bo tę samą listę trzeba przejść i dla chmury, i dla on-prem, różni się tylko rozkład pracy dowodowej. Ten tekst nie jest poradą prawną. Brzmienie klauzul konsultuj z prawnikiem i z inspektorem ochrony danych, bo zależy od stanu faktycznego.

// co tu nie pokrywamCzego tu nie pokrywam

Nie podaję gotowego brzmienia klauzul ani wzoru umowy, bo to zadanie dla prawnika, nie dla notatki. Nie wchodzę w numerację konkretnych przepisów, odwołuję się do nich funkcyjnie. Pomijam pełną analizę mechanizmów transferu poza EOG, bo to osobny, większy temat. Nie omawiam też konstrukcji, w której dostawca jest współadministratorem, a nie procesorem, bo rządzi się inną logiką niż powierzenie.

Powiązane notatki

• Vendor security review AI: 12 pytań przed podpisaniem MSA
• ISO 27001 a AI vendor: trzy kontrole, które warto zmapować dziś
• Audit readiness NIS2 plus AI: 7 dokumentów, które wytwarzasz przed audytorem
• Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d