Adjudicación de cobertura con IA y MCP: qué cubre de verdad ese contrato de previsión de hace veinte años

Son las tres y diez de la mañana. En la sala de atención de una funeraria de Medellín, Guayaquil o Monterrey hay una familia que acaba de perder a su padre y un carné plastificado que dice Plan Familiar Oro, emitido en 1998. La hija pregunta lo único que le importa en ese momento: si el plan cubre la cremación, o si va a tener que conseguir dinero esta madrugada. El asesor de turno —que entró a la compañía hace catorce meses— abre una carpeta compartida, busca el PDF del clausulado de ese plan, lee tres páginas en diagonal y responde.

Esa escena se repite, en un grupo funerario grande de Latinoamérica, varios miles de veces al año. Y es, sin exageración, el punto de la operación donde una decisión de treinta segundos tomada por la persona con menos contexto de toda la compañía tiene la consecuencia económica y reputacional más grande. Si el asesor se equivoca a favor de la familia, la funeraria presta un servicio que no vendió: fuga de margen silenciosa, que nadie contabiliza porque nunca aparece como pérdida. Si se equivoca en contra, hay una queja, a veces una demanda, y siempre una historia que circula.

Este es el undécimo caso del cluster de IA, agentes y MCP aplicado a la operación funeraria, después de los de atención, análisis conversacional, desempeño comercial, cobranza, gobierno de los agentes, cuadrantes de turnos, cierre contable, compras e inventarios, inventario de cementerio, KPIs en lenguaje natural y call center. Y es el más incómodo de escribir, porque el inventario honesto de nuestro propio producto dice que la mayor parte de este caso todavía no existe como función disponible. Lo publicamos igual, con el detalle de qué hay y qué falta, porque el prerrequisito que describe es exactamente lo que decide si el caso funciona o fracasa.

1. El problema de negocio y cuánto cuesta hoy

La previsión exequial tiene una característica que la vuelve distinta de casi cualquier otro contrato de servicios: se vende hoy y se presta dentro de quince o veinte años, en un momento en que el titular ya no puede explicar qué compró. Entre la firma y la prestación cambian el catálogo de servicios, los precios, la estructura de sedes, el equipo comercial, la normativa y a veces la propia compañía. Lo único que no cambia es la obligación.

El resultado es un pasivo que casi ningún grupo funerario tiene medido: una cartera de planes vivos con clausulados heterogéneos, muchos de ellos descontinuados hace años, cuya cobertura exacta solo conocen dos o tres personas de la compañía —normalmente la coordinadora de cartera que lleva veinte años y el gerente que vendió esos planes—. Cuando esas personas no están de turno, y a las tres de la mañana nunca lo están, la decisión la toma quien esté.

• Fuga de margen invisible. Cuando el asesor concede de más, el costo no aparece en ningún reporte: se disuelve dentro del costo del servicio. No hay una línea que diga «esto se prestó sin estar cubierto», porque el sistema no distingue lo cubierto de lo concedido.
• Queja, reclamo y riesgo legal cuando se concede de menos. Negar un ítem que sí estaba cubierto, en el momento de necesidad, es el peor error posible en esta industria. Y es indefendible en un proceso, porque no hay traza de por qué se negó.
• Inconsistencia entre sedes y entre turnos. El mismo plan, la misma solicitud, dos respuestas distintas según quién atienda. Es el síntoma clásico de una regla que vive en la cabeza de las personas y no en el sistema.
• Dependencia de personas concretas. Toda la compañía sabe a quién llamar de madrugada para preguntar por un plan viejo. Esa persona es un punto único de falla que nadie ha documentado como riesgo operativo.
• Imposibilidad de retirar clausulados malos. Nadie puede decir cuántos contratos vivos tienen una cláusula ambigua, porque la cláusula está en un PDF y no en una base de datos consultable.

Conviene ponerle una cifra propia antes de seguir, porque este artículo no va a inventar una. Toma los servicios prestados a afiliados del último año, multiplícalos por el porcentaje que tu equipo estime de decisiones dudosas —la mayoría de las direcciones que hacen este ejercicio se queda entre el 3 % y el 8 %— y por el valor promedio del ítem en disputa. Ese número, que no aparece en ningún estado financiero, es el tamaño real del problema. Y la parte incómoda es que hoy no puedes calcularlo con datos: solo estimarlo, porque el sistema no guarda qué se concedió por fuera de la cobertura.

2. El prerrequisito que nadie quiere oír: hoy la cobertura no está en datos

Antes de hablar de agentes conviene mirar dónde vive la cobertura hoy. Y la respuesta, en SFUN y en cualquier otro sistema del sector que hayamos visto, es la misma: la cobertura vive en prosa. En nuestro caso, en tres lugares y ninguno consultable por código de negocio.

• Un campo de texto enriquecido. Plan.beneficios es un editor libre. Lo que se escriba ahí lo lee un humano, nunca un programa.
• Un PDF adjunto por año fiscal. La tabla Documentos Plan guarda el clausulado como archivo. Buscamos referencias a esa tabla en todo el código Python y JavaScript de la aplicación de previsión: cero. Es un archivero pasivo, correcto para conservar el documento firmado e inútil para decidir nada.
• Un bloque HTML generado en el navegador. Contrato.servicios_basicos se arma con JavaScript al abrir el contrato. Sirve para imprimir; no sirve para preguntar.

Hay una segunda desconexión, más silenciosa y más costosa: el catálogo con el que se cubre y el catálogo con el que se factura son dos universos distintos. El plan cubre elementos de un doctype propio —nombre, descripción, valor— que no tiene ningún vínculo con los ítems de facturación del ERP. Buscamos menciones a ese catálogo de coberturas dentro de la aplicación que presta el servicio: cero resultados. Es decir: aunque alguien escribiera hoy la cobertura completa en el plan, el sistema seguiría sin poder cruzarla contra lo que efectivamente se le está cobrando a la familia, porque son dos vocabularios que nunca se presentaron.

La consecuencia de todo esto se ve en un solo número. El doctype donde se arma el servicio del momento de necesidad tiene 202 campos y su controlador supera las mil quinientas líneas; pero su función de validación ocupa cinco líneas, y lo único que hace es sumar totales y limpiar campos de la interfaz. No consulta el contrato, ni el plan, ni la carencia, ni la cartera. La distinción entre lo cubierto y el excedente existe únicamente porque el operador puso los ítems en una tabla o en otra: estructuralmente son idénticos, no hay ningún campo que diga «esto quedó cubierto» ni «esto se negó, y por esto».

3. Qué datos del ERP intervienen (y cuáles ya están bien)

El diagnóstico anterior no significa que el modelo de datos sea pobre. Significa que está bien construido para vender y mal construido para prestar. Vale la pena ver el detalle, porque la mitad del trabajo ya está hecha y en el lugar equivocado.

Dos observaciones que un director de operaciones debería subrayar. La primera: el motor de reglas ya existe y funciona. Al vender un plan, el sistema evalúa las restricciones de edad beneficiario por beneficiario, descuenta cupos y asigna el sobreprecio a quien queda fuera de rango. Incluso hay un modo de prueba que corre esa evaluación completa dentro de una transacción y la revierte, para mostrar el resultado sin escribir nada. Es, exactamente, la arquitectura correcta — aplicada al momento equivocado.

La segunda: la carencia se calcula bien y luego se olvida. Al afiliar a una persona, el sistema busca su rango de edad en la tabla de carencias del plan, calcula la fecha en que queda cubierta y la guarda en el registro del beneficiario, junto con las fechas de carencia por accidente, por suicidio y por repatriación. Cuatro fechas, bien calculadas. Y después, en el momento de necesidad, nunca se comparan con la fecha de defunción. Verificamos esa afirmación cruzando las búsquedas de carencia con las de fallecimiento en las tres aplicaciones implicadas: el único cruce real está en el producto de seguro de vida, no en la previsión.

4. Por qué el LLM no debe decidir: la evidencia

Hay un trabajo que conviene conocer antes de aprobar cualquier presupuesto en este frente, y su resultado es más interesante —y más incómodo— de lo que se suele contar. Un equipo con investigadores de Stanford CodeX, Caltech y Stanford Computer Science tomó pólizas reales de salud y comparó tres caminos sobre las mismas preguntas de cobertura: preguntarle directamente al modelo; pedirle que tradujera el clausulado a un programa lógico sin darle ninguna estructura; y pedirle lo mismo dándole un marco con los hechos válidos y las reglas auxiliares que puede invocar.

La letra pequeña hay que decirla en la misma frase, porque un CFO que sabe leer un estudio la va a buscar. La muestra es diminuta: una póliza hospitalaria simplificada con nueve preguntas, y dos coberturas de un plan universitario real evaluadas con veinte casos de prueba. Sobre esas coberturas más complejas —las que de verdad se parecen a un clausulado de previsión— el mejor modelo llegó al 95 % en una y al 87 % en la otra, y el resto se quedó entre el 50 % y el 60 %. Es decir: esto no está resuelto, y nadie ha demostrado nada de esto sobre contratos de previsión exequial latinoamericanos. La homologación es por analogía, no por evidencia.

Lo que sí es transferible es el argumento estructural, y lo dicen los propios autores: el programa lógico se puede leer, probar, corregir una sola vez y auditar, y el intérprete explica por qué decidió. Cuando la regla vive dentro del modelo no se puede hacer nada de eso, y la respuesta a «¿por qué le negaron la cremación a mi papá?» es un encogimiento de hombros estadístico.

El modo de falla real: no es que invente, es que no la vio

Un trabajo posterior sobre documentos de cobertura médica midió dónde falla exactamente la traducción a reglas, y el resultado debería reorientar el control de calidad de cualquier proyecto como este: cerca de tres cuartas partes de los errores fueron atributos omitidos —condiciones que estaban en el documento y que el modelo simplemente no incorporó a la regla— y el resto, lógica incompleta. El modo de falla dominante no es la invención: es la omisión.

La consecuencia para el diseño es directa y muy poco intuitiva: lo que hay que medir no es si el sistema responde bien, sino si vio todas las cláusulas. Un motor que acierta el 95 % de las preguntas que le hacen, pero que ignoró tres condiciones del clausulado porque nunca se las preguntaron, es una bomba de tiempo. Va en la misma dirección un experimento sobre reglas de beneficios públicos que encontró exactitudes altas —del 83 % al 100 % según el programa— con completitud de apenas el 34 % al 63 %: el sistema decía cosas ciertas y omitía la mitad de lo que importaba.

Hay un tercer dato que conviene tener a mano al planear el esfuerzo. En los mejores sistemas medidos de extracción estructurada de contratos, el techo real ronda una F de 0,81, y los campos donde peor rinden son justamente los de duración y los de moneda —vigencia, carencia, tope en valor: la columna vertebral de un plan de previsión—. Traducido: aun con la mejor herramienta, alrededor de uno de cada cinco campos extraídos estará mal. Por eso el paso de aprobación humana campo por campo no es burocracia: es el único punto del proceso donde ese error se detiene.

Cómo lo resolvió un sistema real que sí está en producción

La referencia más útil de todas no es un paper de exactitud, sino una decisión de diseño. Un sistema de autorización previa que opera en salud —revisado sobre más de siete mil casos con determinación humana— combina modelos de lenguaje con estructuras simbólicas y tiene una salida deliberadamente asimétrica: aprueba, o escala a revisión humana. No genera denegaciones. Nunca.

Ese es exactamente el patrón que proponemos para la adjudicación de cobertura funeraria, y no por prudencia genérica: porque elimina de un golpe el riesgo reputacional y legal más grande del proyecto conservando casi todo su beneficio. La mayor parte del volumen son casos claramente cubiertos, y ahí el sistema resuelve solo. Lo dudoso —que es donde de verdad se juega la relación con la familia— llega a una persona con contexto y con autoridad. En una operación funeraria la asimetría es aún más evidente que en salud: aprobar de más cuesta dinero, negar mal cuesta la reputación de la compañía en el peor día de la vida de alguien.

Y un último dato que conviene tener presente antes de soñar con un agente que gestione el caso completo: en el mejor benchmark disponible sobre agentes en flujos densos en política, con manual de operaciones y decenas de herramientas a disposición, el mejor agente resolvió el 28 % de las tareas, y con criterio estricto ninguno superó el 20 %. Un servicio funerario es precisamente eso —denso en normas, con varios roles e irreversible—, así que la conclusión práctica es la misma que venimos sosteniendo en todo este cluster: el agente prepara y explica; el sistema determinista decide; la persona firma.

A esto se suma un argumento que en Latinoamérica pesa cada vez más: la regulación de datos personales y de decisiones automatizadas. Ya cubrimos el caso concreto de la directriz de PRODHAB sobre datos personales en la cobranza funeraria en Costa Rica. Y aunque la jurisprudencia europea no obligue a una funeraria latinoamericana, marca hacia dónde va todo: el Tribunal de Justicia de la Unión Europea resolvió en 2025 que, ante una decisión automatizada, no basta con entregar el algoritmo — hay que describir el procedimiento y los principios efectivamente aplicados de forma que la persona entienda qué datos suyos se usaron y cómo. Un motor de reglas produce esa explicación de manera natural: «se aplicó la cláusula 7.2, tu contrato es de 2003, el traslado excede el tope». Un modelo opaco no puede producirla.

5. Cómo se arma el caso con MCP, paso a paso

Con el diagnóstico sobre la mesa, el caso se construye en cinco pasos. Los tres primeros son de datos y ocurren una sola vez por plan; los dos últimos son operación diaria. Marcamos con claridad qué se puede hacer hoy con el producto tal como está y qué requiere desarrollo.

Paso 1 — Inventariar la cartera de clausulados (hoy, con MCP)

Antes de estructurar nada hay que saber el tamaño del problema: cuántos planes distintos tienen contratos vivos, cuántos contratos hay por plan, cuáles están deshabilitados pero siguen con obligaciones vigentes, y qué antigüedad tiene el más viejo. Esto sí se puede hacer hoy, en modo de solo lectura, con las herramientas de análisis y de informes del MCP. Es el primer entregable y suele ser incómodo: la mayoría de las direcciones descubre que tiene entre tres y cinco veces más clausulados vivos de los que creía, y que una parte de la cartera cuelga de planes que nadie recuerda haber vendido.

Paso 2 — El LLM lee el clausulado y propone reglas (requiere desarrollo)

Aquí es donde la inteligencia artificial aporta de verdad, y no es donde la gente espera. Se le entrega el clausulado —el PDF, el texto libre, lo que exista— y se le pide que devuelva una propuesta de reglas explícitas: qué ítems se cubren, con qué cantidad máxima, con qué tope en valor, bajo qué condición, con qué carencia, con qué exclusiones, para qué parentescos. No una respuesta: una estructura. Cada regla propuesta viene con la cita literal del párrafo del clausulado del que salió, para que un humano la valide en segundos en vez de leer treinta páginas.

El subproducto de este paso es tan valioso como el producto: el modelo señala lo que el clausulado no dice. Cláusulas ambiguas, silencios, contradicciones entre secciones, condiciones que dependen de términos indefinidos. Esa lista es, para el área jurídica y comercial, el mapa de los clausulados que hay que retirar del mercado y de las preguntas que el equipo de atención lleva años respondiendo a criterio propio.

Paso 3 — Una persona aprueba y las reglas quedan versionadas (requiere desarrollo)

Ninguna regla entra en producción sin que alguien con nombre y apellido la apruebe. El paquete de reglas de un plan se aprueba como una unidad, con fecha, responsable y versión, y los contratos quedan atados a la versión vigente cuando se firmaron. Este punto es innegociable y hoy es una brecha real: el plan en SFUN no está versionado —solo se puede deshabilitar—, lo que significa que si alguien edita un plan vivo, la cobertura de los contratos ya firmados cambia hacia atrás, sin que nadie lo note. En un producto que se presta veinte años después de venderse, eso no es un detalle técnico: es el corazón del asunto.

Paso 4 — La adjudicación en el momento de necesidad (requiere desarrollo)

Es el momento que importa. El asesor abre la autorización del servicio y el sistema, contra la versión de reglas correspondiente a ese contrato, responde tres cosas por cada ítem solicitado: si está cubierto, hasta cuánto, y por qué. La carencia se evalúa contra la fecha real de defunción, no contra la de hoy. El estado de cartera entra como condición explícita del plan, no como un semáforo informativo. Y el resultado se escribe en el servicio: qué quedó cubierto, qué quedó como excedente y qué regla produjo cada decisión.

Paso 5 — La consulta en lenguaje natural, que es la parte fácil

Una vez que la cobertura está en datos, preguntar en lenguaje natural es casi trivial, y es lo único de todo este caso que se demuestra bien en una reunión: «¿este contrato cubre cremación?», «¿cuántos traslados le quedan a esta familia?», «¿qué contratos vivos tienen la cláusula de repatriación?». Conviene decirlo con todas las letras, porque el orden se suele invertir en las presentaciones comerciales: la conversación en lenguaje natural es la consecuencia del trabajo, no el trabajo. Sin los pasos 2, 3 y 4, preguntarle al sistema qué cubre un plan devuelve exactamente lo que hay hoy: una lista plana de nombres de servicios, sin condiciones. Es la misma lección que ya desarrollamos en el caso de KPIs en lenguaje natural: lo que decide el resultado no es el modelo, es la definición de negocio.

Sobre qué expone el MCP de SFUN para todo esto, conviene ser preciso. Hoy son dieciocho herramientas, con topes duros y deliberados —veinte filas en el análisis agregado, doscientas en un informe, cincuenta kilobytes por respuesta— y permisos en tres capas: un rol específico que se verifica antes incluso de leer la petición, los permisos nativos del ERP sin atajos en las operaciones de escritura, y listas explícitas de funciones permitidas y bloqueadas —466 habilitadas contra 694 bloqueadas tras una auditoría de seguridad—. También expone veinte acciones de negocio curadas, entre ellas una validación de contrato en seco que corre el validate real dentro de una transacción y la revierte. Ese mecanismo de «probar sin escribir» es justamente el que necesitaría una adjudicación de cobertura, y ya está construido para otra cosa.

6. El bucle de mejora continua

Un motor de reglas de cobertura no se termina: se afina. El bucle tiene tres cadencias y cada una tiene un dueño distinto.

1. Diario, en operación. Todo caso donde el sistema no alcanzó a decidir o donde un humano contradijo la recomendación entra a una cola. No es una cola de errores: es la lista de las preguntas que el clausulado no responde. Su tamaño es el mejor indicador del avance real del proyecto.
2. Semanal, con jurídico y con la coordinación de servicio. Se revisa esa cola y se decide: o la regla estaba mal escrita y se corrige, o el clausulado es ambiguo y hay que fijar una postura oficial de la compañía, o el caso es genuinamente excepcional y así se registra. Cada decisión produce una nueva versión del paquete de reglas o una entrada en el criterio interno.
3. Trimestral, con la dirección comercial. Se mira el inventario de clausulados desde el otro lado: cuáles generan más excepciones por contrato vivo, cuáles cuestan más de lo que se cobró, cuáles conviene retirar del portafolio y cuáles conviene migrar por acuerdo con el titular. Esta es la conversación que hoy no se puede tener, porque no hay dato con el que tenerla.

Hay un segundo detalle de método que decide la calidad de todo el bucle: construir el conjunto de casos de prueba antes de escribir la primera regla. Entre cincuenta y cien casos reales de los últimos años, con la decisión que la compañía tomó y considera correcta, resueltos a mano por las personas que hoy son la autoridad. Ese conjunto es lo que permite responder con un número —y no con una opinión— a la pregunta de si la nueva versión de las reglas es mejor que la anterior. Sin él, cada cambio es una apuesta.

7. Gobierno y límites: qué no se automatiza nunca

Este caso toca datos de personas fallecidas y de sus familias en el peor día de sus vidas, y produce decisiones con consecuencia económica directa. El marco de gobierno no es un anexo: es parte del diseño. Lo que sigue complementa lo que ya desarrollamos en la guía de gobierno de agentes de IA en el ERP funerario.

8. KPIs: línea base y meta

Siete indicadores bastan, y los dos primeros son los que casi nadie mide hoy. Las metas que se sugieren son razonables para un grupo con varias sedes y una cartera de previsión madura; ajústalas a tu realidad, pero no arranques sin medir la línea base, porque después nadie va a poder decir si esto funcionó.

Una advertencia sobre el segundo indicador, porque es el que se presta a que el proyecto se desvíe. Subir el porcentaje de decisiones automáticas no es el objetivo: el objetivo es que las decisiones sean correctas, consistentes y explicables. Un equipo presionado por ese número escribirá reglas cada vez más agresivas para cubrir casos que en realidad requieren criterio, y el resultado será peor que el punto de partida. Si tienes que elegir un solo indicador para el comité, elige la consistencia entre sedes: mejora solo cuando el sistema está haciendo bien su trabajo.

9. Hoja de ruta de adopción

Semana 1 — El inventario incómodo

Sin desarrollo y sin presupuesto. Con las herramientas de lectura del MCP, responde cuatro preguntas: cuántos planes distintos tienen contratos vivos, cómo se distribuyen los contratos entre ellos, cuántos de esos planes están deshabilitados, y de qué año es el clausulado más antiguo con obligaciones vigentes. Después reúne físicamente los clausulados: la sorpresa habitual no es cuántos hay, sino cuántos no aparecen. Ese hallazgo, por sí solo, justifica la semana.

Mes 1 — Un plan, cien casos y el criterio escrito

Elige el plan con más contratos vivos —normalmente concentra un tercio de la cartera— y trabaja solo sobre él. Construye el conjunto de casos de prueba con las personas que hoy son la autoridad. Pon al modelo a estructurar ese clausulado y a listar sus ambigüedades. Y toma la decisión que más valor genera de todo el proyecto: escribir la postura oficial de la compañía sobre cada ambigüedad. Aunque el software tardara un año en llegar, ese documento ya elimina la mitad de la inconsistencia entre turnos.

Trimestre 1 — Reglas vivas en modo consulta

Las reglas del plan piloto entran al sistema versionadas y atadas a los contratos, y funcionan en modo consulta: el asesor pregunta y el sistema responde con su justificación, pero el flujo del servicio no cambia todavía. Se comparan las respuestas del motor contra lo que el equipo decide, caso a caso. Solo cuando esa comparación se estabiliza, el motor pasa a autorizar automáticamente lo favorable. Y la evaluación de carencia contra la fecha de defunción —que hoy no ocurre— entra aquí, porque es la corrección de mayor impacto y menor complejidad de toda la lista.

10. Errores comunes

• Empezar por el chatbot. Poner un asistente a responder sobre coberturas antes de tener las reglas es automatizar la inconsistencia y añadirle confianza. La respuesta será fluida, citará el clausulado y estará mal una de cada cinco veces.
• Estructurar los 40 clausulados a la vez. El esfuerzo se dispara y el aprendizaje se pierde. Un plan bien hecho enseña qué campos hacen falta de verdad; cuarenta a la vez producen un modelo de datos diseñado en el vacío.
• Olvidar el versionado. Es el error más caro y el más silencioso: si las reglas no están atadas a la versión vigente al firmar, una corrección de hoy reescribe la cobertura de contratos de 2004. Nadie se entera hasta que llega el reclamo.
• Confundir los dos «excedentes». En el sistema, el excedente del plan es un sobreprecio de la prima mensual por afiliar a alguien fuera del rango de edad. El excedente del servicio es lo que la familia paga de más el día del velorio. No comparten una sola línea de código, y llamarlos igual en una reunión de proyecto ha costado semanas de confusión.
• Dejar que el motor niegue. Ya está dicho arriba y se repite aquí porque es el error del que no se vuelve.
• No medir la línea base. Sin el número inicial de inconsistencia entre sedes y de valor prestado sin cobertura, el proyecto no podrá demostrar su resultado, y a los dieciocho meses alguien preguntará para qué se hizo.

Por qué publicamos este caso con sus brechas

Podríamos haber escrito este artículo describiendo una adjudicación automática de coberturas como si existiera. Habría quedado mejor y habría sido falso. La verdad verificable hoy, en el código, es que SFUN modela la previsión con mucho detalle en el momento de vender —cupos, edades, parentescos, carencias, sobreprecios— y prácticamente no la modela en el momento de prestar. Y esa asimetría no es un descuido nuestro: es la del sector entero, porque durante treinta años el problema urgente fue vender planes, no adjudicarlos.

La conclusión práctica cabe en una frase: la inteligencia artificial no va a resolver qué cubre un plan que la compañía nunca escribió en datos. Lo que sí hace, y hace muy bien, es leer treinta clausulados en una tarde, proponer su estructura, señalar dónde son ambiguos y dejarle a un humano la decisión de qué significa cada cláusula. Ese trabajo —tedioso, aplazado durante años y perfectamente automatizable en su parte mecánica— es el que convierte una carpeta de PDF en un activo operativo. Todo lo demás viene después, y viene solo.

Si quieres ver cómo se ve la previsión exequial cuando el contrato, la cartera, el recaudo y el servicio viven en el mismo sistema, empieza por el módulo de previsión exequial de SFUN, por el de gestión de servicios funerarios y por la guía de gestión de cartera y cobranza a escala. Y si el ángulo que te interesa es el contable —cómo se reconoce el ingreso de un plan que se presta once años después—, el desarrollo completo está en el tratamiento contable de la previsión exequial.

Preguntas frecuentes

¿Puede la IA decidir si un plan cubre un servicio?

No debería, y esa es la recomendación de este artículo. El modelo de lenguaje debe leer el clausulado y traducirlo a reglas explícitas contra un esquema definido; la decisión la toma un motor determinista que puede probarse contra casos conocidos, versionarse y auditarse. Y hay un matiz que conviene no saltarse: traducir a reglas sin darle una estructura al modelo produce peores resultados que preguntarle directamente. Lo que hace ganar al enfoque no es el uso de reglas en abstracto, es el esquema al que se obliga a escribirlas — y ese esquema lo diseña la compañía, no la IA. En una decisión que se le comunica a una familia en duelo y que puede terminar en un juzgado, poder mostrar la regla aplicada lo es todo.

¿Qué hago con los clausulados que ya no encuentro?

Es más común de lo que se admite y hay que tratarlo como lo que es: un riesgo jurídico, no un problema técnico. Reconstruye lo que se pueda desde los contratos firmados, los materiales comerciales de la época y el criterio consolidado de quienes atendieron esos casos; documenta la postura oficial de la compañía para los vacíos; y márcalos en el sistema como planes de cobertura reconstruida, para que toda decisión sobre ellos pase por revisión humana. Lo que no se puede hacer es dejarlos donde están hoy: en la memoria de dos personas.

¿Esto ya funciona en SFUN?

En parte, y conviene ser exacto. Existen hoy: el modelo de planes con carencias, cupos por edad y por parentesco; un motor de reglas que evalúa esas condiciones al vender, con modo de prueba que revierte; el cálculo de las cuatro fechas de carencia de cada beneficiario; el historial completo del contrato; y el MCP con sus dieciocho herramientas, sus topes y sus tres capas de permisos, que ya permite hacer el inventario de la semana 1. No existen hoy: la cobertura por ítem con topes y condiciones, el puente entre el catálogo de coberturas y el de facturación, la evaluación de la carencia contra la fecha de defunción, el versionado del plan, las exclusiones modeladas, la traza de por qué se aprobó o negó un ítem, y la bitácora de invocaciones del MCP. Lo que este artículo describe a partir del paso 2 es hoja de ruta, y así hay que leerlo.

¿Cuánto tarda estructurar un clausulado?

La parte mecánica —leer el documento y proponer la estructura— es cuestión de minutos con un modelo actual. Lo que toma tiempo es lo otro: que jurídico, comercial y la coordinación de servicio se pongan de acuerdo sobre qué significa cada cláusula ambigua. En la práctica, un plan grande se resuelve en dos o tres sesiones de trabajo. Y ese acuerdo, no el documento estructurado, es el entregable que de verdad cambia la operación.

¿Por dónde empiezo si solo tengo un mes?

Por el plan con más contratos vivos, y sin escribir una línea de código. Reúne su clausulado, construye entre cincuenta y cien casos reales con la decisión que la compañía considera correcta, pon al modelo a estructurarlo y a listar sus ambigüedades, y cierra el mes con la postura oficial escrita para cada una. Si el proyecto de software se cae, ese documento sigue valiendo. Si sigue adelante, ya tienes el conjunto de prueba contra el cual medir todo lo demás.

¿Aplica igual en todos los países de Latinoamérica?

El caso en sí es regional: la asimetría entre vender y adjudicar es idéntica en toda la región, y por eso este artículo no tiene variantes por país. Lo que sí cambia por país es el marco de datos personales y de decisiones automatizadas, que decide cuánta explicación hay que poder dar. Ese frente lo cubrimos por separado a medida que se mueve —como en el caso de Costa Rica—, y la regla de diseño que se deriva de él es la misma en todas partes: si el sistema decide, el sistema tiene que poder explicar.