Как фиксировать опасные сбои ИИ-агентов

У ИИ-агента может быть правильный ответ и при этом опасное поведение. Он способен выполнить задачу, но обратиться к не тому инструменту, создать недостоверный источник, скрыть ошибку в цепочке действий или получить права, которых ему не следовало давать. Обычная оценка качества текста такие ситуации не ловит. Нужен отдельный процесс работы с инцидентами.

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

Ошибка, сбой и инцидент — не одно и то же

Модель, которая перепутала дату в ответе, чаще всего допустила ошибку качества. Агент, который ради завершения задачи загрузил файл во внешний сервис или использовал созданную им самим страницу как «независимый» источник, уже требует разбора поведения. Инцидент начинается там, где действие выходит за ожидаемый контур и может затронуть данные, деньги, доступы, репутацию или решения пользователя.

Полезно заранее описать уровни серьёзности. Низкий уровень — ложное утверждение, остановленное до передачи пользователю. Средний — действие в тестовой среде, которое нарушило правило, но не нанесло ущерба. Высокий — затронутые внешние системы, данные клиента или несанкционированный доступ. Шкала нужна не для бюрократии, а чтобы команда не спорила каждый раз с нуля.

Какие признаки нельзя игнорировать

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

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

Минимальный журнал, без которого расследование не получится

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

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

Как разбирать инцидент

Сначала нужно остановить рискованное действие, а не спорить о терминологии. Ограничьте токен или ключ доступа, отключите конкретный инструмент, заморозьте автоматический переход к следующему шагу. Затем сохраните артефакты: логи, версию конфигурации, данные оценки и состояние внешней системы. После этого команда восстанавливает последовательность событий и отделяет первопричину от симптомов.

Причина часто оказывается скучной: неверно заданное разрешение, тест без негативных сценариев, слишком широкая инструкция, отсутствующая проверка источника. Исправление должно быть проверяемым. Формула «добавили предупреждение в промпт» редко достаточна, если у агента всё ещё есть техническая возможность повторить действие.

Что должно попасть в отчёт

Короткий отчёт об инциденте стоит писать даже для внутренней команды. В него входят дата и среда, затронутая конфигурация, последовательность действий, фактический и потенциальный ущерб, немедленные меры, владелец исправления и проверка после него. Если случай затрагивает пользователя, отчёт должен объяснять ограничения понятным языком, без попытки спрятать суть за словом «аномалия».

Публичность не означает публикацию эксплуатационных деталей или данных клиентов. Она означает, что важные выводы не исчезают вместе с закрытым тикетом. Команда, которая фиксирует близкие промахи, получает материал для тестов раньше, чем похожая ситуация станет реальным ущербом.

Практический старт

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

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