Enrutamiento de API de IA con reconocimiento de retención de datos: aplique políticas de registro, residencia y ZDR en la puerta de enlace

Los equipos de seguridad no sólo necesitan saber qué modelo es más barato, más rápido o más capaz. Necesitan saber si una solicitud específica se puede enviar legal y operativamente a un proveedor, punto final, región, función y modo de registro específicos.

Eso es más difícil de lo que parece. Un modelo puede ser aceptable para el chat interno ordinario, pero no para la PII del cliente. Un proveedor puede ofrecer retención de datos cero para una ruta API, mientras que una función de búsqueda almacena mensajes y resultados durante un período fijo. Una región puede admitir la residencia de almacenamiento, pero no el modo de procesamiento que esperaba. Los registros propiedad del desarrollador pueden ser configurables, mientras que los registros de monitoreo de abuso del proveedor siguen una política diferente.

La respuesta práctica es trasladar las decisiones de retención de las aplicaciones individuales a la puerta de enlace API de IA. La puerta de enlace debe clasificar la solicitud, evaluarla frente a una matriz de capacidades del proveedor, bloquear funciones incompatibles, enrutar solo a perfiles de modelo aprobados y registrar una decisión de política sin almacenar mensajes sin formato de forma predeterminada.

El problema del lector: los términos de privacidad del proveedor no son controles de tiempo de ejecución

La mayoría de los equipos comienzan con una hoja de cálculo o una revisión de seguridad que indica qué proveedores de IA están aprobados. Esto es útil, pero no suficiente para la ruta de producción.

Las aplicaciones toman decisiones en tiempo de ejecución:

• ¿Qué ID de modelo debería gestionar esta solicitud?
• ¿La solicitud debería utilizar bases de búsqueda, carga de archivos, ejecución de código, procesamiento por lotes, almacenamiento en caché de mensajes o conversaciones almacenadas?
• ¿Qué región o punto final debe procesar la solicitud?
• ¿Puede el sistema registrar el mensaje sin formato para la depuración?
• ¿Puede el enrutamiento alternativo enviar la misma solicitud a otro proveedor?

Cada una de esas opciones puede cambiar el perfil de retención. Una solicitud que era compatible en el modo de chat simple puede dejar de ser compatible cuando el desarrollador activa el almacenamiento de conversaciones persistentes o de conexión a tierra. Una regla alternativa diseñada para brindar confiabilidad puede enrutar accidentalmente datos regulados a una ruta de proveedor que no ha sido aprobada para cero retención de datos, residencia de datos o controles de monitoreo de abuso.

Recomendación: trate el comportamiento de retención como una restricción de enrutamiento de primera clase, no como documentación adjunta a una cuenta de proveedor.

Hechos a codificar antes de diseñar políticas

Los términos exactos varían según el proveedor, producto, contrato, región, terminal y función. No confíe en la memoria ni en una revisión única. Cree una matriz de propiedad fuente y actualícela cuando cambien los términos.

Varios documentos actuales de proveedores públicos ilustran por qué esto es necesario:

• OpenAI: la residencia de datos de API está documentada como configurada por el proyecto, y las solicitudes regionales requieren prefijos de dominio específicos de la región. OpenAI también distingue el soporte de almacenamiento del soporte de procesamiento por región y señala requisitos adicionales para regiones fuera de EE. UU. OpenAI afirma que la residencia de datos API fuera de EE. UU. requiere aprobación para controles de monitoreo de abuso y una enmienda de Retención Modificada.
• Anthropic: Anthropic documenta cero retención de datos para casos de uso comercial relacionados con API, aunque señala que algunos productos relacionados o feeds de cumplimiento tienen modelos de retención separados, incluida una retención más prolongada para Activity Feed y transcripciones de sesiones remotas.
• Google Gemini: Los términos de la API de Gemini distinguen los servicios pagos y no pagos. Para servicios no pagos, Google puede utilizar el contenido enviado y las respuestas generadas para mejorar los productos; Para los servicios pagos, Google dice que las indicaciones y respuestas no se utilizan para mejorar los productos. La documentación de Gemini Developer API ZDR dice que los registros de monitoreo de abuso de servicios pagos normalmente retienen mensajes y respuestas durante un período limitado, mientras que los proyectos ZDR aprobados limpian el contenido del usuario y los metadatos identificables antes de iniciar sesión.
• Almacenamiento específico de funciones: la documentación de Gemini indica que Grounding with Google Search y Grounding with Google Maps almacenan indicaciones, información contextual y resultados generados durante 30 días, sin forma de inhabilitar ese almacenamiento cuando se utilizan esas funciones.
• Registros propiedad del desarrollador: La documentación de registro de API de Gemini dice que los registros de API propiedad del desarrollador se pueden conservar hasta 55 días de forma predeterminada para proyectos habilitados para facturación y que los desarrolladores pueden elegir períodos más cortos, como 7, 14 o 28 días.
• Gestión de riesgos: el perfil de IA generativa del NIST recomienda monitorear el contenido generado por IA para detectar riesgos de privacidad y conectar las políticas de IA generativa con los procesos existentes de datos, software, legales, de cumplimiento y de gestión de riesgos.

Estos son datos que se deben verificar con la documentación actual del proveedor antes del lanzamiento. La lección de arquitectura es estable: la retención no es un valor booleano a nivel de proveedor.

Arquitectura: un motor de políticas de puerta de enlace en la ruta de solicitud

Una puerta de enlace con reconocimiento de retención tiene cinco componentes principales:

1. Clasificador de sensibilidad de solicitudes: etiqueta la carga de trabajo antes de enrutarla.
2. Matriz de capacidades del proveedor: describe el proveedor, el modelo, el punto final, la región, la retención, el registro y el comportamiento de las funciones.
3. Reglas de política como código: convierte los requisitos de seguridad en decisiones de permiso, denegación o revisión del tiempo de ejecución.
4. Capa de puerta de características: bloquea las características que cambian la retención a menos que se permita explícitamente.
5. Capa de auditoría y análisis: registra metadatos útiles sin almacenar mensajes sin procesar de forma predeterminada.

La puerta de enlace no necesita comprender todos los matices legales. Debe hacer cumplir las decisiones que sus equipos legales, de seguridad, de cumplimiento y de plataforma han aprobado.

Paso 1: clasificar la sensibilidad de las solicitudes antes de seleccionar un modelo

Comience con una pequeña taxonomía de clasificación. Debería ser lo suficientemente simple para que lo utilicen los desarrolladores, pero lo suficientemente expresivo para impulsar políticas.

Ejemplos de etiquetas de confidencialidad:

• público: documentación pública, texto de marketing, contenido del sitio web público.
• interna: información no pública de la empresa con baja sensibilidad.
• confidencial: estrategia, contratos, contexto del cliente, detalles del producto inéditos.
• customer_pii: nombres, correos electrónicos, direcciones, identificadores de cuenta, transcripciones de soporte.
• regulados: datos protegidos de atención médica, financieros, legales, educativos o específicos de una jurisdicción.
• código_fuente: código propietario, configuración, archivos de arquitectura.
• credenciales: secretos, tokens, contraseñas, claves privadas. En la mayoría de los sistemas, esto debería bloquearse, no enrutarse.

La clasificación puede provenir de múltiples fuentes:

• Un encabezado proporcionado por la aplicación, como X-Data-Class: customer_pii.
• Política de inquilinos, según la cual todo el tráfico de un cliente regulado se trata como regulado a menos que una regla aprobada lo rebaje.
• Política de punto final, donde el resumen de tickets de soporte tiene como valor predeterminado customer_pii.
• Análisis ligero de contenido en busca de credenciales, PII obvia o infracciones de políticas.

Recomendación: no dependa exclusivamente de la detección automática. Solicite que las aplicaciones declaren la clase de datos deseada y luego utilice el escaneo para detectar discrepancias obvias o forzar una clase más segura.

Paso 2: crear una matriz de capacidades del proveedor

La matriz de capacidades es la fuente de verdad que evalúa el enrutador. Debe versionarse, revisarse y probarse como la configuración de producción.

Campos de ejemplo:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "proveedor": "proveedor_x",
  "modelo": "modelo grande",
  "api_family": "chat_completions",
  "punto final": "https://eu.example-provider.com/v1",
  "región": "ue",
  "processing_residency": ["ue"],
  "storage_residency": ["ue"],
  "zdr_eligible": verdadero,
  "zdr_contract_required": verdadero,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "retención_modificada_aprobada_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": falso,
  "características_compatibles": {
    "plain_chat": verdadero,
    "transmisión": verdadero,
    "tool_calls": verdadero,
    "search_grounding": falso,
    "maps_grounding": falso,
    "file_upload": falso,
    "lote": falso,
    "conversaciones_almacenadas": falso
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["revisión-de-seguridad-123", "vendor-doc-version-abc"]
}

Utilice perfiles de modelo en lugar de ID de modelo sin formato. Un perfil combina modelo, proveedor, punto final, región, conjunto de características y postura de retención. Los desarrolladores solicitan model_profile: compliant_summarization, no solo model:fast-large-model.

Recomendación: incluir prerrequisitos contractuales en la matriz. Una ruta no está aprobada por ZDR simplemente porque un proveedor ofrece ZDR en algún lugar. Se aprueba solo cuando su cuenta, proyecto, región y punto final cumplen con las condiciones requeridas.

Paso 3: escribir reglas de políticas como código

Las reglas de políticas deben ser explícitas, comprobables y legibles por los equipos de seguridad y plataforma.

Ejemplos de reglas en pseudocódigo:

denegar si data_class == "credenciales"
  motivo "credenciales_no_deben_ser_enviadas_al_modelo"
permitir solo si data_class en ["regulado", "cliente_pii"]
  y perfil.zdr_eligible == verdadero
  y perfil.zdr_contract_required_satisfied == verdadero
  Reason_on_failure "model_profile_not_zdr_eligible"
negar si residency_required == "ue"
  y "eu" no está en perfil.processing_residency
  motivo "región_procesamiento_no_compatible"
negar si clase_datos en ["confidencial", "cliente_pii", "regulado"]y request.raw_prompt_logging == verdadero
  motivo "raw_prompt_logging_not_allowed"
negar si request.features.search_grounding == verdadero
  y Policy.requires_zdr == verdadero
  y perfil.feature_storage.search_grounding_days > 0
  motivo "grounding_requires_retained_content"
negar si fallback_profile.retention_level 

{
  "error": {
    "tipo": "política_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "La búsqueda en tierra no está permitida para cargas de trabajo marcadas como require_zdr porque esta característica del proveedor almacena mensajes, contexto y contenido de salida.",
    "request_id": "req_123",
    "policy_version": "política-de-retención-2026-08-01",
    "acciones_permitidas": [
      "disable_search_grounding",
      "elegir_perfil:zdr_plain_chat",
      "solicitud_excepción"
    ]
  }
}

Los códigos de denegación útiles incluyen:

• model_profile_not_zdr_eligible
• región_procesamiento_no_compatible
• almacenamiento_residencia_no_compatible
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• política_de_retención_debilitada_de_fallback
• contrato_prerrequisito_faltante
• credenciales_detectadas

Paso 7: agregue un flujo de trabajo de excepción, no una derivación oculta

Algunas excepciones son legítimas: respuesta a incidentes, depuración aprobada por el cliente, pruebas de migración o limitación temporal del proveedor. La puerta de enlace debe admitir excepciones sin convertirlas en una política paralela permanente.

Cada excepción debe incluir:

• identidad del aprobador
• equipo o inquilino solicitante
• enlace de ticket o revisión de riesgos
• justificación empresarial
• perfiles y características de modelo permitidos
• clases de datos cubiertas
• fecha de vencimiento
• requisitos de registro adicionales

Recomendación: hacer excepciones más limitadas que la política ordinaria. Evite cambios globales como disable_retention_policy=true. Prefiere anulaciones de ámbito como "permitir el registro de avisos de depuración para el inquilino A, punto final B, durante 24 horas, con redacción y aprobación de seguridad".

Lista de verificación operativa

• Cree una matriz de capacidades de proveedor versionada.
• Asigne un propietario para los términos del proveedor, los requisitos previos del contrato y las revisiones de retención.
• Requerir que las aplicaciones declaren la clase de datos, el requisito de residencia y las características solicitadas.
• Tráfico confidencial y regulado predeterminado sin registro de avisos sin procesar.
• Representar herramientas, conexión a tierra, carga de archivos, lotes y conversaciones almacenadas como indicadores de capacidad separados.
• Ejecutar comprobaciones de políticas antes del enrutamiento principal y antes del enrutamiento alternativo.
• Versión de la política de registro, perfil del modelo, clase de datos, indicadores de características y motivo de denegación.
• Mantenga los metadatos analíticos separados del contenido de mensajes y de salida.
• El representante de pruebas permite y rechaza casos en CI.
• Revise la variación de las políticas cada vez que un proveedor cambie los términos, regiones, puntos finales o características.

Compensaciones para hacer explícitas

El enrutamiento estricto reduce las opciones. Las restricciones de residencia y ZDR pueden impedir el uso del modelo más nuevo, la ruta de menor costo o un punto final con muchas funciones.

El enrutamiento regional puede aumentar la latencia o el costo. Es posible que la región compatible más cercana no admita el modo de procesamiento deseado o que requiera una ruta de proveedor diferente.

Las puertas de funciones sorprenden a los desarrolladores. Un desarrollador puede pensar que solo está habilitando la búsqueda, pero la seguridad detecta un nuevo comportamiento de retención. La documentación y los mensajes de denegación reducen la fricción.

La minimización rápida complica la depuración. Los equipos necesitan muestras redactadas, ventanas de depuración aprobadas por los inquilinos y metadatos sólidos para investigar problemas sin almacenarlo todo.

La matriz requiere mantenimiento. Los términos del proveedor cambian. Lanzamiento de nuevos modelos. Las regiones se expanden. Las funciones pasan de la versión beta a la producción. Una matriz obsoleta es peor que ninguna matriz porque crea una confianza falsa.

¿Qué es una recomendación y qué es una predicción?

Recomendaciones: imponer la retención en la puerta de enlace, clasificar las solicitudes antes de enrutarlas, crear una matriz de capacidades del proveedor, bloquear las funciones que cambian la retención por política, evitar el registro de avisos sin formato de forma predeterminada y versionar cada decisión de política.

Predicción: Los equipos de plataformas de IA tratarán cada vez más la postura de privacidad como parte de la selección del modelo. En lugar de preguntar "¿qué modelo deberíamos utilizar?" las aplicaciones solicitarán un perfil de modelo que satisfaga las restricciones de capacidad, costo, latencia, residencia y retención.

Predicción: las características de privacidad específicas del proveedor seguirán divergiendo. Las puertas de enlace que normalicen únicamente los formatos de solicitud y respuesta no serán suficientes; los equipos de producción también necesitarán una normalización de políticas.

Conclusión procesable

El enrutamiento basado en la retención de datos no es un panel de cumplimiento independiente. Pertenece a la ruta de solicitud.

Comience con tres entregables: una taxonomía de sensibilidad de solicitudes, una matriz de capacidades de proveedores versionada y un pequeño conjunto de reglas de políticas como código para ZDR, residencia, registro sin procesar, respaldo y funciones de cambio de retención. Luego, haga que la puerta de enlace devuelva razones de denegación claras y conserve los análisis sin almacenar contenido sin procesar de forma predeterminada.

Ese diseño centraliza decisiones que de otro modo estarían dispersas entre las opciones del SDK, las variables de entorno, las consolas de los proveedores y las convenciones específicas del equipo. También brinda a los equipos de seguridad y plataforma una pista de auditoría práctica: qué solicitud se permitió, qué versión de política se aplicó, qué perfil de modelo se seleccionó y por qué.

Lectura relacionada

• registro rápido seguro y uso a nivel de puerta de enlace Analytics
• creación de una matriz de capacidades del proveedor durante una migración de API compatible con OpenAI
• herramientas de agentes de gobierno con alcances, aprobaciones y pistas de auditoría