Conclusiones primero
Cuando las empresas hablan de AI Gateway, el malentendido más común es interpretar que "la solicitud pasa primero por el gateway" significa "los datos nunca salen de la empresa". En realidad, el gateway es solo un punto de control en la cadena de llamadas, no una capa de aislamiento de datos inherente.
Mientras un Provider externo ejecute finalmente la inferencia, el prompt original, la system instruction, los fragmentos de recuperación de RAG, los parámetros de herramientas, los archivos subidos o la salida del modelo pueden ser procesados, almacenados en caché o registrados en alguna capa de la cadena.
Lo que realmente hay que revisar no es "si existe un Gateway", sino "qué puede ver cada capa, si los datos se retienen, si se usan para entrenamiento, si cruzan fronteras, y si los contratos y las auditorías son rastreables".
Al evaluar el riesgo, no se fije solo en "qué modelo se usa", sino en "quién en la cadena tiene la oportunidad de ver sus datos, y durante cuánto tiempo puede conservarlos".
Primero determine: ¿esta llamada es inferencia local?
El primer paso es distinguir si esta llamada realiza la inferencia dentro de un entorno controlado por la empresa. Si tanto el modelo como el servicio de inferencia se ejecutan dentro del dominio controlado por la empresa, el límite de datos es completamente distinto al de una API externa.
Comparación de modos de llamada
| Modo de llamada | Ruta de datos | Límite de privacidad | Escenarios aplicables |
|---|---|---|---|
| Inferencia local / servicio de modelo local | Los datos permanecen dentro del dominio controlado por la empresa; la inferencia se realiza con capacidad de cómputo que la empresa controla. | Por defecto, los datos nunca salen de la red de la empresa; los Providers externos no tienen acceso directo a los datos en bruto. | Datos extremadamente sensibles, código fuente, finanzas centrales, negocios altamente regulados. |
| AI Gateway propio de la empresa + modelo de despliegue privado | Los datos llegan primero al gateway de la empresa, y luego pasan a una instancia de modelo dedicada o a un endpoint privado. | La superficie de exposición puede controlarse mediante una red dedicada, un pool de recursos dedicado y un endpoint privado. | Escenarios de alta sensibilidad, tráfico de producción que requiere auditoría y control de políticas. |
| AI Gateway empresarial + API de Provider externo | Los datos llegan primero al gateway, y luego salen de la red hacia un Provider en la cadena ascendente para ejecutar la inferencia. | Es necesario revisar tanto las políticas de logs, entrenamiento y transferencia transfronteriza del gateway como las del Provider en la cadena ascendente. | Escenarios de producción generales, datos de sensibilidad media. |
| Plataforma de agregación / plataforma de enrutamiento + Provider externo | Los datos pasan por al menos un tercero adicional antes de llegar al Provider del modelo final. | Cada capa adicional de plataforma añade otra capa de políticas de retención y de subprocesadores que revisar. | PoC, pruebas A/B, tráfico de baja sensibilidad y experimentación rápida. |
Con inferencia local, los datos de negocio en bruto pueden permanecer principalmente dentro del dominio controlado por la empresa. Con cualquier forma de API externa, asuma por defecto que los datos pasan por al menos un tercero, hasta que haya revisado cada capa a fondo.
Desglosándolo: por qué capas pasa una solicitud de API de LLM
Una solicitud típica de API de LLM pasa por al menos cuatro capas. El verdadero trabajo de gobernanza consiste en revisar cada capa por separado, en lugar de atribuir todo el riesgo genéricamente al "proveedor del modelo".
Capas clave que atraviesa una solicitud
| Capa | Rol | Datos a los que puede acceder | Qué deben confirmar las empresas |
|---|---|---|---|
| Capa de aplicación de negocio | Ensambla la entrada del usuario, el system prompt, el contexto de RAG y los parámetros de herramientas. | Datos de negocio en bruto, identificadores de usuario, archivos subidos, fragmentos recuperados. | ¿Esta capa ya aplica enmascaramiento, minimización de campos y clasificación de datos? |
| Capa de AI Gateway / Policy | Se encarga de la autenticación, el enrutamiento, las cuotas, los reintentos, la auditoría y el control de políticas. | Texto completo de la solicitud, texto completo de la respuesta, uso de tokens, metadatos de la llamada. | ¿El registro de logs está habilitado por defecto? ¿Puede desactivar el registro del cuerpo, aplicar enmascaramiento por campo y auditar por inquilino (tenant)? |
| Capa de agregación / adaptación | Se encarga de la unificación de protocolos, el cambio de proveedor, el fallback y el enrutamiento por costo. | Puede acceder al texto completo de la solicitud, la información de selección de modelo y los logs de errores. | ¿Hay terceros adicionales? ¿Se listan claramente los Providers en la cadena ascendente y los subprocesadores? |
| Capa de Model Provider | Ejecuta la inferencia y devuelve el resultado. | Prompt, contexto, adjuntos, salida del modelo. | ¿Se usa para entrenamiento? ¿Se retiene solo a corto plazo? ¿Admite selección de región, DPA y despliegue dedicado? |
Qué ruta de llamada corresponde a cada clasificación de datos
Decidir si los datos pueden pasar por un Provider externo no debe basarse solo en la urgencia del negocio: primero debe hacerse la clasificación de datos. Distintos niveles de datos requieren distintas rutas de llamada recomendadas.
Clasificación de datos y modo de llamada
| Nivel de datos | Datos típicos | Ruta recomendada | Motivo |
|---|---|---|---|
| P0: datos confidenciales centrales / altamente regulados | Código fuente, finanzas no divulgadas, información personal sensible, texto original de contratos. | Inferencia local o despliegue dedicado, sin pasar por APIs públicas. | No se puede considerar que "la plataforma promete no entrenar" sea un control suficiente. |
| P1: datos internos sensibles | Tickets de soporte al cliente, informes internos, bases de conocimiento con pequeñas cantidades de información personal. | AI Gateway propio + un Provider ya revisado, exigiendo no-train, logs controlados y restricciones contractuales. | El enmascaramiento, la aprobación y la auditoría deben realizarse en la capa del gateway. |
| P2: datos internos generales | SOPs, documentación de producto, conocimiento de I+D no sensible. | Puede pasar por un AI Gateway + API de Provider externo. | Aún se deben configurar la retención de logs, la región y la política de llamadas. |
| P3: datos públicos o de baja sensibilidad | Textos del sitio web, FAQs públicas, materiales de marketing. | Puede usar una plataforma de agregación o enrutamiento multi-Provider. | El foco está en el costo, la disponibilidad y la calidad del modelo, no en un cumplimiento estricto. |
Para el tráfico P0 y altamente regulado, no considere que "la plataforma promete no entrenar" sea un control suficiente. Para P1 y P2, puede permitir una salida controlada a través de un AI Gateway una vez implementados el enmascaramiento, las restricciones contractuales y las políticas de auditoría.
Lista de revisión de Provider
Incluso después de implementar un AI Gateway, los Providers en la cadena ascendente aún deben revisarse por separado. El gateway es una capa de aplicación de políticas, no una exención de la responsabilidad de cumplimiento de la parte ascendente.
Elementos de Provider Policy que las empresas deben verificar como mínimo
| Elemento de revisión | Qué deben confirmar las empresas como mínimo | Estándar mínimo aceptable |
|---|---|---|
| Si se usa para entrenamiento | ¿Por defecto se entrena el modelo con datos de la API? ¿Qué SKUs o planes son excepciones? | El tráfico de producción es no-train por defecto, y esto queda especificado en los términos o el DPA. |
| Período de retención | ¿Cuánto tiempo se retienen los prompts, las respuestas, los archivos y los logs? ¿Se puede desactivar el registro del cuerpo? | Puede desactivar el registro del cuerpo, o minimizar la retención con un TTL claramente definido. |
| Residencia de datos y transferencia transfronteriza | ¿En qué regiones se realiza el procesamiento y almacenamiento de datos? ¿Existen subprocesadores transfronterizos? | Se puede especificar una región, y las rutas transfronterizas son claras y documentables. |
| Acceso humano | ¿Los equipos de soporte, depuración o seguridad pueden ver muestras manualmente? | El principio de mínimo privilegio, los controles de aprobación y las auditorías de acceso son rastreables. |
| Subprocesadores | ¿Hay revendedores, proveedores de nube o plataformas de enrutamiento adicionales involucrados en el procesamiento? | Hay una lista de subprocesadores disponible para revisión, con límites de responsabilidad claros. |
| Contrato y DPA | ¿Se puede firmar un DPA, SCC o un anexo empresarial? | Los escenarios de alta sensibilidad deben estar cubiertos por términos contractuales formales. |
| Capacidad de despliegue privado | ¿Admite dedicated capacity, private endpoint, VPC/VNet? | Las cargas de trabajo de alta sensibilidad deben contar con un aislamiento más sólido. |
| Auditoría y eliminación | ¿Puede proporcionar registros de auditoría, solicitudes de eliminación y notificaciones de incidentes? | Cumple con los requisitos internos de auditoría y respuesta a incidentes. |
El valor y los límites de las plataformas tipo OpenRouter
El valor de plataformas como OpenRouter está en ayudar a los equipos a integrar múltiples modelos más rápido, y ejecutar A/B test, fallback y enrutamiento por costo; pero no pueden sustituir la clasificación de datos y la revisión de Provider que le corresponden a la empresa.
Qué resuelven las plataformas tipo OpenRouter, y qué no
| Capacidad de la plataforma | Valor que aporta | Límite |
|---|---|---|
| Acceso unificado a múltiples modelos | Reduce el costo de experimentación y acelera el cambio entre distintos modelos y proveedores. | No puede sustituir la clasificación de datos y la revisión de Provider en la cadena ascendente que le corresponden a la empresa. |
| Enrutamiento por costo / calidad | Facilita las pruebas A/B, el fallback y el control de presupuesto. | No significa que todos los Providers cumplan con el mismo estándar de privacidad. |
| Pruebas más rápidas de modelos nuevos | Permite que los equipos de producto validen escenarios y experiencias más rápido. | No es adecuado como salida por defecto para datos de alta sensibilidad. |
| Forma de API unificada | Reduce el costo de integración e ingeniería de cambio. | Un protocolo unificado no implica una responsabilidad contractual ni una política de logs unificadas. |
Qué hace realmente un AI Gateway por las empresas
El valor central de un AI Gateway no es "demostrar que los datos nunca salen de la empresa", sino permitir que la empresa decida qué datos pueden salir, a través de quién, bajo qué política, y cómo rastrear, auditar y contener el daño después de que salgan.
Qué hace realmente un AI Gateway por las empresas
| Capacidad | Valor directo para la gobernanza |
|---|---|
| Enrutamiento y orquestación de políticas | Dirige distintos niveles de datos hacia distintos Providers, regiones o modelos. |
| Enmascaramiento y minimización | Elimina PII, credenciales, identificadores internos y contexto irrelevante antes de que la solicitud salga de la red. |
| Autenticación y cuotas unificadas | Reduce las API Keys dispersas, facilitando la gobernanza de permisos y la prevención de abuso. |
| Auditoría y observabilidad | Registra quién llamó a qué modelo, cuándo, y cuántos tokens consumió. |
| Cambio de proveedor y fallback | Reduce la interrupción del negocio causada por fallas o cambios de política de un único Provider. |
| Gobernanza de costos | Ofrece una vista unificada del presupuesto, los límites, la tasa de aciertos de caché y la selección de modelo. |
Lista de evaluación empresarial
Al evaluar un AI Gateway, las empresas deben revisar primero al menos estos 8 parámetros. Solo confirmando cada uno de estos puntos se puede determinar si esta cadena de llamadas está lista para producción.
Revise primero estos 8 parámetros como mínimo
| Parámetro | Qué deben confirmar las empresas |
|---|---|
| Si la solicitud original sale de la red de la empresa | ¿Qué tráfico debe procesarse localmente y cuál puede salir de la red? ¿Ya se alineó esto con el owner del negocio? |
| Qué capa puede ver el prompt / context / file | ¿Qué puede ver cada uno de el gateway, la plataforma de agregación, el Provider y el sistema de logs? |
| Si se registra el log del cuerpo | ¿Admite registrar solo metadatos, sin el cuerpo del prompt / response? |
| Cuánto tiempo se retienen los logs | ¿Está claramente definido el TTL por defecto, las diferencias entre entornos y el mecanismo de eliminación? |
| Si se usa para entrenamiento o mejora del modelo | ¿Son coherentes la política por defecto, las excepciones del plan empresarial y las restricciones contractuales? |
| En qué región residen los datos | ¿Se puede especificar la region? ¿Existen subprocesadores transfronterizos? |
| Si existe un ciclo cerrado de contrato y auditoría | ¿Se pueden proporcionar DPA, SCC, logs de auditoría y notificaciones de incidentes? |
| Si se puede hacer enmascaramiento y enrutamiento por niveles | ¿Se puede aplicar la política por campo, inquilino (tenant) o línea de negocio antes de que la solicitud salga de la red? |
Lista de verificación previa al lanzamiento
| Elemento de verificación | Criterio de aprobación |
|---|---|
| Matriz de clasificación de datos finalizada | La clasificación P0 / P1 / P2 / P3 se ha alineado con seguridad, legal y el owner del negocio. |
| Revisión de Provider completada | Los términos, la retención, el entrenamiento, la región y el DPA están archivados en un único registro de revisión. |
| Políticas del gateway configuradas | El enmascaramiento, la allowlist, los límites de tasa, el fallback y las políticas de logs están todos habilitados. |
| Tráfico de alta sensibilidad aislado | El tráfico P0 / P1 no pasa por rutas de agregación pública sin revisar. |
| Control de acceso implementado | Solo las aplicaciones y equipos aprobados pueden llamar a los modelos y rutas correspondientes. |
| Monitoreo y alertas en producción | Existen alertas en tiempo real para llamadas anómalas, anomalías de costo y rechazos de política. |
| Proceso de eliminación y respuesta a incidentes operativo | Puede manejar la eliminación de datos, los envíos erróneos y la investigación de filtraciones, con un responsable designado. |
| Fuentes de referencia y versiones de términos archivadas | Las policies externas, las conclusiones de revisión interna y los responsables son rastreables. |
FAQ
Cuando una empresa llama a un LLM a través de un AI Gateway, ¿el Provider siempre verá los datos?
Si finalmente un Provider externo ejecuta la inferencia, el Provider procesará al menos los datos de entrada necesarios para generar una respuesta. Un gateway puede reducir la superficie de exposición, aplicar enmascaramiento y controlar los logs, pero no puede convertir la inferencia externa en "los datos nunca salen de la empresa". Solo la inferencia local o el despliegue dedicado mantienen los datos en bruto principalmente dentro del dominio controlado por la empresa.
¿Es adecuada una plataforma tipo OpenRouter para producción formal?
Es adecuada para tráfico de baja sensibilidad, experimentación multi-modelo, fallback y enrutamiento por costo, pero no debería convertirse directamente en la salida por defecto para datos de alta sensibilidad. Si es utilizable en producción formal depende de la policy propia de la plataforma, la combinación de Providers en la cadena ascendente, los términos contractuales y si usted ya ha completado el diseño de clasificación, enmascaramiento y auditoría.
¿Es suficiente que un Provider prometa "no entrenar con los datos de la API"?
No es suficiente. La política de entrenamiento es solo un elemento. Las empresas también deben confirmar la retención de logs, el acceso humano, la región y las transferencias transfronterizas, los subprocesadores, el DPA, los procesos de eliminación y las notificaciones de incidentes. Fijarse solo en no-train suele pasar por alto los verdaderos riesgos de cumplimiento.
¿Puede un AI Gateway reemplazar por completo el enmascaramiento de datos y la gobernanza de permisos?
No. Un AI Gateway es un punto de aplicación de la gobernanza, no la política de gobernanza en sí. Primero deben existir la clasificación de datos, la categorización de campos, la aprobación de acceso y las reglas de negocio; solo entonces el gateway puede convertir esas reglas en políticas de enrutamiento, enmascaramiento, logs y límites de tasa.
¿Cómo determinar si un tipo de datos debe pasar por inferencia local o por una API externa?
Primero considere las obligaciones regulatorias y el costo de una filtración, y luego la urgencia del negocio. Si los datos pertenecen a la categoría P0 de confidencialidad central o de alta regulación, priorice la inferencia local o el despliegue dedicado; si son P1 o P2, puede enrutar a través de un AI Gateway + API externa una vez completados el enmascaramiento, la revisión de Provider y las restricciones contractuales; los datos públicos pueden usar una plataforma de agregación para mejorar la eficiencia.
Recomendaciones finales
Desde una perspectiva arquitectónica, el valor de un AI Gateway no es demostrarle a la empresa que "los datos nunca saldrán del país", sino consolidar la lógica de gobernanza que de otro modo estaría dispersa en el código de la aplicación, la documentación de proveedores y los procesos manuales, en un único sistema de políticas ejecutable, auditable y reversible.
Si su tráfico incluye datos P0 o altamente regulados, priorice la inferencia local o el despliegue dedicado. Si son datos P1 o P2, concéntrese en el enmascaramiento, la revisión de Provider, minimizar la retención de logs y cerrar los contratos. Solo los datos públicos o de baja sensibilidad son adecuados para pasar por defecto por una plataforma de agregación y enrutamiento multi-Provider.
El enfoque más seguro no es elegir primero "qué modelo es el mejor", sino decidir primero "qué datos pueden salir, quién puede verlos, cuánto tiempo pueden conservarse y cómo funciona la rendición de cuentas después de que salgan", y luego dejar que el AI Gateway aplique esa política.
Fuentes de referencia
Se mantiene una sección de fuentes al final de la página para que los equipos puedan comparar políticas, archivarlas internamente, y para que los motores de búsqueda y los sistemas de búsqueda de IA puedan identificar las fuentes del contenido.