Пилот закончился два месяца назад. Демо показывали руководству, всем понравилось, озвучили планы масштабирования. Сейчас у проекта нет владельца, счёт за API приходит каждый месяц, а в CRM и в чатах поддержки ничего не изменилось — команда, как и раньше, делает руками. Так выглядят самые частые проблемы внедрения ИИ в компании. По данным исследования MIT, у большинства корпоративных пилотов с генеративным ИИ это одна история: около 95% из них не дают измеримого влияния на прибыль [1].
Моя позиция: в таких историях буксует не нейросеть. Буксует контур вокруг неё — процесс, данные, встраивание в работу. Поэтому «сменим модель» и «найдём нового подрядчика» лечат не то.
Это видно по цифрам, если читать их целиком. RAND оценивает долю провальных ИИ-проектов более чем в 80% — вдвое выше, чем у обычных ИТ-проектов [2]. Но у компаний, которые всё же дошли до реального применения, эффект есть: по данным сплошных обследований Росстата, 62,7% применяющих ИИ организаций отмечают улучшение качества и эффективности процессов [3]. Разрыв между «95% пилотов без эффекта» и «63% применяющих видят пользу» — не про качество моделей. Он про переход от пилота к рабочему процессу. Ниже — пять точек, где этот переход ломается, что делать по каждой и когда проект честнее закрыть.
Как выглядит буксующий проект
Признаки узнаваемы — это типовые ошибки внедрения ИИ, и ни один из них не про «модель недостаточно умная».
Демо живёт отдельно от процесса. Ассистент открыт на отдельной вкладке «чтобы задать вопрос» — и никто не открывает. Работа идёт там же, где и шла: в CRM, в почте, в чате.
У проекта нет числа. Вместо «время обработки заявки упало с четырёх часов до сорока минут» — «коллегам нравится», «конкуренты уже внедряют». Без числа проектом нельзя управлять, а его бюджет нельзя защитить.
Расходы есть, эффекта нет. Счёт за токены стабилен, выручка и трудозатраты не двигаются.
При любом сбое меняют модель. Не настроили передачу человеку — «модель плохая». Дали ассистенту отменённый прайс — «модель галлюцинирует». Перезапуск у нового подрядчика через полгода даёт те же результаты: организационная дыра осталась той же.
MIT называет корневую причину «разрывом обучения»: универсальные инструменты вроде общего чата не встраиваются в конкретный процесс компании и не адаптируются под него [1]. Проблема не в том, что модель глупая. В том, что её никто не подключил к работе.
Пять точек, где буксует внедрение
Нет названного результата
«Внедрить ИИ» — не результат. Результат — измеримое изменение процесса: время первого ответа на заявку, доля обращений, закрытых без специалиста, стоимость обработки одного заказа. Microsoft в руководстве по внедрению агентных систем предупреждает об этом прямо [4]:
У каждой ИИ-инициативы должны быть названный результат и владелец. Нет владельца — это пожелание, а не решение.
Пока результат не назван, у проекта нет критерия, по которому видно, работает он или буксует.
Нет владельца процесса
У буксующих проектов почти всегда есть инициатор — руководитель, который «хочет ИИ», — и исполнитель: подрядчик или внутренняя «ИИ-команда». А владельца процесса нет: человек, который отвечает за обработку заявок или за базу знаний, не участвовал в проектировании и не отвечает за результат. Подрядчик сдаёт демо и уходит, процесс живёт как жил. Microsoft дополняет эту картину: инициативы буксуют, когда команда берёт на себя больше, чем может владеть, контролировать и эксплуатировать сегодня [4].
Данные не в порядке
RAND называет неадекватные данные второй из пяти корневых причин провала ИИ-проектов [2]. Среди применяющих ИИ российских организаций 34% называют барьером недостаточные или низкокачественные массивы данных [3]. В малом и среднем бизнесе это выглядит не как «нет хранилища», а как «знания размазаны»: половина правил — в регламенте, половина — в голове лучшего менеджера, актуальный прайс — в чате отдела. Модель не найдёт то, чего нет ни в одной системе. Пока на правильный вопрос нельзя найти ответ в документах, ассистенту не из чего отвечать.
Решение не встроено в рабочий поток
Сотрудник не будет держать отдельную вкладку с ассистентом. Если ответ ИИ не появляется там, где уже идёт работа — в CRM, в почте, в мессенджере, — им не будут пользоваться, и проект останется витриной. Встраивание — это интеграционная работа: связать ассистента с CRM и каналами, разметить, какие действия он выполняет сам, а где передаёт человеку. Anthropic формулирует общий принцип: искать простейшее решение, которое закрывает задачу, и усложнять только тогда, когда простого перестаёт хватать [5]. Работает и обратная сторона: простое решение, встроенное в поток, ценнее сложного, стоящего рядом с потоком.
Не посчитана эксплуатация
Пилот — короткая фаза. После него начинается жизнь: документы устаревают, ошибки нужно разбирать, счёт за токены — контролировать, права доступа — пересматривать. Если у эксплуатации нет владельца и бюджета, качество молча деградирует, и через полгода ассистент уверенно отвечает по отменённому прайсу. Не случайно среди барьеров российские организации чаще всего называют высокие затраты — 54% [3]. При этом счёт за ассистента — управляемый параметр, если считать его заранее, а не после первого крупного инвойса: методику расчёта мы разбирали отдельно [7].
Что делать по каждой точке
Порядок имеет значение: сначала организация, потом технология.
- Назвать результат: одна метрика процесса, её текущее значение, целевое значение и срок.
- Назначить владельца: человек, отвечающий за процесс, участвует в проектировании и подписывает приёмку.
- Навести порядок в данных: собрать правила и документы, назначить источник истины, убрать противоречия. На этом шаге часто выясняется, что часть задачи решается правилами без всякой модели — как провести границу между правилами и ИИ, мы разбирали отдельно [10].
- Встроить в поток: CRM, почта, мессенджер; граница «помогать или выполнять» и правило передачи человеку.
- Посчитать эксплуатацию: кто обновляет базу знаний, кто разбирает ошибки, каков лимит расходов, где журнал действий.
Смены модели в этом списке нет. Модель выбирается под класс задачи после того, как контур определён. В большинстве сценариев малого бизнеса решает всё остальное.
Когда проект честнее закрыть
Закрыть проект — не признание провала технологии. Иногда это правильное управленческое решение:
- задача решается шаблоном, правилами или изменением самого процесса — модель не нужна;
- у задачи нет проверяемого эталона в данных, «правильный ответ» каждый раз формулирует эксперт по ситуации;
- ошибка необратима, а точку подтверждения встроить некуда;
- поток слишком мал, чтобы окупить даже скромное содержание.
Провал — не закрытый проект. Провал — второй круг бюджета на ту же организационную дыру: без владельца, без метрики, без встраивания. Как ещё до старта отличить проект, который стоит запускать, от проекта, обречённого буксовать, — отдельный разбор [6].
Как перезапустить пилот без второго круга
Один процесс, одна операция, одна метрика. Один владелец со стороны бизнеса. Срок — четыре–шесть недель. Тестовый набор из реальных кейсов: качество проверяется на нём, а не «сразу на живых клиентах». Правило передачи человеку и журнал действий — с первого дня, а не «потом добавим». Проверки готовности конкретного процесса к такому пилоту — отдельный шаг до старта разработки [8]; приёмка результата — по тому же тестовому набору [9].
Вывод
Буксование ИИ-проекта — диагноз процесса, а не модели. Прежде чем менять модель или подрядчика, назовите результат одним числом, назначьте владельца и найдите самую слабую из пяти точек: результат, владелец, данные, встраивание, эксплуатация. Первый шаг — посчитать текущее значение выбранной метрики за последний месяц; без него и перезапуск будет вслепую.
Если не уверены, в какой точке буксует ваш проект, — начните с аудита процесса: он показывает, нужен ли здесь ИИ, обычная автоматизация или изменение самого процесса, и где границы первого пилота.
Частые вопросы
Сколько ИИ-проектов проваливается?
По оценке RAND — более 80%, вдвое чаще обычных ИТ-проектов [2]; MIT считает уже пилоты с генеративным ИИ: около 95% без измеримого влияния на прибыль [1]. Приговор конкретному проекту эти цифры не выносят: они собраны по корпоративным пилотам в целом и описывают разрыв между демо и рабочим процессом. Там, где до применения дошло, картина другая: по обследованию Росстата, 62,7% применяющих организаций отмечают улучшение процессов [3].
Почему ИИ не приносит пользы, хотя демо хорошее?
Демо отвечает на придуманные вопросы в идеальных условиях. Процесс требует актуальных данных, встраивания в рабочий интерфейс и правила передачи сложных случаев человеку. Без этого демо остаётся витриной, на которую никто не заходит.
Стоит ли менять модель, если ассистент работает плохо?
Сначала найдите причину: в большинстве случаев это данные, интеграция или отсутствие передачи человеку, а не модель. Смена модели не чинит устаревшую базу знаний и не заменяет владельца процесса.
Как понять, что ИИ-проект пора закрыть?
Если задача решается правилами, у неё нет проверяемого эталона в данных, ошибка необратима без человека, а поток мал — проект лучше закрыть и перенести усилия на наведение порядка в процессе. Это экономия, а не поражение.
С чего начать диагностику буксующего проекта?
Назначьте владельца и выберите одну метрику. Посчитайте её текущее значение за последний месяц. Затем пройдите по пяти точкам — результат, владелец, данные, встраивание, эксплуатация — и найдите самую слабую: она и есть ближайшая работа.
Источники
- The GenAI Divide: State of AI in Business 2025 — MIT Project NANDA, август 2025; обзор Fortune (Sheryl Estrada, 2025-08-18)
- The Root Causes of Failure for Artificial Intelligence Projects — RAND Corporation, 2024-08-13
- Крупный бизнес наиболее активно внедряет ИИ — ИСИЭЗ НИУ ВШЭ по данным сплошных обследований Росстата, 2026-09-24
- Choose the right transformation pattern — Microsoft Learn, обновлено 2026-07-14
- Building Effective Agents — Anthropic, декабрь 2024
- Оценка эффективности ИИ-проекта до запуска и на пилоте — Андрей Волкоедов, ai-av.ru, 29 июля 2026
- Стоимость ИИ-ассистента: почему счёт за нейросеть растёт и как им управлять — Андрей Волкоедов, ai-av.ru, 22 сентября 2026
- С чего начать внедрение ИИ в бизнес: аудит перед пилотом — Андрей Волкоедов, ai-av.ru, 13 августа 2026
- Тестирование чат-ботов с ИИ: как проверить RAG-систему перед запуском — Андрей Волкоедов, ai-av.ru, 15 июля 2026
- Автоматизация с помощью ИИ: где она оправдана, а где — нет — Андрей Волкоедов, ai-av.ru, 27 июня 2026
