Проблемы внедрения ИИ: почему пилоты не доходят до продуктива
Пилоты чаще всего останавливает не качество модели, а постановка: нет владельца результата на стороне бизнеса, метрику придумали после запуска, данные не приведены в порядок, а сама система живёт в отдельном окне рядом с рабочими. Ниже — восемь повторяющихся причин провала, как каждая выглядит на практике и что делать, чтобы её не было.
Проблемы внедрения ИИ начинаются до выбора модели
Публичные исследования последних лет сходятся в одном: заметная часть корпоративных ИИ-пилотов не доходит до влияния на финансовый результат. Конкретные доли в разных отчётах отличаются и зависят от того, что именно считали провалом, поэтому опираться стоит не на процент, а на причины — они повторяются от проекта к проекту.
Показательно, что почти все они лежат вне модели. Качество открытых моделей за последние два года выросло настолько, что для типовых корпоративных задач — разбор обращений, поиск по документам, подготовка типовых текстов, классификация — оно перестало быть узким местом. Узким местом стали постановка задачи, данные и эксплуатация.
Дальше — восемь причин, которые мы встречаем чаще всего, с описанием того, как каждая выглядит изнутри проекта и чем лечится. Порядок примерно соответствует частоте. Сроки и порядок работ, при которых эти причины отсекаются заранее, разобраны в статье про этапы внедрения.
Нет владельца результата и метрику придумали задним числом
Причина 1. Владельца нет. Проект ведёт ИТ или внешний подрядчик, а со стороны бизнеса участвует «подразделение». Выглядит это так: вопросы по процессу задавать некому, ответы приходят через неделю, приёмку никто не назначает, а на финальной встрече выясняется, что нужное было другим. Лечится назначением человека с именем, фамилией и личным интересом в цифре — руководителя того подразделения, где меняется работа. Полномочий должно хватать, чтобы менять регламент, а не только высказывать мнение.
Причина 2. Метрика появилась после запуска. Систему собрали, показали, и только потом начали думать, чем измерять успех. В этот момент любая цифра оказывается спорной: замера «до» нет, сравнивать не с чем, и разговор сводится к впечатлениям. Отдельный подвид — метрика, которую нельзя снять из системы и приходится считать руками или опросом.
Лечение простое и неудобное: метрика выбирается до начала работ, ровно одна, и замер «до» снимается из вашей системы и фиксируется письменно обеими сторонами. Пять минут работы в начале снимают месяц спора в конце. Если метрику нельзя посчитать, сценарий в пилот не идёт — это жёсткое правило, и оно экономит деньги обеим сторонам.
Данные не готовы, а модель выбрали до постановки задачи
Причина 3. Данные в беспорядке. Регламенты лежат в трёх хранилищах, действующая версия неотличима от прошлогодней, половина инструкций противоречит другой половине. Модель честно отвечает по тому, что нашла, — и отвечает неправильно, а виноватой считают модель. На практике подготовка данных занимает 1–3 недели на каждый новый домен, и этот срок нужно закладывать, а не надеяться проскочить.
Лечится это разбором ограниченного куска: только те документы, которые нужны первому сценарию. Носитель знаний на вашей стороне решает, какая версия действует, что отменено и что противоречит. Побочный эффект приятный — часть найденных проблем чинится переписанным регламентом за неделю и даёт эффект без всякой автоматизации.
Причина 4. Модель выбрали первой. Сначала покупается платформа или объявляется, что «работаем на такой-то модели», потом под неё ищут задачу. Дальше выясняется, что для документов нужен длинный контекст, для телефонии — потоковое распознавание русской речи, а для агентных сценариев — устойчивый вызов инструментов, и одна модель всё это одинаково хорошо не делает.
Правильный порядок обратный: задача, объём, требования к данным — затем стек. Для текста и агентов это обычно Qwen, DeepSeek, GLM или Kimi, для русской речи GigaAM и T-one, для поиска multilingual-e5 или BGE-M3. Комбинация подбирается под сценарий, каталог собран на странице открытых моделей.
Пилот живёт в отдельном окне, а обновления ломают работающее
Причина 5. Система стоит рядом с рабочими инструментами. Менеджеру, чтобы воспользоваться ИИ, нужно открыть отдельную вкладку, скопировать туда данные из CRM и вернуть результат обратно. Первые две недели он это делает из любопытства, на третьей перестаёт. Метрика показывает, что пользуются мало, и делается вывод, что инструмент не нужен.
Лечится встраиванием в то окно, где человек уже работает: карточка сделки в Битрикс24, документ в 1С, почтовый ящик, телефония. Работа не должна требовать нового действия — подсказка, черновик или заполненное поле появляются там, где сотрудник и так находится. Это дороже на этапе интеграции и дешевле на дистанции.
Причина 6. Обновления ломают то, что работало. Через месяц после запуска меняется версия модели или правила, и сценарий, который держал качество, начинает ошибаться. Виноватых не находят, доверие к системе падает быстрее, чем восстанавливается.
У нас на это выстроен процесс: мастер-система развивается ежедневно, раз в неделю выходит release candidate с полным changelog, каждый релиз версионирован и криптографически подписан, откат делается одним действием. Ни одно обновление не уходит в продуктив без ручной проверки человеком и без гейта на стороне заказчика. Плюс резервирование провайдера: при сбое основного система переключается сама.
Нет плана эксплуатации, а ожидания завышены маркетингом
Причина 7. О жизни после запуска не подумали. Пилот сработал, эффект показали, акт подписали — и на этом всё. Через полгода база знаний устарела, регламенты изменились, никто не следит за качеством ответов, сценарий оброс исключениями, и люди тихо вернулись к ручной работе. Формально проект успешный, фактически его больше нет.
План эксплуатации пишется до запуска и состоит из скучных вещей: кто администратор системы, как часто обновляется база знаний, кто смотрит дашборд качества, что делать при сбое, как заводятся новые правила, с какой периодичностью факт сверяется с ROI-моделью. Роль администратора обучается на вашей стороне в ходе внедрения — это обязательная часть, а не опция.
Причина 8. Ожидания собраны из презентаций вендоров. От системы ждут, что она заменит отдел целиком, будет права в ста процентах случаев и заработает через неделю после установки. Реальность другая: часть операций уходит машине полностью, часть выполняется с подтверждением человека, часть остаётся людям — и это нормальная конструкция, а не недоработка.
Лечится это на диагностике, до денег: карта процесса раскладывается на три группы операций, ROI считается на вашем объёме и ваших ставках, и видно, какая доля реально автоматизируется. Что при этом получается в цифрах, показано в кейсах — метрики там считал сам заказчик, до и после.
Симптом, корневая причина и что делать
Таблица для быстрой самодиагностики: слева то, что видно снаружи, справа — куда смотреть. В половине случаев симптом, который выглядит техническим, оказывается организационным.
| Симптом | Корневая причина | Что делать |
|---|---|---|
| Пилот идёт третий месяц без результата | Нет владельца результата и права принимать решения | Назначить руководителя подразделения владельцем, дать полномочия менять регламент |
| Спорим, дал ли пилот эффект | Метрика выбрана после запуска, замера «до» нет | Зафиксировать одну метрику и снять замер из системы до перезапуска |
| Модель отвечает неверно по внутренним документам | Устаревшие и противоречивые версии в базе знаний | Разобрать документы одного процесса, отметить действующие, собрать проверочные примеры |
| Сотрудники не пользуются системой | Работа требует отдельного окна и лишних действий | Встроить в Битрикс24, 1С или почту, убрать копирование данных руками |
| Качество упало после обновления | Нет версионирования и приёмки релизов заказчиком | Ввести гейт на своей стороне, changelog и откат к предыдущей версии |
| Через полгода всё вернулось к ручной работе | Нет плана эксплуатации и администратора внутри | Назначить и обучить администратора, поставить дашборд качества и регулярную сверку |
| Сумма в смете выросла вдвое против ожиданий | Требования ИБ и интеграции всплыли после старта | Собирать ограничения по данным и доступность API на диагностике |
| Результат есть, но в отчётности не виден | Эффект не переведён в деньги и не сверялся с моделью | Пересчитать экономику по факту и сверять её с ROI-моделью ежемесячно |
Вызовы внедрения ИИ, которые нельзя убрать полностью
Часть трудностей не устраняется правильной постановкой — с ними живут. Первая: доля неопределённости в начале. Заранее неизвестно, какого качества удастся достичь на ваших данных, и честный ответ на вопрос «сработает ли» звучит как «проверим за 2–4 недели на одном процессе». Отсюда формат короткого платного пилота, а не сразу договор на внедрение.
Вторая — сопротивление команды. Люди справедливо считывают автоматизацию как угрозу, и переубеждать презентациями бесполезно. Работает только участие: те же сотрудники прогоняют задачи через систему на пилоте, отмечают ошибки, видят, что уходят рутинные операции, а решения остаются за ними.
Третья — сроки, которые не зависят от техники. Согласование службы безопасности, тендер на GPU-сервер, отпуск единственного носителя знаний. Эти недели не сокращаются деньгами и должны стоять в плане с самого начала, иначе график поедет весь.
Четвёртая — ограничения самих моделей. Они ошибаются, и на некоторых задачах ошибаются уверенно. Поэтому необратимые действия подтверждает человек, а сценарии с высокой ценой ошибки строятся как подготовка решения, а не как его принятие. Отдельный разбор рисков и способов их закрывать собран в статье про риски внедрения ИИ.
Как выглядит успешное внедрение ИИ
Обратная сторона того же списка: проверьте свой проект по этим пунктам до старта, а не после. Отсутствие любого из них — не приговор, но повод остановиться и достроить.
- У сценария есть владелец с именем и полномочиями менять регламент, а не только согласовывать документы.
- Метрика одна, снимается из системы, замер «до» зафиксирован письменно обеими сторонами до начала работ.
- Данные первого сценария разобраны: действующие версии отмечены, противоречия сняты, есть 10–20 проверочных примеров.
- Модель выбрана после задачи, стек собран из открытых весов и разворачивается на вашем железе.
- Система работает в том окне, где люди уже сидят: CRM, 1С, почта, телефония — без копирования данных руками.
- Релизы версионированы, проходят ручную проверку и приёмку на вашей стороне, откат делается одним действием.
- План эксплуатации написан: администратор, дашборд качества, обновление базы знаний, сверка факта с ROI-моделью.
- Ожидания разложены по трём группам операций: машина сама, машина с подтверждением человека, только люди.
Частые вопросы про проблемы внедрения ИИ
Какая причина провала ИИ-пилотов встречается чаще всего?
Отсутствие владельца результата на стороне бизнеса. Все остальные проблемы производны от неё: если некому отвечать за цифру, метрику никто не назначает вовремя, данные никто не разбирает, приёмку никто не проводит, а после запуска за качеством никто не следит. Владелец — это руководитель подразделения, где меняется работа, с полномочиями править регламент и с личной заинтересованностью в результате. ИТ-директор на этой роли работает хуже: он отвечает за инфраструктуру, а не за то, быстрее ли стали обрабатываться заявки в его компании.
Правда ли, что большинство корпоративных ИИ-проектов не окупается?
Публичные отчёты последних лет действительно показывают, что заметная часть пилотов не доходит до влияния на финансовый результат, но цифры в них расходятся, потому что по-разному определяют и провал, и окупаемость. Осторожная формулировка такая: доля неудач высокая, и она объясняется не технологией, а способом запуска. Проекты, где заранее назначен владелец, выбрана одна измеримая метрика и снят замер «до», ведут себя принципиально иначе — там хотя бы понятно, что именно не сработало, и решение о продолжении принимается по цифрам.
Как понять, что пилот пора остановить?
По заранее записанному критерию неудачи, а не по ощущениям. Он формулируется вместе с метрикой до старта: например, если к концу четвёртой недели время обработки не сократилось хотя бы на четверть на реальном потоке, сценарий закрываем. Без такого правила пилот превращается в бесконечный: каждую неделю появляется объяснение, почему нужна ещё одна итерация. Остановка при этом не равна потере: формализованный процесс, приведённые данные и снятые замеры остаются у компании и пригодятся следующему сценарию или другому подрядчику.
Что делать, если сотрудники саботируют внедрение?
Считать это штатной частью проекта, а не неожиданностью. Сопротивление почти всегда рациональное: человеку меняют способ работы и не объясняют, что будет с его ролью. Работают три вещи. Первая — участие тех же сотрудников в пилоте, где они отмечают ошибки системы и видят, что их мнение влияет на настройки. Вторая — прямой разговор о том, какие именно операции уходят машине и какие решения остаются за людьми. Третья — снятие рутины первым: если система начинает с самой нелюбимой части работы, отношение меняется быстрее любых объяснений.
Можно ли спасти проект, который уже буксует?
Чаще всего да, и обычно без переделки технической части. Порядок такой: остановиться, назначить владельца результата, выбрать одну метрику, снять честный замер «до» на текущем состоянии и переопределить объём до одного процесса вместо пяти. Дальше две-три недели на разбор данных этого процесса и повторный запуск с приёмкой по цифре. В нашей практике половина буксующих проектов упирается в организационные вещи — доступы, владельца, размытый объём, — а не в качество ответов. Оставшимся честнее закрыть текущий сценарий и выбрать другой.
Как отличить подрядчика, который сделает работающее внедрение?
По вопросам, которые он задаёт до коммерческого предложения. Если разговор начинается с процесса, объёмов, стоимости часа сотрудников и того, откуда брать замер «до», — это инженерный подход. Если начинается с презентации платформы и списка возможностей модели, результат будет измеряться количеством функций. Второй маркер — готовность назвать критерий неудачи и условия остановки. Третий — что написано в договоре про принадлежность кода и данных и про условия выхода: работающая система должна оставаться у вас и продолжать работать без подрядчика.
Бесплатный аудит: посчитаем эффект внедрения ИИ на ваших цифрах
30–40 минут разбора: смотрим ваши процессы, отмечаем, что можно передать ИИ, считаем ROI-модель на ваших объёмах и сроках. Вы уходите с расчётом и картой внедрения — даже если работать дальше не будете.