ИИ в облаке: кто отвечает за безопасность моделей и данных
Облачные ИИ-системы сохраняют модель совместной ответственности
При использовании ИИ в облаке сохраняется принцип совместной ответственности: облачный провайдер отвечает за инфраструктуру, а клиент — за развёрнутые поверх неё системы. Однако классические средства защиты оказываются недостаточными. Возникают новые зоны риска, связанные с моделями, базами знаний и действиями ИИ-агентов. Эти риски требуют дополнительных мер безопасности, выходящих за рамки традиционных подходов. По данным рыночных исследований, 24% российских компаний уже используют ИИ в облаке, ещё 18% планируют начать в ближайший год. ИИ-системы всё чаще становятся частью значимых бизнес-процессов, работая с внутренними документами и базами знаний.
ИИ добавляет риски для данных, моделей и исполнения
Генеративный ИИ не отменяет традиционные меры информационной безопасности, такие как управление идентификацией и доступом (IAM), межсетевые экраны, шифрование и контроль уязвимостей. Однако появляются угрозы, на которые эти инструменты не рассчитаны. Риски можно разделить на три уровня. Данные включают сведения, на которых модель обучается или которые использует как источник знаний: датасеты, корпоративные документы, базы знаний и векторные хранилища. Злоумышленник может добавить в базу знаний документ с ложными данными или скрытыми инструкциями, что повлияет на ответы и поведение модели. Модель как источник риска включает её веса, сторонние чекпоинты, адаптеры и программные зависимости. Это актуально при загрузке собственных моделей или использовании компонентов из внешних источников. Например, сторонний адаптер может незаметно менять поведение модели при определённых запросах. Исполнение — это угрозы, возникающие во время работы ИИ-системы: обработка запроса, формирование ответа или выполнение действия ИИ-агентом. Сюда относятся промпт-инъекции, утечки чувствительной информации через ответы модели и избыточные полномочия агентов. Если агенту дали доступ к корпоративной почте и файлам, вредоносная инструкция может заставить его выполнить нежелательное действие. Эти и другие угрозы систематизированы в OWASP LLM Top 10.
Граница ответственности определяется для каждого уровня ИИ-системы
При работе в облаке провайдер отвечает за физическую инфраструктуру, платформу, облачный периметр и изоляцию ресурсов. Клиент отвечает за свои данные, настройки доступа, приложения и их использование. С появлением ИИ к этим уровням добавляются модели, базы знаний и действия ИИ-агентов. В случае с готовой моделью как облачным сервисом провайдер отвечает за инфраструктуру и безопасность модели. На стороне компании остаются данные, передаваемые в запросах, и решения об использовании ответов. Если компания разворачивает собственную модель, её зона ответственности шире: происхождение модели, её зависимости и уязвимости контролирует клиент. При работе с RAG-системой клиент отвечает за состав корпоративной базы знаний и права доступа к её содержимому. Если в базе знаний оказывается искажённая информация, риск связан с содержимым данных клиента. Настройки доступа также требуют контроля: компания должна управлять тем, какие пользователи и системы могут обращаться к данным и какие данные разрешено передавать модели. Базовый принцип остаётся прежним: за компонент отвечает тот, кто им управляет.
Снижение рисков требует комплексных мер на разных уровнях
Меры защиты зависят от устройства ИИ-системы и её взаимодействия с данными. Для защиты чувствительных данных в запросах и ответах готовых моделей можно использовать фильтры, распознающие и маскирующие конфиденциальную информацию. Например, инструмент Guardrails Filter в Evolution Foundation Models заменяет персональные данные и API-ключи синтетическими значениями. При обращении модели к корпоративной базе знаний необходимо уделять внимание правам доступа, чтобы пользователь не получил через ИИ документ, недоступный ему напрямую. Права исходных документов должны учитываться при поиске информации, а сами документы и их векторные представления — защищаться при хранении. Для ИИ-агентов к защите данных добавляется контроль действий: агенту следует выдавать только необходимые полномочия, а обращения к внешним инструментам проверять по заданным политикам доступа. Среду работы агента можно изолировать для ограничения его возможностей. При развёртывании собственной ИИ-модели компания должна проверять её происхождение, сторонние адаптеры и зависимости до развёртывания. Облачный провайдер обеспечивает изоляцию вычислительных ресурсов, но не отвечает за встроенные в модель уязвимости. Важно понимать, как провайдер обращается с запросами после обработки: в Evolution Foundation Models используется подход stateless inference, данные не сохраняются и не используются для обучения моделей. Клиентские данные не используются для дообучения моделей и не передаются третьим лицам. Оценка безопасности ИИ должна основываться на комплексном подходе, охватывающем все уровни: инфраструктуру, работу с данными и моделями.
Опубликовано в канале 8 октября, 12:40
Каждый материал сайта выходит в канале в тот же момент.
Источник: Anti-Malware