amorson.me

Он-премис: платформа в контуре заказчика

Ночь 16→17.07.2026 · полная инвентаризация внешних зависимостей трёх репо + ресёрч рынка on-prem healthcare AI. Материал для обсуждения: развилки, а не готовое решение.

Как читать: ① светофор стека — что переносится, что менять → ② 5 блокеров → ③ развилка №4: три глубины он-премиса → ④ выбор LLM и голосовой стек → ⑤ как это продаётся → ⑥ развилка №5: объединять ли репо → ⑦ право · чеклист заказчику · риски.
≈70%стека уже self-hosted (LiveKit, Langfuse, PG, Asterisk…)
1блокер без готовой локальной замены: распознавание речи
0он-премис конкурентов среди dental-AI (все SaaS)
02.08.26AI Act Art.50: бот обязан представляться

Светофор стека: что едет, что менять

зелёное — уже self-hosted, переносится как есть жёлтое — облачное, но есть шов (меняется конфигом/адаптером) красное — нет готовой замены, нужна разработка
Медиа и телефония
LiveKit server/sip/egressAsteriskRedisSIP-транк → местный оператор ЕСturn-detector: локальный, вопрос лицензии весов
Распознавание речи
STT: только облако Yandex, локального нетVAD Silero (локальный)
Синтез речи
Облачные TTS (несколько, per-стек)Silero TTS: локальный, но RU и лицензиялокального TTS для es/en/de нет
Мозг
dental-core (FastAPI+LangGraph)LLM: шов есть, калибровка под облакоembeddings (размерность зашита в схему БД)
Данные
PostgreSQL+pgvector per клиниказаписи звонков: S3-шов → MinIO (уже в стеке)Langfuse v3 self-hosted (промпты, трейсы, judge)
Интеграции
CRM: RU-адаптеры (IDENT/MedFlex), для ЕС нужен новыйTelegram: исходящий канал или локальный bot-apiWhatsApp: не реализован (для ЕС понадобится)
Управление флотом
dental-hub + операторская панельngrok / GitHub-деплой и auth — заменитьCI/CD → локальный git/registry заказчика
Наблюдаемость
health-мониторинг + алерты hubLangfuse-трейсингалерты: Telegram → локальный канал

Пять блокеров (в порядке боли)

  1. STT (распознавание речи). Единственный прод-STT — облачный Yandex (для ЕС ещё и юридически сомнителен). Шов для подключения альтернатив есть (интерфейс плагинов, два своих плагина как образец) — готовой локальной реализации нет. Кандидаты: faster-whisper large-v3-turbo, NVIDIA-стек. Блокер общий для «мультиклиники в ЕС» и «он-премиса». разработка
  2. LLM-калибровка. Шов по URL есть, но всё поведение (промпты, evals, быстрые ветки роутера) откалибровано под конкретную облачную модель. Любой вариант — EU-endpoint или self-host — означает ре-калибровку и прогон evals. работа+риск качества
  3. TTS для 4 языков. Все продовые TTS — облака; локальные кандидаты (Kokoro/Orpheus/Piper) — es/en есть, телефонное качество проверять ушами. Silero — наша интеграция RU + некоммерческая лицензия. подбор+пилот
  4. PMS-адаптер ЕС. Booking-путь весь через RU-сервисы; интерфейс CRM-адаптера есть, реализации под их PMS — ноль. Объём не оценить до ответа «какая PMS». неизвестный объём
  5. Дистрибутив. Сегодня инсталляция = руки+SSH+клон свежего main с github: нет пиновки версий, нет bundle, секреты местами в компоузах, прокси по HTTP. Для он-премиса нужен упакованный, версионированный, подписанный дистрибутив. инженерия поставки → развилка №5

Развилка №4 · Три глубины «он-премиса»: сравнение за 30 секунд

«Он-премис» для заказчика часто значит «данные не в чужом облаке», а не «сервер в подвале клиники». Первое, что выясняем: что им реально нужно. Сначала матрица, ниже — детали.

КритерийA EU-cloudB гибридC полный
Время до пилота недели 1–2 квартала кварталы+
«Данные в контуре» буквально нет (в ЕС, но у нас) PII — да, текст в LLM — EU-зона да
Качество диалога сегодня текущее ≈текущее зависит от ре-калибровки
Стоимость для нас (разработка) низкая STT/TTS + маскинг высокая
Стоимость для заказчика подписка подписка + немного GPU CAPEX GPU + maintenance
Работа при обрыве интернета нет агент нем (нужен failover на людей) да
Наш контроль качества/SLA полный совместный зависит от их железа/сети
AEU private cloud, управляем мы (managed / sovereign-style) минимум переделок

Вся платформа как есть, но на EU-хостинге (местный провайдер заказчика или наш), данные в стране, DPA. Телефония локальная. По сути — переезд + комплаенс-обвязка.

Плюсы
  • Быстрее всего до пилота (недели, не кварталы)
  • Мы управляем: обновления, инциденты, качество — наш SLA честный
  • GDPR-residency закрывается контрактом и регионом
  • Экономика облака сохраняется
Минусы
  • Это не «он-премис» в строгом смысле — если требование политическое, не пройдёт
  • LLM всё ещё внешний вызов (решается EU-endpoint'ом — см. LLM)
  • Заказчик не получает «свою» инсталляцию как актив

Продаётся как: подписка per клиника + setup. Рынок дентальных AI-ресепшенов живёт на $300–800/локация/мес — якорь для прайсинга.

BГибрид: голос и данные в контуре, LLM — через EU-зону гиперскейлера индустриальный компромисс

Медиа-стек, БД, записи, Langfuse — на железе/в контуре заказчика. LLM — EU-зона (обработка и хранение в ЕС, вне обучения). STT/TTS — локальные.

Плюсы
  • PII и аудио не покидают контур; наружу — только маскированный текст в EU-зону
  • Не платим GPU-налог за LLM; качество ≈ текущее (модели те же)
  • Промпты почти без ре-калибровки
  • Типовая схема, которую юристы заказчика уже видели (DPA гиперскейлера)
Минусы
  • Обрыв канала наружу = агент нем на всех линиях страны. Обязателен failover: переадресация на регистратуры у телеком-оператора + место этого сценария в SLA
  • Маскирование PII до отправки в LLM надо сделать доказуемым (в трейсах маскинг есть, в LLM-запросах — предмет работы)
  • Двойная зона ответственности (наш софт + их сеть + гиперскейлер)

GPU нужен только под STT/TTS — заметно дешевле полного self-host LLM.

CПолный он-премис: всё в контуре, LLM self-hosted максимум суверенитета — и цены

vLLM + открытая модель, локальные STT/TTS, всё на GPU заказчика. Кандидаты моделей — в таблице ниже.

Плюсы
  • Аргумент продажи, которого нет ни у одного dental-AI конкурента (все SaaS)
  • Полный суверенитет: работает даже без интернета (контраст с B)
  • Фиксированная стоимость на объёме (не per-token)
Минусы
  • Ре-калибровка ВСЕГО под открытую модель: промпты, evals, роутер — самый большой скрытый объём
  • GPU: ориентир — от 24GB на голосовой пайплайн, для прод-запаса 2×GPU на страну; совокупная стоимость владения ×3–5 на DevOps (оценка по индустрии, не наш замер)
  • У сети стоматологий нет MLOps → де-факто «managed on-prem» нашими руками — закладывать в цену и штат
  • Version drift: 4 страны × свои окружения — без signed-bundle поставки утонем
  • Код и промпты (наш главный актив) физически у заказчика → лицензия, подписанные бандлы, IP-пункты контракта
  • Качество open-модели на 4 языках — валидировать ДО подписания обязательств

Продаётся как: лицензия + 18–22%/год maintenance (норма индустрии) + железо CAPEX заказчика.

Вопрос на созвон: что мы продаём — «суверенитет данных» (достаточно B) или «коробку в собственность» (C)? И что заказчик сам вкладывает в слово «он-премис»?
Моя гипотеза (спорьте): лестница — пилот на A/B, контрактная опция C для тех, кому политически нужно. Тогда локализация STT/TTS (общая для B и C) — первая инвестиция, self-host LLM — отложенная.

Выбор LLM (внутри развилки №4)

Текущий вендор, EU residencyEU Data Zone гиперскейлераSelf-host открытой модели
ДанныеEU-регион вендора, DPAобработка+хранение в ЕС, вне обученияне покидают контур
Промпты/evals без изменений почти без изменений полная ре-калибровка
4 языка (es/en/de/ru) да да Qwen3 — наиболее уверенный кандидат по нашему ресёрчу (языки заявлены официально + tool-calling); альтернативы: Mistral Small (Apache 2.0), Gemma 3. Проверять на наших сценариях
Tool-calling vLLM-экосистема зрелая, но тестировать на нашем графе
Экономикаper-tokenper-tokenGPU CAPEX; оправдано комплаенсом, не экономией

Деталь из кода: размерность эмбеддингов зашита в схему БД — смена embedding-модели тянет миграцию векторного индекса. Мелочь, но в смету.

Голосовой стек он-премис (общее для B и C)

STT → faster-whisper large-v3-turbo (стриминг ~0.5–0.8с, сильные es/de/ru/en) или NVIDIA-стек (лицензия ~$4.5k/GPU/год). Писать LiveKit-плагин — интерфейс готов, наши два плагина как образец.
↓
TTS → кандидаты: Kokoro (Apache 2.0, лёгкий, es поддержан), Orpheus 3B (самый человечный из открытых, нужен GPU). ⚠ Coqui XTTS юридически мёртв (некоммерческая лицензия, компания закрылась). Телефонные 8kHz прощают многое — шанс звучать достойно реален, но решают уши на пилоте.
↓
VAD / определение конца реплики — уже работают локально (модели в образе). ⚠ Нюанс: у turn-detector кастомная лицензия весов, привязанная к экосистеме LiveKit — прочитать условия до контракта с заказчиком.
↓
Бюджет задержки: сегодня главный тормоз — LLM (первый токен ~2.9с медианно на проде). Локальные STT/TTS могут даже выиграть у облака по сетевой задержке. Все ускорители (стриминг, филлеры, FAQ-кэш, преролл-приветствия) переносятся.

Как это продаётся (рынок)

Два факта, которые задают позицию: ① все дентальные AI-ресепшены — чистый SaaS, он-премиса нет ни у кого; прайс-якорь $300–800/локация/мес. ② В ЕС уже есть игрок, продающий «sovereign healthcare AI» как платформу (Corti, Дания) — окно не пустое, но в стоматологии свободно.
Механика поставки и деньги (детали)
  • Норма рынка: connected on-prem (контролируемый выход наружу: обновления, лицензии, bastion для поддержки); строгий air-gap — редкость и дорого.
  • Поставка: подписанные бандлы (образы+манифесты, пин версий), локальный registry, staging у заказчика; «pre-validated bundle» (модель+промпты+конфиг тестируются как целое) — защита от «у нас на стенде работало».
  • Деньги: лицензия + maintenance 18–22%/год; SLA разделять на «наш софт» и «ваша инфраструктура»; журналируемый удалённый доступ — в контракт, иначе время починки и SLA невозможны.
  • IP: код и промпты в контуре заказчика — лицензионные ограничения, запрет форка, аудит использования.
  • Наблюдаемость: Langfuse self-host — уже наша практика (ядро MIT); enterprise-фичи (audit log, retention, masking) — платная лицензия, для меддомена может понадобиться.

Развилка №5 · Объединять ли проекты под он-премис

Факт из кода: hub и core сцеплены намертво (hub генерирует .env/compose ядра, знает его структуру каталогов и 35+ admin-ручек), но версионного контракта нет — деплой всегда клонирует свежий main. Voice связан слабее (комнаты LiveKit + соглашение об именах).

AОставить 3 репо + добавить «дистрибутив» (4-й артефакт: bundle с пиновкой версий) наименьшие изменения процессов
Плюсы
  • Структура команд и зоны владения (voice/core) не ломаются
  • Версионный контракт появляется там, где его нет: релиз = зафиксированная тройка версий + миграции + промпты
  • Он-премис получает главное (воспроизводимость) без реорганизации
Минусы
  • Ещё один репозиторий/пайплайн, дисциплина релизов
  • Интеграционные тесты тройки нужно строить (их нет)
BМонорепо
Плюсы
  • Атомарные изменения через границы, один версионный номер
  • Проще единый CI и релиз
Минусы
  • Большая миграция процессов ради проблемы, которую решает и вариант A
  • Смешение зон ответственности команд; история/CI переезжают болезненно
CНичего не менять
Плюсы
  • Ноль затрат сейчас
Минусы
  • Он-премис без пиновки версий = 4 страны × уникальные «снежинки»-инсталляции; поддержка съест команду
  • «У нас на стенде работало» превращается в спор с заказчиком
Вопрос на созвон: если появляется релизный дистрибутив — кто владелец релизного цикла? (Вопрос организационный, не технический.)
Моя гипотеза (спорьте): вариант A — дистрибутив без слияния репо; монорепо не решает ничего, чего не решил бы bundle.

Право — минимум, который надо знать до продажи

Чеклист вопросов заказчику (первая встреча)

  1. Что для вас «он-премис»: свой ЦОД / серверная / местный EU-провайдер / «не чужое облако»? (Ответ выбирает вариант A/B/C.)
  2. Допустим ли контролируемый выход наружу (обновления, лицензии, bastion поддержки) или строгий air-gap?
  3. Какая PMS в клиниках и есть ли к ней API изнутри контура? (Блокер №4.)
  4. Есть ли GPU/бюджет и кто оперирует (их IT? мы как managed?)
  5. Языковой микс реальных звонков по странам?
  6. Пиковая одновременность звонков и режим 24/7? (Сайзинг железа.)
  7. Кто DPO, кто делает DPIA, в какие сроки?
  8. Политика записи звонков и retention по каждой стране?
  9. Телефония: чьи номера, какие операторы, порт существующих номеров?
  10. Куда эскалируем звонок и что происходит при недоступности агента (failover-маршрут)?
  11. Канал и каденс обновлений (авто/ручной аппрув/физический перенос)? Staging у заказчика?
  12. Критерии успеха пилота: клиники, метрики, ответственный со стороны сети.

Риски предложения

Топ-3:
  1. Продать вариант C, не провалидировав открытую LLM на 4 языках — качество диалога = наш главный актив, терять нельзя. Валидация до обязательств.
  2. Version drift / «снежинки»: 4 страны × свои окружения без signed-bundle = экспоненциальная поддержка.
  3. Секрет-гигиена перед выносом кода наружу: в репо есть закоммиченные секреты и HTTP-прокси — до передачи заказчику чистить обязательно (/adjustment).
Ещё 7 рисков
  1. SLA-парадокс: заказчик ждёт SLA как от SaaS, а железо/сеть — его. Разделять SLA в контракте.
  2. Время починки без доступа: air-gap-ожидания несовместимы с быстрой поддержкой — журналируемый bastion в контракт.
  3. Кадры заказчика: у сети нет MLOps — реально это managed on-prem нашими руками; закладывать в цену.
  4. Экономика: полный он-премис дороже облака — цена продаёт комплаенс, не экономию. Не обещать «дешевле».
  5. Лицензии весов моделей: XTTS мёртв юридически; у turn-detector кастомная лицензия; Silero — некоммерческая. Аудит лицензий всех весов до контракта.
  6. DPIA-сроки: пилот не стартует до DPIA заказчика — влияет на воронку продажи.
  7. Расползание функций в сторону мед. триажа — регуляторная мина (MDR/high-risk).

Что уже готово (наши козыри)

Связки: мультиклиника — «что продаём», он-премис — «как поставляем»; блокеры №1–3 (STT/LLM/TTS) общие для обеих тем → делать один раз. См. /multyclinic и /adjustment (пререквизиты: секреты, версии, валидатор конфигов).