ИИ-ассистент регистратуры клиники: запись, маршрутизация, напоминания. Экономика проекта

Дисклеймер. Описанный ассистент решает организационную задачу — запись на приём, маршрутизацию и напоминания. Он не ставит диагнозы, не назначает лечение и не даёт медицинских рекомендаций. Любое клиническое решение принимает врач. Обработка персональных данных пациентов и сведений о здоровье (специальная категория ПДн) строится по 152-ФЗ: с согласием субъекта, минимизацией данных и защищённым хранением. Окончательное решение по архитектуре, провайдерам и комплаенсу принимает человек — ответственный за ИБ и медицинский директор клиники.

1. Задача и для кого это

Голосовые и чат-ассистенты перестали быть экзотикой: стек «распознавание речи → языковая модель → синтез речи» с телефонией через SIP уже работает в продакшене, а документация фреймворков описывает его как штатный сценарий. Это открывает дорогу прикладным кейсам в сферах, где первая линия контакта — это бесконечная рутина. Регистратура клиники — почти эталонный пример.

Типичная боль частной клиники или сети медцентров: регистратура — узкое место. В часы пик администраторы физически не успевают отвечать на звонки, пациенты слышат «занято» и уходят к конкуренту. Часть обращений приходит вечером и в выходные, когда регистратура закрыта. Добавьте к этому неявки: пациент записался, но забыл — слот простаивает, врач теряет время, клиника теряет выручку.

В таком случае можно рассмотреть кейс внедрения ИИ. Всем надоели тупые роботы, на которых клиенты отваливаются. Отличная задача для внедренцев и разработчиков, которым поставили задачу автоматизировать первую линию регистратуры в клинике на 5–50 врачей. Цель ассистента — три понятные функции:

1. Запись на приём — принять обращение (звонок или чат), понять, к какому специалисту и на когда нужен пациент, подобрать свободный слот и зафиксировать запись в медицинской информационной системе (МИС).
2. Маршрутизация — определить нужную специализацию, а в неоднозначных или эмоционально сложных случаях переключить на живого администратора.
3. Напоминания — отправить SMS за день и за час до приёма, чтобы снизить неявки, и дать возможность перенести или отменить запись.

Чего ассистент НЕ делает: не консультирует по симптомам, не интерпретирует анализы, не рекомендует препараты. Это снимает с компании дополнительные риски, и это важно отдельно прорабатывать.

2. Архитектура решения

Разделим систему на четыре слоя.

Канальный слой (вход). Два входа: телефон (голос) и текстовый чат (сайт, мессенджер). Телефония подключается через SIP: входящий звонок становится участником комнаты, с которым работает голосовой агент. Чат-канал — это обычный текстовый поток в ту же логику диалога.

Слой агента (мозг). Для голоса это конвейер «распознавание речи (STT) → LLM → синтез речи (TTS)» с детекцией конца реплики и обработкой перебиваний. Для чата конвейер короче — текст сразу идёт в LLM. Управляет диалогом сессия агента: она держит состояние разговора, вызывает инструменты и формирует ответы. Документация LiveKit описывает AgentSession как ядро жизненного цикла голосового агента с конфигурируемым пайплайном STT-LLM-TTS, поддержкой перебиваний и turn detection из коробки (docs.livekit.io/agents/build).

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

Слой интеграций (бэкенд). МИС (или её API), SMS-шлюз, и — обязательно — журнал аудита всех действий. Именно здесь живут персональные данные, и здесь же проходит периметр ИБ.

Поток для голосового звонка:

Пациент звонит
  → SIP-транк принимает вызов, создаёт участника в комнате
  → AgentSession: STT распознаёт речь
  → LLM понимает намерение, вызывает инструмент find_slots / create_appointment
  → инструмент идёт в API МИС
  → LLM формулирует ответ, TTS озвучивает
  → запись создана, ставится задача на SMS-напоминание
  → сложный случай → transfer на живого администратора

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

Отдельно стоит подумать о состоянии диалога. Голосовой разговор — это не одиночный запрос, а последовательность реплик, где модель должна помнить контекст: какую специализацию уже назвал пациент, какие слоты ей предложили, что он подтвердил. Сессия агента держит это состояние внутри одного звонка. Между звонками состояние не сохраняется — и это правильно: персональные данные не должны «висеть» в памяти агента дольше необходимого. Если пациент перезвонил, идентификация проходит заново, а история записей берётся из МИС, а не из памяти диалога. Такой подход одновременно и про приватность, и про надёжность: упавшую сессию можно перезапустить без потери критичных данных, потому что источник истины — медицинская система, а не агент. Возможно прикрутить к этому память, чтобы ИИ ассистент мог работать умнее, но оставим это для отдельных публикаций. Рассмотрим в статье наиболее простой и безопасный пример.

Ещё одно архитектурное решение — где проходит граница «доверия» к модели. LLM может галлюцинировать: выдумать врача, перепутать время, «подтвердить» запись, которой нет. Поэтому ни одно действие, меняющее данные, не выполняется по словам модели — только через инструмент, который реально обращается к МИС и возвращает фактический результат. Модель формулирует намерение, а истинность обеспечивает детерминированный код инструмента. Это ключевой принцип: LLM отвечает за язык и понимание, а не за бизнес-логику и данные.

3. Стек и инструменты

• Голосовой агент и телефония: LiveKit Agents — фреймворк для голосовых ИИ-приложений с готовой поддержкой SIP-телефонии (docs.livekit.io/agents/start/telephony). Звонящий представлен как SIP-участник комнаты; настраиваются входящие/исходящие транки и dispatch-правила маршрутизации, поддерживаются DTMF (тональный набор), перевод звонков, шифрование SRTP и шумоподавление.
• LLM: любая модель с поддержкой вызова инструментов (function calling). Для русского языка и медицинской лексики — модель с хорошим RU-качеством; конкретный провайдер выбирается с учётом требований к расположению данных.
• STT/TTS: провайдеры распознавания и синтеза речи с поддержкой русского. Конкретные имена и параметры — version-volatile, сверьте с актуальной документацией выбранного фреймворка.
• МИС: интеграция через REST API клиники. В кейсе ниже МИС абстрагирована за интерфейсом ClinicAPI, чтобы код не зависел от конкретного вендора.
• SMS: SMS-шлюз провайдера (через HTTP API).
• Хранилище состояния и аудит: реляционная БД для журнала действий.

Имена API, флаги CLI и параметры конфигурации фреймворков меняются между версиями — сверяйте с актуальной документацией перед продакшеном.

4. Пошаговая сборка с кодом

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

Шаг 4.1. Интерфейс к МИС

Изолируем всю работу с медицинской системой за одним классом. Это упрощает тесты и замену вендора.

from dataclasses import dataclass
from datetime import datetime

@dataclass
class Slot:
    doctor_id: str
    doctor_name: str
    specialty: str
    start: datetime

class ClinicAPI:
    """Обёртка над API медицинской информационной системы (МИС)."""

    def __init__(self, http_client, base_url: str):
        self._http = http_client
        self._base = base_url

    def find_slots(self, specialty: str, date_from: str, date_to: str) -> list[Slot]:
        resp = self._http.get(
            f"{self._base}/slots",
            params={"specialty": specialty, "from": date_from, "to": date_to},
        )
        resp.raise_for_status()
        return [Slot(**s) for s in resp.json()["slots"]]

    def create_appointment(self, patient_id: str, slot: Slot) -> str:
        resp = self._http.post(
            f"{self._base}/appointments",
            json={"patient_id": patient_id,
                  "doctor_id": slot.doctor_id,
                  "start": slot.start.isoformat()},
        )
        resp.raise_for_status()
        return resp.json()["appointment_id"]

Ожидаемый результат: вызов find_slots(«therapist», «2026-05-25», «2026-05-30») возвращает список объектов Slot; create_appointment(…) — строковый идентификатор записи. Если МИС вернула ошибку, raise_for_status() поднимет исключение, которое мы обработаем выше.

Обратите внимание на два момента. Первый — отказоустойчивость: API МИС может быть недоступно или отвечать медленно. Любой вызов оборачивайте в таймаут и обработку исключения, чтобы агент не «завис» в разговоре с пациентом, а вежливо сообщил о техническом сбое и предложил соединить с администратором. Второй — идемпотентность создания записи: если пациент по плохой связи дважды подтвердил слот, не должно появиться две записи. Решается передачей ключа идемпотентности в create_appointment или проверкой существующей записи на тот же слот перед созданием. Эти детали кажутся мелкими на демо, но именно они отличают пилот от продакшена.

Шаг 4.2. Инструменты для LLM

LLM вызывает функции через function calling. Описываем их как инструменты с понятными названиями и докстрингами — модель опирается на них при выборе.

from livekit.agents import function_tool, RunContext

class ReceptionAgent:
    def __init__(self, clinic: ClinicAPI, audit, sms):
        self.clinic = clinic
        self.audit = audit
        self.sms = sms

    @function_tool()
    async def list_free_slots(self, ctx: RunContext,
                              specialty: str, day: str) -> str:
        """Найти свободные слоты к врачу указанной специализации на дату."""
        slots = self.clinic.find_slots(specialty, day, day)
        self.audit.log("list_free_slots", specialty=specialty, day=day)
        if not slots:
            return "На эту дату свободных слотов нет."
        return "\n".join(
            f"{s.doctor_name} в {s.start.strftime('%H:%M')}" for s in slots[:5]
        )

    @function_tool()
    async def book(self, ctx: RunContext,
                   patient_id: str, doctor_id: str, start_iso: str) -> str:
        """Создать запись на приём для пациента."""
        slot = Slot(doctor_id=doctor_id, doctor_name="", specialty="",
                    start=datetime.fromisoformat(start_iso))
        appt_id = self.clinic.create_appointment(patient_id, slot)
        self.audit.log("create_appointment",
                       patient_id=patient_id, appointment_id=appt_id)
        self.sms.schedule_reminders(patient_id, slot.start, appt_id)
        return f"Запись создана. Номер: {appt_id}. Пришлём напоминание по SMS."

Декоратор function_tool и класс RunContext приведены по документации LiveKit; точные сигнатуры зависят от версии — сверьте с актуальной документацией.

Ожидаемый результат: когда пациент говорит «запишите к терапевту на завтра», LLM сначала вызовет list_free_slots, озвучит варианты, а после подтверждения — book. Каждый вызов фиксируется в аудит-журнале.

Шаг 4.3. Системный промпт с жёсткими границами

Самая важная часть для медицинского домена — инструкция, очерчивающая, что ассистент НЕ делает.

SYSTEM_PROMPT = """
Ты — ассистент регистратуры клиники. Твоя единственная задача —
помочь записаться на приём, выбрать специалиста и время, перенести
или отменить запись.

СТРОГИЕ ЗАПРЕТЫ:
- Не ставь диагнозы и не предполагай заболевания.
- Не давай медицинских советов, не комментируй симптомы и анализы.
- Не рекомендуй и не обсуждай лекарства.
- Если пациент описывает острое или угрожающее состояние
  (сильная боль, затруднённое дыхание, мысли о причинении вреда),
  скажи позвонить в скорую (103) и переведи звонок на администратора.

При сомнениях, конфликте или запросе вне записи — вызови инструмент
перевода на живого администратора. Говори коротко, спокойно, на «вы».
"""

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

Шаг 4.4. Сборка сессии и подключение телефонии

from livekit.agents import AgentSession

async def entrypoint(ctx):
    clinic = ClinicAPI(http_client, base_url=CLINIC_API_URL)
    agent = ReceptionAgent(clinic, audit=AuditLog(), sms=SmsGateway())

    session = AgentSession(
        instructions=SYSTEM_PROMPT,
        stt=make_stt(),     # распознавание речи (RU)
        llm=make_llm(),     # модель с function calling
        tts=make_tts(),     # синтез речи (RU)
        tools=[agent.list_free_slots, agent.book],
    )
    await session.start(room=ctx.room)

Телефония подключается на уровне инфраструктуры: настраивается входящий SIP-транк и dispatch-правило, которое направляет звонки на этого агента (docs.livekit.io/agents/start/telephony). Звонящий входит в комнату как участник, и сессия начинает диалог.

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

Шаг 4.5. Планирование SMS-напоминаний

class SmsGateway:
    def schedule_reminders(self, patient_id, start, appt_id):
        # за день и за час до приёма
        self._enqueue(patient_id, start - timedelta(days=1), appt_id, "day")
        self._enqueue(patient_id, start - timedelta(hours=1), appt_id, "hour")

    def _enqueue(self, patient_id, when, appt_id, kind):
        task_queue.add(
            run_at=when,
            payload={"patient_id": patient_id,
                     "appointment_id": appt_id, "kind": kind},
        )

Отправку выполняет фоновый воркер, который в нужное время дёргает HTTP API SMS-шлюза. Текст напоминания — нейтральный, без медицинских деталей: «Напоминаем о приёме завтра в 10:00. Перенести — позвоните в регистратуру».

Ожидаемый результат: для каждой записи в очередь попадают две задачи; воркер отправляет SMS в назначенное время.

5. Интеграции

• МИС. Главная интеграция. Если у системы нет публичного API — уточняйте у вендора варианты (webhooks, файловый обмен, партнёрский API). Никогда не работайте напрямую с базой МИС в обход вендора: это и риск целостности данных, и нарушение лицензии.
• Телефония (SIP). Через провайдера телефонии или номера платформы. Поддержка DTMF полезна для подтверждений («нажмите 1, чтобы записаться»), SRTP — для шифрования голосового трафика (docs.livekit.io/agents/start/telephony).
• SMS-шлюз. Через HTTP API; учитывайте требования к шаблонам и согласиям на рассылку.
• Чат-каналы. Виджет на сайте и/или мессенджер — та же диалоговая логика без STT/TTS.
• CRM/аналитика. Выгрузка обезличенной статистики обращений для отчётов руководству.

Создание MVP лучше всего делать минимальным с точки зрения функций и затрат: начните с двух эндпоинтов — «найти слоты» и «создать запись». Этого достаточно для рабочего пилота. Перенос и отмена записи, поиск пациента по телефону, проверка прикрепления — добавляются итеративно. Не пытайтесь покрыть весь API МИС сразу: каждый новый эндпоинт — это новая поверхность для ошибок и утечек. Если у вендора МИС есть песочница (тестовый контур) — разрабатывайте только в ней, реальные данные пациентов в разработку не попадают.

Для телефонии заранее продумайте сценарий «агент не понял». При плохой связи или нестандартном запросе пациент быстро раздражается. Хорошая практика — после двух неудачных попыток распознать намерение автоматически переводить на администратора, а не гонять человека по кругу. DTMF-подтверждения («нажмите 1, если всё верно») помогают там, где распознавание речи ненадёжно — например, при подтверждении даты и времени записи.

6. Запуск и метрики

Запускайте поэтапно.

1. Тень (shadow). Ассистент слушает, но не действует: оценивается качество распознавания намерений на реальных диалогах.
2. Пилот на одном направлении. Например, только запись к терапевту, только в чате. Узкая зона — меньше рисков.
3. Расширение. Подключение телефонии и остальных специализаций после стабильных метрик.

Метрики, которые стоит отслеживать (значения измеряйте у себя, не берите чужих цифр):

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

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

7. Безопасность и данные (ИБ-блок)

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

• Правовое основание и согласие. Обработка ПДн — по 152-ФЗ. Информирование пациента о записи разговора и о работе с ботом, получение согласия.
• Минимизация данных. Ассистенту нужен минимум: идентификатор пациента, специализация, время. Диагнозы и анамнез в его контур не передаются.
• Шифрование. Голосовой трафик — через SRTP; данные при передаче — по TLS; ПДн в хранилище — шифрование «на покое».
• Аутентификация и авторизация. Любое действие, меняющее данные (создание/перенос записи), выполняется только после идентификации пациента и в рамках разрешённых операций. Сервисные доступы к МИС — по принципу наименьших привилегий.
• Журнал аудита. Каждый вызов инструмента логируется: кто, что, когда. Это и для разбора инцидентов, и для доказуемости.
• Прозрачность. Пациент должен понимать, что говорит с ассистентом, и иметь простой способ попасть на человека.
• Эскалация. Острые состояния и эмоционально сложные обращения — немедленно человеку.

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

8. ROI (качественно)

Считайте окупаемость на своих числах, без чужой статистики. Источники эффекта:

• Перехват упущенных обращений. Звонки в часы пик, вечером и в выходные, которые раньше терялись, теперь конвертируются в записи.
• Разгрузка администраторов. Рутина уходит ассистенту, люди занимаются живыми пациентами и сложными случаями — это рост качества сервиса без расширения штата.
• Снижение неявок. Напоминания возвращают часть «забывших» пациентов; освобождённые слоты можно перезаполнить.

Обзор AI-инструментов для МСБ отмечает реалистичность внедрения окупаемых решений за 1–2 месяца с оценкой стоимости, сроков и эффекта (kts.tech/posts/ai-instrumenty-dlya-malogo-i-srednego-biznesa-s-bystroj-okupaemostyu). Применяйте ту же дисциплину: до старта зафиксируйте базовые показатели (потерянные звонки, неявки), после пилота сравните.

Важно честно учитывать и затратную сторону. ROI — это не только экономия, но и расходы: оплата STT/TTS и LLM по объёму трафика, телефония и SMS по тарифу провайдера, инфраструктура, и — главное — труд внедрения и сопровождения. Голосовой канал дороже текстового: распознавание и синтез речи в реальном времени стоят заметно больше, чем обработка текста. Поэтому разумная стратегия — сначала запустить чат-ассистента (дешевле, проще, ниже риск ошибки распознавания), снять на нём метрики и отладить сценарии, и только потом подключать дорогой голосовой канал к телефонии. Так вы окупаете внедрение поэтапно и не вкладываетесь в самый дорогой канал до того, как убедились, что сама логика записи работает.

9. Экономика внедрения (количественно)

Раздел 8 даёт качественную рамку. Здесь — числа: сколько стоит запустить ассистента, во сколько обходится один диалог, какой минимум по ИБ нужен и когда внедрение окупится. Все ставки — со ссылками на первоисточники; курс пересчёта 1 $ = 80 ₽ дан только для иллюстрации, для рабочего бюджета подставляйте курс ЦБ на дату счёта.

9.1. Допущения и базовый сценарий

В качестве примера для расчёта берём клинику со следующими данными: 15 врачей, 8 специализаций, 22 рабочих дня в месяце. Поток обращений — 200 звонков и 80 чатов в день, итого 4 400 звонков и 1 760 чатов в месяц. Средний голосовой звонок — 3 минуты (≈ 5 ходов диалога), средний чат — 6 реплик. Доля переводов на администратора — 20 % (по этим долям токены и аудио всё равно тарифицируются, поэтому в unit-economics учитываем 100 % потока). На каждую созданную запись — 2 SMS (за день и за час). Доля обращений, заканчивающихся записью, — 60 %, то есть ≈ 3 690 SMS в месяц.

Рассматриваются два сценария архитектуры.

Вариант А (РФ-стек). SaluteSpeech (Сбер) для STT/TTS, GigaChat Pro для LLM, SIP-телефония российского оператора, SMS через российский шлюз, хостинг в Yandex Cloud или Cloud.ru. ПДн не покидают РФ, что соответствует ст. 18 ч. 5 152-ФЗ о локализации.

Вариант Б (зарубежный стек). OpenAI Whisper/Realtime + GPT-4o-mini + OpenAI TTS. Этот вариант пригоден только если в LLM-канал не передаются ПДн пациента (имя, телефон, диагноз) — иначе нарушение 152-ФЗ. Идентификация и поиск пациента выполняются на стороне МИС, а в модель идут только обезличенные параметры (специализация, диапазон дат). Реалистичность такой архитектуры в медицинском кейсе — спорная; вариант приведён для сравнения с рынком, а не как рекомендация.

9.2. Стоимость одного диалога

Голосовой звонок, Вариант А (РФ-стек, 3 минуты). Бот говорит ≈ 50 % времени; за это время синтезируется ≈ 900 символов речи. Диалог из 5 ходов даёт ≈ 9 500 токенов (8 000 input + 1 500 output).

Если использовать YandexGPT Lite + Yandex SpeechKit вместо стека Сбера, цифры сопоставимы (≈ 5–6 ₽ за звонок): SpeechKit потоковое распознавание 0,1626 ₽ за 15 с (aistudio.yandex.ru/docs/ru/speechkit/pricing), YandexGPT Lite 0,2 ₽ за 1 000 токенов (aistudio.yandex.ru/docs/ru/ai-studio/pricing). Альтернатива — Yandex Agent Atelier «голосовой агент» с управляемым пайплайном: 0,0264 ₽/сек входящего + 0,0203 ₽/сек исходящего + speech-realtime LLM 0,8 ₽/1 000 ток.; итого ≈ 14 ₽ за звонок. Дороже, но меньше работы по сборке.

Голосовой звонок, Вариант Б (зарубежный стек).

Дешевизна Варианта Б — иллюзорна, если учесть юридические и инфраструктурные накладные (шлюз для обезличивания, аудит передаваемых полей, риски штрафов по 152-ФЗ). Для медицинского кейса в РФ почти всегда выигрывает Вариант А.

Чат-диалог (6 реплик). Средний обмен — 3 000 input + 800 output токенов. STT/TTS отсутствуют.

Чат-канал — самая дешёвая часть системы. Это и есть аргумент в пользу запуска чат-ассистента раньше голосового (см. раздел 8).

Сводный месячный расход на токены, аудио и SMS.

9.3. Минимальный вариант (MVP, только чат-канал)

CAPEX (единоразовые расходы на запуск):

OPEX (ежемесячно):

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

9.4. Полный вариант (голос + чат, продакшн)

CAPEX:

OPEX:

9.5. Минимальные затраты на ИБ

Уровень защищённости — УЗ-3 (типичный для частной клиники, обрабатывающей сведения о здоровье как специальную категорию ПДн при количестве субъектов до 100 тыс.; определяется по Постановлению Правительства РФ № 1119 от 01.11.2012). Меры — по приказу ФСТЭК России № 21 от 18.02.2013 (consultant.ru/document/cons_doc_LAW_146520).

Вариант ИБ-1: оценка соответствия без аттестации (минимум для негосударственной клиники). Аттестация для негосударственных операторов формально не обязательна — достаточно оценки соответствия в форме внутреннего аудита и декларирования (fstec.infobezopasnost.ru/stati/kakie-trebovaniya-fstek-predyavlyaet-k-organizacii-zashhity-informacii-ogranichennogo-dostupa).

Вариант ИБ-2: с аттестацией ИСПДн. Имеет смысл, если клиника работает по госконтрактам, передаёт данные в ГИС ЕГИСЗ, или если страховой партнёр требует аттестации. По рыночным данным, минимальная стоимость работ по защите и аттестации ИСПДн начинается от 100 тыс. ₽ для очень простых систем (ec-as.ru/uslugi/attestacija/attestacija-ispdn) и легко уходит в миллионы для типовых.

300 000 — 600 000 ₽

300 000 — 600 000 ₽

300 000 — 600 000 ₽

Конкретный набор СЗИ и подрядчиков утверждает ответственный за ИБ клиники совместно с лицензиатом ФСТЭК. Цифры в таблице — для общего понимания картины.

9.6. Сводная таблица: MVP vs Полный, с двумя вариантами ИБ

9.7. Точка окупаемости (формула)

Срок окупаемости (мес) = CAPEX / (ΔПрибыль_мес − OPEX_мес)

Где ΔПрибыль_мес — прирост чистой прибыли клиники, складывается из трёх компонент:

1. Перехват упущенных обращений = (доля пропущенных звонков сейчас − доля пропущенных с ассистентом) × входящий поток × конверсия в запись × средний чек × маржа.
2. Снижение неявок = (no-show без SMS-напоминаний − no-show с напоминаниями) × число записей × средний чек × маржа.
3. Высвобождение администраторов — обычно не превращается в «живые» деньги (никто не сокращает штат сразу), но даёт прирост качества сервиса и капасити под рост. В прямой ROI-расчёт не включаю; считаю отдельным качественным эффектом.

9.8. Расчёт ROI на типовых параметрах рынка

Здесь — сквозной пример с числами по открытым источникам. Подставьте свои показатели на месте каждой переменной — это не прогноз для конкретной клиники, а шаблон.

Входные параметры и источники.

Расчёт компонента 1: перехват упущенных обращений.

Входящий поток:           4 400 звонков/мес
Сейчас теряется:          4 400 × 23 % = 1 012 звонков
С ассистентом теряется:   4 400 × 5 %  = 220 звонков
Дополнительно отвечено:   1 012 − 220 = 792 звонка
Из них доходит до записи: 792 × 60 % = 475 записей
Дополнительная выручка:   475 × 4 700 ₽ = 2 232 500 ₽/мес
Дополнительная прибыль:   2 232 500 × 20 % = 446 500 ₽/мес

Расчёт компонента 2: снижение неявок.

Базовое число записей в месяц:    4 400 × 60 % × (1 − 0,23 + 0,23) = 2 640
Сейчас не приходит на приём:      2 640 × 23 % = 607
С SMS-напоминаниями не приходит:  2 640 × 8 %  = 211
Возвращено на приём:              607 − 211 = 396 пациентов
Дополнительная выручка:           396 × 4 700 ₽ = 1 861 200 ₽/мес
Дополнительная прибыль:           1 861 200 × 20 % = 372 240 ₽/мес

Итог.

ΔПрибыль_мес = 446 500 + 372 240 = 818 740 ₽/мес

Сроки окупаемости при разных сценариях (CAPEX и OPEX берутся из таблицы 9.6, по верхней границе диапазона для консервативной оценки):

Важная оговорка. MVP-чат в этом расчёте «получает» эффект перехвата звонков, который физически даёт только голосовой канал. Это нарочно — чтобы показать верхнюю планку. Реалистичный MVP-эффект на чат-канале — это 10–25 % от полного: только те пациенты, кто готов взаимодействовать через чат вместо звонка. Если оставить только эффект снижения неявок через SMS (компонент 2) — окупаемость MVP-чата всё равно укладывается в 8–12 месяцев при перечисленных допущениях.

9.9. Чувствительность ROI к ключевым параметрам

Цифры в 9.8 — это иллюстрация при «разумной середине». Реальный ROI чувствителен прежде всего к трём показателям, и стоит явно проверить их у себя до пилота.

Средний чек. Прирост прибыли линейно зависит от чека. При среднем чеке 3 000 ₽ (типично для регионов и недорогих клиник) — ΔПрибыль/мес падает до ≈ 522 тыс ₽, а окупаемость полного варианта растёт до 30+ мес. При 7 000 ₽ (стоматология, узкая специализация) — ΔПрибыль ≈ 1,22 млн ₽/мес, и полный вариант окупается за 9–11 мес.

Доля пропущенных звонков «как есть». Если у вас уже хорошо настроен колл-центр и теряется только 10 % звонков — компонент 1 уменьшается втрое, и полный голосовой ассистент окупается в горизонте 3+ лет. Если вы малая клиника без выделенного колл-центра и теряете 35 % — окупаемость голоса схлопывается до 8–10 мес.

Текущий уровень no-show. Если клиника уже отправляет SMS и no-show у вас 10 %, а не 23 % — компонент 2 уменьшается в три-четыре раза. На таком фоне ассистент окупается в основном за счёт звонков, и идти стоит сразу в голос.

Практический вывод: до старта пилота снимите три цифры — текущую долю пропущенных звонков (выгрузка из АТС за месяц), текущий no-show (из МИС), текущий средний чек и маржу. Подставьте в формулу из 9.7. Если в вашем случае окупаемость выходит за 24 месяца — голосовой канал, скорее всего, не оправдан; начинайте с чата и пересчитывайте через квартал на фактических данных.

10. Сравнение с классическим голосовым роботом

Раздел 9 даёт экономику LLM-ассистента. Но на российском рынке давно работают «обычные» голосовые роботы — сценарные боты на конечных автоматах (FSM), без LLM в петле диалога. У них своя экономика и свой набор компромиссов, которые часто игнорируются в обсуждениях AI-ресепшн. Сравним честно.

10.1. Что такое «классический» голосовой робот

Сценарный (классический) голосовой робот — это конечный автомат: жёсткое дерево состояний, где каждая реплика бота заранее прописана, а понимание пациента сводится к распознаванию из конечного набора намерений и слотов (intent + entity). Готовые продукты на рынке: Voximplant Kit, Robovoice (BSS), Twin24 (VoiceLogic), Aimylogic (Just AI), Naumen Erudite, TWIN, ATSAERO (для МИС «Инфоклиника»).

Архитектурно поток выглядит так:

STT → классификатор намерений → переход по узлу FSM
   → ответ из библиотеки фраз (TTS или предзаписанный)
   → следующий узел

Никакой LLM в этом конвейере нет; вся «логика» — это граф сценария, спроектированный заранее. Если пациент сказал что-то не из ожидаемого набора, бот переспрашивает по шаблону «Я вас не понял. Скажите, пожалуйста, фамилию» или передаёт диалог оператору. По данным VoiceLogic, проектирование сценария — это основная статья работы: до 25 веток — простой пилот, до 50 — средний, до 75+ — сложный со множеством исключений (voicelogic.ru/pricing).

10.2. Стоимость внедрения и эксплуатации

При том же базовом сценарии (15 врачей, 4 400 звонков × 3 мин = 13 200 минут/мес) экономика выглядит так.

Сценарный робот дешевле в OPEX в 3 раза и в CAPEX — в 2–5 раз.

10.3. Плюсы и минусы сценарного робота

Плюсы:

• Цена. В OPEX выигрыш кратный; в CAPEX — тоже. Это главный аргумент для клиник с потоком до 5 000 звонков/мес.
• Сроки. Пилот за 1–2 недели против 2–4 месяцев у LLM-варианта.
• Предсказуемость. FSM не галлюцинирует и не выдаёт неуместных ответов. Каждая ветка диалога прошла приёмку и не изменится без обновления сценария.
• Готовые интеграции. У вендоров для медицины — готовые коннекторы к популярным МИС (Инфоклиника, MEDODS, Medesk), готовые шаблоны напоминаний и подтверждений.
• ИБ из коробки. Крупные российские вендоры (Voximplant, BSS, Naumen) уже прошли необходимые сертификации, размещают данные в РФ, дают типовые формы согласий.
• Нет проблемы промпт-инъекций. Пациент не может «уговорить» FSM сделать что-то вне сценария.

Минусы:

• Жёсткость диалога. Пациент должен говорить «по шаблону». Запрос «Хочу записаться к терапевту, но желательно поближе к работе, и чтоб не утром» сценарный бот не разберёт за один ход — это 3 отдельных вопроса в дереве.
• Раздражение пользователей. Голосовое меню «Нажмите 1, если…» и переспрашивающие FSM-боты — классическая претензия пациентов. NPS у живых администраторов и у LLM-ассистентов обычно выше.
• Хрупкость к изменениям. Появилась новая услуга, изменился график врача, поменялись правила записи — нужно править граф сценария. Каждая правка — это ветка в дереве, которую нужно протестировать.
• Плохая обработка «длинного хвоста». Сценарий покрывает 70–80% типовых случаев; всё остальное уходит на оператора, и нагрузка на регистратуру падает не так сильно, как обещают маркетологи.
• Зависимость от вендора. Сценарий живёт внутри конструктора. Уход к другому провайдеру — полная пересборка дерева.
• Контекстная слепота. FSM не помнит, что пациент звонил вчера. Все «слоты» нужно собирать заново или подгружать из МИС по идентификатору.

10.4. Плюсы и минусы LLM-ассистента

Плюсы:

• Естественный диалог. Один и тот же запрос пациент может сформулировать пятью способами — LLM поймёт все. Это не маркетинг, это базовое свойство трансформерных моделей.
• Сложные случаи в одном ходе. «Запишите к терапевту на завтра после 15:00, желательно к женщине-врачу, у меня ДМС от X» — обрабатывается за один обмен.
• Гибкость без переписывания кода. Изменение поведения — это правка системного промпта и набора инструментов. Граф диалога не нужно перерисовывать.
• Лучше пациентам. NPS, опубликованные кейсами AI-ресепшн в США, регулярно показывают преимущество перед IVR; в РФ независимых исследований мало, но кейсы крупных клиник идут в ту же сторону.
• Эволюция через метрики, а не через релизы. Можно А/Б-тестировать промпты, не выкатывая новый сценарий каждый раз.

Минусы:

• Цена. В 3–5 раз дороже сценарного робота на тех же объёмах. Это значимая статья OPEX.
• Галлюцинации. Без жёстких границ (раздел 7, системный промпт в 4.3) модель может ответить на медицинский вопрос. В сценарном боте такого риска нет.
• Зависимость от LLM-провайдера. SLA, цены и доступность модели — внешние факторы. Изменение тарифа провайдера на 30% — это +30% к OPEX без вашего участия.
• Сложнее ИБ-аудит. Провайдер LLM получает в среднем больше контекста о диалоге, чем нужно. Требуется отдельная схема обезличивания.
• Длиннее путь до продакшна. Нужны тесты на красную команду (промпт-инъекции), регрессионные тесты на нештатные сценарии, мониторинг качества ответов.
• Невозможность 100% предсказуемости. Даже при temperature=0 модель может в одном случае из тысячи дать неожиданный ответ. Для регистратуры это терпимо, для рецептов — нет.

10.5. Как выбрать

Выбор зависит от того, что для клиники критичнее — стоимость или качество клиентского опыта. Грубо:

• Запись на типовой приём, поток до 5 000 звонков/мес, бюджет ограничен → сценарный бот у российского вендора. Старт за 2 недели, OPEX ~100 000 ₽/мес, окупаемость за 2–4 месяца на типовых параметрах из 9.8.
• Сложные программы, корпоративный ДМС, премиум-сегмент с высоким чеком (стоматология, эстетика, чек-апы) → LLM-ассистент. Высокий чек оправдывает рост OPEX; пациенту важнее качество диалога.
• Большая сеть с потоком 10 000+ звонков/мес → LLM-ассистент почти всегда окупается за счёт перехвата звонков; OPEX размазывается по большему обороту.
• Цель — пилот, доказать гипотезу → сценарный бот в качестве «нулевой версии». Если за 3 месяца показывает рост явки и снижение нагрузки на регистратуру — двигайтесь к LLM-варианту с уже измеренными метриками.

10.6. Гибридная архитектура — третий путь

Сценарный робот и LLM не обязаны быть взаимоисключающими. Распространённая в продакшне архитектура — гибрид: FSM обрабатывает 70–80% типовых запросов (запись, перенос, отмена), а LLM подключается только в сложных случаях, где сценарий тупиково переспрашивает второй раз или классификатор не уверен в намерении.

STT → классификатор намерений
  ├─ намерение распознано с уверенностью > 0.8
  │   → FSM-узел (дёшево, предсказуемо)
  └─ намерение неясно / два переспроса подряд / эмоциональная окраска
      → LLM-сессия с тем же контекстом (дороже, но гибко)

Экономика гибрида: ≈ 70% звонков обрабатывается по тарифу сценарного бота (6 ₽/мин), ≈ 30% — по тарифу LLM (~12 ₽/мин у вендора или ~2,3 ₽/мин на своём стеке). Среднее: 7,8 ₽/мин — почти как у сценарного, но с резким улучшением обработки «длинного хвоста». Этот вариант продают «AI-режим» в составе сценарного конструктора многие вендоры (например, Twin24/VoiceLogic). У него есть и обратная сторона: усложняется проектирование и тестирование, ИБ-периметр расширяется до LLM-провайдера, а возможная неконсистентность стилей FSM и LLM раздражает часть пациентов.

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

11. Ошибки

• Ассистент «лечит». Без жёстких границ в промпте модель начнёт отвечать на медицинские вопросы. Запреты + эскалация — обязательны.
• Прямой доступ к БД МИС. Минуя API вендора — риск порчи данных и нарушения лицензии.
• Нет перевода на человека. Тупиковые диалоги бесят пациентов сильнее, чем «занято».
• Оптимизация под прокси-метрику. См. раздел 6 — ломает реальный результат.
• Игнор согласий и логирования. Делает систему уязвимой и юридически, и при разборе инцидентов.
• Запуск сразу на телефоне и всех направлениях. Начинайте с узкого пилота.
• Версионная хрупкость. Имена API и флаги фреймворков меняются — закладывайте сверку с документацией в регламент обновлений.

12. Источники

Технологии и фреймворки

• LiveKit Docs — Building Voice Agents: docs.livekit.io/agents/build
• LiveKit Docs — Telephony Integration (SIP): docs.livekit.io/agents/start/telephony

Тарифы AI и инфраструктуры

• Yandex AI Studio — правила тарификации (LLM, голосовые агенты): aistudio.yandex.ru/docs/ru/ai-studio/pricing
• Yandex SpeechKit — правила тарификации (STT/TTS): aistudio.yandex.ru/docs/ru/speechkit/pricing
• GigaChat API — тарифы для юрлиц: developers.sber.ru/docs/ru/gigachat/tariffs/legal-tariffs
• SaluteSpeech — тарифы для юрлиц: developers.sber.ru/docs/ru/salutespeech/tariffs/legal-tariffs
• OpenAI API Pricing: openai.com/api/pricing
• OpenAI — GPT-4o mini cost-efficient intelligence: openai.com/index/gpt-4o-mini-advancing-cost-efficient-intelligence
• SMSC.ru — тарифы на SMS: smsc.ru/tariffs
• Mango Office — городские номера и тарифы vАТС: mango-office.ru/numbers_and_tariffs/gorodskoy-nomer

Тарифы и сравнение классических голосовых роботов

• VoiceLogic / Twin24 — стоимость сценарных и AI-голосовых роботов: voicelogic.ru/pricing
• Голосовые роботы: что выбрать (обзор тарифов Voximplant Kit, Robovoice, Aimylogic, Infobot): vc.ru/services/126895-golosovye-roboty-chto-vybrat-chast-vtoraya
• Robovoice — голосовой бот для записи пациентов: robo-voice.ru/bot_dlya_zapisi_na_priem
• ATSAERO — Виртуальный медицинский регистратор для МИС «Инфоклиника»: atsaero.ru/infoclinica1

Регуляторика и ИБ

• Приказ ФСТЭК России № 21 от 18.02.2013 — состав мер по защите ПДн: consultant.ru/document/cons_doc_LAW_146520
• Разъяснение по требованиям ФСТЭК для ИСПДн (УЗ-3): fstec.infobezopasnost.ru/stati/kakie-trebovaniya-fstek-predyavlyaet-k-organizacii-zashhity-informacii-ogranichennogo-dostupa
• Аттестация ИСПДн — практика рынка: ec-as.ru/uslugi/attestacija/attestacija-ispdn

Зарплаты и кадры

• Зарплаты Python-разработчиков по городам 2026: enigmai.ru/salary/python/python-salary-by-city

Рынок и метрики

• Средний чек частной клиники РФ 1H 2024: medvestnik.ru/content/news/Srednii-chek-v-chastnyh-klinikah-vyros-na-18-v-2024-godu.html
• Систематический обзор no-show rate (Dantas et al. 2018): sciencedirect.com/science/article/abs/pii/S0168851018300459
• Эффект онлайн-бронирования и напоминаний на no-show (Frontiers 2025): frontiersin.org/journals/digital-health/articles/10.3389/fdgth.2025.1567397/full
• Доля пропущенных звонков в медпрактике (Talkdesk + обзор): agentzap.ai/blog/medical-practice-phone-statistics
• Конверсия отвеченного звонка в запись: resonateapp.com/resources/reduce-missed-calls-from-new-patient-inquiries

Бизнес-кейсы и аналитика

• KTS Tech — AI-инструменты для МСБ с быстрой окупаемостью: kts.tech/posts/ai-instrumenty-dlya-malogo-i-srednego-biznesa-s-bystroj-okupaemostyu
• AI Happens — критика чат-ботов, оптимизирующих метрики: t.me/AIhappens/392