Podczas przerwy między projektami miałam wreszcie przestrzeń, żeby nadrobić zaległości: obejrzałam na Netflixie serial „Heweliusz” oraz odsłuchałam podcast Polskiego Radia „Heweliusz. Prawdziwa historia”. I choć to opowieść o katastrofie morskiej z 1993 roku, w głowie cały czas układała mi się w jedno z wdrożeniami sztucznej inteligencji w firmach: nie z samą technologią, ale z mechanizmem, który prowadzi do katastrof.
Dlaczego prognoza nic nie mówiła o sztormie? Dlaczego prom wypłyną z uszkodzona furtą? Czy prawdziwe są doniesienia o nieprawnym układzie stabilizacji przechyłów, który niezgodnie z przepisami od lat wykorzystywano również na morzu, choć był obliczony tylko na prace w porcie?
redaktor Roman Czejarek – Polskie Radio „Heweliusz. Prawdziwa historia”
W compliance mówimy o tym krótko: katastrofy rzadko mają jedną przyczynę. To zwykle łańcuch drobnych zaniedbań, normalizowanych odstępstw i decyzji „na skróty”, które z osobna wydają się „do obrony”, a razem tworzą scenariusz nieunikniony.
Dlatego ten tekst jest o AI Governance, a nie o historii. AI Act i ISO/IEC 42001 nie powstały po to, żeby „spowolnić innowacje”, tylko żeby organizacje miały procedury, dowody i mechanizmy kontroli ryzyka zanim coś pójdzie źle, oraz żeby potrafiły reagować, gdy jednak pójdzie. AI Act wprost opiera compliance dla systemów wysokiego ryzyka o takie elementy jak zarządzanie danymi, logowanie, kontrola zmian, oceny, monitoring po wdrożeniu i raportowanie incydentów. ISO/IEC 42001 daje natomiast ramę systemową: polityki, procesy, role, cykl doskonalenia i spójny nadzór nad AI w całej organizacji.
Poniżej przedstawiam „10 lekcji” w formie, którą możesz wykorzystać w komunikacji z biznesem: zaniedbanie → analogia AI → pytanie kontrolne dla menedżera.
Lekcja 1: Normalizacja prowizorki kończy się tym, że prowizorka staje się standardem
W podcaście pada wprost wątek statku „znanego z awarii i prowizorycznych napraw”. W organizacjach z AI to wygląda podobnie: „model czasem halucynuje”, „filtr nie zawsze działa”, „logi mamy częściowo”, ale „na razie wystarczy, bo biznes potrzebuje już”.
W AI Act to się zemści — bo zgodność ma być wykazywalna, a nie deklaratywna (m.in. dokumentacja i rejestrowanie zdarzeń).
Pytanie kontrolne: Czy mamy zdefiniowane, które niezgodności są blokujące (release blocking) i kto formalnie akceptuje ryzyko, gdy „działa, ale nieidealnie”?
Lekcja 2: Zmiana parametru krytycznego bez rekwalifikacji to proszenie się o utratę stateczności
W AI „zmianą konstrukcyjną” bywa wymiana modelu, fine-tuning, zmiana danych treningowych, nowa integracja lub zmiana promptów systemowych. AI Act wymaga procedur zarządzania modyfikacjami w ramach systemu zarządzania jakością po stronie dostawców systemów wysokiego ryzyka.
Pytanie kontrolne: Czy każda istotna zmiana modelu/danych/integracji uruchamia u nas ponowną ocenę ryzyka, testy i aktualizację dokumentacji?
Lekcja 3: Presja czasu i „krótsza trasa” to klasyczny mechanizm wypadków — także w IT
Podcast pokazuje presję, skróty i decyzje podejmowane w warunkach napięcia operacyjnego (wątek „czy winna była tylko pogoda” kontra szerszy łańcuch przyczyn i decyzji).
W AI to najczęściej wygląda tak: pomijamy przegląd prawny, bezpieczeństwa, DPIA/ocenę skutków, bo „start kampanii” albo „konkurencja już ma”.
Pytanie kontrolne: Co jest u nas „mocną bramą” przed produkcją i czy biznes wie, że są elementy niepomijalne?
Lekcja 4: Brak zasady „stop/go” powoduje, że statek wypływa mimo czerwonych flag
AI Act kładzie nacisk na wykazywalną zgodność: procedury oceny, dokumentację, logi, a także gotowość do współpracy z organami nadzoru. To jest język „stop/go”: jeśli nie ma dowodów i kontroli — nie wypuszczamy na rynek / nie uruchamiamy.
Pytanie kontrolne: Czy mamy formalny komitet/rolę, która ma mandat powiedzieć „stop” wdrożeniu AI, nawet jeśli projekt jest „strategiczny”?
Lekcja 5: Źle zabezpieczony „ładunek” robi szkody zanim ktokolwiek zdąży zareagować
W świecie AI „ładunek” to dane, uprawnienia, integracje i kanały wyjścia (output). AI Act wymaga m.in. uporządkowanych procedur zarządzania danymi w ramach QMS (systemu zarzadzania jakością) dla systemów wysokiego ryzyka.
Pytanie kontrolne: Czy wiemy, jakie dane trafiają do modelu, gdzie są przetwarzane, kto ma dostęp, i czy mamy kontrolę nad tym, co system może ujawnić w odpowiedzi?
Lekcja 6: „Bezpiecznik” nie zastąpi systemu zarządzania ryzykiem
W organizacjach często widzę wiarę w pojedyncze zabezpieczenie: „mamy filtr treści”, „mamy klauzulę w regulaminie”, „mamy ogólną politykę AI”. ISO/IEC 42001 jest dokładnie po to, by zabezpieczenia nie były wyspami, tylko elementami systemu: polityk, ról, procesów i ciągłego doskonalenia.
Pytanie kontrolne: Czy nasze zabezpieczenia AI są częścią spójnego systemu (właściciele, przeglądy, mierniki, audyty), czy tylko „łatami” do prezentacji?
Lekcja 7: Ludzie bez przygotowania robią to, co naturalne — i organizacja płaci rachunek
W AI Act pojawia się bardzo praktyczny wymiar nadzoru człowieka: osoby mają rozumieć możliwości i ograniczenia systemu, umieć monitorować działanie oraz unikać „automation bias” (nadmiernego polegania na wynikach AI).
Pytanie kontrolne: Czy użytkownicy dostali szkolenie i instrukcję „jak używać AI bezpiecznie”, czy po prostu dostali narzędzie?
Lekcja 8: Gdy zaczyna się kryzys, liczy się procedura reagowania — nie improwizacja
Podcast stawia pytania o przebieg akcji ratunkowej i błędy w działaniach. W AI analogią jest incident response: kto reaguje na wyciek danych, kto wyłącza funkcje, kto komunikuje się z interesariuszami, jak zabezpieczamy dowody.
AI Act przewiduje też obowiązki raportowania poważnych incydentów.
Pytanie kontrolne: Czy mamy procedurę reagowania na incydenty AI, ćwiczoną i przypisaną do ról (a nie „w głowie jednego eksperta”)?
Lekcja 9: Bez dokumentacji po katastrofie zostają emocje, hipotezy i wieloletnie spory
Wątek batalii sądowej i sprzecznych ustaleń wraca w serii wyraźnie. W AI brak dokumentacji oznacza jedno: nie da się wykazać należytej staranności. AI Act wymaga m.in. utrzymywania dokumentacji technicznej i logów (dla systemów wysokiego ryzyka) oraz gotowości do przedstawienia dowodów zgodności.
Pytanie kontrolne: Gdyby jutro doszło do incydentu, czy potrafimy w 48 godzin pokazać: wersję modelu, dane, testy, decyzję o dopuszczeniu ryzyka, logi i osoby odpowiedzialne?
Lekcja 10: Gdy nie wiesz, co naprawdę „płynie” w organizacji, nie zarządzasz ryzykiem — tylko je zgadujesz
W podcaście pojawia się motyw narosłych niejasności: „czy przewoził coś, czego nie powinien?”. A kapitan promu Andrzej Ułasiewicz podczas dramatycznego wywołania sygnału „mayday” ma problem z podaniem liczby osób znajdujących się na pokładzie. W AI to jest dokładnie problem Shadow AI: narzędzia, integracje i automatyzacje działające poza nadzorem.
Pytanie kontrolne: Czy mamy rejestr systemów AI i ich zastosowań (w tym narzędzi genAI), czy dowiadujemy się o nich dopiero przy incydencie?
Checklista wdrożeniowa „STOP/GO” (do użycia na spotkaniu z biznesem)
Nie zarządzasz jeszcze sztuczną inteligencją w swojej organziacji? Oto pięć pytań, które w praktyce przesądzają, czy wdrożenie jest dojrzałe:
- Czy znamy klasyfikację zastosowania (czy to może być „high-risk” lub wpływać na prawa podstawowe) i mamy udokumentowaną ocenę ryzyka?
- Czy mamy właściciela ryzyka, procedurę kontroli zmian i testy przed/po wdrożeniu?
- Czy dane są „zabezpieczone jak ładunek”: minimalne uprawnienia, kontrola wejścia/wyjścia, retencja, logowanie?
- Czy użytkownicy mają instrukcje, szkolenie i mechanizmy human oversight (bez „automation bias”)?
- Czy mamy monitoring po wdrożeniu i procedurę zgłaszania/obsługi incydentów?
Jeśli na którekolwiek pytanie odpowiedź brzmi „nie do końca”, to jest moment na wstrzymanie wdrożenia albo wdrożenie tylko w kontrolowanym, ograniczonym scenariuszu. A wdrożenie zarządzania zgodnoscią w projektach AI to powinno być pierwszym zadaniem w 2026 roku.
