por Rohit Agrawal, Shuyu Cao, Darming Zhao, Zack Siegel y Aaron Davidson
• En Databricks, gobernamos el gasto en IA a escala al enrutar cada agente de codificación a través de Unity AI Gateway, lo que brinda a nuestros equipos un único lugar para aplicar presupuestos, visibilidad y políticas en cada modelo y herramienta.
• Equilibramos la innovación con el control de costos, utilizando presupuestos diarios y mensuales separados que detienen el gasto descontrolado en IA, al tiempo que mantenemos la productividad de nuestros ingenieros con aumentos de presupuesto de autoservicio en lugar de cuellos de botella en las aprobaciones.
• Este modelo de gobernanza comprobado combina controles de gasto centralizados, observabilidad unificada y la aplicación de políticas basadas en datos para escalar la adopción de la IA sin ralentizar a nuestros desarrolladores.
En Databricks, la forma en que creamos software está cambiando rápidamente a medida que adoptamos de manera decidida la AI para la ingeniería. Miles de nuestros ingenieros utilizan agentes de codificación todos los días, alternando entre Claude Code, Codex, Cursor y otros, a menudo varios a la vez. Esa adopción es fantástica, pero genera un nuevo problema: el gasto en agentes de codificación es ahora uno de los elementos de más rápido crecimiento en R&D, y un solo bucle de automatización fuera de control puede consumir el presupuesto de un mes en una tarde.
Esta publicación comparte cómo solucionamos esto internamente, utilizando los mismos Unity AI Gateway Budgets que ofrecemos a los clientes. Debido a que cada agente de codificación en Databricks, independientemente de la herramienta o el modelo, dirige su tráfico a través de nuestra pasarela, podemos aplicar una única política de gasto en toda la flota sin tener que tocar las consolas de administración individuales de cada agente de codificación.
Las principales lecciones de la implementación de esto fueron:
Analicemos en detalle cómo llegamos aquí.
Nota: Las cifras en dólares de esta publicación son ilustrativas, no son nuestros números internos reales.
Cuando comenzamos nuestro proceso de gestión de costos, establecimos exactamente un límite: cada ingeniero tenía un límite de gasto mensual predeterminado (digamos, $500) y, cuando lo alcanzaba, presentaba una solicitud para aumentarlo. Esto suena razonable en el papel, pero descubrimos que, en la práctica, esta estrategia genera fricciones en todas partes.
Debido a que este límite también era nuestra única protección contra el gasto descontrolado, cada aumento de límite también se realizaba en los mismos incrementos de $500. Los usuarios intensivos tenían que presentar una nueva solicitud cada vez que alcanzaban su nuevo límite, a veces varias veces en un solo mes, y cualquier cantidad que superara los $2500 requería una revisión manual. Peor aún, cada aumento era permanente. Un ingeniero que cometía un error costoso o trabajaba en un proyecto de alto gasto mantenía un límite elevado de forma indefinida, lo que aumentaba silenciosamente la proporción de la empresa susceptible a cometer errores costosos. Además, no existía un proceso de emergencia para que los ingenieros pudieran desbloquearse por sí mismos ante tareas críticas y urgentes, como el uso de AI para depurar incidentes de clientes.
A nuestra escala, entre 500 y 1,000 ingenieros alcanzaban el límite cada mes. Eso significa cientos de tickets, cientos de sesiones de trabajo interrumpidas y un canal de Slack #ai-devtools muy descontento.
Antes de diseñar cualquier cosa, escribimos lo que realmente creíamos sobre el gasto en AI, y se redujo a dos principios:
Poner esto por escrito expuso el conflicto. Para detectar un gasto descontrolado, un límite debe ser lo suficientemente pequeño como para que unas pocas horas de accidentes lo activen. Pero un límite tan pequeño interrumpe constantemente el uso mensual normal. Ninguna cifra única puede cumplir ambas funciones.
Reestructuramos todo en torno a un principio simple: permitir que los ingenieros gasten sin impedimentos y solo intervenir en los dos tipos de desperdicio que realmente importan: el desperdicio a corto plazo y el desperdicio a largo plazo.
La solución para esos dos modos de fallo se asocia a dos presupuestos en Unity AI Gateway:
Un límite diario para detectar gastos descontrolados. Este límite es deliberadamente pequeño en comparación con el gasto mensual. Cuando un ingeniero lo alcanza, no asumimos que algo ande mal. Recibe una notificación de Slack, confirma que el gasto fue intencional y el límite se incrementa automáticamente en otro intervalo. Sin aprobaciones, sin tickets, sin esperas. Si el gasto fue un accidente, la notificación es exactamente la alarma que necesitaba. El presupuesto diario se restablece cada noche en nuestra hora de menor uso y se borra por completo al comienzo de cada mes.
Un límite mensual para regular el gasto extraordinario. Este límite se establece lo suficientemente alto como para que el ingeniero promedio nunca lo alcance. Superarlo significa que alguien solicita gastar significativamente más que sus compañeros, lo cual está bien, pero debe justificarse con una prioridad comercial específica. Estos aumentos pasan por la aprobación del gerente en lugar de un comité de aprobación centralizado y se presentan en unos pocos niveles generales en lugar de un sinfín de pequeños incrementos y, lo que es fundamental, tienen un límite de tiempo equivalente a la duración del proyecto. Cuando el proyecto finaliza, el límite vuelve a su estado anterior.
Los dos límites permanecen vinculados a través de una proporción fija. En nuestra implementación, un ingeniero que gasta de manera uniforme a lo largo del mes nunca activará el límite diario, ya que el presupuesto mensual dividido entre los días laborables se mantiene cómodamente por debajo del umbral diario. Si un gerente aumenta el límite mensual de alguien para un proyecto importante, su límite diario y su incremento aumentan proporcionalmente, de modo que la protección contra gastos descontrolados sigue siendo efectiva sin convertirse en una molestia.
En el fondo, el límite efectivo en cualquier momento es fácil de definir. El gasto de un usuario se rige por ambos presupuestos, por lo que se limitará al mínimo de dos límites: su uso en lo que va del mes más un incremento por gasto descontrolado, y su máximo mensual. Cuando un usuario es bloqueado, esa fórmula también nos indica exactamente en qué caso nos encontramos. Si alcanza el límite de gasto descontrolado, el uso se puede reanudar tras una confirmación de autoservicio. Si alcanza el máximo mensual, debe hablar con su gerente.
El límite diario solo funciona si el desbloqueo no presenta fricciones, por lo que dedicamos la mayor parte de nuestro esfuerzo de diseño a esa vía. Esto es lo que experimenta un ingeniero en la realidad.
Una de las ventajas es que una vez que un usuario supera aproximadamente el 90% de su límite diario, se vuelve elegible para un aumento antes de ser bloqueado. Llega una notificación de Slack con el contexto (lo que ha gastado hoy, cuál es su margen restante) y un único botón para confirmar que el gasto es intencional. Al hacer clic en él, el límite diario se incrementa inmediatamente en un intervalo. El mismo aumento automático está disponible desde nuestro portal de presupuesto interno y desde la CLI, que muestra la cuota diaria y mensual restante junto con los enlaces para aumentar cualquiera de las dos.
No hay límite en la cantidad de autoconfirmaciones por día. Un ingeniero que ejecute una carga de trabajo realmente pesada podría confirmar dos o tres incrementos en un solo día, y eso está bien. Cada confirmación es una señal humana deliberada que dice "sí, soy yo y tengo la intención de hacer esto". Un trabajo de cron no supervisado no puede hacer clic en un botón de Slack. El tamaño del incremento es importante aquí: si es demasiado pequeño, las notificaciones se convierten en ruido que acostumbra a la gente a hacer clic sin mirar; si es demasiado grande, la protección deja de proteger. Diseñamos el nuestro de modo que un ingeniero que gaste de manera uniforme con respecto a su presupuesto mensual nunca vea una notificación.
En el lugar de permitir que los límites fluctúen hacia valores arbitrarios por usuario, ambos presupuestos se desplazan a través de un pequeño conjunto de niveles fijos, implementados como membresía de grupo en la pasarela. Todos comienzan en el nivel básico y cada nivel superior eleva el umbral en un paso fijo. Esto mantiene el sistema legible: una lista de grupos responde quién está por encima del valor predeterminado y por cuánto.
Los dos presupuestos se desplazan a través de sus niveles de manera diferente, adaptándose a sus distintas funciones.
Los niveles diarios cambian automáticamente. Todos comienzan el mes en el nivel básico. Cada auto-confirmación asciende al usuario un nivel, y un trabajo programado también asciende a los usuarios de forma proactiva cuando su gasto se acerca a su límite actual, como máximo una vez al día, para que el uso normal nunca se interrumpa. Al final del mes, otro trabajo restablece a todos al nivel básico. El gran esfuerzo del mes pasado no se transfiere como margen para este mes.
Los niveles mensuales cambian de forma deliberada. Solo hay unos pocos, aproximadamente de 2x, 5x, hasta prácticamente ilimitados, y cada ascenso requiere la aprobación de un gerente o de un nivel superior. Los ascensos se limitan al proyecto que los justifica, normalmente por uno, tres o seis meses, y luego se revierten. Estos intervalos amplios obligan a tener una conversación real sobre el gasto, en lugar de pequeños incrementos que nadie revisa. Aumentar el nivel mensual también escala el incremento diario de manera proporcional, por lo que la protección contra descontrol de costos se mantiene calibrada.
La razón por la que esto funciona casi sin infraestructura personalizada es que Unity AI Gateway ya lo ve todo. Cada solicitud de cada agente de programación, ya sea que se dirija a Claude, GPT, Gemini o modelos de código abierto, se atribuye a una identidad de usuario y se mide en un solo lugar. Los presupuestos configurados para el gateway se aplican a todas las herramientas que utiliza un ingeniero, y el gasto no puede superar ninguno de los presupuestos aplicables. Esta última propiedad es la que implementa el comportamiento del "mínimo de los dos límites" de forma gratuita: definimos ambos presupuestos y ambos están vigentes en cualquier momento.
Los niveles diarios y mensuales se implementan asignando las anulaciones de límites por usuario del presupuesto a diferentes grupos. Y el ascenso de nivel se logra haciendo al usuario miembro del grupo del nivel superior, a través de la automatización diaria, las auto-confirmaciones y las aprobaciones de los gerentes.
Dado que el gateway almacena todos estos datos de uso en Unity Catalog, también obtenemos la parte de observabilidad de forma gratuita. Los gerentes ven el gasto a nivel de equipo en las mismas tablas de Lakehouse donde creamos nuestro benchmark interno de agentes de programación, y el departamento de finanzas ve una sola factura en lugar de cinco.
La cola de aprobación basada en interrupciones ha desaparecido. Bajo el nuevo modelo, esperamos que solo un pequeño grupo de nuestros usuarios más activos alcance el límite diario en un mes determinado, y cada uno de esos casos se resuelve con un solo clic de confirmación. Los aumentos de los límites mensuales han pasado de ser una tarea rutinaria recurrente por ingeniero a una decisión poco común, limitada al proyecto, que un gerente toma una sola vez.
Igual de importante es que los ingenieros dejaron de racionar. El objetivo de estos mecanismos de control nunca fue reducir el uso de la IA. Era eliminar el temor a costos ilimitados para poder seguir impulsando la adopción. El gasto es ahora algo que moldeamos con datos en lugar de algo que limitamos por precaución.
Seguimos ajustando las cifras a medida que evolucionan los patrones de uso, y los patrones que demostraron su eficacia internamente están sirviendo de base para el propio producto Budgets: ciclos de presupuesto diarios nativos, anulaciones temporales que vencen con el ciclo de presupuesto y un modelo de permisos que permite a los usuarios finales aumentar ellos mismos su propio límite diario directamente a través de la API de presupuestos con más flexibilidad que los grupos de anulación predefinidos.
También estamos trabajando para que la opción más costosa sea menos necesaria en primer lugar mediante un enrutamiento de modelos más inteligente, de modo que las tareas cotidianas se dirijan a modelos eficientes y los modelos de frontera se reserven para el trabajo que realmente los necesita. Hablaremos más sobre esto en una próxima publicación.
Si su organización está escalando agentes de programación y cada herramienta tiene su propia consola de presupuesto, la solución es la misma que usamos nosotros. El soporte para agentes de programación en Unity AI Gateway está disponible para todos los clientes de Databricks hoy mismo. Consulte la documentación para comenzar.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.