Crea en n8n un flujo de soporte con IA y revisión humana
Un ejercicio editorial para clasificar mensajes de soporte sintéticos, revisar casos sensibles, redactar respuestas y demostrar un flujo de errores de n8n.
Comprobado con la documentación de n8n el .
Ejercicio editorial: tarea y objetivo de aprendizaje
Este es un ejercicio editorial, no un flujo de atención al cliente validado. Tu tarea consiste en crear un flujo principal de n8n que clasifique mensajes de soporte inventados, prepare borradores de respuesta estructurados y dirija los casos sensibles o sin coincidencia a una persona responsable de revisarlos. También crearás un segundo flujo que gestione un fallo deliberado del flujo principal.
El objetivo de aprendizaje es practicar la clasificación, el enrutamiento condicional, la supervisión humana, la redacción estructurada y la gestión de errores sin contactar con clientes reales. Completar con éxito este pequeño ejercicio no demuestra la precisión de la clasificación, la seguridad de las respuestas, la resiliencia en producción ni la preparación para prestar soporte en vivo.
Requisitos previos, entradas y restricciones de seguridad
Utiliza tu propio entorno de n8n y obtén permiso para crear y configurar dos flujos. Necesitarás acceso a un modelo de chat compatible y sus credenciales. Si decides demostrar un mecanismo de aprobación basado en Gmail, también necesitarás credenciales de Gmail y una dirección de prueba controlada por la persona facilitadora. La aprobación mediante Gmail es una sugerencia opcional, no una afirmación de que este flujo concreto haya sido probado.
Prepara un pequeño conjunto de entradas sintéticas. Las categorías sugeridas son pregunta ordinaria, solicitud relacionada con datos sensibles de una cuenta, solicitud relacionada con pagos y mensaje abusivo o amenazante. Incluye al menos un mensaje deliberadamente ambiguo para la ruta sin coincidencia y un elemento con un marcador explícito para probar fallos. Estas categorías son sugerencias editoriales, no una política universal de soporte.
No utilices nombres, direcciones de correo electrónico, identificadores de cuenta, información de pago, secretos ni historiales de clientes reales. Mantén las salidas ordinarias en una rama destinada únicamente a la vista previa y no configures su envío automático a clientes. Una persona debe revisar todos los casos sensibles o sin coincidencia. Quienes faciliten el ejercicio deben elegir reglas prudentes y adecuadas para su situación ficticia, ya que la documentación proporcionada no define ningún umbral de confianza ni ninguna política de escalado universales.
Clasifica los mensajes y conserva los casos sin coincidencia
Inicia el flujo principal con un disparador adecuado para la ejecución automática, seguido de tu fuente de mensajes sintéticos. Añade un Text Classifier y define cada categoría con un nombre y una descripción claros. El nodo clasifica los elementos entrantes según las categorías configuradas en sus parámetros, pero esta capacidad no garantiza su precisión ni su idoneidad para un sistema de soporte en producción.
Activa la salida independiente Other y úsala como ruta de seguridad en lugar de descartar los mensajes que no encajen en las categorías propuestas. Conecta Other directamente con la ruta de revisión humana. Comprueba con el conjunto de muestras previsto que cada mensaje ordinario y sensible llegue a su categoría correspondiente o a Other. Si desaparece algún elemento, revisa la configuración de Other y modifica las descripciones de las categorías sin considerar que una ejecución correcta con las muestras demuestra una fiabilidad general.
Sources: S4
Redacta una respuesta estructurada sin enviarla
En cada rama clasificada que necesite un borrador, añade un Basic LLM Chain conectado al modelo elegido. Crea su prompt mediante una expresión dinámica que incluya únicamente el mensaje sintético y la categoría asignada. Solicita una salida estructurada que contenga, como mínimo, una categoría y un borrador. Exigir un analizador de salida es una restricción sugerida útil cuando se desean campos predecibles.
Indica en el prompt que la respuesta es un borrador pendiente de revisión, no una respuesta verificada. No pidas al modelo que invente políticas, datos de cuentas, reembolsos ni compromisos. Envía los borradores ordinarios únicamente a un paso de vista previa. La capacidad del nodo para aceptar prompts dinámicos o exigir una salida analizada no valida la calidad, la exactitud factual ni la seguridad de la respuesta generada.
Si falta el borrador, revisa la expresión del prompt, la conexión con el modelo, las credenciales y la configuración del analizador. Considera cómo debería gestionar tu flujo una salida estructurada con un formato incorrecto; las capacidades proporcionadas no garantizan que todas las respuestas del modelo respeten la estructura solicitada.
Sources: S5
Dirige los casos sensibles y sin coincidencia a revisión humana
Añade un nodo If después de la clasificación o la redacción para evaluar la categoría asignada. Utiliza condiciones de comparación que envíen las categorías sensibles propuestas a una rama de revisión y las preguntas ordinarias a la rama destinada únicamente a la vista previa. Conecta la salida Other del clasificador con el mismo destino de revisión. Estas condiciones implementan tu política editorial; la capacidad de enrutamiento condicional de n8n no proporciona ni valida esa política.
El registro de revisión debe mostrar la entrada sintética, la categoría propuesta y el borrador de respuesta para que la persona responsable disponga de contexto suficiente para decidir qué hacer. En este ejercicio, no envíes automáticamente borradores sensibles, ambiguos o sin coincidencia. Si demuestras la aprobación mediante Gmail para una herramienta de IA supervisada, trátala como un mecanismo de aprobación opcional y limita cualquier mensaje a una dirección de prueba controlada por la persona facilitadora. El mecanismo de aprobación documentado puede pausar la llamada a una herramienta de IA antes de ejecutar una herramienta supervisada, pero la configuración propuesta no se ha probado aquí.
Crea y demuestra el flujo de errores vinculado
Crea un segundo flujo que comience con Error Trigger y añade después un paso de vista previa o inspección de los detalles del fallo recibido. Guarda este flujo y selecciónalo en el ajuste Error workflow del flujo principal. Un flujo de errores vinculado se ejecuta cuando se produce un error en el flujo principal y proporciona información sobre el flujo que ha fallado y su error.
En el flujo principal, coloca Stop And Error detrás de una condición que solo coincida con el elemento explícito de prueba de fallos. Configura un mensaje de error personalizado y breve que identifique claramente el ejercicio. Este nodo puede provocar deliberadamente el fallo de una ejecución y transmitir información de error personalizada a un flujo de errores; no demuestra que la recuperación o las notificaciones posteriores vayan a funcionar.
Ejecuta la ruta de fallo mediante un disparador automático. La ejecución manual de un flujo no activa el flujo Error Trigger vinculado. Confirma que el segundo flujo se ejecute y que la ejecución fallida del flujo principal esté disponible para su inspección. Si procede, practica reintentándola desde la pestaña Executions con el flujo guardado o con el original, teniendo presente que la visibilidad de las ejecuciones depende de los permisos de acceso y que los flujos eliminados pierden su historial de ejecución.
Criterios de finalización, resolución de problemas y reflexión
El ejercicio estará completo cuando cada muestra sintética llegue a su categoría prevista o a la ruta Other; todos los elementos sensibles y sin coincidencia lleguen a revisión humana; las respuestas ordinarias permanezcan como borradores; la prueba automática de fallos active el flujo de errores vinculado; y la ejecución fallida esté visible para inspeccionarla o reintentarla. Estos son criterios editoriales de finalización para la práctica, no pruebas de rendimiento en producción.
Si se pierden entradas, revisa las descripciones de las categorías y la salida Other. Si el enrutamiento es incorrecto, inspecciona las comparaciones del nodo If y los valores que reciben. Si faltan borradores, verifica el prompt dinámico, el modelo conectado, las credenciales y los campos estructurados esperados. Si el flujo de errores no se ejecuta, confirma que esté guardado, vinculado en los ajustes del flujo principal, que comience con Error Trigger y que se esté probando mediante una ejecución automática, no manual.
Reflexiona sobre estas preguntas sugeridas: ¿Qué casos ficticios deberían requerir siempre una revisión? ¿Qué contexto necesita la persona responsable de revisar? ¿Qué debería ocurrir cuando el modelo devuelve una salida con un formato incorrecto? ¿Cómo deberían gestionarse de manera prudente las categorías contradictorias? ¿Por qué unas ejecuciones correctas con muestras no demuestran la precisión de la clasificación, la seguridad ni la preparación para producción? Una solución sugerida consiste en utilizar categorías explícitas, dirigir Other y todos los casos sensibles a una única ruta de revisión, mantener los resultados ordinarios únicamente como vistas previas y aislar el fallo deliberado detrás de una condición exclusiva para pruebas.
Sources: S4, S5, S6, S7, S8, S2
