Wdrożenie AI Act w jednostce sektora finansów publicznych łatwo rozpocząć od niewłaściwego pytania:

„Kto ma się tym zająć? Informatyka?”

AI Act nie jest regulacją wyłącznie technologiczną. System AI może wpływać na zatrudnienie, świadczenia, edukację, dane osobowe, cyberbezpieczeństwo, zamówienia publiczne, prawa podstawowe i sposób podejmowania decyzji wobec konkretnych osób.

AI Act nie jest zadaniem informatyka. Jest zadaniem organizacji.

Rozporządzenie nie wymaga powołania stanowiska „AI Officera” ani konkretnego komitetu ds. AI. Organizacja może sama ukształtować wewnętrzny model zarządzania. Szczególny docelowy wymóg organizacyjny przewidziano po stronie dostawców systemów wysokiego ryzyka: art. 17 stanowi, że ich system zarządzania jakością ma obejmować ramy określające odpowiedzialność kierownictwa i innych pracowników.

Stan prawny: 26 sierpnia 2026 r.

Najpierw harmonogram

Według aktualnego art. 113 AI Act przepisy sekcji 1–3 rozdziału III dotyczące systemów wysokiego ryzyka będą stosowane od 2 grudnia 2027 r. dla systemów klasyfikowanych na podstawie art. 6 ust. 2 i załącznika III oraz od 2 sierpnia 2028 r. dla systemów z art. 6 ust. 1 związanych z produktami z załącznika I.

Dlatego obowiązki z art. 26 i 27 opisane w tym artykule są według stanu na sierpień 2026 r. przede wszystkim docelowym modelem, do którego JSFP powinny się przygotować.

Odroczenie nie oznacza jednak, że jednostki nie wykonują obecnie żadnych obowiązków z AI Act. Art. 4 dotyczący kompetencji w zakresie AI oraz większość zakazów z art. 5 są już stosowane, a od 2 sierpnia 2026 r. stosuje się również obowiązki przejrzystości z art. 50. Odrębny harmonogram dotyczy niektórych nowych zakazów oraz przepisów odnoszących się do systemów wysokiego ryzyka.

Systemy już używane

Odrębne przepisy przejściowe dotyczą systemów wprowadzonych do obrotu lub oddanych do użytku przed właściwą datą stosowania rozdziału III. Szczególne znaczenie dla sektora publicznego ma art. 111 ust. 2, zgodnie z którym dostawcy i podmioty stosujące systemy wysokiego ryzyka przeznaczone do używania przez organy publiczne mają podjąć niezbędne działania w celu zapewnienia zgodności najpóźniej do 2 sierpnia 2030 r.

Odpowiedzialność prawna a RACI

AI Act przypisuje obowiązki określonym operatorom, m.in. dostawcy, podmiotowi stosującemu, importerowi i dystrybutorowi. Macierz RACI odpowiada na inne pytanie: kto wewnątrz jednostki ma wykonać konkretną czynność?

Dlatego oznaczenie osoby jako A — Accountable nie oznacza automatycznie, że AI Act przypisuje jej osobistą odpowiedzialność prawną.

  • R — Responsible: wykonuje zadanie.
  • A — Accountable: odpowiada organizacyjnie za rezultat.
  • C — Consulted: uczestniczy konsultacyjnie.
  • I — Informed: otrzymuje informację.

Przypisania powinny zostać formalnie zatwierdzone w procedurze, polityce albo zarządzeniu wewnętrznym.

Rekomendowany model dla JSFP

Najbardziej praktyczny układ obejmuje trzy poziomy: kierownictwo ustanawiające model governance, funkcję koordynującą AI oraz właścicieli procesów wspieranych przez IT, cyberbezpieczeństwo, IOD, prawników, zamówienia publiczne i HR.

PoziomRolaGłówne zadanie
StrategicznyKierownik jednostki lub kierownictwoUstanowienie modelu, zapewnienie zasobów i podejmowanie decyzji eskalowanych.
KoordynacyjnyKoordynator AI lub funkcja AI GovernanceUtrzymanie procesu, harmonogramów, kwalifikacji i dowodów zgodności.
Operacyjny i eksperckiWłaściciel procesu, IT, cyberbezpieczeństwo, IOD, prawnicy, zamówienia i HRDecyzje dotyczące zastosowania oraz oceny i kontrole w obszarach specjalistycznych.

Kierownik jednostki

Kierownik nie powinien osobiście kwalifikować każdego systemu AI. Powinien natomiast zapewnić istnienie modelu governance, zasobów, kompetencji, mechanizmu eskalacji i kontroli nad zastosowaniami AI o największym znaczeniu.

Do kierownictwa powinny trafiać przede wszystkim przypadki potencjalnych praktyk zakazanych, systemów należących do kategorii wymienionych w załączniku III, zastosowań wymagających FRIA, istotnego wpływu na prawa osób oraz akceptacji wysokiego ryzyka rezydualnego.

Koordynator AI

Koordynator nie powinien „odpowiadać za całość AI Act”. Jego rolą jest utrzymanie procesu governance: inwentaryzacji, kwalifikacji, harmonogramów, dowodów zgodności, rekwalifikacji i współpracy poszczególnych komórek.

Właściciel procesu

Jeżeli AI jest używana w rekrutacji, właścicielem zastosowania powinien być obszar HR. Jeżeli wspiera przyznawanie świadczeń — komórka prowadząca właściwy proces. Właściciel procesu wie, dlaczego system jest używany, jak wynik wpływa na decyzję, kto może go odrzucić i jakie są konsekwencje błędu.

IT i cyberbezpieczeństwo

IT odpowiada za architekturę, integracje, konfigurację, wersje systemów i modeli, przepływy danych, logowanie i zarządzanie zmianami. Nie powinno jednak samodzielnie rozstrzygać kwalifikacji prawnej systemu.

Funkcja bezpieczeństwa powinna oceniać m.in. kontrolę dostępu, integralność danych, podatności, bezpieczeństwo integracji, logi i scenariusze incydentów. Dla przyszłych systemów wysokiego ryzyka ma to również znaczenie przy obowiązkach monitorowania i reagowania z art. 26.

IOD

Inspektor ochrony danych powinien być konsultowany tam, gdzie AI przetwarza dane osobowe, profiluje osoby, wspiera decyzje wobec osób albo wymaga DPIA. Nie powinien jednak automatycznie stawać się właścicielem AI Act. Jego niezależność i brak konfliktu interesów powinny zostać zachowane.

Prawnicy, zamówienia publiczne i HR

Dział prawny — w małej jednostce również zewnętrzna obsługa prawna — powinien prowadzić analizę regulacyjną roli jednostki, art. 5, art. 6, załącznika III, art. 50, obowiązków operatorów i regulacji sektorowych.

Zarządzanie zgodnością z AI Act powinno rozpoczynać się przed podpisaniem umowy. W dokumentacji zakupowej trzeba zabezpieczyć możliwość pozyskania dokumentacji dostawcy, informacji o kwalifikacji systemu, zmianach wersji, logach, incydentach, nadzorze człowieka oraz współpracy przy FRIA, DPIA i rejestracji.

HR może być właścicielem zastosowań kadrowych, a jednocześnie współtworzyć program kompetencji w zakresie AI z art. 4.

FRIA nie dotyczy automatycznie każdej JSFP

FRIA — Fundamental Rights Impact Assessment, czyli ocena wpływu na prawa podstawowe — nie wynika z samego zaliczenia organizacji do sektora finansów publicznych.

Art. 27 obejmuje podmioty prawa publicznego i prywatne podmioty świadczące usługi publiczne, gdy stosują objęte tym przepisem systemy wysokiego ryzyka, a ponadto podmioty stosujące systemy wskazane w pkt 5 lit. b i c załącznika III. Z zakresu pierwszej grupy wyłączono systemy przeznaczone do używania w obszarze wymienionym w pkt 2 załącznika III.

Bazowa macierz RACI do dostosowania w jednostce

Macierz poniżej jest rekomendowanym modelem governance, a nie wymaganym przez AI Act podziałem stanowisk ani przeniesieniem odpowiedzialności przypisanej operatorom przez prawo.

Skróty: KJ — kierownik jednostki, AI — koordynator AI, WP — właściciel procesu, IT — IT, CYB — cyberbezpieczeństwo, IOD — inspektor ochrony danych, PR — prawnik/compliance, ZP — zamówienia publiczne, HR — kadry.

ZadanieKJAIWPITCYBIODPRZPHR
Ustanowienie governance AIARCCCCCIC
Inwentaryzacja systemów i zastosowańIA/RRRCCCCC
Opis przeznaczenia i procesuICA/RCCCCIC
Ustalenie, czy rozwiązanie jest systemem AIIACRICRII
Kwalifikacja roli, art. 5, art. 6 i art. 50ICCCCCA/RIC
DPIAICA/RCCCCIC
FRIA — jeżeli wymaganaIRA/RCCCCIC
CyberbezpieczeństwoICCRA/RCICI
Nadzór człowiekaICA/RCCCCIR/C
Kompetencje z art. 4ARCCCCCIR
Wymagania do zamówieniaICARRCRRC
Weryfikacja dokumentacji dostawcyIARRRCRCC
Weryfikacja rejestracji systemu przez dostawcęIA/RCCIIRCI
Rejestracja podmiotu i użycia w bazie UE — jeżeli wymaganaIA/RCCIIRII
Relewantność i dostateczna reprezentatywność danych wejściowych pozostających pod kontrolą jednostkiICA/RRCCCIC
Przechowywanie automatycznych logówICARRIIII
Używanie zgodnie z instrukcjąICA/RCCIIIR/C
Informowanie pracownikówICAIICCIR
Informowanie osób fizycznych zgodnie z art. 26 ust. 11ICA/RIICRIC
Zgłoszenie ryzyka i zawieszenie używania systemuIRARRCRII
Zgłoszenie poważnego incydentuIRARRCRIC
Zawiadomienie organu nadzoru rynku o FRIAIRAIICRII
Rekwalifikacja po zmianie systemu lub przeznaczeniaIA/RRRCCRIC
Zakończenie używania systemu objętego progiem eskalacyjnymARRRCCCIC
Okresowy przegląd kompletności dowodów zgodnościIA/RCCCCCII

Okresowy przegląd prowadzony przez koordynatora AI nie zastępuje niezależnego audytu wewnętrznego. Audyt wewnętrzny nie powinien być właścicielem procesów, które następnie ocenia.

Ważne rozróżnienia w art. 26

Dane wejściowe

Art. 26 ust. 4 dotyczy danych wejściowych tylko w zakresie, w jakim podmiot stosujący sprawuje nad nimi kontrolę, i wymaga ich relewantności oraz dostatecznej reprezentatywności ze względu na przeznaczenie systemu. Nie oznacza to przejęcia przez JSFP pełnego reżimu jakości danych treningowych dostawcy z art. 10.

Ryzyko a poważny incydent

Jeżeli podmiot stosujący ma powody uznać, że używanie systemu zgodnie z instrukcjami może doprowadzić do ryzyka w rozumieniu art. 79 ust. 1, docelowy art. 26 ust. 5 przewiduje zawiadomienie bez zbędnej zwłoki dostawcy lub dystrybutora oraz właściwego organu nadzoru rynku, a także zawieszenie używania systemu.

Jeżeli został zidentyfikowany poważny incydent, podmiot stosujący ma natomiast natychmiast informować w pierwszej kolejności dostawcę, a następnie importera lub dystrybutora oraz właściwe organy nadzoru rynku.

Informowanie osób

Art. 26 ust. 11 obejmuje podmioty stosujące systemy wysokiego ryzyka z załącznika III, które podejmują decyzje dotyczące osób fizycznych lub pomagają w podejmowaniu takich decyzji. Osoby te mają zostać poinformowane, że podlegają wykorzystaniu systemu wysokiego ryzyka.

Art. 49 trzeba oceniać osobno

Macierz obejmuje zadania wynikające z art. 26, 27 i 49. Art. 26 i 27 należą do sekcji 3 rozdziału III i dla systemów z art. 6 ust. 2 będą stosowane od 2 grudnia 2027 r.

Art. 49 dotyczący rejestracji znajduje się w sekcji 5, ale jest funkcjonalnie związany z kwalifikacją na podstawie art. 6. Aktualne oficjalne materiały Komisji ujmują rejestrację systemów z załącznika III w harmonogramie stosowanym od 2 grudnia 2027 r. Położenie przepisu pozostaje zastrzeżeniem interpretacyjnym, dlatego przed użyciem konkretnego systemu trzeba ponownie sprawdzić aktualne stanowisko, status jednostki i zakres rejestracji.

Mała jednostka nie potrzebuje dziewięciu etatów

RACI opisuje role, a nie liczbę stanowisk. Jedna osoba może pełnić kilka funkcji, a obsługa prawna czy cyberbezpieczeństwo mogą być zapewniane zewnętrznie.

Trzeba jednak zachować niezależność funkcji kontrolnych i unikać konfliktów interesów, szczególnie w odniesieniu do IOD.

Polska ustawa również wchodzi w życie etapami

Krajowe otoczenie AI Act tworzy ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji, Dz.U. 2026 poz. 1003. Została ogłoszona 27 lipca 2026 r. i co do zasady weszła w życie 11 sierpnia 2026 r., ale art. 8–18 oraz rozdziały 3–5, 8 i 9 zaczną obowiązywać dopiero 28 października 2026 r. ISAP wskazuje także, że art. 125 ust. 4 wszedł w życie 28 lipca 2026 r.

Na 26 sierpnia 2026 r. krajowy system instytucjonalny przewidziany ustawą nie jest więc jeszcze w pełni operacyjny.

Podsumowanie

AI Act nie wymaga powołania „AI Officera”. Wymaga natomiast, aby organizacja była zdolna do wykonania obowiązków, które prawo przypisuje jej jako dostawcy lub podmiotowi stosującemu.

Rekomendowany model: kierownik ustanawia governance, koordynator AI utrzymuje proces, właściciel procesu odpowiada za konkretne zastosowanie, a IT, cyberbezpieczeństwo, IOD, prawnicy, zamówienia i HR wykonują przypisane funkcje eksperckie.

Najgorszym rozwiązaniem byłoby zapisanie w procedurze: „Za AI Act odpowiada dział IT”. AI Act wymaga nie jednej „osoby od AI”, ale dobrze zaprojektowanego systemu odpowiedzialności w całej jednostce.

Podstawy prawne i materiały

Czytaj dalej

Więcej praktycznych materiałów o AI Governance

W Bazie wiedzy publikujemy opracowania z aktualnym stanem prawnym, praktycznymi wskazówkami i źródłami.

Zobacz wszystkie artykuły