El gateway de IA de Databricks ya lee el motivo de cada solicitud. La respuesta la da quien llama

La gobernanza de IA en las empresas no deja de pedir contexto: no solo quién llama a un modelo o a una herramienta, sino para qué proyecto, en qué entorno y con qué finalidad. El 9 de octubre, Databricks dio a su gateway una forma de leer ese contexto. El problema está en quién lo proporciona.

La nota de versión, en beta, es breve: “Las políticas de servicio personalizadas de Unity Gateway ya pueden comprobar request tags proporcionadas por quien llama, por ejemplo exigiendo una tag antes de que continúe una solicitud a un modelo o una llamada a una herramienta MCP.” Quien llama envía las tags como un objeto JSON en una cabecera de la solicitud, y una política puede devolver ALLOW o DENY según sus valores, evaluada en cada solicitud.

La propia documentación de Databricks deja claro el límite: “Las tags las proporciona quien llama y son distintas de las service tags y del contexto del actor autenticado.” Y: “Una tag por sí sola no establece la identidad ni el permiso para usar un proyecto.”

Tres tipos de entrada que puede leer una política del gateway

Establecido por la plataforma

• Actor autenticado
• Service tags

Puede sustentar una autorización

Declarado por quien llama

• Request tags: proyecto, finalidad, entorno

Contexto útil; por sí solo no prueba nada

Juzgado por un modelo

• Políticas LLM-as-a-judge, ahora con OpenJev

Las request tags no llegan al juez

Útiles para atribuir, débiles para autorizar

Las request tags son realmente útiles. Una tag con el proyecto permite a finanzas imputar el gasto en modelos al presupuesto correcto. Una tag con el entorno permite a una política alejar el tráfico de pruebas de los endpoints de producción. “Exigir una tag antes de la llamada” es buena higiene, porque obliga a quien llama a declarar una finalidad que luego aparece en el registro.

Lo que una tag no puede hacer por sí sola es autorizar. Si la política dice “permitir llamadas con la tag del proyecto p-1042”, cualquiera capaz de enviar la cabecera puede alegar p-1042. Un DENY basado en una tag frena a quien la olvidó por descuido, no a quien actúa de mala fe. La documentación indica que las comprobaciones de identidad o de permiso sobre un proyecto necesitan datos de identidad y autorización fiables.

El patrón útil es vincular ambas cosas: la política comprueba que el proyecto de la tag sea uno al que el actor autenticado pertenece de verdad, usando datos en los que confía la plataforma. Así la tag añade contexto a una identidad, en lugar de sustituirla. Es la misma separación que encontramos en los agentes de Databricks que llevan la identidad del usuario y en las tres identidades de un agente de IA: una afirmación sobre la finalidad no es una credencial.

El hueco en la aprobación

Un detalle de la documentación merece la atención de quien diseña aprobaciones humanas. Las políticas que devuelven ASK, y se detienen para que una persona apruebe, no distinguen tags. La documentación advierte que una aprobación puede reutilizarse en una llamada equivalente con tags distintas, y que las pantallas de aprobación no muestran las tags.

En la práctica: si un revisor aprueba una llamada a una herramienta marcada como “pruebas”, la misma aprobación puede cubrir una llamada equivalente marcada como “producción”. No use tags para acotar lo que una persona aprobó. Acote las aprobaciones por la propia llamada y reserve las tags para atribuir.

Las tags también llegan a las dos fases de una política, la llamada y el resultado, y se mantienen en los reintentos y en el fallback de modelo, de modo que la solicitud conserva su contexto declarado de principio a fin. No se envían a proveedores externos de políticas ni se añaden a los prompts de LLM-as-a-judge, y el tamaño de las tags decodificadas está limitado a 10 KiB por defecto.

Un juez más rápido

La misma versión añadió una segunda beta. OpenJev, un modelo Qwen3.5 4B, ya puede elegirse como evaluador de políticas personalizadas de LLM-as-a-judge. Como “clasifica el contenido sin generar tokens de salida”, Databricks afirma que “normalmente responde más rápido que un evaluador conversacional”.

Eso importa porque la gobernanza en línea tiene un presupuesto de latencia. Un juez que revisa cada respuesta de modelo o resultado de herramienta suma su retraso a cada llamada, y un juez lento acaba desactivado. Un evaluador de tipo clasificador es la idea de los modelos de decisión aplicada a la aplicación de políticas. Sigue costando inferencia, y sus veredictos necesitan la misma prueba de calibración que cualquier juez.

Ambas funciones están en beta, y la combinación dice mucho. Databricks está dando a su gateway más contexto y un juicio más rápido, los ingredientes de un gateway que aplica políticas en lugar de limitarse a reenviar tráfico. El trabajo de diseño que queda para los clientes es decidir cuáles de esas entradas merecen confianza para decidir algo.