5 ошибок при запуске пилота с ИИ в компании

2026-09-02 · Слаживание

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

Я бы свёл весь материал к одной мысли: пилот проваливается не из-за модели, а из-за плохой подготовки. До старта нужно решить _пять_ вещей: какой кейс брать, что считать успехом, куда встраивать ИИ, как закрыть 152-ФЗ и доступы, кто отвечает за итог. Иначе компания тратит бюджет, а эффект в ₽ так и не появляется.

Вот суть статьи в одном списке:

• Ошибка 1: берут удобный кейс вместо болезненного и измеримого
• Ошибка 2: запускают пилот без KPI, ROI и порога для решения
• Ошибка 3: откладывают интеграцию с CRM, 1С, почтой и телефонией
• Ошибка 4: оставляют вопросы 152-ФЗ, on-prem, логов и ролей на потом
• Ошибка 5: идут в пилот без владельца процесса и плана внедрения

Что я бы проверил _до_ запуска:

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

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

Most AI Pilots Fail Because Of This Reason

Что должен дать хороший ИИ-пилот

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

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

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

1. Неправильный выбор кейса для пилота

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

Бизнес-эффект и базовая метрика

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

Например, можно смотреть на такие метрики:

• время выхода нового сотрудника на продуктивность
• частоту потери данных при передаче задач между отделами
• стоимость одной обработки обращения в колл-центре, бухгалтерии или первичной техподдержке [2][5]

Если исходной метрики нет, сравнивать пилот попросту не с чем. А значит, доказать эффект не получится.

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

Готовность данных

Если нужные данные недоступны, кейс для пилота не годится. Тут всё без лишней философии: нет данных - нет пилота.

Возможность масштабировать результат и принятие командой

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

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

Ниже - быстрый ориентир, который помогает отсеять слабые варианты.

Даже если кейс выбран правильно, этого мало: без KPI, логики ROI и понятного порога для решения пилот всё равно может провалиться.

2. Запуск без KPI, логики ROI и порогов для решения

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

Бизнес-эффект и базовая метрика

Что именно должно измениться и на сколько? Если на старте нет чёткого ответа, пилот легко превращается в эксперимент ради эксперимента.

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

Масштабируемость и принятие командой

Кроме операционных метрик, важно заранее договориться о пороге для решения. Иначе говоря: при каком результате пилот идёт в масштабирование, а при каком его останавливают. Если интеграция съедает почти весь бюджет пилота, ROI стоит пересчитать ещё до запуска [1].

Пилот смотрят не только по техэффекту. Не меньше значит и то, сколько сотрудников продолжают работать с инструментом после первых недель [4]. Здесь проверяют не только саму технологию, но и то, приняла ли её команда.

Ниже - базовый набор KPI, на который обычно смотрят, когда решают: масштабировать пилот или остановить.

Без таких договорённостей пилот часто заканчивается просто отчётом, а не управленческим решением.

3. Интеграция с CRM, 1С, почтой и телефонией «на потом»

Даже если кейс выбран верно, а KPI заданы чётко, пилот может не взлететь по простой причине: он не встроен в рабочие системы. Команда вроде бы всё сделала правильно, но решила отложить интеграцию с CRM, 1С, почтой и телефонией ради быстрого старта. На практике это почти всегда бьёт по результату.

Проблема в том, что ИИ начинает жить отдельно от бизнеса. Он не видит переписку, не знает историю клиента, не связан с задачами и звонками. То есть работает _в вакууме_. А значит, остаётся ещё одним интерфейсом, а не частью процесса.

Бизнес-эффект и базовая метрика

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

Поэтому ещё до запуска стоит замерить долю задач, где есть:

• решение
• ответственный
• следующий шаг

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

Готовность данных и интеграций

В корпоративных системах основная стоимость нередко связана не с самой функцией, а с совместимостью, миграцией данных и доработкой архитектуры [1]. Это не самый заметный участок проекта, но именно он часто съедает время, деньги и нервы.

Если отложить интеграцию, техдолг начинает копиться почти сразу. А сотрудники, как это обычно бывает, находят обходные пути: копируют данные руками, дублируют задачи в почте, пересылают контекст в мессенджерах. Формально пилот запущен, но по факту команда продолжает работать по-старому [1].

Масштабируемость и принятие командой

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

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

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

4. Безопасность данных, on-prem и 152-ФЗ - «разберёмся потом»

Даже если интеграция уже готова, пилот могут не пустить в работу по простой причине: данные нельзя хранить и обрабатывать в нужном контуре. Если до старта не закрыть вопросы по хранению, доступу и соответствию 152-ФЗ, проект встанет. Причём не в начале, а позже - когда в него уже вложили время и деньги.

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

Что проверить до запуска

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

До запуска стоит проверить четыре вещи: где хранятся данные, как выданы доступы, есть ли аудит и как устроено обезличивание.

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

Масштабируемость и принятие командой

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

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

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

5. Пилот без владельца процесса и плана внедрения

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

Масштабируемость и принятие командой

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

Это особенно заметно там, где пилот всё-таки доводят до постоянного режима. Опыт ПАО «ОДК-Сатурн» показывает: при понятном контуре внедрения более 50% участников программы переходят в постоянный штат [4].

Что должен делать владелец процесса

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

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

Реальные примеры и признаки каждой ошибки

Абстрактные ошибки легко пропустить. На словах всё звучит нормально. А вот в пилоте такие вещи всплывают почти сразу.

Ошибка 1: неподходящий кейс. ИИ для квалификации лидов работает отдельно от CRM, а решения по лидам команда заносит в таблицы. На практике это значит, что пилот живёт сам по себе, а продажи - сами по себе. Тревожный признак: данные пилота хранятся в таблицах, а не в CRM или 1С [2].

Ошибка 2: нет KPI и ROI-логики. Компания запускает ИИ для подготовки коммерческих предложений, но не замеряет базовую конверсию, не задаёт целевой денежный эффект и не определяет порог, после которого пилот можно масштабировать. Иначе говоря, непонятно, с чем сравнивать итог. Тревожный признак: нет точки отсчёта, нет метрики успеха и нет порога для решения о масштабировании [1].

Ошибка 3: интеграцию отложили. ИИ-агент для обработки документов работает отдельно от CRM и 1С. После каждого шага сотрудник вручную переносит данные в другую систему. Это быстро превращает «автоматизацию» в лишнюю рутину. Тревожный признак: ручной перенос данных после каждого взаимодействия с ИИ [1].

Ошибка 4: безопасность и 152-ФЗ пропущены. В HR-процессе ИИ получает доступ к персональным данным сотрудников через общий аккаунт, без разделения прав. Это уже не мелочь, а прямой риск. Тревожный признак: в пилоте нет матрицы доступа, сценария ошибки и проверки на соответствие 152-ФЗ [2][3].

Ошибка 5: нет владельца и плана обучения. Сотрудники открывают интерфейс, видят слова вроде «репозиторий», «контекст», «развёртывание» - и просто закрывают вкладку. Это частый сигнал: инструмент вроде бы есть, но в работу он не вошёл. Там, где выстроена согласованная работа команды и системы, более 50% участников пилота переходят в постоянный штат [4]. Тревожный признак: инструмент используют время от времени, а сотрудники закрывают вкладку.

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

Таблицы, которые делают каждый риск наглядным

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

Кейс для пилота: слабый и сильный

Смысл здесь простой: если у пилота нет базы для сравнения, внятной цели и владельца, он почти наверняка останется разовой проверкой “на попробовать”.

Пилот без KPI и с KPI

Без KPI команда часто смотрит на пилот “по ощущениям”. С KPI разговор сразу становится предметным: сработало это в деньгах или нет.

Пилот без интеграций и с интеграциями

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

Минимальные требования безопасности к ИИ-пилоту

Безопасность легко отложить “на потом”, особенно в начале. Но если пилот работает с данными клиентов, сотрудников или сделок, такие вещи лучше не оставлять на авось.

Пилот без владельца и управляемый процесс

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

Дальше - как закрыть эти риски до запуска.

Как избежать этих ошибок с первого дня

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

Начните с процесса, где контекст уже теряется на стыках. Часто для этого берут онбординг [2]. Это удобная точка входа: там быстро видно, где люди тратят лишнее время, где данные теряются по дороге и где появляются сбои. Сразу зафиксируйте базовую картину: сколько уходит времени, сколько стоит операция в ₽ и сколько ошибок происходит сейчас.

Дальше заранее решите, по каким цифрам будете оценивать результат. Не раздувайте список метрик. Лучше выбрать один KPI и отдельно посчитать ROI в ₽: сколько стоит запуск и какой эффект вы ждёте получить [1]. Порог, после которого пилот можно масштабировать, стоит определить письменно ещё до старта. Иначе потом обсуждение легко уходит в стиль «вроде стало лучше, но неясно насколько».

Пилот должен работать не в вакууме, а в живом контуре. Поэтому подключайте его к CRM, 1С, почте и телефонии. Демо-стенд для решения о масштабировании не подходит [2]. На бумаге всё может выглядеть гладко, а в боевой среде обычно всплывает самое важное: права доступа, качество данных, сбои в обмене и ручные обходные пути.

Отдельно, с самого начала, согласуйте правила работы с данными. Сюда входят хранение данных, матрица доступа, обезличивание и соблюдение 152-ФЗ [3]. Этот блок лучше не оставлять «на потом». Если вернуться к нему в последний момент, проект может встать именно там, где все уже ждут запуск.

Когда контур данных согласован, нужен человек, который доведёт внедрение до результата. Назначьте владельца процесса со стороны бизнеса. Не только со стороны IT. Именно бизнес должен отвечать за то, чтобы решение прижилось в работе, а не осталось ещё одной системой «для галочки». Параллельно соберите кросс-функциональную команду: бизнес, IT, ИБ и юристы [2][4].

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

Заключение: от пилотного эксперимента к рабочему ИИ-слою

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

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

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

FAQs