AI-инцидент — это не только outage. Это правдоподобный вредный ответ, лишний tool call, раскрытие данных, неконтролируемая стоимость, повтор бизнес-действия или незаметное падение качества.
Хороший план позволяет обнаружить, ограничить, расследовать и восстановить систему, не ожидая объяснения от агента.
Определите AI-инцидент и тяжесть
Создайте уровни по последствиям: утечка, лишнее действие, повреждение записей, вред клиенту, регуляторный риск, финансовая потеря, недоступность и потеря мониторинга.
Учитывайте near miss. Заблокированная попытка использовать лишнее право показывает необходимость контроля.
Назначьте владельцев и контакты
Нужны incident lead, технический и бизнес-владелец, security/privacy, коммуникации и контакт поставщика. Определите право остановки и согласование запуска.
Runbook должен быть доступен вне пострадавшего AI. Храните зависимости, data flow, escalation и rollback.
Обнаруживайте по техническим и бизнес-сигналам
Используйте мониторинг агентов: пропуск trace, лишний инструмент, повтор записи, ошибка схемы, скачок стоимости, задержки, качество и отмены людьми.
Сообщения пользователей направляйте в один intake с correlation ID и временем.
Сначала ограничьте ущерб
Остановите опасную способность, не обязательно весь бизнес. Отзовите tool, включите read-only, передайте очередь людям, снизьте лимит или включите fallback.
Kill switch должен быть внешним. Сохраните доказательства до изменения конфигурации, если это не продлевает вред.
- Подтвердить и назначить severity.
- Остановить или ограничить действия.
- Защитить аккаунты, токены и данные.
- Зафиксировать last known good.
- Уведомить владельцев.
Сохраните доказательства и оцените scope
Сохраните traces, логи, версии модели и промпта, tools, права, входы, выходы, approvals, API response и внешние изменения.
Определите затронутые записи, пользователей, период и решения. Ищите тот же паттерн шире первого случая.
Восстанавливайте контролируемо
Исправьте данные из авторитетного источника, при необходимости смените credentials, разверните проверенную версию и сделайте reconciliation. Начните с canary или shadow.
Повторите предзапусковые evals. Запуск разрешён, когда причина контролируется, мониторинг активен и rollback доступен.
Превратите выводы в контроль
Разделите trigger, root cause, failure контроля и impact. Назначьте corrective actions, владельцев и сроки. Добавьте паттерн в regression tests.
NIST SP 800-61r3 связывает response с Detect, Respond и Recover, а подготовку — с Govern, Identify и Protect.
Сообщайте факты
Укажите известное, scope, containment, действие клиента и время обновления. Юридические уведомления согласуйте с профильными специалистами.
Сгенерированная сводка не должна быть единственной записью. Важную коммуникацию утверждает человек.
Небольшой инцидент, улучшивший процесс
При большой трёхъязычной передаче API я нашёл повреждённый UTF-8 символ после принятия черновика сервером. Публикация остановилась, записи сохранились в draft для сравнения.
Я изменил передачу, заново отправил полные тела, перечитал записи и потребовал нулевое расхождение по всем 21 полям. После публикации проверил публичные страницы.
Исправление превратилось в постоянный regression rule. Ценность была не в ручной правке, а в новом автоматическом контроле.
Вопросы и ответы
Когда включать kill switch?
Когда продолжение увеличивает ущерб или критический контроль ненадёжен. Право и пороги задайте заранее.
Нужно ли выключать весь AI?
Не автоматически. Ограничьте пострадавшую способность и зависимости, сохранив безопасную работу.
Какие доказательства важны?
Трассы, версии, права, tool calls, входы, выходы, approvals, API response и внешние изменения.
Кто разрешает запуск?
Назначенные бизнес- и технический владельцы с security, privacy или legal по ситуации.
Когда recovery завершён?
Состояние сверено, причина контролируется, тесты пройдены, мониторинг работает, коммуникация завершена, задачи отслеживаются.
Операционный лист контроля
До согласования занесите каждый контроль в таблицу: владелец, доказательство, порог и дата следующей проверки. Фраза «контролировать качество» не исполнима. Правило «операционный владелец каждый понедельник проверяет долю существенных исправлений и ставит процесс на паузу выше согласованного порога» можно проверить.
Свяжите контроль с последствием для бизнеса. Если ошибка схемы может повредить карточку клиента, опишите containment и reconciliation. Если всплеск стоимости объясняется сезонным объёмом, задайте контекст, защищающий от ложной эскалации.
Версионируйте промпты, схемы, политики, инструменты и внешние зависимости. Результат без конфигурации нельзя воспроизвести. У исключений должны быть причина, владелец и срок окончания, иначе временный обход станет невидимой постоянной политикой.
Отрепетируйте человеческий путь. Назначенный владелец должен найти доказательства, остановить или ограничить workflow, включить fallback и объяснить состояние без просьбы к самому AI диагностировать себя.