Почему 95% пилотов проваливаются
🤔 Зачем это читать
Руководство сказало: «внедряем AI, нужны результаты». Ты выбил бюджет, нашёл подрядчика, запустил пилот (пробный проект — прогон на ограниченном куске работы, чтобы проверить идею до больших вложений). Полгода, несколько миллионов, презентации со светящимися графиками. А потом всё тихо сдулось: продукт никто не использует, цифры не сошлись, проект свернули без громких слов. На разборе вопрос смотрит на тебя: «так почему не взлетело?»
И вот что обиднее всего: ты, скорее всего, ответишь «модель оказалась слабовата» или «технология ещё сырая». А это почти наверняка неправда. И пока ты так думаешь, следующий пилот наступит на те же грабли.
Потому что провал почти никогда не на кухне у повара. Он на стыке: между блестящей демкой и реальной работой, где грязные данные, несгибаемые старые системы и сотрудники, которым новый инструмент только мешает. Это не технический вопрос. Это вопрос управленца — то есть твой.
После этой темы ты сможешь посмотреть на любой проваленный (или ещё живой) AI-пилот и назвать настоящую причину: одна из трёх дверей внедрения (данные, интеграция, принятие людьми) — или ошибка ещё на старте (взяли не тот кейс по риску, либо выбрали не тот подход «своё против готового»). И, главное, прикинуть, как не попасть в те самые 95% со своим следующим проектом.
Задержись на 10 секунд. Вспомни один AI-проект, который при тебе запускали — твой или у знакомых. Он взлетел или заглох? А теперь главный вопрос: знаешь ли ты, почему именно — или просто списали на «технологию»? Держи этот случай в голове: к концу страницы ты, возможно, поставишь другой диагноз.
📉 Цифра, с которой всё начинается
Есть исследование, которое за 2025 год разошлось по деловым изданиям — от Fortune до Reuters. Его сделали в MIT и назвали «GenAI Divide» — про разрыв между шумихой вокруг AI и реальной отдачей. Команда разобрала, как корпоративные пилоты доходят (или не доходят) до результата, и вывела цифру, которая бьёт наотмашь. (Методику потом критиковали — небольшая выборка, — но порядок цифры и причину провала это не меняет; и ровно эту причину нам и важно расслышать.)
На момент весны 2026 года она звучит так: из корпоративных AI-пилотов лишь около 5% доходят до измеримого бизнес-результата. Остальные — деньги потрачены, толку ноль: продукт не прижился, цифры не сошлись, проект свернули. Но дальше начинается самое важное, и тут нужно не отшатнуться от цифры, а вчитаться в причину.
Вот ключ ко всей теме, держи его крепко: пилоты проваливаются почти всегда во внедрении, а не в модели. Не потому, что повар-модель плохо готовит. А потому, что блюдо не довезли до зала: его не встроили в реальный рабочий поток, скормили ему бардак вместо чистых данных, не состыковали со старыми системами компании, и сотрудники его попросту не приняли. Это и есть тот самый разрыв между «работает на демке» и «работает в потоке» (в исследовании его называют learning gap). Дальше разложим, как этот разрыв выглядит на кухне.
🍽 Блюдо, которое не доехало до меню
Представь: шеф приготовил новое блюдо на дегустацию для своих. Гениально, все в восторге, решено — ставим в меню. Проходит месяц, а блюда в зале так и нет. Не потому, что оно невкусное. А потому, что тест-кухня и боевая линия — это два разных мира, и между ними блюдо застряло на трёх вещах.
Ровно так умирает AI-пилот. Демка прошла блестяще — а в реальную работу продукт не доехал. И застревает он почти всегда на одной из трёх дверей.
Разберём двери по очереди, по-человечески.
Первая — грязные данные. Самый частый и самый недооценённый барьер. AI хорош ровно настолько, насколько чисты данные, которыми ты его кормишь. Если в кладовой реквизиты в трёх форматах, половина клиентов задвоена, а актуальный прайс лежит в голове у Любови Петровны — никакая модель это не вытянет. Будет уверенно готовить из тухлятины и так же уверенно ошибаться. Не зря качество данных стабильно называют барьером № 1 для масштабирования AI. Эту дверь мы подробно отдельно разбирали — см. 7.4 — Грязные данные: garbage in, plausible garbage out.
Вторая — старые системы (legacy). Демку показывают на красивых тестовых данных в вакууме. А боевая работа живёт в твоей CRM, в 1С, в почте, на складе — в системах, которым по десять лет и которые не созданы стыковаться с чем-то новым. Подключить к ним AI оказывается дороже и дольше, чем сам пилот. По данным опросов, интеграцию со старыми системами руководители называют одним из главных вызовов внедрения. Блюдо готово — а раздачи, через которую его выносят в зал, просто нет.
Третья — люди не приняли. Самая невидимая дверь. Инструмент технически работает, но сотрудники им не пользуются: он добавляет лишний клик, ломает привычный порядок, или его навязали сверху без объяснений. Это называют change management (управление изменениями — как провести людей через новый процесс, чтобы они им реально пользовались). Официанты, которые не знают, как подавать новое блюдо, и втихую советуют гостям старое, угробят его вернее любого конкурента.
🛒 Контринтуитивное: готовое часто бьёт своё
Вот вывод, от которого многие управленцы морщатся, потому что он бьёт по гордости «мы построим своё, уникальное». По данным MIT, купленное у вендора готовое решение чаще доходит до результата, чем разработанное своими силами — грубо, успешными оказываются около двух третей покупных против примерно трети самописных. Цифру держи мягко, как ориентир направления, а не точный закон, но направление устойчивое.
Логика кухонная и простая. Построить свою кухню с нуля под уникальное блюдо — это месяцы, свои повара, своё оборудование и куча шансов застрять на каждой из трёх дверей. Заказать проверенный кейтеринг, который это блюдо уже сто раз отдавал на потоке, — быстрее, дешевле и надёжнее. Это и есть выбор build-vs-buy (своё против готового) — одна из двух главных ошибок ещё на старте, до всякого внедрения. Запомни: «давайте сделаем своё, уникальное» — частая дорога прямиком в 95%.
⏳ И это не только пилоты
Можно было бы сказать «ну, пилоты — это эксперименты, им положено отваливаться». Но дело шире. Аналитики Gartner прогнозируют, что более 40% уже запущенных агентных проектов будут отменены к концу 2027 года — из-за растущих затрат, неясной бизнес-ценности и слабого контроля рисков. На момент весны 2026 года это прогноз, не свершившийся факт, но он бьёт ровно в ту же точку: дорого, непонятно зачем, и риски не под контролем — провал.
Заметь: и тут причины — не «модель слабая». Затраты, ценность, контроль рисков — это всё решения владельца, а не повара. Один и тот же нерв: AI-проекты тонут на бизнес-стыке, а не на технике.
🧩 Та же диагностика одной схемой — для тех, кто мыслит «если… то…»
ЕСЛИ данные грязные, разрозненные или их нет:
→ причина = ДАННЫЕ # кладовая пуста, готовить не из чего
ИНАЧЕ ЕСЛИ не стыкуется с CRM / 1С / складом / почтой:
→ причина = ИНТЕГРАЦИЯ # оборудование не встаёт на линию
ИНАЧЕ ЕСЛИ работает, но сотрудники не пользуются:
→ причина = ЛЮДИ НЕ ПРИНЯЛИ # официанты не подают
ИНАЧЕ ЕСЛИ задачу вообще не стоило отдавать агенту (высокий риск):
→ причина = НЕ ТОТ КЕЙС # см. 1.8: хватило бы скрипта/человека
ИНАЧЕ ЕСЛИ типовую задачу строили своими силами вместо готового:
→ причина = НЕ ТОТ ПОДХОД # своё против готового, см. кейтеринг
ИНАЧЕ:
→ скорее всего, причина НЕ в «слабой модели» # это последнее, на что грешить
🎮 Поставь диагноз пилоту
Прежде чем жать кнопку — ответь себе сам, а потом сверься. Расхождение твоего ответа с разбором тут ценнее угаданного совпадения: на нём видно, на какую дверь ты пока не смотришь.
Пять проваленных пилотов. Для каждого выбери настоящую причину провала. Подсказка по правилу всей темы: «слабая модель» — почти всегда неверный ответ, ищи дверь во внедрении. Жми кнопку — сразу увидишь разбор.
А теперь — про твой кейс
Тренажёр — про чужие пилоты. Сила навыка в том, чтобы навести его на свой. Возьми тот проект, что держал в голове с начала страницы, и честно прогони три вопроса:
- Данные, которыми его кормят, — реально чистые и собранные в одном месте, или это «прайс в голове у Любови Петровны»?
- Он подключён к системам, в которых люди уже работают, — или живёт сбоку, и в него надо что-то переносить руками?
- Сотрудники, которым он нужен, понимают, зачем он и что он им даёт, — или восприняли его как угрозу или лишний клик?
📖 Ключевые понятия
- Пилот / PoC (пробный проект)
- Прогон AI-идеи на ограниченном куске работы, чтобы проверить её до больших вложений. PoC — proof of concept, «доказательство, что замысел в принципе работает». Проблема в том, что успешный пилот ещё не означает работающий продукт: между ними — внедрение.
- Внедрение (то, на чём всё ломается)
- Путь от «работает на демке» до «работает в реальном потоке»: чистые данные, стыковка со старыми системами, встроенность в рабочий процесс, принятие людьми. Именно здесь, а не в модели, и застревают те самые ~95% пилотов — не дошли до измеримого результата. Разрыв между демкой и потоком в исследовании MIT называют learning gap.
- Старые системы (legacy)
- CRM, 1С, склад, почта — то, в чём компания уже работает много лет. Часто не созданы стыковаться с новым, и подключить к ним AI оказывается дороже самого пилота. Одна из трёх дверей, на которых застревает проект.
- Принятие / управление изменениями (change management)
- Работа по тому, чтобы люди реально пользовались новым инструментом: объяснить зачем, обучить, встроить в их день, снять страх «нас заменят». Инструмент может технически работать и всё равно провалиться, если эту дверь не открыли.
- Своё vs готовое (build-vs-buy)
- Выбор: строить AI-решение своими силами или купить готовое у вендора. По данным MIT, готовое чаще доходит до результата (грубо две трети против трети у самописного) — особенно на типовых задачах. «Сделаем своё уникальное» — частая дорога в те самые 95%.
🛡️ Частые заблуждения
«Пилот не взлетел, потому что модель оказалась слабой — подождём модель помощнее»
Почти всегда неправда, и это самая дорогая ошибка диагноза. Провал почти никогда не на кухне у повара, а на стыке: грязные данные, несостыкованные системы, не принявшие инструмент люди. Модель помощнее не починит грязную кладовую и не подключит твою CRM. Будешь менять повара вместо ремонта раздачи — снова в 95%.
«Успешная демка означает, что продукт готов к работе»
Демка — это дегустация для своих на тест-кухне. Реальная работа — боевая линия в пятницу вечером, с грязными данными, старыми системами и живыми сотрудниками. Между ними — целое внедрение, и именно там застревает большинство. Демка доказывает, что повар умеет готовить, а не что блюдо доедет до зала.
«Раз это наша уникальная задача, надо строить своё, а не покупать готовое»
Чаще всего задача типовее, чем кажется, а «своё уникальное» — это месяцы, свои повара и шанс застрять на каждой двери. По данным MIT, готовые решения доходят до результата чаще самописных. Строить своё оправдано там, где задача правда уникальна и в этом твоё преимущество, — а не по умолчанию из гордости.
🧠 AI-чутьё (AI Judgment)
Что на самом деле решает успех AI-проекта
Вот центральная мысль не только этой темы, но и всего курса, в одной фразе: успех AI-проекта решают интеграция, чистые данные и встроенность в рабочий поток — а не хайп вокруг технологии и не «модель помощнее». Около 95% пилотов тонут именно на этом стыке, не на кухне. Кто это понял — уже не в большинстве.
Для тебя как владельца это два рабочих движения. Первое — правильный диагноз: на любой буксующий проект сначала смотри на три двери (данные, интеграция, люди) и на выбор кейса, и только в последнюю очередь греши на модель. «Слабая модель» — это почти всегда отговорка, за которой прячется незакрытая дверь внедрения.
Второе — как не попасть в 95% со своим проектом. Начинай с малого, высокоценного и низкорискового кейса — той самой скучной бумажной рутины, которую не видит клиент (то, что называют back-office), из когда агент НЕ нужен. Сначала наведи порядок в данных, продумай стыковку с системами и план для людей — и только потом обсуждай, какая модель. Скучный кейс, который реально доехал до результата, ценнее десяти эффектных, утонувших на демке. Не «давайте внедрим AI», а «давайте доведём один понятный кейс до измеримого результата». Так звучит владелец, который не попадёт в 95%.
🎯 Практика
Одно задание — вернись к нему, когда будет минут десять спокойно подумать, — чтобы навык диагноста лёг на твою реальную работу, а не остался цифрой из исследования.
- Возьми один AI-проект из своего опыта — проваленный, буксующий или тот, что только собираются запускать.
- Прогони его по той же решётке, что в тренажёре. Сначала три двери внедрения: данные (чистые и в одном месте?), интеграция (подключён к рабочим системам?), принятие (люди понимают, зачем он, и пользуются?). Потом две ошибки на старте: тот ли это кейс (задачу вообще стоило отдавать AI по риску, см. матрицу «ценность × риск»?) и тот ли подход (строили своё там, где есть готовое?). Где зияет дыра?
- Если проект ещё живой — выпиши одно конкретное действие по самой слабой двери: какие данные почистить, какую систему подключить, кого и как обучить. Это и есть твой шаг из 95% в 5%.
- Загляни в заметку из начала страницы: тот случай, что ты держал в голове. Совпал твой первый диагноз с тем, что вышло по этой решётке, — или ты раньше списывал на «технологию»?
Этот листок с диагнозом — уже почти готовый разговор с руководством или подрядчиком. Не «модель подвела, нужна посильнее», а «проект буксует вот на этой двери, и вот что мы по ней сделаем». Так звучит управленец, который понимает, где на самом деле ломаются AI-проекты.