Почему 80% AI-проектов для бизнеса проваливаются (и как попасть в 20%)

Сначала честно: AI-проект проваливается не из-за модели

Когда бизнес говорит «у нас не взлетел AI», почти всегда начинается обсуждение модели: не та нейросеть, не тот промпт, не тот векторный поиск, не тот fine-tuning. На практике модель редко является главной причиной. Проект ломается раньше: на выборе задачи, данных, ответственности, интеграциях, ожиданиях и отсутствии владельца процесса.

Я за последние годы участвовал в 12 AI-проектах для бизнеса: ассистенты продаж, RAG-базы знаний, AI-диспетчеры, прогноз спроса, HR-боты, аналитические агенты. Из них 10 дошли до рабочей эксплуатации, 2 я считаю провалами. Не «частично неудачными», а именно провалами: бизнес не получил ожидаемый эффект, команда устала, проект пришлось закрыть или пересобрать с нуля.

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

Причина 1. Выбрали задачу, где AI не нужен

Самая частая ошибка — начать с модного сценария, а не с боли бизнеса. Руководитель увидел демо ChatGPT, конкурент запустил бота, подрядчик предложил «AI-ассистента для всего», и команда начинает автоматизировать процесс, который не влияет на деньги. Получается красиво, но бесполезно.

AI нужен там, где есть повторяемость, данные, цена ошибки и измеримый результат. Например, обработка 500 заявок в день, поиск по 20 000 документов, первичный скрининг кандидатов, прогноз оттока, ответы поддержки, диспетчеризация заказов. Если процесс выполняется 3 раза в месяц и требует сложного экспертного решения, AI может быть помощником, но не основой ROI.

Причина 2. Нет владельца процесса

AI-проект не может принадлежать «всем понемногу». Если за него отвечает IT, но пользователи сидят в продажах, проект зависнет. Если отвечает директор, но нет операционного владельца, все решения будут ждать календаря руководителя. Если отвечает подрядчик, но внутри компании никто не меняет регламенты, AI останется внешней надстройкой.

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

Причина 3. Данные грязные, разрозненные или недоступные

AI не спасает хаос данных. Если статусы сделок ведутся как попало, база знаний устарела, документы лежат в пяти папках, а сотрудники пишут клиентам из личных мессенджеров, модель будет уверенно генерировать мусор. Она не знает, что в вашей CRM половина полей не обновлялась год.

В RAG-проектах это особенно заметно. Бизнес ожидает, что ассистент будет отвечать по регламентам, но регламенты противоречат друг другу. В аналитике модель должна прогнозировать спрос, но исторические продажи и остатки не совпадают. В HR агент должен оценивать кандидатов, но профили вакансий написаны общими словами.

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

Причина 4. Демо приняли за продукт

Демо почти всегда впечатляет. На 10 подготовленных примерах агент отвечает быстро, красиво и уверенно. Но продукт начинается там, где появляются исключения: клиент пишет с ошибками, документ не того формата, менеджер меняет статус вручную, API падает, пользователь задает вопрос не по инструкции, а руководитель требует отчет утром.

AI-проект должен проектироваться как система: интерфейс, роли, логирование, права доступа, fallback-сценарии, мониторинг качества, ручное подтверждение опасных действий. Если этого нет, демо не переживет реальность.

Причина 5. Ждали магию вместо внедрения

AI не внедряется сам. Нужно обучить людей, изменить регламенты, объяснить границы ответственности, убрать старые дублирующие действия, назначить метрики. Если менеджеры продолжают работать «как раньше», а AI живет в отдельном окне, эффекта не будет. Любая автоматизация требует управленческой воли.

Я видел проекты, где агент экономил время, но команда не доверяла ему, потому что никто не объяснил, как проверять ответы. Видел проекты, где AI формировал идеальные задачи, но руководители не открывали таск-трекер. Это не техническая проблема. Это проблема внедрения.

Мой опыт: 2 провала из 12

Провал №1: прогноз спроса без нормальной истории

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

Модель показывала приемлемую точность на исторических данных, но плохо работала в операционном планировании. Главная ошибка была моя: я слишком рано согласился на прогноз как цель, хотя сначала нужно было привести данные и процесс планирования в порядок. Проект закрыли после пилота. Вывод: если данные не отражают реальность, AI только ускорит самообман.

Провал №2: AI-ассистент продаж без владельца в продажах

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

Через месяц ассистент стал «еще одним инструментом», а не частью процесса. Виноват не AI. Виновата архитектура внедрения: нужно было сначала договориться о правилах работы отдела и только потом автоматизировать.

Формула успеха AI-проекта

Сейчас я использую простую формулу: боль × данные × владелец × интеграция × метрика. Если один элемент равен нулю, весь проект проседает.

• Боль: задача повторяется часто и стоит бизнесу денег, времени или риска.
• Данные: есть источники, на которых можно учить, искать или принимать решения.
• Владелец: внутри компании есть человек, который меняет процесс.
• Интеграция: AI встроен в CRM, ERP, телефонию, документы или рабочие чаты.
• Метрика: заранее понятно, как измерять успех: скорость, конверсия, стоимость, ошибки, SLA.

И еще одно правило: хороший AI-проект начинается узко. Не «автоматизировать отдел продаж», а «сократить время подготовки КП с 40 минут до 7 минут». Не «сделать умную базу знаний», а «снизить повторные вопросы поддержки на 30% по 50 самым частым темам». Узкий пилот легче измерить и легче масштабировать.

Красные флаги подрядчика

AI-рынок сейчас шумный. Много сильных команд, но много и тех, кто продает обертку вокруг API без понимания бизнеса. Я бы насторожился, если подрядчик:

• обещает «полностью заменить отдел» до аудита процесса;
• не спрашивает про данные, права доступа и интеграции;
• говорит только про модель, но не говорит про метрики;
• не предлагает пилот с ограниченным scope;
• не обсуждает безопасность, логи и хранение данных;
• не может показать похожие кейсы или демо на ваших примерах;
• не закладывает этап обучения пользователей;
• избегает разговора о поддержке после запуска;
• обещает 100% точность там, где есть человеческий язык и исключения.

Сильный подрядчик иногда отговаривает от AI. Это хороший знак. Значит, он думает о результате, а не о продаже любой ценой.

Чеклист 15 пунктов перед стартом

1. Сформулируйте одну бизнес-задачу, а не общий лозунг про AI.
2. Назначьте владельца процесса со стороны бизнеса.
3. Опишите текущий процесс шаг за шагом.
4. Посчитайте стоимость проблемы: часы, деньги, ошибки, потери заявок.
5. Проверьте источники данных и их актуальность.
6. Определите, какие действия AI может делать сам, а какие только предлагать.
7. Подготовьте 30–50 реальных примеров для тестирования.
8. Опишите KPI пилота до начала разработки.
9. Проверьте требования по персональным данным и доступам.
10. Продумайте fallback: что происходит, если AI ошибся или сервис недоступен.
11. Настройте логирование действий и оценку качества ответов.
12. Встройте агента в рабочие системы, а не в отдельную вкладку.
13. Обучите пользователей и объясните границы доверия.
14. Проводите еженедельный разбор метрик пилота.
15. Масштабируйте только после доказанного эффекта.

Как я сейчас запускаю AI-проекты

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

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

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

FAQ

С какого AI-проекта бизнесу лучше начинать?

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

Сколько должен длиться пилот?

Обычно 4–8 недель достаточно, чтобы проверить гипотезу. Если за это время невозможно показать хотя бы промежуточный эффект, scope выбран слишком широкий или задача плохо подготовлена.

Можно ли запускать AI без чистых данных?

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

Как понять, что проект пора закрывать?

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

Мой главный вывод после 12 проектов: AI выигрывает не там, где больше всего хайпа, а там, где есть дисциплина процесса. Модель — это двигатель. Но без дороги, водителя и приборной панели бизнес далеко не уедет.

Мой опыт: 2 провала из 12 проектов

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

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

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

Формула успеха AI-проекта

Моя рабочая формула выглядит так: боль × данные × владелец × интеграция × метрика. Если один элемент равен нулю, весь проект стремится к нулю. Боль отвечает за мотивацию бизнеса. Данные дают модели материал. Владелец принимает решения и снимает блокеры. Интеграция встраивает AI в рабочий день, а не оставляет его в отдельной вкладке. Метрика показывает, выиграли мы или просто сделали красивую игрушку.

Например, AI-агент для обработки заявок в логистике работает, если есть поток заявок, история перевозок, правила проверки, интеграция с CRM и метрика вроде времени обработки или доли ошибок. Если убрать CRM, менеджеры будут копировать ответы вручную. Если убрать владельца, никто не согласует спорные правила. Если убрать метрику, команда будет спорить о впечатлениях вместо результата.

Красные флаги подрядчика

• обещает «AI для всего бизнеса» без аудита процессов;
• говорит только про ChatGPT, но не спрашивает про данные, роли и интеграции;
• не предлагает пилот с ограниченным объемом;
• не фиксирует метрики до старта;
• игнорирует безопасность, доступы и хранение персональных данных;
• не объясняет, что будет делать человек при ошибке модели;
• продает магию вместо архитектуры и регламента эксплуатации.

Чеклист 15 пунктов перед стартом

1. Опишите одну бизнес-задачу, не десять.
2. Посчитайте текущую стоимость процесса.
3. Назначьте владельца со стороны бизнеса.
4. Определите пользователей, которые будут работать с AI каждый день.
5. Проверьте качество данных и документов.
6. Уберите устаревшие инструкции из базы знаний.
7. Согласуйте права доступа.
8. Выберите метрику успеха.
9. Опишите сценарии ошибок и эскалации человеку.
10. Запустите пилот на ограниченном участке.
11. Соберите обратную связь пользователей.
12. Проверьте интеграции с CRM, ERP, телефонией или helpdesk.
13. Назначьте владельца поддержки после запуска.
14. Сравните результат с базовой метрикой.
15. Масштабируйте только после доказанного эффекта.

FAQ

С чего начинать AI-проект в бизнесе?

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

Как понять, что подрядчик по AI опасен?

Опасный подрядчик обещает универсального бота без анализа процесса, не говорит про данные и интеграции, не фиксирует метрики, избегает пилота и не объясняет ограничения модели.

Какой AI-проект быстрее всего окупается?

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