ИИ в облаке: кто отвечает за безопасность

ИИ в облаке не отменяет модель совместной ответственности, но добавляет новые зоны риска: модели, базы знаний и действия ИИ-агентов. Разбираем, что защищает провайдер, что остаётся на стороне клиента и какие меры должен предпринять контролировать CISO.

1. 1. Введение
2. 2. ИИ добавляет новые риски
3. 3. Где заканчивается ответственность провайдера
4. 4. Как снизить риски при работе с ИИ
5. 5. Что остаётся на стороне CISO
6. 6. Выводы

Введение

По данным рыночных исследований, 24% российских компаний уже используют ИИ в облаке, ещё 18% планируют начать в ближайший год. ИИ-системы все чаще становятся частью значимых бизнес-процессов: работают с внутренними документами, базами знаний, а ИИ-агенты получают доступ к системам и могут выполнять действия от имени пользователя. Но если в классической архитектуре приложение работает с данными по заранее заданной логике, то с появлением ИИ между данными и результатом появился «чёрный ящик» — модель, поведение которой не всегда можно предсказать или объяснить.

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

ИИ добавляет новые риски

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

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

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

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

Эти и другие характерные для приложений на базе больших языковых моделей угроз систематизированы в OWASP LLM Top 10 — перечне основных рисков безопасности для таких систем. Среди них — раскрытие чувствительной информации, отравление данных и моделей, риски цепочки поставок, избыточные полномочия агентов, промпт-инъекции и другие угрозы.

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

Где заканчивается ответственность провайдера

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

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

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

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

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

Таблица 1. Экспертная оценка применимости рисков OWASP LLM Top 10 к различным сценариям и сервисам работы с ИИ

Как снизить риски при работе с ИИ

Меры защиты зависят от того, как устроена ИИ-система и с какими данными и ресурсами работает модель. Один из рисков при использовании готовых языковых моделей связан с чувствительными данными в запросах и ответах. Для их защиты можно использовать фильтры, которые распознают такие сведения и маскируют их до передачи модели. Например, в Evolution Foundation Models — сервисе Cloud.ru для работы с готовыми ИИ-моделями — используется инструмент Guardrails Filter. Так, перед отправкой запроса сервис автоматически заменяет персональные данные, API-ключи, пароли и другую конфиденциальную информацию синтетическими значениями.

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

Для ИИ-агентов к защите данных добавляется контроль действий. Агенту стоит выдавать только те полномочия, которые нужны для конкретной задачи, а обращения к внешним инструментам проверять в соответствии с заданными политиками доступа. Среду, в которой работает агент, также можно изолировать. Тогда даже при ошибочной или вредоносной инструкции возможности агента будут ограничены заранее установленными правами. Именно такой подход к работе с данными реализован в сервисе для развёртывания ИИ-агентов AI Agents.

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

Наконец, до начала работы с облачной моделью компании стоит понимать, как провайдер обращается с её запросами после обработки. Например, в Evolution Foundation Models используется подход stateless inference (вывод без состояния): данные и промпты не сохраняются, каждый ответ формируется независимо, а запросы не используются для обучения моделей. Запись событий обращений включается самим клиентом. Также клиентские данные не используются для дообучения моделей и не передаются третьим лицам.

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

Что остаётся на стороне CISO

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

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

Так, зона ответственности CISO охватывает не только технические средства защиты, но и правила, по которым ИИ-системы появляются в компании, используются и выводятся из эксплуатации.

Выводы

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

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

Задача CISO — встроить ИИ в существующие процессы безопасности: учитывать его в модели угроз, контролировать жизненный цикл моделей, разграничивать доступ и заранее определять ответственность сторон. Чем раньше ИБ подключается к ИИ-проекту, тем меньше вероятность, что защиту придётся достраивать уже после запуска системы.