Streszczenie AI
Unijne prawo dotyczące ochrony danych (RODO) i akt o sztucznej inteligencji (AI Act) tworzą zaprzyjaźnione, a jednocześnie oddzielne ramy, gdzie spełnienie wymogów jednego nie zwalnia z obowiązków drugiego. Kluczowe wyzwania w 2026‑2028 latach to harmonizacja procesu oceny ryzyka (DPIA + FRIA) oraz rozwiązanie konfliktu pomiędzy zasadą minimalizacji danych a wymogiem ciągłego logowania systemów wysokiego ryzyka, co wymaga uwzględnienia kryptograficznej pseudonimizacji, segregacji środowisk i wielopoziomowych polityk retencji. Dlatego organizacje muszą wdrażać jednolity framework governance, łączący zarówno techniczne, produktowe standardy AI Act, jak i ochronę prawną danych przewidzianą przez RODO.
Spis treści:
Dwa kluczowe unijne akty prawne – Ogólne rozporządzenie o ochronie danych (RODO) oraz Akt w sprawie sztucznej inteligencji (AI Act, Rozporządzenie 2024/1689) – tworzą wzajemnie powiązane ramy prawne dla wdrażania systemów algorytmicznych przetwarzających dane osobowe. Zgodnie z art. 2 ust. 7 AI Act, unijne przepisy o ochronie danych osobowych mają charakter nadrzędny i stosowane są równolegle, co oznacza, że spełnienie wymogów AI Act nie zwalnia z obowiązków wynikających z RODO i odwrotnie. W realiach 2026 roku, w obliczu postępującej implementacji kolejnych faz AI Act oraz zmian harmonogramowych wprowadzonych przez Pakiet Cyfrowy (Digital Omnibus – Rozporządzenie UE 2026/1744), Inspektorzy Ochrony Danych (IOD/DPO) oraz zespoły compliance muszą wdrożyć zintegrowany proces zarządzania ryzykiem technologicznym i prawnym.
Gdzie zaczynają się – i gdzie kończą – oba rozporządzenia
Podstawowa różnica między RODO a AI Act wynika z przedmiotu ochrony oraz przyjętego modelu regulacyjnego. RODO chroni prawa podstawowe osób fizycznych w związku z przetwarzaniem ich danych osobowych, koncentrując się na całym cyklu życia danych: od zbierania i przygotowania zbiorów treningowych (input), przez inferencję, aż po retencję i usuwanie danych. Z kolei AI Act opiera się na podejściu ukierunkowanym na bezpieczeństwo produktu i zarządzanie ryzykiem całego systemu AI, skupiając się w szczególności na skutkach działania modeli algorytmicznych (output), zapobieganiu dyskryminacji oraz ochronie zdrowia, bezpieczeństwa i praw podstawowych.
Wdrożenie systemu AI przetwarzającego dane osobowe w Unii Europejskiej oznacza bezwzględny wymóg jednoczesnego spełnienia obu reżimów. Kluczowe punkty styku i potencjalnych napięć koncentrują się wokół czterech filarów:
- Praworządność i podstawa prawna: Konieczność wykazania ważnej podstawy przetwarzania danych (art. 6 i art. 9 RODO) na każdym etapie – treningu, dostrajania (fine-tuning), testowania oraz działania produkcyjnego systemu AI.
- Zarządzanie jakością danych i wykrywanie stronniczości: AI Act (art. 10 ust. 5) wyjątkowo zezwala na przetwarzanie szczególnych kategorii danych osobowych (danych wrażliwych) w celu wykrywania i korygowania stronniczości algorytmicznej (bias), pod warunkiem wdrożenia rygorystycznych zabezpieczeń technicznych (m.in. pseudonimizacji i szyfrowania), co stanowi precyzyjne uzupełnienie mechanizmów z art. 9 RODO.
- Prawa jednostki a zautomatyzowane decyzje: Koordynacja praw osób, których dane dotyczą (art. 15–22 RODO, w tym zakaz w pełni zautomatyzowanego podejmowania decyzji wywołujących skutki prawne) z wymogami nadzoru ludzkiego (art. 14 AI Act) oraz prawem do wyjaśnienia decyzji zindywidualizowanych podejmowanych przez systemy wysokiego ryzyka (art. 86 AI Act).
- Harmonogram i fazy stosowania: Podczas gdy zakazy dotyczące niedozwolonych praktyk AI (art. 5) oraz wymogi przejrzystości (art. 50) i reguły dla modeli GPAI weszły już do pełnego stosowania, znowelizowany harmonogram wynikający z Rozporządzenia 2026/1744 wyznacza termin bezpośredniego stosowania obowiązków dla samodzielnych systemów wysokiego ryzyka z Załącznika III na 2 grudnia 2027 r., a dla systemów wbudowanych w produkty regulowane (Załącznik I) na 2 sierpnia 2028 r.
Ocena ryzyka: DPIA kontra FRIA – czy można połączyć?
Jednym z najczęstszych wyzwań operacyjnych dla DPO jest relacja pomiędzy oceną skutków dla ochrony danych (DPIA – Data Protection Impact Assessment) z art. 35 RODO a oceną wpływu na prawa podstawowe (FRIA – Fundamental Rights Impact Assessment) wprowadzoną w art. 27 AI Act.
Obowiązek przeprowadzenia FRIA dotyczy podmiotów wdrażających (deployers), które są organami publicznymi lub podmiotami prywatnymi świadczącymi usługi publiczne, a także podmiotów komercyjnych wdrażających systemy wysokiego ryzyka z Załącznika III w obszarach oceny zdolności kredytowej osób fizycznych (pkt 5 lit. b) oraz wyceny ryzyka i taryfikacji w ubezpieczeniach na życie i zdrowotnych (pkt 5 lit. c).
Prawodawca unijny bezpośrednio przewidział integrację obu procesów. Zgodnie z art. 27 ust. 4 AI Act, jeżeli którykolwiek z elementów wymaganych w ramach oceny praw podstawowych został już zrealizowany podczas przeprowadzania DPIA na podstawie art. 35 RODO, ocena FRIA stanowi uzupełnienie (komplementarne rozszerzenie) wcześniej sporządzonego DPIA. Oznacza to brak konieczności dublowania analiz technicznych.
Kryterium | DPIA (art. 35 RODO) | FRIA (art. 27 AI Act) |
|---|---|---|
| Podstawa prawna | Art. 35 ust. 1 RODO | Art. 27 ust. 1 AI Act |
| Adresaci obowiązku | Wszyscy administratorzy danych (publiczni i prywatni) | Podmioty publiczne, podmioty świadczące usługi publiczne oraz deployerzy AI w scoringu kredytowym i ubezpieczeniach |
| Moment przeprowadzenia | Przed rozpoczęciem operacji przetwarzania danych | Przed pierwszym wdrożeniem / użyciem systemu wysokiego ryzyka |
| Przedmiot i cel oceny | Ocena konieczności, proporcjonalności i ryzyka naruszenia praw i wolności w związku z przetwarzaniem danych | Ocena wpływu działania całego systemu na prawa podstawowe (równość, zakaz dyskryminacji, godność, środowisko) |
| Elementy składowe | Opis procesów, podstawy prawne, środki techniczne, bezpieczeństwo, analiza ryzyka prywatności | Identyfikacja kategorii osób narażonych, analiza ryzyka systemowego, plan nadzoru ludzkiego, środki naprawcze |
| Zasada komplementarności | Fundament bazowy dla analizy technicznej | Uzupełnia DPIA zgodnie z art. 27 ust. 4 AI Act – brak dublowania tożsamych sekcji |
Kluczowy konflikt: minimalizacja danych vs. obowiązek logowania
Najpoważniejsze napięcie inżynieryjno-prawne między oboma rozporządzeniami występuje na styku zasady minimalizacji danych i ograniczenia przechowywania (art. 5 ust. 1 lit. c i e RODO) oraz obowiązku automatycznego rejestrowania zdarzeń (logowania) nałożonego przez art. 12 i art. 19 AI Act.
Systemy AI wysokiego ryzyka muszą w sposób ciągły rejestrować operacje, aby umożliwić monitorowanie po wprowadzeniu do obrotu, audytowalność i identyfikację anomalii w całym cyklu życia rozwiązania. Logi te z reguły zawierają pełne dane wejściowe (input prompts, wektory cech biometrycznych, historie zapytań), identyfikatory użytkowników oraz wygenerowane decyzje. Bezpośrednie gromadzenie tych danych w postaci jawnej przez długi czas rodzi ryzyko naruszenia art. 5 RODO.
Aby pogodzić te sprzeczne wektory regulacyjne, zespoły architektoniczne i IOD powinny wdrożyć czterostopniowy mechanizm zabezpieczeń:
- Rozdzielenie środowisk i kryptograficzna pseudonimizacja: Identyfikatory osób fizycznych w logach operacyjnych AI Act powinny być zastępowane dynamicznymi tokenami lub skrótami kryptograficznymi (z kluczem trzymanym w odseparowanym module HSM). Identyfikacja wsteczna jest dopuszczalna wyłącznie na potrzeby oficjalnego incydentu bezpieczeństwa lub audytu nadzorczego.
- Wielopoziomowa polityka retencji danych: Zdefiniowanie odrębnych okresów przechowywania dla danych transakcyjnych (usuwanych zgodnie z RODO niezwłocznie po zrealizowaniu celu) oraz zanonimizowanych metadanych telemetrycznych i zdarzeń systemowych utrzymywanych zgodnie z art. 19 AI Act przez minimalny wymagany prawem okres (standardowo minimum 6 miesięcy dla podmiotów wdrażających).
- RBAC i audytowalny dostęp do rejestrów: Ograniczenie dostępu do pełnych logów zawierających dane osobowe wyłącznie do wyznaczonych ról nadzoru technicznego i audytu, z rejestracją każdego odczytu w niezmiennym dzienniku zdarzeń (immutable audit trail).
- Anonimizacja i agregacja wskaźników jakości: Wszędzie tam, gdzie logowanie służy do pomiaru driftu modelu (model drift) lub wskaźników dokładności algorytmu, dane telemetryczne należy agregować i przekształcać w formę uniemożliwiającą powiązanie z konkretną osobą.
Praktyczna tabela zgodności dla DPO
Zestawienie porównawcze identyfikuje kluczowe obszary nakładania się obowiązków, definiuje poziom ryzyka kolizji oraz wskazuje bezpośrednie rekomendacje wdrożeniowe dla zespołów ochrony danych i cyberbezpieczeństwa.
Obszar | Wymóg RODO | Wymóg AI Act | Ryzyko kolizji | Rekomendacja dla DPO / Compliance |
|---|---|---|---|---|
| Ocena ryzyka | DPIA (art. 35) | FRIA (art. 27) | Niskie – komplementarność | Stworzyć modułową ocenę ryzyka: część bazowa DPIA uzupełniona o aneks FRIA (zgodnie z art. 27 ust. 4 AI Act). |
| Przejrzystość | Obowiązek informacyjny (art. 13 i 14) oraz art. 22 ust. 3 | Przejrzystość systemów AI (art. 13 i art. 50) | Niskie – spójne cele | Zintegrować klauzule informacyjne: opisać logikę modelu AI, zakres danych wejściowych i cel inferencji w jednej warstwowej notatce. |
| Retencja danych i logowanie | Zasada ograniczenia przechowywania (art. 5 ust. 1 lit. e) | Obowiązek automatycznego logowania zdarzeń (art. 12 i 19) | Wysokie – konflikt celów | Wdrożyć pseudonimizację logów, separację uprawnień i odrębne podstawy przetwarzania (prawny obowiązek z art. 6 ust. 1 lit. c RODO). |
| Jakość danych i minimalizacja | Minimalizacja danych (art. 5 ust. 1 lit. c) | Reprezentatywność i kompletność zbiorów (art. 10) | Wysokie – napięcie strukturalne | Stosować dane syntetyczne lub zanonimizowane do testów; przetwarzać dane wrażliwe do testów stronniczości ściśle wg art. 10 ust. 5 AI Act. |
| Rozliczalność i role stron | Administrator (ADO) vs Podmiot przetwarzający (art. 4 pkt 7 i 8) | Dostawca (Provider) vs Podmiot wdrażający (Deployer) (art. 3) | Średnie – dywergencja ról | Przeprowadzić mapowanie ról: zweryfikować, czy deployer jest administratorem danych; zaktualizować umowy DPA oraz SLA z dostawcami AI. |
| Prawa jednostki i usuwanie danych | Prawo do usunięcia danych (art. 17) i sprzeciwu (art. 21) | Wymóg odporności i integralności modeli (art. 15) | Średnie – trudności techniczne (machine unlearning) | Zapewnić procedury usuwania danych z baz RAG i cache; w przypadku wag modeli stosować procedury retrainingu lub techniki unlearningu. |
| Dane biometryczne | Zakaz przetwarzania z wyjątkami (art. 9) | Zakaz biometrii w czasie rzeczywistym i kategoryzacji emocji (art. 5) | Niskie – zbieżność restrykcji | Przyjąć zasadę prymatu najsurowszego zakazu; zweryfikować czy system nie podpada pod zakazane praktyki z art. 5 AI Act. |
| Rejestry i dokumentacja | Rejestr czynności przetwarzania – RCP (art. 30) | Dokumentacja techniczna (art. 11) i rejestracja w bazie UE (art. 49/71) | Niskie – synergia dokumentacyjna | Rozszerzyć strukturę RCP o atrybuty AI (klasyfikacja ryzyka, nazwa modelu, wersja wag, rola w AI Act). |
Jak organizacja powinna podejść do podwójnej zgodności
Skuteczne zarządzanie zgodnością w organizacji wymaga wdrożenia ujednoliconego frameworku Governance łączącego wymogi prawne z architekturą IT. Podejście to opiera się na trzech krokach operacyjnych:
- 01Inwentaryzacja i podwójna klasyfikacja systemów: Każde narzędzie algorytmiczne w organizacji musi zostać poddane równoległej ocenie: pod kątem RODO (charakter, zakres i podstawa przetwarzania danych) oraz pod kątem AI Act (kwalifikacja do kategorii zakazanej, wysokiego ryzyka z Załącznika III, podlegającej wymogom przejrzystości z art. 50 czy ogólnego przeznaczenia – GPAI).
- 02Aktualizacja dokumentacji kontraktowej i governance: Precyzyjne rozgraniczenie ról w łańcuchu dostaw AI. Dostawca zewnętrznego modelu SaaS jest z perspektywy AI Act dostawcą (providerem), a organizacja integrująca go we własnych procesach staje się podmiotem wdrażającym (deployerem). W relacjach tych niezbędne jest skorelowanie postanowień umowy powierzenia przetwarzania danych (DPA) z gwarancjami technicznymi wymaganymi przez AI Act (dostęp do logów, metadane treningowe, zgłaszanie incydentów).
- 03Wdrożenie połączonych procedur DPIA / FRIA: Wykorzystanie istniejących procesów ochrony prywatności (Privacy by Design) jako fundamentu pod audyty algorytmiczne. Organizacja powinna rozszerzyć standardowy formularz DPIA o sekcje badające ryzyko halucynacji, podatności na ataki adversarialne, stronniczości statystycznej oraz procedury nadzoru człowieka (Human-in-the-loop).
Zgodność z RODO i AI Act nie stanowi dwóch rozłącznych projektów audytowych. AI Act nakłada ramy techniczne i produktowe na systemy, podczas gdy RODO strzeże integralności danych i praw człowieka w procesie ich wykorzystania. Synergia obu regulacji pozwala na zbudowanie trwałego, rozliczalnego ekosystemu sztucznej inteligencji w organizacji.
