Технологию внедряют, а процесс оставляют прежним

В 2025 году Массачусетский технологический институт (MIT) выпустил исследование, в котором говорилось, что 95 % корпоративных ИИ-пилотов не дают измеримого результата. На ваш взгляд, в чём здесь основная проблема: в низкой эффективности нейросетей или отсутствии правильной методики подсчёта прибыли от их внедрения в бизнес-процессы?

Обе версии частично верны, но корень проблемы лежит в третьем месте. Компании научились покупать и запускать ИИ, однако почти не научились одновременно перестраивать под него процессы. Технологию ставят рядом с существующим порядком работы и ждут, что цифры изменятся сами.

Показательно, что и авторы самого исследования The GenAI Divide выводят качество моделей из числа главных причин и объясняют провал «разрывом в обучении»: инструмент хорошо выглядит на демонстрации, но не накапливает обратную связь, не адаптируется к контексту и не встроен в реальный рабочий процесс. Универсальные чат-боты берут простые задачи и упираются в потолок ровно там, где нужны контекст компании и интеграции.

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

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

Российская картина устроена похоже. По данным «Якова и Партнёров» и «Яндекса», генеративный ИИ применяют более 70 % компаний, а все 150 крупнейших организаций из выборки провели хотя бы один пилот. При этом эффект выше 5 % EBITDA (прибыли до вычета процентов, налогов и амортизации) зафиксировали лишь 9 % компаний. Динамика всё же положительная: доля организаций без подтверждённого эффекта за два года снизилась с 32 % до 22 %.

Для расчёта окупаемости в бизнесе обычно используют показатель ROI: из дохода вычитают размер вложений, а затем результат делят на сумму инвестиций. Актуален ли такой подход для измерения эффективности внедрения ИИ? Возможны ли иные расчёты?

ROI (return on investment, возврат на вложенные средства) остаётся правильной рамкой — в конце концов, любой проект должен окупаться. Проблема в том, что в случае с ИИ обе части формулы считают небрежно.

В знаменателе почти всегда занижают вложения. В смету попадает лицензия или стоимость обращений к модели, а интеграция с внутренними системами, подготовка данных, переобучение сотрудников, мониторинг качества и поддержка остаются за скобками. По опыту, именно эта «невидимая» часть определяет итоговую стоимость владения.

В числителе чаще всего стоят сэкономленные часы. Здесь и кроется главная ловушка: частичная автоматизация сокращает время на отдельные операции, но сама по себе не уменьшает расходы на персонал. Час, сэкономленный у сотрудника, превращается в деньги только при одном условии — если этот час чем-то занят: выросла пропускная способность, снизился процент ошибок, обработали больше заявок теми же силами. Финансовые директора это давно поняли, и в 2026 году отчёт в духе «экономим четыре часа в неделю» на совете директоров уже не принимают. 

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

И отдельно — про сроки. Ожидания здесь традиционно завышены. Реалистичный горизонт выглядит так: первые 90 дней уходят на проверку гипотезы, через три-шесть месяцев появляются первые заметные результаты, через полгода-год — подтвержденный эффект в рамках одного процесса. Устойчивое влияние на прибыль формируется в течение одного-двух лет, а вклад портфеля проектов в EBITDA — за три-пять лет.

Какой подход к тестированию ИИ-гипотез вы считаете наиболее эффективным: A/B-тестирование, Shadow Mode (параллельный запуск с человеком) или бэктестирование на исторических данных? В каких случаях какой метод предпочтительнее?

Эти три метода отвечают на разные вопросы, поэтому спор «что лучше» я бы заменил на выстраивание их в последовательность.

Бэктест (проверка на исторических данных) — самый дешёвый фильтр. Он отсекает заведомо слабые гипотезы за считанные дни и не требует трогать боевые системы. Его слабость в том, что история не знает, как поведут себя люди и как изменятся данные: легко получить красивый результат за счёт того, что модель невольно «подсмотрела» ответ в данных, которых в реальный момент решения ещё не существовало.

Shadow Mode («теневой режим») — когда модель получает копию реального потока запросов и принимает решения параллельно с человеком, но её ответы никому не показывают и в дело не пускают. Это лучший инструмент там, где ошибка дорого стоит: кредитование, медицина и промышленность. Вы видите поведение системы на живых данных, ничем не рискуя. Ограничение тоже понятно: теневой режим показывает качество решений, но не показывает, как на них отреагируют клиенты и сотрудники.

A/B-тестирование (когда часть трафика идёт на новое решение, а часть остаётся на старом) — единственный способ увидеть причинно-следственный эффект на бизнес-метриках. Только оно честно отвечает на вопрос, выросла ли конверсия или выручка именно из-за ИИ. Взамен требуется достаточный объём трафика и готовность допустить часть пользователей до незрелого решения.

Рабочая схема для большинства компаний: отсеять гипотезы бэктестом, обкатать выжившие в теневом режиме, а победителя вывести на A/B и уже по нему принимать решение о масштабировании. В процессах, где ошибка недопустима, последний шаг заменяют постепенным раскатыванием на узкой группе под усиленным контролем.

Как выбрать первый пилотный процесс для внедрения ИИ? Что нужно учесть, чтобы не потерять деньги?

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

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

Три вещи нужно сделать до запуска, и именно на них чаще всего экономят. Первое — зафиксировать исходную метрику и контрольную группу: без замера «как было» доказать эффект потом невозможно. Второе — назначить владельца со стороны бизнеса; у процесса должен быть человек, отвечающий за результат в деньгах, и одного ИТ-куратора здесь мало. Третье — заранее назвать источник финансового эффекта: за счёт чего именно появится экономия или выручка.

И главное условие, которое отличает удачные проекты от неудачных: вместе с процессом надо менять показатели эффективности сотрудников. Если человек по-прежнему премируется за то же, что и раньше, он будет перепроверять машину вручную, дублировать работу и добросовестно съедать весь выигрыш. Поэтому внедрение начинается с решения, как изменится сама работа, и только потом доходит до покупки лицензии.

Допустим, гипотеза подтвердилась на пилотном этапе. Но при масштабировании эффект исчезает и данные по окупаемости резко меняются. В чём чаще всего кроется причина?

Такой разрыв встречается настолько часто, что его уже описывают отдельным термином — «каскад затухания». Причин обычно несколько, и они накладываются друг на друга.

Первая — условия пилота были тепличными. Его вели на чистом, заранее подготовленном срезе данных, с участием мотивированных сотрудников и на узком наборе типовых случаев. В реальной эксплуатации приходят унаследованные системы, неполные справочники, редкие исключения — и качество проседает. Данную причину можно нивелировать изначальной подготовкой данных для «честных» экспериментов.

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

Третья, и по моему опыту самая частая, — организационная. Ускорили один этап, а согласования, тестирование и смежные звенья остались прежними: узкое место просто переехало дальше по цепочке, а сквозной срок не изменился. Тут поможет справиться только эволюция бизнес-процессов вместе с внедрением ИИ.

Однако, есть еще один момент, который частично опровергает предыдущие и это очень явно заметно в разработке ПО. Дав разработчикам ИИ-инструменты для генерации кода и увеличив их производительность в несколько раз, компании начинают нагружать этих разработчиков пропорционально, а иногда и непропорционально бОльшим объемом задач. Таким образом компания действительно становится эффективнее и быстрее. При этом метрика «разработчики должны меньше работать вместе с ИИ» не выполняется. Поэтому необходимо правильно выбирать конечный показатель эффективности ИИ, например, время до публикации новой функциональности или объем выполненных задач. 

Отсюда практический вывод: вместе с моделью нужно масштабировать и договорённости вокруг неё. Иначе проект попадает в статистику Gartner, где более 40 % агентских инициатив закрывают к 2027 году из-за расходов и неочевидной ценности.