AWS propuso medir los agentes de IA más allá de las horas ahorradas. Una hora liberada no vale nada si nadie la convierte en dinero. Revisa tu caso de negocio hoy.
Casi todos los casos de negocio de automatización que he visto calculan las horas ahorradas por el costo por hora y le restan el costo de desarrollo. En la presentación parece funcionar. Pero seis meses después, finanzas pregunta dónde está el ahorro y nadie lo ve.
El 7 de octubre, AWS publicó un artículo que trata ese problema en los agentes de IA. Manish Ballal y Sumit Wasuja, del equipo de Amazon Quick, lo firman y proponen algo que llaman el Agentic Value Model. Es útil leerlo aunque no uses AWS.
Por qué la fórmula clásica falla
La fórmula de horas ahorradas viene de la época de RPA y trae supuestos que ya no aplican:
- Supón que el proceso se mantiene igual, así que no tomes en cuenta el mantenimiento.
- Supón que todo sigue reglas; no hay espacio para excepciones.
- Supone que la tarea incluye todo el trabajo, por lo que nunca suma el costo de la supervisión humana.
- Supón que liberar una hora equivale a ganar dinero. Casi nunca pasa. El tiempo libre se usa en tareas pendientes y no se refleja en los resultados financieros.
El artículo menciona el patrón 1:3:5 de McKinsey. En las transformaciones exitosas, por cada dólar que se invierte en tecnología, se invierten tres en rediseñar procesos y cinco en desarrollar capacidades y lograr que la gente adopte los cambios. La mayoría de las empresas gasta más en tecnología que en los otros dos aspectos.
Las cuatro fuentes de valor
AWS separa el valor de un agente en cuatro partes y pide medir cada una por separado:
- Tiempo. Lo de siempre, pero en tareas que RPA hacía de forma incorrecta.
- Excepciones. Sus rangos de planificación sitúan el costo de corregir una transacción entre 1,5 y 4 veces el costo original, y el error humano entre el 2% y el 15% del costo operativo.
- Calidad de decisión. Un agente usa la misma política en todos los casos y anota su razonamiento. Hay decisiones con poco volumen y mucho valor en las que el agente se justifica por la calidad y no por el costo.
- Resiliencia al cambio. Los scripts dejan de funcionar si una pantalla cambia. Los agentes toleran parte de esa variación, pero el mantenimiento pasa a evaluaciones, prompts y monitoreo. Ese costo hay que descontarlo.
Y para mí, lo más importante del artículo es que cada beneficio debe tener un mecanismo que lo haga rentable y alguien que se encargue. Si liberas capacidad o reduces gasto, tienes que asignarlo a un resultado concreto y medible.
El ejemplo que hace la diferencia
El artículo muestra un caso sobre cómo se clasifican las reclamaciones. Lo resumo porque los números explican la situación mejor que cualquier comentario.
- 200,000 reclamaciones al año. Cada una toma 12 minutos. La hora cuesta 45 dólares. El costo base es casi 1.8 millones.
- Automatizar el 70% libera unas 28,000 horas, lo que equivale a 1.26 millones.
- Ese dinero solo aparece si se reduce el personal o se bajan los gastos en contratistas, horas extra u outsourcing. Si eso cubre la mitad, el caso real es de unos 630,000 dólares.
- Por otro lado, 8% de las reclamaciones requiere corrección. Corregir cuesta 3.5 veces más. El riesgo anual es de unos 504,000. Si el agente logra bajar ese porcentaje en 40% y se capta el 75%, el beneficio estimado es de unos 151,000.
Pasamos de 1.26 millones en la lámina a cerca de 780,000 antes de descontar los costos de operación del agente. Finanzas va a defender ese número.
La regla que ponen es simple y casi nadie la respeta. Por cada hora que se libera, suma el valor que se reparte o el ahorro en dinero. Nunca ambos.
Dónde sí y dónde no usar agentes
El artículo propone una matriz con dos ejes, complejidad de la tarea y riesgo de la decisión:
- Baja complejidad y bajo riesgo, usa RPA. El agente solo suma costo y no aporta valor.
- Alta complejidad y bajo riesgo: automatiza por cantidad y control de excepciones.
- Alta complejidad y alto riesgo. Deja a una persona en el proceso y explica que esto ayuda a tomar mejores decisiones.
- Baja complejidad y alto riesgo. Refuerza los controles en ese paso. No necesita razonamiento.
Me gusta mucho el atajo que ofrecen. Cuando una persona cambia entre sistemas y entiende el contexto ambiguo en cada paso, está evaluando un agente. Si el proceso es fijo, RPA suele costar menos.
Cómo presentarlo a dirección
Citan otro dato de McKinsey. Cerca de dos tercios de las empresas han probado agentes, pero menos del 10% los ha llevado a un valor tangible. Para avanzar, recomiendan:
- Gestionar un portafolio con tres a cinco dominios prioritarios, no un solo proyecto aislado.
- Establecer metas de punto de equilibrio y definir puntos de salida para apagar agentes que no cumplen. Los autores dicen que esto suele convencer a un CFO escéptico.
- Vincular cada dominio a los indicadores que la dirección ya usa, como costo por servicio, tiempo de ciclo o exposición regulatoria.
Qué haría esta semana
Si tienes un piloto de agentes en marcha o en propuesta:
- Divide tu caso de negocio en las cuatro fuentes de valor y evita contar lo mismo dos veces.
- Asigna a cada fuente un propietario con nombre y una forma específica de cómo obtiene la información.
- Usa un factor de realización realista. Si no sabes cuánto vas a obtener, pon 50%.
- Queda el costo de operar el agente: evaluaciones, monitoreo, supervisión y gobierno.
- Hoy fija el criterio para apagarlo.
En Papalote trabajamos con equipos de datos y operaciones para armar casos de negocio de IA que pasan la revisión de finanzas y decidir qué flujo conviene llevar primero a producción. Si tu propuesta de agentes sigue basada en horas ahorradas, hablemos en papalote.ai.
También puedes ver cómo trabajamos estos casos en nuestra consultoría en análisis de datos e IA.
