Безопасность ИИ без воды: почему универсальные фреймворки не работают и что работает вместо этого

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

Автор: Анна Заболотская, руководитель отдела менеджмента кибербезопасности Infosecurity (ГК Softline).

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

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

Почему универсальные фреймворки не работают

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

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

Логику лучше развернуть. Не идти от абстрактного каталога угроз к такому же абстрактному набору мер, а начинать с конкретного бизнес-сценария и уже от него двигаться к рискам.

На практике это выглядит проще, чем кажется. Берём сценарий: например, агент обрабатывает входящие запросы клиентов и инициирует действия в CRM. Дальше задаём базовые вопросы. Кто им пользуется — внешний клиент или сотрудник? Какие данные агент видит в процессе работы? Модель сторонняя или собственная? Проводилось ли дообучение? С какими системами есть интеграции? Насколько агент автономен?

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

Следующий шаг — оценить последствия. Не в формате «критично/некритично», а в нормальных бизнес-категориях: что произойдёт, если угроза реализуется. Возможны финансовые потери, репутационный ущерб, регуляторные последствия, операционный сбой. Когда владельцы системы отвечают на этот вопрос, часто выясняется, что одни страшные по описанию угрозы почти не влияют на конкретный кейс, а другие, о которых никто не думал, могут привести к серьёзным последствиям. Так появляется понимание, какие сценарии действительно критичны и что нужно закрывать в первую очередь.

Как это выглядит в виде инструмента

Эту логику можно оформить как скоринговую модель. В ней есть набор факторов риска, порядка 30 ключевых признаков, шкала оценки последствий, перечень актуальных угроз, около 40, и набор требований по защите — около 70. Связь простая: ответы на вопросы о сценарии использования ИИ активируют релевантные угрозы, а угрозы — соответствующие требования. Дальше требования можно ранжировать по стоимости реализации, количеству закрываемых угроз и влиянию на риск. Такую модель компания может собрать под себя или адаптировать на основе существующих методик.

Результат — не каталог из сотен пунктов, а приоритизированный список мер для конкретного ИИ-сценария. Обычно это десяток-два требований, расположенных от более важных к менее важным. Такой инструмент не заменяет полноценный аудит. Его задача другая: ответить на вопрос «с чего начать» применительно к конкретной системе и запустить нормальный разговор между ИБ и продуктовыми командами.

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

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

Такую систему нельзя создать одним проектом и внедрить приказом сверху. Она строится итеративно: компания разбирает конкретные юзкейсы, обобщает опыт и постепенно формализует то, что действительно работает.

Про новые инструменты: шлюзы, рельсы и то, что под капотом

Отдельный слой — специализированные инструменты защиты LLM-систем. Их пока не так много, но они уже есть.

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

Второй класс — guardrails, или «рельсы». Это библиотеки и SDK, которые задают границы поведения модели: что она может делать, а что нет. Часто такие механизмы становятся частью шлюзовых решений. Есть важная деталь: внутри «рельсов» тоже нередко используется LLM, чтобы понять контекст и принять решение. Значит, инструмент защиты в некоторых сценариях сам может быть уязвим к тем же типам атак, от которых защищает.

Третий класс формируется сейчас — шлюзы для взаимодействия агентов между собой через протоколы типа MCP, Model Context Protocol, который соединяет агентов с внешними инструментами. Когда агентские системы начинают общаться друг с другом, возникает отдельная поверхность атаки, и контроль этого обмена становится самостоятельной задачей.

Красная команда для языковой модели

Отдельно стоит говорить о тестировании ИИ-систем, в том числе о red teaming. Принцип знаком по классическому пентесту: проверить не бумажную защищённость, а реальную. Разница в том, что набор атак стал шире.

Часть атак на LLM-системы строится на прямом диалоге с моделью. Злоумышленник буквально «разговаривает» с системой: убеждает её выдать информацию, которую нельзя раскрывать, или выполнить действие, которое не должно выполняться. Prompt injection, извлечение системного промпта, обход ограничений через ролевые конструкции — jailbreak — требуют от команды тестирования отдельной экспертизы.

Хорошая новость в том, что инструменты и практика для таких проверок уже появляются. Чем раньше компания начнёт тестировать свои ИИ-системы таким образом, тем выше шанс найти слабые места до того, как ими воспользуется кто-то другой.

Безопасность ИИ — не отдельная планета с другими законами физики. Это знакомая территория, к которой добавились несколько новых кварталов. Классические практики остаются актуальными, но к ним прибавляются непредсказуемое поведение моделей, новые векторы атак и новые классы защитных инструментов.

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