Tus conversaciones de WhatsApp ya tienen el diagnóstico: análisis con IA y MCP en una funeraria a escala

Pregúntale al director de operaciones de un grupo funerario cuáles son los cinco motivos por los que más lo contactan las familias. Va a responder con seguridad, y va a estar parcialmente equivocado. No por falta de oficio: porque su respuesta viene de lo que escucha en comité, de los casos que escalaron y de las quejas que llegaron por escrito. Es decir, de una muestra sesgada hacia lo que hizo ruido. Mientras tanto, en el canal de WhatsApp hay decenas de miles de mensajes al mes donde las familias explicaron, con sus propias palabras, exactamente qué necesitaban, cuánto esperaron y en qué momento se dieron por vencidas.

Ese archivo es el activo peor aprovechado de una funeraria grande. Este artículo desarrolla el caso de uso que lo pone a trabajar: analizar todas las conversaciones —las que atendió el bot y las que atendió una persona— con inteligencia artificial conectada por MCP a los datos reales del ERP, para responder con evidencia tres preguntas que hoy se responden con intuición: qué tan bien atendemos, qué nos están pidiendo de verdad y cuánto negocio se nos escapa en la conversación. Verás los datos que intervienen, cómo se arma el análisis, el bucle que lo sostiene, los límites honestos del método, el gobierno que exige un contexto de duelo y los indicadores para saber si sirvió.

El problema de negocio y cuánto cuesta hoy

En una funeraria a escala, WhatsApp dejó de ser un canal de apoyo: es la puerta principal. Por ahí entra el aviso de fallecimiento de madrugada, la duda sobre la cobertura de un plan, la solicitud de un certificado, el reclamo por un cobro, la coordinación con la familia durante el velorio y la consulta del asesor en campo. Y sin embargo, en la mayoría de los grupos, todo ese tráfico se supervisa igual que en 1995: alguien mira por encima la bandeja, alguien más lee los reclamos formales y el resto se archiva. Estos son los costos concretos de esa ceguera:

• Demanda mal entendida: la dirección dimensiona turnos, guiones y capacitación sobre los motivos que cree que dominan el canal. Si los tres primeros motivos reales son otros, todo lo que se construyó encima está mal calibrado.
• Quiebres de guion invisibles: la respuesta que un asesor da bien en la sede principal se da mal en la sucursal nueva, y nadie lo detecta hasta que aparece un reclamo. El error no está en las personas: está en que nadie mira.
• Tiempos que se degradan por franja, no por promedio: el promedio mensual de primera respuesta puede verse impecable mientras el turno de la madrugada —el más crítico en este sector— responde sistemáticamente tarde.
• Molestia que nunca se convierte en queja: la mayoría de las familias molestas no reclaman formalmente. Escriben “ya llamé tres veces”, “nadie me responde” o “déjenlo así” y se van. Ese texto existe, está fechado y hoy nadie lo cuenta.
• Oportunidad comercial perdida: quien preguntó por un plan de previsión a las 9 de la noche, no obtuvo respuesta útil y jamás quedó registrado como prospecto en el CRM. Es la fuga más silenciosa del canal.
• Cartera que se cae en la conversación: gestiones de cobro que mueren sin acuerdo porque no se dio el saldo exacto ni un medio de pago, y nadie las retomó.
• Capacitación a ciegas: se entrena a todo el equipo en lo que el formador supone, en vez de en los tres quiebres que de verdad se repiten. Es el gasto de formación peor dirigido de la operación.

Todos esos costos comparten una causa: el muestreo. Revisar una fracción mínima de las interacciones fue durante décadas la única opción posible, y arrastra dos defectos que ninguna disciplina corrige. El primero es estadístico: los problemas graves de este sector son pocos y dispersos, justo lo que una muestra pequeña no ve. El segundo es humano: la muestra la elige alguien, y nadie elige para quedar mal.

La homologación al sector es directa. Lo que en una fintech es “el reclamo por un cargo no reconocido que se cerró sin resolver”, en una funeraria es “el aviso de fallecimiento que se respondió con un catálogo de planes”. Y lo que allá es un cliente que se va a otro banco, aquí es una familia que va a contar esa experiencia durante años, en el momento más recordado de su vida. En este sector la calidad de la conversación no es una métrica de servicio: es el producto.

Qué datos del ERP intervienen

La razón por la que este caso es viable en semanas y no en trimestres es que no hay que instrumentar nada nuevo. Si la atención vive en el mismo ERP que opera la funeraria, el rastro ya está escrito y —esto es lo decisivo— ya está ligado al negocio: no analizas “chats”, analizas conversaciones con un contrato, un saldo y un servicio detrás.

Las tres lecturas que valen

Un análisis de conversaciones fracasa casi siempre por lo mismo: se plantea como “vamos a ver qué encontramos”. Sin una pregunta, la IA devuelve un resumen bonito e inaccionable. Estas son las tres lecturas que sí producen decisiones, en el orden en que conviene abordarlas.

1. Calidad: dónde se rompe el guion

Es la lectura que más rápido paga. Consiste en definir de tres a cinco criterios binarios —se responde sí o no, sin escalas de 1 a 10— y pedirle a la IA que evalúe cada conversación contra ellos. Para una funeraria, el conjunto mínimo es este:

• ¿La respuesta fue correcta según nuestras condiciones reales? Es decir, coherente con lo que dice el contrato, la cobertura y la tarifa vigente del plan de esa familia, no con una versión aproximada.
• ¿Se reconoció el contexto? Cuando la familia informó un fallecimiento, ¿la respuesta lo trató como tal desde el primer mensaje?
• ¿Se resolvió o solo se contestó? Una conversación puede tener respuestas rápidas y correctas y terminar sin que la persona logre lo que necesitaba.
• ¿El tono fue el adecuado? Sin plantillas comerciales ni emojis en un aviso de fallecimiento; con claridad y sin tecnicismos en un cobro.
• ¿Quedó registro en el sistema? El acuerdo, la solicitud o el interés detectado, ¿quedaron escritos donde la operación los va a ver mañana?

Los criterios binarios no son una simplificación ingenua: son la forma de que dos evaluaciones distintas den el mismo resultado. Una escala de 1 a 10 es irrepetible —ni dos supervisores humanos coinciden—, mientras que “¿contradijo la cobertura del contrato? sí/no” se puede auditar, discutir y corregir. Es el mismo criterio con el que la banca digital evalúa a sus agentes, y es el que hace comparables los resultados de un mes contra otro.

2. Demanda: por qué te contactan de verdad

La segunda lectura responde la pregunta que casi nadie tiene contestada con datos: ¿cuáles son los motivos reales de contacto y cómo se mueven en el tiempo? El camino corto —y equivocado— es pedirle al equipo que tipifique cada conversación a mano: se hace mal, se hace tarde y se abandona en tres meses. El camino correcto es el que ya recorrieron otros sectores intensivos en atención: que la clasificación del motivo la produzca el sistema y que la persona solo la valide.

Uber describió públicamente cómo su asistente de soporte clasifica el tipo de problema del ticket y sugiere las soluciones más probables a partir del contenido y del contexto del viaje, y reportó una reducción de más del 10 % en el tiempo de resolución manteniendo o mejorando la satisfacción. En el mundo de los contact centers, un trabajo de ingeniería de Cisco propone generar automáticamente los call drivers —el motivo del contacto— como capa base sobre la que después se construyen el modelado de temas, la categorización de lo que entra, la detección de tendencias y las preguntas frecuentes. Y una publicación reciente de investigación aplicada muestra cómo agrupar conversaciones multivuelta en temas que se refinan de forma incremental, en lugar de rehacer la taxonomía entera cada vez que aparece un asunto nuevo: exactamente el problema de una funeraria que abre una sede, lanza un plan o enfrenta un cambio normativo.

Traducido a la operación: en lugar de imponer desde el escritorio una lista de veinte motivos, se le pide a la IA que lea un mes de conversaciones y proponga los motivos que emergen, con ejemplos reales de cada uno. La dirección revisa, fusiona lo que sobra, renombra con el vocabulario de la casa y fija una taxonomía de ocho a doce motivos. A partir de ahí, la clasificación es barata y comparable mes a mes. Es la diferencia entre discutir si “últimamente preguntan más por cremación” y saber que ese motivo pasó del 6 % al 14 % del canal en dos trimestres.

3. Señales: molestia silenciosa y oportunidad perdida

La tercera lectura es la que más sorprende a la dirección, porque saca a la luz lo que el sistema de quejas nunca ve. Se le pide a la IA que marque conversaciones con señales explícitas —no que “interprete emociones”, que es otra cosa y tiene sus propios problemas—:

• Insistencia: la persona dice que ya escribió o llamó antes por el mismo asunto. Es la señal más limpia y la más subestimada del canal.
• Abandono: la familia dejó de responder después de una respuesta nuestra. Cuándo y tras qué mensaje concreto.
• Anuncio de salida: menciones a cancelar, retirar el plan, pedir devolución o comparar con otra funeraria.
• Escalamiento social: menciones a redes sociales, entes de control, superintendencias o abogados.
• Interés comercial sin desenlace: preguntas por precio, cobertura o afiliación que no derivaron en un prospecto registrado ni en un contacto de seguimiento.
• Petición de una persona: solicitudes explícitas de hablar con alguien que no fueron atendidas a tiempo.

Cada una de estas señales es un hecho textual verificable, no una inferencia sobre el estado de ánimo de nadie. Esa distinción importa por dos razones. La primera es técnica: los hechos se pueden auditar y las inferencias no. La segunda es de gobierno: inferir emociones de personas es justamente el terreno donde la regulación de inteligencia artificial se está poniendo estricta, y no hay razón de negocio para pisarlo cuando lo que necesitas —“esta familia escribió que es la tercera vez que pregunta”— está escrito con todas las letras.

Cruzar estas señales con el ERP es lo que las convierte en dinero: de las conversaciones marcadas con interés comercial sin desenlace, ¿cuántas terminaron en contrato en los siguientes 30 días? De las marcadas con anuncio de salida, ¿cuántas terminaron efectivamente en retiro? Ese segundo número suele ser el argumento más contundente que puede llevar un director de operaciones a un comité: la lista concreta de contratos que se perdieron después de una conversación que estaba escrita y que nadie leyó.

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

El MCP (Model Context Protocol) es el estándar que conecta la inteligencia artificial que prefiera tu equipo con el ERP para consultar y analizar en lenguaje natural, con los permisos del usuario que autorizó la conexión. En este caso de uso cumple un papel muy concreto: es el analista que lee lo que nadie tiene tiempo de leer, y que además puede cruzarlo con el contrato y la cartera sin exportar un solo archivo.

1. Define el alcance y la pregunta antes de tocar nada. Un canal, un periodo y una de las tres lecturas. “Todas las conversaciones de WhatsApp de junio, lectura de calidad.” Analizar todo a la vez es la forma más común de no concluir nada.
2. Conecta el MCP con un usuario de análisis. Autoriza la conexión con un usuario cuyo rol permita leer las conversaciones y los datos de contrato necesarios, y nada más. La IA hereda exactamente esos permisos: no puede ver lo que ese usuario no puede ver.
3. Empieza por el mapa, no por el detalle. Pide primero los agregados —volumen por día y franja, distribución por equipo y sede, incumplimientos de SLA, duración— para saber dónde mirar. Es rápido, barato y evita conclusiones sacadas de tres casos memorables.
4. Deriva la taxonomía de motivos de los datos. Pídele a la IA que lea una muestra grande de conversaciones y proponga los motivos recurrentes con ejemplos. Revisa, fusiona y bautiza con el vocabulario de la casa. Ocho a doce motivos, ni uno más.
5. Escribe la rúbrica de calidad en criterios binarios y verifica que dos personas del equipo, leyendo las mismas diez conversaciones, coincidan al aplicarla. Si no coinciden, el problema es la rúbrica, no el modelo.
6. Calibra el evaluador contra una muestra etiquetada a mano. Toma entre 50 y 100 conversaciones, califícalas manualmente y compara con lo que dice la IA. Donde no coincidan, corrige la instrucción. Este paso es el que separa un análisis serio de un espejismo, y es el que casi todo el mundo se salta.
7. Corre el análisis completo y pide siempre la evidencia. Que cada hallazgo venga con la conversación concreta que lo respalda. Un porcentaje sin ejemplo no se puede defender en un comité ni corregir en la operación.
8. Cruza con el resultado de negocio. Une lo que pasó en la conversación con lo que pasó después: pago registrado, servicio prestado, contrato retirado, prospecto creado. Ahí el análisis deja de ser de servicio al cliente y pasa a ser de negocio.
9. Deja los hallazgos como reportes guardados. Cuando una consulta demuestra su valor, pídele a la IA que la deje como reporte reutilizable en el sistema, para que el próximo mes se ejecute igual y el resultado no dependa de cómo se redactó la pregunta.
10. Asigna dueño a cada hallazgo. Un análisis sin responsable ni fecha es entretenimiento. Cada quiebre detectado se convierte en un cambio de guion, una capacitación, un ajuste de turno o una automatización, con nombre propio.

Conviene tener claro el alcance técnico para no diseñar un proceso sobre supuestos. En SFUN el MCP lee y analiza con los permisos del usuario, ejecuta agregaciones y reportes guardados y puede crear reportes nuevos; pero no opera la mesa de agentes: responderle a una familia, asignar, etiquetar o escalar una conversación desde la IA está deliberadamente deshabilitado por seguridad. Y hay un límite de diseño que conviene entender bien porque ordena todo el método: las respuestas vienen acotadas —los agregados devuelven un número reducido de grupos, los reportes se truncan a unos cientos de filas y los listados llegan paginados— precisamente para impedir la extracción masiva de datos personales. No es un obstáculo: es lo que te obliga a trabajar como corresponde, con agregados, top-N y lectura dirigida de casos concretos, en vez de volcar miles de conversaciones a un archivo que después vive sin control en el computador de alguien.

Hay además una capacidad reciente que cambia el final de este proceso. SFUN incorporó un motor de reportes propio con herramientas expuestas al MCP para crear, versionar, revertir, publicar y compartir un reporte. En la práctica significa que el resultado del análisis no tiene que morir en un chat con la IA: el propio agente puede dejar construido el tablero —con su versión, sus permisos por equipo y su enlace para compartir— y la dirección lo abre el mes siguiente sin volver a preguntar nada. El motor consulta respetando los permisos de cada usuario y filtra campo por campo, de modo que un tablero de analítica conversacional se puede montar sin exponer datos que quien lo mira no debería ver.

El bucle: qué se revisa cada semana y cada mes

A diferencia de la mejora del bot, que es un ciclo diario, el análisis de conversaciones rinde mejor con un ritmo semanal y mensual: los patrones necesitan volumen para ser confiables. Lo que no cambia es la regla de oro: sin un responsable con nombre propio, el bucle no existe.

Gobierno y límites: lo que nunca se automatiza

Este caso de uso toca dos materiales delicados a la vez: datos de familias en duelo y desempeño de trabajadores. Ninguna eficiencia justifica manejarlos sin reglas escritas:

• Se analizan procesos, no personas. El resultado del análisis apunta a guiones, turnos, capacidades del sistema y capacitación. Si se usa para evaluar a una persona, tiene que ser con hechos verificables, con su conocimiento y con derecho a réplica, nunca con una inferencia de tono o de emoción.
• Nunca se infieren emociones para calificar a un empleado. Marcar que la familia escribió que ya había preguntado tres veces es un hecho. Concluir que un asesor “estuvo desmotivado” a partir de su forma de escribir es exactamente lo que la regulación de IA en el trabajo está restringiendo, y además no resiste una discusión seria.
• Alcance por rol, no por confianza. El usuario con el que se conecta el MCP tiene permisos de lectura acotados a lo que el análisis necesita. La IA no puede hacer nada que ese usuario no pueda hacer, y cada operación queda registrada.
• Datos sensibles del doliente. Se tratan con el criterio de un historial clínico: se leen para corregir el proceso, no para perfilar a nadie, y cualquier evidencia que salga del sistema —una captura en un acta, un ejemplo en una capacitación— va con los datos identificables cubiertos.
• La transcripción no es prueba. Un audio mal transcrito puede cambiar el sentido de una frase. Sirve para detectar temas; no sirve para sostener una sanción ni una decisión sobre una persona.
• Nunca se automatiza: responderle a una familia sin supervisión en un caso sensible, cerrar un reclamo, negar una cobertura, modificar un contrato, sancionar a un colaborador o comunicarse con autoridades a partir de una conclusión del análisis.
• Retención y base legal. Define por escrito cuánto tiempo se conservan las conversaciones, con qué fundamento y quién puede consultarlas. Es la pregunta que primero hace una autoridad de datos.

El calendario regulatorio de la región refuerza la urgencia y conviene tenerlo a la vista: en Chile, la Ley 21.719 de protección de datos entra en vigencia el 1 de diciembre de 2026 y crea una agencia con facultades sancionatorias; en Ecuador, la Superintendencia de Protección de Datos ya emitió resoluciones sancionatorias bajo la LOPDP; en Perú, el plazo para designar Oficial de Datos Personales venció el 30 de junio de 2026; Paraguay aprobó su Ley 7593/2025 con un régimen sancionador severo y ventana de adecuación; y El Salvador suma a su Ley de Protección de Datos Personales un marco de evaluación de riesgos de sistemas de inteligencia artificial que alcanza a un asistente de atención o a un análisis automatizado sobre datos personales. Un grupo funerario multipaís no necesita un régimen distinto por país: necesita el estándar más exigente aplicado en todas sus sedes.

KPIs: línea base y meta

Las metas de abajo son referencias de arranque para una operación funeraria a escala, no promesas. Lo que importa es que cada grupo fije su línea base el primer mes y mida el movimiento contra ella. Un indicador sin línea base propia solo sirve para discutir.

Hoja de ruta de adopción

Semana 1: acotar y calibrar

• Elegir un solo canal, un solo periodo y una sola lectura. Empezar por calidad: es la que produce cambios visibles más rápido.
• Conectar el MCP con un usuario de análisis de solo lectura y confirmar qué puede y qué no puede ver.
• Escribir la rúbrica de cinco criterios binarios y probarla con dos personas del equipo sobre las mismas diez conversaciones.
• Etiquetar a mano entre 50 y 100 conversaciones y comparar con la IA. Corregir la instrucción donde no coincidan.
• Nombrar al responsable del análisis. Sin nombre propio, no hay bucle.

Mes 1: línea base y mapa de motivos

• Correr el análisis completo del mes y fijar la línea base de todos los KPIs de la tabla anterior.
• Derivar la taxonomía de motivos de los datos, validarla con operaciones y dejarla congelada por un trimestre para poder comparar.
• Dejar guardados los reportes de diagnóstico para que el análisis se repita igual cada mes.
• Presentar el primer hallazgo con evidencia: un quiebre de guion, con conversaciones reales y su costo estimado.
• Revisar con Cumplimiento la base legal, la retención y quién puede consultar las conversaciones, según la normativa del país de cada sede.

Trimestre 1: del diagnóstico a la operación

• Eliminar de raíz los dos motivos evitables más grandes con autoservicio o con un cambio de proceso, y verificar que su participación baja.
• Conectar el análisis con el cuadro de mando de la compañía: el canal deja de ser un tema de tecnología y pasa a ser un indicador de servicio.
• Montar el flujo de retención sobre las señales de salida detectadas, con responsable y tiempo de respuesta comprometido.
• Evaluar si extiendes el análisis al canal telefónico y a los agentes de voz: hoy queda el registro de la llamada —quién, cuándo, cuánto duró, si la atendió el bot o una persona—, pero la grabación y la transcripción son un proyecto aparte, con la advertencia sobre sesgo ya explicada.
• Llevar al comité el cruce con negocio —conversión del interés detectado y retiros precedidos por señal— en vez de estadísticas de mensajes.

Errores comunes que hacen fracasar el caso

• Analizar sin pregunta. “A ver qué sale” produce un informe largo que nadie usa. Una lectura, un periodo, una decisión.
• No calibrar el evaluador. Si nunca comparaste la calificación de la IA contra una muestra hecha a mano, no sabes qué tan mal está midiendo, y lo vas a descubrir en la peor reunión posible.
• Usar escalas en vez de criterios binarios. Un 7,4 promedio no es accionable ni comparable. “Cumple / no cumple” sí.
• Cambiar la taxonomía cada mes. Si los motivos se redefinen constantemente, no hay tendencia que valga. Se congela un trimestre.
• Usar el análisis para castigar. El día que el equipo perciba que las conversaciones se leen para sancionar, empezará a escribir para el auditor y no para la familia. Ese día el canal deja de ser una fuente de verdad.
• Quedarse en el canal. Un análisis que nunca cruza con contratos, pagos y servicios se queda en estadística de mensajes: interesante, irrelevante.
• Confundir el hallazgo con la solución. Detectar que el 12 % pregunta el saldo no mejora nada; construir el autoservicio de saldo sí.

Preguntas frecuentes

¿Cómo se analizan las conversaciones de WhatsApp de una funeraria con inteligencia artificial?

Se conecta la IA al ERP mediante MCP con un usuario de solo lectura y se le pide que evalúe las conversaciones contra criterios explícitos. El orden que funciona es: primero los agregados (volumen, franjas, sedes, incumplimientos de SLA) para saber dónde mirar; después una rúbrica de tres a cinco criterios binarios de calidad; luego una taxonomía de motivos derivada de los propios datos y validada por operaciones; y por último el cruce con el negocio —pagos, servicios, prospectos, retiros—. Antes de reportar cualquier cifra, el evaluador se calibra contra una muestra de 50 a 100 conversaciones etiquetadas a mano. Sin ese paso, los porcentajes no son defendibles.

¿Es necesario tener un chatbot para hacer este análisis?

No. Este caso se aplica igual sobre conversaciones atendidas exclusivamente por personas: lo único que se necesita es que la atención ocurra dentro del sistema, con sus mensajes, tiempos y vínculo con el contrato. De hecho, muchos grupos obtienen aquí su mayor retorno inicial, porque descubren quiebres de guion humanos que llevaban años repitiéndose sin que nadie los viera. Si además hay un bot, el análisis cubre ambos y permite comparar cómo se resuelve el mismo motivo en cada caso.

¿Qué se puede saber de una conversación que una encuesta de satisfacción no dice?

Casi todo lo que importa. La encuesta la responde una minoría autoseleccionada y llega tarde, cuando el caso ya se cerró. La conversación, en cambio, contiene el hecho: cuánto esperó la familia, cuántas veces preguntó lo mismo, si la respuesta coincidía con su contrato, si pidió hablar con una persona y no la atendieron, y en qué mensaje exacto dejó de responder. Además cubre el 100 % de los casos, incluidos los que jamás habrían contestado una encuesta. La encuesta mide percepción declarada de unos pocos; el análisis de conversaciones mide comportamiento observado de todos.

¿Puede la IA analizar conversaciones con datos personales de familias en duelo?

Puede, si se hace con base legal documentada, alcance acotado y trazabilidad. La conexión por MCP se autoriza con un usuario concreto y hereda sus roles: la IA no accede a nada que esa persona no pueda ver, y cada consulta queda registrada. A eso hay que sumarle el gobierno propio del grupo: analizar procesos y no perfilar personas, cubrir datos identificables en cualquier evidencia que salga del sistema, definir por escrito el periodo de retención y revisar el conjunto con Cumplimiento. Ten presente el calendario regional: Chile aplica su nueva ley desde diciembre de 2026, Ecuador ya está sancionando, Perú exige Oficial de Datos Personales, Paraguay tiene su ley aprobada en adecuación y El Salvador suma un marco de evaluación de riesgos para sistemas de IA.

¿Cuánto tarda en dar resultados y quién debe hacerse cargo?

El primer hallazgo accionable aparece en la primera semana, casi siempre en la lectura de calidad, y suele ser un quiebre de guion que nadie sospechaba. La línea base completa toma un mes, y las decisiones de proceso —eliminar motivos evitables, montar el flujo de retención, ajustar turnos por franja— rinden entre el segundo y el tercer mes. El dueño natural es el líder del canal de atención, con la dirección de operaciones como destinataria del reporte mensual y el área comercial involucrada en la lectura de oportunidad. No hace falta un equipo de datos: hace falta un responsable con nombre propio y la disciplina de no saltarse la revisión.

Fuentes

• Nubank — “Building AI Agents for 131 Million Customers” (auditoría del 100 % de las conversaciones con un modelo evaluador y criterios binarios): building.nubank.com.
• S. Zhang, A. Wang y S. Lei — “Catching One in Five: LLM-as-Judge Blind Spots in Production Multi-Turn Transaction Agents” (junio de 2026): arxiv.org.
• Uber Engineering — “COTA: Improving Uber Customer Care with NLP & Machine Learning” (clasificación del motivo del ticket y reducción de más del 10 % en el tiempo de resolución): uber.com.
• V. Embar, R. Shrivastava, V. Damodaran, T. Mehlinger, Y.-C. Hsiao y K. Raghunathan — “LLM-Based Insight Extraction for Contact Center Analytics and Cost-Efficient Deployment” (generación automática de call drivers como capa base de la analítica de atención), arXiv 2503.19090: arxiv.org.
• P. Pattnayak, S. Chowdhuri, A. Agarwal y H. L. Patel — “LLM-Guided Lifecycle-Aware Clustering of Multi-Turn Customer Support Conversations” (AACL 2025), arXiv 2601.04388: arxiv.org.
• A. Koenecke et al. — “Racial disparities in automated speech recognition”, PNAS (tasas de error de palabra de 0,35 frente a 0,19 según el grupo del hablante en cinco sistemas comerciales): pnas.org.
• Financial Conduct Authority — FG21/1, “Guidance for firms on the fair treatment of vulnerable customers”: fca.org.uk.
• Chile — Ley 21.719 sobre protección y tratamiento de datos personales: bcn.cl. Ecuador — resoluciones de la Superintendencia de Protección de Datos Personales: spdp.gob.ec. Perú — Directiva del Oficial de Datos Personales (RD N.° 100-2025-JUS/DGTAIPD): gob.pe. Paraguay — Ley N.º 7593/2025 de Protección de Datos Personales: bacn.gov.py.