Drodzy Czytelnicy,
W wydaniu szesnastym, opublikowanym we wrześniu 2025 roku, pisałem, że AI governance powinno być wyrażone jako kod, a nie tylko jako dokumenty z politykami. W wydaniu trzydziestym drugim, trzy miesiące później, opisałem AI gateway — pojedynczy komponent architektoniczny, który kieruje całym ruchem do modeli przez jedną, zarządzaną warstwę.
Oba wydania wyznaczały kierunek. Żadne nie opisywało pełnego krajobrazu. Od tamtej pory narzędzia znacznie dojrzały — silniki polityk, platformy monitorujące, frameworki testowe, automatyzacja compliance — a termin wejścia w życie wymogów dla systemów wysokiego ryzyka z AI Act zbliżył się na tyle, że to pytanie przestało być teoretyczne.
Pytanie, które ciągle słyszę od czytelników, nie brzmi już “czy powinniśmy technicznie zarządzać AI?”. Brzmi ono: “jakie narzędzia istnieją, które z nich działają i od czego zacząć?”. To wydanie mapuje obecny stan technicznego stosu, który potrafi wymuszać zasady governance w czasie rzeczywistym — nie za sześć miesięcy, ale za pomocą tego, co jest dostępne teraz.
Luka w egzekwowaniu zasad#
Raport Deloitte State of AI z 2026 roku ocenia gotowość korporacji na AI governance na 30% — poniżej zarządzania danymi (40%), poniżej infrastruktury technicznej (43%) i znacznie poniżej dostępu do narzędzi (60%). Dostęp do narzędzi jest dwa razy wyższy niż gotowość do governance. Firmy potrafią szybciej dotrzeć do modeli AI, niż zarządzać tym, co się dzieje, gdy już to zrobią.
Przyczyna jest strukturalna. Większość programów governance zaczynała się od dokumentów: zasad, polityk, deklaracji etycznych, statutów komitetów. To nie są kontrole. Spisana zasada, która zabrania wysyłania danych klientów do zewnętrznych modeli, nie oferuje żadnej ochrony, jeśli w infrastrukturze nie ma niczego, co powstrzymałoby analityka przed zrobieniem tego w dwadzieścia sekund.
Wydanie czterdzieste drugie ujawniło ten sam wzorzec w czterech regulowanych sektorach. W bankowości, jeden bank na pięć miał pełną inwentaryzację systemów AI. W telekomunikacji 21% firm zgłosiło, że ma odpowiednie governance dla autonomicznych agentów AI, podczas gdy 47% już wdrożyło agenty. Przepaść nie leży między chęciami a świadomością. Leży między dokumentami a egzekwowaniem zasad.
Pięć warstw technicznego egzekwowania#
Poniżej przedstawiam obecny stan technicznego stacku, który zasypuje tę przepaść. To nie jest rekomendacja produktowa. To mapa tego, co istnieje, co działa, a co nie.
Warstwa 1: Silniki polityk — zasady jako kod, nie jako PDF.
Silnik polityk ocenia każdą akcję AI względem deklaratywnych reguł w czasie rzeczywistym. Przychodzi zapytanie; silnik sprawdza je z zestawem reguł; akcja przechodzi dalej lub nie.
OPA (Open Policy Agent) z językiem Rego pozostaje rynkowym standardem dla policy-as-code. Sprawdził się produkcyjnie w środowiskach cloud-native, ale wymaga inżynierskich umiejętności, żeby dostosować go do specyficznych use case’ów AI. Nie ma standardowej biblioteki polityk AI — każda firma pisze reguły od zera.
Najistotniejszym nowym rozwiązaniem jest tutaj AWS Bedrock AgentCore, który wszedł do ogólnej dostępności w marcu 2026 roku. Automatycznie konwertuje on reguły governance napisane w języku naturalnym na polityki w języku Cedar. Ocena w Cedarze jest deterministyczna — w momencie egzekwowania reguły nie bierze w tym udziału LLM — i generuje pełne ślady audytowe (audit trail). Zespoły bezpieczeństwa piszą polityki; programiści budują agenty AI; jedni nie modyfikują pracy drugich. To pierwsze prawdziwie gotowe rozwiązanie policy-as-code do zarządzania agentami AI.
Luka: w bezpieczeństwie IT istnieją ustandaryzowane biblioteki reguł — gotowe konfiguracje, które organizacje przyjmują i adaptują (CIS Benchmarks dla utwardzania serwerów, zestawy reguł OWASP dla aplikacji webowych). Dla AI governance nie opublikowano niczego porównywalnego. Jeśli chcesz mieć startową bibliotekę polityk, musisz ją napisać sam.
Warstwa 2: AI gateways — kontrola ruchu.
Szczegółowo omówiłem to w wydaniu trzydziestym drugim. AI gateway to zarządzany punkt kontrolny, przez który przepływa cały ruch AI: filtrowanie promptów, maskowanie danych, kierowanie do modeli, rozliczanie kosztów, logowanie audytowe.
Od stycznia krajobraz dojrzał. Każdy duży dostawca chmury — AWS, Azure, Google Cloud — oferuje teraz produkt typu gateway z wbudowanymi mechanizmami AI governance: filtrowaniem promptów, bezpieczeństwem treści, śledzeniem użycia. Niezależni dostawcy oferują rozwiązania multi-cloud dla organizacji, które nie chcą zamykać się w jednej chmurze. Pół roku temu wybór był węższy. Dla firm, które już używają API gateways dla swoich usług webowych, rozszerzenie ich na ruch AI to punkt wejścia o najmniejszym oporze.
Nie będę tu powtarzał architektury gateway’a — przeczytaj wydanie trzydzieste drugie, żeby poznać pełny projekt. W tym wydaniu chodzi o umiejscowienie: gateway to warstwa druga z pięciu. Konieczna, ale niewystarczająca.
Warstwa 3: Monitorowanie i drift detection — co się zmieniło i kiedy.
Model, który przeszedł wszystkie testy przy wdrożeniu, może po cichu zawieść na produkcji, kiedy dostawca zaktualizuje dane treningowe, kiedy zmienią się dystrybucje wejść lub kiedy zmieni się zachowanie użytkowników. Drift detection wyłapuje takie sytuacje.
Arize AI zapewnia najsilniejszą obserwowalność po wdrożeniu (observability) — głęboką analitykę dryfu, analizę osadzeń (embeddings), śledzenie jakości. Fiddler specjalizuje się w wyjaśnialności (explainability) i wykrywaniu uprzedzeń (bias) dla regulowanych branż; jeśli twój CISO musi wytłumaczyć KNF-owi, dlaczego model scoringowy zmienił zachowanie, Fiddler jest zbudowany właśnie do takich rozmów. WhyLabs udostępniło swój kod w modelu open-source na licencji Apache 2.0 w styczniu 2025 roku i oferuje opcję self-hosted.
Luka: te narzędzia zostały zbudowane dla tradycyjnego uczenia maszynowego — danych tabelarycznych, klasyfikacji, regresji. Monitorowanie LLM-ów jest tam doklejone, a nie natywne. Wykrywanie istotnego dryfu behawioralnego w modelu językowym (model stał się bardziej konserwatywny w decyzjach kredytowych po aktualizacji od dostawcy) pozostaje w dużej mierze nierozwiązanym problemem na poziomie automatycznym. Dla subtelnych zmian wciąż potrzebna jest ocena człowieka.
Warstwa 4: Automatyczne testowanie — ciągłe, a nie jednorazowe.
W bezpieczeństwie aplikacji webowych automatyczne skanowanie przy każdym wdrożeniu jest standardem od ponad dekady. W systemach AI ciągłe testowanie dopiero teraz staje się technicznie możliwe.
Promptfoo działa wewnątrz potoków CI/CD (pipelines) i mapuje swoje 133 wtyczki na OWASP Top 10 dla LLM-ów, NIST RMF i MITRE ATLAS. Testuje potoki RAG, wieloturowe agenty AI i naruszenia polityk przy każdym wypchnięciu kodu. Microsoft, Shopify i Discord używają go na produkcji. Taka konfiguracja przypomina to, co większość zespołów inżynierskich robi już w zakresie bezpieczeństwa aplikacji webowych — automatyczne skany wyzwalane przez wdrożenie, a nie kwartalne audyty planowane przez dział compliance.
Microsoft PyRIT obsługuje niestandardowe, wieloetapowe testy adwersarialne (red teaming) i ewaluację wielomodalną. Garak od NVIDII testuje odporność modelu na ponad sto scenariuszy ryzyka — od prób jailbreaku i prompt injection po niekontrolowane ujawnienie danych — i lepiej nadaje się do okresowych audytów niż do ciągłych potoków.
Luka: obecne narzędzia testują pod kątem błędów bezpieczeństwa — generowania szkodliwych treści, jailbreaków, wycieków danych. Prawie żadne nie testują pod kątem błędów logiki biznesowej: model zatwierdził pożyczkę, której nie powinien był zatwierdzić, albo wygenerował raport z błędem numerycznym, który wyglądał wiarygodnie. Testowanie bezpieczeństwa jest konieczne. Ale to testowanie ryzyka biznesowego jest tym obszarem, w którym leży prawdziwe zagrożenie, a narzędzi do tego jest mało.
Warstwa 5: Circuit breakers i kill switches — interwencja w czasie rzeczywistym.
Kiedy model zaczyna źle się zachowywać o trzeciej rano, co go powstrzyma?
Żaden komercyjny produkt nie dostarcza gotowego kill switcha dla AI. Firmy budują to z prymitywów infrastrukturalnych. Wyłaniający się wzorzec wykorzystuje pięć mechanizmów: booleanowski kill flag per agent AI (sprawdzany przed każdą akcją, z opóźnieniem sub-milisekundowym przez Redis lub system feature-flag), limitowanie przepustowości (rate limiting) typu token-bucket dla drogich operacji, wykrywanie wzorców w przesuwnych oknach czasowych w celu wychwycenia powtarzających się pętli, twarde blokady na poziomie polityk przez OPA/Rego dla warunków semantycznych (limity wielkości plików, granice regionalne, budżety akcji) oraz unieważnianie tożsamości przez certyfikaty SPIFFE/SPIRE jako opcja atomowa — po unieważnieniu, agent AI nie może uzyskać nowych certyfikatów i wszystkie dalsze zapytania są odrzucane.
Zasada architektoniczna, co do której panuje zgoda: warstwa izolacji należy do warstwy orkiestracji, a nie do serwerów aplikacji. Zarządzasz agentami AI z góry, a nie od wewnątrz.
Luka: wzorce są dobrze zrozumiane, ale wdrożenie jest szyte na miarę. To oczywista luka rynkowa, którą ktoś zapewne wypełni.
Gdzie jeszcze są luki#
Podsumowanie: klocki istnieją, warstwa integracyjna — nie. Żadna pojedyncza platforma nie łączy silnika polityk, gateway’a, monitorowania, dowodów compliance i kill switcha w jeden spójny stos. Korporacje, które chcą mieć dzisiaj governance-as-code, budują to same z czterech do sześciu różnych narzędzi.
Credo AI, IBM watsonx.governance i OneTrust AI Governance zapewniają automatyzację compliance — mapowanie charakterystyk modeli na EU AI Act, ISO 42001, NIST AI RMF, generowanie dokumentacji gotowej do audytu. Credo AI jest wdrażane przez Microsoft, Databricks i Mastercard. IBM prowadzi zarówno w IDC MarketScape, jak i Forrester Wave dla platform AI governance. Ale żadne z nich nie ma dojrzałego procesu dla obowiązków wdrażającego z Artykułu 26 (Article 26 deployer obligations) ani dla Ocen Skutków dla Praw Podstawowych (Fundamental Rights Impact Assessments). Dla większości firm — które są podmiotami wdrażającymi (deployers), a nie dostawcami (providers) — narzędzia compliance są niedorozwinięte, podczas gdy sierpniowy termin z 2026 roku jest za cztery miesiące.
Briefing#
78% europejskich firm nieprzygotowanych na obowiązki z AI Act
Raport gotowości od Vision Compliance, obejmujący osiem sektorów w Europie, wykazał, że 78% przedsiębiorstw nie podjęło znaczących kroków w kierunku compliance. Konkretne braki są nam znane: 83% nie ma formalnej inwentaryzacji systemów AI, 74% nie wyznaczyło organu zarządzającego zgodnością AI, a 61% nie potrafi dostarczyć technicznej dokumentacji wymaganej dla systemów wysokiego ryzyka. Jeden wniosek warto odnotować: organizacje, które już są zgodne z RODO, wykazały wyraźnie lepszą gotowość na AI Act, szczególnie w obszarze data governance. Dla polskich firm, gdzie zgodność z RODO jest stosunkowo dojrzała, ta korelacja to konkretny punkt wyjścia — infrastruktura data governance już istnieje; brakuje tylko warstwy, która łączy ją ze specyficznymi obowiązkami dla AI.
Komisja Europejska rozważa klasyfikację ChatGPT jako “bardzo dużej platformy” w ramach DSA
Reuters poinformował, że Komisja Europejska analizuje, czy ChatGPT od OpenAI powinien zostać uznany za “bardzo dużą platformę internetową” w ramach Digital Services Act, po tym jak liczba jego użytkowników przekroczyła regulacyjny próg. Taka klasyfikacja poddałaby OpenAI najostrzejszemu rygorowi DSA: systemowym ocenom ryzyka, przejrzystości algorytmicznej, niezależnym audytom. Ten ruch jest istotny, bo pokazuje, że Unia nie czeka tylko na egzekwowanie AI Act — nakłada istniejące regulacje na usługi AI przez jakikolwiek framework, który akurat pasuje. Dla każdej firmy budującej w Europie narzędzia z AI skierowane do klienta, właściwe pytanie nie brzmi tylko “czy AI Act ma zastosowanie?”, ale “która z sześciu czy siedmiu nakładających się unijnych regulacji ma zastosowanie jako pierwsza?”.
Zwolnienia w amerykańskim sektorze technologicznym przypisywane AI — ale to w dużej mierze zasłona dymna
Raport z outplacementu firmy Challenger, Gray & Christmas za marzec 2026 roku wymienia AI jako najczęściej podawany powód zwolnień w USA: 15 341 ogłoszonych redukcji etatów, 25% miesięcznej sumy. W pierwszym kwartale 2026 roku sektor technologiczny zlikwidował około 80 000 stanowisk, z czego prawie połowę przypisano AI i automatyzacji. Nagłówek przyciąga uwagę. Treść jest jednak uboższa. “AI” stało się wygodną etykietą dla decyzji restrukturyzacyjnych napędzanych presją na marże, korektami po zbytnim zatrudnianiu i strategicznymi zwrotami, które mają niewiele wspólnego z automatyzacją zastępującą konkretne role. Prawdziwe pytanie dla firm nie brzmi “czy AI zastąpi moją siłę roboczą (workforce)?”, ale “czy budujemy wewnętrzne kompetencje, żeby używać AI produktywnie, zanim presja kosztowa wymusi na nas decyzję?”.
Pytania do zarządu#
Czy wasza infrastruktura potrafi powstrzymać pracownika przed wysłaniem danych klienta do zewnętrznego modelu AI już teraz — nie poprzez dokument z polityką, ale przez techniczną kontrolę, która zadziała zanim dane opuszczą waszą sieć?
Jeśli dostawca modelu zaktualizowałby jutro model stojący za waszym systemem oceny kredytowej lub wykrywania oszustw, czy wasze monitorowanie wykryłoby zmianę behawioralną, zanim wpłynęłaby ona na decyzje? Ile czasu by to zajęło?
Które z pięciu warstw opisanych w tym wydaniu wasza organizacja wdrożyła produkcyjnie? Które istnieją tylko jako zaplanowane punkty w roadmapie dla governance?
Jeśli musielibyście wyłączyć konkretny agent AI o trzeciej rano, bo zaczął produkować szkodliwe treści, jaki jest do tego mechanizm? Czy jest udokumentowany? Czy był testowany?
Problem integracji#
Nordea to najlepiej i najbardziej publicznie udokumentowany przypadek governance-as-code w europejskiej bankowości. Przeszli od dowodu koncepcji (PoC) na laptopie do dziesięciu tysięcy użytkowników na platformie AI klasy produkcyjnej, wbudowując reguły governance w warstwę platformy, a nie w poszczególne use case’y. Ich opis to: “organizacyjne przepięcie kabli”. Zajęło im to lata.
Większość korporacji nie zbuduje tego, co zbudowała Nordea. Złożą to z komponentów: gateway od jednego dostawcy, monitorowanie od drugiego, mapowanie compliance od trzeciego, kill switches poskładane z prymitywów infrastrukturalnych. Umiejętność nie polega na wyborze narzędzi. Polega na połączeniu ich w system, który konsekwentnie wymusza zasady przy każdej interakcji z AI, za każdym razem, bez wyjątków.
Wydanie szesnaste mówiło, że governance powinno być kodem. Wydanie trzydzieste drugie pokazało jeden komponent. Pełny stos istnieje w kawałkach. Firmy, które złożą go przed sierpniem, będą miały system. Reszta będzie miała dokumenty.
Do następnego razu, Krzysztof