Tasa de Intervención Humana: la única métrica que les dice si su despliegue de IA realmente está funcionando
La mayoría de las empresas que tienen agentes de IA en producción no pueden decir con qué frecuencia esos agentes realmente necesitan que una persona intervenga. La Tasa de Intervención Humana es el número que responde esa pregunta, y al terminar este texto deberían poder calcularla para un flujo de trabajo que ya operan.
El propio marco de FabricLoop para las organizaciones de IA define la Tasa de Intervención Humana con claridad: pregunta con qué frecuencia el trabajo automatizado necesita a una persona. Esa es la definición, y este texto no se aparta de ella. Lo que sigue es la parte que la página del concepto no detalla por completo: la aritmética real, aplicada a un flujo de trabajo concreto, con los números que vuelven la idea tangible en lugar de aspiracional.
Qué mide realmente el número
La Tasa de Intervención Humana (TIH) es la proporción de las acciones de un agente, dentro de un flujo de trabajo definido y un periodo, que requirieron que una persona interviniera antes de que el resultado pudiera darse por terminado. «Intervenir» tiene aquí un significado preciso: una persona corrigió el resultado, anuló una decisión que tomó el agente, o respondió una pregunta que el agente planteó de forma explícita antes de seguir, lo que el Loop Agent de FabricLoop llama un momento ask_human. Dividan el conteo de esas acciones entre el total de acciones que el agente realizó en el mismo periodo, y obtienen la TIH.
Esta métrica merece un lugar junto al tiempo de actividad y la exactitud, y no por debajo, porque mide algo que esos números no alcanzan a ver. Un agente puede mostrar 95% de exactitud en algún benchmark interno y, aun así, ser un peor despliegue que uno con 80%, si el 5% en el que se equivoca se cuela en silencio mientras el 20% del que no está seguro se marca siempre. La TIH no pregunta si el agente es bueno. Pregunta si el sistema sabe cuándo necesita a una persona, y si esa persona de verdad aparece cuando hace falta. Esa segunda pregunta es la que decide si un despliegue se puede ampliar con seguridad.
Cómo calcular la TIH para un flujo de trabajo real
Tomen un flujo que un equipo de TI u operaciones podría estar corriendo hoy: un agente que clasifica los tickets de soporte que entran, los categoriza (facturación, reporte de error, reembolso, acceso a la cuenta, y así) y redacta una primera respuesta. Cada borrador llega a una cola de revisión antes de llegar a un cliente: nada se envía solo. Ese paso de revisión, por sí mismo, no es una intervención. Que quien revisa pulse «enviar» en un borrador que no necesitaba cambios es el flujo funcionando como se diseñó. La intervención es lo que ocurre cuando el borrador sí necesitaba trabajo: quien revisa lo reescribió, corrigió la clasificación, redirigió el ticket a otra cola, o el propio agente se detuvo a mitad de la tarea y hizo una pregunta antes de redactar nada.
Los números de abajo son un ejemplo ilustrativo, no los datos de una empresa real, pero la forma de la historia, y la aritmética detrás, es exactamente lo que construirían a partir de sus propios registros.
En el mes piloto, el agente toca 640 tickets. De esos, 415 necesitan una intervención —una reescritura, una reclasificación o un reenrutamiento— y solo 75 de esos 415 son momentos que el agente marcó por sí mismo antes de redactar nada. El resto son errores que quien revisa detecta después. Eso es una TIH de 64.8%, con una proporción de escalamientos de apenas 18%: el agente se equivoca con confianza la mayor parte de las veces que se equivoca, y esa es la peor versión de este problema.
El equipo saca el registro de correcciones y etiqueta cada intervención con un motivo. Dos categorías dominan: el agente malinterpreta la política de reembolsos en cualquier cosa que involucre un monto en dólares, y redacta respuestas calmadas y procedimentales para clientes que están visiblemente enojados. Las dos se pueden corregir sin tocar el modelo: agreguen una regla explícita para que cualquier ticket que mencione un reembolso de más de $50, o que supere un umbral de sentimiento, dispare un escalamiento ask_human en lugar de un borrador. Todo lo demás se sigue redactando y revisando como antes.
| Mes | Tickets atendidos | Intervenciones | TIH | Proporción de escalamientos |
|---|---|---|---|---|
| 1 — Piloto | 640 | 415 | 64.8% | 18% |
| 2 — Tras agregar reglas | 810 | 224 | 27.7% | 58% |
| 3 — Reglas ajustadas otra vez | 940 | 101 | 10.7% | 79% |
Para el mes tres, la TIH bajó más de 80%, pero el número más informativo es la proporción de escalamientos: subió de 18% a 79%. La mayor parte de lo que queda no es el agente al que se le descubre un error: es el agente reconociendo correctamente un caso de verdad ambiguo (una cuenta VIP, una excepción de política, un reembolso que cae justo en el umbral) y preguntando antes de actuar. La baja es real, y se ganó: cada ronda de correcciones volvió a reglas explícitas, así que los errores concretos que las produjeron dejaron de repetirse, mientras las categorías que todavía necesitan criterio se siguen marcando en lugar de rodearlas con un borrador.
La baja que importa es aquella en la que el agente mejora en saber lo que no sabe, no aquella en la que una persona deja de revisar en silencio.
El error: tratar el cero como la meta
Cuando un equipo ve la TIH bajar mes con mes, la siguiente pregunta obvia es qué tan bajo puede llegar. El instinto es tratar el cero como la línea de meta: la prueba de que el agente por fin es lo bastante bueno para correr sin supervisión. Ese instinto está al revés, y es la lectura equivocada más común de esta métrica.
Un flujo que muestra 0% de intervención durante semanas casi nunca significa que el agente dejó de equivocarse. Significa que pasó una de dos cosas: quienes revisan dejaron de leer de verdad los borradores antes de aprobarlos, o la vía de escalamiento se rompió en silencio: se aflojaron los umbrales, falló una regla de enrutamiento sin avisar, o el disparador ask_human dejó de activarse. En cualquiera de los dos casos, el cero no les dice que el sistema dejó de necesitar a una persona. Les dice que a una persona dejaron de pedirle, o que dejó de mirar.
La meta real nunca fue tener menos intervenciones en abstracto. Es un sistema en el que los momentos concretos que necesitan el criterio de una persona salen a la superficie, y solo esos momentos, para que la atención de esa persona vaya a lo que de verdad la necesita, en lugar de repartirse parejo entre todo o faltar por completo. Un flujo en 12% de TIH, donde casi todo ese 12% es el agente marcando correctamente casos de verdad ambiguos o de alto riesgo, está más sano que uno en 2%, donde la mayor parte de ese 2% es alguien que tropieza con un error que el agente nunca marcó. El número más bajo puede esconder el peor sistema.
Para eso existe la proporción de escalamientos. Vista junto a la TIH, les dice en qué historia están:
Si la TIH baja mientras la proporción de escalamientos se mantiene plana o también baja, no la archiven todavía como un triunfo. Saquen una muestra al azar de las acciones registradas como «no requirió intervención» y pidan que alguien las revise en frío, sin decirle que la muestra estaba marcada como limpia. Revisen si las señales posteriores —tickets que se reabren, quejas, reversiones de reembolsos, CSAT— se están moviendo al alza al mismo tiempo. Una TIH a la baja con problemas posteriores al alza no es un sistema que aprendió más rápido. Es un sistema al que nadie alcanzó a detener a tiempo.
Qué instrumentar si quieren medir esto hoy
Nada de esto exige tantas herramientas nuevas como registrar lo correcto. La mayoría de los equipos que corren un agente ya miden el volumen: cuántos tickets tocó, cuántas tareas redactó. Casi ninguno mide el resultado, que es lo único que la TIH realmente necesita.
- Registren un resultado para cada acción, no solo un conteo de actividad. Enviado tal cual, editado antes de enviar, rechazado y reescrito, o escalado por el propio agente. Sin un registro a nivel de resultado, la TIH no se puede calcular: sabrán que el agente hizo algo, no si hubo que corregirlo.
- Arreglen el denominador antes de arreglar el numerador. Decidan qué cuenta como una acción en este flujo —un ticket tocado, una tarea redactada— y mantengan esa definición estable entre periodos, para que un cambio en la TIH refleje el criterio del agente y no un cambio en cómo están contando.
- Etiqueten cada intervención con un motivo. «Editado» casi no les dice nada. «Editado: se aplicó mal la política de reembolsos por encima de $50» les dice exactamente qué corregir después. Una taxonomía corta y consistente convierte un registro de correcciones en una lista de trabajo, no en un marcador.
- Sigan la proporción de escalamientos junto a la TIH, no en lugar de ella. Los dos números juntos les dicen si una baja se ganó o se prestó: vean la tabla de tendencia de arriba.
- Fijen un piso, no una meta de cero. Decidan, por flujo, cómo se ve una TIH plausible y distinta de cero según cuánta ambigüedad real contiene ese flujo, y traten una tasa que cae muy por debajo de ese piso como algo que hay que investigar, no que celebrar.
- Reporten la TIH por flujo, nunca como un solo número mezclado de toda la empresa. Un promedio único esconde qué flujo específico ya se ganó menos supervisión y cuál está acumulando riesgo en silencio debajo de una cifra que se ve bien.
- Vuelvan a revisar la muestra «limpia» con un calendario. De vez en cuando saquen acciones registradas como que no necesitaban intervención y pidan que alguien las revise sin saber que estaban marcadas como limpias. Es la única verificación directa de si quienes revisan siguen leyendo.
Por eso el Loop Agent está construido alrededor de ask_human, resume y el escalamiento por la aplicación del canal, en lugar de una autonomía silenciosa: un agente que hace una pausa para preguntar es un agente que aparece a propósito en el numerador de su TIH, no uno al que atraparon por accidente. Los escalamientos y los borradores salen en los mismos Grupos donde el equipo ya trabaja, junto a las tareas y las notas, así que el momento que necesitó a una persona se ve donde el trabajo ya vive, y no queda enterrado en una consola de agente aparte que nadie revisa. En el plan Empresa, los registros de auditoría permiten que TI y operaciones vean qué hicieron los agentes y exactamente cuándo intervino una persona, que es la materia prima con la que se construye la TIH desde el principio.
Combínenlo con la Legibilidad —el concepto compañero para que los permisos y el acceso también sean visibles— y tienen las dos preguntas que todo despliegue de IA debería poder responder antes de ampliarse: quién puede ver qué está haciendo un agente, y con qué frecuencia una persona realmente necesita intervenir.