Rządzone agenty to nieefektowna, ale decydująca część dzisiejszej rozmowy o AI w przedsiębiorstwie. Faza pilotażu — kiedy zespół pokazuje na demie, że model "potrafi odpowiedzieć z bazy wiedzy" — w większości dużych organizacji powoli się kończy. Tym, co zostaje, są systemy, które codziennie czytają dane klienta, wywołują narzędzia, podejmują decyzje i zostawiają ślady — często bez właściciela, bez klasyfikacji i bez rejestru. Naszym zdaniem najbliższe osiemnaście miesięcy przetrwają w produkcji te wdrożenia, w których klasyfikacja danych, nadzór człowieka i ścieżka audytu są częścią runtime'u, a nie dokumentem doklejonym po incydencie zarządczym.
Ten tekst nie jest playbookiem implementacyjnym ani przewodnikiem po konkretnym produkcie. Jest notatką architektoniczną dla osób, które będą musiały odpowiedzieć audytorowi, regulatorowi albo zarządowi na pytanie, kto pozwolił agentowi zrobić to, co zrobił. Opisujemy trzy filary, które naszym zdaniem muszą znaleźć się w architekturze odniesienia każdej organizacji wdrażającej agentów w środowisku regulowanym — i pięć anty-wzorców, które w naszej praktyce zwracają się z odsetkami.
Trzy filary rządzenia agentami
1. Klasyfikacja danych — jaką klasę informacji agent może przeczytać, zapisać i przekazać dalej. "Dobry" obraz to klasyfikacja danych, która nie zatrzymuje się na granicy skrzynki mailowej i pliku w SharePoint, ale wchodzi do kontekstu modelu i do każdego wywołania narzędzia. Każdy dokument, fragment bazy wiedzy i pole rekordu CRM ma poziom wrażliwości (publiczne, wewnętrzne, poufne, dane osobowe, dane regulowane), a agent w czasie wykonania wie, co mu wolno wpiąć w prompt, a czego nie. Klasyfikacja propaguje się przez łańcuch wywołań — jeśli narzędzie A zwraca dane poufne, narzędzie B i model wiedzą o tym i działają w odpowiednim trybie. Tryb awarii, którego unikamy: dane regulowane lądują w publicznym endpointu modelu, bo "tak się złożyło, że RAG pobrał wszystko". Konkretny artefakt, który zespół powinien posiadać: macierz klasyfikacji danych dla agentów — tabela źródeł, poziomów i dozwolonych ścieżek, z właścicielem biznesowym i wersjonowaniem.
2. Human-in-the-loop — gdzie człowiek faktycznie zatwierdza, a gdzie tylko widzi. "Dobry" obraz to świadomy projekt punktów decyzyjnych: agent autonomicznie wykonuje to, co jest odwracalne i tanie w błędzie, a zatrzymuje się przed działaniami nieodwracalnymi, regulowanymi albo o wysokiej wartości — i prosi konkretną rolę o zatwierdzenie z pełnym kontekstem. Tryb awarii, którego unikamy: human-in-the-loop sprowadza się do klikania "OK" w skrzynce, bo zatwierdzający nie ma czasu, kontekstu ani danych, żeby sensownie odmówić — i w praktyce staje się gumową pieczątką. Metryka, która mówi, czy pętla jest realna, jest jakościowa, ale obserwowalna: udział odrzuceń i modyfikacji w decyzjach zatwierdzających. Jeśli ten udział od miesięcy wynosi zero, naszym zdaniem nie macie human-in-the-loop — macie teatr nadzoru. Konkretny artefakt: rejestr punktów zatwierdzeń — lista miejsc w przepływie, gdzie wymagana jest akceptacja człowieka, z rolą, czasem reakcji i historią decyzji.
3. Ścieżka audytu — co zostaje zapisane, na jak długo i jak to broni się przed regulatorem. "Dobry" obraz to log, który dla każdej decyzji agenta utrzymuje pięć elementów: prompt (z metadanymi klasyfikacji), model i jego wersja, narzędzia wywołane wraz z parametrami i wynikami, podjęta decyzja, oraz — jeśli była wymagana — tożsamość zatwierdzającego i znacznik czasu. Polityka retencji jest dopasowana do reżimu prawnego danych (inna dla danych osobowych, inna dla dokumentacji księgowej, inna dla decyzji kredytowych), a log jest niezmienialny w okresie retencji. Tryb awarii, którego unikamy: logujemy prompt i odpowiedź, ale nie logujemy kontekstu wpiętego z RAG ani parametrów wywołanych narzędzi — i w dniu audytu nie umiemy odtworzyć, dlaczego agent podjął tę konkretną decyzję. Konkretny artefakt: rejestr systemów AI w duchu klasyfikacji ryzyka EU AI Act, z odnośnikiem do audit sinka i polityki retencji per system.
Architektura odniesienia (krótki przegląd)
Naszym zdaniem rządzony agent w przedsiębiorstwie wygląda end-to-end mniej więcej tak. Żądanie wchodzi przez bramkę klasyfikacji, która przypina do kontekstu poziom wrażliwości danych użytkownika i samego zapytania. Następnie silnik polityk decyduje, co wolno dalej: które modele, które narzędzia, które źródła danych są dopuszczone dla tej klasy. Wywołanie modelu odbywa się z kontekstem zbudowanym tylko z dozwolonych źródeł, a cały kontekst wpięty w prompt jest logowany razem z odpowiedzią. Brama narzędzi pośredniczy między modelem a światem — żadne narzędzie nie jest wywoływane bezpośrednio, każde przechodzi przez warstwę autoryzacji, limitów i logów. Tam, gdzie decyzja jest nieodwracalna, regulowana albo o wysokiej wartości, bramka zatwierdzenia wstrzymuje wykonanie i kieruje sprawę do właściwej roli ludzkiej z pełnym kontekstem decyzyjnym. Wszystkie te kroki — od klasyfikacji po wynik — trafiają do audit sinka z polityką retencji i niezmienialnością. To nie jest opis produktu; to docelowa architektura, którą zespół architektury powinien umieć narysować na jednej kartce zanim wybierze dostawców.
Pięć anty-wzorców, które zwracają się z odsetkami
- Polityka bezpieczeństwa istnieje w dokumencie, nie w runtime. Reguły są spisane w PDF-ie ładu informacyjnego, ale w czasie wykonania nic ich nie egzekwuje — agent działa zgodnie z polityką tylko wtedy, kiedy ktoś pamiętał ją zakodować.
- Agent ma uprawnienia jak człowiek, ale nikt nie zatwierdza jego decyzji. Konto serwisowe agenta dziedziczy uprawnienia "doświadczonego operatora", tylko że człowiek operator pracuje pod nadzorem zespołu, a agent działa w nocy bez nikogo po drugiej stronie.
- Logujemy prompt, nie logujemy kontekstu i narzędzi. Mamy zapis pytania i odpowiedzi, ale nie wiemy, jakie fragmenty bazy wiedzy zostały wpięte, jakie narzędzia agent wywołał i z jakimi parametrami — czyli nie umiemy zrekonstruować decyzji.
- Human-in-the-loop = klikanie "OK" bez kontekstu. Zatwierdzający widzi powiadomienie, ale nie widzi danych, na których agent oparł rekomendację — i odrzucenie staje się fizycznie trudniejsze niż akceptacja.
- Brak właściciela rejestru systemów AI. Nikt w organizacji nie utrzymuje aktualnej listy działających agentów, ich klasy ryzyka i właściciela biznesowego — w dniu audytu rejestr powstaje wstecznie i wszyscy o tym wiedzą.
Następne 90 dni — co może zrobić CIO / CTO
Niezależnie od dojrzałości obecnego portfela AI, w ciągu najbliższego kwartału warto autoryzować trzy ruchy, które naszym zdaniem nie wymagają nowego budżetu inwestycyjnego — wymagają decyzji zarządczej. Po pierwsze — rejestr systemów AI z właścicielem biznesowym, klasą ryzyka (w duchu EU AI Act), klasyfikacją danych wejściowych i odnośnikiem do audit sinka; jeśli rejestru dziś nie ma, niech powstanie wersja minimum w trzydzieści dni, prowadzona jak rejestr ryzyka. Po drugie — przegląd punktów human-in-the-loop w działających przepływach z agentami: gdzie człowiek powinien zatwierdzać, gdzie tylko widzi, gdzie pętla jest teatrem — i jakie modyfikacje wprowadzić w następnym sprincie. Po trzecie — audyt logów decyzyjnych jednego wybranego systemu: czy jesteśmy dziś w stanie zrekonstruować pojedynczą decyzję sprzed trzydziestu dni z pełnym kontekstem; jeśli nie, to jest pierwsza luka do zamknięcia. To nie jest pełna metodologia ładu AI — to wersja minimum, którą można przedstawić zarządowi w najbliższym przeglądzie architektury.
Przynieś architekturę
Jeśli projektujecie ład nad agentami w przedsiębiorstwie albo właśnie próbujecie zamknąć fazę pilotażową bez incydentu zarządczego w pierwszych miesiącach produkcji, przynieście tę architekturę. Pracujemy od konkretu — trzy filary powyżej i rejestr systemów AI to dobry punkt wyjścia do rozmowy. Opisz swój przypadek: mailto:[email protected]?subject=Rozmowa%20z%20Aurora%20AI.