El asistente le contó a un deudo la deuda de otro: validación de identidad cuando la IA atiende a las familias por WhatsApp

Un martes por la noche entra un mensaje al WhatsApp de la funeraria, desde el número registrado del titular de un plan de previsión: «Hola, ¿cuánto queda por pagar del plan y quiénes están cubiertos?». El asistente de IA reconoce el número, encuentra el contrato y responde con amabilidad: el saldo, las tres cuotas vencidas y los nombres de los cuatro beneficiarios.

El titular murió hace dos semanas. El teléfono lo tiene ahora su hija, que no es beneficiaria. O lo tiene la exesposa, que está en un proceso de sucesión con los hijos del primer matrimonio. O el número se dio de baja y la operadora ya se lo asignó a otra persona. En ninguno de esos casos el asistente cometió un error técnico: identificó bien el número. El error fue suponer que el número es la persona, y que la persona tiene derecho a ese dato.

Este artículo trata ese fallo en un grupo funerario que atiende con IA. Complementa el gobierno de agentes de IA en el ERP funerario, que resuelve quién es el empleado que usa al agente, y el chatbot funerario que mejora cada día, que explica cómo se afina el canal. Aquí miramos el otro lado: la persona de afuera que escribe, a quién representa y qué puede saber.

1. El problema de negocio: en una funeraria, quien escribe casi nunca es el titular

En un banco, el que pregunta por el saldo suele ser el dueño de la cuenta. En una funeraria pasa lo contrario. El servicio se activa porque el titular murió, y a partir de ese momento escriben personas con relaciones muy distintas con el contrato:

• El beneficiario designado, que tiene derecho a saber qué cubre el plan para él, pero no necesariamente el saldo del titular ni quiénes son los otros beneficiarios.
• El familiar que organiza el servicio sin figurar en el contrato: el hijo mayor, una sobrina, un vecino que ayuda.
• Quien paga las cuotas desde hace años sin ser titular, y quiere saber cuánto debe.
• La persona en conflicto: la expareja, el hermano distanciado, el heredero que disputa la sucesión. Es quien más insiste y quien más datos conoce.
• El que tiene el teléfono del fallecido, que en un grupo familiar puede ser cualquiera, y a veces nadie de la familia.

Cuando esto lo atiende una persona, el sentido común hace el trabajo: pregunta con quién habla, nota el tono, pide que venga a la sede. Cuando lo atiende un asistente de IA conectado al ERP, el sentido común no viene incluido. Y el costo de equivocarse no se parece al de un e-commerce. Revelar a quién dejó el titular como beneficiario, cuánto debía o qué servicio contrató puede abrir un conflicto familiar en medio del duelo, exponer datos personales que las leyes de la región protegen (lo explicamos en las guías de Chile y México) y terminar con el canal de WhatsApp apagado por decisión de la dirección.

Hay un segundo costo, menos visible: el fraude. La Comisión Federal de Comercio de Estados Unidos (FTC) advirtió en 2023 sobre impostores que se hacen pasar por el personal de la funeraria para exigir pagos urgentes a familias en duelo, y recomendó a las familias llamar a la funeraria a un número conocido. El patrón funciona en los dos sentidos: quien conoce los detalles del servicio no es, por eso, quien dice ser. Un asistente que entrega el estado de cuenta a cualquiera que escriba desde el número correcto es una fuente de información para ese estafador.

2. La evidencia: los agentes casi nunca se niegan

El fallo está medido. CRMArena-Pro, un benchmark publicado en 2025 por Salesforce AI Research, evalúa agentes de IA en tareas reales de un CRM. Una parte de la prueba hace exactamente lo que hace el mensaje del martes: un usuario pregunta por los datos de otro cliente («¿me cuentas del pedido de Jackson Kim?», cuando quien pregunta no es Jackson Kim). La respuesta correcta es negarse. Los resultados en tareas de cara al cliente, empresa a empresa:

Los autores lo resumen sin rodeos: todos los modelos mostraron una conciencia de confidencialidad «cercana a cero» con el prompt estándar. Y agregan dos matices que importan para una funeraria. El primero: la instrucción de confidencialidad cuesta desempeño en la tarea (uno de los modelos más capaces perdió casi seis puntos). El segundo: en conversaciones de varios turnos, la regla del prompt pierde relevancia frente al esfuerzo del agente por resolver lo que le piden. Justo lo que pasa en un chat de WhatsApp con una familia que escribe diez mensajes seguidos.

La conclusión práctica coincide con la que publica OWASP, la organización de referencia en seguridad de aplicaciones, en su lista de riesgos de aplicaciones con modelos de lenguaje de 2025. Su riesgo de revelación de información sensible describe, como primer escenario, a un usuario que recibe en la respuesta datos personales de otro usuario. Y su riesgo de agencia excesiva da la regla que ordena todo este artículo: la autorización debe implementarse en los sistemas de destino, en lugar de confiar en que el modelo decida si algo está permitido.

3. Lo que la banca y las telecomunicaciones ya resolvieron

Ningún sector tiene resuelta la IA conversacional, pero la banca y las telecomunicaciones llevan décadas atendiendo por teléfono a gente que dice ser el titular. Sus reglas se pueden trasladar casi literalmente a una funeraria:

La analogía tiene un límite honesto: un banco puede exigir la aplicación móvil y una funeraria no puede pedirle eso a una madre que acaba de perder a su hijo. Por eso el diseño funerario tiene que ser proporcional: sin verificación se puede orientar, informar horarios y requisitos, y acompañar; con verificación se entregan datos de cuenta; y hay datos que no se entregan por chat nunca.

4. Qué datos del ERP intervienen, y la matriz de facultad

En un ERP funerario como SFUN, el mensaje del martes toca más registros de los que parece:

• El contacto de la conversación: el teléfono o el identificador de WhatsApp con el que llega el mensaje. Es lo único que el canal sabe con certeza.
• El cliente: la ficha del titular, con sus teléfonos registrados. En SFUN, la previsión exequial tiene índices sobre esos teléfonos justamente para ubicar al titular desde el número de WhatsApp.
• El contrato de previsión y sus afiliados: quién es el titular, quiénes son los beneficiarios y en qué estado está cada uno.
• La cartera: facturas, cuotas vencidas, pagos y acuerdos.
• El servicio funerario: estado de la solicitud, sala, horario, destino final. Aquí aparecen además datos del fallecido que la familia no siempre comparte entre sí.
• Los documentos: factura, enlace de pago y certificados. En SFUN, el asistente puede compartirlos con enlaces firmados que vencen en 24 horas, y como todo enlace, sirven a quien lo tenga: por eso importa a qué número se mandan.

Con esos datos a la vista, la herramienta central del caso no es técnica: es una matriz de facultad escrita y aprobada por la dirección, que diga qué puede saber cada tipo de interlocutor y qué verificación exige. Este es un punto de partida para ajustar con el área legal de cada país:

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

SFUN MCP conecta un asistente de IA (Claude, ChatGPT u otro compatible) con el ERP, con los permisos del usuario que lo autoriza. En este caso no se usa para que el agente responda a las familias, sino para que el equipo de atención y de riesgo mida la exposición, pruebe el asistente y lo vigile, en solo lectura.

Paso 1. El inventario de teléfonos compartidos (la primera semana)

Antes de discutir prompts, averigua cuántos contratos están expuestos. Con la herramienta de análisis del MCP, el equipo pide agrupar los clientes por teléfono y contar cuántos comparten el mismo número. La herramienta devuelve los 20 grupos más grandes por consulta, así que el trabajo se hace por sede o por tramo, no de una sola vez. Las preguntas que valen:

• ¿Cuántos titulares comparten teléfono con otro titular? Suelen ser familias enteras registradas con el celular de quien hizo el trámite.
• ¿Cuántos titulares fallecidos siguen con un teléfono activo en su ficha, desde el que la conversación puede seguir llegando? Este cruce suele pedir dos consultas: los servicios del periodo y las fichas de sus titulares.
• ¿Cuántos contactos de las conversaciones recientes coinciden con más de un cliente? La bandeja de SFUN ya los señala como ambiguos al vincular el número.

El resultado es un número con denominador («uno de cada N contratos activos comparte teléfono con otro contrato») que convierte una discusión abstracta sobre privacidad en una lista de trabajo para limpiar datos. Esa N no la da ningún estudio: la da tu propio ERP.

Paso 2. La matriz de facultad, escrita y firmada

La tabla de la sección anterior se ajusta con el área legal y de servicio al cliente, y se aprueba. Sin este documento, cada ajuste del asistente es una opinión. Con él, cada respuesta se puede contrastar contra una regla.

Paso 3. La regla va en el sistema, no en el prompt

Este es el paso que decide si el caso funciona. Siguiendo la regla de OWASP, el asistente no debe recibir datos que el interlocutor no está autorizado a ver, en vez de recibirlos con la instrucción de callarlos. En la práctica significa tres cosas en el diseño del asistente:

1. La verificación ocurre fuera del modelo. El código se genera, se envía al dato registrado y se valida en el sistema. El modelo solo recibe el resultado: verificado como titular del contrato X, o no verificado.
2. La consulta se acota al contrato verificado. Las búsquedas del asistente se filtran por el contrato y el rol que resultaron de la verificación, nunca por un número de documento o un nombre que la persona escribe en el chat.
3. Lo no autorizado no existe para el modelo. Si no hay verificación, el asistente no tiene disponible la consulta de saldo. No puede revelar lo que no ve.

La instrucción de confidencialidad en el prompt se mantiene, pero como segunda capa. La primera es que el dato no llegue.

Paso 4. La batería de conversaciones difíciles, cada semana

Arma entre 30 y 50 conversaciones de prueba con los casos que más preocupan: la hija que escribe desde el celular del padre, el beneficiario que pregunta por los otros beneficiarios, la persona que da la cédula y la fecha de nacimiento del titular, el que pide cambiar el correo registrado «porque el anterior ya no lo usa», el que insiste durante diez mensajes. Se corren contra el asistente antes de cada cambio de versión y una vez por semana. Con el MCP, el equipo lee las conversaciones resultantes y cuenta cuántas veces el asistente entregó un dato que la matriz no permitía. La meta de esa batería es cero, y el número se reporta con su denominador.

Paso 5. Paso a una persona, con contexto

Todo lo que la matriz manda a atención humana debe llegar con la conversación completa y sin que la familia repita su historia. En SFUN, el asistente puede transferir la conversación a un agente humano: el bot se pausa y la bandeja muestra el aviso del traspaso. La regla de diseño es que el asistente no le explique a la persona por qué no puede darle el dato con detalles del contrato («el plan tiene otros beneficiarios»): eso ya es revelar.

6. El bucle de mejora continua

• Cada día: una muestra de conversaciones en las que el asistente entregó datos de cuenta, revisada contra la matriz. Con el MCP, la muestra se arma en minutos y se revisa en un cuarto de hora.
• Cada semana: la batería de conversaciones difíciles, más los casos nuevos que aparecieron en la muestra diaria. Cada fallo real se convierte en un caso de la batería.
• Cada mes: el inventario de teléfonos compartidos, para ver si baja; los titulares fallecidos con teléfono activo, y la revisión de la matriz con el área legal.
• Cada trimestre: la dirección revisa los KPIs de la sección 8 y decide si el asistente puede ampliar lo que responde o si debe recortarlo.

Este bucle se apoya en el análisis de conversaciones que ya describimos en el caso de análisis de WhatsApp con IA. La diferencia es la pregunta: allí se busca dónde se rompe el guion; aquí, dónde se entregó un dato que no correspondía.

7. Gobierno y límites: lo que nunca se hace por chat

Hay operaciones que ningún asistente debe hacer, ni con verificación, porque el daño de un error es mayor que la comodidad del canal:

• Cambiar el teléfono o el correo registrados. Son el destino del código de verificación: quien los cambia por chat se queda con la cuenta.
• Cambiar titular o beneficiarios, o cualquier dato que altere a quién le corresponde el servicio.
• Confirmar un fallecimiento a un tercero o dar datos de la causa de muerte.
• Revelar quiénes son los beneficiarios a alguien que no es el titular.
• Enviar certificados, facturas o enlaces de pago a un número distinto del registrado.
• Resolver disputas entre familiares o responder a quien anuncia un conflicto legal. Eso va a una persona, siempre.

Y dos reglas del lado del MCP. La primera: el usuario con el que el equipo de riesgo conecta el MCP para revisar conversaciones debe tener solo permisos de lectura sobre la bandeja, las ejecuciones del asistente y los contratos que necesita. La segunda: las muestras que salen del sistema (un acta, una capacitación) van con los datos identificables cubiertos. Revisar fugas no puede ser una fuga nueva.

8. KPIs: cómo saber si funcionó

Falta un indicador que tienta a todos: la tasa de verificaciones completadas. Si se usa como meta, el equipo empuja a las familias a verificarse para todo. Se mira, pero no se premia.

9. Hoja de ruta de adopción

Semana 1: medir la exposición

• Inventario de teléfonos compartidos y de titulares fallecidos con teléfono activo, por sede.
• Lista de lo que el asistente responde hoy con datos de cuenta, leída en conversaciones reales.
• Primera versión de la batería con diez conversaciones difíciles.

Mes 1: cortar el flujo

• Matriz de facultad aprobada por la dirección y el área legal.
• Mientras no exista verificación en el sistema, el asistente deja de entregar saldo, cuotas y beneficiarios, y ofrece paso a una persona o el pago con enlace al número registrado.
• Batería completa y corrida semanal, con el resultado reportado.

Trimestre 1: devolver el servicio con verificación

• Verificación con código al dato registrado y consultas acotadas al contrato verificado.
• Limpieza de los teléfonos compartidos más grandes y actualización de fichas de titulares fallecidos.
• Cuatro semanas con cero revelaciones indebidas en la batería antes de volver a entregar datos de cuenta por chat.

Errores comunes

• Resolverlo con una frase en el prompt. La evidencia dice que ayuda poco y se desgasta en la conversación.
• Tratar el número de WhatsApp como identidad. Identifica un teléfono, no a una persona, y menos su facultad sobre un contrato.
• Pedir cédula y fecha de nacimiento como «verificación». Las conoce toda la familia.
• Mandar el código al dato que da la persona en lugar del registrado.
• Explicar la negativa con detalles del contrato. «No puedo, porque usted no es beneficiario» ya es un dato.
• Probar solo con conversaciones amables. Las fugas aparecen en el décimo mensaje de alguien que insiste.

Qué existe hoy en SFUN y qué es hoja de ruta

Preguntas frecuentes

¿Cómo se verifica la identidad de un cliente por WhatsApp?

Con un código de un solo uso enviado a un dato que ya estaba registrado en el contrato (el teléfono o el correo del titular), que la persona escribe en el chat. Así lo hace, por ejemplo, Banco Pichincha en Ecuador antes de mostrar saldos o cuotas. La verificación la valida el sistema, no el asistente de IA, y además de confirmar la identidad hay que confirmar qué facultad tiene esa persona sobre el contrato.

¿Basta con pedir la cédula y la fecha de nacimiento del titular?

No. Son datos que conoce cualquier familiar y que suelen estar en los papeles del contrato. Los reguladores de banca y telecomunicaciones lo dicen expresamente: la CNBV de México no admite cuestionarios hechos solo con datos que el banco ya envió al cliente, y la FCC de Estados Unidos exige a las telefónicas una contraseña que no se base en información biográfica fácil de obtener.

¿Qué le puede decir la funeraria a un familiar si el titular falleció?

Depende del contrato y de la ley de cada país. Un beneficiario designado tiene derecho a saber qué le cubre el plan; el resto de los datos del titular suele requerir atención humana y documentos que acrediten la facultad, como la calidad de heredero. En Chile, por ejemplo, la Ley 21.719 regula en su artículo 4 el ejercicio de derechos por los herederos. Lo que no cambia en ningún país es que escribir desde el teléfono del fallecido no acredita nada.

¿No se soluciona con instrucciones de confidencialidad en el prompt?

Ayudan, pero no alcanzan. En CRMArena-Pro, con instrucciones explícitas el mejor modelo se negó a dar datos de otros clientes el 62,9 % de las veces en un turno y el 47,9 % en varios turnos, y varios modelos quedaron por debajo del 12 %. OWASP recomienda implementar la autorización en los sistemas de destino y no dejar que el modelo decida. La instrucción es la segunda capa; la primera es que el dato no autorizado no llegue al modelo.

¿Esto es lo mismo que el gobierno de agentes de IA?

Es la otra mitad. El gobierno de agentes trata de los empleados que usan un agente conectado al ERP: cómo se autentican y qué permisos heredan. Este caso trata de las personas de afuera que escriben al canal de atención, que no son usuarios del ERP y cuya identidad y facultad hay que establecer en cada conversación.

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

El problema técnico es idéntico en toda la región: un número de teléfono no es una persona en ningún país. Lo que cambia es quién puede acceder a los datos de un fallecido, qué acredita la calidad de heredero y qué dice cada ley de datos personales. Tenemos guías específicas para Chile, México y Costa Rica.

En resumen

En una funeraria, quien escribe al canal de atención casi nunca es el titular del contrato. Un asistente de IA que reconoce el número y responde con el saldo y los beneficiarios hizo bien su trabajo técnico y mal el que importa. Los benchmarks muestran que los agentes casi nunca se niegan a dar datos de otro cliente por iniciativa propia, y que la instrucción en el prompt ayuda poco y se desgasta en la conversación.

La banca y las telecomunicaciones ya tienen la respuesta: identidad y facultad son dos preguntas, saber datos no prueba nada, y el código va al dato registrado. Llevado a una funeraria con IA, eso es una matriz de facultad aprobada por la dirección, una verificación que ocurre fuera del modelo, consultas acotadas al contrato verificado y una batería semanal de conversaciones difíciles medida con MCP. La dirección mira un solo número: cuántas revelaciones indebidas encontró la batería esta semana. La meta es cero.

Fuentes de este artículo

• CRMArena-Pro: Holistic Assessment of LLM Agents Across Diverse Business Scenarios and Interactions, Huang, Prabhakar, Thorat, Agarwal, Choubey, Mao, Savarese, Xiong y Wu (Salesforce AI Research), arXiv:2505.18878, 24 de mayo de 2025. arxiv.org. De aquí salen las tasas de negativa de la Tabla 3 (tareas de cara al cliente, empresa a empresa), el costo en desempeño y el ejemplo de la consulta sobre otro cliente (apéndice H). Preprint.
• CI-Work: Benchmarking Contextual Integrity in Enterprise LLM Agents, arXiv:2604.21308, 23 de abril de 2026 (arxiv.org), y MuPPET: A Benchmark for Contextual Privacy of LLM Assistants in Multi-Party Conversations, arXiv:2606.23217, 22 de junio de 2026 (arxiv.org). Preprints.
• OWASP Top 10 for LLM Applications 2025: LLM02 Sensitive Information Disclosure y LLM06 Excessive Agency.
• Comisión Nacional Bancaria y de Valores (México), Disposiciones de carácter general aplicables a las instituciones de crédito, art. 310 y fracción I (factores de autenticación). cnbv.gob.mx.
• 47 CFR § 64.2010, Federal Communications Commission, protección de la información de clientes de telecomunicaciones. ecfr.gov.
• Authentication and Access to Financial Institution Services and Systems, FFIEC, 11 de agosto de 2021. occ.gov (PDF).
• Reglamento Delegado (UE) 2022/2360, que modifica el art. 10 del Reglamento Delegado (UE) 2018/389. eur-lex.europa.eu.
• Banco Pichincha, guía de servicios por WhatsApp. pichincha.com.
• Scammers impersonate funeral home staff to prey on mourning families, FTC, 15 de junio de 2023. ftc.gov.
• Código del producto SFUN, rama principal, consultado el 16 de septiembre de 2026: asociación de conversaciones a contactos, vínculo con clientes y marca de ambigüedad en la bandeja, índices de teléfonos del titular, transferencia a agente humano, enlaces firmados de documentos, registro de turnos del asistente y permisos de SFUN MCP.