Безопасность данных в чат-боте: что нужно знать бизнесу

Сергей Полухин · CTO и сооснователь PapAI · 9 марта 2026

Задавать вопрос «безопасно ли это?» абстрактно бессмысленно — ответ распадается на две разные части: что устроено безопасно на уровне платформы, а что зависит от того, как сам бизнес обращается с доступом и данными клиентов. Ниже — без сертификатов, которых никто не выдавал, и без формулировок, которые звучат солиднее, чем есть на самом деле.

Вход без пароля — это не мелочь

Вход в конструктор устроен через одноразовую ссылку на почту, а не через пароль. У этого решения есть побочный эффект, о котором редко думают: паролей, которые можно украсть, забыть, переиспользовать в десяти сервисах или слить через фишинг — здесь просто нет ни у кого, ни у владельца бизнеса, ни у оператора. Это не гарантия от любых проблем с доступом, но снимает целый класс типичных инцидентов ещё до того, как они могли бы случиться.

Данные одного бота не смешиваются с данными другого

У каждого бота в конструкторе — свой собственный ключ на движке, где он на самом деле работает, и своя изолированная история диалогов. Технически это значит, что переписка клиентов одного бизнеса физически не пересекается с перепиской другого, даже если оба бота работают на одной и той же инфраструктуре: изоляция происходит не на уровне договорённостей, а на уровне того, как устроены данные внутри платформы.

Где физически лежат данные

Инфраструктура, на которой работает конструктор, размещена в России. Для бизнеса, который и так должен думать о требованиях к обработке персональных данных клиентов, — см. отдельную статью про 152-ФЗ — это довольно значимая деталь сама по себе, отдельно от вопроса безопасности как такового.

Честно: у платформы нет и здесь не заявляются какие-либо формальные сертификаты безопасности, результаты независимого аудита или пентеста — ничего из этого мы не проходили и не станем утверждать обратное только ради солидности текста. Три факта выше — беспарольный вход, изоляция данных между ботами и размещение инфраструктуры в России — реальны и проверяемы, и именно на них стоит опираться, а не на общие фразы про «надёжность» и «защищённость», которые ничего конкретного не говорят.

А что зависит уже не от платформы, а от вас

Кто имеет доступ к CRM-вкладке бота. Там видна вся переписка с клиентами — и это такой же чувствительный доступ, как доступ к почте компании или к CRM. Давать его стоит так же избирательно, а не всем подряд «на всякий случай».
Как передаётся сам доступ. Магическая ссылка приходит на почту конкретного человека — делиться этой ссылкой или пересылать её коллеге вместо того, чтобы завести отдельный вход, обнуляет часть смысла беспарольной модели.
Что вы просите бота спрашивать у клиента. Поведение бота задаётся текстом описания задачи — значит, ровно вы решаете, спрашивает ли бот только то, что нужно для дела, или заодно собирает данные, которые ему не были нужны, а вам потом придётся объяснять, зачем вы их вообще хранили.

Пример: уволился сотрудник

Администратор, у которого была своя ссылка для входа в CRM-вкладку бота, уволился. Магическая ссылка привязана к его конкретной почте — если эта почта у компании больше не под контролем (например, была личной, а не корпоративной), доступ к ней стоит считать скомпрометированным так же, как считали бы скомпрометированным пароль в обычной системе. Платформа здесь не может знать, что сотрудник уволился, — это ровно тот случай, когда «кто имеет доступ» и «как передаётся ссылка» из списка выше перестают быть отвлечённой рекомендацией и становятся конкретной задачей: завести новую ссылку на корпоративную почту и не полагаться на то, что старая просто забудется.

Итог

Платформенная безопасность и дисциплина внутри компании — две разные вещи, и одна не заменяет другую. Беспарольный вход, изоляция данных между ботами и размещение в России — то, что уже устроено безопасно по умолчанию. Кто получает доступ к чатам, как передаётся ссылка для входа и что именно бот просит у клиента, — то, за чем всё равно должен следить сам бизнес, и никакая платформа не сделает это решение за вас.