# Jak audyt wewnętrzny powinien testować kontrole AI
W wielu organizacjach audyt wewnętrzny otrzymał nowe zadanie: ocenić, czy kontrole AI są realnie skuteczne, a nie tylko formalnie opisane. To wyzwanie jest jakościowo inne od klasycznych audytów IT. W systemach AI istnieje zmienność modeli, zależność od danych i dostawców, ryzyko dryfu oraz luki interpretacyjne między polityką a praktyką operacyjną. Dlatego standardowe checklisty zgodności nie wystarczą.
Zarówno IIA Global Internal Audit Standards (2024), jak i COSO Internal Control - Integrated Framework (2013) oraz NIST AI RMF 1.0 (2023) wskazują potrzebę oceny kontroli w kontekście ryzyka, celu biznesowego i skuteczności działania. W AI oznacza to przejście od audytu dokumentów do audytu dowodów operacyjnych: logów, decyzji, wyjątków, incydentów, jakości danych i ścieżek eskalacji.
Ten playbook pokazuje, jak audyt wewnętrzny może testować kontrole AI w sposób, który pomaga zarządowi podejmować decyzje o skali, remediacji i akceptacji ryzyka. Celem nie jest spowolnienie transformacji, lecz zwiększenie jej sterowalności.
Co odróżnia audyt kontroli AI od klasycznego audytu IT
W tradycyjnym audycie systemowym kontrola często ma charakter binarny: istnieje lub nie istnieje. W AI taka logika jest zbyt uproszczona. Kontrola może formalnie istnieć, ale działać nieskutecznie w określonych segmentach danych, rolach użytkowników lub scenariuszach wyjątków.
Różnice kluczowe: - skuteczność kontroli zależy od jakości danych wejściowych i kontekstu użycia, - część ryzyk materializuje się po wdrożeniu (drift, zmiana zachowań użytkowników), - decyzje modelu bywają probabilistyczne i wymagają oceny progów akceptowalności, - odpowiedzialność jest rozproszona między biznes, IT, data, risk i vendorów.
To oznacza, że audyt musi badać nie tylko design kontroli, ale też jej działanie w czasie.
Zły -> dobry przykład
Zły: audyt ogranicza się do sprawdzenia, czy istnieje polityka AI, rejestr modeli i podpisane role odpowiedzialności. Raport kończy się oceną „kontrole zaprojektowane”, mimo że w operacji rośnie liczba wyjątków i eskalacji jakości.
Dobry: audyt testuje nie tylko istnienie kontroli, ale ich skuteczność na próbkach decyzji i incydentów: czy wyjątki były obsłużone zgodnie z procedurą, czy eskalacje działały w SLA, czy rekomendacje po incydentach zostały wdrożone. Raport zawiera ocenę ryzyka rezydualnego i konkretne działania korygujące z właścicielami oraz terminami.
## Trzy cele audytu AI, które powinien zatwierdzić komitet audytu
Przed rozpoczęciem testów audyt powinien uzgodnić z komitetem audytu trzy cele:
1. **Adekwatność**: czy kontrola odpowiada profilowi ryzyka danego use case'u AI. 2. **Efektywność operacyjna**: czy kontrola działa konsekwentnie i wykrywa odchylenia. 3. **Egzekwowalność odpowiedzialności**: czy istnieje jasna ścieżka właścicieli, decyzji i remediacji.
Bez takiego uzgodnienia audyt łatwo zostaje zredukowany do przeglądu dokumentacji.
Model testowania AIC-T6
Praktyczne podejście do audytu kontroli AI to model AIC-T6 (AI Control Testing, 6 kroków), który można stosować w audytach przekrojowych i tematycznych.
### T1 Scope by risk
Zakres audytu należy zdefiniować według krytyczności use case'ów, a nie według struktury organizacyjnej. Priorytetem są systemy o wysokim wpływie na klienta, finanse, zgodność lub bezpieczeństwo.
### T2 Control inventory and ownership
Audyt tworzy mapę kontroli: prewencyjnych, detekcyjnych, korekcyjnych oraz governance. Każda kontrola musi mieć ownera, częstotliwość działania i oczekiwany dowód.
### T3 Design adequacy testing
Na tym etapie audyt ocenia, czy projekt kontroli jest logicznie wystarczający. Przykład: czy istnieją progi eskalacji błędów, czy human-in-the-loop jest realny, czy warunki przejścia do produkcji są mierzalne.
### T4 Operating effectiveness testing
Najważniejsza faza: test działania kontroli na próbach rzeczywistych decyzji i wyjątków. Obejmuje analizę logów, rejestrów incydentów, ticketów remediacyjnych i czasu zamknięcia działań.
### T5 Outcome and residual risk assessment
Audyt ocenia nie tylko zgodność, ale też ryzyko rezydualne. Kontrola może działać formalnie, a mimo to pozostawiać nieakceptowalny poziom ryzyka biznesowego.
### T6 Remediation and governance follow-through
Wynik audytu powinien kończyć się konkretnym planem naprawczym z terminem, właścicielem i kryterium zamknięcia. Audyt monitoruje postęp remediacji i raportuje opóźnienia do komitetu audytu.
Model AIC-T6 porządkuje pracę audytową i ułatwia porównywanie wyników między jednostkami.
Jak budować próbę audytową w środowisku AI
Próbkowanie jest krytyczne, bo ryzyka AI często są nierównomiernie rozłożone. Losowa próba może nie wykryć problemów w segmentach wysokiego ryzyka. Dlatego audyt powinien łączyć:
- próbę losową (ocena ogólnej stabilności), - próbę celowaną (scenariusze trudne, wyjątki, eskalacje), - próbę czasową (okresy zmian modelu lub wzrostu wolumenu), - próbę podmiotową (różne role użytkowników i różne rynki/jurysdykcje).
To podejście zwiększa szansę wykrycia luk rzeczywiście istotnych dla biznesu.
Jakie dowody powinien akceptować audyt
W audycie AI deklaracje słowne i statyczne polityki to za mało. Silny pakiet dowodowy obejmuje:
- logi decyzji modelu i ścieżki zatwierdzeń człowieka, - historię zmian promptów, reguł, konfiguracji i wersji modeli, - rejestr wyjątków, incydentów i działań korekcyjnych, - metryki jakości i driftu wraz z progami alarmowymi, - dowody szkolenia użytkowników oraz potwierdzenia ról odpowiedzialności, - zapisy testów przedprodukcyjnych i kryteriów przejścia.
W praktyce warto stosować zasadę: każda krytyczna kontrola powinna być audytowalna "od końca do końca", czyli od definicji do śladu operacyjnego.
Typowe luki wykrywane przez audyt wewnętrzny
1. Kontrole istnieją na papierze, ale nie mają przypisanych ownerów operacyjnych. 2. Human-in-the-loop jest formalny, lecz w praktyce zatwierdzenia odbywają się masowo bez review. 3. Brakuje progów, które automatycznie uruchamiają eskalację lub zatrzymanie procesu. 4. Rejestr incydentów nie łączy się z procesem remediacji i aktualizacją kontroli. 5. Zmiany modelu lub dostawcy nie uruchamiają ponownej oceny ryzyka. 6. Metryki jakości są zbierane, ale nie mają skutków decyzyjnych.
Audyt, który identyfikuje te luki wcześnie, zmniejsza koszt późniejszych incydentów.
Scenariusz: kontrola formalna, ryzyko realne
W firmie ubezpieczeniowej wdrożono system AI wspierający ocenę zgłoszeń szkód. Dokumentacja kontroli była kompletna: polityki, role, checklisty i przeglądy miesięczne. W audycie AIC-T6 wykryto jednak, że kluczowa kontrola jakości decyzji działała słabo w jednym segmencie przypadków o wysokiej złożoności.
Problem nie wynikał z braku polityki, lecz z praktyki operacyjnej. Próg eskalacji był ustawiony zbyt wysoko, a zespół review miał niedostateczną przepustowość. W efekcie część spraw przechodziła bez odpowiedniego nadzoru, mimo formalnego modelu human-in-the-loop.
Audyt zalecił korektę progów, rozszerzenie próby review i automatyczne alerty dla segmentu podwyższonego ryzyka. Po dwóch cyklach monitoringu spadła liczba korekt po fakcie i skrócił się czas zamykania wyjątków.
Scenariusz pokazuje, że główna wartość audytu AI polega na wykrywaniu rozjazdu między designem kontroli a rzeczywistym działaniem.
Jak raportować wyniki do zarządu i komitetu audytu
Raport z audytu AI powinien być decyzyjny, nie wyłącznie opisowy. Dobrze działa struktura:
- poziom ryzyka rezydualnego dla każdego krytycznego use case'u, - status kluczowych kontroli (green/amber/red) wraz z uzasadnieniem, - wpływ luk na cele biznesowe i zgodność, - plan remediacji: właściciel, termin, kryterium zamknięcia, - obszary wymagające decyzji zarządu (np. akceptacja ryzyka, dodatkowe inwestycje).
Taka forma ułatwia połączenie audytu z governance i planowaniem inwestycji.
Plan działania audytu na 12 tygodni
### Tygodnie 1-2: Kalibracja ryzyka i zakresu
Wybór krytycznych use case'ów, uzgodnienie celu audytu i mapy interesariuszy.
### Tygodnie 3-5: Inwentaryzacja kontroli i test designu
Budowa mapy kontroli, ownerów i oczekiwanych dowodów; identyfikacja luk projektowych.
### Tygodnie 6-9: Testy efektywności operacyjnej
Analiza prób losowych i celowanych, testy wyjątków, przegląd incydentów oraz czasu remediacji.
### Tygodnie 10-11: Ocena ryzyka rezydualnego i rekomendacje
Kategoryzacja ustaleń według wpływu, przygotowanie planu naprawczego i decyzji zarządczych.
### Tydzień 12: Raport i plan follow-up
Prezentacja wyników komitetowi audytu, uzgodnienie kamieni milowych i harmonogramu retestu.
Co odróżnia dobry audyt AI od audytu pozorowanego
Dobry audyt AI pokazuje, gdzie kontrola nie działa w praktyce i co należy zmienić, aby ryzyko było akceptowalne. Audyt pozorowany potwierdza, że dokumenty istnieją, ale nie potrafi ocenić skuteczności operacyjnej.
Dobry audyt łączy dowody techniczne, procesowe i organizacyjne. Audyt pozorowany rozdziela te światy i przez to traci obraz całości.
Dobry audyt prowadzi do remediacji z właścicielem i terminem. Audyt pozorowany kończy się listą obserwacji bez egzekucji.
W środowisku AI ta różnica decyduje o tym, czy governance chroni firmę, czy jedynie wygląda przekonująco.
