PII redaction перед AI в n8n: как защитить персональные данные и сохранить качество ответа ¶

Обновлено: 2026-05-29

Короткий ответ ¶

PII redaction перед AI в n8n — это обязательный safety layer, если workflow отправляет в LLM письма, заявки, чаты, CRM-поля, документы или тикеты пользователей. Цель не просто «замазать email», а убрать или заменить персональные данные так, чтобы модель всё ещё понимала задачу. Хорошая схема различает masking, tokenization, hashing и removal; сохраняет mapping в защищённом storage; не логирует raw PII; проверяет результат перед LLM; и запрещает AI выполнять действия с персональными данными без нужных прав.

Что считается PII ¶

PII — это данные, которые прямо или косвенно помогают идентифицировать человека. В AI workflow опасны не только очевидные поля вроде email и телефона, но и комбинации: имя + компания + должность + город + текст обращения.

Типы данных, которые стоит искать:

Redaction, masking, tokenization и hashing ¶

Эти слова часто смешивают, но для workflow они означают разные вещи.

Для LLM чаще всего лучше tokenization: модель видит структуру, но не видит реальное значение. Например: «Клиент [PERSON_1] просит поменять email [EMAIL_1] на [EMAIL_2]». Модель понимает действие, но не получает адреса.

Базовый workflow PII redaction в n8n ¶

1. Input trigger получает письмо, чат, webhook или CRM payload.
2. PII detector находит email, телефон, имена, адреса, IDs, tokens.
3. Risk classifier определяет уровень: low/medium/high/blocked.
4. Redaction mapper заменяет значения на placeholders.
5. Secure mapping storage сохраняет соответствие [EMAIL_1] -> real email, если нужно восстановление.
6. Redaction validator проверяет, что raw PII не осталось.
7. AI step получает только redacted input.
8. Output validator проверяет, что модель не выдумала PII.
9. Rehydration при необходимости подставляет данные обратно в защищённой ветке.
10. Audit log сохраняет PII types, counts, policy decision, но не raw values.

Пример redaction в Code node ¶

function redact(text) {
  const map = [];
  let result = String(text || '');

  const patterns = [
    { type: 'EMAIL', re: /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi },
    { type: 'PHONE', re: /(?:\+?7|8)?[\s\-\(]*\d{3}[\s\-\)]*\d{3}[\s\-]*\d{2}[\s\-]*\d{2}/g },
    { type: 'TOKEN', re: /(sk-[A-Za-z0-9_-]{20,}|xox[baprs]-[A-Za-z0-9-]+)/g },
    { type: 'CARD', re: /\b(?:\d[ -]*?){13,19}\b/g }
  ];

  for (const { type, re } of patterns) {
    let count = 0;
    result = result.replace(re, (match) => {
      count += 1;
      const token = `[${type}_${count}]`;
      map.push({ token, type, value: match });
      return token;
    });
  }

  return { redacted: result, pii_map: map };
}

const { redacted, pii_map } = redact($json.text);

return [{
  json: {
    ...$json,
    redacted_text: redacted,
    pii_types: [...new Set(pii_map.map(x => x.type))],
    pii_count: pii_map.length,
    // raw pii_map лучше отправлять в secure storage, а не в обычный execution output
    pii_map_preview: pii_map.map(x => ({ token: x.token, type: x.type }))
  }
}];

Это стартовый пример, не финальная privacy-система. Имена, адреса и контекстные PII требуют дополнительных правил, словарей или отдельного detection step.

Как сохранить смысл после redaction ¶

Слишком агрессивная редация ломает задачу. Например, фраза «Клиент из Германии просит удалить аккаунт по GDPR» теряет смысл, если заменить всё на [TEXT]. Нужно оставлять типы и роли:

До:

Иван Петров из ООО Ромашка просит перенести встречу с 12 июня на 13 июня и отправить ссылку на ivan@company.ru.

Плохо:

[REMOVED] просит [REMOVED].

Хорошо:

[PERSON_1] из [COMPANY_1] просит перенести встречу с [DATE_1] на [DATE_2] и отправить ссылку на [EMAIL_1].

Модель понимает задачу, но не видит реальные данные.

Когда нельзя отправлять даже redacted текст ¶

Есть сценарии, где редации недостаточно:

• пользователь прислал API key или OAuth token;
• запрос содержит банковские реквизиты;
• документ содержит чувствительные медицинские/юридические данные;
• пользователь просит выполнить действие с чужими данными;
• redaction validator не уверен;
• текст настолько уникален, что человека можно идентифицировать даже без email;
• политика клиента запрещает отправку данных внешним AI-провайдерам.

В этих случаях route должен идти в human review, local processing, обычные правила или secure internal model, если это разрешено политикой.

Rehydration: как вернуть PII после AI ¶

Иногда AI нужен для подготовки шаблона, а реальные данные надо вернуть позже. Например, модель пишет черновик письма:

{
  "subject": "Перенос встречи",
  "body": "Здравствуйте, [PERSON_1]. Подтверждаем перенос встречи на [DATE_2]. Ссылка будет отправлена на [EMAIL_1]."
}

После validation workflow может заменить placeholders на реальные значения. Но rehydration должна быть отдельным контролируемым шагом:

• только после schema validation;
• только для разрешённых placeholders;
• только в trusted channel;
• с audit log;
• без повторной отправки rehydrated текста в LLM.

Проверка, что PII не просочилась ¶

После redaction запустите validator:

• повторный regex scan;
• список запрещённых типов;
• проверка token-like strings;
• проверка card-like numbers;
• проверка email/phone;
• проверка известных customer names;
• оценка high-risk context;
• random sampling для QA.

Если validator нашёл PII, workflow должен остановиться или перейти на secure review. Нельзя «надеяться», что модель сама не использует лишние данные.

Что логировать ¶

Логируйте:

{
  "redaction_status": "passed",
  "pii_types": ["EMAIL", "PHONE"],
  "pii_count": 3,
  "redaction_policy_version": "pii_v6",
  "mapping_storage": "secure_vault",
  "rehydration_allowed": true,
  "validator_status": "passed",
  "raw_pii_logged": false
}

Не логируйте сами значения PII в обычные execution logs, spreadsheets или Slack alerts. Даже alert об ошибке может стать утечкой, если в нём есть raw payload.

PII и RAG ¶

RAG может протащить персональные данные из документов в ответ. Поэтому redaction нужна не только на user input, но и на ingestion:

• очищать документы перед embedding;
• хранить metadata sensitivity level;
• не индексировать private tickets в public knowledge base;
• разделять vector stores по tenant/project;
• фильтровать retrieval по правам пользователя;
• не смешивать support transcripts с публичной документацией;
• удалять embeddings при deletion request, если политика этого требует.

Если в vector store попали персональные данные, LLM может достать их даже при чистом вопросе.

PII и AI Agent tools ¶

AI Agent с tools опаснее обычного LLM, потому что он может не только прочитать, но и выполнить действие. Для tools:

• разделяйте read-only и write tools;
• не давайте агенту широкие CRM credentials;
• требуйте human approval для изменения email, телефона, адреса, тарифа, платежных данных;
• проверяйте, что placeholder не ушёл в API вместо реального значения;
• проверяйте, что реальное значение не ушло в модель после rehydration.

Тестовый набор ¶

Проверьте redaction на таких примерах:

1. Один email в тексте.
2. Несколько email с разными доменами.
3. Российский телефон в разных форматах.
4. Имя + компания + должность.
5. Паспорт/ИНН/СНИЛС-like номера.
6. API key в тексте ошибки.
7. OAuth token в webhook payload.
8. Текст с адресом и номером квартиры.
9. Запрос с двумя людьми и двумя email.
10. RAG-документ с персональными данными.
11. Prompt injection: «не удаляй мой email».
12. Сценарий, где rehydration разрешена.
13. Сценарий, где rehydration запрещена.

FAQ ¶

Достаточно ли regex для PII redaction? ¶

Для email, телефонов, карт и токенов regex полезен. Для имён, адресов, должностей и контекстной идентификации нужен дополнительный слой: словари, NER, rules или отдельный detection model. Но даже model-based detection нужно валидировать правилами.

Нужно ли редактировать имя пользователя? ¶

Зависит от задачи. Для ответа «Здравствуйте, Иван» имя нужно только в финальном шаблоне, не в LLM reasoning. Лучше заменить на [PERSON_1], а имя вернуть после validation.

Можно ли отправлять PII в LLM, если пользователь сам его написал? ¶

Не автоматически. Сам факт, что пользователь прислал данные, не означает, что их можно передавать внешнему AI-провайдеру. Нужна политика обработки данных, согласие/договорные основания и минимизация.

Как работать с CRM ID и order ID? ¶

Если ID сам по себе не раскрывает человека, его можно tokenized. Но если по ID можно получить профиль через tool, считайте его sensitive. Добавляйте access control и audit.

Что делать, если пользователь просит обработать документ с PII? ¶

Сначала классифицировать документ. Если задача возможна на redacted version — редактировать. Если смысл потеряется, отправить на human review или использовать разрешённый secure processing path.

Нужно ли удалять PII из embeddings? ¶

Да. Если персональные данные попали в embeddings/vector store, их сложнее контролировать и удалять. Лучше редактировать до ingestion.

Как не сломать качество поддержки? ¶

Оставляйте роли и типы данных: [PERSON_1], [EMAIL_1], [ORDER_ID_1], [DATE_1]. Модель должна понимать структуру запроса, но не реальные значения.

Что делать при обнаружении API key в тексте? ¶

Не просто redact. Это security incident: остановить workflow, не отправлять ключ в LLM, уведомить владельца, отозвать ключ, проверить логи, заменить credential.

Где хранить mapping placeholders? ¶

В защищённом хранилище с коротким retention и доступом только нужной ветке workflow. Не храните mapping в обычных execution outputs, Slack, Google Sheets без контроля доступа.

Можно ли rehydrate ответ автоматически? ¶

Можно только для low-risk шаблонов и после validation. Для платежей, аккаунтов, юридических/медицинских данных и изменения персональных данных нужен approval.