n8n: Parte 6 — Nodo Guardrails: protección de procesos LLM

Los procesos n8n con modelos de lenguaje conllevan dos tipos de riesgos. En la entrada, el usuario puede enviar datos personales, una clave API o un intento de «hackear» las instrucciones del modelo. En la salida, el modelo puede dar una respuesta inapropiada, un enlace ajeno o revelar lo que haya recibido en el contexto. Antes, estas comprobaciones se reunían manualmente con nodos IF, expresiones regulares y solicitudes adicionales al modelo. El nodo Guardrails las agrupa en un solo lugar.

Dos operaciones

Según la documentación de n8n, el nodo tiene dos operaciones:

• Check Text for Violations — comprueba el texto según un conjunto de reglas seleccionadas. Si al menos una regla se incumple, el elemento va a la rama Fail, si no — a Pass.
• Sanitize Text — no bloquea el texto, sino que detecta infracciones y las reemplaza por marcadores; por ejemplo, en lugar de una dirección de correo inserta una etiqueta.

Normalmente se coloca el nodo dos veces: antes de llamar al modelo (para comprobar o limpiar la entrada) y después (para comprobar la respuesta antes de enviarla al usuario o a otro sistema).

Tipos de comprobaciones

Las comprobaciones que ejecuta el modelo (Jailbreak, NSFW, Topical Alignment, Custom) requieren un nodo de modelo de chat conectado y tienen un umbral de activación de 0.0 a 1.0. Cuanto más bajo es el umbral, más estricta es la comprobación y más falsos positivos habrá.

Ejemplo: asistente de soporte

Tarea: los mensajes de los clientes llegan vía webhook, el modelo prepara la respuesta y ésta se envía al cliente.

1. Webhook recibe el mensaje.
2. Guardrails, Sanitize Text con comprobaciones PII y Secret Keys — teléfonos, direcciones de correo y claves insertadas por error se reemplazan por marcadores antes de que el texto llegue al modelo y a los registros de ejecución.
3. Guardrails, Check Text for Violations con la comprobación Jailbreak — los intentos de reescribir las instrucciones van a la rama Fail, donde el proceso responde con una frase estándar y registra el evento en el log.
4. AI Agent o nodo de modelo prepara la respuesta.
5. Guardrails, Check Text for Violations en la respuesta: Topical Alignment («solo preguntas sobre el producto y los pedidos») y URLs con una lista de dominios permitidos (tus dominios).
6. La rama Pass envía la respuesta al cliente; la rama Fail deriva la solicitud a un operador.

Qué tener en cuenta

• Las comprobaciones basadas en modelo cuestan dinero y tiempo. Cada una implica una solicitud adicional al modelo. Para un flujo de miles de mensajes al día, es un coste y una latencia notables. Coloca primero las comprobaciones baratas (Keywords, PII, Secret Keys, URLs, Custom Regex).
• La sanitización no anula las obligaciones legales. Si los datos personales ya llegaron al webhook, pasaron por tu servidor n8n y podrían haberse guardado en el historial de ejecuciones. Los plazos de retención del historial se configuran por separado — sobre esto en la segunda parte de la serie.
• Un modelo en la nube implica transferencia de datos. Para empresas rusas, la transferencia de datos personales a un proveedor extranjero de modelos es una cuestión legal aparte; la sanitización antes de la llamada reduce el riesgo, pero no lo resuelve por completo.
• Los umbrales se ajustan con datos reales. Ejecuta en el proceso un conjunto de solicitudes reales y observa cuántos mensajes legítimos son filtrados.

Errores típicos

• Poner solo la comprobación de salida y enviar al modelo la entrada sin limpiar.
• Hacer de la rama Fail un callejón sin salida: el usuario no recibe respuesta y el operador no se entera de la solicitud.
• Usar para las comprobaciones el mismo modelo y el mismo prompt que para la respuesta: la misma vulnerabilidad puede eludir ambos.
• No revisar el historial de ejecuciones: sin él no se sabe qué reglas fallan por falsos positivos.

Guardrails no hace que un proceso con modelo de lenguaje sea seguro por sí solo, pero sustituye decenas de comprobaciones caseras por un nodo claro y fácil de mantener.