Организации, строящие решения на облачной языковой модели, получают от производителя модель, прошедшую обучение безопасности, и платформу, но остаются ответственными за приложение вокруг неё. Microsoft, Cloud Security Alliance и Регламент ЕС об ИИ (EU AI Act) распределяют работу между поставщиком модели и стороной, которая её развёртывает, используя разную терминологию и имея разную юридическую силу. В этой заметке три подхода сравниваются и предлагается практическое разделение для распространённого случая, когда модель используется через API. Она дополняет статью How Anthropic red-teams Claude, and what it leaves to you, в которой на одном опубликованном примере рассматривается сторона поставщика.
Контекст: облачная модель, распространённая на ИИ
Облачная модель разделённой ответственности относит каждый механизм контроля к поставщику или к клиенту в зависимости от типа сервиса: программное обеспечение как услуга (SaaS), платформа как услуга (PaaS) или инфраструктура как услуга (IaaS). И Microsoft, и Cloud Security Alliance (CSA) распространяют эту идею на генеративный ИИ. Такое расширение меняет скорее терминологию, чем логику: чем ниже по стеку строит клиент, тем больше механизмов контроля принадлежит ему.
Модели производителей
Microsoft: платформа, приложение и использование
Модель разделённой ответственности за ИИ от Microsoft описывает приложение с ИИ как три уровня: платформу ИИ, приложение ИИ и использование ИИ. Уровень платформы предоставляет модель через API и включает систему безопасности, фильтрующую вредоносные входные и выходные данные. Уровень приложения — это интерфейс, с которым работает пользователь, с привязкой к данным (grounding), плагинами и коннекторами данных; ему нужна собственная система безопасности приложения. Уровень использования охватывает то, как люди пользуются этой возможностью, и здесь Microsoft указывает на управление идентификацией и доступом, политики допустимого использования и обучение пользователей. [1]
Какая доля каждого уровня принадлежит клиенту, зависит от типа развёртывания. На странице указано, что обязанности различаются для SaaS, PaaS и IaaS; рекомендуется начинать с SaaS-предложений, таких как Copilot, переходить к PaaS-сервисам, таким как Azure OpenAI Service, только если готовые возможности не подходят, а создание собственных моделей оставить организациям с глубокой экспертизой. Страница добавляет, что рекомендации носят иллюстративный характер, используются в смысле управления и не изменяют никаких соглашений с Microsoft. [1]
Microsoft: расширение для агентов
Вторая страница Microsoft посвящена агентам, которые она отличает от простой модели: агент действует без одобрения человеком каждого шага, планирует и работает в циклах, хранит память, имеет собственную идентичность и может взаимодействовать с другими агентами. Она добавляет три уровня: оркестрацию агентов, инструменты и действия, а также память и состояние. В её матрице ответственности в случае PaaS за клиентом остаются инструкции и область действия агента, разрешения для каждого инструмента и одобрение человеком действий с серьёзными последствиями, тогда как среда выполнения и платформа оркестрации принадлежат Microsoft. [2]
Страница перечисляет обязанности, которые всегда остаются за клиентом: данные, идентификация и минимальные привилегии, авторизация действий, контроль со стороны человека, допустимое использование и управление. В ней также сказано, что автономность никогда не снижает подотчётность. [2]
Cloud Security Alliance: предложение 2023 года
В записи блога от 28 июля 2023 года один из членов CSA предложил модель с тремя сторонами: поставщиком сервиса ИИ, пользователем сервиса ИИ, создающим приложение, и предприятием или конечным пользователем этого приложения. Согласно предложению, IaaS-поставщик предоставляет инфраструктуру и базовые модели, а пользователь отвечает за обучение, проверку данных, фильтрацию промптов и безопасность приложения; в случае PaaS пользователь обеспечивает контекст и безопасность приложения; в случае SaaS пользователь управляет привязкой к данным, фильтрацией промптов и защитой интеллектуальной собственности. Запись представляет это как предложение по разделению обязанностей, а не как стандарт. [3]
Право: EU AI Act распределяет обязанности по ролям
EU AI Act распределяет обязанности по ролям. Согласно ответам на частые вопросы к руководящим принципам Европейской комиссии, поставщик модели ИИ общего назначения — это организация, которая разрабатывает модель или заказывает её разработку и выводит её на рынок под своим именем. Обязанности поставщика включают техническую документацию, документацию для разработчиков следующего уровня о возможностях и ограничениях, политику соблюдения авторского права и публичное резюме обучающих данных. Эти обязанности применяются с 2 августа 2025 года. Модели, предположительно несущие системный риск, — с вычислительными затратами на обучение от 10^25 операций с плавающей запятой — несут дополнительные обязанности, включая состязательное тестирование и меры кибербезопасности. [4]
Там же 2 августа 2026 года названо датой, с которой к этим поставщикам применяются меры принуждения, включая штрафы, а 2 августа 2027 года — сроком для моделей, выведенных на рынок до 2 августа 2025 года. Там же указано, что разработчик следующего уровня, изменивший модель, становится поставщиком лишь в исключительных обстоятельствах, например при использовании более трети исходных вычислительных затрат на обучение, так что большинство вариантов дообучения не меняет роль поставщика. [4]
Эксплуатанты (deployers), то есть организации, использующие системы ИИ, несут отдельный набор обязанностей. Анализ юридической фирмы от 24 июля 2026 года относит к обязанностям эксплуатантов с 2 августа 2026 года раскрытие информации о дипфейках и уведомление людей о распознавании эмоций и биометрической категоризации. Для систем высокого риска в нём перечислены компетентный контроль со стороны человека, уведомление людей об использовании ИИ и консультации с работниками. [6] Страница Комиссии с хронологией добавляет, что эксплуатанты должны обеспечивать контроль со стороны человека и мониторинг и сообщать о серьёзных инцидентах после вывода систем на рынок. [5]
Перенос сроков по Digital Omnibus
Сроки для систем высокого риска сдвинулись. Страница Комиссии с хронологией указывает 2 декабря 2027 года для систем высокого риска в чувствительных областях, таких как биометрия, трудоустройство и правоохранительная деятельность, и 2 августа 2028 года для систем высокого риска, встроенных в регулируемые продукты, ссылаясь на Digital Omnibus по ИИ, который, по её описанию, вступает в силу в июле 2026 года. [5] Анализ Norton Rose Fulbright приводит те же две даты и указывает, что Omnibus опубликован в официальном своде законодательства ЕС. [6] Таким образом, два независимых источника сходятся в том, что перенос принят, а не только предложен. Обязанности поставщиков моделей общего назначения и описанные выше обязанности по прозрачности этими двумя датами не переносятся.
Разделение работы при использовании модели через API
Для случая PaaS, когда приложение обращается к облачной модели, источники поддерживают следующее разделение. Строки, основанные на Microsoft, следуют описанным выше уровням платформы и приложения; строки о тестировании пограничных рисков, системной документации и каналах раскрытия уязвимостей отражают обязанности поставщиков по руководящим принципам ЕС и практики, которые публикуют производители моделей. Таблица — обобщение FireAI, а не текст какого-либо из источников.
| Область | Сторона поставщика | Ваша сторона |
|---|---|---|
| Поведение модели | Обучение безопасности и выравнивание модели | Системный промпт и защитные механизмы приложения |
| Тестирование рисков | Тестирование пограничных рисков самой модели | Тестирование вашего приложения, включая его промпты, данные и инструменты |
| Платформа | Безопасность платформы и базовые фильтры входных и выходных данных | Проверки безопасности приложения для контента, плагинов и коннекторов |
| Документация | Системная карта и документация для разработчиков следующего уровня | Её изучение и фиксация того, какую модель и версию вы развернули |
| Данные и инструменты | Ничего сверх договора об API | Данные RAG, инструменты, агенты и их разрешения |
| Выходные данные | Возвращает сгенерированный текст | Обработка выходных данных далее: проверка, экранирование, одобрение человеком |
| Эксплуатация | Канал раскрытия уязвимостей модели | Журналирование, мониторинг и реагирование на инциденты для приложения |
| Люди | Условия политики использования | Собственная политика использования и обучение пользователей |
Две области являются разделёнными в строгом смысле. Первая — внедрение промптов (prompt injection): поставщик обучает модель противостоять внедрённым инструкциям, а эксплуатант ограничивает то, чего может добиться внедрённая инструкция, через разрешения инструментов и доступ к данным. Страница Microsoft об агентах описывает то же разделение, предписывая клиентам считать извлечённый контент, выходные данные инструментов и сообщения других агентов недоверенными и ставить действия с серьёзными последствиями под контроль. [2] Вторая — конфиденциальность данных: поставщик устанавливает условия хранения и использования для обучения, а эксплуатант решает, какие данные вообще попадают в промпт или поисковый индекс.
Рекомендации
- Сначала определите тип развёртывания (SaaS, PaaS или собственный хостинг) и запишите, какие строки приведённого выше разделения принадлежат организации.
- Тестируйте сторону эксплуатанта напрямую: системный промпт, данные для поиска, разрешения инструментов и обработку выходных данных. Тестирование модели производителем их не охватывает.
- Прежде чем внедрять модель, изучите системную карту поставщика, его условия хранения данных и использования их для обучения и найдите канал раскрытия уязвимостей.
- Ограничьте возможности внедрённой инструкции: инструменты с минимальными привилегиями, ограниченный доступ к данным и одобрение человеком необратимых действий.
- Решите, какие данные могут попадать в промпты, и ведите журналы, достаточные для восстановления хода инцидента.
- Учебные материалы по фреймворкам и red teaming см. в курсе FireAI University по фреймворкам безопасности ИИ и red teaming.
Значение для FireAI
Локальное приложение или агент, обращающийся к API модели, — это приложение на Mac, и его адреса видны FireAI. Активность показывает, какие приложения выходили в сеть, а Правила позволяют пользователю разрешить или заблокировать приложение или конкретный адрес. Это один механизм контроля на стороне эксплуатанта, на одном 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.