ИИ-проекты чаще всего останавливаются не потому, что технология не сработала, а потому, что проверяли не то. Демонстрация показывает, что модель умеет решать задачу на подобранных примерах. Эксплуатация проверяет другое: выдержит ли решение поток, кто чинит ошибки, откуда берутся актуальные документы и найдётся ли внутри компании человек, для которого работоспособность системы через полгода — его личная задача. Между этими двумя проверками и лежит разрыв, из которого берётся ощущение, что ИИ не оправдал ожиданий.
Разочарование при этом почти никогда не объявляется вслух. Проект не закрывают — его продлевают ещё на месяц, потом переводят в «фоновый режим», потом руководитель проекта уходит и папка остаётся в общем диске. Через полгода на вопрос «что там с нашим ИИ» отвечают, что решение работает в тестовом контуре и вот-вот будет запущено. Это и есть типичная форма остановки, и она дороже честного закрытия, потому что расходы продолжаются.
Ниже — семь причин, по каждой из которых есть признак, видимый до подписания договора; разбор того, почему второй месяц эксплуатации опаснее первого; модельный расчёт стоимости вечного пилота; чек-лист из десяти пунктов на старте и три условия, при которых проект честно не стоит начинать. Общие причины провалов автоматизации — неописанный процесс, отсутствие начального замера, автоматизация хаоса — разобраны у нас в отдельном материале журнала; здесь только то, что специфично для ИИ.
Сначала о цифрах: что мы знаем и чего не знаем
В материалах про ИИ принято начинать с процента провалившихся проектов. Мы этого делать не будем, и вот почему. Сводной российской статистики по доле ИИ-внедрений, дошедших до промышленной эксплуатации, по состоянию на сентябрь 2026 года не существует: нет ни отраслевого реестра проектов, ни общепринятого определения того, что считать дошедшим до эксплуатации, ни независимого сбора данных. Цифры, которые ходят по презентациям, — это либо зарубежные исследования на других рынках и с другими определениями, либо опросы с самоотбором участников, либо пересказ пересказа без первоисточника.
Что мы можем сказать честно: в публичных отраслевых наблюдениях на сентябрь 2026 устойчиво повторяется одно и то же утверждение — значительная часть ИИ-проектов останавливается между пилотом и эксплуатацией, при том что сами пилоты в большинстве случаев признаются успешными. Это наблюдение, а не измерение. Наш собственный материал ниже опирается на разбор проектов, которые мы вели или принимали после других подрядчиков, и на модельные расчёты с открытой арифметикой. Там, где вы увидите проценты, они относятся либо к конкретному модельному примеру, либо к диапазону, который мы наблюдали, — и это будет сказано прямо.
Если подрядчик обосновывает предложение цифрой вроде «80% проектов проваливаются, а у нас нет» — попросите первоисточник: кто считал, на какой выборке, что считалось провалом. В девяти случаях из десяти источника не окажется. Это не повод отказываться от работы, но хороший ранний индикатор того, как в проекте будут обращаться с метриками качества.
Почему демонстрация проходит, а эксплуатация — нет
Демонстрация и эксплуатация отличаются не масштабом, а видом проверки. На демонстрации задают вопросы, для которых заранее известно, что ответ в системе есть. В эксплуатации вопросы приходят от людей, которые не знают ни структуры вашей базы знаний, ни принятых у вас формулировок, и часть из них задаёт то, чего в документах нет вообще. Разница видна в таблице.
| Параметр | Демонстрация | Эксплуатация | Что ломается на переходе |
|---|---|---|---|
| Число разных формулировок | 10–30 подобранных вопросов | сотни новых формулировок в первый же месяц | поиск перестаёт находить документ, который есть в базе |
| Качество входа | чистые вопросы, набранные подрядчиком | опечатки, голосовые расшифровки, скриншоты, обрывки фраз | падает точность классификации и извлечения полей |
| Полнота базы знаний | документы под показанные сценарии | вопросы про частные случаи, исключения и старые договоры | растёт доля честных отказов, а с ней — раздражение клиентов |
| Кто рядом | инженер подрядчика в том же чате | оператор в пятницу вечером, инженер в отпуске | нерешённые случаи копятся, вместо разбора включается обход системы |
| Цена ошибки | нулевая: это же тест | деньги, срок, клиент, иногда претензия | появляется требование «выключить, пока не разберёмся» |
| Актуальность данных | выгрузка сделана на прошлой неделе | прайс поменялся, регламент переписали, никто не загрузил | система отвечает правильно по неправильному документу |
Из таблицы следует простое требование к пилоту, которое почти никогда не ставят: пилот должен воспроизводить не задачу, а условия. Это значит поток реальных обращений за реальный период, а не выборку, отобранную подрядчиком; вход в том виде, в каком он приходит на самом деле; и хотя бы одну неделю, когда систему держат ваши люди, а не инженеры исполнителя. Пилот, который идёт две недели на подготовленных данных при постоянном присутствии подрядчика, проверяет только то, что технология в принципе существует.
Две колонки. Левая «Демонстрация»: рамка с двадцатью аккуратными одинаковыми карточками-вопросами, подпись «подобранные примеры, инженер рядом, цена ошибки ноль». Правая «Эксплуатация»: та же рамка, но карточек много, они разной высоты и формы, часть надорвана и подписана «опечатка», «голосовое», «скриншот», «вопрос не по адресу»; подпись «сотни формулировок в первый месяц, оператор один, цена ошибки — клиент». Между колонками стрелка с надписью «здесь и возникает разрыв».
Семь причин остановки и признак, по которому каждую видно заранее
Причины ниже расположены в порядке, в котором они успевают сработать: первые три убивают проект до начала работ, следующие две — во время пилота, последние две — после запуска. Признак в каждом пункте сформулирован так, чтобы его можно было проверить на первой-второй встрече, до того как подписан договор и потрачены деньги.
- 11. Нет владельца процесса на вашей стороне
Не куратора, который согласовывает счета, а человека с правом менять регламент и временем в календаре — 4–6 часов в неделю. Признак: на встречах каждый раз новые люди, а на вопрос «кто примет решение, если придётся изменить порядок обработки заявок» отвечают «надо согласовать». Что делать: назначить владельца до старта и записать его роль в договор. Эту причину мы подробно разбирали в материале про провалы автоматизации — она общая для любых проектов, не только для ИИ.
- 22. Нет критерия выхода из пилота
Самая частая и самая дорогая. Пилот без числового критерия не может закончиться: любой результат можно назвать и успехом, и поводом для доработки. Признак: в предложении написано «оценить применимость технологии» вместо «доля правильно определённых тем не ниже 90% на выборке из 500 обращений за июль». Что делать: критерий формулируется до начала работ, вместе с выборкой, на которой он будет проверяться, и с датой, после которой проект либо переходит в эксплуатацию, либо честно останавливается.
- 33. Данные не готовы, и этого никто не проверял
ИИ-проект живёт на исторических данных: размеченных примерах для классификации, актуальных документах для базы знаний, записях звонков для речевой аналитики. Признак, который стоит проверить на первой встрече: попросите выгрузить 300 обращений за прошлый квартал с проставленными темами. Если это занимает больше двух недель или выясняется, что темы ставили по-разному в разных отделах, готовности нет. Что делать: неделя-две на подготовку данных до пилота, отдельным этапом с отдельным результатом.
- 44. ИИ ставят поверх сломанного процесса
Если заявки теряются, потому что их обрабатывают в четырёх местах и никто не отвечает за просроченную, агент добавит пятое место. Признак: задайте трём сотрудникам вопрос «кто отвечает за заявку, которая висит третий день» и получите три разных ответа. Что делать: сначала свести процесс в одно место и назначить ответственного — это обычно дешевле и быстрее, чем ИИ, и без этого ИИ всё равно не даст эффекта.
- 55. Никто не считает эффект
Начальные значения не зафиксированы до старта, поэтому после запуска нечего сравнивать. Через три месяца разговор превращается в обмен ощущениями: «вроде стало быстрее» против «а мне кажется, работы прибавилось». Признак: в плане проекта нет этапа «замер до». Что делать: одна-две недели на замер до старта — сколько минут занимает операция, сколько операций в месяц, сколько ошибок и переделок. Восстановить эти числа задним числом нельзя.
- 66. Никто не отвечает за ошибки агента
Специфично для ИИ и почти никогда не проговаривается заранее. Агент ошибётся — вопрос в том, кто разбирает инцидент, за чей счёт чинится дефект и в какой срок. Признак: в договоре нет ни метрик качества, ни порядка разбора, а на вопрос об ошибках отвечают «модель обучится». Что делать: приложение к договору с метриками, жёсткий ноль на ответы без источника и срок исправления дефекта за счёт подрядчика. Что именно ловить и как это проверять, мы разбирали в материалах про контуры защиты.
- 77. Сотрудники обходят систему
Формально система запущена, фактически заявки заводят руками, потому что «так надёжнее». Признак виден ещё на демонстрации: кто-то из будущих пользователей говорит «а можно я по-старому», и это не шутка. Что делать: разбираться с причиной обхода, а не с дисциплиной — почти всегда за ним стоит реальное неудобство или реальный риск для сотрудника. Об этом отдельно ниже.
Горизонтальная линия проекта с пятью этапами: «Идея», «Подготовка», «Пилот», «Приёмка», «Эксплуатация». Под линией семь вертикальных отводов-тупиков с подписями: «нет владельца», «нет критерия выхода», «данные не готовы» (все три у этапов «Идея» и «Подготовка»), «ИИ поверх сломанного процесса», «никто не считает эффект» (у этапа «Пилот»), «никто не отвечает за ошибки» (у «Приёмки»), «сотрудники обходят систему» (у «Эксплуатации»). Долей и процентов на схеме намеренно нет.
Сопротивление сотрудников — рациональное поведение
Сопротивление принято описывать как консерватизм и лечить приказом. На разборах остановившихся проектов картина другая: почти всегда за обходом системы стоит понятный расчёт человека, у которого есть свои показатели и своя ответственность. Оператор, у которого мерят время ответа, не будет пользоваться подсказкой, если она добавляет два клика. Менеджер, чья премия зависит от закрытых сделок, не отдаст квалификацию лида системе, которая иногда ошибается: ошибётся она, а объясняться будет он. Кладовщик не станет фотографировать паллету для распознавания, если камера срабатывает с третьего раза, а норма выработки осталась прежней.
Отдельный и самый тяжёлый случай — когда бизнес-обоснование проекта построено на сокращении. Если люди слышали, что система внедряется, чтобы уменьшить численность, они будут вести себя ровно так, как рационально вести себя в этой ситуации: подчёркивать ошибки агента, не сообщать о случаях, где он сработал хорошо, и сохранять ручной контур как доказательство своей нужности. Никакое обучение это не перекрывает, потому что сопротивление здесь не иррациональное.
- Считать нагрузку, а не головы. Работающая формулировка на старте: система снимает очередь, переработки и рутину, штат не сокращается, освободившееся время уходит на то, до чего раньше не доходили руки. Если это неправда, лучше не начинать: обман вскроется на второй месяц.
- Не менять показатели людей задним числом. Если оператору добавили работу по проверке ответов агента, а норму по числу обращений оставили прежней, обход системы гарантирован.
- Взять двух-трёх будущих пользователей в пилот с правом сказать «неудобно» и увидеть результат этой правки. Пользователь, чью претензию исправили при нём, становится сторонником — и это дешевле любых внутренних коммуникаций.
- Дать понятный способ пожаловаться на конкретный ответ агента в один клик, прямо из интерфейса, и показывать, что с этими жалобами что-то происходит. Это одновременно и канал доверия, и лучший источник данных для пополнения базы знаний.
- Не требовать пользоваться системой там, где она объективно медленнее. Один честно оставленный ручной сценарий сохраняет доверие ко всем остальным.
Двухколоночная схема-весы. Левая чаша «Пользоваться системой»: строки «плюс два клика», «если агент ошибётся — объясняться мне», «норма выработки прежняя». Правая чаша «Обойти систему»: строки «привычно и быстро», «ответственность понятна», «показатели не пострадают». Весы наклонены вправо. Под весами полоса «Что меняет наклон»: «снять лишние клики», «пересчитать норму», «ответственность за ошибку агента — на системе, не на операторе».
Второй месяц — самый опасный
Первый месяц эксплуатации обычно проходит хорошо, и это создаёт ложное чувство завершённости. Работает несколько механизмов сразу: систему запускают на части потока, рядом дежурит инженер подрядчика, а сотрудники ещё внимательно смотрят на каждый ответ. На второй месяц включают полный поток, инженер уходит на следующий проект, внимание рассеивается. И тогда обнаруживается главное свойство любой системы, отвечающей на вопросы людей: поток шире тестовой выборки не на проценты, а в разы.
Ниже — модельная картина по неделям для клиентской поддержки с потоком около 1 300 обращений в месяц; конкретные числа зависят от предметной области, но форма кривой повторяется от проекта к проекту. Число разных формулировок вопроса растёт первые полтора-два месяца и только потом выходит на плато. Покрытие базы знаний, то есть доля вопросов, на которые в документах есть ответ, в это время проседает — и восстанавливается только за счёт пополнения базы, то есть за счёт чьей-то работы.
Двухосевой график на 12 недель. Левая ось — «новых формулировок вопроса за неделю», линия растёт: 40, 90, 160, 210, 240, 250, 250, 245, 240, 235, 230, 230. Правая ось — проценты, линия «покрытие базы знаний»: 85, 80, 72, 64, 58, 55, 60, 66, 71, 75, 78, 80. Область между пятой и седьмой неделями заштрихована и подписана «второй месяц: полный поток, инженер ушёл». Точка минимума 55% выделена и подписана.
Выход из этого провала стоит конкретных часов: разбор накопившихся отказов, пополнение базы знаний, правка сценариев, донастройка ограничителей. По нашим проектам это 20–40 часов, распределённых на второй и третий месяцы, — и именно этих часов чаще всего нет в бюджете, потому что смету считали до запуска, а поддержку записали строкой «по факту». Дальше события развиваются предсказуемо: денег на доработку нет, качество проседает, сотрудники возвращаются к ручной обработке, проект тихо переходит в фоновый режим.
Механику расширения потока проще увидеть на примере. На пилоте вопрос про сроки задавали в двух формах: «когда придёт заказ» и «какой срок доставки». На полном потоке за второй месяц те же по смыслу вопросы приходят десятками способов: «уже отгрузили?», «что там с моим номером 4471», «завтра успеете до обеда», «почему статус не меняется третий день», «курьер звонил, но не приехал». Часть из них вообще не про сроки, а про статус, часть — про качество работы курьерской службы, и ни один не совпадает с формулировкой в регламенте. Поиск начинает промахиваться там, где ответ в базе есть, доля отказов растёт, и внутри компании это читается как «система стала хуже», хотя система не менялась — изменился вход. Ремонт здесь не в модели, а в словаре формулировок и в разбиении документов, и делается он по журналу отказов за первый месяц.
Рыночный ориентир на сентябрь 2026 — 20 000–30 000 ₽/мес для заказного агента, и это не страховка от поломок, а бюджет на изменения: поток формулировок, прайсы и регламенты меняются постоянно. Если в предложении поддержка обозначена как «обсудим после запуска», вы получите счёт ровно в тот момент, когда денег на проекте уже не будет.
Сколько стоит вечный пилот
Расчёт ниже — модельный, на компанию из 120 человек с потоком около 1 300 обращений в месяц. Задача пилота: классификация обращений и черновики ответов. Пилот прошёл успешно, критерия выхода не было, дальше — два продления и полгода ожидания. Ставки те же, что и в остальных наших материалах: инженер 3 000 ₽/час, руководитель 2 500 ₽/час, эксперт предметной области 1 500 ₽/час, оператор 700 ₽/час.
К этому добавляется то, что в смету обычно не попадает: ручная работа, которую пилот должен был снять и не снял. 1 300 обращений в месяц по 4 минуты обработки — это около 87 часов, то есть примерно 60 000 ₽ в месяц по ставке оператора, за полгода 364 000 ₽. Итого около 1,2 млн ₽ за полгода, из которых прямых денег — 837 000 ₽. Для сравнения: рыночная вилка заказного ИИ-агента на сентябрь 2026 — 250 000–500 000 ₽ плюс поддержка, а комплексная автоматизация процессов начинается примерно от 1 500 000 ₽. То есть на вечный пилот уходит бюджет полноценного внедрения.
Практический вывод не в том, что пилоты вредны, а в том, что у пилота должен быть потолок и дата. Разумная конструкция: пилот с фиксированной ценой и сроком 4–6 недель, числовой критерий выхода, согласованный до старта, и явное право обеих сторон остановиться после пилота без штрафа. Тогда неудачный пилот стоит своих 450 000 ₽ и заканчивается решением, а не превращается в полтора миллиона и отсутствие решения.
Две накопительные колонки. Левая «Пилот с критерием выхода» — один сегмент 450 000 ₽, подпись «5 недель, решение принято». Правая «Пилот без критерия, полгода» — пять сегментов снизу вверх: 450 000 ₽ пилот, 75 000 ₽ руководитель, 120 000 ₽ эксперты, 120 000 ₽ продления, 72 000 ₽ инфраструктура, итого 837 000 ₽; сверху отдельный заштрихованный сегмент 364 000 ₽ с подписью «неснятая ручная работа». Итог справа: «около 1 200 000 ₽».
Чек-лист из десяти пунктов на старте
Список ниже не гарантирует успеха, но закрывает те причины остановки, которые вообще можно закрыть организационно. Проходить его имеет смысл до подписания договора; на всё уходит одна-две встречи и неделя на подготовку данных.
- 1Назначен владелец процесса с правом менять регламент и 4–6 часами в неделю в календаре. Не куратор бюджета, а человек, для которого работа системы — его задача.
- 2Записан числовой критерий выхода из пилота: какой показатель, на какой выборке, к какой дате. Формулировка «оценить применимость» не считается.
- 3Сделан замер до старта: сколько операций в месяц, сколько минут занимает одна, сколько ошибок и переделок. Задним числом эти числа не восстанавливаются.
- 4Проверена готовность данных: выгрузка 300 примеров за прошлый квартал сделана за два-три дня, разметка согласована между отделами.
- 5Процесс сведён в одно место и у просроченной задачи есть один ответственный. Если нет — сначала это, потом ИИ.
- 6В бюджете есть поддержка на 12 месяцев отдельной строкой и 20–40 часов на выход из провала второго месяца.
- 7В договоре есть метрики качества и порядок разбора инцидента: что чинит подрядчик за свой счёт, в какой срок, что остаётся на вашей стороне.
- 8Два-три будущих пользователя включены в пилот с правом сказать «неудобно» и увидеть исправление.
- 9Явно проговорено, что происходит с людьми: снимается нагрузка, а не должности. Если обоснование строится на сокращении — см. следующий раздел.
- 10Есть право обеих сторон остановиться после пилота без штрафа, и обе стороны это вслух проговорили.
Три условия, при которых проект честно не стоит начинать
Мы отговариваем примерно каждого четвёртого из тех, кто приходит с запросом на ИИ-агента, и почти всегда по одной из трёх причин ниже. Каждая определяется до сметы, по одной встрече и выгрузке из системы.
- Объём ниже порога окупаемости. Ориентиры, от которых мы считаем разговор осмысленным: примерно от 2 000 обращений в месяц для клиентской поддержки, от 300–500 документов в месяц для распознавания первички, от 1 500 звонков в месяц для речевой аналитики. Ниже этих значений постоянные расходы на контроль качества и ведение базы съедают экономию, и дешевле нанять человека на неполный день.
- Процесс не описан, и никто не готов его описать в ближайшие два месяца. Не «описан плохо», а именно так: правила живут в головах, у разных сотрудников разные, и назначить владельца некому. ИИ здесь не наведёт порядок — он закрепит текущий беспорядок и сделает его дороже.
- Ожидание построено на сокращении штата. Если экономическое обоснование проекта — увольнение конкретных людей, проект с высокой вероятностью остановится на сопротивлении, причём тихо и на этапе эксплуатации, когда деньги уже потрачены. Реалистичное обещание другое: снимается очередь, переработки и рутина, а высвобожденное время уходит на работу, до которой не доходили руки.
Есть и четвёртая ситуация, более редкая, но её стоит назвать: цена одной ошибки выше стоимости всей автоматизации. Медицинские рекомендации, юридические заключения, расчёт налогов, конструкторские допуски — здесь модель может готовить материал для специалиста, но не принимать решение и не разговаривать с клиентом от лица компании. Это не значит «нельзя»; это значит, что проект будет другим по составу и по цене, и начинать его надо с описания того, кто именно подписывается под результатом.
Как это записывается в договор
Большая часть перечисленного выше — не техника, а формулировки в документе, который подписывается до начала работ. Ниже — четыре пункта, которые чаще всего пишут так, что они не работают, и рабочие варианты тех же пунктов. Более подробный разбор договора на разработку у нас есть отдельным материалом; здесь — только специфика ИИ-проектов.
| Пункт | Формулировка, которая не работает | Рабочая формулировка |
|---|---|---|
| Этапность | «Работы выполняются в соответствии с техническим заданием» | Пилот с фиксированной ценой и сроком 4–6 недель, затем отдельный этап эксплуатации; право любой стороны остановиться после пилота без штрафа |
| Критерий приёмки | «Система должна корректно обрабатывать обращения» | Числовой показатель на согласованной выборке: доля правильно определённых тем не ниже указанной на 500 обращениях за указанный месяц, проверка прогоном тестового набора |
| Качество ответов | «Исполнитель обеспечивает высокое качество работы модели» | Метрики в приложении: жёсткий ноль на фактические ответы без ссылки на источник, вилки по остальным показателям, фиксация значений по итогам первого месяца эксплуатации |
| Ответственность за ошибку | Пункт отсутствует | Порядок разбора инцидента, срок исправления дефекта контура за счёт исполнителя и явный перечень случаев, которые остаются на стороне заказчика (устаревшие документы, изменения регламента) |
Отдельно про новое регулирование. С 1 сентября 2026 года в России вступают в силу требования к ИИ: маркировка ИИ-контента, требования к моделям и к обработке персональных данных. Практическое следствие для проекта — компании стоит завести внутреннюю политику использования ИИ и заранее решить два вопроса: маркируются ли ответы агента как сгенерированные и что происходит с персональными данными, попадающими в диалоги. Второй вопрос упирается в 152-ФЗ и часто определяет архитектуру: если данные нельзя выпускать за периметр, модель разворачивается в собственном контуре, и это меняет смету.
Лента времени слева направо. Этап «Подготовка данных, 1–2 нед.» — результат «выгрузка и согласованная разметка». Этап «Пилот, 4–6 нед., фиксированная цена» — результат «число на согласованной выборке». Далее развилка-ромб «Критерий достигнут?»: ветка «да» ведёт к этапам «Эксплуатация» и «Поддержка 12 мес., отдельная строка бюджета»; ветка «нет» ведёт к блоку «Остановка без штрафа, отчёт с причиной». Над этапом эксплуатации отметка «2-й месяц: 20–40 ч на выход из провала».
Если свести всё сказанное к одному предложению: ИИ-проекты не доходят до эксплуатации не из-за технологий, а из-за отсутствия решения о том, когда и на каком основании проект считается состоявшимся. Технология в 2026 году доступна и по цене, и по качеству — доступнее, чем внутренняя договорённость о критерии успеха. Поэтому самая полезная работа делается до первой строчки кода: описать процесс, назначить владельца, замерить исходное состояние и записать число, при котором пилот заканчивается.
Таблица-сравнение из двух колонок «Проект без критерия» и «Проект с критерием». Строки: «Длительность» (6+ месяцев / 8–10 недель), «Прямые расходы» (837 000 ₽ / 450 000 ₽ при остановке, дальше эксплуатация), «Чем заканчивается» (фоновый режим, папка в общем диске / решение: запускаем или останавливаемся), «Что осталось компании» (ничего / замер, размеченные данные, описанный процесс). Нижняя строка выделена.
