Почему 95% ИИ-пилотов не доходят до отчётности

Организации массово внедряют ИИ, но эффект в P&L видят единицы. Причина не в качестве моделей, а в отсутствии владельца процесса и критериев успеха, зафиксированных до старта.

Что произошло

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

Ответ оказался неудобным. 95% организаций не находят эффекта от ИИ в P&L, а 49% компаний, запускавших ИИ-агентов, откатывали их назад именно из-за экономики — не потому, что агент ошибался, а потому, что стоимость его работы не сходилась с ценностью результата. До измеримой ценности доходят 5% пилотов. Остальные заканчиваются презентацией, в которой есть точность модели, скорость ответа и положительная обратная связь пользователей, но нет строки в бюджете, которая изменилась.

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

Анатомия проблемы

Пилот стартует без владельца денег

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

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

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

Критерии успеха формулируются после старта

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

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

Критерий успеха, сформулированный после пилота, — это не критерий, а интерпретация результата.

Метрика модели подменяет метрику процесса

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

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

Эффект растворяется на границах подразделений

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

Стоимость эксплуатации не входит в расчёт

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

Расчёт экономики пилота, который не включает стоимость эксплуатации за год, не является расчётом. Он показывает стоимость демонстрации.

Признак	Демонстрация	Пилот
Кто отвечает за результат	ИТ или команда цифровизации	Руководитель операционного подразделения
Что измеряется	Метрики модели	Показатель процесса и его отражение в бюджете
Когда определён критерий успеха	По итогам	До старта, числом и сроком
На каких данных	Подготовленная выборка	Реальный поток в ограниченном масштабе
Что посчитано	Стоимость разработки	Стоимость эксплуатации за год в целевой архитектуре
Что происходит по завершении	Презентация	Решение по заранее согласованному правилу

Как это выглядит на практике

Банк из первой сотни, ассистент оператора контакт-центра. Модель подсказывала оператору ответ на основе базы знаний. Точность подсказок на тестовой выборке была высокой, операторы в опросе отмечали удобство. Через квартал после пилота среднее время обработки обращения не изменилось. Причина: регламент требовал от оператора самостоятельной проверки каждой подсказки, поскольку ответственность за ответ клиенту оставалась на нём. Ассистент добавил шаг, а не убрал. Владелец регламента в пилоте не участвовал; изменение регламента не входило в план.

Производственная компания, прогноз отказов оборудования. Модель предсказывала вероятность отказа узлов по данным телеметрии за несколько дней до события. Инженеры подтверждали, что предсказания в целом верны. Простои не сократились. Причина: не существовало регламента, по которому предупреждение модели превращалось в заявку на ремонт вне планового графика, а запасных частей под внеплановые замены на складе не было. Модель работала; процесс вокруг неё не изменился, потому что за процесс в пилоте никто не отвечал.

Розничная сеть, агент для подготовки заказов поставщикам. Агент собирал данные из нескольких систем и формировал проект заказа. Пилот на облачной модели показал, что качество проектов сопоставимо с работой категорийного менеджера. При расчёте перехода в промышленный режим выяснилось, что стоимость обработки одного заказа — с учётом количества обращений агента к модели и требований безопасности к размещению данных — сопоставима с трудозатратами менеджера. Проект остановили. Это правильное решение, принятое на полгода позже, чем следовало.

Во всех трёх случаях техническая часть была сделана. Не было сделано другое: не определён владелец, не зафиксирована базовая линия, не посчитана эксплуатация.

Что это значит для российской компании

Закрытый контур меняет экономику. Пилот, сделанный на внешнем облачном API, не переносится в контур один к одному. Для финансовых организаций, госсектора, медицины и ТЭК размещение данных клиентов за пределами контура недопустимо по требованиям регуляторов и 152-ФЗ, а значит, промышленная версия потребует собственной инфраструктуры инференса. Это другой порядок затрат, и если экономика пилота считалась на облачных ценах, она заведомо неверна.

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

Отечественный стек снимает вопрос доступности, но не вопрос экономики. Открытые модели, разворачиваемые в контуре, и российские LLM закрывают потребность в технологии. Но они не снимают необходимость считать стоимость эксплуатации, и в закрытом контуре эта стоимость ложится на компанию полностью: железо, люди, обновление моделей, мониторинг.

Регуляторная нагрузка растёт. Требования к обработке персональных данных и к объяснимости решений в регулируемых отраслях означают, что промышленная система должна иметь журналирование, контроль доступа и процедуры разбора инцидентов. Это часть стоимости и часть ответственности владельца.

Что делать: пошагово

Назначьте владельца до выбора технологии. Это руководитель операционного подразделения, в бюджете которого должен появиться эффект. Он подписывает целевое значение показателя и получает полномочия менять регламент. Если такого руководителя найти не удаётся — проект не готов к старту, независимо от зрелости технологии.
Зафиксируйте базовую линию. Измерьте показатель, который собираетесь улучшать, в текущем состоянии: не по ощущениям, а по данным за представительный период. Если показатель не измеряется, первым проектом становится измерение, а не ИИ.
Сформулируйте критерий успеха числом и сроком. «Снизить стоимость обработки заявки на заданную долю за квартал при сохранении качества по контрольной метрике». Включите в критерий не только целевой показатель, но и ограничения: что не должно ухудшиться.
Посчитайте эксплуатацию за год до старта пилота. Инфраструктура в целевой архитектуре, интеграция, поддержка, обновление моделей, мониторинг, люди. Сравните с ожидаемым эффектом. Если результат отрицательный или на грани — остановитесь на этом этапе. Это дешевле, чем остановиться после пилота.
Опишите цепочку от результата модели до денег. Кто принимает результат, какое решение меняется, какой регламент нужно переписать, какие интеграции нужны. Каждое звено — задача с ответственным и сроком. Пилот проверяет цепочку целиком, а не только модель.
Проведите пилот на реальном потоке, а не на выборке. Ограничьте не данные, а масштаб: одно подразделение, одна линия, один регион. Измеряйте показатель процесса, а не только метрики модели.
Примите решение по заранее согласованному правилу. До старта договоритесь: при каком результате масштабируем, при каком дорабатываем, при каком закрываем. Решение о закрытии — нормальный исход: отказ от проекта, который не окупается, экономит бюджет.

Типичные ошибки

Спонсор вместо владельца. Генеральный директор поддерживает проект, но не отвечает за конкретную строку. Почему это проблема: поддержка сверху не заменяет полномочий менять регламент на уровне подразделения. Что вместо: спонсор назначает владельца и делегирует ему полномочия и ответственность за результат.

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

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

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

Отсутствие правила закрытия. Никто не договорился, при каком результате проект останавливается. Почему это проблема: проект продолжается по инерции, потому что закрыть — значит признать ошибку. Что вместо: правило принятия решения фиксируется до старта; закрытие по правилу — не ошибка, а результат.

Как понять, что вы на верном пути

У проекта есть владелец, который может назвать строку бюджета, где появится эффект, и число, которого он ожидает.
Базовая линия измерена по данным, а не по экспертной оценке, и владелец с ней согласен.
Критерий успеха записан числом, сроком и ограничениями и подписан до старта.
Стоимость эксплуатации за год посчитана в целевой архитектуре и сопоставлена с эффектом.
Цепочка от результата модели до операционного показателя описана по звеньям, у каждого звена есть ответственный.
Регламенты, которые нужно изменить, перечислены, и владелец имеет полномочия их менять.
Правило принятия решения по итогам пилота согласовано: масштабировать, дорабатывать, закрыть.
Финансовый директор видел расчёт и согласен с методикой измерения эффекта.

Вопросы, которые нам задают

Если владельца найти не удаётся — пилот всё равно имеет смысл как обучение команды?

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

Мы считали экономику, но эффект оказался меньше ожидаемого. Проект провалился?

Нет, если правило принятия решения было согласовано заранее. Эффект меньше ожидаемого — это данные. Дальше возможны три варианта: доработать цепочку (часто узкое место обнаруживается не в модели), пересчитать масштаб (эффект может быть достаточным при развёртывании на большем объёме) или закрыть. Провал — это когда решение не принимается, а проект живёт по инерции.

Как убедить операционного директора взять на себя ответственность за результат?

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

Сколько времени должно пройти от завершения пилота до отражения в отчётности?

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