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

Чат-бот — сотрудник, который видит больше всего данных

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

Этот материал — практическая рамка безопасности данных при интеграции чат-бота: карта рисков, принцип минимума данных, права доступа, работа с персональными данными, срок хранения, журнал действий и вопросы к поставщику. Что бот может говорить и делать (guardrails), — отдельная тема; здесь речь о защите самих данных. Юридические требования у каждой компании свои и должны проверяться вашим юристом.

Карта рисков: где находятся данные

1. 1Сам диалогВсё, что пишет клиент, включая то, чего писать не следовало: номер карты, фото документа, подробности о здоровье.
2. 2База знанийМатериалы, по которым отвечает бот. Сюда по ошибке может попасть внутренний документ — маржа, номера сотрудников, условия договоров.
3. 3ИнтеграцииCRM, система заказов, статус оплаты. Чем больше систем подключено к боту, тем больше последствия ошибки в настройке.
4. 4Выгрузки и отчётыВыгрузки в Excel, аналитика, отчёты по почте — данные покидают систему.
5. 5ЛюдиОператоры, менеджеры, техническая команда, поддержка поставщика — кто что видит?

Принцип минимума данных

Самые безопасные данные — те, которые не собирали. По каждому полю один вопрос: это действительно нужно для следующего шага?

• Для лида нужны имя и телефон; дата рождения и домашний адрес обычно нет
• Для вопроса о статусе хватает номера заказа и поля проверки; показывать полный адрес не нужно
• Бот не должен запрашивать данные карты, пароли, номера документов
• Если клиент сам написал чувствительные данные, бот не должен их повторять или переносить в другие поля
• Поля, которые бот читает через интеграцию, тоже должны быть минимальными — не вся карточка клиента

Права доступа

Кто что видит — самая часто забываемая часть безопасности.

• Доступ по ролям: оператор видит диалоги, менеджер — лиды, руководитель — отчёты; не все видят всё
• В интеграциях у бота должно быть право только на чтение, а запись — только в нужные поля
• Доступ уволившегося сотрудника должен закрываться сразу
• Команда поставщика должна смотреть ваши данные только при необходимости техподдержки
• Действия в аккаунте — кто что изменил — должны журналироваться

В Vexvon права доступа управляются на уровне пользователей и ролей, доступ удалённого из аккаунта пользователя закрывается сразу, а действия фиксируются; эти правила описаны на странице безопасности.

Персональные данные (PII)

1. 1СборКакие персональные данные и с какой целью собираются, должно быть записано.
2. 2ИспользованиеДанные используются только для этой цели — работы сервиса. Для маркетинга нужно отдельное согласие.
3. 3РазделениеДанные одной компании должны храниться отдельно от данных других клиентов.
4. 4ПередачаДанные передаются по зашифрованному каналу (HTTPS/TLS).
5. 5Обучение моделейДиалоги и документы компании не должны использоваться для обучения общих AI-моделей — это вопрос, который нужно письменно задать поставщику.

Срок хранения и удаление

• Сколько хранятся диалоги и записи — должно быть определено в договоре
• Запись конкретного клиента можно удалить по запросу
• Компания может выгрузить все свои данные
• После окончания сервиса данные удаляются через согласованный срок
• Выгруженные файлы — Excel, отчёты — тоже подчиняются правилу хранения

Безопасность интеграций

Когда бот отправляет запросы в системы компании, возникают три риска: неверный запрос, слишком много данных в ответе и попытка через бота получить доступ к другой системе.

• Бот отправляет запросы только на заранее разрешённые адреса
• API-ключи выдаются с минимальными правами и регулярно меняются
• Клиенту показывается только нужная часть ответа
• Персональные данные не возвращаются без проверки личности

В Vexvon запросы бота к API компании защищены от SSRF — ситуации, когда бота вынуждают отправить запрос во внутреннюю сеть. Сама архитектура интеграции разобрана в статье об интеграции чат-бота через API и вебхуки.

Чего бот не должен говорить

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

Как настраиваются права бота на чтение, запись и обещания, подробно разобрано в статье о guardrails AI-чат-бота.

Пример: клиент пишет номер карты

1. 1Клиент«Оплата не прошла, вот моя карта: 4169 …, срок …, код на обороте …»
2. 2Бот«В целях безопасности не пишите данные карты в чате — мы их не храним и не используем. Чтобы повторить оплату, можем прислать ссылку на защищённую страницу оплаты или передать вопрос сотруднику. Что удобнее?»
3. 3За кадромСообщение не показывается операторам полным текстом и не попадает в выгрузки и отчёты с данными карты — это правило платформа и компания должны согласовать заранее.

Если случился инцидент: первые шаги

• Кто узнаёт и кого уведомляет — заранее назначенный человек
• Какой доступ или ключ интеграции закрывается немедленно
• Как определяется, какие данные затронуты, — журналы
• Что и когда сообщается клиентам и при необходимости регулятору — вместе с юристом
• Какое правило меняется после инцидента

Этот план нужно записать на одной странице до начала проекта — план, написанный во время инцидента, всегда опаздывает.

Чек-лист для поставщика

Выбирая платформу чат-бота или подписывая договор, задайте эти вопросы письменно:

• Где хранятся наши данные и как они отделены от данных других клиентов?
• Как данные защищены при передаче и хранении?
• Используются ли наши диалоги и документы для обучения AI-моделей?
• Когда и как ваша команда может смотреть наши данные?
• На каком уровне управляются права доступа и журналируются ли действия?
• Можем ли мы сами определять срок хранения?
• Как делаются выгрузка и удаление данных и сколько времени это занимает?
• Что происходит с данными после окончания сервиса?
• Даёте ли вы письменные ответы на вопросы нашего юридического отдела?

Внутренний чек-лист перед запуском

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

Ограничения

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

Итог: о безопасности спрашивают в начале проекта

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

Как защищаются персональные данные при анализе диалогов, показано в статье об аналитике диалогов чат-бота; остальные материалы — в этой рубрике. Чтобы обсудить вопросы вашего юридического отдела, свяжитесь с нами.

Частые вопросы

1. 1Использует ли чат-бот данные клиентов для обучения AI-модели?Зависит от платформы, и это нужно спрашивать письменно. В Vexvon загруженные базы, диалоги и документы не используются для обучения общих AI-моделей.
2. 2Может ли бот принимать данные карты?Не должен. Оплата должна проходить на защищённой странице платёжного провайдера.
3. 3Можно ли удалить данные?Удаление записи конкретного клиента и удаление всех данных по окончании сервиса должны быть прописаны в договоре и выполняться по запросу.