Rozwój narzędzi rozwoju agentowego, które powierzają agentom AI przygotowywanie modyfikacji kodu, stawia pytanie o audytowalność workflowów. W sektorach regulowanych samo wskazanie, kto zatwierdził zmianę, już nie wystarcza: trzeba móc odtworzyć kontekst, kontrole i decyzje, które do niej doprowadziły.
Wewnątrz dużej instytucji finansowej wykorzystującej agenta w swoim workflow rozwoju, zespół audytu wewnętrznego i zgodności zadał sobie konkretne pytanie. Dla merge request (żądania scalenia kodu) otwartego przez agenta w celu zaktualizowania zależności usługi płatniczej, czy można było wskazać, kto ją zatwierdził, jakie dane wejściowe i prompty wykorzystał agent, jakie kontrole polityk zostały ocenione oraz jak odtworzyć lub cofnąć to zadanie? Zespół nie miał odpowiedzi. System dostarczania nie traktował pracy agenta jako odrębnej i audytowalnej transakcji.
Zatwierdzony przez CI (integrację ciągłą, która automatycznie testuje kod) i zaakceptowany diff dowodzi, że zmiana miała miejsce. Nie dowodzi natomiast kontekstu użytego przez agenta, decyzji dotyczących polityk ocenionych przed utworzeniem merge request, ani możliwości odtworzenia wyniku przy późniejszym wykonaniu. Tymczasem w środowiskach regulowanych „jak » i „dlaczego » są kluczowe. Sytuacja ta powtarza się na wszystkich platformach i w organizacjach DevSecOps: budżet na narzędzia agentowe jest zatwierdzany w ciągu kilku tygodni, podczas gdy budżet na rejestracje wykonania, powiązanie tożsamości i narzędzia do odtwarzania nigdy się nie pojawia lub jest traktowany jako zwykły koszt zgodności.
Cztery powtarzające się wyjątki
Gdy tylko agenci otwierają merge requesty w regulowanym środowisku CI/CD, pojawiają się cztery rodzaje wyjątków zgodności. Pierwszym jest brakująca proweniencja: nikt nie może powiedzieć, jakich danych użył agent, czy to specyfikacji, pobranego kontekstu, wywołań narzędzi czy stanu repozytorium. Drugim jest niejasna atrybucja tożsamości, ponieważ agent działał pod współdzielonym tokenem usługi, bez wyznaczonego ludzkiego odpowiedzialnego. Trzecim jest nieodtwarzalny łańcuch decyzyjny, ponieważ rozumowanie zostało uchwycone tylko w sposób ulotny. Czwartym jest nieograniczone cofnięcie: zmiany agenta są sprzężone, więc każde wycofanie staje się ręczną pracą obejmującą commity i repozytoria.
Rekonstrukcja post factum polega na przeglądaniu logów konwersacji, częściowych wyników CI i wciąż dostępnych śladów agenta. W większości organizacji nikt nie rozlicza godzin poświęcanych każdego tygodnia na to zadanie, dlatego jego koszt pozostaje niewidoczny. Źródło proponuje prosty test: czy zespół jest w stanie wyprodukować w mniej niż godzinę dossier dowodów zawierające specyfikację zadania, stan repozytorium, ocenione kontrole i ludzkiego odpowiedzialnego za inicjatywę?
„Najpierw dostarczaj » i jego ograniczenia
Strategia „Najpierw dostarczaj, potem zarządzaj » może działać, gdy agenci są ograniczeni do wąskich obszarów, jak generowanie testów, małe refaktoryzacje czy aktualizacja dokumentacji, przy solidnym przeglądzie ludzkim. Załamuje się jednak, gdy zespoły się od niej odrywają, biblioteki promptów mnożą się z niespójnym logowaniem, a współdzielone tokeny uniemożliwiają atrybucję na skalę portfela. Artykuł przytacza też przypadek dużej firmy, która chciała zbudować podstawę workflow przed upowszechnieniem agentów: projekt platformy rozciągnął się na kilka kwartałów, a zespoły w końcu go ominęły.
Artykuł podkreśla, że „presja konkurencyjna nagradza szybkość, podczas gdy regulatorzy nagradzają zdolność do rekonstrukcji ». Opisuje koszt tej luki: brakujące dowody odkryte podczas kontroli, kilkutygodniowa remediacja i rosnący zasięg wpływu każdej źle zarejestrowanej akcji agenta. W tym kontekście cytuje Crédit Agricole CIB, które pilotuje, według tekstu, wdrożenie łączące tysiące developerów rozsianych w dziesiątkach krajów na jednej platformie DevSecOps – warunek wymagany do audytowania pracy agentowej.
Nazywanie i mierzenie pracy
Źródło zaleca traktowanie tego przedsięwzięcia jako pełnoprawnego produktu, nazwanego „Zarejestrowane wykonanie dla agentowego CI/CD », z zasobami łączącymi inżynierię platformy, bezpieczeństwo, audyt i doświadczenie developera. Jego rezultaty obejmują schemat rejestracji przechwytujący dane wejściowe, wyjścia, wywołania narzędzi i wersję modelu, powiązanie tożsamości przypisujące każde działanie ludzkiemu odpowiedzialnemu, logi decyzji polityk oraz mechanizmy odtwarzania i cofania. Śledzenie postępów może opierać się na głębokości kolejki wyjątków, medianie czasu uzyskiwania dowodów, wskaźniku sukcesu odtworzeń i wskaźniku ponownego otwierania wyjątków.
Jeśli należy podjąć tylko jeden krok, tekst radzi zacząć od przypadków najwyższego ryzyka, jak zmiany zależności, modyfikacje Infrastructure as Code i konfiguracja bezpieczeństwa. Ostatni proponowany test polega na poproszeniu zespołu o czyste cofnięcie scalonej zmiany napisanej przez agenta, opierając się wyłącznie na zarejestrowanych artefaktach.
