ИИ в бизнес-приложениях: метрики реального эффекта

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

Исследование поддержки, опубликованное Национальным бюро экономических исследований США (NBER), показало, что доступ к генеративному ИИ-ассистенту был связан с ростом числа решённых обращений на час в среднем на 14%. Это значимый результат для конкретного сценария, в котором ассистент подсказывал специалистам ответы клиентам. Но переносить его на любое бизнес-приложение нельзя. Эффективность ИИ в бизнес-приложениях зависит от задачи, пользователей, качества данных и того, как локальное улучшение встроено в рабочий процесс.

Сначала измеряют сценарий, затем бизнес-результат

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

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

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

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

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

Что именно показало исследование поддержки NBER

В исследовании участвовали 5 179 специалистов поддержки. Им предоставили генеративный ИИ-ассистент, который в реальном времени предлагал подсказки по ответам клиентам. В среднем число решённых обращений на час выросло на 14%. Наибольший эффект наблюдался у менее опытных и менее квалифицированных сотрудников; у опытных и высококвалифицированных специалистов он был минимальным.

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

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

Результат NBER показывает, где искать эффект: в конкретном процессе и у конкретных групп пользователей. Само число 14% не является прогнозом для нового внедрения.

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

Локальная экономия ещё не означает рост EBIT

Разрыв между удачным сценарием и эффектом на всю организацию виден и в опросных данных McKinsey за 2025 год. 88% респондентов сообщили, что их организации регулярно используют ИИ хотя бы в одной бизнес-функции. Около трети сказали, что начали масштабировать ИИ-программы на уровне предприятия. При этом о каком-либо влиянии ИИ на EBIT компании сообщили 39% участников опроса. Среди этой группы большинство оценило связанную с ИИ долю EBIT менее чем в 5%.

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

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

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

Опрос McKinsey также показывает, что 80% респондентов называют повышение эффективности целью ИИ-инициатив. Компании, получающие наибольшую ценность, часто ставят дополнительно цели роста или инноваций. Для руководителя продукта это означает, что оценка не должна ограничиваться сокращением времени на операцию: сценарий может быть ценен, если он открывает новый способ обслуживания или позволяет работать с задачами, которые прежде было слишком дорого обрабатывать вручную.

Как считать окупаемость генеративного ИИ

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

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

В расчёт стоит включить три группы величин:

1. Текущие расходы процесса. Сколько ресурсов уходит на выполнение задачи до появления ИИ, включая время сотрудников и последующую проверку результата.

2. Расходы на ИИ-функцию. Разработка, подключение модели, эксплуатация, мониторинг, обновления и поддержка связанной инфраструктуры.

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

Здесь особенно важна атрибуция, то есть правило, по которому эффект относят именно к ИИ. Если в тот же период компания меняет интерфейс, процесс обучения сотрудников или правила маршрутизации обращений, рост производительности нельзя автоматически считать результатом одной модели. Хороший анализ фиксирует сопутствующие изменения и, где возможно, использует контрольное сравнение.

Для мобильного бизнеса добавляется контекст использования. Функцию могут включить многие пользователи, но регулярно применять её лишь небольшая часть; другой вариант — частота использования высокая, однако каждый запрос оказывается дорогим или требует ручной доработки. Поэтому число активаций само по себе не подтверждает окупаемость. Его рассматривают вместе с завершением целевого сценария, возвратами к функции, ошибками и ресурсными затратами на один полезный результат.

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

После запуска: качество модели и контур управления риском

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

Национальный институт стандартов и технологий США (NIST) в AI RMF 1.0 описывает управление рисками ИИ через четыре функции: Govern, Map, Measure и Manage. Рамка добровольная и рассчитана на применение на протяжении жизненного цикла системы. Её полезно читать как последовательность управленческих вопросов: кто отвечает за систему, где и на кого она влияет, как измеряется её поведение и какие действия предпринимаются при обнаружении риска.

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

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

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

Практический прогноз

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

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

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