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

18 августа 2026 · 7 мин чтения

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

Чем пилот отличается от демо, и почему это вопрос денег

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

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

Ошибка 1. Успех меряют впечатлением, а не метрикой

Самый частый сценарий: пилот запускают, чтобы «посмотреть, как ИИ справится». Через месяц у команды есть ощущения, у руководителя скриншоты, а решения нет, потому что сравнивать не с чем. Никто не зафиксировал, сколько процесс стоил до пилота: сколько минут занимает одна заявка, сколько заявок в день, какая доля уходит в брак.

Работает только одна последовательность: сначала неделя замера базовой линии, потом пилот. Метрика должна быть согласована до старта и сформулирована проверяемо: «время ответа на претензию с 4 часов до 30 минут», «разбор входящей почты с 40 минут в день до 5». Если метрику невозможно назвать одним предложением, пилот превратится в демо, просто дорогое.

Ошибка 2. Пилот живёт на чужой выгрузке, а не на первоисточнике

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

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

Ошибка 3. Право и персональные данные вспоминают после сборки

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

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

Ошибка 4. Агента выпускают в живой канал без приёмки

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

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

Ошибка 5. У пилота нет владельца со стороны процесса

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

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

Владелец процесса — это не «куратор от дирекции», а человек, который сам живёт в этом процессе и тратит на пилот 15 минут в день. Если такого человека не нашлось, процесс, скорее всего, не болит, и автоматизировать его рано.

Чек-лист стоп-сигналов до старта

Каждый пункт «нет» — это не запрет, а работа, которую надо сделать до пилота, иначе она всплывёт посреди него.

1. Метрика успеха сформулирована одним предложением и согласована с тем, кто платит.
2. Базовая линия замерена: известно, сколько процесс стоит сейчас в часах и деньгах.
3. Данные подключаются из первоисточника, или в пилоте есть автоматическая сверка с ним.
4. Список данных проверен на персональные данные, ответ на вопрос «где сервер» известен.
5. Всё, что уходит клиентам, проходит через подтверждение человеком.
6. Назначен владелец процесса, у него есть 15 минут в день на разбор результатов.
7. У пилота есть дата решения и заранее записанные условия «продолжаем» и «останавливаем».
8. Скоуп влезает в одно предложение без союза «и ещё».

Читайте также: Сколько стоит внедрение ИИ в бизнес: из чего складывается цена и С чего начинать автоматизацию бизнес-процессов

Как довести пилот до боевой работы

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

Пилот, прошедший этот путь, не «понравился на демо». У него есть цифра до, цифра после и накопленная статистика качества. Решение о полном внедрении из решимости превращается в арифметику, а это и был смысл пилота. Что происходит дальше, после снятия гейта, мы разобрали в статье про задачи, которые ИИ-агенты уже закрывают в работе.

Частые вопросы