Una funeraria grande niega o limita servicios todos los días. No por mala fe: porque el contrato tiene carencias, porque la cuota está en mora, porque el fallecido no figura como beneficiario inscrito, porque el plan nunca incluyó ese ítem. Tomada bien, la decisión es legítima y necesaria: es lo que sostiene la mutualidad frente a los afiliados que sí pagaron. El problema no es decir que no. El problema es lo que queda escrito cuando se dice que no.
Porque seis meses después, cuando llega el derecho de petición, la queja ante la autoridad de consumo o la demanda, nadie va a discutir el veredicto en abstracto. Van a preguntar tres cosas muy concretas: por qué exactamente, en qué cláusula dice eso y quién lo decidió. Y en la mayoría de los grupos funerarios de Latinoamérica, la respuesta a las tres está en la memoria de quien estaba de turno.
Este es el duodé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, call center y adjudicación de cobertura. Con ese último conviene marcar la diferencia desde el principio, porque son las dos mitades del mismo problema: aquel trata de decidir qué cubre un plan; este trata de qué queda escrito cuando la decisión es adversa. Se puede acertar lo primero y fallar catastróficamente en lo segundo.
1. El problema de negocio y cuánto cuesta hoy
El costo de una negativa mal motivada no aparece como una línea en el estado de resultados. Aparece repartido en cinco lugares, y ninguno de los cinco tiene dueño en el organigrama.
- La causal omitida gana el reclamo. Cuando concurren dos motivos —mora y carencia incumplida, por ejemplo— y la comunicación invoca solo uno, el afiliado que desvirtúa ese uno gana. La compañía tenía razón por partida doble y pierde igual, porque solo escribió la mitad.
- La cláusula mal citada convierte un error en una tergiversación. Citar el párrafo equivocado no es un descuido de redacción: es afirmar algo inexacto sobre el contenido del contrato, en el momento de mayor vulnerabilidad de la familia.
- La inconsistencia entre sedes. El mismo hecho, negado en una ciudad y concedido en otra. Sin motivación escrita nadie lo detecta, porque no hay nada que comparar.
- La reversión silenciosa. El coordinador de turno niega, la familia insiste, alguien con más rango autoriza «por excepción» y el caso se cierra. Nadie registra que la negativa inicial estaba mal: la operación aprende cero.
- El tiempo de la gente que más sabe. Cada negativa dudosa escala a las dos o tres personas que conocen los planes viejos. Ese es el verdadero cuello de botella, y es el mismo de madrugada que a mediodía.
Antes de seguir conviene poner una cifra propia, porque este artículo no va a inventar una: toma las autorizaciones de servicio del último año que terminaron en rechazo, el porcentaje de ellas que se revirtió después, y el costo promedio de un servicio prestado por excepción. Ese producto es el piso del problema. El techo —quejas, sanciones, procesos— no lo puedes calcular, y precisamente por eso conviene atacarlo por el lado que sí es medible: qué quedó escrito.
2. La evidencia: acertar y saber explicar son dos capacidades distintas
La intuición del directivo es que si el sistema decide bien, la carta sale bien. La medición dice lo contrario, y con una diferencia grande. El trabajo de referencia hoy es InsLogicBench (ACL 2026), que evaluó ocho modelos sobre 2.621 casos construidos a partir de pólizas reales, con validación de expertos en suscripción. Sus resultados se trasladan casi sin traducción a la previsión exequial.
| Qué se midió | Resultado | Qué significa para una funeraria |
|---|---|---|
| Exactitud de la decisión frente a F1 de citación de la cláusula | 0,82 contra 0,66 en el mejor caso | El modelo acierta si procede o no bastante más de lo que acierta en por qué. Son dos habilidades, no una |
| Un modelo con alta exactitud y citación imprecisa | 0,78 de exactitud con 0,40 de precisión de citación | Trae cláusulas que no vienen al caso. La comunicación se ve fundamentada y no lo está |
| Negar porque falta una condición, en vez de porque se cumple una exclusión | Caídas de 0,88 a 0,71; de 0,93 a 0,64; de 0,93 a 0,62 según el modelo | Es el caso funerario más frecuente: falta antigüedad, falta el registro de defunción, el beneficiario no está inscrito, la cuota está impaga |
| Exclusiones con excepción anidada («excluido salvo que…») | La exactitud cae entre 12,4 % y 17,0 % | Es la estructura literal del clausulado exequial: suicidio excluido salvo transcurrido el plazo, traslado excluido salvo cobertura ampliada |
| Casos con dos causales simultáneas | La exactitud sube, pero la cobertura explicativa baja a 0,57 — la peor de todas | El modelo encuentra una razón suficiente y deja de leer. Acierta el veredicto por razonamiento parcial |
Esa última fila es la que decide el diseño del caso. Un modelo al que se le pide «di si procede y explica por qué» tiende a detenerse en cuanto encuentra una causal que basta. Para un examen, es correcto. Para una negativa, es una motivación incompleta, que es tan riesgosa como la equivocada: deja intacta la causal que no mencionaste y le entrega al reclamante el argumento de que la compañía «cambió de versión» cuando la invoques después.
El segundo bloque de evidencia es sobre la cita en sí, y es igual de sobrio. En tareas generales de respuesta con atribución, a los mejores modelos les falta soporte de citación completo la mitad de las veces (ALCE, arXiv:2305.14627). Un estudio de 2026 sobre citas en escritos judiciales midió qué tan bien un modelo detecta citas fabricadas de otro modelo: recall del 84,4 % pero F1 de 0,55 (arXiv:2606.21155). Y otro trabajo del mismo año encontró el patrón más engañoso de todos: la validez formal de las referencias supera el 94 % y su relevancia el 80 %, mientras la exactitud factual se queda entre el 39 % y el 77 % (arXiv:2605.06635). La cita apunta al documento correcto; lo que la comunicación afirma que ese documento dice, no siempre está ahí.
3. Qué datos del ERP intervienen (y el inventario honesto)
Este caso no se sostiene sobre un modelo: se sostiene sobre si el sistema puede responder, para un servicio concreto, todas las razones por las que no procede. Lo que sigue está verificado contra el código de SFUN, no contra el folleto — y la parte incómoda es la más larga.
Lo que existe hoy y sirve
- Los hechos deterministas están calculados y guardados. La carencia se calcula por rango de edad contra la tabla del plan y se persiste por beneficiario en cuatro fechas distintas —la general, la accidental, la de suicidio y la de repatriación—, más el indicador de si le aplica. La mora se calcula como días transcurridos desde el fin de vigencia y vive en el contrato junto con el estado y el valor en cartera. Los cupos por edad y los parentescos cubiertos son tablas del plan, no código.
- La autorización de servicio es un documento formal y auditable. 82 campos, submittable, con historial de cambios activo. Y algo que suele faltar en sistemas parecidos: registra automáticamente quién, cuándo y desde qué dirección IP solicitó la autorización, en campos de solo lectura que el usuario no puede tocar.
- Una matriz de autoridad configurable sin programar. Una tabla cruza rol contra días de atraso por compañía y define quién puede autorizar un servicio con cuánta mora. La política no está en un manual: está en datos que el sistema evalúa.
- Un validador que no escribe nada. Existe un evaluador en vivo del borrador de autorización, documentado explícitamente como «valida sin escribir, no hace submit ni persiste nada». Es la base técnica correcta para este caso: se puede preguntar sin ensuciar.
- Un precedente de diseño reciente y muy bueno. En agosto de 2026 el motor de descuentos por pronto pago pasó de una decisión de todo o nada a un límite parametrizado de días de atraso por compañía. Lo valioso no es la función: es cómo resolvió el dato faltante. Cuando la mora no se puede calcular, el motor no bloquea — la nota del propio código dice que es «para no negar un descuento por un dato que no se pudo calcular».
El patrón que buscamos ya existe… en el flujo equivocado
El hallazgo más útil de esta revisión es que «enumerar todas las causales de una vez» no es una idea nueva que haya que inventar: ya está implementada y funcionando — pero al vender, no al prestar. Cuando se crea un contrato, el sistema recorre todos los beneficiarios, acumula en una lista los que no cumplen, hace lo mismo con mascotas y con servicios complementarios, y presenta un solo mensaje con las tres listas juntas. Es exactamente el comportamiento que hace falta en la autorización de servicio.
En el momento de prestar, en cambio, el veredicto se produce con una cadena de condiciones encadenadas que sale en la primera coincidencia y devuelve un solo motivo. Dicho de otro modo: la compañía ya sabe hacer lo correcto, y lo hace cuando está cobrando. No lo hace cuando está negando. Corregir eso es mover un patrón que ya existe de un módulo a otro, no investigar nada nuevo.
Lo que no existe, y sin lo cual el caso no funciona
| Brecha verificada | Qué impide | Cómo se ve en el código |
|---|---|---|
| La carencia se calcula, se guarda… y no se evalúa al autorizar | Que la causal más característica del ramo sea una regla y no un criterio | La tabla de carencias del plan se lee en tres lugares del sistema y los tres son de afiliación. En el módulo que autoriza servicios, la palabra «carencia» aparece cinco veces: una consulta que la muestra, dos encabezados de tabla y dos opciones de un desplegable. Ninguna línea la compara con la fecha de defunción |
| El veredicto devuelve una sola causal | Producir la lista completa de motivos en una sola pasada | Es una cadena de condiciones que corta en la primera coincidencia. Y solo evalúa cuatro cosas: estado del contrato, prenecesidad pagada, mora contra el rol y mora informativa. Ni edad, ni parentesco, ni cupos, ni ítems del plan |
| El modelo de datos no admite dos causales | Registrar que un servicio se negó por mora y por carencia | El campo que clasifica el caso es un desplegable de un solo valor —Mora, Carencias, Preexistencias, Servicio Cancelado, Prestado Por Otra Funeraria o Pruebas— y además lo elige el operador a mano: el sistema no lo calcula ni lo contrasta con nada |
| El porqué no queda registrado | Reconstruir seis meses después en qué se fundó la negativa | Los motivos se muestran como mensajes en pantalla. El rechazo se fija al crear el documento, así que ni siquiera hay una transición de estado que el historial pueda registrar: el documento nace rechazado. La razón de una anulación posterior va a un comentario libre |
| La excepción no exige sustento | Auditar por qué alguien pasó por encima de una restricción | El campo se llama, literalmente, «causal para ignorar restricciones», y apunta a un catálogo cuyo registro tiene un solo campo de texto. Elegir una causal basta para continuar |
| No hay clausulado del que citar | Traer el párrafo exacto que sustenta la causal | Es la brecha dura. Buscar «clausulado» o «articulado» en los cuatro módulos implicados devuelve cero. La app destinada a contratos está vacía. El clausulado se guarda como PDF adjunto en una tabla que ningún código consulta, y el campo de beneficios del plan es un editor de texto libre sin versionar |
Vale la pena leer las seis filas juntas, porque cuentan una historia coherente: estos sistemas —el nuestro y los que conocemos— están construidos para ejecutar la decisión, no para sostenerla. Saben frenar un servicio que no procede. No saben explicar por qué lo frenaron. Y esa asimetría no es un descuido de programación: es el reflejo de una industria en la que, hasta ahora, nadie preguntaba.
4. El formato de salida ya está escrito, y tiene tres campos
Hay una buena noticia para quien tenga que diseñar esto: no hay que inventar el formato de una negativa motivada. Otros sectores ya lo escribieron, con rango normativo, y el funerario latinoamericano simplemente todavía no fue alcanzado por esa exigencia. Copiar el estándar de un ramo más regulado es, además, la forma más barata de estar listo cuando llegue.
| Norma | Qué exige | Traducción al servicio exequial |
|---|---|---|
| Reglamento de prácticas de liquidación de siniestros de California (10 CCR § 2695.7(b)(1)) | El rechazo debe listar todas las bases, dar el fundamento fáctico y legal de cada una y, si se apoya en una cláusula, referenciarla y explicar cómo se aplica al caso | Tres campos, no uno: la causal, la cláusula referenciada y la subsunción del hecho concreto en esa cláusula |
| Modelo NAIC #900 de prácticas desleales | Es práctica desleal no dar una explicación razonable y exacta de la base de la negativa, y también tergiversar las cláusulas de cobertura ante el reclamante | Una cita de cláusula incorrecta generada por un modelo no es un fallo técnico: encuadra en tergiversación |
| Circular 2023-03 de la CFPB (crédito) | Prohíbe el motivo genérico o excesivamente amplio aunque la decisión venga de un modelo complejo: hay que dar el motivo principal, específico y exacto | «No procede según las condiciones del plan» es el equivalente funerario del motivo prohibido |
| Boletín modelo de la NAIC sobre uso de IA (diciembre de 2023) | Calibra la exigencia de controles según, entre otros, cuánto interviene un humano en la decisión final y qué tan explicable es el resultado para el consumidor afectado | «El agente propone y una persona firma» no es una decisión cosmética: es la variable con la que un supervisor mide el riesgo |
| Ley 21.719 de Chile (vigente el 1 de diciembre de 2026) | Derecho a no ser objeto de decisiones basadas exclusivamente en tratamiento automatizado con efectos significativos, con intervención humana, explicación de la lógica y revisión | Es el marco con fecha más cercano para un cliente de la región. Negar un servicio exequial contratado afecta significativamente a una persona |
5. Cómo se arma el caso con MCP, paso a paso
La arquitectura es deliberadamente aburrida, y esa es su virtud. Cinco etapas, con la frontera entre lo determinista y lo generativo marcada con tinta.
- El ERP enumera. Todas. Un evaluador determinista recorre el conjunto completo de condiciones —vigencia y estado del contrato, mora contra la matriz de autoridad por rol, las cuatro fechas de carencia del beneficiario contra la fecha de defunción, inscripción, parentesco y cupo, ítem dentro del plan— y devuelve una lista, no un veredicto. Regla no negociable: no corta en la primera falla, acumula. El código de referencia para hacerlo ya existe en el flujo de venta; falta traerlo al de servicio y añadirle la comparación de carencia, que hoy no se hace.
- El agente recupera la cláusula por MCP, en solo lectura. Con las causales ya fijadas, el agente consulta el contrato, el plan, el estado de cartera y el clausulado estructurado, y trae para cada causal el fragmento de texto que la sustenta. Aquí el modelo no elige si hay causal: busca dónde está escrita la que el ERP ya determinó. Esto exige un prerrequisito que hoy no está: que el clausulado exista como dato versionado y no como PDF adjunto.
- El verificador valida cada cita antes de que exista la comunicación. Cada fragmento citado se compara contra el documento fuente: si el texto no aparece literalmente en el clausulado de ese plan y esa vigencia, la salida se bloquea y el caso escala a una persona. Este paso no es un lujo de ingeniería: es lo único que separa una motivación verificable de un texto bien escrito que nadie comprobó.
- El modelo redacta, y solo redacta. Con las causales cerradas y las citas verificadas, produce dos salidas: la comunicación para la familia, en lenguaje llano y con el tono que exige el momento, y el registro interno estructurado —causal, cláusula, hecho— que queda en el expediente. Nada de lo que dice ese texto puede provenir de la memoria del modelo.
- Una persona firma, y su firma significa algo. El coordinador revisa la lista de causales y las citas verificadas, y decide. Si autoriza por excepción, tiene que escribir por qué. La firma en lote sin lectura es el anti-patrón que ya conocemos de otros sectores: no protege a nadie, y menos a quien firma.
Hay una brecha más que conviene decir en voz alta, porque es la que hoy hace inviable el paso 1 aunque todo lo demás estuviera listo: ningún motor de validación está expuesto al MCP. Ni el de venta ni el de servicio. Un agente no puede preguntar «¿qué impide autorizar este servicio?»: tendría que reconstruir el cálculo leyendo documentos sueltos, que es justamente el camino por el que un modelo concluye mal habiendo leído bien.
6. El bucle de mejora continua
Sin bucle, esto es un proyecto que se entrega y se degrada. Con bucle, es un activo que mejora solo. La cadencia que recomendamos es deliberadamente ligera, porque un ritual pesado se abandona en la segunda semana.
- Cada día, la cola de bloqueos. Los casos en que el verificador rechazó una cita son la señal más valiosa del sistema: o el clausulado está mal estructurado, o el plan cambió, o la causal no está donde el agente la busca. Se revisan uno por uno, y cada uno produce una corrección concreta.
- Cada semana, las reversiones. Toda negativa revertida después se revisa: ¿faltaba una causal, sobraba una, o la cita era imprecisa? Es el único indicador honesto de calidad, porque lo produce la realidad y no una autoevaluación.
- Cada semana, las excepciones autorizadas. Si una misma causal se ignora por excepción una y otra vez, no hay un problema de disciplina: hay una regla mal escrita. La política real de la compañía es la que se ejecuta, no la que está en el manual.
- Cada mes, el muestreo ciego. Una persona con criterio revisa una muestra de negativas sin ver lo que produjo el agente, redacta su propia lista de causales y se comparan. Las discrepancias son la agenda del mes siguiente.
- Cada trimestre, el conjunto de casos de prueba. Los casos difíciles resueltos se congelan como pruebas de regresión. Cambiar una regla, un plan o un modelo obliga a volver a pasarlas todas. Sin esto, cada mejora es una apuesta.
7. Gobierno y límites: qué no se automatiza nunca
- El agente nunca niega. Produce la lista de causales y las citas; la negativa la comunica y la asume una persona identificada. No es una precaución retórica: es la variable que los supervisores de seguros usan para calibrar cuánta exigencia aplicar, y es el derecho que la ley chilena hará oponible desde diciembre de 2026.
- Ante el dato ausente, no se niega: se escala. La dirección del fallo seguro se declara por escrito y se prueba. Es exactamente el criterio que el motor de descuentos ya aplica cuando no puede calcular la mora.
- Sin cita verificada no hay comunicación. Si el verificador no encuentra el texto en el documento, el caso sale del flujo automático. Nunca se completa con una paráfrasis del modelo, por buena que suene.
- El agente trabaja en solo lectura sobre el dominio de cobertura. No modifica contratos, no cambia estados, no cierra autorizaciones. Conviene ser exacto sobre cómo se garantiza eso hoy: mediante los permisos de rol del usuario con el que corre el agente y, si hace falta, el modo de solo lectura de todo el sitio. Un perfil de escritura acotado por doctype todavía no existe, y por eso el rol con el que se conecta el agente es la pieza de gobierno más importante del despliegue.
- Los datos del doliente no salen del perímetro. Causa de muerte, condición de salud, creencia religiosa y datos de los deudos son categorías sensibles en toda la región. El caso se diseña sobre el mínimo dato necesario para sustentar la causal, y nada más.
- La comunicación a la familia no se presenta como generada por IA ni se automatiza el envío. El texto lo revisa y lo entrega una persona. En este oficio, el canal es parte del servicio.
8. KPIs: línea base y meta
Los tres primeros definen si el caso funcionó. Los dos últimos evitan que funcione por el motivo equivocado.
| Indicador | Cómo se mide | Línea base típica | Meta |
|---|---|---|---|
| Negativas con cláusula citada y verificada | Casos rechazados con cita validada contra el documento / total de rechazos | Cercana a cero: hoy casi nadie lo registra | 100 %. Es un requisito, no una aspiración |
| Completitud de causales | Negativas cuya lista de motivos coincide con la del revisor ciego | Desconocida — el sistema solo admite una causal a la vez | ≥ 95 % de coincidencia en el muestreo mensual |
| Reversión tras revisión humana | Negativas revertidas / negativas comunicadas | Medible desde hoy con el histórico de autorizaciones | < 5 %, y sobre todo estable: un salto indica una regla mal escrita |
| Tasa de bloqueo del verificador | Casos detenidos por cita no verificable / casos procesados | Alta al principio, y está bien que lo sea | Que baje sola a medida que se estructura el clausulado. Si no baja, el problema no es el modelo |
| Excepciones con sustento escrito | Autorizaciones por excepción con justificación / total de excepciones | Cercana a cero: el catálogo de causales no pide texto | 100 %, con revisión mensual de las causales más usadas |
9. Hoja de ruta de adopción
- Semana 1 — el inventario. Cuenta las negativas del último año, clasifícalas a mano por causal real y mide cuántas tuvieron más de una. Ese número, que hoy nadie tiene, es el argumento del proyecto. Se levanta consultando el ERP en lectura, sin escribir una línea de código.
- Semanas 2 a 4 — la lista de causales. Jurídico, servicio y cartera acuerdan el catálogo cerrado de motivos por los que un servicio no procede, con el dato del ERP que prueba cada uno. Este acuerdo, y no el software, es el entregable que cambia la operación.
- Mes 2 — el clausulado estructurado de los tres planes que más pesan. No los cuarenta. Los tres que concentran el volumen. El modelo lee y propone la estructura; jurídico la valida cláusula por cláusula. Y se resuelve de paso el problema de fondo: que el texto legal quede versionado dentro del sistema, no en un PDF que ningún proceso consulta.
- Mes 3 — el evaluador que acumula, corriendo en paralelo. Junto al proceso actual, sin comunicar nada, comparando sus listas contra las decisiones reales. Empieza por añadir la comparación de carencia contra la fecha de defunción: es la regla de mayor impacto sobre datos que ya están calculados.
- Trimestre 2 — el verificador de citas y el texto asistido. Primero solo para consumo interno del coordinador. La comunicación a la familia se incorpora únicamente cuando la tasa de bloqueo se haya estabilizado y el muestreo ciego dé consistentemente por encima del 95 %.
10. Errores comunes
- Pedirle al modelo la decisión y la explicación en el mismo turno. Es la forma más rápida de conseguir razonamiento parcial: encuentra una causal suficiente y deja de mirar. La medición lo muestra con claridad, y en una negativa esa es justamente la falla que cuesta el caso.
- Confiar en que la cita es buena porque apunta al documento correcto. La validez formal de las referencias supera el 94 % mientras la exactitud de lo que afirman baja al 39 % en el peor caso. La verificación tiene que comparar el texto, no el enlace.
- Poner un segundo modelo a auditar las citas del primero y dormir tranquilo. El mejor detector medido de citas fabricadas alcanza un F1 de 0,55: casi la mitad de las citas malas pasa. Sirve como filtro previo, no como control final.
- Automatizar el envío a la familia. La eficiencia que se gana es marginal y el daño de un error es irreparable. Este es el punto del proceso donde la intervención humana no es un costo: es el producto.
- Empezar por el clausulado en vez de por las causales. Estructurar cuarenta clausulados es un proyecto de meses que se detiene solo. Acordar la lista de causales y su dato probatorio toma semanas y ya produce valor sin una sola línea de IA.
- Dejar la excepción sin sustento. Si autorizar por encima de una restricción no exige escribir por qué, el sistema entero de motivación se vacía por el lado más fácil, y nadie lo nota hasta la auditoría.
Por qué publicamos este caso con sus brechas
Porque el inventario honesto es la parte útil. Existe hoy en SFUN: las carencias parametrizadas por rango de edad y las cuatro fechas por beneficiario, calculadas y guardadas; la mora determinista en el contrato; la matriz de rol contra días de atraso; la autorización de servicio como documento formal, submittable, con historial y con registro automático de usuario, fecha e IP; un validador en vivo que no escribe nada; el patrón de «acumular todas las causales», ya implementado en el flujo de venta; el criterio de no perjudicar ante un dato incalculable, ya escrito en el motor de descuentos; y un MCP con descubrimiento semántico por intención y permisos por rol.
No existe hoy, y así hay que leerlo: la evaluación de la carencia contra la fecha de defunción al autorizar; un veredicto que devuelva la lista completa en vez de la primera causal; el registro de más de una causal por servicio; la persistencia del motivo de la negativa; el sustento obligatorio al autorizar una excepción; la bitácora de decisiones de cobertura; el clausulado como dato versionado del que se pueda citar; el verificador de citas; y la exposición del evaluador al MCP. Nada de eso es exótico —son campos, una función que acumula en vez de cortar, un repositorio de texto y un paso de validación—, pero mientras no existan, lo que este artículo describe a partir del paso 1 es hoja de ruta, y así hay que leerlo.
Y hay algo que conviene decir sin rodeos, porque es el hallazgo más interesante de esta investigación: no encontramos publicación de ingeniería de ninguna aseguradora, healthtech o fintech que documente esta arquitectura con métricas. Hay normas que la exigen, trabajos académicos que miden lo mal que sale cuando no se hace, y material comercial de proveedores sin un cliente identificado. Pero el caso completo —agente que propone, cita verificada, persona que firma, todo medido— no está publicado en ningún sector. Quien lo construya primero en el funerario no va a llegar tarde a nada.
Preguntas frecuentes
¿Puede un agente de IA negar la cobertura de un servicio funerario?
No debería, y la recomendación de este artículo es explícita: el agente propone la lista de causales con sus citas verificadas, y una persona identificada decide y comunica. Hay tres razones convergentes. La primera es de medición: los modelos aciertan la decisión bastante más de lo que aciertan la justificación, y se degradan justo en el escenario funerario más común, que es negar porque falta una condición. La segunda es de gobierno: los supervisores que ya se ocupan del tema calibran su exigencia según cuánto interviene un humano en la decisión final. La tercera es de negocio: en previsión exequial la negativa no se comunica por carta, se comunica cara a cara en el peor momento de una familia, y eso no se delega.
¿Cuándo puede una funeraria negarse a prestar un servicio a un afiliado?
Depende del contrato y del país, y esa es justamente la razón por la que la respuesta tiene que estar en el sistema y no en el criterio de quien esté de turno. Las causales habituales son de cuatro familias: de vigencia (contrato retirado, inactivo o terminado), de cartera (mora por encima del umbral autorizado para el rol que atiende), de carencia (el plazo desde la afiliación no se cumplió, con plazos distintos para muerte natural, accidental, suicidio y repatriación) y de alcance (el fallecido no es beneficiario inscrito, el parentesco no está cubierto, el ítem nunca estuvo en el plan). Lo importante para la dirección no es memorizar la lista: es que el sistema pueda decir cuáles de ellas concurren en este caso, en plural, y dónde está escrita cada una.
¿Por qué no basta con decir «no procede según las condiciones del plan»?
Porque es exactamente el motivo genérico que los reguladores de otros sectores ya prohibieron. La circular de 2023 de la autoridad de crédito estadounidense es tajante: el motivo tiene que ser el principal, específico y exacto, incluso cuando la decisión proviene de un modelo complejo. Y el reglamento californiano de liquidación de siniestros exige tres cosas juntas: todas las bases del rechazo, el fundamento fáctico y legal de cada una, y la explicación de cómo se aplica la cláusula al caso concreto. El sector funerario latinoamericano todavía no tiene una norma equivalente, pero la dirección del viento es inequívoca, y adoptar el estándar antes de que sea obligatorio cuesta lo mismo y evita la migración de urgencia.
¿Esto ya funciona en SFUN?
En parte, y conviene ser exacto. Existe hoy: las carencias por rango de edad con sus cuatro fechas calculadas y guardadas por beneficiario; la mora determinista; la matriz de rol contra días de atraso que define quién puede autorizar con cuánta mora; la autorización de servicio como documento formal con historial y con usuario, fecha e IP registrados automáticamente; un validador que consulta sin escribir; el patrón de enumerar todas las causales, ya funcionando en el flujo de venta; y un MCP con descubrimiento semántico y permisos por rol, suficiente para levantar el inventario de la semana 1. No existe hoy: la evaluación de la carencia al autorizar el servicio, el veredicto con la lista completa de causales, el registro de más de una causal, la persistencia del motivo, el sustento obligatorio de la excepción, el clausulado citable por código, el verificador de citas y la exposición del evaluador al MCP. Todo lo que este artículo describe a partir del paso 1 es hoja de ruta.
¿Cuánto tarda tener la primera versión útil?
La primera versión útil no es software: es el acuerdo sobre el catálogo cerrado de causales y el dato del ERP que prueba cada una. Eso se resuelve en tres o cuatro sesiones entre jurídico, servicio y cartera, y ya produce valor sin una sola línea de inteligencia artificial, porque convierte una decisión de criterio en una decisión verificable. Lo demás —estructurar los tres clausulados que concentran el volumen, hacer que el evaluador acumule en vez de cortar, añadir el verificador— es trabajo de un trimestre. Lo que no conviene es invertir el orden y empezar por el modelo: sin la lista de causales, un agente muy capaz produce textos muy convincentes sobre nada.