Volver al blog
    Automatización con IAAtención al cliente

    Triaje de atención al cliente con IA: asignación, borradores y cuándo escalar a una persona

    La IA puede clasificar un buzón de soporte en segundos, pero no toda respuesta debe salir sin revisión. Así se separan asignación, borradores y escalado.

    Por Nichita Railean, CTOPublicado 5 min de lectura

    Un buzón de soporte compartido lo mezcla todo: preguntas sobre pedidos, quejas, facturas enviadas a la dirección equivocada, restablecimientos de contraseña, bajas y, de vez en cuando, una amenaza legal. Alguien tiene que leer cada mensaje, averiguar de qué se trata y derivarlo antes de que nadie pueda responderlo. Ese paso de clasificación suele ser donde la IA ayuda primero, y unas pocas reglas claras deciden si ayuda o perjudica.

    Este artículo trata por separado la asignación, los borradores y el escalado, porque cada uno conlleva un nivel de riesgo distinto.

    Asignación: el modelo lee, las reglas deciden

    La asignación es el punto de partida más seguro, porque una etiqueta errónea cuesta un traspaso entre colas, no una promesa equivocada a un cliente. Un modelo de lenguaje lee el mensaje y devuelve unos pocos campos estructurados: el tema, el idioma, el producto, lo urgente que parece y si el cliente pide hablar con una persona. Los datos que el modelo no puede ver en el texto, como el contrato del cliente o los pedidos abiertos, salen de su CRM o de su sistema de pedidos, no de una suposición.

    Mantenga la lista de temas corta y ligada a quién los gestiona. Si dos categorías van siempre al mismo equipo, son una sola categoría. Construya la primera versión a partir de unos meses de tickets reales y pida a las personas que hoy los responden que etiqueten a mano una muestra. Esa muestra se convierte en su conjunto de pruebas: la asignación funciona cuando el modelo coincide con su equipo en ella, no cuando parece convincente en una demostración. Los mensajes sobre los que el modelo duda van a una persona, como hoy.

    Borradores: respuestas basadas en sus propias fuentes

    Redactar respuestas es donde se va la mayor parte del tiempo y donde está la mayor parte del riesgo. Un modelo puede escribir una respuesta fluida a casi cualquier cosa, y ese es justamente el problema: una respuesta segura sobre una política de reembolsos que usted no tiene es peor que ninguna respuesta. Construya los borradores solo a partir de material aprobado, como su centro de ayuda, las políticas vigentes y los datos de pedido del cliente, y muestre al agente qué fuente ha usado cada borrador para que pueda comprobarlo en segundos. Fine-tuning frente a RAG explica cómo funciona este anclaje en fuentes.

    Los borradores que aprueba una persona son también donde la evidencia es más sólida. Un estudio con 5179 agentes de atención al cliente concluyó que el acceso a un asistente de IA generativa aumentó el número de incidencias resueltas por hora un 14% de media, con una mejora del 34% para los agentes noveles y menos cualificados y un impacto mínimo en los más experimentados y cualificados. Los autores sugieren que el asistente trasladó las prácticas de los mejores agentes a los compañeros más nuevos.

    Dejar que las respuestas salgan sin revisión es otra decisión. En 2024, un tribunal de la Columbia Británica, en Canadá, falló en contra de Air Canada después de que el chatbot de su web sugiriera que una tarifa por duelo podía solicitarse con carácter retroactivo, algo que la aerolínea no permitía. La aerolínea alegó que no podía responder por lo que dijera el chatbot. El tribunal calificó ese argumento de notable y resolvió que la empresa es responsable de toda la información de su web, tanto si procede de una página estática como de un chatbot. Lo que su sistema le dice a un cliente lo ha dicho su empresa.

    Cuándo escalar a una persona

    Ponga por escrito las reglas de escalado antes del lanzamiento y aplíquelas en el código, no en el criterio del modelo. Estas son las señales de las que partimos en nuestros proyectos.

    SeñalPor qué toma el relevo una persona
    El cliente pide hablar con una personaAtiéndalo de inmediato. Obligar a la gente a discutir con un bot para llegar a alguien cuesta más confianza que una respuesta más lenta.
    Reembolsos, abonos, bajas o cambios de contratoComprometen dinero o modifican un acuerdo, así que decide una persona concreta.
    Una queja, mucha frustración o una mención de abogados o reguladoresLa relación está en juego, y la redacción de la respuesta importa más que su rapidez.
    Una solicitud de acceso, rectificación o supresión de datos personalesSegún el RGPD, la respuesta debe darse sin dilación indebida y en el plazo de un mes, prorrogable solo cuando la complejidad o el número de solicitudes lo hagan necesario.
    Salud, seguridad o un cliente en situación vulnerableUna respuesta errónea cuesta demasiado como para aceptar cualquier tasa de error.
    Ninguna fuente aprobada cubre la pregunta, o el modelo dudaUn borrador sin fuente es una suposición. Pase el ticket a una persona con lo que el sistema sí haya encontrado.
    El cliente vuelve a escribir sobre el mismo problemaUn contacto repetido suele significar que la primera respuesta no resolvió el problema.
    El mensaje contiene instrucciones dirigidas al sistemaOWASP sitúa la inyección de prompts, incluidas las instrucciones ocultas en contenido externo, en primer lugar entre los riesgos de las aplicaciones con modelos de lenguaje.

    El dinero es la línea más clara. Según el RGPD, las personas tienen derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado que produzca efectos jurídicos en ellas o les afecte significativamente de modo similar. No todas las decisiones sobre reembolsos alcanzan ese umbral, pero rara vez compensa discutir cuáles sí. Cuando la norma se aplica, las excepciones llevan garantías, entre ellas el derecho a obtener intervención humana y a impugnar la decisión. Un modelo puede preparar un reembolso o un rechazo. La decisión la toma una persona.

    Informe a los clientes y haga un traspaso limpio

    Desde el 2 de agosto de 2026, el Reglamento de IA de la UE exige que los sistemas de IA que interactúan directamente con personas estén diseñados para que esas personas sepan que están interactuando con un sistema de IA, salvo que resulte evidente por el contexto. En atención al cliente, la forma más sencilla de cumplirlo es una frase clara al inicio de un chat o en una respuesta automática.

    El traspaso es el momento que más notan los clientes. Cuando un ticket pasa a una persona, debe llevar un breve resumen: qué preguntó el cliente, qué encontró el sistema, qué le ha dicho ya y por qué lo escaló. Nadie debería tener que explicar el problema dos veces.

    Cómo empezar

    1. Mida la situación actual. Cuente los tickets por semana, por canal y por tema, el tiempo hasta la primera respuesta y con qué frecuencia un ticket pasa de un equipo a otro.
    2. Ponga la asignación en modo sombra. El modelo etiqueta cada ticket mientras las personas asignan como siempre. Compare ambos durante unas semanas antes de que el modelo asigne por su cuenta.
    3. Añada borradores para los temas más frecuentes. Un agente aprueba o edita cada borrador. Registre con qué frecuencia los borradores se envían sin cambios, se editan o se descartan.
    4. Permita respuestas automáticas solo para temas acotados y de bajo riesgo, como el estado de un pedido o el horario de apertura, y solo cuando las revisiones muestren una tasa de error baja.
    5. Revise cada semana una muestra aleatoria, incluidos los tickets que nunca se escalaron. Ahí encontrará los errores de los que el sistema estaba seguro.

    Para estimar cuánto podría ahorrar su equipo de soporte, describa el flujo de trabajo en la calculadora de ROI. Si está valorando un agente que también ejecute acciones, como emitir reembolsos, lea primero agentes de IA explicados o consulte flujos de trabajo habituales por área de negocio.

    Fuentes

    1. Brynjolfsson, Li and Raymond: Generative AI at Work (NBER Working Paper 31161)
    2. Civil Resolution Tribunal of British Columbia: Moffatt v. Air Canada, 2024 BCCRT 149
    3. Regulation (EU) 2016/679, the GDPR, Articles 12 and 22 (EUR-Lex)
    4. Regulation (EU) 2024/1689, the AI Act, Articles 50 and 113 (EUR-Lex)
    5. Regulation (EU) 2026/1744 amending the AI Act, Digital Omnibus on AI (EUR-Lex)
    6. OWASP Gen AI Security Project: LLM01:2025 Prompt Injection