# Разделённая ответственность для LLM: кто что защищает

> Модель разделённой ответственности для LLM: подходы Microsoft и CSA, обязанности поставщиков и пользователей по EU AI Act и таблица для работы через API.

FireAI Security & Research Team (HisnLabs) · Published 2026-09-30
Canonical: https://hisnlabs.com/ru/blog/razdelennaya-otvetstvennost-llm

Организации, строящие решения на облачной языковой модели, получают от производителя модель, прошедшую обучение безопасности, и платформу, но остаются ответственными за приложение вокруг неё. Microsoft, Cloud Security Alliance и Регламент ЕС об ИИ (EU AI Act) распределяют работу между поставщиком модели и стороной, которая её развёртывает, используя разную терминологию и имея разную юридическую силу. В этой заметке три подхода сравниваются и предлагается практическое разделение для распространённого случая, когда модель используется через API. Она дополняет статью [How Anthropic red-teams Claude, and what it leaves to you](https://hisnlabs.com/en/blog/how-anthropic-red-teams-claude), в которой на одном опубликованном примере рассматривается сторона поставщика.

## Контекст: облачная модель, распространённая на ИИ

Облачная модель разделённой ответственности относит каждый механизм контроля к поставщику или к клиенту в зависимости от типа сервиса: программное обеспечение как услуга (SaaS), платформа как услуга (PaaS) или инфраструктура как услуга (IaaS). И Microsoft, и Cloud Security Alliance (CSA) распространяют эту идею на генеративный ИИ. Такое расширение меняет скорее терминологию, чем логику: чем ниже по стеку строит клиент, тем больше механизмов контроля принадлежит ему.

## Модели производителей

### Microsoft: платформа, приложение и использование

Модель разделённой ответственности за ИИ от Microsoft описывает приложение с ИИ как три уровня: платформу ИИ, приложение ИИ и использование ИИ. Уровень платформы предоставляет модель через API и включает систему безопасности, фильтрующую вредоносные входные и выходные данные. Уровень приложения — это интерфейс, с которым работает пользователь, с привязкой к данным (grounding), плагинами и коннекторами данных; ему нужна собственная система безопасности приложения. Уровень использования охватывает то, как люди пользуются этой возможностью, и здесь Microsoft указывает на управление идентификацией и доступом, политики допустимого использования и обучение пользователей. [[1]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)

Какая доля каждого уровня принадлежит клиенту, зависит от типа развёртывания. На странице указано, что обязанности различаются для SaaS, PaaS и IaaS; рекомендуется начинать с SaaS-предложений, таких как Copilot, переходить к PaaS-сервисам, таким как Azure OpenAI Service, только если готовые возможности не подходят, а создание собственных моделей оставить организациям с глубокой экспертизой. Страница добавляет, что рекомендации носят иллюстративный характер, используются в смысле управления и не изменяют никаких соглашений с Microsoft. [[1]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)

### Microsoft: расширение для агентов

Вторая страница Microsoft посвящена агентам, которые она отличает от простой модели: агент действует без одобрения человеком каждого шага, планирует и работает в циклах, хранит память, имеет собственную идентичность и может взаимодействовать с другими агентами. Она добавляет три уровня: оркестрацию агентов, инструменты и действия, а также память и состояние. В её матрице ответственности в случае PaaS за клиентом остаются инструкции и область действия агента, разрешения для каждого инструмента и одобрение человеком действий с серьёзными последствиями, тогда как среда выполнения и платформа оркестрации принадлежат Microsoft. [[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)

Страница перечисляет обязанности, которые всегда остаются за клиентом: данные, идентификация и минимальные привилегии, авторизация действий, контроль со стороны человека, допустимое использование и управление. В ней также сказано, что автономность никогда не снижает подотчётность. [[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)

### Cloud Security Alliance: предложение 2023 года

В записи блога от 28 июля 2023 года один из членов CSA предложил модель с тремя сторонами: поставщиком сервиса ИИ, пользователем сервиса ИИ, создающим приложение, и предприятием или конечным пользователем этого приложения. Согласно предложению, IaaS-поставщик предоставляет инфраструктуру и базовые модели, а пользователь отвечает за обучение, проверку данных, фильтрацию промптов и безопасность приложения; в случае PaaS пользователь обеспечивает контекст и безопасность приложения; в случае SaaS пользователь управляет привязкой к данным, фильтрацией промптов и защитой интеллектуальной собственности. Запись представляет это как предложение по разделению обязанностей, а не как стандарт. [[3]](https://cloudsecurityalliance.org/blog/2023/07/28/generative-ai-proposed-shared-responsibility-model)

## Право: EU AI Act распределяет обязанности по ролям

EU AI Act распределяет обязанности по ролям. Согласно ответам на частые вопросы к руководящим принципам Европейской комиссии, поставщик модели ИИ общего назначения — это организация, которая разрабатывает модель или заказывает её разработку и выводит её на рынок под своим именем. Обязанности поставщика включают техническую документацию, документацию для разработчиков следующего уровня о возможностях и ограничениях, политику соблюдения авторского права и публичное резюме обучающих данных. Эти обязанности применяются с 2 августа 2025 года. Модели, предположительно несущие системный риск, — с вычислительными затратами на обучение от 10^25 операций с плавающей запятой — несут дополнительные обязанности, включая состязательное тестирование и меры кибербезопасности. [[4]](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)

Там же 2 августа 2026 года названо датой, с которой к этим поставщикам применяются меры принуждения, включая штрафы, а 2 августа 2027 года — сроком для моделей, выведенных на рынок до 2 августа 2025 года. Там же указано, что разработчик следующего уровня, изменивший модель, становится поставщиком лишь в исключительных обстоятельствах, например при использовании более трети исходных вычислительных затрат на обучение, так что большинство вариантов дообучения не меняет роль поставщика. [[4]](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)

Эксплуатанты (deployers), то есть организации, использующие системы ИИ, несут отдельный набор обязанностей. Анализ юридической фирмы от 24 июля 2026 года относит к обязанностям эксплуатантов с 2 августа 2026 года раскрытие информации о дипфейках и уведомление людей о распознавании эмоций и биометрической категоризации. Для систем высокого риска в нём перечислены компетентный контроль со стороны человека, уведомление людей об использовании ИИ и консультации с работниками. [[6]](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/) Страница Комиссии с хронологией добавляет, что эксплуатанты должны обеспечивать контроль со стороны человека и мониторинг и сообщать о серьёзных инцидентах после вывода систем на рынок. [[5]](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)

### Перенос сроков по Digital Omnibus

Сроки для систем высокого риска сдвинулись. Страница Комиссии с хронологией указывает 2 декабря 2027 года для систем высокого риска в чувствительных областях, таких как биометрия, трудоустройство и правоохранительная деятельность, и 2 августа 2028 года для систем высокого риска, встроенных в регулируемые продукты, ссылаясь на Digital Omnibus по ИИ, который, по её описанию, вступает в силу в июле 2026 года. [[5]](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) Анализ Norton Rose Fulbright приводит те же две даты и указывает, что Omnibus опубликован в официальном своде законодательства ЕС. [[6]](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/) Таким образом, два независимых источника сходятся в том, что перенос принят, а не только предложен. Обязанности поставщиков моделей общего назначения и описанные выше обязанности по прозрачности этими двумя датами не переносятся.

## Разделение работы при использовании модели через API

Для случая PaaS, когда приложение обращается к облачной модели, источники поддерживают следующее разделение. Строки, основанные на Microsoft, следуют описанным выше уровням платформы и приложения; строки о тестировании пограничных рисков, системной документации и каналах раскрытия уязвимостей отражают обязанности поставщиков по руководящим принципам ЕС и практики, которые публикуют производители моделей. Таблица — обобщение FireAI, а не текст какого-либо из источников.

| Область | Сторона поставщика | Ваша сторона |
| --- | --- | --- |
| Поведение модели | Обучение безопасности и выравнивание модели | Системный промпт и защитные механизмы приложения |
| Тестирование рисков | Тестирование пограничных рисков самой модели | Тестирование вашего приложения, включая его промпты, данные и инструменты |
| Платформа | Безопасность платформы и базовые фильтры входных и выходных данных | Проверки безопасности приложения для контента, плагинов и коннекторов |
| Документация | Системная карта и документация для разработчиков следующего уровня | Её изучение и фиксация того, какую модель и версию вы развернули |
| Данные и инструменты | Ничего сверх договора об API | Данные RAG, инструменты, агенты и их разрешения |
| Выходные данные | Возвращает сгенерированный текст | Обработка выходных данных далее: проверка, экранирование, одобрение человеком |
| Эксплуатация | Канал раскрытия уязвимостей модели | Журналирование, мониторинг и реагирование на инциденты для приложения |
| Люди | Условия политики использования | Собственная политика использования и обучение пользователей |

*Разделение ответственности для модели, используемой как облачный API (PaaS). Обобщение FireAI.*

Две области являются разделёнными в строгом смысле. Первая — внедрение промптов (prompt injection): поставщик обучает модель противостоять внедрённым инструкциям, а эксплуатант ограничивает то, чего может добиться внедрённая инструкция, через разрешения инструментов и доступ к данным. Страница Microsoft об агентах описывает то же разделение, предписывая клиентам считать извлечённый контент, выходные данные инструментов и сообщения других агентов недоверенными и ставить действия с серьёзными последствиями под контроль. [[2]](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent) Вторая — конфиденциальность данных: поставщик устанавливает условия хранения и использования для обучения, а эксплуатант решает, какие данные вообще попадают в промпт или поисковый индекс.

> FireAI, файрвол для macOS от HisnLabs, работающий на устройстве, определяет, каким приложениям на Mac разрешён выход в сеть, и показывает каждое соединение в разделе «Активность». Контроль исходящего трафика находится на стороне эксплуатанта. [Download FireAI for Mac](https://hisnlabs.com/en/download)

## Рекомендации

1. Сначала определите тип развёртывания (SaaS, PaaS или собственный хостинг) и запишите, какие строки приведённого выше разделения принадлежат организации.
2. Тестируйте сторону эксплуатанта напрямую: системный промпт, данные для поиска, разрешения инструментов и обработку выходных данных. Тестирование модели производителем их не охватывает.
3. Прежде чем внедрять модель, изучите системную карту поставщика, его условия хранения данных и использования их для обучения и найдите канал раскрытия уязвимостей.
4. Ограничьте возможности внедрённой инструкции: инструменты с минимальными привилегиями, ограниченный доступ к данным и одобрение человеком необратимых действий.
5. Решите, какие данные могут попадать в промпты, и ведите журналы, достаточные для восстановления хода инцидента.
6. Учебные материалы по фреймворкам и red teaming см. в [курсе FireAI University по фреймворкам безопасности ИИ и red teaming](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming).

## Значение для FireAI

Локальное приложение или агент, обращающийся к API модели, — это приложение на Mac, и его адреса видны FireAI. [Активность](https://hisnlabs.com/ru/docs/activity-and-connection-history) показывает, какие приложения выходили в сеть, а [Правила](https://hisnlabs.com/ru/docs/per-app-rules) позволяют пользователю разрешить или заблокировать приложение или конкретный адрес. Это один механизм контроля на стороне эксплуатанта, на одном Mac. FireAI не анализирует промпты, не оценивает выходные данные модели, не обнаруживает внедрение промптов и не оценивает, выполняет ли поставщик какие-либо юридические обязанности.

## Ограничения

- Страницы Microsoft — это рекомендации производителя для продуктов Azure; они называют себя иллюстративными и не меняют условий договоров. Текст CSA — предложение 2023 года.
- Эта заметка не является юридической консультацией. Является ли организация поставщиком, эксплуатантом или оператором системы высокого риска по EU AI Act, зависит от обстоятельств, которые здесь не оцениваются, а национальные органы могут толковать Регламент по-разному.
- Даты Digital Omnibus взяты со страницы Комиссии с хронологией и из одного анализа юридической фирмы. Сам текст регламента для этой заметки не изучался.
- Таблица для API — обобщение, и отдельные поставщики в своих условиях относят некоторые строки иначе.

## Какое место здесь занимают FireAI и HisnLabs

На вашей стороне границы находится и то, что покидает Mac. FireAI показывает это и позволяет вам решать.

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

Вы можете прочитать о технических решениях, лежащих в его основе, или попробовать FireAI в течение 17 дней на странице [FireAI от HisnLabs](https://hisnlabs.com/ru/download).

## Sources

- [Microsoft Learn: Artificial intelligence shared responsibility model (page dated 24 August 2026)](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai)
- [Microsoft Learn: AI agent shared responsibility model (page dated 26 August 2026)](https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility-ai-agent)
- [Cloud Security Alliance: Generative AI: a proposed shared responsibility model (28 July 2023)](https://cloudsecurityalliance.org/blog/2023/07/28/generative-ai-proposed-shared-responsibility-model)
- [European Commission: Guidelines on the obligations of general-purpose AI model providers (FAQ)](https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers)
- [European Commission: AI Act regulatory framework and application timeline](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)
- [Norton Rose Fulbright, Data Protection Report: The EU AI Act, when does it become enforceable now? (24 July 2026)](https://www.dataprotectionreport.com/2026/07/the-eu-ai-act-when-does-it-become-enforceable-now/)
- [FireAI docs: Rules: app, website, domain, IP or a range](https://hisnlabs.com/en/docs/per-app-rules)
- [FireAI docs: Activity: every app that went online](https://hisnlabs.com/en/docs/activity-and-connection-history)
- [FireAI University: AI security frameworks and red teaming](https://hisnlabs.com/en/university/ai-security-frameworks-and-red-teaming)