DIAGNÓSTICO DE SALUD DEL CLIENTE BASADO EN EVIDENCIA

La IA interpreta la evidencia y comunica resultados. No es dueña de la autoridad diagnóstica.

Un sistema de diagnóstico asistido por IA que evalúa si un cliente está logrando los resultados que justificaron la compra, identifica las condiciones que respaldan o amenazan esos resultados, expone evidencia faltante o contradictoria, y ayuda a los equipos de Customer Success a decidir qué merece atención primero.

EL PROBLEMA

Todo equipo de Customer Success termina construyendo, comprando o heredando un health score. Casi ninguno confía en él.

El patrón se repite en todas las empresas. Un modelo produce un número, normalmente rojo, amarillo o verde, y el CSM dueño de la cuenta no puede explicar por qué se movió. El número no puede decir qué evidencia usó, si esa evidencia alguna vez fue confirmada como cierta, o qué tendría que pasar para cambiarlo. Cuando el número y el juicio del propio CSM no coinciden, el número pierde, en silencio, y el equipo vuelve a las hojas de cálculo y a la intuición.

Eso no es una falla de herramienta. Es una falla de autoridad. Al sistema se le pidió tomar una decisión que no tenía forma de justificar.

La pregunta que este proyecto buscó responder: ¿puede un sistema asistido por IA evaluar la salud de un cliente de una forma en que un CSM o un ejecutivo realmente confíe, es decir, que muestre su evidencia, admita lo que no sabe, y nunca anule en silencio el criterio de una persona sobre la cuenta?

INVESTIGACIÓN

Antes de escribir una sola línea de metodología, la pregunta de partida fue por qué los health scores existentes no logran ganarse la confianza, no cómo construir una mejor fórmula de puntuación. Tres patrones de falla se repitieron en los enfoques revisados.

OPACIDAD

Un puntaje compuesto único comprime docenas de señales en un solo número. Esa compresión es exactamente lo que destruye la confianza, porque el CSM no puede rastrear el número hasta una razón.

CEGUERA A LA EVIDENCIA

La mayoría de los modelos de puntuación tratan cada dato de entrada como igualmente cierto. Un rumor de un hilo de correo y una renovación de contrato confirmada se promedian como si tuvieran el mismo peso.

FALSA CONFIANZA

Cuando falta evidencia o es contradictoria, la mayoría de los sistemas igual producen un número limpio en lugar de admitir el vacío. El resultado se ve decisivo hasta que resulta estar equivocado.

Un diagnóstico de salud se gana la confianza siendo auditable, no siendo inteligente.

DECISIÓN DE DISEÑO

La decisión de diseño central se derivó directamente de esa hipótesis: separar las partes del sistema que interpretan el lenguaje de la parte que decide el resultado.

Los modelos de lenguaje son genuinamente buenos leyendo evidencia desordenada del cliente, correos, notas de llamadas, tickets, y extrayendo señal estructurada de ahí. No son algo a lo que se le quiera dar autoridad única sobre una conclusión de negocio gobernada, porque pueden ser convincentes y estar equivocados al mismo tiempo.

Por eso el sistema se dividió en dos categorías de trabajo que nunca se mezclan: el trabajo de interpretación, que sigue siendo asistido por IA, y el trabajo de autoridad, que permanece basado en reglas y determinista. Un paso de confirmación humana se ubica entre ambos, deliberadamente. Nada de lo que la IA extrae de la evidencia puede afectar el resultado gobernado hasta que una persona lo confirme.

CÓMO FUNCIONA

El método de 5 pasos

La evidencia atraviesa cinco etapas, y solo una de ellas tiene permitido decidir algo.

01
Evidencia del Cliente

Notas, correos, resúmenes de llamadas: lo que un CSM ya tiene sobre la cuenta.
02
Extracción Estructurada por IA

La evidencia se convierte en candidatos estructurados, como cambios de stakeholders, incidentes de servicio y señales de riesgo, cada uno rastreable hasta el texto exacto de origen del que provino.
03
Confirmación Humana

Un revisor confirma, corrige o rechaza cada candidato antes de que pueda afectar algo más adelante. Nada consecuente avanza solo porque la IA lo dijo.
04
Motor de Reglas Determinista → Resultado Diagnóstico Gobernado

Una metodología fija y publicada, no un modelo ni un prompt, evalúa la evidencia confirmada y produce el resultado diagnóstico: resultado del objetivo, exposición al riesgo, prioridad operativa, y un recuento explícito de lo que permanece incierto.
05
Explicación de IA Fundamentada + Preguntas Diagnósticas

La IA vuelve a intervenir, solo para explicar el resultado gobernado en lenguaje sencillo y formular algunas preguntas sobre lo que sigue sin resolver. No puede introducir un hecho, un riesgo o una conclusión que no esté ya en el resultado gobernado.

QUÉ HACE

Reconstruye evidencia estructurada a partir de notas de clientes en bruto, con cada elemento rastreable hasta su fuente
Trata los estados de la evidencia explícitamente (confirmada, sin confirmar, contradicha) en lugar de promediarlos entre sí
Exige confirmación humana antes de que cualquier evidencia derivada de la IA pueda afectar una conclusión gobernada
Evalúa la salud del cliente mediante una metodología determinista y publicada, no mediante los pesos internos de un modelo
Expone riesgos, incertidumbre y contradicciones explícitamente en lugar de resolverlos en silencio
Genera una explicación de IA fundamentada y un pequeño conjunto de preguntas diagnósticas, cada una rastreable hasta un vacío real y sin resolver

QUÉ SE NIEGA A HACER

No hay un único health score opaco
No hay predicción de abandono (churn)
No hay pronóstico de probabilidad de renovación
No hay ninguna conclusión gobernada generada por IA
No hay resolución silenciosa de evidencia contradictoria
No hay evidencia ni vacíos fabricados
No hay afirmación de validación estadística ni de estar listo para producción SaaS

EL LÍMITE DE AUTORIDAD DE LA IA

La IA interpreta la evidencia y comunica resultados. No es dueña de la autoridad diagnóstica.

Ese límite se aplica en dos puntos separados, no solo se afirma en una diapositiva. En la extracción, todo candidato propuesto por la IA queda inerte hasta que una persona lo confirma; el motor de reglas solo lee evidencia confirmada. En la explicación, la IA recibe un paquete cerrado de hechos ya gobernados y referencias a vacíos sin resolver, nada más, y su respuesta se verifica contra ese paquete antes de que llegue a la pantalla. Si la explicación menciona algo fuera de ese paquete, no se muestra; el resultado diagnóstico subyacente se despliega solo, por su cuenta.

La IA puede equivocarse en cómo formula algo, y en el peor de los casos aparece un aviso simple de que la explicación no está disponible. No puede equivocarse en el diagnóstico en sí, porque nunca tiene voto sobre el diagnóstico.

DEMOSTRACIÓN

Existe un prototipo funcional: una aplicación en Streamlit que guía a un revisor a través de todo el flujo, de principio a fin, desde la evidencia en bruto hasta un resultado gobernado y una explicación de IA. Las capturas de pantalla abajo son de esa aplicación en ejecución. Pruébala tú mismo con el escenario insignia, o revisa el código directamente.

PRUEBA EL PROTOTIPO VE EL REPOSITORIO EN GITHUB

Pantalla de configuración de CHDM con el selector de escenario de ejemplo — Pantalla de configuración con el selector de escenario de ejemplo, mostrando el punto de entrada sin datos reales de clientes.

Cola de revisión de evidencia con candidatos sin confirmar en espera de una decisión humana — La cola de revisión de evidencia, mostrando candidatos sin confirmar en espera de una decisión humana, el filtro de confirmación hecho concreto.

Panel de Resultado Diagnóstico mostrando prioridad operativa, revisión de evidencia, confiabilidad y resultado del objetivo — El panel de Resultado Diagnóstico: prioridad operativa, estado de revisión de evidencia, confiabilidad y resultado del objetivo juntos, claramente etiquetados como derivados de las reglas.

Panel de Explicación de IA y Preguntas Diagnósticas, expandido — El panel de Explicación de IA y Preguntas Diagnósticas, expandido, mostrando la narrativa generada y sus preguntas clasificadas, cada una apuntando a un vacío real.

EVALUACIÓN

El sistema se validó por capas, avanzando de lo sintético a lo real en cada etapa.

567 pruebas automatizadas aprobadas al cierre final del MVP, cubriendo la metodología determinista, el pipeline de extracción, la máquina de estados de confirmación y la capa de fundamentación de la explicación.
Evaluación de escenarios sintéticos contra casos de referencia elaborados y etiquetados a mano que ejercitan los casos límite de la metodología.
Validación en vivo del modelo, ejecutando los pipelines reales de extracción y explicación contra un modelo de lenguaje real y no solo contra fixtures predefinidos.
Validación de confirmación humana, confirmando que la evidencia confirmada, corregida y rechazada mueve el resultado gobernado exactamente como se especifica, y que la evidencia sin confirmar nunca lo hace.
Validación de consecuencia confirmar vs. rechazar, demostrando que el resultado gobernado realmente difiere según la decisión de confirmación de una persona.
Validación de la explicación fundamentada, incluyendo un falso positivo detectado en vivo en el verificador de citas, diagnosticado y corregido bajo una restricción explícita de "no debilitar la fundamentación", y luego confirmado como corregido con pruebas de regresión adversarias.
Pruebas manuales de humo de extremo a extremo en Streamlit, recorriendo la aplicación real en ejecución para confirmar que el resultado determinista, la explicación de IA y el comportamiento de caché funcionan juntos como fueron diseñados.
Verificación de regresión en entorno limpio, reinstalando las dependencias desde cero y volviendo a ejecutar toda la suite de pruebas antes de cada hito entregado.

LO QUE ESTE SISTEMA NO HACE, DICHO DIRECTAMENTE

Un sistema construido sobre "admite lo que no sabes" debería exigirse el mismo estándar a sí mismo.

Este es un prototipo funcional, no software de producción. No hay autenticación, ni persistencia, ni multiusuario, ni despliegue.
No ha sido validado contra cuentas de clientes reales ni un conjunto de datos de producción, solo escenarios sintéticos y etiquetados a mano.
No predice abandono (churn) ni probabilidad de renovación, y nunca fue diseñado para hacerlo.
No hace ninguna afirmación de validación estadística sobre resultados; las pruebas automatizadas verifican que el software se comporta según lo especificado, no que la metodología prediga resultados de negocio.
No es un agente autónomo de Customer Success. No actúa sobre una cuenta; produce un resultado diagnóstico para que una persona actúe.
Los pasos de IA dependen de un modelo de lenguaje en vivo y cargan con las limitaciones ordinarias de esa tecnología: pueden fallar, y el sistema está diseñado para fallar de forma cerrada, sin mostrar nada en lugar de mostrar algo sin fundamento, cuando eso ocurre.

LO QUE APRENDÍ

El reto técnico de este proyecto resultó ser la parte fácil. Lograr que un modelo de lenguaje extraiga señal estructurada de texto desordenado, o que formule una explicación coherente, es hoy un problema resuelto en la mayoría de los dominios que importan.

El problema más difícil, y el que vale la pena llevar a cualquier futuro sistema de IA, fue decidir dónde debía detenerse la voz de la IA y dónde debía empezar una regla, o una persona. Es tentador dejar que un modelo capaz maneje todo el juicio de principio a fin, porque puede hacerlo. La disciplina está en negarse a ese atajo deliberadamente: escribir de antemano, con precisión, qué decisiones la IA nunca puede tomar por su cuenta, y luego construir el software para que ese límite no se erosione en silencio a medida que el sistema crece.

Eso, en realidad, no es una lección de IA. Es una lección de operaciones disfrazada de IA: la autoridad tiene que diseñarse, no asumirse, o termina yéndose hacia la parte del sistema que resulta más convincente y no hacia la que resulta más responsable.