Databricks anunció el 4 de agosto la disponibilidad general de Unity AI Gateway, la capa con la que la compañía pretende centralizar el control del gasto, la seguridad y los permisos de todo lo que consume modelos de lenguaje dentro de una organización: agentes propios, agentes externos, servidores MCP, skills y asistentes de programación. Hasta ahora el componente estaba en vista previa; según Databricks, durante esa fase pasaron por el gateway más de un cuatrillón de tokens.
El producto se apoya en tres bloques. El primero es el control de coste y la observabilidad: visibilidad extremo a extremo del gasto desagregado por modelo, proveedor, equipo y aplicación, con presupuestos y topes duros que cortan el consumo cuando se alcanza el límite. A esto se suma Smart Routing, todavía en beta, que decide a qué modelo enviar cada petición combinando criterios de calidad, coste, rendimiento, disponibilidad y presupuesto restante.
El segundo bloque es la gobernanza unificada. Al integrarse con Unity Catalog, el gateway aplica sobre las interacciones de IA el mismo modelo de identidad, permisos y auditoría que ya rige para tablas y ficheros, e incorpora barreras de ejecución para exposición de datos personales e inyección de instrucciones. El tercero es la flexibilidad multiproveedor: una única API da acceso a modelos de Anthropic, OpenAI, Google, Kimi o GLM, junto a los alojados en la propia plataforma.
El movimiento no llega aislado. Una semana antes, el 28 de julio, Snowflake presentó Cortex AI Gateway con un planteamiento muy parecido —políticas centralizadas de acceso para agentes propios y de terceros, registro de actividad, control de consumo y enrutado de modelos—. Los dos grandes proveedores de plataforma de datos están convergiendo en la misma tesis: si los agentes van a leer y escribir sobre datos corporativos, la capa de gobierno tiene que ser la misma que ya protege esos datos, no un sistema paralelo.
Para un responsable de datos en España el interés práctico está menos en el anuncio y más en dos problemas que ya aparecen en cualquier despliegue real. El primero es el descontrol de coste: sin presupuestos por equipo, el gasto en tokens se convierte en una partida opaca que solo se descubre al cerrar la factura mensual. El segundo es la trazabilidad. Cuando un agente consulta tablas con datos personales, el RGPD exige poder responder quién accedió, a qué y con qué finalidad; resolverlo con el catálogo que ya gobierna esas tablas ahorra construir un registro de auditoría aparte. La contrapartida evidente es la dependencia: centralizar el control del acceso a modelos dentro de la plataforma de datos refuerza el vínculo con el proveedor, aunque la API admita modelos de terceros.
Más en Dataprix: Gobierno de datos: catálogos, linaje y control de acceso
Fuente: Blog de Databricks
Contenido elaborado con asistencia de inteligencia artificial y revisado editorialmente por el equipo de Dataprix.