ИИ-проект сегодня можно запустить за несколько недель. Подключить модель, загрузить корпоративную базу знаний, собрать интерфейс, показать топ-менеджменту работающую демонстрацию и получить первый восторженный отзыв: «Наконец-то у нас тоже есть ИИ».
Но между красивым демо и промышленным сервисом есть неприятный разрыв. Модель может отвечать на вопросы, готовить черновики, искать документы и даже выглядеть убедительно. Это еще не означает, что она экономит деньги, ускоряет процесс или снижает нагрузку на сотрудников.
Главный вопрос к корпоративному ИИ все чаще звучит не как «какая модель умнее», а как «сколько стоит полезный результат». Не запрос к модели, не токен, не GPU-час, а именно действие, после которого сотрудник быстрее обработал обращение, нашел нужный документ, подготовил расчет, закрыл инцидент или принял управленческое решение.
«Судьба ИИ-проекта решается не при выборе модели, а на стыке бизнес-задачи, процессов, данных и инфраструктуры. Главная метрика здесь не количество запусков модели и не число пользователей, которым выдали доступ. Важнее стоимость одного полезного запроса», — говорит Игорь Юрин, технический директор, руководитель направления цифровизации и цифровой трансформации компании «ГИГАНТ — Компьютерные системы».
Если такой запрос обходится дороже ручной работы или привычной автоматизации, ИИ быстро теряет экономический смысл. Поэтому считать нужно не только стоимость модели, но и всю цепочку, которая превращает ответ нейросети в полезное действие.
Пилот работает, экономика нет
Массовое внедрение ИИ пока не стало массовым финансовым результатом. В исследовании McKinsey за 2025 год 88% респондентов сообщили, что их компании регулярно используют ИИ хотя бы в одной функции. Но влияние на EBIT на уровне всей организации отметили только 39%.
Еще жестче ситуацию описывает отчет MIT NANDA «The GenAI Divide: State of AI in Business 2025». По его данным, только 5% интегрированных корпоративных пилотов генеративного ИИ принесли значимую измеримую ценность. Большинство внедрений не показало влияния на финансовый результат, хотя технически работало и успешно проходило демонстрацию.
Проблема обычно начинается не с модели, а с постановки задачи. Компания запускает ИИ, потому что хочет попробовать технологию, но не фиксирует, какой именно процесс должен измениться, кто отвечает за результат и по какому показателю будет оцениваться эффект.
На демо ИИ-ассистент уверенно отвечает на вопрос по базе знаний. В реальной техподдержке ему уже нужен контекст: история инцидентов, прошлые решения, ключевые атрибуты заявки, статус клиента, договорные условия, права доступа, актуальные регламенты. Если этот контекст не подключен, модель вроде бы отвечает, но сотрудник все равно вручную проверяет факты и собирает данные из разных систем.
С проектной документацией происходит то же самое. На презентации модель быстро готовит черновик. В рабочем процессе она должна понимать, какой шаблон актуален, какая версия документа согласована, какие ограничения есть у конкретного объекта и кто принял итоговую правку. Без этих связей ИИ остается отдельной витриной, эффективность которой сложно измерить.
Пользователи задают вопросы, модель отвечает, но компания не понимает, сколько времени сэкономлено, какой этап ускорен, сколько ошибок снято и во сколько обошелся каждый полезный результат.
Так пилот зависает между ИТ, бизнесом, ИБ и финансами. ИТ отвечает за запуск. Бизнес не видит подтвержденного эффекта. Служба безопасности задает вопросы о данных. Финансовый блок не понимает, почему эксперимент нужно масштабировать. Инструмент может быть хорошим, но производственного процесса вокруг него нет.
GPU-час дешев только в прайсе
Облако удобно для проверки гипотез. Компания быстро получает доступ к вычислительным ресурсам, не покупает GPU-кластер и оплачивает только стартовый объем. Пока нагрузка небольшая и меняется от недели к неделе, такая схема часто выгоднее собственной инфраструктуры.
Но пилотная цена ничего не говорит о совокупной стоимости промышленной эксплуатации. В тарифе виден GPU-час, но за реальным сервисом стоит гораздо больше: хранение данных и моделей, исходящий трафик, резервирование, защита, интеграции, работа инженеров, мониторинг и сопровождение.
Есть и менее очевидная статья расходов. Облачный инстанс с GPU часто приходится держать включенным ради приемлемой задержки, хотя сама видеокарта простаивает большую часть времени. Поэтому дешевый на старте пилот при постоянной нагрузке может превратиться в дорогой сервис.
Один пользовательский вопрос к внутренней базе знаний на деле может запускать цепочку операций: поиск по корпоративным данным, подготовку контекста, несколько обращений к LLM, фильтрацию документов, проверку прав, сохранение истории, логирование и контроль результата. Если речь идет не о справочном вопросе, а о подготовке технического ответа или разборе обращения, цепочка становится еще длиннее.
«Цена GPU-часа в прайсе показывает только верхний слой расходов. Пока компания не считает хранение данных, трафик, резервирование, средства защиты, интеграцию и работу инженеров, облачный пилот кажется дешевым просто потому, что его полная промышленная себестоимость еще не видна», — отмечает Игорь Юрин.
Локальный программно-аппаратный комплекс меняет структуру затрат. Компания вкладывается в оборудование, сеть, электропитание, охлаждение и эксплуатацию, но получает предсказуемую стоимость вычислений, контроль над размещением данных и возможность настроить инфраструктуру под конкретную нагрузку.
Закрытый контур сам по себе не гарантирует выполнение всех требований безопасности. Но он упрощает контроль доступа, управление версиями моделей, расследование инцидентов и работу с чувствительными данными. Чем стабильнее и интенсивнее используется кластер, тем быстрее капитальные затраты распределяются между выполненными задачами.
Универсального порога, после которого собственное оборудование всегда дешевле облака, не существует. На результат влияют тип GPU, срок эксплуатации, цена электроэнергии, облачный тариф, скидки за резервирование, требования к отказоустойчивости и нагрузка на команду сопровождения. Поэтому сравнивать нужно не абстрактный GPU-час, а стоимость конкретной рабочей нагрузки за весь срок эксплуатации.
Гибрид работает, если данные можно разделить
Выбор между облаком и собственным кластером не всегда должен быть бинарным. При неравномерной нагрузке может работать гибридная модель. Внутренний контур берет на себя штатные сценарии: регулярные запросы, работу с чувствительными данными, сервисы с предсказуемой задержкой. Облако подключается там, где нужен временный прирост мощности: дообучение модели, сезонный рост обращений, разовый анализ большой выборки данных.
Так компания не оплачивает ежедневную эксплуатацию по облачному тарифу и одновременно не покупает железо под несколько самых напряженных дней в году. Но гибрид эффективен только при одном условии: задачи действительно можно отделить друг от друга.
Внутри чаще логично держать поиск по коммерческим и чувствительным корпоративным данным, инженерной документации, обращениям клиентов с персональными данными, внутренним отчетам и сценариям помощи дежурной смене при разборе инцидента. Наружу можно выносить задачи, которые не тянут за собой критичные данные: обучение на обезличенной выборке, разовый расчет по открытым данным, тестирование новой модели на некритичном сценарии.
Если вместе с вычислениями во внешний контур приходится передавать документы, служебные данные и контент, экономия быстро исчезает. Компания платит уже не только за GPU, но и за трафик, хранение, интеграции, отдельный контроль безопасности и объяснения аудиторам.
В таком случае гибрид превращается в две разные площадки, которые нужно сопровождать, защищать и управлять ими отдельно. Ошибка возникает и в обратную сторону: компания покупает инфраструктуру «на вырост», закладывает спрос на несколько лет вперед, берет максимальную конфигурацию, а использует лишь малую часть кластера. Или наоборот: нагрузка уже стала постоянной, но бизнес продолжает платить за нее как за эксперимент в облаке.
В обоих случаях экономика ломается не из-за ИИ, а из-за неверно рассчитанного профиля нагрузки.
Когда инфраструктура начинает возвращать деньги
Экономику ИИ-инфраструктуры можно увидеть на примере проекта для крупной организации с распределенной инфраструктурой, большим массивом технической документации и постоянным потоком внутренних запросов от инженерных, сервисных, эксплуатационных и научно-изыскательских подразделений.
ПАК ИИ не был универсальным чат-ботом для всех. Он закрывал конкретные рабочие сценарии: инженерные расчеты на больших данных, поиск по внутренней базе регламентов и проектной документации, подготовку черновиков типовых технических ответов, первичный разбор обращений и помощь специалистам при работе с накопленной экспертизой.
Экономический эффект складывался из нескольких частей. Инженеры и специалисты поддержки тратили меньше времени на поиск документов и подготовку однотипных ответов. Обращения обрабатывались быстрее. Эксперты второй линии получали уже разобранные случаи, а не весь поток первичных вопросов. Отдельный эффект давала инфраструктура: при сопоставимой нагрузке собственный контур снижал стоимость полезного запроса по сравнению с постоянным использованием облачных GPU.
В расчетной модели капитальные затраты на ПАК ИИ составили 76,25 млн рублей, ежегодные операционные расходы — 24,18 млн рублей, ожидаемый валовой экономический эффект — 101,82 млн рублей в год. Пятилетняя совокупная стоимость владения собственным комплексом составила 204,75 млн рублей против 533,62 млн рублей при использовании облачной модели. Разница достигла 328,87 млн рублей, расчетный ROI за пять лет — 148,7%. Первоначальные вложения возвращались примерно за год.
В консервативном сценарии, где масштаб использования и бизнес-эффект сокращались вдвое, срок окупаемости увеличивался до полутора лет, а пятилетний ROI снижался до 24%. В оптимистичном сценарии расчет показывал окупаемость за пять месяцев и ROI 339%.
Такой разброс объясняет главное: результат зависит не столько от цены сервера или производительности модели, сколько от количества рабочих сценариев и подтвержденной ценности каждого из них.
«Расчет ИИ-инфраструктуры стоит начинать не с вопроса “сколько GPU купить”, а с другого: сколько полезных запросов в месяц пройдет через контур, сколько будет стоить один такой запрос, какие ресурсы он позволит сэкономить и какой эффект даст бизнесу», — подчеркивает Игорь Юрин.
Собственный ПАК ИИ имеет смысл считать всерьез, если данные нельзя свободно передавать во внешний сервис, нагрузка стала регулярной, задержка важна для пользователя или процесса, горизонт проекта измеряется годами, а компании нужен контроль над доступами, версиями моделей и историей изменений.
Если совпадает несколько этих условий, речь уже не о покупке железа «на всякий случай», а о полноценной TCO-модели. В такой ситуации инфраструктура перестает быть технической деталью и становится частью бизнес-модели ИИ-проекта.
Почему 95% пилотов остаются презентациями
ИИ сам по себе не создает финансовый эффект. Закрытый контур сам по себе не гарантирует безопасность. Облако само по себе не делает проект дешевым. И самая умная модель не спасает сценарий, в котором не посчитаны данные, процесс, нагрузка и стоимость результата.
В успешные 5% ИИ-внедрений попадают не те компании, которые быстрее всех подключили новую технологию. Попадают те, кто заранее понял, где именно ИИ создает измеримую ценность, какие данные ему нужны, сколько стоит промышленная эксплуатация и какие ограничения нельзя обойти после запуска.
Если эта логика собрана до масштабирования, пилот получает шанс стать рабочим инструментом. Если нет, он остается демонстрацией, которую трудно защищать перед советом директоров, финансовым директором, ИБ и бизнес-заказчиком.
Корпоративный ИИ начинается не с вопроса «верим ли мы в технологию». Он начинается с более жесткого вопроса: какой процесс станет быстрее, дешевле или надежнее, сколько будет стоить один полезный результат и кто готов отвечать за его качество.
Без этого любой ИИ-пилот рискует остаться красивой презентацией. Просто теперь очень дорогой.
Комментарии