Gdzie trafiają dane firmowe w Make i Zapier i co z tego wynika dla RODO?

Dane przesyłane przez automatyzacje w Make i Zapier lądują na serwerach tych firm, co oznacza, że opuszczają infrastrukturę Waszej firmy. Zapier to firma amerykańska i dane trafiają domyślnie na serwery w USA. Make ma centra danych w Unii Europejskiej (region Frankfurt na AWS), ale korzysta też z podprocesów zlokalizowanych poza EOG. W obu przypadkach Wasza firma pozostaje administratorem danych osobowych w rozumieniu RODO i to Wy odpowiadacie za cały łańcuch przetwarzania, jeśli UODO zapyta.

Gdzie fizycznie lądują dane podczas automatyzacji w Make i Zapier?

Dane w automatyzacjach chmurowych nie tylko "przechodzą" przez serwery. Są też zapisywane. W Make każde uruchomienie scenariusza zostawia log wykonania: widać w nim, co zostało przesłane, do którego modułu i kiedy. W Zapier historia uruchomień pokazuje pełne payloady z danymi. Jeśli wysyłacie dane faktury przez Make do systemu księgowego, pola takie jak NIP kontrahenta, kwota czy numer rachunku są chwilowo przechowywane na serwerach Make.

Make domyślnie dla klientów europejskich kieruje ruch do regionu eu-central-1 na AWS, czyli Frankfurt. To dobra wiadomość: dane nie opuszczają EOG automatycznie. Zapier natomiast działa przede wszystkim z regionu us-east-1 w AWS, serwery w Stanach Zjednoczonych. Przy standardowej konfiguracji dane Waszej firmy opuszczają Europejski Obszar Gospodarczy.

Do tego dochodzą podprocesorzy (sub-processors). Make i Zapier nie obsługują całej infrastruktury samodzielnie. Korzystają z usług innych firm, np. AWS do hostingu, narzędzi do monitoringu i obsługi klienta. Każda z tych firm może mieć serwery poza EOG. Obaj dostawcy publikują aktualną listę sub-processors w swojej dokumentacji. Warto ją raz przejrzeć, zanim podejmiecie decyzję o tym, jakie dane przez te narzędzia puszczacie.

Osobna kwestia: OpenAI API. Wiele firm wpina OpenAI bezpośrednio w scenariusze Make, żeby przetworzyć treść dokumentu, wygenerować podsumowanie albo sklasyfikować maila. OpenAI to firma amerykańska i dane przesyłane przez API trafiają na serwery w USA, nawet jeśli sama automatyzacja działa z Frankfurtu. To dwa oddzielne transfery, dwa oddzielne podmioty przetwarzające.

Co to jest DPA i dlaczego podpisanie go to obowiązek, nie opcja?

DPA (Data Processing Agreement), czyli umowa powierzenia przetwarzania danych osobowych, jest wymagana przez art. 28 RODO. Jeśli przez Make lub Zapier przechodzą dane osobowe, musi istnieć podpisana umowa z każdym dostawcą. Nie ma wyjątków od tej zasady.

Make udostępnia gotowe DPA do zaakceptowania w panelu konta, w sekcji ustawień dotyczącej prywatności i ochrony danych. Zapier oferuje DPA na żądanie lub przez formularz w centrum pomocy dla klientów biznesowych. Problem polega na tym, że większość firm klika "Akceptuję" przy rejestracji i nigdy nie weryfikuje, czy DPA w ogóle zostało zawarte i co zawiera.

Co powinno się znaleźć w DPA z Make lub Zapier:

• Opis kategorii przetwarzanych danych: jakie typy danych osobowych trafiają do automatyzacji
• Czas przechowywania logów wykonania: jak długo historia scenariuszy jest dostępna w systemie
• Lista podprocesów: firmy, którym Make lub Zapier dalej przekazuje dane w ramach swojej infrastruktury
• Mechanizm transferu poza EOG: Standardowe Klauzule Umowne lub certyfikacja w ramach EU-US Data Privacy Framework
• Postępowanie w razie naruszenia danych: terminy i forma powiadomienia administratora o incydencie

DPA musicie mieć podpisane zanim uruchomicie pierwsze scenariusze przetwarzające dane osobowe. Nie "jak będzie więcej danych" ani "jak zaczniemy skalować". Od pierwszego Zapa z imieniem klienta w payloadzie.

Transfer danych do USA: na jakiej podstawie jest to legalne?

W 2023 roku Komisja Europejska przyjęła decyzję o adekwatności dla EU-US Data Privacy Framework (DPF). To mechanizm, który pozwala legalnie transferować dane osobowe do firm w USA, które uzyskały certyfikację DPF. Zapier jest certyfikowany w ramach DPF. Make (jako część grupy Celonis) też. OpenAI API również.

Sama certyfikacja DPF nie zastępuje DPA. Te dwa dokumenty działają razem. DPF stanowi podstawę prawną transferu z art. 45 RODO (decyzja stwierdzająca odpowiedni poziom ochrony), natomiast DPA reguluje zasady powierzenia przetwarzania po stronie dostawcy. Brak jednego z tych elementów to luka compliance, którą UODO może zakwestionować.

Alternatywnym mechanizmem są Standardowe Klauzule Umowne (SCC), zatwierdzone decyzją Komisji z 2021 roku. Część firm stosuje SCC zamiast DPF lub jako dodatkowe zabezpieczenie. Zapier w swoim DPA oferuje możliwość oparcia transferu na SCC dla klientów, którzy wolą ten mechanizm.

Jest jeden element ryzyka, o którym warto mieć świadomość: US CLOUD Act. To amerykańska ustawa umożliwiająca organom ścigania w USA żądanie dostępu do danych przechowywanych przez firmy podlegające jurysdykcji USA, niezależnie od tego, gdzie fizycznie te dane stoją. W praktyce dotyczy to przede wszystkim firm z sektora finansowego, medycznego lub powiązanych z podmiotami publicznymi. Ale to ryzyko prawne, które warto uwzględnić przy ocenie architektury automatyzacji, zwłaszcza jeśli przetwarzacie dane wrażliwe.

Kto odpowiada, gdy UODO zapyta o Wasze automatyzacje?

Administrator danych to Wasza firma. Make i Zapier to podmioty przetwarzające. Jeśli UODO wszczyna postępowanie dotyczące np. wycieku danych klienta, który przeszedł przez automatyzację, odpowiadacie Wy. Podmiot przetwarzający odpowiada tylko wtedy, gdy naruszył konkretne postanowienia DPA lub działał poza Waszymi instrukcjami.

To przekłada się na konkretne obowiązki dokumentacyjne. Rejestr Czynności Przetwarzania (RCP), który każda firma jako administrator powinna prowadzić, musi zawierać wpis o każdym narzędziu przetwarzającym dane osobowe. Typowy wpis dla Make mógłby wyglądać tak:

• Podmiot przetwarzający: Make (Celonis GmbH)
• Cel przetwarzania: automatyzacja obiegu faktur i zamówień
• Kategorie danych: imię, nazwisko, NIP, adres dostawy, dane płatnicze kontrahentów
• Lokalizacja serwerów: EU (Frankfurt, AWS eu-central-1) oraz podprocesorzy zgodnie z listą DPA
• Podstawa transferu poza EOG: DPF lub SCC zgodnie z zawartym DPA

Inspektorzy UODO przy kontroli pytają właśnie o takie szczegóły: czy DPA istnieje, czy RCP zawiera wpis, czy macie udokumentowaną listę podprocesów. Brak wpisu lub brak DPA to naruszenie art. 28 RODO, które może skutkować decyzją nakazową.

Jakie dane w automatyzacjach budzą największe wątpliwości prawne?

Nie każda automatyzacja niesie ten sam poziom ryzyka. Jeśli Make kopiuje numer zamówienia między systemami i nie przetwarza danych fizycznych osób, obciążenia compliance są minimalne. Problem zaczyna się przy:

• imionach, nazwiskach, adresach e-mail lub fizycznych klientów indywidualnych (handel B2C)
• danych pracowników: PESEL, adres zamieszkania, wynagrodzenie, zwolnienia lekarskie
• NIPach osób fizycznych prowadzących działalność, które są danymi osobowymi w rozumieniu RODO
• dokumentach kadrowych przepuszczanych przez OCR w automatyzacji, np. skanach umów o pracę
• danych z kategorii szczególnych z art. 9 RODO: dane zdrowotne, wyznanie, przynależność do związków zawodowych

Typowy przykład z polskiej firmy: automatyzacja pobiera zamówienia z platformy e-commerce, zapisuje dane kupującego (imię, adres dostawy, numer telefonu) do arkusza Google, stamtąd wysyła do CRM. W tej pętli dane przechodzą przez Make lub Zapier, Google Workspace i system CRM. Każdy z tych dostawców to oddzielny podmiot przetwarzający, z którym potrzebujecie DPA. Trzy DPA, a nie jedno.

Własny serwer zamiast chmury: kiedy to upraszcza RODO, a kiedy nie?

To nie jest artykuł o tym, że chmura jest zła. Make z centrum danych w Frankfurcie i podpisanym DPA jest legalnym sposobem przetwarzania danych. Ale są sytuacje, gdzie własna infrastruktura upraszcza compliance zamiast go komplikować.

Jeśli przetwarzacie dane wrażliwe w dużej skali, np. w branży medycznej, kadrowej lub finansowej z dziesiątkami tysięcy rekordów osób fizycznych, przepływ tych danych przez zewnętrzne serwery generuje więcej dokumentacji i więcej punktów, w których trzeba zarządzać ryzykiem. Własna instancja n8n zainstalowana na serwerze w biurze lub w polskim centrum danych wycina pytanie o transfer poza EOG całkowicie. Dane nie opuszczają infrastruktury firmy.

Podobnie z modelami językowymi. Zamiast wysyłać treść faktury lub umowy do OpenAI API (serwery USA), można uruchomić model on-premise i przetwarzać dokumenty lokalnie. U jednego z naszych klientów dział prawny postawił twarde veto wobec przesyłania jakichkolwiek umów przez zewnętrzne API. Własny serwer z lokalnym modelem dał im możliwość automatyzacji bez naruszenia tej zasady.

Własna infrastruktura to jednak realne koszty: utrzymanie, aktualizacje, odpowiedzialność za zabezpieczenie serwera. Nie jest to opcja dla każdego. Decyzja powinna wynikać z rodzaju przetwarzanych danych i skali operacji, nie z ogólnej obawy przed chmurą. Jeśli chcecie zobaczyć, jak to wygląda w praktyce u firm o podobnym profilu, zajrzyjcie do realnych wdrożeń.

Jeśli nie macie pewności, czy Wasze obecne automatyzacje są właściwie udokumentowane w RCP i czy DPA są podpisane z każdym dostawcą, warto to sprawdzić zanim zrobi to ktoś inny. Przeprowadzamy bezpłatny audyt przepływów danych, w ramach którego mapujemy, przez jakie systemy przechodzą dane Waszej firmy, identyfikujemy braki dokumentacyjne i wskazujemy, gdzie wystarczy zaktualizować dokumenty, a gdzie architektura wymaga zmiany.