Голосовой AI-менеджер на входящих звонках B2B-торговли

Контекст бизнеса

Заказчик это производственно-торговая компания федерального масштаба, дистрибьютор инженерного оборудования для систем водоснабжения, отопления и газоснабжения. Работает с начала 1990-х. В каталоге свыше 20 000 SKU от европейских и российских производителей. Клиентская база это крупные B2B-клиенты. Производство, торговля, строительство, инфраструктурные объекты.

Объёмы. Свыше 100 отгрузок в день, география вся РФ. Входящая телефонная линия (московский номер плюс 8-800) это основной канал первичного контакта.

Команда первой линии. 5 операторов. Полная стоимость рабочего места (зарплата, взносы, ДМС, рабочее место, супервизия, найм с учётом текучки) около 95–110 тыс ₽ на человека в месяц.

Проблемы, ради которых заказчик пошёл в проект

1. До 20% пропущенных звонков в часы пик. Клиент звонил трижды, потом уходил к конкуренту. Потерянный звонок не оставляет следа в отчёте, поэтому эту выручку никто не считал. 20%пропуска в пик
2. 100% потерянных звонков в ночь и выходные. Заказы из регионов в часовых поясах +3…+7 от Москвы терялись целиком.
3. Текучка первой линии 30–40% в год. Новый оператор выходил на продуктивность 2–3 месяца, и всё это время качество было ниже.
4. 60–70% звонков типовые справочные («есть ли товар, какая цена, когда отгрузите»). Дорогой обученный человек тратил день на функцию справочного бюро.
5. Справочный звонок занимал 4–6 минут. Параллельно оператор не успевал заполнять карточку клиента в CRM, данные терялись.

Почему не наняли ещё людей

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

• Найм не лечит ночь. Чтобы закрыть пояса +3…+7, нужна полноценная вторая и третья смена. Это не «ещё один оператор», это удвоение штата ради нескольких заявок за ночь. Экономика не сходится.
• Найм усиливает текучку, а не гасит её. Чем больше первая линия, тем больше людей в зоне с оттоком 30–40% в год. Это постоянный конвейер найма и обучения, который сам стоит денег.
• Дорогой ресурс остаётся на дешёвой функции. Нанимая людей под справку, мы консервируем проблему. Квалифицированный сотрудник продолжает зачитывать остатки со склада вместо работы со сложными сделками.

Вывод был не «уволить людей и поставить робота». Вывод был «снять с людей рутину, которую машина делает не хуже, и направить людей туда, где машина бесполезна». Это разные проекты с разной этикой и разными рисками.

Решение коротко

Голосовой ИИ-агент первым отвечает на входящий звонок и ведёт диалог голосом. Что он делает.

• Опознаёт клиента по номеру через 1С.
• Ищет товары в каталоге через семантический поиск (RAG).
• Получает остатки и цены через REST API 1С, живые данные, не кэш.
• Оформляет типовые повторные заказы напрямую в 1С.
• При сложном вопросе или явном запросе «дайте человека» переключает на оператора с подгруженным контекстом разговора.

С коммерческой стороны агент закрывает три сценария.

1. Справочный звонок. «Есть ли труба X на складе, какая цена, когда отгрузите». Ответ за 1–2 секунды.
2. Первичная квалификация лида. Кто звонит, что нужно, объём, сроки, регион. Агент заполняет карточку лида в CRM и переводит на живого менеджера, если квалификация прошла.
3. Повторный заказ действующего клиента. Контрагент опознан по номеру, история есть, агент собирает заказ и передаёт на подтверждение менеджеру.

За живыми менеджерами осталось то, где машина бесполезна. Новые сделки от 500 000 ₽, нестандартные позиции под заказ, споры по качеству, переговоры по отсрочке, рекламации.

Купить, собрать или гибрид

Это решение принимается до архитектуры. От него зависят экономика и зависимость от поставщика.

Готовый облачный SaaS «под ключ». Быстро, без своей команды, оплата за минуту. Минута ИИ-разговора стоит порядка 14 ₽ (распознавание ~5 ₽, языковая модель 4–6 ₽, синтез ~1.5 ₽ плюс телефония и наценка). На 3000 звонков в месяц по 3 минуты это около 126 000 ₽ только за минуты, без интеграции с 1С, которую коробочный SaaS обычно не умеет. Плюс данные клиентов уходят на сторону поставщика, что отдельно больно по 152-ФЗ.

Полностью своё на открытых компонентах. Дороже на старте (команда и GPU), но минута почти бесплатна, данные не покидают контур, интеграция с 1С под полным контролем. Минус — на сложных диалогах локальная модель уступает облачной.

Гибрид, который выбран. Распознавание и синтез свои, на локальном GPU. Языковая модель двухконтурная. Простой вопрос обрабатывает локальная модель бесплатно, сложный уходит в российское облако с оплатой за токены, причём текст перед отправкой обезличивается. Низкая стоимость минуты на массовом потоке, контроль над данными, качество облачной модели там, где оно реально нужно.

Архитектура одним кадром

Входящий звонок приходит в Asterisk 22. Stasis-приложение через ARI WebSocket поднимает медиа-канал, через externalMedia поток RTP уходит в Python-воркер. Воркер режет аудио на сегменты по VAD, гонит в потоковый ASR (T-one для телефонии, GigaAM v3 как второй контур), финальный текст идёт в языковую модель. Модель работает с двумя инструментами. Это REST в 1С и retrieval из векторного индекса. Ответ потоково в синтез речи, обратно в RTP-канал. Параллельно MixMonitor пишет двухканальный stereo WAV.

Локальный контур (телефония, распознавание, синтез, локальная модель, база) работает на своём железе и не падает вместе с интернетом. Облачная модель — единственный внешний компонент, и на неё есть автоматический запасной путь.

Технический стек и архитектурные решения

4.1. Телефония на Asterisk 22 LTS, ARI + externalMedia

Слой интеграции переписан относительно типовых решений. AGI для realtime-стриминга это плохой выбор. AGI блокирующий, спавнит процесс на каждый звонок, не даёт нормально стримить медиа. Переход на ARI Stasis + externalMedia стабилен с Asterisk 18 и остаётся рабочим продакшен-паттерном на Asterisk 22 LTS. Stasis-приложение получает StasisStart, через POST /channels/id/externalMedia поднимаются два RTP-сокета (slin16, 20 ms ptime), Python-воркер слушает их через asyncio / aiortc. Для более простой интеграции есть альтернатива AudioSocket (TCP, сырой PCM в обе стороны). На масштабе externalMedia точнее по RTP-таймингу, поэтому выбран он.

Подводные камни, которые реально стреляют.

• NAT и jitter. Если Asterisk и медиа-воркер не в одном L2-сегменте, нужны directmedia=no, force_rport, rtp_symmetric=yes. Между ДЦ идёт IPsec/WireGuard, не голый RTP.
• Подавление эха. Без agc, denoise, формата 16 кГц mono распознавание глохнет на эхе от плохих SIP-телефонов клиента.
• Перекодирование кодеков. Входящий G.711 μ-law → slin16 на Asterisk даёт +5–10 ms и +20% CPU. На 100 одновременных звонков нужен выделенный DSP-сервер.
• Буфер потока. ARI externalMedia шлёт 20 ms фреймы, потоковый ASR хочет сегменты 200–500 ms. Буферизация в Python через collections.deque с нарезкой по VAD.

4.2. Русский ASR. Почему не Whisper «по умолчанию»

Главное отличие от типовых проектов 2024 года. Для русской телефонии на 8 кГц generic-Whisper уже не оптимален. Специализированные открытые модели ошибаются на телефонии в 1.5–2 раза реже — это единственный вывод, который устойчив на всех публичных замерах. А вот кто из специализированных первый, зависит от тестового набора. На бенчмарке команды T-one впереди T-one, на независимом замере автора Vosk впереди GigaAM. Поэтому честный выбор движка делается не по чужим таблицам, а замером на записях конкретного заказчика в пилоте.

• T-one (Apache 2.0) — потоковый ASR-конвейер, Conformer-CTC на 71 млн параметров, заточен под телефонию. Держит streaming сегментами по 300 мс и запускается даже на CPU. В нашем пилоте на записях заказчика показал лучший результат — выбран основным.
• GigaAM v3 (MIT) — модель на 220–240 млн параметров, обучена на 700 тысячах часов русской речи, умеет пунктуацию и нормализацию. На независимых бенчмарках идёт первой, у нас — второй контур для сложных диалогов и постобработки записей. Замена местами с T-one не меняет архитектуру.
• faster-whisper Large-v3 (CTranslate2-порт, в 2–4 раза быстрее официального Whisper) оставлен как запасной вариант для нетелефонного аудио. На русской телефонии уступает обеим специализированным моделям по точности.

Замеры на проде. На чистом канале доля ошибок держится 8–12%. На терминологии (артикулы, латиница, цифро-буквенные коды DN50/PN16) растёт до 15–22%. Лечится словарём терминов, постобработкой через GigaAM и дообучением на записях.

4.3. Языковая модель с маршрутизацией по сложности

В реальной эксплуатации не работает «одна модель на всё». Поэтому сделан маршрутизатор.

• Простые запросы (наличие, цена, режим, статус заказа) идут в локальную Qwen3 (класс 7–8B, лицензия Apache 2.0, коммерческое использование без ограничений) через self-hosted vLLM. Задержка 200–400 ms, стоимость близка к нулю.
• Сложные сценарии (техконсультация, подбор аналога, нестандартная отгрузка) идут во внешний API. YandexGPT 5.1 Pro или GigaChat 2 — оба резиденты РФ, оплата в рублях, GigaChat при этом сертифицирован ФСТЭК, что важно для регулируемых отраслей.
• Перевод на человека срабатывает, если у модели confidence < threshold, или два раунда не сошлись с клиентом, или клиент явно сказал «дай человека».

4.4. RAG на pgvector в той же PostgreSQL, что и состояние диалога

На проде стоит pgvector в основной PostgreSQL. Одна база держит всё (диалоги, метрики, эмбеддинги), один бэкап, одна миграция. ChromaDB на стенде падал на 500k+ векторов. Qdrant хорош, но pgvector с HNSW-индексом полностью покрывает наш масштаб. До 1 млн векторов p95 ниже 50 ms, до 5 млн — 80–140 ms. Каталог на 20 000 SKU после нарезки на чанки это десятки тысяч векторов, глубоко в зелёной зоне.

Эмбеддинги. Для русской B2B-терминологии лучший retrieval в 2025–2026 даёт связка BGE-M3 + reranker. Модель multilingual-e5-large идёт близко и оставлена как альтернатива. Обе self-hosted на том же GPU, обе обходят облачные эмбеддинги OpenAI на нашей терминологии.

4.5. TTS. Реалистичный и лицензионно чистый выбор

От клонирования голоса оператора отказались. 152-ФЗ требует согласия на обработку голоса, риски подделки голоса в РФ растут, стандартный голос по фактическому качеству диалога не хуже клонированного.

4.6. 1С-интеграция через FastAPI-шлюз, не прямой REST

На реальных контурах типичны три варианта.

1. HTTP-сервисы 1С (нативно, тянет до ~50 RPS на нормально настроенной 1С).
2. OData v3 из коробки 1С 8.3. Для read-only справочников ок, для записи кривовато.
3. Шина (1С:КД, RabbitMQ/Kafka) для крупных контуров.

Стандартизирован контракт через FastAPI-шлюз между инструментами модели и 1С. Модель думает, что у неё чистый REST, шлюз решает, OData это или HTTP-сервис. Это спасает при смене подрядчика 1С — переписывается только шлюз.

Латентность. Честные цифры, не маркетинг

«1–2 секунды отклика» в типовых КП это про лучший случай. Честная картина от конца речи клиента до первого слова робота, p50 на проде, выглядит так.

То есть честно. 1.0–1.3 секунды до первого слова на простых запросах, 2.0–2.5 сек на сложных с обращением в 1С и RAG, p95 до 3 сек. Это согласуется с публичными замерами голосовых агентов 2026 года, где даже сквозные speech-to-speech модели стартуют от 0.8 секунды. Обещания «мгновенно» — повод усомниться в честности подрядчика.

Где можно срезать ещё

• Частичные транскрипты потокового ASR + ранний запуск модели на стабильном префиксе. Экономит 150–300 ms, рискует ошибиться. Streaming T-one здесь играет в нашу пользу.
• Спекулятивный пред-запрос в 1С на частые запросы. Экономит 100–200 ms, усложняет.
• Маршрутизация на эмбеддингах вместо генерации. Экономит 50–80 ms.

Эксплуатация и наблюдаемость

По каждому звонку пишется в ClickHouse через Vector/Fluent-bit вот что.

• call_id, caller_id, agent_id, длительность, число тёрнов.
• На каждый тёрн vad_duration_ms, asr_latency_ms, asr_confidence, transcript, llm_model, llm_latency_ms, tool_calls[].
• intent_detected, confidence, fallback_to_human с причиной.
• Тональность клиента на каждой реплике через мелкий классификатор. Нужна для алертов «клиент злится, выключи бота».

Реалистичный SLA на 100+ звонков/день

«99.9% uptime» в типовых КП относится к сетевому железу, не к системе целиком. Любое обновление облачной модели, любая ошибка в RAG-индексе, любая правка скрипта Asterisk открывает окно недоступности. Честный SLA равен 99.5%.

Что пошло не так и как чинили

Реалистичные инженерные детали из пилота. Без них кейс читается как маркетинг.

1. Галлюцинации на паузах. На первой неделе бот вставлял в расшифровку «продолжение следует» в моменты тишины. Причина — отсутствие VAD на входе. Поставили Silero VAD, галлюцинации ушли.
2. Дубли заказов в 1С после таймаута. Инструмент модели повторял POST заказа, если 1С отвечала дольше таймаута. Закрыли Idempotency-Key плюс дедуп в Redis на 24 часа.
3. Эхо от дешёвых SIP-телефонов клиента. ASR ловил собственный голос бота как речь абонента. Включили подавление эха, agc и denoise, привели вход к 16 кГц mono.
4. Артикулы и иностранные бренды распознавались плохо. Латиница и коды (DN50, PN16) давали WER за 20%. Завели словарь терминов и постобработку через GigaAM v3.
5. Бот зацикливался на «уточните пожалуйста». При плохом распознавании модель просила переспросить по кругу. Ввели жёсткие правила разрыва петли (счётчик раундов, стоп-слова, порог по тональности).
6. Скачок задержки в часы пик. На пике локальная модель упиралась в GPU, p95 рос. Развели простое на локальную, сложное на облачную, добавили кэш частых ответов.

Бизнес-кейс и экономика

Метрики, которые я готов защитить

Везде ниже цифра идёт диапазоном, не точкой. Нижняя граница измерена по факту за первые 90 дней пилота. Верхняя это экстраполяция при сохранении того же качества.

Что я НЕ ставлю в метрики

• «Клиент не отличает робота от человека». Часть отличает. Это нормально, управляется приветствием.
• «Рост среднего чека на 10% за счёт допродаж». Не воспроизвели в контролируемых условиях. Гипотеза.
• «Рост выручки на 20%». Невозможно отделить вклад агента от сезонности и работы живых менеджеров.

Расчёт окупаемости и что в него НЕ вошло

Вложения (разовые)

Ежемесячные расходы

Два сценария, оба на честной базе

Отдача 70–130% годовых это то, что я готов поставить в инвестиционный паспорт и защищать перед собственником. ROI 1041% и окупаемость 1.15 месяца из рекламных материалов это лозунг, посчитанный от допущения, что агент заберёт всю упущенную выручку. Так не бывает.

Что в расчёт НЕ вошло. Рост среднего чека от допродаж (гипотеза), рост лояльности от «всегда отвечают» (реален, но честно не оцифровывается), снижение нагрузки на найм (есть, но не ставлю, чтобы не задваивать с высвобождением людей).

Когда сценарий подходит и когда нет

Подходит, если

• Минимум 1 500 входящих звонков/мес. Если меньше, окупаемость растягивается за горизонт планирования.
• Доля типовых справочных звонков от 50% и выше. Это критическая граница. Если агент закрывает меньше половины, экономика разваливается.
• Есть учётная система (1С или аналог) с API или возможностью допилить API.
• Существует структурированный каталог. Документация, прайс, описания товаров. Поиск нужно чем-то кормить.
• Есть Asterisk, MikoPBX, Mango Office или любая АТС с возможностью внешнего SIP-моста.

Не подходит, если

• Звонок это уже зрелая сделка с индивидуальной комплектацией. Агент не заменит инженера-консультанта.
• Меньше 500 входящих в месяц. Проще нанять ещё одного человека.
• От 500 до 1 500 звонков — пограничная зона. Экономику считаю индивидуально, и нередко рекомендую подождать.
• В компании нет внутреннего владельца процесса. Агент требует регулярного разбора логов и обновления знаний. Если этим некому заниматься, через 3–4 месяца система начинает врать и терять клиентов. Это главная причина провалов, и она не техническая.

Что ИИ-менеджер НЕ делает

• Не ведёт переговоры о цене. Скидки, отсрочка, индивидуальные условия всегда на человека.
• Не принимает претензии. При распознавании конфликтной интонации идёт мгновенная эскалация супервайзеру.
• Не продаёт то, чего нет в 1С. Если позиции нет, честно говорит «уточню у менеджера, он перезвонит». Без галлюцинаций по остаткам.
• Не работает в тишине. Звонок логируется, разговор записывается, расшифровка попадает в CRM.
• Не заменяет отдел продаж. Это первая линия. KPI отдела продаж остаются на живых людях.

Стратегические сценарии применимости

После этого проекта я выделил 4 устойчивых сценария, где голосовой ИИ-агент даёт измеримый эффект для среднего бизнеса (50–500 человек) в РФ в 2026.

Сценарий 1. Дистрибуция / B2B-торговля с большим каталогом

Это наш кейс. Условия такие. 1 000+ SKU в активном каталоге, от 60% звонков типовые, ERP с REST API, B2B-клиенты с карточкой в ERP. Типичная экономика. Окупаемость 6–10 месяцев, высвобождение 40–60% загрузки первой линии.

Сценарий 2. Сервисное обслуживание / запись на визит

Медицина, автосервис, ремонт, репетиторские центры, салоны красоты. Закрывает запись, перенос, отмену, ответ на «какие услуги», «сколько стоит».

Сценарий 3. Финансы, лизинг, страхование. Квалификация лида

Условия такие. Большой поток лидов с маркетинга, квалификация по 5–10 параметрам перед передачей менеджеру, скоринговая модель как источник решения. По регуляторике повышенные требования по 152-ФЗ, 115-ФЗ, 161-ФЗ. Модель с правом давать рекомендации по продуктам это отдельный регуляторный кейс.

Сценарий 4. Государственный сектор и справочные функции

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

Где голосовой ИИ-агент НЕ работает

• Сложные B2B-продажи длинного цикла (от 1 млн ₽, проектные поставки). Клиент хочет говорить с экспертом.
• VIP-обслуживание. Премиум-клиенты ожидают человека.
• Конфликтные / экстренные ситуации. Нужен человек с эмпатией и юридической ответственностью.
• Многоязычность с сильными акцентами. Качество распознавания падает.

Как это масштабируется

От одной линии к N и от одного сценария к нескольким.

• По линиям. Старт с одной из пяти линий на пилоте. Узкое место не телефония (Asterisk держит сотни каналов), а инференс. T-one дёшев по ресурсам (71 млн параметров, работает даже на CPU) и параллелится широко, узкое место — локальная языковая модель на GPU. Одна RTX 4090 (24 ГБ) держит порядка 25–30 параллельных диалогов. Пик в кейсе 15 параллельных, прошёл с запасом. Дальше горизонтально. Вторая GPU-нода или L40S (48 ГБ), которая держит 100+ потоков распознавания.
• По сценариям. Сначала один сценарий (справочный звонок), затем квалификация лида и приём повторного заказа. Каждый сценарий это отдельный набор интентов, промптов и инструментов поверх той же платформы. Платформа не меняется, растёт библиотека сценариев.
• По нагрузке на пиках. Маршрутизатор разводит простое на локальную модель, сложное на облачную. Кэш частых ответов снимает обращения к модели вообще. Это держит p95 в рамках при росте объёма.

План внедрения по фазам

Голосовой ИИ-агент не внедряется одним большим запуском. Только три последовательные фазы, на каждой границе решение «продолжаем или останавливаемся».

Параметры фаз совпадают с услугой «Внедрение ИИ» на этом сайте. Пилот 4 недели от 400 000 ₽, рабочий вариант 8 недель от 1 000 000 ₽, эксплуатация 3–6 месяцев. После пилота решаем, продолжаем или останавливаемся без переплат.

Кто в команде

• Со стороны заказчика. Внутренний владелец процесса (руководитель продаж или клиентского сервиса), администратор 1С, системный администратор АТС.
• Со стороны внедрения. Архитектор-постановщик, инженер интеграций, инженер по диалогам и распознаванию.
• Я как внешний ИТ-директор. Держу границы фаз, экономику, регуляторику и риски. Слежу, чтобы проект не превратился в бесконечную доработку без выхода на окупаемость.

Работа с людьми. Самая недооценённая часть

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

Как готовить операторов первой линии

Что НЕ работает

• «Робот вас не заменит, не волнуйтесь». Операторы видят план и не верят.
• «Это просто инструмент». Операторы видят, что инструмент берёт их хлеб.
• «Будет переобучение». Операторы спрашивают «куда?», не получают ответа.

Что работает

1. Честность с первого дня. «Через 6 месяцев нужно 2 человека вместо 5. Есть три пути. Переход на линию работы с крупными клиентами, роль куратора робота, выходное пособие плюс рекомендации».
2. Финансовые гарантии. Тем, кто остаётся, повышение оклада на 30–50% (растёт сложность работы). Тем, кто уходит, 3 оклада плюс рекомендации.
3. Участие в проекте. Лучшие операторы учат робота. Их формулировки становятся образцом, они первыми разбирают ошибки. Человек, который строил систему, не саботирует её.
4. Прозрачные метрики. Команда видит, что робот делает и чего не делает, какие ошибки, как растёт качество. Не «чёрный ящик».

Что говорить клиентам

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

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

Регуляторика. Что обязательно в РФ

Раздел, который проваливает большинство презентаций ИИ-проектов. И именно он становится миной при первой проверке.

152-ФЗ, персональные данные

ФИО, телефон, email клиентов в карточке 1С это ПДн. Голос становится биометрическими ПДн, только если используется для установления личности. Здесь клиент опознаётся по номеру телефона, поэтому записи ведутся в общем режиме ПДн, и это решение зафиксировано в модели обработки. Биометрия с 1 сентября 2025 требует отдельного письменного согласия, а штрафы за утечку биометрии выросли до 15–20 млн ₽ — поэтому «не лезть в биометрию» это сознательное архитектурное решение, а не случайность.

• Уведомление в РКН (ст. 22). Форма утверждена Приказом Роскомнадзора № 180 от 28.10.2022. Подавать обязательно, потому что формируется база клиентов-граждан РФ в 1С. С 30 мая 2025 за неподачу штраф юрлицу 100–300 тыс ₽.
• Политика обработки ПДн на сайте (ст. 18.1).
• Согласие на запись разговора (ст. 6 и 9). Явное уведомление в первой фразе плюс ссылка на политику. С 1 сентября 2025 согласие на ПДн должно быть отдельным, не спрятанным в другие документы. На спорной трактовке «продолжение разговора = согласие» легко получить претензию, поэтому уведомляем явно.
• Локализация ПДн в РФ (242-ФЗ, ст. 18 ч. 5 152-ФЗ). 1С и записи лежат на своём железе или в РФ-резидентных облаках. Не AWS, не GCP.
• Уровень защищённости ИСПДн. Для типичного коммерческого B2B это УЗ-3 или УЗ-4 (ПП РФ № 1119, Приказ ФСТЭК № 21). Пакет документов 80–100 страниц, готовится 4–6 недель.
• Утечка данных карается отдельно. Несообщение об утечке стоит юрлицу 1–3 млн ₽. Поэтому записи и расшифровки в защищённом контуре, с разграничением доступа и журналом «кто что когда».

Облачные модели и обезличивание

Основной путь — РФ-резидентные YandexGPT и GigaChat, без трансграничной передачи. Перед отправкой сложного диалога в облако текст обезличивается. Телефон → [PHONE], ФИО → [NAME], адрес → [ADDRESS]. Запросы с явными ПДн вообще не уходят в облако — их обрабатывает локальная Qwen3 на своём GPU. Двухконтурная схема существует ровно для того, чтобы не нарушить локализацию данных.

Право клиента на разговор с человеком

Прямой общей нормы «робот обязан переключить на человека» в РФ на июнь 2026 нет, есть отраслевые требования (финансы, взыскание по 230-ФЗ) и внесённый в январе 2026 законопроект о маркировке робозвонков. Действующее ядро ожиданий регулятора и хорошей практики это информировать клиента, что отвечает автоматизированная система, плюс возможность переключения на человека. Мы строим систему так, будто норма уже действует. Это дешевле, чем переделывать потом.

Зависимость от вендора и запасной вариант

Это раздел, который в большинстве КП отсутствует. На уровне ИТ-директора он обязателен.

Риск 1. Облачная модель недоступна или подняла цены

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

Что заложено в архитектуру.

• Двухконтурная модель с автопереключением. Основная облачная (YandexGPT / GigaChat), запасная локальная Qwen3 на своём GPU. Просадка качества при переключении ~15–20%, но звонки не теряются.
• Автоматический триггер. Ошибки облака больше 3 раз за 60 секунд — весь поток уходит на локальную модель, ИТ-директору приходит оповещение.
• Кэш частых ответов вообще без обращения к модели.

Отдельный плюс выбранного стека распознавания и синтеза. T-one (Apache 2.0) и GigaAM v3 (MIT) полностью self-hosted, лицензии пермиссивные. Зависимости от зарубежного вендора на пути распознавания и синтеза нет вообще.

Риск 2. Пилот провалится, что делаем

Сценарий такой. Пилот показал, что нужного качества не достичь. Вот активы, которые не теряются.

1. База каталога с поиском. Структурированная база 20 000 SKU с эмбеддингами. Переиспользуется в поиске на сайте, в чат-боте, в помощнике менеджеров.
2. REST API 1С через FastAPI-шлюз. Эндпоинты переиспользуются в любом канале (сайт, мобильное приложение, партнёрский API).
3. Библиотека сценариев диалогов. Идёт на обучение операторов и скрипты звонков.
4. Мониторинг и аналитика звонков. Stereo-запись, расшифровка, классификация исходов. Ценны сами по себе, даже без робота.

Доля «затопленных» активов при полном откате около 30%. Остальные 70% переиспользуются.

FAQ, частые вопросы на ознакомительном звонке

Что обсуждаю на ознакомительном звонке

30 минут, бесплатно. На звонке отвечу на три вопроса.

1. Подходит ли сценарий вашему профилю звонков (нужны цифры по объёму, доле типовых, наличию API).
2. Какой реалистичный диапазон окупаемости в вашем случае.
3. С чего начинать. Пилот на одной линии, аудит инфраструктуры или сразу полноценный проект.

По итогам звонка отдам короткий документ с оценкой потенциала проекта и тремя вариантами плана (минимальный, оптимальный, активный).

Если задача шире звонков — мониторинг, инциденты и заявки — посмотрите, как я ставлю техподдержку и эксплуатацию ИТ на автоматизацию.