Расцвет инструментов агентной разработки, которые поручают ИИ-агентам подготовку изменений кода, ставит вопрос об аудируемости рабочих процессов. В регулируемых секторах недостаточно знать, кто утвердил изменение: необходимо иметь возможность восстановить контекст, проверки и решения, которые к нему привели.
Внутри крупного финансового учреждения, использующего агента в своем рабочем процессе разработки, команда внутреннего аудита и комплаенса задалась конкретным вопросом. Для merge request (запроса на слияние кода), открытого агентом для обновления зависимости платежного сервиса, можно ли было указать, кто его утвердил, какие входные данные и промпты использовал агент, какие политики контроля были оценены и как воспроизвести или отменить эту задачу? У команды не было ответа. Система поставки не рассматривала работу агента как отдельную и поддающуюся аудиту транзакцию.
Diff, проверенный CI (непрерывной интеграцией, которая автоматически тестирует код) и утвержденный, доказывает, что изменение произошло. Однако он не доказывает контекст, использованный агентом, решения по политикам, оцененные перед созданием merge request, ни возможность воспроизвести результат при последующем запуске. Между тем, в регулируемых средах « как » и « почему » имеют решающее значение. Эта ситуация наблюдается на всех платформах и в организациях DevSecOps: бюджет на агентные инструменты утверждается за несколько недель, тогда как бюджет на запись выполнения, привязку идентичности и инструменты повторного выполнения либо никогда не появляется, либо рассматривается как простая стоимость соответствия.
Четыре повторяющихся исключения
Как только агенты открывают merge requests в регулируемой среде CI/CD, появляются четыре типа исключений по соответствию. Первое — это отсутствие прослеживаемости: никто не может сказать, какие данные использовал агент, будь то спецификации, извлеченный контекст, вызовы инструментов или состояние репозитория. Второе — неопределенная атрибуция идентичности, поскольку агент действовал под общим токеном службы без назначенного ответственного человека. Третье — невосстанавливаемая цепочка решений, поскольку рассуждения были зафиксированы лишь эпизодически. Четвертое — неограниченный откат: поскольку изменения агента связаны, любая отмена становится ручной работой по коммитам и репозиториям.
Последующее восстановление заключается в изучении журналов бесед, частичных выходных данных CI и еще доступных следов агента. В большинстве организаций никто не учитывает часы, еженедельно затрачиваемые на эту задачу, что объясняет, почему ее стоимость остается невидимой. Источник предлагает простой тест: способна ли команда менее чем за час подготовить досье доказательств, включающее спецификации задачи, состояние репозитория, оцененные проверки и ответственного человека, инициировавшего действие?
« Сначала поставить » и его ограничения
Стратегия « Сначала поставить, потом управлять » может работать, когда агенты ограничены узкими областями, такими как генерация тестов, небольшие рефакторинги или обновление документации, при наличии надежного человеческого ревью. Однако она рушится, когда команды выходят за эти рамки, когда библиотеки промптов множатся с несогласованной журнализацией и когда общие токены делают атрибуцию невозможной в масштабах всего портфеля. В статье также приводится пример крупной компании, которая хотела построить основу рабочего процесса перед масштабированием агентов: проект платформы растянулся на несколько кварталов, и команды в итоге обошли его.
В статье подчеркивается, что « конкурентное давление вознаграждает скорость, в то время как регуляторы вознаграждают способность к восстановлению ». В ней описывается цена этого разрыва: недостающие доказательства, обнаруженные во время проверки, недели на исправление и расширяющийся радиус воздействия с каждым плохо зафиксированным действием агента. В связи с этим упоминается Crédit Agricole CIB, которая, согласно тексту, осуществляет поставку, объединяющую тысячи разработчиков из десятков стран на единой платформе DevSecOps, что является необходимым условием для аудита агентной работы.
Обозначить и измерить работу
Источник рекомендует рассматривать эту задачу как полноценный продукт под названием « Записанное выполнение для агентного CI/CD », с ресурсами, объединяющими инжиниринг платформы, безопасность, аудит и опыт разработчика. Его результаты включают схему записи, фиксирующую входные данные, выходные данные, вызовы инструментов и версию модели; привязку идентичности, связывающую каждое действие с ответственным человеком; журналы решений по политикам; а также механизмы повторного выполнения и отката. Мониторинг может опираться на глубину очереди исключений, медианное время получения доказательств, процент успешных повторных выполнений и процент повторного открытия исключений.
Если нужно сделать только один шаг, текст советует начать с наиболее рискованных случаев, таких как изменения зависимостей, изменения Infrastructure as Code и настройки безопасности. Последний предлагаемый тест заключается в том, чтобы попросить команду чисто отменить объединенное изменение, написанное агентом, опираясь исключительно на записанные артефакты.
