La abstracción corporativa está subiendo un nivel: de “¿qué endpoint de modelo?” a “¿qué servicio de IA gobernado?”.
Un estate multi-modelo se vuelve desordenado antes de lo que sugieren muchos diagramas. Equipos distintos traen proveedores distintos. Los coding agents llevan sus propios clientes. Los servidores MCP exponen herramientas. Algunas cargas necesitan procesamiento europeo, otras endpoints privados y otras simplemente el modelo más barato que supere un umbral de evaluación.
Si cada aplicación incorpora sus propias claves, reintentos, filtros, logging y presupuestos, la infraestructura de IA se fragmenta.
La documentación 2026 de Unity AI Gateway de Databricks ilustra una alternativa: enrutar tráfico de modelos y MCP por una capa común capaz de aplicar privilegios, rate limits, presupuestos, fallbacks, políticas y observabilidad sobre proveedores externos y alojados.
El concepto importante no es el producto. Es el plano de políticas.
Separar elección de modelo e identidad de aplicación
Idealmente una aplicación debería pedir un servicio gobernado:
contract-analysis-prod
en lugar de hardcodear:
provider/model/version
Ese servicio puede definir:
- destinos permitidos;
- orden de contingencia;
- restricciones geográficas;
- presupuestos;
- rate limits;
- políticas de contenido o datos;
- telemetría;
- requisitos de evaluación.
La aplicación conserva un contrato estable mientras el equipo de plataforma puede cambiar la implementación inferior.
Así la caída de precios y los nuevos modelos pueden aprovecharse sin reescribir cada aplicación de negocio.
MCP amplía el gateway más allá de inferencia
Cuando los agentes llaman servicios MCP, el problema de control deja de limitarse a requests de modelo.
La plataforma debe responder:
- ¿Qué agentes pueden descubrir este servidor?
- ¿Qué herramientas pueden invocar?
- ¿A qué ritmo?
- ¿Bajo qué política?
- ¿Una llamada destructiva requiere aprobación?
- ¿Qué devolvió?
- ¿Qué sistema downstream fue afectado?
Databricks documenta políticas capaces de permitir, denegar o exigir aprobación humana alrededor de tool calls MCP, además de telemetría por servicio.
La dirección apunta a un plano integrado para razonamiento y acción.
Las credenciales de proveedor deberían dejar de repartirse por todos los clientes
El routing central también mejora la arquitectura de credenciales.
En lugar de entregar API keys a cada aplicación y herramienta de desarrollo, el gateway puede custodiar credenciales externas y autorizar al principal contra un servicio interno.
Eso limpia rotación, offboarding y auditoría. Además permite distinguir:
quién puede usar IA de qué cuenta externa implementa el servicio.
Son preocupaciones diferentes y no deberían colapsarse en un único secreto.
Presupuesto y disponibilidad pertenecen al routing
Un gateway maduro debería combinar política técnica y económica.
Por ejemplo:
- repartir tráfico normal 80/20 entre dos destinos aprobados;
- hacer contingencia ante 429 o 5xx;
- limitar gasto mensual de un departamento;
- restringir modelos caros a flujos de trabajo autorizados;
- usar modelos de menor coste para coding rutinario;
- mantener cargas reguladas dentro de una geografía aprobada.
El gateway se convierte en el lugar donde la intención de plataforma es ejecutable.
Pero ese poder crea una nueva dependencia crítica.
El gateway no debe convertirse en un cuello de botella opaco
La centralización falla si la capa es lenta, propietaria o imposible de inspeccionar.
Requisitos corporativos:
- overhead de latencia claro;
- alta disponibilidad;
- telemetría exportable;
- configuración como código;
- versionado de políticas;
- comportamiento de fallo predecible;
- modos degradados o bypass para servicios críticos;
- portabilidad razonable de routing y políticas.
Un plano de control debería reducir lock-in, no moverlo una capa hacia arriba.
Una separación arquitectónica útil
Lexdatum tiende a separar cuatro preocupaciones:
Capa de aplicación
Interfaces, agentes y flujos de trabajo de negocio.
Plano de políticas de IA
Identidad, routing, presupuesto, salvaguardas, evaluaciones y telemetría.
Capa de capacidades
Herramientas MCP, APIs corporativo, retrieval y acciones de software.
Capa de proveedores/runtime
Modelos, sandboxes, compute y servicios externos.
Así cada capa puede evolucionar a distinta velocidad.
La visión de Lexdatum
El activo estratégico de IA corporativa es cada vez menos un contrato con un modelo y más el camino gobernado por el que inteligencia y uso de herramientas entran en la organización.
Un AI gateway puede convertirse en ese camino si permanece model-agnostic, observable y rico en políticas.
El modelo sigue siendo reemplazable. El plano de políticas se convierte en infraestructura institucional.
Sources
- Databricks — AI governance with Unity AI Gateway (2026-08-21)
- Databricks — AI governance guide (2026-08-21)
Nota de investigación: este análisis se basa en información pública disponible el 1 de septiembre de 2026. Las capacidades de producto, precios e interpretaciones regulatorias pueden cambiar. Las afirmaciones de proveedores se identifican como tales. No constituye asesoramiento jurídico, de seguridad, financiero ni de inversión.