Экономика ИИ: как считать окупаемость, чтобы проект не закрыли

Российские компании вкладывают в ИИ всё больше — судя по конференциям и пресс‑релизам. Но по оценкам тех, кто эти проекты внедряет, до реальной работы доходит примерно один из двадцати. Остальное — красивые презентации, затянувшиеся сроки и бюджеты, которые уже не вернёшь. Главная причина провалов не техническая. Дело в том, что проект с самого начала не обосновали в деньгах.

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

Дело в другом. Большинство ИИ‑проектов начинаются с технологии: архитектура, стек, команда, спринты. Вопрос «зачем это бизнесу и когда окупится» появляется позже — обычно, когда треть бюджета уже потрачена, а остановиться значит признать, что с самого начала пошли не туда. Доводят по инерции, потом закрывают. Не потому что проект плохой, а потому что объяснить его ценность в деньгах так никто и не смог.

Те 5%, что всё же добираются до прода, начинают с другого конца — с экономики.

В России 95% ИИ‑проектов не доходят до продакшена и остаются на этапе красивых презентаций и сожжённых бюджетов. И всего 5% реально выходят в прод

Три способа заработать на ИИ — и почему их нельзя смешивать

Разговор об окупаемости невозможен, пока не решён один предварительный вопрос: каким именно способом ИИ будет зарабатывать деньги? Звучит банально, но большинство проектов его пропускают. Всё многообразие сводится к трём сценариям, и между собой они не смешиваются.

Расчёт, который защищают перед финансовым директором

Допустим, с типом задачи определились. Теперь нужно поговорить про деньги — и поговорить правильно.

Финансовый директор не оценит «модель теперь точнее на 15%» — это не его язык. Его язык: «сэкономим X рублей в квартал» или «получим дополнительно Y рублей выручки при тех же затратах на команду». Именно с этими числами проект попадёт в следующий бюджетный цикл, а не будет срезан как очередной дорогой эксперимент.

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

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

Есть ещё один приём: делать расчёт вместе с заказчиком, а не за него. Пусть он сам подставит свои данные — по ФОТ, по потенциальной выручке. Если он согласен с собственными числами, возражение «а вдруг не окупится» снимается само.

Ценообразование, которое убирает возражение «дорого»

У правильно посчитанной экономики есть побочный эффект: она же становится инструментом переговоров.

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

Почему фиксированный бюджет — это обещание, которое нельзя выполнить

Теперь о неудобном. Посчитать эффект можно. Точно подсчитать затраты — почти нельзя.

ИИ‑разработка не похожа на большинство IT‑проектов. Стоимость инфраструктуры меняется не по годам, а по кварталам — рынок движется так быстро, что смета полугодовой давности устаревает раньше, чем её успели утвердить.

Рассчитать конкретный бюджет и пообещать заказчику, что он в него уложится на 100%, крайне сложно. Вышел Qwen 3.6 — и то, что мы запускали на мощностях за тридцать тысяч долларов в месяц, теперь крутится на одной видеокарте

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

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

Inhouse или SaaS: стратегический выбор, который выглядит техническим

Последний денежный вопрос — и самый чувствительный. Inhouse или SaaS кажется технической историей. На деле решается, насколько вы готовы зависеть от чужого кода.

Я общался с заказчиками, у которых уже был «свой ИИ». А внутри — набор обёрток if‑else. Получали доступ к коду — и искусственным интеллектом там особо не пахло

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

Простой вопрос для самопроверки: что случится, если завтра подрядчик закроется или поднимет ценник вдвое? «Катастрофа» — это inhouse‑задача. «Переедем на аналог за пару недель» — SaaS нормальный выбор.

Сложность задачи тут вообще не критерий:

1. Рекомендательный движок, от которого зависит выручка платформы, — inhouse, даже если его проще взять в аренду.
2. Чат‑бот для HR с типовыми ответами — SaaS, даже если технически хочется сделать своё.

Цена ошибки в первом случае несопоставимо выше.

С чего на самом деле начинается окупаемость

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

Если же начать с расчёта, даже провал даёт что‑то ценное. Честный прогноз, который не сбылся, — это информация: вот где гипотеза не подтвердилась, вот что уточнить в следующий раз.

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

Вся разница между 5%, что доходят до прода, и остальными 95% — не в моделях и не в инженерах. А в том, что кто‑то сел и посчитал экономику заранее.