Ваш AI-реестр рисков — не план реагирования на инциденты

Представьте момент после сообщения о проблеме с ИИ.

Аналитик безопасности изучает заявку о том, что внутренний инструмент ИИ выдал неверную рекомендацию в реальном бизнес-процессе. Риск больше не теоретический. Кто-то хочет понять, является ли это инцидентом безопасности, проблемой модели, вопросом конфиденциальности, проблемой вендора или просто «тем, что сделал ИИ». В реестре рисков есть пункт для неточных результатов, и ему даже может быть присвоен уровень серьезности.

Чего в нем нет — так это ответа на вопрос, который сейчас задают все: у кого есть полномочия остановить это?

Это пробел, который многим программам управления ИИ еще предстоит закрыть. Организации становятся лучше в выявлении рисков ИИ, их документировании и распределении по категориям управления. Но к чему они часто менее готовы — это к операционному моменту, когда риск ИИ превращается в реальное событие, которое необходимо расследовать, локализовать и объяснить.

В программах безопасности это различие имеет значение. Реестр рисков может документировать опасения, но он не может сохранить доказательства, уведомить руководство, оценить воздействие или решить, следует ли продолжать работу системы ИИ. Руководителям безопасности не нужна еще одна таблица, в которой говорится, что ИИ может ошибаться; им нужна исполняемая модель реагирования на то, что происходит, когда это случается.

Список — это не ответ

Реестры рисков полезны, поскольку они создают прозрачность. Они помогают организациям называть риски, сравнивать серьезность, назначать ответственных и сообщать о проблемах руководству. На ранних этапах внедрения ИИ прозрачность важна, потому что многие организации все еще выясняют, где используется ИИ, какие данные задействованы и какие бизнес-процессы могут быть затронуты.

Но реестр рисков — это не средство контроля. Специалисты по безопасности уже понимают это в других областях. Список уязвимостей — это не программа управления уязвимостями, а список сторонних рисков — не функция управления рисками вендоров. Список — это только начало работы.

Риски ИИ создают ту же проблему. Запись о риске, гласящая «результат модели может быть неточным», не определяет, кто контролирует качество результатов, какой уровень ошибки допустим, какие доказательства следует сохранять или кто может приостановить систему. Запись о риске «конфиденциальные данные могут быть раскрыты» не объясняет, регистрируются ли промпты, проверяются ли результаты, может ли вендор использовать отправленные данные или должно ли событие инициировать эскалацию по вопросам конфиденциальности, юридическим или вопросам безопасности.

Вот где управление ИИ может выглядеть сильнее, чем оно есть на самом деле. В организации может быть политика, комитет, форма приема заявок и реестр рисков, но эти артефакты не создают автоматически операционную готовность. Когда что-то происходит, настоящим тестом является то, знает ли организация, что делать дальше.

Инциденты с ИИ не всегда выглядят как утечки

Часть проблемы в том, что инциденты с ИИ не всегда выглядят как традиционные инциденты кибербезопасности. Утечка имеет знакомые шаблоны: несанкционированный доступ, кража данных, вредоносное ПО, компрометация учетных данных или подозрительная активность в системе. Сбои ИИ могут быть более запутанными, потому что они могут сначала проявиться как плохая рекомендация, вводящее в заблуждение резюме, небезопасная автоматизация, ошибочная классификация или результат, который незаметно меняет решение.

Это не делает их менее важными. Инструмент ИИ, используемый в рабочем процессе безопасности, может неправильно классифицировать оповещение. Генеративный ИИ-ассистент может раскрыть конфиденциальную информацию в ответе. Модель, встроенная в бизнес-процесс, может со временем дрейфовать и выдавать ненадежные рекомендации. Функция ИИ, управляемая вендором, может изменить поведение после обновления, которое организация не полностью проверила.

Командам безопасности нужен практический способ сортировки таких событий. Не каждую ошибку ИИ следует рассматривать как полноценный инцидент безопасности. Тем не менее, каждая организация, использующая ИИ в значимых рабочих процессах, должна знать, как сообщается об инцидентах, связанных с ИИ, как они триажируются и эскалируются. Без такой структуры команды могут тратить время на споры об ответственности, пока последствия продолжают нарастать.

Первый шаг — определить, что считается инцидентом с ИИ. Это определение должно быть достаточно широким, чтобы охватить проблемы безопасности, конфиденциальности, эксплуатационные и комплаенс-вопросы, но достаточно конкретным, чтобы сотрудники знали, когда сообщать о чем-то. Сбивающий с толку ответ чат-бота может не требовать такой же реакции, как событие раскрытия данных, но оба случая должны иметь путь для проверки.

Доказательства должны существовать до начала расследования

Реагирование на инциденты зависит от доказательств. Это очевидно в кибербезопасности, но часто упускается из виду в обсуждениях управления ИИ. Если организация не может восстановить, что произошло, кто использовал систему, какие данные были задействованы и какой результат был получен, ей будет трудно расследовать событие или защищать свои действия.

Системы ИИ могут усложнить цепочку доказательств. Промпты могут не регистрироваться. Результаты могут не сохраняться. Инструменты вендоров могут предоставлять ограниченную видимость. Версии моделей могут меняться. Пользователи могут копировать сгенерированный ИИ контент в другие системы, не сохраняя его источник. Бизнес-команды могут рассматривать результаты ИИ как рекомендацию, а не как системное событие.

Руководители безопасности должны добиваться требований к доказательствам до того, как системы ИИ будут введены в эксплуатацию. Как минимум, организации должны знать, какие журналы доступны, как долго они хранятся, кто имеет к ним доступ и достаточны ли они для расследования. Для вариантов использования с более высоким риском командам также могут потребоваться записи версии модели, истории промптов, истории результатов, действий пользователей, источников данных и последующих решений.

Это не означает, что каждое взаимодействие с ИИ нуждается в интенсивном наблюдении. Мониторинг должен быть соразмерен риску, и организациям все еще необходимо учитывать вопросы конфиденциальности, юридические и кадровые аспекты. Смысл проще: если система ИИ достаточно важна, чтобы влиять на реальную работу, она достаточно важна, чтобы оставлять след доказательств, когда что-то идет не так.

Ответственность не может подразумеваться

Ответственность за ИИ часто фрагментирована. Бизнес-подразделение может спонсировать вариант использования, команда Data Science может настраивать модель, ИТ — управлять платформой, служба безопасности — оценивать риски, а вендор — предоставлять базовую функциональность. Все вовлечены, но никто не может нести полную ответственность после развертывания.

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

Программы безопасности должны настаивать на назначении ответственных за системы ИИ, особенно те, которые используются в чувствительных или высокорисковых рабочих процессах. Ответственность должна включать мониторинг, обработку исключений, руководство для пользователей, координацию с вендором и эскалацию инцидентов. Она также должна включать права на принятие решений, потому что подотчетность без полномочий — это просто имя в таблице.

Самый сложный вопрос часто — это полномочия на остановку. Кто может приостановить, ограничить, откатить или вывести из эксплуатации систему ИИ, когда риск превышает допустимый уровень? Если на этот вопрос не ответить до развертывания, организации, возможно, придется отвечать на него под давлением.

Руководителям безопасности нужен сценарий реагирования на инциденты с ИИ

Сценарий реагирования на инциденты с ИИ не обязательно должен быть сложным, но он должен быть реальным. В нем должно объясняться, как сотрудники сообщают о проблемах с ИИ, как проводится триаж события, какие доказательства сохраняются, кто расследует, когда привлекаются юридические отделы или отделы конфиденциальности и кто может принимать операционные решения. В нем также должно быть определено, когда необходимо уведомлять высшее руководство.

Сценарий должен отражать тип задействованной системы ИИ. Для низкорискового внутреннего инструмента повышения производительности может потребоваться легкий путь проверки. Система ИИ, поддерживающая операции безопасности, регулируемые решения, коммуникацию с клиентами, рабочие процессы в здравоохранении или финансовые процессы, требует более строгого мониторинга и эскалации. Модель реагирования должна соответствовать риску варианта использования.

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

Организациям также следует проводить посмертный анализ значимых событий, связанных с ИИ. Целью не должно быть обвинение; целью должно быть обучение. Сработал ли мониторинг? Был ли ответственный ясен? Было ли достаточно доказательств? Отреагировал ли вендор? Были ли пользователи сбиты с толку относительно допустимого использования? Знала ли организация, кто может принять решение?

Управление должно быть реализуемым

Об управлении ИИ часто говорят как о проблеме политики, этики или соответствия требованиям. Это все эти вещи, но как только системы ИИ переходят в эксплуатацию, это также становится задачей исполнения в области безопасности. Риски необходимо отслеживать, события расследовать, и кто-то должен иметь возможность действовать.

Вот почему следующим шагом в повышении зрелости является не просто улучшение документации. Организациям нужно управление, которое работает, когда система активна, решение требует срочности, а факты неполны. В этот момент реестр рисков может помочь объяснить, чего ожидала организация, но он не будет управлять реагированием.

Руководители безопасности не должны ждать, пока управление ИИ появится в полностью сформированном виде откуда-то еще из предприятия. Они должны помочь сформировать операционную модель сейчас, пока многие организации еще достаточно рано, чтобы скорректировать курс. Цель не в том, чтобы владеть каждым риском ИИ; цель в том, чтобы гарантировать, что риском ИИ можно управлять, как только ИИ перейдет в операционную фазу.

Реестр рисков может сказать руководителям, что может пойти не так. План реагирования на инциденты говорит людям, что делать, когда это происходит. Чтобы управление ИИ имело значение в программах безопасности, организациям нужно и то, и другое.

Эта статья опубликована в рамках сети экспертных участников Foundry.
Хотите присоединиться?