Po co firmie rejestr systemów AI i czego będzie wymagał regulator
Rejestr jako fundament ładu AI, a nie kolejna tabelka
Rejestr systemów AI w firmie to podstawowe narzędzie, które pozwala realnie zarządzać ryzykiem, a nie tylko „odhaczyć” compliance. Bez niego organizacja zwykle nie wie dokładnie:
gdzie w procesach biznesowych działa AI,
na jakich danych pracują poszczególne rozwiązania,
kto odpowiada za skutki ich działania,
jakie są zależności między modelami, dostawcami i procesami.
Efekt to typowy chaos: każdy zespół wdraża swoje narzędzia (często w modelu shadow IT), brak spójnych polityk, trudno wskazać odpowiedzialnego, gdy klient, pracownik albo regulator zada szczegółowe pytanie.
Dobrze zaprojektowany rejestr systemów AI w firmie rozwiązuje kilka praktycznych problemów naraz. Po pierwsze, wymusza wskazanie właściciela biznesowego każdego systemu i przypisanie mu odpowiedzialności. Po drugie, porządkuje informacje o dostawcach, typach danych, celach przetwarzania oraz powiązanych ryzykach. Po trzecie, tworzy centralny punkt odniesienia dla prawników, inspektora ochrony danych, działu bezpieczeństwa IT, risk managerów i audytu wewnętrznego.
Kluczowa zmiana mentalna: rejestr systemów AI nie jest „papierologią dla prawnika”. To narzędzie operacyjne, które pomaga zarządowi i menedżerom podejmować racjonalne decyzje o rozwoju, inwestycjach w AI i akceptowalnym poziomie ryzyka.
Powiązanie rejestru z AI Act, RODO, prawem pracy i oczekiwaniami klientów
Akt o sztucznej inteligencji (AI Act) wprowadza dla części systemów AI obowiązek spełnienia konkretnych wymogów: zarządzanie ryzykiem, dokumentacja techniczna, logowanie, nadzór człowieka, transparencja. Nawet jeśli dana firma nie będzie producentem systemów wysokiego ryzyka, i tak będzie ich użytkownikiem w rozumieniu AI Act. To oznacza realne obowiązki, a część z nich da się spełnić tylko wtedy, gdy wiadomo, z jakimi systemami w ogóle ma się do czynienia.
Rejestr systemów AI w firmie staje się więc centralnym miejscem, gdzie można oznaczyć, które rozwiązania:
mogą podpadać pod kategorie wysokiego ryzyka określone w AI Act,
wykorzystują dane osobowe i wymagają analizy pod kątem RODO (np. DPIA),
dotykają relacji pracodawca–pracownik (monitorowanie, ocena efektywności, rekrutacja),
są ważne dla spełnienia wymagań klientów B2B (korporacyjne polityki zakupowe, wymagania w RFP).
RODO wymaga m.in. zasady rozliczalności. Gdy pojawia się pytanie: „Jakie systemy wykorzystują dane tej kategorii?” albo „Gdzie używany jest profilujący scoring?”, rejestr pozwala w kilka minut wyciągnąć odpowiedź zamiast rozpoczynać tygodniowy research mailowy w całej organizacji.
Podobnie w relacji B2B: duzi klienci coraz częściej zadają szczegółowe pytania o governance AI w organizacji dostawcy. Rejestr systemów AI w firmie to gotowy materiał do odpowiedzi na rozbudowane kwestionariusze bezpieczeństwa, RFP, due diligence przed inwestycją lub przejęciem.
Rejestr systemów AI vs zwykły spis narzędzi IT
Klasyczna inwentaryzacja IT skupia się na sprzęcie, licencjach i aplikacjach jako takich. Dla AI jest to za mało. System AI to nie tylko „aplikacja na liście”, ale zespół elementów: model, dane, proces decyzyjny, wpływ na ludzi, nadzór człowieka. Dlatego rejestr systemów AI różni się od zwykłego spisu narzędzi IT w kilku kluczowych punktach:
odwołuje się do ryzyka i wpływu, a nie tylko do „co mamy zainstalowane”,
koncentruje się na zastosowaniu AI w procesie (np. scoring kredytowy, rekomendacje ofert),
uwzględnia dane (kategorie, źródła, wrażliwość, dane osobowe),
uwzględnia rola człowieka: kto nadzoruje, kto może nadpisać decyzję systemu,
oznacza kontekst regulacyjny: AI Act, RODO, sektorowe wymogi branżowe.
Sam wykaz licencji „Copilot dla M365, 50 użytkowników” nie powie nic sensownego audytorowi czy regulatorowi. W rejestrze AI trzeba rozłożyć to na zastosowania: generowanie kodu, podpowiedzi w Excelu, przygotowywanie ofert, obsługa maili. Każde z nich może mieć inny profil ryzyka, inny dostęp do danych i innych użytkowników końcowych.
Jak rejestr ułatwia kontrole, audyty i due diligence
Przygotowanie do kontroli regulatora, audytu wewnętrznego lub przeglądu przed inwestycją zwykle zaczyna się od prostego pytania: „Pokażcie, gdzie macie AI i jak tym zarządzacie”. Rejestr systemów AI w firmie pozwala przedstawić spójny obraz:
kompletną listę systemów AI uporządkowaną według procesów lub działów,
wskazanie właścicieli biznesowych i technicznych,
opis zastosowań, ryzyka i środków kontroli,
powiązania z analizami ryzyka, DPIA, politykami, procedurami reakcji na incydenty.
Dla regulatora czy audytora istotne jest nie tylko, że systemy są „gdzieś opisane”, ale że organizacja potrafi wykazać ciągłość: od decyzji o wdrożeniu, przez ocenę ryzyka, po bieżący monitoring. Rejestr staje się kręgosłupem całego governance AI. Na jego bazie można planować audyty tematyczne, przeglądy ryzyka, a także priorytety rozwoju – np. które rozwiązania warto zastąpić bardziej bezpiecznymi lub lepiej udokumentowanymi.
Źródło: Pexels | Autor: Werner Pfennig
Co w firmie jest „systemem AI” – praktyczne kryteria
Definicja AI z AI Act w wersji dla praktyków
AI Act definiuje system AI dość szeroko. W uproszczeniu: to system zaprojektowany tak, aby działał z różnym stopniem autonomii, i który na podstawie danych generuje wyniki (prognozy, rekomendacje, decyzje, treści) wpływające na środowisko fizyczne lub cyfrowe. W praktyce oznacza to, że system AI:
przetwarza dane wejściowe (np. tekst, obraz, liczby, sygnały),
stosuje modele uczenia maszynowego lub inne zaawansowane techniki,
produkuje wynik, który jest później używany w decyzjach lub interakcji z użytkownikami.
Wiele funkcji AI jest dziś „zaszytych” w produktach: np. inteligentne podpowiedzi w CRM, funkcje predykcyjne w ERP, systemy antyfraudowe w bankowości, rekomendacje w e-commerce. W rejestrze systemów AI trzeba uwzględnić nie tylko projekty oczywiście „AI/ML”, ale także gotowe komponenty w narzędziach SaaS, jeśli ich działanie spełnia powyższe kryteria.
Proste testy: AI vs automatyzacja vs zwykłe oprogramowanie
Praktyczny problem to odróżnienie systemów AI od zwykłej automatyzacji lub raportowania. Dobry sposób to zastosowanie kilku prostych testów decyzyjnych:
Czy system uczy się na danych? Jeśli logika działania opiera się na wyuczonym modelu (uczenie nadzorowane, nienadzorowane, reinforcement learning, deep learning), to mocny sygnał, że mamy do czynienia z AI.
Czy system generuje treści lub rekomendacje? Generatory tekstu, obrazu, kodu, systemy rekomendacyjne, scoringi, predykcje popytu – typowe przykłady.
Czy system sam dopasowuje się w czasie? Jeżeli wynik działania zmienia się w miarę napływu nowych danych lub feedbacku użytkownika, bez ręcznej zmiany reguł, to znów wskazówka w stronę AI.
Z kolei klasyczne makra, skrypty IF/THEN, twardo zakodowane reguły biznesowe, zwykła automatyzacja workflow bez uczenia się – to przeważnie nie będzie system AI według AI Act. Mogą oczywiście generować ryzyko (np. błędy w regułach), ale innego rodzaju niż system uczący się.
Gotowe narzędzia SaaS, wbudowane modele i własne rozwiązania
W inwentaryzacji systemów AI warto rozróżnić trzy główne kategorie:
Gotowe narzędzia SaaS z funkcjami AI Przykłady: Copilot dla M365, asystenci AI w narzędziach programistycznych, moduły „AI Insights” w systemach analitycznych, chatboty dostarczane jako usługa. Firma nie buduje modelu, ale używa go, często na własnych danych. Ryzyko skupia się na konfiguracji, zakresie danych i sposobie użycia przez pracowników.
Modele wbudowane w istniejące systemy (CRM, ERP, HR, marketing) Producent systemu dodaje moduł predykcji, rekomendacji lub scoringu. Użytkownicy biznesowi często nie traktują tego jako „projektu AI”, bo funkcja jest „po prostu w systemie”. W rejestrze systemów AI należy takie zastosowania wyszczególnić, bo ich decyzje wpływają np. na klientów (rekomendacje ofert, weryfikacje KYC) lub pracowników (harmonogramy, targety).
Własne modele, boty i skrypty ML Rozwiązania budowane w działach data science, IT, R&D: scoringi, detekcja anomalii, forecasting, personalizacja. Tu firma ma największą kontrolę, ale też największą odpowiedzialność – za dane treningowe, jakość modelu, dokumentację i monitoring.
W rejestrze systemów AI każda kategoria może mieć nieco inne pola akcentowane. Dla własnych modeli kluczowa będzie dokumentacja techniczna i dane treningowe. Dla narzędzi SaaS – umowa z dostawcą, konfiguracja, zakres przekazywanych danych i zasady nadzoru.
Gdzie przebiega granica: automaty Excel, reguły biznesowe, statystyka opisowa
Pojawia się pokusa, by do rejestru systemów AI wrzucić „na wszelki wypadek” wszystko, co niestandardowe. Szybko powstaje przeładowana baza, której nikt nie jest w stanie aktualizować. Pomaga ustalenie jasnych kryteriów, co zwykle nie trafia do rejestru:
Makra i formuły w Excelu – jeżeli działają na prostych regułach bez elementów uczenia maszynowego i nie „uczą się” na nowych danych, zwykle traktujemy je jako automatyzację, nie jako AI.
Klasyczne systemy regułowe – np. „jeśli klient ma saldo > X i brak zaległości, to przyznaj ofertę Y”. To logika ekspercka, ale nie model uczący się. Do rejestru systemów AI trafiają tylko wtedy, gdy są ściśle powiązane z modułami AI lub ich wynik jest z nimi mieszany.
Raporty BI, statystyka opisowa – dashboardy, raporty, KPI, klasyczne agregaty danych bez elementu predykcji lub rekomendacji same w sobie nie są systemami AI.
Te granice dobrze opisać w polityce korzystania z AI i w instrukcji prowadzenia rejestru. Dzięki temu właściciele procesów wiedzą, co zgłaszać, a co pozostaje w standardowym zarządzaniu IT/BI.
Najwięcej niejasności pojawia się przy systemach „pomiędzy” – formalnie mogą być oparte na klasycznych algorytmach, ale ich wpływ na ludzi jest bardzo duży. W praktyce do rejestru systemów AI warto obowiązkowo wciągać m.in.:
Scoringi i klasyfikatory – ocena ryzyka kredytowego, scoring lojalności, modele churn, przyznawanie limitów, kwalifikacja leadów. To typowe zastosowania AI/ML i jednocześnie kandydaci do kategorii wysokiego ryzyka (szczególnie w finansach, HR, sektorze publicznym).
Systemy rekomendacyjne i personalizacja – rekomendacje produktów, personalizacja interfejsu, profilowanie marketingowe. Nawet jeśli technicznie nie są skomplikowane, dotykają prywatności i mogą powodować dyskryminację lub nieuczciwe praktyki marketingowe.
Systemy antyfraudowe i bezpieczeństwa – detekcja anomalii, flagowanie podejrzanych transakcji, monitoring zachowań użytkowników. Tu ryzyko dotyczy błędów fałszywie pozytywnych/negatywnych i wpływu na prawa osób (zablokowanie konta, odmowa transakcji).
Nawet jeżeli dostawca twierdzi, że używa „zwykłych algorytmów statystycznych”, z perspektywy AI Act i zarządzania ryzykiem bezpieczniej jest traktować takie systemy jak AI i prowadzić ich opis w rejestrze. Dzięki temu firma jest gotowa na pytania regulatora i klientów, a przy okazji ma wgląd w realny wpływ tych systemów na użytkowników.
Decyzja strategiczna: zakres rejestru i cele biznesowe
Minimum zgodności z prawem czy narzędzie zarządcze
Przed startem prac trzeba jasno zdecydować, jaki jest docelowy zakres rejestru systemów AI w firmie. Można przyjąć dwa skrajne podejścia:
Model minimalistyczny (tylko to, co wymaga prawo) Rejestr obejmuje wyłącznie systemy objęte AI Act jako wysokiego ryzyka lub wskazane w wewnętrznych politykach jako „wrażliwe”. Celem jest wyłącznie spełnienie wymogów regulatorów i klientów korporacyjnych. Zaleta: mniejsza skala pracy na start. Wada: ryzyko, że wykluczy się część rozwiązań, które dziś są „niewinne”, ale jutro znajdą się pod lupą regulatorów (np. generatywne AI w obsłudze klienta).
Rozszerzony model zarządczy (rejestr jako mapa wykorzystania AI)
Druga opcja to potraktowanie rejestru jako narzędzia zarządczego dla całej organizacji. W tym ujęciu obejmuje on nie tylko systemy „podlegające pod AI Act”, ale szerzej – wszystkie istotne zastosowania AI, także eksperymentalne i pilotażowe. Celem jest przejrzystość: kto czego używa, w jakim procesie, z jakim skutkiem biznesowym i ryzykiem.
Taki rejestr pozwala m.in.:
zidentyfikować duplikaty projektów (trzy zespoły budują podobny scoring),
lepiej planować inwestycje – widać, gdzie AI wspiera procesy krytyczne, a gdzie to tylko gadżet,
kontrolować „shadow AI” – nieautoryzowane użycie narzędzi przez zespoły,
lepiej zarządzać kompetencjami – wiadomo, gdzie potrzebne są role typu prompt engineer, data scientist, AI product owner.
Rozszerzony model wymaga więcej pracy przy wdrożeniu, ale później ułatwia zarówno przygotowanie do kontroli, jak i rozmowy z zarządem o realnym zwrocie z inwestycji w AI.
Model mieszany: minimum prawne + strefa „sandbox”
W praktyce najlepiej sprawdza się wariant pośredni. Trzon rejestru odpowiada wymogom prawnym (szczególnie dla systemów wysokiego ryzyka), a obok funkcjonuje lżejsza część „sandboxowa” dla eksperymentów i narzędzi o niższym wpływie. Różnią się one głębokością wymaganych informacji.
Przykładowy podział:
Warstwa „regulowana” – systemy wysokiego ryzyka, systemy używane na klientach i pracownikach, krytyczne procesy. Tu wymagany jest pełny pakiet pól, ocen ryzyka, dokumentacji, decyzji zatwierdzających.
Warstwa „eksperymentalna” – pilotaże, PoC, indywidualne wykorzystanie narzędzi generatywnych do pracy wewnętrznej. Wymagane są jedynie podstawowe informacje: kto, co, z jakim celem i na jakich danych.
Takie podejście ogranicza biurokrację przy eksperymentach, a jednocześnie daje działowi compliance widoczność, gdzie AI w ogóle się pojawia. Pozwala też płynnie przenosić systemy z części sandboxowej do „regulowanej”, gdy zaczynają wpływać na klientów czy kluczowe decyzje.
Jak podejść do zakresu w zależności od dojrzałości organizacji
Zakres rejestru sensownie dostosować do tego, na jakim etapie rozwoju AI jest firma:
Organizacja na starcie przygody z AI – lepiej zacząć od katalogu podstawowych zastosowań (np. 10–20 systemów) i prostego rejestru. Najpierw zbudować nawyk zgłaszania, dopiero później dodawać bardziej rozbudowane pola.
Firmy z licznymi projektami data science – tu od razu potrzebny jest pełniejszy rejestr, bo bez niego nie ma szans zapanować nad ryzykiem modeli w produkcji. Często dobrym krokiem jest objęcie rejestrem projektów ML już na etapie developmentu, nie dopiero po wdrożeniu.
Duże grupy kapitałowe – przydatny jest rozdział: rejestr centralny (krytyczne systemy, wspólne platformy) i rejestry lokalne w spółkach, zintegrowane procesowo, ale prowadzone blisko biznesu.
Jak „sprzedać” rejestr zarządowi i biznesowi
Bez wsparcia zarządu rejestr AI staje się kolejną tabelą, którą biznes omija. W prezentacji dla kierownictwa lepiej od razu mówić językiem ryzyka i pieniędzy:
pokazać scenariusze kar i konsekwencji reputacyjnych przy niezgodności z AI Act,
pokazać, jak rejestr ułatwi odpowiedzi na ankiety due diligence od kluczowych klientów,
zaznaczyć, że rejestr będzie też bazą do przeglądu portfela projektów AI i szukania oszczędności.
Dobrze działa prosta mapa: „dziś nie wiemy, ile mamy systemów AI, gdzie działają i na jakich danych; po wdrożeniu rejestru – mamy listę, status zgodności, odpowiedzialnych właścicieli i plan redukcji ryzyka”.
Źródło: Pexels | Autor: Mikael Blomkvist
Role i odpowiedzialności: kto „trzyma” rejestr i kto wpisuje dane
Właściciel rejestru: centrum vs biznes
Kluczowy wybór organizacyjny dotyczy tego, gdzie „przyczepić” rejestr. Kilka najczęstszych wariantów:
Compliance / ryzyko / dział prawny – dobre miejsce, gdy głównym celem jest zgodność z prawem i przygotowanie na kontrole. Ryzyko: biznes widzi rejestr jako „narzucony obowiązek”.
IT / data / cyfryzacja – rejestr staje się elementem zarządzania architekturą IT i danymi. Plus: lepsze rozumienie technologii, minus: słabsza presja na stronę prawną i etyczną.
Nowa funkcja „AI governance” – w większych organizacjach powstają dedykowane role (np. AI Governance Lead), które spinają prawo, technologię i biznes.
Bez względu na wybór, właściciel rejestru musi mieć realną mandatę: prawo do wymuszania zgłoszeń, blokowania wdrożeń bez wpisu do rejestru i eskalowania tematów do zarządu.
Właściciel systemu AI (business owner)
Każdy wpis w rejestrze powinien mieć jedną osobę „na nazwisko” po stronie biznesu. To nie musi być technik – raczej menedżer odpowiedzialny za proces, w którym działa AI. Do jego zadań należy m.in.:
zgłoszenie systemu do rejestru i aktualizacja danych przy zmianach,
dbanie o przestrzeganie ograniczeń użytkowania (np. jakie dane można wprowadzać do narzędzia),
organizowanie przeglądów ryzyka razem z działem compliance i IT,
reagowanie na sygnały o błędach lub nadużyciach.
Przykład: właścicielem systemu scoringu kredytowego nie jest „dział analityki”, tylko szef obszaru kredytów detalicznych, który wykorzystuje model do podejmowania decyzji biznesowych.
Odpowiedzialność IT / data / model ownera
Po stronie technicznej także potrzebna jest wyraźna odpowiedzialność. Zwykle dzieli się ją na:
Model ownera / lead data scientist – odpowiada za parametry modelu, dane treningowe, dokumentację techniczną, releasy wersji i monitoring techniczny (drifty, błędy),
System ownera w IT – pilnuje infrastruktury, integracji, uprawnień, zarządzania wersjami oprogramowania,
Data ownera / stewarda danych – odpowiada za jakość źródeł danych i zgodność z polityką danych (w tym RODO).
Rejestr powinien odzwierciedlać ten podział. Przy każdym systemie jasno wskazać: kto odpowiada za biznes, kto za technologię, kto za dane. Regulator, pytając o konkretny przypadek, będzie oczekiwał, że w ciągu jednego dnia pojawi się komplet interesariuszy przy jednym stole.
Rola compliance, bezpieczeństwa i ochrony danych
Działy compliance, bezpieczeństwa informacji i ochrony danych osobowych muszą mieć zdefiniowaną rolę w procesie wpisywania i przeglądu systemów AI. Typowy podział wygląda tak:
Compliance / ryzyko operacyjne – określa wymagane pola rejestru, progi ryzyka, triggery do dodatkowych ocen (np. AI impact assessment), prowadzi cykliczne przeglądy zgodności.
Bezpieczeństwo informacji (CISO / security) – weryfikuje, czy konfiguracja i integracje nie tworzą luk bezpieczeństwa, oraz czy dostawcy SaaS spełniają wymagania bezpieczeństwa.
Inspektor Ochrony Danych (IOD/DPO) – włącza się przy systemach przetwarzających dane osobowe, w szczególności w przypadkach profilowania, scoringu, monitoringu pracowników i klientów.
Dobrym zwyczajem jest ustalenie progów: np. system wysokiego ryzyka musi przejść przegląd trzech funkcji, a system niższego ryzyka – tylko krótką konsultację z compliance.
Użytkownicy końcowi i managerowie liniowi
Choć użytkownicy końcowi nie wpisują systemów do rejestru, to od ich zachowań zależy, czy wpis będzie miał sens. Potrzebują prostych zasad:
z jakich narzędzi mogą korzystać bez dodatkowych zgód,
kiedy muszą zgłosić nowe użycie AI (np. instalację wtyczki, nowy bot w obsłudze klienta),
jak zgłosić incydent lub niepokojące zachowanie systemu (np. dyskryminujące rekomendacje).
Managerowie liniowi powinni z kolei wiedzieć, że każde szersze wdrożenie AI w zespole wymaga formalnego zgłoszenia i przypisania odpowiedzialności. Bez tego „lokalne” inicjatywy szybko urosną do krytycznej skali poza radarem.
Źródło: Pexels | Autor: qmicertification design
Jak zaprojektować strukturę rejestru: jakie pola są naprawdę potrzebne
Warstwa podstawowa: identyfikacja systemu
Na początek wystarczy zestaw pól, które jednoznacznie opisują system i jego kontekst. Typowe minimum:
nazwa systemu (robocza i oficjalna),
krótki opis funkcji (2–3 zdania, bez żargonu technicznego),
obszar biznesowy / proces, w którym działa (np. „obsługa klienta – reklamacje”),
jednostka organizacyjna (departament, spółka),
właściciel biznesowy (imię, nazwisko, stanowisko),
właściciel techniczny / model owner,
status systemu (pomysł, PoC, pilot, produkcja, wycofywany).
Bez tych pól rejestr zamienia się w listę niespójnych wpisów, których nikt potem nie potrafi powiązać z rzeczywistością organizacyjną.
Warstwa regulacyjna: kategoria ryzyka i podstawa prawna
Drugi zestaw pól dotyczy tego, jak system „wpada” w kategorie AI Act i innych regulacji. Przykładowe pola:
czy system przetwarza dane osobowe (tak/nie + zakres kategorii),
czy system dotyczy klientów, pracowników, czy tylko danych anonimowych,
wstępna klasyfikacja wg AI Act (wysokie ryzyko / ograniczone / minimalne / zakazane),
link do oceny DPIA / AI impact assessment, jeśli była wykonywana,
czy system podejmuje lub wspiera decyzje wywołujące skutki prawne lub podobnie istotne (odmowa kredytu, odmowa zatrudnienia, blokada konta).
Na tym etapie nie trzeba jeszcze mieć perfekcyjnej klasyfikacji ryzyka. Ważne, by każdy system przeszedł przez ten sam, prosty zestaw pytań. Pomyłki można korygować w przeglądach okresowych.
Warstwa techniczna: model, dane i dostawca
Struktura rejestru nie powinna być dokumentacją ML end-to-end, ale kilka pól technicznych jest niezbędnych, szczególnie na potrzeby audytów:
rodzaj rozwiązania: narzędzie SaaS, moduł w istniejącym systemie, własny model,
główny typ AI: model generatywny, klasyfikacja, regresja, rekomendacje, detekcja anomalii, NLP etc.,
informacja o dostawcy: nazwa, kraj, link do umowy / DPA,
główne źródła danych (systemy zasilające, typ danych: transakcyjne, logi, dokumenty),
czy model jest trenowany / dostrajany na danych firmy (fine-tuning, RAG), czy używany „out of the box”,
częstotliwość aktualizacji modelu (ciągła, okresowa, brak automatycznej aktualizacji).
To pozwala szybko odróżnić np. prosty moduł rekomendacji SaaS od własnego, ryzykownego modelu działającego na danych wrażliwych.
Warstwa operacyjna: sposób użycia i kontrola nad decyzjami
Systemy o podobnej technice mogą mieć zupełnie inny profil ryzyka w zależności od tego, jak są używane. W rejestrze warto mieć pola opisujące:
czy decyzja AI jest automatyczna, czy zawsze zatwierdzana przez człowieka (human-in-the-loop),
jak użytkownicy widzą i edytują wynik modelu (np. możliwość nadpisania rekomendacji),
czy użytkownik końcowy (klient, pracownik) jest informowany o użyciu AI,
jakie są główne wskaźniki jakości (accuracy, precision/recall, inne KPI ustalone biznesowo),
jak działa monitoring: kto sprawdza wyniki, jak często i z jakimi progami alarmów.
To są informacje, o które bardzo często pytają audytorzy zewnętrzni i klienci w due diligence. Dobrze mieć je zebrane w jednym miejscu, a nie szukać na ostatnią chwilę w różnych prezentacjach i mailach.
Warstwa etyczna i ESG: wpływ na ludzi i środowisko
Coraz więcej klientów i regulatorów oczekuje informacji nie tylko o zgodności prawnej, ale też o wpływie AI na ludzi. Można to ująć w kilku prostych polach:
czy system może prowadzić do dyskryminacji lub nierównego traktowania (np. w HR, kredytach, marketingu),
czy system wykorzystuje dane wrażliwe lub pochodzące z mediów społecznościowych,
czy istnieją mechanizmy skarg i odwołań dla osób dotkniętych decyzjami AI,
czy system wpływa na warunki pracy (monitoring pracowników, ocena wydajności, harmonogramy).
Warstwa dowodowa: dokumenty i artefakty do pokazania regulatorowi
Sam opis systemu w rejestrze nie wystarczy. Przy pierwszej większej kontroli pojawi się pytanie: „gdzie są dowody, że robicie to, co deklarujecie?”. Dlatego przy każdym wpisie dobrze mieć sekcję linków do kluczowych artefaktów:
opis przypadku użycia (business case, notatka z komitetu, decyzja o wdrożeniu),
model card / karta systemu (skrót techniczny i biznesowy),
metryki jakości i raport z testów przedprodukcyjnych,
raport z przeglądu prawnego / DPIA / AI assessment,
protokół z ostatniego przeglądu okresowego (data, uczestnicy, ustalenia),
procedury awaryjne i playbook na wypadek incydentu (rollback, wyłączenie, komunikacja do klientów).
Nie trzeba wklejać całych dokumentów do rejestru. Wystarczy stabilny link (np. do SharePointa) i jasne ustalenie, kto odpowiada za aktualność tych materiałów. Dzięki temu w razie audytu można w kilka minut otworzyć cały „pakiet dowodowy” dla wybranego systemu.
Warstwa cyklu życia: daty, wersje i decyzje o wyłączeniu
Regulator będzie patrzył nie tylko na to, jak system działa dziś, ale także jak się zmieniał. Przydatny jest prosty moduł historii życia:
data zgłoszenia systemu do rejestru,
daty startu PoC, pilotażu i wejścia na produkcję,
kluczowe zmiany wersji (np. nowy model, nowe źródło danych, nowy dostawca),
data i przyczyna wyłączenia systemu (decommissioning),
link do decyzji o wyłączeniu / migracji na inne rozwiązanie.
To baza do pokazania dojrzałego zarządzania cyklem życia: powstanie, rozwój, monitoring, wycofanie. Chaos w wersjach i datach to jeden z pierwszych sygnałów dla audytora, że organizacja nie panuje nad swoimi modelami.
Inwentaryzacja istniejących i planowanych systemów AI – krok po kroku
Krok 1: Zdefiniuj, co w firmie liczy się jako „system AI”
Bez tej definicji inwentaryzacja ugrzęźnie w sporach „czy to już AI, czy jeszcze nie”. Trzeba mieć prostą, roboczą regułę, opartą na kryteriach z AI Act, ale przełożoną na język organizacji. Przykładowy zestaw pytań kontrolnych:
czy system wykorzystuje modele uczące się na danych (machine learning, deep learning, modele generatywne),
czy system generuje rekomendacje, prognozy lub klasyfikacje, które wpływają na decyzje biznesowe,
czy używamy gotowych usług chmurowych z komponentem AI (np. rozpoznawanie obrazu, mowy, tekstu),
czy system został opisany przez dostawcę jako „AI”, „ML”, „cognitive”, „predictive” itp.
Jeśli odpowiedź na któreś z tych pytań brzmi „tak”, system powinien przynajmniej przejść wstępny screening i potencjalne wpisanie do rejestru. Formalna, prawnicza definicja może zostać w polityce – na codzień potrzebny jest prosty filtr operacyjny.
Krok 2: Zbierz informacje z góry – projekty, budżety, roadmapy
Inwentaryzację lepiej zacząć „od góry”, czyli od przeglądu tego, co już jest formalnie planowane lub finansowane. Źródła:
portfolio projektów IT / zmiany (PMO, biuro projektów),
budżety inwestycyjne (CAPEX/OPEX) – linijki z „AI”, „data science”, „automatyzacja”,
roadmapy produktowe poszczególnych linii biznesowych,
umowy z dostawcami chmurowymi i SaaS (szczególnie z dopiskami „AI add-on”, „analytics module”).
Na tym etapie sporządza się pierwszą listę kandydatów do rejestru. Nie wszystko będzie „prawdziwym” systemem AI, ale lepiej zacząć szerzej i potem odsiać, niż pominąć kluczowy model scoringowy ukryty w jakimś większym projekcie.
Krok 3: Przeczesz istniejące systemy – architektura IT i integracje
Druga warstwa to przegląd tego, co już działa w produkcji, często od lat, pod hasłem „model predykcyjny” albo „silnik regułowo-uczący się”. W praktyce oznacza to:
przegląd katalogu aplikacji (CMDB, lista systemów IT) z filtrami po słowach kluczowych,
rozmowy z zespołami odpowiedzialnymi za hurtownie danych, platformy analityczne, data lake,
przegląd integracji z zewnętrznymi API dostawców AI (np. OCR, biometria, scoring fraudowy).
W wielu firmach ujawnia się wtedy „szara strefa” – modele napisane lata temu przez pojedynczych analityków, działające na serwerze pod biurkiem lub w zapomnianym kontenerze. W rejestrze takie systemy powinny dostać status „do uporządkowania” i plan działań naprawczych.
Krok 4: Zapytaj ludzi – ankieta i wywiady z kluczowymi zespołami
Same systemy IT nie pokażą pełnego obrazu, szczególnie jeśli pracownicy korzystają z narzędzi SaaS lub AI-as-a-feature w innych aplikacjach. Dlatego przydaje się prosta ankieta rozesłana do:
Ankieta powinna zawierać kilka konkretnych pytań, bez żargonu:
czy w Twoim obszarze korzystacie z narzędzi, które automatycznie rekomendują decyzje, priorytety, oferty lub działania wobec klientów/pracowników,
czy używacie narzędzi generatywnych (tekst, obraz, kod) do pracy na danych firmy lub danych klientów,
czy w ciągu ostatniego roku pojawił się projekt „z AI” lub „zaawansowaną analityką” – jaki i z jakim dostawcą.
Ważne, żeby od razu zapewnić, że celem nie jest „polowanie na czarownice”, tylko uporządkowanie stanu faktycznego i stworzenie zasad, które uchronią zespoły przed problemami z regulatorem.
Krok 5: Zidentyfikuj „ukryte” użycia narzędzi generatywnych
Najtrudniejsza część to praca z generatywną AI (chatboty, asystenci, generatory kodu), z której ludzie korzystają poza formalnymi procesami. Tu trzeba połączyć kilka podejść:
polityka korzystania z narzędzi generatywnych – jasne zasady co wolno, a czego nie,
przegląd logów proxy / CASB (jeśli firma monitoruje ruch do popularnych serwisów AI),
warsztaty z zespołami IT, marketingu, developmentu – gdzie i jak faktycznie używają AI w codziennej pracy,
kanał do anonimowego zgłaszania „shadow AI”, który pozwoli bezpiecznie wyciągnąć na światło dzienne nieformalne rozwiązania.
Nie każde użycie ChatGPT czy Copilota musi skończyć jako osobny wpis w rejestrze. W większych organizacjach praktykuje się wpisy na poziomie „klasy użycia” (np. „asystenci programisty”, „asystenci tworzenia treści marketingowych”) z opisem zasad, zamiast setek pojedynczych wpisów dla każdego pracownika.
Krok 6: Wyznacz progi – co trafia do pełnego rejestru, a co tylko do ewidencji uproszczonej
Po pierwszej inwentaryzacji lista „kandydatów do rejestru” bywa długa i chaotyczna. Żeby rejestr nie zmienił się w śmietnik, trzeba ustalić progi:
Poziom 1 – systemy krytyczne / wysokiego ryzyka – pełny wpis, pełna dokumentacja, obowiązkowe przeglądy,
Poziom 2 – systemy istotne, ale niższego ryzyka – uproszczony wpis, okresowy przegląd,
Poziom 3 – użycia masowe, niskiego ryzyka (np. generatywne AI do draftów dokumentów) – rejestrowane w formie zbiorczej (klasy użycia, polityki, zasady), a nie per użytkownik.
Progi można oprzeć na kilku kryteriach: wpływ na decyzje wobec klientów/pracowników, skala użytkowników, rodzaj danych (osobowe, wrażliwe), automatyczność decyzji, stopień zależności biznesu od systemu. Takie podejście utrzymuje rejestr w rozsądnej wielkości i pozwala skupić się na tym, co naprawdę może interesować regulatora.
Krok 7: Ustal cykl aktualizacji i przeglądów okresowych
Inwentaryzacja jednorazowa ma sens tylko jako punkt startu. Dalej potrzebny jest stały rytm:
aktualizacja wpisu przy każdej istotnej zmianie (nowy model, nowe źródło danych, zmiana dostawcy, zmiana kategorii ryzyka),
przeglądy okresowe (np. raz w roku) dla systemów wysokiego i średniego ryzyka,
przegląd przekrojowy raz do roku – porównanie rejestru z portfelem projektów, architekturą IT i budżetami.
Dobrym zabiegiem jest powiązanie rejestru z istniejącymi cyklami: planowaniem budżetu, przeglądem ryzyka operacyjnego, rocznym przeglądem RODO, przeglądami kontraktów z dostawcami. Im więcej „kotwic” w realnych procesach, tym mniejsze ryzyko, że rejestr stanie się martwym dokumentem.
Krok 8: Wbuduj rejestr w procesy zakupowe i projektowe
Żeby rejestr nie wymagał ciągłego „łapania ogona”, trzeba go włączyć w standardowe ścieżki: zakupy, projekty, zmiany w systemach. Praktyczne kroki:
dodanie pytania o komponent AI do formularza zgłoszenia projektu IT / biznesowego,
wymóg konsultacji z funkcją AI governance / compliance przy każdym zakupie rozwiązania podpisanego jako „AI”,
warunek: żaden system z komponentem AI nie może wejść na produkcję bez numeru wpisu w rejestrze (lub decyzji, że nie podlega wpisowi),
checklista „AI / dane osobowe” w procesie due diligence dostawców SaaS.
Dzięki temu nowe systemy same „wpadają” do rejestru w trakcie standardowej ścieżki decyzyjnej. Inwentaryzacja nie przeradza się wtedy w corzne, nerwowe polowanie na zapomniane projekty.
Krok 9: Zaplanuj działania naprawcze dla „legacy AI”
Inwentaryzacja niemal zawsze ujawnia starsze systemy AI, które działają „jak działają”: brak dokumentacji, niejasne dane treningowe, brak właściciela, brak formalnej zgody na przetwarzanie. Zamiast chować je pod dywan, lepiej przygotować uporządkowany plan:
priorytetyzacja: które legacy systemy mają największy wpływ na klientów, decyzje i ryzyko regulacyjne,
mini-audyt: czy da się odtworzyć działanie modelu, dane, metryki, proces decyzyjny,
decyzja: poprawiamy (dokumentacja, nowe dane, nowy model) czy wygaszamy i zastępujemy,
terminy: przypisanie odpowiedzialności i dat granicznych (np. „do końca roku albo zgodnie z nowym standardem, albo wyłączenie”).
Regulator spodziewa się, że w dużych organizacjach będą takie przypadki. Kluczowe jest pokazanie, że istnieje plan ich uporządkowania, a nie ignorowanie problemu.
Krok 10: Przygotuj „pakiet na kontrolę” oparty na rejestrze
Rejestr systemów AI to nie tylko narzędzie dla wewnętrznego porządku. To także główne źródło informacji w trakcie kontroli lub zapytań od regulatora, audytora czy dużego klienta. W praktyce opłaca się przygotować kilka standardowych widoków danych z rejestru:
lista systemów wysokiego ryzyka z krótkim opisem, kategorią według AI Act i statusami ocen,
mapa powiązań: system – proces biznesowy – dane osobowe – jednostka organizacyjna,
zestawienie systemów wpływających na decyzje wobec klientów i pracowników (odmowy, oceny, profilowanie),
lista systemów, dla których wykonano DPIA / AI impact assessment, z datami i wynikami,
rejestr incydentów lub poważnych błędów związanych z AI, powiązanych z konkretnymi wpisami.
Jeśli takie przekroje można wygenerować jednym kliknięciem z rejestru, rozmowa z regulatorem wygląda zupełnie inaczej. Zamiast gorączkowo zbierać informacje z całej organizacji, pokazujesz spójny obraz i ścieżkę dojrzewania nadzoru nad AI.
Najczęściej zadawane pytania (FAQ)
Co to jest rejestr systemów AI w firmie i czym różni się od zwykłej inwentaryzacji IT?
Rejestr systemów AI to uporządkowana lista zastosowań sztucznej inteligencji w firmie wraz z kluczowymi informacjami: gdzie działa dany system, na jakich danych, z jakim celem, kto za niego odpowiada i jakie niesie ryzyka. To narzędzie do zarządzania ryzykiem i ładem AI, a nie tylko techniczny spis narzędzi.
Klasyczna inwentaryzacja IT skupia się na sprzęcie, licencjach i aplikacjach. Rejestr AI idzie dalej – opisuje konkretne zastosowania (np. scoring kredytowy, chatbot HR), rodzaje i źródła danych, rolę człowieka w nadzorze oraz kontekst regulacyjny (AI Act, RODO, prawo pracy). Dzięki temu da się szybko odpowiedzieć regulatorowi, klientowi czy audytorowi, „gdzie i jak” używana jest AI, a nie tylko „jakie mamy programy”.
Czy moja firma ma obowiązek prowadzić rejestr systemów AI według AI Act?
AI Act wprost nie narzuca formy „rejestru wewnętrznego”, ale w praktyce bez takiego narzędzia trudno spełnić wymagania regulacyjne. Użytkownik systemów wysokiego ryzyka (czyli większość firm korzystających z gotowych rozwiązań AI) musi wykazać m.in. zarządzanie ryzykiem, nadzór człowieka, dokumentację i logowanie. Do tego konieczna jest wiedza, jakie systemy AI są w organizacji i jak są używane.
Wewnętrzny rejestr systemów AI staje się więc de facto obowiązkowym elementem ładu AI: pozwala oznaczyć systemy wysokiego ryzyka, wskazać, gdzie przetwarzane są dane osobowe (RODO, DPIA), a także które zastosowania wpływają na relacje pracodawca–pracownik. Bez tego ryzyko niezgodności z AI Act i RODO rośnie lawinowo.
Jak zacząć tworzenie rejestru systemów AI w organizacji krok po kroku?
Na start wystarczą trzy proste kroki. Po pierwsze, zdefiniuj, co w waszej firmie uznajecie za „system AI” (np. używa uczenia maszynowego, generuje rekomendacje lub treści, sam się dostosowuje na bazie danych). Po drugie, zrób przegląd procesów biznesowych i zapytaj zespoły o narzędzia, w których pojawia się AI – zarówno projekty „ML”, jak i funkcje zaszyte w SaaS (CRM, ERP, marketing, HR).
Po trzecie, dla każdego zidentyfikowanego systemu zbierz minimum informacji: właściciel biznesowy, cel użycia, rodzaje danych (czy są dane osobowe), grupa użytkowników, wpływ na klientów/pracowników oraz powiązane regulacje (AI Act, RODO, branżowe standardy). Na tej bazie można później rozbudowywać rejestr o szczegóły techniczne, analizy ryzyka czy wyniki audytów.
Jak rozpoznać, czy dane narzędzie to „system AI”, a nie zwykła automatyzacja?
Pomaga kilka prostych testów. System najpewniej jest AI, jeśli: uczy się na danych (model ML zamiast sztywnych reguł), generuje treści lub rekomendacje (np. scoring, prognozy, rekomendacje produktów, generowanie tekstu/obrazu/kodu) albo sam dopasowuje swoje działanie w czasie bez ręcznej zmiany reguł.
Z kolei makra w Excelu, proste skrypty IF/THEN, workflow „jeśli A to wyślij mail B”, raporty BI bez uczenia się – to zwykle nie będą systemy AI w rozumieniu AI Act. W rejestrze warto więc uwzględnić: generatory (tekst, obraz, kod), moduły predykcyjne w CRM/ERP/HR, systemy antyfraudowe, chatboty, systemy scoringowe, a pominąć czystą automatyzację opartą wyłącznie na sztywnych regułach.
Jakie informacje powinien zawierać dobry rejestr systemów AI, żeby wystarczył na audyt lub kontrolę?
Regulatora czy audytora interesuje nie tylko lista narzędzi, ale spójny obraz zarządzania ryzykiem. W praktyce w rejestrze powinny znaleźć się co najmniej: nazwa i opis systemu, proces biznesowy, właściciel biznesowy i techniczny, dostawca, typy i źródła danych (w tym dane osobowe), główne ryzyka oraz informacje o nadzorze człowieka (kto może nadpisać decyzję systemu).
Dobrze, jeśli rejestr zawiera też odnośniki: do analiz ryzyka (w tym DPIA), polityk i procedur, logów, planów reagowania na incydenty oraz informacji, czy system podpada pod wysokie ryzyko w AI Act. Dzięki temu w trakcie kontroli można w kilka minut pokazać ciągłość: od decyzji o wdrożeniu, przez ocenę ryzyka, aż po bieżący monitoring.
Czy do rejestru AI trzeba wpisywać też funkcje AI w narzędziach typu Copilot, CRM czy ERP?
Tak, jeśli ich działanie spełnia kryteria systemu AI i realnie wpływa na procesy lub ludzi. Sama pozycja na liście licencji „Copilot dla M365, 50 użytkowników” nic nie znaczy dla audytora. W rejestrze trzeba rozbić to na konkretne zastosowania: generowanie kodu, podpowiedzi w dokumentach, przygotowanie ofert, automatyczne odpowiedzi na maile, analizy danych itp.
Każde zastosowanie ma inny dostęp do danych, inny profil ryzyka i innego „odbiorcę” (pracownik, klient, kandydat do pracy). Dlatego w rejestrze opisujemy nie tyle „produkt”, co sposób jego użycia w procesie biznesowym. To później pozwala szybko znaleźć np. wszystkie systemy wykorzystujące dane HR albo wszystkie zastosowania AI, które wpływają na klientów B2B.
Jak rejestr systemów AI pomaga przy wymaganiach RODO i w relacjach B2B z klientami?
RODO wymaga rozliczalności: trzeba umieć pokazać, gdzie i jak przetwarzane są dane osobowe, w tym w profilowaniu, scoringu czy analizach predykcyjnych. Dobrze zbudowany rejestr pozwala jednym filtrem sprawdzić, które systemy AI wykorzystują określone kategorie danych, gdzie potrzebna jest DPIA, kto jest administratorem danych i jak wygląda nadzór człowieka.
W relacjach B2B coraz częściej pojawiają się pytania o governance AI w kwestionariuszach bezpieczeństwa, RFP czy due diligence. Rejestr systemów AI staje się gotowym źródłem danych: można z niego wygenerować zestawienie systemów, ryzyk, środków kontroli i odpowiedzialności. Zamiast tygodniowego „polowania na informacje po mailach” da się odpowiedzieć klientowi w sposób kompletny i spójny.
Co warto zapamiętać
Rejestr systemów AI to fundament ładu AI w firmie: pozwala wskazać właścicieli biznesowych, odpowiedzialność za skutki działania systemów i powiązania między modelami, dostawcami i procesami, zamiast utrzymywać chaos „shadow IT”.
Bez centralnego rejestru organizacja nie jest w stanie realnie spełnić wymogów AI Act, RODO czy prawa pracy, bo nie wie, gdzie dokładnie działa AI, jakie dane przetwarza i jak wpływa na klientów oraz pracowników.
Rejestr AI różni się od zwykłej inwentaryzacji IT – skupia się na zastosowaniach w procesach, typach i źródłach danych, profilu ryzyka, roli człowieka i kontekście regulacyjnym, a nie tylko na liście aplikacji i licencji.
Dobrze zbudowany rejestr porządkuje kluczowe informacje dla działów prawnego, bezpieczeństwa, IOD, risk i audytu, tworząc jedno źródło prawdy do analiz DPIA, ocen ryzyka, aktualizacji polityk i decyzji zarządczych.
Rejestr znacząco ułatwia kontrole regulatora, audyty i due diligence, bo pozwala szybko pokazać pełny obraz: listę systemów AI, właścicieli, opis zastosowań, ryzyka, środki kontroli oraz powiązane dokumenty (np. DPIA, procedury incydentowe).
System AI to nie „funkcja w aplikacji”, ale połączenie modelu, danych, procesu decyzyjnego, wpływu na ludzi i nadzoru człowieka – dlatego w rejestrze trzeba rozbijać ogólne narzędzia (np. Copilot) na konkretne zastosowania o różnym ryzyku.
