ИИ-инцидент шире ошибки модели
Сбой может возникнуть в prompt, retrieval, permissions, tool, модели, фильтре или UI. Пользователь видит один ответ, но расследование требует trace всей цепочки и версий каждого компонента.
Классы инцидентов
Разделите data exposure, unauthorized action, harmful output, systematic hallucination, availability и runaway cost. Severity определяется ущербом и охватом, а не тем, насколько необычно выглядит ответ.
Что подготовить заранее
Назначьте owner, каналы связи, kill switches, rollback targets и контакты провайдеров. Версионируйте prompts, models, indexes и policies. Проводите tabletop exercise с реальным сценарием LLM-инцидента.
Первые действия
Остановите опасные actions, сузьте трафик, отключите скомпрометированный tool или версию. Не уничтожайте logs при ротации ключей. Зафиксируйте timestamps, trace IDs, affected tenants и состояние конфигурации.
Сохранение evidence
Храните минимально необходимый prompt manifest, retrieved chunk IDs, tool requests/results, policy decisions и model version. Чувствительный payload защищайте отдельными правами и retention, не копируйте его в общий чат инцидента.
Containment и recovery
Варианты: переключить model alias, отключить retrieval source, перевести tool в read-only, ужесточить approval, отозвать ключ или вернуть предыдущий index snapshot. Recovery подтверждается smoke и regression eval, а не только зелёным healthcheck.
Коммуникация
Сообщайте подтверждённые факты, охват, временные меры и следующий update. Не называйте гипотезу причиной до проверки. Обязательства по уведомлению зависят от данных, договора и юрисдикции - подключайте ответственных.
Postmortem, который меняет систему
Опишите цепочку условий, почему controls не сработали и как сократить blast radius. Добавьте детерминированную защиту, observability и regression case. Проверяйте закрытие действий и повторяйте tabletop.