Защита данных в Staqflow: маскирование ПДн и секретов в workflow
Сообщения клиентов, заявки и выгрузки могут содержать телефоны, паспортные данные, номера карт или ключи доступа. При автоматизации эти сведения переходят в CRM, ИИ-модель, журнал и общие каналы. Узел «Защита данных» — Guardrails в английском интерфейсе Staqflow — позволяет проверить текст до следующего шага: составить отчёт, направить элемент на разбор или заменить чувствительные значения метками. Ниже — возможности и ограничения из публикации Staqflow от 6 ноября 2026 года.
Три действия: найти, проверить и замаскировать
Узел распознаёт более двадцати видов персональных данных и секретов. Основной поиск выполняют правила на сервере Staqflow: для этой проверки не используется модель и не выполняются внешние запросы. При необходимости можно дополнительно подключить модель чата, в том числе локальную.
Действие «Найти» добавляет к элементу отчёт с обнаруженными значениями. Оно подходит для обследования данных, например выгрузки из CRM. Действие «Проверить» разделяет поток между выходами «Чисто» и «Найдено». Ко второму можно подключить уведомление ответственному и дальнейший ручной разбор. Действие «Замаскировать» заменяет обнаруженные значения в тексте, после чего передаёт элемент дальше.
Область проверки выбирается отдельно: весь элемент, включая вложенные поля, либо текст, заданный выражением. Например, {{ $json.body }} передаёт содержимое поля body. При проверке всего элемента отчёт содержит путь к полю с находкой. Файлы передаются дальше без изменений: для проверки скана или PDF сначала нужно извлечь текст.
Какие персональные данные и секреты распознаются
Каждый тип включается отдельным переключателем. Большинство типов активны сразу; часть проверок с повышенным риском ложных срабатываний по умолчанию отключена. Набор нужно согласовать с назначением процесса: не всякая ссылка или имя в конкретном потоке требует остановки.
Контакты, ФИО и документы
В список входят e-mail, телефоны, ФИО, ники мессенджеров и ссылки t.me. Телефоны с «+» распознаются для любой страны. Для номеров без «+» доступны форматы двенадцати стран, включая Россию, Казахстан, Грузию и Молдову; список настраивается. По умолчанию выбраны Россия, Казахстан, Узбекистан и Беларусь.
Имена и отчества сопоставляются со словарём русских, среднеазиатских и кавказских имён с учётом падежей. Фамилия считается находкой, если рядом есть имя или инициалы. Собственный список фамилий, например список сотрудников из предыдущего узла, позволяет находить их и без соседнего имени.
Поддерживаются паспорт РФ, СНИЛС, ИНН, ОГРН, ИИН и БИН Казахстана, ПИНФЛ и паспорт Узбекистана, личный номер Беларуси. Для большинства номеров документов нужен контекст: соответствующее слово рядом либо подходящее имя поля, например inn. Исключения — ИНН из 12 цифр и СНИЛС в характерном формате: они определяются по номеру и контрольной сумме.
Платёжные реквизиты
Банковские карты проверяются алгоритмом Луна, IBAN — по длине для страны и контрольной сумме. Также распознаются расчётные счета, БИК и криптокошельки. Для типов с контрольной суммой её несовпадение исключает находку. Это помогает отличать реквизиты от случайных длинных чисел и номеров заказов, но не подтверждает принадлежность или действительность счёта.
Пароли, ключи и инфраструктура
Поиск секретов учитывает контекст: пароль после «пароль:» или «pwd=», а также конструкцию user:pass@host. Узел распознаёт API-ключи по префиксам сервисов, токены Telegram-ботов, JWT, приватные ключи и строки подключения PostgreSQL, MySQL, MongoDB и Redis.
Для ключей без известных префиксов предусмотрен поиск случайных строк по энтропии — оценке характера последовательности. Есть три уровня чувствительности. Эта проверка по умолчанию выключена: идентификаторы и хеши тоже могут выглядеть случайными. При включении в источнике рекомендуется начинать со сбалансированного уровня.
К инфраструктурным данным относятся IP- и MAC-адреса, порты, внутренние хосты в зонах .local, .corp и .internal, а также в указанных пользователем доменах. Распознаются сетевые и файловые пути, логины вида ДОМЕН\логин, записи Active Directory и ID AnyDesk, TeamViewer, RustDesk.
Можно добавить собственные слова и фразы: названия внутренних проектов, кодовые имена и другие чувствительные обозначения. Регистр не влияет на поиск. Для ссылок предусмотрен список разрешённых доменов: ссылки на указанные ресурсы не считаются находками. HTML тоже разбирается: проверка учитывает адреса, разделённые тегами, и кириллицу в HTML-сущностях.
Режимы маскирования: метка, частичная замена и хеш
В режиме «Метка вида» значение превращается в обозначение категории: <EMAIL>, <PHONE> или <CARD>. Получатель видит, какие сведения были в сообщении, без их исходного содержимого. Например, ИИ-агенту для разбора причины отказа оплаты может быть достаточно указания, что клиент прислал карту.
Частичная замена оставляет фрагмент значения: i***@mail.ru, +7 *** ***-**-67, **** **** **** 1234. ФИО сокращается до инициалов. Такой режим применим, например, когда оператору нужно сверить последние цифры. Пароли, ключи и логины даже здесь полностью заменяются меткой.
В режиме «Хеш» одно значение получает одинаковую метку в разных элементах, например <EMAIL:3f9a1c0b2e>. Это позволяет группировать обращения по одному адресу, не сохраняя адрес в обработанном тексте. Хеш является псевдонимом, а не шифрованием: телефон с ограниченным множеством вариантов можно подобрать перебором. Рассматривать такой результат как гарантию обезличивания нельзя.
Замена необратима: узел не хранит таблицу соответствия исходных значений и меток. Если оригинал нужен дальше, его следует сохранить до маскирования, например в отдельной ветке процесса, и определить доступ к этой копии.
Дополнительная проверка моделью и локальный контур
Правила подходят для формализованных значений. Для адресов доставки, дат рождения, диагнозов, сумм сделок или иных сведений можно включить «Дополнительно проверять моделью». В поле «Что ещё считать чувствительным» задаётся описание, например номера договоров или диагнозы; снизу подключается узел модели чата.
В модели чата есть вариант «Своя или совместимая с OpenAI»: через него можно подключить Ollama, vLLM, LM Studio, LiteLLM или другой сервер с тем же протоколом. Если модель работает на сервере компании, текст не передаётся стороннему провайдеру моделей. Для полностью внутреннего контура сам Staqflow также нужно разместить в своей сети. Развёртывание описано в материале о Staqflow on-premise.
Текст передаётся модели фрагментами до 12 000 символов — ориентировочно 3–4 тысячи токенов. Модель должна поддерживать вызов инструментов, или function calling: именно через этот механизм узел принимает ответ. Для узкой задачи поиска дословных фрагментов можно рассмотреть небольшую открытую модель с коротким контекстом. Перед выбором в источнике предлагается проверить около десяти реальных текстов и оценить отчёт; подходящую модель определяют по своим данным.
Перед обращением к модели значения, уже найденные правилами, заменяются метками. Поэтому даже облачная модель получает текст без этих значений. Остальные сведения остаются в передаваемом фрагменте: этот механизм не означает, что всё чувствительное уже распознано.
Модель должна вернуть дословные цитаты. Узел сверяет их с исходным текстом; цитата, которой там нет, отбрасывается. Такая проверка защищает от маскирования выдуманного фрагмента, но сама по себе не доказывает полноту распознавания.
Если модель не отвечает, можно остановить узел либо продолжить выполнение с отметкой в отчёте. Для действия «Проверить» такой элемент направляется в «Найдено».
Неполная проверка: complete: false и <NOT_CHECKED>
Превышение лимита текста, времени проверки или незавершённый просмотр моделью не приравниваются к отсутствию находок. В отчёте появляется complete: false с причиной. Действие «Проверить» отправляет элемент в «Найдено», а «Замаскировать» заменяет непроверенный хвост меткой <NOT_CHECKED>.
В «Параметрах» настраиваются размер текста на элемент, количество находок и время обработки элемента. Размер по умолчанию — 5 миллионов символов. Значение лимита и поведение при ошибке нужно проверить до подключения узла к рабочему потоку.
Как подключить защиту данных к процессу
- Разместить узел после источника текста: вебхука формы, Telegram или почты. Поставить его до отправки в модель, общий канал или внешний журнал.
- Выбрать «Проверить» и область «Весь элемент» для первоначального обследования потока.
- Настроить типы данных: отключить проверки сведений, допустимых в этом процессе, и добавить свои фамилии, внутренние домены и слова при необходимости.
- Соединить «Чисто» с основной веткой, «Найдено» — с уведомлением ответственному или другим действием для разбора.
- Выполнить пробные запуски на нескольких реальных сообщениях с разрешённым доступом и изучить отчёт guardrails. Проверить находки, пути полей и полноту обработки.
Для практической проверки полезны разные случаи: текст без чувствительных сведений, несколько типов в одном сообщении, вложенные поля, HTML, превышение заданного лимита и недоступная модель. Оценивать нужно и пропуски, и ложные срабатывания, а также выход, в который направляется элемент.
Примеры применения в поддержке, журналах и документах
Перед ИИ-агентом или узлом модели можно маскировать сообщение поддержки метками категорий. Это сохраняет контекст обращения, сокращая передачу обнаруженных значений. Например, вместо номера карты модель получает <CARD>. Место узла в workflow определяет, какие дальнейшие системы увидят очищенный вариант.
Перед общей перепиской или задачей в трекере с доступом подрядчиков подходит разделение «Чисто» / «Найдено»: обращения с находками остаются на разборе у ответственного. Перед записью данных запросов и ошибок в журнал можно заменять пароли, токены и строки подключения. Это уменьшает риск передачи обнаруженного секрета в журнал; уже существующие копии автоматически не исчезают.
При аудите CRM, таблицы или базы действие «Найти» показывает, какие значения и где обнаружены. Сводка summary группирует число находок по видам и может использоваться в отчёте. Для договоров и анкет сначала применяют распознавание документов, затем проверяют извлечённый текст. Сам файл скана при этом остаётся неизменным.
Сборку проверки можно поручить ИИ-клиенту через MCP: например, добавить маскирование перед моделью и проверку перед общим каналом. После сборки нужно проверить соединения, настройки и результаты; каталог интеграций помогает определить, какие системы получают текст из процесса.
Что сохраняется в истории и где границы защиты
Действие «Найти» всегда включает найденные значения в отчёт. Отчёт сохраняется в истории запусков, поэтому обследование само создаёт место, где чувствительные сведения доступны. Для «Проверить» и «Замаскировать» значения по умолчанию не включаются: остаются тип, поле и позиция. Включать значения следует лишь при обоснованной необходимости дальнейшей обработки.
Проверка текста не заменяет разграничение доступа и правила работы с персональными данными. Её нужно сочетать с выбором допустимых каналов передачи, размещением платформы и модели, проверкой результатов и доступом к истории. Секреты интеграций и обычный выход узла — разные механизмы; это разобрано в статье о хранении учётных данных Staqflow.
Подробнее о возможностях автоматизации — на сайте Staqflow.