ТЗ на запись звонков: требования для Verint, NICE и on-prem

С чего начинаются проблемы в проектах записи звонков

Запись звонков и speech analytics покупают не ради "галочки". Бизнесу это нужно, чтобы разбирать спорные ситуации с клиентами, повышать качество работы операторов и находить причины потерь. Службе безопасности и комплаенсу - чтобы расследовать инциденты, подтверждать факты и снижать риски по персональным данным.

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

Обычно слишком поздно вспоминают про детали:

• ретеншн по разным типам звонков и правила удаления
• роли, аудит действий и разделение полномочий (кто слушает, кто выгружает, кто администрирует)
• маскирование и запрет прослушивания отдельных фрагментов (например, данные карты)
• выгрузки для расследований: формат, контроль целостности, журнал цепочки действий

Чтобы требования не разрастались и не тормозили проект, разделите их на две группы. Обязательные - те, без которых вы не пройдете проверку и не проведете расследование безопасно. Желательные - то, что ускорит работу (например, расширенная аналитика или дополнительные дашборды), но может подождать второй очереди.

Ориентир простой: если пункт влияет на безопасность, доступы и юридическую пригодность записи, это почти всегда must-have.

Классы решений: Verint, NICE и on-prem, и что это меняет

Перед тем как описывать требования, полезно понять класс решения. Условно есть три группы: крупные платформы уровня Verint и NICE, специализированные on-prem рекордеры (в том числе под SIPREC), и гибридные схемы, где часть функций уходит в облако, а хранение остается у вас.

Главное отличие между классами не в кнопках интерфейса, а в том, какие требования становятся обязательными.

Облако, on-prem и гибрид: что меняется в требованиях

В облаке вы чаще упираетесь в юридику и контроль: где физически лежат данные, как обеспечивается доступ, как делаются выгрузки для проверок. В on-prem вы отвечаете за ресурсы и эксплуатацию: диски, бэкапы, обновления, мониторинг.

Что лучше зафиксировать сразу:

• модель развертывания и границы ответственности (кто администрирует, кто хранит ключи шифрования)
• где выполняется speech analytics (на вашей площадке или у поставщика) и какие данные туда попадают
• требования к масштабированию: сколько одновременных каналов записи, прирост хранилища, пики
• план обновлений и совместимость с вашей телефонией и политиками безопасности

Где живут аудио и метаданные

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

Не забудьте про зависимости. На практике проект стопорится не на самой записи, а на стыках:

• телефония/контакт-центр (SIP, SIPREC, CTI, политика записи)
• CRM (карточка клиента, привязка звонка)
• SSO и роли (AD/LDAP, MFA)
• сетевые зоны и межсетевые экраны
• серверная база для on-prem (например, выделенные серверы и дисковые полки, если вы храните записи у себя)

Если это описать заранее, дальше проще согласовать хранение, доступы и выгрузки без сюрпризов.

Хранение и ретеншн: сроки, шифрование, бэкапы, удаление

Про хранение часто пишут одной строкой: "хранить 1 год". Потом выясняется, что сроки разные для продаж, поддержки и претензионных случаев, а часть записей нельзя трогать до окончания проверки. Лучше сразу описать матрицу ретеншна: по типу звонка, подразделению, каналу (входящий/исходящий) и статусу (обычный/инцидент/спор).

Дальше - формат и качество. Укажите, нужен ли раздельный стереоканал (оператор и клиент отдельно), минимальная частота/битрейт, и допускается ли перекодирование при переносе в архив. Это влияет и на размер хранилища, и на качество распознавания речи.

Шифрование стоит разделять на два слоя: "на диске" и "при передаче". Важный, но часто забытый пункт: кто владеет ключами и где они хранятся (служба ИБ, администратор платформы, отдельный HSM). В on-prem вариантах это особенно критично: без понятной ответственности за ключи шифрование превращается в формальность.

С резервными копиями не ограничивайтесь фразой "делать бэкап". Зафиксируйте минимум:

• RPO/RTO для архива записей и для метаданных
• что именно бэкапится (аудио, индексы, справочники, журналы аудита)
• периодичность и срок хранения копий
• как часто проводится тестовое восстановление и кто подписывает акт
• защита копий (шифрование, изоляция, контроль доступа)

Удаление тоже должно быть управляемым: автоматическое по сроку, удаление по запросу (например, по обращению субъекта данных), и удаление с подтверждением. Полезно требовать доказуемость удаления: запись события в журнале, идентификатор объекта, кто инициировал, по какому основанию, и что именно удалено (аудио, расшифровка, индексы). Для расследований отдельно оговорите режим "заморозки" (legal hold), чтобы ретеншн не удалил нужные материалы раньше времени.

Доступы и контроль: роли, аудит, разделение полномочий

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

Начните с ролей и их границ. Важно не только "кто может слушать", но и кто может экспортировать, удалять, менять правила записи и словари для speech analytics.

Минимальный набор ролей, который стоит закрепить:

• Оператор: слушает только свои звонки (и только за нужный период), без выгрузок.
• Супервайзер: слушает звонки своей группы, ставит оценку, делает заметки.
• QA: доступ по выборке, без прав на изменение настроек и без массовых выгрузок.
• Безопасность/комплаенс: доступ ко всем записям, право на выгрузку для расследований, запуск legal hold.
• Администратор: управляет системой и интеграциями, но не имеет права слушать содержимое (если это реализуемо).

Дальше - аутентификация. Часто забывают прописать SSO/MFA, правила сессий и блокировок. Укажите требования к входу через корпоративный SSO и обязательному MFA для ролей с выгрузками, таймауту неактивности и принудительному выходу, политике паролей для локальных учетных записей (если они остаются), блокировке после неудачных попыток.

Отдельный пункт - аудит действий. Нужен журнал, где видно: кто искал, кто слушал, кто скачал, кто менял настройки, и с какого устройства. Важно, чтобы аудит нельзя было "подчистить" обычным администратором, а выгрузка аудита делалась по запросу.

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

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

Маскирование и соответствие требованиям по данным

Риски чаще возникают не из-за самой записи, а из-за того, что в аудио и расшифровках остаются чувствительные данные. В требованиях важно прямо назвать, что считается чувствительным именно у вас: ИИН, номер и срок действия карты, CVV, адрес, e-mail, данные о здоровье, сведения по зарплате или внутренним расследованиям.

Отдельно зафиксируйте, где должно работать маскирование: в тексте (speech-to-text, заметки оператора, поля CRM) и в аудио. Для текста обычно достаточно скрывать фрагменты символами и ограничивать поиск по ним. Для аудио нужен понятный вариант: либо вырезание фрагмента, либо замена на тон, либо хранение оригинала с жестким контролем доступа.

Если у вас принимают платежи по телефону, уточните требование к паузе записи на время ввода карточных данных. Пропишите триггеры (кнопка у оператора, IVR-режим, автоматическое распознавание) и поведение системы при ошибках, чтобы пауза не превращалась в дыру в контроле качества.

Права на снятие маски должны быть редким исключением. Полезно задать правила:

• кто может видеть оригинал (например, служба безопасности по заявке)
• требуется ли двухстороннее согласование (владелец процесса + ИБ)
• как фиксируется просмотр (аудит, причина, номер кейса)
• можно ли скачивать оригинал или только просматривать
• как быстро блокируется доступ при инциденте

Еще один забытый пункт - срок хранения расшифровок. Текст искать и копировать проще, чем аудио, поэтому утечки часто происходят именно через транскрипты. Нередко безопаснее хранить их меньше, чем сами записи, и жестче контролировать выгрузки.

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

Поиск, метаданные и speech analytics: что попросить в требованиях

Если не описать поиск и метаданные, система быстро превращается в "архив звука", где нужный разговор ищут часами. Хорошее правило: сначала описать, как люди реально будут находить записи (контроль качества, разбор жалоб, безопасность), и только потом - какие отчеты и аналитика нужны.

Метаданные: что фиксировать по каждому звонку

Минимальный набор лучше закрепить сразу, иначе часть полей окажется недоступной из АТС/контакт-центра или будет заполняться вручную:

• номер клиента (ANI) и внутренний номер/ID оператора
• очередь, направление, результат (принят, пропущен, перевод)
• время начала/окончания, длительность, ID звонка и ID записи
• теги и категории (например, "жалоба", "возврат", "VIP") и кто их поставил
• признаки "чувствительных данных" (например, платежные данные) для маскирования

Дальше опишите, какие поля приходят автоматически, какие подтягиваются из CRM, и что делать, если источник недоступен (например, звонок есть, а карточки клиента нет).

Поиск и speech analytics: как формулировать требования

Поиск обычно нужен не один. Укажите фильтры и скорость реакции интерфейса на типовых объемах. Часто хватает набора: поиск по времени, номеру и оператору, по очереди/направлению, по тегам, плюс полнотекстовый поиск по расшифровке (ключевые слова и фразы). Если нужны темы и классификация, заранее опишите, как они обучаются и кто отвечает за качество.

Отдельно зафиксируйте синхронизацию времени: поддержка NTP, единый часовой пояс, и допустимое расхождение таймкодов между аудио, логами и метаданными. Иначе при разборе инцидента "в 10:15" запись может оказаться "в 10:12".

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

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

Выгрузки для расследований: форматы, следы, legal hold

Выгрузка записей нужна не каждый день, поэтому ее часто описывают одной строкой. А потом выясняется, что при инциденте, внутренней проверке, споре с клиентом или запросе регулятора нельзя быстро и безопасно собрать пакет материалов. Заранее зафиксируйте, что именно считается "выгрузкой" и какие правила действуют.

Сначала определите состав пакета. В разных кейсах нужны не только аудиофайлы, но и расшифровка, метаданные (номер, оператор, время, очередь, ID звонка), а иногда и результаты speech analytics (теги, найденные фразы, оценки). Укажите допустимые форматы и единый контейнер передачи (например, один архив на кейс), чтобы его можно было открыть без установленной системы.

Еще важнее цепочка хранения: кто запросил выгрузку, кто ее сделал, где лежит копия и кто имел доступ. Пропишите требования к следам (audit trail) и проверке целостности.

Что полезно закрепить:

• выгрузка аудио, текста, метаданных и отчетов отдельными файлами и в составе одного пакета
• автоматический журнал: заявка, исполнитель, время, список файлов, основание
• контроль целостности: хэш/контрольная сумма на каждый файл и на весь пакет
• ограничения на массовые выгрузки: квоты, лимиты по времени, только по роли
• правила хранения копии: срок, шифрование, запрет "ручной" пересылки

Legal hold (юридическая заморозка) выделите отдельным пунктом: по кейсу должна включаться блокировка автоудаления и очистки, даже если общий ретеншн истек.

Пример: служба безопасности расследует утечку. Нужны 23 звонка за неделю, их транскрипты и метки "паспорт/карта". Без legal hold часть записей могла бы удалиться по политике хранения, а без журнала действий нельзя доказать, кто и когда делал выгрузку.

Как собрать требования и оформить их в ТЗ: пошагово

Хорошее ТЗ начинается не с выбора Verint, NICE или on-prem платформы, а с понятных задач и границ ответственности. Если это не зафиксировать, позже всплывают "неожиданные" требования к хранению, доступам или выгрузкам, и проект начинает буксовать.

Собирайте требования по шагам:

1. Снимите вводные по нагрузке и охвату: сколько звонков в сутки, средняя длительность, какие каналы (телефония, софтфон, контакт-центр), какие подразделения и сколько операторов. Сразу уточните, с какого дня записи должны быть доступны и какой горизонт хранения нужен.

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

3. Составьте матрицу требований с приоритетами must/should/could и критериями приемки. Например: "must: выгрузка фрагмента в заданном формате + журнал действий" или "should: маскирование фрагментов с персональными данными при прослушивании".

4. Заранее согласуйте интеграции и RACI: АТС/контакт-центр, SSO/AD, SIEM, системы заявок. Отдельно пропишите, кто отвечает за сеть, сертификаты, резервное копирование и администрирование ролей.

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

Практический прием: перед финальной версией ТЗ проведите 30-минутный разбор одного сложного кейса, например расследование инцидента с legal hold. Если вы можете пошагово описать, как запись находится, кем подтверждается целостность, как выгружается и кто это видит в аудит-логе, значит требования собраны достаточно полно.

Типовые ошибки в ТЗ, из-за которых проект буксует

Самая частая причина провала сроков не в Verint или NICE, и не в "железе", а в том, что ТЗ описывает цель, но не описывает правила. В итоге на приемке выясняется, что разные отделы ожидали разное.

Одна цифра ретеншна почти всегда недостаточна. Для аудиозаписей, расшифровок, метаданных (номер, оператор, очередь), отчетов и логов часто нужны разные сроки и разные требования к хранению. Если этого нет, вам либо не хватит дисков, либо вы случайно храните лишнее и повышаете риски.

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

С маскированием похожая история: слово есть, правил нет. Важно заранее определить, где маскировать (в аудио, в тексте, на экране плеера), для каких ролей и по каким триггерам (например, номера карт, ИИН, паспортные данные). Иначе часть пользователей увидит лишнее, а часть не сможет работать.

Часто забывают описать выгрузки и жизнь копий. Экспорт "для службы безопасности" без форматов, подписи/хэша, сопроводительных файлов и порядка хранения вне системы приводит к тому, что записи гуляют по флешкам и почте.

Минимум, который стоит явно прописать

• ретеншн по типам данных и условия удаления
• аудит: список событий, сроки хранения, доступ и защита от правок
• маскирование: где, для кого, по каким правилам и как проверять
• выгрузки: кто может, в каком виде, как маркируется цепочка хранения
• тесты: восстановление из бэкапа и сценарии отказа (что считается успешным)

Простой пример: служба безопасности просит записи за неделю по очереди колл-центра. Если в ТЗ нет правила legal hold и формата выгрузки, ИТ выгрузит что сможет, а через месяц окажется, что часть записей удалена по ретеншну, а подлинность файлов невозможно подтвердить.

Короткий чек-лист перед согласованием ТЗ

Перед тем как отправлять ТЗ на согласование (особенно если выбираете Verint, NICE или on-prem), пройдитесь по короткой проверке. Проект часто "застревает" не из-за записи как таковой, а из-за спорных моментов по данным и доступам, которые всплывают уже на внедрении.

Пять вопросов, на которые в документе должны быть четкие ответы, без формулировок "по умолчанию":

• какой срок хранения нужен по типам разговоров и каналам, и кто утверждает исключения (например, для претензий и спорных кейсов)
• как удаляются записи: по расписанию, по событию, по запросу, и как фиксируется факт удаления (важно для проверок)
• кто и как получает доступ: роли, разделение обязанностей, вход через SSO и/или MFA, и какие действия пишутся в аудит
• как маскируются персональные данные и платежные данные: что маскируем, на каком этапе (в записи, в расшифровке, в плеере), и кто имеет право на раскрытие
• как выдается выгрузка для расследования: формат, подписи/хэши, журнал действий, и как защищается цепочка хранения (chain of custody)

Дальше проверьте, что это можно измерить на приемке, а не "поверить на слово".

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

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

Пример сценария: расследование инцидента без лишних рисков

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

Сотрудник с ролью "расследование" находит запись по метаданным: номер клиента, входящая линия, ID оператора, дата и интервал времени, статус звонка (принят, переведен), а также связанный тикет из CRM. Важно, чтобы система показывала признак целостности: например, цифровую подпись или хэш, и чтобы было видно, что файл не менялся после записи.

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

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

• аудио и расшифровка с маскированием: номера карт, ИИН, адреса, пароли, коды из SMS
• пакет доказательств: исходный файл, контрольная сумма, метаданные, отметка времени
• отчет действий: кто искал, кто слушал, кто выгружал, с какого устройства
• режим запрета удаления (legal hold) на период проверки

После закрытия дела остаются артефакты: служебная записка с ID записи, отчет аудита, пакет выгрузки с хэшами, решение по доступам (кому выдавали и когда отозвали), и отметка о снятии legal hold. Этот сценарий хорошо проверяет, что хранение, доступы, маскирование и выгрузки действительно работают вместе.

Следующие шаги: пилот, расчет ресурсов и внедрение

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

Пилот на реальных сценариях

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

Проверьте и измерьте:

• качество записи и полнота охвата каналов (включая переводы и удержания)
• поиск по метаданным и скорость выдачи результатов
• корректность маскирования и права доступа по ролям
• процесс выгрузки для расследований с сохранением следов
• реальный путь от запроса до выдачи записи (кто, как и за сколько)

Расчет ресурсов и план внедрения

Если выбираете on-prem контур, заранее посчитайте хранение и серверные ресурсы: число одновременных каналов, кодек, средняя длительность разговоров, сроки ретеншна, запас под индексацию и speech analytics. Отдельно запланируйте резервирование: где будут бэкапы, как проверяется восстановление, что происходит при отказе узла.

Дальше согласуйте модель поддержки и регламенты: кто заводит пользователей, кто утверждает доступы, как часто смотрят аудит, кто выполняет legal hold. Если службе безопасности нужно срочно поднять цепочку звонков по инциденту, заранее определите, кто может инициировать выгрузку, а кто только подтверждает.

Если нужен on-prem, продумайте поставку серверов и рабочих станций под администрирование, а также поддержку 24/7. Это удобно обсуждать с системным интегратором вроде GSE.kz (gse.kz): они работают как производитель и интегратор, поэтому помогают собрать инфраструктуру под запись, хранение и эксплуатацию без жесткой привязки к одному вендору.