Маршрутизация AI API с учетом сохранения данных: применение политик ZDR, резидентности и журналирования на шлюзе

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

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

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

Проблема читателя: условия конфиденциальности поставщика не регулируют время выполнения

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

Приложения делают выбор во время выполнения:

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

Рекомендация: рассматривайте поведение хранения как первоклассное ограничение маршрутизации, а не как документацию, прикрепленную к учетной записи поставщика.

Факты, которые необходимо закодировать перед разработкой политики

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

Несколько текущих документов общедоступных поставщиков иллюстрируют, почему это необходимо:

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

Архитектура: механизм политики шлюза в пути запроса

Шлюз с поддержкой хранения состоит из пяти основных компонентов:

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

Шаг 1. Классифицируйте чувствительность запроса перед выбором модели

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

Пример меток конфиденциальности:

Классификация может происходить из нескольких источников:

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

Шаг 2: постройте матрицу возможностей поставщика

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

Примеры полей:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "провайдер": "provider_x",
  "модель": "модель-большая",
  "api_family": "chat_completions",
  "конечная точка": "https://eu.example-provider.com/v1",
  "регион": "ЕС",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": правда,
  «zdr_contract_required»: правда,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  «raw_prompt_logging_allowed»: ложь,
  "поддерживаемые_функции": {
    "plain_chat": правда,
    "потоковая передача": правда,
    «tool_calls»: правда,
    «search_grounding»: ложь,
    «maps_grounding»: ложь,
    «file_upload»: ложь,
    «партия»: ложь,
    "stored_conversations": ложь
  },
  "last_reviewed": "01.08.2026",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]

Используйте профили моделей, а не необработанные идентификаторы моделей. Профиль объединяет модель, поставщика, конечную точку, регион, набор функций и состояние хранения. Разработчики запрашивают model_profile: совместимое_суммирование, а не просто model: fast-large-model.

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

Шаг 3: напишите правила политики как кода

Правила политики должны быть явными, проверяемыми и понятными для специалистов по безопасности и платформе.

Пример правил в псевдокоде:

запретить, если data_class == "учетные данные"
  причина "credentials_must_not_be_sent_to_model"
разрешить, только если data_class в ["regulated", "customer_pii"]
  и профиль.zdr_eligible == true
  и Profile.zdr_contract_required_satisfied == true
  Reason_on_failure "model_profile_not_zdr_eligible"
отклонить, если residency_required == "eu"
  и "eu" нет в профиле.processing_residency
  причина «region_processing_not_supported»
запретить, если data_class в ["конфиденциально", "customer_pii", "регулируется"]и request.raw_prompt_logging == true
  причина "raw_prompt_logging_not_allowed"
отклонить, если request.features.search_grounding == true
  и policy.requires_zdr == true
  и Profile.feature_storage.search_grounding_days > 0
  причина "grounding_requires_retained_content"
отклонить, если Fallback_profile.retention_level < первичного_профиля.retention_level
  причина "fallback_weakens_retention_policy"

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

Шаг 4. Рассматривайте инструменты и функции как возможности изменения удержания

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

Назначьте каждой функции свои собственные флаги политики:

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

Шаг 5. Сохраните аналитику без хранения необработанных подсказок

Маршрутизация с учетом хранения не должна ослеплять команду платформы. Вы можете сохранить полезную аналитику использования ИИ, минимизируя при этом хранение контента

Безопасные поля телеметрии по умолчанию:

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

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

Шаг 6. Укажите действенные причины отказа

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

Пример ответа:

{
  "ошибка": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Заземление поиска не разрешено для рабочих нагрузок с пометкой require_zdr, поскольку эта функция поставщика хранит приглашение, контекст и выходной контент.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "разрешенные_действия": [
      "disable_search_grounding",
      "выберите_профиль:zdr_plain_chat",
      "запрос_исключение"
    ]
  }

Полезные коды отказа включают:

Шаг 7: добавьте рабочий процесс исключения, а не скрытый обход

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

Каждое исключение должно включать:

Рекомендация: делайте исключения более узкими, чем обычные правила. Избегайте глобальных переключателей, таких как disable_retention_policy=true. Предпочитайте переопределения с ограниченной областью, такие как «разрешить ведение журнала подсказок отладки для клиента A, конечной точки B, в течение 24 часов с редактированием и утверждением безопасности».

План действий

Компромиссы, которые следует четко обозначить

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

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

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

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

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

Что такое рекомендация и что такое прогноз?

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

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

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

Практическое заключение

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

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

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

Связанное чтение

• безопасное ведение журнала подсказок и использование на уровне шлюза аналитика
• построение матрицы возможностей поставщика во время миграции API, совместимого с OpenAI
• управление инструментами агента с помощью областей действия, утверждений и журналов аудита