Облачный конструктор сценариев видит всё, что через него проходит, и хранит это дольше, чем думает большинство его пользователей. В журнале прогонов лежит не строчка «сценарий отработал», а тело каждого запроса целиком: текст письма клиента, его телефон, сумма сделки, содержимое вложения. Типовой срок хранения на массовых тарифах — от 7 до 30 дней, на старших до 90; вложения в файловом хранилище площадки переживают и сам сценарий.
Это не изъян платформ, а условие их работы: без сохранённых значений нельзя ни повторить упавший прогон, ни понять, почему в CRM попало не то. Проблема возникает там, где компания об этом не знает и пропускает через облако то, что пропускать нельзя. Утечка в таком контуре происходит не через взлом сценария, а буднично: через доступ к панели платформы у уволенного сотрудника, через экспорт сценария с ключом внутри, через журнал прогонов, открытый всей команде.
Ниже — что именно остаётся в облаке и на какой срок, светофор полей, приём с маскированием и передачей по ссылке, правила обращения с ключами и перечень пунктов, без которых поручение обработки не закрывает 152-ФЗ. И расчёт, во сколько обходится привести всё это в порядок.
Что платформа хранит по умолчанию
Первое действие при аудите — открыть журнал любого вчерашнего прогона и посмотреть на него глазами постороннего. Обычно этого достаточно: в развёрнутом виде там окажется переписка с клиентом, его номер телефона и сумма сделки. Второе действие — найти в настройках тарифа срок хранения журналов и записать его числом.
| Что остаётся в облаке | Где именно | Типовой срок | Чем это опасно |
|---|---|---|---|
| Тело входящего запроса: письмо целиком, поля формы, текст сообщения | Журнал прогонов | 7–30 дней, на старших тарифах до 90 | Переписка с клиентом лежит вне вашего периметра и доступна всем, у кого есть вход в панель |
| Значения на входе и выходе каждого узла | Журнал прогонов | Столько же | Телефон, адрес и сумма видны в открытом виде, даже если в CRM они скрыты правами |
| Вложения: счета, акты, фотографии, сканы | Файловое хранилище площадки | Часто до ручного удаления | Файл переживает сценарий: удаление сценария не удаляет то, что он успел загрузить |
| Ключи и токены доступа к вашим системам | Раздел учётных данных | Бессрочно, до ручного отзыва | Ключ от CRM и от 1С физически хранится у площадки, а не у вас |
| Прогоны, завершившиеся ошибкой | Очередь необработанного | Обычно дольше успешных | Самые «грязные» данные — недоразобранные письма и сбойные заявки — хранятся дольше всего |
Карта связей. Слева блок «источник: почта, форма, чат», стрелка в центральный блок «облачная платформа: сценарий из 11 узлов», из него стрелка вправо в блок «ваша CRM и 1С». Вниз от центрального блока три отвода в прямоугольники: «журнал прогонов — тела запросов, 7–30 дней», «файловое хранилище — вложения, до ручного удаления», «учётные данные — ключи к вашим системам, бессрочно». Пунктирной рамкой обведены три отвода с подписью «остаётся у площадки». Чертёжный стиль, подписи по-русски.
Светофор полей: что пропускать можно, а что нельзя вовсе
Дальше разбирается не сценарий, а данные. Возьмите список полей, которые сценарий реально трогает, и разложите их на три группы. Правило простое: чем тяжелее последствия утечки конкретного поля, тем меньше оно должно появляться в теле запроса.
| Группа | Примеры полей | Как обращаться в облачном сценарии |
|---|---|---|
| Зелёные | Номер заявки, статус, срок, идентификатор клиента, сумма без реквизитов, артикул, склад | Пропускать свободно — по отдельности эти поля не идентифицируют человека |
| Жёлтые | ФИО, телефон, электронная почта, адрес доставки, текст обращения клиента | Пропускать можно при наличии поручения обработки; в журнале — маскированно, срок хранения сокращён до минимума тарифа |
| Красные | Паспортные данные, СНИЛС, сведения о здоровье и диагнозы, платёжные реквизиты и полные номера карт, биометрия, сведения о судимости | Через облако не пропускать: передавать идентификатор записи и ссылку, значение оставлять в своём контуре |
Приём, который закрывает большую часть жёлтой зоны и всю красную, называется передачей по ссылке. Сценарий получает не документ и не значение, а идентификатор записи в вашей системе и одноразовую ссылку на неё. В журнале прогонов остаётся строка вида «заявка 48213, телефон +7 916 *--00, ответственный назначен» — по ней можно разобрать сбой, но нельзя восстановить ни номер, ни содержание. На стороне вашей системы этот приём стоит дополнительного узла и часа работы на сценарий. Так же устроены наши решения, которые работают с перепиской клиентов: и обработка электронной почты, и классификация обращений отдают наружу признаки и идентификатор, а само письмо остаётся в контуре заказчика.
Две карточки рядом, стиль абстрактного экрана. Левая с заголовком «как обычно»: строки «телефон: +7 916 000-00-00», «письмо: полный текст, 1 400 знаков», «скан паспорта: вложение 2,3 МБ», под ней красная плашка «всё это остаётся в журнале 7–30 дней». Правая с заголовком «через ссылку»: строки «заявка: 48213», «телефон: +7 916 ***-**-00», «документ: ссылка, действует 15 минут», под ней зелёная плашка «в журнале ничего восстановимого». Между карточками стрелка с подписью «плюс один узел, около часа работы на сценарий». Подписи по-русски.
Ключи доступа: где хранить и что делать при увольнении
Ключ к CRM или к базе 1С даёт больше, чем любой отдельный прогон: он открывает всю базу целиком. Поэтому обращение с ключами — отдельная процедура, а не деталь настройки.
Самая частая ошибка сборки — вписать токен прямо в поле узла HTTP-запроса вместо раздела учётных данных. Такой токен видно дважды: в журнале каждого прогона и в файле экспорта сценария. Сотрудник, который выгрузил сценарий «чтобы посмотреть дома», унёс вместе с ним действующий ключ к вашей CRM, и при увольнении вы этого не заметите — доступ к панели вы отзовёте, а ключ останется рабочим. Проверяется за десять минут: поиск по словам token, key, Bearer в теле всех сценариев.
- 1Все ключи — только в разделе учётных данных площадки, ни одного в теле узла. В узлах остаются ссылки на запись, а не значения.
- 2Для каждой интеграции — отдельный служебный пользователь в целевой системе с минимальными правами, а не личная учётная запись сотрудника. Уволился человек — его учётка гаснет, а сценарии продолжают работать.
- 3Плановая ротация раз в 6–12 месяцев и внеплановая — при увольнении любого, кто имел доступ к панели, и при подозрении на утечку.
- 4Процедура вывода сотрудника: снять доступ к платформе, ротировать ключи, которые он видел, проверить журнал экспортов сценариев за последний месяц. Три шага, полчаса работы, и делать их надо в день увольнения, а не в отчётный период.
- 5Второй человек с полным доступом. Один владелец сценариев — это отпуск, болезнь и увольнение, во время которых чинить некому. Двое — это уже процедура, а не зависимость от конкретного человека.
Поручение обработки: что должно быть в договоре с площадкой
Как только через сценарий проходят ФИО, телефон или адрес клиента, площадка становится обработчиком персональных данных по вашему поручению, а вы остаётесь оператором и отвечаете перед субъектом. Оформляется это по ч. 3 ст. 6 152-ФЗ отдельным документом или разделом договора. Публичной оферты «мы соблюдаем законодательство» для этого недостаточно.
- Перечень действий с данными и цель обработки — не общими словами, а списком: приём, передача, хранение в журнале, удаление.
- Категории данных и категории субъектов: чьи данные и какие именно поля идут через сценарии.
- Срок хранения журналов прогонов числом. Это единственный пункт, который читатели договора пропускают чаще всего, а он определяет, сколько дней ваши данные живут вне периметра.
- Обязанность соблюдать конфиденциальность и применять меры защиты по ст. 19 152-ФЗ, с перечислением мер, а не отсылкой к ней.
- Обязанность уведомить вас об инциденте в срок, который позволяет вам самим уложиться в 24 часа на первое уведомление в Роскомнадзор и 72 часа на результаты внутреннего расследования. Если площадка обещает сообщить «в разумный срок», ваши сутки уже потрачены.
- Порядок удаления данных при расторжении договора и письменное подтверждение удаления. Сюда же — что происходит, если площадка сама прекращает работу в России: кто и в какой срок отдаёт вам выгрузку и уничтожает копии.
- Место размещения серверов и запрет на трансграничную передачу. Для данных граждан РФ базы должны находиться в России — ч. 5 ст. 18 152-ФЗ.
Требование локализации сужает выбор ещё до сравнения функций. На сентябрь 2026 года у Albato российское юридическое лицо и серверы в РФ, ApiX-Drive присутствует в реестре отечественного ПО Минцифры, Nodul — российская платформа. Установка n8n на собственном сервере закрывает локализацию, но остаётся зарубежным открытым продуктом и требование к отечественному ПО не закрывает — для госзаказчика это блокер. Различия площадок по этому и восьми другим параметрам мы разобрали в сравнении Albato, ApiX-Drive и Nodul, а устройство собственного контура — в материале про n8n на своём сервере.
Сколько стоит привести контур в порядок
Работа разовая и обозримая. Ниже — смета для компании с парком из 15 действующих сценариев, из которых 8 трогают персональные данные клиентов. Ставка инженера — 3 000 ₽ в час.
Сравнивать эту сумму стоит не с абстрактным риском. По КоАП в редакции, действующей с 30 мая 2025 года, утечка персональных данных от 1 000 до 10 000 субъектов обходится юридическому лицу в 3–5 млн ₽, а повторное нарушение переводит штраф в оборотный. Минимальная граница в 28 раз больше всей сметы. Точные размеры и составы меняются, поэтому перед тем, как ссылаться на конкретные суммы в служебной записке, сверьтесь с действующей редакцией — это инженерный материал, а не юридическая консультация.
Когда облачный конструктор не подходит вовсе
Есть случаи, в которых никакое маскирование не помогает и выбор сужается до собственного сервера или собственного сервиса. Проверять их надо до подписания договора с площадкой, а не после первого прогона.
- Специальные категории данных в самом предмете процесса. Клиники, лаборатории, психологические центры: там диагноз или направление — это и есть содержание заявки, вынести его по ссылке нельзя, потому что без него сценарий не работает.
- Биометрия и распознавание лиц. Отдельный режим обработки с письменным согласием на каждого субъекта; облачный конструктор в этой схеме — лишнее звено, которое придётся отдельно описывать и защищать.
- Требование заказчика к отечественному ПО из реестра. В госзаказе и у части крупных компаний оно жёсткое: локализации серверов недостаточно, нужна запись в реестре Минцифры. Это отсекает часть площадок сразу.
- Площадка не даёт поручения обработки. Если в ответ на просьбу подписать поручение приходит ссылка на публичную оферту, дальше идти некуда: юридически вы останетесь единственным ответственным за данные, которые физически лежат не у вас.
Во всех остальных случаях облачный конструктор — рабочий и законный инструмент, вопрос только в дисциплине: знать срок хранения журналов, держать красные поля вне облака, хранить ключи в предназначенном для этого месте и вывести из системы уволенного в тот же день. Тридцать шесть часов один раз и полчаса на каждое увольнение — это вся цена вопроса. С чего начинать разбор данных до внедрения, мы описали отдельно в материале про данные перед внедрением, а требования, которые мы предъявляем к собственным проектам, собраны на странице о безопасности.
