Знакомый сюжет: пилот показал отличные цифры, всем понравилось, решение приняли — а через год система так и не работает. Причём модель не сломалась и точность не упала. Просто пилот и промышленная эксплуатация оказались разными задачами, и вторую никто не планировал. Разберём семь причин, по которым это происходит, и что делать на старте.
Причина первая: пилот мерил не то
Самая частая. Пилот показывает точность модели, а бизнесу нужен эффект на процессе. Это связанные, но разные вещи: модель с точностью 95% может не давать выгоды, если процесс всё равно требует сплошной проверки, а модель с точностью 80% — окупаться, потому что она берёт на себя самый массовый и дешёвый в проверке кусок.
Что делать: формулировать критерий успеха в единицах процесса до начала пилота. Не «точность выше 90%», а «доля документов, обработанных без участия человека, выше 70% при доле ошибок ниже 1%». Такой критерий проверяем и переводится в деньги.
Причина вторая: пилот работал на чистых данных
Для пилота обычно отбирают хорошую выборку — читаемые сканы, полные записи, типичные случаи. В эксплуатации приходит всё: фотографии под углом, поля с пропусками, форматы, которых не было в обучении. Точность падает, и падает именно там, где её никто не мерил.
Что делать: просить на пилот не отобранные образцы, а обычную выборку за период — со всем мусором. Мы на диагностике настаиваем именно на этом: цифра, полученная на идеальных данных, в эксплуатации не повторится, и лучше узнать это до пилота, чем после внедрения.
Причина третья: не было плана интеграции
Пилот жил отдельным приложением, куда данные загружали руками. Для проверки гипотезы это правильно. Но в эксплуатации результат должен попадать туда, где живёт процесс: в CRM, в ERP, в MES, в систему документооборота. Эта работа сопоставима по объёму с самой моделью, а обнаруживается после пилота как неприятный сюрприз.
Практический приём: ещё на этапе пилота выясните, отдаёт ли ваша система нужные данные наружу и принимает ли результат обратно. Не «в принципе», а конкретным запросом к API в тестовом контуре. Это два дня работы, которые спасают проект от полугодового провала.
Причина четвёртая: не решили, что делать с ошибками
Модель ошибается — вопрос не в этом, а в том, что происходит дальше. Кто увидит ошибку, кто её исправит, куда попадёт исправление, как оно вернётся в обучение. Если процесс не описан, при первой же заметной ошибке система теряет доверие, и люди возвращаются к старому способу — тихо и необратимо.
Что делать: проектировать не модель, а процесс с моделью внутри. Порог уверенности, маршрут спорных случаев, интерфейс исправления, накопление исправлений для дообучения — всё это часть решения, а не дополнение к нему.
Причина пятая: не подумали о нагрузке
Пилот обрабатывал сто документов в день на одной машине. В эксплуатации их десять тысяч, и приходят они не равномерно, а пиками: конец месяца, приёмная кампания, чёрная пятница. Решение, посчитанное по средней нагрузке, ложится ровно в тот день, когда оно нужнее всего.
Что делать: считать по пику, а не по среднему, и проверять пропускную способность нагрузочным тестом до запуска. Заодно выяснится реальная стоимость инфраструктуры — она часто отличается от оценки по пилоту в разы.
Причина шестая: не было владельца
У пилота есть энтузиаст, который его продвигал. У промышленной системы должен быть владелец — человек, отвечающий за то, что она работает и приносит результат. Если после сдачи система оказывается ничьей, она деградирует не от технических причин, а от отсутствия внимания: никто не смотрит на метрики, не разбирает ошибки, не инициирует дообучение.
Что делать: назначать владельца до старта проекта, а не после сдачи. И проверять, что у него есть время на эту роль, — иначе она остаётся на бумаге.
Причина седьмая: не заложили сопровождение
Модель без присмотра деградирует. Меняются поставщики, формы документов, ассортимент, законодательство — и модель, точная в марте, к декабрю ошибается заметно чаще. Если мониторинга нет, узнают об этом из жалоб, когда доверие уже потеряно.
Что делать: включать в проект мониторинг качества и дрейфа данных с самого начала и закладывать сопровождение в бюджет — обычно 15–25% стоимости проекта в год. Проект без этой строки не дешевле, он просто отложил расход.
Что закладывать в пилот, чтобы он дошёл до прода
- Критерий успеха в единицах процесса, а не в метриках модели, согласованный до начала работ.
- Данные как в жизни: обычная выборка за период, а не отобранные образцы.
- Проверка интеграции: реальный запрос к реальной системе в тестовом контуре, а не обещание, что «API есть».
- Описанный маршрут ошибок: порог, кто проверяет, как исправляет, как исправление попадает в обучение.
- Оценка пиковой нагрузки и стоимости инфраструктуры под неё.
- Назначенный владелец с выделенным временем.
- Строка сопровождения в бюджете и мониторинг качества в составе решения.
И отдельно — возможность остановиться. Если пилот не дал нужного качества, правильное решение не «доработать», а закрыть гипотезу. Проект, в котором отрицательный результат считается провалом, обречён на то, что этот результат скроют.
Организационные причины, о которых не принято говорить
Технические причины разобрать легче, но значительная часть провалов не техническая. О них редко пишут, потому что они неудобные.
Пилот делали, чтобы отчитаться
Если задача формулировалась как «нам нужен ИИ-проект к концу года», результат предопределён: пилот сделают, покажут, отчитаются, и на этом всё закончится. Признак такой постановки — отсутствие процесса, который должен улучшиться. Спросите, чья работа изменится после внедрения; если внятного ответа нет, до эксплуатации проект не дойдёт.
Люди, чей процесс автоматизируют, узнали последними
Система, спроектированная без участия тех, кто с ней будет работать, встречает сопротивление — иногда прямое, чаще пассивное. Формально всё работает, а на практике находятся причины делать по-старому. Лечится участием этих людей в постановке задачи, а не убеждением после запуска.
Успех пилота никому не выгоден
Неприятная, но реальная ситуация: если автоматизация сокращает значимость подразделения, его руководитель не будет её продвигать. Это не саботаж, а нормальная реакция. Учитывать её надо на этапе выбора процесса, а не удивляться потом.
Бюджет был только на пилот
Классика: деньги нашли на эксперимент, а на внедрение планировать забыли. Пилот заканчивается успехом, а дальше начинается новый бюджетный цикл, и импульс теряется. Оценку полной стоимости внедрения стоит делать до пилота, даже если она приблизительная.
Как выглядит пилот, который дойдёт до прода
Соберём признаки вместе. Хороший пилот отличается от плохого не технологиями, а тем, что в нём заранее описано.
- Назван процесс и подразделение, чья работа изменится, и эти люди участвовали в постановке задачи.
- Критерий успеха сформулирован в единицах процесса и согласован письменно до начала работ.
- Данные для проверки — обычная выборка за период, а не отобранные образцы.
- Проверена техническая возможность интеграции: реальный запрос к реальной системе, а не обещание.
- Описан маршрут ошибок и спорных случаев: порог, кто проверяет, как исправляет.
- Оценена пиковая нагрузка и стоимость инфраструктуры под неё.
- Назначен владелец с выделенным временем и посчитана полная стоимость внедрения, а не только пилота.
- Заранее определено, что считается отрицательным результатом и что происходит в этом случае.
Последний пункт важнее, чем кажется. Пилот, у которого нет права закончиться словом «нет», превращается в самоисполняющееся пророчество: цифры подгонят, критерий смягчат, а проблема всплывёт в эксплуатации.
Что делать, если пилот уже провалился
Провалившийся пилот — не приговор направлению, если разобрать причину честно. Полезно ответить на три вопроса.
- Не сработала технология или не сработала постановка? Если модель дала нужную точность, но система не прижилась, проблема не в ИИ, и следующая попытка с другим подрядчиком закончится так же.
- Проверяли на реальных данных или на удобных? Если на удобных, вы ещё не знаете, решается задача или нет, — это не отрицательный результат, а отсутствие результата.
- Был ли у проекта владелец? Если нет, начинать надо с этого, а не с выбора технологии.
Отрицательный результат, полученный честно и быстро, стоит своих денег: он закрывает гипотезу и высвобождает бюджет на ту, которая сработает. Дорого обходится не провалившийся пилот, а провалившийся молча и повторённый через год в том же виде.
Как построить договор, чтобы риск был разделён
Значительная часть провалов закладывается не в разработке, а в том, как оформлены отношения с подрядчиком. Несколько положений, которые стоит обсудить до подписания.
- Этапность с точками выхода. Диагностика, прототип, пилот, внедрение — каждый со своей фиксированной ценой и правом не продолжать. Договор, где всё одним куском, лишает вас возможности остановиться на отрицательном результате.
- Критерий приёмки этапа в единицах процесса, зафиксированный письменно до начала работ. Формулировка «решение работает корректно» приведёт к спору, а не к приёмке.
- Данные для проверки согласованы заранее: какая выборка, кто её формирует, за какой период. Иначе на приёмке появится соблазн подобрать удобные примеры.
- Принадлежность результата: код, веса модели, документация и воспроизводимый процесс обучения остаются у вас. Это принципиально: решение, от которого зависит процесс, не должно зависеть от продолжения отношений.
- Сопровождение как отдельный предмет со своей ценой и составом работ, а не как обещание помочь.
Отдельно стоит обсудить, что считается отрицательным результатом и как он оплачивается. Здоровая конструкция: этап проверки гипотезы оплачивается независимо от исхода, потому что вы покупаете знание, а не гарантию успеха. Подрядчик, готовый работать только за положительный результат, либо заложит риск в цену, либо будет подгонять цифры — оба варианта хуже.
Правильный размер первого проекта
Отдельная причина провалов, которую стоит вынести отдельно: неверно выбранный масштаб первого шага. Ошибаются в обе стороны, и обе дорого стоят.
Слишком крупный первый проект тонет в согласованиях и интеграциях раньше, чем покажет результат. Пока команда подключается к пяти системам и согласует доступы, интерес угасает, бюджетный цикл заканчивается, а показать нечего. Признак такой постановки — фраза «давайте сразу сделаем нормально, а не игрушку».
Слишком мелкий проект показывает результат, но не убеждает. Демонстрация на десяти документах впечатляет ровно до вопроса «а на нашем потоке это сработает». Ответа нет, потому что поток не проверяли, и решение откладывается до следующего раза.
Разумный размер выглядит так: один процесс, одно подразделение, реальные данные за период, измеримая цифра на выходе. Достаточно мал, чтобы уложиться в недели, и достаточно реален, чтобы полученной цифре можно было верить и переносить её на масштаб.
Хороший вопрос для проверки масштаба на старте: сможем ли мы через шесть недель назвать конкретное число, которое изменилось, и объяснить, откуда оно взялось. Если ответ отрицательный, проект надо либо сужать, либо переформулировать — независимо от того, насколько интересна технология.
Коротко
- Пилот проверяет гипотезу, эксплуатация решает другую задачу — переход между ними надо планировать заранее.
- Точность модели и эффект на процессе — разные вещи; критерий успеха формулируется в единицах процесса.
- Чистые данные на пилоте — главный источник несбывшихся ожиданий.
- Интеграция, маршрут ошибок и нагрузка сопоставимы по объёму с самой моделью.
- У системы должен быть владелец и строка сопровождения в бюджете, иначе она тихо деградирует.