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

Алексей Штурбин C-level стратег · Зинин × Штурбин LinkedIn ↗

2 июня 2026

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

Где именно умирает пилот и почему

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

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

Старт с выбора модели вместо больного процесса

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

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

Грязные данные и пустой контур контроля

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

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

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

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

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

Пилот без владельца, без метрик и в ожидании чуда

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

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

Метрика и ожидание чуда связаны теснее, чем кажется. Когда у пилота есть число успеха, широкая мечта «пусть решит всё сразу» сама собой сжимается до проверяемой задачи: вы вынуждены выбрать процесс, по которому это число можно посчитать. Когда метрики нет, мечта разрастается, потому что её нечем приземлить, и каждый участник видит в пилоте своё. Маркетолог ждёт от него тексты, поддержка — ответы клиентам, руководство — экономию на штате, и пилот пытается угодить всем сразу, заваливая каждую задачу понемногу. Одна метрика на один процесс гасит этот разнобой в первый же день.

• Метрику качества и порог задавайте до запуска через оценки качества: какой долей верных ответов или какой экономией часов вы признаете пилот удачным. Без этого числа спор об успехе превращается в спор о вкусе.
• Отдачу считайте через ROI ИИ: цена запуска и подписок против сэкономленных часов и денег по выбранному процессу. Цифра либо защищает следующий шаг перед руководством, либо честно закрывает тупиковый пилот.
• Ожидание чуда лечится сужением задачи. Узкий пилот с проверяемым результатом за короткий срок приносит понятную победу, а широкий «решим всё разом» расплывается и умирает без единой завершённой задачи.

Как довести пилот до рабочего контура

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

1. Назовите один больной процесс и посчитайте его цену в часах и деньгах. С этой цифрой вы потом докажете отдачу самому себе и руководству.
2. Соберите данные процесса в один источник и наведите в них порядок, прежде чем подключать модель.
3. Назначьте владельца пилота с выделенным временем и задайте одну метрику качества с порогом заранее.
4. Запустите короткий узкий пилот со связкой, где сотрудник проверяет результат модели и держит финальное слово.
5. Посчитайте отдачу через ROI ИИ и решите по цифрам: расширять пилот, переделывать или честно закрывать.

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

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

← Все статьи