ИИ-транскрипция встреч – ландшафт инструментов

Автор: Николай СапуновОбновлено: август 202622 мин чтения
Содержание статьи +

Кратко

Все инструменты ИИ-транскрипции для встреч делают одно и то же – превращают разговор в звонке в текст с возможностью поиска и краткое резюме, – но сильнее всего они различаются в том, как они получают аудио, и именно этот выбор определяет их подход к приватности, стоимость и возможность интеграции в ваш собственный продукт. На рынке существует четыре способа захвата: собственный ИИ платформы для звонков, облачный «бот», который подключается к звонку как видимый участник, десктопное приложение без бота, которое записывает звук напрямую с вашего компьютера, и инфраструктурный API, на котором вы строите решение, если транскрипция должна работать внутри вашего софта. Точность больше не является ключевым отличием – на чистом звуке все инструменты показывают результат около 90–97% правильных слов, – поэтому выбор теперь зависит от согласия, развёртывания и интеграции, а не от процентов. Эта статья – карта: она объясняет каждый подход простыми словами, показывает, где на самом деле лежат деньги и юридический риск, и помогает определить, какой паттерн выбрать – покупаете ли вы инструмент для команды или встраиваете транскрипцию в видеопродукт.

Почему это важно

Транскрипция встреч перестала быть новинкой и превратилась в полноценный рынок: объём сегмента ИИ-заметок в 2025 году составил около $623 млн и превысил примерно $740 млн в 2026 году – внутри более широкого рынка ИИ-ассистентов для встреч, который растёт примерно на 26% в год. Если вы руководите продуктовой командой, отделом продаж или видеоплатформой, на ваш стол попадают два ключевых вопроса: «Какой ноутейкер выбрать в качестве стандарта?» и всё чаще – «Не стоит ли реализовать это внутри нашего приложения, вместо того чтобы платить за каждого пользователя?» Эта статья отвечает на оба вопроса, предлагая единую модель – четыре паттерна захвата и одно правило приватности, – чтобы продакт-менеджер мог выбрать инструмент, не утонув в таблицах функций, а инженер – чётко определить, где проходит граница между «купить» и «построить». Статья продолжает серию о LiveKit в этом разделе: ранние уроки показывают, как создать агента для транскрипции, а эта – делает шаг назад и рассматривает весь рынок вокруг неё.

Единственное, что реально разделяет эти инструменты

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

Решение лежит на уровень ниже – в вопросе, который большинство гайдов упускает: как инструмент вообще получает звук? Этот единственный архитектурный выбор – назовём его паттерном захвата – определяет три вещи, которые действительно важны. Он решает, видят ли остальные участники встречи, что идёт запись – это вопрос приватности и доверия. Он определяет, сколько и как вы платите, потому что у инструмента, работающего на вашем ноутбуке, совсем другая структура затрат, чем у того, что держит сервер для каждого звонка. И он решает, сможет ли инструмент когда-нибудь стать частью продукта, который вы создаёте, или останется отдельным приложением, работающим параллельно с встречами.

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

Рисунок 1. Четыре паттерна захвата. Любой продукт для транскрипции встреч на рынке – один из этих четырёх; остальные их списки фич отличаются мало.

Работа, которую они выполняют за 30 секунд

Перед паттернами – о самой работе. Каждый инструмент здесь проходит три одинаковых этапа, и названия этих этапов делают остальную часть статьи понятной.

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

Второй – распознавание речи: преобразование звука в текст. Технический термин – automatic speech recognition, обычно сокращают до ASR. Сегодня это уже достаточно зрелая технология; одна и та же группа движков (мы разбираем их в уроке про потоковый ASR) лежит в основе почти всех продуктов на рынке – именно поэтому их точность больше не является ключевым различием.

Третий – понимание: два слоя поверх исходного текста. Первый – диаризация, громоздкое слово, означающее разметку: кто сказал какую фразу, чтобы транскрипт выглядел как «Мария: …» и «Сэм: …», а не как сплошная стена слов. Второй – резюме: языковая модель анализирует весь транскрипт и составляет краткое изложение из нескольких абзацев, а также список действий. Когда в гайде говорят «ИИ-резюме встречи» (ai meeting summary), имеют в виду именно этот слой – модель генерирует текст поверх транскрипта, а не создаёт что-то совершенно отдельное.

Имейте в виду эти три шага. Четыре паттерна ниже – по сути, четыре разных ответа на первый шаг.

Паттерн 1 – Собственный ИИ платформы

Самый простой способ – использовать встроенную транскрипцию в вашем приложении для звонков. У Zoom есть AI Companion и функция личных заметок My Notes. В Microsoft Teams – Copilot с функцией «интеллектуального итога» (intelligent recap). В Google Meet – опция «Take notes for me» на базе модели Gemini. Вы включаете её во время встречи – и получаете живые субтитры в реальном времени, а также краткое резюме после окончания звонка.

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

Ограничения тоже очевидны. Встроенный ИИ привязан к платформе: нотификатор Zoom помогает вам только в Zoom, а не где-либо ещё. Поэтому команда, которая за неделю проводит встречи в Zoom, Teams и Google Meet, получает три разных формата транскриптов – в трёх разных местах, без единого поискового архива по всем. Хорошие функции обычно доступны только на более дорогих тарифах. А поскольку всё скрыто и привязано к аккаунту организатора, вы часто не можете перенести транскрипт в свои системы без ручного экспорта.

Одна практическая оговорка по поводу времени – она часто удивляет людей. Живые субтитры работают в реальном времени, но аккуратный транскрипт и резюме на основе облачной записи – не мгновенны. В случае облачной записи Zoom готовый транскрипт обычно появляется примерно вдвое позже, чем длилась встреча: 30-минутный звонок может занять около часа до готовности транскрипта. Если ваш сценарий предполагает, что резюме появляется в ту же секунду, как закончился звонок, проверьте это допущение, прежде чем на нём строить.

Паттерн 2 – Облачный бот для встречи

Это паттерн, который большинство представляет, услышав «ИИ-ноутейкер», и именно его по умолчанию используют Otter, Fireflies и Fathom. Программа – «бот» – присоединяется к вашей встрече, как будто она ещё один участник. Она появляется в списке участников с именем вроде «Fireflies.ai Notetaker», подключается к звуку и видео звонка так же, как это сделал бы браузер человека, и передаёт этот звук в облачный сервис, где он транскрибируется и суммируется.

Как бот «входит» в звонок, куда его не приглашали, как человека? Под капотом бот – это обычно headless-браузер, то есть настоящий веб-браузер, запущенный на сервере без экрана, который открывает ссылку встречи и подключается через WebRTC – ту же технологию реального времени для звука и видео, что использует ваш браузер в видеозвонках. Для участников встречи он выглядит как ещё один гость с выключенной камерой. Поэтому бот может одинаково подключаться к Zoom, Teams и Google Meet: он просто запускает браузер в каждом из них.

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

Слабость – сам бот. Он видимый: все видят «Notetaker» в списке участников, и это присутствие влияет на то, как люди общаются. Хуже того, видимость – не то же самое, что юридическое согласие (об этом ниже). Итог 2026 года – то, что отрасль теперь открыто называет «ботовой усталостью»: измеримый откат, когда клиенты отказываются от встреч с ботом в комнате, а корпоративные IT-команды начинают прямо запрещать сторонние авто-подключатели. Приватность сегодня – самый частый барьер для внедрения в этой категории.

Рисунок 2. Бот и приложение без бота решают одну задачу захвата в противоположных местах: один входит в звонок с сервера, другой слушает изнутри устройства, которое уже в нём.

Паттерн 3 – Desktop-приложение без бота

Реакция на усталость от ботов породила третий паттерн – и это самый быстрорастущий сегмент рынка. Инструмент без бота – самый известный пример Granola – работает как нативное приложение на вашем компьютере (Mac, Windows, иногда и на мобильных устройствах). Вместо того чтобы подключаться к звонку, он записывает звук, который ваш компьютер уже обрабатывает: аудио с динамиков (все остальные участники) и сигнал с вашего микрофона (ваш голос). Захват происходит на уровне звуковой системы операционной системы, прямо на вашем устройстве, и в саму встречу ничего не попадает.

Поскольку никого нет, не появляется сообщение «Notetaker присоединился», имя не отображается в списке, а в зале ожидания не требуется одобрение. Поскольку он записывает звук с самого устройства, а не с конкретного приложения, он работает со всем: Zoom, Teams, Google Meet, Slack-ходл, звонки в браузере – даже телефон на громкой связи рядом с ноутбуком. Если звук исходит из компьютера, приложение его транскрибирует.

Компромиссы реальны, и о них стоит говорить прямо – privacy-маркетинг их обычно умалчивает. Приложение нужно установить и держать запущенным на каждом устройстве, чтобы оно записывало вашу версию встречи, а не чистый серверный поток: один инструмент на пользователя, а не один бот на звонок. Многие решения без бота принципиально не хранят аудиозапись – например, Granola удаляет звук после распознавания и не позволяет его воспроизвести. Это отлично для приватности, но означает, что переслушать звонок позже будет нечего. Кроме того, у нативных десктопных приложений есть ограничения по платформам: к 2026 году такие, как Granola, доступны для macOS, Windows и iOS, но не для Android, что исключает их из использования частью команд.

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

Паттерн 4 – API для построения инфраструктуры

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

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

Первый вариант – арендовать слой захвата у инфраструктурного провайдера. Здесь доминирует Recall.ai: он предоставляет единый API, который запускает бота для встречи (или desktop-рекордер без бота) в Zoom, Teams, Google Meet, Webex и других платформах, и возвращает вашему продукту аудио, видео и транскрипт. Вам не нужно самостоятельно поддерживать флот headless-браузеров. К 2026 году стоимость по модели pay-as-you-go составит $0,50 за час записи – как для bot API, так и для desktop SDK – плюс $0,15 за час за встроенную транскрипцию. Интеграция с календарём бесплатна, а месячной платы за платформу нет. Конкуренты в этой нише – MeetingBaaS, Skribby, Nylas Notetaker и open-source Attendee.

Второй способ – построить захват самостоятельно внутри своего стека реального времени. Он уместен, когда сама встреча и есть ваш продукт: например, конференц- или телемедицинское приложение, уже работающее на WebRTC. В этом случае внешний бот для входа не нужен, потому что ваш сервер уже участвует в звонке. Можно централизованно распознавать речь на медиа-сервере и рассылать субтитры всем (паттерн ASR fan-out на стороне SFU), запустить агента LiveKit как молчаливого участника, который выдаёт результат ноутейкера, или вообще перенести распознавание в браузер. Это отдельные темы; здесь важно понимать, что у «построить» есть две двери: арендовать внешний API захвата или расширить пайплайн, которым вы уже владеете.

От звука к действию: общий стек

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

Рисунок 3. Общий стек. Захват различается по паттерну; четыре этапа после него почти одинаковы у всех, поэтому продукты конкурируют интеграциями и полировкой, а не сырой транскрипцией.

Поток выглядит так: сначала происходит захват аудио, затем ASR преобразует звук в сырые слова, после чего диаризация привязывает имя говорящего к каждой реплике. Далее языковая модель составляет резюме и выделяет действия, а интеграции передают результат в инструменты, которые команда уже использует – CRM вроде Salesforce или HubSpot, документы вроде Notion, чат вроде Slack. Точность транскрипта определяется на первых двух этапах. Всё, за что вендор берёт наценку – гладкое резюме, синхронизация с CRM, аналитика разговоров – реализуется на последних двух этапах, и именно поэтому лидеры рынка так схожи по точности, но так сильно различаются по цене.

Миф о точности, с цифрами

Вендоры рекламируют «точность 99%». Относитесь к этому так же, как к слову «до» в любой рекламе. Вот обоснованные цифры из бенчмарков 2026 года.

Профессиональный транскрибатор по чистому звуку ошибается примерно на 1–2%. Стандартный способ измерения ошибок транскрипции – word error rate (WER): подсчитывают слова, которые система исказила – заменила, вставила или удалила, – и делят это число на общее количество произнесённых слов. Если из 100 слов 5 оказались ошибочными, получается 5 ÷ 100 = 0,05, то есть WER 5%, что условно называют «точностью 95%». Чем ниже WER – тем лучше.

На чистом звуке – по одному говорящему за раз, хорошие микрофоны, носители английского – лучшие ИИ-движки достигают WER 4–10%, то есть точности 90–96%. На «грязных» реальных звонках – перебивания, фоновый шум, акценты, плохая телефонная связь – вся отрасль держится на уровне 90–97% и дальше не идёт. Честный итог: на хорошем звонке любой передовой инструмент примерно одинаково точен, а на сложном – ни один не сравнится с внимательным человеком.

Диаризация – разметка «кто что сказал» – сложнее распознавания речи и ошибается чаще. Независимое тестирование 2026 года показывает точность атрибуции говорящего около 91% у Otter и в середине 90-х у лучших систем, причём главным фактором является наличие коротких пауз между репликами, а не перекрытие речи. Если ваш сценарий требует идеальной разметки говорящих – например, допрос или многосторонние переговоры – будьте готовы вручную исправлять результаты. Перед тем как полагаться на автоматическую диаризацию, ознакомьтесь с нашими материалами о пословных тайм-кодах WhisperX и диаризации Pyannote.

«Частая ошибка: выбирать по цифре точности на главной странице. Поскольку каждый ведущий инструмент опережает любой другой на несколько пунктов в условиях чистого звука, рекламируемая точность – наименее полезный критерий для выбора. Гораздо важнее на практике два фактора: как инструмент работает в ваших условиях (сильные акценты, конкретный язык, трое на одной громкой связи) и какой паттерн захвата соответствует вашим требованиям к приватности и развёртыванию. Протестируйте его на реальных встречах – а не на демо-ролике вендора – и оценивайте по качеству резюме и меток говорящих, а не по проценту распознанных слов.»

Сколько эти инструменты реально стоят

Ценники сконцентрированы в узком диапазоне, а бесплатные тарифы отличаются сильнее, чем платные. Ниже – таблица с данными на 2026 год по четырём наиболее часто сравниваемым инструментам, а также вариант «сделай сам»; перед принятием решения проверьте актуальные цены, поскольку эта категория часто переприцовывается.

ИнструментПаттерн захватаБесплатный тарифПлатный старт (год)Заметное ограничение
OtterОблачный бот300 мин/мес, 30 мин на звонок$8,33/польз./мес (Pro)~4 языка; лимиты по минутам
FirefliesОблачный бот800 мин общего хранилища$10/польз./мес (Pro)CRM-синк нужен Business ($19)
FathomОблачный ботБезлимит записи, 5 ИИ-резюме/мес~$15/польз./мес (Premium)CRM-синк нужен Team Edition
GranolaDesktop без ботаБесплатно навсегда, ограниченная история$14/польз./мес (Business)Нет Android; нет воспроизведения
Recall.aiBuild-it APIПробные кредиты$0,50/час записиПо потреблению; продукт строите вы

Читайте таблицу по тому, как вы платите, а не только сколько. Инструменты с оплатой за место (Otter, Fireflies, Fathom, Granola) стоят фиксированную сумму с человека в месяц – это предсказуемо и дёшево для команды, которая встречается умеренно, но дорого на большую организацию, где многие почти не пользуются. Вариант по потреблению (Recall.ai) ничего не стоит в простое и масштабируется с записанными часами – это подходит продукту, который транскрибирует только тогда, когда его пользователи реально проводят звонки.

Вот арифметика «купить или построить» в цифрах. Допустим, вы разрабатываете инструмент для продаж, и ваши клиенты в сумме проводят 10 000 часов записанных звонков в месяц. На платформе Recall.ai это составляет 10 000 × ($0,50 за захват + $0,15 за транскрипцию) = 10 000 × $0,65 = $6 500 в месяц на захват и транскрипцию – к этому добавляется ваша модель резюмирования и хранилище. Выиграет ли этот подход перед оплатой за пользователей – зависит исключительно от того, сколько пользователей приходится на эти 10 000 часов. Именно поэтому цифры нужно считать, а не гадать. Полная модель расходов – в уроке про реальную стоимость ИИ в видеопродуктах.

Что таблицы фич умалчивают: согласие и закон

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

В США закон о записи разговоров различается в зависимости от штата. В 39 штатах и округе Колумбия действует правило согласия одной стороны: если вы участвуете в разговоре, вы можете его записывать. В 11 штатах – включая Калифорнию, Иллинойс и Пенсильванию – требуется согласие всех сторон, то есть каждый участник должен дать согласие до начала записи. По GDPR в ЕС необходимо правовое основание и чёткое, информированное согласие на фиксацию чьего-либо голоса. Главный момент, на котором команды часто ошибаются: присутствие бота в списке участников само по себе не является юридическим согласием. Ни одна крупная юрисдикция не считает «они видели Notetaker» достаточным для информированного согласия, которое требует закон. Запись без бота ещё более незаметна, поэтому обязанность раскрывать факт записи становится ещё важнее, а не менее.

Два новых риска заслуживают внимания. Первый – биометрия: этап распознавания говорящего, используемый для диаризации, формирует «голосовой отпечаток» (voiceprint). В юридическом анализе 2026 года этот отпечаток всё чаще признаётся защищённым биометрическим идентификатором по законам вроде иллинойсского BIPA – то есть обычная функция «кто что сказал» может потребовать обязательного согласия пользователей (opt-in). Второй риск – рост судебных исков: коллективные иски конца 2025 года – Brewer v. Otter.ai в Калифорнии и Cruz v. Fireflies.ИИ в Иллинойсе – как раз утверждают эти нарушения: боты перехватывали коммуникации и собирали биометрические голосовые данные без согласия всех участников. Каким бы ни был итог этих дел, они уже заставили корпоративных юристов действовать осторожнее и во многом объясняют, почему набирают популярность решения без ботов и self-hosted архитектуры.

Если вы строите транскрипцию в продукт, закладывайте согласие с самого начала: раскрывайте присутствие ИИ до того, как он включится, фиксируйте согласие и давайте реальную возможность отказаться – та же дисциплина раскрытия, что в уроке про EU AI Act и инженерию раскрытия. Обязанность прозрачности из статьи 50 EU AI Act делает это продуктовым требованием в ЕС, а не любезностью.

Как выбрать – короткий путь решения

Уберите списки функций, и выбор сводится к нескольким вопросам по порядку.

Рисунок 4. Путь решения. Четыре вопроса ведут к одному из четырёх паттернов; юридическая проверка применима ко всем.

Должна ли транскрипция быть встроена в ваш софт? Если да – вы выбираете между арендой API распознавания, например Recall.ai, и развитием собственного пайплайна обработки в реальном времени. Если нет – вы покупаете решение, и тогда задайте себе: все ли встречи проходят на одной платформе? Если да – встроенный ИИ платформы станет самым дешёвым и простым решением. Если вы используете несколько платформ, оцените, насколько важна конфиденциальность или насколько клиенты скептически относятся к ботам: если да – десктопное приложение без бота остаётся незамеченным; если нет – облачный бот обеспечивает максимальный охват и богатые интеграции. В любом случае перед включением любого решения проверьте требования закона о согласии в штатах и странах, где вы работаете.

Где здесь Фора Софт

Мы создаём видеопродукты, в которых реализованы функции транскрипции – конференц-платформы, телемедицинские приложения, e-learning, OTT-сервисы, – поэтому регулярно сталкиваемся с выбором «купить или построить» с инженерной точки зрения. Когда транскрипция может быть сторонним решением, мы помогаем выбрать подходящий паттерн и интегрировать его. А когда она должна быть встроена в продукт – например, автоматическая заметка телемедицинского приёма, сгенерированная прямо на платформе; живые субтитры, отправленные каждому участнику вебинара; резюме продаж, отображённое на дашборде клиента, – мы реализуем это на пайплайне реального времени на базе WebRTC. Таким образом, захват аудио остаётся нативным для приложения, а не подключается через внешнего бота. При этом согласие пользователя и прозрачность обработки данных закладываются ещё на первом спринте. Паттерны, о которых идёт речь в этом уроке, – те же самые, которые мы обсуждаем с клиентами, когда они решают: приобрести готовое решение или развивать функцию самостоятельно.

Главные выводы

  • Инструменты в первую очередь различаются паттерном захвата, а не функциональными возможностями – именно этот выбор определяет уровень приватности, стоимость и применимость в конкретном продукте.
  • Существует четыре паттерна: нативный ИИ платформы, облачный бот, десктопное приложение без бота, инфраструктурный API для самостоятельной разработки.
  • На чистом звуке любой ведущий инструмент обеспечивает точность около 90–97%; цифра с главной страницы – слабый критерий для выбора.
  • Облачные боты заметны и удобны в использовании; приложения без бота остаются невидимыми, но работают локально и привязаны к одному пользователю.
  • Видимость бота не означает автоматического юридического согласия; действуют законы штатов, требующие согласия всех сторон, GDPR и защита биометрических данных, включая голосовые отпечатки.
  • Интеграцию можно реализовать двумя способами: арендой API захвата или расширением собственного WebRTC-пайплайна.

Что почитать дальше

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.