Записи разговоров слушают все менеджеры. Это не доступ, а дыра

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

Голосовой агент не создаёт новую проблему, он увеличивает старую. Раньше расшифровывали выборку звонков, теперь есть текст каждого диалога и поиск по нему. Архив, который никто не открывал из-за неудобства, превращается в базу, где за минуту находится место, где клиент продиктовал адрес, сумму или номер документа.

Ответ на вопрос «кто может слушать» состоит из трёх частей: где данные физически лежат, роли с разными правами, журнал обращений. Без третьей части первые две недоказуемы.

За один звонок возникает пять разных объектов, а не один

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

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

Кто должен иметь доступ к записям разговоров

«Все менеджеры видят все звонки» — это не щедрость, а отсутствие настройки. Менеджеру нужны разговоры по его сделкам, а не архив компании: чужие звонки не помогают закрыть свою сделку, но увеличивают число людей, способных вынести базу к конкуренту. Разумная рамка — четыре уровня.

• Менеджер — записи и транскрипты только по сделкам, которые ведёт он. Права даёт CRM, а не устная договорённость.
• Супервизор и контроль качества — записи своей команды или очереди. Это те, кому прослушивание нужно ежедневно.
• Аналитик — агрегаты и выборки, по возможности обезличенные. Для оценки сценария редко нужны имя и номер телефона.
• Администратор — управление правами, но не доступ к содержанию разговоров по умолчанию.

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

Прослушивание при этом не блажь: агента приходится проверять постоянно. Миф «ИИ понимает как человек» разбивается об измеренную консистентность: по данным препринта τ-bench (Sierra и Принстонский университет, arXiv:2406.12045), GPT-4o решает retail-задачу с первого раза примерно в 61% случаев, но при восьми прогонах той же задачи показатель падает ниже 25%. Спорные звонки будут поднимать регулярно. Вопрос не в том, давать ли доступ, а в том, кому и с каким следом.

Доступ подрядчика — это не доступ сотрудника

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

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

Ответственность при этом не делится пополам. История Air Canada: чат-бот авиакомпании сообщил пассажиру несуществующую политику возврата, суд встал на сторону пассажира и обязал компанию выполнить обещанное ботом. За слова агента отвечает бизнес, а не поставщик технологии. С данными логика та же: за утечку записей перед клиентом и регулятором отвечает компания, которая эти разговоры собрала. Регресс к подрядчику работает только в объёме, прописанном в договоре, — поэтому что проверить в договоре стоит читать до подписания, а не после инцидента.

Ограничения: чего настройка доступа не закрывает

Она не заменяет договор. Роли в CRM не описывают, что подрядчик делает с данными на своей стороне, сколько их хранит, вправе ли обучать на них модели и что происходит при расторжении. Это предмет договора, а не панели администратора.

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

Она не отменяет требований к тому, где данные лежат. 152-ФЗ требует хранить персональные данные россиян в базах на территории РФ, а записи и транскрипты — это персональные данные. Отдельный риск — трансграничная передача: по публикациям на Habr, доступ к аудио-API OpenAI и Google Gemini для российских номеров и юрлиц ограничен, и обход через прокси стал обычной практикой. Роли внутри CRM не помогают, если разговор ушёл за пределы страны в момент обработки. Базовая рамка — в статье про 152-ФЗ и запись разговоров, сроки — в материале про хранение записей разговоров.

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

Коротко

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

Если хотите разобрать, где именно в вашей схеме возникают записи и у кого к ним доступ, — можем собрать демо на вашем сценарии и пройти по цепочке вместе.