Персональные данные и ИИ в поддержке: что проверить до запуска

На внутреннем созвоне обычно спорят не о персональных данных. Спорят о другом: «Давайте включим ИИ на типовые вопросы, там ничего опасного». Потом открывают пять реальных обращений — и в каждом есть телефон, почта, номер заказа, адрес доставки или имя ребёнка, если это школа.

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

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

Сначала посмотрите, какие данные реально живут в обращениях

Персональные данные в поддержке редко лежат аккуратно в одном поле «телефон». Они размазаны по переписке: клиент подписался именем, переслал чек, написал номер карты для возврата, приложил скрин личного кабинета, продублировал email «на всякий случай».

Если ИИ подключают к живым обращениям, важно пройтись не по регламенту, а по фактическим диалогам. Возьмите 20–30 последних обращений из разных каналов: почта, чат, Telegram, форма на сайте. Не выбирайте красивые примеры для демо. Нужны обычные, немного грязные переписки.

Отметьте, какие данные встречаются чаще всего:

• имя клиента;
• email и телефон;
• адреса доставки или оказания услуги;
• номера заказов, договоров, счетов;
• платёжные данные, если клиенты их присылают;
• документы и скриншоты;
• внутренние комментарии операторов.

Отдельно посмотрите, какие данные действительно нужны для ответа. Чтобы объяснить правила возврата, ассистенту обычно не нужен номер карты. Чтобы подсказать, где найти акт, не нужен паспорт. А вот оператору для конкретного действия в системе данные могут понадобиться.

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

Обезличивание важно проверить до первого теста

Самая частая ошибка — обсуждать качество ответов раньше потока данных. Команда сначала смотрит, «как красиво ИИ формулирует», а потом выясняет, что в модель уходят имена, телефоны и реквизиты из исходного сообщения.

Проверка должна начинаться с простого вопроса: что происходит с текстом обращения перед автоматической ИИ-обработкой. Если в сообщении есть email, телефон, номер карты, номер счёта или имя клиента, должны быть понятны правила: что заменяется на плейсхолдеры, на каком этапе это происходит и что видит модель.

Плейсхолдер — не украшение для отчёта. Он должен сохранять смысл обращения без лишних деталей. Например, оператору и ассистенту важно понять, что клиент оставил контакт для связи. Но самому ИИ не всегда нужен конкретный адрес почты. Достаточно отметки вроде «email клиента».

У обезличивания есть цена. Иногда без точного значения нельзя выполнить действие: проверить заказ, найти оплату, изменить запись. Значит, такие сценарии нельзя маскировать под «бот сам всё решит». Ассистент может объяснить порядок действий или подготовить черновик, но само действие остаётся у человека или в отдельной системе с понятными правами доступа.

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

Доступ к перепискам нельзя оставлять «как-нибудь потом»

ИИ — не единственный риск. До автоматизации у поддержки часто уже есть проблема: слишком много людей видят слишком много переписок. На старте всем выдали права администратора, потому что так быстрее. Потом команда выросла, появились стажёры, подрядчики, менеджеры продаж, бухгалтерия — и никто не помнит, кто может открыть историю клиента.

Перед запуском ИИ стоит пересмотреть роли. Не в духе «мы всем доверяем», а практически: кому нужна очередь обращений, кому настройки каналов, кому база знаний, кому отчёты, кому экспорт. Если человек отвечает только за Telegram, ему не обязательно видеть все письма за два года. Если сотрудник пишет статьи справки, ему не всегда нужны настройки интеграций.

Особенно аккуратно стоит обращаться с внутренними заметками. Команды иногда пишут туда то, что не рискнули бы отправить клиенту: догадки, раздражение, оценки, лишние подробности. Это не становится безопасным только потому, что заметка «внутренняя». Если она хранится рядом с обращением, её тоже может увидеть тот, у кого есть доступ к истории. Про границу между ответом и служебной записью мы уже писали в разборе про внутренние заметки в поддержке.

Цена нормальных прав доступа — больше администрирования. Придётся заводить роли, объяснять команде, почему часть экранов пропала, и иногда разбирать просьбы «дайте мне всё, мне так удобнее». Зато при споре или ошибке будет меньше ситуаций, где доступ был у всех, а ответственность ни у кого.

Должно быть видно, кто что сделал

Когда ИИ появляется в поддержке, команда начинает жить в новом режиме. Ответ мог написать оператор. Черновик мог подготовить ассистент. Настройку мог поменять администратор. Порог уверенности могли поднять перед выходными, а в понедельник никто уже не помнит, кто и зачем это сделал.

Поэтому до запуска нужен журнал действий. Не ради слежки за людьми, а ради нормальной разборки инцидентов. Если клиент жалуется на неверный ответ, вам нужно понять цепочку: откуда взялся текст, кто его отправил, был ли это автоответ, какая статья базы знаний использовалась, менялись ли настройки канала.

Отдельно проверьте, как помечаются ИИ-ответы. Клиенту не стоит угадывать, с кем он говорит. Команде тем более. В ленте обращений должно быть видно, где ответил ассистент, а где человек проверил и отправил черновик. Иначе любая ошибка превращается в спор по памяти: «я такого не писал», «бот сам отправил», «наверное, кто-то нажал не туда».

Эта прозрачность не отменяет доверия к команде. Она просто убирает серую зону. Если ИИ помогает, это видно. Если ошибся источник в базе знаний, это тоже видно. Если оператор отправил черновик без проверки, разговор становится предметным. Мы уже разбирали, почему важно не прятать, кто ответил клиенту — человек или ассистент.

Границы автоматизации лучше задать по каналам

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

Поэтому до запуска полезно решить не «включаем ИИ или нет», а где он отвечает сам, а где только помогает оператору. Для одного канала допустим автоответ по базе знаний. Для другого безопаснее черновик, который человек прочитает и отправит сам. Это не непоследовательность, а нормальная настройка под цену ошибки. Подробно эту границу мы разбирали в статье про то, где уместен черновик оператору, а где ответ клиенту.

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

Порог автоматизации придётся менять. После первых недель станет видно, где бот молчит слишком часто, а где, наоборот, берёт вопросы с недостаточной опорой. Это нормальная работа, а не провал запуска. Плохой признак — когда настройки никто не пересматривает, потому что «один раз включили и забыли».

В DeskAI перед автоматической ИИ-обработкой текст обращения обезличивается: email, телефоны, номера карт и счетов, имя клиента заменяются на плейсхолдеры; доступ разграничивается ролями и точечными правами, значимые действия фиксируются в журнале аудита, а ИИ-ответы помечаются в переписке и ленте обращений.

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