← Todos los insights

Guía de arquitecturaEnfoque: España y Latinoamérica5 min de lectura

Controles de gasto de agentes de IA: cinco capas y cuáles detienen de verdad una factura

Guía práctica para controlar lo que gastan los agentes de IA: atribución, visibilidad, aplicación, optimización y revisión. Qué ofrecen AWS y Databricks.

Escuche este artículo · 6 min

Narración completa del artículo, generada con IA.

Un volante de válvula rojo, en duotono La Madre, junto a las palabras Freno al gasto
Foto: Wesha (Wikimedia Commons, Public domain)

Los controles de gasto de agentes de IA son los mecanismos que deciden quién paga las llamadas a modelos y el compute de un agente, quién puede ver ese gasto y qué ocurre cuando supera un límite. Importan más para agentes que para chat porque una tarea de un agente puede hacer docenas de llamadas a modelos, reintentar por su cuenta y ejecutarse de noche. Una comparación de precios por token no dice casi nada sobre lo que costará un agente.

Esta guía agrupa los controles en cinco capas, siguiendo la estructura que AWS publicó el 30 de octubre en su playbook para costes de Bedrock, y añade lo que Databricks y otros ya ofrecen. La columna más importante es la que los proveedores mencionan menos: la rapidez con la que actúa cada control.

Cinco capas de control del gasto de agentes011. Atribuir:quién lo gastó022. Observar:adónde fue033. Aplicar:qué lo detiene044. Optimizar:gastar menospor tarea055. Revisar:coste porresultado
  1. 1. Atribuir: quién lo gastó
  2. 2. Observar: adónde fue
  3. 3. Aplicar: qué lo detiene
  4. 4. Optimizar: gastar menos por tarea
  5. 5. Revisar: coste por resultado
Los nombres de las capas siguen el playbook de AWS del 30 de octubre de 2026. Solo la tercera capa detiene el gasto; las demás lo hacen visible o menor.

1. Atribución: cada llamada necesita un dueño

El gasto que no se puede atribuir no se puede controlar. El playbook de AWS atribuye el uso de Bedrock mediante identidades de IAM y etiquetas, de modo que el coste recae en un equipo, una aplicación o un usuario. Su principal advertencia es sobre identidades compartidas: cuando todos los agentes llaman a los modelos a través de un único rol de gateway, todo el gasto se atribuye a ese rol y la visibilidad por usuario desaparece salvo que el gateway transmita las sesiones de usuario. Bedrock tampoco aplica metadatos de solicitud, así que los esquemas de etiquetado se desvían salvo que un componente los inyecte de forma central.

Databricks ofrece etiquetas de compute serverless para el mismo propósito, actualmente en beta, y un nuevo identificador de compute en sus tablas de facturación para atribuir el gasto por objeto de compute.

2. Observabilidad: saber antes de la factura

Los informes de coste y uso de AWS llegan con un retraso de aproximadamente un día. Los logs de invocación y la telemetría ofrecen vistas casi en tiempo real, pero vienen de otra fuente y pueden no coincidir con la facturación. Las tablas de sistema y las alertas de presupuesto de Databricks están en disponibilidad general en AWS, Azure y Google Cloud, y la propia Databricks califica la monitorización de reactiva: avisa del sobregasto al día siguiente en lugar de evitarlo.

3. Aplicación: la capa que de verdad detiene una factura

Aquí es donde más difieren los controles, y la diferencia es el tiempo.

  • Las alertas de presupuesto avisan. No bloquean nada.
  • La aplicación asíncrona de IAM, en el diseño de AWS, revoca el acceso después de detectar un exceso. AWS señala que tarda de segundos a minutos, o hasta la siguiente renovación de credenciales, así que parte del gasto se registra después del límite.
  • Los límites síncronos en el gateway comprueban cada solicitud antes de que llegue al modelo y pueden rechazarla. Son la única parada dura, y añaden un componente en la ruta de la solicitud que debe desplegarse, escalarse y someterse a revisión de seguridad.
  • Los límites de tasa sobre compute, como los nuevos límites beta de Databricks para notebooks y trabajos serverless, fijan un techo a cuánto puede escalar una carga de trabajo. Databricks subraya que el tamaño es un máximo, no una asignación fija, y que los presupuestos compartidos para trabajo interactivo aún están por llegar.
  • Los controles de acceso deciden quién puede usar compute caro en primer lugar. Los controles de acceso al compute serverless de Databricks están en disponibilidad general.

Para entrenamiento y otro trabajo con GPU, AWS Batch ahora ofrece quota shares para trabajos de entrenamiento de SageMaker: los equipos pueden reservar capacidad, prestar capacidad no usada y tomar prestada de otros, con la preempción recuperando la capacidad prestada cuando su propietario la necesita. La preempción interrumpe trabajos en ejecución, así que el checkpointing pasa a formar parte del diseño de costes.

4. Optimización: gastar menos por el mismo trabajo

Las dos palancas grandes son el enrutamiento de modelos y el uso de caché. AWS ofrece cálculos concretos de caché para modelos Claude en US East a octubre de 2026: las lecturas de caché cuestan la décima parte del precio base de entrada en algunos modelos y la vigésima parte en otros, mientras que las escrituras de caché cuestan un 25 por ciento extra con una vida de cinco minutos y el doble con una vida de una hora. Diez llamadas contra un prefijo de prompt estable cuestan aproximadamente la quinta parte del precio sin caché; una caché escrita y nunca releída es puro sobrecoste.

El enrutamiento importa más para agentes que para chat. Mostramos cómo Databricks redujo los costes unitarios de programación con IA con fricción progresiva en el gateway en lugar de topes duros para sus mejores desarrolladores.

5. Revisión: coste por resultado, no por token

El playbook de AWS termina donde debe: con el coste por resultado de negocio exitoso. Un agente que es barato por llamada y necesita tres intentos por tarea no es barato. Defendimos lo mismo en precios de inferencia por tarea completada. La revisión es también donde se corrigen las capas anteriores: un equipo cuyo gasto sigue sorprendiendo a finanzas suele tener un problema de atribución, no un problema de modelo.

Preguntas que hacer a cualquier plataforma

  1. ¿Cuáles de sus controles bloquean una solicitud y cuáles solo la reportan?
  2. ¿Cuánto tiempo pasa entre cruzar un límite y que el límite surta efecto?
  3. ¿Se puede atribuir el gasto al usuario final cuando los agentes llaman a través de un gateway compartido?
  4. ¿Qué ocurre con una tarea de agente en ejecución cuando se alcanza su presupuesto: se detiene, se degrada a un modelo más barato o se pregunta a una persona?
  5. ¿Quién puede subir un límite y ese cambio queda registrado?

Para las cuotas y topes que las plataformas de modelos han añadido este año, consulte nuestro resumen anterior de guardrails de gasto de IA. La versión corta de ambos textos: ponga la parada dura en la ruta de la solicitud, atribuya cada llamada a un responsable y juzgue la factura por lo que lograron los agentes.

¿Tiene un caso de uso de IA detenido entre el prototipo y la producción?

Cuéntenos qué quiere poner en marcha. Le respondemos con próximos pasos honestos.

Conversemos sobre un caso de uso