IA para reclamos en Chile: clasificar y derivar con criterio

Del mensaje recibido al equipo que puede resolverlo

Para una empresa chilena, usar IA en reclamos puede comenzar con una tarea concreta: identificar el problema y sugerir quién debería atenderlo. Antes de permitir que el sistema responda o cierre casos, conviene comprobar si distingue una consulta de seguimiento, una entrega incumplida y una solicitud que reúne varios problemas.

En su cuenta pública difundida el 27 de julio de 2026, SERNAC informó que recibió alrededor de 655 mil reclamos durante 2025. Retail, mercado financiero, telecomunicaciones, servicios básicos y transporte concentraron el 74%. Son antecedentes de gestión del año anterior, no un conteo de este mes ni de todos los contactos recibidos directamente por las empresas. SERNAC, cuenta pública de la gestión 2025.

Esas cifras dan contexto al problema de atención. No permiten deducir cuántos casos podría resolver automáticamente una empresa ni cuánto ahorraría. Esta guía propone cómo evaluar la clasificación y la derivación con datos propios.

Una experiencia chilena que ayuda a delimitar el alcance

El informe de evaluación del Cyber Day 2025 del SERNAC describe un análisis temático de una muestra de reclamos, estratificada por empresa. Para extraer y agrupar temas recurrentes utilizó procesamiento de lenguaje natural, complementado con validación manual del equipo analítico. Es un antecedente metodológico de 2025. SERNAC, metodología del informe Cyber Day 2025, página 3.

El documento describe análisis para un estudio; no demuestra que un sistema haya atendido o resuelto automáticamente los reclamos. Para una empresa, nuestra recomendación es separar ambas decisiones: primero comprobar si la IA organiza bien los mensajes y después evaluar qué acciones puede apoyar. Cada paso necesita su propia evidencia.

Definir categorías que conduzcan a una acción

Proponemos comenzar con categorías comprensibles para quienes atienden: seguimiento de entrega, cobro por revisar, producto recibido con problemas y solicitud incompleta, por ejemplo. Cada categoría necesita un responsable y una regla para los casos que no encajan. Una etiqueta útil debería facilitar el siguiente paso del trabajo.

Conviene mantener separados el motivo, la prioridad y el estado. Un mensaje puede tratar sobre un despacho y seguir pendiente de antecedentes; otro puede mencionar despacho y cobro a la vez. Forzar ambos a una única etiqueta puede ocultar trabajo. El tono del cliente, por sí solo, tampoco debería decidir la urgencia: proponemos usar criterios operacionales explícitos.

En un ejemplo hipotético, una tienda chilena recibe un mensaje que informa una entrega pendiente y un cobro repetido. La propuesta de clasificación conserva los dos motivos, sugiere un responsable principal y deja una tarea asociada para revisar el cobro. La persona encargada confirma el recorrido antes de contactar al cliente. El ejemplo no representa un resultado medido.

Medir qué casos se escapan, además de los aciertos

Microsoft documenta la evaluación de clasificación de intenciones mediante precisión, recall y una matriz de confusión. La precisión muestra qué proporción de los casos asignados a una categoría fue correcta; el recall mide qué parte de los casos de una categoría se detectó. La matriz permite observar qué categorías se confunden entre sí. Microsoft, métricas de evaluación de CLU.

Aplicado al ejemplo, interesa contar los cobros repetidos que terminaron clasificados únicamente como consultas de despacho. También los mensajes enviados a revisión de cobros sin corresponder. Son errores diferentes y consumen recursos distintos. Proponemos comparar la IA con la clasificación actual sobre los mismos mensajes, con etiquetas revisadas por el equipo.

La documentación distingue datos de entrenamiento y datos de prueba que el modelo no vio durante el entrenamiento. Para nuestro piloto sugerimos reservar casos que tampoco se usen para ajustar instrucciones, incluir categorías poco frecuentes y evitar que fragmentos del mismo reclamo aparezcan a ambos lados de la evaluación. Así la prueba se acerca mejor al trabajo nuevo que deberá enfrentar.

Diseñar la revisión humana como parte del servicio

Microsoft advierte que los errores de clasificación tienen consecuencias en las acciones de la aplicación y que los umbrales deben probarse con datos reales. En CLU, cambiar el umbral modifica el equilibrio entre falsos positivos y falsos negativos; la configuración adecuada depende del escenario. Es documentación técnica, no una garantía de desempeño para cualquier modelo. Microsoft, limitaciones y evaluación en contexto.

Nuestra propuesta es enviar a revisión los mensajes ambiguos, incompletos o fuera de las categorías previstas. Esa revisión necesita un equipo asignado, seguimiento de antigüedad y acceso al mensaje original. Una cola sin responsable puede acumular justamente los casos más difíciles. Las categorías críticas definidas por la empresa también requieren controles propios, aunque el sistema entregue una puntuación alta.

Antes del piloto, recomendamos limitar los datos enviados al modelo a lo necesario, revisar accesos y retirar identificadores que no aporten a clasificar. Los ejemplos de prueba deben conservar el significado del problema sin circular información personal innecesaria.

Empezar con sugerencias y comprobar el recorrido completo

El primer piloto puede operar en paralelo: la IA propone etiquetas y destinos, mientras el equipo mantiene la decisión. Conviene registrar correcciones, cambios de responsable, casos que vuelven a la cola y tiempo hasta que alguien toma la gestión. Clasificar un mensaje no demuestra que el reclamo haya quedado resuelto.

El entregable debería incluir criterios de clasificación, errores por categoría y condiciones para ampliar o detener la automatización. Si la solución incorpora conversación, la guía sobre pruebas de agentes de atención permite revisar esa etapa adicional. Una implementación de IA aplicada para empresas debe conectar cada sugerencia con un proceso que el equipo pueda seguir y corregir.