Audytor wewnętrzny prosi o dwie rzeczy: listę systemów AI, z których korzysta firma, i nazwisko osoby, która zatwierdziła każdy z nich. IT zna narzędzia kupione centralnie, marketing płaci za generator treści prywatną kartą, a obsługa klienta testuje chatbota dostawcy. Zebranie odpowiedzi trwa tydzień i nadal nie wiadomo, czy lista jest kompletna.
Tak wygląda firma, która ma politykę korzystania z AI, ale nie ma AI governance. Polityka mówi, co wolno. Governance odpowiada na pytania, kto decyduje, na podstawie jakiej oceny i jaki ślad zostaje po decyzji. Pokazujemy minimalny model, który da się uruchomić bez budowania nowego działu: role, rejestr systemów AI, proces zatwierdzania i mierniki.
Czym jest AI governance i czym różni się od polityki AI i ram ryzyka?
AI governance to system decyzji i odpowiedzialności za sztuczną inteligencję w firmie: określa, kto zatwierdza użycie AI, na podstawie jakiej oceny, z jakim dowodem i jak decyzja jest później monitorowana. Obejmuje role, rejestr systemów AI, proces zatwierdzania i nadzór nad systemami w trakcie ich działania.
Polityka AI to jeden z dokumentów tego systemu. Opisuje zasady dla użytkowników: jakie narzędzia są dozwolone, jakich danych nie wolno wpisywać w prompty, jak weryfikować wyniki. Elementy dobrej polityki omawia artykuł polityka AI w firmie. Governance sprawia, że polityka ma właściciela, jest egzekwowana i aktualizowana.
Rama ryzyka to z kolei metoda oceny. Pokazuje, jakie zagrożenia analizować i jak je mierzyć — na przykład w przypadku modeli językowych robi to framework oceny ryzyka LLM. Governance decyduje, kiedy taka ocena jest obowiązkowa, kto ją wykonuje i kto akceptuje ryzyko rezydualne.
Warto też odróżnić governance od pojęcia AI safety, które dotyczy tego, czy sam system AI działa bezpiecznie i zgodnie z zamierzeniem. Governance jest warstwą organizacyjną nad tą oceną. W modelu nFlo jest częścią filaru Ład, ryzyko i zgodność, obok ładu w obszarze cyberbezpieczeństwa i ochrony danych.
Kto odpowiada za AI w firmie?
Za AI w firmie odpowiada zarząd, który akceptuje poziom ryzyka, oraz właściciel każdego systemu AI, który odpowiada za jego cel, dane i wyniki; pozostałe role doradzają i kontrolują. Dział IT nie powinien być właścicielem systemu tylko dlatego, że go uruchomił.
NIST w dokumencie „AI Risk Management Framework (AI RMF 1.0)”, opublikowanym 26 stycznia 2023 r., wskazuje, że kierownictwo najwyższego szczebla bierze odpowiedzialność za decyzje o ryzyku związanym z rozwojem i wdrażaniem systemów AI (kategoria GOVERN 2.3). Ten sam dokument wymaga, by role i odpowiedzialności były udokumentowane i jasne dla zespołów (GOVERN 2.1).
W typowej firmie model obejmuje kilka ról. Zarząd zatwierdza politykę i akceptuje ryzyko wysokie. Właściciel systemu AI, zwykle kierownik obszaru biznesowego, zgłasza potrzebę i odpowiada za użycie. Komitet lub forum AI przegląda wnioski i rozstrzyga przypadki sporne. CISO ocenia bezpieczeństwo, inspektor ochrony danych — przetwarzanie danych osobowych, dział prawny i zgodności — obowiązki regulacyjne, a dział zakupów pilnuje warunków umów z dostawcami.
Każda czynność musi mieć jedną osobę rozliczalną. OWASP w dokumencie „LLM AI Cybersecurity & Governance Checklist” (wersja 1.1 z 7 maja 2024 r.) wprost zaleca przygotowanie macierzy RACI dla AI — rozpisujemy ją w tabeli w dalszej części artykułu.
Jak zbudować rejestr systemów AI?
Rejestr systemów AI buduje się jako jedną listę wszystkich systemów wytwarzanych, kupowanych i stosowanych w firmie, z minimalnym zestawem pól, który pozwala ocenić ryzyko i przypisać obowiązki. Rejestr jest punktem wyjścia dla każdej innej decyzji: nie da się sklasyfikować ani zabezpieczyć systemu, o którym nikt nie wie.
NIST AI RMF wymienia inwentaryzację systemów AI jako osobny wynik funkcji GOVERN (GOVERN 1.6), a lista kontrolna OWASP zaleca katalogowanie usług, narzędzi i właścicieli AI oraz źródeł danych wraz z ich wrażliwością. Do rejestru trafiają też funkcje AI dodane przez dostawców do istniejących narzędzi SaaS. Te najczęściej umykają, bo nie przechodzą przez proces zakupu.
Minimalny zestaw pól rejestru wygląda tak:
| Pole | Co zawiera | Po co |
|---|---|---|
| Cel i zakres użycia | Do czego system służy i kto z niego korzysta | Ocena, czy użycie mieści się w zatwierdzonym celu |
| Dostawca i model | Kto dostarcza system lub model, w jakiej wersji | Ocena dostawcy, warunki umowy, zmiany wersji |
| Rola wg AI Act | Dostawca, podmiot stosujący albo inna rola | Przypisanie właściwych obowiązków |
| Kategoria ryzyka | Praktyka zakazana, wysokie ryzyko, przejrzystość, minimalne | Zakres obowiązków i terminów |
| Dane | Kategorie danych na wejściu i wyjściu, dane osobowe | Ocena RODO, klasyfikacja informacji |
| Właściciel | Osoba rozliczalna z obszaru biznesowego | Jedna osoba odpowiedzialna za decyzje |
| Ocena bezpieczeństwa | Data i wynik przeglądu lub testu | Dowód, że ryzyko zostało ocenione |
| DPIA / FRIA | Czy wymagana i czy wykonana | Dowód spełnienia obowiązków oceny skutków |
| Status | Zgłoszony, zatwierdzony, w użyciu, wycofany | Kontrola cyklu życia systemu |
Rejestr nie musi zaczynać się od specjalistycznego narzędzia. Arkusz z tymi polami i jasno wskazanym właścicielem działa lepiej niż platforma, której nikt nie aktualizuje. Ważniejsze jest źródło zasilania: rejestr powinien uzupełniać się z zakupów, procesu zatwierdzania i przeglądów, a nie z jednorazowej ankiety.
Jak wygląda proces zatwierdzania nowego systemu AI?
Proces zatwierdzania nowego systemu AI składa się z siedmiu etapów: zgłoszenia, klasyfikacji, oceny ryzyka i danych, przeglądu bezpieczeństwa, decyzji, monitorowania i wycofania. Każdy etap ma właściciela i zostawia zapis w rejestrze, dzięki czemu po roku da się odtworzyć, kto i dlaczego zgodził się na użycie systemu.
Zgłoszenie składa właściciel biznesowy: opisuje cel, użytkowników, dane i dostawcę. Klasyfikacja ustala rolę firmy i kategorię ryzyka według AI Act oraz to, czy system przetwarza dane osobowe. Od klasyfikacji zależy głębokość dalszej oceny. Narzędzie streszczające publiczne dokumenty nie wymaga tej samej ścieżki co system oceniający kandydatów do pracy.
Ocena ryzyka i danych obejmuje skutki dla osób, ochronę danych i warunki umowy z dostawcą: miejsce przetwarzania, wykorzystanie danych do trenowania, okres przechowywania. Przegląd bezpieczeństwa sprawdza konta i uprawnienia, integracje, logowanie oraz — w przypadku aplikacji opartych na modelach językowych i agentach — podatność na nadużycia. Kontrole techniczne dla całego środowiska opisuje przewodnik bezpieczeństwo środowisk AI w firmie.
Decyzja zapada na poziomie odpowiednim do ryzyka: właściciel i CISO dla ryzyka niskiego, komitet AI dla średniego, zarząd dla wysokiego. Zatwierdzony system jest monitorowany, a przegląd powtarza się przy istotnej zmianie. Ostatni etap, wycofanie, bywa pomijany — tymczasem NIST AI RMF wymienia procedury bezpiecznego wycofywania systemów AI jako osobny element governance (GOVERN 1.7).
Najważniejsze:
- AI governance odpowiada na pytania: kto decyduje, na podstawie jakiej oceny i jaki ślad zostaje po decyzji.
- Właścicielem systemu AI jest biznes; IT, bezpieczeństwo, IOD i dział prawny doradzają i kontrolują.
- Rejestr obejmuje także funkcje AI włączane przez dostawców w kupionych narzędziach.
- Proces zatwierdzania kończy się wycofaniem systemu, a nie decyzją o jego uruchomieniu.
Jak AI governance łączy się z obowiązkami AI Act?
AI governance jest mechanizmem, przez który firma realizuje obowiązki z Rozporządzenia (UE) 2024/1689 (AI Act): rejestr pokazuje, które systemy podlegają przepisom, a proces zatwierdzania przypisuje obowiązki i terminy. Bez rejestru firma nie wie, czy w rozumieniu AI Act jest dostawcą, czy podmiotem stosującym, ani które z jej systemów są systemami wysokiego ryzyka.
Rola ma znaczenie, bo od niej zależą obowiązki. Zgodnie z art. 3 pkt 4 AI Act podmiot stosujący to podmiot, który wykorzystuje system AI, nad którym sprawuje kontrolę. Większość firm jest właśnie w tej roli wobec kupionych narzędzi. Dla systemów wysokiego ryzyka art. 26 nakłada na podmioty stosujące m.in. obowiązek korzystania z systemu zgodnie z instrukcją, powierzenia nadzoru człowieka osobom z niezbędnymi kompetencjami i uprawnieniami oraz monitorowania działania systemu.
Część obowiązków przekłada się wprost na pola rejestru. Art. 26 ust. 6 wymaga przechowywania automatycznie generowanych rejestrów zdarzeń, które są pod kontrolą podmiotu stosującego, przez co najmniej sześć miesięcy. Art. 26 ust. 7 nakazuje pracodawcom poinformować pracowników i ich przedstawicieli przed użyciem systemu wysokiego ryzyka w miejscu pracy. Art. 26 ust. 9 łączy AI Act z oceną skutków dla ochrony danych z art. 35 RODO.
Art. 27 wymaga oceny skutków dla praw podstawowych (FRIA) przed użyciem systemu wysokiego ryzyka tylko od wskazanych podmiotów stosujących: podmiotów prawa publicznego, podmiotów prywatnych świadczących usługi publiczne oraz stosujących systemy do oceny zdolności kredytowej i do ustalania cen ubezpieczeń na życie i zdrowotnych. Art. 49 ust. 3 wymaga rejestracji w bazie UE od podmiotów stosujących, które są organami publicznymi. Dlatego pole „DPIA / FRIA” w rejestrze odpowiada na pytanie, czy ocena jest wymagana, a nie tylko czy ją wykonano.
Według stanu na 10 listopada 2026 r. obowiązki dla systemów wysokiego ryzyka z załącznika III stosuje się od 2 grudnia 2027 r., a dla systemów z załącznika I — od 2 sierpnia 2028 r. (art. 113 AI Act po zmianie Rozporządzeniem (UE) 2026/1744). Pełną oś czasu i polską ustawę o systemach sztucznej inteligencji omawia artykuł AI Act 2026: harmonogram obowiązków. Tekst rozporządzenia jest dostępny w EUR-Lex.
Jak wykorzystać NIST AI RMF i ISO/IEC 42001 w governance AI?
NIST AI RMF warto wykorzystać jako mapę tego, co governance ma obejmować, a ISO/IEC 42001 — jako ramę systemu zarządzania, jeśli firma chce go sformalizować lub certyfikować. Oba są dobrowolne i nie zastępują obowiązków prawnych, ale porządkują pracę.
NIST AI RMF dzieli zarządzanie ryzykiem AI na cztery funkcje: GOVERN, MAP, MEASURE i MANAGE. GOVERN jest według dokumentu funkcją przekrojową, która przenika pozostałe trzy: ustanawia kulturę, role, polityki i procesy. MAP ustala kontekst i ryzyka konkretnego systemu, MEASURE je ocenia, a MANAGE decyduje o reakcji. Dla zespołu budującego governance najbardziej użyteczna jest lista kategorii GOVERN, bo przekłada się na konkretne zapisy: inwentaryzację, role, odpowiedzialność kierownictwa, ryzyko stron trzecich.
NIST opublikował też 26 lipca 2024 r. profil dla generatywnej AI (NIST AI 600-1), który pomaga zidentyfikować ryzyka specyficzne dla tych systemów. Na stronie ramy NIST informuje, że AI RMF 1.0 jest w trakcie rewizji, więc odwołując się do niego w dokumentacji, warto podawać wersję.
ISO/IEC 42001 to norma systemu zarządzania sztuczną inteligencją. Firma, która ma już system zarządzania bezpieczeństwem informacji zgodny z ISO/IEC 27001, może wykorzystać istniejące procesy: przeglądy kierownictwa, audyty wewnętrzne, zarządzanie dokumentacją. Model opisany w tym artykule — role, rejestr i proces zatwierdzania — jest dobrym punktem wyjścia, niezależnie od późniejszej decyzji o certyfikacji.
Jak mierzyć skuteczność AI governance?
Skuteczność AI governance mierzy się tym, czy rejestr jest kompletny i aktualny, czy decyzje zapadają w przewidywalnym czasie i czy każdy system w użyciu ma ocenę odpowiednią do swojego ryzyka. Liczba przyjętych polityk mierzy pracę, a nie efekt.
Pierwszy miernik to kompletność rejestru, sprawdzana przez porównanie z innymi źródłami: fakturami za usługi chmurowe, listą aplikacji z dostępem do katalogu tożsamości, wynikami wykrywania nieautoryzowanych narzędzi. Każdy system znaleziony poza rejestrem to sygnał, że proces zatwierdzania jest omijany.
Drugi miernik to czas od zgłoszenia do decyzji. Jeśli zatwierdzenie trwa zbyt długo, pracownicy zaczynają korzystać z narzędzi bez zgody i powstaje shadow AI. Trzeci to odsetek systemów w użyciu, które mają aktualną ocenę ryzyka i bezpieczeństwa, oraz liczba systemów z przeterminowanym przeglądem.
Warto też śledzić wycofania: jeśli długo żaden system nie został wycofany, rejestr zawiera zapewne narzędzia, z których nikt nie korzysta, a które nadal mają dostęp do danych. Mierniki przedstawiane zarządowi powinny pokazywać trend, a nie pojedynczy stan.
Jak rozpisać role w AI governance?
Role w AI governance najlepiej rozpisać w macierzy RACI, w której każda czynność ma dokładnie jedną osobę rozliczalną (A), wykonawcę (R) oraz role konsultowane (C) i informowane (I). Nazwy ról w poniższej macierzy można dopasować do firmy, ale zasada jednej osoby rozliczalnej powinna zostać.
| Czynność | Zarząd | Właściciel systemu | Komitet AI | CISO | IOD | Prawny i zgodność | Zakupy |
|---|---|---|---|---|---|---|---|
| Przyjęcie polityki AI i apetytu na ryzyko | A | I | R | C | C | C | I |
| Zgłoszenie nowego systemu AI | I | A/R | I | I | I | I | C |
| Klasyfikacja wg AI Act i rola firmy | I | C | A | C | C | R | I |
| Ocena danych osobowych i DPIA | I | C | I | C | A/R | C | I |
| Przegląd bezpieczeństwa i testy | I | C | I | A/R | I | I | I |
| Ocena dostawcy i warunki umowy | I | C | I | C | C | C | A/R |
| Decyzja o użyciu systemu wysokiego ryzyka | A | R | C | C | C | C | I |
| Prowadzenie rejestru systemów AI | I | R | A | C | C | C | C |
| Przegląd okresowy i wycofanie | I | A/R | C | C | C | C | I |
Najczęstszy błąd to wpisanie komitetu jako osoby rozliczalnej za wszystko. Komitet przegląda i rozstrzyga, ale za cel i wynik systemu odpowiada jego właściciel, a za ryzyko wysokie — zarząd. Drugi błąd to brak działu zakupów w macierzy, przez co funkcje AI wchodzą do firmy razem z odnowieniem licencji, bez żadnej oceny.
Jak nFlo może pomóc w budowie AI governance?
nFlo w ramach usługi gotowość na AI Act i governance AI pomaga zinwentaryzować systemy AI, sklasyfikować je według AI Act, przypisać role i obowiązki oraz zaprojektować proces oceny nowych systemów. Pracę zaczynamy od rejestru, bo od niego zależą wszystkie kolejne decyzje.
Efektem jest rejestr systemów AI z kategorią ryzyka i rolą firmy dla każdego z nich, analiza luk wobec obowiązków i terminów, macierz odpowiedzialności oraz opis procesu zatwierdzania, który da się utrzymać. Interpretacja przepisów w konkretnej sprawie wymaga porady prawnej, dlatego chętnie współpracujemy z kancelarią klienta. Więcej o podejściu do tego obszaru znajdziesz na stronie bezpieczeństwa AI i w bazie wiedzy o bezpieczeństwie AI.
Jeśli chcesz uporządkować odpowiedzialność za AI w firmie, skontaktuj się z nami.
Co jeszcze warto wiedzieć o AI governance?
Czy mała firma potrzebuje komitetu AI?
Nie musi to być osobny komitet. W mniejszej organizacji wystarczy cykliczne spotkanie właściciela biznesowego, osoby odpowiedzialnej za bezpieczeństwo i inspektora ochrony danych, które przegląda rejestr i rozstrzyga o nowych narzędziach. Ważne, by decyzje były zapisywane.
Czy funkcje AI w kupionym oprogramowaniu też trafiają do rejestru?
Tak. Funkcja AI dodana do narzędzia SaaS przetwarza dane firmy tak samo jak osobny system. Rejestr powinien obejmować systemy wytwarzane, kupowane i stosowane, w tym funkcje AI włączane przez dostawców w istniejących narzędziach.
Czy AI governance wymaga certyfikacji ISO/IEC 42001?
Nie. ISO/IEC 42001 opisuje system zarządzania sztuczną inteligencją i można go certyfikować, ale AI Act nie wymaga certyfikatu tej normy. Wiele firm zaczyna od rejestru, ról i procesu zatwierdzania, a decyzję o certyfikacji podejmuje później.
Kto powinien być właścicielem systemu AI?
Właścicielem powinien być kierownik obszaru biznesowego, który korzysta z systemu i odpowiada za jego wyniki, a nie dział IT. IT i bezpieczeństwo doradzają i kontrolują, ale decyzja o celu, danych i akceptacji ryzyka należy do biznesu.
Jak często przeglądać rejestr systemów AI?
Przy każdej istotnej zmianie systemu oraz cyklicznie, w rytmie przeglądów ryzyka w firmie. Przegląd sprawdza, czy klasyfikacja, właściciel, dane i zabezpieczenia są aktualne i czy system nie powinien zostać wycofany.
