В компании внезапно обнаруживают, что AI-сервис несколько дней принимал файлы не из того хранилища, а часть ответов модели строилась на данных, которые не должны были попадать в рабочий контур. Формально это не похоже на классический взлом: нет вредоносного файла, нет шифрования, нет явного аккаунта злоумышленника. Но для службы безопасности это полноценный инцидент, потому что нарушены границы данных, доверие к модели и ожидания пользователей.
Главная ошибка в таких случаях — искать только техническую причину. У AI-инцидента есть несколько слоёв: кто загрузил данные, почему политика разрешила загрузку, как модель использовала материал, кто видел вывод, можно ли восстановить цепочку и требуется ли уведомление владельцев данных. Если эти вопросы не заданы сразу, через неделю расследование превращается в спор между командами.
Карточка AI-инцидента должна быть такой же строгой, как карточка утечки или компрометации доступа. В ней фиксируются данные, сессии, версии модели, настройки хранения, действия пользователей, выводы модели и решение о дальнейшей обработке. Без этого организация не понимает, что именно произошло: сбой модели, дефект интеграции, ошибка владельца данных или обход политики.
Практическая цель для защитника — создать процесс, при котором скрытый сбой модели не живёт в переписке и не зависит от памяти одного инженера. Любое подозрение должно попадать в единый журнал, получать владельца и проходить разбор по одинаковой схеме.
Что считать AI-инцидентом
AI-инцидентом стоит считать не только вредный ответ модели. Важны любые события, где модель, данные, интеграция или пользовательское действие нарушают утверждённую политику. Это позволяет не спорить о терминах в момент кризиса.
Классификация должна быть простой. Если сотрудник видит странную загрузку, неожиданное использование файла или ответ с чувствительным контекстом, он должен понимать, куда это отправить и какие данные приложить.
- несанкционированная загрузка файла;
- использование данных вне разрешённого проекта;
- вывод, раскрывающий чувствительную информацию;
- обход политики хранения запросов;
- подключение лишнего источника данных;
- неожиданное действие интеграции;
- ошибка классификации уровня риска.
Какие журналы сохранить
Расследование ломается, когда журналы AI-сервиса хранят только красивую историю запросов. Для безопасности нужны технические поля: идентификатор пользователя, проект, источник файла, версия модели, политика хранения, решение фильтра, результат DLP, связанная интеграция и время доступа.
Особенно важно разделять история запросов и журналы аудита. История запросов помогает понять контекст, но не заменяет журнал доступа. Если файл попал в модель через подключённый сервис, команда должна видеть исходное событие в хранилище и событие использования в AI-платформе.
- user_id и tenant_id;
- project_id и workspace_id;
- model_version и policy_version;
- file_id и source_system;
- retention_flag и согласие_состояние;
- dlp_result и classification_label;
- connector_id и action_type.
Кто принимает решение
Решение о раскрытии нельзя оставлять только владельцу AI-платформы. В событии участвуют безопасность, юридическая команда, владелец данных, владелец продукта и представитель бизнеса. Их роли лучше назначить заранее, иначе каждая команда будет минимизировать собственную часть риска.
Для небольших событий достаточно внутреннего разбор после инцидента. Для событий с персональными данными, клиентскими файлами или регулируемой информацией нужен отдельный маршрут: сохранение доказательств, оценка затронутых лиц, решение об уведомлении и запрет на удаление журналов до завершения разбора.
- назначить владельца события;
- зафиксировать затронутые данные;
- определить необходимость уведомления;
- запретить очистку журналов;
- выделить техническую и юридическую линии;
- закрыть событие только после проверки мер.
Проверки перед внедрением
Перед изменением политики команда должна выполнить короткую проверку на исторических событиях. Нельзя считать контроль рабочим только потому, что он звучит правильно в описании. Его нужно прогнать на старых инцидентах, ложных срабатываниях и нормальных рабочих сценариях.
Для владельца процесса важна воспроизводимость. Любой вывод модели должен иметь ссылку на событие, правило, источник данных и версию настройки. Если объяснение нельзя восстановить через неделю, такой контроль не должен автоматически менять доступы, блокировать пользователя или закрывать инцидент.
- выбрать двадцать нормальных событий и десять рискованных;
- проверить, что правило не зависит от одного поля журнала;
- сохранить версию политики и набор тестовых данных;
- назначить владельца исключений;
- описать ручной путь отката;
- проверить, что журнал содержит причину решения.
Метрики зрелости
Хорошая метрика показывает не количество красивых срабатываний, а снижение неопределённости. Если после внедрения AI-контроля аналитик всё равно вручную ищет те же связи, значит автоматизация просто переименовала старую очередь задач.
Минимальный набор метрик стоит хранить рядом с карточками инцидентов: доля объяснимых решений, время до подтверждения, число откатов, доля событий с полным набором журналов, количество исключений без владельца и среднее время закрытия риска.
- сократить время первичного разбора;
- уменьшить долю событий без владельца;
- снизить число повторных ложных срабатываний;
- повысить полноту журналов;
- отдельно учитывать события, где модель ошиблась;
- раз в месяц удалять устаревшие исключения.
Контрольный лист для запуска
Перед публикацией новой политики безопасности команда должна пройти короткий контрольный лист. Он нужен не для формальности, а чтобы убедиться: у решения есть владелец, журналирование, критерии остановки и понятный путь ручной проверки. Если хотя бы один пункт отсутствует, автоматизацию лучше оставить в режиме рекомендации.
- назначить владельца риска и владельца данных;
- проверить, какие поля попадают в журналы;
- описать условия ручного подтверждения;
- задать срок пересмотра исключений;
- создать тестовые события для регрессии;
- подготовить шаблон отчёта для руководителя;
- сохранить версию политики и причины изменений.
Такой список помогает не превратить AI-контроль в ещё один непрозрачный слой. Команда видит, какие решения можно доверить автоматике, какие нужно только подсвечивать аналитику, а какие требуют подтверждения владельца процесса. Это особенно важно для тем, где ошибка может затронуть доступ, данные, платежи или публичную репутацию.
После первого месяца работы правило стоит пересмотреть. Нужно сравнить ожидаемые и реальные срабатывания, выделить ложные тревоги, проверить пропущенные события и обновить инструкции для дежурной смены. Если модель или политика изменилась, прежние результаты тестов нельзя считать актуальными.
