Drogi Czytelniku,
Tydzień temu pisałem, że prawdziwa linia podziału w AI dla firm przebiega między oprogramowaniem, które doradza, a tym, które działa samodzielnie. A gdy zaczyna działać, człowiek znika z procesu, chyba że celowo zaprojektujemy dla niego rolę. To wydanie jest o drugiej rzeczy, która znika wraz z człowiekiem: o zapisie działań.
Dopóki AI doradzało, człowiek był obecny na każdym istotnym etapie. Czytał rekomendację, podejmował decyzję i działał, zostawiając po sobie ślad zrozumiały dla innych. E-mail miał nadawcę, zgoda miała przypisane nazwisko. Gdy agent działa samodzielnie, nikt nie bierze udziału w danym kroku. Jedynym świadectwem tego, co się stało, jest to, co system zapisał w trakcie pracy. Jeśli nie zostało to zarejestrowane na bieżąco, nie da się tego odtworzyć później i nie ma kogo zapytać.
Dwa sposoby, by mieć dowody#
Większość dowodów na potrzeby compliance jest dziś odtwarzana po fakcie. Gdy audytor lub zarząd pyta, co zrobił system, osobny zespół zbiera odpowiedź po czasie: wyciąga logi, jakie są, eksportuje zapisy z każdego systemu, w którym działał agent, i skleja resztę. Dowód powstaje na żądanie, a nie jest czymś, co firma ma pod ręką.
To podejście sprawdzało się, gdy decyzje zapadały w tempie pracy człowieka i przy każdej z nich ktoś był obecny. Nie przetrwa konfrontacji z agentem, który wykonuje dziesięć tysięcy działań miesięcznie w czterech systemach, na bieżąco decydując o kolejności kroków. Wyobraźmy sobie, że jedno z tych działań pójdzie nie tak i audytor zapyta o ten konkretny przypadek. Ślad odtworzony po miesiącach z logów, które nie były projektowane pod takie pytania, będzie niepełny i łatwy do podważenia. Odtwarzanie zawsze było słabszą metodą. Przy agentach ta słabość robi się kosztowna.
Alternatywą jest system, który zapisuje ślad na bieżąco, w trakcie działania: każdy krok, użyte dane wejściowe, osobę, która go zatwierdziła, i podjętą akcję. Logi oczywiście już istnieją, ale powstały po to, by inżynierowie mogli debugować: są rozrzucone po systemach, nieustrukturyzowane i zwykle kasowane po krótkim czasie. To zapis innego rodzaju. Jest ustrukturyzowany, więc można go przeszukiwać zapytaniem, zamiast filtrować tekst; jest kompletny, bo runtime zapisuje każdy istotny krok, a nie próbkę; i rejestruje jedną rzecz, której logi do debugowania prawie nigdy nie mają: kto zatwierdził daną akcję. Różnica między jednym a drugim to różnica między tym, że ma się jakieś pliki z logami, a tym, że można udowodnić, co się stało. Dowód powstaje przy okazji pracy, a nie jako osobne zadanie doczepione po fakcie. To idea governance-as-code, o której piszę od dwóch lat, tym razem w fizycznej formie – jako element działania agenta.
Narzędzia stworzono do innego zadania#
Na rynku jest już dojrzałe oprogramowanie do obserwowania agentów. LangSmith, Langfuse, Arize Phoenix, Weights & Biases Weave czy logowanie wywołań w AWS Bedrock – wszystkie te narzędzia rejestrują, co zrobił agent: prompty, wywołania narzędzi, kroki rozumowania. Powstaje nawet wspólny standard, konwencje GenAI w OpenTelemetry, więc nie jesteśmy skazani na format jednego dostawcy.
Problem w tym, do czego je stworzono. To narzędzia typu observability, zbudowane, by inżynierowie mogli debugować i ulepszać agenty. Nie powstały po to, by udowodnić regulatorowi, co agent zrobił w sprawie danego klienta. Luka między tymi dwoma zadaniami to pułapka, w którą wpadnie większość organizacji. Najlepszy dowód: na początku 2026 roku użytkownicy LangChain, najpopularniejszego frameworku dla agentów, zgłosili zapotrzebowanie na „ustrukturyzowane logowanie dla audytów compliance pod AI Act, Artykuł 12” – dedykowany mechanizm, niezależny od istniejących callbacków do debugowania. To, że trzeba było prosić o nie osobno, pokazuje, że standardowe śledzenie nie było pomyślane jako materiał dowodowy.
Gdy spojrzymy na domyślne narzędzia jak na źródło dowodów dla compliance, a nie pomoc w debugowaniu, zobaczymy konkretne luki:
- Logi mogą być zmieniane przez operatora. Dane z systemów observability można edytować, samplować lub wyłączyć. Samo narzędzie bezpieczeństwa Amazona zawiera regułę wykrywającą, gdy ktoś usunie konfigurację logowania wywołań w Bedrock, co pokazuje, jak częste jest to zdarzenie. Dowód, który właściciel systemu może po cichu usunąć, nie jest dowodem.
- Treść jest domyślnie wyłączona. Standard OpenTelemetry celowo nie zapisuje treści promptów i odpowiedzi, by uniknąć zasysania danych osobowych do telemetrii. W efekcie część kluczowa dla compliance – czyli to, co powiedziano agentowi i co zdecydował – trzeba włączyć samemu.
- Sampling pomija pojedyncze przypadki. W systemach observability obniża się koszty, rejestrując tylko ułamek ruchu. Próbka jest w porządku do wykrywania trendów, ale bezużyteczna w przypadku jednej, spornej akcji. Artykuł 12 wymaga pełnego zapisu, a nie reprezentatywnego.
- Logowany jest tylko początek i koniec. Częsta droga na skróty to zapisywanie tylko wejścia i finalnego wyniku, z pominięciem promptu systemowego i pobranego w międzyczasie kontekstu – czyli dokładnie tam, gdzie może ukrywać się naruszenie zakresu działania lub stronnicza instrukcja.
- Zatwierdzenie jest niewidoczne. Większość systemów śledzenia rejestruje kroki modelu, ale nie decyzję człowieka obok. Punkt kontrolny wspomniany przed tygodniem, w którym człowiek zatwierdza nieodwracalną akcję, nie zostawia śladu, jeśli celowo go nie zapiszemy.
Co jest potrzebne, by mieć zapis#
To, żeby dowód powstawał sam, w trakcie pracy, wymaga świadomej decyzji, a nie jednego ustawienia w konfiguracji. W praktyce oznacza to instrumentację środowiska runtime, tak by każdy krok generował zapis w uniwersalnym formacie; wysyłanie tych zapisów do ustrukturyzowanej bazy, którą można przeszukiwać za pomocą zapytań, a nie do stosu tekstu, który trzeba filtrować; rejestrowanie kluczowych pól: promptu systemowego, pobranego kontekstu, wejść i wyjść narzędzi, zgody człowieka i finalnej akcji; zabezpieczenie bazy przed modyfikacją, tak by każda zmiana była widoczna; i przechowywanie danych wystarczająco długo, by spełnić wymogi prawa.
Przez ostatnie kilka miesięcy przyglądałem się dwóm bardzo różnym rozwiązaniom agentowej infrastruktury i oba są zbudowane wokół tej idei. Pierwsze to framework, na którym zespoły inżynierskie budują własne agenty: gdy agent działa, framework zapisuje każdą decyzję, każdą akcję i osobę, która ją zatwierdziła, do ustrukturyzowanych, przeszukiwalnych rekordów. Dzięki temu na pytanie „pokaż mi każdą nieodwracalną akcję tego agenta z zeszłego kwartału i kto ją zatwierdził” odpowiada jedno zapytanie do bazy, a nie żmudne dochodzenie. Drugie to system, w którym agenty piszą i wdrażają oprogramowanie: informacja o tym, co trafiło na produkcję i za czyją zgodą, powstaje na bieżąco. Żaden z tych systemów nie traktuje śladu audytowego jako raportu do wygenerowania w przyszłości. W obu zapis powstaje przy okazji wykonywanej pracy.
Najtrudniejsza część nie jest techniczna. Aby udowodnić, co agent zdecydował, trzeba przechowywać to, co widział, a to często obejmuje dane osobowe. Kompletność dowodów i minimalizacja danych to dwie przeciwstawne siły, a żadne narzędzie nie rozwiąże tego konfliktu za nas. To decyzja projektowa: co przechowywać w całości, co jako referencję, jak długo. I należy ona do nas, nie do dostawcy.
Prawo wymaga tego samego#
To nie tylko dobra praktyka. Unijne rozporządzenie o AI, w Artykule 12, wymaga od systemów wysokiego ryzyka automatycznego rejestrowania zdarzeń przez cały cykl ich życia. Słowem-kluczem jest „automatycznie”: zapis ma być tworzony przez system w trakcie działania, a nie składany ręcznie po fakcie. Argument inżynierski i wymóg prawny prowadzą do tego samego wniosku.
Czasu jest więcej, niż było. Obowiązki dla systemów wysokiego ryzyka z Załącznika III, które obejmują wiele powszechnych zastosowań agentów – decyzje o roszczeniach, ocenę zdolności kredytowej czy selekcję kandydatów – zostały przesunięte przez unijny Digital Omnibus i zaczną obowiązywać dopiero od 2 grudnia 2027. To jednak czas na przygotowania, a nie odroczenie problemu. Architektury dowodów nie da się dorobić w ostatnim kwartale przed terminem, bo system, który nie zapisywał od początku, nie ma czego odtworzyć. Gdy obowiązek już zacznie działać, kary sięgają 15 mln € lub 3% światowego obrotu. W Polsce to z jednej strony działka UODO w kwestii ochrony danych, a z drugiej KNF, gdy tylko agent zaczyna działać w procesach bankowych lub ubezpieczeniowych. Żadna polska firma nie opublikowała jeszcze, w jaki sposób audytuje działania swoich agentów. Firma, która już dziś potrafi na pytanie „co zrobił wasz agent i jak to udowodnicie?” odpowiedzieć zapytaniem do bazy, wyprzedza rynek, który traktuje grudzień 2027 jako odległą przyszłość.
Źródło dowodów wybiera się na etapie decyzji o środowisku runtime, a nie wtedy, gdy dzwoni audytor. Narzędzie, które pozwala obserwować agenty, to nie to samo co narzędzie, które pozwala udowodnić, co zrobiły. A tej różnicy nie widać na demo.
Briefing#
Microsoft, kilka dni po tym, jak Amazon przeznaczył 1 mld USD na własny zespół inżynierów wdrażających AI u klientów, powołał osobną spółkę z budżetem 2,5 mld USD i ok. 6000 inżynierów, by robić to samo (TechCrunch, The AI Insider). Producenci modeli sami wchodzą w warstwę wdrożeń i doradztwa, przez co inaczej wygląda wybór między budową u siebie a zakupem gotowego rozwiązania, i co innego zaczyna znaczyć niezależność firmy.
OpenAI miało rzekomo prowadzić rozmowy o przekazaniu 5% udziałów w firmie rządowi USA (CNBC). Każdy plan ciągłości działania lub pozyskiwania modeli oparty na jednym amerykańskim laboratorium frontier jest teraz obarczony zmienną polityczną, która nie ma nic wspólnego z technologią.
Czołowi europejscy bankierzy i nadzorcy finansowi ostrzegli, że AI rozwija się szybciej niż regulacje, które mają je kontrolować (CNBC). Nastroje nadzorcze w unijnym sektorze finansowym zaostrzają się, mimo że terminy dla systemów wysokiego ryzyka z AI Act właśnie przesunęły się na 2027 rok. Presja nadchodzi więc szybciej niż same przepisy, niezależnie od formalnej daty. Należy się spodziewać, że KNF i podobne jej instytucje zaczną zadawać trudniejsze pytania.
Pytania dla zarządu#
- Czy w przypadku każdego z naszych agentów zapis jego działań powstaje na bieżąco, w trakcie pracy, czy jest składany po fakcie, na żądanie?
- Czy na pytanie „pokaż mi każdą nieodwracalną akcję podjętą przez tego agenta w ostatnim kwartale i powiedz, kto ją zatwierdził” możemy odpowiedzieć, zadając jedno zapytanie do bazy, czy jest to cały projekt?
- Czy traktujemy narzędzie typu observability jak ślad audytowy i czy sprawdziliśmy, czy jego logi można samplować, edytować lub wyłączyć?
- Czy dla naszych zastosowań agentów wysokiego ryzyka budujemy ślad dowodowy już teraz, gdy mamy czas do grudnia 2027, czy będziemy go dorabiać pod presją terminu? I kto w firmie odpowiada za konflikt między logowaniem wystarczającej ilości danych do udowodnienia decyzji a przechowywaniem nie więcej danych osobowych, niż to konieczne?
Podsumowanie#
Gdy agent działa samodzielnie, w danym kroku nie ma człowieka, który zostawiłby ślad, więc jedynym dowodem jest to, co system zapisze w trakcie pracy. Odtwarzanie tego śladu po fakcie sprawdzało się, gdy decyzje zapadały w tempie pracy człowieka; zawodzi, gdy agent wykonuje tysiące operacji w wielu systemach. Istnieją narzędzia do obserwowania agentów, ale zbudowano je do debugowania, nie do udowadniania: ich logi można samplować, edytować lub wyłączyć, a kluczowa treść jest domyślnie nieaktywna. Sprawienie, by dowód powstawał sam, w trakcie pracy, to świadoma decyzja: generowanie zapisu na bieżąco, w trakcie działania agenta, do przeszukiwalnej i zabezpieczonej przed modyfikacją bazy, z odpowiednim okresem przechowywania. Artykuł 12 AI Act wymaga dokładnie tego – zapisu automatycznego, a nie ręcznego – a obowiązki dla systemów wysokiego ryzyka zostały przesunięte na grudzień 2027: to czas, by zbudować to porządnie, a nie powód, żeby czekać. Tę decyzję podejmuje się, wybierając środowisko runtime.
Zachowaj równowagę, Krzysztof Goworek
Krzysztof Goworek jest założycielem Quintant — firmy doradczej, która prowadzi przedsiębiorstwa od eksperymentów AI do realnej, mierzalnej wartości.