Diseña un agente de soporte al cliente con IA: triaje, conocimiento, acciones y derivación

Las afirmaciones destacadas sobre resolución de tickets, ahorro y tiempo de respuesta pueden describir un despliegue concreto de un proveedor, pero no establecen qué puede automatizar tu cola. El resultado depende del alcance, las políticas, la calidad del conocimiento, el acceso a herramientas, la derivación y la forma de medir la «resolución».

No existe una tasa universal de automatización defendible para una «cola de SaaS típica». El restablecimiento de contraseñas, las disputas de facturación, las interrupciones y los errores de producto tienen límites de gestión distintos, y los proveedores contabilizan la «resolución» de formas diferentes. Un agente puede producir respuestas sin respaldo o contrarias a la política aunque su lenguaje parezca seguro. La arquitectura y el diseño de la medición importan más que un porcentaje destacado.

Este artículo presenta un diseño de referencia para probarlo con una muestra etiquetada de tu propia cola. Sus categorías, ventanas temporales, umbrales, prompts y etapas son ejemplos, no valores predeterminados ni afirmaciones de rendimiento. Conserva solo lo que supere tus políticas, la revisión de seguridad y los criterios de evaluación.

Las cuatro tareas de un agente de soporte

Un agente de soporte con IA útil realiza cuatro tareas, en este orden:

1. Comprender el ticket. ¿Qué pide realmente el cliente? ¿Con qué estado emocional aborda la situación? ¿A qué categoría pertenece el problema?
2. Buscar el contexto adecuado. La cuenta del cliente, su historial con la empresa, la documentación pertinente y tickets similares ya resueltos.
3. Decidir qué hacer. Responder con la solución, formular una pregunta aclaratoria, derivar el caso a una persona o ejecutar una acción en la cuenta.
4. Ejecutar una decisión autorizada. Enviar la respuesta, formular la pregunta, derivar el caso o realizar una acción aprobada en la cuenta, registrando la evidencia, la autorización y el resultado necesarios para las operaciones y la auditoría.

Muchos fallos de los agentes de soporte se originan en la falta de contexto o en una lógica de derivación poco clara, pero la capacidad del modelo y la evaluación también importan. Trata el sistema como un todo.

La arquitectura

Un flujo de referencia es:

Ticket entrante
    ↓
[Agente de triaje: clasificar, priorizar, derivar]
    ↓
[Recopilación de contexto: datos del cliente, historial, RAG de la base de conocimiento]
    ↓
[Agente de decisión: proponer respuesta o acción]
    ↓
[Control de política: autorizar, confirmar, bloquear o derivar]
    ↓
[Redacción de respuesta / ejecución controlada de la acción]
    ↓
[Control de calidad de la respuesta, envío o derivación]

Los bloques representan responsabilidades, no una cantidad obligatoria de modelos o servicios. Puedes combinarlos o separarlos en n8n, un framework de agentes o un servicio propio, siempre que el límite de autorización quede fuera del modelo. El flujo se parece al patrón de enrutamiento de la guía de Anthropic para crear agentes eficaces, que incluye el enrutamiento de atención al cliente como ejemplo; no constituye una garantía independiente de la plataforma.

Veamos cada paso.

Paso 1: Clasificación inicial

El agente de clasificación recibe el ticket original y lo categoriza.

Este es un prompt de triaje ilustrativo. Adapta las etiquetas y los umbrales a tu cola y prueba los falsos positivos y negativos de cada categoría antes de enrutar tickets reales:

Eres un agente de triaje del servicio de atención al cliente de [Company]. Clasifica cada ticket entrante según tres dimensiones:

1. CATEGORÍA: uno de estos valores
   - account_access (inicio de sesión, contraseña, MFA, cuenta bloqueada)
   - billing (cargos, reembolsos, cambios de plan, facturas)
   - product_question (instrucciones, preguntas sobre funciones, configuración)
   - bug_report (algo no funciona o se comporta de forma inesperada)
   - feature_request (solicitud de una función que no tenemos)
   - complaint (cliente frustrado, sin un problema técnico concreto)
   - other

2. URGENCIA: uno de los valores "critical" (producción caída, disputa de facturación), "normal" o "low" (consulta informativa).

3. TONO_EMOCIONAL: uno de los valores "calm", "frustrated" o "very_angry". Sé sincero.

Devuelve JSON con `category`, `urgency`, `emotional_tone`, `confidence` y `needs_review`. Establece `needs_review` cuando las pruebas sean insuficientes o el resultado no alcance el umbral validado para esa categoría.

Ejecuta la clasificación con el modelo de menor coste y latencia que supere tus evaluaciones de clasificación y enrutamiento. Un modelo más capaz puede seguir siendo necesario para colas ambiguas o multilingües; decide a partir de los errores medidos, no de una etiqueta fija de modelo.

La salida de esta fase puede alimentar dos decisiones de política:

• En una política, los tickets muy urgentes o procedentes de clientes muy enfadados se derivan directamente a una persona. Otra cola puede usar señales distintas o exigir reglas deterministas para incidentes.
• La categoría puede restringir qué fuente de conocimiento y qué herramientas estarán disponibles después; por sí sola, no debe conceder permisos.

Paso 2: Recopilación de contexto

La calidad del contexto es una variable importante de la calidad del soporte. Sin evidencia pertinente y autorizada, el modelo puede rellenar lagunas con inferencias sin respaldo.

Tres posibles fuentes de contexto son:

Datos del cliente. ¿Quién es? Consulta su plan, la antigüedad de la cuenta, la actividad reciente, el estado de los pagos y cualquier incidencia abierta. Esta información suele proceder del CRM o de la base de datos del producto mediante una llamada a la API.

Historial de conversaciones. ¿Se ha puesto en contacto anteriormente? ¿Por qué motivo? ¿Cómo se resolvió? Evita el modo de fallo «ya te expliqué esto ayer».

Base de conocimiento. Documentación, artículos del centro de ayuda y procedimientos operativos internos. La recuperación puede usar filtros, búsqueda por palabras clave, recuperación densa, búsqueda híbrida, reordenación o una combinación propia del producto. Elige el método y la cantidad de resultados a partir de evaluaciones de recuperación, no de la etiqueta genérica «RAG». (Consulta cómo crear un RAG personal y RAG en producción.)

Las siguientes ventanas y cantidades son marcadores ilustrativos. Defínelos a partir del historial de la cola, las reglas de privacidad y conservación, los presupuestos de latencia y las evaluaciones de recuperación:

Recopila contexto para el ticket [content]:

1. Busca al cliente por su correo electrónico. Si lo encuentras, recupera plan, account_age_days, recent_actions (últimos 7 días) y open_tickets.

2. Consulta el historial de tickets del cliente de los últimos 90 días. Recupera hasta 5 de los tickets más recientes junto con su resolución.

3. Busca artículos relevantes en la base de conocimiento. Recupera los 3 primeros por similitud semántica e incluye sus títulos, resúmenes y URL.

4. Busca problemas similares entre los tickets resueltos de nuestra base de datos. Recupera los 2 primeros junto con sus resoluciones.

Combina los resultados en un objeto de contexto.

Este paso proporciona al agente evidencia con la que trabajar, pero su cobertura y latencia dependen de los sistemas conectados, el diseño de recuperación y los objetivos de nivel de servicio verificados. Registra los identificadores y las versiones de los documentos para que una persona revisora pueda reconstruir qué evidencia estaba disponible.

Límite de privacidad. El contexto del cliente son datos sujetos a permisos, no una comodidad para el prompt. Recupera solo los campos necesarios para el ticket, aplica los controles de acceso por tenant y rol antes de la recuperación, oculta secretos y datos personales innecesarios, y aplica las reglas de conservación aprobadas a prompts, resultados de herramientas, trazas y borradores. Nunca confíes en que el modelo decida qué registros estaba autorizado a ver.

Paso 3: El agente de razonamiento

Ahora el agente propone qué hacer. Este prompt es un ejemplo de política de decisión, no una autorización para ejecutar una acción. Sustituye sus umbrales fijos de dinero, confianza y emoción por valores aprobados para cada categoría de ticket y jurisdicción:

Eres especialista en atención al cliente de [Company]. Tu trabajo consiste en resolver el problema del cliente.

Para cada ticket:

1. Lee detenidamente el ticket y el contexto. El contexto incluye la cuenta del cliente, su historial con nosotros y la documentación pertinente.

2. Decide una de estas acciones:
   - RESOLVE: tienes una respuesta o solución fiable. Redacta una respuesta.
   - CLARIFY: necesitas más información. Redacta una pregunta aclaratoria.
   - ESCALATE: una persona debe ocuparse del caso. Explica por qué.
   - ACT_AND_RESOLVE: propón una acción en la cuenta (emitir un reembolso, restablecer la contraseña, cambiar el plan, etc.) y redacta la respuesta posterior. No la ejecutes; el control de política posterior decide si puede realizarse.

3. Usa un tono directo, cercano y competente. Adáptate al registro del cliente. No seas condescendiente, no te disculpes más de una vez y nunca uses «agradecemos tu paciencia».

4. Cuando cites documentación, enlaza el artículo concreto. No parafrasees de memoria.

5. Si el cliente está frustrado, reconócelo de forma breve y clara y pasa después a la resolución.

6. Transfiere siempre el caso a una persona si:
   - el cliente pide hablar con una persona;
   - el problema implica una disputa económica superior a €100 / $100;
   - el caso no alcanza el umbral validado de confianza o de política para su categoría;
   - el cliente está enfadado y el problema no se resuelve con un solo paso sencillo;
   - el problema afecta a la seguridad o la privacidad;
   - se trata de una queja sobre una persona de nuestro equipo.

7. La salida debe ser JSON:
{
  "action": "<resolve|clarify|escalate|act_and_resolve>",
  "confidence": <0.0-1.0>,
  "reasoning": "<brief explanation>",
  "response_draft": "<the email body>",
  "escalation_reason": "<if applicable>",
  "action_to_take": "<if act_and_resolve, the specific action and arguments>"
}

Este es el núcleo del agente. Elige el modelo menos costoso que cumpla tus umbrales de disposición, calidad de respuesta, seguridad y derivación en tickets representativos. Vuelve a evaluarlo cuando cambien el modelo, el prompt, las herramientas o la cola. El campo reasoning de este ejemplo debe contener una justificación breve, basada en evidencia y política, para un operador; no una cadena de pensamiento privada ni una prueba de que la acción estaba autorizada.

Paso 4: Ejecución de la acción

Para RESOLVE y CLARIFY, la respuesta propuesta debe superar los controles de calidad y de política antes de enviarse.

Para ESCALATE, deriva el ticket a una cola humana con el mensaje del cliente, la evidencia recuperada, la regla de política pertinente, los pasos intentados y el motivo de la derivación. No sustituyas ese registro para el operador por razonamiento oculto del modelo.

Para ACT_AND_RESOLVE, el modelo propone una acción. Una ruta de control independiente decide si puede ejecutarse. La guía de OWASP sobre agencia excesiva recomienda funcionalidad y permisos mínimos, ejecución en el contexto de seguridad del usuario, autorización posterior y aprobación humana para acciones de alto impacto. Aplica esos controles al flujo de soporte:

• Lista de permisos mínimos. Expón solo operaciones de alcance reducido. Una política podría permitir reembolsos de hasta 50 € a modo ilustrativo y exigir revisión por encima de esa cantidad, pero el límite real debe proceder de la política autorizada, no de este artículo ni del prompt.
• Identidad y autorización. Resuelve el cliente autenticado, el tenant, el operador y el alcance concedido antes de ejecutar. Aplica el acceso en el servicio posterior en cada llamada; la clasificación o confianza del modelo no puede conceder acceso.
• Argumentos validados. Restringe los nombres y argumentos de las acciones mediante un esquema, rechaza campos inesperados y vuelve a comprobar cuenta, divisa, importe, destino y política justo antes del efecto. Cuando el proveedor admita llamadas a herramientas limitadas por esquema, actívalas; por ejemplo, el modo strict de llamadas a funciones de OpenAI exige conformidad con el esquema, pero no establece autorización ni corrección factual.
• Confirmación y aprobación. Exige confirmación explícita del cliente o aprobación humana cuando lo requieran el riesgo, la política, la ley o la ambigüedad. La recuperación sensible para la seguridad debe seguir el proceso de recuperación de identidad verificado, no una acción de restablecimiento genérica.
• Idempotencia y concurrencia. Asigna a cada acción una clave de idempotencia, evita ejecuciones duplicadas en los reintentos y gestiona el estado obsoleto de la cuenta o las actualizaciones competidoras.
• Reversibilidad y gestión de fallos. Prefiere operaciones por etapas o reversibles, define la reversión o conciliación ante un fallo parcial y deriva los resultados inciertos a una persona en lugar de repetir la acción a ciegas.
• Controles de seguridad. Aplica límites de frecuencia, tiempos de espera de herramientas, aislamiento entre tenants, gestión de secretos y supervisión de abusos con independencia del modelo.
• Registro de auditoría. Registra el identificador de la solicitud, la identidad del actor y del cliente, las entradas ocultando datos sensibles, los identificadores y versiones de la evidencia, el resultado de política y autorización, la confirmación o persona aprobadora, los argumentos exactos de la acción, el resultado de la herramienta y el estado de reversión o error. Una justificación generada por el modelo puede facilitar la revisión, pero no constituye el registro de auditoría.

Paso 5: Revisión de calidad

Usa dos controles distintos. Antes de cualquier efecto, los controles deterministas de política y autorización deben bloquear, aprobar o derivar la acción propuesta. Por separado, un revisor de respuesta basado en un modelo o en reglas puede detectar problemas de calidad antes de enviar el mensaje. Trátalo como un detector evaluado con tasas conocidas de falsos positivos y negativos, no como un juez infalible ni como un servicio de autorización.

Revisas la calidad de respuestas de atención al cliente generadas por IA.

A partir del ticket original y del borrador de respuesta, comprueba:

1. ¿La respuesta aborda realmente la pregunta del cliente?
2. ¿Es correcta según el contexto proporcionado y no contiene hechos inventados?
3. ¿El tono es adecuado (cercano, directo, sin condescendencia ni disculpas excesivas)?
4. ¿Hay algún enlace roto o incorrecto?
5. ¿Contiene alguna de estas señales de alerta?
   - Promete algo que no podemos cumplir
   - Se disculpa por algo que no es culpa nuestra
   - Suena enfadada o sarcástica
   - Usa jerga interna
   - Revela información interna

Salida: APPROVE o REVISE (con sugerencias concretas de corrección).

Si el control de calidad devuelve APPROVE y la respuesta supera la política, puede enviarse. Si devuelve REVISE, aplica una revisión acotada y vuelve a comprobarla, o derívala a una persona. Limita los reintentos de revisión automática para que un detector defectuoso no genere un bucle.

La utilidad de este control frente a su coste es una cuestión empírica. Registra con qué frecuencia cambia la decisión, cuántas respuestas deficientes detecta y cuántas respuestas correctas bloquea; consérvalo solo si esas mediciones justifican la latencia y la llamada al modelo adicionales.

Haz que la base de conocimiento sea comprobable

La base de conocimiento es un factor crítico para la calidad del agente. Si el centro de ayuda está desactualizado, contiene contradicciones o está incompleto, el agente puede producir respuestas seguras pero sin respaldo.

Principios prácticos:

Audita antes del despliegue. Toma una muestra de los tipos de tickets de mayor volumen y riesgo y comprueba que la base de conocimiento contenga la respuesta adecuada para cada uno. Completa las lagunas, resuelve las contradicciones y actualiza los artículos obsoletos. Amplía la muestra hasta que los datos de tu cola respalden tus criterios de aceptación.

Estructura para el método de recuperación elegido. Las secciones enfocadas, los títulos claros, los identificadores estables y la aplicabilidad explícita pueden ayudar a la recuperación, pero la fragmentación y la longitud de los artículos son decisiones de implementación. Comprueba que se recuperen el pasaje necesario y su ámbito en preguntas representativas.

Incluye secciones explícitas sobre lo que no debe hacerse. Muchos tickets preguntan cómo realizar una acción que el cliente no debería ejecutar. Los artículos deben indicar de forma expresa: «si intentas hacer X, estos son los motivos por los que no lo recomendamos y esta es la alternativa».

Representa el ámbito de aplicación. Metadatos como «solo para el plan gratuito», «solo para clientes de la UE» o «solo para la aplicación iOS» pueden servir para filtrar. Aplica esas restricciones en la capa de recuperación y comprueba que se excluya el material contradictorio o fuera de alcance.

Revisa según la responsabilidad y los desencadenantes de cambio. Asigna una persona responsable a cada área de conocimiento y un intervalo de revisión adecuado a su riesgo y ritmo de cambio. Vuelve a revisar el material afectado cuando cambien los productos, las políticas, los incidentes o las regulaciones.

Calibra la derivación mediante políticas y evaluaciones

Un sistema que deriva demasiado aumenta la carga de la cola; uno que deriva demasiado poco puede causar daños al cliente o a la seguridad. Define reglas según la categoría, las consecuencias, la calidad de la evidencia, la elección del cliente y las tasas de error medidas. Una política inicial podría incluir:

Derivar a una persona o a una cola especializada:

• Solicitudes explícitas de hablar con una persona
• Enfado por encima de un umbral (especialmente tras una mala respuesta del agente)
• Disputas que involucran dinero real
• Preocupaciones de seguridad o privacidad
• Implicaciones para la salud, la seguridad o de carácter jurídico
• Tickets repetidos del mismo cliente sobre el mismo problema
• Casos que no cumplan el umbral validado de confianza o política de su categoría

Candidatos para la automatización después de superar las evaluaciones pertinentes:

• Preguntas triviales con respuestas claras en la KB
• Tareas de mantenimiento de cuenta (restablecimiento de contraseña, cambios básicos de perfil)
• Consultas de estado («¿se ha procesado mi reembolso?»)
• Solicitudes de funciones (dirigirlas al equipo de producto, no al soporte humano)

Estas listas no son universales. Un restablecimiento de contraseña, el estado de un reembolso o un cambio de cuenta pueden ser de alto riesgo en un producto y rutinarios en otro. Automatiza solo cuando la respuesta o acción esté dentro de la política, se hayan verificado la identidad y autoridad de quien llama, la herramienta tenga un alcance estricto y el caso supere la regla de aceptación medida de la categoría.

En la zona intermedia es donde importa el criterio del agente. Añade instrumentación que permita responder estas preguntas: de todos los casos que el agente podría haber derivado y no derivó, ¿en qué proporción volvió a contactar el cliente? De los casos derivados, ¿cuántos resolvió una persona de forma trivial?

Obtén un objetivo de automatización a partir de tu propia cola

No empieces con el objetivo de tasa de resolución de un proveedor. Etiqueta una muestra representativa de tu cola reciente en categorías como:

• preguntas sencillas y claramente documentadas;
• preguntas que requieren contexto de la cuenta o una herramienta controlada;
• diagnóstico de problemas complejos, situaciones emocionales o decisiones sobre políticas;
• informes de errores y solicitudes de funciones que corresponden a producto o ingeniería.

Para cada categoría, comprueba si el agente puede producir una disposición y una respuesta correctas conforme a tu política real. La suma de las categorías que superen tus umbrales de aceptación es tu techo inicial de automatización. Vuelve a calcularlo cuando cambien la base de conocimiento, las herramientas o las políticas; no ajustes las etiquetas a posteriori para alcanzar un porcentaje prometido.

Mide los resultados para el cliente

Mide qué valoran los clientes en tu propia cola. Algunas métricas posibles son:

• tiempo hasta una resolución correcta;
• precisión de la respuesta y cumplimiento de las políticas;
• tasa de nuevos contactos, esfuerzo del cliente y satisfacción;
• capacidad para contactar con una persona cuando falla la automatización.

No deduzcas las preferencias solo de la velocidad. Una respuesta rápida pero incorrecta, o un bot que oculta la vía humana, puede empeorar la experiencia frente a una cola con un tiempo de espera explícito.

Un bucle automatizado repetido sin una vía humana utilizable es un modo de fallo previsible. Mide los contactos reiterados y las sesiones abandonadas, limita los reintentos automáticos y haz que la derivación sea fácil de encontrar.

Un par de patrones específicos

La personalización puede ser pertinente. «Hola, Anna. Veo que utilizas nuestro plan Pro y eres cliente desde 2023» produce un efecto distinto de «Hola, cliente». Utiliza solo datos aprobados que ayuden a resolver el caso y evita detalles que puedan percibirse como vigilancia.

Reconoce una espera verificada cuando sea pertinente. Usa las marcas de tiempo del sistema de tickets y la política real de nivel de servicio en lugar de inventar cuánto esperó el cliente o dar a entender que se incumplió un objetivo.

Confirma el dato pertinente. «Has indicado que la importación fallaba en los registros cuyo nombre de empresa contenía caracteres especiales». Úsalo solo si refleja fielmente el ticket; repetirlo no demuestra que el sistema lo haya entendido.

Termina con un siguiente paso verificado. «El reembolso fue aceptado por [payment system] a las [time]. Su plazo de liquidación actual es [verified policy or provider window]». No afirmes que una acción tuvo éxito ni inventes un plazo de entrega a partir del borrador del modelo.

No te disculpes sin motivo. Decir «siento mucho las molestias» antes de saber qué ha ocurrido resulta poco sincero. Discúlpate una vez, de forma específica y cuando corresponda.

Un ejemplo completo

El cliente escribe:

Hola, llevo tres días intentando iniciar sesión y siempre aparece un mensaje que indica que mi contraseña es incorrecta. Estoy seguro de que es la correcta: la he utilizado durante dos años. Empiezo a pensar que han sufrido un ataque.

Un borrador más seguro, después de que el sistema haya verificado la cuenta y la vía de recuperación aprobada, es:

Hola Anna,

Entiendo que tres días de intentos fallidos de inicio de sesión resulten preocupantes. Los registros de acceso disponibles para soporte muestran varios intentos fallidos, pero no permiten saber quién los hizo ni si alguien accedió a la cuenta. No he cambiado tu contraseña ni la configuración multifactor.

Utiliza el enlace de recuperación de cuenta de nuestra página de inicio de sesión verificada: [approved recovery URL]. Antes de completar cualquier restablecimiento, el flujo de recuperación verificará tu identidad. No compartas con soporte una contraseña, un código de un solo uso, un código de recuperación ni un enlace de restablecimiento.

Si no reconoces los intentos, no puedes completar el flujo de recuperación verificado o ves una sesión o cambio de cuenta desconocidos, responde aquí y derivaré el caso al equipo de seguridad de cuentas. Su objetivo de respuesta es [verified security-queue SLA].

— Soporte de AI Expert

Este borrador distingue la evidencia observada de la inferencia, evita afirmar que no hubo una intrusión, no expone ni elige una dirección de recuperación y deja como marcadores explícitos la derivación de seguridad y el plazo de respuesta. La versión final sigue necesitando la URL verificada de la empresa, su proceso de identidad y su objetivo actual de nivel de servicio.

Qué construir primero

Define el objetivo de resolución a partir de una referencia etiquetada y de datos piloto, no de este artículo ni del caso de estudio de un proveedor. El modelo rara vez es el único cuello de botella. Hay cuatro factores principales:

1. Una base de conocimiento gobernada y evaluada.
2. Una recopilación de contexto sólida (datos e historial del cliente, recuperación desde la base de conocimiento y tickets similares ya resueltos).
3. Un agente de razonamiento con criterios de decisión y reglas de derivación claros.
4. Controles (autorización, listas de permitidos, confirmación, controles de respuesta y registros de auditoría).

Estos controles pueden respaldar un piloto útil, pero no garantizan un soporte mejor ni una menor carga humana.

Empieza con un piloto acotado y reversible. Mide la disposición correcta, la exactitud de las respuestas fundamentadas, el cumplimiento de políticas, los intentos de acciones no autorizadas, las acciones duplicadas o fallidas, la tasa de nuevos contactos, el tiempo hasta la resolución correcta, el esfuerzo del cliente, la precisión y exhaustividad de la derivación, y la carga que los falsos positivos crean en la cola humana. Segmenta los resultados por categoría, idioma, grupo de clientes cuando proceda y acción de herramienta para que una puntuación agregada no oculte un segmento peligroso.

Tras el piloto sigue habiendo riesgo residual: la recuperación puede omitir evidencia o mostrarla obsoleta, las señales de identidad pueden ser erróneas, la política puede estar incompleta, quienes revisan pueden pasar por alto borradores inseguros, las integraciones pueden fallar entre la aprobación y la ejecución, y los clientes pueden malinterpretar una respuesta automatizada. Mantén una vía humana visible, un control para detener incidentes, un proceso supervisado de reversión o conciliación y responsables designados de políticas, conocimiento, herramientas y evaluación. Amplía el alcance solo cuando los beneficios medidos y el riesgo residual respalden la siguiente categoría.