Cómo saber si una métrica de IA para llamadas es confiable
En corto
Una métrica de IA es confiable cuando puedes medir su precisión en la clase específica que le mandas al supervisor, no en el promedio global. Que el modelo conteste lo mismo varias veces no prueba que acierte: tres errores idénticos también coinciden entre sí.
Todo proveedor de análisis de llamadas con IA te va a dar un número de precisión. Casi ninguno te va a decir de qué precisión está hablando, y esa diferencia es la que decide si tu supervisor toma buenas decisiones el lunes o si acusa a un agente de algo que no hizo.
Lo que sigue son cuatro fallas que encontré midiendo mis propias métricas en operaciones reales de cobranza. Ninguna se arregla reescribiendo el prompt, que es exactamente lo primero que todos intentamos.
1. Consistencia no es verdad
La forma más común de medir una métrica de IA sin tener la respuesta correcta a la mano es la consistencia: corres la misma llamada varias veces y ves si el modelo contesta igual. Si coincide, le llamas confiable.
Es razonable y es lo único disponible cuando no hay set etiquetado. Pero tiene un agujero grande.
En julio de 2026 mi propio vigilante de calidad reportó 100% de confiabilidad tres barridos seguidos. Los mismos días en que el proveedor de IA estaba caído y ninguna corrida devolvía un valor. El sistema medía qué tan seguido coincidían tres corridas entre sí, y tres errores coinciden perfecto.
3 barridos
reportados como salud perfecta mientras el motor no respondía. Generaron alertas falsas que sobrevivieron una semana.
Medición propia, Prompt Lab AIM8, 25 al 27 de julio de 2026
2. El promedio se traga lo que sí importa
Una métrica de cobranza que audité tenía 97% de confiabilidad global. Un número excelente en cualquier presentación.
Esa métrica clasifica cada llamada en varias clases. Una de ellas es la que de verdad se le manda al supervisor para que actúe. Medida por separado, esa clase estaba en 25%.
Medición propia sobre una operación de cobranza, agosto de 2026. Sin identificar al cliente.
Tres de cada cuatro veces, el dato que llegaba a la persona que iba a actuar era incorrecto. Y el promedio lo escondía perfectamente.
3. Las cuatro causas piden acciones opuestas
Cuando una métrica sale mal hay cuatro razones posibles, y confundirlas cuesta semanas porque lo que arregla una empeora otra.
| Causa | Cómo se ve | Qué hacer | Qué NO hacer |
|---|---|---|---|
| Prompt | Falla parejo en todas las clases | Reescribir el prompt | Cambiar de modelo antes de aislar |
| Dilución | La misma instrucción acierta sola y falla acompañada | Reducir el tamaño del lote o subir la instrucción de posición | Reescribir el prompt: ya estaba bien |
| Ruido | Variación chica sin patrón | Nada. Vivir con el piso de error | Perseguirlo. Se van semanas |
| Capacidad inexistente | Una clase específica falla siempre, las demás no | Cambiar el motor o recortar el objetivo | Reescribir el prompt veinte veces |
4. La dilución: mismo prompt, distinto lugar
Esta me sorprendió y no la había visto documentada en español. Los sistemas de análisis de llamadas suelen mandar varias instrucciones juntas en una sola petición al modelo, para ahorrar costo y latencia.
Tomé una instrucción, una llamada y un modelo. Sin cambiar una sola palabra, moví la instrucción de lugar:
Medición propia, Prompt Lab AIM8, julio de 2026. Modelo pequeño de razonamiento.
Un caso de “el prompt no funciona” puede ser 100% estructural. Antes de culpar al texto, corre la instrucción sola y compárala contra su desempeño dentro del lote. Si sola pasa, no es el prompt.
5. La pregunta que va antes del prompt
Volvamos a la métrica del 25%. La causa no era el prompt ni la dilución.
Esa clase exigía saber cuál de los dos participantes había dicho algo. El motor de transcripción corría sin separación de hablantes. Sin eso, la atribución no es difícil: es imposible. Y como el modelo no puede atribuir, cae al valor por default, que en ese caso era el que acusaba al agente.
De ahí sale un principio de diseño que aplico a todo: el modelo extrae, el código decide. Toda aritmética y toda combinación de condiciones baja del prompt al pipeline, donde es determinística y auditable.
6. El checklist antes de aceptar un número
- 1
¿Qué se está midiendo, precisión o consistencia?
Si es consistencia, sabes que el modelo es estable. No sabes si acierta.
- 2
¿Los errores están fuera del conteo?
Un timeout no es un valor. Si entra al promedio, el número está inflado.
- 3
¿Cuánto de la muestra se pudo medir?
Debajo del 80%, el resultado correcto es no concluyente, no un porcentaje calculado sobre lo que sobrevivió.
- 4
¿Cuál es la precisión de la clase accionable?
La que dispara una acción del supervisor. El global no sirve para esto.
- 5
¿La instrucción se midió sola y acompañada?
Si solo se midió dentro del lote, no sabes si el problema es el texto o el lugar.
- 6
¿El motor puede resolver lo que la métrica exige?
Si la respuesta es no, ningún prompt lo arregla. Se cambia el motor o se recorta el objetivo.
7. Recortar el objetivo suele dar mejor producto
Cuando parte de un objetivo es imposible, la salida no es inventar un prompt que va a fallar. Es recortar hasta lo que sí se puede sostener.
Sobre la misma operación, dos formas de decir algo parecido:
| Lo que suena mejor | Lo que aguanta que lo revisen |
|---|---|
| “El agente aceptó la promesa sin refutar” | “Hay 40 promesas de pago a más de 7 días, revísalas” |
| Falso 3 de cada 4 veces | Verificable contra el sistema |
| Acusa a una persona con nombre | Señala un lote de casos |
| El supervisor lo discute | El supervisor lo acciona el lunes |
El dato chico que aguanta una auditoría vale más que el dato grande que se cae en la primera junta donde alguien lo revise. Y para el supervisor la diferencia no es filosófica: es si vuelve a abrir el reporte la semana que entra.
Lo que se lleva un director de operaciones
La IA aplicada a llamadas ya funciona bien para muchas cosas. El problema no es que se equivoque, es que se equivoca en silencio y con una cifra de precisión que respalda el error.
Antes de meter una métrica al reporte semanal de tu operación, pide las tres cosas: precisión de la clase accionable, cuánto de la muestra se pudo medir, y qué pasa cuando el motor no responde. Si las tres tienen respuesta, el número sirve.