ИИ-пилот не доходит до продуктива, когда в нём не заложено то, без чего система не живёт в эксплуатации: критерий успеха, владелец, боевые данные, интеграция с рабочими системами, порядок обработки ошибок, безопасность, мониторинг качества, посчитанная экономика, пользователи и передача исходников. Всё это можно заметить на старте, пока исправление стоит недель, а не квартала.
В статье десять таких причин. У каждой есть ранний признак (по чему видно, что проект идёт не туда) и вопрос на старте. Статистики о «проценте провалившихся проектов» здесь нет: у нас нет источника, которому можно доверять, и она не помогает решать конкретную задачу. Есть инженерный разбор: что ломается и как это проверить заранее.
Пилот и продуктив: чем они отличаются на самом деле
Пилот отвечает на вопрос «работает ли это вообще». Продуктив отвечает на другой: «работает ли это каждый день, на любых данных, при любом сбое, без нашего присмотра и за приемлемые деньги». Это разные задачи, и вторая сложнее первой не потому, что модель в ней другая, а потому что вокруг модели появляется всё остальное.
- данные: не выбранные вручную примеры, а поток с опечатками, пропусками и форматами, которых никто не ждал;
- системы: не загрузка файла, а работа с боевыми учётными и рабочими системами и их ограничениями;
- ошибки: не «в среднем неплохо», а определённое поведение на каждый тип ошибки;
- люди: не группа энтузиастов, а сотрудники, которым работа с системой навязана задачей;
- ответственность: кто отвечает за систему в три часа дня во вторник через год.
Если пилот этих вещей не затрагивает, он ничего не доказывает про продуктив. Он доказывает только, что демонстрацию можно показать. Как устроен весь путь от пилота к эксплуатации, описано на странице вывода пилота в продуктив и в материале про внедрение ИИ на предприятии.
Десять причин в одной таблице: признак и вопрос на старте
Таблица для быстрой проверки собственного проекта. Если на вопрос из третьего столбца ответа нет, значит, причина уже заложена в проект.
| Причина | Ранний признак | Вопрос на старте |
|---|---|---|
| 1. Нет измеримого критерия успеха | Успех описывают словами «станет удобнее», «ответы стали лучше» | Какое число и на каком наборе задач будет означать «принято»? |
| 2. Нет владельца на стороне заказчика | Решения по пилоту ждут согласований у людей, которым он не нужен | Кто принимает решение и кто отвечает за систему после запуска? |
| 3. Пилот на чистых данных | Примеры для пилота выбирали и чистили вручную | Откуда данные придут в эксплуатации и кто их готовит? |
| 4. Нет интеграции с боевыми системами | Результат пилота копируют руками в рабочую систему | Какие системы читает и пишет ИИ и какие права для этого нужны? |
| 5. Не определён порядок ошибок и исключений | На вопрос «что если ответ неверный» отвечают «такого не будет» | Что система делает, когда не уверена или ошиблась, и кто это видит? |
| 6. Безопасность вспомнили в конце | Служба безопасности впервые видит проект перед запуском | Какие данные уйдут в модель, где она работает и кто это согласовал? |
| 7. Нет мониторинга качества | Качество проверяли один раз, на демонстрации | Как через три месяца мы узнаем, что качество упало? |
| 8. Экономика не посчитана на объёме | Стоимость и срок известны для десятка примеров, а не для потока | Сколько стоит обработка в день на реальном объёме и что окупается? |
| 9. Нет людей, которые будут пользоваться | Пользователей на пилоте набрали из энтузиастов | Кто будет работать с системой, и что изменится в их задачах и ответственности? |
| 10. Подрядчик ушёл, исходников нет | Код и настройки лежат у исполнителя; документации нет | Где исходники, доступы и инструкция по развёртыванию и можно ли передать другому? |
Причины 1 и 2: нет критерия успеха и нет владельца
1. Нет измеримого критерия успеха
Пилот закончился, все согласны, что «в целом неплохо», и никто не может сказать, принят он или нет. Пока нет письменного критерия, любые цифры можно толковать как угодно, и решение о бюджете откладывается. Критерий не обязан быть сложным: набор типовых задач с ожидаемыми ответами, правила оценки и порог, при котором система принимается. Его записывают до начала работ, а не после.
Что сделать до старта. Собрать эталонный набор задач, договориться, кто и как оценивает ответ, и записать порог. Если для вашей задачи точность не единственная метрика, добавьте скорость, долю случаев с передачей человеку и стоимость обработки.
2. Нет владельца на стороне заказчика
У подрядчика есть руководитель проекта, у заказчика — «ответственный по ИТ» или несколько людей, никто из которых не отвечает за результат. Вопросы по данным, доступам и приёмке ждут ответа неделями, а после пилота система остаётся «ничья»: её никто не принимает и не развивает.
Что сделать до старта. Назначить владельца с правом принимать решения и отвечать за результат: тот, кому система нужна для работы, а не только для отчёта. Записать, кто принимает пилот и кто остаётся её владельцем в эксплуатации.
Причины 3 и 4: чистые данные на пилоте и нет интеграции с боевыми системами
3. Пилот на чистых данных, а жизнь на грязных
Для пилота выбирают примеры, где всё хорошо: читаемые сканы, полные записи, аккуратные формулировки. В эксплуатации приходят документы с пятнами, письма без темы, номенклатура с дублями и пропусками. Система, которая отлично работала на подготовленных данных, на живых показывает другое качество, и это выясняется уже после того, как о ней доложили руководству.
Что сделать до старта. Взять для пилота случайную выборку из боевого потока, включая плохие случаи, и заранее выяснить, кто готовит данные в эксплуатации. Как проверить данные до старта, разобрано в материале про подготовку данных для ИИ-пилота.
4. Нет интеграции с боевыми системами
Пилот выдаёт результат в окне или файле, а человек переносит его в рабочую систему руками. Выглядит как автоматизация, но экономии нет: перенос съедает выигрыш, а при росте потока становится узким местом. Интеграция при этом приносит собственные вопросы: права доступа, лимиты, формат данных, что делать при сбое чужой системы.
Что сделать до старта. Составить список систем, которые ИИ читает и в которые пишет, с правами для каждой, и включить хотя бы одну боевую интеграцию в пилот. Про обмен с учётными системами и типовые проблемы — на странице интеграций и сопровождения.
Причины 5 и 6: порядок обработки ошибок и безопасность
5. Не определён порядок обработки ошибок и исключений
Языковая модель отвечает с одинаково уверенной интонацией, и когда права, и когда ошибается. Если на этот случай нет правила, ошибка уходит дальше: в документ, в письмо клиенту, в учётную систему. Нужно решить заранее, что система делает при низкой уверенности (передаёт человеку), при неизвестном типе входа (отклоняет с понятной причиной) и при сбое смежной системы (откладывает и повторяет).
Что сделать до старта. Описать три-четыре типа ошибок и реакцию на каждый, определить, кто разбирает очередь исключений и в какой срок, и настроить порог уверенности (про него — в материале про порог уверенности модели). Если ИИ совершает действия в системах, нужны ещё права и подтверждение действий (как ограничить ИИ-агента).
6. Безопасность и контур вспомнили в конце
Пилот собирают на удобном облачном сервисе или на ноутбуке разработчика, а перед запуском выясняется, что документы с персональными данными (152-ФЗ) или конфиденциальные данные за периметр уйти не могут, а если система окажется в контуре значимого объекта КИИ (187-ФЗ), добавляются ещё требования. Пилот приходится переделывать почти целиком.
Что сделать до старта. Привлечь службу безопасности в первую неделю: какие данные пойдут в систему, где она будет работать, какие требования применимы. Если нужны частные модели в вашем контуре, то это решается на этапе выбора архитектуры; подробности — в материале о требованиях КИИ к ИИ. Мы не проводим лицензируемые работы и аттестацию, и об этом говорим сразу.
Причины 7 и 8: мониторинг качества и экономика на объёме
7. Нет мониторинга качества
Качество замерили один раз, в конце пилота. Через три месяца меняются документы, формулировки, поставщик данных или версия модели, и качество медленно падает. Пользователи замечают это первыми и перестают системе доверять, а команда узнаёт об этом из жалоб.
Что сделать до старта. Определить, что измеряется регулярно: доля ответов, принятых человеком без правки, число передач человеку, время обработки, контрольная выборка с эталонными ответами. Назначить того, кто смотрит на эти показатели, и порог, при котором включается разбор.
8. Экономика не посчитана на объёме
Для десятка примеров всё работало быстро и недорого. На потоке в день обнаруживается, что для нужной скорости нужно больше оборудования, что часть случаев всё равно проверяет человек, и что общая стоимость не покрывает экономию. Пилот не показывает этого, пока в нём не заложена нагрузка, близкая к реальной.
Что сделать до старта. Оценить объём в день и в пике, стоимость обработки одного случая (оборудование, лицензии, время проверяющих) и сравнить с тем, что делается сейчас. Схема расчёта разобрана в материале про окупаемость внедрения ИИ. Если окупаемость не сходится на бумаге, пилот не спасёт.
Причины 9 и 10: нет пользователей и нет исходников
9. Нет людей, которые будут пользоваться
Пилот делали для сотрудников, которые не просили систему и не видят, как она меняет их работу. Они проверяют её на недостатки, а не на пользу, либо обходят: делают как раньше. Если система создаёт у человека впечатление, что его контролируют или заменяют, она не приживётся, сколько бы раз её ни показывали.
Что сделать до старта. Включить будущих пользователей в пилот с первой недели, понять, что у них сейчас занимает время и что они не готовы отдавать машине, и обучить. Что работает при обучении, описано в материале про обучение сотрудников работе с ИИ.
10. Подрядчик ушёл, а исходников нет
Пилот закончен, договор закрыт, а код, настройки, промпты и инструкции лежат у исполнителя. Чтобы доработать систему или передать её другому подрядчику, приходится договариваться заново. Иногда они не передаются вовсе, и проект начинается с нуля.
Что сделать до старта. Записать в договор: исходный код в вашем репозитории с первого коммита, доступы у вас, документация в объёме, достаточном для передачи другому подрядчику, инструкция по развёртыванию. У нас это входит всегда (тарифы), и мы предлагаем проверять это у любого исполнителя.
Критерии продуктива: что записать до пилота
Эти критерии отделяют «понравилось» от «принято в эксплуатацию». Их записывают до пилота, подписывают обе стороны, и они не меняются по ходу работ без письменного согласования.
| Критерий | Что записать | Как проверяется |
|---|---|---|
| Качество | Эталонный набор задач с ожидаемыми ответами и порог принятия | Прогон набора по протоколу; результат фиксируется в документе |
| Данные | Источники, формат, кто готовит и как часто | Случайная выборка боевого потока, включая плохие случаи |
| Интеграция | Системы, права, форматы, поведение при сбое | Сквозной сценарий в боевом контуре, повтор и обрыв связи |
| Ошибки и исключения | Типы, реакция, очередь, ответственный, срок разбора | Намеренные сбои: неверный вход, низкая уверенность, недоступность системы |
| Безопасность | Какие данные, где обработка, кто согласовал | Согласование службы безопасности в письменном виде до запуска |
| Мониторинг | Показатели, порог, ответственный, оповещение | Показатели доступны с первого дня эксплуатации, а не «потом» |
| Экономика | Объём в день и в пике, стоимость случая, что заменяется | Расчёт на объёме, близком к реальному, подписанный владельцем |
| Пользователи | Кто работает, что меняется, как обучены | Работа реальных пользователей на пилоте и разбор их обращений |
| Передача | Исходники, доступы, инструкция, документация | Развёртывание с нуля по инструкции без участия исполнителя |
Чек-лист перед стартом пилота
Если на пункт нет ответа, пилот не стартует: дешевле закрыть вопрос сейчас.
- Записан критерий приёмки: набор задач, порог, способ оценки.
- Назначен владелец на стороне заказчика с правом решения.
- Для пилота взята случайная выборка боевого потока, а не отобранные примеры.
- Определены системы, с которыми ИИ работает, и права на них.
- Описаны типы ошибок и реакция на каждый; названа очередь исключений и её владелец.
- Служба безопасности знает о проекте, данные и место обработки согласованы.
- Определены показатели качества для эксплуатации и тот, кто за ними следит.
- Посчитана стоимость обработки на объёме в день и в пике.
- Будущие пользователи участвуют в пилоте с первой недели.
- Исходники, доступы и документация записаны в договор как передаваемые.
Что делать, если пилот уже застрял
Если пилот работает «в демонстрационном режиме» уже месяцы, нужно не добавлять функций, а выяснить, к какой причине из десяти он относится. Порядок действий.
- Пройти по таблице выше и честно ответить на десять вопросов. Отметить, какие причины подтверждаются.
- Построить мерило, если его нет: эталонный набор задач и правила оценки. Пока качество не измеряется, любое изменение остаётся вопросом вкуса.
- Разобрать ошибки по корзинам: данные, промпты и модель, процесс вокруг системы. Каждая стоит своих денег и срока.
- Определить владельца и согласовать с безопасностью то, что можно вывести в продуктив.
- Решить: доработать до продуктива, ограничить область или остановить. Остановка с протоколом — тоже результат, о том, как её принимать, написано в материале о том, когда останавливать пилот.
Подробно о диагностике, доработке и эксплуатации застрявшего пилота — на странице вывода ИИ-пилота в продуктив. Типовой разбор такой ситуации — в материале ИИ-пилот, который не выходит из демонстрации.
Что делаем мы и с чего начать
Мы не берёмся внедрять систему целиком, а делаем один участок или контур по ступеням, и право остановиться есть после каждой. Полная лестница расписана на странице тарифов.
- Обследование: 200 000 ₽ и 2–3 недели за один-два процесса; 350 000 ₽ и 3–4 недели, если систем несколько. Результат: критерии приёмки, требования, план по этапам и вилка бюджета; сумма вычитается из следующего этапа.
- Пилот: лёгкий — 150 000 – 400 000 ₽ и 2–8 недель, тяжёлый (с действиями в системах и интеграцией контура) — 400 000 – 1 200 000 ₽ и 2–3 месяца.
- Вывод в продуктив: от 1 500 000 ₽ этапами по 300 000 – 700 000 ₽, от 3 месяцев; у каждого этапа своя приёмка.
- Сопровождение: 20 000, 60 000 или 120 000 ₽ в месяц; сверх пакета — 5 000 ₽ в час.
Исходный код, доступы и документация остаются у вас, работаем в вашем контуре. Мы не обещаем, что пилот пройдёт: задача обследования и первых недель — выяснить заранее, какие из десяти причин заложены в проект, и записать критерии, по которым решение примет владелец. С чего начать вашему проекту: внедрение ИИ, вывод пилота в продуктив.
Частые вопросы
Почему ИИ-пилот работает на демонстрации, а в эксплуатации нет?
На демонстрации данные подобраны, объём мал, а ошибки и сбои никто не провоцирует. В эксплуатации приходит поток с шумом, нагрузка выше, смежные системы иногда недоступны, а пользователи не знают, что система «должна» уметь. Это разные задачи, и для второй нужны критерии, интеграция, порядок ошибок и мониторинг.
Какая причина встречается чаще всего?
Мы не приводим статистику: у нас нет источника, которому можно доверять. По инженерной логике самая опасная та, которую видно позже всего: нет измеримого критерия успеха. Без него невозможно ни принять пилот, ни закрыть, ни проверить доработку.
Как записать критерий успеха пилота?
Нужны три вещи: эталонный набор задач с ожидаемыми ответами, правила оценки (кто и как смотрит) и порог принятия. Если важны скорость, доля передач человеку или стоимость обработки, добавьте их. Критерий подписывается до начала работ и не меняется без письменного согласования.
Сколько данных нужно для пилота?
Зависит от задачи: важно не количество, а то, что выборка случайная и включает плохие случаи из боевого потока. Для оценки на этапе обследования хватает небольшой выборки; сколько нужно именно вам, определяем после просмотра данных.
Что делать с ошибками модели, которые нельзя исключить полностью?
Определить, как они обнаруживаются и что с ними происходит: порог уверенности, передача человеку, очередь исключений, журнал. Цель не исключить ошибки, а чтобы они не уходили дальше незамеченными и имели владельца.
Зачем привлекать службу безопасности на старте?
Потому что решения о том, какие данные идут в модель и где она работает, определяют архитектуру. Менять их после пилота значит переделывать его почти целиком. Мы не проводим лицензируемые работы по защите информации и аттестацию, но помогаем описать требования и проектировать в контуре заказчика.
Как понять, что пилот пора остановить?
Когда критерий приёмки не достигнут и разбор ошибок показывает причину, которую нельзя устранить в разумный срок и за разумные деньги, либо экономика не сходится на объёме. Остановка с протоколом лучше затянутой «доработки»; подробнее в материале о том, когда останавливать пилот.
Можно ли вывести в продуктив пилот, который сделал другой подрядчик?
Часто да, если есть исходники, доступы и описание. Мы начинаем с диагностики: что работает, на чём держится качество, какие из десяти причин подтверждаются. Если исходников нет, вариант — восстановить систему по доступному коду и логам либо переделать часть; решение принимается после диагностики.
Сколько стоит довести пилот до продуктива?
По тарифам: вывод в продуктив — от 1 500 000 ₽ этапами по 300 000 – 700 000 ₽, от трёх месяцев, у каждого этапа своя приёмка. Для застрявшего пилота обычно начинают с обследования за 200 000 ₽, которое вычитается из следующего этапа. Точную вилку называем по его результатам.
Обещаете ли вы, что пилот дойдёт до продуктива?
Нет. Мы не обещаем результат заранее: задача обследования и пилота — выяснить, работает ли решение на ваших данных, и записать критерии, по которым решение принимает владелец. Право остановиться есть после каждой ступени, и всё сделанное остаётся у вас.