Почему AI-проекты не достигают целей: пять ошибок внедрения

Что исследования говорят о внедрении AI

Gartner 7 апреля 2026 года опубликовал итоги опроса 782 руководителей по инфраструктуре и эксплуатации. Полностью достигают целей и оправдывают ожидания по возврату инвестиций 28% сценариев применения AI. Каждый пятый проект проваливается начисто, а хотя бы одну неудачу у себя за год видели 57% опрошенных. Среди причин лидируют устойчивая нехватка навыков и плохое качество данных - их назвали по 38%.

Deloitte в «State of AI in the Enterprise» 2026 года спросил о том же 3235 руководителей в 24 странах и получил пять барьеров. Людям не хватает навыков. Инфраструктура не готова. В управлении данными дыры. С рисками и соответствием требованиям неясность. Нужных людей не найти.

Барьеры связаны с технической готовностью и организацией внедрения.

С агентами разрыв ещё шире. Deloitte в Tech Trends 2026 разложил компании по стадиям: 30% присматриваются, 38% гоняют пилоты, 14% держат готовое к запуску решение. Агенты работают в проде у 11%.

Прогноз Gartner от 26 мая 2026 года добавляет цифру, которую неприятно читать: к 2027 году 40% компаний понизят автономных агентов в правах или выключат совсем. Дыры в полномочиях обнаруживаются только после инцидента в проде, когда агент уже успел что-то сделать. Отказ от AI-инициативы перестал быть исключением.

Разрозненные данные: почему AI не знает, что он не знает

Разрозненные данные - это когда рабочая информация лежит в местах, которые не видят друг друга. Система учёта клиентов не видит таск-трекер (программу для отслеживания задач), таск-трекер не видит бухгалтерию, а таблица, которую с 2021 года ведёт один операционщик, обычно самое важное хранилище в компании.

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

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

Для AI это принципиальная проблема, и вот почему. Агент - это программа на нейросети, которая сама выполняет кусок работы. Агент, у которого есть треть картины, не скажет, что у него треть картины. Он выдаст гладкий уверенный ответ, построенный на трети картины.

Ручной бардак хотя бы заметен.

Первые две недели: две карты одной компании

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

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

Система, спроектированная по карте руководителя, не приживается. Команда чувствует несовпадение сразу и начинает работать в обход.

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

Этот подсчёт часто оказывается неожиданным для самого руководства.

Проектирование на бумаге: прежде чем нажать первую кнопку

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

Первой проектируют схему данных. Схема данных - это описание того, какие главные объекты у бизнеса есть (клиент, заказ, проект, объект, пациент), какие поля они несут и как связаны между собой. Схема данных появляется до экранов, до автоматизаций, до агентов. Всё остальное строится поверх неё.

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

Как только две системы могут писать одну и ту же запись - разрыв воссоздан на новом софте. Место, где хранится правильная версия, должно быть одно.

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

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

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

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

Хорошо спроектированное внедрение удаляет больше, чем создаёт.

Порядок сборки: данные, потом процессы, потом агенты

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

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

Агенты идут последними - поверх чистых процессов и чистых данных.

Правило одной точки ввода закрепляют в коде: каждая автоматизация, которая пишет данные, проверяет их по схеме. Мусор отсекают на входе, и до отчётов он не доходит.

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

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

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

Переход: три пути и их арифметика

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

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

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

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

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

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

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

Приживаемость и четыре петли обратной связи

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

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

Главная метрика после запуска - доля описанных процессов, которые идут через новую систему.

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

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

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

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

Пять причин провала и форма проекта на 90 дней

Типичный проект выглядит так. Недели 1-2: оценка - интервью, инвентаризация систем, карта процессов, замер потерь, разбор результата с руководством. Недели 3-4: архитектура и фундамент - схема данных финализируется, инструменты проходят через дерево решений, выбирается путь перехода, начинается база данных. Недели 5-8: процессы отдел за отделом, тестирование на реальных данных, ежедневные показы. Недели 9-10: агенты поверх стабильных процессов, проверка на реальных случаях. Недели 11-12: переход, обучение по ролям, запуск, отключение старых инструментов. Следующие 30 дней - наблюдение за приживаемостью.

Сроки зависят от сложности. Порядок не меняется никогда.

Пять причин, по которым внедрения проваливаются, и ни одна из них не техническая.

Оценку пропустили или сделали поверхностно. Систему спроектировали по карте руководителя, команда почувствовала несовпадение и начала работать в обход.

Автоматизировали сломанный процесс. Он стал выполняться быстрее - но по-прежнему сломанным.

Инструменты выбрали до архитектуры. Бизнес подогнали под софт, хотя выбор инструментов должен идти последним - после того, как понятна схема данных и карта процессов.

AI поставили первым вместо последнего. Агенты сели на разрозненные данные без слоя процессов, хорошо показали себя на демо и посыпались в реальных условиях. Команда потеряла веру во всю затею.

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

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

Вопросы и ответы

Мы уже купили AI-инструмент. Поздно делать оценку?

Нет. Оценка нужна до того, как вы решите, на какие процессы этот инструмент ставить. Купленный инструмент - это ещё не внедрение, это подписка. Разница между ними и есть тот самый процесс.

Сколько стоит разрозненность данных в деньгах?

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

Нужно ли переносить всю историческую базу в новую систему?

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

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

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

Majento строит AI-агентов и внедряет их внутри компаний-клиентов по модели forward-deployed: инженеры встраиваются в процессы клиента, находят узкое место, собирают рабочую систему и остаются до результата. Если хотите разобраться, с чего начать в вашей компании, - пишите в Telegram t.me/shimaoz или на hello@majento.ai.

Источники

1. gartner.com - 2026 04 07 gartner says artificial intelligence projects in infrastructure and operations stall ahead of meaningful roi returns
2. deloitte.com - state of ai in the enterprise
3. deloitte.com - agentic ai strategy
4. gartner.com - 2026 05 26 gartner says applying uniform governance across ai agents will lead to enterprise ai agent failure