Jak przeprowadzić inwentaryzację systemów AI w JSFP? Rejestr AI krok po kroku

Proces inwentaryzacji systemów i zastosowań AI krok po kroku

Wdrożenie AI Act w jednostce sektora finansów publicznych powinno rozpocząć się od odpowiedzi na pozornie proste pytanie:

gdzie rzeczywiście wykorzystujemy sztuczną inteligencję?

Nie wystarczy zapytać działu IT o listę „systemów AI”. Sztuczna inteligencja może być funkcją systemu kadrowego, monitoringu, obiegu dokumentów, pakietu biurowego, usługi chmurowej albo systemu dostawcy. Pracownicy mogą dodatkowo korzystać z ChatGPT, Copilota, narzędzi do transkrypcji, tłumaczenia czy analizy dokumentów poza formalnym procesem wdrożenia.

Dlatego inwentaryzacja powinna obejmować przede wszystkim przypadki użycia AI, a nie jedynie nazwy produktów.

Stan prawny: 22 sierpnia 2026 r.

Rejestr AI nie jest ustawową ewidencją każdego systemu

AI Act nie ustanawia ogólnego obowiązku prowadzenia przez każdą JSFP wewnętrznego dokumentu o nazwie „rejestr AI”.

Nie jest to więc odpowiednik rejestru czynności przetwarzania z RODO ani ewidencja o ustawowo określonym zakresie danych.

Wewnętrzny rejestr AI jest natomiast bardzo użytecznym narzędziem organizacyjnym, ponieważ pozwala ustalić:

• które rozwiązania podlegają AI Act;
• w jakich procesach i w jakim celu są wykorzystywane;
• czy jednostka jest dostawcą, podmiotem stosującym czy pełni inną rolę;
• jakie obowiązki dotyczą konkretnego przypadku użycia;
• jakie ryzyka zostały zidentyfikowane;
• kto odpowiada za system i jego wykorzystanie;
• jakie działania należy wykonać i monitorować.

Prowadzenie inwentaryzacji systemów AI jest również elementem dobrych praktyk rekomendowanych przez dobrowolny NIST AI Risk Management Framework. NIST wskazuje m.in. na potrzebę określenia zasad tworzenia i utrzymywania inwentaryzacji, przypisania odpowiedzialności za jej aktualność oraz ustalenia informacji przechowywanych o systemach. NIST AI RMF nie jest jednak źródłem obowiązków prawnych w Polsce.

Inwentaryzacja krok po kroku

Praktyczny proces można przeprowadzić w ośmiu krokach:

1. wyznacz koordynatora inwentaryzacji i osoby odpowiedzialne za dostarczenie informacji w poszczególnych komórkach;
2. przygotuj ankietę opartą na wykonywanych czynnościach, a nie tylko na pytaniu „czy korzystasz z AI?”;
3. zbierz informacje z procesów, IT, zakupów, umów, usług chmurowych i wykorzystywanego oprogramowania;
4. utwórz wpisy kandydackie dla rozwiązań mogących wykorzystywać AI;
5. oddziel system lub usługę od konkretnych przypadków użycia;
6. przeprowadź kwalifikację prawną każdego przypadku;
7. przypisz właściciela, ograniczenia, działania i terminy;
8. określ zdarzenia powodujące ponowną ocenę, np. zmianę modelu, funkcji, danych, dostawcy lub celu wykorzystania.

Na początku nie jest potrzebny rozbudowany system informatyczny. Ważniejsza jest kompletność identyfikacji i jednolity sposób kwalifikowania przypadków użycia.

Które obowiązki już obowiązują, a które dopiero zaczną obowiązywać?

W 2026 r. harmonogram AI Act został zmieniony rozporządzeniem (UE) 2026/1744.

AI Act stosuje się zasadniczo od 2 sierpnia 2026 r., ale dla niektórych grup przepisów przewidziano inne terminy. Aktualne daty wynikają przede wszystkim z art. 113 AI Act.

Komisja Europejska również wskazuje obecnie 2 grudnia 2027 r. dla reguł dotyczących zastosowań wysokiego ryzyka z załącznika III oraz 2 sierpnia 2028 r. dla systemów wysokiego ryzyka związanych z produktami objętymi załącznikiem I.

Ma to bezpośrednie znaczenie dla sposobu prowadzenia rejestru.

A co z art. 49 i rejestracją w bazie UE?

Wewnętrznego rejestru AI jednostki nie należy mylić z rejestracją przewidzianą w art. 49 AI Act.

Art. 49 znajduje się poza odroczonymi sekcjami 1–3 rozdziału III. Art. 49 ust. 3 obejmuje podmioty stosujące będące organami publicznymi, instytucjami, organami, urzędami lub agencjami Unii, a także osoby działające w ich imieniu, jeżeli wykorzystują one systemy wysokiego ryzyka wymienione w załączniku III, z wyjątkiem systemów z pkt 2 załącznika III.

Obowiązek jest funkcjonalnie zależny od kwalifikacji systemu na podstawie art. 6 ust. 2 i załącznika III. Aktualne oficjalne materiały Komisji ujmują reguły rejestracyjne dla takich systemów w harmonogramie stosowanym od 2 grudnia 2027 r.

Położenie art. 49 w sekcji 5 pozostaje istotnym zastrzeżeniem interpretacyjnym, ale w działaniach wdrożeniowych należy przyjmować 2 grudnia 2027 r. jako dominujące oficjalne stanowisko i śledzić dalsze wyjaśnienia Komisji oraz właściwych organów.

Z praktycznego punktu widzenia jednostka powinna już teraz:

• identyfikować systemy, które mogą znaleźć się w zakresie art. 49;
• ustalać status podmiotu;
• gromadzić dane potrzebne do późniejszej rejestracji;
• ponownie zweryfikować obowiązek przed rozpoczęciem stosowania właściwych regulacji high-risk.

W rejestrze można więc zastosować pole:

„art. 49 – dotyczy / nie dotyczy / wymaga ponownej weryfikacji”.

Nie należy natomiast automatycznie zakładać, że każda jednostka wymieniona w art. 9 polskiej ustawy o finansach publicznych jest organem publicznym w rozumieniu art. 49 ust. 3 AI Act.

Pojęcie to należy analizować w kontekście prawa Unii i konkretnego przypadku, a nie poprzez mechaniczne utożsamienie go z polską kategorią JSFP.

Najważniejsza zasada: system to nie przypadek użycia

Rejestr zawierający wpis:

Microsoft Copilot – Microsoft

albo:

ChatGPT – OpenAI

nie pozwala jeszcze ocenić ryzyka ani obowiązków.

Ten sam produkt może być wykorzystywany do bardzo różnych celów:

Z punktu widzenia AI Act kluczowe jest przeznaczenie i rzeczywisty sposób wykorzystania systemu.

Dlatego konstrukcja rejestru powinna rozdzielać przynajmniej:

SYSTEM / USŁUGA → PRZYPADEK UŻYCIA → KWALIFIKACJA

Jeden system może mieć wiele przypadków użycia, a każdy z nich może mieć inne dane, użytkowników, wpływ na osoby i konsekwencje prawne.

Jak znaleźć systemy, o których jednostka nie wie?

Problemem jest tzw. shadow AI – określenie praktyczne, a nie pojęcie zdefiniowane w AI Act.

Chodzi o używanie AI poza ustanowionym procesem zarządzania organizacji.

Może to być np.:

• indywidualne konto pracownika w usłudze generatywnej AI;
• bezpłatne narzędzie do transkrypcji spotkań;
• rozszerzenie do przeglądarki;
• aplikacja do tłumaczenia lub redagowania tekstu;
• przesyłanie dokumentów do zewnętrznych usług AI;
• funkcja AI aktywowana po aktualizacji istniejącego oprogramowania.

Sama ankieta skierowana do IT tego nie wykryje.

Warto porównać kilka źródeł informacji:

Identyfikacja shadow AI nie daje jednak pracodawcy nieograniczonych uprawnień do monitorowania pracowników. Sposób pozyskiwania informacji musi pozostawać zgodny m.in. z RODO, prawem pracy oraz obowiązującymi w jednostce zasadami monitorowania.

Nie pytaj tylko „czy korzystasz z AI?”

Takie pytanie często daje słaby rezultat. Pracownik może nie wiedzieć, jaka technologia znajduje się pod interfejsem używanego systemu.

Lepsza ankieta pyta o czynności:

Najpierw identyfikujemy potencjalne przypadki użycia. Dopiero następnie sprawdzamy, czy rozwiązanie spełnia definicję systemu AI z art. 3 pkt 1.

Jak potraktować konkretne rodzaje systemów?

ChatGPT, Copilot i inne narzędzia generatywne

Nie należy tworzyć wyłącznie jednego wpisu „ChatGPT” albo „Copilot”.

Rejestrować należy konkretne przypadki użycia i określić m.in.:

• cel;
• użytkowników;
• rodzaj wprowadzanych danych;
• rodzaj generowanego wyniku;
• sposób wykorzystania wyniku;
• wpływ na osoby;
• sposób weryfikacji przez człowieka.

Szczególnej uwagi wymagają treści publikowane publicznie.

Art. 50 ust. 4 obejmuje m.in. tekst generowany lub zmanipulowany przez AI i publikowany w celu informowania społeczeństwa o sprawach leżących w interesie publicznym. Nie oznacza to jednak, że każdy projekt komunikatu przygotowany z pomocą AI musi zostać oznaczony jako wygenerowany przez AI.

Przepis przewiduje wyjątek m.in. wtedy, gdy treść została poddana weryfikacji przez człowieka lub kontroli redakcyjnej, a osoba fizyczna lub prawna ponosi odpowiedzialność redakcyjną za jej publikację.

Dlatego rejestr nie powinien automatycznie przyjmować:

„tekst AI = obowiązek oznaczenia”.

Właściwsze jest:

„art. 50 ust. 4 – wymaga analizy sposobu publikacji i kontroli redakcyjnej”.

Obowiązki transparentności z art. 50 są stosowane od 2 sierpnia 2026 r.

OCR i automatyczne przetwarzanie dokumentów

Samo określenie „OCR” nie rozstrzyga, czy mamy do czynienia z systemem AI w rozumieniu AI Act.

Jedno rozwiązanie może jedynie odczytywać znaki. Inne może dodatkowo:

• rozpoznawać typ dokumentu;
• interpretować jego treść;
• wyodrębniać informacje;
• klasyfikować sprawę;
• rekomendować dalszy sposób postępowania.

Dlatego rozwiązanie powinno początkowo otrzymać status:

„do kwalifikacji”.

Dopiero analiza sposobu działania i przeznaczenia pozwala ocenić, czy spełnia definicję systemu AI.

System kadrowy

Samo prowadzenie dokumentacji pracowniczej w systemie informatycznym nie oznacza systemu wysokiego ryzyka.

Znacznie większego znaczenia nabierają funkcje AI przeznaczone np. do:

• analizowania i filtrowania aplikacji;
• oceniania kandydatów;
• wspierania określonych decyzji dotyczących stosunku pracy;
• przydzielania zadań na podstawie cech lub zachowania osób;
• monitorowania i oceniania pracowników.

Takie zastosowania znajdują się w obszarach wskazanych w załączniku III i wymagają szczegółowej kwalifikacji.

Reguły sekcji 1–3 rozdziału III dotyczące systemów klasyfikowanych jako wysokiego ryzyka na podstawie art. 6 ust. 2 i załącznika III będą stosowane od 2 grudnia 2027 r.

Chatbot

W przypadku chatbota trzeba ustalić przede wszystkim, czy system jest przeznaczony do bezpośredniej interakcji z osobą fizyczną.

Art. 50 ust. 1 nakłada na dostawcę takiego rozwiązania obowiązek zaprojektowania go w sposób zapewniający poinformowanie osoby, że wchodzi w interakcję z systemem AI, chyba że jest to oczywiste z punktu widzenia odpowiednio poinformowanej, uważnej i rozsądnej osoby w danych okolicznościach.

Jednostka wykorzystująca chatbota powinna więc znać swoją rolę oraz wiedzieć, jak obowiązek transparentności został zrealizowany.

Analityka i predykcja

Nie każdy dashboard ani moduł Business Intelligence jest systemem AI.

Trzeba ustalić, czy rozwiązanie jedynie prezentuje i przelicza dane, czy też np.:

• klasyfikuje;
• prognozuje;
• generuje rekomendacje;
• ocenia prawdopodobieństwo zdarzenia.

O kwalifikacji decyduje sposób działania i przeznaczenie, a nie marketingowa nazwa „analytics”.

Monitoring i analiza obrazu

Szczególnie ostrożnie należy traktować określenie „inteligentny monitoring”.

Rozpoznawanie osób, zdalna identyfikacja biometryczna, kategoryzacja biometryczna, rozpoznawanie emocji i wykrywanie określonych zachowań nie mają jednej wspólnej kwalifikacji prawnej.

W zależności od:

• celu;
• miejsca wykorzystania;
• kategorii osób;
• sposobu działania;
• właściwego wyjątku przewidzianego w AI Act

dane zastosowanie może podlegać zakazowi, zostać zakwalifikowane jako wysokiego ryzyka, podlegać obowiązkom transparentności albo nie należeć do żadnej z tych kategorii.

Sama obecność funkcji analizy obrazu nie przesądza wyniku kwalifikacji.

Nie zapomnij o AI wykorzystywanej przez dostawców

AI może być wykorzystywana w procesie jednostki, mimo że system technicznie znajduje się po stronie wykonawcy.

Przykładem może być zewnętrzna:

• obsługa infolinii;
• analiza dokumentów;
• klasyfikacja zgłoszeń;
• rekrutacja;
• wykrywanie anomalii;
• transkrypcja.

Nie można poprzestać na stwierdzeniu:

„to system wykonawcy”.

Trzeba ustalić:

kto jest dostawcą → kto jest podmiotem stosującym → pod czyją kontrolą system działa → jakie jest jego przeznaczenie → w jaki sposób wpływa na proces jednostki.

Informacje o funkcjach AI warto więc pozyskiwać już na etapie zamówienia oraz później przy zarządzaniu umową.

Inwentaryzacja musi uwzględniać kompetencje użytkowników

Rejestr powinien również odpowiadać na pytanie:

kto korzysta z systemu i jakich kompetencji potrzebuje?

Art. 4 AI Act jest stosowany od 2 lutego 2025 r. W aktualnym brzmieniu wymaga od dostawców i podmiotów stosujących podejmowania środków wspierających rozwój kompetencji w zakresie AI personelu i innych osób zajmujących się obsługą oraz wykorzystywaniem systemów w ich imieniu.

Należy przy tym uwzględniać m.in. wiedzę techniczną, doświadczenie, wykształcenie, szkolenia, kontekst zastosowania oraz osoby lub grupy, wobec których system jest stosowany.

Nie oznacza to obowiązku zapewnienia każdej osobie identycznego, ustawowo określonego poziomu kompetencji.

W rejestrze można więc powiązać przypadek użycia z informacjami:

grupa użytkowników → wymagane kompetencje → zrealizowane działania szkoleniowe lub informacyjne.

FRIA i DPIA – dwa odrębne procesy

Przy potencjalnym systemie wysokiego ryzyka z załącznika III warto już podczas inwentaryzacji oznaczyć możliwość wystąpienia obowiązku FRIA – oceny wpływu na prawa podstawowe.

Art. 27 może obejmować m.in.:

1. podmioty stosujące będące podmiotami prawa publicznego lub prywatnymi podmiotami świadczącymi usługi publiczne – w odniesieniu do systemów wysokiego ryzyka z art. 6 ust. 2, z przewidzianymi w przepisie wyjątkami;
2. niezależnie od powyższego statusu – podmioty stosujące określone systemy wskazane w pkt 5 lit. b i c załącznika III.

Dla systemów klasyfikowanych na podstawie art. 6 ust. 2 i załącznika III art. 27, jako element sekcji 3 rozdziału III, będzie stosowany od 2 grudnia 2027 r.

FRIA nie jest tym samym co DPIA z art. 35 RODO.

Obie oceny mogą być koordynowane, a AI Act umożliwia wykorzystanie właściwych części DPIA w ramach FRIA, jednak w rejestrze warto zachować je jako odrębne statusy:

• DPIA – wymagana / wykonana / niewymagana / do analizy;
• FRIA – wymagana / wykonana / niewymagana / do analizy.

Minimalny rejestr startowy

Jednostka rozpoczynająca inwentaryzację nie potrzebuje od razu kilkudziesięciu pól.

Na początku wystarczy:

Taki rejestr można początkowo prowadzić nawet w arkuszu kalkulacyjnym.

Rejestr dojrzały

Po wykonaniu pierwszej inwentaryzacji można dodać kolejne grupy informacji:

W rozwiązaniu informatycznym najbardziej użyteczny model powinien rozdzielać co najmniej:

system/usługę → przypadek użycia → kwalifikację → obowiązki → działania.

Co zrobić z rozwiązaniem, które nie jest systemem AI?

Jeżeli po analizie jednostka ustali, że rozwiązanie nie spełnia definicji systemu AI, nie ma potrzeby prowadzenia go dalej przez cały proces zgodności AI Act.

Warto jednak zachować wpis:

„przeanalizowano – poza definicją systemu AI”

wraz z krótkim uzasadnieniem.

Pozwala to wykazać, że rozwiązanie zostało świadomie ocenione, a nie pominięte.

Ma to również znaczenie przy późniejszych aktualizacjach produktu. Funkcja, która dzisiaj nie spełnia definicji systemu AI, po zmianie technologii może wymagać ponownej analizy.

Kiedy ponownie przeprowadzić ocenę?

AI Act nie ustanawia ogólnego obowiązku ponownego przeglądu każdego wpisu w wewnętrznym rejestrze np. dokładnie raz w roku.

Lepsze jest podejście oparte na zdarzeniach wywołujących przegląd.

Takim zdarzeniem może być:

• zmiana modelu;
• nowa funkcja;
• nowe przeznaczenie;
• zmiana rodzaju wykorzystywanych danych;
• integracja z innym systemem;
• rozszerzenie grupy osób objętych działaniem;
• zmiana dostawcy;
• istotny incydent;
• zmiana regulacji lub oficjalnych wytycznych.

Jednostka może dodatkowo ustanowić przeglądy okresowe, jednak ich częstotliwość będzie rozwiązaniem organizacyjnym, a nie uniwersalnym terminem wynikającym z AI Act.

Dostęp do rejestru, retencja i publikowanie danych

Rejestr AI może zawierać informacje wymagające ochrony.

Mogą znaleźć się w nim dane dotyczące:

• architektury systemów;
• ryzyk i podatności;
• umów;
• dostawców;
• przetwarzania danych osobowych;
• incydentów;
• zabezpieczeń;
• wewnętrznych ocen prawnych.

Dlatego jednostka powinna określić:

kto może przeglądać dane → kto może je modyfikować → które informacje wymagają ograniczonego dostępu → jak długo należy je przechowywać → które informacje mogą być udostępniane na zewnątrz.

AI Act nie ustanawia jednego uniwersalnego okresu retencji całego wewnętrznego rejestru. Należy brać pod uwagę wymagania dotyczące konkretnego systemu, ochrony danych, archiwizacji, cyberbezpieczeństwa oraz innych właściwych regulacji.

Wewnętrznego rejestru jednostki nie należy także utożsamiać z unijną bazą systemów wysokiego ryzyka przewidzianą w art. 71 AI Act.

Polska ustawa o systemach sztucznej inteligencji

AI Act uzupełnia w Polsce ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji, Dz.U. z 2026 r. poz. 1003, ogłoszona 27 lipca 2026 r.

Zgodnie z art. 127:

Ustawa przewiduje również publikowanie przez Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji corocznych informacji zawierających przykłady dobrych praktyk w zakresie wdrażania i stosowania systemów AI m.in. w jednostkach sektora finansów publicznych.

Oznacza to, że krajowe dobre praktyki dotyczące inwentaryzacji i zarządzania AI mogą być dalej rozwijane. Wewnętrzny rejestr powinien zatem umożliwiać późniejsze dostosowywanie zakresu danych i procesu kwalifikacji.

Co jest najważniejsze?

Dobra inwentaryzacja nie odpowiada wyłącznie na pytanie:

„Jakie produkty zawierające AI kupiliśmy?”

Znacznie ważniejsze jest:

„W jakich procesach wykorzystujemy AI, w jakim celu, wobec kogo, na jakich danych, kto za to odpowiada i jakie obowiązki wynikają z konkretnego sposobu użycia?”

Dlatego podstawową zasadą konstrukcyjną rejestru powinno być:

SYSTEM / USŁUGA → PRZYPADEK UŻYCIA → KWALIFIKACJA → OBOWIĄZKI I DZIAŁANIA

Tak zbudowany rejestr pozwala wykrywać shadow AI, właściwie kwalifikować wykorzystanie ChatGPT, Copilota, OCR, systemów kadrowych, chatbotów, analityki, monitoringu i rozwiązań dostawców, a następnie zarządzać zmianami w całym cyklu życia AI.

Rejestr przestaje być wtedy listą aplikacji.

Staje się podstawowym narzędziem zarządzania wykorzystaniem AI w jednostce.

Podstawy prawne i materiały pomocnicze

• Rozporządzenie (UE) 2024/1689 – AI Act, tekst skonsolidowany według stanu na 27 lipca 2026 r.
• Rozporządzenie (UE) 2026/1744 z 8 lipca 2026 r. zmieniające AI Act
• Ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji, Dz.U. z 2026 r. poz. 1003
• Komisja Europejska – aktualny harmonogram stosowania AI Act
• Komisja Europejska – wytyczne dotyczące definicji systemu AI
• Komisja Europejska – wytyczne dotyczące obowiązków transparentności z art. 50
• NIST AI Risk Management Framework oraz AI RMF Playbook – Govern 1.6 – dobrowolne źródło dobrych praktyk, a nie podstawa obowiązków prawnych.