Czym są te wytyczne i czym nie są

EDPB nie wynalazł nowego narzędzia. Opublikował projekt rewizji wcześniejszych wytycznych WP29 dotyczących DPIA - rozszerzony o oficjalny szablon, który dotychczas nie istniał jako ustandaryzowany dokument unijny. Cel deklarowany w dokumencie: ułatwienie organizacjom przeprowadzenia DPIA w sposób zgodny z art. 35 RODO. Cel faktyczny - widoczny w strukturze wytycznych - jest głębszy: wskazanie, że DPIA bez solidnego baseline'u z art. 32 jest oceną połowiczną.

14.04 data publikacji projektu wytycznych EDPB
9.06 deadline uwag do konsultacji publicznych 2026
1998 rok ISO/IEC TR 13335-3 - mechanizm baseline-eskalacja po raz pierwszy sformalizowany

Szablon to narzędzie. Mechanizm to architektura. Polska kancelaria, która wdroży szablon bez zrozumienia mechanizmu, wypełni poprawny dokument i popełni ten sam błąd co wcześniej - tylko schludniej.

Historia mechanizmu - 1998, nie 2018

ISO/IEC TR 13335-3:1998 - "Guidelines for the Management of IT Security, Part 3: Techniques for the management of IT security" - to techniczny raport ISO z 1998 roku, poprzednik dzisiejszego ISO 27005. Dokument opisał dwupoziomowy model oceny ryzyka w zarządzaniu bezpieczeństwem informacji jako strukturę operacyjną dla organizacji. Nie jako akademicką propozycję - jako narzędzie pracy specjalistów bezpieczeństwa.

1998

ISO/IEC TR 13335-3 - dwa poziomy oceny ryzyka

Ocena ogólna (baseline) daje przekrojowy obraz ryzyka dla całej organizacji. Jeśli baseline wykaże wysokie ryzyko - obowiązek przejścia do oceny szczegółowej (detailed). Nie opcja, nie rekomendacja - mechanizm eskalacji wbudowany w strukturę procesu.

2011

ISO/IEC 27005 - mechanizm sformalizowany w rodzinie 27000

ISO 27005 przejął logikę TR 13335-3 i wbudował ją w standard zarządzania ryzykiem bezpieczeństwa informacji. Baseline risk assessment jako wstęp do detailed risk assessment dla obszarów wysokiego ryzyka. Mechanizm stał się częścią globalnego standardu auditów bezpieczeństwa.

2018

RODO art. 32 i art. 35 - mechanizm przepisany na język prawa UE

Art. 32 RODO to ocena ogólna - środki techniczno-organizacyjne adekwatne do ryzyka. Art. 35 RODO (DPIA) to eskalacja - obowiązkowa dla operacji "mogących powodować wysokie ryzyko". Oba artykuły w tym samym rozdziale RODO. Ten sam mechanizm, bez przypisu do TR 13335.

2024

AI Act art. 9 - trzeci poziom tej samej piramidy

Art. 9 AI Act nakłada na dostawców systemów AI obowiązek ciągłego systemu zarządzania ryzykiem (baseline). Art. 6 + Annex III wyznaczają systemy wysokiego ryzyka (eskalacja do oceny zgodności). Dla wybranych kategorii - external audit przez jednostkę notyfikowaną. Ten sam wzorzec eskalacji, trzecia regulacja.

Art. 32 i art. 35 - jeden proces, nie dwa checkboxy

Art. 32 RODO to baseline całej organizacji. Administratorzy danych oceniają ryzyko dla praw i wolności osób fizycznych - ogólnie, dla wszystkich operacji przetwarzania - i dobierają środki techniczne i organizacyjne adekwatne do tego ryzyka. To jest fundament.

Art. 35 RODO (DPIA) to eskalacja. Wyzwalacz jest precyzyjny: operacja przetwarzania, która "może powodować wysokie ryzyko" - czyli gdy ocena z art. 32 wskazuje wysokie ryzyko dla konkretnej operacji. DPIA nie jest projektem równoległym do art. 32. Jest jego kontynuacją dla przypadków wysokiego ryzyka.

Wytyczne EDPB z 2026 roku - podobnie jak wcześniejsze wytyczne WP29 - przypominają tę logikę. Nowy szablon nie zmienia mechanizmu: zmienia jedynie narzędzie jego dokumentowania. Organizacja, która nie ma solidnego procesu art. 32 pod spodem, nie poprawi swojego compliance przez wypełnienie szablonu DPIA.

Konsekwencja dla kancelarii

Kancelaria, która zamawia DPIA u zewnętrznego doradcy bez wcześniejszej oceny art. 32 wewnątrz organizacji, robi eskalację bez baseline'u. Wynik: poprawny dokument, błędna kolejność działań, niezmienione ryzyko rzeczywiste.

Trzyfilarowy filtr MateMatic

✓ Co bierzemy

Szablon jako punkt wyjścia do ustrukturyzowania procesu art. 32 - dla kancelarii, która nie ma jeszcze formalnego rejestru czynności przetwarzania, struktura szablonu DPIA jest dobrym punktem wyjścia do zrozumienia co RODO wymaga w warstwie oceny ryzyka. Logika eskalacji - wytyczne potwierdzają że art. 32 i art. 35 to jeden proces w dwóch aktach. Dla kancelarii wdrażającej AI Act: ten sam argument stosuje się do art. 9 i art. 6/Annex III. Konsultacje do 9 czerwca 2026 - to aktywne okno, w którym kancelarie mogą zgłaszać uwagi przez swoje izby (KIRP, NRA) lub bezpośrednio do EDPB.

⚠ Co wymaga kontekstu

Dokument jest projektem do konsultacji - wersja finalna może się różnić. Kancelaria wdrażająca szablon przed 9 czerwca 2026 powinna traktować go jako roboczy, nie normatywny. Szablon to narzędzie dla jednej operacji przetwarzania - nie zastępuje rejestru czynności przetwarzania (art. 30 RODO) ani ogólnej polityki zarządzania ryzykiem (art. 32). Polska kancelaria, która nie ma ani rejestru art. 30 ani polityki art. 32, powinna zacząć od tych fundamentów - nie od szablonu DPIA.

✕ Czego nie endorsujemy

Traktowania szablonu DPIA jako produktu compliance do odhaczenia - DPIA bez procesu art. 32 pod spodem to dokument bez wartości operacyjnej. Jeśli kancelaria lub doradca oferuje "wdrożenie DPIA" bez audytu art. 32, to jest to sprzedaż dokumentu, nie wdrożenie mechanizmu. Pominięcia warstwy AI Act - kancelarie wdrażające systemy AI dla klientów (narzędzia do analizy dokumentów, systemy oceny ryzyka, automatyzacja pism) są deployers pod AI Act. Art. 9 AI Act nakłada obowiązki analogiczne do art. 32 RODO - ignorowanie tej warstwy w ocenie ryzyka jest błędem metodologicznym.

Mapping na instrumenty polskie

RODO art. 32 i art. 35 - dla kancelarii jako administratora

Polska kancelaria prawna jest administratorem danych klientów. Art. 32 wymaga oceny ryzyka i doboru środków adekwatnych do ryzyka - dla każdej operacji przetwarzania, w tym dla narzędzi AI używanych w pracy z aktami klientów. Art. 35 wchodzi gdy operacja "może powodować wysokie ryzyko" - np. systematyczna analiza danych wrażliwych klientów przez zewnętrzny system AI, profilowanie klientów na potrzeby marketingu usług, lub systemy podejmowania decyzji z istotnym skutkiem dla klienta. Kancelaria używająca zewnętrznych narzędzi AI do analizy akt klientów bez oceny art. 32 i bez weryfikacji wyzwalacza art. 35 działa poza ramami RODO - niezależnie od posiadania klauzul w umowach z klientami.

AI Act art. 9 - dla kancelarii jako deployera systemów AI

Kancelaria wdrażająca system AI do obsługi spraw klientów jest deployer w rozumieniu AI Act. Art. 9 nakłada na dostawców (providers) obowiązek systemu zarządzania ryzykiem przez cały cykl życia systemu - ale deployer dziedziczy część tych obowiązków przez art. 26. Mechanizm jest analogiczny do art. 32/35 RODO: ocena ryzyka systemu AI (baseline) plus eskalacja do formalnej oceny zgodności dla systemów z Annex III. Kancelaria obsługująca klientów z sektorów wymienionych w Annex III (wymiar sprawiedliwości, egzekwowanie prawa, zarządzanie migracją) musi sprawdzić czy narzędzia AI klienta - lub jej własne - trafiają na listę wysokiego ryzyka.

NIS2 / KSC - dla kancelarii obsługującej podmioty kluczowe

Polska ustawa KSC (nowelizacja podpisana 19 lutego 2026, wejście w życie 3 kwietnia 2026) rozszerza obowiązki cyberbezpieczeństwa na 18 sektorów. Kancelarie obsługujące podmioty z tych sektorów mogą dziedziczyć część obowiązków jako podmioty trzecie w łańcuchu dostawców. Mechanizm baseline-eskalacja z RODO art. 32/35 oraz AI Act art. 9 daje gotową strukturę do analizy ryzyka bezpieczeństwa informacji wymaganej przez NIS2 - bez reinwencji koła dla każdej regulacji osobno.

Powiązane materiały MateMatic