ИИ-транскрибация совещаний и звонков: куда уходят записи переговоров
Автор: Михаил Тевс, руководитель юридической службы компании IDX (ООО «Системы управления идентификацией»)
Риски ИИ-транскрибации: куда уходят данные
Сервисы транскрибации становятся повседневным рабочим инструментом. Мы загружаем запись разговора в сервис или бот подключается к созвону, записывает разговор, а через несколько минут выдает расшифровку, краткое содержание и список задач. Экономия времени очевидна, а снятие рутины создает вау-эффект: не нужно вести протокол вручную, возвращаться к записи и искать необходимый фрагмент разговора, а если стенограмма очень важна дословно – не нужно её перепечатывать.
Но за удобным интерфейсом скрывается довольно длинный маршрут данных. Запись может последовательно пройти через платформу видеосвязи, сервер сервиса транскрибации, облачную инфраструктуру, стороннюю модель распознавания речи, языковую модель и несколько хранилищ. На каждом этапе появляются новые копии данных и новые лица, которые технически могут получить к ним доступ.
В этой статье мы не рассматриваем правовые и сопутствующие организационные требования к записи переговоров: получение согласий, соблюдение тайны связи, оформление обработки персональных данных и другие подобные вопросы. Отдельно не будем разбирать голос как биометрию, международные различия в регулировании, достоверность расшифровок и этику записи.
Нас интересует более узкий и практический вопрос: как именно «ходят» данные при транскрибации и в каких точках организация перестает их контролировать.
Транскрибация: долгий путь одного клика
Когда пользователь нажимает кнопку «Записать встречу» или разрешает боту подключиться к звонку, может показаться, что запись просто отправляется в выбранный сервис, там превращается в текст и возвращается обратно.
На практике дело обстоит обычно сложнее.
Типовой маршрут выглядит так
1. устройство или платформа видеосвязи захватывает звук;
2. аудио передается сервису транскрибации;
3. сервис размещает поток или файл в облачной инфраструктуре;
4. запись передается системе распознавания речи;
5. полученный текст обрабатывается языковой моделью;
6. результаты сохраняются в базе данных и поисковом индексе;
7. транскрипт и саммари передаются в подключенные интеграции.
Некоторые этапы могут проходить внутри одной компании. Есть сервисы, которые, наоборот, передают отдельные операции нескольким подрядчикам. Поэтому за одной и той же кнопкой «Транскрибировать» может скрываться принципиально разная техническая архитектура.
Разберем этот маршрут по шагам.
1. Первый этап: захват звука
Все начинается на устройстве пользователя или внутри платформы, на которой проводится разговор.
Это может быть:
- микрофон компьютера или телефона;
- локальная программа для записи;
- бот, подключенный к видеоконференции;
- встроенная функция Teams, Meet, Zoom или другой платформы;
- отдельное устройство в переговорной комнате.
Уже на этом этапе важно понимать, где фактически возникает первая запись.
Если разговор проходит через облачную платформу видеосвязи, ее инфраструктура в любом случае участвует в передаче аудио. Даже если транскрибация осуществляется локально на своем компьютере или сервере, сам звонок не становится локальным и доступ к его данным остается у платформы связи.
Если же записывается очная встреча на локальное устройство, а обработка проводится на компьютере организации, аудиозапись может вообще не покидать ее периметр.
Основной риск этого этапа
Пользователь часто не видит разницы между локальной записью и записью облачной платформой. В интерфейсе это может выглядеть одинаково, хотя маршруты данных будут совершенно разными.
Кроме того, боты нередко автоматически подключаются к встречам через календарь. Сотрудник однажды разрешает интеграцию, после чего бот начинает появляться на всех событиях подряд – в том числе на тех, где его присутствие не планировалось.
2. Второй этап: сервер вендора
После захвата аудиозапись или поток поступает на сервер компании, предоставляющей сервис транскрибации.
На этом этапе вендор может:
- принять и временно буферизовать аудио;
- разделить запись на фрагменты;
- улучшить качество звука;
- определить язык;
- подготовить данные для передачи системе распознавания речи;
- сохранить исходную запись.
Здесь возникает первая важная точка доступа. Чтобы обработать аудио, облачный сервис, как правило, должен получить его в открытом виде. Шифрование канала защищает запись во время передачи, а шифрование хранилища – сохраненный файл от прямого чтения с диска. Но в момент обработки система все равно должна расшифровать данные.
Именно поэтому обычное сквозное шифрование плохо совместимо с облачной транскрибацией: сервис не может распознавать речь в аудио, содержание которого скрыто.
Основные риски этого этапа
Первый риск – компрометация учетной записи. Если сервис хранит историю встреч, получивший доступ к аккаунту злоумышленник может увидеть не один документ, а целый архив переговоров.
Второй риск – доступ сотрудников вендора. Он может требоваться для технической поддержки, анализа ошибок и обслуживания системы. Даже если такой доступ ограничен внутренними правилами, техническая возможность обычно существует.
Третий риск – неопределенный срок хранения. Пользователь может считать, что запись удаляется после создания транскрипта, хотя фактически она остается в сервисе до ручного удаления, окончания подписки или срабатывания отдельной политики хранения.
3. Третий этап: облачная инфраструктура
Сервер вендора не всегда означает собственный сервер в буквальном смысле. Большинство подобных сервисов используют инфраструктуру крупных облачных провайдеров.
Поэтому в цепочке появляются как минимум два разных участника:
- компания, с которой взаимодействует пользователь;
- компания, на инфраструктуре которой размещена система.
Кроме самого аудиофайла, в облаке могут находиться:
- резервные копии;
- журналы событий;
- временные файлы;
- базы данных;
- данные об участниках встреч;
- электронные адреса и названия организаций;
- информация о времени и продолжительности звонков.
Даже если основной файл удален, отдельные сведения о нем могут сохраниться в логах, резервных копиях и служебных системах.
Основной риск этого этапа
Организация оценивает безопасность известного ей сервиса, но не всегда учитывает инфраструктурных поставщиков и субподрядчиков.
При этом атака необязательно должна быть направлена на сам сервис транскрибации. Уязвимым звеном может оказаться облачная учетная запись, система резервного копирования, сторонняя библиотека, панель администратора или токен интеграции.
Чем больше элементов в цепочке, тем больше возможных точек компрометации.
4. Четвертый этап: сервер распознавания речи
Не каждый сервис транскрибации самостоятельно разрабатывает систему распознавания речи.
Вендор может предоставлять удобный интерфейс, подключение к календарю, редактор и поиск, но саму расшифровку выполнять через API другого поставщика.
В этом случае аудио или его фрагменты передаются на отдельный сервер распознавания речи. Там происходит преобразование звука в текст.
У разных компаний этот этап может называться сервером расшифровки, ASR-провайдером или модулем транскрибации. Название не так важно. Существенно то, что содержание разговора получает еще один участник цепочки.
После обработки у него могут остаться:
- исходные аудиофрагменты;
- временные копии;
- распознанный текст;
- служебные журналы;
- данные для диагностики качества работы системы.
Основные риски этого этапа
Пользователь может вообще не знать, что сервис использует внешнего поставщика распознавания речи.
Условия работы с этим поставщиком определяются договором между двумя компаниями. Клиент не всегда может проверить, какой срок хранения установлен у субподрядчика, кто имеет доступ к данным и какие технические журналы сохраняются.
Особенно важно различать нулевой срок хранения и обещание удалить данные позднее. В первом случае поставщик обрабатывает запрос и не создает долгосрочную копию. Во втором – данные сначала сохраняются, а значит, на определенный период остаются доступными и могут быть скомпрометированы.
5. Пятый этап: языковая модель
Получить текст – только половина задачи современного сервиса.
После транскрибации система обычно предлагает:
- краткое содержание встречи;
- основные тезисы;
- список решений;
- поручения;
- перечень вопросов;
- поиск ответов по содержанию разговора;
- автоматическое заполнение CRM.
Для этого текст передается языковой модели. Она также может принадлежать не сервису транскрибации, а отдельному поставщику.
Таким образом, если аудио обрабатывал один подрядчик, то транскрипт может быть передан другому.
Основные риски этого этапа
Текстовая версия разговора нередко представляет даже больший интерес, чем исходное аудио. Ее легче искать, копировать, анализировать и массово обрабатывать. В часовом разговоре злоумышленнику пришлось бы вручную искать нужный фрагмент. В транскрипте достаточно ввести название проекта, фамилию, сумму сделки или слово «пароль».
Кроме того, вместе с текстом языковой модели может передаваться дополнительный контекст: имена участников, названия компаний, сведения из предыдущих встреч или инструкции пользователя.
6. Шестой этап: архив, поиск и интеграции
После обработки данные обычно не исчезают. Наоборот, сервис превращает их в удобный долговременный архив.
Могут сохраняться:
- аудиозапись;
- полная расшифровка;
- саммари;
- список поручений;
- сведения об участниках;
- комментарии пользователей;
- поисковый индекс;
- векторные представления текста;
- история запросов к транскрипту.
Затем результаты автоматически передаются в другие системы: CRM, корпоративный мессенджер, электронную почту, облачный диск, систему управления проектами или базу знаний.
Каждая интеграция создает дополнительную копию.
Например, один разговор может одновременно остаться1. в сервисе видеосвязи;
2. в аккаунте транскрибационного сервиса;
3. у поставщика распознавания речи;
4. в системе языковой модели;
5. в CRM;
6. в сообщении корпоративного мессенджера;
7. в резервных копиях перечисленных систем.
При этом удаление транскрипта в основном интерфейсе не означает автоматического удаления всех созданных копий.
Основной риск этого этапа
Разрозненные записи превращаются в централизованный и хорошо индексированный архив переговоров.
До появления транскрибации информация могла быть распределена между письмами, сообщениями, личными заметками и памятью участников. Теперь она собрана в одном месте и снабжена поиском.
Это удобно для сотрудников – и одновременно удобно для злоумышленников.
Почему нельзя полагаться только на пользовательское соглашение
При оценке сервиса часто задаются вопросом: «Обучается ли модель на наших данных?» Вендор сообщает, что клиентский контент не используется для обучения, и обсуждение на этом заканчивается.
Но с точки зрения информационной безопасности это не главный вопрос.
Во-первых, обещание может относиться только к конкретной модели или конкретной категории данных. Например, компания может не обучать основную модель на содержании транскриптов, но сохранять технические журналы, метаданные или отдельные фрагменты для аналитики и улучшения сервиса.
Во-вторых, условия использования меняются. То, что действует сегодня, может быть скорректировано после обновления продукта, смены поставщика модели или появления новой функции.
В-третьих, даже полное соблюдение заявления «не используем для обучения» не защищает от утечки, ошибочной настройки доступа, взлома учетной записи или компрометации подрядчика. Поэтому риск обучения или необучения на пользовательских данных не следует купировать только ссылкой на пользовательское соглашение.
Для практической модели угроз разумно использовать более жесткое правило:
Если у внешнего сервиса есть техническая возможность получить содержание разговора, сохранить его или передать подрядчику, следует считать, что данные не защищены.
Это не означает, что вендор обязательно злоупотребит доступом. Это означает, что безопасность не должна зависеть исключительно от его обещания этого не делать. Надежная защита строится не на декларации «мы не смотрим», а на отсутствии технической возможности посмотреть.
Все это опасно, но не уникально
После описания цепочки может сложиться впечатление, что любая облачная транскрибация недопустима.
Это не так.
Похожие риски возникают при использовании практически любого внешнего цифрового сервиса:
- переписка хранится на серверах мессенджера;
- письма проходят через почтового провайдера;
- документы размещаются на облачном диске;
- видеозвонки обрабатываются платформой связи;
- задачи и комментарии остаются в системе управления проектами;
- сведения о клиентах хранятся в CRM.
Транскрибация не создает принципиально новый тип риска. Она усиливает уже имеющийся риск передачи информации внешнему поставщику.
Главная особенность заключается в масштабе и концентрации данных. Сервис может автоматически собирать содержание десятков и сотен разговоров, превращать его в текст и создавать единый поисковый архив. Поэтому правильный вывод заключается не в полном отказе от транскрибации, а в разделении процессов.
Какие разговоры можно передавать внешнему сервису
Не все рабочие встречи одинаковы по чувствительности.
Для обычного организационного звонка риск может быть приемлемым. Например, если сотрудники обсуждают время следующего совещания, публичную информацию о продукте или распределение стандартных задач.
Другая ситуация – переговоры, в которых звучат:
- условия еще не заключенной сделки;
- цены и скидки;
- финансовые показатели;
- стратегия компании;
- данные клиентов;
- результаты внутреннего расследования;
- содержание юридической консультации;
- кадровые решения;
- пароли, ключи доступа и сведения об инфраструктуре;
- информация, составляющая коммерческую тайну.
Такие разговоры не должны автоматически отправляться в обычный внешний сервис только потому, что сотруднику удобно получить саммари.
Практически процессы можно разделить на три категории.
Первая категория: допустима внешняя транскрибация
Это встречи, содержание которых не нанесет заметного ущерба при раскрытии.
Для них можно использовать утвержденный облачный сервис при условии разумных настроек доступа и хранения.
Вторая категория: транскрибация допустима с ограничениями
К этой группе относятся внутренние рабочие обсуждения, содержащие непубличные, но не критичные сведения.
Для них может использоваться корпоративный тариф, ограниченный срок хранения, отключение записи аудио после получения текста и запрет ненужных интеграций.
Третья категория: только локальная обработка или полный отказ от записи
Это переговоры, утечка которых способна привести к существенным финансовым, правовым или репутационным последствиям.
Здесь предпочтительно локальное распознавание речи. Если безопасный локальный процесс не создан, встречу лучше не транскрибировать.
Два главных принципа
Из всей технической цепочки следуют два основных практических вывода.
Первый принцип: сотрудники должны понимать, какие данные нельзя передавать наружу
Запретить конкретный сервис недостаточно. Через месяц появится другой инструмент, браузерное расширение или бот с бесплатным тарифом. Сотрудник зарегистрируется с рабочей почты и снова подключит его к календарю. Поэтому нужно объяснить не только перечень разрешенных продуктов, но и сам принцип разделения информации.
Сотрудник должен уметь ответить на два вопроса:
- Насколько чувствительным будет содержание встречи?
2. Допустимо ли передавать его внешней системе и создавать поисковый архив?
Без такого понимания есть риск, что ограничения быстро превратятся в формальность, которую обходят ради удобства.
Второй принцип: для чувствительных переговоров нужна локальная транскрибация
Локальное решение обрабатывает запись на компьютере пользователя или на сервере организации. В этом случае аудио не нужно передавать отдельному сервису распознавания речи, а текст – внешней языковой модели.
Это не устраняет все риски. Нужно защищать само устройство, сервер, учетные записи и локальное хранилище. Но организация сохраняет контроль над инфраструктурой и не добавляет в процесс внешних участников.
При этом важно учитывать источник записи. Если разговор уже проходит через внешнюю облачную платформу, локальная транскрибация исключает дополнительную передачу данных сервису для расшифровки, но не исключает доступ самой платформы связи.
Для действительно чувствительных коммуникаций нужно оценивать весь маршрут, а не только последний этап расшифровки.
Что сделать в первую очередь
Переход к более безопасной транскрибации не требует немедленной перестройки всей инфраструктуры. Для начала достаточно пяти шагов.
1. Провести инвентаризацию используемых сервисов
Выяснить:
- какие боты и приложения подключены к календарям сотрудников;
- какие сервисы автоматически входят на встречи;
- где хранятся записи и транскрипты;
- какие интеграции включены;
- кто имеет доступ к архивам.
На практике организация может одновременно использовать несколько инструментов, о которых ИТ- и ИБ-подразделения не знают.
2. Отключить автоматическую запись и подключение ботов
Транскрибация должна запускаться осознанно для конкретной встречи. Автоматический вход во все события календаря создает риск записи разговоров, которые не предполагалось передавать внешней системе. Поэтому подключение бота, сохранение аудио и передачу результатов в другие сервисы лучше отключить по умолчанию.
3. Разделить встречи по уровню чувствительности
Для начала достаточно трех режимов:
- внешний сервис разрешен;
- внешний сервис разрешен с ограничениями;
- только локальная обработка или запрет записи.
Критерии должны быть понятны сотруднику до начала разговора. К третьей категории следует относить переговоры о сделках, ценах, стратегии, клиентах, кадровых вопросах, внутренних расследованиях, юридических консультациях и об инфраструктуре.
4. Утвердить разрешенные инструменты и правила хранения
Организация должна заранее определить:
- какие сервисы разрешено использовать;
- для каких категорий встреч они подходят;
- как долго хранятся аудио и транскрипты;
- какие интеграции допустимы;
- когда данные должны удаляться.
Ненужные архивы, старые записи и автоматическую передачу транскриптов в CRM, мессенджеры и облачные диски следует отключить. Чем меньше копий создается, тем проще контролировать данные.
5. Запустить локальную транскрибацию для чувствительных переговоров
Локальное решение можно сначала внедрить в подразделениях, которые регулярно работают с чувствительной информацией: у руководства, юристов, финансистов, кадровой службы, ИБ и команд, участвующих в сделках.
Одновременно сотрудникам нужно объяснить сам маршрут данных:
звук → сервис → облако → система распознавания → языковая модель → архив → интеграции
Понимание этой цепочки важнее запрета конкретного продукта. Сервисы будут меняться, а принцип останется прежним: обычные встречи можно передавать утвержденным внешним системам, чувствительные — следует обрабатывать локально или не записывать.
Основной вывод
Главный риск ИИ-транскрибации заключается не в самом преобразовании речи в текст. Проблема возникает из-за того, что один разговор может пройти через несколько независимых систем и остаться в каждой из них в виде аудио, текста, саммари, метаданных, поискового индекса или резервной копии.
Пользовательское соглашение и обещание не обучать модель на клиентских данных имеют значение, но не заменяют техническую модель угроз. Если сервис получает содержание разговора, безопасность в любом случае зависит от его инфраструктуры, сотрудников, подрядчиков и настроек.
При этом транскрибация не требует тотального отказа от облачных инструментов. Организации уже принимают похожие риски, используя мессенджеры, электронную почту, видеосвязь и облачные хранилища.
Нужен не тотальный запрет, а понятное разделение процессов:
- обычные встречи можно передавать утвержденным внешним сервисам;
- для непубличной информации нужны дополнительные ограничения;
- чувствительные переговоры должны обрабатываться локально либо не записываться.
Поэтому первоочередная задача состоит не в поиске идеального пользовательского соглашения. Гораздо важнее объяснить сотрудникам, какие разговоры нельзя отправлять наружу, и создать локальный вариант транскрибации для тех случаев, где внешний сервис использовать недопустимо.
