ROI de agentes de IA: cómo medirlo antes del piloto

El problema: por qué el costo salta cuando el piloto pasa a producción

El ROI de agentes de IA no falla en la prueba de concepto. Un workflow de agente funciona con una belleza pilotada sobre unas dos docenas de casos, y la factura disfrazada de modernización llega cuando ese mismo workflow pasa a correr el mes entero, contra el dato real, con excepciones, aprobaciones humanas y retrabajo que el piloto nunca tocó. El costo por tarea estalla justo ahí, en el punto donde la cuenta deja de ser técnica y se vuelve balance.

El alcance de esta guía es uno solo: decidir si el piloto pasa a producción con la regla financiera del costo por tarea automatizada y del valor por tarea automatizada de cada workflow, dejando la elección técnica de modelo y la tabla de precio por token en etapas anteriores que esta lectura no vuelve a abrir.

Casi toda empresa que escala un agente sabe cuánto gastó para construir el piloto. Muy pocas saben el costo por tarea automatizada después de que entró en producción, porque nadie definió la unidad de medida antes. Sin esa unidad, el debate sobre ampliar se vuelve opinión. Con ella, se vuelve aritmética.

La evaluación técnica del modelo, esa la resuelve Nexforce en el post que sigue a la elección de las métricas para evaluar agentes antes del piloto, con el ángulo de B2B que este artículo asume como paso previo. Aquí el piloto ya pasó por eso. La pregunta cambió de naturaleza y pasó a ser financiera: cuánto cuesta una tarea ejecutada por el agente, cuánto vale, y dónde cruzan los dos números. El resto es teatro de gestión.

Definir el costo por tarea automatizada antes de ampliar no es una vanidad de la controlaría. Es la única forma de impedir que el gate de escala se decida por el entusiasmo de quien presentó el piloto en lugar de por el número que lo produce.

La unidad de medida: costo por tarea automatizada de cada workflow

Costo por tarea automatizada es todo el desembolso necesario para que una sola ejecución de un workflow de agente complete su trabajo con un estándar aceptable, sumando el consumo de modelos en la capa de infraestructura, el retrabajo sobre ejecuciones que fallaron y el costo de las aprobaciones humanas que la gobernanza exige. No es el precio de un modelo.

El giro conceptual consiste en tratar el costo por el workflow del agente y no por token ni por modelo. El token es una variable de infraestructura; lo que el negocio compra es la tarea concluida. Un workflow de conciliación que procesa una remesa, un agente de soporte que cierra un ticket, un agente de coding que cierra un pull request, cada uno de esos produce algo que se puede nombrar y fijar su precio. El token que pasa por el medio es un detalle interno, no el producto.

En las cuentas de costo por tarea entran tres componentes que necesitan un dueño explícito.

El primero es el consumo de modelos, medido en la capa Router en la que corre el agente, con rastreo completo por llamada. El segundo es el retrabajo: la fracción de ejecuciones que exigen un nuevo intento, un ajuste de prompt o una corrección de salida, y cuánto de eso consume tiempo humano. El tercero es la aprobación humana obligatoria, que tiene el costo real de que alguien revise la ejecución antes de que se libere.

La atribución a un workflow específico depende de la granularidad de la telemetría. Un agente solo en el workspace, corriendo una plantilla, se aísla con facilidad. La dificultad empieza cuando un gateway rutea muchos agentes, porque es preciso rescatar cada ejecución por su workflow de origen y no por la clave de consumo. Nexforce Code, por ejemplo, permite que los desarrolladores comprueben cuánto tiempo dedicó un dev a retrabajar lo que entregó el agente, porque el runtime agéntico corre en el flujo del propio desarrollador.

El retrabajo es el villano silencioso del costo por tarea. Un modelo barato que se equivoca en 1 tarea de cada 20 parece magnífico hasta que la cuenta suma las iteraciones humanas sobre cada error. El costo del token equivocado casi nunca aparece en la factura del modelo; aparece en horas de desarrollo.

El otro lado de la cuenta: el valor de la tarea automatizada

Valor por tarea automatizada es lo que la ejecución devuelve a la operación en horas recuperadas, throughput adicional y penalizaciones de SLA evitadas, monetizado de forma rastreable y no como promesa de eficiencia. Es el numerador del ROI, y necesita medirse tanto como el costo, porque un piloto barato que no entrega valor es solo un despido diferido.

El error más común aquí consiste en confundir tiempo ahorrado con valor capturado. Una hora devuelta solo se vuelve valor cuando la operación usa esa hora en otra tarea productiva. Si el equipo liberado queda ocioso, lo que se automatizó fue un costo que no se convertía en ingreso. La pregunta correcta sobre el agente no es cuántas horas ahorra, sino qué hace la empresa con la hora que le sobra.

Un ejemplo de trabajo fija la unidad: un workflow de agente que automatiza la verificación de facturas y pedidos en un mid-market B2B. En ese agente, cada ejecución reemplaza una revisión manual que consumía, en la carga observada, algo así como 12,7 minutos de un analista de cuentas por pagar por cada verificación, contra un costo por tarea automatizada cercano a R$ 0,36 sumando modelos, retrabajo y liberaciones.

Un número no redondo merece un alcance explícito: los R$ 0,36 de costo por tarea y las horas recuperadas son una estimación de orden de magnitud construida para esta guía a partir de premisas declaradas de carga y de valor-hora, y no un dato oficial de un cliente de Nexforce. Sirve para mostrar la aritmética, no para convertirse en benchmark de contrato. El valor-hora del analista entra al cálculo ya con cargas sociales.

La otra cara del valor es lo que no sucede. Una verificación atrasada dentro de una rutina de pago dispara una multa de SLA o traba el cierre; el agente que evita la repetición de un retraso tiene un valor que jamás se ve en un panel de minutos, porque aparece como una multa que no se pagó. Ese es el centro de la operación donde el agente gana su costo.

El valor por tarea automatizada también cambia de naturaleza según el tipo de agente. Para un agente de coding en Nexforce Code, el valor se mide en el tiempo de desarrollo recuperado para tareas de mayor complejidad. Para un workflow de negocio en Nexforce Work, el valor está en el throughput del equipo y en el SLA honrado. La unidad es la misma; lo que llena el numerador difiere por workflow.

Punto de equilibrio y el gate de escala: cuándo el número justifica ampliar

El punto de equilibrio de automatización es el lugar donde el valor por tarea automatizada, multiplicado por el volumen, cubre el costo fijo de llevar un workflow del piloto a la producción y el costo por tarea en escala. El gate de escala es el umbral financiero que la empresa declara antes de medir y confirma después, sin aceptar un ajuste de meta durante la medición.

Ninguna empresa debería ampliar un piloto porque funcionó. Debería ampliarlo porque el número aguantó el volumen. La diferencia entre las dos decisiones es exactamente el gate: un umbral en blanco y negro definido antes de que lleguen los primeros datos reales, para que el resultado no se interprete a medida después. Definirlo después equivale a no definirlo.

La regla es simple y dura. Quien fija el umbral del gate antes del piloto y mide después tiene una prueba honesta. Quien empieza a medir sin un umbral predefinido y descubre el punto de equilibrio a los golpes está solo patrocinando un laboratorio caro que nunca fue diseñado para decidir. El puesto que decide esa autonomía en producción es asunto de la gobernanza de agentes en producción de Nexforce, pero el filtro financiero es otro y viene antes.

Un workflow de agente merece pasar a escala cuando el costo por tarea automatizada cae de forma estable con el volumen y el valor por tarea automatizada se sostiene sin que el retrabajo humano crezca a la par. Traducido en dinero: el punto de equilibrio calculado sobre R$ 41.500 de costo fijo para llevar el workflow a producción, dividido por un margen neto de R$ 2,98 por tarea automatizada, devuelve la inversión en 13.926 tareas de punto de equilibrio. Para un volumen típico de 2.000 tareas por mes, algo próximo a 7 meses de operación en escala. La cuenta entera se redondea hacia abajo.

Aquí aparece la prueba que separa la decisión de la esperanza. Cuando el piloto cuesta poco por correr en un volumen pequeño, el costo fijo de gobernanza se vuelve la barrera real, y es él el que debe ser honesto. Si el margen por tarea automatizada es cómodo en un piloto de 200 casos pero se desploma cuando crece el retrabajo, lo que el gate muestra es la necesidad de volver al diseño del workflow, no de empujar volumen dentro de un proceso roto.

Ampliar de forma responsable no lo decide el costo fijo ni el volumen por separado, sino el cruce de los dos. Un workflow con margen alto sobre una tarea inútil es peor que otro con un margen menor sobre una tarea que resuelve un cuello de botella real. El gate de escala mide eso al exigir que el workflow pase el umbral de volumen y de margen al mismo tiempo antes de recibir más capacidad.

Un workflow sin margen por tarea automatizada no cambia de nombre cuando llega el volumen.

Rastreo del gasto por workflow de agente: quién es dueño de cada ejecución

Rastreo del gasto por workflow de agente significa registrar, para cada ejecución de cada workflow, quién la disparó, quién la aprobó y cuánto consumió, para que el área financiera pueda auditar la responsabilidad del gasto sin depender de quién lo recuerde. Sin ese rastro, el costo por tarea automatizada es un promedio que borra quién gastó.

La capa de aprobaciones y permisos de Nexforce Work es el mecanismo que permite localizar quién aprobó cada ejecución de workflow. Ese es el punto de unión entre la responsabilidad financiera y la operación: toda tarea que exige una liberación lleva el registro de quién la liberó, así que la pregunta de quién es dueño del gasto tiene respuesta en el sistema, no en una reunión.

La responsabilidad del gasto se divide en dos plantas y conviene decir cuál es cuál. En la planta del workspace, la contención de costo viene de la ejecución sandboxed y de las aprobaciones y permisos de Nexforce Work, que limitan dónde puede correr un agente y qué puede hacer. En la planta de infraestructura, cuando la conversación toca el consumo de modelos, el techo de gasto y el rastro por clave son funciones de Nexforce Router, la capa en la que el agente consume modelos. Las dos protecciones cooperan; el dueño de cada una no se confunde. Quien quiere la separación completa de permisos y el perímetro de acceso por agente encuentra en permisos y rastreabilidad de agentes la lectura de autorización por acción.

El área financiera necesita una pregunta resuelta antes de liberar presupuesto para ampliar: cuántos workflows existen y cuál es el costo por tarea automatizada de cada uno aislado. Cuando la respuesta es un gasto agregado que mezcla diez workflows, el auditor no puede decidir cuál cortar. La telemetría granular por workflow transforma esa niebla en línea por línea, y es esa granularidad la que sustentan el rastro de la capa de aprobación y la traza de consumo por clave.

El rastro también cambia la conversación con quien opera. Un líder de área que corre agentes en Nexforce Work pasa a saber, por workflow, lo que consume cada rutina, en lugar de recibir una constatación de fin de mes sin cara. Empoderado por el dato, deja de pedir disculpas por el gasto y se dedica a explicar el valor que el gasto genera. La responsabilidad financiera bien medida no achica al agente; entrega un argumento.

Sin rastro, lo que sucede es previsible: un workflow de bajo valor pero alto consumo sobrevive porque nadie puede señalar con el dedo. Con rastro, el gasto de cada workflow tiene dueño, y el dueño responde por él al mismo ritmo con que responde por el presupuesto de las herramientas tradicionales.

Framework completo de ROI: la tabla de comparación y el paso a paso

Un framework de ROI de agentes de IA compara, lado a lado, el costo por tarea automatizada con el valor por tarea automatizada de cada workflow, y decide por el cruce con el gate de escala. No necesita un único número de retorno; necesita una regla que se aplique a todos los workflows de la misma forma.

La tabla de abajo organiza las dos caras de la unidad económica por workflow y el veredicto que entrega cada combinación. Los valores de costo y de margen siguen el ejemplo ilustrativo de la guía, con alcance explícito de estimación y premisas declaradas, nunca como dato oficial de un cliente.

El paso a paso que sigue convierte la tabla en un proceso repetible. Cada paso es discreto y verificable, y el conjunto alimenta el esquema HowTo de este artículo:

Paso 1. Lista los workflows de agente en producción-piloto y dale a cada uno un dueño financiero nombrado. Un workflow sin dueño no entra a la medición.

Paso 2. Define, por workflow, la ecuación del costo por tarea automatizada con los tres componentes de modelos, retrabajo y aprobaciones, y registra la fuente de cada dato para la auditoría futura.

Paso 3. Define, por workflow, el valor por tarea automatizada con horas recuperadas y reales, throughput y SLA evitado, monetizado por el valor-hora ya con cargas, sin inventar aprovechamiento.

Paso 4. Establece el umbral del gate de escala antes de medir: el volumen mínimo mensual sustentable y el margen neto mínimo por tarea automatizada que justifican ampliar.

Paso 5. Corre el piloto durante al menos un ciclo completo en producción, colectando el costo y el valor reales de cada workflow por telemetría, con el rastro de la capa de aprobaciones de Nexforce Work.

Paso 6. Compara el resultado medido con el umbral predefinido, workflow por workflow, y amplía solo los que pasan de margen y de volumen al mismo tiempo.

Paso 7. Después de la ampliación, vuelve a medir durante 90 días para confirmar que el costo por tarea automatizada no subió con el volumen, porque es en ese intervalo donde aparece el retrabajo.

Cerrar este paso a paso exige que el workflow ya exista con una arquitectura de orquestación, y es allí donde la lectura de orquestación de agentes en empresas B2B entra como el fundamento que esta guía asume. Un framework de ROI solo mide lo que ya corre de forma orquestada y rastreable; el resto es optimismo con números.

Preguntas frecuentes sobre el ROI de agentes de IA

¿Cuál es la diferencia entre el costo por tarea automatizada de un agente y el costo por token? El costo por tarea automatizada de un agente suma el consumo de modelos en la capa Router, el retrabajo sobre ejecuciones fallidas y las aprobaciones humanas, y atribuye el total a un workflow. El costo por token mide solo el consumo de un modelo, que es una variable de infraestructura y no dice cuánto cuesta realmente una tarea concluida.

¿Cuándo escalar un piloto de agentes? Un piloto merece escala cuando el workflow pasa el gate predefinido: el volumen mínimo mensual sustentable y el margen neto por tarea automatizada por encima del umbral, los dos medidos después en producción y no estimados antes. El gatillo es el conjunto de las dos condiciones, jamás solo la emoción del resultado del piloto.

¿Cómo se calcula el punto de equilibrio de automatización? Divide el costo fijo de llevar el workflow a producción por el margen neto por tarea automatizada, que es el valor por tarea automatizada menos el costo por tarea. En el ejemplo de la guía, R$ 41.500 divididos entre R$ 2,98 dan 13.926 tareas de punto de equilibrio, cerca de 7 meses a un volumen de 2.000 tareas mensuales.

¿El costo por tarea automatizada cambia después de ampliar el piloto? Cambia, y por eso el gate define la medición durante 90 días después de la escala. El retrabajo y las excepciones tienden a crecer con el volumen real y con la diversidad de casos; un costo que parecía estable en el piloto puede subir cuando el workflow se encuentra con el dato del mundo entero.

¿Quién es responsable del gasto de cada workflow de agente? El dueño financiero nombrado de cada workflow, sostenido por el rastro de la capa de aprobaciones y permisos de Nexforce Work, que registra quién aprobó cada ejecución, y por el consumo por clave en la capa Router. La responsabilidad financiera exige esa granularidad, sin la cual el gasto no tiene responsable.

Llevar un piloto a Nexforce Agents es la forma de mantener esa disciplina con los mecanismos que el framework pide: la capa de aprobaciones y permisos de Nexforce Work para darle dueño al gasto y la granularidad de Nexforce Code para medir el tiempo de desarrollo recuperado. Quien quiere estructurar la medición antes de ampliar conversa con equipos que ya corren agentes en B2B agendando una conversación o arranca por la página de Nexforce Agents.

Referencias y lecturas complementarias

• World Economic Forum, AI Governance Alliance, Briefing Paper sobre gobernanza e implementación responsable de IA: weforum.org/publications/ai-governance-alliance-briefing-paper.
• Nexforce Agents, la unidad de desarrollo e implementación de agentes de IA en operaciones B2B: nexforce.ai/agents.
• Nexforce, métricas para evaluar agentes antes del piloto: metricas-avaliacao-agentes-b2b-piloto.

El gate no decide solo, pero decide temprano

Ampliar un piloto de agentes es la decisión más cara que toma un equipo de IA después de elegir la stack, y la más barata de tomar mal: basta saltarse el gate. La regla del costo por tarea automatizada y del valor por tarea automatizada, cruzada con un umbral predefinido, saca esa decisión del terreno de la convicción y la coloca en el terreno de la aritmética, donde pertenece.

Es por eso que, desde que Nexforce Agents empezó a recibir a los primeros clientes de la unidad nueva, el consejo que más se repite no habla de elegir el modelo sino de elegir la unidad de medida. Un equipo que decide ampliar por el costo por tarea automatizada puede equivocarse en la magnitud, pero acierta la pregunta. Un equipo que decide por el piloto lindo ya perdió la pregunta antes de llegar a la respuesta.

El camino hacia la producción responsable comienza en medir cada workflow en una plataforma donde el costo por tarea automatizada tenga dueño y rastro, las aprobaciones dejen registro y el valor por tarea automatizada quede visible para el área financiera. Es en ese tipo de medición donde la escala deja de ser un salto de fe y se convierte en un número que se defiende en la sala de directorio: el costo por tarea automatizada contra el valor por tarea automatizada, con el punto de equilibrio sobre la mesa y el dueño del gasto señalado. Un equipo que instrumenta el piloto de esa forma no solo está decidiendo si amplía. Está aprendiendo, antes del volumen, cuáles de sus workflows debieron haber sido automatizados de verdad y cuáles nunca debieron salir de la hoja de cálculo.