Jak przeprowadzić ocenę skutków dla praw podstawowych (FRIA) na podstawie unijnego AI Act

Kto faktycznie musi zrobić FRIA

To pierwsze pytanie do rozstrzygnięcia, bo zakres jest węższy, niż sugerowałoby ogólne pokrycie AI Act. Artykuł 27(1) ogranicza obowiązek FRIA do trzech grup deployerów systemów AI wysokiego ryzyka, o których mowa w Artykule 6(2):

• Deployerzy będący podmiotami prawa publicznego. Administracje publiczne, agencje i podobne podmioty publiczne.
• Deployerzy będący prywatnymi podmiotami świadczącymi usługi publiczne. Prywatna firma prowadząca usługę skierowaną do społeczeństwa, taką jak opieka zdrowotna, edukacja, budownictwo socjalne czy usługi kluczowe, może się tu znaleźć.
• Każdy deployer, publiczny albo prywatny, który używa systemu AI wysokiego ryzyka do oceny zdolności kredytowej lub scoringu kredytowego (Załącznik III, punkt 5(b)), albo do oceny ryzyka i wyceny w związku z ubezpieczeniami na życie i zdrowie (Załącznik III, punkt 5(c)).

Jest wyraźny wyjątek. Obowiązek FRIA nie dotyczy systemów wysokiego ryzyka używanych w obszarze wymienionym w punkcie 2 Załącznika III, który obejmuje infrastrukturę krytyczną. Podmiot publiczny wdrażający system AI wysokiego ryzyka do zarządzania infrastrukturą krytyczną jest więc objęty wieloma obowiązkami z AI Act, ale nie konkretnie Artykułem 27.

Z tego zakresu wynika kilka praktycznych konsekwencji.

Prywatna firma używająca AI do wewnętrznej produktywności, tworzenia treści, podsumowań czy kodowania nie ma obowiązku FRIA. Takie zastosowania w ogóle nie są wysokiego ryzyka na podstawie Załącznika III, a nawet tam, gdzie zastosowanie jest wysokiego ryzyka, obowiązek FRIA dotyczy tylko kategorii wymienionych powyżej.

Bank albo ubezpieczyciel to najbardziej oczywisty przypadek FRIA w sektorze prywatnym. Scoring kredytowy i wycena ubezpieczeń na życie lub zdrowie są wymienione wprost. Jeśli twoja organizacja prowadzi AI w którejkolwiek z tych funkcji, planuj FRIA niezależnie od tego, czy jesteś podmiotem publicznym, czy prywatnym.

Bycie poza zakresem FRIA nie oznacza bycia poza zakresem reszty aktu. Deployer każdego systemu wysokiego ryzyka wciąż ma obowiązki deployera z Artykułu 26: używanie systemu zgodnie z instrukcjami providera, zapewnienie nadzoru ludzkiego, prowadzenie logów, monitorowanie działania i informowanie osób, na które wpływa. FRIA to jedna konkretna ocena nałożona na te obowiązki dla grup wymienionych powyżej.

Sześć elementów, jakie musi zawierać FRIA na podstawie Artykułu 27

Artykuł 27(1) określa dokładnie, co ocena musi opisywać. Nie ma opcjonalnej dziewiątej sekcji do wymyślenia: te sześć elementów to cała treść. Traktuj je jako szkielet dokumentu.

(a) Procesy, w których system będzie używany. Opis własnych procesów deployera, w których system AI wysokiego ryzyka będzie używany, zgodnie z jego przeznaczeniem. To dotyczy twojego przepływu pracy, nie marketingu dostawcy. Gdzie system znajduje się w łańcuchu decyzyjnym, co zasila i co zależy od jego wyniku.

(b) Okres i częstotliwość użycia. Opis okresu, w którym, oraz częstotliwości, z jaką, każdy system wysokiego ryzyka ma być używany. Jednorazowy pilotaż i stale działający system produkcyjny niosą inną ekspozycję, a ocena powinna wskazać, który z nich prowadzisz.

(c) Kategorie osób, na które wpływa. Kategorie osób fizycznych i grup osób, na które użycie systemu prawdopodobnie wpłynie w danym kontekście. Nazwij populacje: wnioskodawcy, klienci, pacjenci, studenci, osoby zgłaszające roszczenia. Zwróć uwagę na grupy wrażliwe, bo skoncentrowany wpływ na nie zmienia obraz ryzyka.

(d) Konkretne ryzyka szkody. Konkretne ryzyka szkody, które prawdopodobnie dotkną kategorie osób zidentyfikowane w punkcie (c), z uwzględnieniem informacji, jakie provider dostarcza na podstawie Artykułu 13. To analityczny rdzeń oceny. Instrukcje użytkowania i dokumentacja providera są tu materiałem wejściowym, a nie czymś dodanym na końcu, więc musisz mieć je w ręku, zanim uzupełnisz ten element.

(e) Środki nadzoru ludzkiego. Opis tego, jak zostanie wdrożony nadzór ludzki, zgodnie z instrukcjami użytkowania providera. Kto przegląda wyniki, kto może unieważnić działanie systemu albo je zatrzymać oraz czy te osoby mają kompetencje, uprawnienia i czas, by robić to realnie.

(f) Środki na wypadek zmaterializowania się ryzyka. Środki do podjęcia, jeśli zidentyfikowane ryzyka faktycznie wystąpią, w tym wewnętrzne mechanizmy zarządzania i mechanizmy skargowe. To plan reakcji: eskalacja, naprawa i ścieżka, którą dotknięte osoby mogą złożyć skargę.

Artykuł 27(2) dodaje dwie zasady dotyczące terminów. Obowiązek dotyczy pierwszego użycia systemu, a deployer może, w podobnych przypadkach, oprzeć się na wcześniej przeprowadzonej FRIA albo na istniejącej ocenie wykonanej przez providera. Jeśli jakikolwiek element później się zmieni albo się zdezaktualizuje w trakcie użytkowania, deployer musi zaktualizować informacje.

Powiadomienie organu i szablon, którego jeszcze nie ma

FRIA nie jest czysto wewnętrznym dokumentem. Na podstawie Artykułu 27(3), po wykonaniu oceny deployer musi powiadomić organ nadzoru rynku o wynikach, przekazując wypełniony szablon jako część powiadomienia. Jest wąski wyjątek: w przypadku, o którym mowa w Artykule 46(1), czyli odstępstwie od procedury oceny zgodności, deployerzy mogą być zwolnieni z obowiązku powiadomienia.

Sam szablon ma pochodzić z centrali. Artykuł 27(5) nakłada na AI Office zadanie opracowania szablonu kwestionariusza, w tym za pomocą zautomatyzowanego narzędzia, żeby pomóc deployerom spełnić obowiązek w uproszczony sposób. Według stanu na czerwiec 2026 AI Office nie wydał jeszcze tego szablonu. To tworzy praktyczną lukę: obowiązek oceny i powiadomienia jest zapisany w prawie, ale standardowe narzędzie do powiadomienia wciąż nie istnieje.

Praktycznym rozwiązaniem, dopóki szablon nie powstanie, jest zbudowanie oceny wokół sześciu ustawowych elementów opisanych powyżej, udokumentowanie jej w ustrukturyzowanej formie, którą później będzie można nanieść na oficjalny szablon, oraz śledzenie tego, co publikuje AI Office, aby przenieść swoją treść, gdy szablon się pojawi. Wykonanie merytorycznej analizy teraz to trwała część pracy. Przeformatowanie jej na oficjalny kwestionariusz później to część tania.

Jak FRIA nakłada się na DPIA z RODO

Większość organizacji objętych zakresem FRIA już prowadzi oceny skutków dla ochrony danych na podstawie Artykułu 35 RODO, bo AI wysokiego ryzyka wpływające na ludzi niemal zawsze wiąże się z przetwarzaniem danych osobowych wysokiego ryzyka. AI Act jest skonstruowany tak, żeby to wykorzystać.

Artykuł 27(4) stanowi, że jeśli którykolwiek z obowiązków FRIA jest już spełniony przez DPIA przeprowadzoną na podstawie Artykułu 35 RODO (albo Artykułu 27 dyrektywy o egzekwowaniu prawa 2016/680), FRIA uzupełnia DPIA, zamiast ją powielać. Instrukcja prawna brzmi: uzupełnia, nie zastępuje. Nie można pominąć FRIA, bo ma się DPIA, i nie trzeba dokumentować od nowa tego, co DPIA już obejmuje.

W praktyce obie oceny nakładają się na siebie w dużej części, ale nie całkowicie:

• Optyka · DPIA (RODO, Art. 35): Ryzyka dla osób, których dane dotyczą, wynikające z przetwarzania danych osobowych · FRIA (AI Act, Art. 27): Ryzyka dla praw podstawowych wynikające z użycia AI
• Wyzwalacz · DPIA (RODO, Art. 35): Przetwarzanie danych osobowych wysokiego ryzyka · FRIA (AI Act, Art. 27): Użycie AI wysokiego ryzyka przez konkretnych deployerów
• Osoby, na które wpływa · DPIA (RODO, Art. 35): Osoby, których dane dotyczą · FRIA (AI Act, Art. 27): Wszystkie osoby fizyczne i grupy, na które wpływa, w tym osoby niebędące podmiotami danych
• Skupienie ryzyka · DPIA (RODO, Art. 35): Ryzyka dla prywatności i ochrony danych · FRIA (AI Act, Art. 27): Szersze prawa podstawowe: niedyskryminacja, godność, uczciwe traktowanie, dostęp do usług
• Nadzór · DPIA (RODO, Art. 35): Zabezpieczenia nad przetwarzaniem · FRIA (AI Act, Art. 27): Nadzór ludzki nad systemem AI zgodnie z instrukcjami providera
• Wynik · DPIA (RODO, Art. 35): Zapis wewnętrzny, konsultacja z organem nadzorczym przy wysokim ryzyku szczątkowym · FRIA (AI Act, Art. 27): Powiadomienie organu nadzoru rynku

Najczystszym sposobem na przeprowadzenie obu jest jedna skoordynowana ocena z dwoma nazwanymi wynikami. Tam, gdzie kontrola albo ustalenie spełnia wymóg po obu stronach, zapisz je raz i odwołuj się do niego z obu miejsc. Tam, gdzie FRIA wykracza poza ochronę danych, w ryzyko dyskryminacji, uczciwość decyzji kredytowej lub ubezpieczeniowej albo adekwatność ścieżki skargowej, DPIA tego nie obejmie i FRIA musi to dodać. Europejska Rada Ochrony Danych sygnalizowała, że koordynowanie tych ocen to zamierzone podejście, przy zachowaniu ich jako odrębnych instrumentów prawnych, adresujących odrębne prawa.

Kto powinien nią zarządzać i ją przeprowadzać

FRIA to obowiązek deployera, więc odpowiedzialność spoczywa na organizacji wdrażającej, nie na dostawcy AI. Wewnątrz organizacji odpowiedzialność najlepiej sprawdza się tam, gdzie już leży proces DPIA, zwykle u inspektora ochrony danych albo w funkcji prywatności lub ryzyka, bo obie oceny mają tyle wspólnych danych wejściowych i korzystają na tym, gdy koordynuje je jeden właściciel.

Wykonanie użytecznej FRIA to nie samotne ćwiczenie prawne. Potrzeba do tego:

• Właściciela biznesowego procesu, który potrafi dokładnie opisać elementy (a) i (b).
• Dokumentacji i instrukcji użytkowania providera, które zasilają elementy (d) i (e). Bez materiału od providera na podstawie Artykułu 13 analiza ryzyka szkody jest zgadywaniem.
• Spojrzenia osób, które będą sprawować nadzór, żeby element (e) odzwierciedlał, jak nadzór wygląda naprawdę, a nie to, co deklaruje polityka.
• Wkładu prawnego albo z zakresu praw podstawowych tam, gdzie ryzyka dotykają dyskryminacji, uczciwego procesu albo dostępu do usług kluczowych.

Drobny szczegół o dużym znaczeniu: zdobądź dokumentację providera wcześnie. Dwa z sześciu elementów od niej zależą, a FRIA napisana bez niej się nie obroni.

Gdzie FRIA sytuuje się w harmonogramie AI Act

FRIA mieści się wśród obowiązków deployera dla wysokiego ryzyka, które mają bazową datę stosowania 2 sierpnia 2026 na podstawie Artykułu 113 AI Act. To data aktualnie obowiązująca.

Jest tu ruchomy element. Digital Omnibus przesuwa samodzielne obowiązki wysokiego ryzyka z Załącznika III, w tym obowiązek FRIA, na 2 grudnia 2027. Został przyjęty przez Parlament 16 czerwca 2026 i przez Radę 29 czerwca 2026, ale nabiera mocy prawnej dopiero z chwilą publikacji w Dzienniku Urzędowym, która według stanu na lipiec 2026 wciąż nie nastąpiła, więc na razie nie zmienia żadnego obowiązującego obowiązku. Traktuj 2 sierpnia 2026 jako datę operacyjną, dopóki publikacja się nie pojawi. Zaplanowanie procesu FRIA już teraz ma sens niezależnie od tego, która data ostatecznie zadecyduje, bo ocena zależy od materiałów wejściowych (dokumentacja providera, projekt nadzoru, mechanizmy skargowe), których zebranie zajmuje czas.

Źródła

• Article 27: Fundamental Rights Impact Assessment for High-Risk AI Systems, EU Artificial Intelligence Act (Regulation (EU) 2024/1689), pełny tekst i data wejścia w życie · https://artificialintelligenceact.eu/article/27/ (sześć elementów, zakres, obowiązek powiadomienia, nakładanie się z DPIA, szablon AI Office)
• Article 27: Fundamental rights impact assessment for high-risk AI systems, European Commission AI Act Service Desk · https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27 (oficjalna wykładnia artykułu przez Komisję)
• Article 26: Obligations of Deployers of High-Risk AI Systems, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/26/ (obowiązki deployera, obok których sytuuje się FRIA)
• Annex III: High-Risk AI Systems Referred to in Article 6(2), EU Artificial Intelligence Act · https://artificialintelligenceact.eu/annex/3/ (wyjątek dotyczący infrastruktury krytycznej z punktu 2, punkty 5(b) i 5(c) o kredycie i ubezpieczeniach)
• Article 113: Entry into Force and Application, EU Artificial Intelligence Act · https://artificialintelligenceact.eu/article/113/ (bazowa data 2 sierpnia 2026 dla obowiązków deployera dla wysokiego ryzyka)
• EU AI Act: focus on the fundamental rights impact assessment for high-risk AI systems, A&O Shearman · https://www.aoshearman.com/en/insights/ao-shearman-on-tech/zooming-in-on-ai-13-eu-ai-act-focus-on-fundamental-rights-impact-assessment-for-high-risk-ai-systems (analiza kancelarii prawnej dotycząca zakresu i koordynacji z DPIA)
• GDPR Article 35: Data protection impact assessment, Regulation (EU) 2016/679 · https://gdpr-info.eu/art-35-gdpr/ (DPIA, którą uzupełnia FRIA)