La nueva economía de la gestión de costos de la AI

Durante los últimos dos años, la historia en torno a la adopción de la IA empresarial se ha centrado principalmente en conseguir que las personas la utilicen. En los últimos meses, esa historia ha cambiado rápidamente en muchas organizaciones. La observabilidad de la IA, que antes medía el éxito según el volumen de tokens, empieza a medir el éxito según el retorno de la inversión, y las empresas que primero resuelvan la gestión de costos serán las que puedan escalar la IA sin que sus gastos superen sus ingresos.

En su esencia, la gestión de costos de IA es la práctica de medir, atribuir, controlar y optimizar el gasto en IA a través de modelos, agentes, aplicaciones y equipos. El objetivo no es simplemente usar menos tokens, sino maximizar el valor empresarial generado por cada dólar gastado. A medida que los agentes de IA asumen un trabajo más autónomo, esa disciplina se extiende cada vez más a la gestión del costo del razonamiento de los agentes, las llamadas a herramientas y los modelos que los impulsan.

Nos sentamos con Kevin Stumpf, Senior Staff Engineer en Databricks y líder técnico de Unity Gateway, para hablar sobre cómo los equipos deberían poner en práctica esa disciplina: no tratando el costo de la IA como un gasto que hay que minimizar, sino como un sistema que hay que gestionar.

Del tokenmaxxing al valuemaxxing

Las redes sociales están llenas de líderes que argumentan que el "tokenmaxxing", es decir, ejecutar la IA al máximo y con la mayor frecuencia posible, es la forma correcta de acelerar la innovación. Aparte de las obvias implicaciones de costo, ¿por qué es esa una forma equivocada de pensar en la adopción de la IA?

Kevin Stumpf: La industria está pasando del tokenmaxxing al valuemaxxing. En los primeros días, había tablas de clasificación públicas que mostraban cuántos tokens consumía la gente, y en ese momento eso tenía sentido como estrategia. Mucha gente se resistía a empezar a usar la IA, por lo que mostrar que los líderes a los que todos admiraban eran grandes usuarios de IA dio a otros un motivo para seguir sus pasos. Si veo que alguien a quien respeto usa muchísima IA, quiero ser como esa persona.

Pero el sistema fue manipulado. Una vez que estar en la cima de la tabla de clasificación se convirtió en un símbolo de estatus, la gente se dio cuenta de que la forma más rápida de llegar allí no era hacer un buen trabajo, sino generar volumen. Desplegar un agente básico que se ejecute en bucle, hacer que pregunte cuál es el clima una y otra vez, y consumir tokens sin hacer esencialmente nada. Ese era el resultado predecible de una estructura de incentivos que recompensaba el uso bruto en lugar de los resultados.

Ahora que las organizaciones están plenamente convencidas del valor de la IA, la conversación se ha desplazado hacia un uso responsable y eficaz. Lo que realmente deberíamos construir es un tipo diferente de tabla de clasificación, una que clasifique a las personas por el impacto que generaron con la IA dividido por lo que costó generarlo. Eso es el retorno de la inversión, y es algo mucho más difícil de cuantificar que el conteo bruto de tokens, pero es el número que realmente importa. Relacionado: ¿Qué impulsa la adopción de la IA en las empresas?

Qué significa realmente la atribución de costos en la práctica

¿Puedes explicarnos qué significa realmente la "atribución de costos" en la IA?

Kevin Stumpf: En última instancia, la atribución de costos de IA consiste en responder a dos preguntas: ¿de dónde procede mi gasto y qué he obtenido a cambio? En el nivel más sencillo, esto significa atribuir el costo a un usuario individual o a un equipo, como un equipo de ciencia de datos o un equipo de ingeniería de software. También puede asignarse a un proyecto específico o a un nodo del organigrama, como entender cuánto gasto corresponde a un VP de IA frente a un SVP de ingeniería.

El objetivo es tener una visibilidad lo suficientemente granular como para poder analizar los datos desde todos los ángulos y entender de dónde procede realmente el costo, porque no se puede gestionar lo que no se puede medir. Databricks ofrece atribución de costos lista para usar por usuario, grupo, agente, endpoint de AI gateway, modelo, proveedor y período de tiempo. Pero las organizaciones también pueden personalizarla al máximo mediante etiquetas a nivel de solicitud. Una etiqueta puede representar cualquier cosa que le importe a su organización, como una pull request específica, una función o un cliente externo, y una vez que cada solicitud lleva esa etiqueta, puede agregar el gasto en función de ella como lo necesite.

Ese cambio en la percepción de los clientes ha sido real. Hace seis meses, la principal preocupación era quedarse atrás en la adopción de la IA. Ahora es todo lo contrario: la IA suele utilizarse para cosas irrelevantes, los costos crecen más rápido que los ingresos y los líderes se preguntan cómo aplanar esa curva de costos antes de que afecte a la rentabilidad. Esto no es algo hipotético. Es una conversación a nivel de junta directiva en casi todas las organizaciones con las que hablamos, incluso internamente en Databricks.

Controlar la saturación de contexto

A menudo se culpa al uso de tokens y al tamaño de la ventana de contexto, pero rara vez se explican bien. ¿Cómo se ve realmente la saturación de contexto en un sistema de producción y cuál es la solución práctica?

Kevin Stumpf: La saturación de contexto significa proporcionarle a un agente mucha más información de la que necesita para tomar una buena decisión. Eso es un problema por dos razones. En primer lugar, consume tokens innecesarios. En segundo lugar, resulta distractor: el agente tiene que procesar esa información adicional y decidir si es relevante, lo que supone su propio tipo de sobrecarga. No es muy diferente de entregarle a una persona un montón de documentos irrelevantes y pedirle que determine qué es lo importante antes de que pueda empezar la tarea.

La mejor solución no es recortar o almacenar en caché a posteriori, sino evitar generar la saturación desde un principio. Un patrón común y eficaz consiste en dejar que el agente obtenga el contexto relevante bajo demanda, a través de herramientas, servidores MCP o habilidades, en lugar de enviarle proactivamente todo lo que podría necesitar por adelantado. Por defecto, solo deberías enviar contexto a un agente si tienes un 90% de certeza o más de que es genuinamente importante para la tarea en cuestión. De lo contrario, informa al agente sobre lo que está disponible y permítele obtener lo que necesita cuando lo necesite.

Enrutamiento dinámico de modelos y harness

La selección de modelos suele ser una decisión que se toma una sola vez. ¿Por qué debería ser dinámica en su lugar y cómo decide el enrutamiento inteligente, en tiempo real, si una tarea necesita un modelo de frontera o algo más económico y rápido? ¿Se extiende esa misma idea a la elección entre diferentes harness de agentes?

Kevin Stumpf: La optimización de costos de IA no consiste en elegir siempre el modelo más barato, y los equipos deberían inclinarse por elegir el modelo o harness de menor costo que pueda ofrecer la calidad que requiere la tarea. La realidad actual es que los modelos de frontera son extremadamente capaces y costosos, mientras que los modelos que no son de frontera siguen siendo muy capaces, solo que menos costosos. Aproximadamente entre el 5% y el 10% de las tareas realmente necesitan un modelo de frontera, ya sea porque hay mucho en juego y se desea el mejor resultado posible, o porque el problema es demasiado complejo para algo inferior. El otro 90% de las tareas se pueden resolver con modelos más sencillos, ya sean modelos de código abierto que aloje usted mismo o familias de modelos más económicas de los principales laboratorios.

Si se deja a su propio criterio, la mayoría de los empleados elegirá por defecto el modelo más costoso disponible, porque su objetivo es simplemente resolver el problema y nadie controla lo que les cuesta individualmente. Smart Routing soluciona esto insertando una capa que evalúa la complejidad de la tarea en tiempo real y decide si una solicitud debe dirigirse a un modelo de frontera o a uno de menor costo, con el objetivo de mantener la misma calidad de respuesta a un costo menor.

El enrutamiento de harness es el siguiente nivel después del enrutamiento de modelos. Existen investigaciones recientes que muestran que el mismo modelo, ejecutado a través de un harness diferente, puede generar costos significativamente distintos. Esto tiene sentido, ya que el harness determina cómo interactúa el modelo con su entorno: qué reglas sigue, cuándo reduce la ventana de contexto, qué lógica empresarial rige su comportamiento. Todo eso afecta directamente a la cantidad de tokens que se consumen. El enrutamiento de harness es el siguiente paso en esa evolución paulatina de optimización de costos, la cual habilitamos a través de Unity Gateway y Omnigent, nuestro meta-harness.

Diseño de límites de protección para el gasto

Hablemos de los límites de protección para el gasto en sí, como topes estrictos, presupuestos y límites de tasa. ¿Cuál es la forma correcta de diseñarlos para detener el descontrol de costos sin perjudicar la productividad de los desarrolladores ni interrumpir los flujos de trabajo en producción?

Kevin Stumpf: Algunas reglas se aplican a todas las organizaciones, mientras que otras dependen del caso de uso o de la empresa. Todos deberían contar con topes de gasto estrictos para controlar el uso desmedido. Si un usuario intensivo habitual gasta como máximo unos $300 al día en IA, establezca el tope estricto un poco por encima, tal vez en $500. Ese margen le da espacio para detectar errores reales, como un agente que se quedó ejecutándose en bucle por accidente, sin limitar los días legítimos de uso elevado.

Más allá de esa línea base, tiene mucho sentido diferenciar los presupuestos por equipo o proyecto. Un equipo que trabaja en algo crítico para el CEO podría justificar un presupuesto mucho mayor que un equipo que trabaja en tareas de menor prioridad, y esa decisión debe sopesar el valor de lo que produce ese equipo frente al costo de darles un mayor margen de maniobra.

Los presupuestos también deberían ser capaces de activar diferentes tipos de respuestas, no solo un límite estricto. Pueden enviar alertas, aplicar límites máximos o reducir la capacidad disponible del modelo, por ejemplo, cortando el acceso predeterminado a los modelos de frontera una vez que un equipo haya consumido el 70% de su presupuesto y redirigiendo el resto de sus solicitudes a modelos de código abierto. Los principios fundamentales que se aplican en todas partes: evitar el gasto descontrolado, establecer límites diferenciados por grupo o proyecto, alertar antes de limitar e incorporar una reducción inteligente de capacidad en lugar de un cierre abrupto.

Medir lo que la AI realmente ofrece

¿Qué plataformas ofrecen monitoreo de agentes y seguimiento de costos de forma conjunta, y hasta dónde puede llevarte esa visibilidad para medir el ROI real, no solo el gasto?

Kevin Stumpf: Medir el costo es mucho más fácil que conectar ese costo con el retorno de la inversión, y esa es la pregunta que todos quieren responder y que casi nadie ha resuelto por completo. El etiquetado a nivel de sesión o de solicitud es lo que hace esto posible. Si un agente está trabajando en un pull request específico, puede etiquetar su sesión o las solicitudes específicas que genera con el identificador de ese pull request. Esa atribución se devuelve a un panel de control de costos, para que puedas ver, por ejemplo, que un pull request determinado costó $300 completarse. Esto es algo que ya estamos haciendo internamente en Databricks.

En un estado ideal, y esto es algo que estamos incorporando al producto Unity Gateway, puedes ir un paso más allá y conectar ese pull request con una función específica, y esa función con un resultado medible, como cuántos ingresos o pipeline generó en un período determinado. Ese es el santo grial: no solo saber cuánto costó la AI, sino saber cuánto devolvió. Con Unity Gateway, ya contamos con una plataforma altamente personalizable sobre la cual construir esto, y estamos invirtiendo para que esa vista de costo a retorno esté disponible de forma predeterminada, en lugar de ser algo que los equipos tengan que construir por sí mismos.

La visibilidad del gasto requiere un sistema centralizado

Para una empresa que ejecuta múltiples modelos, agentes y herramientas en muchos equipos, ¿qué requiere realmente una buena visibilidad del gasto? ¿Es un problema de panel de control, de gobernanza o de FinOps?

Kevin Stumpf: Una buena visibilidad del gasto requiere que cada interacción de AI fluya a través de un sistema centralizado. Eso es lo que te permite asegurar la información correcta de manera consistente, para que puedas construir paneles de control y alertas confiables sobre ella. Un gateway de AI proporciona un punto de control centralizado para la gestión de costos de AI en todos los modelos, agentes, herramientas y equipos. Databricks Unity Gateway está diseñado para proporcionar ese punto de control centralizado en modelos, agentes, herramientas y agentes de código. Cuando las interacciones de AI fluyen a través de un punto de control común, las organizaciones pueden observar el uso, atribuir costos, hacer cumplir los presupuestos y optimizar el gasto en un solo lugar.

Pero tener el sistema centralizado no es suficiente por sí solo. También necesitas una forma de hacer cumplir que todos realmente enruten su tráfico de AI a través de él. La visibilidad solo funciona si la adopción es universal, no opcional.

Equilibrar la optimización de costos y la calidad de los resultados

El control de costos no puede lograrse a expensas de la calidad o la confiabilidad. ¿Cómo sabes cuándo una optimización ha ido demasiado lejos y ha comenzado a perjudicar los resultados?

Kevin Stumpf: Eso depende genuinamente del caso de uso. Necesitas un mecanismo de retroalimentación, y puede ser subjetivo u objetivo. La retroalimentación subjetiva es anecdótica, alguien del equipo diciéndote que no puede realizar el trabajo con el presupuesto actual. Eso es rápido de obtener pero fácil de descartar como la queja de una sola persona. La retroalimentación objetiva proviene de evaluaciones automatizadas, que son más difíciles de configurar pero mucho más confiables.

Para un caso de uso común como los agentes de código, eso podría significar definir una métrica indirecta de calidad, como los pull requests fusionados que no se revierten en un plazo de dos semanas. A partir de ahí, puedes experimentar: reducir el presupuesto a la mitad y ver si esa métrica clave cambia, se mantiene estable o incluso mejora, ya que las restricciones a veces estimulan la creatividad. Realizar experimentos paralelos en varios equipos con diferentes presupuestos, modelos y entornos (harnesses), o comparaciones con límite de tiempo a lo largo de pocas semanas, te permite inferir si un presupuesto determinado está creando valor o destruyéndolo, en lugar de adivinar.

El valor del rastreo de extremo a extremo

¿Qué papel desempeñan aquí el rastreo y el monitoreo de extremo a extremo? Una vez que puedes ver prompts, llamadas a herramientas y uso de tokens a lo largo de todo el flujo de trabajo de un agente, ¿qué permite esto que no podías hacer antes?

Kevin Stumpf: El rastreo consiste en recopilar todo el rastro de lo que hacen los agentes: qué están pensando, a qué herramientas están llamando, qué datos están extrayendo, si los prompts son buenos o malos. Esos datos sin procesar son los que puedes analizar para obtener información valiosa, ya sea identificando abusos, desperdicios, filtraciones de seguridad o simplemente patrones que nunca pensaste en buscar.

Esto refleja lo que sucedió en la industria de datos en general. Al principio, solo teníamos datos limpios y estructurados en bases de datos. Luego vinieron los data lakes, que durante un tiempo se convirtieron en pantanos de datos (data swamps) porque las personas volcaban datos no estructurados en ellos sin una forma de extraerles valor. Con el tiempo, esos pantanos se convirtieron nuevamente en data lakes utilizables, y ahora estamos en una mejor posición que nunca para extraer información de datos no estructurados y semiestructurados, en gran parte porque los LLMs son lo suficientemente flexibles para procesarlos. Los rastreos de agentes caen en esa misma categoría. Cuanto más recopiles, más información estará disponible y será más fácil acceder a ella que nunca.

Escalar a flotas de agentes

Muchas empresas están pasando de aplicaciones de AI únicas a flotas de agentes. ¿Ese cambio altera la ecuación de costos (¿nuevos generadores de costos? ¿nuevos puntos ciegos?) en comparación con la ejecución de un solo modelo detrás de una aplicación?

Kevin Stumpf: No cambia tanto la ecuación como la multiplica. Los enjambres de agentes van a ser la nueva realidad, y cada uno de esos agentes gastará tokens que deben ser atribuidos, monitoreados y gestionados. Ahora mismo es el momento de establecer las bases adecuadas de visibilidad y gestión de costos, antes de que el número de agentes en producción crezca de la manera en que está proyectado.

Los agentes de código son la categoría dominante que consume tokens hoy en día, pero eso se va a expandir a muchas otras clases de agentes que realizan trabajo autónomo las 24 horas del día, agentes que llaman a otros agentes que llaman a otros agentes. Las organizaciones que esperen a construir una infraestructura centralizada de observabilidad y gestión de costos de AI hasta que llegue esa complejidad, la construirán bajo presión, en lugar de hacerlo en sus propios términos.

Si tuvieras que dejar a los líderes de AI empresarial con un cambio de mentalidad sobre la gestión de costos de cara al próximo año, ¿cuál sería?

Kevin Stumpf: No esperaría al próximo año. Esto es urgente y debería tratarse así a partir de ahora. Si tuviera que resumirlo en una sola idea, es esta: no puedes gestionar lo que no mides. Eso se aplica a las materias primas, se aplica a las personas y se aplica igualmente a la AI. La AI se está convirtiendo rápidamente en una de las partidas más importantes en el estado de flujo de efectivo de una empresa, y debe estar completamente instrumentada para que pueda medirse y, a su vez, gestionarse. Es solo otro ingrediente básico en el sistema que produce los bienes o servicios de tu organización, y merece ser tratado con la misma disciplina.

El tiempo corre desde ahora Controlar los costos de AI en varios equipos que utilizan múltiples modelos y herramientas no es un problema que se resuelva con un solo panel de control o con la elección única de un modelo. Es una disciplina operativa: atribución lo suficientemente granular como para rastrear el gasto hasta una persona o un proyecto, enrutamiento que se adapta en tiempo real a lo que requiere una tarea, barreras de protección (guardrails) que detectan el gasto descontrolado antes de que se convierta en titular y un rastreo lo suficientemente detallado como para convertir los datos de uso sin procesar en información valiosa real. Las organizaciones que se están adelantando a esto no son las que gastan menos en AI. Son las que pueden decir, con confianza, exactamente qué obtuvieron por lo que gastaron.

Obtén más información sobre cómo Unity Gateway centraliza la atribución de costos, el enrutamiento inteligente y las barreras de protección de gasto en todo tu entorno de AI.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original