Cómo definir un presupuesto de uso para una función con IA

El presupuesto operativo de una función con IA debe partir de una tarea de negocio terminada y limitar el trabajo necesario para completarla. Estimar tokens no incluye por sí solo las consultas a fuentes, los intentos repetidos, el procesamiento documental ni la revisión humana. Muchas llamadas baratas pueden formar un flujo costoso.

Separá dos preguntas: cuánto cuesta un uso aceptable y qué impide que un uso inesperado siga consumiendo recursos sin control.

Definí la unidad antes de calcular volumen

Elegí una unidad reconocible para la persona responsable del producto, como un resumen documental aceptado o una clasificación de soporte completada. Contá también intentos fallidos y abandonados. Dividir solo entre respuestas exitosas del proveedor puede ocultar una función que obliga a repetir el trabajo.

Estimá por separado procesamiento de entrada y salida, consultas a fuentes, almacenamiento, herramientas y revisión. No mezclés cargos del proveedor con estimaciones de trabajo interno. Si la unidad es una conversación, especificá duración o cantidad máxima de turnos para que el cálculo tenga sentido.

Usá las tarifas vigentes del proveedor durante la implementación, sin asumir un precio universal. Amazon Bedrock documenta cuotas de inferencia basadas en tokens. Esas cuotas de capacidad son distintas del límite de gasto que impone tu aplicación; una no reemplaza al otro.

Ejemplo hipotético de presupuesto por tarea

Supongamos 8.000 tareas terminadas al mes para un ejercicio de planificación. El consumo estimado de proveedor e infraestructura sería de USD 0,04 por tarea, incluidos reintentos habituales: USD 320. Una reserva hipotética de USD 80 deja un presupuesto de procesamiento de USD 400.

Ahora suponé que el 10% requiere tres minutos de revisión. Son 40 horas de trabajo. Deben entrar en el plan de capacidad aunque no aparezcan en la factura del modelo. Estas cifras inventadas ilustran el cálculo: no son tarifas, una proyección ni resultados de 5e Labs.

Durante el piloto, medí costo por tarea intentada y por tarea aceptada. Un modelo más barato que produce más correcciones puede reducir un cargo y aumentar el trabajo necesario para completar el proceso.

Reservá capacidad antes de ejecutar solicitudes simultáneas

Aplicá las reglas de admisión en el servidor:

• Limitá tamaño documental, contexto recuperado, salida e iteraciones de herramientas.
• Definí cupos por usuario y organización, además de un límite global.
• Reservá el consumo estimado de forma atómica antes de enviar solicitudes concurrentes.
• Conciliá la reserva con el uso real, incluidos intentos fallidos.
• Limitá los reintentos y evitá que los del SDK se multipliquen con los de la aplicación.

Una alerta avisa, pero no necesariamente detiene trabajo. Para un límite estricto, rechazá o encolá solicitudes antes de enviarlas cuando el saldo no cubra el máximo configurado. Incluí las que siguen ejecutándose. Contrastá las mediciones locales con el registro del proveedor: pueden existir demoras o datos incompletos.

Decidí qué ocurre cuando se agota el cupo

Elegí una alternativa explícita: dejar el trabajo en cola, mostrar el formulario manual o desactivar el paso opcional de IA. No cambiés silenciosamente a un modelo de menor calidad sin comprobar que cumple los mismos criterios de aceptación. Conservá las funciones ordinarias del producto cuando sea posible.

Antes de aprobar el piloto, documentá la unidad, su trabajo máximo, el presupuesto mensual y quién puede ampliarlo. Revisá esas decisiones al planificar software a la medida y usá las mediciones del piloto para reemplazar los supuestos que más pesan en la estimación.