71% организаций заявляют, что ИИ имеет доступ к основным бизнес-системам. Только 16% эффективно управляют этим доступом, согласно отчету CISO AI Risk Report 2026. Задайте своей команде IR три вопроса: Где находится ваш реестр ИИ-систем? Что произойдет, если production-модель начнет генерировать вредоносные результаты? Кто имеет право отключить ее?
Я провел 14 лет в сфере безопасности — энергетика, банки, телеком, производство. Работа в Red team, программы обнаружения, а последние несколько лет — фокус на риски ИИ и ShadowAI. Что я вижу постоянно: у организаций есть ИИ в production, есть IR playbook, и они думают, что эти две вещи связаны. Но это не так.
CISO, который считает, что его IR playbook охватывает инциденты с ИИ, вероятно, не тестировал его. Те, кто тестировал, знают, что это не так.
Два типа инцидентов с ИИ — и почему это разделение важнее списка
Количество инцидентов с ИИ выросло на 56,4% с 2023 по 2024 год, достигнув 233 задокументированных случаев. Большинство фреймворков IR — включая NIST SP 800-61, MITRE ATLAS и GLACIS AI Incident Response Playbook — предоставляют таксономию из шести типов инцидентов и на этом останавливаются. Хотя это полезно, упускается более важное разделение: сбои, вызванные самой моделью, и сбои, вызванные человеком. Ваш подход к обнаружению, логика сдерживания и юридические риски сильно различаются между этими двумя группами.
Сбои, исходящие от модели — деградация, предвзятость, галлюцинации — происходят, когда система делает именно то, для чего была создана, но плохо. Модель Epic Sepsis Model, развернутая в сотнях больниц США, показала чувствительность всего 33% при внешней валидации. Она пропустила две трети реальных случаев сепсиса и завалила врачей ложными сигналами, как показало исследование JAMA Internal Medicine 2021 года. Никто не атаковал ее. Она просто тихо перестала работать, пока все дашборды оставались зелеными.
Внешние сбои — состязательные атаки, отравление данных, утечки конфиденциальности — происходят, когда кто-то портит входные данные или среду обучения. Случаи с phantom braking в Tesla Autopilot, расследованные NHTSA на сотнях тысяч автомобилей, показывают, как выглядят сбои состязательных входных данных в критически важной системе безопасности. Эти две группы требуют разных основных защит и собственных playbooks.
Затем есть гибридный случай, который сейчас несет наибольший юридический риск. Галлюцинации исходят от модели, но в суде они рассматриваются как человеческие ошибки. Когда чат-бот Air Canada придумал тариф на похороны, авиакомпания была признана ответственной. Когда федеральный суд США разрешил дело Mobley v. Workday продолжиться, он принял, что AI-платформа для найма может нести прямую ответственность как «агент» работодателей, использующих ее. Ни один из этих сбоев не выглядел как инцидент безопасности. Оба стали юридическими. Если ваша юридическая команда не включена в дерево вызовов IR, ваш playbook уже неполон.
Триада CIA не покрывает галлюцинацию
Триада CIA — конфиденциальность, целостность, доступность — не применима к большинству инцидентов с ИИ. Когда чат-бот Air Canada выдумал политику, ничего не было недоступно, ничего не было изменено без разрешения, ничего не было раскрыто. Фреймворк просто не охватывает это. Когда модель Epic Sepsis Model пропустила две трети случаев, не было утечки, вторжения, индикатора компрометации. По всем традиционным показателям IR система выглядела нормально.
Это не частный случай. Классические фреймворки IR предполагают детерминированные сбои со статическими индикаторами компрометации — предположение, которое рушится при столкновении с вероятностными системами. В блоге Microsoft Security Blog в апреле 2026 года было хорошо сказано: модель может сегодня выдать вредоносный результат, а завтра — совершенно другой на тот же самый промпт. Коренная причина — не строка кода. Это распределение вероятностей, и, как выразился Microsoft Security Blog, вы не можете пропатчить распределение вероятностей.
Цифры подтверждают разрыв. Среднее время обнаружения инцидента с ИИ составляет 4,5 дня. 67% инцидентов с ИИ происходят из-за ошибок модели, а не состязательных атак — однако бюджеты на безопасность по-прежнему финансируют периметральные инструменты, созданные для последних. Мы ищем не те сигналы, не теми инструментами, для не тех типов сбоев.
Как выглядит зрелая способность реагирования на инциденты ИИ
Меня спрашивают об этом на каждой конференции, где я выступаю. Вот краткий ответ: три вещи, которые зрелые команды внедряют до того, как произойдет инцидент.
Во-первых, AI Bill of Materials (AIBOM) для каждой production-системы. Думайте об этом как о программном SBOM, но для ИИ: он документирует базовую модель, обучающие датасеты, сторонние зависимости и полный стек компонентов. Без него вы не знаете, из чего состоит ваш ИИ — и не сможете расследовать инцидент с отравлением данных или компрометацию цепочки поставок без этой основы. Проект OWASP GenAI Security Project в декабре 2025 года выпустил open-source генератор AIBOM, который создает вывод в формате CycloneDX, совместимом со стандартами SPDX. Его можно внедрить уже сейчас.
Во-вторых, model card (карточка модели) для каждой production-системы ИИ — не документ в общей папке, который никто не открывает, а то, что ваша команда IR может поднять в первые десять минут реагирования. Происхождение обучающих данных. Версия модели. Известные ограничения производительности, включая субпопуляции, показавшие меньшую точность в тестах. Контроль доступа. Радиус поражения при сбое. У большинства организаций, с которыми я работаю, документация по модели написана для data scientists, и никто из службы безопасности не может ею воспользоваться в 2 часа ночи. Это не документация. Это ответственность.
В-третьих, назначенный data scientist в дереве вызовов IR. Не тот, кого привлекают после инцидента, а тот, кто имеет полномочия в реальном времени исследовать поведение модели. Традиционный IR имеет дежурного сетевого инженера. AI IR требует той же логики в отношении людей, которые понимают, как работает отказывающая система.
Четвертая вещь, которая есть у очень немногих команд: задокументированный порог отката для каждой развернутой модели. Заранее согласованное определение того, какой уровень аномалий, метрика дрейфа или отклонение по справедливости запускает сдерживание или переключение на запасной вариант. Команды без этого тратят первые часы инцидента с ИИ на споры, действительно ли то, что они видят, является проблемой. Команды с порогом тратят эти часы на реагирование.
Четыре дела до следующего инцидента
Перепишите свои триггеры обнаружения. Оценка аномалий выходных данных, мониторинг распределения данных на предмет дрейфа и отслеживание поведения использования API модели должны быть в вашем уровне обнаружения. Они не придут из вашего SIEM. Это работа по инструментации на уровне AI-системы.
Переопределите сдерживание. Для большинства инцидентов с ИИ «изолировать систему» — неправильный первый шаг. Переключение на rule-based fallback (запасной вариант на основе правил) при сохранении работы сервиса может нанести меньше вреда, чем вывод системы из эксплуатации и эскалация бизнес-проблем. Каждая развернутая модель требует заранее определенных критериев отката и назначенного запасного варианта. Запишите их сейчас.
Привлеките юристов до инцидента. Дело Mobley v. Workday означает, что и поставщик ИИ, и развертывающая организация могут нести ответственность за инциденты, связанные с предвзятостью. Дело Air Canada означает, что вы не можете отказываться от ответственности за то, что ваш ИИ говорит клиенту. Если ваша юридическая команда узнает об инциденте с ИИ из запроса прессы, что-то уже пошло не так.
Постройте свой AI-инвентарь и относитесь к нему как к реестру активов. Начните с AIBOM для ваших систем с наибольшим риском — тех, которые имеют доступ к данным клиентов, финансовым решениям или клиническим рабочим процессам. Фреймворк GenAI-IRF предоставляет структурированную таксономию для этой работы, а GLACIS AI Incident Response Playbook отображает ее на процедуры NIST SP 800-61 и MITRE ATLAS, которые ваша команда может адаптировать, не начиная с нуля.
42% организаций уже имели подозрительный или подтвержденный инцидент с ИИ, и более половины говорят, что их уровень безопасности догоняет, непоследователен или реактивен. Обновление вашего playbook — не опция. Исправьте его, пока он не понадобился.
Эта статья опубликована в рамках Foundry Expert Contributor Network.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Julie Brunias
