El reloj corre desde el aviso: armar el expediente del servicio funerario con IA y MCP

Son las 2:40 de la madrugada. Suena el teléfono de la sede norte. Una hija acaba de perder a su padre en una clínica y llama al número que aparece en un carné plastificado que su papá guardaba desde 2009. La persona que contesta anota el nombre en una libreta, pregunta la cédula, y empieza el trabajo real: buscar si ese contrato existe, si está al día, quién figura como afiliado, si el fallecido es el titular o un beneficiario, si el documento del solicitante coincide con alguien del contrato, y qué papeles hay que pedirle a una familia que en este momento no está en condiciones de buscar nada.

Nadie va a autorizar ese servicio todavía. No porque falte criterio, sino porque falta el expediente. Y entre el aviso y el expediente completo pasan, en la mayoría de las compañías funerarias de Latinoamérica, entre dos y diez horas de un trabajo que no tiene nada de decisorio: es reunir, verificar, cotejar y volver a llamar.

Ese tramo es el tema de este artículo, y la razón es precisa: es el único tramo del proceso funerario que es puramente preparatorio. No hay juicio que emitir, no hay cobertura que adjudicar, no hay negativa que motivar. Solo hay que llegar con todo puesto al momento en que una persona decide. Y resulta que eso —reunir, verificar, señalar lo que falta— es exactamente lo que un agente de IA con acceso al ERP hace bien hoy, mientras que lo que viene después, la decisión, es donde la evidencia publicada en 2026 dice que todavía no llega.

Si vienes del resto de la serie: qué cubre exactamente el contrato, cómo se motiva una negativa y cómo se entrega lo cubierto ya están tratados. Este artículo es el capítulo anterior a los tres.

El problema: el reloj arranca y nadie lo cuenta

El costo de este tramo no aparece en ningún estado de resultados con su nombre. Aparece repartido en cosas que la dirección sí ve pero no atribuye: una familia que llamó tres veces preguntando por qué no arranca el servicio; un asesor de guardia que pasó la noche en el teléfono en vez de atendiendo; un servicio que se autorizó con un dato mal digitado y terminó en una anulación; un contrato que estaba vigente y que nadie encontró porque la cédula tenía un dígito cambiado, así que la familia pagó como particular un servicio que ya había pagado durante quince años.

Hay una razón estructural por la que este costo es invisible: el sistema no sabe a qué hora llamó la familia. En SFUN, el aviso se registra en un documento llamado Reporte de Fallecido, y ese documento tiene ocho campos reales —nombres, apellidos, lugar, teléfono, observaciones y quién reporta—, ningún campo de fecha propio, ningún vínculo con el contrato ni con la autorización posterior, y una clase de Python que no hace absolutamente nada. La única marca temporal es la fecha de creación del registro. La autorización, por su parte, tiene un campo fecha que es de solo lectura y toma el valor ahora: es el instante en que alguien abrió el formulario, no el instante en que sonó el teléfono.

Vale la pena decir cuánto pesa esto en otros sectores que sí lo miden, porque el sector funerario no publica esa estadística y conviene no inventarla. En seguros patrimoniales de Estados Unidos, el ciclo completo desde el primer aviso del siniestro hasta el pago final promedió 40,7 días en el estudio de J. D. Power de 2026, sobre 5.093 asegurados. En el mismo estudio, el 38 % de los clientes avisa por canal digital y el 49 % envía fotos para sustentar la estimación o el pago.

Ese segundo dato importa más de lo que parece: el aviso de fallecimiento es un aviso de siniestro, y el patrón de que la familia mande fotos por un canal digital ya está probado a escala en otra industria. En una funeraria latinoamericana ese canal se llama WhatsApp, y ya está ocurriendo hoy, con o sin proceso que lo reciba.

Por qué el agente prepara y no decide: la evidencia, no la prudencia

«El humano decide» suele decirse como una cortesía corporativa. Aquí no lo es: es lo que dicen los números de 2026, y conviene ponerlos porque son inusualmente claros.

CHI-Bench, publicado en mayo de 2026, evalúa si los agentes pueden automatizar flujos de trabajo sanitarios largos y densos en política —el pariente más cercano de una autorización de servicio exequial—. El resultado en el escenario de punta a punta es 0 %: ningún modelo de frontera completó una sola de las 23 tareas enviadas. El mejor agente alcanza 28,0 % en el primer intento sobre el conjunto completo de 75 tareas, y ninguno supera el 20 % cuando se le exige repetir el mismo acierto en tres corridas. Es decir: ni completa, ni es reproducible.

Un segundo trabajo, de marzo de 2026, es todavía más útil para el diseño. Puso a tres modelos punteros a redactar cartas de autorización previa sobre 45 escenarios validados por médicos, y el hallazgo es que el contenido clínico salía sólido y lo administrativo salía roto de forma consistente: códigos de facturación ausentes, duración de la autorización no solicitada, seguimiento mal planteado. El título del paper lo resume mejor que cualquier paráfrasis: contenido clínico fuerte, andamiaje administrativo débil.

Y hay un dato que cuantifica lo que cuesta decidir con el expediente mal armado. Sobre 52,8 millones de determinaciones de autorización previa en Medicare Advantage durante 2024, el 7,7 % fueron denegadas; de esas denegaciones solo se apeló el 11,5 %, y de las apeladas se revirtió total o parcialmente el 80,7 %. Ocho de cada diez «no» se caen cuando por fin aparece el expediente completo. Preparar bien antes es mucho más barato que revertir después — y en un servicio exequial no hay «después»: el cuerpo no espera a la apelación.

El hallazgo que no esperábamos: SFUN ya escribió este patrón, a mano

Al revisar el código para escribir este artículo apareció algo que vale más que la tesis: el producto ya implementa el patrón correcto de encender un automatismo, y lo implementó sin llamarlo así.

En las tareas programadas de servicios funerarios hay un repaso de autorizaciones que corre cada hora. Recorre las autorizaciones en progreso, evalúa para cada una si ya cumple las tres condiciones de cierre —nada por facturar, nada por entregar, nada por comprar—, cuenta cuántas cerraría… y no cierra ninguna. Hay una constante en el archivo que vale falso, y encima de ella un comentario que explica por qué:

El repaso de autorizaciones mide pero todavía no cierra. Dos de sus tres comprobaciones están rotas (devuelven «OK» siempre), así que encenderlo hoy marcaría como finalizadas autorizaciones bajo un criterio que sabemos equivocado. Se enciende cuando el criterio esté reparado y se haya medido cuántas autorizaciones cambiarían de estado.— Comentario en el código de tareas programadas de servicios funerarios, SFUN

Cada corrida deja un resumen con cuántas evaluó, cuántas cerraría y cuántas fallaron. Eso tiene un nombre en la práctica de despliegue de modelos: modo sombra. El automatismo corre en producción, sobre datos reales, produciendo la decisión que tomaría, sin ejecutarla, hasta que alguien mida si esa decisión habría sido correcta. Es exactamente la forma en que debe encenderse el agente de este caso, y no hay que introducirla como concepto nuevo: ya está corriendo cada hora dentro del sistema.

Qué datos del ERP intervienen: una mitad resuelta y una mitad inexistente

El expediente de una autorización tiene dos mitades, y su estado de madurez en el sistema es radicalmente distinto. Conviene verlo así porque define dónde hay que invertir.

La mitad financiera y de identidad: ya está, y es instantánea

Todo lo que un asesor de guardia averigua por teléfono sobre el contrato ya está resuelto en una sola llamada del servidor. La función que alimenta el formulario de autorización devuelve, al elegir un contrato: días de atraso, fecha de plazo, porcentaje de prestación, tipo de contrato, plan, estado del contrato, si está pagado en su totalidad, fecha de afiliación, tiempo de afiliación, fecha del último pago, acumulado de pagos —sumando recibos de caja de previsión y facturas de venta, ambos ya enviados— y saldo pendiente para los contratos de prenecesidad y título.

A eso se suman tres piezas más que ya existen y que suelen sorprender:

• Validación sin escribir. Hay una función que valida un borrador de autorización sin persistir nada: acumula problemas campo por campo (fecha de defunción anterior al nacimiento, edad superior a 120 años, fecha futura, cédula del fallecido en cero, solicitante que es la misma persona fallecida) y devuelve un veredicto sobre el contrato con su nivel de bloqueo. Es literalmente un simulacro de la decisión, disponible antes de tomarla.
• Detección de expediente duplicado. Al validar, el sistema busca otras autorizaciones en curso para la misma cédula de fallecido y avisa. Y lo hace en nivel de advertencia, no de error, por una razón bien pensada: en una base multicompañía, otra funeraria del grupo puede estar prestando un servicio distinto a la misma persona. Avisa, muestra la lista, y deja que el operador confirme.
• Verificación de identidad contra un registro externo. Existe una función expuesta que consulta los datos de una persona por número de documento contra un servicio externo de verificación, reutilizando el mismo método que usa el alta de cliente. La identidad del solicitante no depende de que alguien la teclee bien.

Y el borrador es un objeto de primera clase: se puede crear incompleto, guardar incompleto y validar sin enviar. Nada de esto es hoja de ruta. Está funcionando hoy en la consola de autorizaciones.

La mitad documental: no existe, y hay que decirlo así

La otra mitad del expediente —los papeles— no está modelada en ninguna parte. Estos son los hechos, verificados sobre el código el 28 de agosto de 2026:

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

El caso se arma en cuatro pasos y ninguno decide. El corte entre lo que existe y lo que es hoja de ruta se marca en cada uno, sin trampas.

Paso 1 — Congelar la hora del aviso

Antes de cualquier modelo: cuando entra el aviso —por teléfono, por WhatsApp o por el portal—, se registra la hora en un campo que nadie pueda reescribir después. Es la línea de salida del reloj y la etiqueta con la que se va a medir todo lo demás. Hoy este campo no existe: es hoja de ruta, y es el prerrequisito de todo el caso. Es el mismo aprendizaje del caso del servicio en riesgo: sin un compromiso congelado no hay cumplimiento que medir.

Paso 2 — Reconstruir la mitad financiera sola, en segundos

Con la cédula del fallecido o del contratante, el agente arma la ficha completa: qué contratos existen para esa persona, en qué estado, con cuántos días de atraso, con qué plan, desde cuándo afiliado, cuál fue el último pago y cuánto se acumuló. También corre la validación en seco, que devuelve los problemas de datos y el veredicto preliminar, y consulta si ya hay otra autorización en curso para el mismo fallecido. Todo esto ya está implementado en el servidor; lo que falta es exponerlo como herramienta al agente, y de eso hablamos abajo.

Paso 3 — Recibir, clasificar y verificar los documentos que llegan por foto

Este es el paso donde entra el modelo de verdad, y donde hay que ser muy honesto con el techo de la técnica. El agente recibe las imágenes por el canal de WhatsApp, clasifica cada una (certificado de defunción, documento del fallecido, documento del solicitante, autorización de cremación), extrae los campos que necesita el expediente y los coteja contra lo que ya está en el sistema: que el nombre del certificado coincida con el del afiliado, que la fecha de defunción sea coherente con la que se digitó, que el número de documento sea el mismo.

¿Cuánto acierta eso hoy? Los benchmarks publicados en 2026 con documentos reales dan un rango incómodo y necesario de conocer:

Tres conclusiones de diseño salen de ahí, y son las que separan un caso que funciona de uno que produce daño:

1. Elegir mal el extractor cuesta cincuenta puntos de exactitud. No es un detalle de implementación: es la diferencia entre un expediente utilizable y uno que hay que rehacer entero. Se evalúa contra documentos propios, no contra la demo del proveedor.
2. Con fotos reales el estado del arte ronda el 70 %. Eso alcanza para armar y señalar faltantes, y no alcanza para autorizar. Es la frontera del caso, escrita con número.
3. Todo campo extraído debe mostrar de dónde salió. Como el anclaje automático tiene techo en 46,4 %, la interfaz tiene que enseñar el recorte de la imagen junto al dato, para que el humano confirme en un segundo en lugar de abrir el archivo. Y todo campo debe traer su puntaje de confianza: lo dudoso se enruta a una persona en vez de pasar como bueno.

Paso 4 — Entregar la lista corta de lo que falta, y a quién pedírselo

El entregable del agente no es un veredicto: es un expediente completo o una lista corta y precisa de lo que falta, con el nombre de quién lo tiene. «Falta el certificado de defunción — lo emite la clínica X, teléfono en el expediente» es útil. «Documentación incompleta» no lo es.

Y aquí hay evidencia que cambia la intuición de mucha gente. La Oficina de Evaluación de Ciencias del Comportamiento del gobierno de Estados Unidos midió, sobre 33.574 solicitantes del programa de asistencia alimentaria, qué pasaba al darles un cargador de documentos móvil sin contraseña. Punto de partida: el 21,1 % de los solicitantes fue denegado porque el analista no tenía información suficiente para evaluar la elegibilidad — no por ser inelegibles. El cargador móvil redujo esas denegaciones solo 1,1 puntos y no movió la inscripción de forma significativa.

El patrón de bloqueo correcto ya está en el producto — pero del lado de la venta

Falta responder una pregunta incómoda: si el expediente está incompleto, ¿qué impide que alguien autorice igual? La respuesta hoy es: nada. Pero el producto ya sabe hacer ese bloqueo, y lo hace muy bien — solo que en el otro extremo del ciclo de vida.

El 21 de agosto de 2026 se integró en el módulo de firma electrónica una declaración de estado de salud obligatoria antes de firmar un contrato. Vale la pena mirar cómo está hecha, porque es el patrón exacto que necesita el expediente del servicio:

• Los consentimientos obligatorios son explícitos y son dos, y el tercero se registra pero deja de bloquear porque se comprobó que no tenía repercusión real. Es decir: la lista de obligatorios se depuró contra el efecto, no contra la costumbre.
• El bloqueo es de dos capas. Sin los dos obligatorios la interfaz no habilita continuar, y si alguien se salta la interfaz, el servidor devuelve un error. Un gate que solo vive en la pantalla no es un gate.
• Queda traza. El valor de cada consentimiento se guarda junto a la firma, no en un comentario.
• Y el documento generado dejó de ser estático: cada línea de la constancia sale solo si ese consentimiento quedó marcado, para no afirmar en un documento legal algo que el firmante no aceptó.

El bucle de mejora continua

Este caso no se implanta: se afina. La revisión tiene tres cadencias, y todas se apoyan en algo que la operación ya produce.

• Cada día, quince minutos. Se revisan los expedientes que llegaron incompletos a la mesa de decisión y se anota el motivo con una etiqueta cerrada: documento no llegó, documento ilegible, campo mal extraído, contrato no encontrado, duplicado no detectado. Cinco etiquetas, no un campo de texto libre — si es texto libre, en dos semanas nadie lo puede contar.
• Cada semana. Se miran los campos con peor calibración: aquellos donde el agente dijo estar seguro y se equivocó. Esos son los que se bajan de umbral para que siempre pasen por revisión humana. Es el uso operativo directo del hallazgo de ConfBench: la confianza mal calibrada es más peligrosa que el error, porque el error se detecta y la sobreconfianza no.
• Cada mes. Se revisa la lista de documentos exigidos por tipo de plan contra lo que de verdad pidió la operación. Casi siempre sobran documentos que nadie mira nunca y falta alguno que se pide siempre de palabra. Depurar esa lista mejora el indicador más que cualquier cambio de modelo, y es exactamente lo que se hizo con los consentimientos de firma.

Y por encima de los tres, el bucle que ya describimos: mientras el agente esté en sombra, la corrida deja el registro de lo que habría hecho. El día que se proponga encenderlo, la conversación no es sobre confianza en la IA: es sobre un número medido durante semanas de operación real.

Gobierno y límites: qué nunca se automatiza

Las reglas de este caso son más estrictas que las de cualquier otro de la serie, porque se trabaja con el dato de una persona que acaba de morir y con una familia que no está en condiciones de detectar un error.

• El agente nunca autoriza ni rechaza. Ni siquiera «pre-aprueba». Prepara, verifica y señala. La transición de estado la ejecuta una persona identificada.
• El agente nunca le dice a la familia si el servicio está cubierto. Esa comunicación es de una persona, siempre, y la razón no es legal: es humana.
• El agente no crea ni modifica registros maestros por su cuenta — ni el expediente del fallecido, ni el cliente, ni el contrato. Propone; una persona confirma. Cuando el emparejamiento de un contrato es aproximado, se muestra la lista de candidatos con sus diferencias, nunca un único resultado presentado como certeza.
• Alcance por rol, no por usuario. Quien recibe avisos ve lo del intake; no ve la cartera consolidada ni el histórico comercial. Es el mismo marco descrito en el gobierno de agentes en el ERP.
• Solo lectura mientras dure la fase de sombra, y el paso a escritura se decide con la medición en la mano, nunca por impresión.

Sobre el marco normativo conviene ser preciso y no exagerar. En Europa, el artículo 22 del Reglamento General de Protección de Datos reconoce el derecho a no ser objeto de una decisión basada únicamente en tratamiento automatizado que produzca efectos jurídicos, y obliga a garantizar al menos la intervención humana. En Latinoamérica no existe todavía un supervisor con norma específica sobre IA en la evaluación de beneficios, pero sí hay una fecha en firme: la Ley 21.719 de Chile activa el 1 de diciembre de 2026 un derecho equivalente. Diseñar hoy con la persona decidiendo no es una concesión: es llegar sin deuda a una fecha que ya está puesta.

KPIs: línea base y meta

Cuatro indicadores bastan. Los cuatro exigen capturar primero la hora del aviso, así que el orden de trabajo no es negociable: primero el campo, después el agente.

Hoja de ruta de adopción

Semana 1 — Poner el reloj y la lista

Dos cosas, ninguna de ellas de inteligencia artificial. Primero, capturar y congelar la hora del aviso, con el aviso vinculado a la autorización que salga de él. Segundo, escribir la lista de documentos exigidos por tipo de plan y parentesco como dato del sistema, no como conocimiento tácito. Se hace entrevistando a los dos o tres asesores que llevan más años, y la primera versión siempre está mal: por eso el bucle mensual existe.

Mes 1 — Sombra y medición

El agente arma el expediente en paralelo al proceso humano y no participa. Al final del mes se comparan las dos versiones: qué documentos identificó bien, qué campos extrajo mal, cuántas veces habría pedido algo que no hacía falta y cuántas veces habría olvidado algo. Se sale con la línea base de los cuatro indicadores y con la tabla de qué tipo de documento se automatiza y cuál no. Es el mismo mecanismo que el repaso horario ya usa dentro del producto.

Trimestre 1 — Encender por documento, no por caso

El error clásico es encender el caso entero. Lo correcto es encender un tipo de documento a la vez, empezando por el más estandarizado y de mayor volumen —normalmente el certificado de defunción—, con umbral de confianza alto y revisión visible. Cuando ese tipo se estabiliza, entra el siguiente. Un caso encendido a medias que funciona vale más que uno completo que nadie usa.

Lo que hoy falta en el producto, dicho sin adornos

Todo lo de esta lista es hoja de ruta, no función disponible. Se publica porque un caso de uso que oculta sus prerrequisitos no le sirve a nadie que tenga que ejecutarlo.

Cinco errores que hacen fracasar este caso

1. Empezar por el modelo y no por el reloj. Sin hora de aviso congelada, a los tres meses nadie sabe si mejoró algo y el proyecto muere por falta de evidencia, no por falta de calidad.
2. Dejar que el modelo recuerde qué documentos hacen falta. Es justo su punto débil: contenido bien redactado, andamiaje administrativo flojo. La lista va escrita en el sistema y verificada por máquina.
3. Creer que el problema es que la familia no sabe subir archivos. El experimento con 33.574 solicitantes lo cerró: facilitar la subida movió 1,1 puntos. Lo que falta es saber cuál documento falta y a quién pedírselo.
4. Ocultar la incertidumbre para que la pantalla se vea limpia. Un campo extraído sin confianza y sin origen visible es peor que un campo vacío, porque se firma sin mirar.
5. Encender el caso completo el primer día. Un tipo de documento a la vez, con umbral alto, y solo después de la fase de sombra. El propio producto ya da el ejemplo: hay un automatismo escrito, funcionando y deliberadamente apagado, con la razón anotada al lado.

Preguntas frecuentes

¿Un agente de IA puede autorizar un servicio funerario?

No, y no es una postura sino una lectura de los datos. El benchmark de flujos sanitarios densos en política publicado en mayo de 2026 reporta 0 % de éxito de punta a punta para todos los modelos de frontera evaluados, y menos del 20 % de reproducibilidad en tres corridas para el mejor de ellos. Lo que sí puede hacer un agente, y hace bien, es dejar el expediente listo para que una persona decida en minutos en lugar de en horas.

¿Qué diferencia hay entre esto y un chatbot que atiende el aviso?

El chatbot atiende la conversación; este caso trabaja sobre el expediente. Son complementarios y de hecho comparten canal: los documentos llegan por el mismo WhatsApp que atiende el bot. La diferencia está en el entregable: el bot devuelve una respuesta a la familia, el agente de expediente devuelve un estado verificable dentro del ERP y una lista de pendientes con destinatario.

¿Sirve si la mayoría de nuestros avisos entran por teléfono y no por WhatsApp?

Sí, y en ese caso la mitad financiera es la que rinde primero: reconstruir contrato, estado, mora, plan y último pago desde la cédula que se dictó por teléfono ya es la mayor parte del tiempo de una llamada nocturna. La mitad documental llega después, cuando la familia manda las fotos — y las manda por WhatsApp aunque haya avisado por teléfono. En seguros patrimoniales, el 49 % de los asegurados ya envía fotos para sustentar el siniestro.

¿Y si el certificado de defunción llega mal fotografiado, de noche y con poca luz?

Es el caso normal, no la excepción, y por eso el diseño exige puntaje de confianza por campo. Con documentos fotografiados reales, el estado del arte medido en 2026 ronda el 69 % de F1 global: si el sistema no distingue lo que leyó bien de lo que adivinó, un tercio de los campos pasa como bueno sin serlo. Con calibración, ese tercio se enruta a una persona y el resto pasa. Sin calibración, este caso no debería encenderse.

¿Cuánto de esto funciona hoy en SFUN y cuánto es hoja de ruta?

Funciona hoy toda la reconstrucción financiera y de identidad: la ficha del contrato en una llamada, la validación en seco que devuelve problemas por campo y veredicto sin escribir nada, la detección de otra autorización en curso para el mismo fallecido y la verificación de identidad por documento contra un registro externo. Es hoja de ruta todo lo documental —el reloj del aviso, el catálogo de documentos exigidos, los adjuntos en la autorización, la lectura de las fotos— y también la exposición de esas funciones de lectura al conector de IA, que hoy solo publica dos funciones de servicios funerarios y ambas son de escritura.

¿Esto tiene sentido en una funeraria de una sola sede?

La mitad financiera sí, y de inmediato, porque el ahorro está en la llamada nocturna y eso ocurre igual con una sede que con veinte. La mitad documental rinde en proporción al volumen: por debajo de unos pocos servicios diarios, escribir el catálogo de documentos exigidos ya ordena la operación aunque nunca se automatice la lectura. En ese escenario, el catálogo es el entregable — y es el barato.

¿Cómo se evita que el agente confunda dos contratos de personas con el mismo nombre?

No se evita con el modelo: se evita con la regla. El agente nunca resuelve una ambigüedad de identidad por su cuenta; muestra los candidatos con sus diferencias y una persona elige. Es la misma disciplina que ya se aplica a la detección de autorizaciones duplicadas del mismo fallecido, que está deliberadamente en nivel de advertencia y no de bloqueo, para que sea el operador quien confirme. Y hay una razón técnica adicional: el anclaje automático de un dato a su fuente tiene techo medido en 46,4 %, así que la decisión de identidad tiene que apoyarse en lo que el humano ve, no en lo que el modelo afirma.

Referencias

• H. Chen y otros — CHI-Bench: Can AI Agents Automate End-to-End, Long-Horizon, Policy-Rich Healthcare Workflows?, arXiv:2605.16679 (15 de mayo de 2026). Fuente del 0 % de éxito de punta a punta sobre 23 tareas enviadas, del 28,0 % del mejor agente en el primer intento sobre 75 tareas y de que ninguno supera el 20 % de reproducibilidad en tres corridas: arxiv.org/abs/2605.16679.
• M. S. Awan y otros — AI-Generated Prior Authorization Letters: Strong Clinical Content, Weak Administrative Scaffolding, arXiv:2603.29366 (31 de marzo de 2026). Fuente del hallazgo sobre 45 escenarios validados por médicos y tres modelos punteros: contenido clínico sólido con huecos administrativos consistentes: arxiv.org/abs/2603.29366.
• A. Joshi y otros — RealDocBench: A Benchmark for Field-Level QA and Layout Understanding on Real-World Regulated Documents, arXiv:2606.07401 (5 de junio de 2026). Fuente del rango de exactitud por campo de 96,0 % a 41,6 % en 18 sistemas, sobre 1.356 preguntas y 581 documentos reales: arxiv.org/abs/2606.07401.
• Y. Wang y otros — From Recognition to Reasoning: Benchmarking and Enhancing MLLMs on Real-World Receipt Document Understanding, arXiv:2605.22413 (21 de mayo de 2026). Fuente del 0,686 de F1 global y 0,548 de parseo estructural sobre 10.656 recibos fotografiados reales: arxiv.org/abs/2605.22413.
• B. Zhang y otros — ExtractBench: A Benchmark for Schema-Guided Enterprise Document Extraction, arXiv:2607.29677 (31 de julio de 2026). Fuente del 95,6 % de F1 de valor del mejor sistema, de la caída de 87,9 % a 27,9 % en documentos largos y del techo de 46,4 % en anclaje al documento fuente, sobre 370 documentos y 4.869 páginas: arxiv.org/abs/2607.29677.
• P. Roy y otros — Can You Trust the Confidence? ConfBench for Vision-Language Models on Document Extraction, arXiv:2608.01792 (3 de agosto de 2026). Fuente del contraste entre modelos bien calibrados y modelos severamente sobreconfiados, y de que la modalidad de imagen más reconocimiento óptico da las mejores estimaciones de confianza; más de 70.000 evaluaciones por entidad sobre 1.346 variantes de documento degradado: arxiv.org/abs/2608.01792.
• R. Naik y otros — Agent-Based Detection and Resolution of Incompleteness and Ambiguity in Interactions with Large Language Models, arXiv:2507.03726 (4 de julio de 2025). Fuente de que separar clasificar, resolver y responder acorta la interacción con el humano cuando la información está incompleta, a costa de más llamadas al modelo: arxiv.org/abs/2507.03726.
• J. Beck y otros — Bias in the Loop: How Humans Evaluate AI-Generated Suggestions, arXiv:2509.08514 (10 de septiembre de 2025), publicado en Harvard Data Science Review 8.2 (primavera de 2026). Fuente del experimento aleatorizado con 2.784 participantes: exigir corregir los errores marcados redujo el compromiso y aumentó la aceptación de sugerencias incorrectas, y la actitud hacia la IA predijo el desempeño mejor que cualquier variable demográfica: arxiv.org/abs/2509.08514.
• Office of Evaluation Sciences (GSA) — Decreasing SNAP denials for insufficient information. Fuente del 21,1 % de solicitantes denegados por información insuficiente para evaluar elegibilidad, y de que el cargador de documentos móvil redujo esas denegaciones solo 1,1 puntos porcentuales sobre 33.574 solicitantes en línea (datos de septiembre a diciembre de 2023): oes.gsa.gov.
• KFF — Medicare Advantage insurers made nearly 53 million prior authorization determinations in 2024 (28 de enero de 2026). Fuente de los 52,8 millones de determinaciones, el 7,7 % de denegaciones, el 11,5 % de apelación y el 80,7 % de reversión total o parcial de las apeladas: kff.org.
• J. D. Power — 2026 U.S. Property Claims Satisfaction Study, difundido el 18 de marzo de 2026 (trabajo de campo de diciembre de 2024 a diciembre de 2025, 5.093 asegurados). Fuente de los 40,7 días promedio desde el primer aviso del siniestro hasta el pago final, del 38 % que avisa por canal digital y del 49 % que envía fotos: claimsjournal.com.
• Reglamento General de Protección de Datos de la Unión Europea, artículo 22. Fuente del derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado que produzca efectos jurídicos, y de la obligación de garantizar al menos la intervención humana: gdpr-info.eu.
• Los ocho identificadores de arXiv citados arriba se verificaron uno por uno contra la interfaz de consulta de arXiv el 28 de agosto de 2026, comprobando título, primer autor y fecha de publicación.
• Las capacidades y las brechas de SFUN descritas en este artículo se verificaron el 28 de agosto de 2026 contra el código de las aplicaciones de servicios funerarios, atención conversacional, firma electrónica y el conector MCP. El patrón de bloqueo en dos capas con traza y constancia no estática proviene de la declaración de estado de salud obligatoria antes de firmar, integrada el 21 de agosto de 2026. Todo lo que aquí aparece como brecha —el reloj del aviso, el catálogo de documentos exigidos, los adjuntos en la autorización, el puente desde el canal conversacional, la traza de transiciones, la exposición de las funciones de lectura al conector y la extracción de campos con confianza y anclaje— se presenta explícitamente como hoja de ruta, no como función disponible.