Umowa powierzenia danych (DPA) z firmą od automatyzacji: czego wymagać

Umowę powierzenia przetwarzania danych podpisujemy w NoCodeWork kilka razy w roku, tyle że z drugiej strony stołu niż większość osób czytających ten tekst. To my jesteśmy podmiotem przetwarzającym: dostajemy dostęp do skrzynki, CRM-u i bazy klientów, żeby zbudować i utrzymywać automatyzacje. Klient przysyła wzór, my czytamy go zdanie po zdaniu i część odsyłamy z uwagami.

Te wzory rozkładają się tak. Albo dokumentu nie ma wcale, choć wykonawca od pół roku ma administracyjny dostęp do systemu z danymi kilku tysięcy osób. Albo jest, ściągnięty z internetu i podpisany bez czytania: bez listy podprocesorów, bez zdania o modelach AI, za to z karą umowną wyższą niż wartość wdrożenia. Trzecia grupa, najrzadsza, to umowy pisane pod konkretną współpracę.

To nie porada prawna, tylko lista rzeczy, które w tych dokumentach realnie widzimy. O umowie głównej (własność workflow, dostępy, plan wyjścia) pisaliśmy w tekście o umowie na automatyzację. Tutaj chodzi wyłącznie o dane osobowe.

TL;DR: DPA jest potrzebna zawsze, gdy wykonawca automatyzacji dotyka danych osobowych, czyli przy CRM, skrzynce i bazie klientów praktycznie zawsze. Art. 28 ust. 3 RODO wyznacza minimum treści. Reszta sporu toczy się o cztery rzeczy: listę podprocesorów, lokalizację danych, realny tryb audytu i wysokość kar umownych.

Kiedy DPA jest potrzebna, a kiedy nie

Podział ról jest prostszy, niż sugeruje żargon. Twoja firma decyduje, po co i jak przetwarza dane swoich klientów, więc jest administratorem. Wykonawca robi to na Twoje polecenie, więc jest podmiotem przetwarzającym. Art. 28 RODO wymaga, żeby taka relacja opierała się na umowie w formie pisemnej, w tym elektronicznej.

Powierzeniem jest sam dostęp, a nie kopiowanie danych do siebie. Wykonawca, który loguje się do Twojego CRM-u, żeby zbudować workflow, przetwarza dane Twoich klientów, nawet jeśli nigdy nic nie pobrał na dysk. Tak samo działa dostęp do skrzynki, systemu zamówień, bazy kandydatów czy panelu fakturowego. Osobna sprawa to hosting: jeśli wykonawca utrzymuje Twoją instancję n8n na swoim serwerze, dane osobowe przez nią płyną i powierzenie jest oczywiste, co rozkładamy szerzej w tekście o n8n i RODO.

Wyjątki są wąskie. Powierzenia nie ma, gdy workflow rusza wyłącznie dane bez elementu osobowego: stany magazynowe, liczby produkcyjne, zagregowane raporty. Drugi wyjątek to praca na danych syntetycznych, bez dostępu do produkcji. Rzadko trwa dłużej niż kilka tygodni, bo prędzej czy później ktoś musi zajrzeć do logu z prawdziwym mailem klienta.

Minimum z art. 28 ust. 3 RODO

Przepis wymienia wprost, co umowa musi określać. To lista do odhaczenia, nie miejsce na kreatywność.

Do tego dochodzi osiem obowiązków wykonawcy: przetwarzanie wyłącznie na udokumentowane polecenie administratora, poufność osób dopuszczonych do danych, środki bezpieczeństwa z art. 32, przestrzeganie zasad podpowierzenia, pomoc przy żądaniach osób, których dane dotyczą, pomoc przy obowiązkach z art. 32 do 36, usunięcie lub zwrot danych po zakończeniu usługi oraz udostępnienie informacji i umożliwienie audytów.

Jest jeszcze zdanie czytane najrzadziej, a chroniące obie strony: wykonawca ma niezwłocznie poinformować administratora, jeśli jego zdaniem otrzymane polecenie narusza przepisy o ochronie danych. To formalna podstawa, żeby powiedzieć „nie zbudujemy tego w ten sposób".

Stawka jest taka: naruszenie art. 28 mieści się w niższym progu kar z art. 83 ust. 4 RODO, do 10 mln euro albo 2 procent światowego rocznego obrotu. Odpowiada administrator, czyli Twoja firma, także wtedy, gdy realnym problemem był brak umowy z wykonawcą.

Podprocesorzy: hosting, SaaS, modele AI

Tu wzory z internetu rozjeżdżają się z rzeczywistością automatyzacji najmocniej. Klauzula brzmi „podmiot przetwarzający nie korzysta z usług innych podmiotów bez uprzedniej zgody administratora", wykonawca podpisuje, a tego samego dnia stawia instancję u dostawcy serwerów i wysyła zapytania do modelu językowego. Formalnie łamie umowę od pierwszego dnia.

Art. 28 ust. 2 dopuszcza zgodę szczegółową, osobną dla każdego podprocesora, albo ogólną pisemną, przy której wykonawca informuje o zmianach na liście, a administrator może zgłosić sprzeciw. Przy wdrożeniach dla MŚP działa tylko ta druga, bo zgoda szczegółowa oznacza aneks za każdym razem, gdy dostawca zmieni podwykonawcę centrum danych. Sensowny załącznik wygląda tak:

Dopisz termin uprzedzenia o zmianie (14 albo 30 dni) i skutek sprzeciwu. Ten drugi punkt pomijany jest najczęściej, a bez niego prawo sprzeciwu nic nie znaczy: jeśli administrator sprzeciwia się nowemu dostawcy, a wykonawca nie ma alternatywy, umowa musi mówić, co dalej. Zwykle rozwiązaniem jest prawo do wypowiedzenia bez kar dla obu stron.

Zgodnie z art. 28 ust. 4 to wykonawca odpowiada wobec Ciebie za swojego podprocesora. Jeśli dostawca serwera zgubi dane, partnerem do rozmowy nie jest ten dostawca, tylko firma, która go wybrała.

Gdzie fizycznie leżą dane

Pytanie „gdzie leżą nasze dane" powinno mieć w umowie odpowiedź w postaci nazw i krajów, a nie zdania o „serwerach zapewniających odpowiedni poziom ochrony".

Wewnątrz Europejskiego Obszaru Gospodarczego dane krążą swobodnie. Poza EOG wchodzi rozdział V RODO. Komisja Europejska wydała decyzje o adekwatności dla kilkunastu jurysdykcji, między innymi dla Wielkiej Brytanii, Szwajcarii i Japonii, a w przypadku Stanów Zjednoczonych dla firm uczestniczących w EU-US Data Privacy Framework. Gdzie decyzji nie ma, najczęściej używanym narzędziem są standardowe klauzule umowne.

Transfer poza EOG nie jest więc zakazany, ale wymaga podstawy wskazanej w dokumentach. Jeśli w umowie tego nie ma, a workflow wysyła treść maili do usługi hostowanej za oceanem, luka jest po stronie administratora, nie tylko wykonawcy.

Tu leży jeden z mocniejszych argumentów za instancją na własnym serwerze w UE. Przy self-hostowanym n8n dane wykonania zostają na serwerze, który wskazujesz, a lista podprocesorów kurczy się do serwerowni i tych narzędzi, które sam podepniesz. To nie magiczna zgodność, ale zdejmuje z rozmowy o DPA kilka trudnych punktów naraz.

„Najgorsze umowy powierzenia, jakie czytaliśmy, nie były pisane po łebkach. Były przepisane ze wzoru dla globalnego dostawcy chmury: dwadzieścia stron obowiązków, których trzyosobowa firma wdrożeniowa fizycznie nie wykona, łącznie z całodobowym zespołem bezpieczeństwa i certyfikatem, którego nikt na tym rynku nie ma. Wykonawca podpisuje, bo chce zlecenie, i od pierwszego dnia jest w naruszeniu. Klient ma wtedy dokument, a nie ochronę." — Mikołaj Brunka, założyciel NoCodeWork

Środki bezpieczeństwa: konkretne zamiast „odpowiednich"

Art. 32 RODO mówi o „odpowiednich środkach technicznych i organizacyjnych" i w dziewięciu wzorach na dziesięć to sformułowanie jest po prostu przepisane. Załącznik, który brzmi „Podmiot przetwarzający stosuje odpowiednie środki", nie daje administratorowi nic: nie da się go wyegzekwować ani sprawdzić. Lista, którą sami wpisujemy do naszych DPA, jest krótka i sprawdzalna:

• Dostępy imienne, każda osoba po stronie wykonawcy na własnym koncie. Wspólne hasło do konta „admin" oznacza, że nigdy nie ustalisz, kto co zmienił.
• Uwierzytelnianie dwuskładnikowe na kontach mających dostęp do systemów z danymi.
• Szyfrowanie w tranzycie i w spoczynku, łącznie z credentialami w platformie i dyskiem serwera.
• Minimalny zakres uprawnień: dostęp do systemów objętych wdrożeniem, a nie rola administratora całej organizacji, bo tak było szybciej.
• Rejestr osób dopuszczonych do danych i zobowiązania do poufności, obejmujące też podwykonawców wykonawcy.
• Backupy z określoną częstotliwością i miejscem przechowywania, z informacją, czy kopie leżą w UE.
• Retencja logów wykonań podana w dniach. Przy automatyzacjach to punkt pomijany najczęściej, a logi w n8n czy Make potrafią zawierać pełną treść rekordów i żyć tam miesiącami.
• Procedura odbierania dostępów przy odejściu osoby z projektu.

Nie wymagaj za to certyfikatów, których na tym rynku nie ma. ISO 27001 czy SOC 2 mają zwykle dostawcy platform i chmur, a nie kilkuosobowe firmy wdrożeniowe. Jeśli certyfikat jest dla Ciebie warunkiem, powiedz to przy wyborze wykonawcy, a nie przy podpisie. Jak z bezpieczeństwem radzą sobie same platformy, opisaliśmy w tekście o bezpieczeństwie automatyzacji.

Audyt, który da się przeprowadzić

Art. 28 ust. 3 lit. h daje administratorowi prawo do kontroli, w tym inspekcji. Problem leży w tym, jak to prawo bywa opisane: „Administrator ma prawo przeprowadzić audyt w dowolnym momencie, bez uprzedzenia, na koszt Podmiotu przetwarzającego". Widzieliśmy ten zapis wielokrotnie i nigdy nie widzieliśmy, żeby ktoś z niego skorzystał.

Klauzula z szansą na zadziałanie ma cztery elementy: uprzedzenie (14 dni), częstotliwość (raz w roku plus po naruszeniu), zakres ograniczony do przetwarzania objętego umową i podział kosztów. Rynkowo pierwszy audyt w roku wykonawca obsługuje w ramach umowy, kolejne są płatne, chyba że wynikają z naruszenia.

W praktyce najczęściej używanym narzędziem nie jest inspekcja na miejscu, tylko kwestionariusz. Raz w roku wysyłasz listę pytań: kto ma dostęp, jakie środki, jacy podprocesorzy, jakie retencje, czy były incydenty. Odpowiedzi na piśmie są dowodem nadzoru i to realistyczna wersja obowiązku kontroli dla firmy bez działu compliance.

Zwrot i usunięcie danych po zakończeniu

Art. 28 ust. 3 lit. g: po zakończeniu świadczenia usług wykonawca usuwa lub zwraca dane, zależnie od decyzji administratora, i kasuje istniejące kopie, chyba że prawo nakazuje ich przechowanie.

Przy automatyzacjach trzeba to rozpisać, bo dane są w kilku miejscach naraz: eksporty i pliki robocze na komputerach wykonawcy, kopie testowe w środowisku deweloperskim, logi wykonań (nierzadko z całą treścią rekordów), backupy serwera oraz konta wykonawcy w Twoich systemach.

Zapisz termin, formę potwierdzenia i osobną regułę dla kopii zapasowych. Trzydzieści dni od zakończenia współpracy to rozsądna wartość, oświadczenie o usunięciu wystarcza jako potwierdzenie, a przy backupach usunięcie punktowe zwykle nie jest technicznie możliwe. Standardowo dane w kopiach wygasają wraz z ich rotacją w zadeklarowanym terminie i do tego czasu nie są używane do żadnych celów.

Zgłaszanie naruszeń: 24 godziny czy „bez zbędnej zwłoki"

RODO rozkłada to na dwa poziomy. Administrator zgłasza naruszenie organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia. Wykonawca ma jeden obowiązek: zawiadomić administratora bez zbędnej zwłoki, bez sztywnego terminu w przepisie.

Ponieważ to administrator biegnie z zegarem 72 godzin, umowy powszechnie skracają termin dla wykonawcy do 24 albo 48 godzin. Sami takie terminy akceptujemy, pod jednym warunkiem: mają biec od stwierdzenia naruszenia, a nie od jego wystąpienia. Zapis „w ciągu 24 godzin od zaistnienia naruszenia" jest niewykonalny, bo dotyczy zdarzeń, o których nikt jeszcze nie wie.

Dopisz trzy rzeczy, których brakuje w większości wzorów: kanał zgłoszenia z konkretnym adresem i telefonem (nie „pisemnie na adres siedziby", bo to gwarantuje przekroczenie terminu), minimalny zakres pierwszego zgłoszenia (co się stało, jakich danych i ilu osób dotyczy) oraz obowiązek uzupełniania informacji w miarę ustalania faktów.

Odpowiedzialność i kary umowne

Tu przebiega największa linia sporu i tu najczęściej odsyłamy wzory z uwagami.

Art. 82 RODO rozkłada odpowiedzialność odszkodowawczą według winy i roli: wykonawca odpowiada za szkodę wtedy, gdy nie dopełnił obowiązków nałożonych na podmioty przetwarzające albo działał poza zgodnymi z prawem poleceniami administratora. Kary umowne to osobna warstwa, dopisywana z woli stron, i to w niej pojawiają się zapisy oderwane od realiów wdrożenia. Cztery widujemy najczęściej:

• Kara nieproporcjonalna do kontraktu: kwota liczona w dziesiątkach tysięcy złotych przy wdrożeniu wartym ułamek tej sumy. Wykonawca, który to podpisuje, zwykle po prostu nie przeczytał.
• Kara za każde naruszenie, niezależnie od przyczyny. „Za każdy incydent bezpieczeństwa", bez rozróżnienia, czy zawinił wykonawca, dostawca serwera, czy pracownik klienta, który wysłał plik na prywatną skrzynkę.
• Kara za samo zgłoszenie naruszenia. Efekt wychodzi odwrotny do zamierzonego, bo wykonawca dostaje finansowy powód, żeby o incydencie milczeć.
• Brak limitu kumulacji: kary sumujące się bez górnego pułapu i bez odniesienia do wartości umowy.

Wersja uczciwa wobec obu stron: kary powiązane z konkretnymi, sprawdzalnymi uchybieniami (brak informacji o naruszeniu w terminie, użycie podprocesora spoza listy, nieusunięcie danych), z limitem odniesionym do wartości umowy i z wyłączeniem zdarzeń po stronie administratora. Polskie prawo pozwala zresztą sądowi obniżyć rażąco wygórowaną karę umowną, więc zapis odstraszający na papierze bywa mniej groźny, niż wygląda. To już pytanie do prawnika, nie do wykonawcy automatyzacji.

AI w łańcuchu przetwarzania

Jeśli workflow wysyła treść do modelu językowego, w łańcuchu pojawia się kolejny podmiot. Klasyfikacja maila, streszczenie rozmowy, wyciąganie danych z faktury: za każdym razem dane Twoich klientów opuszczają Twoje systemy. Dostawca API jest wtedy podprocesorem i musi być na liście, tak samo jak firma hostingowa. Do zapisania są trzy rzeczy:

1. Wyłączenie trenowania na Waszych danych. U głównych dostawców dostęp przez API różni się pod tym względem od zwykłego konta w aplikacji czatowej, ale to deklaracja, którą trzeba mieć w warunkach i w DPA, a nie w mailu od handlowca.
2. Retencja po stronie dostawcy: ile dni trzyma zapytania, czy da się to skrócić, kto po jego stronie ma do nich dostęp. Przy danych wrażliwych ten punkt bywa rozstrzygający.
3. Region przetwarzania. Część dostawców pozwala wybrać UE, część nie. Jeśli nie, wracasz do rozmowy o transferach z poprzedniej sekcji.

Przy najbardziej wrażliwych procesach sięgamy po model uruchomiony lokalnie albo na tym samym serwerze co automatyzacje. Dane nie wychodzą wtedy poza infrastrukturę, kosztem jakości i wygody. Kiedy to się opłaca, rozkładamy w tekście o bezpiecznym korzystaniu z AI w organizacji, a obowiązki z AI Act w artykule o AI Act i RODO dla polskiej firmy.

Checklista: 10 pytań przed podpisaniem

Zadaj je sobie z dokumentem w ręku. Każde „nie wiem" to miejsce do poprawienia.

1. Czy umowa wymienia przedmiot, czas, charakter i cel przetwarzania, rodzaj danych i kategorie osób, a nie tylko odsyła do „współpracy"?
2. Czy jest załącznik z listą podprocesorów, z nazwami i lokalizacjami?
3. Ile dni wcześniej wykonawca uprzedza o zmianie na tej liście i co się dzieje, gdy zgłosisz sprzeciw?
4. Czy dane wychodzą poza EOG, a jeśli tak, na jakiej podstawie?
5. Czy załącznik o środkach bezpieczeństwa da się sprawdzić, czy jest przepisanym art. 32?
6. Czy retencja logów wykonań ma podaną liczbę dni?
7. Czy tryb audytu jest wykonalny: uprzedzenie, częstotliwość, zakres, koszty?
8. Czy termin zgłoszenia naruszenia biegnie od stwierdzenia i czy wskazany jest kanał kontaktu?
9. Czy kary umowne mają limit i związek z wartością umowy, i czy nie karzą za samo zgłoszenie incydentu?
10. Czy jest zapisane, co dzieje się z danymi po zakończeniu: termin, forma potwierdzenia, reguła dla backupów?

Na co uważać po obu stronach

Najczęstszy błąd klienta to skala dokumentu oderwana od skali wdrożenia. Dwudziestostronicowa umowa z karami rodem z przetargu publicznego, podpięta do automatyzacji za kilka tysięcy złotych, powoduje jedno: dobrzy wykonawcy odpadają, a zostaje ten, który podpisze wszystko, bo nie przeczytał. Ochrona jest wtedy pozorna.

Błąd wykonawcy jest lustrzany: podpisać byle podpisać. Umowa, w której obiecujesz całodobowy zespół bezpieczeństwa, audyt na żądanie w 24 godziny i zerowe korzystanie z podprocesorów, jest zobowiązaniem nie do dotrzymania, a przy pierwszym incydencie zamienia się w dowód przeciwko Tobie.

Trzeci błąd popełniają obie strony razem: podpisać DPA i uznać temat za zamknięty. Umowa jest zdjęciem stanu na dany dzień, a potem dochodzi nowa integracja, zmienia się dostawca serwera, do workflow wchodzi model AI, którego pół roku wcześniej tam nie było. Przegląd załączników raz na rok, przy odnowieniu umowy utrzymaniowej, wystarczy.

I rzecz ostatnia: to tekst praktyka wdrożeniowego, nie prawnika. Brzmienie klauzul, zwłaszcza o karach i odpowiedzialności, przejrzyj z kancelarią. Przegląd wzoru to jednorazowy koszt rzędu kilkuset złotych i starcza na wiele umów. A jeśli dopiero szukasz firmy do współpracy, reakcja na prośbę o DPA jest jednym z lepszych testów: uczciwy wykonawca ma wzór w szufladzie, słabszy mówi „dopiszemy to potem". Więcej takich testów zebraliśmy w tekście o doborze partnera do automatyzacji.

FAQ

Czy przy każdym wdrożeniu automatyzacji potrzebna jest umowa powierzenia?

Zawsze wtedy, gdy wykonawca ma dostęp do danych osobowych, a przy automatyzacjach skrzynki, CRM-u, zamówień czy faktur ma go praktycznie zawsze. Powierzeniem jest sam dostęp do systemu, nawet jeśli wykonawca niczego nie kopiuje do siebie. Umowa nie jest potrzebna tylko wtedy, gdy workflow dotyka danych bez elementu osobowego, na przykład stanów magazynowych czy raportów liczbowych.

Co musi zawierać DPA według art. 28 ust. 3 RODO?

Przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych osobowych, kategorie osób, których dane dotyczą, oraz obowiązki i prawa administratora. Do tego osiem obowiązków podmiotu przetwarzającego: działanie wyłącznie na udokumentowane polecenie, poufność osób dopuszczonych do danych, środki bezpieczeństwa z art. 32, zasady podpowierzenia, pomoc przy żądaniach osób, których dane dotyczą, pomoc przy obowiązkach z art. 32 do 36, usunięcie lub zwrot danych po zakończeniu usługi oraz umożliwienie audytów.

Czy wykonawca automatyzacji może korzystać z podwykonawców i narzędzi SaaS?

Tak, ale za zgodą administratora. Art. 28 ust. 2 RODO dopuszcza zgodę szczegółową dla każdego podprocesora osobno albo ogólną pisemną, przy której wykonawca informuje o zamierzonych zmianach, a administrator może zgłosić sprzeciw. Przy automatyzacjach praktyczna jest tylko zgoda ogólna z załącznikiem wymieniającym hosting, platformę, dostawcę modelu AI i narzędzia do powiadomień. Za działania podprocesora wykonawca odpowiada wobec Ciebie jak za własne.

W jakim terminie wykonawca musi zgłosić naruszenie ochrony danych?

RODO wymaga zawiadomienia administratora bez zbędnej zwłoki, bez wskazania konkretnej liczby godzin. Ponieważ administrator ma własny termin 72 godzin na zgłoszenie do organu nadzorczego, umowy zwykle skracają czas dla wykonawcy do 24 albo 48 godzin. To rozsądny standard pod jednym warunkiem: termin ma biec od stwierdzenia naruszenia, a nie od jego wystąpienia, i w umowie musi być wskazany konkretny kanał kontaktu.

Czy dane klientów mogą trafiać do modelu AI w automatyzacji?

Mogą, jeśli dostawca modelu jest wpisany na listę podprocesorów, transfer poza EOG ma podstawę prawną, a warunki wykluczają trenowanie modelu na Waszych danych. Ustal też retencję zapytań po stronie dostawcy i region przetwarzania. Przy procesach najbardziej wrażliwych alternatywą jest model uruchomiony lokalnie albo na tym samym serwerze co automatyzacje: dane w ogóle nie opuszczają wtedy infrastruktury.

Podsumowanie

Dobra umowa powierzenia nie jest ani najdłuższa, ani najbardziej restrykcyjna. Jest nią ta, którą obie strony realnie wykonają. Art. 28 ust. 3 RODO daje szkielet, którego nie da się ominąć, a spór i tak toczy się poza nim: o listę podprocesorów, o to, gdzie leżą dane, o tryb audytu i o wysokość kar.

Podpisując te dokumenty jako wykonawca, najlepiej pracujemy na umowie krótkiej i konkretnej: kilka załączników zamiast dwudziestu stron klauzul, lista podprocesorów z nazwami, sprawdzalne środki bezpieczeństwa, termin naruszenia liczony od stwierdzenia i kary powiązane z wartością kontraktu. Taki dokument daje klientowi realną ochronę, a wykonawcy zobowiązania, których dotrzyma. Wzór ściągnięty z internetu, bez jednego zdania o AI i hostingu, nie daje nikomu nic poza poczuciem, że temat jest odhaczony.

Chcesz sprawdzić, czy Wasza umowa z wykonawcą automatyzacji pokrywa to, co realnie dzieje się z danymi w workflow? Umów bezpłatną konsultację — powiemy wprost, jeśli wystarczy dopisać załącznik z listą podprocesorów i żadne większe porządki nie są potrzebne.

Przeczytaj również

• Umowa na automatyzację: co musi zawierać, żebyś nie został z niczym
• n8n a RODO: gdzie trzymać dane firmowych automatyzacji
• AI Act i RODO: co musi wiedzieć polska firma wdrażająca AI
• Jak bezpiecznie korzystać z AI w organizacji
• Jak dobrać partnera do wdrożenia automatyzacji