Соответствие требованиям и обработка персональных и регулируемых данных
Раздел устанавливает технические требования к реализации утвержденного правового решения и решения о соответствии требованиям для AI-сценария; он не определяет правовое основание обработки, допустимых получателей, сроки хранения или правовую квалификацию трансграничной передачи.
Возможности Yandex Cloud, включая выбор региона, шифрование, DSPM, IAM и журналы аудита, являются техническими мерами и не заменяют оценку конкретной обработки уполномоченными представителями организации, отвечающими за правовые вопросы или соответствие требованиям.
Под регулируемыми данными далее понимаются ПДн, коммерческая тайна, банковская тайна, платежные данные и иные категории, для которых применимое право, договор либо внутренняя политика устанавливают особый режим обработки.
Правовое решение и размещение
Утвержденная допустимость обработки
Идентификатор требования: AI-COMPLY1
Риск
Запуск AI-сценария без установленных правовых, организационных и технических условий обработки ПДн или иных регулируемых данных может привести к нарушению законодательства, договорных обязательств и внутренних политик.
Требование
До передачи регулируемых данных в модель, RAG-базу, векторный индекс, журнал, резервную копию, внешний API или иной компонент уполномоченная сторона организации должна определить, документировать и утвердить:
- цель, правовое основание и допустимые операции обработки;
- категории субъектов, категории данных и минимально необходимый состав полей;
- роли организации, Yandex Cloud, внешних поставщиков, операторов и иных получателей;
- допустимые места обработки и хранения, требования локализации и трансграничной передачи;
- условия поручения обработки, применимые договорные обязательства и использование субподрядчиков;
- сроки хранения, удаления, уничтожения, архивирования и резервного копирования;
- требования к защите, журналированию, реагированию на инциденты и реализации прав субъектов данных;
- особенности данных, используемых для обучения, дообучения, оценки, эксплуатации модели или наполнения RAG-базы.
Решение связывается с версионированной карточкой обработки, в которой указаны цель, классы данных, источник, операции, точные ресурсы и регион Yandex Cloud, модель и поставщик, получатели, хранение, технические меры и орган, принявший решение; карточка связывается с потоками данных из AI-SDLC1. Для продуктивного сценария обработки результат N/A не допускается.
Реализация
Когда клиент размещает ПДн в Yandex Cloud и выступает оператором, он поручает провайдеру обработку таких ПДн в рамках применимой договорной модели; сведения о мерах и подтверждениях Yandex Cloud приведены в документации о соответствии требованиям, но она не заменяет оценку конкретной системы клиента. Запись правового решения находится вне конфигурации сервисов Yandex Cloud; конфигурация подтверждает фактическую реализацию, но не устанавливает правовое основание.
Рекомендация
Проводить оценку конфиденциальности и соответствия требованиям до подключения модели, внешнего API, RAG-контура, обучения или дообучения модели, а также до существенного изменения состава данных, получателя, региона, эндпоинта или архитектуры.
Ручная проверка
- Сопоставьте утвержденное решение с фактическими полями, субъектами, моделями, журналами, индексами и получателями.
- Проверьте, что каждый тип регулируемых данных, каждый сценарий и каждый получатель явно охвачены решением.
- Не допускайте обработки неописанного типа данных или передачи неописанному получателю до пересмотра и утверждения решения.
- Выберите фактическое поле ресурса, журнала или запроса и проследите его до утвержденной карточки обработки; просроченное решение означает невыполнение.
Артефакт
- Утвержденное правовое решение и решение о соответствии требованиям.
- Реестр AI-сценариев.
- Диаграмма потоков данных.
- Описание архитектуры.
- Перечень обработчиков и получателей.
- Договорные ссылки.
- Записи о пересмотре решения.
- Идентификаторы потоков и ресурсов.
- Пример трассировки без реальных персональных данных.
Ограничения размещения реализованы в архитектуре
Идентификатор требования: AI-COMPLY2
Риск
Размещение ПДн или иных регулируемых данных в компонентах, не соответствующих требованиям к локализации, региону, защите либо срокам хранения, создает риск неправомерной обработки и неучтенных копий данных.
Требование
Организация должна определить и поддерживать актуальную карту жизненного цикла регулируемых данных для AI-сценария: получение, передача, хранение, резервное копирование, кеширование, журналирование, индексация, векторизация, инференс, обучение, дообучение, техническая поддержка и удаление.
Для каждого компонента, который способен обрабатывать регулируемые данные, должны быть определены:
- допустимость использования и категория данных;
- облако, каталог, регион, зона доступности или внешнее местоположение;
- владелец ресурса и владелец данных;
- срок и способ хранения, удаления, уничтожения и контроля резервных копий;
- применяемые меры защиты;
- входящие и исходящие потоки данных, включая внешние конечные точки.
Инвентаризация охватывает каждую копию данных, включая экспорт; разрешенные сервисы и регионы применяются превентивно в политике создания ресурсов и выпуска.
Реализация
Регион Yandex Cloud — это географическая область, объединяющая зоны доступности; он имеет собственную инфраструктуру и набор сервисов. Выбор региона сам по себе не подтверждает выполнение юридических требований и не описывает передачу данных во внешние системы. Место обработки не выводится только из каталога ресурса; для обработки у внешнего поставщика нужны его документированные сведения.
Рекомендация
Включать в реестр компонентов как минимум Object Storage, Yandex Managed Service for PostgreSQL или иные БД, диски виртуальных машин, очереди, кеши, Cloud Logging, Audit Trails, RAG-индексы, векторные БД, средства наблюдаемости, рабочие станции администраторов и внешние AI API.
Проверка
- Проследите за синтетическим регулируемым объектом от точки получения до всех копий и получателей.
- Сопоставьте регион и фактическое местоположение каждого облачного ресурса с утвержденным решением.
- Проверьте резервные копии, журналы, индексы, кеши и рабочие данные на наличие неучтенных копий.
- Любая неучтенная копия, внешний маршрут или смена региона должны блокировать ввод изменения в эксплуатацию до обновления решения.
- В отрицательном тесте развертывание или экспорт в запрещенную ветвь блокируется.
Артефакт
- Карта потоков данных.
- Реестр компонентов.
- Инвентаризация ресурсов Yandex Cloud.
- Конфигурация регионов и каталогов.
- Политики хранения.
- Доказательства удаления.
- Результаты архитектурного ревью.
- Выгрузки ресурсов.
- Запись о миграции или удалении.
Внешние получатели и трансграничные потоки
Передача внешнему получателю разрешена и ограничена
Идентификатор требования: AI-COMPLY3
Риск
Передача ПДн или иной конфиденциальной информации во внешнюю модель, API, SaaS-инструмент или иному поставщику без оценки допустимости может нарушить правовые требования, договорные обязательства и политики организации.
Требование
Для каждого внешнего получателя организация должна до начала передачи документировать:
- получателя, его юрисдикцию и допустимые субподрядные организации;
- цель, категории, состав и предельно допустимый объем передаваемых данных;
- разрешенные эндпоинты, доменные имена, IP-адреса и рабочую идентичность отправителя;
- регион обработки, хранения и резервного копирования, если он определен поставщиком;
- условия поручения обработки, трансграничной передачи, хранения, удаления и прекращения обработки;
- срок действия решения и обстоятельства, требующие его повторного рассмотрения.
Приложение или централизованный AI Gateway должны передавать только утвержденные данные на проверенный эндпоинт. Изменение получателя, эндпоинта, региона обработки, состава полей, условий поставщика или субподрядчика требует повторной оценки.
Реализация
Таблицы маршрутизации VPC позволяют направлять трафик подсети через заданный next hop, но сами по себе не подтверждают допустимость передачи, фильтрацию по содержимому либо контроль получателя на прикладном уровне.
Рекомендация
Использовать централизованный слой интеграции с AI-сервисами для аутентификации рабочей нагрузки, управления списком разрешенных получателей, минимизации полей, преобразования PII, регистрации метаданных запросов и блокирования неразрешенных направлений. Не записывать полное содержимое регулируемых запросов и ответов в технические журналы без отдельного обоснования и мер защиты.
Проверка
- Сопоставьте утвержденный реестр внешних получателей с конфигурацией приложений, DNS, TLS-соединений, VPC-маршрутов и исходящих сетевых трассировок.
- Выполните тест разрешенной передачи на утвержденный эндпоинт.
- Выполните попытку отправить запрещенное поле либо направить запрос на неутвержденный эндпоинт.
- Запрещенная передача должна быть остановлена до выхода данных из доверенного контура.
- Попытка перенаправления на неутвержденный адрес блокируется; запрещенный вызов отсутствует в журнале исходящего трафика и в трассировке провайдера.
Артефакт
- Оценка передачи данных.
- Реестр получателей и эндпоинтов.
- Договорные документы или ссылки на них.
- Конфигурация AI Gateway.
- Сетевые политики.
- Журналы блокировок и результаты тестирования.
- Идентификатор секрета.
- Свидетельства провайдера.
Трансграничный поток разрешен отдельным решением
Идентификатор требования: AI-COMPLY4
Применимость
Требование применяется, если данные, резервная копия, журнал, запрос к модели, результат модели либо иной компонент потока могут пересечь границу, определенную применимым правом или внутренней политикой размещения.
Риск
Трансграничная передача без выполнения применимых процедур, уведомлений, договорных и организационных требований может повлечь нарушение законодательства и меры со стороны регулятора.
Требование
До запуска трансграничного потока уполномоченные представители организации, отвечающие за правовые вопросы или соответствие требованиям, должны определить и утвердить:
- наличие трансграничной передачи в конкретном сценарии;
- страны, получателей, субподрядчиков и конечные точки;
- категории, состав, цель и правовое основание передачи;
- применимые запреты, ограничения, согласования, уведомления и договорные условия;
- требования к защите, срокам хранения, удалению и реализации прав субъектов;
- срок действия решения и события, требующие его повторного пересмотра.
Техническая команда должна следовать решению уполномоченных представителей и сопоставить его с ресурсами, маршрутами и эндпоинтом из AI-COMPLY2 и AI-COMPLY3. Наличие TLS, выбор региона или договор, не рассмотренный уполномоченными представителями, не являются самостоятельным подтверждением правовой допустимости.
Для каждого потока указываются отправитель и получатель, поля и класс данных, места источника и назначения, транспорт, хранение и дальнейшая передача и идентификатор решения. При создании ресурсов и на исходящем трафике применяются списки разрешенных получателей и мест с запретом по умолчанию; неизвестный или измененный эндпоинт, регион или получатель блокируется.
Внутренний поток через границу сам по себе не является правовым выводом о трансграничной передаче.
Проверка
- Выберите один внешний поток и сопоставьте страну, получателя, категории данных, эндпоинт, субподрядчиков и срок с действующим решением.
- Проверьте, что изменение региона поставщика, назначения, субподрядчика или состава данных блокирует поток до повторного решения, если прежнее решение этого не охватывает.
- Убедитесь, что сведения о трансграничном потоке согласованы с архитектурной картой и реестром получателей.
- При неизвестном месте обработки или последующем получателе поток останавливается до получения авторитетных сведений; предположения не делаются.
Артефакт
- Правовая оценка и оценка соответствия требованиям.
- Подтверждения необходимых процедур.
- Реестр трансграничных потоков.
- Архитектурная схема.
- Конфигурация эндпоинта и журнал изменений.
- Реестр потоков с идентификаторами решений.
- Отказ неизвестного ребра.
Обезличивание, псевдонимизация и маскирование ПДн
Преобразование регулируемых данных снижает объем идентифицирующей информации, передаваемой модели или внешнему компоненту, до минимально необходимого для сценария. Метод выбирают с учетом необходимости сохранить структуру, связи между записями, возможность восстановления значения и риска повторной идентификации.
Ниже приведен технический глоссарий используемых в стандарте терминов. Он не является юридическим определением и не заменяет оценку уполномоченных представителей.
- Маскирование — скрытие либо замена части значения, например
+7 *** ***-12-34или[USER_NAME]; формат или часть значения могут сохраниться. - Псевдонимизация — замена значения псевдонимом или кодом; обратное преобразование возможно при доступе к ключу, таблице соответствия или сервису детокенизации.
- Токенизация — контролируемая замена значения токеном, обычно когда приложению требуется восстановить значение после обработки моделью.
- Хеширование — получение производного значения; его устойчивость зависит от энтропии исходных данных, соли, секрета и риска перебора.
- Агрегация — замена детальных данных групповыми или статистическими значениями.
- Анонимизация — преобразование, при котором не предусмотрен штатный путь восстановления личности из передаваемого набора; достаточность оценивают для конкретного набора и риска сопоставления.
Защитное преобразование выполняется до границы доверия
Идентификатор требования: AI-COMPLY-PII1
Риск
Передача в LLM или внешний AI-сервис ПДн, которые не нужны для выполнения задачи, увеличивает риск утечки и нарушения требований к обработке данных.
Требование
Если утвержденное решение требует преобразования, организация должна выполнять обнаружение и преобразование PII до передачи данных в ту часть модельного, облачного или внешнего контура, которая не вправе видеть исходные значения.
Для каждого сценария должны быть определены:
- поля и категории данных, подлежащие обнаружению и преобразованию;
- алгоритм, точка выполнения и версия политики;
- допустимость обратимости;
- ключи, таблицы соответствия и порядок детокенизации;
- субъекты с правом на обратное преобразование;
- безопасное поведение при ошибке либо недоступности преобразователя.
Если восстановление не требуется, применяются необратимые или практически необратимые для сценария методы. Если восстановление необходимо, допускаются псевдонимизация или токенизация при условии, что восстановление выполняется в контролируемом контуре организации.
Если модели требуются только статистические свойства, применяются агрегация или иное снижение детализации. Хеширование допускается только после оценки риска перебора, сопоставления и повторной идентификации.
Преобразователь размещается перед первой запрещенной границей; сначала выполняется минимизация, затем выбранное преобразование, а валидатор отклоняет остаточные запрещенные поля.
Реализация
Для хранения секретов можно использовать Lockbox, а для управления ключами шифрования — KMS; выбор и интеграция средств должны соответствовать утвержденной архитектуре. KMS и Lockbox защищают ключи и таблицы соответствия, но шифрование само по себе не является анонимизацией; KMS, DSPM и Guardrails сами по себе не являются преобразованием.
Рекомендация
Применять семантически понятные токены, например [USER_NAME], [PHONE] и [ORDER_ID], если они сохраняют смысл запроса и не раскрывают исходное значение.
Проверка
- На синтетической записи проследите исходное поле, результат преобразования, модельный запрос и журналы.
- Подтвердите, что исходное значение не пересекает установленную границу доверия.
- Проверьте, что обратное преобразование доступно только утвержденному субъекту и фиксируется без записи исходного значения в журнал.
- Подайте ввод с остаточным запрещенным полем и смоделируйте недоступность преобразователя: последующий вызов за границу не должен состояться.
- Подтвердите отсутствие исходных значений за границей по журналам и трассировке.
Артефакт
- Политики преобразования.
- Конфигурация gateway или приложения.
- Реестр токенов и ключей без раскрытия значений.
- Результаты тестов.
- Модель разграничения доступа.
- Тип и версия преобразования.
- Подтверждение отсутствия данных за границей.
Средства обнаружения ПДн соответствуют данным и риску
Идентификатор требования: AI-COMPLY-PII4
Риск
Неподходящие средства обнаружения ПДн могут пропускать чувствительные данные при передаче запросов в LLM или сохранять их в индексах, журналах и иных хранилищах.
Требование
Организация должна использовать средства обнаружения, соответствующие составу данных и уровню риска: правила, регулярные выражения, словари, NER-модели, классификаторы, DLP/DSPM-инструменты, AI Gateway или специализированные сервисы токенизации.
Средства обнаружения должны поддерживать:
- контроль ложноположительных и ложноотрицательных срабатываний;
- версионирование правил и управляемое изменение конфигурации;
- тестовые наборы, включающие многоязычный, структурированный и вложенный ввод;
- мониторинг ошибок, обходов и неизвестных типов полей;
- периодическую оценку качества на репрезентативных синтетических или разрешенных тестовых данных.
Пропуски и ложные срабатывания оцениваются отдельно по классу данных, языку, формату и пути; допустимый результат утверждают владельцы политики и правового решения, универсальный порог не задается. Критический пропуск переводит поток в безопасный отказ или карантин. Если детектор не заявлен, это требование допускает N/A, но требования AI-COMPLY-PII1 и AI-COMPLY-PII3 остаются применимыми.
Реализация
Модуль DSPM в Security Deck предназначен для обнаружения чувствительной информации в поддерживаемых источниках; его результаты следует использовать для выявления и контроля данных, но не считать заменой преобразования данных в запросе к модели.
Рекомендация
Включать в тестовые наборы нестандартные формулировки, транслитерацию, вложения, JSON, CSV, документы, OCR-текст, промпт-инъекцию и намеренно поврежденный ввод.
Проверка
- Выполните набор тестов на синтетических данных для всех поддерживаемых категорий ПДн.
- Зафиксируйте точность и полноту или иной утвержденный показатель качества для сценария.
- Проверьте, что изменение правила, классификатора или модели проходит процедуру согласованного изменения.
- Подтвердите, что неизвестный или нераспознанный тип поля не приводит к неконтролируемой передаче исходного значения.
- Известные положительные и отрицательные примеры запускаются при каждом существенном изменении детектора.
Артефакт
- Конфигурации DSPM, DLP, gateway или классификаторов.
- Версии правил.
- Тестовые наборы.
- Результаты оценки качества.
- Заявки и журналы изменений.
- Правила управления тестовым набором.
- Версии детектора.
Преобразование контролируется и не обходится при ошибке
Идентификатор требования: AI-COMPLY-PII3
Применимость
Требование применяется, если для сценария реализуются программное маскирование, токенизация, псевдонимизация, детокенизация или иное защитное преобразование.
Риск
Несанкционированная деанонимизация, подмена правил, компрометация ключей или аварийный обход преобразования могут привести к раскрытию регулируемых данных.
Требование
Доступ к изменению алгоритмов и правил, чтению свидетельств проверки, использованию ключей и таблиц соответствия, а также к обратному преобразованию должен предоставляться по принципу минимально необходимых привилегий и разделения обязанностей.
Событие о маскировании, токенизации, псевдонимизации, детокенизации или ином защитном преобразовании формирует приложение или компонент преобразования. Cloud Logging только принимает это событие. Audit Trails фиксирует опубликованные облачные операции, но не подтверждает выполнение каждой прикладной операции преобразования. Для каждой операции преобразования и обратного преобразования должны фиксироваться:
- время и технический идентификатор запроса;
- компонент, сервисная учетная запись или пользователь;
- идентификатор и версия примененного правила;
- тип операции и технический результат;
- признак ошибки, отказа или явно разрешенного исключения.
Исходные ПДн, ключи и таблицы соответствия не должны включаться в журналы без отдельного обоснования, утверждения и защитных мер.
Ошибка парсера, неизвестное поле, поврежденный ввод или недоступность преобразователя не должны приводить к отправке исходных данных модели внешнему получателю или в технический журнал; допустимое аварийное поведение утверждается вместе с политикой обработки. Последующий вызов модели, RAG, инструмента или журнала должен получать только типизированный успешный результат преобразователя; обход, таймаут, исключение или неверный результат блокируют вызов.
Права на чтение журналов в Cloud Logging и Audit Trails также должны быть ограничены.
Рекомендация
Экспортировать необходимые аудитные события в Yandex SIEM, задавать срок хранения свидетельств, защищать их от несанкционированного изменения и регулярно проверять доступ к ним. Документация Yandex Cloud также рекомендует анализировать Cloud Logging и Audit Trails при расследовании компрометации секретов.
Проверка
- На синтетических данных выполните успешное преобразование, ввод с неизвестным полем, поврежденный объект и недоступность преобразователя.
- Проверьте отказ до пересечения границы доверия во всех сценариях ошибки.
- Проверьте попытку обхода через альтернативный API, очередь, журнал или административный интерфейс.
- Проверьте отказ в обратном преобразовании неуполномоченному субъекту.
- Подтвердите наличие в свидетельствах времени, компонента, версии правила, типа операции и признака ошибки или обхода без исходных значений, ключей и таблиц соответствия.
- Проверьте, что субъект, изменяющий правило, не получает права одновременно выполнять детокенизацию и изменять либо читать свидетельства без отдельного утвержденного исключения.
Артефакт
- IAM-политики и ролевые модели.
- Конфигурация Audit Trails и Cloud Logging.
- Журналы преобразования.
- Журналы отказов.
- Результаты тестов отказоустойчивости.
- Правила хранения и доступа к свидетельствам.
- Схема события.
- Тесты недоступности и обхода.