En el comité de presupuesto, el gerente financiero celebra que bajó la factura del modelo de IA. El jefe de operaciones no celebra: su equipo sigue dedicando las tardes a corregir solicitudes que el agente marcó como atendidas.
Para controlar el costo de un agente de IA, mida cuánto cuesta resolver una solicitud completa, no cuánto cuesta responder un mensaje. Sume consumo del modelo, consultas a herramientas, reintentos y revisión humana. Después, establezca límites por tipo de solicitud y una transferencia definida cuando el agente no pueda continuar.
El tope mensual puede evitar una sorpresa en la factura. Pero no le dice si está pagando por trabajo terminado o por conversaciones que alguien más tendrá que resolver.
Un agente barato por mensaje puede salir caro por caso resuelto.
¿Dónde se está gastando la plata del agente?
Considere este recorrido como ejemplo: un cliente pregunta por su pedido en WhatsApp Business. El agente interpreta el mensaje mediante la API de OpenAI, consulta SAP y prepara una respuesta.
Falta un dato. El agente pregunta, recibe una respuesta ambigua, consulta otra vez y termina enviando la conversación a un analista. Esa persona debe leerla, verificar el pedido y volver a contactar al cliente.
El modelo pudo haber costado poco. La atención completa, no.
Cada intento agrega consumo y puede generar cargos en otros servicios. La transferencia agrega minutos humanos. Si el analista recibe una conversación sin contexto suficiente, también repite trabajo que parecía adelantado.
El mecanismo que suele quedar fuera del presupuesto es ese traslado de costos: la factura tecnológica baja mientras la carga de operaciones permanece. Incluso puede aumentar si ahora el equipo debe corregir respuestas, además de resolver solicitudes.
Antes de negociar tarifas, defina qué significa “resuelto”. Para una consulta de pedidos podría ser entregar el estado correcto, respaldado por el sistema, sin una reapertura por información errónea dentro del plazo acordado.
Enviar una respuesta no basta.
¿Qué límites necesita antes de atender más solicitudes?
Un presupuesto mensual no detiene a tiempo una solicitud que entra en un ciclo de consultas. Los controles deben funcionar dentro del recorrido.
En el ejemplo del pedido, el agente podría hacer una consulta inicial y un reintento si falla la conexión. Si falta el número de pedido, lo solicita. Si aun así no puede identificarlo, transfiere el caso. No sigue buscando sin una condición de salida.
Ese diseño necesita cuatro controles concretos:
- Consumo por solicitud: un máximo de llamadas al modelo y de información procesada.
- Uso de herramientas: consultas permitidas, reintentos y operaciones que exigen autorización.
- Costo acumulado: un umbral que detenga el recorrido automático y active la transferencia.
- Gasto del periodo: alertas y un límite que pause nuevas atenciones automáticas cuando corresponda.
Los límites deben ejecutarse en el sistema que controla el recorrido; escribirlos únicamente en las instrucciones del agente no garantiza que se cumplan.
Además, detener la automatización no equivale a resolver la solicitud. Debe quedar definido quién recibe el caso, en qué horario y con qué información: identidad validada cuando corresponda, consultas realizadas, resultados y motivo de la transferencia.
Si nadie puede recibirlo, el agente debe informar el estado real de la solicitud. No prometer una solución inmediata ni marcarla como terminada.
La cuenta que incluye el trabajo que salió mal
El cálculo operativo es sencillo:
Costo por caso resuelto = costo total de atención del grupo de solicitudes / casos resueltos y verificados de ese mismo grupo.
Lo difícil es no acomodar la cuenta.
Tome las solicitudes recibidas durante una semana y siga ese mismo grupo durante un plazo definido. Incluya lo consumido en intentos fallidos, casos transferidos y correcciones posteriores. En el denominador cuente únicamente las resoluciones verificadas.
Reporte también cuántas solicitudes siguen pendientes y cuánto tiempo llevan abiertas. Sin ese dato, el indicador puede parecer mejor simplemente porque el trabajo difícil quedó esperando.
Para valorar la intervención humana, registre minutos reales y acuerde con finanzas un costo por hora. Separe la configuración e integración iniciales del gasto recurrente, pero mantenga ambas en la evaluación económica.
Después haga el cálculo por tipo de solicitud. Consultar un estado de pedido y resolver una reclamación no requieren el mismo recorrido ni deberían compartir automáticamente el mismo límite.
¿Y si los topes impiden resolver los casos difíciles?
Puede ocurrir. Un caso complejo puede necesitar más consultas y aun así justificar su costo. La respuesta es ajustar el límite con evidencia, no eliminarlo porque hubo una excepción.
El método de Setapp es empezar por un proceso completo y medible, integrar antes de reemplazar y dejar en manos de una persona las decisiones con riesgo. Un presupuesto disponible no autoriza al agente a aprobar una devolución o modificar un pago por su cuenta.
La recomendación de medir costo por caso resuelto tampoco aplica igual a una investigación abierta o a una tarea creativa sin un final verificable. Allí conviene acordar un entregable revisado o un tiempo autorizado. Y si todavía no está definida la calidad aceptable, reducir consumo es una discusión prematura.
El lunes, reconstruya diez solicitudes
Sin comprar nada, reúna diez solicitudes recientes del mismo tipo. Revise cómo terminaron, qué consultas hicieron, cuántos reintentos necesitaron y cuánto tiempo humano consumieron.
Pida a operaciones y finanzas que acuerden qué cuenta como resolución y señalen el punto donde cada recorrido debió detenerse o pasar a una persona. Si no pueden reconstruirlo, el siguiente paso es dejar ese registro funcionando antes de aumentar el volumen.
Envíenos el recorrido de una de esas solicitudes y le indicamos dónde pondríamos el límite de consumo y qué falta medir para calcular su costo por caso resuelto.