Введение

Назначение и область примененияНазначение и область применения

Стандарт устанавливает требования и рекомендации по безопасности для систем искусственного интеллекта, развернутых полностью или частично в Yandex Cloud. Он предназначен для архитекторов, специалистов по информационной безопасности, разработчиков, ML- и DevSecOps-инженеров, владельцев сервисов, SOC и специалистов по соответствию требованиям.

Стандарт применяется к следующим сценариям:

• вызов моделей и API Yandex AI Studio;
• RAG на базе AI Search или выбранного организацией хранилища;
• агенты, MCP Gateway, MCP-серверы и другие инструменты;
• обучение, эксперименты и развертывание моделей в Yandex DataSphere;
• работа ИИ-компонентов в Yandex Managed Service for Kubernetes, Yandex Serverless Containers, Yandex Cloud Functions и Yandex Compute Cloud;
• использование самостоятельно размещенных моделей;
• вызов внешних модельных API из Yandex Cloud;
• обработка данных, модельных артефактов, системных инструкций, секретов и журналов на всех стадиях жизненного цикла.

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

Стандарт можно рассматривать как основу для разработки внутренних политик организации. Не все требования могут быть применимы к конкретной системе; также могут потребоваться дополнительные меры, не включенные в документ.

Разделение ответственностиРазделение ответственности

Граница ответственности зависит от используемого сервиса и способа его потребления. Общий принцип описан в модели разделения ответственности Yandex Cloud.

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

• выбор облаков, каталогов, сервисов и режимов их использования;
• учетные записи, сервисные аккаунты, ключи, роли и область привязок;
• публичные точки входа, сетевые маршруты и связи с внешними системами;
• допустимость, минимизацию, классификацию и сроки хранения данных;
• прикладную проверку ввода, контекста и вывода модели;
• авторизацию документов до передачи в RAG-контекст;
• полномочия агента и его инструментов;
• прикладные журналы, корреляцию событий и реагирование;
• выпуск, замену и вывод из эксплуатации данных, индексов, моделей и конфигураций.

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

Как применять стандартКак применять стандарт

До проверки требований нужно иметь описание фактической или планируемой архитектуры. В ней должны быть указаны:

• компоненты, среды и границы доверия;
• входные точки и вызываемые модельные API;
• облака, каталоги и идентификаторы ресурсов;
• пользователи, сервисные аккаунты, API-ключи и внешние субъекты;
• хранилища данных, RAG-индексы и места хранения модельных артефактов;
• пути входящего, исходящего и межкомпонентного трафика;
• инструменты агента, их бэкенды и целевые ресурсы;
• места обработки персональных и иных регулируемых данных;
• источники аудитных, прикладных и эксплуатационных журналов;
• внешние поставщики и получатели данных.

Слова «должен», «должна» и «должны» обозначают обязательное требование. Слово «рекомендуется» обозначает меру, выбор которой зависит от риска и архитектуры. Слово «может» обозначает допустимый способ реализации, но не единственный.

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

ИсключенияИсключения

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

Функция на стадии Preview или доступная по запросу может использоваться как мера только после подтверждения доступности для организации. Если она недоступна, владелец выбирает другой способ достижения требуемого состояния либо оформляет исключение; недоступность конкретного продукта не отменяет само требование.

ИдентификаторыИдентификаторы

Независимые проверяемые требования имеют стабильные идентификаторы AI-*. Идентификатор служит для ссылок и записей проверки и не кодирует критичность. Один идентификатор всегда обозначает одно требуемое состояние.

СвидетельстваСвидетельства

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

Свидетельство не должно раскрывать значение секрета, избыточные персональные данные, полный диалог или закрытый документ. Если сервис не публикует нужное событие или настройку, это фиксируется как слепая зона и при необходимости закрывается прикладным журналом или ручным тестом; отсутствие телеметрии не превращается в успешный результат.