Судя по числу конференций и пресс-релизов, российские компании вкладываются в ИИ всё активнее. Но те, кто эти системы реально внедряет, оценивают выход в боевую эксплуатацию скромно: до продакшена добирается около 5% инициатив. Остальное оседает в виде эффектных презентаций, съехавших сроков и денег, которые уже не вернуть. И корень провала почти никогда не технический: проект просто не перевели на язык денег в самом начале.
Причин обычно называют много: не те данные, галлюцинации моделей, служба информационной безопасности, которая тормозит любое новшество. Такое действительно случается. Но будь дело в технике, тренд смотрел бы вверх: модели крепнут год от года, данных становится больше, а доля успешных внедрений стоит на месте.
Причина глубже. Львиная доля ИИ-проектов стартует с технологии: выбирают архитектуру, стек, набирают команду, нарезают спринты. А вопрос «зачем это бизнесу и через сколько вернутся вложения» всплывает позже, обычно когда потрачена уже треть бюджета, а развернуться назад означает признать, что с самого начала пошли не туда. Такие проекты тянут по инерции, а затем закрывают: не из-за слабой идеи, а потому что перевести её ценность в рубли так никто и не сумел.
Те немногие, кто доезжает до прода, идут ровно наоборот — от экономики.
В России 95% ИИ-проектов так и не выходят за пределы красивых слайдов и сожжённых бюджетов. Работающими становятся лишь 5%.
Пока не отвечен один предварительный вопрос, разговор об окупаемости бессмыслен: как именно ИИ будет приносить деньги? Вопрос кажется банальным, но именно его чаще всего и проскакивают. При этом всё многообразие сводится к трём сценариям, и между собой они не смешиваются.
ИИ автоматизирует рутину, снимает нагрузку с операторов, ускоряет обработку документов и модерацию. Метрика — сколько человеко-часов заменяет система и во что это обходится в рублях за квартал.
Здесь штат не режут: система помогает зарабатывать быстрее — одобрить кредит за 15 минут вместо недели, оценить поставщика за день вместо месяца. Метрика — дополнительная выручка за счёт скорости: маржа прежняя, а операций больше.
Рекомендательные системы, персонализация и скоринг напрямую влияют на конверсию и средний чек. Метрика — изменение выручки платформы.
Стоит впихнуть все три цели в одно техническое задание, и проект расползается в кашу. Формулировка «хотим, чтобы ИИ улучшил наш бизнес» выглядит как цель, а ведёт себя как её отсутствие. Спустя полгода вскрывается, что каждый держал в голове свой проект: кто-то оптимизировал ФОТ, кто-то гнался за конверсией, кто-то думал про доклад на конференции. Где нет метрики, там нет и предмета для разговора об успехе.
Предположим, с типом задачи разобрались. Дальше — деньги, и говорить о них нужно на правильном языке.
Фразу «модель стала точнее на 15%» финансовый директор пропустит мимо ушей — это не его словарь. Его словарь другой: «сэкономим X рублей за квартал» или «добавим Y рублей выручки при том же составе команды». Именно с такими числами проект попадает в следующий бюджетный цикл, а не идёт под нож как очередной дорогой эксперимент.
Арифметика простая: если проект способен принести сто миллионов, то пятьдесят миллионов на GPU: уже не трата, а вложение с понятной отдачей. Финансовый директор смотрит не на сумму расходов саму по себе, а на зазор между расходами и результатом.
Отдельная тема — честность. Желание накрутить прогноз ради согласованного бюджета понятно, но срабатывает оно один раз: через квартал придётся отчитываться живыми цифрами. Ошибочный, но честный расчёт — это опыт. Подтасованный — это конец доверия к команде.
Ещё один рабочий приём: считать вместе с заказчиком, а не вместо него. Пусть он сам подставит свои данные: по ФОТ, по потенциальной выручке. Как только он соглашается с собственными числами, возражение «а вдруг не окупится» отпадает само собой.
У честно посчитанной экономики есть приятный побочный эффект: она превращается в переговорный рычаг.
Вместо того чтобы назвать сумму и ждать сопротивления, сперва считают, сколько заказчик сэкономит или заработает. И только потом озвучивают свою цену — заведомо ниже этой величины. После этого спор идёт уже не о том, дорогая ли разработка, а о том, как делить полученную выгоду.
Но срабатывает это лишь при одном условии: прогноз честный, и обе стороны готовы в него верить. Поэтому совместный расчёт не просто способ вытащить данные, а подстраховка: если заказчик сам проставлял цифры, позже он не заявит, что «всё посчитали неправильно».
Теперь о неприятном. Эффект посчитать реально, а вот точно предсказать затраты почти нельзя.
Разработка на ИИ живёт по другим законам, чем большинство IT-проектов. Цена инфраструктуры пересматривается не раз в год, а раз в квартал: рынок несётся так, что смета полугодовой давности успевает устареть раньше, чем её утвердят.
Назвать конкретный бюджет и гарантировать заказчику, что он уложится в него на все сто, почти нереально. Вышел Qwen 3.6: нагрузка, которую мы держали на железе за тридцать тысяч долларов в месяц, теперь помещается в одну видеокарту.
Куда качнёт маятник в следующий раз — не угадаешь. Затраты способны как рухнуть, подобно истории с Qwen, так и вырасти: очередная версия модели может потребовать больше памяти, другого железа, перекройки архитектуры. Называть в таких условиях точную цифру значит: либо лукавить, либо закладывать такой запас, что цена перестаёт быть конкурентной.
Выход — работать с диапазоном: базовый сценарий плюс явно обозначенный буфер на смену инфраструктуры, с расшифровкой, что входит в каждую часть. «Мы не знаем» звучит как некомпетентность. «Рынок меняется быстро, вот конкретные риски и вот как мы их закладываем» — уже совсем другой разговор.
Последний денежный вопрос самый чувствительный. «Инхаус или SaaS» выглядит как технический спор. На деле решается другое: насколько вы готовы зависеть от чужого кода.
Мне попадались заказчики, у которых уже был «собственный ИИ». Открываешь — а внутри гирлянда обёрток if-else. Дают доступ к коду, а искусственным интеллектом там и не пахнет.
Скверный код можно переписать. С зависимостью сложнее. Когда бизнес-процесс, на котором держится выручка, крутится в чужом облаке и чужом репозитории, у компании не остаётся выбора — только платить по тарифам подрядчика. Уйти на другое решение либо невозможно, либо выйдет дороже, чем собрать всё заново.
Правило короткое: продукт, от которого зависит бизнес, делайте инхаус — чтобы он не превратился в чёрный ящик. Задача тривиальная и статичная: берите SaaS, своя разработка обойдётся кратно дороже.
Быстрый тест на самопроверку: что будет, если завтра подрядчик закроется или удвоит ценник? Ответ «катастрофа» — это про инхаус. Ответ «за пару недель переедем на аналог» — SaaS вполне подойдёт.
Сложность задачи здесь вообще ни при чём:
Рекомендательный движок, от которого зависит выручка платформы — инхаус, даже если арендовать его проще.
Чат-бот для HR со стандартными ответами — SaaS, даже если руки чешутся сделать своё.
Цена ошибки в первом случае несопоставимо выше.
Проект, стартовавший с технологии, почти всегда выходит дороже и мутнее, чем задумывался. Дело не в том, что команда некомпетентна, а в том, что без заранее заданной экономики неясно, что вообще считать успехом. Что-то сломалось — но что именно и чем это мерить? Инженеры отстаивают свои решения, руководство режет бюджет, проект хоронят как неудавшийся эксперимент.
А вот если начать с расчёта, ценность появляется даже у провала. Честный прогноз, который не сбылся — это данные: видно, где гипотеза не подтвердилась и что подкрутить в следующий заход.
Когда ошибка дёшева, её не страшно совершать. Считайте экономику до того, как деньги пошли в расход: тогда неудачная гипотеза оборачивается недорогим уроком, а не списанным бюджетом.
Вся разница между теми 5%, что дошли до прода, и оставшимися 95%: не в моделях и не в инженерах, а в том, что кто-то не поленился сесть и посчитать экономику заранее.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.