Локальный шлюз не гарантирует суверенитет данных

Локальный API-шлюз дает контроль над входом в систему, но сам по себе не сохраняет суверенитет данных. Если шлюз отправляет промпт зарубежному провайдеру, текст покидает локальный контур хотя бы на время обработки. Утверждение «данные остаются у нас» в такой схеме ложно, даже когда провайдер обещает ничего не хранить.

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

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

Шлюз контролирует маршрут, а не всю обработку

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

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

В обычном запросе приложение устанавливает TLS-соединение со шлюзом внутри Казахстана. Шлюз аутентифицирует клиента, применяет лимит, иногда маскирует поля, затем открывает второе TLS-соединение с провайдером. Шифрование защищает оба канала в пути. На каждой конечной точке текст расшифровывается для обработки. Поэтому фраза «все зашифровано» не доказывает, что зарубежная сторона не видела промпт.

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

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

У запроса есть четыре разных потока

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

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

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

Телеметрия живет в балансировщиках, WAF, APM, трассировке, счетчиках затрат и системах обнаружения злоупотреблений. Шлюз может не писать промпты, пока библиотека наблюдаемости автоматически сохраняет тело HTTP-запроса при ошибке. Именно так аккуратная политика приложения проигрывает настройке агента, которую никто не включал в схему данных.

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

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

Зарубежная генерация всегда пересекает границу

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

Закон Республики Казахстан «О персональных данных и их защите» отдельно определяет накопление, хранение, использование, распространение, обезличивание и обработку. Для архитектурного решения это важное различие: отсутствие накопления у провайдера не означает отсутствия обработки. Юристы должны определить правовое основание и условия передачи для конкретного набора данных, а инженеры должны дать им точную схему вместо обещания «у нас локальный endpoint».

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

Не полагайтесь на общий текст страницы конфиденциальности. Проверяйте условия конкретного сервиса, модели, тарифа и функции. Документация Google Cloud по zero data retention, например, отдельно описывает журналирование промптов для контроля злоупотреблений, кэш в памяти и функции grounding, для которых действуют свои сроки. Документация Microsoft по Azure Direct Models отдельно объясняет автоматический анализ, возможное хранение выбранных промптов для проверки человеком и режим измененного мониторинга для одобренных клиентов. Я согласен с таким разбиением: обещание на уровне бренда слишком грубое для архитектурного контроля.

Допустимая передача и локальная обработка остаются разными статусами. В реестре решения так и пишите: external_processing: approved, а не data_stays_local: true. Второе утверждение не становится верным после подписи договора.

Маскирование снижает объем передачи, но не меняет географию

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

Представьте обращение: «Подготовь ответ главному врачу районной больницы по осложнению после редкой операции 12 мая; пациенту 14 лет». Удаление имени и ИИН не делает текст безличным. Должность адресата, учреждение, дата, возраст и редкое событие образуют квазиидентификаторы. Модель все еще обрабатывает сведения, связанные с узким кругом людей.

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

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

Некоторые задачи теряют смысл после маскирования. Модель не сможет точно проверить договор, если связи между сторонами и суммами разрушены. В таком случае честных вариантов два: запустить подходящую модель в локальном контуре или не применять LLM к этому классу данных. Совет «просто анонимизируйте все» популярен, потому что обещает сохранить один маршрут. Он неверен там, где контекст нужен для результата или повторная идентификация остается возможной.

Политика провайдера должна стать машинным правилом

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

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

data_classes:
  public:
    allowed_routes: [external, local]
  internal:
    allowed_routes: [external_zdr, local]
    require_redaction: true
  restricted:
    allowed_routes: [local]

routes:
  external_zdr:
    region_allowlist: [approved-region]
    prompt_retention: none
    training_use: disabled
    human_review: disabled
    fallback: deny
  local:
    processing_country: KZ
    fallback: deny

Поле prompt_retention: none нельзя заполнять со слов менеджера по продажам. Приложите версию условий, дату проверки, перечень исключений и доказательство активированной настройки. Если нулевое хранение требует отдельного одобрения или отключения функции, статус должен оставаться pending, пока команда не увидит подтверждение в панели или API управления.

Отдельно проверьте обучение, контроль злоупотреблений, человеческий просмотр, поддержку, кэширование и сохранение состояния диалога. Запрет обучения не запрещает журнал безопасности. Нулевой срок для базового inference может не действовать на batch, assistants, grounding, файлы или fine-tuning. Одинаковое имя модели через двух посредников также не означает одинаковые условия.

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

Резервный маршрут чаще всего ломает обещание

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

Разберите отказ по времени. Приложение отправляет запрос локальной модели. Она отвечает медленно, клиентская библиотека решает, что произошел timeout, хотя сервер продолжает вычисление. Шлюз повторяет тот же промпт у внешнего провайдера. Теперь две модели обработали данные, а локальный ответ может позднее попасть в журнал как «неизвестная ошибка». Если ретраи не имеют общего идентификатора, аудит увидит два несвязанных события.

У такого сбоя четыре неприятных последствия. Команда теряет однозначный список получателей. Один запрос порождает несколько копий. Биллинг и метрики перестают показывать реальную причину. Пользователь не знает, что режим обработки изменился. Все это происходит без изменения клиентского кода.

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

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

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

Аудиту нужны события, а не скриншоты

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

Записывайте событие решения без содержимого промпта. Такой JSON можно отправлять в локальное неизменяемое хранилище и связывать с журналом приложения:

{
  "request_id": "01J...",
  "data_class": "restricted",
  "policy_version": "2026-07-27.3",
  "route": "local-qwen",
  "processing_country": "KZ",
  "content_logged": false,
  "fallback": "deny",
  "decision": "allow",
  "reason": "class_route_match"
}

У отказа должна быть такая же форма с decision: "deny" и конкретной причиной. Тогда тест аудита выглядит как запрос к событиям, а не как разговор с владельцем платформы. Например: найти все события класса restricted, где страна не KZ, маршрут начинается с external или версия политики отсутствует. Ожидаемый результат для утверждения «закрытые данные не покидают страну» равен нулю строк.

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

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

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

Допустимость зависит от класса данных и цели

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

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

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

Закрытые данные отправляйте только в маршрут, прямо разрешенный политикой. Если правило требует обработки в Казахстане, модель должна исполняться в Казахстане, а ее журналы, кэши, резервные копии и административный доступ должны соответствовать тому же решению. Локальный шлюз перед внешним inference этого требования не выполняет.

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

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

Субобработчики расширяют границу доступа

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

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

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

Нарисуйте цепочку как последовательность доверия: приложение, локальный шлюз, посредник маршрутизации, endpoint провайдера, фильтр, модель, журнал безопасности, резервная система, поддержка. Для каждого перехода укажите открытый текст, псевдонимизированный текст, метаданные или агрегат. Эта отметка важнее юридического названия роли. Компания, которая получает request ID, не равна компании, инженер которой может открыть сохраненный промпт по этому ID.

Поддержка создает отдельный путь, которого нет в штатном сетевом потоке. Разработчик получает ошибку, копирует промпт в тикет, прикладывает трассировку и тем самым отправляет данные в систему с другим регионом и сроком хранения. Запретите содержательные примеры в тикетах для закрытых классов. Для диагностики передавайте request ID, код ошибки, версию маршрута и синтетический пример. Если провайдеру нужен реальный payload, оформляйте это как отдельную передачу с владельцем, сроком и подтвержденным удалением.

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

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

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

Суверенитет проверяется сменой модели

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

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

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

AI Router позволяет разделить такие маршруты через один OpenAI-совместимый endpoint: внешние модели использовать для разрешенных классов, а open-weight модели на собственной GPU-инфраструктуре в Казахстане назначить данным, которым нужна локальная обработка. Маскирование PII, аудит-логи и лимиты на уровне ключа помогают исполнять политику, но классификацию и допустимые маршруты организация все равно должна определить сама.

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

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