Dwa unijne rozporządzenia – RODO (od 2018 r.) i AI Act (formalnie obowiązujący od 2024 r.) – tworzą dziś nakładające się ramy prawne dla każdej organizacji, która wdraża systemy sztucznej inteligencji przetwarzające dane osobowe. Art. 2 ust. 7 AI Act expressis verbis potwierdza, że oba reżimy stosuje się równolegle i wzajemnie się uzupełniają. Dla IOD (DPO) oznacza to konkretne obowiązki w zakresie podwójnej zgodności, ale też możliwości optymalizacji procesów.
Gdzie zaczynają się – i gdzie kończą – oba rozporządzenia
RODO obejmuje ochronę danych osobowych na każdym etapie ich przetwarzania – od zebrania (input), przez szkolenie modelu, aż po użycie systemu produkcyjnego. AI Act natomiast koncentruje się przede wszystkim na skutkach działania systemu AI (output) i dotyczy głównie systemów zakazanych oraz systemów wysokiego ryzyka. To różnica zasadnicza: RODO chroni dane osobowe jako takie, AI Act zarządza ryzykiem związanym z decyzjami algorytmicznymi.
Jeśli system AI przetwarza dane osobowe użytkowników w UE, organizacja podlega jednocześnie obu rozporządzeniom – bez możliwości wyboru jednego z nich. Zakresy te nakładają się szczególnie mocno w obszarach: przejrzystości, rozliczalności, prawidłowości danych oraz oceny ryzyka.
Ocena ryzyka: DPIA kontra FRIA – czy można połączyć?
RODO wymaga przeprowadzenia oceny skutków dla ochrony danych (DPIA) wszędzie tam, gdzie przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób fizycznych. AI Act wprowadza natomiast własne narzędzie – ocenę wpływu na prawa podstawowe (FRIA, Fundamental Rights Impact Assessment), wymaganą dla systemów wysokiego ryzyka, np. stosowanych w rekrutacji, dostępie do usług finansowych czy edukacji.
Różnica jest istotna i dotyczy perspektywy analizy:
- DPIA analizuje proces przetwarzania danych osobowych – cele, podstawy prawne, ryzyka prywatności, środki zaradcze.
- FRIA analizuje działanie systemu AI jako całości, w tym możliwość dyskryminacji, wpływ algorytmu na decyzje dotyczące ludzi i skutki społeczne.
- EDPS (Europejski Inspektor Ochrony Danych) konsekwentnie rozróżnia te dwie perspektywy: ryzyko wynikające z ochrony danych oraz ryzyko wynikające z zastosowania systemu AI.
Mimo tych różnic wiele elementów obu analiz pokrywa się. W praktyce zaleca się zintegrowane podejście: dane zebrane na etapie DPIA (opis operacji przetwarzania, identyfikacja zagrożeń, środki ograniczające ryzyko) mogą i powinny być bezpośrednio wykorzystane przy sporządzaniu FRIA. Firmy, które wcześniej wdrożyły dobre praktyki RODO – rejestry czynności, zasady privacy by design – mogą je względnie łatwo rozszerzyć na obszar AI Act, co znacząco obniża koszty i czas dostosowania.
| Kryterium | DPIA (RODO) | FRIA (AI Act) |
|---|---|---|
| Podstawa prawna | Art. 35 RODO | Art. 27 AI Act |
| Kiedy wymagana | Wysokie ryzyko dla prywatności | Systemy AI wysokiego ryzyka (zał. III) |
| Perspektywa | Dane osobowe i ich przetwarzanie | Działanie algorytmu i jego skutki społeczne |
| Zakres oceny ryzyka | Naruszenie prywatności, bezpieczeństwo danych | Dyskryminacja, prawa obywatelskie, decyzje zautomatyzowane |
| Możliwość integracji | Tak – elementy pokrywające się można dokumentować wspólnie | |
Kluczowy konflikt: minimalizacja danych vs. obowiązek logowania
Najpoważniejsze napięcie między oboma rozporządzeniami dotyczy zasady minimalizacji danych z RODO i obowiązku rejestrowania zdarzeń z AI Act. RODO w art. 5 ust. 1 lit. c) wymaga, żeby przetwarzane dane osobowe były adekwatne, istotne i ograniczone do tego, co niezbędne dla osiągnięcia celu przetwarzania. AI Act w art. 12 nakłada natomiast na systemy wysokiego ryzyka obowiązek automatycznego rejestrowania zdarzeń przez cały cykl życia systemu – w tym danych wejściowych, wyników decyzji i momentów, w których system mógł działać nieprawidłowo.
W praktyce rejestry systemów AI (logi) mogą zawierać dane osobowe: identyfikatory użytkowników, dane biometryczne, oceny kredytowe, wyniki rekrutacyjne. Przechowywanie tych danych przez długi czas jest wymagane przez AI Act dla celów monitoringu i audytu, ale jednocześnie stoi w bezpośredniej sprzeczności z zasadą ograniczenia przechowywania z RODO (art. 5 ust. 1 lit. e). Podobnie RODO wymaga minimalizacji danych w systemach AI analizujących kredyty czy zachowania użytkowników, podczas gdy AI Act wymaga dla takich systemów szczegółowych danych historycznych niezbędnych do prawidłowego nadzoru.
Nie ma tu jednego gotowego rozwiązania, ale istnieją narzędzia ograniczające konflikt:
- Pseudonimizacja logów – identyfikatory osobowe w rejestrach zastępuje się pseudonimami; pełna re-identyfikacja możliwa tylko w ściśle określonych przypadkach.
- Ograniczona retencja – ustalenie najkrótszego możliwego okresu przechowywania logów, który jednocześnie spełnia wymogi monitoringu AI Act.
- Kontrola dostępu do rejestrów – dostęp do logów zawierających dane osobowe ograniczony do funkcji audytu i monitoringu, z oddzielnym uzasadnieniem prawnym przetwarzania.
- Anonimizacja na poziomie agregatu – gdzie możliwe, logi przechowywać w formie zagregowanej statystycznie, nie na poziomie pojedynczych decyzji.
Praktyczna tabela zgodności dla DPO
Poniższa tabela zestawia kluczowe obowiązki z obu rozporządzeń w kontekście praktycznej pracy IOD/DPO. Kolumna „Ryzyko kolizji” wskazuje obszary, gdzie spełnienie jednego wymogu może utrudniać spełnienie drugiego.
| Obszar | Wymóg RODO | Wymóg AI Act | Ryzyko kolizji | Rekomendacja dla DPO |
|---|---|---|---|---|
| Ocena ryzyka | DPIA (art. 35) | FRIA (art. 27) | Niskie – zakresy częściowo pokrywalne | Sporządzić zintegrowany dokument DPIA+FRIA z wyraźnym rozróżnieniem sekcji |
| Przejrzystość | Obowiązek informacyjny (art. 13–14) | Obowiązek przejrzystości wobec użytkowników systemu AI (art. 13) | Niskie – zbieżne cele | Połączyć klauzule informacyjne RODO z opisem działania AI w jednym dokumencie |
| Retencja danych / logi | Ograniczenie przechowywania (art. 5 ust. 1 lit. e) | Obowiązek rejestrowania zdarzeń przez cały cykl życia (art. 12) | Wysokie – bezpośredni konflikt | Pseudonimizacja logów; ustalić minimalny okres retencji spełniający oba wymogi; osobna podstawa prawna dla logów AI |
| Minimalizacja danych | Dane adekwatne i ograniczone do celu (art. 5 ust. 1 lit. c) | Systemy wysokiego ryzyka wymagają szczegółowych danych historycznych i wejściowych | Wysokie – napięcie strukturalne | Ocenić niezbędność każdej kategorii danych przez lens AI Act; stosować anonimizację/agregację tam, gdzie AI nie wymaga danych osobowych |
| Rozliczalność | Administrator odpowiada za zgodność z RODO (art. 5 ust. 2) | Dostawca/użytkownik systemu AI odpowiada za zgodność z AI Act | Średnie – możliwa rozbieżność ról | Zweryfikować, kto jest administratorem RODO a kto dostawcą/użytkownikiem AI Act; uregulować w umowach przetwarzania |
| Prawo do sprzeciwu/usunięcia | Prawo do usunięcia danych (art. 17), sprzeciw wobec profilowania (art. 21–22) | Brak bezpośredniego odpowiednika, ale wymóg nadzoru ludzkiego (art. 14) | Średnie – usunięcie danych może kolidować z integralnością modelu AI | Wdrożyć procedury usuwania danych z rejestrów i zbiorów treningowych; udokumentować wpływ na model |
| Dane biometryczne | Dane szczególnej kategorii (art. 9); domyślny zakaz przetwarzania | Dodatkowe zakazy identyfikacji biometrycznej w czasie rzeczywistym w przestrzeni publicznej (art. 5) | Niskie – AI Act rozszerza ochronę RODO | Stosować surowszy reżim; zbieg sankcji z art. 83 RODO i art. 99 AI Act jest możliwy |
| Dokumentacja i rejestry | Rejestr czynności przetwarzania (art. 30) | Dokumentacja techniczna systemu AI (art. 11); rejestr systemów AI wysokiego ryzyka (art. 71) | Niskie – możliwa integracja dokumentów | Uzupełnić rejestr czynności przetwarzania o sekcję AI; powiązać z dokumentacją techniczną AI Act |
Jak organizacja powinna podejść do podwójnej zgodności
Praktyczne wdrożenie wymaga sekwencyjnego podejścia: w pierwszej kolejności organizacja powinna spełnić wymagania RODO na etapie gromadzenia danych, a następnie połączyć przepisy obu rozporządzeń na etapie przetwarzania danych przez algorytm i zarządzania wynikami. Kluczowym krokiem jest identyfikacja każdego systemu AI, który przetwarza dane osobowe – taki system automatycznie podlega procedurze RODO niezależnie od klasyfikacji ryzyka AI Act.
Dla DPO szczególnie istotne jest uregulowanie ról i odpowiedzialności. RODO posługuje się pojęciami administratora i podmiotu przetwarzającego, natomiast AI Act wprowadza kategorie dostawcy (provider) i użytkownika (deployer) systemu AI. Role te nie zawsze pokrywają się w jednej organizacji – dostawca systemu AI może nie być administratorem danych w rozumieniu RODO, co wymaga precyzyjnego uregulowania w umowach. Organizacje, które wdrożyły już dojrzałe procesy compliance RODO, są w zdecydowanie lepszej pozycji startowej: ich rejestry czynności, procedury DPIA i mechanizmy privacy by design stanowią gotowy fundament do rozszerzenia na wymogi AI Act.
Obie regulacje nie wykluczają się wzajemnie – działają komplementarnie. Część obowiązków ulega zdublowaniu, ale nie zwalnia to z ich realizacji w ramach obu reżimów. Nic nie stoi jednak na przeszkodzie, aby informacje pozyskane na etapie oceny ryzyka RODO wykorzystać na potrzeby dokumentacji AI Act.
Źródła
- Wolters Kluwer – RODO i AI – razem czy osobno?
- Lawgo – DPIA a AI Act. Czy analiza ryzyka z RODO wystarczy dla systemów AI?
- AfterLegal – RODO i AI Act – jak łączyć te dwa akty prawne?
- PBSG – RODO i AI Act: Jak połączyć przepisy w spójną strategię zgodności?
- Doradcy365 – AI Act a RODO – jak zgodnie z przepisami korzystać z AI w firmie?
- AI Act Service Desk – Artykuł 12: Rejestrowanie zdarzeń
- Lawspective – AI Act a ochrona danych osobowych: jak unikać konfliktów z RODO?
- Traple – Wzajemna relacja RODO i Aktu w sprawie sztucznej inteligencji
- RPMS – RODO i AI Act. Jak stosować razem te akty prawne?
- ODO Serwis – Jak zapewnić zgodność z RODO? EIOD przedstawia wytyczne zarządzania ryzykiem dla systemów AI
- AI Act Hub – Dane biometryczne – istotne różnice między AI Act a RODO
