Tasa de Intervención Humana: la única métrica que dice si su despliegue de IA funciona de verdad
La mayoría de las empresas que tienen agentes de IA en producción no pueden decir con qué frecuencia esos agentes necesitan de verdad que una persona intervenga. La Tasa de Intervención Humana es el número que responde a esa pregunta — y al final de este artículo debería poder calcularla para un flujo de trabajo que ya ejecuta.
El propio marco de FabricLoop para las organizaciones de IA define la Tasa de Intervención Humana sin rodeos: pregunta con qué frecuencia el trabajo automatizado necesita a una persona. Esa es la definición, y este artículo no se aparta de ella. Lo que sigue es la parte que la página del concepto no escribe 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 de verdad el número
La Tasa de Intervención Humana (TIH) es la parte de las acciones de un agente, dentro de un flujo de trabajo definido y un periodo de tiempo, que exigió que una persona interviniera antes de que el resultado pudiera darse por terminado. «Intervenir» tiene aquí un significado concreto: una persona corrigió la salida, anuló una decisión que tomó el agente o respondió a 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. Divida el recuento de esas acciones entre el número total de acciones que el agente realizó en el mismo periodo, y tiene la TIH.
Esta métrica se gana un lugar junto a la disponibilidad y la precisión, y no por debajo de ellas, porque mide algo que esos números no pueden ver. Un agente puede publicar un 95 % de precisión en algún benchmark interno y seguir siendo un despliegue peor que uno con un 80 %, si el 5 % que falla se cuela en silencio mientras el 20 % del que no está seguro se marca cada vez. La TIH no pregunta si el agente es bueno. Pregunta si el sistema sabe cuándo necesita a una persona, y si una persona aparece de verdad cuando eso ocurre. Esa segunda pregunta es la que decide si un despliegue se puede ampliar con seguridad.
Calcular la TIH para un flujo de trabajo real
Tome un flujo de trabajo que un equipo de TI u operaciones podría ejecutar hoy de verdad: un agente que clasifica los tickets de soporte que entran, los categoriza (facturación, informe de error, reembolso, acceso a la cuenta, y así sucesivamente) y redacta una primera respuesta. Cada borrador cae en 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 intervención. Un revisor que pulsa «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 necesitaba trabajo: un revisor 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 que hay detrás, es exactamente lo que construiría a partir de sus propios registros.
En el mes piloto, el agente toca 640 tickets. De ellos, 415 necesitan una intervención — una reescritura, una reclasificación o un desvío — y solo 75 de esos 415 son momentos que el propio agente marcó antes de redactar nada. El resto son errores que un revisor atrapa después. Eso es una TIH del 64,8 %, con una cuota de escalación de apenas el 18 %: el agente se equivoca con confianza la mayor parte de las veces que se equivoca, que 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 implique una cantidad en dólares, y redacta respuestas calmadas y procedimentales a clientes que están visiblemente enfadados. Las dos se arreglan sin tocar el modelo — añada una regla explícita: cualquier ticket que mencione un reembolso de más de 50 $, o que supere un umbral de sentimiento, dispara una escalación ask_human en lugar de un borrador. Todo lo demás sigue redactándose y revisándose como antes.
| Mes | Tickets atendidos | Intervenciones | TIH | Cuota de escalación |
|---|---|---|---|---|
| 1 — Piloto | 640 | 415 | 64,8 % | 18 % |
| 2 — Tras añadir reglas | 810 | 224 | 27,7 % | 58 % |
| 3 — Reglas afinadas de nuevo | 940 | 101 | 10,7 % | 79 % |
Para el mes tres, la TIH ha bajado más de un 80 %, pero el número más informativo es la cuota de escalación: subió del 18 % al 79 %. Casi todo lo que queda no es el agente pillado en un error — es el agente que reconoce correctamente un caso de verdad ambiguo (una cuenta VIP, una excepción de política, un reembolso justo en el umbral) y pregunta antes de actuar. El descenso es real, y está ganado: 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 aún necesitan juicio siguen marcándose en lugar de rodearse con un borrador.
El descenso que importa es aquel en el que el agente mejora en saber lo que no sabe — no aquel en el que una persona deja de revisar en silencio.
El error: tratar el cero como la meta
Cuando un equipo ve la TIH caer mes tras mes, la siguiente pregunta parece obvia: cuánto puede bajar. 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 funcionar sin supervisión. Ese instinto va al revés, y es la lectura más habitual de esta métrica.
Un flujo que muestra un 0 % de intervención durante semanas seguidas casi nunca significa que el agente dejó de cometer errores. Significa que ocurrió una de dos cosas: los revisores dejaron de leer de verdad los borradores antes de aprobarlos, o la vía de escalación se rompió en silencio — se aflojaron umbrales, una regla de enrutamiento falló sin avisar, o el disparador ask_human dejó de activarse. En cualquier caso, el cero no le dice que el sistema dejó de necesitar a una persona. Le dice que a una persona dejaron de preguntarle, o que dejó de mirar.
La meta real nunca fue menos intervenciones en abstracto. Es un sistema en el que los momentos concretos que necesitan el juicio de una persona salen a la superficie — y solo esos momentos — para que la atención de una persona vaya a lo que de verdad la necesita, en lugar de repartirse por igual entre todo o faltar por completo. Un flujo al 12 % de TIH, en el que casi todo ese 12 % es el agente marcando correctamente casos de verdad ambiguos o de alto riesgo, está más sano que uno al 2 %, en el que la mayor parte de ese 2 % es un revisor que tropieza con un error que el agente nunca marcó. El número más bajo puede esconder el peor sistema.
Para eso sirve exactamente la cuota de escalación. Vista junto a la TIH, le dice en qué historia está:
Si la TIH baja mientras la cuota de escalación se mantiene plana o también baja, no lo archive todavía como una victoria. Saque una muestra al azar de las acciones registradas como «no hizo falta intervención» y pida a alguien que las revise en frío, sin decirle que la muestra estaba marcada como limpia. Compruebe si las señales posteriores — tickets que se reabren, quejas, recuperaciones de reembolsos, CSAT — se desplazan 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 que nadie atrapó a tiempo.
Qué instrumentar si quiere medir esto hoy
Nada de esto exige tanto herramientas nuevas como registrar lo correcto. La mayoría de los equipos que operan un agente ya siguen el volumen — cuántos tickets tocó, cuántas tareas redactó. Casi ninguno sigue el resultado, que es lo único que la TIH necesita de verdad.
- Registre un resultado para cada acción, no solo un recuento 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á que el agente hizo algo, no si había que corregirlo.
- Fije el denominador antes de fijar el numerador. Decida qué cuenta como una acción en este flujo — un ticket tocado, una tarea redactada — y mantenga esa definición estable entre periodos, para que un cambio en la TIH refleje el juicio del agente y no un cambio en cómo está contando.
- Etiquete cada intervención con un motivo. «Editado» no dice casi nada. «Editado: política de reembolsos mal aplicada por encima de 50 $» dice exactamente qué corregir después. Una taxonomía corta y constante convierte un registro de correcciones en una lista de trabajo, no en un marcador.
- Siga la cuota de escalación junto a la TIH, no en su lugar. Los dos números juntos dicen si un descenso está ganado o prestado — vea la tabla de tendencia de arriba.
- Fije un suelo, no una meta de cero. Decida, por flujo, cómo se ve una TIH plausible y distinta de cero dada la ambigüedad real que ese flujo contiene, y trate una tasa que cae muy por debajo de ese suelo como algo que hay que investigar, no celebrar.
- Informe la TIH por flujo, nunca como un solo número mezclado de toda la empresa. Un promedio único esconde qué flujo concreto se ha ganado de verdad menos supervisión y cuál acumula riesgo en silencio bajo una cifra de portada que se ve bien.
- Vuelva a revisar la muestra «limpia» con un calendario. Saque de vez en cuando acciones registradas como que no necesitaban intervención y pida a alguien que las revise sin saber que estaban marcadas como limpias. Es la única comprobación directa de si sus revisores siguen leyendo.
Por eso Loop Agent está construido alrededor de ask_human, resume y la escalación de canal-app, y no de una autonomía silenciosa — un agente que se detiene para preguntar es un agente que aparece en el numerador de su TIH a propósito, no uno al que pillaron por accidente. Las escalaciones y los borradores salen en los mismos Grupos donde el equipo ya trabaja, junto a las tareas y las notas, de modo que el momento que necesitaba a una persona es visible donde el trabajo ya vive — no enterrado en una consola de agente aparte que nadie revisa. En Enterprise, los registros de auditoría permiten a TI y operaciones ver qué hicieron los agentes y exactamente cuándo intervino un humano, que es la materia prima con la que se construye la TIH.
Únalo a la Legibilidad — el concepto compañero para que los permisos y el acceso también sean visibles — y tiene 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 tiene que intervenir de verdad.
