# Rejestr systemów AI: najprostszy pierwszy krok governance
Większość programów AI governance zaczyna od polityk, a kończy na gaszeniu pożarów. Zespoły tworzą dokumenty, ale organizacja nadal nie potrafi odpowiedzieć na podstawowe pytania: jakie systemy AI mamy, kto za nie odpowiada, które są wysokiego ryzyka, gdzie działają i jakie kontrole są aktywne.
Dlatego najprostszy, a jednocześnie najbardziej niedoceniany pierwszy krok to rejestr systemów AI. Nie jest to biurokratyczny dodatek. To operacyjny kręgosłup governance, bez którego zarząd, compliance, security i audyt działają na fragmentach informacji.
EU AI Act (2024) wzmacnia potrzebę uporządkowanego podejścia do identyfikacji i klasyfikacji systemów AI. NIST AI RMF 1.0 (2023), ISO/IEC 42001:2023 i ISO/IEC 23894:2023 również podkreślają znaczenie systematycznego zarządzania ryzykiem w całym cyklu życia. Rejestr to narzędzie, które łączy te wymagania z praktyką codziennego działania.
Czym jest rejestr systemów AI i czym nie jest
Rejestr systemów AI to aktualny, zarządzany katalog rozwiązań AI używanych, testowanych lub planowanych w organizacji. Obejmuje zarówno rozwiązania budowane wewnętrznie, jak i usługi vendorów osadzone w produktach, procesach lub narzędziach pracy.
Rejestr nie jest jednorazowym arkuszem do audytu. Jeśli powstaje tylko na potrzeby kontroli, szybko traci aktualność. Nie jest też listą eksperymentów bez ownera i statusu. Działa dopiero wtedy, gdy jest powiązany z decyzjami o ryzyku, produkcji, zakupach i wyjątkach.
Dlaczego rejestr jest pierwszym krokiem governance
Pierwszy powód to widoczność. Organizacje zaskakująco często nie wiedzą, ile systemów AI realnie działa poza centralnym programem transformacji. Bez rejestru powstaje shadow AI governance: narzędzia istnieją, ale nie są monitorowane.
Drugi powód to odpowiedzialność. Rejestr wymusza przypisanie ownera biznesowego i ownera technicznego. To fundament łańcucha accountability.
Trzeci powód to priorytetyzacja ryzyka. Nie każde rozwiązanie wymaga tego samego rygoru. Rejestr pozwala klasyfikować systemy i kierować zasoby kontrolne tam, gdzie potencjalny wpływ jest największy.
Czwarty powód to gotowość audytowa. Audyt i compliance nie mogą opierać się na deklaracjach ad hoc. Potrzebują spójnego źródła prawdy, które pokazuje status kontroli, wyjątki i historię zmian.
Minimalny zakres rejestru: 14 pól obowiązkowych
Wiele organizacji przegrywa na starcie, bo próbuje zebrać 80 pól i idealną metadokumentację. Lepiej zacząć od zestawu minimalnego, który wystarczy do decyzji.
1. Unikalny identyfikator systemu AI. 2. Nazwa i krótki opis zastosowania. 3. Jednostka biznesowa i proces, którego dotyczy. 4. Owner biznesowy (accountable). 5. Owner techniczny (responsible). 6. Dostawca / model / komponent krytyczny. 7. Typ danych wejściowych i wrażliwość danych. 8. Grupa odbiorców i skala użycia. 9. Klasyfikacja ryzyka (wstępna). 10. Status cyklu życia (pomysł, pilot, produkcja, wycofanie). 11. Wymagane kontrole i ich status. 12. Otwarta lista wyjątków oraz daty przeglądu. 13. Data ostatniej aktualizacji i osoba aktualizująca. 14. Powiązane incydenty lub alerty jakości.
Ten zakres jest wystarczający, aby połączyć rejestr z zarządzaniem ryzykiem i operacjami.
Jak klasyfikować systemy bez paraliżu
Klasyfikacja nie powinna być akademicką debatą. Ma być narzędziem działania. Sprawdza się trzystopniowa skala: niskie, podwyższone, wysokie ryzyko, oparta na potencjalnym wpływie na prawa osób, decyzje finansowe, bezpieczeństwo, zgodność regulacyjną i reputację.
Wysokie ryzyko wymaga pełnej ścieżki kontroli przed produkcją i częstego przeglądu po wdrożeniu. Podwyższone ryzyko wymaga kontroli proporcjonalnych i regularnego monitoringu. Niskie ryzyko może korzystać z uproszczonej ścieżki, ale nadal pozostaje widoczne w rejestrze.
Kluczowe jest to, by klasyfikacja była aktualizowana. System może zmienić profil ryzyka wraz ze zmianą danych, skali użytkowników, funkcji produktu lub dostawcy modelu.
Ownership i rytm operacyjny
Rejestr umiera, gdy nie ma właściciela procesu. Potrzebne są trzy role.
Owner procesu rejestru odpowiada za standard pól, jakość danych i terminowość aktualizacji. Ownerzy systemów odpowiadają za merytoryczną poprawność wpisów. Funkcje kontrolne (risk, compliance, audit) weryfikują, czy statusy i wyjątki odpowiadają rzeczywistości.
Rytm minimalny to miesięczna aktualizacja statusu systemów i kwartalny przegląd pełnego portfela. Dla systemów wysokiego ryzyka warto stosować rytm częstszy, na przykład comiesięczny review wyjątków i incydentów.
Integracja z istniejącymi procesami
Najczęstszy błąd to traktowanie rejestru jako osobnego bytu. Rejestr powinien być spięty z czterema procesami.
Pierwszy to intake nowych inicjatyw AI. Każdy nowy pomysł trafia do rejestru przed pilotażem.
Drugi to procurement i vendor due diligence. Jeśli zespół kupuje nowe narzędzie AI, wpis do rejestru powinien powstać automatycznie.
Trzeci to gate review przed produkcją. Brak pełnego wpisu i statusu kontroli powinien blokować przejście.
Czwarty to incident management. Każdy istotny incydent AI musi mieć powiązanie z rekordem w rejestrze, aby decyzje naprawcze były śledzalne.
Scenariusz: jak rejestr obniżył ryzyko operacyjne
Międzynarodowa firma usługowa wdrożyła centralny program GenAI, ale po pół roku wykryła duże rozbieżności: zespoły lokalne używały dodatkowych narzędzi, których centrala nie monitorowała. W jednym kraju narzędzie do klasyfikacji zgłoszeń pracowało na danych wrażliwych bez pełnej walidacji dostawcy.
Po uruchomieniu rejestru 14-polowego i wpięciu go w zakup oraz gate review firma zidentyfikowała 37 systemów AI, z czego 11 wcześniej niewidocznych. Trzy systemy otrzymały status wysokiego ryzyka i zostały objęte dodatkowym monitoringiem. W kolejnym kwartale spadła liczba wyjątków krytycznych, a audyt wewnętrzny skrócił czas przygotowania materiałów kontrolnych.
Wartość rejestru nie polegała na „pięknej tabeli”. Polegała na tym, że organizacja odzyskała kontrolę nad tym, co naprawdę działa w środowisku produkcyjnym.
Plan wdrożenia rejestru w 60 dni
Dni 1-15: ustal definicję systemu AI, zakres rejestru i minimalne pola. Wyznacz ownera procesu oraz sponsorstwo na poziomie governance.
Dni 16-30: przeprowadź inwentaryzację inicjalną przez jednostki biznesowe i IT. Nie dąż do perfekcji danych, dąż do pełnego pokrycia.
Dni 31-45: uruchom klasyfikację ryzyka i przypisz wymagane kontrole. Wprowadź status wyjątków oraz daty kolejnych przeglądów.
Dni 46-60: zintegruj rejestr z intake, zakupami i gate review. Przeprowadź pierwszy formalny przegląd portfela z udziałem risk/compliance.
Po 60 dniach rejestr powinien działać operacyjnie, nawet jeśli część pól będzie nadal dojrzewać.
Najczęstsze błędy i jak ich uniknąć
Błąd pierwszy: przesadna szczegółowość na starcie. Rozwiązanie: zacznij od zakresu minimalnego i iteruj.
Błąd drugi: brak automatycznych punktów aktualizacji. Rozwiązanie: podłącz rejestr do procesów, które i tak mają formalne bramki.
Błąd trzeci: brak odpowiedzialności biznesowej. Rozwiązanie: każdy rekord musi mieć ownera biznesowego, nie tylko technicznego.
Błąd czwarty: traktowanie klasyfikacji ryzyka jako jednorazowej. Rozwiązanie: cykliczny review i reclass przy zmianie funkcji lub skali.
Błąd piąty: brak użycia rejestru w realnych decyzjach. Rozwiązanie: warunkuj przejście do produkcji kompletnością wpisu i statusem kontroli.
Rejestr jako podstawa współpracy z audytem i kontrolą wewnętrzną
Dobrze zaprojektowany rejestr upraszcza pracę audytu wewnętrznego, bo skraca drogę od pytania kontrolnego do dowodu. Zamiast budować materiał „na żądanie”, organizacja utrzymuje stale aktualizowany obraz systemów AI, ich ownerów, kontroli i wyjątków. To zmniejsza koszt przygotowania audytu i ogranicza ryzyko niespójnych odpowiedzi między jednostkami.
Rejestr pomaga też funkcji kontroli wewnętrznej przejść z trybu reaktywnego do trybu planowego. Jeśli widać, gdzie kumulują się wyjątki krytyczne lub opóźnienia remediacji, można wcześniej zaplanować przegląd i wsparcie dla zespołów, zanim pojawi się incydent.
W praktyce oznacza to, że rejestr powinien zawierać nie tylko status „jest kontrola/nie ma kontroli”, ale także datę ostatniego testu skuteczności oraz właściciela dowodu. Bez tego audyt widzi deklarację, ale nie widzi wiarygodnej ścieżki potwierdzenia.
Jak utrzymać jakość danych w rejestrze
Jakość rejestru nie bierze się z jednorazowego porządkowania arkusza. Potrzebny jest prosty mechanizm data quality: reguły walidacji, cykliczne przeglądy i konsekwencja odpowiedzialności.
Reguły walidacji powinny wyłapywać pola krytyczne: brak ownera, brak klasyfikacji ryzyka, nieaktualną datę przeglądu i otwarte wyjątki bez terminu zamknięcia. Taki zestaw reguł można wdrożyć nawet przy prostych narzędziach.
Przegląd jakości powinien odbywać się minimum raz w miesiącu i kończyć listą korekt z przypisaniem ownerów. Najważniejsze jest, by korekty były domykane, a nie tylko notowane.
Wreszcie, warto publikować wskaźnik kompletności rejestru na poziomie jednostek biznesowych. Gdy jakość danych staje się widoczna, rośnie odpowiedzialność lokalna i spada pokusa odkładania aktualizacji „na później”.
Executive Takeaway
Co się zmieniło? Rejestr systemów AI to najprostszy i najbardziej praktyczny pierwszy krok governance, bo daje organizacji widoczność, ownership i podstawę do proporcjonalnego zarządzania ryzykiem.
Dlaczego to ważne? Największy efekt daje minimalny, 14-polowy zakres danych zintegrowany z intake, zakupami, gate review i incident management, zamiast jednorazowej tabeli tworzonej pod audyt.
Co liderzy powinni zrobić? Wdrożenie w 60 dni jest realne, jeśli firma zaczyna od pełnego pokrycia i jasnych ról, a dopiero później doskonali szczegółowość i automatyzację rejestru.


