n8n: Часть 6 — Узел Guardrails: защита LLM-процессов

Процессы n8n с языковыми моделями несут два типа рисков. На входе пользователь может прислать персональные данные, ключ API или попытку «взломать» инструкции модели. На выходе модель может выдать неуместный ответ, чужую ссылку или раскрыть то, что попало ей в контекст. Раньше такие проверки собирали вручную из узлов IF, регулярных выражений и дополнительных запросов к модели. Узел Guardrails собирает их в одном месте.

Две операции

По документации n8n у узла две операции:

• Check Text for Violations — проверяет текст по выбранному набору правил. Если хотя бы одно правило нарушено, элемент уходит в ветку Fail, иначе — в Pass.
• Sanitize Text — не блокирует текст, а находит нарушения и заменяет их заглушками, например вместо адреса почты подставляет метку.

Обычно узел ставят дважды: перед вызовом модели (проверить или очистить ввод) и после него (проверить ответ перед отправкой пользователю или в другую систему).

Типы проверок

Проверки, которые выполняет модель (Jailbreak, NSFW, Topical Alignment, Custom), требуют подключённого узла чат-модели и имеют порог срабатывания от 0,0 до 1,0. Чем ниже порог, тем строже проверка и тем больше ложных срабатываний.

Пример: помощник поддержки

Задача: сообщения клиентов приходят через веб-хук, модель готовит ответ, ответ уходит клиенту.

1. Webhook принимает сообщение.
2. Guardrails, Sanitize Text с проверками PII и Secret Keys — телефоны, адреса почты и случайно вставленные ключи заменяются заглушками до того, как текст попадёт к модели и в журналы выполнения.
3. Guardrails, Check Text for Violations с проверкой Jailbreak — попытки переписать инструкции уходят в ветку Fail, где процесс отвечает стандартной фразой и пишет событие в журнал.
4. AI Agent или узел модели готовит ответ.
5. Guardrails, Check Text for Violations на ответе: Topical Alignment («только вопросы о продукте и заказах») и URLs с разрешённым списком ваших доменов.
6. Ветка Pass отправляет ответ клиенту, ветка Fail — передаёт обращение оператору.

Что учитывать

• Проверки на базе модели стоят денег и времени. Каждая из них — дополнительный запрос к модели. Для потока в тысячи сообщений в день это заметная статья расходов и задержка ответа. Дешёвые проверки (Keywords, PII, Secret Keys, URLs, Custom Regex) ставьте первыми.
• Санитизация не отменяет требований закона. Если персональные данные уже попали в веб-хук, они прошли через ваш сервер n8n и могли сохраниться в истории выполнений. Сроки хранения истории настраиваются отдельно — об этом во второй части цикла.
• Облачная модель — это передача данных. Для российских компаний передача персональных данных зарубежному поставщику модели — отдельный правовой вопрос; санитизация перед вызовом уменьшает риск, но не решает его полностью.
• Пороги подбирают на реальных данных. Прогоните через процесс набор настоящих обращений и посмотрите, сколько законных сообщений отсекается.

Типичные ошибки

• Поставить только выходную проверку и отправлять модели неочищенный ввод.
• Сделать ветку Fail тупиком: пользователь не получает ответа, оператор не узнаёт об обращении.
• Использовать для проверок ту же модель и тот же промпт, что и для ответа: одна и та же уязвимость обходит обе.
• Не смотреть историю выполнений: без неё непонятно, какие правила срабатывают ложно.

Guardrails не делает процесс с языковой моделью безопасным сам по себе, но заменяет десятки самодельных проверок одним понятным узлом, который легко поддерживать.