Покупать или разрабатывать ИИ-функции и сколько это стоит

Автор: Николай СапуновОбновлено: август 202617 мин чтения
Содержание статьи +

Это инженерные рекомендации, а не юридическая консультация. Требования к данным и ПО для вашей организации уточняйте у юриста.

Кратко

Любую ИИ-функцию в обучающем продукте (тьютора, аватар, автосубтитры, генератор тестов) можно добавить тремя способами: купить готовый продукт, вызвать модель провайдера через облачный API (GigaChat API, Yandex AI Studio, SpeechKit) или развернуть открытую модель на своей инфраструктуре. Обычно правильный ответ такой: сейчас купить продукт или подключить API, а о своей модели думать позже. Решение определяют четыре фактора: объём использования, требования к точности, чувствительность данных учащихся и готовность зависеть от поставщика (vendor lock-in). Какая модель «лучшая», для выбора почти неважно. Сравнивать варианты нужно по затратам на одного учащегося в месяц. В нашем примере ИИ-тьютор через API обходится в единицы рублей на человека, а своя модель окупается только при высоком стабильном объёме – при недорогой модели это порядка сотни тысяч активных учащихся. Особенно дорого обходятся две ошибки: развернуть открытую модель «ради экономии», пока объёма ещё нет, и купить продукт по эффектному демо, не выяснив, куда уходят данные учащихся. По 152-ФЗ нужны поручение на обработку и базы в России, а ИИ, который сам выставляет оценку, попадает под ст. 16 о решениях на основании исключительно автоматизированной обработки, кто бы ни построил функцию.

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

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

Три способа добавить любую ИИ-функцию

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

Первый – купить готовый продукт: вы покупаете лицензию у поставщика, который уже реализовал функцию целиком. Например, сервис синтетического ведущего превращает сценарий в видео с «говорящей головой» – подробнее об этом в статье об ИИ-аватарах для курсов. В России такие решения предлагают и сервисы, и студии: в 2025 году Narrators Production (E-Promo Group) сделала цифровые аватары преподавателей для корпоративного обучения. Работающая функция появляется за несколько дней: вы её настраиваете и платите подписку, а ИИ-кода почти не пишете.

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

Третий – развернуть открытую модель: вы берёте модель с открытыми весами (Whisper для речи, открытую языковую модель для тьютора) и запускаете её на мощностях, арендованных в российском облаке, или на собственных серверах. Данные не покидают вашу инфраструктуру, модель можно дообучать, платы за запросы нет. Взамен вы покупаете или арендуете графические процессоры, или GPU (специализированные чипы, на которых работают ИИ-модели), и сами отвечаете за эксплуатацию, масштабирование, мониторинг и звонки в два часа ночи, когда всё сломалось. Есть и промежуточный вариант: некоторые российские провайдеры поставляют свои модели для установки в контуре заказчика, например SpeechKit Hybrid. Модель коммерческая, но данные не уходят за ваш периметр.

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

Рисунок 1. Три способа добавить любую ИИ-функцию: от самого быстрого запуска до максимального контроля. Готовый продукт запускается за дни, но контроля над ним меньше всего; своя модель даёт полный контроль, но требует больше всего инженерной работы. Облачный API находится посередине, и большинству обучающих продуктов стоит начинать с него.

Четыре фактора, от которых зависит выбор

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

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

Учитывать нужно все четыре фактора одновременно. Если объём большой, данные не чувствительные, а ошибки допустимы (скажем, черновые субтитры к тысячам внутренних видео), имеет смысл своя открытая модель. Если объём небольшой, данные чувствительные, а требования к точности высокие (ИИ-тьютор, работающий с именными записями нескольких сотен учащихся), лучше подойдёт российский провайдер с внятным поручением на обработку или развёртывание в своём контуре. Путь определяют эти факторы, рейтинг моделей здесь вторичен.

Считать нужно затраты на учащегося в месяц

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

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

На учащегося в месяц:
  вход:  1 500 токенов × 40 = 60 000 токенов
  выход:   500 токенов × 40 = 20 000 токенов

При ставке недорогой облачной модели порядка 26 ₽ за миллион
входных и 100 ₽ за миллион выходных токенов (иллюстративно):
  вход:  60 000 / 1 000 000 × 26 ₽  = 1,56 ₽
  выход: 20 000 / 1 000 000 × 100 ₽ = 2,00 ₽
  итого ≈ 3,6 ₽ на учащегося в месяц

При 5 000 активных учащихся это около 18 тыс. ₽ в месяц – меньше недели работы одного senior-инженера (по данным Хабр Карьеры, медианная зарплата senior-разработчика – 304 тыс. ₽ в месяц на руки, то есть около 70 тыс. ₽ в неделю). Ставки у разных провайдеров, а также у облегчённых и старших моделей одной линейки отличаются в разы, поэтому подставьте цены выбранной модели. Но даже при ставке в 10 раз выше выйдет ≈ 36 ₽ на учащегося и ≈ 180 тыс. ₽ в месяц на те же 5 000 человек. Это меньше месячной зарплаты одного инженера, без которого свою модель не развернуть и не сопровождать. Поэтому для большинства обучающих продуктов API выгоднее: затраты на учащегося невелики, а своя модель дорого обходится с первого дня.

Теперь субтитры. Распознавание речи тарифицируют поминутно: у облачных моделей ориентировочно 0,26–0,51 ₽ за минуту (точные ставки – в прайсе выбранного провайдера). Однократное распознавание 30-минутной лекции обойдётся примерно в 8–15 ₽. Дороже всего аватары: видео с синтетическим ведущим у SaaS-сервисов стоит ориентировочно 170–430 ₽ за готовую минуту, то есть 10-минутный урок обойдётся в 1 700–4 300 ₽. Для тщательно проработанного ключевого урока это нормально, а персональные видео для каждого учащегося разорят бюджет. У каждой функции своя единица оплаты, и перед решением все их нужно пересчитать «на учащегося».

Купить, API или своя модель: сравнение

ВариантСрок запускаФорма затратПотолок точностиКонтроль данныхЗависимость от поставщикаСтандарты и трекинг
Купить продуктДниЗа место / минуту / кредитЗадан поставщиком, часто высокийНизкий: данные у поставщика; нужны поручение и базы в РФВысокая: его формат и его план развитияxAPI/cmi5 отправляете вы; продукт может этого не уметь
Вызвать облачный APIНеделиЗа токен / минуту, растёт с использованиемВысокий: модель выбираете выСредний: зависит от поручения и места обработкиСредняя: провайдера можно заменить за слоем абстракцииРезультаты вы упаковываете в xAPI
Своя открытая модельМесяцыКрупные фиксированные (GPU + инженеры) + небольшие переменныеЗависит от вашей донастройки и вложенных усилийВысокий: данные не уходят наружуНизкая: веса у васПолный контроль конвейера трекинга

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

Вопрос приватности: куда уходят данные учащихся?

Для обучающих продуктов этот вопрос стоит острее обычного: данные учащихся – это персональные данные, часто данные несовершеннолетних, а иногда и сведения о здоровье (например, статус ОВЗ относится к специальной категории по ст. 10 152-ФЗ).

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

Вторая проверка – где физически находятся базы данных. С 1 июля 2025 года сбор, запись и хранение персональных данных граждан России с использованием баз данных за рубежом не допускаются (ч. 5 ст. 18 152-ФЗ в редакции 23-ФЗ). Поэтому зарубежные ИИ-API для данных учащихся сразу отпадают, тем более что крупнейшие из них в России официально недоступны. Если обработчик – иностранное лицо, перед учащимся отвечают и оператор, и обработчик (ч. 6 ст. 6). У российских провайдеров письменно уточните, где обрабатываются запросы, сколько они хранятся и используются ли для обучения моделей. С 1 сентября 2025 года согласие на обработку оформляется отдельно от других документов (ч. 1 ст. 9); за несовершеннолетних его дают законные представители. Цена ошибки высока: за повторную утечку юрлицо заплатит 1–3% выручки (не менее 20 млн ₽ и не более 500 млн ₽).

Есть и ещё одна ловушка, характерная именно для образования. Статья 16 152-ФЗ запрещает принимать на основании исключительно автоматизированной обработки персональных данных решения, которые порождают юридические последствия для человека или иным образом затрагивают его права и законные интересы, кроме случаев письменного согласия или прямого указания федерального закона. Оператор обязан разъяснить порядок принятия такого решения, дать возможность заявить возражение и рассмотреть его в течение 30 дней. По нашей инженерной оценке, типичные кандидаты в такие решения – итоговая оценка за аттестацию, допуск, зачисление и отчисление. Требование привязано к функции, а не к поставщику: купив готовый ИИ-оценщик, вы не снимаете обязанность с себя. ИИ-тьютор, который даёт обратную связь и не влияет на оценки, под эту норму, как правило, не попадает. ИИ, который сам выставляет итоговую оценку, скорее всего, попадает, поэтому в принятии решения должен участвовать человек.

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

Рисунок 2. Куда уходят данные учащихся. Со своей моделью персональные данные остаются внутри вашего периметра; при вызове провайдера они уходят наружу, и тогда главные средства контроля – поручение на обработку по ст. 6 152-ФЗ и базы в России. Если функция сама выставляет оценку, по ст. 16 152-ФЗ решение при любом варианте должен принимать человек.

Частая ошибка: своя модель «ради экономии» слишком рано

Чаще всего мы видим такую картину: команда разворачивает открытую модель, чтобы не платить за API, а потом выясняется, что плата за API никогда не была существенной статьёй расходов. Команда арендует GPU, которые большую часть суток простаивают, нанимает инженеров или отвлекает своих на инференс, мониторинг и масштабирование. В результате на одного учащегося она тратит намного больше, чем стоил бы API, и запускается на месяцы позже. Даже минимальная своя модель – это GPU плюс часть ставки инженера, по расчёту ниже порядка 4,3 млн ₽ в год. «Бесплатна» открытая модель только в том смысле, что не нужно платить за лицензию.

Обратная ошибка – купить продукт по эффектному демо, не прочитав условия обработки данных. Потом на проверке безопасности выясняется, что данные учащихся идут на обучение модели поставщика, привлечённые подрядчики не раскрыты, базы находятся за рубежом или поручения нет вовсе. Сделка срывается, когда вокруг продукта уже многое построено. Третья ошибка – забыть про трекинг: купленная функция, которая не умеет отправлять xAPI-утверждения, отлично выглядит в демо, но аналитика её не видит.

Избежать этих ошибок несложно. Новую функцию запускайте на облачном API и проверяйте, пользуются ли ею учащиеся и есть ли от неё польза: сначала проверка идеи, оптимизация инфраструктуры подождёт. Поставьте между своим кодом и провайдером тонкий слой абстракции, чтобы потом можно было его сменить. Читайте условия обработки данных до того, как вас впечатлит демо. О своей модели думайте, только когда фиксированные затраты оправданы стабильным объёмом, жёстким требованием хранить данные в своём контуре или необходимостью дообучать модель на своём контенте.

Расчёт: когда своя модель окупается

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

Фиксированные затраты на свою модель (иллюстративно):
  аренда одного производительного GPU в российском облаке
    ≈ 210 тыс. ₽/мес (сверяйте с прайсом облака)
  + полставки senior ML/инфраструктурного инженера
    ≈ 150 тыс. ₽/мес (половина медианы 304 тыс. ₽ на руки)
  ≈ 360 тыс. ₽/мес, почти не зависит от нагрузки

Облачный API по ставке тьютора из примера выше (≈ 3,6 ₽ на учащегося в месяц):
  окупаемость ≈ 360 000 ₽ / 3,6 ₽ ≈ 100 000 активных учащихся

Если ставка выбранной модели в 10 раз выше (≈ 36 ₽ на учащегося),
окупаемость наступает примерно с 10 000 учащихся; при редком
использовании может не наступить никогда.

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

Рисунок 3. Затраты в зависимости от месячного объёма. Расходы на облачный API начинаются почти с нуля и растут с использованием; у своей модели высокие постоянные затраты, которые почти не меняются. До точки пересечения дешевле API; своя модель выигрывает только после неё и только при стабильном объёме.

Короткий алгоритм выбора

Большинству команд хватает четырёх вопросов. Функция новая и непроверенная? Начните с облачного API: сначала проверка, потом оптимизация. Функция работает с чувствительными данными учащихся, которые не могут покинуть ваш контур? Выбирайте свою модель, on-prem-поставку модели провайдера или российского провайдера, который подпишет поручение, обрабатывает данные в России и не обучает модели на ваших запросах. Объём одновременно высокий и стабильный, а затраты на учащегося уже за точкой пересечения? Своя модель начинает окупаться. Нужна законченная, хорошо проработанная возможность, которую вы не хотите разрабатывать сами, например синтетические аватары или готовый тьютор? Купите продукт и подключите к нему свой трекинг. Гибридный подход (сейчас купить продукт или подключить API, а одну высоконагруженную функцию позже перенести к себе) – это не вынужденная полумера, а разумный вариант по умолчанию.

Рисунок 4. Как выбрать между покупкой, API и своей моделью. Новые и непроверенные функции запускают на облачном API, при чувствительных данных или высоком стабильном объёме выбирают свою модель, готовую проработанную возможность покупают. Большинство продуктов в итоге приходит к гибриду.

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

Фора Софт с 2005 года разрабатывает видеоконференции, стриминг, e-learning и ИИ-функции для видео. Когда клиенту нужны ИИ-тьютор, синтетические аватары, автосубтитры или генерация заданий, мы для каждой функции выбираем подходящий путь (купить, API или своя модель) с учётом объёма, требований к точности, чувствительности данных учащихся и зависимости от поставщика. Между продуктом и провайдером ставим тонкий слой абстракции, чтобы сегодняшний выбор не связал руки завтра. Для большинства функций мы советуем начинать с облачного API российского провайдера: он быстро подключается, а затраты на учащегося невелики. Свою модель или on-prem-поставку оставляем для большого объёма или жёстких требований к контуру, когда фиксированные затраты действительно окупаются. Каждую ИИ-функцию мы подключаем к трекингу и аналитике, а условия обработки данных читаем до демо: самая дешёвая в запуске функция бесполезна, если не проходит проверку безопасности и требований к персональным данным.

Главное

  • Три способа добавить ИИ: купить продукт, вызвать облачный API или развернуть открытую модель (плюс on-prem-поставка модели провайдера).
  • Выбор определяют четыре фактора: объём, требования к точности, чувствительность данных и готовность зависеть от поставщика.
  • Сравнивайте варианты по затратам на учащегося в месяц, пересчитав места, минуты и токены в эту единицу.
  • Для большинства продуктов выгоднее облачный API: в нашем примере тьютор стоит ≈ 3,6 ₽ на учащегося в месяц, и даже при ставке в 10 раз выше расходы меньше зарплаты одного инженера.
  • Своя модель окупается только при высоком стабильном объёме: в её фиксированные затраты входит работа дефицитных ML-инженеров.
  • Чтобы передать данные учащихся провайдеру, нужны поручение по ст. 6 152-ФЗ и базы в России; ИИ, который сам ставит итоговую оценку, попадает под ст. 16 152-ФЗ при любом поставщике.

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

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.