Preflight de Genie autónomo en Databricks: aprobaciones, presupuestos y salvaguardas antes de ejecutarlo

En la práctica, eso implica tres cosas: empezar con trabajos que solo lean e informen, exigir la aprobación de una persona antes de cualquier acción que modifique un sistema o contacte con alguien, y no tratar un presupuesto de Genie como un tope de tu factura total.

Qué cambia con Genie autónomo

Los trabajos de Genie ya no esperan a que alguien pregunte. El blog de anuncio de Databricks indica que, una vez en marcha, un trabajo de Genie puede ejecutarse según una programación o responder a disparadores, como la caída de una métrica o que más de 10 clientes pidan la misma funcionalidad.

Esos disparadores pueden basarse en un conjunto de datos mucho más amplio. Databricks afirma que Genie Search se amplía a más de 100 fuentes de datos empresariales, incluido el lakehouse y aplicaciones de negocio como Google Drive, Jira y Confluence.

Un mayor alcance viene acompañado de un modelo de facturación distinto. En el comunicado de prensa, Databricks explica que los clientes pagan por lo que usan en lugar de por puesto, y que los administradores pueden fijar límites de gasto por equipo o por usuario mediante Unity AI Gateway. Genie One es gratuito para los usuarios hasta el 31 de enero de 2027, y Databricks asegura que antes de esa fecha habrá controles de costes más detallados.

Para mostrar el modelo funcionando a escala, Databricks cita a dos clientes. Informa de que General Motors ha desplegado más de 1,000 agentes de Genie en ventas, ingeniería, cadena de suministro y operaciones de RR. HH. Se cita a HelloFresh diciendo que Genie redujo en un 75% el tiempo necesario para identificar los anuncios ganadores en Meta. Databricks publicó ambas declaraciones, ninguna es una medición independiente y ninguna indica qué controles había implantados, así que hablan de la demanda pero dicen poco sobre cómo se comportará Genie en tu entorno.

Por qué los agentes siempre activos necesitan otro modelo de riesgo

En un chat, una persona lee cada respuesta antes de actuar en consecuencia, y la sesión tiene un final claro. Un trabajo activado por un disparador puede ejecutarse en plena noche o cada vez que una métrica cruza un umbral, sin nadie leyendo, y sigue adelante hasta que algo lo detiene. Por eso sus permisos se deciden en la fase de diseño.

Esa decisión de diseño se complica a medida que se multiplican los conectores. Según sus herramientas, un trabajo que puede leer Jira y Confluence quizá también pueda editarlos, así que, para cada trabajo, documenta lo que puede cambiar además de lo que puede ver.

El volumen agrava el problema. La documentación de configuración de Databricks indica que cada Genie Agent admite hasta 200,000 conversaciones, y que cada conversación puede incluir hasta 10,000 mensajes. Un disparador mal configurado podría activarse muchísimas veces dentro de esos límites antes de que nadie se dé cuenta.

Lo organizamos con lo que llamamos la escalera de autonomía Leer-Informar-Actuar. Cada herramienta que un trabajo podría invocar recibe un peldaño, y cada trabajo sube los peldaños de uno en uno.

La autonomía se gana por peldaño, no se concede por agente.

Aprobaciones y listas de herramientas permitidas

Por defecto, leer e informar

Empieza cada trabajo autónomo en los dos peldaños inferiores y haz que todo lo que escriba en un sistema, envíe un mensaje o abra un ticket espere a una persona. Es prudente a propósito, porque puedes relajar una política más adelante, pero no es fácil retirar algo que ya ha llegado a un cliente.

Redacta las políticas de servicio como listas de permitidos

Las políticas de servicio de Unity AI Gateway deciden qué llamadas a herramientas MCP están permitidas. La sintaxis y las opciones de aprobación pueden cambiar, así que guíate por los ejemplos de políticas de servicio y la documentación sobre cómo gobernar un MCP de Databricks en lugar de dar por hecho que una función existe. Si necesitas un paso de aprobación para herramientas del peldaño Actuar que la documentación no describe, pregunta a Databricks o canaliza esas acciones a través de un flujo de trabajo existente que ya exija aprobación.

Cada política debe nombrar las herramientas que un trabajo puede invocar.

Cuenta con que las políticas fallen en modo cerrado

Las políticas de servicio fallan en modo cerrado: una comparación sobre un campo ausente, una función no admitida o cualquier error de evaluación da como resultado DENY. Es el comportamiento de seguridad predeterminado correcto, pero tiene un coste operativo, porque una errata o una regla que comprueba un campo que algunas llamadas no tienen bloqueará en silencio trabajo legítimo.

Los proveedores externos de salvaguardas se comportan igual. La documentación sobre cómo gobernar un MCP indica que las políticas de servicio externas fallan en modo cerrado: si el endpoint del proveedor no está accesible o responde con lentitud, Databricks deniega la llamada. Una caída del proveedor se traduce en trabajos fallidos, no en trabajos que se saltan la salvaguarda. Configura alertas para las denegaciones y decide de antemano si una ejecución fallida se reintenta más tarde o simplemente informa de que no pudo terminar.

Prueba una política antes de confiar en ella

Toma un trabajo de informe semanal de abandono de clientes en el peldaño Informar. La política siguiente es pseudocódigo ilustrativo con nombres de herramientas hipotéticos, no sintaxis de Databricks.

policy: churn-weekly-report
applies_to: tools/call
allow_if: tool_name in [run_readonly_sql, write_internal_summary]
otherwise: DENY

Después, haz tres llamadas con la propia identidad del trabajo:

1. Ruta permitida. run_readonly_sql debería estar permitida.
2. Herramienta fuera de alcance. create_ticket debería devolver DENY.
3. Fallo deliberado. Una llamada a la que le falte el campo que comprueba la política, como una sin nombre de herramienta, debería devolver DENY. Si se permite, la política no hace lo que crees.

Registra los resultados con el responsable del trabajo y repite las tres pruebas cada vez que cambie la política o la lista de herramientas. Si tus herramientas no permiten enviar fácilmente una llamada malformada, pregunta a Databricks cómo recomiendan probar ese caso.

Detente ante los rechazos por límite de tasa

Los límites de tasa de MCP se aplican a las solicitudes tools/call y se miden en consultas por minuto (QPM). Las llamadas que superan el límite devuelven HTTP 429. Sugerimos tratar un rechazo por límite de tasa en un trabajo desatendido como señal de que puede estar ocurriendo algo inesperado, como un bucle o un disparador que se activa con más frecuencia de lo previsto, y hacer que el trabajo se detenga e informe en lugar de reintentar en un bucle cerrado que solo acumula más llamadas rechazadas. A los equipos puede resultarles útil fijar límites de QPM por herramienta a partir de lo que necesita una ejecución normal más cierto margen, para que un rechazo sea lo bastante raro como para interpretarse como una señal real. Cuando haya que detener un trabajo a mitad de ejecución, nuestro runbook del interruptor de emergencia para agentes de IA explica cómo pararlo de forma limpia.

Limita la frecuencia con la que se activan los disparadores

Una condición como «más de 10 clientes pidieron esto» puede seguir cumpliéndose durante horas, y si cada nueva solicitud vuelve a activar el trabajo, acabas con un montón de ejecuciones casi idénticas. Los límites de QPM no ayudan aquí, ya que ralentizan las llamadas dentro de una ejecución sin impedir nuevas ejecuciones. Establece un intervalo mínimo entre ejecuciones y un tope diario. Las fuentes revisadas aquí no describen un ajuste integrado de debounce para los disparadores de Genie, así que consúltalo con Databricks y, si no existe, incorpora el límite en el propio trabajo.

Presupuestos: qué controlan y qué se les escapa

Los presupuestos de Genie solo cubren el uso de LLM

La documentación de presupuestos de Genie indica que los presupuestos controlan el uso de LLM, y que el cómputo utilizado para ejecutar consultas, como un SQL warehouse, se factura por separado y no está incluido. Para un agente de datos cuya tarea principal es ejecutar consultas, esa brecha puede ser grande: en la sesión de prueba de SELECT, descrita más abajo, el cómputo excluido fue la factura completa.

La documentación también indica que no se deben usar los presupuestos para garantizar un tope de gasto absoluto sobre los importes finales facturados, y que Databricks no se hace responsable de los costes incurridos por encima de los umbrales de presupuesto configurados. Los umbrales te ayudan a supervisar. No garantizan un límite.

Cada presupuesto admite un máximo de cuatro umbrales compartidos y 100 excepciones por usuario, y una cuenta puede tener un máximo de 1,000 presupuestos. Si cada equipo y cada trabajo van a tener su propio presupuesto, comprueba que tu diseño cabe en esos límites.

Asignaciones gratuitas y entidades de servicio

Databricks empezó a cobrar el uso de Genie Code por encima de una asignación mensual gratuita el 8 de julio de 2026. Un análisis independiente de SELECT indica que cada usuario identificado recibe cada mes 150 DBUs gratuitas de Genie Code para uso de LLM, equivalentes a unos $10 a $11 según el proveedor de nube y la región. SELECT también informa de que las entidades de servicio (service principals) no reciben ninguna asignación gratuita, de modo que cualquier uso de Genie vinculado a una entidad de servicio se factura desde la primera solicitud.

La brecha en la práctica

La sesión de prueba de SELECT muestra por qué el gasto en LLM y el gasto en cómputo necesitan un seguimiento separado. La sesión costó $5.12 a precios de lista: $4.34 en SQL Serverless y $0.77 en All-Purpose Serverless, con $0.00 en uso de LLM de Genie. Aun así, la sesión consumió unas 102 DBUs de uso de LLM de Genie, repartidas en 79.7 de Genie Code y 22.7 de Genie One y Agents, todo dentro de la asignación gratuita. Un presupuesto de Genie habría vigilado la parte gratuita y se le habría escapado la factura entera.

Una sola sesión no predice tus costes, pero muestra dónde está el riesgo. Nuestro playbook de AI gateway sobre enrutamiento, presupuestos y control de proveedores trata esa misma separación desde el lado del gateway.

Topes estrictos: confirma qué control se aplica

Una entrada del blog de Databricks sobre Unity AI Gateway describe topes de gasto estrictos que detienen automáticamente las solicitudes cuando se superan los presupuestos. La documentación de presupuestos de Genie describe umbrales que no deberías tratar como un tope absoluto. Ambas cosas pueden ser ciertas para productos o rutas de solicitud distintos, así que pregunta a Databricks cuál se aplica a los trabajos autónomos de Genie.

Ali Ghodsi, de Databricks, dijo a TechCrunch que los costes pueden controlarse mediante Unity AI Gateway, que permite a las empresas fijar límites de uso y sustituir modelos por otros de pesos abiertos más baratos.

El playbook previo al lanzamiento

Ejecuta las etapas en orden. No empieces una hasta que la anterior haya cumplido su criterio de salida.

Las programaciones van antes que los disparadores porque son predecibles y más fáciles de revisar. En la Etapa 5, una aprobación solo te protege si quien revisa lee lo que aprueba; nuestra guía para aprobar y detener ejecuciones de agentes desde el móvil trata la aprobación desde dispositivos móviles.

Preguntas abiertas que resolver con Databricks

Fase de lanzamiento y nube

Las fuentes revisadas no aclaran si cada capacidad autónoma está en disponibilidad general, en vista previa pública o en beta, y las condiciones de soporte varían según la fase. Además, las páginas de Databricks citadas en este artículo son las versiones para AWS, y no hemos comprobado el comportamiento en Azure ni en Google Cloud.

Identidad de ejecución

Las fuentes tampoco indican si los trabajos programados y activados por disparadores se ejecutan como su creador, como una entidad de servicio o como el usuario que hace la solicitud, y esa única elección determina a la vez el acceso a datos, los registros de auditoría y la facturación.

Piensa en el trabajo de informe semanal de abandono de clientes de antes. Si se ejecuta con la identidad de quien lo creó, hereda todo lo que esa persona puede leer, que suele ser más de lo que necesita un trabajo del peldaño Informar, y el registro de auditoría vincula su nombre a ejecuciones que nunca supervisó. Pasarlo a una entidad de servicio resuelve los problemas de auditoría y de ciclo de vida, pero SELECT informa de que las entidades de servicio no reciben asignación gratuita, así que el uso de LLM que habría cabido en la asignación gratuita de un usuario con nombre empieza a facturarse desde la primera solicitud. Ninguna de las dos opciones es incorrecta en todos los casos.

Contexto del benchmark

Databricks informa de que, en su benchmark con Turing, Genie respondió correctamente en el 91% de las ejecuciones de tareas, 1.6 veces la tasa del agente frontera más fuerte, usando menos de la mitad de tokens. La cobertura de Unite.AI sitúa al agente frontera más fuerte en el 58%, con una media para Genie de 431,829 tokens y 100.3 segundos por ejecución. Databricks advierte de que la prueba refleja un despliegue consolidado con conocimiento de negocio acumulado, y de que las diferencias pueden ser menores en despliegues nuevos o cuando bastan los esquemas de las tablas.

Previsiones de costes y controles cambiantes

SELECT cita una previsión de IDC según la cual las organizaciones G1000 se enfrentan a un aumento de hasta el 30% en costes de infraestructura de IA subestimados para 2027, impulsado menos por el gasto excesivo que por modelos de consumo opacos que la presupuestación estándar nunca tuvo en cuenta. Es una previsión, y la citamos a través de SELECT y no del informe original de IDC, pero aun así es un argumento para controlar el gasto en LLM y en cómputo por separado desde el primer día. Los controles de costes que Databricks ha prometido podrían cerrar algunas de las brechas anteriores, así que revisa esta checklist cuando estén disponibles.