Un grupo funerario que atiende por WhatsApp con un asistente de inteligencia artificial recibe, tarde o temprano, este reclamo: «el asistente me dijo que el plan cubría la cremación, y ahora me la cobran», o «me confirmaron que estaba al día y me negaron el servicio». La familia tiene la captura de pantalla. La empresa tiene una pregunta difícil: ¿esa respuesta la dio el asistente o una persona, con qué versión de sus instrucciones, y con qué dato del ERP?
La pregunta importa porque cada respuesta tiene un dueño distinto. Si el asistente leyó bien el contrato y lo explicó mal, el problema está en sus instrucciones. Si leyó un dato equivocado, el problema está en el ERP. Si la versión que respondió ya fue reemplazada, hay que saber cuántas familias recibieron la misma respuesta mientras estuvo publicada. Y si respondió una persona, el asunto ni siquiera es de IA.
Este artículo es un caso de uso concreto de inteligencia artificial conectada al ERP por MCP, escrito para servicio al cliente, la gerencia comercial, contraloría y el área jurídica de un grupo funerario. Complementa la prueba de conversaciones antes de publicar (lo que se hace antes) y el bucle diario de mejora del asistente (lo que se hace en general): aquí se trata de un reclamo concreto, reconstruido hasta la versión que respondió.
1. El problema de negocio: la empresa responde por lo que dijo el asistente
El caso más citado es de una aerolínea, y el tema era justamente un duelo. En Moffatt v. Air Canada (2024 BCCRT 149, Tribunal de Resolución Civil de Columbia Británica, 14 de febrero de 2024), el asistente del sitio web le explicó a un pasajero que podía pedir la tarifa por duelo después de viajar, algo que la política de la aerolínea no permitía. La aerolínea alegó que el asistente era responsable de sus propias respuestas; el tribunal lo rechazó y la condenó a pagar CAD 812,02 entre diferencia de tarifa, intereses y costas. La cifra es pequeña; el principio no: lo que dice el asistente en tu canal lo dice tu empresa. No es un precedente obligatorio en Latinoamérica, pero es exactamente el razonamiento que hará cualquier autoridad de protección al consumidor.
La Oficina de Protección Financiera del Consumidor de Estados Unidos (CFPB) llegó a la misma conclusión en su informe sobre asistentes conversacionales en la banca (junio de 2023): los asistentes a veces dan respuestas equivocadas, no reconocen que el cliente está presentando un reclamo y lo dejan dando vueltas sin llegar a una persona. En una funeraria con previsión, esos tres riesgos se traducen en tres reclamos típicos:
- Cobertura. «Me dijeron que el plan cubría cremación, traslado desde otra ciudad o un beneficiario nuevo.»
- Estado de cuenta. «Me confirmaron que estaba al día» o «me dijeron que con este pago quedaba habilitado».
- Compromiso comercial. «Me ofrecieron un descuento, un plazo o la condonación de la mora.»
El costo de no poder reconstruir el turno no es solo el valor del servicio en disputa. Es que la empresa decide a ciegas: o reconoce todo para cerrar el caso (y no corrige la causa), o lo niega todo (y arriesga una queja ante la autoridad y la reputación con una familia en duelo). Además, el plazo corre: en varios países el reclamo formal tiene respuesta obligatoria en pocas semanas; en el Perú, por ejemplo, el Libro de Reclamaciones exige responder en 15 días hábiles.
2. Qué datos del ERP intervienen
La reconstrucción usa cuatro registros del módulo de atención por WhatsApp de SFUN (Contacto AI) y los datos del contrato:
| Registro | Qué aporta al reclamo | Límite que hay que conocer |
|---|---|---|
| Conversación | El contacto, la bandeja, el estado del asistente en esa conversación (activo, esperando, transferido a una persona) y la versión vigente | La versión vigente se guarda como texto y refleja el estado actual, no el del día del reclamo |
| Mensaje | Cada mensaje con su dirección, su autor (familia, asistente, persona del equipo o sistema), el usuario que lo envió si fue una persona, y la hora | No apunta al turno del asistente que lo generó |
| Ejecución del turno | La versión del asistente que respondió (dato obligatorio), la conversación, el estado, la entrada que recibió (los últimos mensajes), la salida que produjo (hasta 60.000 caracteres), la hora de inicio y fin, la duración y el error si lo hubo | No guarda qué datos del ERP consultó el asistente dentro del turno |
| Versión del asistente | Identificador único, etiqueta, descripción del cambio, quién la cargó y cuándo, y el paquete completo con sus instrucciones | No registra quién la publicó ni cuándo |
| Contrato, plan y cartera | Lo que de verdad cubría el plan y el estado de cuenta de la fecha | Hay que leerlo con la fecha del reclamo, no con la de hoy |
Todos esos registros se pueden leer por SFUN MCP con los permisos del usuario que consulta. Eso es lo que permite que un asistente de IA, en solo lectura, arme el expediente en minutos en vez de que alguien de sistemas lo busque a mano en la base.
3. Cómo se arma con MCP, paso a paso
Lo usa la persona de servicio al cliente o de calidad que recibe el reclamo, con un asistente de IA conectado por MCP a una cuenta de solo lectura. La frecuencia es por evento: cada reclamo que mencione una respuesta del canal de WhatsApp.
Paso 1. Ubicar la conversación y el mensaje reclamado
Con el número de la familia y la fecha aproximada, el asistente busca la conversación y lista los mensajes de esa ventana. La captura que trae la familia se compara con el texto registrado: si coincide, se marca el mensaje exacto con su hora. Si no aparece, el reclamo cambia de naturaleza (otro número, otro canal, una captura editada) y se trata por otra vía.
Paso 2. Separar quién respondió: el asistente o una persona
Cada mensaje dice si lo escribió el asistente o una persona del equipo (y cuál). Ese dato resuelve una parte sorprendente de los reclamos: la frase discutida la escribió un asesor después de una transferencia. Si hubo transferencia, la nota privada que deja el sistema con el motivo marca el momento en que el asistente dejó de responder.
Paso 3. Encontrar la ejecución del turno
Si respondió el asistente, se busca la ejecución de esa conversación cuya hora de inicio y fin encierra la hora del mensaje, y se confirma que la salida registrada contiene el mismo texto. Este cruce es por conversación y hora, porque hoy el turno no apunta al mensaje: cuando la familia escribió varios mensajes seguidos o hubo un reintento, puede haber dos candidatos, y el asistente debe mostrarlos los dos en vez de elegir uno.
Paso 4. Identificar la versión y lo que cambió
La ejecución dice qué versión respondió. De esa versión se leen la descripción del cambio, quién la cargó y cuándo, y se compara con la anterior. Dos preguntas cierran este paso: ¿la versión sigue publicada? y ¿cuántas ejecuciones hizo esa versión? Como el ERP no guarda la fecha de publicación, el periodo en que una versión atendió se deduce de su primera y su última ejecución; es un dato confiable, y además es el que importa: cuántas familias pudieron recibir la misma respuesta.
Paso 5. Cotejar contra el contrato y la política
Con la fecha del mensaje, el asistente lee el plan del contrato, sus beneficiarios y el estado de cartera de ese día, y pone lado a lado lo que dijo el asistente y lo que dice el contrato, citando la cláusula, igual que en una negativa de cobertura con la cláusula citada. Como el turno no registra qué datos consultó el asistente, la entrada y la salida son la evidencia: si la salida menciona un saldo o una cobertura, se verifica si ese dato existía en el ERP en esa fecha.
El entregable: una ficha de reconstrucción con cuatro salidas posibles
| Dictamen | Qué significa | Qué se hace |
|---|---|---|
| Error del asistente | El dato del ERP era correcto y el asistente lo explicó mal o prometió algo que la política no permite | Se responde a la familia reconociendo el error; se corrige la instrucción; se buscan las otras conversaciones de la misma versión con la misma respuesta |
| Dato equivocado en el ERP | El asistente repitió bien un dato que estaba mal (cobertura mal parametrizada, pago no aplicado) | Se corrige el dato y se revisan los contratos con la misma parametrización |
| Respuesta de una persona | La frase la escribió un asesor | Se trata como un caso de calidad del equipo, no del asistente |
| Sin evidencia de la promesa | La conversación existe pero no contiene lo que se reclama, o la frase admite otra lectura | Se responde con la transcripción y la cláusula, con tono de acompañamiento |
La ficha la arma el asistente de IA; el dictamen lo firma una persona, y la respuesta a la familia también.
4. El bucle de mejora continua
- Cada reclamo reconstruido como error del asistente se convierte en un caso de prueba del banco con el que se valida la siguiente versión antes de publicarla (ver simular conversaciones antes de publicar).
- Cada semana, calidad revisa las fichas de la semana agrupadas por versión: si una versión acumula dictámenes de «error del asistente», se vuelve a la anterior (republicándola) mientras se corrige.
- Cada vez que se publica una versión, el equipo anota en su descripción qué cambió y por qué; esa descripción es lo primero que se lee en el paso 4, y una descripción vacía hace inútil la reconstrucción.
- Cada mes, los dictámenes de «dato equivocado en el ERP» se llevan a quien administra planes y cartera: son errores que también afectan a la atención humana.
5. Gobierno y límites
- Solo lectura. La reconstrucción no modifica nada. La cuenta que usa el asistente de IA no debe poder publicar versiones, enviar mensajes ni cambiar contratos; SFUN MCP tiene un modo de solo lectura para toda la instalación, y las funciones que reejecutan o listan ejecuciones del asistente están deshabilitadas en el conector.
- Datos del doliente. La entrada y la salida del turno contienen conversación con datos personales y, a veces, la causa de muerte. Acceso solo para quien tramita el reclamo, y nada de copiar la conversación completa en la ficha: basta el fragmento discutido.
- Qué nunca se automatiza. El dictamen, la respuesta a la familia, cualquier reconocimiento económico y la decisión de retirar una versión.
- Conservación. Hoy SFUN no borra las ejecuciones de forma automática, lo que permite reconstruir reclamos antiguos, pero también acumula datos personales sin plazo. Cada empresa debe fijar su propio plazo de conservación según su política de datos y los plazos de reclamo de su país. Como referencia, el Reglamento de IA de la Unión Europea pide a los sistemas de alto riesgo conservar sus registros al menos seis meses (art. 19); un asistente de atención funeraria normalmente no es de alto riesgo, pero el criterio sirve.
- Revisión humana del cruce. Cuando el paso 3 devuelve dos turnos candidatos, decide una persona.
6. KPIs: cómo saber si funcionó
| Indicador | Línea base | Meta a 90 días |
|---|---|---|
| Reclamos del canal de WhatsApp con ficha de reconstrucción | Medir el primer mes (normalmente cerca de cero) | 100 % |
| Tiempo desde el reclamo hasta el dictamen | Medir el primer mes | Menos de 2 días hábiles |
| Reclamos en que no se pudo identificar el turno | Medir el primer mes | Menos del 5 % |
| Versiones publicadas con descripción del cambio | Contar las actuales | 100 % |
| Errores del asistente que se repiten en la versión siguiente | Medir el primer trimestre | Cero |
7. Hoja de ruta de adopción
- Semana 1. Definir quién tramita los reclamos del canal, crear la cuenta de solo lectura para el asistente de IA y escribir la plantilla de la ficha con sus cuatro dictámenes.
- Mes 1. Reconstruir todos los reclamos del mes, incluidos los que ya se cerraron, y exigir descripción en cada versión nueva del asistente.
- Trimestre 1. Conectar las fichas con el banco de pruebas y con la revisión semanal por versión; fijar el plazo de conservación de las conversaciones.
Errores comunes
- Leer la versión vigente de la conversación como si fuera la que respondió: hay que leerla en la ejecución del turno.
- Quedarse con el primer turno candidato cuando hay mensajes seguidos o reintentos.
- Cotejar con el contrato de hoy y no con el del día del mensaje.
- Publicar versiones sin descripción del cambio.
- Cerrar el reclamo sin buscar a las demás familias que recibieron la misma respuesta.
Lo que otros sectores ya hacen
El marco de gestión de riesgos de IA generativa del NIST (AI 600-1) recomienda incluir en el inventario de sistemas los modelos con sus versiones y registrar los errores y casi errores. El Reglamento de IA europeo exige a los sistemas de alto riesgo registrar eventos durante toda su vida útil (art. 12). Y en ingeniería es práctica común enlazar cada respuesta generada con la versión exacta de sus instrucciones. La traducción al sector es directa: lo que en un banco es poder mostrar al supervisor qué modelo atendió a un cliente, en una funeraria es poder mostrarle a una familia, con la transcripción y la cláusula, qué le dijo el asistente y por qué.
Qué existe hoy en SFUN y qué es hoja de ruta
| Pieza | Estado |
|---|---|
| Versiones del asistente con identificador, etiqueta, descripción, autor, fecha de carga y paquete completo | Existe |
| Publicar como paso aparte y volver a una versión anterior republicándola | Existe |
| Registro de cada turno con versión, conversación, entrada, salida, duración y error | Existe |
| Autor de cada mensaje (familia, asistente o persona del equipo) y nota de transferencia con motivo | Existe |
| Lectura por MCP de conversaciones, mensajes, turnos y versiones, con los permisos del usuario | Existe (hasta 50 filas por consulta) |
| Modo solo lectura del servidor MCP | Existe, para toda la instalación |
| Ficha de reconstrucción y cruce por conversación y hora | Lo arma el asistente de IA con sus instrucciones; no es un informe del ERP |
| Enlace directo entre el turno y el mensaje que produjo | Hoja de ruta |
| Quién publicó cada versión y cuándo | Hoja de ruta (hoy se deduce de las ejecuciones) |
| Registro de qué datos consultó el asistente dentro del turno | Hoja de ruta |
| Plazo de conservación configurable de las ejecuciones | Hoja de ruta |
Preguntas frecuentes
¿La funeraria responde por lo que diga su asistente de IA?
En la práctica, sí: el asistente habla en el canal de la empresa. El caso Moffatt v. Air Canada (2024) rechazó el argumento de que el asistente respondía por sí mismo. Por eso conviene poder reconstruir cada respuesta discutida.
¿SFUN guarda qué versión del asistente respondió cada mensaje?
Guarda qué versión procesó cada turno, junto con la conversación, la entrada y la salida. El turno se cruza con el mensaje por conversación y hora; un enlace directo es hoja de ruta.
¿Cuánto tiempo se deben conservar las conversaciones del asistente?
Lo define cada empresa según su política de datos personales y los plazos de reclamo de su país. Hoy SFUN no borra las ejecuciones automáticamente; fijar un plazo es parte de la adopción.
¿El asistente de IA responde el reclamo a la familia?
No. Arma la ficha en solo lectura; el dictamen y la respuesta los firma una persona.
¿Aplica igual en todos los países de Latinoamérica?
El método, sí. Cambian el plazo legal para responder el reclamo y las reglas de datos personales de cada país, que fijan cuánto conservar y quién puede leer la conversación.
En resumen
Un asistente de WhatsApp que atiende a miles de familias va a decir algo equivocado alguna vez. La diferencia entre un error aislado y un problema que se repite es poder contestar, para cada reclamo, qué versión respondió, qué dijo, con qué dato y a cuántas familias más. En SFUN, esa reconstrucción se arma con IA y MCP en solo lectura sobre registros que ya existen; la decisión y la palabra final con la familia siguen siendo de una persona. Si quieres ver cómo se hace sobre tus propios datos, conoce SFUN MCP y el marco de gobierno de agentes de IA en el ERP funerario.
Fuentes de este artículo
- Civil Resolution Tribunal of British Columbia, Moffatt v. Air Canada, 2024 BCCRT 149 (14 de febrero de 2024).
- Consumer Financial Protection Bureau, Chatbots in consumer finance (6 de junio de 2023).
- NIST, AI 600-1, Generative Artificial Intelligence Profile (julio de 2024), acciones GV-1.6-003, MG-4.3-002 y MS-2.8-003.
- Reglamento (UE) 2024/1689 de inteligencia artificial, artículo 12 y artículo 19.
- Agencia Andina, plazo de 15 días hábiles para responder el Libro de Reclamaciones (D. S. 101-2022-PCM).
- Código de SFUN (rama principal, consulta del 28 de octubre de 2026) para todo lo que se afirma del producto.