W poprzednich wydaniach omawialiśmy systemy AI i ich wyjaśnialność z perspektywy regulacji i zasad. Tym razem schodzimy poziom niżej: od zasad do architektury technicznej rozwiązań.
Wiele dużych przedsiębiorstw ma już polityki AI, deklaracje etyczne i komitety ds. ryzyka. Na papierze zarządzanie wygląda poważnie. Jednak na produkcji lwia część użycia AI wciąż odbywa się poprzez niesankcjonowane narzędzia, prywatne konta i improwizowane prompty.
To wydanie poświęcone jest elementowi architektury, który pomaga zlikwidować tę lukę.
W wielu organizacjach zaczyna się od spisania polityki, w której „doklejono” akapity o AI do istniejących ram ryzyka. Jako pierwszy krok jest to zrozumiałe — podobnie obsługiwany był problem zgodności z RODO . Wiele organizacji nie zdecydowało się na wdrożenie technicznych zabezpieczeń, pozostając przy dokumentach. W przypadku AI to jednak zdecydowanie nie wystarczy.
Systemy, na których wyrósł Twój model zarządzania IT, są deterministyczne. Zmieniają się powoli, poprzez zarządzane wdrożenia (releases). Raz uruchomione, cały czas robią dokładnie to, co na początku. Standardowe zarządzanie backlogiem rozwojowym, testy regresji i procesy release managementu sprawdzają się świetnie.
Modele GenAI zachowują się inaczej:
- Są stochastyczne: to samo wejście może dać różne wyniki. Halucynacja nie jest rzadkim edge case; to natura działania tych systemów.
- Dryfują: dostawcy zmieniają dane treningowe, architektury i warstwy bezpieczeństwa. Zachowanie modelu może zmienić się w sposób krytyczny dla ryzyka, bez zmiany choćby linijki Twojego kodu.
- Wtargnęły do naszego życia jako consumer product, zoptymalizowany pod kątem natychmiastowej dostępności i odpowiedzi. Każdy, kto ma przeglądarkę i adres e-mail, ma dostęp do modelu klasy frontier. Jeśli potraktujesz to jako problem do rozwiązania dokumentacją, przegrasz. Jedyny miarodajny test reguły governance jest następujący:
Czy potrafimy zapisać ją jako kod, który automatycznie wymusi tę zasadę w odpowiednim punkcie cyklu życia systemu?
Jeśli zasada „żadne dane osobowe (PII) nie mogą opuścić kraju” nigdy nie pojawia się jako deterministyczne sprawdzenie ruchu wychodzącego, to nie masz kontroli.
Ta zmiana jest niewygodna dla działów, których narzędziami od zawsze były dokumenty i komitety. Polityki i szkolenia nadal są ważne, ale teraz muszą być budowane na znacznie potężniejszym technicznym fundamencie. Bez tego fundamentu prosimy ludzi, by ręcznie zarządzali stochastycznymi zachowaniami i dryfem modeli, oraz rozpowszechnionym na masową skalę Shadow AI. To nie jest realistyczny plan.
Od teatru zarządzania do realnej kontroli#
Działy prawne i compliance nie próżnują. Publikują polityki AI i zasady dopuszczalnego użytkowania. Dokumenty są zazwyczaj solidne i często trafiają do zarządu.
Rzeczywistość jednak nie pokrywa się z dokumentacją.
Duża część pracowników używa w pracy niesankcjonowanych narzędzi AI. Wielu przyznaje się do wklejania danych firmowych do publicznych chatbotów, czasem z prywatnych kont, które znajdują się poza zasięgiem działu bezpieczeństwa. Organizacja zakazuje używania tych narzędzi. Przeglądarka internetowa – nie.
To jest teatr zarządzania. Masz widoczne artefakty sygnalizujące kontrolę, ale nie stawiają one żadnego oporu w praktyce. Pisemny zakaz wysyłania danych klientów do zewnętrznych modeli nie daje żadnej ochrony, jeśli nic w Twoim stacku technologicznym nie powstrzyma developera czy analityka przed zrobieniem tego w dwadzieścia sekund.
Konsumenckie AI pogarsza problem. Narzędzia takie jak ChatGPT zaprojektowano pod kątem użyteczności i szybkości, a nie zgodności (compliance). Są szybkie, wyrozumiałe i potężne. Narzędzia wewnętrzne często wydają się wolniejsze i bardziej ograniczone, ponieważ muszą skanować dane pod kątem PII, kierować ruch do zatwierdzonych modeli (a nie tych najnowszych) i pilnować zasad kontroli dostępu. Użytkownicy porównują narzędzie zarządzane z niezarządzanym i po cichu wybierają to drugie.
Z perspektywy prawa nie jest to abstrakcyjna luka między „etyką” a „zachowaniem”. To błąd kontroli. Po kolejnym incydencie urzędnicy nie zapytają, jak gruby był Twój segregator z polityką AI, tylko jaka kontrola techniczna działała w momencie, gdy dane opuściły Twoją sieć.
Czym właściwie jest AI Gateway#
Patternem architektury korporacyjnej, który wyłania się na rynku, jest AI Gateway: wyspecjalizowana płaszczyzna kontrolna (control plane) pomiędzy wszystkimi Twoimi aplikacjami korzystającymi z AI a dostawcami modeli.
Bez niej każdy chatbot, asystent czy agent może rozmawiać bezpośrednio z jednym lub wieloma API modeli. Każdy zespół może wymyślić własny sposób obsługi uwierzytelniania, logowania, przetwarzania danych i śledzenia kosztów. Gdy dostawca wycofuje model lub zmienia cennik, musisz zmienić kod lub konfigurację w dziesiątkach repozytoriów. Gdy regulator pyta, co konkretny system zrobił danego dnia, odkrywasz, że logi są niespójne lub niekompletne.
Gateway zmienia to w model „piasty i szprych” (hub-and-spoke). Cały ruch AI – z interfejsów czatowych, narzędzi back-office, asystentów kodowania, wbudowanych agentów – przepływa przez jedną, dobrze zdefiniowaną bramkę. Aplikacje wywołują jedno wewnętrzne API. Gateway zajmuje się wyborem modelu, sprawdzaniem polityk, przetwarzaniem danych, logowaniem i mierzeniem zużycia, zanim cokolwiek opuści Twoją sieć.
AI Gateway zapewnia trzy podstawowe funkcjonalności:
- Suwerenność. Deweloperzy integrują się z bramką, a nie z konkretnym dostawcą (vendor). Jeśli dostawca ma awarię, zmienia zachowanie modeli lub podnosi ceny, dostosowujesz reguły routingu w jednym miejscu. Systemy klienckie działają dalej. Gdy później wprowadzisz modele własne (in-house), możesz je ukryć za tym samym interfejsem.
- Zapora dla danych (Data firewall). Gateway przechwytuje prompty, wykrywa wrażliwe dane i zastępuje je tokenami. „Anna Kowalska, konto 12345” staje się „<OSOBA_1>, <KONTO_1>”. Model widzi tylko puste wskaźniki (placeholders). Generuje odpowiedź, używając ich, a bramka przywraca oryginalne wartości w drodze powrotnej. Dostawca modelu nigdy nie widzi surowych danych osobowych. Warto zwrócić uwagę, ze z perspektywy RODO może to nie być wystarczające zabezpieczenie, ponieważ nawet po anonimizacji możliwe może być zidentyfikowanie osoby na podstawie innych cech lub danych przekazanych do modelu.
- Ścieżka audytowa. Ponieważ wszystkie wywołania przechodzą przez jeden punkt, możesz raz wdrożyć spójne, odporne na manipulacje logowanie. Każde żądanie i odpowiedź mogą być rejestrowane ze znacznikiem czasu, ID użytkownika, wersją modelu i podjętą decyzją. Kiedy musisz prześledzić, jak powstała konkretna decyzja wspierana przez AI, nie musisz sklejać logów z sześciu różnych systemów. W bardziej złożonych środowiskach taki gateway często funkcjonuje obok warstwy zarządzania narzędziami oraz tradycyjnego API Gateway dla usług backendowych. Nie potrzebujesz tego pełnego wzorca od pierwszego dnia. Ważnym krokiem jest zatrzymanie wycieku ruchu AI przez niekontrolowane ścieżki i skierowanie go przez jedną ścieżkę.
Od tekstu polityki do kodu polityki#
Gdy ruch przepływa przez jedno miejsce, możesz przestać traktować polityki jak eseje i zacząć traktować je jak egzekwowalne reguły.
Dedykowany silnik polityk (policy engine) ocenia każde przychodzące żądanie względem zestawu deklaratywnych zasad. Gateway pyta: „Biorąc pod uwagę tego użytkownika, ten model i ten kontekst – czy to wywołanie jest dozwolone? Pod jakimi warunkami?”. Punkt egzekwowania (enforcement point) działa następnie zgodnie z odpowiedzią.
Zasady, które obecnie żyją w plikach PDF, przenoszą się do kodu. Na przykład:
- młodsi analitycy nie mogą wydać więcej niż X złotych dziennie na modele premium;
- prompty zawierające identyfikatory klientów nie mogą być wysyłane do publicznych modeli SaaS;
- określone klasy decyzji muszą być kierowane do kolejki ludzkiej weryfikacji, jeśli pewność modelu jest niska lub występują specyficzne flagi. Ponieważ zasady są kodem, możesz objąć je kontrolą wersji, weryfikować, testować i wdrażać jak każdą inną konfigurację. Naruszenia prowadzą do automatycznej blokady lub błędu, a nie do notatki w protokole, którą komitet omówi tygodnie później.
To tutaj abstrakcyjny język regulacji staje się konkretem. Ramy takie jak NIST AI Risk Management Framework czy standardy ISO 42001 wymagają identyfikacji, mierzenia i zarządzania ryzykiem AI w całym cyklu życia. Silnik polityk plus gateway to miejsca, w którym te pojęcia przestają być slajdami prezentacji, a stają się faktycznym działaniem.
Oczywiście nie zapiszesz wszystkiego w kodzie — organizacyjny poziom tolerancji ryzyka czy kwestie kultury organizacyjnej zawsze będą wymagały osądu. Ważny jest jednak kierunek: jeśli reguła nigdy nie pojawia się w kodzie, jest mało prawdopodobne, by była stosowana spójnie w świecie probabilistycznych systemów i masowego Shadow AI.
[redakcja do tego miejsca]
Regulacje jako zadanie dla inżynierów#
Nowe regulacje AI często traktuje się jako problem prawny, istniejący w innym wszechświecie niż architektura IT. Czytane uważnie, zapisy regulacji brzmią jednak bardziej jak dokument projektowy dla Twojej bramki AI.
Unijny AI Act jest dobrym przykładem. Od systemów wysokiego ryzyka oczekuje co najmniej trzech rzeczy:
- Identyfikowalność (Traceability). Systemy muszą logować swoje działanie. Centralny gateway to naturalne miejsce do generowania spójnych, ustrukturyzowanych logów dla wszystkich wywołań modeli, niezależnie od aplikacji czy dostawcy.
- Nadzór ludzki. Operatorzy muszą mieć możliwość interwencji. Na poziomie bramki przekłada się to na bezpieczniki (circuit breakers) i reguły routingu: możesz wstrzymać dany use case, gdy wskaźniki błędów wzrosną, lub wysłać pewne klasy żądań do kolejki do obsługi przez człowieka zamiast pozwalać modelowi odpowiadać bez nadzoru.
- Bezpieczeństwo. Systemy powinny radzić sobie z atakami takimi jak prompt injection i kontynuować bezpieczne działanie. Gateway to miejsce, gdzie możesz przepuścić żądania przez dedykowane skanery, ograniczyć ruch (rate-limiting), aby uniknąć ataków typu denial of wallet, i przełączyć się na modele zapasowe (failover), gdy jakość głównego modelu spada. Pozostałe regulacje wskazują ten sam kierunek. ISO 42001 mówi o posiadaniu systemu zarządzania AI z dowodami kontroli. Te dowody znacznie łatwiej dostarczyć, gdy możesz zgodnie z prawdą powiedzieć: „każde wywołanie dowolnego modelu AI przeszło przez tę płaszczyznę, tu są polityki, a tu logi”.
Kontrola kosztów#
Nawet jeśli zignorujesz regulacje, ekonomia AI przemawia za centralizacją.
Modele generatywne zmieniają model kosztowy korzystania z usługi w stosunku nawet do SaaS. Użycie jest mierzone w tokenach. Wykorzystanie może gwałtownie wzrosnąć w ciągu tygodni. Jedno źle skonfigurowane zadanie wsadowe może przepalić miesięczny budżet. Jeśli każdy zespół korzysta z modeli bezpośrednio, nikt nie ma pełnego obrazu sytuacji, dopóki nie przyjdzie faktura.
Gateway daje Ci jeden licznik. Widzisz w czasie zbliżonym do rzeczywistego, które zespoły i które przypadki użycia generują koszty. Możesz ustawić twarde limity dla użytkownika, działu lub aplikacji. Możesz wykryć anomalie wystarczająco wcześnie, by zareagować.
Możesz też przestać traktować jeden model jako domyślny do wszystkiego. Wiele zadań o dużym wolumenie jest prostych: routing, krótkie streszczenia, podstawowa klasyfikacja. Mniejszy i tańszy model wystarczy. Gateway może kierować ruch według reguł lub za pomocą lekkiego modelu routera:
- proste zadania trafiają do tańszych modeli;
- złożone zadania o wyższym ryzyku trafiają do modeli, które uzasadniają swój koszt. W dużej skali ta optymalizacja ma znaczenie. Ta sama platforma może również wykonywać semantic caching: gdy dwa prompty są wystarczająco bliskie znaczeniowo, może zaserwować poprzednią odpowiedź zamiast ponownie wywoływać model. W powtarzalnych obciążeniach redukuje to zarówno opóźnienia, jak i wydatki.
Tak właśnie traktujesz już inne media. Nie pozwalasz każdemu zespołowi kłaść własnego światłowodu czy negocjować własnej umowy z centrum danych. Centralizujesz, mierzysz i optymalizujesz. AI zmierza w tę samą stronę.
Bezpieczeństwo agentic AI#
Do tej pory mówiliśmy głównie o AI, która pisze tekst. Profil ryzyka zmienia się, gdy AI może podejmować samodzielne działania.
Systemy agentowe (agentic systems) mogą inicjować płatności, zmieniać konfiguracje, aktualizować rekordy, wysyłać wiadomości. W tym momencie halucynacja nie jest dziwnym akapitem w wersji roboczej; jest błędnym przelewem, złym ustawieniem na produkcji lub mylącym raportem wysłanym do przełożonego.
Prace nad bezpieczeństwem dużych modeli językowych skatalogowały już prompt injection, niebezpieczną obsługę wyników, wyciek wrażliwych danych i celowe próby wyczerpania zasobów. Wzorzec jest jasny: poleganie wyłącznie na wewnętrznych mechanizmach bezpieczeństwa modelu nie wystarczy. Mechanizmy te są nieprzejrzyste i zmieniają się poza Twoją kontrolą.
Gateway daje Ci kolejną linię obrony. Możesz:
- przepuszczać prompty i odpowiedzi przez dedykowane modele weryfikujące (guard models), które szukają znanych wzorców ataku lub niedozwolonych treści, zanim dotrą one do agenta lub użytkownika;
- ograniczyć, które narzędzia lub API dany agent może wywoływać, używając bramki jako egzekutora tych uprawnień;
- monitorować i ograniczać zachowanie we wszystkich agentach, a nie tylko wewnątrz pojedynczej aplikacji. Żadna z tych metod nie eliminuje ryzyka całkowicie. Wprowadza jednak systemy AI w ramy tego samego myślenia o bezpieczeństwie, które stosujesz już do płatności czy systemów core banking: nigdy nie wystawione bezpośrednio do publicznego internetu, zawsze chronione przez bramki i monitoring.
Jak wdrożyć gateway bez rewolucji#
Wprowadzenie tego mechanizmu w żywej organizacji jest wyzwaniem tyleż społecznym, co technicznym. Najbardziej praktycznym scenariuszem, jaki znam, jest protokół Shadow AI: Amnestia i Utwardzanie Drogi (Amnesty & Pave) z wydania #24.
W skrócie:
- Zaczynasz od ujawnienia Shadow AI bez karania.
- Następnie budujesz wiarygodną, zarządzą „utwardzoną drogę”, której ludzie chcą używać.
- Dopiero po tym wprowadzasz ograniczenia i domyślnie kierujesz ruch tą drogą.
Briefing#
1. AI Omnibus: Wdrożenie, nie teoria
Propozycja AI Omnibus Komisji po cichu zmienia sposób patrzenia na AI Act: traktuje go głównie jako problem wdrożenia, a nie projektowania nowych zasad[1]. Wprowadza mechanizm „stop‑the‑clock” dla obowiązków wobec systemów wysokiego ryzyka – dopóki nie powstaną odpowiednie standardy i narzędzia wsparcia, część wymogów byłaby zawieszona. Łagodzi też niektóre obowiązki rejestracyjne oraz poszerza podstawę prawną przetwarzania danych wrażliwych w celu wykrywania i poprawiania stronniczości modeli. Wspólna opinia EDPB/EDPS się temu sprzeciwia: domaga się utrzymania surowego testu „ściśle konieczne” dla danych szczególnych kategorii, broni przed rozwodnieniem rejestracji systemów z załącznika III oraz żąda formalnego udziału organów ochrony danych w piaskownicach na poziomie UE[2]. W praktyce Bruksela wysyła sygnał, że bramki dostępu, rejestry i wykonywalne polityki stają się domyślną infrastrukturą dla zgodności z przepisami o AI
2. Agentic AI: adopcja wyprzedza governance
Artykuł Campbella Robertsona „Agentic AI Governance Gap” zauważa, że około 90% dużych organizacji wdraża agenty AI, ale tylko 19% wdrożyło dojrzałe ramy zarządzania[3]. Przegląd pilotaży agentowego AI przeprowadzony przez PEX Network dodaje, że około 65% przedsiębiorstw testuje agenty, ale tylko około 11% wdrożeń dociera na produkcję, a Gartner przewiduje, że ponad 40% projektów agentowych zostanie anulowanych do 2027 roku[4].
3. Deloitte: strategia gotowa, operacje nie
Raport Deloitte „State of AI in the Enterprise 2026” donosi o 50-procentowym wzroście dostępu pracowników do AI i nadchodzącym podwojeniu liczby firm z ≥40% projektów na produkcji – ale tylko około jedna trzecia naprawdę przeprojektowuje kluczowe procesy. Większość czuje się strategicznie przygotowana na AI, ale operacyjnie nieprzygotowana w zakresie infrastruktury, danych, ryzyka i talentów[5].
Podsumowując: to nie modele są ograniczeniem. Są nim modele operacyjne, procesy i governance.
Pytanie na ten tydzień#
Zanim podpiszesz kolejny budżet na AI, zadaj sobie jedno pytanie:
Jeśli ktoś jutro wklei wrażliwy zbiór danych do zewnętrznego narzędzia AI, jaki mechanizm powstrzyma te dane przed opuszczeniem firmy w nienaruszonej formie?
Jeśli szczera odpowiedź brzmi: „nasza polityka dopuszczalnego użytkowania mówi, że nie powinni”, to nie ma kontroli nad przepływem danych.
To samo pytanie dotyczy kosztów i regulacji. Jeśli Twoja wiedza o wydatkach AI to miesięczna faktura od jednego dostawcy, lecisz na ślepo.
AI Governance w 2026 roku nie polega już głównie na pisaniu lepszych polityk czy prowadzeniu większej liczby warsztatów. To wybór i wdrożenie odpowiedniej architektury.
Zachowaj równowagę,
Krzysztof