El lunes, el equipo ajusta una instrucción del asistente de WhatsApp para que deje de ofrecer acuerdos de pago que la política no permite. El cambio funciona. El jueves, una hija escribe a las dos de la mañana que su madre acaba de fallecer y el asistente, en lugar de transferirla de inmediato a la línea de servicio, le pregunta por el estado de sus cuotas. Nadie tocó esa parte. Pero nadie comprobó tampoco que siguiera funcionando.
Probar un asistente de IA antes de publicarlo significa tener un banco de conversaciones de prueba —los casos que no pueden fallar— y pasar por él cada versión nueva antes de que hable con una familia. Este artículo explica cómo armarlo en un grupo funerario, con qué datos, quién decide y cómo se mide. Está escrito para la gerencia de servicio al cliente, la dirección de operaciones y la dirección de tecnología, y sigue el formato de los casos de este blog.
1. El problema de negocio: cada cambio es una apuesta
Un asistente basado en un modelo de lenguaje no es un menú de opciones. No responde lo mismo dos veces, y un ajuste en un párrafo de sus instrucciones puede cambiar su conducta en un tema que nadie tocó. Quien lo administra suele probarlo con tres o cuatro mensajes escritos a mano, ve que responde bien y publica. Eso prueba lo que se cambió; no prueba lo que se rompió.
En el sector funerario el costo de ese vacío no es una mala reseña. Es una familia en duelo que recibe una respuesta de cobranza, un afiliado al que se le confirma una cobertura que su contrato no tiene, o una persona que pide hablar con alguien y no lo consigue. Y la empresa responde por lo que dice su asistente.
El segundo problema es la consistencia. El estudio académico τ-bench (2024), que prueba agentes de atención con un usuario simulado, herramientas y políticas de negocio, midió algo que una prueba manual nunca ve: el mismo agente que resolvía cerca del 61 % de las tareas de comercio en un intento resolvía menos del 25 % cuando se le exigía acertar la misma tarea ocho veces seguidas. Son modelos de 2024 y la cifra no se traslada a los actuales, pero el hallazgo sí: acertar una vez no significa acertar siempre, y un asistente atiende a miles de familias, no a una.
2. Qué datos del ERP intervienen
En SFUN el asistente vive en Contacto AI, junto a la bandeja de conversaciones, y trabaja sobre los mismos datos del ERP que usa el equipo humano. Para este caso importan cinco familias de datos.
| Dato | Qué guarda | Para qué sirve en este caso | Límite que hay que conocer |
|---|---|---|---|
| Versiones del asistente | Cada paquete subido, con identificador, etiqueta, autor, fecha y descripción | Saber exactamente qué se está probando y qué está publicado | No hay una acción «deshacer»: se vuelve atrás publicando de nuevo la versión anterior |
| Versión publicada | Un puntero por asistente; publicar es un paso separado de subir | Es la compuerta: nada llega a las familias sin ese paso | Publicar afecta a todo el tráfico del canal a la vez |
| Ejecuciones | Un registro por turno: versión, estado, entrada, salida, duración y error; las de prueba quedan marcadas | Leer qué respondió cada versión, en prueba y en producción | Los campos de costo, tokens y detalle por paso existen, pero la plataforma no los llena hoy |
| Conversaciones y mensajes | El historial real, con estado, etiquetas y la transferencia a una persona | Es la cantera de casos: de aquí salen los fallos que el banco debe cubrir | El motivo de la transferencia es texto libre en una nota interna, no un campo; no hay encuesta de satisfacción |
| Contratos, cartera y servicios | Los datos de previsión, pagos y servicios en curso | Decidir cuál era la respuesta correcta en cada caso | Un caso de prueba debe usar contratos de prueba, no los de una familia real |
Con SFUN MCP, conversaciones, mensajes, versiones y ejecuciones son documentos que un asistente de IA puede leer con los permisos de lectura de quien pregunta. Esa es la parte del caso que el conector resuelve: leer y resumir. Ejecutar el asistente y enviarle mensajes no se puede hacer por el conector, y publicar una versión es una decisión que conviene reservar a una persona, desde la pantalla del asistente.
3. Cómo se arma el caso, paso a paso
Paso 0: escribir lo que no puede fallar
Antes de cualquier herramienta, la gerencia de servicio escribe en una página las conductas que ninguna versión puede romper. No las escribe tecnología. Una lista de partida para un grupo funerario:
| Situación | Conducta que se exige | Tipo de comprobación |
|---|---|---|
| Aviso de fallecimiento, a cualquier hora | Transfiere de inmediato a la línea de servicio; no pregunta por pagos ni ofrece productos | Exacta: hubo transferencia en el primer turno |
| Cuota vencida y pide plazo | Explica las opciones que la política permite; no promete condonaciones ni fechas que nadie aprobó | Rúbrica: no hay compromiso fuera de política |
| Pregunta por el contrato de otra persona | No entrega datos de un titular a quien no acredita serlo | Exacta: la respuesta no contiene datos del contrato |
| Pregunta si el plan cubre un servicio | Responde con lo que dice el contrato; si no lo sabe, lo dice y transfiere | Rúbrica: no inventa cobertura |
| Reclamo por un cobro | Registra el reclamo y transfiere; no discute ni reversa | Exacta: hubo transferencia con resumen |
| Pide hablar con una persona | Transfiere sin insistir | Exacta: transferencia en un turno o menos |
| Mensaje que intenta cambiarle las instrucciones | Ignora la instrucción y sigue en su papel | Rúbrica |
La tercera columna importa. Hay conductas que se comprueban sin opinar (hubo o no transferencia) y otras que exigen criterio (el tono fue adecuado para alguien en duelo). Conviene que la mayor parte del banco sea del primer tipo.
Paso 1: sacar los casos de las conversaciones reales
Un banco inventado en una sala de reuniones prueba lo que el equipo imagina. El que sirve sale de lo que ya pasó. Aquí el conector ahorra semanas: quien tiene lectura sobre la bandeja le pide al asistente de IA que busque en las conversaciones de los últimos tres meses las que terminaron en transferencia a una persona, las que tienen ejecuciones con error y las que el equipo etiquetó como problema, y que las agrupe por situación.
«De las conversaciones del último trimestre que el asistente transfirió a un asesor, muéstrame las veinte situaciones más repetidas, con dos ejemplos de cada una y la nota de transferencia.»— Consulta de ejemplo de la gerencia de servicio, con lectura sobre la bandeja
De ahí salen los primeros casos. La guía de evaluación de agentes que publicó Anthropic en enero de 2026 recomienda empezar con entre 20 y 50 tareas tomadas de fallos reales, no con cientos. Mil conversaciones es adonde se llega, no por donde se empieza.
Paso 2: escribir cada caso como una ficha
Cada caso es una ficha corta: quién escribe (una hija, un afiliado en mora, un tercero), qué dice en uno o varios mensajes, con qué contrato de prueba, y cuál es el resultado esperado. El resultado esperado se escribe como un hecho comprobable siempre que se pueda («transfiere en el primer turno») y como una rúbrica de dos o tres líneas cuando no («no promete nada que la política no permita»).
Paso 3: pasar la versión candidata por el banco
La versión nueva se sube, pero no se publica. SFUN permite ejecutarla con una entrada de prueba: la ejecución queda registrada con su versión, su entrada y su salida, marcada como prueba, y no envía ningún mensaje por WhatsApp. Hoy esa ejecución se lanza por la interfaz de programación de la plataforma, no desde una pantalla, y la puede lanzar quien tenga un rol de administración, supervisión o desarrollo. Recorrer el banco completo es, por tanto, un guion que el equipo técnico o el implementador escribe una vez: toma cada ficha, la envía a la versión candidata y guarda la respuesta.
- Es un turno por llamada. Una conversación de varios mensajes exige que el guion reenvíe el historial en cada turno.
- Las acciones no se ejecutan en la prueba. Transferir o enviar una plantilla quedan como intención en la salida; se comprueba que el asistente las pidió, no que ocurrieron.
- La prueba no está aislada de los datos. Si el asistente consulta o escribe en el ERP durante la prueba, lo hace sobre la base real. Por eso los casos usan contratos y contactos de prueba, y por eso conviene correr el banco contra un sitio de pruebas cuando el asistente tiene permiso de escribir.
- Cada caso se corre varias veces. Tres a cinco repeticiones por caso; un caso crítico pasa solo si pasa en todas.
Paso 4: calificar, con una persona al final
Las comprobaciones exactas las hace el guion. Las de rúbrica las puede preparar un modelo de lenguaje que actúa como revisor, pero ese revisor también se equivoca: hay que calibrarlo contra el criterio de personas antes de confiar en él, y las fallas de los casos críticos las lee siempre alguien del equipo de servicio. El resultado es una hoja con tres columnas —pasa, falla, revisar— por versión.
Paso 5: la decisión de publicar
Publicar es un paso explícito en SFUN y lo da una persona. La regla que proponemos: ninguna versión se publica con un caso crítico en falla, y quien aprueba no es quien hizo el cambio. Si después de publicar algo sale mal, se publica de nuevo la versión anterior, que sigue guardada.
4. El bucle de mejora continua
| Cuándo | Qué se revisa | Quién | Qué produce |
|---|---|---|---|
| Cada día | Transferencias a una persona y ejecuciones con error de las últimas 24 horas, leídas por MCP | Supervisión de servicio | Uno a tres casos nuevos para el banco |
| Antes de cada versión | El banco completo contra la versión candidata | Equipo técnico corre; servicio lee las fallas | Decisión de publicar o devolver |
| La semana siguiente a publicar | Las mismas situaciones del banco en conversaciones reales de la versión nueva | Supervisión de servicio | Confirmación o vuelta a la versión anterior |
| Cada trimestre | Casos que ya no aplican, políticas que cambiaron, calibración del revisor | Gerencia de servicio | Banco depurado |
La regla que hace crecer el banco es simple: todo incidente en producción se convierte en un caso. Si una familia recibió una respuesta que no debía, esa situación entra al banco antes de corregir el asistente, y la corrección se prueba contra ella. El detalle del repaso diario está en el chatbot funerario que mejora todos los días; este artículo cubre el paso anterior: que la mejora de hoy no rompa lo que funcionaba ayer.
5. Gobierno y límites
- Quién escribe los casos críticos: la gerencia de servicio, con cumplimiento. Tecnología los implementa, no los define.
- Quién corre las pruebas: un rol técnico con acceso a la plataforma del asistente. No es una tarea para el conector de IA: en SFUN MCP lanzar el asistente y enviar mensajes está deshabilitado.
- Quién publica: una persona distinta de quien hizo el cambio.
- Datos personales: el banco no guarda conversaciones reales; guarda situaciones reescritas con datos de prueba. Quien lee la bandeja por MCP ve lo mismo que vería en pantalla, y ese acceso debe estar limitado a quien lo necesita.
- Lo que nunca se automatiza: la aprobación de publicar, la lectura de las fallas en casos de duelo y la decisión de qué puede prometer el asistente en cobranza.
- Lo que el banco no garantiza: pasar todos los casos no prueba que el asistente no fallará; prueba que no falla en lo que ya se conoce. Por eso existe la revisión de la semana siguiente.
El perfil de inteligencia artificial generativa del NIST (AI 600-1, 2024), una guía voluntaria de Estados Unidos, dedica un apartado a las pruebas previas al despliegue y pide que sus resultados lleguen a quien aprueba la liberación. Es la misma idea: la prueba sirve si la ve quien decide. Para el marco general de permisos y responsabilidades, consulta gobierno de agentes de IA en el ERP funerario.
6. KPIs para saber si funcionó
La línea base es la de tu operación: se mide el primer mes, antes de exigir nada. Las metas son una propuesta editorial, no un estándar del sector.
| Indicador | Cómo se calcula | Línea base | Meta sugerida |
|---|---|---|---|
| Versiones publicadas con banco completo | Versiones publicadas con hoja de resultados ÷ versiones publicadas | Normalmente 0 % | 100 % desde el segundo mes |
| Casos críticos que pasan en todas las repeticiones | Casos críticos sin ninguna falla ÷ casos críticos | La de la versión publicada hoy | 100 %; cualquier otro valor bloquea |
| Incidentes repetidos | Incidentes en producción cuya situación ya estaba en el banco | Primer trimestre | Cero |
| Tiempo de incidente a caso | Días entre el incidente y su ficha en el banco | Sin dato | Dos días hábiles o menos |
| Vueltas a la versión anterior | Publicaciones que se revirtieron en la primera semana | Primer trimestre | A la baja trimestre a trimestre |
| Cobertura del banco | Situaciones de transferencia del trimestre que tienen al menos un caso | Primer mes | 80 % de las veinte más repetidas |
7. Hoja de ruta de adopción y errores comunes
- Semana 1: la página de conductas que no pueden fallar; primera extracción de situaciones desde la bandeja con MCP; 20 a 30 fichas con datos de prueba.
- Mes 1: el guion que recorre el banco contra una versión no publicada; hoja de resultados; regla de «no se publica con un crítico en falla»; línea base de los indicadores.
- Trimestre 1: banco de 150 a 300 casos alimentado por incidentes; repeticiones por caso; revisor automático calibrado para las rúbricas; revisión de la semana siguiente como rutina.
Errores que vemos repetirse: probar solo lo que se cambió; armar el banco con casos felices; copiar conversaciones reales con sus datos; correr cada caso una sola vez; dejar que apruebe quien hizo el cambio; confiar en el revisor automático sin haberlo comparado con personas, y dejar de alimentar el banco cuando pasa la urgencia.
Lo que falta construir: la hoja de ruta de producto
Para que este caso sea una función y no un procedimiento, al producto le faltan piezas que hoy no existen y que no presentamos como disponibles: una pantalla para probar una versión antes de publicarla; un banco de casos guardado junto al asistente; pruebas aisladas de los datos reales; conversaciones de varios turnos con un usuario simulado; calificación automática con registro; publicación gradual a un grupo de números o a una parte del tráfico; un motivo de transferencia estructurado, y el registro de costo y de pasos de cada ejecución, cuyos campos ya están previstos.
De dónde sale el patrón: la prueba previa en otros sectores
| Quién | Qué hace | Qué se traduce al sector funerario |
|---|---|---|
| Nubank (banca digital), artículo técnico de junio de 2026 | Según el propio banco, evaluadores automáticos calibrados contra etiquetas de analistas; solo las versiones que igualan o mejoran sus métricas pasan a una prueba con una fracción pequeña de clientes | La compuerta antes de publicar y el revisor calibrado. La publicación gradual, que SFUN no tiene hoy, va a la hoja de ruta |
| Intercom (software de soporte), documentación de simulaciones | Un cliente simulado recorre un procedimiento con datos de prueba, sin tocar sistemas reales, y el resultado es pasa o falla | Datos de prueba y criterio binario para los casos críticos |
| Salesforce (CRM), anuncio de noviembre de 2024 | Genera cientos de interacciones sintéticas y las corre en un entorno de pruebas | El volumen llega después: primero los casos reales, luego las variaciones |
| τ-bench (investigación) | Mide consistencia: la misma tarea, varias veces | Repetir cada caso crítico y exigir que pase siempre |
Lo que en un banco es «que el asistente no prometa una reestructuración de deuda que nadie aprobó», en una funeraria es «que no prometa una cobertura que el contrato no tiene ni un plazo que cartera no autorizó». Las cifras de los proveedores son declaradas por ellos y no las usamos como referencia. No encontramos un caso publicado, con métricas medidas por un tercero, de un banco de pruebas de este tipo en una empresa funeraria.
Preguntas frecuentes
¿Cómo se prueba un asistente de IA antes de publicarlo?
Con un banco de conversaciones de prueba: situaciones reales reescritas con datos de prueba, cada una con un resultado esperado. La versión nueva se ejecuta contra todas, varias veces, y una persona decide si se publica.
¿SFUN tiene un simulador de conversaciones para el asistente?
No. SFUN guarda las versiones, separa subir de publicar, permite ejecutar una versión no publicada con un mensaje de prueba por la interfaz de programación y registra cada ejecución. El simulador, el banco de casos y la calificación automática no existen hoy en el producto.
¿Cuántas conversaciones de prueba necesita una funeraria?
Para empezar, entre 20 y 50 tomadas de fallos reales. El banco crece con cada incidente; en un trimestre es razonable llegar a unos cientos. Importa más que cubra las situaciones críticas que el número.
¿Puede el asistente de IA conectado por MCP correr las pruebas?
No. Por el conector se leen conversaciones, mensajes, versiones y ejecuciones con los permisos de quien pregunta; ejecutar el asistente y enviar mensajes está deshabilitado. El conector sirve para construir el banco y para revisar después de publicar.
¿Qué pasa si una versión publicada falla con una familia?
Se publica de nuevo la versión anterior, que queda guardada; la situación se convierte en un caso del banco, y la corrección se prueba contra ese caso antes de volver a publicar.
¿La empresa responde por lo que dice su asistente?
Depende de la ley de cada país y conviene consultarlo con tu asesor legal. Como criterio de gestión, trata lo que dice el asistente como lo que dice un empleado en tu nombre: así lo entendió el tribunal canadiense del caso citado.
En resumen
Un asistente que atiende a familias en duelo no se publica porque «respondió bien en las pruebas de ayer». Se publica porque pasó, varias veces, las situaciones que la empresa decidió que no pueden fallar, y porque una persona lo aprobó. SFUN aporta las versiones, la compuerta de publicación, la ejecución de prueba y el registro; el banco y la disciplina los pone el equipo. Si quieres ver cómo se conecta con tu operación, conoce el software funerario con inteligencia artificial de SFUN.
Fuentes de este artículo
- Civil Resolution Tribunal de Columbia Británica, Moffatt v. Air Canada, 2024 BCCRT 149 (14 de febrero de 2024). Lectura parcial de la decisión.
- Yao, Shinn, Razavi y Narasimhan, τ-bench (2024): tabla 2 y sección 5. Modelos de 2024.
- Anthropic, Demystifying evals for AI agents (9 de enero de 2026). Leída por resumen.
- Nubank, Building Customer Support AI Agents at 100M-User Scale (junio de 2026). Leído por resumen; se usa solo el patrón.
- Intercom, simulaciones de procedimientos, y Salesforce, Agentforce Testing Center (documentación y anuncio de proveedor; se usa solo el patrón).
- NIST, AI 600-1 (julio de 2024), apartado de pruebas previas al despliegue.
- Producto: lo descrito de SFUN se verificó en el código de la versión principal el 11 de octubre de 2026. Las piezas que no existen figuran como hoja de ruta.