¿Qué es un gateway de IA?
Un gateway de IA es un punto de entrada compartido entre sus aplicaciones y los modelos de IA que utilizan: OpenAI, Anthropic, Mistral o modelos que usted mismo aloja. En lugar de que cada aplicación tenga sus propias claves y tome sus propias decisiones, todas las peticiones pasan por un único lugar donde el acceso, el coste, las reglas sobre los datos y el registro de lo ocurrido se gestionan una sola vez, para todos.
Las mismas tres aplicaciones, dos veces
Sin gateway
- Cada aplicación guarda sus propias claves de proveedor, y cada una de ellas es un lugar por donde puede filtrarse una clave.
- Cada equipo desarrolla sus propios reintentos, límites y registros, cada uno un poco distinto.
- El gasto llega como una factura por proveedor, sin una línea que indique el equipo o la función que lo originó.
- Añadir o cambiar de proveedor obliga a modificar el código de todas las aplicaciones.
Con gateway
- Las claves de proveedor están en un solo lugar. Las aplicaciones reciben claves propias del gateway, que se pueden revocar sin tocar al proveedor.
- Los reintentos, el failover y la caché se resuelven una vez, de la misma forma, para todas las aplicaciones.
- Cada petición se atribuye en el momento a un equipo, una aplicación y un usuario.
- Los modelos se añaden o se sustituyen por configuración. El código de las aplicaciones no cambia.
Cinco cosas le ocurren a cada petición
Los detalles varían de un producto a otro, pero el esquema es el mismo: primero las comprobaciones, en medio la llamada al modelo y al final el registro. Una petición que no supera una comprobación se detiene antes de que nadie pague por ella.
- Comprobar quién la envía. La aplicación presenta su propia clave del gateway, o el acceso corporativo de un usuario. Los llamantes desconocidos son rechazados. ✗ rechazada
- Comprobar los límites. ¿Está este equipo dentro de su presupuesto y de su límite de frecuencia? Si no, la petición se detiene aquí, antes de contactar con el proveedor. ✗ presupuesto agotado
- Aplicar las reglas. Las reglas de toda la organización se aplican al prompt: por ejemplo, enmascarar datos personales o impedir que salgan hacia un proveedor externo. ✗ bloqueada · ◑ enmascarada
- Elegir un modelo y llamarlo. El gateway decide qué proveedor y qué modelo atienden la petición, y pasa al siguiente si un proveedor va lento o está caído.
- Registrar lo ocurrido. Quién preguntó, qué modelo respondió, cuánto costó y qué reglas se aplicaron: queda anotado en cada petición, no se reconstruye después.
Esta es la versión simplificada. La ruta de la petición completa de Wäg tiene nueve etapas, incluidas la caché y la política de herramientas sobre las llamadas a herramientas de los agentes: vea la ruta de la petición, etapa por etapa.
Suele empezar por uno de estos motivos
Nadie compra un gateway porque exista la categoría. Lo compra porque ha ocurrido algo de esta lista.
| Lo que se nota | Lo que hace un gateway al respecto | Más información |
|---|---|---|
| La factura de IA se ha duplicado y nadie sabe decir qué equipo la ha causado. | Atribuye el coste de cada petición a un equipo, una aplicación y un usuario, y detiene el gasto al llegar al límite que usted fije. | Costes y presupuestos |
| Las claves de proveedor están pegadas en una docena de archivos de configuración y secretos de CI. | Custodia las claves de proveedor en un solo lugar. Las aplicaciones reciben claves del gateway que puede acotar, rotar y revocar. | Postura de seguridad |
| La caída de un proveedor dejó fuera de servicio una función de cara al cliente. | Reintenta y hace failover automáticamente a otro proveedor o modelo. | Enrutamiento y failover |
| Alguien preguntó si los datos de clientes se envían a un modelo externo y nadie supo responder. | Aplica reglas sobre los datos a cada prompt (enmascarar, redactar o bloquear) antes de que salga. | Políticas y guardrails |
| Cada equipo eligió su propio modelo, y casi todos usan por defecto el más caro. | Dirige cada petición al modelo más barato capaz de resolverla, por política y no por costumbre. | Enrutamiento inteligente |
| Un auditor, un cliente o el Reglamento Europeo de IA preguntan qué han hecho realmente sus sistemas de IA. | Guarda un registro de cada petición: quién preguntó, qué modelo respondió, cuánto costó y qué reglas se aplicaron. | Reglamento Europeo de IA y registros |
| Los agentes ya llaman a herramientas y sistemas internos con credenciales reales. | Somete las llamadas a herramientas de los agentes a la misma identidad, política y registro que las llamadas a modelos. No todos los gateways lo hacen: pregunte. | Gobernanza de agentes |
Normalmente, una línea
La mayoría de los gateways hablan la API de OpenAI, que casi todos los SDK y frameworks de IA ya admiten. Adoptar uno significa cambiar la dirección a la que su aplicación envía las peticiones y la clave con la que las envía.
client = OpenAI(
- base_url="https://api.openai.com/v1",
- api_key=os.environ["OPENAI_API_KEY"],
+ base_url="https://ai-gateway.internal/v1",
+ api_key=os.environ["GATEWAY_KEY"],
)Los prompts, el SDK y el tratamiento de las respuestas se quedan como están. Un buen gateway también traduce para los proveedores con una API distinta, como Anthropic o Gemini, de modo que la aplicación nunca tiene que saber qué proveedor respondió.
La decisión que casi nadie sabe que está tomando
Un gateway ve cada prompt y cada respuesta que pasa por él. Por eso la primera pregunta no es qué funciones tiene, sino en la infraestructura de quién se ejecuta.
| Pregunta | Gestionado: lo opera un proveedor | Autoalojado: lo opera usted |
|---|---|---|
| Adónde van los prompts y las respuestas | Por la red y los sistemas del proveedor, de camino al proveedor del modelo | A ningún sitio nuevo: permanecen en su infraestructura hasta llegar al proveedor que usted eligió |
| Quién custodia sus claves de proveedor | El proveedor del gateway | Usted |
| Tiempo hasta la primera petición | Minutos: se registra y cambia la URL base | Más: primero hay que desplegarlo |
| Quién lo mantiene en marcha | El proveedor del gateway | Su equipo, normalmente el de plataforma |
| Es la opción adecuada cuando | Lo más importante es la rapidez y los datos no son sensibles | La protección de datos, la normativa o las reglas de compras descartan a un tercero en la ruta de la petición |
No siempre
Tiene una aplicación, un proveedor y un equipo, y nadie fuera de ingeniería pregunta por el gasto en IA ni por los datos. Llamar directamente al proveedor es más sencillo, y lo sencillo es una virtud. Vuelva cuando eso cambie.
Empiece a buscar cuando ocurra alguna de estas cosas:
- Llega un segundo equipo o un segundo proveedor.
- Alguien pregunta cuánto cuesta la IA por equipo o por producto, y la respuesta tarda una semana.
- Protección de datos o seguridad preguntan adónde van los prompts.
- La caída de un proveedor se convierte en su propia caída.
- Los agentes empiezan a actuar sobre sus sistemas con credenciales reales.
Cuando un gateway no basta
Un gateway gobierna las aplicaciones que deciden apuntar a él. Cuando la IA se convierte en infraestructura compartida (muchos equipos, agentes con autoridad real, auditores que hacen preguntas), la cuestión deja de ser cómo se reenvían las peticiones y pasa a ser quién decide qué puede ser una petición, para toda la organización. Esa es la línea que separa un gateway de IA de un control plane de IA.
Un gateway de IA que usted mismo ejecuta
Wäg es un gateway de IA de código abierto que se ejecuta íntegramente en su propia infraestructura: sin versión alojada, sin ningún proveedor en la ruta de la petición y sin phone-home. Habla la API de OpenAI, se conecta con más de 25 proveedores compatibles con OpenAI además de Anthropic y Gemini de forma nativa, y añade la capa de control plane (identidad, presupuestos jerárquicos, políticas, gobernanza de agentes y auditoría) en la misma ruta de la petición. Apache-2.0, escrito en Rust.
¿Ya utiliza LiteLLM u otro gateway? Wäg importa la configuración de LiteLLM, y la guía de migración explica cómo ejecutar ambos en paralelo antes de dar el paso.
Lo que se pregunta primero
¿Es lo mismo un gateway de IA que un proxy de LLM?
En su mayor parte, sí. Proxy de LLM, proxy de IA, gateway de LLM y gateway de IA describen un único endpoint delante de varios proveedores de modelos. «Gateway» suele implicar algo más que reenviar (claves, límites, reglas y un registro), pero los términos no se usan de forma coherente, así que compruebe lo que un producto aplica de verdad en lugar de cómo se llama.
¿En qué se diferencia de un API gateway?
Un API gateway gestiona peticiones: enrutamiento, autenticación y límites de frecuencia por llamada. Un gateway de IA entiende además lo que hay dentro de una petición a un modelo: tokens, el precio de cada modelo, respuestas en streaming, prompts que pueden contener datos personales y proveedores que pueden sustituirse entre sí. Algunos API gateways ya incorporan funciones de IA; la pregunta útil es si cuentan tokens y coste, o solo peticiones.
¿Tengo que cambiar el código de mi aplicación?
Normalmente solo la URL base y la clave, siempre que el gateway hable la API de OpenAI y su aplicación use un SDK o framework compatible con OpenAI, como hace la mayoría.
¿Ralentiza las peticiones?
Añade un salto de red, así que añade algo de tiempo. Un gateway bien construido añade milisegundos, frente a respuestas de modelo que tardan cientos de milisegundos o varios segundos, y un acierto de caché puede hacer una petición mucho más rápida que llamar al proveedor. Pida a cualquier proveedor la sobrecarga medida con los registros y los presupuestos activados, no desactivados.
¿No es un punto único de fallo?
Solo si se ejecuta como una única instancia. Los gateways en producción se ejecutan como varias instancias sin estado detrás de un balanceador de carga, y el failover entre proveedores suele evitar más caídas de las que el gateway introduce.
¿Ve mis prompts el proveedor del gateway?
Con un gateway gestionado, sí: los prompts y las respuestas pasan por los sistemas del proveedor. Con un gateway autoalojado, el proveedor no está en la ruta de la petición en absoluto: el software se ejecuta en su infraestructura y solo habla con los proveedores que usted configure.
¿Puede dirigir peticiones a modelos que alojamos nosotros?
Sí, si esos modelos exponen una API compatible con OpenAI, como hacen vLLM, Ollama y la mayoría de los servidores de inferencia. El gateway los trata como a cualquier otro proveedor, de modo que los modelos locales y los de la nube quedan tras el mismo endpoint y las mismas reglas. Para los modelos en los ordenadores de los empleados o dentro de apps móviles, Wäg Edge registra las llamadas locales y las notifica al gateway.
Un endpoint. Cada modelo. Control total.
Ejecútelo en su propia infraestructura
Todo lo necesario para operar un control plane en producción es Apache-2.0 y seguirá siéndolo: enrutamiento, alta disponibilidad, caché, failover, presupuestos, políticas, MCP, trabajos y observabilidad. Self-hosted, sin cuenta, sin phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>No es un pull que funcione: las imágenes aún no son públicas. Los socios de diseño reciben los datos del registro en privado.
Despliega en 5 minutosContribuya a definirlo como design partner
Wäg todavía no se ha publicado. Trabajamos con un grupo reducido de equipos que ejecutan IA multiproveedor en producción y se toman en serio la gobernanza y la soberanía, para endurecer el control plane con cargas de trabajo reales.
- Todas las capacidades Enterprise incluidas, sin coste de licencia
- Migración acompañada: la hacemos con usted, también desde LiteLLM
- Línea directa con los ingenieros que lo construyen e influencia real sobre lo que llega después