Телефония с ИИ перестала быть экспериментом. Вендоры либо встраивают модели в платформу, либо продают отдельные «AI add-on» с внешними API и сюрпризами в биллинге. 3CX Enterprise / AI Edition — пример первого подхода: ИИ, контакт-центр и интеграции упакованы в одну редакцию, а не размазаны по маркетплейсу.
Для архитектора UC это интересно не маркетингом «самая низкая цена в отрасли», а моделью связки: голос → транскрипция → аналитика → CRM/BI → автоматизация. Интеграции downstream проработаны хорошо; upstream к LLM — нет: OpenRouter и custom providers в UI не предусмотрены. Ниже — что входит в AI Edition, где схема сильная и где обрывается.
Для кого эта редакция
3CX позиционирует AI Edition для среднего и крупного бизнеса с большим потоком вызовов, распределёнными командами и требованиями к непрерывности. Лицензирование — по числу одновременных вызовов (SC), а не по количеству пользователей. Для IT-администратора без глубокого телеком-бэкграунда это плюс: одна годовая подписка, функции без скрытых надстроек.
Развёртывание — на выбор:
- 3CX Hosted (управляемый хостинг вендора)
- собственное облако
- on-premise
Последний пункт критичен для финансов, здравоохранения и любой среды, где голосовые данные не должны уходить в публичное облако без явного решения.
Стек AI-функций: не один «чат-бот», а цепочка
На странице AI Edition и в релизах V20 Update 8 (agentic AI) 3CX описывает не разрозненные фичи, а конвейер обработки коммуникаций:
| Слой | Что делает | Зачем архитектору |
|---|---|---|
| ИИ-секретарь / receptionist | Принимает входящие, маршрутизирует, отвечает на типовые вопросы | Снижает нагрузку на операторов и IVR-деревья |
| ИИ-агенты (OpenAI) | Первая линия, голосовая почта, резюме звонков, sentiment | Автономные сценарии без постоянного присмотра человека |
| ИИ ПА (personal assistant) | Персональный ассистент для сотрудника | Не только для call center — для всей организации |
| Транскрипция + диаризация | Текст разговора с разделением по спикерам | Точный call log, compliance, поиск по записям |
| Резюме и анализ настроения | Сжатие длинных разговоров, оценка тона клиента | QA, обучение, эскалация проблемных кейсов |
| ИИ-аналитика | Отчёты, дашборды, мониторинг в реальном времени | SLA, удовлетворённость, эффективность команд |
Важный архитектурный момент: агенты в Update 8 получили Knowledge Sources — базы знаний из Admin Console, привязанные к конкретному агенту. Это уже не «подключили GPT и надеемся», а retrieval-augmented сценарий внутри АТС: агент тянет корпоративные факты во время звонка или чата.
По умолчанию для OpenAI-сервисов указан gpt-5-mini (баланс цена/качество для типичных PBX-нагрузок); модель можно сменить вручную.
Транскрипция: облако, свой движок, GPU
Здесь 3CX показывает зрелую двухконтурную модель — редкость среди SMB/Mid-market PBX:
- 3CX Cloud Transcription — быстрый старт, минимум инфраструктуры.
- Transcription Engine Server — отдельный Linux-хост (on-prem или private cloud), ставится командой из Admin Console (
Admin → Integrations → Transcription). Требует Enterprise/AI и 16SC+.
Локальный движок рассчитан на Nvidia GPU с ≥24 GB VRAM (в community обсуждают RTX 40xx/ADA, L4 на грани, в перспективе — ARM/GB10). Автообновление сервера транскрипции — по расписанию (воскресенье, 01:00 по времени сервера).
Альтернативы в экосистеме: OpenAI Whisper, Google Cloud Speech API — для тех, кто уже стандартизировал провайдера распознавания.
Вывод для проектирования: можно начать с облака, а при росте требований к конфиденциальности переключить контур на свой Transcription Engine, не меняя АТС. Голос остаётся в периметре, а downstream-интеграции (CRM, BI) продолжают получать те же метаданные.
Интеграции: почему это хороший эталон
Именно блок интеграций на странице AI Edition — то, что стоит смотреть архитектору. 3CX не ограничивается «есть REST API», а называет конкретные точки стыковки в корпоративном ландшафте:
Голос (3CX PBX)
│
├─► Microsoft Teams Direct Routing
├─► CRM (нативные коннекторы + API)
├─► Power BI
├─► Grafana
├─► PostgreSQL (хранилище CDR/метаданных)
├─► MS 365 / Google Workspace
├─► Live Chat, WhatsApp, SMS
└─► Call Flow Designer + API → автоматизация процессов
Что из этого особенно полезно
Microsoft Teams Direct Routing — голос остаётся на 3CX, Teams получает номера и маршрутизацию. Для гибридных сред (SFB/Lync-наследие, M365, но своя АТС) это привычный паттерн; AI-слой накладывается на тот же SIP-транк.
Power BI и Grafana — готовые векторы для операционной и executive-аналитики: не экспорт CSV раз в неделю, а поток событий вызовов, очередей, sentiment. Для контакт-центра это закрывает разрыв между «телефония работает» и «руководство видит KPI».
PostgreSQL — явный акцент на свой data plane: метаданные звонков в реляционном хранилище, откуда их подхватывают ETL, дашборды или внутренние ML-пайплайны.
API + Call Flow Designer — low-code для маршрутизации и high-code для кастомных workflow (webhook, синхронизация с тикет-системой, триггеры по sentiment).
Схема напоминает то, как современные AI-ready сайты строят слои robots.txt → llms.txt → Schema.org: здесь аналог — PBX → транскрипция/агенты → структурированные данные → корпоративные системы. Разница в том, что источник — живой голос, а не HTML.
Чего не хватает: OpenRouter и custom AI providers
Интеграции с CRM, BI и Teams у 3CX проработаны хорошо. Слой выбора LLM-провайдера — нет. Это заметный архитектурный разрыв, если вы привыкли к паттерну вроде OpenRouter: один OpenAI-compatible endpoint, маршрутизация между моделями и вендорами, failover, оптимизация стоимости.
На странице AI Edition звучит «без надстроек или внешних API», но для встроенных ИИ-агентов реальность другая: в Admin Console (Admin → Integrations → AI) настраивается только прямой OpenAI API — secret key, выбор моделей (gpt-realtime для звонков, gpt-5o-mini для текста), Knowledge Sources через экосистему OpenAI. Поля для custom base URL нет.
В форуме 3CX это уже обсуждали: запрос на свой endpoint (типичный кейс — Azure OpenAI) получил ответ «пока только OpenAI direct, пожелание зафиксировали». То есть ни OpenRouter, ни Azure OpenAI, ни Anthropic/Groq/Mistral не являются first-class опциями в AI Agent wizard.
Голос (3CX PBX)
│
├─► CRM / BI / Teams / PostgreSQL ✓ нативно
│
└─► LLM-провайдер
├─► OpenAI (прямой API) ✓ из коробки
├─► OpenRouter.ai ✗ нет
├─► Azure OpenAI ✗ нет (запрос в roadmap)
└─► свой on-prem LLM ✗ только через обходной путь
Почему это важно архитектору:
- Vendor lock-in на inference. Все агенты, RAG и биллинг Knowledge Sources завязаны на один OpenAI project/key. Мульти-тенантным интеграторам приходится заводить отдельный ключ на каждого клиента — иначе общий пул документов между инстансами (обсуждение на форуме).
- Нет cost routing. Нельзя отправить простые FAQ на дешёвую модель, а сложный screening — на дорогую. OpenRouter как раз решает это одним API; 3CX — нет.
- Нет graceful degradation. При деградации OpenAI или смене модели (Update 8 уже требует вручную авторизовать новые модели в ключе) вы не переключитесь на резервного провайдера из UI.
- Realtime-ограничение. Для голосовых агентов 3CX опирается на
gpt-realtime— модели, которых нет в каталоге OpenRouter. Даже гипотетический proxy не закроет весь стек «из коробки».
Обходной путь — не интеграция, а отдельный проект. Для полностью своей модели остаётся Call Control API: внешнее приложение перехватывает вызовы, само гоняет STT → LLM → TTS и может смотреть куда угодно — OpenRouter, локальный Ollama, корпоративный endpoint. Но это свой voice bot поверх АТС, а не настройка агента в Admin Console за десять минут. Аудиострим в CFD не отдаётся — только SIP-клиент или API-оркестрация.
Для сравнения: в типичном AI-стеке (IDE, CI, внутренние боты) OpenRouter уже стандарт — один ключ, десятки моделей, предсказуемый биллинг. 3CX AI Edition интегрируется с корпоративным периметром отлично, но слой inference остаётся монолитным. Пока 3CX не добавит custom AI providers (хотя бы OpenAI-compatible base URL + выбор модели из списка), архитекторы с multi-vendor стратегией закладывают либо жёсткую зависимость от OpenAI, либо параллельную разработку на Call Control API.
Контакт-центр и UC «вокруг» AI
AI Edition включает не только ИИ, но и расширенный call center: отчёты, wallboards, отслеживание настроения, права на старт/стоп записи, резервирование (failover + standby license). Для глобальных команд — видео до 250 участников на сессию, встроенный MCU (локальный MCU — лицензия 32SC+).
Каналы сообщений (Live Chat, WhatsApp, SMS) идут в той же платформе — агенты и аналитика не привязаны только к PSTN/SIP.
Лицензии и апдейты: на что смотреть перед апгрейдом
Линейка редакций у 3CX сейчас в движении (V20 Update 8):
- PRO — телефония и коллаборация без полного AI-стека
- Enterprise / AI — агенты, расширенная аналитика, интеграции
- Enterprise Plus — для предсказуемых объёмов транскрипции и compliance (8/16/24 SC)
Перед обновлением стоит сверить: объём SC, требования к on-prem транскрипции, авторизацию новых моделей OpenAI в ключе API (миграция с устаревших моделей — вручную).
Когда имеет смысл, а когда нет
Имеет смысл, если:
- высокий объём входящих и нужна автоматизация первой линии без отдельного CCaaS;
- нужен единый вендор для голоса, чатов, видео и AI-аналитики;
- compliance требует локальной транскрипции или чёткого data residency;
- уже есть или планируется стек Teams + Power BI + CRM — 3CX заявляет нативные стыки.
Скептически смотреть, если:
- организация уже глубоко в Microsoft Teams Phone / Copilot и не хочет второй голосовой платформы;
- AI нужен точечно (только summary встреч) — полная AI Edition может быть избыточной;
- нет GPU-инфраструктуры для local transcription, а облачный контур запрещён политикой — придётся закладывать CAPEX или ENT+ с облачной квотой 3CX;
- нужна мульти-провайдерная LLM-стратегия (OpenRouter, Azure OpenAI, on-prem) — встроенные агенты этого не дают, только прямой OpenAI или свой код на Call Control API.
Итог
3CX AI Edition — не «ещё один GPT-бот в IVR», а попытка встроить agentic AI в ядро АТС и сразу вывести результат в привычные корпоративные системы. Для архитектора UC ценность — в целостной карте интеграций downstream: от Direct Routing в Teams до PostgreSQL и Grafana.
Слабое место — upstream к LLM: нет OpenRouter, нет custom providers, нет смены inference-вендора без обхода через Call Control API. Эталонная схема интеграций обрывается на границе «чья модель отвечает в трубку».
Полезно использовать эту страницу как чек-лист при проектировании любой voice+AI платформы: где транскрибируем, где храним, кто потребляет метаданные, кто поставляет LLM и можно ли сменить провайдера без переписывания агентов. Даже если финальный выбор — не 3CX, вопросы останутся те же.
Ссылки
