Сотрудник запускает разрешённый AI-процесс для подготовки отчёта. Через несколько минут сервис обращается к таблицам, письмам и хранилищу, к которым сам сотрудник редко обращался напрямую. Вредной подсказки нет, но данные уже прошли через машинное действие с доверенной идентичностью. Расследование должно восстановить цепочку: кто поручил, кто исполнил, какие данные были открыты и куда ушёл результат.
Практическая задача защиты — превратить аудит AI-действий в рабочем процессе в проверяемый процесс. Пока команда видит только итоговое сообщение, файл или действие, она вынуждена верить внешнему виду. Безопасность начинается там, где каждое действие имеет владельца, источник данных, журнал, правило допуска и понятный способ остановки.
Первый риск связан с доверием к удобному объяснению. AI может ускорить работу аналитика, разработчика, оператора или финансового сотрудника, но он не должен становиться единственной точкой принятия решения. Если модель ошиблась, была обманута или получила лишний контекст, последствия будут выглядеть как нормальное рабочее действие.
Второй риск — разрыв между бизнес-процессом и техническими журналами. Финансовый отдел видит согласование, AppSec видит пакет, SOC видит событие, а владелец данных видит доступ. Инцидент обнаруживается только тогда, когда эти фрагменты связаны в одну цепочку.
Минимальные контроли
- разделять пользователя, сервисную идентичность и исполнителя действия
- записывать основание доступа к каждому источнику данных
- ограничивать область данных перед передачей в модель
- проверять новые связи между AI-процессом и корпоративными хранилищами
- вводить подтверждение для чувствительных действий
- сохранять трассу от запроса до результата без лишнего текста данных
Контроли лучше включать сначала в режиме наблюдения. В течение двух недель команда собирает нормальную картину: кто инициирует действия, какие данные используются, как часто возникают исключения, где появляются новые устройства, новые ключи, новые источники и необычные цепочки согласования.
После этого правила делятся на три группы. Первая группа блокирует явные нарушения: неизвестный ключ, новый получатель платежа, обращение к данным вне роли, опасный сценарий сборки или прямой обход утверждённого канала. Вторая группа требует подтверждения владельца. Третья только повышает риск и помогает аналитику собрать контекст.
Что логировать
- инициатор
- сервисная идентичность
- источник данных
- тип действия
- политика доступа
- объём данных
- получатель результата
- время выполнения
- номер исключения
- решение контроля
Журнал должен помогать расследованию и не создавать новую утечку. Поэтому не всегда нужно хранить полный текст запроса, письма или документа. Часто достаточно класса данных, источника, идентификатора события, решения политики, владельца и ссылки на защищённое хранилище, где доступ к деталям отдельно аудируется.
Полезная проверка — восстановить событие через неделю. Если команда не может ответить, кто инициировал действие, какая политика сработала, какой источник данных был использован и почему операция была разрешена, значит контроль существует только формально. Такой пробел нужно закрыть до масштабирования AI-сценария.
- каждое исключение получает владельца и срок действия;
- каждое чувствительное действие имеет независимый канал подтверждения;
- каждый новый источник данных проходит оценку риска;
- каждое расхождение между AI-сводкой и технической проверкой уходит в разбор;
- каждая блокировка должна иметь понятное объяснение для владельца процесса.
Для SOC важна корреляция. Отдельный запрос, письмо или файл может выглядеть нормально. Но связка из нового устройства, нетипичного времени, срочного действия, изменения получателя, необычного доступа к данным и повторной попытки после отказа уже должна повышать критичность.
План внедрения
В первый день команда описывает процесс и владельцев. Во второй — отмечает критичные данные и действия. Затем включается сбор событий в SIEM, создаётся набор тестовых сценариев и проверяется, что блокировка действительно работает. После этого можно включать правила для части пользователей и расширять покрытие.
- описать процесс от запроса до результата;
- назначить владельца данных и владельца технического контроля;
- проверить доступы сервисных учётных записей;
- создать тестовые события для разрешения, блокировки и эскалации;
- сверить журналы приложения, IAM, DLP, EDR и SIEM;
- утвердить действие по умолчанию при отсутствии ответа владельца.
Отдельно стоит проверять отказоустойчивость. Если внешний AI-сервис недоступен, модель ошибается, ключ скомпрометирован или журнал временно не пишется, процесс должен переходить в безопасный режим. Это может быть ручная проверка, ограничение действия, временный запрет операции или дополнительное подтверждение.
Зрелый результат выглядит просто: команда может быстро объяснить, что произошло, кто отвечал за решение, какие данные были затронуты и почему система разрешила или остановила действие. Тогда AI остаётся ускорителем, а не непрозрачной зоной риска.
Главный вывод: защищать нужно не только модель и не только пользователя. Защищать нужно цепочку доверия вокруг действия — источник, роль, данные, журнал, подтверждение и возможность остановки. Именно эта цепочка превращает AI из спорного риска в управляемый инструмент.
Метрики для еженедельного контроля
После запуска полезно вести небольшой набор метрик, который показывает не объём внедрения AI, а качество контроля. В отчёт попадают не только заблокированные события, но и исключения, ручные подтверждения, повторные попытки после отказа, доля событий с полным журналом и среднее время реакции владельца процесса.
- доля действий с указанным владельцем и источником данных;
- число исключений старше согласованного срока;
- число повторных попыток после отказа политики;
- доля событий, которые можно связать с IAM, DLP, EDR и SIEM;
- время от подозрительного сигнала до решения владельца;
- число случаев, где AI-сводка противоречила технической проверке.
Эти показатели помогают не превращать безопасность AI в разовую настройку. Если исключения растут, журналы неполные, а владельцы отвечают слишком поздно, значит команда получает скорость ценой управляемости. Если метрики стабильны, можно расширять охват на новые подразделения и сценарии.
