Антон Хаймовский: «ИИ-проекты закрываются, потому что экономику не посчитали до старта»
Сегодня практически каждая компания заявляет о планах внедрения ИИ, но статистика по результатам выглядит тревожно. Как вы оцениваете ситуацию?
По данным Gartner за 2025 год, в 63% организаций либо не имеют правильных практик управления данными для ИИ, либо не уверены в их наличии. А 57% руководителей провалившихся проектов назвали причиной нереалистичные ожидания. В целом это объяснимо и, я бы даже сказал, нормально. Технология новая, рынок учится применять ее в практических задачах. В одни процессы ИИ встраивается относительно легко, другие требуют более тщательной подготовки.
В чем тут может быть причина?
Частая ошибка, когда внедрение ИИ становится целью само по себе. В реальности цель — это измеримый бизнес-результат, например, сокращение времени обработки заявки, снижение процента ошибок, освобождение сотрудников от рутины. Другая распространенная ошибка — непонимание того, как просчитывать экономику ИИ-проектов, в каких метриках определять успех и как прикладывать их к своим процессам.
Как тогда правильно ставить цели для ИИ-проекта?
Мы предлагаем использовать фреймворк SMART, адаптированный под специфику ИИ. Критерии здесь работают немного иначе, чем в классическом управлении проектами. Например, при оценке значимости всегда следует сравнивать ИИ-решение с альтернативами. Иногда изменение самого процесса дает сопоставимый результат при меньших затратах.
Как на практике понять, нужен ли проекту ИИ или достаточно более простого решения?
Самый простой вопрос для проверки: можно ли описать процесс, который мы планируем автоматизировать, четкими правилами? Если да, то, скорее всего, здесь достаточно классической автоматизации или инструментов роботизации (RPA).
Приведу два примера, которые хорошо показывают эту разницу.
Первый — когда банк получает более 50 тысяч клиентских обращений в месяц. Значительную долю составляют сложные запросы: почему не прошел платеж, как оспорить транзакцию. Оператор в процессе разбора ситуации открывает до пяти различных систем и в среднем тратит на кейс 12 минут. В таком сценарии требуется понимание естественного языка, работа с контекстом, выбор различных инструментов. Это задача для агентной системы.
Второй кейс — тот же банк, другая задача: обработка заявок на потребительские кредиты. Заявки поступают через современный веб-портал, но учетная система и база скоринговых правил — устаревшие legacy-системы без API. Операторы вручную открывают заявки и переносят данные в автоматизированную банковскую систему, после чего запускают проверку в скоринговой системе. Среднее время обработки одной заявки — 15 минут. Высокий объем рутины ведет к опечаткам и выгоранию сотрудников. При этом процесс абсолютно стандартизирован, данные поступают в определенном формате, критерии проверок жестко регламентированы. Здесь оптимальное решение — классическое RPA. Такая автоматизация обойдется дешевле, чем ИИ, к тому же ее проще внедрить.
Мы в Content AI не рекомендуем на старте внедрение ИИ, если видим, что задача может быть решена другими методами автоматизации. Например, с потоковой обработкой первичных бухгалтерских документов эффективно справляется IDP-платформа ContentCapture, в которой классические методы распознавания и извлечения данных работают в связке с RPA-инструментами. Это позволяет решать задачу качественно и с минимумом затрат.
Поговорим о финансовой стороне вопроса. Из чего складываются затраты на ИИ?
Экономика ИИ-проектов принципиально отличается от классической ИТ-автоматизации. Традиционные системы работают по детерминированным правилам и дают гарантированный результат. ИИ работает с вероятностями, где точность 90–95% на легких задачах считается хорошим показателем, но это означает, что в 5–10% случаев система может ошибиться. Такова природа технологии, и это нужно учитывать. При планировании бюджета в проект нужно закладывать механизмы контроля и ручной обработки исключений. Далее стоимость проектов определяется типом используемых решений: SaaS/SaaS по API, on-premise, кастомная разработка. У каждого — своя структура затрат.
SaaS/SaaS по API — готовое облачное решение. Затраты относительно невысокие, если не требуется сложная интеграция, и внедрить такой проект можно за несколько недель. Его ключевая особенность заключается в том, что затраты растут пропорционально объему. Иными словами, при малом трафике это выгодно, но при росте объемов будут расти и затраты.
On-premise — готовое решение на собственной инфраструктуре. Стартовые инвестиции здесь существенные, так как включают закупку лицензий на ПО, приобретение или аренду GPU-серверов, затраты на интеграцию. Внедрение занимает от одного до трех месяцев. Регулярные расходы при этом условно фиксированы и не зависят от объема обработки или политики ценообразования облачных провайдеров. При высоких объемах операций собственный контур в долгосрочной перспективе значительно выгоднее.
Кастомная разработка — решение с нуля или через дообучение модели под конкретные задачи. Максимальные инвестиции, как и в on-premise, на старте проекта, срок внедрения — от четырех месяцев. Этот подход оправдан в тех случаях, когда готовые решения не в полной мере соответствуют специфике бизнеса. Для крупных заказчиков это работает, эффект масштаба окупает вложения.
На каком объеме операций имеет смысл задумываться о собственной инфраструктуре?
Покажу на примере нашего кейса с крупным банком из топ-20 с 5 млн клиентов. Если в среднем клиент (юридические и физические лица вместе с учетом прерывания и возобновления сессий) генерирует восемь обращений в месяц и 80% запросов уходят на первичную обработку ИИ, получаем 32 млн запросов ежемесячно.
В облаке при условной цене запроса 0,04 руб. получается примерно 15,4 млн в год за API, плюс первоначальные расходы на интеграцию — около 500 тыс. единоразово. Итого за пять лет — около 77,3 млн.
При выстраивании инфраструктуры в собственном контуре для решения одной задачи основные затраты лягут на «железо». Допустим, стоимость GPU-серверов — 48 млн (шесть серверов со сроком полезного использования пять лет), расходы на создание ЦОДа — 10 млн, порядка 4 млн на бессрочные лицензии. Таким образом, стартовые инвестиции составляют 62 млн. Предположим, что годовые операционные расходы — 11,6 млн (обслуживание оборудования, 1 DevOps и 1 MLOps, техподдержка). Общий объем инвестиций за пять лет — 120 млн.
То есть для одной задачи облако выгоднее?
Да, но собственный контур редко обслуживает одну задачу. В банке обычно есть и антифрод-мониторинг, и скоринг, и аналитика. Предположим, что в дополнение к 32 млн запросов по обработке обращений ежегодно необходимо обрабатывать 80 млн запросов по этим трем направлениям. Стоимость обработки дополнительных запросов составит 0,02 рубля за запрос. Общее количество обрабатываемых запросов — 112 млн в месяц.
С учетом указанных выше вводных, обработка всех задач в облаке обойдется в 175 млн за пять лет (173 млн обработка + 2 млн интеграция).
В собственном контуре — 132 млн (с учетом увеличения лицензий до 4 штук). Но здесь также нужно учитывать затраты на расширение инфраструктуры, если это будет необходимо для обработки дополнительных задач.
Что чаще всего забывают в расчете стоимости владения?
То, что я отметил выше, — новые мощности, необходимые при масштабировании или добавлении сценариев. Мы рекомендуем закладывать сверху 15–20% на резервное оборудование, продление лицензий, неплановые ремонты.
В on-premise-проектах могут упускать затраты на персонал. Между тем, DevOps и MLOps-специалисты для поддержки собственного контура обойдутся в 250–700 тысяч рублей ежемесячно.
Для банков и других регулируемых отраслей отдельной статьей затрат является информационная безопасность. ИИ-проект должен пройти согласование с ИБ-службой, для запуска моделей может требоваться развертывание изолированных сегментов сети. Также нередко решение должно пройти аттестацию ФСТЭК или ФСБ. Эти задачи могут занимать месяцы и обходиться в миллионы рублей.
Отдельная и весомая статья расходов связана с внедрением изменений в компании. ИИ-автоматизация требует обучения сотрудников, адаптации регламентов, иногда комплексных организационных изменений. Все эти неочевидные на первый взгляд расходы могут добавлять до 20% к базовой оценке стоимости владения.
Есть ли понятная формула точки безубыточности, с которой можно начать расчеты?
Да, берете годовые условно постоянные расходы на собственный контур — амортизация оборудования, лицензии и др. — вычитаете фиксированные расходы на облако, стоимость интеграции в нашем примере, и делите полученную величину на стоимость одного запроса в облаке в год. Получаете минимальный объем, при котором CAPEX становится выгоднее.
Для нашего банка с одной задачей эта точка — 50 миллионов запросов в месяц. При расчетном объеме в 32 млн облако выгоднее.
Но когда добавляются еще три задачи, картина меняется. Средневзвешенная стоимость запроса снижается, при неизменности используемой инфраструктуры, а точка безубыточности для четырех задач составит около 85 миллионов запросов в месяц. При суммарном объеме в 112 млн обрабатываемых запросов собственный контур уже выгоднее.
При этом важно понимать, что точка безубыточности по годовым расходам и полная окупаемость стартовых инвестиций — это разные вещи. Можно выйти на уровень, когда ежегодные расходы на CAPEX ниже, чем на облако, но при этом еще не отбить первоначальные вложения. Это нужно считать отдельно.
Грубый ориентир для первичной оценки: до 50 млн запросов в месяц — облако, свыше 50 млн — стоит считать собственный контур. Если задач несколько и их можно объединить на одной инфраструктуре, CAPEX почти всегда оказывается выгоднее.
Что бы вы посоветовали руководителю на пороге ИИ-проекта?
Возможно, повторюсь, но это действительно ключевые вещи: сформулируйте цель в измеримых бизнес-терминах, оцените структуру затрат, выберите OPEX или CAPEX на основе объема и горизонта планирования, не забудьте о скрытых издержках. И главное — каждый успешный ИИ-проект начинается с правильного вопроса: какую бизнес-проблему нужно решить? Компании, подходящие к внедрению ИИ осознанно, достигают положительного ROI втрое чаще.
Опубликовано 28.05.2026
