Un gateway de modelos: enrutamiento, presupuestos y trazabilidad en un solo punto

El patrón inicial de adopción de modelos en casi todas las organizaciones es el mismo: cada equipo que necesita uno consigue una credencial del proveedor y se conecta directamente.

Es lo más rápido y es correcto al principio. Deja de serlo cuando hay cinco equipos y tres proveedores, porque en ese punto la organización pierde simultáneamente el control de tres cosas.

El costo, porque el gasto se reparte entre varias cuentas sin desagregación por equipo ni por caso de uso. El acceso, porque las credenciales se distribuyen sin política central y nadie sabe quién tiene cuál. La trazabilidad, porque cada equipo registra lo que le parece, en formatos distintos, cuando lo registra.

Una capa de gateway resuelve las tres a la vez.

Qué hace un gateway de modelos

Es una capa intermedia entre las aplicaciones y los proveedores. Las aplicaciones hablan con el gateway; el gateway habla con los proveedores. Eso habilita seis capacidades que sin él son inviables.

Interfaz unificada. Las aplicaciones usan un solo protocolo, independientemente del proveedor detrás. Cambiar de modelo o de proveedor deja de requerir cambios en cada aplicación.

Enrutamiento. Dirigir cada tipo de solicitud al modelo adecuado. Tareas simples a modelos económicos, tareas complejas a modelos capaces. Esta decisión, centralizada, puede cambiar significativamente el costo total sin tocar ninguna aplicación.

Alternativas ante fallas. Si un proveedor no responde, la solicitud se redirige. Sin esto, la disponibilidad del sistema queda atada a la de un proveedor externo sobre el que no se tiene ningún control.

Límites y presupuestos. Cuotas por equipo, por aplicación, por agente, por período, aplicadas en el punto por donde pasa todo el tráfico.

Control de acceso. Las credenciales de los proveedores viven en un solo lugar. Los equipos reciben acceso al gateway, no a los proveedores. Revocar un acceso es una operación, no una búsqueda.

Seguimiento de gasto y trazabilidad. Registro homogéneo de cada solicitud: qué aplicación, qué modelo, qué costo, qué latencia, qué resultado.

El argumento de los presupuestos

De las seis, la capacidad que suele justificar el esfuerzo por sí sola es la de límites.

Un agente con un defecto que provoca reintentos puede generar un volumen enorme de solicitudes en minutos. Sin límite aplicado en el punto de acceso, ese comportamiento se detecta cuando alguien mira la factura o cuando el proveedor corta por exceso de uso.

Con límites en el gateway, el agente se detiene al alcanzar su cuota, se emite una alerta, y el daño queda acotado a lo presupuestado. Es exactamente el tipo de control que no se puede implementar de forma distribuida: si cada aplicación aplica su propio límite, basta con que una no lo haga.

Lo que hay que cuidar

Un gateway agrega valor y agrega riesgo, y conviene ser explícito sobre el segundo.

Es un punto único de falla. Si el gateway cae, todas las aplicaciones que dependen de él pierden acceso. Requiere el tratamiento de un componente crítico: redundancia, monitoreo, objetivos de servicio definidos.

Agrega latencia. Poca, pero existe. En casos sensibles al tiempo de respuesta hay que medirla en vez de suponerla despreciable.

Puede convertirse en cuello de botella organizacional. Si agregar un modelo nuevo requiere un ticket y una espera de dos semanas, los equipos van a buscar caminos alternativos, y la organización va a terminar con un gateway y un conjunto de conexiones directas por fuera. El gateway tiene que ser un servicio de autoservicio, no una puerta con guardia.

Concentra credenciales. Todas las llaves en un lugar es mejor que distribuidas sin control, y es también un objetivo más valioso. Requiere un almacén de secretos adecuado y rotación.

La telemetría que conviene no encerrar

Hay una decisión adicional que se toma al implementar un gateway y que tiene consecuencias a largo plazo: en qué formato se registra la telemetría.

La opción cómoda es usar el formato propietario de la herramienta elegida. La opción que envejece mejor es emitir la telemetría en un formato abierto y estandarizado. Las convenciones actuales de OpenTelemetry para sistemas generativos permiten registrar modelos, consumo, llamadas a herramientas, trazas y eventos de forma neutral respecto del proveedor.

La diferencia importa porque la capa de observabilidad de IA es un mercado en movimiento. Una organización que emite telemetría estándar puede cambiar de herramienta de análisis sin perder su historial. Una que emitió en formato propietario descubre, dos años después, que migrar significa perder la serie histórica sobre la que se apoyan todas sus comparaciones.

Cómo se decide el enrutamiento

De las seis capacidades, el enrutamiento es la que más ahorro produce y la que se implementa peor, porque suele configurarse por intuición: tareas “importantes” al modelo capaz, tareas “simples” al económico.

Esa clasificación por importancia percibida es la equivocada. La correcta es por dificultad verificable.

Hay tres características que determinan si una tarea necesita un modelo capaz.

Ambigüedad de la entrada. Una tarea con entrada estructurada y salida acotada —clasificar en cinco categorías, extraer cuatro campos de un documento con formato conocido— rara vez requiere el modelo más costoso. Una con entrada libre y salida abierta, sí.

Necesidad de razonamiento encadenado. Tareas que requieren combinar varias piezas de información y derivar conclusiones se benefician de modelos más capaces. Tareas de transformación o extracción, mucho menos.

Costo del error. No porque el modelo caro no se equivoque, sino porque en tareas donde el error es costoso conviene el margen adicional.

La forma correcta de decidir no es razonar sobre estas tres características: es medir. Se toman cincuenta casos reales de cada tipo de tarea, se corren con el modelo económico y con el capaz, y se compara la tasa de éxito contra el criterio definido.

El resultado habitual sorprende en ambas direcciones. Hay tareas que se estaban ejecutando con el modelo más caro y que el económico resuelve con calidad indistinguible: ahí hay un ahorro directo, con frecuencia grande. Y hay tareas aparentemente simples donde el modelo económico falla en una proporción que no se había notado porque nadie estaba midiendo.

Ese segundo hallazgo es tan valioso como el primero. Significa que la organización estaba aceptando una tasa de error que desconocía, en tareas que consideraba resueltas.

Una vez tomada la decisión, conviene que quede en la configuración del gateway y no en cada aplicación. Así, cuando aparezca un modelo nuevo, la reevaluación se hace en un solo lugar y con el mismo conjunto de casos, que es exactamente lo que convierte una decisión puntual en una capacidad reutilizable.

Cuándo introducirlo

No con el primer caso de uso. Con el tercero.

Con uno o dos, la conexión directa es más simple y el gateway es sobreingeniería. A partir del tercero aparecen las condiciones que lo justifican: múltiples equipos, más de un proveedor, necesidad de comparar costos y una superficie de credenciales que ya nadie tiene enteramente mapeada.

Introducirlo en ese momento es relativamente barato: hay pocas aplicaciones que migrar y la convención se establece antes de que existan quince integraciones directas. Introducirlo con quince es un proyecto de migración que compite con el trabajo de producto y que, por eso, suele postergarse indefinidamente.