«Сколько стоит внедрить ИИ» — вопрос, на который честный ответ звучит как уклонение: смотря что внедрять. Это не отговорка. Разброс здесь такой же, как в вопросе «сколько стоит построить здание»: киоск и заводской корпус строятся из одних материалов, но смета отличается на два порядка. Ниже — разбор того, из чего эта смета складывается, что в ней прячется и как посчитать выгоду до того, как вы подпишете договор.
Почему одной цифры не существует
Стоимость ИИ-проекта почти не зависит от того, какая модель стоит внутри. Открытые модели бесплатны, облачные стоят копейки за запрос, и в большинстве проектов расходы на саму модель — это единицы процентов сметы. Платят не за модель. Платят за то, чтобы она заработала в конкретной компании с её данными, её системами и её требованиями безопасности.
Отсюда практическое следствие: две компании могут заказать «чат-бота по документам» и получить сметы, отличающиеся в пять раз, — при том, что технология одна. Разница будет в количестве документов, в их состоянии, в числе систем, к которым надо подключиться, и в том, можно ли выпустить данные в облако.
Четыре фактора, которые определяют цену
Количество сценариев
Один процесс или пять связанных — это принципиально разные проекты. Ассистент, который отвечает на вопросы по регламенту, и ассистент, который отвечает, а потом сам создаёт заявку, согласует её и отчитывается, различаются не «доработкой», а архитектурой. Первый читает. Второй действует, а значит, ему нужны права, проверки, откаты и журнал.
Практический совет: на старте берите один сценарий. Не самый заметный, а тот, где ошибка стоит денег и её легко посчитать. Такой сценарий одновременно и проще внедрить, и проще защитить перед финансовым директором.
Глубина интеграции
Это самая недооценённая статья. Модель, работающая в отдельном окне, стоит одних денег. Модель, которая читает из CRM, пишет в ERP, дёргает телефонию и отдаёт события в корпоративную шину, — совсем других. Каждая интеграция это не только код: это согласование доступов, тестовый контур, обработка отказов смежной системы и ответ на вопрос, что делать, когда она недоступна.
Хорошая новость в том, что интеграции масштабируются лучше моделей. Первая обходится дорого, пятая — заметно дешевле: инфраструктура, аутентификация и мониторинг уже есть.
Где должны лежать данные
Три сценария, три уровня стоимости. Облачная модель через API — самый дешёвый и быстрый путь, но данные уходят наружу. Российское облако по 152-ФЗ — компромисс. Полностью закрытый контур с локальной моделью на вашем железе — самый дорогой вариант: к работе добавляются подбор и закупка GPU, развёртывание, обновления и вся эксплуатация.
Решать это надо в самом начале, а не в середине проекта. Переезд из облака в закрытый контур на позднем этапе означает смену модели, повторные замеры качества и переработку значительной части решения.
Состояние данных
Фраза «у нас есть данные» и фраза «у нас есть данные, пригодные для обучения» — не синонимы. Между ними обычно лежит работа: выгрузка, чистка, приведение к одному формату, разметка. В проектах компьютерного зрения и распознавания документов подготовка данных нередко занимает больше времени, чем обучение модели.
Пять этапов, из которых складывается работа
- Диагностика. Разбираем процесс, смотрим на реальные данные, формулируем измеримый критерий успеха и оцениваем, есть ли вообще задача для ИИ. Иногда результат диагностики — рекомендация не делать ИИ-проект, а починить процесс или отчётность.
- Прототип. Работающая версия на ваших данных, без интеграций и красивого интерфейса. Задача одна: проверить, достижимо ли нужное качество в принципе. Срок — обычно до двух недель.
- Пилот. Прототип превращается в решение, которое работает на реальном участке с ограниченным охватом: интеграции, роли, логирование, обработка отказов. Здесь появляются первые честные цифры эффекта. Срок — обычно 3–6 недель.
- Промышленное внедрение. Масштабирование на весь процесс: нагрузка, отказоустойчивость, безопасность, приёмка, обучение сотрудников, документация. Срок с интеграциями — обычно 4–12 недель.
- Сопровождение. Мониторинг качества, отслеживание дрейфа данных, дообучение, обновления. Это не гарантийный ремонт, а постоянная работа: модель без присмотра деградирует вместе с изменением реальности вокруг неё.
Между этапами должна быть возможность остановиться. Если прототип не дал нужного качества, правильное решение — не идти в пилот, а закрыть гипотезу и сэкономить бюджет. Договор, в котором такой точки выхода нет, работает против заказчика.
Ориентиры по деньгам
Мы публикуем вилки открыто, чтобы разговор начинался с реальности, а не с угадывания. Это ориентиры под рынок РФ, а не оферта: точная цифра появляется после диагностики.
- Прототип — от 600 тыс. ₽. Проверка гипотезы на ваших данных, без интеграций.
- Пилот — 1,5–3,5 млн ₽. Работающее решение на ограниченном участке с интеграциями и замером эффекта.
- Промышленное внедрение — считается индивидуально. Слишком сильно зависит от числа сценариев, нагрузки и требований к контуру.
Вилка пилота широкая не из-за неопределённости подрядчика, а потому что внутри неё лежат разные проекты. Пилот с одной интеграцией и готовыми данными уходит к нижней границе. Пилот с закрытым контуром, тремя интеграциями и разметкой с нуля — к верхней.
Что съедает бюджет незаметно
Разметка данных
Самая частая недооценка. Разметить несколько тысяч примеров — это человеко-недели, и делать это должны люди, понимающие предмет: технолог, юрист, врач. Их время дороже времени разработчика, и его почти никогда не закладывают в план.
Доступы и согласования
Получение тестового доступа к корпоративной системе иногда занимает больше календарного времени, чем разработка интеграции с ней. Это не строчка в смете, но это срок, а срок — деньги.
Инфраструктура
Для закрытого контура нужны серверы с GPU, а к ним — размещение, питание, охлаждение и обновления. Иногда выгоднее арендовать мощности в российском облаке, иногда — купить. Считать это надо до старта: разница в стоимости владения за два года бывает кратной.
Приёмка и работа с людьми
Система, которой не пользуются, не окупается. Обучение сотрудников, изменение инструкций, период параллельной работы старым и новым способом — всё это реальные затраты. Их часто не видят в смете подрядчика, потому что они лежат на стороне заказчика.
Сопровождение после запуска
Заложите его сразу. Данные меняются: приходят новые поставщики, меняется оснастка, обновляется законодательство. Модель, которая была точна в марте, к декабрю может просесть — и узнать об этом лучше из мониторинга, чем из жалоб.
Как посчитать окупаемость до того, как платить
Считать надо не «эффект от ИИ», а разницу между двумя понятными числами: во что процесс обходится сейчас и во что он будет обходиться после. Порядок действий такой.
- Опишите текущую стоимость процесса: сколько людей, сколько часов, какая ставка. Прибавьте цену ошибок — возвраты, штрафы, переделки, упущенные сделки.
- Определите, какую долю этой работы забирает система. Не всю: часть случаев останется человеку, и это нормально.
- Умножьте на реалистичную точность, а не на желаемую. Если модель даёт 92%, оставшиеся 8% всё ещё стоят денег — их надо оставить в расчёте.
- Вычтите стоимость владения: сопровождение, инфраструктуру, время сотрудников на проверку спорных случаев.
- Разделите стоимость проекта на полученную месячную выгоду. Получится срок окупаемости в месяцах.
Пример структуры расчёта на нашем проекте по контролю качества. Система распознаёт дефекты с точностью 92%, доля возвратов снизилась на 18%. Чтобы превратить это в деньги, нужны три ваших числа: стоимость одного возврата, их количество в месяц и фонд оплаты труда контролёров, освободившихся от сплошного отсмотра. Умножаете первое на второе и на 0,18, прибавляете высвобожденный фонд, вычитаете сопровождение — получаете месячную выгоду. Дальше делите на стоимость проекта.
Метрики модели здесь настоящие — 92% точности и снижение возвратов на 18% взяты из нашего кейса и подтверждены замером на отложенной выборке. А вот денежные величины подставляете вы: стоимость возврата и фонд оплаты труда у каждого свои, и переносить чужие цифры в свой расчёт бессмысленно.
Три схемы работы и что они означают для бюджета
Одна и та же задача может быть оформлена тремя разными способами, и от выбора зависит, кто несёт риск неопределённости.
- Фиксированная цена за этап. Подрядчик берёт риск на себя и закладывает его в цену. Работает, когда объём понятен: прототип на готовых данных, интеграция с известной системой. Требует внятного описания результата — иначе спор о том, что считать сделанным, неизбежен.
- Время и материалы. Платите за фактическую работу. Дешевле при высокой неопределённости, но риск переноса сроков и роста сметы ваш. Разумно ограничивать потолком бюджета на этап.
- Выделенная команда. Подходит, когда ИИ становится постоянной частью продукта, а не разовым проектом. Дороже в месяц, но снимает накладные расходы на постановку задач заново и на передачу контекста.
На практике смешанная схема работает лучше всего: фиксированная цена на диагностику и прототип, где объём понятен, и время с потолком на пилот, где неопределённость выше.
На чём можно сэкономить, а на чём нельзя
Где экономия безопасна
Интерфейс на этапе пилота может быть некрасивым — важно, работает ли логика. Открытая модель вместо коммерческой часто даёт сопоставимое качество на узкой задаче. Один сценарий вместо пяти сокращает смету кратно, а научит тому же самому. Облако вместо своего железа на этапе проверки гипотезы избавляет от закупки, которая может оказаться ненужной.
Где экономия обходится дороже
Разметка данных: сэкономленные здесь недели возвращаются моделью, которая не работает. Замер качества на отложенной выборке: без него вы не знаете, что купили. Логирование решений модели: без журнала невозможно разобрать ни одну спорную ситуацию и нечем дообучать. И сопровождение: система без присмотра тихо деградирует, а обнаруживается это тогда, когда доверие к ней уже потеряно.
Отдельно про пилотный этап: соблазн пропустить его и сразу заказать промышленное внедрение выглядит экономией времени, но на деле это ставка на то, что нужное качество достижимо. Проверка гипотезы стоит заметно дешевле, чем внедрение, которое пришлось свернуть.
Три признака плохой сметы
- Одна строка «Разработка ИИ-решения» и общая сумма. Такую смету невозможно проверить и невозможно сократить: непонятно, от чего отказываться.
- Нет этапа проверки гипотезы. Если подрядчик готов сразу делать промышленное внедрение, не убедившись, что нужное качество достижимо на ваших данных, риск целиком ваш.
- Нет строки на сопровождение. Значит, либо её добавят потом, либо после сдачи система останется без присмотра — и оба варианта плохие.
Что спросить у подрядчика до подписания
- Какой измеримый критерий успеха у этапа и что происходит, если он не достигнут? Ответ «будем дорабатывать» означает, что риск не разделён.
- На каких данных будет проверяться качество и кто их размечает? Если разметка на вас — это ваши человеко-недели, и их надо планировать.
- Где физически будут находиться данные на каждом этапе, включая обучение и отладку? Ответ должен быть конкретным, а не «в защищённом контуре».
- Что входит в сопровождение, сколько оно стоит в месяц и что будет с решением, если мы прекратим сотрудничество? Модель и код должны оставаться у вас.
- Какие три вещи в этом проекте могут пойти не так? Подрядчик, который не может назвать риски, либо не делал похожих проектов, либо не хочет о них говорить.
Коротко
- Цена ИИ-проекта определяется не моделью, а количеством сценариев, глубиной интеграций, требованиями к контуру и состоянием данных.
- Ориентиры: прототип — от 600 тыс. ₽, пилот — 1,5–3,5 млн ₽, промышленное внедрение — индивидуально.
- Незаметные статьи расходов — разметка, согласование доступов, инфраструктура, обучение людей и сопровождение.
- Окупаемость считается как разница стоимости процесса до и после, с учётом реальной, а не желаемой точности.
- Начинать стоит с одного сценария, где цена ошибки понятна и измерима, и с этапа, который можно остановить без потери всего бюджета.