Оценка эффективности ИИ: как выбрать проект и не считать ROI по гипотезам

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

Компания ещё не знает, насколько пригодны её данные, какого качества удастся добиться, сколько исключений придётся обрабатывать вручную и как сотрудники будут пользоваться системой. Поэтому точную финансовую оценку полезнее заменить тремя отдельными вопросами: какую ценность получит бизнес, если решение заработает; насколько вероятен успех в конкретном процессе; сколько будет стоить не только разработка, но и эксплуатация. Такой подход соответствует логике expected ROI, или eROI.[1]

Пилот в этой схеме нужен не для эффектной демонстрации технологии, а для проверки предположения, в котором компания уверена меньше всего.

Почему точный ROI до пилота — это гипотеза

Классический ROI требует как минимум двух величин: ожидаемого эффекта и полной стоимости проекта. Обе до пилота известны лишь приблизительно.

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

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

часы сотрудников × ставка × предполагаемый процент автоматизации

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

Сначала нужно зафиксировать исходный процесс:

• кто выполняет работу сейчас;
• какое событие запускает процесс;
• какие данные получает сотрудник;
• какое решение он принимает и куда передаёт результат;
• сколько времени занимает операция;
• какие ошибки и повторные действия возникают;
• кто отвечает за итог.

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

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

Три критерия оценки ИИ-проекта

Исследование Foster Provost и Panos Ipeirotis предлагает оценивать ИИ-инициативы по трём отдельным компонентам: ценности в случае успеха, вероятности успеха и требуемым инвестициям.[1] Разделение важно: высокая потенциальная ценность не должна скрывать слабые данные, а дешёвый прототип — дорогую эксплуатацию.

1. Ценность в случае успеха

Сначала представьте, что система уже работает с приемлемым качеством. Что изменилось в бизнесе?

Ценность может проявляться по-разному:

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

Не каждый эффект сразу переводится в деньги. Для первичного сравнения достаточно оценок «низкая», «средняя» и «высокая». Мнимая точность здесь вреднее грубой, но честной оценки.

Ценность должна быть связана с действием. Формулировка «повысить эффективность отдела» ничего не даёт. Формулировка «сократить время от поступления заявки до назначения ответственного менеджера» уже позволяет определить базовую метрику.

Проверьте четыре аспекта:

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

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

2. Вероятность успеха

Высокая потенциальная ценность ещё не делает проект хорошим кандидатом на внедрение. Нужно понять, можно ли получить нужный результат в реальных условиях компании. Microsoft рекомендует сопоставлять сценарии с текущей зрелостью организации, доступностью данных, инфраструктурой и ресурсами, а затем проверять бизнес-ценность и техническую реализуемость в ограниченном PoC.[3] AWS отдельно выделяет бизнес-ценность, техническую реализуемость и готовность данных.[5]

Для оценки задайте четыре вопроса.

1. Процесс достаточно определён? Если два руководителя по-разному объясняют, что считать качественной заявкой, модель не решит разногласие. Сначала бизнесу придётся согласовать правило или допустимый диапазон оценок.
2. Есть пригодные данные? Для помощника по документам нужны актуальные документы, понятные версии и права доступа. Для анализа заявок — сохранённые данные о клиентах и результатах работы. Важен не только объём данных, но и их соответствие задаче.
3. Качество можно измерить? Для классификации обращений это может быть доля правильных маршрутов; для ответа по базе знаний — корректность, подтверждающий источник и доля передач специалисту; для извлечения документов — точность по обязательным полям.
4. Ошибку можно ограничить? ИИ может подготовить рекомендацию, заполнить черновик карточки или ответить на типовой вопрос, а рискованное действие оставить человеку.

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

3. Полная стоимость

Стоимость ИИ-проекта — это не только вызовы модели и часы разработчика. В оценку нужно включить:

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

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

Как выбрать проект и спроектировать пилот

Для первого отбора не нужна модель с десятками коэффициентов. Достаточно единой таблицы:

Кандидат	Оценка
Ответы по базе знаний	Ценность — высокая; вероятность успеха и стоимость — средние. Неопределённость: качество и актуальность документов.
Оценка входящих заявок	Ценность — высокая; вероятность успеха и стоимость — средние. Неопределённость: согласованность критериев оценки.
Автономное изменение заказов	Ценность и стоимость — высокие; вероятность успеха — низкая. Неопределённость: цена ошибки и контроль действий.

Это условный пример, а не готовая оценка для любой компании. Главный смысл таблицы — обсуждать свойства проекта отдельно.

Не стоит автоматически складывать оценки в один балл. Так критическое ограничение легко растворяется в среднем результате. Если у проекта нет владельца процесса или невозможно сформулировать метрику качества, это не «минус один балл», а условие, которое нужно устранить до запуска.

Рациональный кандидат для первого пилота сочетает:

• заметную пользу в случае успеха;
• ограниченный процесс;
• доступные данные;
• проверяемый результат;
• обратимое действие;
• приемлемую стоимость ошибки.

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

Метрики пилота лучше разделить на четыре уровня:

1. Изменение процесса: время операции, размер очереди, доля ручных действий, количество передач и повторных обработок.
2. Качество ИИ: правильность классификации, точность извлечения, корректность ответа, доля ответов с источником, отказов и передач человеку.
3. Экономика: стоимость одной операции, использование модели и инфраструктуры, время проверки, сопровождение и исправление ошибок.
4. Фактическое использование: сколько сотрудников применяют систему, как часто принимают результат, когда обходят решение и что всё равно делают вручную.

Одна техническая метрика не показывает эффективность внедрения. Модель может стать точнее, а процесс — медленнее из-за дополнительной проверки.

До пилота запишите, при каких результатах проект переходит в эксплуатацию, требует ещё одной итерации, возвращается на доработку данных или останавливается.

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

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

Когда ИИ пока не нужен

Не стоит начинать ИИ-проект, если:

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

В таких условиях сначала нужно исправить сам процесс. Это не отказ от ИИ, а отказ платить за технологию раньше, чем появилась задача, которую она действительно улучшит.

NIST рассматривает управление рисками как часть проектирования, разработки, использования и оценки ИИ-систем, а не как проверку после запуска.[4] Для рискованных действий заранее определите границы автономности, подтверждение человеком, журналирование и способ остановить систему.

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

Вывод и частые вопросы

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

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

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

Как рассчитать ROI от внедрения ИИ?

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

Что является измеримым эффектом внедрения ИИ?

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

С чего начать внедрение ИИ?

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

Как выбрать ИИ-проект для пилота?

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

Сколько стоит внедрение ИИ?

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

Источники

1. AI Strategy: How to Choose What AI Product to Implement — Foster Provost, Panos Ipeirotis, 26 июля 2026 года.
2. The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed — RAND Corporation, 13 августа 2024 года.
3. Plan for AI adoption — Microsoft Cloud Adoption Framework, обновлено 10 апреля 2026 года.
4. AI Risk Management Framework — NIST, проверено 29 июля 2026 года.
5. Prioritize AI integration based on business value, feasibility, and alignment — AWS Well-Architected Framework, проверено 29 июля 2026 года.