[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > Стандарт безопасности для внедрения и эксплуатации ИИ-систем в Yandex Cloud, версия 1.0.0 > Данные, обучение, модели и выпуски

# Данные, обучение, модели и выпуски

{#data-training-models}

Требования этого раздела применяются к тем объектам жизненного цикла, которые фактически существуют. Для управляемого инференса без собственного обучения не применяются требования к обучающей среде и загружаемым весам, но сохраняются требования к входным данным, RAG-корпусу, конфигурации приложения и версии используемой модели. Для RAG без обучения модельным выпуском считается согласованная комбинация модели, индекса, системных инструкций и прикладной конфигурации.

## Прием и подготовка данных {#data-intake}

### Каждый набор данных имеет владельца, происхождение и разрешенное назначение {#dataset-has-owner-origin-allowed-purpose}

{#ai-data1-id}

Идентификатор требования: `AI-DATA1`

{#ai-data1-requirement}

**Требование**

До загрузки или использования владелец системы должен зарегистрировать набор данных или RAG-корпус: источник, владельца, стадию жизненного цикла, категорию чувствительности, назначение, версию, преобразования, ограничения использования, допустимых получателей и связь с системой, моделью, индексом или выпуском. Для стороннего источника дополнительно фиксируются условия получения и приемки. Синтетические данные отмечаются отдельно по `AI-DATA7`.

Запись создается до загрузки набора, и при его изменении оформляется новая версия. Если система использует только управляемый модельный API и не ведет собственных наборов, все равно фиксируются разрешенные категории данных и набор для оценки.

{#ai-data1-implementation}

**Реализация**

Yandex Cloud предоставляет хранилища и средства контроля доступа, но не формирует за организацию реестр происхождения и разрешенного использования. DataSphere разграничивает доступ к сообществам и проектам; опубликованная [модель доступа DataSphere](../../datasphere/security/index.md) не заменяет запись о происхождении конкретного набора. Запись связывается с точной версией объекта в фактическом хранилище: [версией объекта Object Storage](../../storage/concepts/versioning.md), идентификатором Vector Store или индекса, расположением в [Yandex Managed Service for OpenSearch](../../managed-opensearch/index.md) или [Yandex Managed Service for YDB](../../ydb/index.md) либо набором [DataSphere](../../datasphere/index.md).

{#ai-data1-manual-check}

**Ручная проверка**

1. Выберите по одному внутреннему, стороннему и синтетическому набору, если они используются.
1. Проследите от записи в реестре до фактического объекта и версии.
1. Дополнительно выберите образцы объектов из развернутого корпуса и проследите каждый до его записи; объект без записи отклоняется при загрузке или выпуске, помещается в карантин и получает владельца, источник и классификацию либо удаляется по правилам хранения.

Неучтенный или неразрешенный источник не должен попадать в обучение, оценку или индекс.

{#ai-data1-artifacts}

**Артефакт**

* Запись реестра.
* Прослеживание до объекта и версии.
* Версия карточки.
* Версия или хеш объекта.
* Согласующий.

### Загрузчик RAG ограничен утвержденным источником и назначением {#rag-loader-restricted-approved-source-destination}

{#ai-rag-ingest1-id}

Идентификатор требования: `AI-RAG-INGEST1`

{#ai-rag-ingest1-applicability}

**Применимость**

Требование применяется, если система создает или обновляет RAG-корпус либо поисковый индекс.

{#ai-rag-ingest1-requirement}

**Требование**

Рабочая идентичность загрузчика должна читать только утвержденные источники и писать только в назначенную промежуточную область и целевой индекс. Она не должна иметь право изменять иной продуктивный корпус только потому, что он находится в том же облаке или каталоге.

Источник, версия, результат приемной проверки, субъект загрузки и решение о публикации связываются с операцией обновления. Идентичности загрузки и поиска разделяются.

До записи загрузчик проверяет карточку источника, тип, размер, хеш и обязательные метаданные арендатора и доступа; неутвержденный пакет помещается в карантин.

{#ai-rag-ingest1-implementation}

**Реализация**

Для [AI Search](https://aistudio.yandex.ru/docs/ru/ai-studio/concepts/search/) фиксируются исходный объект, файл, Vector Store и роли управления.

Для Managed Service for OpenSearch, YDB или другого хранилища используются собственные роли, сетевые границы и объекты конфигурации выбранного сервиса.

Архитектура может разделять чтение источника, запись в промежуточную область и публикацию между несколькими идентичностями.

В AI Search индекс создается документированным потоком (`AI Studio → AI Search → поисковые индексы`); Terraform управляет инфраструктурой, но не допуском корпуса.

{#ai-rag-ingest1-check}

**Проверка**

1. Выполните чтение утвержденного источника, запись в назначенную промежуточную область и публикацию тестовой версии.
1. Затем проверьте отказ чтения неутвержденного источника и записи в посторонний индекс или область.
1. Отдельно проверяются отказ для измененного хеша и неверного арендатора — до индексирования.

Свидетельство должно связывать опубликованную версию с источником, проверкой и субъектом изменения. При провале загрузчик приостанавливается, пакет помещается в карантин, затронутый сегмент индекса удаляется или перестраивается, скомпрометированная идентичность заменяется, после чего тест повторяется.

{#ai-rag-ingest1-artifacts}

**Артефакт**

* Успешная загрузка утвержденного объекта.
* Отказ для неутвержденного источника.
* Версия загрузчика.
* События принятия и отклонения.
* Запись о переиндексации.

### Стадии данных разделены {#data-stages-separated}

{#ai-data3-id}

Идентификатор требования: `AI-DATA3`

{#ai-data3-requirement}

**Требование**

Исходные, очищенные, размеченные, обучающие, оценочные и опубликованные данные должны быть различимы по объектам или версиям, правам записи и правилам продвижения. Переход между стадиями выполняется только после предусмотренной для него проверки и решения.

Изменение уже утвержденного объекта требует новой версии и повторного допуска; рабочая среда не должна изменять продуктивный корпус напрямую. Сеть и IAM по умолчанию не должны давать запись назад или между параллельными стадиями.

Если один неизменяемый вход используется напрямую без производных стадий, результат `N/A` допустим только для отсутствующих ветвей.

Для Object Storage можно использовать отдельные бакеты или префиксы, политики доступа и [версионирование](../../storage/operations/buckets/versioning.md).

Для сетевых хранилищ, доступных по сети, применяются [группы безопасности VPC](../../vpc/concepts/security-groups.md) там, где сервис их поддерживает. Конкретная схема должна соответствовать выбранному сервису, а не переноситься с одного хранилища на другое.

В AI Search загрузка файла и создание индекса рассматриваются как разные объекты жизненного цикла.

{#ai-data3-check}

**Проверка**

Проверьте путь одной записи от исходного объекта до опубликованной версии, субъекты с правом записи на каждой стадии и невозможность записи из продуктивной среды исполнения в исходный или оценочный набор. Производные результаты, созданные во время нарушения, признаются недействительными, а конвейер повторяется после сужения доступа.

{#ai-data3-artifacts}

**Артефакт**

* Политики доступа к бакетам/префиксам.
* Тест записи из рабочей среды.
* Схема стадий.
* Версии входа и выхода.
* Журнал перехода.

### Данные классифицированы и минимизированы до передачи в ИИ-контур {#data-classified-minimized-before-ai}

{#ai-data4-id}

Идентификатор требования: `AI-DATA4`

{#ai-data4-requirement}

**Требование**

Владелец данных должен определить для каждого поля или типа объекта категорию чувствительности, разрешенных получателей и допустимое действие: сохранить, удалить, обобщить, маскировать либо токенизировать. Поля, записи, вложения и секреты, которые не нужны для заявленного сценария, удаляются до передачи.

Если применяется обратимое преобразование, должны быть определены место выполнения, допустимая обратимость и субъекты с доступом к ключу или таблице соответствия.

Карта полей составляется по назначениям: промпт, контекст RAG, данные инструмента, внешний вызов и событие журнала; удаление или преобразование выполняется до пересечения границы, а не после получения провайдером или моделью.

{#ai-data4-implementation}

**Реализация**

[Модуль контроля данных Data Security Posture Management](../../security-deck/concepts/dspm.md) (DSPM) может использоваться для поиска определенных категорий данных в поддерживаемых источниках. Он не преобразует исходные данные и не определяет правовое основание обработки.

Область источников, сервисный аккаунт с ролью `dspm.worker` и дополнительные права для KMS-зашифрованного бакета описаны в [инструкции по созданию сканирования DSPM](../../security-deck/operations/dspm/create-scan.md). Находка DSPM или NER не считается преобразованием: назначение найденного кандидата подтверждает человек или логика приложения.

{#ai-data4-check}

**Проверка**

1. Возьмите выборку из фактического входного набора после преобразований и сопоставьте ее с утвержденной схемой.
1. Попытайтесь загрузить запрещенные поля или объект.

Отчет обнаружения без исправления источника не подтверждает минимизацию. Дополнительное чувствительное поле должно блокироваться или редактироваться до вызова и отсутствовать в журналах. При провале затронутый поток останавливается, кешированные, индексированные и записанные в журналы копии удаляются по правилам хранения и правовым требованиям, после чего тест повторяется.

{#ai-data4-artifacts}

**Артефакт**

* Схема полей.
* Выборка после преобразования.
* Отказ загрузки запрещенных полей.
* Карта полей по назначениям.
* Запись об удалении копий.

### Качество данных и независимость оценки проверяются до выпуска {#data-quality-independent-assessment-before-release}

{#ai-data5-id}

Идентификатор требования: `AI-DATA5`

{#ai-data5-requirement}

**Требование**

Организация должна определить входные версии, метрики, пороги и известные ограничения проверки качества, полноты и допустимого смещения для конкретного сценария. Обучающие и оценочные выборки должны разделяться так, чтобы утечка между ними не делала результат проверки недостоверным. Для RAG проверяются качество разбиения, актуальность, полнота метаданных и воспроизводимость поиска. Проверки охватывают полноту, дубликаты, схему, распределение, источники и пересечение обучающей и оценочной выборок.

Если используются синтетические данные, их доля, способ получения и влияние на оценку должны быть видны в отчете. Универсальный облачный порог качества не устанавливается: критерии утверждает владелец продукта совместно с ответственным за риск.

Результат утверждает проверяющий, независимый от производителя данных; отчет связывается с точной версией набора, модели или индекса. При отсутствии управляемого набора данных результат `N/A` допустим только тогда, когда выбор модели или API все равно проходит независимую оценку.

{#ai-data5-manual-check}

**Ручная проверка**

1. Повторите утвержденную оценку на зафиксированной версии данных и конфигурации.
1. Проверьте отсутствие пересечения идентификаторов или иных признаков утечки, а также сохраненный отчет с исходной версией, критериями и результатом.

Пакет с дубликатом, нарушенной схемой, запрещенными данными или пересечением обучающей и оценочной выборок должен блокировать выпуск: он помещается в карантин, источник или преобразование исправляется, формируется новый отчет и тест повторяется.

{#ai-data5-artifacts}

**Артефакт**

* Сохраненный отчет с версией, критериями и результатом.
* Версия кода проверок и тестов.
* Хеши набора.
* Независимый проверяющий.

### Изменения данных и RAG-корпуса контролируются {#data-and-rag-corpus-changes-controlled}

{#ai-data6-id}

Идентификатор требования: `AI-DATA6`

{#ai-data6-requirement}

**Требование**

Исходные, промежуточные и опубликованные версии должны иметь проверяемые идентификаторы или контрольные суммы. Для процесса фиксируются владелец, автор изменения, версия кода или конфигурации, выполненные проверки, решение о публикации и способ восстановления предыдущей безопасной версии. Загрузка, очистка, разбиение, построение индекса и публикация выполняются доверенной идентичностью через воспроизводимый процесс. Непроверенный объект не должен становиться доступным продуктивной системе.

Приемная проверка должна соответствовать риску источника и выявлять неподдерживаемый формат, нарушение структуры, неожиданное исполняемое содержимое и запрещенные организацией категории до публикации. Модерация модельного трафика не считается проверкой всего набора данных.

{#ai-data6-implementation}

**Реализация**

В Object Storage для истории объектов можно включить [версионирование](../../storage/operations/buckets/versioning.md), а для требуемой неизменяемости — [Object Lock](../../storage/concepts/object-lock.md) с учетом его правил и сроков.

В AI Search загрузка файлов и создание Vector Store являются частью документированного [процесса индексирования](https://aistudio.yandex.ru/docs/ru/ai-studio/concepts/search/index.html); авторизацию документов и допуск содержимого приложение реализует отдельно.

Манифест связывает логический выпуск с точными идентификаторами и хешами объектов, файлов и индексов; каждое изменение создает новую версию и новое согласование, единственная копия не перезаписывается. Object Lock включается только после утверждения срока хранения: защищенные версии могут стать неудаляемыми. Для хранилищ без версионирования сохраняются неизменяемая копия выпуска и запись об изменении.

{#ai-data6-check}

**Проверка**

1. Проследите одну опубликованную версию от исходного объекта до индекса или набора.
1. Затем попробуйте опубликовать измененный объект в обход проверки.
1. Отдельно подтвердите на синтетическом объекте появление новой версии, доступ к предыдущей версии и восстановление из нее.

Требование выполнено, если обход отклоняется, а активная версия и инициатор изменения устанавливаются по сохраненным данным.

{#ai-data6-artifacts}

**Артефакт**

* Связь версии с источником.
* Тест обхода проверки.
* Манифест выпуска с хешами.
* Событие изменения.
* Тест восстановления.

### Синтетические данные учитываются отдельно {#synthetic-data-accounted-separately}

{#ai-data7-id}

Идентификатор требования: `AI-DATA7`

{#ai-data7-applicability}

**Применимость**

Требование применяется, если синтетические данные используются для обучения, дообучения или оценки.

{#ai-data7-requirement}

**Требование**

Для синтетической части набора должны быть зарегистрированы модель или метод генерации, версия и параметры генератора, назначение, исходные данные, доля синтетических записей и известные ограничения. Синтетические записи проходят те же стадии допуска и проверки качества, что и остальные данные; их происхождение не должно смешиваться с наблюдаемыми данными.

Каждая синтетическая запись или пакет получает метку `synthetic=true`; необработанные сгенерированные данные не включаются в обучение или оценку без явного согласования. Итоговый пакет получает отдельный идентификатор и хеш набора.

{#ai-data7-implementation}

**Реализация**

При генерации через AI Studio или DataSphere запись содержит доступные идентификаторы модели, API, проекта или задания. Yandex Cloud не формирует за организацию универсальный реестр синтетических данных.

{#ai-data7-check}

**Проверка**

1. Проследите версию синтетической выборки до генератора, исходных данных и параметров.
1. Проверьте, что отчет показывает ее долю и отдельно оценивает необходимые свойства относительно несинтетической контрольной выборки.

Сгенерированный тестовый пример без метки должен отклоняться при загрузке.

{#ai-data7-artifacts}

**Артефакт**

* Запись о синтетической части.
* Отчет с долей и контрольной выборкой.
* Версия генератора.
* Результат теста на отклонение немеченых данных.

## Обучение и модельные артефакты {#training-artifacts}

### Разработка, обучение и продуктивное выполнение разделены {#dev-training-prod-execution-separated}

{#ai-train1-id}

Идентификатор требования: `AI-TRAIN1`

{#ai-train1-requirement}

**Требование**

Если организация обучает, дообучает или экспериментально запускает модели, такие задачи должны быть отделены от продуктивного контура по проекту, пространству имен, сервисному аккаунту, правам, хранилищам и сетевым путям в соответствии с выбранной средой. Эксперимент не должен получать продуктивные секреты и право изменять продуктивные данные только потому, что выполняется в том же облаке.

Для каждого задания секрет передается только его рабочей идентичности с минимальными правами и не хранится в ноутбуке, датасете, образе или журнале. Исходящий доступ ограничивается утвержденными источниками, получателями и назначением. Открытый доступ в интернет допускается только как ограниченное исключение с владельцем, сроком и компенсирующей мерой.

Способ доставки секрета и сетевой контроль выбираются по фактической среде и проверяются по разделам [IAM, сеть, шифрование, секреты и аудит](iam-network-crypto-secrets-audit.md) и [Профили реализации в Yandex Cloud](profiles.md).

{#ai-train1-implementation}

**Реализация**

В DataSphere права назначаются на сообщества и проекты согласно [документации доступа](../../datasphere/security/index.md).

В [Managed Service for Kubernetes](../../managed-kubernetes/index.md) дополнительно разделяются IAM-доступ к кластеру и Kubernetes RBAC; рекомендации по пространствам имен, сетевой политике и защите метаданных приведены в [руководстве по безопасности Kubernetes](../domains/kubernetes.md).

Для системы, использующей только управляемый модельный API без обучения, результат `N/A` применим к этому требованию целиком.

Для DataSphere фиксируются сервисный аккаунт, сеть и группы безопасности проекта и свидетельства заданий; события плоскости управления не доказывают происхождение данных внутри ноутбука или задания.

Для Kubernetes используется отдельное пространство имен или кластер с Workload Identity, RBAC и сетевой политикой.

Для [Compute Cloud](../../compute/index.md) задаются отдельный сервисный аккаунт, группы безопасности, диск с шифрованием и путь доставки секрета.

Идентичность разработки не изменяет указатель продуктивного артефакта; выпуск копирует точный утвержденный артефакт.

{#ai-train1-check}

**Проверка**

1. Сопоставьте пользователей и сервисные аккаунты экспериментального и продуктивного контуров.
1. Из экспериментальной среды и постороннего задания попытайтесь прочитать продуктивный или чужой тестовый секрет, изменить продуктивный объект и обратиться к запрещенному эндпоинту.
1. Отдельно проверьте, что субъект разработки или обучения не может развернуть или перезаписать продуктивную версию.

Разрешенное задание должно получить только назначенный секрет и источник; запрещенные действия должны быть отклонены, а журналы не должны содержать значение секрета. Допустимое отклонение оформляется как исключение по разделу [Исключения](intro.md#exceptions). Артефакты, созданные внутри недоверенной границы, признаются недействительными и пересобираются после изоляции.

{#ai-train1-artifacts}

**Артефакт**

* Сопоставление контуров.
* Тест чтения чужого секрета и записи в продуктив.
* Хеши входных и выходных объектов задачи.

### Модельный комплект имеет проверяемое происхождение {#model-artifact-verifiable-provenance}

{#ai-model1-id}

Идентификатор требования: `AI-MODEL1`

{#ai-model1-requirement}

**Требование**

Для самостоятельно размещенной или сторонней модели владелец должен зарегистрировать источник, версию, контрольную сумму, лицензионные и эксплуатационные ограничения, формат весов, токенизатор, конфигурацию, код загрузки, зависимые программные компоненты, связанные версии данных, статус допуска и результаты проверок.

Для управляемого API вместо недоступных весов фиксируются поставщик, API, идентификатор или версия модели и доступные параметры, влияющие на поведение.

Запись должна однозначно указывать комплект, который прошел проверку и используется в выпуске. Утвержденные артефакты копируются в контролируемое хранилище; загрузка в продуктивной среде напрямую по изменяемому внешнему URL не допускается — продуктивная среда загружает только точный дайджест.

Object Storage может хранить файлы комплекта, [Yandex Container Registry](../../container-registry/index.md) — Docker-образы, а DataSphere — документированные типы ресурсов, включая модели, Docker-образы и файловые хранилища. Организация должна связать фактические объекты и версии в отдельной записи происхождения независимо от места хранения. Границы ресурсов описаны в документации [Container Registry](../../container-registry/index.md) и [DataSphere](../../datasphere/concepts/resources.md).

{#ai-model1-manual-check}

**Ручная проверка**

1. Определите модельный комплект работающего экземпляра и сравните его с записью допуска.
1. Повторно вычислите дайджест развернутых файлов и образов и сверьте его с записью; измененный артефакт или неизвестный источник блокирует допуск и помещается в карантин.

Несовпадение веса, конфигурации, загрузчика или зависимости требует нового рассмотрения.

{#ai-model1-artifacts}

**Артефакт**

* Запись происхождения.
* Сопоставление с работающим экземпляром.
* Карточка модели.
* Хеши и версии объектов в хранилище.

### Формат и загрузчик модели не допускают произвольного выполнения {#model-format-loader-no-arbitrary-exec}

{#ai-model2-id}

Идентификатор требования: `AI-MODEL2`

{#ai-model2-requirement}

**Требование**

Перед первым использованием стороннего модельного комплекта организация должна оценить свойства формата, сопутствующего кода, пользовательского загрузчика и зависимостей, исключить ненужное выполнение кода, проверить контрольную сумму и провести первый запуск в изолированной среде без продуктивных секретов и записи в продуктивные хранилища. Конкретный формат выбирается по риску; название расширения само по себе не доказывает безопасность.

В правилах допуска перечисляются разрешенные форматы и точные версии загрузчиков для фактически используемого фреймворка; исполняемая десериализация недоверенного артефакта не применяется, если доступен совместимый безопасный формат.

{#ai-model2-implementation}

**Реализация**

Сканер Container Registry анализирует уязвимости Docker-образа, а не поведение модели, содержимое весов или отравление данных. Его область описана в [документации сканера](../../container-registry/concepts/vulnerability-scanner.md).

{#ai-model2-check}

**Проверка**

Повторите загрузку зафиксированного комплекта в изолированной среде и наблюдайте файловые, сетевые и процессные действия. Неожиданное выполнение кода, изменение внешнего состояния или несовпадение контрольной суммы блокирует допуск. Первичная проверка завершается ожидаемым результатом smoke-теста, после чего одноразовая среда проверки уничтожается.

{#ai-model2-artifacts}

**Артефакт**

* Результат изолированного запуска.
* Наблюдение за действиями.
* Версии формата и загрузчика.
* Конфигурация изолированной среды.
* Решение о допуске.

## Выпуск, откат и отзыв {#release-rollback}

### В продуктивную среду допускается точная проверенная версия {#exact-verified-version-admitted-to-prod}

{#ai-rel1-id}

Идентификатор требования: `AI-REL1`

{#ai-rel1-requirement}

**Требование**

Решение о выпуске должно связывать точные версии данных или индекса, модельный комплект, системные инструкции, конфигурацию приложения, образ, результаты проверок, действующие исключения и утверждающих. Сборка и публикация выполняются доверенным процессом; результат выпуска должен совпадать с утвержденным комплектом, а ручная подмена одного компонента после проверки не допускается.

Развертывание использует манифест выпуска, а не тег или имя по умолчанию: для бессерверных сред — точная ревизия или версия, для Kubernetes — дайджест образа и конфигурация, для AI Studio — идентификаторы экземпляра модели, Guardrail и индекса.

{#ai-rel1-implementation}

**Реализация**

Для контейнерного выпуска результат [сканирования образа](../../container-registry/operations/scanning-docker-image.md) может быть частью решения, но порог допуска и срок исправления уязвимостей определяет организация. Сканирование образа не заменяет проверку модельного комплекта и данных.

{#ai-rel1-check}

**Проверка**

По продуктивной ревизии восстановите все перечисленные версии и решение о допуске. Требование выполнено, если набор однозначен, воспроизводим и совпадает с проверенным. Тег `latest` или неподтвержденное расхождение фактической ревизии с манифестом означает невыполнение.

{#ai-rel1-artifacts}

**Артефакт**

* Решение о выпуске.
* Сопоставление с продуктивной ревизией.
* Хеш манифеста выпуска.
* Событие развертывания.

### Замена, откат и отзыв версии управляются явно {#version-managed-explicitly}

{#ai-rel2-id}

Идентификатор требования: `AI-REL2`

{#ai-rel2-requirement}

**Требование**

Для модели, индекса и связанной конфигурации должны быть определены совместимость, порядок поэтапной замены, критерии отката, предыдущий безопасный совместимый комплект и способ отзыва небезопасной версии. Откат не должен возвращать известную уязвимость, запрещенные данные или отозванный секрет. Отзыв охватывает все продуктивные эндпоинты, псевдонимы, прямые ссылки и обходные пути, через которые версия могла быть выбрана.

{#ai-rel2-implementation}

**Реализация**

Средства конкретного сервиса используются только в их документированной области: ревизии и события развертывания и отката Serverless Containers из [справочника Audit Trails](../../serverless-containers/at-ref.md), [версии объектов Object Storage](../../storage/operations/buckets/versioning.md) или собственная схема версий приложения. Наличие истории объектов не гарантирует работоспособный откат всей ИИ-системы.

Цель отката фиксируется по среде: для бессерверных сред — предыдущая проверенная ревизия или версия; для Kubernetes — предыдущий образ и конфигурация; для Compute Cloud — план восстановления образа, диска и конфигурации; для RAG — предыдущий манифест корпуса или индекса либо процедура перестроения; для AI Studio — предыдущая конфигурация экземпляра, Guardrail и индекса.

До выпуска проверяется обратная совместимость данных и индекса. Ссылка на «предыдущую версию» без идентификатора и проверенной совместимости планом отката не считается.

{#ai-rel2-check}

**Проверка**

На тестовой среде выполните замену и откат связанного комплекта.

1. Проверьте, что активная версия наблюдаема, журнал связывает инициатора и изменение, а отозванная версия не может быть выбрана обычным путем.
1. Репетиция отката включает переключение на предыдущую цель, функциональные проверки и проверки безопасности; возврат к новой версии выполняется только после согласования.

Откат, раскрывающий данные более нового состояния, не засчитывается.

{#ai-rel2-artifacts}

**Артефакт**

* Тест замены и отката.
* Журнал инициатора.
* Недоступность отозванной версии.
* Идентификаторы целей отката.
* Согласование возврата.