Пентагон вводит 3 проверки для каждого фрагмента кода от ИИ

ИИ-агент за минуту обновил библиотеку, поправил сборку и открыл запрос на слияние. Патч выглядит аккуратно, тесты на первый взгляд зелёные. Но кто отвечает, если агент незаметно ослабил проверку прав доступа? И можно ли спустя полгода установить, какая модель внесла изменение и кто разрешил его выпустить?

Новая инструкция Министерства войны США 8430.01 отвечает жёстко: код, созданный или изменённый ИИ, считается непроверенным, пока команда не подтвердит его качество. Разработчики остаются ответственными за безопасность, работоспособность и целостность результата. Для критических функций требуется одобрение человека.

Это правило действует для организаций ведомства и программ закупки, в состав которых входит программное обеспечение. Но сам подход полезен любой компании, которая уже пускает агентов в репозитории: скорость генерации кода не заменяет доказательства того, что изменение безопасно.

Что именно нужно доказать

Инструкция сводит работу с ИИ к трём практическим требованиям.

Первое — прослеживаемость. Команда должна понимать, где участвовал ИИ, какая модель и версия использовались и какие действия выполнял агент. Одной подписи «сделано с ИИ» мало. История должна связывать изменение с конкретным процессом и человеком, который его запустил.

Второе — проверка. Код агента проходит те же тесты, анализ зависимостей, поиск уязвимостей и правила одобрения, что и код человека. Для функций, от которых зависят безопасность системы или жизнь людей, последнее решение принимает назначенный специалист.

Третье — границы данных. Запросы, исходный код и непубличная информация нельзя без разбора отправлять внешней модели. Организация должна заранее определить разрешённые модели, места их запуска и правила хранения данных.

Как это выглядит на обычном патче

Допустим, агент предлагает обновить библиотеку авторизации. Нормальный процесс выглядит так: агент создаёт отдельную ветку и запрос на слияние; журнал фиксирует его служебную учётную запись и разработчика, который поставил задачу; конвейер запускает тесты, анализ зависимостей и сканирование безопасности. Поскольку изменение затрагивает защищённый участок, система требует одобрения ответственного инженера. Агент может исправить найденную ошибку, но не может сам снять блокировку и отправить код в основную ветку.

Такой порядок не запрещает автономность. Он задаёт её пределы. Агенту можно поручить поиск обновлений, подготовку патча и повторный запуск проверок. Право на слияние или выпуск зависит от риска: правка документации может пройти автоматически, а изменение авторизации — только через человека.

GitLab приводит собственную платформу как способ реализовать эти требования: журналы аудита, защищённые ветки, правила одобрения, сканирование зависимостей и самостоятельно размещённый шлюз к моделям. Это полезный пример, но источник остаётся коммерческим материалом. Инструкция описывает требования, а не обязывает использовать GitLab; те же принципы можно собрать в GitHub, Azure DevOps или внутренней системе.

Что изменить в процессе разработки

Начните не с выбора очередного ИИ-инструмента, а с карты полномочий. Зафиксируйте, какие репозитории и данные доступны агенту, какие действия он выполняет самостоятельно и где обязан остановиться. Выделите защищённые ветки, критические файлы и операции выпуска. Для них назначьте владельцев и обязательные проверки.

Затем добавьте происхождение изменений в журнал аудита: модель, её версию, служебную учётную запись агента и человека-инициатора. Не полагайтесь только на комментарий в запросе на слияние — он легко теряется и плохо подходит для расследования.

Главный вывод простой: ИИ ускоряет написание патча, но не переносит ответственность с команды на модель. Если компания не может показать, кто запустил агента, что именно было проверено и кто разрешил выпуск, у неё пока не управляемая разработка с ИИ, а быстрый генератор технического долга.