Umowa powierzenia dla AI: Luki w standardowej umowie
Dlaczego standardowe umowy powierzenia nie wystarczą dla enterprise AI. Lista kontrolna wymagań dla HR i compliance.
Umowa powierzenia przetwarzania danych dla infrastruktury AI musi obejmować dziesięć obszarów, których standardowe umowy SaaS nie regulują: polityki logowania promptów, separacja środowisk (dev/staging/prod), łańcuchy dostawców modeli, przetwarzanie in-flight vs. at-rest, ochrona danych embeddingów RAG, dostęp z krajów trzecich do danych produkcyjnych, zgodność z tajemnicą zawodową, tokenizacja PII, ścieżki audytu Decision Layer i weryfikowalność środków technicznych.
Dlaczego standardowe umowy powierzenia nie wystarczą dla infrastruktury AI
Standardowa umowa powierzenia przetwarzania danych osobowych reguluje sposób, w jaki podmiot przetwarzający obsługuje dane osobowe w imieniu administratora. Definiuje cel, kategorie danych, środki techniczne i organizacyjne, podwykonawców przetwarzania oraz okresy przechowywania. Dla systemu CRM czy oprogramowania HR to wystarczy.
Infrastruktura enterprise AI tworzy konstelacje, których żadna standardowa umowa nie przewiduje. Model językowy przetwarza prompty - wprowadzenia tekstowe, które mogą zawierać wszystko: dane kadrowe, informacje klientów, tajemnice przedsiębiorstwa, a nawet szczególne kategorie danych z art. 9 RODO, gdy pracownik zada pytanie dotyczące zdrowia. Dane przepływają przez łańcuch systemów: od interfejsu przez warstwę orkiestracji do dostawcy modelu, z powrotem do bazy danych, potencjalnie przez pipeline RAG z wektorami embedding. Na każdym etapie pojawiają się inne pytania o przechowywanie, dostęp i usuwanie.
Gdy pytasz swojego dostawcę AI o umowę powierzenia i otrzymujesz standardowy dokument, powinno to wzbudzić czujność. Nie dlatego, że dostawca jest niewiarygodny, lecz dlatego, że specyficzne ryzyka infrastruktury AI wymagają innych regulacji niż klasyczna aplikacja SaaS.
Dziesięć luk między standardową umową a rzeczywistością AI
1. Treść promptów jako nowa kategoria danych
Standardowe umowy wymieniają kategorie danych: imię, email, numer pracownika. Przy agentach AI pojawia się kategoria, której nie da się z góry zdefiniować - prompt. Prompt może być nieszkodliwym pytaniem o regulamin urlopowy albo kompletnym pismem klienckim z danymi osobowymi. Umowa musi regulować, że odpowiedzialność za klasyfikację treści leży po stronie organizacji, a dostawca AI nie dokonuje wstępnej weryfikacji treści. Jednocześnie dostawca musi wykazać środki techniczne chroniące wszystkie wprowadzone treści - niezależnie od ich wrażliwości.
2. Polityka logowania: Co może znaleźć się w logach?
Przy klasycznym oprogramowaniu logowane jest to, co technicznie konieczne. Przy infrastrukturze AI logowanie ma inny wymiar: Czy treści promptów są logowane? Czy odpowiedzi modelu są zapisywane? Czy przesłane dokumenty trafiają do logów błędów?
Solidna umowa powierzenia dla infrastruktury AI musi jednoznacznie ustalić, że w środowisku produkcyjnym logowanie treści żądań/odpowiedzi jest wyłączone, że rejestrowane są wyłącznie metadane techniczne, że logowanie debugowe w produkcji jest dezaktywowane i że ślady stosu nie zawierają treści promptów ani dokumentów.
3. Separacja środowisk: Dev, Staging, Prod
Każde wdrożenie enterprise posiada środowiska deweloperskie, testowe i produkcyjne. Przy infrastrukturze AI separacja jest krytyczna dla bezpieczeństwa, ponieważ prawdziwe dane mogą być wykorzystane jako dane testowe. Umowa specyficzna dla AI musi ustalić, że środowiska dev i staging wykorzystują wyłącznie dane syntetyczne lub zanonimizowane, że dostęp produkcyjny jest ograniczony do zdefiniowanych ról w UE/EOG i że przypadki wsparcia są obsługiwane wyłącznie z danymi testowymi zatwierdzonymi przez organizację.
4. Łańcuch dostawców modeli zamiast klasycznych podwykonawców
Przy klasycznym oprogramowaniu dostawca ma podwykonawców przetwarzania: dostawcę hostingu, może usługę email. Przy infrastrukturze AI powstaje łańcuch trzywarstwowy: dostawca infrastruktury AI obsługuje platformę, dostawcy modeli (Azure OpenAI, Google Vertex AI, Anthropic) przetwarzają prompty, dostawcy platformy (Supabase, Vercel) hostują bazę danych i frontend.
Kluczowy punkt: Kto jest partnerem umownym dostawców modeli? Czy modele działają w tenancie dostawcy AI czy w tenancie organizacji? Ta różnica decyduje o tym, czy dostawca modelu jest podwykonawcą przetwarzania dostawcy, czy organizacja samodzielnie zarządza relacjami z dostawcami.
| Komponent | W tenancie klienta | W tenancie dostawcy |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Klient | - |
| Azure OpenAI / Vertex AI | ✓ Klient | - |
| Supabase (Baza danych) | ✓ Klient | - |
| Vercel (Hosting) | ✓ Klient | - |
| Plane (System zgłoszeń) | - | ✓ Dostawca |
| GitHub (Hosting kodu) | - | ✓ Dostawca |
| Google Workspace (Komunikacja) | - | ✓ Dostawca |
Komponenty w tenancie klienta są zarządzane przez klienta w jego własnej ewidencji dostawców. Komponenty w tenancie dostawcy podlegają liście podwykonawców przetwarzania w umowie.
5. In-flight vs. at-rest: Gdzie pozostają dane?
Przy klasycznym oprogramowaniu pytanie jest proste: dane leżą w bazie danych. Przy infrastrukturze AI istnieją dwa tryby przetwarzania. Przetwarzanie in-flight: prompt jest wysyłany do dostawcy modelu, przetwarzany i odpowiedź zwracana - brak trwałego przechowywania u dostawcy. Przechowywanie at-rest: czaty, przesłane pliki i embeddingi są przechowywane w bazie danych - trwale i przypisane do użytkownika.
Umowa musi ustanowić odrębne regulacje dla obu trybów.
6. RAG i embeddingi: Dane wektorowe jako nowe wyzwanie
RAG (Retrieval Augmented Generation) umożliwia przeszukiwanie dokumentów firmowych przez AI. Dokumenty są konwertowane na wektory embedding i przechowywane w bazie wektorowej. Wektory te stanowią nową kategorię danych: nie zawierają czytelnych tekstów, ale w określonych okolicznościach mogą pozwalać na wnioskowanie o treści oryginalnej. Umowa musi traktować embeddingi jako dane osobowe, gdy są generowane z dokumentów zawierających dane osobowe.
7. Dostęp z krajów trzecich do danych produkcyjnych
Wielu dostawców AI pracuje z rozproszonymi zespołami. Gdy deweloper z kraju trzeciego ma dostęp do środowiska produkcyjnego, stanowi to transfer danych w rozumieniu RODO. Umowa musi definiować, że dostęp produkcyjny jest ograniczony do UE/EOG, że dostęp dev/staging z krajów trzecich jest dopuszczalny (ponieważ obecne są tylko dane syntetyczne), że RBAC przewiduje oddzielne grupy adminów dla produkcji i dev/staging i że istnieje procedura wyjątkowa wymagająca pisemnej zgody administratora.
Uwaga dla rynku polskiego: UODO (Urząd Ochrony Danych Osobowych) stosuje rygorystyczne podejście do transferów danych do państw trzecich. Organizacje powinny szczególnie zweryfikować, czy standardowe klauzule umowne (SCC) są wystarczające, czy potrzebne są dodatkowe zabezpieczenia.
8. Tajemnica zawodowa na platformie AI
Dla regulowanych branż - kancelarii prawnych, doradców podatkowych, biegłych rewidentów, placówek medycznych - przetwarzanie na platformie AI wymaga jednoznacznych regulacji umownych. Polskie prawo przewiduje ochronę tajemnicy zawodowej (art. 266 Kodeksu karnego, przepisy branżowe). Dostawca musi zobowiązać wszystkie osoby mające dostęp pisemnie do zachowania poufności. Standardowe klauzule poufności nie wystarczają.
9. Tokenizacja PII jako moduł opcjonalny
Filtry wejściowe i wyjściowe wykrywające dane osobowe i pseudonimizujące je przed przekazaniem do dostawcy modelu dodają dodatkową warstwę ochrony. Tokenizacja PII nie jest konieczna w każdym wdrożeniu, ale umowa powinna przewidywać ją jako moduł opcjonalny. Ważne: jeśli możliwa jest odwracalna re-identyfikacja, umowa musi regulować, kto ma dostęp do tabeli mapowania, jak klucze mapowania są przechowywane i szyfrowane oraz że re-identyfikacja następuje wyłącznie celowo po udokumentowanej autoryzacji.
10. Ścieżka audytu i Decision Layer
Agenci AI podejmują lub przygotowują decyzje. Każda z tych decyzji musi być możliwa do prześledzenia - nie tylko ze względu na ochronę danych, ale także dla audytu wewnętrznego, biegłych rewidentów i przedstawicieli pracowników. Decision Layer rozkłada każdy proces na poszczególne kroki decyzyjne i definiuje dla każdego kroku: człowiek, silnik reguł lub AI. Umowa musi zakotwiczać ścieżkę audytu jako element umowny: Jakie dane są rejestrowane przy każdej decyzji? Jak długo są przechowywane? Kto ma dostęp?
Lista kontrolna: 25 pytań do dostawcy AI
Poniższa lista kontrolna przekształca dziesięć luk w konkretne pytania weryfikacyjne.
Lista kontrolna: 25 pytań weryfikacyjnych dla umów powierzenia AI →
A - Kategorie danych i cele przetwarzania
- Czy treści promptów i odpowiedzi modeli są wymienione jako odrębne kategorie danych w umowie?
- Czy ustalono, że odpowiedzialność za klasyfikację treści leży po stronie organizacji, a nie dostawcy?
- Czy embeddingi/wektory są sklasyfikowane jako potencjalnie dane osobowe?
- Czy umowa przewiduje regulację dla szczególnych kategorii danych z art. 9 RODO, które mogą powstać przez wprowadzenia użytkowników?
B - Logowanie i monitoring
- Czy logowanie treści żądań/odpowiedzi w środowisku produkcyjnym jest wyłączone?
- Jakie metadane są rejestrowane (kody statusu, czasy odpowiedzi, identyfikatory żądań)?
- Czy logowanie debugowe w produkcji jest weryfikowalnie wyłączone?
- Czy ślady stosu i komunikaty błędów są skonfigurowane tak, aby dane treściowe nie trafiały do logów?
- Czy weryfikacja ustawień logowania jest częścią procesu wydawniczego?
C - Separacja środowisk i dostęp
- Czy istnieją oddzielne środowiska (dev, staging, prod) z odrębnymi politykami danych?
- Czy środowiska dev/staging zawierają wyłącznie dane syntetyczne lub zanonimizowane?
- Czy dostęp produkcyjny jest ograniczony do autoryzowanych ról w UE/EOG?
- Czy istnieje udokumentowana procedura wyjątkowa dla przypadków wsparcia z dostępem do danych?
D - Dostawcy modeli i podwykonawcy
- Czy rozgraniczenie jest jasne: Którzy dostawcy są podwykonawcami przetwarzania dostawcy, a którzy działają w tenancie organizacji?
- Czy przechowywanie treści u dostawców modeli jest wyłączone?
- Czy wykluczenie wykorzystania do celów treningowych jest udokumentowane umownie?
- Gdzie znajdują się endpointy modeli (region UE, US, inne)?
E - Przechowywanie i usuwanie danych
- Czy ustalono, gdzie przechowywane są trwałe dane treściowe (baza danych, region, dostawca)?
- Jaka retencja kopii zapasowych obowiązuje i jak traktowane są usunięte dane w kopiach zapasowych?
- Czy pojedynczy użytkownik może samodzielnie usunąć swoje dane w aplikacji?
F - Branże regulowane
- Czy umowa zawiera regulację zgodności z tajemnicą zawodową (art. 266 KK lub odpowiednik branżowy)?
- Czy zobowiązania do poufności obejmują wszystkie osoby mające dostęp?
- Czy tokenizacja PII jest dostępna jako moduł opcjonalny?
G - Governance i weryfikowalność
- Czy ścieżka audytu dla decyzji agentów jest zakotwiczona jako element umowy?
- Czy środki techniczne i organizacyjne mogą być wykazane na żądanie (dokumentacja konfiguracji, zanonimizowane wyciągi z logów)?
Od listy kontrolnej do architektury
Te 25 pytań to nie narzędzie prawne. To kompas architektoniczny. Każde pytanie, na które Twój dostawca AI nie potrafi odpowiedzieć, ujawnia lukę w jego infrastrukturze - nie tylko w jego umowie.
W Gosign wbudowaliśmy te wymagania w architekturę: separacja środowisk z blokadą produkcji, logowanie bez danych treściowych, dostawcy modeli w tenancie klienta, Decision Layer z pełną ścieżką audytu. Nie dlatego, że klient tego wymagał, ale dlatego, że enterprise AI bez tych podstaw nie jest auditowalny.
Jeśli chcesz ocenić, jak Twoja obecna infrastruktura AI wypada w porównaniu z tymi 25 punktami - lub oceniasz nową platformę - chętnie porozmawiamy.