El gateway de IA ya no es un proxy: es un punto de control de políticas. El LLM Gateway de C1 explica por qué

Casi toda empresa que usa más de un modelo ya tiene un gateway de IA, aunque nadie lo llame así. A veces es un proxy inverso delante de Azure OpenAI. A veces, una librería interna que el equipo de plataforma pide usar a todos. Con frecuencia, un almacén de claves de API y una hoja de cálculo que asigna cada clave a un centro de coste.

Esos montajes responden a una sola pregunta: ¿puede esta aplicación llegar al modelo? Casi nunca responden a las que hacen el CISO, el delegado de protección de datos o el director financiero. ¿Quién hizo la llamada? ¿Qué datos llevaba? ¿Podía ese modelo verlos? ¿Quién paga?

C1, proveedor de seguridad y gobierno de identidades, lanzó el 1 de octubre un LLM Gateway construido alrededor de esas preguntas. El producto es un dato. El cambio que refleja es mayor: el gateway se está convirtiendo en un punto de aplicación de políticas, y la identidad pasa a ser la clave de enrutamiento.

Qué anunció C1

Según C1, LLM Gateway ofrece a aplicaciones y agentes un único endpoint de inferencia controlado por políticas, que reparte las llamadas entre despliegues de modelos aprobados: públicos, privados y controlados por el cliente. El equipo define las rutas elegibles por proveedor, modelo, despliegue, región y reglas de tratamiento de datos. Dentro de esas rutas, el gateway elige destino según capacidad, salud, latencia y coste.

Dos detalles lo alejan de un simple proxy. El gateway vincula cada llamada a la persona, aplicación, carga de trabajo o agente que la origina, apoyándose en la base de identidad y políticas de la plataforma C1. Y conserva ese contexto para imputar el uso y el coste de inferencia a responsables, proyectos o unidades de negocio.

El anuncio no indica disponibilidad general, precios, regiones ni la lista de proveedores compatibles. La interoperabilidad hay que probarla, no darla por hecha.

Por qué la ruta sale del código

En la primera ola de IA empresarial, la elección del modelo vivía en el código. Quien desarrollaba elegía un endpoint, fijaba el nombre del despliegue y seguía adelante. Eso deja de funcionar por tres razones.

La lista aprobada cambia sin parar. Llegan modelos nuevos cada mes, se retiran versiones antiguas y el mismo modelo se ofrece por varias vías con condiciones de datos distintas, como explicamos en nuestro análisis de las vías de Claude en Azure y AWS. Si cada aplicación decide su ruta, cada cambio exige tocar código en decenas de repositorios.

La regla depende del dato, no de la aplicación. Un mismo asistente interno puede revisar un contrato de proveedor por la mañana y una historia clínica por la tarde. En una empresa española, que una llamada con datos personales termine en un despliegue dentro de la UE o fuera de ella es una decisión de transferencias internacionales bajo el RGPD; por eso Microsoft completó en 2025 su EU Data Boundary, y por eso muchos equipos ya separan despliegues europeos de los globales. En México, la nueva Ley Federal de Protección de Datos Personales en Posesión de los Particulares, vigente desde marzo de 2025, mantiene reglas propias para las transferencias. Y en Chile, la Ley 21.719 entra en vigor el 1 de diciembre de 2026 con una agencia de protección de datos con capacidad sancionadora. Son marcos distintos, pero todos piden lo mismo a la arquitectura: decidir llamada a llamada.

El coste necesita un responsable en el momento de la llamada. Finanzas quiere el gasto en IA por caso de uso y por área, no por SKU de modelo. Repartir la factura de tokens a posteriori, con logs sin identidad, es el camino lento y conflictivo. Tratamos la parte de las plataformas en nuestro artículo sobre límites de gasto en IA.

1. Quien llama: persona, app o agente
2. Resolver identidad y carga
3. Aplicar reglas de datos y región
4. Elegir entre rutas elegibles
5. Despliegue del modelo
6. Imputar el coste a un responsable

• Decide la política: Resolver identidad y carga · Aplicar reglas de datos y región · Elegir entre rutas elegibles
• Deciden las señales: Elegir entre rutas elegibles · Despliegue del modelo

Trabajo que pasa del código de la aplicación al gateway

El orden de las decisiones importa

La idea de diseño más útil en la descripción de C1 es la secuencia: primero la política, después la optimización. Las reglas de identidad, tipo de dato y región definen qué rutas son elegibles. Solo entonces la latencia y el coste eligen entre ellas.

Los equipos que construyen su propio gateway suelen invertir el orden. Empiezan por el balanceo de carga y la conmutación por error, que son fáciles de medir, y dejan la política para después. El resultado es un gateway capaz de pasar, sin avisar, de un despliegue privado lento a uno público. Justo lo que el equipo de privacidad necesita impedir.

Qué comprobar antes de comprar o construir

Las empresas que trabajan sobre Microsoft ya tienen un punto de partida: las capacidades de gateway de IA de Azure API Management, que aplican límites de tokens, reparten carga entre backends de modelos y emiten métricas de uso. Eso cubre mucho. La pregunta que conviene hacer a cualquier opción, sea Microsoft, C1 o un proxy propio, es si la identidad real de quien llama llega a la decisión de ruta o si el gateway solo ve una clave de aplicación.

Una lista práctica:

1. Identidad, no solo claves. ¿Ve el gateway a la persona y al agente, también cuando el agente actúa en nombre de alguien? ¿Puede tomar esa identidad de su proveedor de identidad actual?
2. Reglas de datos expresadas como política. ¿Se puede decir “los datos personales de clientes solo van a despliegues en la UE” sin modificar el código de las aplicaciones?
3. Nada de degradación silenciosa. ¿Qué pasa si todas las rutas elegibles fallan? La respuesta segura es un error, no un desvío a una ruta no autorizada.
4. Registros de coste útiles para finanzas. ¿Cada llamada lleva responsable, proyecto y centro de coste, en un formato que su herramienta de FinOps pueda importar?
5. Evidencia. ¿Se registran las decisiones de ruta con la política aplicada, para que una auditoría reconstruya por qué una llamada fue adonde fue?
6. Portabilidad. ¿Habla el gateway los formatos de API que ya usan sus aplicaciones, de modo que añadir o quitar un proveedor sea solo configuración?

En resumen

En cuanto una empresa usa más de un modelo, alguien tiene que decidir qué llamada va adónde. Dejar esa decisión en el código la reparte entre todos los equipos. Llevarla a un gateway que conoce la identidad la convierte en política que seguridad, privacidad y finanzas pueden leer y revisar. El lanzamiento de C1 es la versión de un proveedor. El argumento de arquitectura vale para cualquier stack y encaja en las capas de identidad y política de nuestra guía del stack de IA empresarial de 2026.