Od modeli do agentów: przeprojektowanie trzech linii obrony

Sztuczna inteligencja typu agentowa łamie zasady zarządzania opracowane dla tradycyjnego oprogramowania i konwencjonalnych modeli, ale tę tezę łatwiej zobaczyć na konkretnym przykładzie. Lata pracy nad MLOps, obejmujące inwentarze modeli, procesy walidacji, monitorowanie odchyleń oraz procedury zatwierdzania w środowiskach korporacyjnych i usług finansowych, nie zostają porzucone po wdrożeniu przez organizację modeli językowych i agentów. To, co się zmienia, jest węższe i bardziej specyficzne, niż przypuszczają większość ludzi.

Załóżmy, że zespół zajmujący się ryzykiem modeli przetwarza zwykłą wniosek o przyjęcie do pracy. Formularz zawiera standardowe pytania dotyczące danych treningowych, numeru wersji, statusu zatwierdzenia oraz daty ostatniej weryfikacji odchylenia, a zespół już przetworzył wiele takich wniosków. Następnie pojawia się opis systemu: cztery współpracujące agenty, sześć narzędzi dzielonych między nie, indeks wyszukiwania odbudowywany codziennie oraz wynik uzyskany w wyniku sekwencji kroków, z których każdy wydawał się poprawny. Nic z tego nie pasuje do formularza.

Sondaż McKinsey AI Trust z 2026 roku, obejmujący około pięciuset organizacji, pokazuje podobny obraz: około jedna trzecia przedsiębiorstw twierdzi, że ich poziom dojrzałości w zakresie zarządzania jest wystarczający dla już działających autonomicznych agentów. Pozostałe nadal używają starego formularza i mają nadzieję, że będzie on wystarczająco dobry. Zazwyczaj tak nie jest, więc istotnym zadaniem jest określenie, gdzie występują błędy.

Co już obejmuje istniejący program

Rządyzna w obszarze MLOps to zbiór mechanizmów kontrolnych, które zapewniają wiarygodność tradycyjnego modelu uczenia maszynowego od etapu szkolenia aż do wycofania go z użycia. W praktyce:

• wersjonowanie modeli, dzięki czemu zawsze jest jasne, który model jest używany w produkcji i dlaczego;
• monitorowanie odchyłek, które wykrywają spadek wydajności wraz ze zmianami w danych wejściowych;
• śledzenie pochodzenia danych aż do zbiorów używanych do szkolenia i walidacji;
• procedury zatwierdzania przed każdym wypuszczeniem w produkcji;
• zasady zarządzania zmianami i procesami CI/CD, oczekiwane od każdego oprogramowania produkcyjnego, które stanowi część tego programu, a nie coś na zasadzie dodatku.

Żaden z tych mechanizmów nie działa samoczynnie. Ktoś musi być odpowiedzialny za każdą kontrolę, a ktoś inny musi sprawdzić, czy dana osoba faktycznie wykonała swoje zadanie.

Odpowiedzialność jest zazwyczaj rozdzielana za pomocą trzech linii obrony, ramy, której banki i inne regulowane branże od dawna używają do określania obowiązków. Jedna uwaga dotycząca dokładności: Instytut Biegłych Rewidentów Wewnętrznych w 2020 roku przemianował to na Model Trzech Linii, przenosząc akcent na tworzenie wartości zamiast na czystą obronę. W kręgach zajmujących się finansami i ryzykiem modeli nadal mówi się o trzech liniach obrony, podobnie jak w tym tekście, chociaż oficjalna nazwa się zmieniła.

W tradycyjnym programie MLOps podział wygląda następująco:

• Pierwsza linia, obejmująca produkt, dane i inżynierię, odpowiada za rozwój, testowanie, wdrożenie oraz dokumentację modeli.
• Druga linia, obejmująca zgodność z regulacjami i zarządzanie ryzykiem, ustala zasady używania modeli, monitoruje istnienie uprzedzeń oraz sprawdza aplikacje o wysokim ryzyku przed ich uruchomieniem.

Trzecia linia, audyt wewnętrzny, ma najwęższe zakres zadania: niezależnie potwierdza, że pierwsze dwie linie realizują to, co deklarują, nie tworząc ani nie zatwierdzając niczego samodzielnie.

Ta struktura jest dojrzała i dobrze zrozumiana, i sprawdza się w systemach, dla których została zaprojektowana, mianowicie w modelach o stałej strukturze, które są walidowane raz i monitorowane pomiędzy cyklami przeglądów.

Jak każda linia musi ulec zmianie w przypadku agentów

Rządy AgentOps opierają się na tych samych trzech liniach, ale treść, którą każda z nich sprawdza, jest inna, ponieważ systemy zachowują się różnie. Poniższe różnice sprowadzają się do pięciu konkretnych różnic.

Jeden artefakt staje się wieloma. Klasycznym modelem jest jedna rzecz do wersjonowania. System czterech agentów to zbiór składników: model bazowy, cztery prompty systemowe, sześć definicji narzędzi oraz warstwa pobierania danych, która aktualizuje się samodzielnie. Każdy z tych elementów może zmieniać zachowanie, dlatego konieczne jest wersjonowanie i testowanie każdej części. Wygląda to mniej jak wpis w rejestrze, a bardziej jak prompty i schematy narzędzi traktowane jako kod źródłowy, z kontrolą wersji, przeglądaniem pull-requests oraz testami kanaryjnymi na zbiorze kontrolnym przed wdrożeniem jakichkolwiek zmian. Śledzenie tylko modelu pozostawia około trzech czwartych aspektów zachowania bez zarządzania.

Prawidłowy wynik mieści się w akceptowalnym zakresie. Jeśli podać tradycyjnemu modelowi ten sam wprowadzony danych, zwróci on taki sam wynik, dlatego walidacja jest prosta. Model językowy typu LLM może przy różnych uruchomieniach dostarczyć dwa różne, ale uzasadnione odpowiedzi. Dlatego druga linia przestaje sprawdzać, czy odpowiedź jest poprawna, a zaczyna sprawdzać, czy odpowiedzi w większości przypadków pozostają w akceptowalnym zakresie. Wymaga to bramy oceny z określonymi progami, na przykład minimalnego wskaźnika prawidłowych odpowiedzi w oznaczonym zbiorze testowym przed publikacją, oraz mechanizmu przeglądu przez człowieka, gdy poziom pewności lub wyniki oceny spadną poniżej ustalonego progu. Uzgodnienie z zespołem ds. zgodności, co oznacza „akceptowalne w większości przypadków” dla danego przypadku użycia, to odrębny projekt, który nie można zrealizować w ciągu popołudnia.

Jeden właściciel staje się łańcuchem. Samotny model dokonujący pojedynczej prognozy ma oczywistego właściciela. System składający się z czterech agentów nie ma go. Gdy ostateczny wynik jest błędny, ale żaden z kroków nie był błędny indywidualnie, diagnostyka wymaga dziennika decyzji, który rejestruje pośrednie przekazy, a także ostateczny produkt: dane wejściowe dla każdego agenta, każdą decyzję oraz to, co zostało przekazane dalej. Bez niego nikt nie może stwierdzić, który agent jest odpowiedzialny, a pierwsza i druga linia konsultują się w tej kwestii po incydencie, zamiast uzgodnić to wcześniej.

Monitorowanie dewiacji to nie monitorowanie zachowania. Sprawdzania dewiacji porównują przewidywania z znaną linią bazową. Są one niewidome wobec tego, co agent robi w trakcie działania: jakich narzędzi używa, jakie działania podejmuje oraz czy pozostaje w ramach określonego zakresu. Platformy umożliwiające obserwację agentów eliminują tę słabość, rejestrując cały ślad wykonywania, włączając wezwania do narzędzi, parametry oraz sposób, w jaki wyniki jednego agenta są przekazywane następnemu. Wiele z nich opiera się na otwartych standardach, takich jak OpenTelemetry, które zapewniają przenośność śladów pomiędzy różnymi dostawcami. W tym systemie ślad jest jedynym artefaktem, na podstawie którego audytor może później odtworzyć zdarzenia. Bez niego audyt trzeciej strony polega na analizie „czarnej skrzynki” i określeniu jej jako weryfikacji niezależnej.

Przeprowadzanie ponownego szkolenia kalendarza staje się ciągłą zmianą. Tradycyjne modele są ponownie szkoleniane według określonego harmonogramu: miesięcznie, kwartalnie, gdy tylko zgromadzi się wystarczająco dużo nowych danych. System oparty na RAG lub ciągłym dopasowywaniu może zmieniać swoje efektywne zachowanie tak często, jak aktualizowana jest jego baza wiedzy, być może codziennie. Jeśli warstwa wyszukiwania odświeża się co noc, trzeci element oparty na kwartalnych przeglądach sprawdza system zaledwie około dziewięćdziesiąt razy rzadziej niż ten się zmienia.

Gdzie spotykają się te dwa programy

W bezpośrednim porównaniu oba programy mają podobną strukturę. Obowiązują te same trzy elementy, a oba wymagają wersjonowania, testowania, przeglądów oraz niezależnej audytoryzy. Różnice leżą w stopniu szczegółowości, częstotliwości oraz obiektach, które są sprawdzane przez każdy z nich.

Rządyzna w obszarze MLOps nie jest tutaj błędna. Jej założenia opierały się po prostu na przekonaniu, że zachowanie modelu pozostaje stabilne pomiędzy przeglądami, a system, którego indeks wyszukiwania jest odbudowywany co noc, nie może utrzymać tej stabilności tak długo. Wszystkie pięć różnic wynika z nieudanego spełnienia tego jednego założenia: to, co kiedyś zmieniało się co miesiąc, teraz może zmieniać się codziennie, czasami bez żadnego ingerowania w model.

Zamknięcie tej luki nie wymaga tworzenia nowej funkcji rządyznej od zera. Wymaga rozszerzenia istniejących rozwiązań o funkcje, których wcześniej nie potrzebowano, oraz szczerej oceny kosztów każdej z nich:

• Pierwszy element: kontrola wersji promptów i narzędzi, wraz z testami typu canary przed ich wdrożeniem. Jest to głównie zmiana w praktykach inżynieryjnych, a nie powołanie nowego zespołu.
• Druga linia: brama oceny określająca progi akceptacji oraz pisemna ścieżka eskalacji dla decyzji podejmowanych przez kilku agentów. To prawdziwy projekt tworzenia polityk, a pierwszy etap będzie obejmował rzeczywiste negocjacje z działami prawnymi i ds. zgodności.
• Trzecia linia: narzędzia do obserwowalności w czasie rzeczywistym oraz umiejętności audytu dziennika decyzji zamiast statycznej karty modelu. Dla większości funkcji związanych z ryzykiem modeli oznacza to nowego pracownika lub intensywny kurs szkoleniowy, a nie zaznaczenie pola na starym formularzu oceny.

Żadne z tych elementów nie jest opcjonalne, jeśli celem jest wiarygodne ustalenie, który z czterech agentów podjął decyzję.

Co do tej pory powiedzieli regulatorzy

Żaden pojedynczy framework regulacyjny nie nadążył w pełni za sztuczną inteligencją agentową, ale trzy istniejące modele z różnych branż pokazują, w jakim kierunku zmierzamy.

• Ustawa UE w sprawie sztucznej inteligencji ma zastosowanie we wszystkich sektorach. Obowiązki transparentności określone w artykule 50 wchodzą w życie 2 sierpnia 2026 roku, niezależnie od innych wydarzeń. Bardziej rygorystyczne wymogi z Załącznika III dotyczące wysokiego ryzyka obowiązywały początkowo w tym samym terminie, ale proponowany pakiet Digital Omnibus, uzgodniony w zasadzie w maju 2026 roku i wciąż czekający na formalną aprobatę, opóźniłby ich wejście w życie do grudnia 2027 roku. Kalendarz zgodności powinien odnotować to opóźnienie jako w toku.
• Postępowanie FDA wobec urządzeń medycznych wykorzystujących sztuczną inteligencję jest ukierunkowane w sposób wertykalny i skupione na produkcie, a jego kluczowym narzędziem jest Predetermined Change Control Plan. Dzięki temu planowi pierwotna zgoda już obejmuje określone późniejsze aktualizacje modeli, pod warunkiem że pozostają one w ramach określonych limitów wydajności. Do tego dochodzą wytyczne dotyczące dobrych praktyk w uczeniu maszynowym oraz system jakości zmierzający do standardu ISO 13485. W praktyce kontrola zmian staje się częścią procedury zatwierdzania, a nie obowiązkiem dodawanym później.
• Finanse są pouczające przede wszystkim dzięki temu, co pominą. Wytyczne międzyagencji z 2026 roku SR 26-2, które zastąpiły SR 11-7, wyraźnie wykluczają sztuczną inteligencję generatywną i agentową ze swojego formalnego zakresu. Dojrzała struktura przyznaje, że narzędzia zaprojektowane dla jednego pokolenia modeli nie automatycznie nadają się do użycia w kolejnym, a firmy działające w jej ramach już teraz opracowują zasady zarządzania agentami, wyprzedzając organy nadzoru.

Żaden z tych trzech dokumentów nie stanowi gotowego wzoru do kopiowania. Czytane razem wskazują jedno kierunek: konieczność zmiany wcześniej ustalonych granic, poziomów ryzyka oraz otwarte uznanie niezgodności między obecnymi regulacjami a zachowaniem agentów.

Z powrotem do formularza zgłoszeniowego

Obecny formularz rejestracyjny może zostać. Obok niego zespół potrzebuje oddzielnego kwestionariusza dla systemów wielu agentów, zorganizowanego wokół trzech kryteriów, na których już się opiera, i powinien oczekiwać, że uczciwe odpowiadanie wymaga rzeczywistego wysiłku.

Który krok zostanie najpierw nadrobiony? Prawdopodobnie wersjonowanie, ponieważ przypomina problem kontroli wersji, który inżynierowie już potrafią rozwiązać. Odpowiedzialność za łańcuchowe decyzje najprawdopodobniej będzie problemem najdłużej utrzymującym się. To problem projektowania organizacyjnego w technicznym ubraniu, a żadne bramy oceny tego nie naprawią.

Literatura pokrewna

• Od pętli agentów do grafów przepływów pracy: typowane stany, bramy dowodowe i ograniczona odbudowa — Dlaczego agenci działające przez długi czas przekraczają możliwości pojedynczej pętli oraz w jaki sposób wyraźne węzły, krawędzie, typowane artefakty, zweryfikowane przejścia i uprawnienia dla poszczególnych węzłów sprawiają, że są one niezawodne.
• LLMOps dla agenta zadaniowego: MLflow Traces, Evals i brama CI — Stwórz asystenta zadaniowego PydanticAI przy użyciu FastAPI, śledź jego działanie za pomocą MLflow, oceniaj go za pomocą narzędzi GenAI oraz blokuj regresje w GitHub Actions, wszystko na lokalnych modelach.

Pamięć długoterminowa do szukania dla agentów inżynierii danych — Jak system inżynierii danych oparty na wielu agentach przestał ponownie debugować te same błędy: automatyczne rejestrowanie, dzienniki z określonym zakresem, starannie wyselekcjonowane poziomy oraz przywoływanie informacji na poziomie kontekstu.