Проваливаются они почти всегда по одной из четырёх причин, и ни одна не про качество моделей. Задачу выбрали неправильно. Результат никто не проверяет. Интеграция выглядит рабочей, но не работает. Эксплуатацию не спроектировали.
По публичному разбору пятидесяти российских внедрений (vc.ru, 2026) почти каждый четвёртый проект заканчивается ничем. Методология автором не раскрыта, так что цифру стоит держать как ориентир. Но набор причин повторяется и там, и в разговорах с людьми, у которых предыдущая попытка не сработала.
| Где ломается | Как выглядит снаружи | Что спросить до старта |
|---|---|---|
| Задачу выбрали неправильно | Система работает, пользы не видно; сотрудники обходят её стороной | «Почему именно эта задача и что мы измерим через месяц» |
| Результат никто не проверяет | В отчётах растут цифры активности, в работе ничего не изменилось | «Как я пойму, что ответ верный, не открывая документ сам» |
| Интеграция выглядит рабочей | Индикатор зелёный, а данные в системе не меняются | «Как вы проверяете, что действие реально выполнилось» |
| Эксплуатацию не спроектировали | Первые недели всё хорошо, через полгода систему не открывают | «Кто разбирает очередь исключений и кто обновляет документы» |
Задачу выбрали неправильно
Взяли процесс, где хватило бы обычной программы
Самый частый и самый обидный случай. Языковую модель ставят проверять формат почтового адреса, сверять два числа или находить дубликаты по точному совпадению. Всё это делает обычный код: быстрее, дешевле и с одинаковым результатом на одинаковом входе.
Признак этой ошибки простой: если правило задачи можно записать словами без «примерно» и «в зависимости от контекста», модель здесь лишняя. Она стоит денег на каждом вызове и отвечает по-разному на один и тот же вход.
Взяли процесс, где ИИ не может знать ответ
Ассистент отвечает по документам, а не вместо них. Если ответы живут в головах трёх человек, а инструкции устарели два года назад, система будет уверенно выдумывать. Хуже того, выдумывать правдоподобно: сотрудники поверят и передадут дальше.
Порядок здесь обратный привычному: сначала документы, потом автоматизация. Наведение порядка в базе знаний скучное и не выглядит как проект внедрения, но без него остальное не имеет смысла.
Взяли слишком большой процесс сразу
Автоматизировать всю воронку продаж целиком, а не одну задачу в ней. Проект растягивается на месяцы, за это время меняются процессы и люди, а первый видимый результат появляется тогда, когда терпение уже кончилось. Правильный размер первого шага - задача, результат которой виден на второй неделе.
Результат никто не проверяет
Проверка стоит дороже самой работы
Это главная причина, по которой закрывают уже работающие системы. Ассистент отвечает, но чтобы убедиться в правильности ответа, человек открывает те же документы и читает их сам. Экономии нет, зато есть лишний шаг.
Лечится это ссылкой на источник в каждом ответе: сотрудник видит, откуда взята информация, и проверка занимает секунды вместо минут. Если подрядчик не сделал этого сразу, спросите почему.
Мерят активность вместо исхода
В отчёте: три тысячи обработанных обращений за месяц. В реальности неизвестно, сколько из них решены и сколько ушло к человеку следом. Активность растёт всегда, потому что систему используют. Исход может не измениться вовсе.
Мерить надо то, ради чего затевалось: доля обращений, закрытых без человека; время от поступления до ответа; число ошибок, которые пришлось исправлять. Метрика выбирается до начала работ, а не подбирается под результат в конце.
Интеграция выглядит рабочей, но не работает
Ответ «принято» принимают за выполненное действие
Сервер отвечает, что запрос получен, статус подключения зелёный, а карточка в системе не изменилась: сработало правило автоматизации, поле оказалось обязательным, у пользователя не хватило прав. Система считает задачу выполненной и идёт дальше.
Лечится обратной проверкой: после действия состояние перечитывается и сверяется с ожидаемым. Не сошлось - несколько попыток, потом очередь к человеку. Это скучная и дорогая часть работы, поэтому её чаще всего и не делают.
Зелёный статус скрывал провал неделями
Продолжение предыдущего. Никто не смотрит в систему, потому что индикатор зелёный и ошибок нет. Обнаруживается всё через несколько недель, когда кто-то вручную открывает карточки и видит, что половина заявок никуда не записалась.
Признак здоровой системы - не отсутствие ошибок, а наличие очереди, куда они попадают, и человека, который её читает.
Демо проходит, продакшен падает
Демо собирали на подготовленных данных с простыми параметрами. Реальный поток приносит сканы, опечатки в названиях компаний, документы на сорок страниц и письма на смеси двух языков. Цепочка, безупречно отработавшая тридцать раз на подготовленном наборе, падает на первой неделе.
Разбор того, как выбрать подрядчика, начинается ровно с этого вопроса: попросите показать процесс на ваших данных.
Эксплуатацию не спроектировали
Не определили, что такое «сделано»
В договоре написано «внедрение ИИ-ассистента». Через два месяца выясняется, что заказчик ждал автоматических ответов клиентам, а исполнитель сделал подсказки для менеджера. Оба формально правы.
Критерий приёмки должен быть измеримым и записанным: система обрабатывает столько-то обращений в день с такой-то долей ручной проверки. Как это формулируется, разобрано в материале про техническое задание.
База знаний деградирует
Документы устаревают, регламенты меняются, а ассистент продолжает отвечать по прошлогодней инструкции. Формально всё работает: ошибок нет, ответы выдаются. Фактически система вводит людей в заблуждение, и это опаснее, чем если бы она молчала.
Нужен человек, который отвечает за актуальность базы. Не отдел, не «служба поддержки», а конкретный человек с именем и выделенным на это временем.
Стоимость постройки упала, стоимость плохой эксплуатации не изменилась
Собрать прототип сегодня можно за вечер, и это создаёт ощущение, что весь проект такой же дешёвый. Но цена ошибки в работающей системе не зависит от того, сколько стоила её сборка. Неверно закрытая сделка, отправленное не тому клиенту письмо и потерянная заявка стоят столько же, сколько стоили всегда.
Разбор того, из чего складываются расходы после запуска, лежит отдельно.
Люди, а не техника
Отдельная группа причин, которая техническими средствами не лечится.
Систему внедрили как надзор. Первым проектом взяли расшифровку звонков ради оценки работы менеджеров. Сопротивление в этом случае гарантировано, и оно окажется сильнее любой технологии. Начинать надо с задач, которые сотрудники сами не любят: заполнение карточек, поиск забытых сделок, сбор документов по шаблону.
Никого не спросили. Процесс описал руководитель, а работают по нему другие люди, у которых есть свои обходные пути и причины ими пользоваться. Система, собранная по описанию «сверху», расходится с реальностью в первую же неделю.
Не назначили владельца. У системы нет человека, который отвечает за неё после запуска. Через месяц накапливается очередь исключений, которую никто не разбирает, а через полгода систему тихо перестают открывать.
Признаки на этапе переговоров
| Что говорит подрядчик | Что это значит |
|---|---|
| «Точность 100%, гарантируем» | С реальными данными не работал либо рассчитывает, что вы не проверите |
| «Такого не бывает» про падение шага цепочки | Обработку отказов не проектировали |
| «Мы всё логируем» без ответа, кто читает логи | Очередь исключений останется без хозяина |
| «Практически всё будет автоматизировано» | Процесс не смотрели: ручная часть остаётся всегда |
| «Стоимость эксплуатации зависит от нагрузки», без цифр | Либо не считали, либо считали и не хотят называть |
| «Мы предоставим доступ к нашей платформе» | Вы покупаете аренду, а не систему |
Как выглядит проект, который доходит до результата
Задача одна и повторяется каждый день. Метрика выбрана до начала. Данные посмотрели глазами до оценки сроков. Первый месяц каждое действие подтверждает человек, и по накопленной статистике решают, где подтверждение снимать. Отказы уходят в очередь, у очереди есть хозяин. Исходники, ключи и документация оформлены на компанию с первого дня. Расходы эксплуатации посчитаны до подписания договора.
Ни один пункт не про модели. Все семь про то, как устроена работа вокруг них.
Частые вопросы
Как понять до старта, что проект не взлетит?
По ответам подрядчика на три вопроса. Что произойдёт, когда упадёт второй шаг цепочки. Как вы докажете, что действие реально выполнилось, а не вернуло «принято». Что останется ручным после внедрения. Уверенные конкретные ответы на все три означают, что человек уже сталкивался с эксплуатацией. Ответ «такого не бывает» на первый вопрос - достаточное основание закончить разговор. Плюс к этому проверьте себя: есть ли у вас метрика, по которой через месяц будет видно, изменилось что-нибудь или нет.
Мы уже потратили деньги, система не работает. Что делать?
Сначала понять, на каком из четырёх пунктов сломалось: неверная задача, отсутствие проверки, мнимая интеграция или неспроектированная эксплуатация. Обычно это видно за час разговора с теми, кто пользовался системой. Дальше решение зависит от диагноза: иногда достаточно добавить ссылку на источник в ответы и назначить владельца, иногда правильнее закрыть тему и вернуться через полгода с другой задачей. Начинать заново с тем же подрядчиком и тем же процессом смысла нет.
Виноват подрядчик или мы сами?
Чаще всего обе стороны понемногу, и это не отговорка, а следствие устройства таких проектов. Подрядчик отвечает за то, что не спросил про исключения, не проверил данные и не спроектировал отказы. Заказчик - за то, что описал процесс так, как он выглядит в регламенте, не назначил владельца системы и не выделил человека на разбор очереди. Практическая польза от разделения одна: понять, что менять в следующей попытке. Если менять только подрядчика, вторая попытка сломается там же, где первая.
Можно ли проверить работу ИИ, не разбираясь в технологиях?
Можно, и технические знания для этого не нужны. Возьмите двадцать реальных случаев за прошлую неделю, прогоните через систему и сверьте ответы с тем, что сделал бы человек. Отдельно посчитайте, сколько времени занимает проверка одного ответа: если больше, чем сделать работу самому, система бесполезна независимо от её точности. И третье - откройте несколько записей в рабочей системе руками и посмотрите, действительно ли там появилось то, что должно было.
Сколько времени нужно, чтобы понять, работает ли внедрение?
Правильно устроенный проект даёт первый ответ через две-четыре недели: столько занимает пилот на одной задаче с замерами качества и расхода. Если через месяц после старта нет ни одной измеренной цифры, а есть только обещания, это и есть сигнал. Проект, где первый видимый результат отодвинут на полгода, чаще всего не доживает до него по причинам, не связанным с технологией.
С чего начать, если предыдущая попытка не сработала
С разбора того, что произошло. Тридцать минут по видео: смотрим, какую задачу брали, что мерили и на чём сломалось. По итогам обычно понятно, стоит ли пробовать снова и с чего.
Написать можно в Telegram или на почту hi@za-ai.ru.