Añadir métricas no mejora necesariamente la comprensión. Muchos paneles contienen varias medidas del mismo comportamiento subyacente. Las métricas resultan más útiles para el diagnóstico cuando se combinan en pares que se contraponen: coste y calidad, contención y percepción, o precisión y 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.
La supervisión operativa y la medición estratégica tienen fines distintos. Los equipos pueden monitorizar cientos de señales del sistema y utilizar 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 de producto importante.
El asistente de IA de Klarna se asoció públicamente con un mayor rendimiento, menores costes y unas puntuaciones de satisfacción del cliente comparables a las de los agentes humanos. Al año siguiente, la empresa decidió ampliar el acceso a la asistencia humana, y su director ejecutivo reconoció que se había dado demasiada importancia a reducir los costes.
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 aquellos que estaban preparados para abordar casos complejos y confidenciales.
Tras definir desde el principio qué debe conseguir un producto, la mayoría de las organizaciones que desarrollan productos de IA acaban afrontando la misma pregunta: ¿funciona realmente?
Si la respuesta no está clara, el impulso suele ser añadir más métricas. Tres se convierten en 10 y luego 10 en 30. El panel gana datos, pero puede que el equipo no comprenda mejor la situación.
El problema no siempre reside 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 votos positivos pueden aportar señales útiles, pero quizá reflejen cambios similares en la percepción general. Cuando evolucionan a la vez, confirman que algo ha ocurrido, pero no explican necesariamente por qué.
Por tanto, los equipos de IA deben ir más allá de las métricas que coinciden entre sí e identificar medidas que revelen resultados contrapuestos. Estos pares que se contraponen revelan y ayudan a supervisar el impacto de las contrapartidas que condicionan el rendimiento 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 las llamadas entrantes de atención al cliente. Una de las preguntas más difíciles no tenía que ver con elegir el modelo ni con la orquestación. Era cómo sabría la organización si el producto funcionaba cuando los clientes empezaran a utilizarlo 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 escalado: frecuencia con la que una llamada se transfiere a un agente humano.
Tasa de resolución: frecuencia con la que se acaba resolviendo el problema del cliente.
Cada medida era razonable. Sin embargo, en conjunto no podían responder una pregunta evidente: si aumenta el escalado, ¿qué nos indica?
El equipo desglosó el escalado en ocho subtipos. Después añadió medidas de abandono, recorrido y tiempo, puntuaciones de comprensión del lenguaje y resolución por tipo de consulta. El marco acabó incluyendo 31 métricas repartidas en seis categorías.
Podía describir el escalado en detalle, pero seguía sin poder diagnosticar de forma fiable su causa. La mayoría de las métricas eran variantes del mismo comportamiento, así que evolucionaban juntas en lugar de contrastar explicaciones contrapuestas.
El panel se había vuelto descriptivo en lugar de servir para el diagnóstico.
El equipo no necesitaba otro nivel de desglose. Necesitaba métricas que se limitaran mutuamente.
Las 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 fallo que genera una optimización unilateral, no el estado deseado.
Cuando ambos lados se mantienen en buen estado, el producto puede estar funcionando de forma sostenible. Cuando divergen, la dirección de esa divergencia ayuda al equipo a decidir qué debe investigar.
Lo que teníamos | Par mutuamente destructivo | Lo que puede revelar el par |
|---|---|---|
Tasa de escalado dividida en ocho subtipos | Tasa de escalado ↔ tiempo hasta el escalado | Un escalado 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 presentadas 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 la resolución satisfactoria es eficiente o requiere una interacción demasiado larga. |
Para profundizar en cómo se revela y qué hacer con esta información, consideremos la tasa de escalado y el tiempo hasta el escalado. El equipo no sabrá cómo se comportan los clientes hasta que lleguen llamadas reales, pero puede definir las hipótesis que necesita comprobar.
Si empiezan a escalarse más llamadas y los clientes abandonan la experiencia con la IA durante los primeros 30 segundos, el equipo debe investigar la confianza, la transparencia, el tono y las interacciones iniciales. Si los clientes solicitan el escalado después de intentar una tarea durante varios minutos, es más probable que el problema sea la capacidad o la cobertura del flujo de trabajo.
La cifra principal de escalado es la misma. La decisión de producto es distinta.
Un par útil no demuestra la causa por sí solo. Acota la investigación y aclara la siguiente decisión.
El ejemplo anterior de Klarna muestra cómo se aplica este principio cuando interactúan el coste y la calidad del servicio. Muestra cómo puede evolucionar un modelo operativo basado en IA cuando una empresa supervisa el impacto de las contrapartidas y aprende de su implementación.
En febrero de 2024, la empresa informó de que su asistente de IA había gestionado 2,3 millones de conversaciones durante su primer mes, realizado un trabajo equivalente al de 700 agentes a tiempo completo y obtenido puntuaciones de satisfacción del cliente comparables a las de los agentes humanos. Klarna estimó que el asistente contribuiría a mejorar sus beneficios en 40 millones de dólares durante 2024. Eran resultados comunicados 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 costes de atención al cliente y describió sus planes para ampliar el acceso a la asistencia humana. Esto supuso ajustar el equilibrio entre el servicio automatizado y el humano, no rechazar el asistente de IA ni la tecnología en la que se basaba.
La información 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 ofrecer buenos resultados de media, aunque algunos casos complejos, delicados o inusuales sigan beneficiándose de un canal humano accesible.
Supervisar ambos lados de esa relación ayuda a una empresa a decidir dónde aporta valor la automatización, dónde sigue siendo importante la asistencia humana y cómo debe cambiar el equilibrio al surgir nuevos datos.
Otros pares que se contraponen aplicables a productos de IA pueden ser:
Par mutuamente destructivo | Riesgo que ayuda a identificar |
|---|---|
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 corrección por el usuario | Un flujo de trabajo de IA que completa tareas que los usuarios rehacen repetidamente. |
Coste por interacción ↔ calidad evaluada del resultado | Ahorros logrados a costa de empeorar la experiencia del cliente o del empleado. |
Adopción ↔ tiempo hasta obtener valor | Aumento de registros sin un incremento equivalente del valor para el usuario. |
El objetivo no es que ambas medidas aumenten indefinidamente. Es hacer visible la contrapartida antes de que una optimización unilateral cree un problema operativo.
En una implementación de asistencia a jugadores para una empresa de juegos móviles surgió un problema relacionado. El sistema gestionaba problemas de gran volumen, como la pérdida de progreso, las disputas de pagos y el acceso a cuentas.
Las medidas de eficiencia eran importantes porque el sistema funcionaba a gran escala. Pero la asistencia a jugadores no es una simple cola operativa. Los jugadores suelen llegar frustrados porque algo ya ha salido 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 seguir indicando una baja satisfacción porque perdió su progreso en primer lugar. Interpretar esa puntuación sin contexto puede penalizar la interacción de asistencia por una frustración surgida antes en el recorrido del cliente.
Por tanto, el equipo necesitaba distinguir la percepción inicial del cliente del efecto de la experiencia de asistencia. La pregunta más útil no era «¿Estaba contento el jugador?» sino «¿Mejoró la interacción la situación respecto al punto de partida del jugador?»
Esa comparación puede ayudar a separar la frustración con el producto de la calidad de la asistencia, siempre que el equipo disponga de una forma fiable de medir ambas.
Los productos de IA cambian, pero sus métricas suelen permanecer fijas.
Durante una fase piloto, la pregunta principal puede ser si el sistema es lo bastante fiable como para justificar que se siga invirtiendo:
¿Completa la tarea principal de forma fiable?
¿Confían los usuarios lo suficiente como para seguir utilizándolo?
¿Cómo se comporta fuera de los escenarios más habituales?
¿Se pueden identificar los fallos y recuperarse de ellos de forma segura?
Esas preguntas favorecen pares como:
éxito de la tarea principal ↔ rendimiento en casos extremos;
tasa de automatización ↔ tasa de correcció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?
¿Se mantiene estable el rendimiento a medida que crece la adopción?
¿Se producen las intervenciones humanas en los lugares adecuados?
Los pares correspondientes pueden pasar a ser:
coste por interacción ↔ calidad evaluada del resultado;
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 a las preguntas que importaban en una etapa anterior.
El riesgo aparece durante la transición. Las métricas de la fase piloto suelen mantenerse porque los equipos saben cómo comunicarlas y nadie asume la decisión de retirarlas. Las medidas que antes facilitaban el aprendizaje pueden convertirse gradualmente en métricas de vanidad.
Por tanto, los pares deben tener un ciclo de vida. Los equipos deben introducirlos para una decisión concreta, revisar si siguen revelando una contrapartida relevante 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 la supervisión operativa no equivale a la medición para la dirección.
La supervisión ayuda a los equipos a detectar incidentes, rastrear fallos y comprender el comportamiento del sistema. Las métricas para la toma de decisiones ayudan a los responsables de producto y negocio a decidir si invertir, intervenir, cambiar de rumbo o aceptar una contrapartida.
Una organización puede monitorizar cientos de señales técnicas y operativas, pero destacar solo dos o tres pares que se contraponen para una decisión concreta de 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 exigir revisiones semanales, mientras que un producto maduro puede revisarse mensual o trimestralmente. El principio importa más que el intervalo: revisa el par con la frecuencia suficiente para actuar antes de que la contrapartida resulte costosa o insegura.
Un par solo resulta útil cuando la organización acuerda qué ocurrirá si se deteriora.
Para ello no basta con definir una línea roja para la divergencia. Los equipos deben considerar tres condiciones:
Fallo absoluto: una medida supera un umbral inaceptable, con independencia de la otra.
Divergencia: una medida mejora mientras se deteriora la que la contrarresta.
Deterioro conjunto: ambos lados empeoran, lo que apunta a un problema más amplio del producto o de su funcionamiento.
Cada par debe tener:
una persona responsable designada;
una decisión clara a la que sirva de apoyo;
umbrales o criterios de evaluación acordados;
un proceso de investigación; y
un conjunto de posibles intervenciones.
Sin esos elementos, la organización observa el producto en lugar de gestionarlo.
Antes de añadir otra medida, elige una decisión de producto importante y responde a estas preguntas. Anota las respuestas para que la revisión concluya con un siguiente 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 valor mejora, ¿qué podría empeorar?
Identifica el resultado que debes proteger y una medida que revele cualquier perjuicio. Por ejemplo, combina el coste por interacción con la calidad evaluada del resultado 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, y después busca grupos que obtengan peores resultados. Considera también las condiciones iniciales: una baja satisfacción puede reflejar una frustración anterior a la interacción de asistencia.
4. ¿Qué nos haría actuar y quién se responsabiliza de la respuesta?
Establece criterios para actuar cuando una medida supere un límite inaceptable, una mejore mientras la otra empeora o ambas se deterioren. Acordad quién investigará, qué comprobará primero y cuándo informará de los resultados.
5. ¿Sigue encajando este par con la etapa actual del producto?
Decide si mantenerlo, sustituirlo o retirarlo. Una fase piloto puede centrarse en la fiabilidad de las tareas y la confianza del usuario; un servicio activo quizá requiera un examen más riguroso del coste y la calidad. Fija una fecha para revisar la decisión.
La medición de los productos de IA debe hacer algo más que describir el rendimiento. Debe revelar las contrapartidas que asume la organización y aclarar la siguiente decisión.