SIBERIA / СТАТЬИ / 03
От демо к результату: как довести ИИ-проект до денег
Как перейти от впечатляющего пилота к работающему ИИ-решению с измеримым эффектом и понятной экономикой.
Сделать впечатляющую демонстрацию искусственного интеллекта сегодня сравнительно просто: достаточно готовой модели, нескольких документов и пары недель работы. Намного сложнее превратить её в решение, которое выдержит реальную нагрузку, встроится в процессы компании, будет соответствовать требованиям безопасности и даст измеримый бизнес-результат.
Именно здесь останавливается большинство проектов. Причина редко в том, что ИИ «не справился». Чаще с самого начала не было понятно, какую задачу он решает, сколько это стоит и кто будет сопровождать решение после запуска.

Путь ИИ-проекта · 2 точки решения, цикл сопровождения
У ИИ-проекта две точки, где правильно остановиться, и ни одной точки, где работа заканчивается. Разберём каждый этап.
Начинать нужно с проблемы, а не с ИИ
Самая дорогая ошибка идёт до написания первой строчки кода: компания решает «нам нужен ИИ» и только потом ищет, куда его приложить. В таком проекте нет критерия успеха, а значит, нет и способа понять, окупились ли вложения.
«Начинать нужно не с желания внедрить ИИ, а с конкретной бизнес-задачи. Если выяснится, что её эффективнее решить без искусственного интеллекта, это тоже правильный результат. Простые аналитические алгоритмы более предсказуемы, контролируемы и, как правило, дешевле», — говорит главный конструктор программно-аппаратных комплексов ЛАНИТ-ТЕРКОМ Михаил Смирнов.
Хорошо сформулированная задача отвечает на четыре вопроса:
Что именно сейчас не так? Не «хотим автоматизировать документооборот», а «проверка одного договора занимает три дня, и из-за этого мы теряем сделки».
Сколько это стоит сегодня? Часы сотрудников, штрафы, упущенная выручка, брак. Без этой цифры нельзя посчитать эффект.
Какой результат будет считаться успехом? Конкретная метрика и порог: «проверка за один день без роста числа пропущенных рисков».
Кто владеет процессом? У результата должен быть владелец со стороны бизнеса, а не только ИТ-команда.
После такого разбора часто оказывается, что нужен не ИИ, а правило в учётной системе, отчёт или изменение регламента. Это не провал проекта, а сэкономленные месяцы и бюджет. ИИ оправдан там, где данные неструктурированы (тексты, изображения, речь), а правил слишком много, чтобы прописать их вручную.
Пилот и внедрение — это разные проекты
Пилот отвечает на вопрос «может ли это работать?». Внедрение отвечает на другой: «будет ли это работать каждый день, у всех пользователей, с любыми данными и без участия разработчиков?». Между этими ответами — большая часть работы и бюджета.
| Пилот | Полноценное внедрение | |
|---|---|---|
| Данные | Отобранная и очищенная выборка | Живой поток с ошибками, пропусками и новыми форматами |
| Пользователи | Десяток заинтересованных сотрудников | Все, включая скептиков |
| Нагрузка | Десятки запросов в день | Реальный поток и пики |
| Интеграции | Выгрузка в Excel или ручная передача | Учётные системы, права доступа, журналы |
| Ошибки | Разбирает команда проекта | Нужны регламент, мониторинг и резервный сценарий |
| Безопасность | Часто отложена «на потом» | Согласование службы ИБ, требования регулятора |
| Результат | Доказана техническая возможность | Измеримый финансовый эффект |
Переход от одного к другому — самое узкое место рынка. Gartner прогнозировал, что к концу 2025 года не менее 30% проектов генеративного ИИ будут брошены после стадии проверки концепции. Причины: плохие данные, слабый контроль рисков, растущие затраты и неясная ценность для бизнеса (Gartner). Исследование MIT NANDA 2025 года ещё жёстче: из компаний, оценивавших корпоративные ИИ-системы, 20% дошли до пилота и лишь 5% — до промышленной эксплуатации (Virtualization Review).
Поэтому хороший пилот сразу проектируют как начало внедрения. Он идёт на реальных данных, с заранее согласованными критериями успеха и с участием службы безопасности. А его итог — не «всем понравилось», а решение: масштабируем, дорабатываем или останавливаем.
Как оценить экономический эффект
Эффект ИИ-проекта — это разница между стоимостью процесса «до» и «после» за вычетом полной стоимости владения решением. Звучит очевидно, но на практике обычно пропускают одну из трёх частей.
1. База. Сколько процесс стоит сейчас: время сотрудников, ошибки, задержки, упущенная выручка. Замерять нужно до старта — потом будет не с чем сравнить.
2. Эффект, который доходит до денег. Сэкономленные часы сами по себе не прибыль. Они становятся деньгами, только если компания берёт больше заказов тем же штатом, не нанимает новых людей или снижает потери. Если свободное время просто растворилось, эффект равен нулю.
3. Полная стоимость владения. Не только разработка, но и инфраструктура, лицензии или оплата запросов к модели, поддержка, мониторинг, дообучение, обучение сотрудников и время тех, кто проверяет результаты ИИ.
Разберём на условном примере. Компания проверяет 2000 договоров в год, на каждый юрист тратит 3 часа, час его работы стоит компании 1500 ₽. ИИ-помощник сокращает проверку до 1 часа.
| Статья | Расчёт | Сумма |
|---|---|---|
| Стоимость процесса сейчас | 2000 × 3 ч × 1500 ₽ | 9 млн ₽ в год |
| Экономия при полном использовании | 2000 × 2 ч × 1500 ₽ | 6 млн ₽ в год |
| Разработка и внедрение | разово | 4 млн ₽ |
| Эксплуатация: инфраструктура, поддержка, мониторинг | ежегодно | 1,5 млн ₽ в год |
На бумаге проект окупается меньше чем за год. Но всё зависит от того, сколько сотрудников реально начнут пользоваться инструментом:
Условный пример: разработка 4 млн ₽, поддержка 1,5 млн ₽ в год, экономия 6 или 3 млн ₽ в год
Если ИИ воспользуется только половина юристов, экономия упадёт вдвое, а расходы на поддержку останутся прежними — и срок окупаемости вырастет втрое. Поэтому доля активных пользователей — такая же ключевая метрика, как точность модели. И при оценке проекта стоит считать не один, а минимум два сценария: оптимистичный и реалистичный.
Запуск на живых данных — не финиш, а старт
Обычная программа работает одинаково, пока её не изменили. ИИ-решение деградирует само: меняются данные, клиенты, документы и правила, а модель продолжает отвечать так, как её научили.
Исследователи в Scientific Reports проверили 128 комбинаций моделей и наборов данных из четырёх отраслей — метеорологии, здравоохранения, авиаперевозок и финансов. Качество со временем снижалось в 91% случаев (Vela et al., 2022). Ещё в 2015 году инженеры Google предупреждали: содержание ML-систем в реальной эксплуатации обычно обходится намного дороже, чем кажется на старте (Sculley et al., NeurIPS 2015).
У решений на больших языковых моделях есть свои источники деградации:
база знаний устаревает — выходят новые регламенты и прайсы, а ИИ отвечает по старым;
поставщик обновляет модель — и выверенные инструкции начинают давать другой результат;
пользователи находят новые сценарии — и задают вопросы, которых не было на испытаниях;
меняются смежные системы — новая версия учётной системы меняет формат данных, и алгоритм тихо начинает ошибаться.
Хуже всего то, что такая деградация не вызывает ошибок в логах. Система работает, просто отвечает хуже. Поэтому в промышленной эксплуатации ИИ следят за тремя группами метрик:
Качество. Регулярная проверка на эталонном наборе примеров, выборочная оценка ответов экспертами, доля ответов, которые пользователи правят.
Использование. Доля активных пользователей и отказы от подсказок. Если люди перестали пользоваться ИИ, это часто первый сигнал падения качества.
Экономика. Стоимость одной операции и фактический эффект в сравнении с базой.
Из этого следует практический вывод для бюджета: деньги и люди на сопровождение закладываются сразу, а не ищутся после первой жалобы. У решения должен быть владелец, регламент обновлений и план отката на предыдущую версию.
Безопасность и процессы: то, что не видно на демо
На демонстрации ИИ отвечает на хорошо подобранные вопросы по чистым документам. В рабочей среде к нему добавляется всё то, что не видно на слайдах, но занимает большую часть проекта.
Права доступа. ИИ не должен показывать сотруднику те документы, к которым у него нет доступа в исходной системе. Для пилота этим часто пренебрегают, а в эксплуатации это прямой путь к утечке зарплат или коммерческой тайны.
Данные и регулятор. Если в процессе есть персональные данные или информация ограниченного доступа, служба безопасности должна участвовать с первого дня. Проект, который приходит на согласование уже после успешного пилота, рискует переделывать архитектуру целиком — например, переезжать из облака в закрытый контур.
Защита от манипуляций. Языковая модель выполняет инструкции из текста, который читает, — в том числе из письма или договора контрагента. Чем больше действий разрешено системе, тем важнее фильтрация входных данных, журналирование и подтверждение критичных шагов человеком.
Место в процессе. ИИ должен работать там, где сотрудник и так работает: в учётной системе, почте, CRM. Отдельное окно, куда нужно копировать данные вручную, быстро перестают открывать. Также нужно заранее решить, что делает сотрудник, когда ИИ ошибся или недоступен, и кто отвечает за результат.
Люди. Внедрение меняет привычную работу, и часть сотрудников будет сопротивляться. Обучение, понятные правила и честный разговор о том, как ИИ повлияет на их работу, напрямую влияют на долю активных пользователей — а значит, и на окупаемость.
Чек-лист для руководителя
Перед тем как утвердить бюджет ИИ-проекта, проверьте, что на каждый вопрос есть конкретный ответ:
☐ Сформулирована бизнес-задача, и посчитано, сколько она стоит сейчас
☐ Проверено, что её нельзя решить проще: правилом, отчётом, изменением регламента
☐ Есть владелец результата со стороны бизнеса
☐ Критерии успеха пилота зафиксированы до его начала, а не после
☐ Пилот идёт на реальных данных, а служба безопасности в курсе с первого дня
☐ Экономика посчитана с учётом полной стоимости владения и минимум в двух сценариях
☐ Понятно, куда пойдёт сэкономленное время сотрудников
☐ В бюджете есть строка на сопровождение, мониторинг и обновления
☐ Есть план на случай ошибки ИИ и возможность отката
Если больше трёх пунктов остаются пустыми, проект рано запускать. Это не отказ от ИИ, а способ не попасть в те 30% проектов, которые останавливаются после пилота.
Источники
Gartner — 30% of GenAI projects will be abandoned after proof of concept by end of 2025, 29.07.2024: https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025
Virtualization Review — MIT NANDA, The GenAI Divide, 19.08.2025: https://virtualizationreview.com/articles/2025/08/19/mit-report-finds-most-ai-business-investments-fail-reveals-genai-divide.aspx
Vela et al. — Temporal quality degradation in AI models, Scientific Reports, 2022: https://www.nature.com/articles/s41598-022-15245-z
Sculley et al. — Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015: https://proceedings.neurips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html