Почему ИИ-пилоты не доходят до эксплуатации

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

Главное — за 30–40 секунд

Критерий перехода определяется до пилота, а не после. Вопрос «сможет ли нейросеть это сделать?» нормален для первого эксперимента, но не помогает принять инвестиционное решение: нужны пороги по времени операции, доле принятых без правок результатов и стоимости обработки — раздел «Причина №1».
Пять красивых примеров не говорят о качестве системы. Нужны репрезентативная выборка с редкими сценариями, плохими входными данными и случаями, где система обязана отказаться от ответа, и заранее зафиксированный правильный результат. Средняя точность скрывает различия: 99 верных простых случаев и одна ошибка в критичном дают отличную цифру и непригодное для автоматического действия решение — раздел «Причина №2».
Прототип на ручных запусках, личных учётных записях и временном доступе к данным нормален для проверки гипотезы, но стоимость его превращения в рабочую систему часто выше ожидаемой. Иногда дешевле собрать промышленную версию заново — и это нормальный результат, если компания знала об этом заранее — раздел «Причина №3».
Абстрактный human-in-the-loop не работает. Нужно спроектировать, что именно сотрудник обязан проверять, что система ему для этого показывает и сколько времени проверка должна занимать. Иначе возникает один из двух сценариев: сотрудник доверяет ИИ и пропускает ошибку либо перепроверяет всё настолько тщательно, что экономия исчезает — раздел «Причина №4».
Экономику считают от полного цикла, а не от скорости ответа модели. В неё входят обращения к модели, инфраструктура, интеграции, наблюдение, поддержка, ручная проверка и разбор инцидентов, а главное — доля случаев, которые система действительно обрабатывает без дополнительной работы — раздел «Причина №5».

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

Это не означает, что пилот провалился. Он выполнил свою задачу: дал компании данные для решения.

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

Что такое промышленная эксплуатация ИИ

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

Слева зелёная плитка «AI-модель» с галочкой, стрелка вправо к четырём плиткам: «Интеграции и безопасность» с галочкой, «Проверка человеком» с восклицательным знаком, «Мониторинг» с восклицательным знаком, «Экономика» с крестиком; внизу подпись «Production — это больше, чем вызов модели» — Работающая модель — одна закрытая позиция из пяти. Интеграции, работа человека, мониторинг и экономика проверяются отдельно и чаще всего остаются открытыми после пилота.

Это означает, что решение:

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

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

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

Способность модели решить задачу — лишь один компонент.

Причина №1. Пилот запускали без критерия перехода к внедрению

Многие пилоты начинаются с вопроса:

«Сможет ли нейросеть это сделать?»

Для первого эксперимента вопрос нормальный. Но он не помогает принять инвестиционное решение.

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

сотрудник тратит на постобработку звонка на четыре минуты меньше;
не менее 80% резюме принимаются без существенных исправлений;
обязательные сведения находятся в 95% записей;
доля ручной проверки не превышает заданный уровень;
стоимость обработки одного звонка укладывается в экономическую модель;
качество не ухудшается на шумных записях и разных группах операторов.

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

Хороший пилот должен заранее иметь три возможных исхода:

Переходим к ограниченному внедрению.
Дорабатываем гипотезу и повторяем проверку.
Останавливаем проект.

Если допустим только первый вариант, это уже не эксперимент, а попытка обосновать принятое решение.

Hyperfast Presale / Пилот с решением

Пилот должен закончиться решением, а не презентацией

На Hyperfast Presale мы до запуска прототипа фиксируем критерии проверки и три допустимых результата: перейти к внедрению, изменить гипотезу или остановить проект. За 2–24 часа прототип проверяется на реальных примерах и измеримых показателях, поэтому итогом становится основание для решения, а не подборка удачных ответов модели.

Проверить гипотезу на Hyperfast Presale

Причина №2. Качество оценивали по впечатлению

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

Экран «Проверка на реальных данных» с четырьмя плитками документов: зелёная «Типовые случаи», оранжевая «Плохое качество», жёлтая «Неполные данные», красная «Исключения»; внизу подпись «Красивых ответов недостаточно. Нужна репрезентативная выборка» — Выборка для оценки должна повторять состав реального потока. Плохое качество, неполные сведения и исключения проверяются наравне с типовыми случаями.

Для оценки нужна выборка, которая отражает реальную работу:

типовые случаи;
редкие сценарии;
плохое качество входных данных;
неполные сведения;
разные категории пользователей;
новые форматы;
случаи, в которых система должна отказаться от ответа.

Нужно также заранее определить правильный результат. Иначе проверяющие начинают оценивать ответ по ощущению: «вроде похоже на правду». В Google Cloud такую проверку прямо называют тестированием «по ощущениям» и противопоставляют строгому подходу на данных и метриках — оценка перестаёт быть просмотром отдельных ответов и становится измерением на наборе данных.

Для разных задач потребуются разные показатели:

обработка документов — точность отдельных полей, доля необработанных случаев, количество опасных пропусков;
RAG-ассистент (система, которая отвечает, опираясь на найденные в корпоративных источниках фрагменты) — качество поиска, соответствие ответа источникам, полнота и корректность ссылок;
контакт-центр — точность расшифровки, качество классификации, время ответа, доля исправлений сотрудником.

Одна общая цифра «точность 90%» почти всегда скрывает важные различия. Модель может правильно обработать 99 простых случаев и ошибиться в одном критичном. Средняя точность будет высокой, а решение — непригодным для автоматического действия.

Причина №3. Прототип построен как одноразовая конструкция

Для пилота нормально использовать временный интерфейс, вручную загружать файлы и запускать обработку по команде разработчика. Цель прототипа — быстро проверить гипотезу, а не сразу построить идеальную архитектуру.

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

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

В модели зрелости агентного ИИ Microsoft, направление «Технологии и данные», разделение сред разработки, тестирования и эксплуатации, контроль версий, CI/CD, согласования и откат отнесены к стандарту для всех промышленных агентов, а мониторинг, журналирование и оценка качества — к тому, что встраивается в архитектуру. Начальный уровень зрелости там описан почти дословно как типовой пилот: агенты работают из личных учётных записей или тестовых тенантов, без явного владельца, жизненного цикла и пути в эксплуатацию, а экспериментальный код переносится в продуктив без управления жизненным циклом, тестирования и планов отката.

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

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

Причина №4. Не спроектирована работа человека

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

Если интерфейс не показывает источники и сомнения модели, возникает один из двух нежелательных сценариев. В первом сотрудник слишком доверяет ИИ и пропускает ошибку. Во втором перепроверяет каждый ответ настолько тщательно, что экономия исчезает.

Поэтому до внедрения нужно спроектировать не абстрактный human-in-the-loop (схему, при которой значимое решение остаётся за человеком), а конкретную работу человека:

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

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

Тот же принцип заложен в отраслевую рамку управления рисками. В ядре AI Risk Management Framework NIST предусмотрено, что организация определяет роли и ответственность в связках «человек — ИИ» и порядок надзора за системой (Govern 3.2), документирует пределы знаний системы и то, как её результат используется и контролируется человеком (Map 2.2), проверяет систему в условиях, близких к реальному применению (Measure 2.3), а в планах наблюдения после развёртывания предусматривает обжалование и отмену решения, реагирование на инциденты, восстановление и вывод системы из эксплуатации (Manage 4.1, Govern 1.7).

Причина №5. Экономику считали по лучшему сценарию

На пилоте часто сравнивают две величины:

сотрудник выполняет операцию за десять минут;
модель формирует результат за десять секунд.

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

В экономику промышленного решения также входят:

обращения к модели;
вычислительная инфраструктура;
хранение и передача данных;
интеграции;
лицензии;
наблюдение;
поддержка;
ручная проверка;
разбор инцидентов;
обновление источников и правил.

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

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

получение задачи → обработка → проверка → действие → исправление возможной ошибки.

И сравнивал бы его с текущим процессом, а не с идеальной версией будущего.

После запуска качество не остаётся постоянным

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

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

Это же констатирует NIST: в марте 2026 года центр AI Standards and Innovation выпустил отдельный отчёт «Challenges to the monitoring of deployed AI systems» (NIST AI 800-4). Авторы отмечают, что проверки до развёртывания полезны, но проводятся преимущественно в контролируемых тестовых средах, тогда как наблюдение после развёртывания необходимо, чтобы подтвердить надёжную работу системы в реальных сценариях, отследить непредвиденные результаты и увидеть неожиданные последствия её работы. Там же честно сказано, что общепринятых методик и терминологии для такого мониторинга пока нет — практика только складывается.

После внедрения нужно отслеживать как минимум:

изменение качества;
новые типы ошибок;
долю передачи человеку;
исправления пользователей;
задержки;
стоимость операций;
нарушения правил;
инциденты безопасности;
изменения бизнес-эффекта.

Если мониторинг никто не планировал и не финансировал, пилот может дойти до запуска, но не до устойчивой эксплуатации.

Переходить в эксплуатацию лучше поэтапно

Между пилотом и полным запуском полезно сделать несколько промежуточных шагов.

Пять плиток со стрелками: «Прототип» → «Контрольная выборка» → «Теневая эксплуатация» → «Ограниченный запуск» → «Масштабирование»; сверху строка «Следующий этап открывается после проверки результата», внизу подпись «Пилоты должны заканчиваться решениями: внедрить, изменить или остановить» — Каждый следующий этап открывается только после проверки результата предыдущего. Так при ухудшении качества видно, какое именно изменение его вызвало.

1. Зафиксировать контрольную выборку

Собрать репрезентативные примеры и правильные результаты. Проверить не только среднее качество, но и критичные ошибки. Эта выборка понадобится при любом изменении модели, правил или источников.

2. Провести теневую эксплуатацию

Система обрабатывает реальные задачи параллельно с сотрудниками, но её результат пока не влияет на процесс. Это позволяет увидеть качество на рабочем потоке без риска для клиента или компании.

3. Запустить ограниченный контур

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

4. Сравнить результат с исходной точкой

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

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

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

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

Что в Daturum мы называем хорошим пилотом

Хороший пилот не обязан закончиться внедрением. Он должен дать достаточно данных, чтобы принять решение.

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

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

Дальнейший путь от подтверждённой гипотезы до промышленного контура разложен по фазам в методологии AI Factory, а измеримые обязательства по качеству мы фиксируем в гарантиях с KPI и SLA.

После проверки возможны три честных результата.

Первый: качество и экономика подтверждены, можно проектировать ограниченное внедрение.

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

Третий: эффект не подтверждён, продолжать проект не стоит.

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

Пилоты должны заканчиваться решениями

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

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

Если после пилота компания не понимает, какой из трёх вариантов выбрать, значит, эксперимент проверял не тот вопрос.

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

Почему успешный пилот не всегда стоит внедрять?

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

Какие критерии перехода от пилота к внедрению нужно задать заранее?

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

Почему «точность 90%» — плохая метрика для ИИ-системы?

Потому что одна усреднённая цифра скрывает распределение ошибок. Модель может правильно обработать 99 простых случаев и ошибиться в одном критичном — средняя точность будет высокой, а автоматическое действие на её основе недопустимым. Измерять нужно по конкретным полям, типам данных и сценариям, а набор метрик зависит от задачи: для документов это точность полей и опасные пропуски, для RAG-ассистента — соответствие ответа источникам, для контакт-центра — точность расшифровки и доля исправлений.

Что такое теневая эксплуатация ИИ-системы?

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

Зачем нужен мониторинг, если система уже проверена перед запуском?

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

Hyperfast Presale

Проверьте гипотезу до инвестиций в промышленную систему

Принесите один рабочий сценарий и небольшую выборку реальных данных, чтобы проверить не только качество модели, но и критичные ошибки, роль сотрудника, требования к интеграциям и экономику полного процесса. За 2–24 часа Daturum соберёт прототип и сформирует предметную рекомендацию: переходить к внедрению, изменить границы задачи или остановить проект.