Данные, закон и data residency

Три слова, которые путают

• data residency (место нахождения данных) — где физически хранятся и обрабатываются данные: например, только в облачном регионе ОАЭ или ЕС. Часто это требование регулятора или договора с клиентом.
• data localisation (локализация) — требование закона держать данные или их копию внутри страны.
• cross-border transfer (трансграничная передача) — любая отправка данных в другую юрисдикцию, в том числе запрос к модели, которая считает ответ в другой стране.

Для LLM-системы важно, что копия данных появляется в нескольких местах. Запрос уходит на inference (вычисление ответа модели). Logs и traces (полная запись шагов агента) хранят текст разговора. Judge читает эти traces при оценке. Eval dataset (набор для оценки) собран из реальных разговоров. Fine-tuning (дообучение) впитывает данные в веса. Каждое место — отдельный вопрос «где и кто имеет доступ».

Общий закон и отраслевые правила

Пример ЕС. GDPR (общий регламент ЕС о защите данных) разрешает передачу персональных данных за пределы ЕС через три основных механизма: adequacy decision (решение Еврокомиссии, что в стране достаточная защита), standard contractual clauses (SCC, типовые договорные условия) и binding corporate rules (BCR, обязательные внутренние правила группы компаний).

Пример ОАЭ. Federal Decree-Law 45/2021 о персональных данных (PDPL) вступил в силу 2 января 2022 года, по обзору Clyde & Co; детали задают исполнительные регламенты, поэтому актуальность проверяй. Основа закона: согласие — opt-in (явное «да»), основания «legitimate interests» (законный интерес), как в GDPR, нет; передача за рубеж — в страны с adequate protection, иначе узкие исключения (исполнение договора, судебные требования, явное согласие). Главное для инженера — исключения из сферы закона: государственные данные, медицинские данные со своим законом, свободные зоны DIFC и ADGM со своими законами и banking data, для которой есть собственное регулирование. То есть для банка главными часто оказываются правила центрального банка, а не общий закон. Правильный ход на работе — спросить compliance, какой режим применим, а не угадывать.

Классы данных и маршрут в коде

Data classification (классификация данных) — основа всех решений. Пример таблицы для банка:

PII (personally identifiable information) — данные, по которым можно узнать человека. Маршрут выбирает код в LLM gateway (шлюзе перед моделями) по классу данных, а не пользователь и не модель. Prompt «не отправляй персональные данные» — совет; правило в gateway — гарантия.

Облако: где на самом деле считается ответ

Регион облака на бумаге ещё не значит, что ответ считается в этом регионе. В Amazon Bedrock есть cross-Region inference (выполнение запроса в другом регионе): geographic profile держит обработку внутри географии (US, EU, APAC), а global profile отправляет запрос в любой коммерческий регион мира и, по документации AWS (открыта 10.10.2026), стоит примерно на 10% дешевле. Журнал CloudTrail записывает такие запросы в исходном регионе, и поле inferenceRegion показывает, где запрос обработали. Набор моделей, доступных внутри конкретного региона, меняется. По проверке документации AWS 08.10.2026 (из исходных материалов курса), в регионе ОАЭ me-central-1 внутри региона были только Amazon Nova Pro и Nova Lite, а остальные модели — через global cross-Region inference. Отсюда правило: проверять документацию в день решения и записывать дату.

Варианты, когда лучшая модель недоступна в нужном регионе: модель, доступная в регионе, после проверки на своих задачах; своя open-weight модель (с открытыми весами) на серверах в регионе; redaction и облако; письменное разрешение compliance. Выбор — компромисс качества, цены и риска, и его записывают.

Redaction — тоже модель, её надо оценивать

Redaction (вырезание PII перед отправкой) — классификатор, а у классификатора есть recall (доля найденных объектов). Пример. На тестовом наборе из 2 000 имён redaction пропустила 30: recall = 1 970 / 2 000 = 98,5%. Если в день идёт 40 000 сообщений, в каждом по одному имени, около 600 имён в день уйдут в облако. Для класса «customer PII только в регионе» это нарушение каждый день.

Поэтому:

• порог recall записывают до теста;
• кроме обычного набора нужен stress corpus (набор трудных случаев): редкие имена, транслитерация, смешение письменностей, имя внутри адреса;
• считают отдельно по языкам и письменностям;
• если порог не пройден, данные идут в модель внутри региона, а не «почти работает».

Тестовый набор выглядит идеальным, пока в нём нет трудных случаев: redaction со 100% на лёгком наборе может провалиться на трудном.

Evals и traces под теми же правилами

Traces с данными клиентов определяют, где можно запускать evals. Judge работает внутри региона или on-premises либо читает traces после redaction с последовательными заменителями: «[CLIENT_A]» и «[CLIENT_B]», чтобы judge отличал данные одного клиента от другого. Доступ к хранилищу traces ограничен, срок хранения записан. Eval datasets из реальных разговоров обезличивают и хранят с data lineage (происхождением каждой записи). Lineage нужна и для прав клиента: если человек требует удалить свои данные, ты должен найти их в наборах для оценки и дообучения, а не гадать.

Отсюда и осторожность с fine-tuning на данных клиентов. Запись из индекса RAG удаляется одной операцией, а то, что модель запомнила при дообучении, из весов точечно не убрать: придётся переобучать без этих данных. Поэтому знания о конкретных клиентах держат в индексе с фильтром доступа, а дообучение делают на обезличенных примерах стиля и формата.