AI не был взломан, но причинил ущерб. Как расследовать такой инцидент
Представим, что AI-агент самостоятельно изменил условия договора, отправил клиенту некорректную рекомендацию, заблокировал легитимную операцию или передал внутренние данные внешнему сервису.
Команда ИБ начинает расследование, но быстро сталкивается с непривычной ситуацией.
Учётная запись не скомпрометирована. Вредоносного кода нет. Уязвимость не эксплуатировалась. Контрольные суммы файлов не изменились. Все компоненты системы формально работали так, как были спроектированы.
AI не был взломан. Он просто сделал то, чего от него не ожидали.
На мой взгляд, именно такие случаи станут одной из наиболее сложных категорий инцидентов в компаниях, внедряющих GenAI и автономных агентов. Проблема здесь не только в технологии. Она в том, что традиционный incident response ищет детерминированную цепочку событий, а AI-система принимает решения на основе изменяющегося контекста, вероятностного вывода и множества внешних зависимостей.
AI может быть не только целью, но и источником инцидента
В классическом киберинциденте обычно ищут нарушителя, точку проникновения, уязвимость, вредоносный процесс или индикатор компрометации.
В AI-инциденте ничего из этого может не быть.
Система могла:
- неправильно интерпретировать корректный запрос;
- получить недостоверные данные из RAG-хранилища;
- использовать устаревшую или загрязнённую память;
- вызвать разрешённый инструмент в неправильной последовательности;
- выполнить действие, выходящее за фактическое намерение пользователя;
- принять опасное решение из-за слишком широких полномочий;
- обработать скрытую инструкцию из документа, письма или веб-страницы;
- передать данные внешнему провайдеру в рамках формально разрешённого сценария.
В 2026 году NIST отдельно выделил проблему AI incident management, отметив появление класса событий, в которых AI-системы могут быть одновременно целью атак и самостоятельным источником риска. Среди открытых вопросов NIST называет определения, жизненный цикл, таксономию и пробелы существующих руководств. :contentReference[oaicite:1]{index=1}
Это важное изменение. Инцидент больше нельзя определять исключительно через факт компрометации.
Более практичная формулировка звучит так:
AI-инцидент — это событие, при котором поведение AI-системы привело или могло привести к неприемлемому ущербу, независимо от наличия злоумышленника.
Такой подход соответствует опубликованному In-Q-Tel определению, согласно которому AI-инциденты могут быть как намеренными, так и непреднамеренными. :contentReference[oaicite:2]{index=2}
Главная ошибка — расследовать только ответ модели
Когда AI выдаёт опасный результат, первым делом команда обычно изучает входной запрос и финальный ответ.
Этого недостаточно.
Ответ модели — только последняя видимая часть гораздо более длинной цепочки. На него могли повлиять:
- системный и developer prompt;
- история диалога;
- retrieved documents;
- долгосрочная и сессионная память;
- версия модели и провайдера;
- параметры генерации;
- маршрутизация между моделями;
- версии guardrails;
- результат предыдущих tool calls;
- права сервисной учётной записи;
- внешние API;
- feature flags;
- ручные подтверждения или их отсутствие.
Поэтому вопрос «Почему модель так ответила?» часто поставлен слишком узко.
Правильнее спрашивать:
В каком состоянии находилась вся AI-система, когда было принято решение?
Если компания не может восстановить это состояние, полноценное расследование становится практически невозможным.
Логи AI должны сохранять не текст, а контекст решения
Обычный application log фиксирует запрос, ошибку, идентификатор пользователя и время события.
Для AI этого мало.
Минимальный forensic snapshot должен включать:
- идентификатор и версию модели;
- системные, developer- и пользовательские prompts;
- историю сообщений, переданную модели;
- retrieved context с версиями или хешами источников;
- состояние краткосрочной и долгосрочной памяти;
- список доступных инструментов и их схем;
- все tool calls, параметры и ответы;
- права и токены, которыми обладал агент;
- настройки guardrails и policy engine;
- решения human-in-the-loop;
- параметры генерации и маршрутизации;
- идентификаторы связанных бизнес-транзакций.
Важно не просто сохранять всё подряд. Логи могут содержать персональные данные, коммерческую тайну, credentials и конфиденциальные prompts. Значит, AI observability сама должна проектироваться как защищённая система: с разграничением доступа, сроками хранения, маскированием, контролем целостности и цепочкой сохранности доказательств.
Rollback модели может ничего не исправить
Одна из наиболее опасных иллюзий — считать, что возврат предыдущей версии модели автоматически устраняет проблему.
Причина могла находиться не в модели.
Даже после rollback могут сохраниться:
- скомпрометированная память;
- ошибочные embeddings;
- опасный документ в knowledge base;
- чрезмерные права агента;
- изменённая схема инструмента;
- неудачный system prompt;
- накопленные задачи в очереди;
- неверное состояние бизнес-процесса.
Именно поэтому восстановление должно проводиться по всей цепочке исполнения.
Иногда нужно вернуть модель. Иногда — очистить память. Иногда — пересобрать индекс. Иногда — отозвать credentials. Иногда — повторно подтвердить уже подготовленные агентом действия.
В AI incident response невозможно восстановить доверие к системе, восстановив только один компонент.
Root cause здесь редко бывает одной причиной
Классический post-incident review стремится найти root cause.
В AI-системах полезнее искать causal chain — совокупность условий, каждое из которых по отдельности могло быть допустимым, но вместе они создали ущерб.
Например:
- документ клиента содержал скрытую инструкцию;
- система автоматически добавила его в контекст;
- модель интерпретировала инструкцию как приоритетную;
- агент имел доступ к отправке писем;
- подтверждение пользователя было настроено только для платежей;
- DLP контролировал вложения, но не содержание сгенерированного сообщения.
Что здесь является корневой причиной?
Prompt injection? Архитектура RAG? Избыточные полномочия? Ошибка классификации данных? Отсутствие approval? Недостаточное тестирование?
На практике инцидент возник из-за сочетания всех факторов.
Компактный AI incident response playbook
До инцидента
- определить критерии AI-инцидента;
- инвентаризировать модели, данные, память, инструменты и владельцев;
- внедрить traceability полного workflow;
- разработать сценарии containment;
- определить состав команды и полномочия;
- провести tabletop exercise;
- подготовить безопасную среду для replay.
В первые часы
- остановить дальнейший бизнес-ущерб;
- сохранить forensic snapshot до изменения системы;
- зафиксировать версии всех компонентов;
- определить затронутые процессы, пользователей и данные;
- разделить подтверждённые факты и гипотезы;
- выбрать минимально необходимый способ containment;
- проверить, продолжаются ли автономные действия.
Во время расследования
- восстановить контекст события;
- воспроизвести его в изолированной среде;
- проверить intentional и unintentional hypotheses;
- проанализировать всю causal chain;
- оценить похожие workflow и потенциальный systemic impact;
- документировать не только ответы модели, но и действия системы.
Перед восстановлением
- устранить причины на уровне модели, данных, памяти, tools и permissions;
- проверить уже созданные системой артефакты и транзакции;
- повторно выполнить критические evaluations;
- временно снизить автономность;
- усилить monitoring и approval;
- получить формальное решение владельца риска.
После инцидента
- добавить сценарий в evaluation suite;
- обновить threat model;
- пересмотреть guardrails;
- уменьшить полномочия;
- улучшить observability;
- скорректировать AI governance и IR-playbook.
NIST SP 800-61 Rev. 3 рассматривает incident response как часть более широкой системы киберрисков и подчёркивает непрерывное улучшение на основе lessons learned. Для AI это особенно важно: каждый реальный инцидент должен превращаться в новый тест, правило наблюдаемости или архитектурное ограничение.
Моя позиция
AI incident response нельзя добавить в конце обычного IR-плана как ещё один раздел.
Сначала нужно построить наблюдаемость и управляемость AI-системы: знать её состав, сохранять контекст решений, ограничивать полномочия и уметь отключать отдельные способности.
Без этого расследование будет строиться на скриншотах, воспоминаниях пользователей и попытках повторно задать модели похожий вопрос.
Но похожий ответ — ещё не воспроизведение инцидента.
Если организация не может восстановить состояние AI-системы на момент решения, она не расследует инцидент. Она формирует правдоподобную версию произошедшего.
Именно поэтому AI forensics начинается не после ущерба.
Она начинается в архитектуре.
Подписывайтесь на мой ТГ канал: @ib_decisions