Agregar métricas no necesariamente mejora la comprensión. Muchos paneles contienen varias medidas del mismo comportamiento subyacente. Las métricas ofrecen un mejor diagnóstico cuando se combinan en pares que se contraponen: costo con calidad, contención con percepción del cliente o precisión con latencia.
Los pares adecuados cambian a medida que un producto de IA pasa de la fase piloto a producción. La medición debe responder a las decisiones que el equipo necesita tomar en cada etapa.
El monitoreo operativo y la medición estratégica tienen propósitos distintos. Los equipos pueden monitorear cientos de señales del sistema y usar solo unos pocos pares para orientar las decisiones de producto.
Las métricas principales pueden contar una historia convincente y, aun así, dejar sin resolver una decisión importante sobre el producto.
El asistente de IA de Klarna se asoció públicamente con un mayor rendimiento, menores costos y puntuaciones de satisfacción del cliente comparables con las de agentes humanos. Al año siguiente, la empresa decidió ampliar el acceso al soporte humano, y su director ejecutivo reconoció que se había dado demasiada importancia a reducir costos.
Esto no supuso rechazar al asistente de IA ni la tecnología en la que se basaba. Fue un ajuste del equilibrio entre la automatización y la atención humana conforme la empresa aprendía al operar el producto. A medida que la automatización se hacía cargo de una mayor proporción de las consultas más sencillas y frecuentes, los agentes humanos que Klarna necesitaba eran quienes estaban preparados para casos complejos y sensibles.
Después de definir desde el inicio lo que debe lograr un producto, la mayoría de las organizaciones que desarrollan productos de IA terminarán enfrentando la misma pregunta: ¿realmente funciona?
Si la respuesta no está clara, el impulso suele ser agregar más métricas. Tres se convierten en 10 y luego 10 en 30. El panel se enriquece, pero la comprensión del equipo quizá no mejore.
El problema no siempre está en la calidad de cada medida, sino en la relación entre ellas. La satisfacción del cliente, el Net Promoter Score, las reseñas y las tasas de aprobación pueden aportar señales útiles, pero quizá reflejen cambios similares en la percepción general. Cuando avanzan juntas, confirman que algo ocurrió, pero no necesariamente explican por qué.
Por lo tanto, los equipos de IA deben ir más allá de las métricas que coinciden entre sí e identificar medidas que expongan resultados contrapuestos. Estos pares que se contraponen revelan y ayudan a monitorear el impacto de las disyuntivas detrás del desempeño del producto, lo que permite tomar mejores decisiones.
En una implementación previa al lanzamiento, el equipo conjunto desarrollaba un agente de voz con IA en tiempo real para llamadas entrantes de soporte al cliente. Una de las preguntas más difíciles no se refería a la selección ni a la orquestación del modelo, sino a cómo sabría la organización si el producto funcionaba cuando los clientes comenzaran a usarlo a gran escala.
El marco inicial utilizaba tres medidas:
Tasa de contención: frecuencia con la que la IA resuelve una llamada sin transferirla a una persona.
Tasa de escalamiento: frecuencia con la que una llamada se transfiere a un agente humano.
Tasa de resolución: frecuencia con la que finalmente se resuelve el problema del cliente.
Cada medida era razonable. Sin embargo, juntas no podían responder una pregunta obvia: si aumenta el escalamiento, ¿qué nos indica?
El equipo desglosó el escalamiento en ocho subtipos. Luego agregó medidas de abandono, recorrido y tiempos, puntuaciones de comprensión del lenguaje y resolución por tipo de consulta. El marco llegó a contener 31 métricas en seis categorías.
Podía describir el escalamiento en detalle, pero aún no permitía diagnosticar su causa de forma confiable. La mayoría de las métricas eran variaciones del mismo comportamiento, por lo que avanzaban juntas en lugar de poner a prueba explicaciones contrapuestas.
El panel se había vuelto observacional en vez de diagnóstico.
El equipo no necesitaba otra capa de desglose. Necesitaba métricas que se limitaran entre sí.
Los llamamos pares que se contraponen: dos medidas en las que mejorar una de forma aislada puede perjudicar el resultado que representa la otra. El nombre describe el modo de falla que crea la optimización unilateral, no el estado deseado.
Cuando ambos lados se mantienen en niveles adecuados, es posible que el producto funcione de forma sostenible. Cuando divergen, la dirección de esa divergencia ayuda al equipo a decidir dónde investigar.
Lo que teníamos | Par mutuamente destructivo | Lo que el par puede revelar |
|---|---|---|
Tasa de escalamiento dividida en ocho subtipos | Tasa de escalamiento ↔ tiempo hasta el escalamiento | Un escalamiento inmediato puede indicar un problema de confianza o planteamiento; uno posterior puede indicar que el sistema no puede completar la tarea. |
Tasa de contención y tasa de resolución informadas por separado | Tasa de contención ↔ percepción del cliente | Si la contención representa una resolución satisfactoria o el abandono del intento por parte del cliente. |
Tasa de resolución por tipo de intención | Tasa de resolución ↔ profundidad de la conversación | Si una resolución exitosa es eficiente o requiere una interacción agotadora. |
Para profundizar en cómo se revela esto y qué hacer con ese hallazgo, consideremos la tasa y el tiempo de escalamiento. El equipo no sabrá cómo se comportan los clientes hasta recibir llamadas reales, pero puede definir las hipótesis que necesita comprobar.
Si comienzan a escalarse más llamadas y los clientes abandonan la experiencia con IA durante los primeros 30 segundos, el equipo debe investigar la confianza, la comunicación de que se usa IA, el tono y las interacciones iniciales. Si los clientes escalan después de dedicar varios minutos a intentar una tarea, es más probable que el problema sea la capacidad o la cobertura del flujo de trabajo.
La cifra principal de escalamiento es la misma. La decisión sobre el producto es distinta.
Un par útil no demuestra por sí solo la causa. Delimita la investigación y aclara la próxima decisión.
El ejemplo anterior de Klarna muestra cómo se aplica este principio cuando interactúan el costo y la calidad del servicio. Demuestra cómo puede evolucionar un modelo operativo basado en IA a medida que una empresa monitorea el impacto de las disyuntivas y aprende de su implementación.
En febrero de 2024, la empresa informó que su asistente de IA había gestionado 2,3 millones de conversaciones durante su primer mes, realizado el trabajo equivalente al de 700 agentes de tiempo completo y logrado puntuaciones de satisfacción del cliente comparables con las de agentes humanos. Klarna estimó que el asistente contribuiría a mejorar las ganancias en $40 millones durante 2024. Estos eran resultados informados por la propia Klarna, no una evaluación independiente.
En mayo de 2025, el director ejecutivo de Klarna afirmó que la empresa había dado demasiada importancia a reducir los costos del servicio al cliente y describió planes para ampliar el acceso al soporte humano. Esto representó un ajuste del equilibrio entre la atención automatizada y la humana, no un rechazo del asistente de IA ni de la tecnología en la que se basaba.
La evidencia pública muestra por qué las medidas de eficiencia deben considerarse junto con las necesidades de distintos clientes e interacciones. Un sistema de IA puede tener un buen desempeño promedio, aunque algunos casos complejos, delicados o inusuales todavía se beneficien de un canal humano accesible.
Monitorear ambos lados de esa relación ayuda a una empresa a decidir dónde crea valor la automatización, dónde sigue siendo importante el soporte humano y cómo debe cambiar el equilibrio ante nueva evidencia.
Otros pares que se contraponen en productos de IA pueden incluir:
Par mutuamente destructivo | Riesgo que ayuda a revelar |
|---|---|
Precisión de la respuesta ↔ latencia de la respuesta | Un sistema técnicamente preciso, pero demasiado lento para el flujo de trabajo. |
Finalización de tareas ↔ tasa de intervención del usuario | Un flujo de trabajo con IA que completa tareas que los usuarios rehacen repetidamente. |
Costo por interacción ↔ calidad evaluada de los resultados | Ahorros logrados a costa de deteriorar la experiencia del cliente o empleado. |
Adopción ↔ tiempo para obtener valor | Aumento de registros sin el correspondiente valor para los usuarios. |
El objetivo no es hacer que ambas medidas aumenten indefinidamente. Es visibilizar la disyuntiva antes de que una optimización unilateral cree un problema operativo.
Un desafío relacionado surgió al implementar soporte para jugadores en una empresa de juegos móviles. El sistema gestionaba problemas de gran volumen, como la pérdida de progreso, disputas de pagos y acceso a cuentas.
Las medidas de eficiencia importaban porque el sistema operaba a gran escala. Pero el soporte para jugadores no es solo una cola operativa. Los jugadores suelen llegar frustrados porque algo ya salió mal en otra parte de su experiencia.
Ese punto de partida cambia la forma de interpretar los datos de satisfacción del cliente. Un jugador cuyo problema se resuelve correctamente puede aun así informar poca satisfacción porque perdió su progreso desde un principio. Interpretar esa puntuación sin contexto puede penalizar la interacción de soporte por una frustración surgida antes en el recorrido del cliente.
Por lo tanto, el equipo necesitaba distinguir la percepción inicial del cliente del efecto de la experiencia de soporte. La pregunta más útil no era: “¿Estaba contento el jugador?”. Era: “¿La interacción mejoró la situación respecto del punto de partida del jugador?”
Esa comparación puede ayudar a separar la frustración con el producto de la calidad del soporte, siempre que el equipo tenga una forma confiable de medir ambas.
Los productos de IA cambian, pero sus métricas suelen permanecer fijas.
Durante un programa piloto, la pregunta central puede ser si el sistema es lo bastante confiable como para justificar una inversión continua:
¿Completa de forma confiable la tarea principal?
¿Los usuarios confían lo suficiente como para continuar?
¿Cómo se comporta fuera de los escenarios más comunes?
¿Es posible identificar las fallas y recuperarse de forma segura?
Esas preguntas favorecen pares como:
éxito de la tarea principal ↔ desempeño en casos extremos;
tasa de automatización ↔ tasa de intervención humana; y
velocidad de finalización ↔ confianza del usuario.
Cuando el producto adquiere importancia operativa, las preguntas cambian:
¿Puede escalar sin reducir la calidad?
¿Mejora su rentabilidad con el uso?
¿El desempeño se mantiene estable a medida que aumenta la adopción?
¿Las intervenciones humanas ocurren en los lugares adecuados?
Los pares correspondientes pueden orientarse hacia:
costo por interacción ↔ calidad evaluada de los resultados;
amplitud de adopción ↔ profundidad de uso; y
tasa de automatización ↔ exposición al riesgo operativo.
Las métricas iniciales no son necesariamente incorrectas. Responden las preguntas que importaban en una etapa anterior.
El riesgo surge durante la transición. Las métricas del programa piloto suelen persistir porque los equipos saben cómo informarlas y nadie es responsable de decidir cuándo retirarlas. Las medidas que antes favorecían el aprendizaje pueden convertirse gradualmente en métricas vanidosas.
Por lo tanto, los pares deben tener un ciclo de vida. Los equipos deben introducirlos para una decisión definida, revisar si aún exponen una disyuntiva importante y retirarlos cuando cambien el producto o la decisión.
Los sistemas de IA requieren observabilidad detallada, alertas, control de calidad y evaluación. Eliminar esas señales dificultaría operar el producto de forma segura. Pero el monitoreo operativo no es lo mismo que la medición para líderes.
El monitoreo ayuda a los equipos a detectar incidentes, rastrear fallas y comprender el comportamiento del sistema. Las métricas de decisión ayudan a los líderes de producto y de negocio a decidir si invertir, intervenir, cambiar de rumbo o aceptar una disyuntiva.
Una organización puede monitorear cientos de señales técnicas y operativas y destacar solo dos o tres pares que se contraponen para una decisión concreta sobre el producto. Mantener reducido ese nivel de decisión facilita la priorización.
La frecuencia de revisión adecuada depende del producto. Un sistema nuevo o que cambia rápidamente puede requerir revisiones semanales, mientras que un producto maduro puede admitir una frecuencia mensual o trimestral. El principio importa más que el intervalo: revisa el par con suficiente frecuencia para actuar antes de que la disyuntiva resulte costosa o insegura.
Un par solo resulta útil cuando la organización acuerda qué ocurrirá si se deteriora.
Eso requiere más que definir un límite crítico de divergencia. Los equipos deben considerar tres condiciones:
Falla absoluta: una medida cruza un umbral inaceptable, independientemente de la otra.
Divergencia: una medida mejora mientras se deteriora la que la contrarresta.
Deterioro conjunto: ambos lados empeoran, lo que sugiere un problema más amplio del producto o de su operación.
Cada par debe tener:
una persona responsable designada;
una decisión clara que respalde;
umbrales o criterios de evaluación acordados;
una ruta de investigación; y
un conjunto de posibles intervenciones.
Sin esos elementos, la organización observa el producto en lugar de gestionarlo.
Antes de agregar otra medida, elige una decisión importante sobre el producto y analiza estas preguntas. Anota las respuestas para que la revisión concluya con un próximo paso acordado.
1. ¿Qué decisión necesitamos tomar con ayuda de estas métricas?
Concreta la decisión: ¿estamos decidiendo si ampliar la automatización, cambiar un modelo o mejorar la transferencia a una persona? Define la decisión antes de elegir las medidas.
2. Si este número mejora, ¿qué podría empeorar?
Identifica el resultado que necesitas proteger y una medida que permita detectar daños. Por ejemplo, combina el costo por interacción con la calidad evaluada de los resultados para comprobar si las respuestas más baratas siguen siendo útiles.
3. ¿Qué podrían estar ocultando las cifras principales?
Analiza ambas medidas para los mismos usuarios, tareas y periodo; luego, busca grupos que obtengan peores resultados. Considera también las condiciones iniciales: una satisfacción baja puede reflejar una frustración anterior a la interacción de soporte.
4. ¿Qué nos llevaría a actuar y quién es responsable de responder?
Establece criterios para actuar cuando una medida cruce un límite inaceptable, una mejore mientras la otra empeora o ambas se deterioren. Acuerden quién investigará, qué revisará primero y cuándo informará los resultados.
5. ¿Este par aún corresponde a la etapa actual del producto?
Decide si conservarlo, reemplazarlo o retirarlo. Un programa piloto puede centrarse en la confiabilidad de las tareas y la confianza de los usuarios; un servicio activo puede requerir un examen más minucioso del costo y la calidad. Define una fecha para volver a revisar la elección.
La medición de productos de IA debe hacer más que describir el desempeño. Debe exponer las disyuntivas que enfrenta la organización y aclarar la próxima decisión.