Данные, обучение, модели и выпуски

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

Прием и подготовка данныхПрием и подготовка данных

Каждый набор данных имеет владельца, происхождение и разрешенное назначениеКаждый набор данных имеет владельца, происхождение и разрешенное назначение

Идентификатор требования: AI-DATA1

Требование

До загрузки или использования владелец системы должен зарегистрировать набор данных или RAG-корпус: источник, владельца, стадию жизненного цикла, категорию чувствительности, назначение, версию, преобразования, ограничения использования, допустимых получателей и связь с системой, моделью, индексом или выпуском. Для стороннего источника дополнительно фиксируются условия получения и приемки. Синтетические данные отмечаются отдельно по AI-DATA7.

Запись создается до загрузки набора, и при его изменении оформляется новая версия. Если система использует только управляемый модельный API и не ведет собственных наборов, все равно фиксируются разрешенные категории данных и набор для оценки.

Реализация

Yandex Cloud предоставляет хранилища и средства контроля доступа, но не формирует за организацию реестр происхождения и разрешенного использования. DataSphere разграничивает доступ к сообществам и проектам; опубликованная модель доступа DataSphere не заменяет запись о происхождении конкретного набора. Запись связывается с точной версией объекта в фактическом хранилище: версией объекта Object Storage, идентификатором Vector Store или индекса, расположением в Yandex Managed Service for OpenSearch или Yandex Managed Service for YDB либо набором DataSphere.

Ручная проверка

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

Неучтенный или неразрешенный источник не должен попадать в обучение, оценку или индекс.

Артефакт

• Запись реестра.
• Прослеживание до объекта и версии.
• Версия карточки.
• Версия или хеш объекта.
• Согласующий.

Загрузчик RAG ограничен утвержденным источником и назначениемЗагрузчик RAG ограничен утвержденным источником и назначением

Идентификатор требования: AI-RAG-INGEST1

Применимость

Требование применяется, если система создает или обновляет RAG-корпус либо поисковый индекс.

Требование

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

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

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

Реализация

Для AI Search фиксируются исходный объект, файл, Vector Store и роли управления.

Для Managed Service for OpenSearch, YDB или другого хранилища используются собственные роли, сетевые границы и объекты конфигурации выбранного сервиса.

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

В AI Search индекс создается документированным потоком (AI Studio → AI Search → поисковые индексы); Terraform управляет инфраструктурой, но не допуском корпуса.

Проверка

1. Выполните чтение утвержденного источника, запись в назначенную промежуточную область и публикацию тестовой версии.
2. Затем проверьте отказ чтения неутвержденного источника и записи в посторонний индекс или область.
3. Отдельно проверяются отказ для измененного хеша и неверного арендатора — до индексирования.

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

Артефакт

• Успешная загрузка утвержденного объекта.
• Отказ для неутвержденного источника.
• Версия загрузчика.
• События принятия и отклонения.
• Запись о переиндексации.

Стадии данных разделеныСтадии данных разделены

Идентификатор требования: AI-DATA3

Требование

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

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

Если один неизменяемый вход используется напрямую без производных стадий, результат N/A допустим только для отсутствующих ветвей.

Для Object Storage можно использовать отдельные бакеты или префиксы, политики доступа и версионирование.

Для сетевых хранилищ, доступных по сети, применяются группы безопасности VPC там, где сервис их поддерживает. Конкретная схема должна соответствовать выбранному сервису, а не переноситься с одного хранилища на другое.

В AI Search загрузка файла и создание индекса рассматриваются как разные объекты жизненного цикла.

Проверка

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

Артефакт

• Политики доступа к бакетам/префиксам.
• Тест записи из рабочей среды.
• Схема стадий.
• Версии входа и выхода.
• Журнал перехода.

Данные классифицированы и минимизированы до передачи в ИИ-контурДанные классифицированы и минимизированы до передачи в ИИ-контур

Идентификатор требования: AI-DATA4

Требование

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

Если применяется обратимое преобразование, должны быть определены место выполнения, допустимая обратимость и субъекты с доступом к ключу или таблице соответствия.

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

Реализация

Модуль контроля данных Data Security Posture Management (DSPM) может использоваться для поиска определенных категорий данных в поддерживаемых источниках. Он не преобразует исходные данные и не определяет правовое основание обработки.

Область источников, сервисный аккаунт с ролью dspm.worker и дополнительные права для KMS-зашифрованного бакета описаны в инструкции по созданию сканирования DSPM. Находка DSPM или NER не считается преобразованием: назначение найденного кандидата подтверждает человек или логика приложения.

Проверка

1. Возьмите выборку из фактического входного набора после преобразований и сопоставьте ее с утвержденной схемой.
2. Попытайтесь загрузить запрещенные поля или объект.

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

Артефакт

• Схема полей.
• Выборка после преобразования.
• Отказ загрузки запрещенных полей.
• Карта полей по назначениям.
• Запись об удалении копий.

Качество данных и независимость оценки проверяются до выпускаКачество данных и независимость оценки проверяются до выпуска

Идентификатор требования: AI-DATA5

Требование

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

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

Результат утверждает проверяющий, независимый от производителя данных; отчет связывается с точной версией набора, модели или индекса. При отсутствии управляемого набора данных результат N/A допустим только тогда, когда выбор модели или API все равно проходит независимую оценку.

Ручная проверка

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

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

Артефакт

• Сохраненный отчет с версией, критериями и результатом.
• Версия кода проверок и тестов.
• Хеши набора.
• Независимый проверяющий.

Изменения данных и RAG-корпуса контролируютсяИзменения данных и RAG-корпуса контролируются

Идентификатор требования: AI-DATA6

Требование

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

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

Реализация

В Object Storage для истории объектов можно включить версионирование, а для требуемой неизменяемости — Object Lock с учетом его правил и сроков.

В AI Search загрузка файлов и создание Vector Store являются частью документированного процесса индексирования; авторизацию документов и допуск содержимого приложение реализует отдельно.

Манифест связывает логический выпуск с точными идентификаторами и хешами объектов, файлов и индексов; каждое изменение создает новую версию и новое согласование, единственная копия не перезаписывается. Object Lock включается только после утверждения срока хранения: защищенные версии могут стать неудаляемыми. Для хранилищ без версионирования сохраняются неизменяемая копия выпуска и запись об изменении.

Проверка

1. Проследите одну опубликованную версию от исходного объекта до индекса или набора.
2. Затем попробуйте опубликовать измененный объект в обход проверки.
3. Отдельно подтвердите на синтетическом объекте появление новой версии, доступ к предыдущей версии и восстановление из нее.

Требование выполнено, если обход отклоняется, а активная версия и инициатор изменения устанавливаются по сохраненным данным.

Артефакт

• Связь версии с источником.
• Тест обхода проверки.
• Манифест выпуска с хешами.
• Событие изменения.
• Тест восстановления.

Синтетические данные учитываются отдельноСинтетические данные учитываются отдельно

Идентификатор требования: AI-DATA7

Применимость

Требование применяется, если синтетические данные используются для обучения, дообучения или оценки.

Требование

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

Каждая синтетическая запись или пакет получает метку synthetic=true; необработанные сгенерированные данные не включаются в обучение или оценку без явного согласования. Итоговый пакет получает отдельный идентификатор и хеш набора.

Реализация

При генерации через AI Studio или DataSphere запись содержит доступные идентификаторы модели, API, проекта или задания. Yandex Cloud не формирует за организацию универсальный реестр синтетических данных.

Проверка

1. Проследите версию синтетической выборки до генератора, исходных данных и параметров.
2. Проверьте, что отчет показывает ее долю и отдельно оценивает необходимые свойства относительно несинтетической контрольной выборки.

Сгенерированный тестовый пример без метки должен отклоняться при загрузке.

Артефакт

• Запись о синтетической части.
• Отчет с долей и контрольной выборкой.
• Версия генератора.
• Результат теста на отклонение немеченых данных.

Обучение и модельные артефактыОбучение и модельные артефакты

Разработка, обучение и продуктивное выполнение разделеныРазработка, обучение и продуктивное выполнение разделены

Идентификатор требования: AI-TRAIN1

Требование

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

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

Способ доставки секрета и сетевой контроль выбираются по фактической среде и проверяются по разделам IAM, сеть, шифрование, секреты и аудит и Профили реализации в Yandex Cloud.

Реализация

В DataSphere права назначаются на сообщества и проекты согласно документации доступа.

В Managed Service for Kubernetes дополнительно разделяются IAM-доступ к кластеру и Kubernetes RBAC; рекомендации по пространствам имен, сетевой политике и защите метаданных приведены в руководстве по безопасности Kubernetes.

Для системы, использующей только управляемый модельный API без обучения, результат N/A применим к этому требованию целиком.

Для DataSphere фиксируются сервисный аккаунт, сеть и группы безопасности проекта и свидетельства заданий; события плоскости управления не доказывают происхождение данных внутри ноутбука или задания.

Для Kubernetes используется отдельное пространство имен или кластер с Workload Identity, RBAC и сетевой политикой.

Для Compute Cloud задаются отдельный сервисный аккаунт, группы безопасности, диск с шифрованием и путь доставки секрета.

Идентичность разработки не изменяет указатель продуктивного артефакта; выпуск копирует точный утвержденный артефакт.

Проверка

1. Сопоставьте пользователей и сервисные аккаунты экспериментального и продуктивного контуров.
2. Из экспериментальной среды и постороннего задания попытайтесь прочитать продуктивный или чужой тестовый секрет, изменить продуктивный объект и обратиться к запрещенному эндпоинту.
3. Отдельно проверьте, что субъект разработки или обучения не может развернуть или перезаписать продуктивную версию.

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

Артефакт

• Сопоставление контуров.
• Тест чтения чужого секрета и записи в продуктив.
• Хеши входных и выходных объектов задачи.

Модельный комплект имеет проверяемое происхождениеМодельный комплект имеет проверяемое происхождение

Идентификатор требования: AI-MODEL1

Требование

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

Для управляемого API вместо недоступных весов фиксируются поставщик, API, идентификатор или версия модели и доступные параметры, влияющие на поведение.

Запись должна однозначно указывать комплект, который прошел проверку и используется в выпуске. Утвержденные артефакты копируются в контролируемое хранилище; загрузка в продуктивной среде напрямую по изменяемому внешнему URL не допускается — продуктивная среда загружает только точный дайджест.

Object Storage может хранить файлы комплекта, Yandex Container Registry — Docker-образы, а DataSphere — документированные типы ресурсов, включая модели, Docker-образы и файловые хранилища. Организация должна связать фактические объекты и версии в отдельной записи происхождения независимо от места хранения. Границы ресурсов описаны в документации Container Registry и DataSphere.

Ручная проверка

1. Определите модельный комплект работающего экземпляра и сравните его с записью допуска.
2. Повторно вычислите дайджест развернутых файлов и образов и сверьте его с записью; измененный артефакт или неизвестный источник блокирует допуск и помещается в карантин.

Несовпадение веса, конфигурации, загрузчика или зависимости требует нового рассмотрения.

Артефакт

• Запись происхождения.
• Сопоставление с работающим экземпляром.
• Карточка модели.
• Хеши и версии объектов в хранилище.

Формат и загрузчик модели не допускают произвольного выполненияФормат и загрузчик модели не допускают произвольного выполнения

Идентификатор требования: AI-MODEL2

Требование

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

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

Реализация

Сканер Container Registry анализирует уязвимости Docker-образа, а не поведение модели, содержимое весов или отравление данных. Его область описана в документации сканера.

Проверка

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

Артефакт

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

Выпуск, откат и отзывВыпуск, откат и отзыв

В продуктивную среду допускается точная проверенная версияВ продуктивную среду допускается точная проверенная версия

Идентификатор требования: AI-REL1

Требование

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

Развертывание использует манифест выпуска, а не тег или имя по умолчанию: для бессерверных сред — точная ревизия или версия, для Kubernetes — дайджест образа и конфигурация, для AI Studio — идентификаторы экземпляра модели, Guardrail и индекса.

Реализация

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

Проверка

По продуктивной ревизии восстановите все перечисленные версии и решение о допуске. Требование выполнено, если набор однозначен, воспроизводим и совпадает с проверенным. Тег latest или неподтвержденное расхождение фактической ревизии с манифестом означает невыполнение.

Артефакт

• Решение о выпуске.
• Сопоставление с продуктивной ревизией.
• Хеш манифеста выпуска.
• Событие развертывания.

Замена, откат и отзыв версии управляются явноЗамена, откат и отзыв версии управляются явно

Идентификатор требования: AI-REL2

Требование

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

Реализация

Средства конкретного сервиса используются только в их документированной области: ревизии и события развертывания и отката Serverless Containers из справочника Audit Trails, версии объектов Object Storage или собственная схема версий приложения. Наличие истории объектов не гарантирует работоспособный откат всей ИИ-системы.

Цель отката фиксируется по среде: для бессерверных сред — предыдущая проверенная ревизия или версия; для Kubernetes — предыдущий образ и конфигурация; для Compute Cloud — план восстановления образа, диска и конфигурации; для RAG — предыдущий манифест корпуса или индекса либо процедура перестроения; для AI Studio — предыдущая конфигурация экземпляра, Guardrail и индекса.

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

Проверка

На тестовой среде выполните замену и откат связанного комплекта.

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

Откат, раскрывающий данные более нового состояния, не засчитывается.

Артефакт

• Тест замены и отката.
• Журнал инициатора.
• Недоступность отозванной версии.
• Идентификаторы целей отката.
• Согласование возврата.