El motor de recomendaciones de Medicare que se explica solo

La selección de plan Medicare es una de las decisiones financieras más importantes que toma un jubilado americano cada año. Equivocarse — elegir un plan que no cubre a tus médicos, tus medicamentos o tus hospitales preferidos — tiene un costo real y medible. No en términos abstractos, sino en dólares reales que personas con ingresos fijos no tienen.

Cuando empezamos a construir el motor de recomendaciones para Trranu, teníamos un problema técnicamente correcto delante: dado un beneficiario con sus médicos, medicamentos y presupuesto, encontrar el plan Medicare óptimo. Es un problema de optimización abordable. Los datos son públicos (CMS publica los datos de planes), las restricciones son conocidas, y la lógica de matching no es complicada.

Lanzamos una versión de eso. Los usuarios daban su información, el motor puntuaba los planes, y mostrábamos el mejor resultado. El problema: nadie actuaba en base a él.

El problema de confianza

Los beneficiarios de Medicare — especialmente los agentes que los asesoran — no quieren una recomendación. Quieren una justificación. Han sido quemados antes por productos de seguros que parecían buenos en papel y funcionaron mal en la práctica. Quieren entender el razonamiento, no solo aceptar el resultado.

Aquí es donde fallan la mayoría de herramientas de recomendación de IA. Están optimizadas para la recomendación, no para la explicación. El modelo produce una puntuación, la UI muestra un resultado, y se espera que el humano confíe en él. En dominios con consecuencias reales, esto no funciona.

Reconstruimos el motor con la explicabilidad como resultado primario. La recomendación es secundaria.

Cómo funciona el motor

El flujo tiene tres etapas: intake estructurado, análisis de planes y generación de explicación.

Intake. El usuario (típicamente un agente de seguros) proporciona los médicos actuales del beneficiario, las recetas activas (por nombre y dosis), la farmacia preferida y las restricciones de presupuesto. El intake es conversacional — la API de Claude parsea el texto libre para extraer datos estructurados. Un agente puede decir “toma Metformina 1000mg dos veces al día y usa CVS” y el sistema lo gestiona.

Análisis de planes. Contra el intake estructurado, el motor consulta datos de formulario del plan (cobertura de medicamentos y precio por nivel), datos de red de proveedores (si los médicos específicos están en red) y datos de coste del plan (primas, deducibles, máximos de gastos de bolsillo). Produce una lista ordenada de planes con proyecciones de coste para ese beneficiario específico.

Generación de explicación. Esta es la capa de Claude. Para los planes mejor posicionados, el motor genera explicaciones en lenguaje llano: por qué este plan se posiciona donde se posiciona, cuáles de los medicamentos específicos del beneficiario impulsaron la recomendación, cuáles son los compromisos entre las dos mejores opciones. No descripciones genéricas de planes — razonamiento específico a nivel de persona.

Por qué “que se explique solo” es la parte difícil

Generar una recomendación precisa es un problema de ingeniería de datos. Generar una explicación fiable es un problema completamente diferente.

La explicación tiene que ser:

Específica. “Este plan cubre a tus médicos y tus medicamentos” no sirve de nada. “Este plan cubre al Dr. Martínez en Memorial y cubre Eliquis en nivel 2, lo que reduce tu coste anual de medicamentos en aproximadamente $1,400 comparado con el Plan B” es lo que mueve a las personas.

Honesta sobre la incertidumbre. Los datos de planes Medicare cambian. Las redes cambian a mitad de año. Los formularios se actualizan. La explicación tiene que reconocer qué se sabe con certeza y qué debe verificar el agente antes de la inscripción.

Sin alucinaciones. En contextos de salud, un error en la inclusión de red o el nivel de medicamento no es un error menor. La capa de explicación está restringida a referenciar solo los datos que el sistema ha recuperado realmente — sin interpolación ni inferencia sobre coberturas que los datos no confirman.

Con la voz correcta. El resultado lo leen agentes de seguros, no ingenieros. El lenguaje tiene que ser profesional pero no técnico, seguro pero no absoluto.

Lo que cambió después de la reconstrucción

Después de lanzar la versión centrada en la explicación, las tasas de completar el flujo de recomendación mejoraron notablemente. Los agentes dejaron de pedir hablar con un supervisor antes de actuar en base al resultado. La explicación les daba algo que mostrar a sus clientes — un documento que podían entregar y discutir, no un resultado de caja negra que tenían que defender.

La lección generalizó más allá de Medicare. En cualquier dominio donde las consecuencias son reales y el humano es responsable del resultado, la IA tiene que hacer que el humano parezca informado, no dependiente. Una explicación que el agente entiende y puede defender vale más que una recomendación estadísticamente óptima pero opaca.

La IA específica de dominio es, en gran medida, confianza específica de dominio. El modelo es solo el mecanismo.