Внедрение ИИ в бизнес: с чего начать, если ещё не пробовали

Первый пилот с ИИ почти никогда проваливается из-за модели. Исследование MIT Project NANDA (август 2025 года, 300 разобранных внедрений в компаниях) показало, что 95% корпоративных пилотов с генеративным ИИ не дают измеримого эффекта на прибыль. Чаще всего процесс для первого захода выбирали без метрики, с которой можно было бы сравнить результат до и после.

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

Почему большинство пилотов проваливаются, ещё не начавшись?

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

Российский опрос компании «Интеллектуальная аналитика» (март 2026 года, около 50 крупных организаций) показывает похожую картину со своей спецификой. 90% проектов с ИИ не дошли до рабочих процессов, около 40% свернули ещё на этапе пилота. Часть причин совпадает с американской выборкой: процесс запускали ради самого факта запуска, под отчёт о цифровизации, без конкретной задачи за этим. Другая часть местная — точность языковых моделей на специфичном русскоязычном тексте оказалась ниже 30%, а обучение персонала и вопросы безопасности заняли больше времени, чем закладывали на старте.

С какого процесса начинать?

1. Есть метрика, которую и так уже считают. Время обработки заявки, число возвратов, конверсия в звонок — неважно какая именно, важно, что цифра существует ещё до пилота, до того как вообще встал вопрос об ИИ.
2. У процесса один владелец. Как только в пилот вовлечены два отдела или два ответственных за результат, единого критерия успеха у него не остаётся. Ровно это сочетание MIT чаще всего находит среди тех 95% пилотов, которые проваливаются.
3. Мало исключений. Рутинная задача с понятной структурой — хороший кандидат. Процесс с большим числом частных случаев, вроде сложной юридической экспертизы или нестандартной сделки, лучше отложить на вторую волну, когда в команде уже накопится опыт работы с инструментом.

Ничего в этом списке не требует творческого подхода к выбору, поэтому его и пропускают, торопясь сразу к инструменту.

Как это выглядит в разных видах бизнеса

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

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

Своими силами или с подрядчиком?

Тот же отчёт MIT сравнил внутренние разработки и партнёрства с внешними исполнителями. У внутренних команд, которые строят решение сами, до полного внедрения доходит 33% пилотов — против 66% у тех, кто привлёк внешнего подрядчика, и в среднем меньше 90 дней вместо девяти месяцев на разработку. Смешанные команды, где свои сотрудники работают вместе с внешней экспертизой, показывают ещё выше результат: 67% против 22% у команд, которые делают всё силами своего IT-отдела.

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

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

Сколько времени закладывать на первый результат

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

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

Что закрыть на бумаге до старта

Прежде чем выбирать инструмент, стоит закрепить на бумаге три вещи:

1. какая метрика подтвердит успех и какое у неё текущее значение до пилота;
2. кто один человек отвечает за пилот и вправе его остановить, если через месяц цифра не сдвинулась;
3. письменный порог успеха — конкретное число, при котором пилот считается сработавшим. Без этого порога результат легко трактовать как угодно: «стало лучше» не годится как критерий, если его нельзя проверить цифрой.

В практике консультантов по quick-win пилотам к этому добавляют короткие еженедельные сверки — зафиксировать, что застряло и что стоит изменить, — вместо одного большого разбора в конце срока.

Все три пункта звучат как формальность, но их отсутствие MIT называет главной причиной, по которой пилоты технически работают, а бизнес-результата не показывают. На практике без них через три месяца команда спорит, сработал пилот или нет, вместо того чтобы посмотреть на заранее согласованную цифру.

Частые вопросы

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

Сколько стоит первый пилотный проект с ИИ? Зависит от масштаба. По данным опроса «Интеллектуальная аналитика» (март 2026), у крупных российских компаний типовой бюджет пилота составляет 5-15 млн рублей. Для одного узкого процесса на готовых инструментах вход обычно на несколько порядков дешевле — это разные весовые категории пилота, сравнивать их напрямую бессмысленно.

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

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

Нужно ли обучать сотрудников перед стартом? Да, и это стоит закладывать в срок пилота отдельной строкой. По российскому опросу, обучение персонала и вопросы безопасности регулярно оказываются сложнее, чем ожидали на старте — и именно они чаще всего сдвигают сроки пилота.

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

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

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

Об авторе

Тимур Яковлев — экспертный редактор бизнес-сообщества по искусственному интеллекту. Внедряет нейросети в собственные процессы, от контента до продаж, и разбирает на своих цифрах, что из этого окупается.