Мы привыкли, что расследование начинается с поиска нарушителя.

Кто получил доступ? Какая уязвимость была использована? Какая учётная запись скомпрометирована? Где индикаторы компрометации?

Но что делать, если AI не был взломан?

Например, агент получил легитимный запрос, использовал разрешённые данные, вызвал разрешённый инструмент и причинил бизнесу ущерб.

Формально каждый компонент работал штатно.

Не было malware. Не было украденной учётной записи. Возможно, не было даже prompt injection.

Было нежелательное поведение сложной системы.

На мой взгляд, именно здесь проходит граница между традиционным incident response и AI incident response.

Расследовать только prompt и ответ модели бессмысленно. На решение могли повлиять system prompt, история диалога, RAG-контекст, память, версия модели, параметры генерации, результаты внешних API, полномочия агента и отсутствие human approval.

В AI-системе evidence — это не отдельный лог. Это состояние всей цепочки принятия и исполнения решения.

Поэтому до запуска значимого AI-сценария компания должна уметь ответить хотя бы на пять вопросов:

Что именно мы считаем AI-инцидентом?

Можем ли мы восстановить состояние системы на момент события?

Какие способности агента можно отключить отдельно?

Кто имеет право остановить сценарий и принять residual risk?

Как инцидент будет превращён в новый evaluation и архитектурное ограничение?

Особенно важен третий вопрос.

Containment для AI не всегда означает полное отключение. Иногда нужно отозвать конкретное разрешение, закрыть доступ к инструменту, очистить память, ограничить источники данных или временно вернуть обязательное подтверждение человеком.

Но для этого AI-система должна быть изначально спроектирована как управляемая.

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

Поэтому моя позиция достаточно жёсткая:

AI forensics начинается не после инцидента. Она начинается при проектировании observability, permissions и decision rights.

Компании много говорят о качестве моделей, но гораздо реже проверяют, смогут ли они объяснить конкретное решение после того, как оно причинит ущерб.

А кто, на ваш взгляд, должен владеть AI-инцидентом: CISO, владелец продукта, data science или руководитель затронутого бизнес-процесса?