Своя разработка или покупка ИИ-функций: что и сколько стоит

Это инженерные рекомендации, а не юридическая консультация. Детали уточняйте у квалифицированного юриста.

Кратко

Для каждой ИИ-функции телемедицинского продукта – скрайба, транскрипции, ассистента триажа, резюме визита – приходится решать, делать её самим или покупать. И цена, которую сравнивают первой, почти никогда не оказывается решающей. «Купить» – значит лицензировать готовый клинический ИИ-продукт российского разработчика или вызывать модель российского провайдера по договору (GigaChat, Alice AI в Yandex AI Studio, SaluteSpeech, Yandex SpeechKit). «Сделать» – собрать функцию самим, обычно на open-модели в своём контуре или на API в собственной обёртке, и взять на себя валидацию, комплаенс и сопровождение. Зарубежные ИИ-API для медданных не рассматриваются вовсе: их исключают запрет хранить данные россиян в зарубежных базах и правила трансграничной передачи. Сравнивать нужно стоимость визита на горизонте трёх лет с учётом интеграции, клинической валидации, мониторинга и инженеров, которые всё это поддерживают, а не ценник лицензии или цену минуты у API. В статье – полная модель затрат, пример расчёта стоимости визита в рублях и четыре вопроса для принятия решения. Требования, общие для обоих путей, вынесены в статью о слое комплаенса и безопасности клинического ИИ.

Зачем это читать

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

Между «сделать» и «купить» – целый спектр

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

На одном краю – покупка «под ключ»: вы лицензируете готовый клинический ИИ-продукт. Например, сервис для клиник, который расшифровывает приём и составляет резюме анамнеза (такую функцию с лета 2026 года пилотирует «Яндекс Мед»), или систему поддержки врачебных решений российских разработчиков вроде Webiomed, «Третьего мнения» или «Цельса».¹ ² Продукт делает всю работу, обрабатывает данные пациентов по договору и сам обновляет свою модель; вы его интегрируете и настраиваете, но ничего не обучаете и не размещаете. На другом краю – разработка с нуля: вы обучаете или серьёзно дообучаете собственную модель на своих данных и запускаете её на своей инфраструктуре. В телемедицине почти никому не стоит начинать отсюда, и дальше станет понятно почему.

Между ними – варианты, которые команды и выбирают на практике. Купить модель, сделать приложение – значит вызывать модель общего назначения через API провайдера (программный интерфейс, через который одна программа запрашивает результат у другой): GigaChat, Alice AI через Yandex AI Studio, распознавание речи SaluteSpeech или Yandex SpeechKit, – а клиническую логику продукта писать самим. Разместить open-модель у себя – значит взять модель с открытыми весами (для речи – например, Whisper), запустить её на своём сервере или в аттестованном сегменте российского облака и построить продукт вокруг неё. К этому же варианту относятся on-prem-версии коммерческих моделей: такая есть, например, у Yandex SpeechKit. Два средних варианта различаются тем, где работает модель: в дата-центре провайдера или в вашем.

Один термин будет встречаться постоянно, поэтому определим его сразу. Поручение на обработку персональных данных – договор, по которому подрядчик, обрабатывающий данные пациентов от имени оператора (обычно клиники), получает перечень данных, действий и целей, обязуется соблюдать конфиденциальность и требования к защите и отвечает перед оператором (ст. 6 152-ФЗ).³ Без такого поручения подрядчика к данным не допускают. Выбор варианта меняет лишь то, с кем нужно оформить поручение – с вендором готового продукта, провайдером API или облаком, – но само требование остаётся. А если вы платформа для клиник, поручение от клиники нужно вам самим при любом варианте.

Нажмите, чтобы увеличить

Цена, которую сравнивают первой, – лишь вершина айсберга

Самая частая ошибка в решениях «сделать или купить» – сравнить стоимость лицензии с зарплатой инженера и на этом остановиться. Реальная стоимость складывается из трёх слоёв, а в начале виден только верхний.

Видимый слой – то, что сравнивают в первый день: плата за лицензию при покупке или стоимость инференса при разработке (цена минуты аудио и объёма текста у API либо аренда GPU). Эти расходы реальны и легко считаются, но за время жизни продукта обычно оказываются самыми небольшими из трёх.

Слой интеграции – чуть ниже ватерлинии. ИИ-функция бесполезна, пока не встроена в реальный визит: нужно захватить аудио из звонка, показать черновик врачу, записать результат в МИС как черновик на подпись и вести журнал каждого шага для аудита. Это инженерная работа и при разработке, и при покупке – купленный продукт тоже придётся интегрировать, – и обычно она занимает недели.

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

Нажмите, чтобы увеличить

Пример расчёта: стоимость визита с ИИ-скрайбом

Посмотрим на цифрах. Возьмём самую распространённую ИИ-функцию в телемедицине – амбиентный скрайб, который слушает визит и готовит черновик протокола (подробно – в статье об ИИ-скрайбе), – и оценим стоимость в расчёте на визит для небольшого продукта: 2 000 визитов в месяц по 15 минут. Сравним покупку управляемого сервиса с разработкой на open-модели в своём контуре. Все цифры ниже – ориентировочные рублёвые оценки для планирования, а не коммерческие предложения: актуальные тарифы сверяйте с прайсами провайдеров.

Покупка. Управляемый сервис распознавания речи и резюмирования тарифицируется по длительности аудио и объёму текста; для расчёта примем ориентировочно 8,5 ₽ за минуту визита вместе с резюме:

• 15 минут на визит × ≈ 8,5 ₽ за минуту = ≈ 127,5 ₽, то есть ≈ 130 ₽ за визит только на модель.
• 2 000 визитов × 130 ₽ = ≈ 260 тыс. ₽ в месяц за ИИ-инференс «под ключ» – с поручением, обновлениями и доступностью сервиса на стороне провайдера.

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

Разработка. Open-модели распознавания речи и резюмирования на собственных мощностях по прямым затратам на минуту действительно дешевле. Аренда мощного GPU в облаке – ориентировочно 130–300 ₽ в час; собственный сервер с двумя GPU амортизируется примерно на 77–100 тыс. ₽ в месяц только по железу, без электричества и размещения. При нескольких тысячах визитов в месяц сам инференс вполне может обойтись дешевле 260 тыс. ₽ за управляемый сервис. Но это лишь видимая вершина. Под ней на вас ложатся валидация (достаточно ли точна open-модель на русской клинической речи), своевременные обновления сервера и модели, дежурства на случай сбоя в самый загруженный для клиники понедельник и мониторинг дрейфа. Ориентир по стоимости такого инженера – медианная зарплата senior-разработчика, около 304 тыс. ₽ в месяц на руки (Хабр Карьера, 2026), то есть ≈ 3,6 млн ₽ в год без налогов, страховых взносов и накладных расходов.⁴ Один инженер, закреплённый за функцией, обходится дороже всего счёта за покупной инференс и съедает экономию на железе, пока объём не станет действительно большим.

Из этого не следует, что покупать всегда дешевле. Разработка выигрывает в стоимости инференса на единицу и проигрывает во всём остальном, пока объём невелик. Точка безубыточности существует – при достаточном числе визитов собственная модель окупается, – но она лежит гораздо дальше, чем подсказывает сравнение цены минуты, и достичь её можно, только если поддерживать высокую загрузку и держать закреплённую команду. Для продукта на 2 000 визитов в месяц покупка почти всегда и дешевле, и менее рискованна. Для сети на 200 000 визитов в месяц та же покупка стоила бы порядка 26 млн ₽ в месяц (200 000 × 130 ₽), и расчёт уже говорит в пользу собственной модели.

Нажмите, чтобы увеличить

«Налог на валидацию»: вы платите его в любом случае

Заманчиво думать, что покупка перекладывает вопрос точности на вендора. Это верно лишь отчасти. Разработчик отвечает за работу модели в целом, но за то, безопасна ли она для вашей популяции пациентов и вашего процесса и нет ли на них смещения, отвечаете вы. И требует этого не только хорошая практика.

Здесь действуют два правила, оба – независимо от того, сделали вы модель или купили. Первое – граница между инструментом, который поддерживает врача, и инструментом, который принимает медицинское решение. ПО, которое производитель предназначил для диагностики, лечения или мониторинга состояния организма, – медицинское изделие (ч. 1 ст. 38 323-ФЗ). ПО с ИИ относится к классу риска 3 и регистрируется в Росздравнадзоре по правилам ПП 1684. Порядок оказания телемедицинской помощи допускает системы поддержки принятия врачебных решений в отложенных консультациях, если они зарегистрированы как ПО-медизделия с ИИ (п. 17 193н).⁵ ⁶ ⁷ ⁸ Если функция переходит эту границу, её нужно регистрировать, откуда бы ни взялась модель; подробно этот случай разобран в статье об ИИ-триаже. Покупка зарегистрированного компонента помогает, но собственная логика поверх него может изменить назначение всего продукта – оцените это с юристом до релиза.

Второе – ответственность за качество помощи. За качество медицинской помощи отвечает медорганизация, а вывод, который врач подписал своей УКЭП, становится его выводом. Проверить модель на ваших пациентах вендор за вас не может. Поэтому валидация – измерение точности и проверка на смещение на вашей популяции до запуска и по графику после – обязательна и подрядчику не передаётся. Покупка сокращает этот объём работ, но не отменяет его. Подробно все четыре проверки разобраны в статье о слое комплаенса и безопасности клинического ИИ; здесь важно одно: «налог на валидацию» входит и в бюджет разработки, и в бюджет покупки.

Есть и особенность, которая касается только ИИ. Модель, которую постоянно улучшают, – не застывший продукт: в правилах ПП 1684 есть отдельный порядок внесения изменений в зарегистрированное ПО с ИИ (п. 112–136).⁷ Если вы разрабатываете сами и собираетесь переобучать модель, этот жизненный цикл и регистрационная работа – на вас. Если покупаете, спросите вендора, как он выпускает обновления модели, валидирует и регистрирует их: дрейф его модели напрямую скажется на ваших пациентах.

Требования комплаенса одинаковы для обоих путей

Сразу отбросим популярный довод в пользу своей разработки: требования к защите данных не становятся мягче, если вы делаете всё сами. Каждый введённый симптом, каждая записанная фраза визита, каждый черновик протокола – это медданные: специальная категория персональных данных (ст. 10 152-ФЗ) и врачебная тайна (ст. 13 323-ФЗ). Связанные с ними обязанности одинаковы, работает ли модель в облаке провайдера или на вашем сервере.

Если вы покупаете продукт, его вендор обрабатывает данные по поручению, и поручение нужно оформить до того, как к нему попадут первые данные пациентов. Для ИИ к этому добавляется условие «без обучения»: цели обработки ограничены вашей услугой, а обучение моделей вендора на данных ваших пациентов прямо запрещено договором. Если вы строите функцию на API-модели, провайдер API – такой же обработчик с теми же условиями; проверьте, что договор распространяется именно на тот бизнес-сервис, которым вы пользуетесь, и что данные обрабатываются в России. Зарубежные провайдеры в этой схеме не участвуют: записывать и хранить персональные данные россиян в зарубежных базах запрещено с 1 июля 2025 года (ч. 5 ст. 18), а передача спецкатегории за рубеж – трансграничная передача с уведомлением Роскомнадзора (ст. 12).⁹ ¹⁰

Если вы размещаете open-модель у себя, вендор модели выпадает из цепочки обработки данных – это реальное преимущество, – но вся защита переходит к вам: уровень защищённости по ПП 1119, меры по приказу ФСТЭК № 21, шифрование, разграничение доступа, журналы. Аттестованное облако закрывает инфраструктурный слой, но не ваше приложение.¹¹ Своя разработка лишь переносит работу по комплаенсу к вам. Обезличивать данные перед тем, как они покинут контур для аналитики, нужно во всех трёх случаях – подробнее в статье об обезличивании и аналитике медданных; требования к защите разобраны в статье требования к защите ПДн в 2026 году.

Привязка к поставщику: сможете ли вы уйти

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

Покупка «под ключ» даёт самый быстрый старт и самую сильную зависимость. Ваш продукт зависит от модели, форматов и планов развития вендора; любое его повышение цен бьёт по вам, а переход к другому поставщику может потребовать собирать функцию заново. При коротком списке российских поставщиков этот риск выше: альтернатив меньше, и даже поколения моделей у провайдеров сменяются – так, Alice AI пришла на смену YandexGPT. Вызов модели через API даёт больше свободы: провайдера часто можно сменить без больших усилий, если логика промптов и данные остаются у вас, но вы по-прежнему зависите от доступности сервиса и условий провайдера. Open-модель у себя даёт максимальную независимость: веса принадлежат вам, и модель продолжит работать, даже если её издатель исчезнет; ради этого часть команд и соглашается на более высокую операционную нагрузку. Разработка с нуля – это полный контроль и полная ответственность.

Универсально верного варианта нет. Главное – оценить привязку заранее, при выборе, а не обнаружить её при продлении договора. Частый разумный компромисс – купить сейчас, чтобы быстрее запуститься, но изолировать провайдера за собственным интерфейсом: остальной продукт не должен знать, какая модель стоит за этим интерфейсом. Так сохраняется возможность перейти на свою модель, когда объём это оправдает.

Четыре вопроса для решения

Решение удобно принимать по четырём вопросам – отдельно для каждой функции, а не один раз для всей платформы.

1. Какой у вас объём и сохранится ли он? Если визитов меньше пары тысяч в месяц, покупайте: вы не дойдёте до точки, где собственная модель окупает нужных ей инженеров. В масштабе крупной сети со стабильной загрузкой разработка становится оправданной.

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

3. Потянете ли вы сопровождение? Разработка означает постоянные обязательства: валидацию, мониторинг, переобучение, дежурства. Если вы не можете выделить инженера на бессрочную поддержку функции, разрабатывать её не стоит: вы сможете только запустить её и наблюдать, как она деградирует.

4. Где должны обрабатываться данные? Если российский провайдер подписывает поручение с условием «без обучения», обрабатывает данные в России и это укладывается в ваш профиль рисков, покупка не создаёт проблем. Если заказчик – например, государственная клиника или организация с объектами критической информационной инфраструктуры – требует, чтобы медданные не покидали его контур, остаётся open-модель у себя или on-prem-версия коммерческой модели, и связанные с этим операционные расходы вы берёте на себя.

Нажмите, чтобы увеличить

Частая дорогая ошибка

Типичный провал – разрабатывать ради экономии и обнаружить, что экономили не на том. Команда сравнивает open-модель у себя с лицензией вендора, видит меньшую цену минуты и начинает разработку. Через год экономия на инференсе действительно есть, но она мала и теряется на фоне зарплаты инженера, незаложенной валидации, дежурств по функции, которая сама по себе не продукт, и модели, которая незаметно дрейфует, потому что за её точность никто не отвечает. Само решение разрабатывать могло быть верным; подвело сравнение, в котором учли только вершину айсберга.

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

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

Начнём с требований: ИИ-функция должна оставаться инструментом поддержки врача (или быть зарегистрирована как медизделие), хранить все данные пациентов в контуре в России – у вас или у обработчика по поручению – и пройти валидацию на точность и смещение на реальной популяции. Эти обязанности действуют независимо от того, куплена модель или сделана. Фора Софт с 2005 года разрабатывает ПО для видео реального времени, конференций и клинических процессов, в том числе телемедицинские платформы, где ИИ-скрайб, транскрипция и триаж работают внутри живой консультации. Обычно мы подключаем покупную модель российского провайдера через собственную прослойку интеграции. Это позволяет быстро запуститься, с первого дня соответствовать требованиям и позже заменить модель на open-модель в контуре клиента, если этого потребуют объём или ограничения на данные. Так решение «сделать или купить» можно пересмотреть в любой момент, а продукт не оказывается в тупике.

Главное

• «Сделать или купить» – это спектр: «под ключ», API провайдера, open-модель у себя, своя модель с нуля; выбирать нужно по каждой функции.
• Лицензия или цена минуты – лишь видимая вершина; большую часть реальной стоимости составляют интеграция и сопровождение.
• Пример: ≈ 130 ₽ за визит и ≈ 260 тыс. ₽ в месяц за покупку против инженера за ≈ 304 тыс. ₽ в месяц на руки.
• «Налог на валидацию» – проверка точности и смещения на вашей популяции – входит в бюджет и при разработке, и при покупке.
• Комплаенс одинаков: поручение, условие «без обучения», данные в России; зарубежные ИИ-API исключены.
• Оцените привязку к поставщику заранее: покупка через собственную прослойку интеграции позволяет позже перейти на свою модель.

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

• Слой комплаенса и безопасности клинического ИИ
• Где ИИ встраивается в телемед-продукт – карта
• Свой, покупной или гибрид для телемедицины