Внедрение ИИ проходит пять этапов: выбор процесса, проверка достижимости на реальных данных, пилот в боевых условиях, промышленный запуск и сопровождение. Пропуск этапа не ускоряет проект, а переносит его стоимость дальше — ошибка, которую можно было обнаружить за неделю проверки, всплывает после разработки и обходится в весь бюджет.
Почему порядок этапов важнее скорости
Соблазн начать сразу с разработки понятен: задача кажется ясной, подрядчик готов, время идёт. Проблема в том, что у ИИ-проекта два ключевых параметра неизвестны на старте и не могут быть определены обсуждением.
Первый — достижимое качество. Будет ли модель отвечать правильно на ваших документах, а не на абстрактных, заранее не знает никто. Это выясняется только проверкой на реальных данных.
Второй — стоимость эксплуатации. Она зависит от объёма обращений и размера контекста, и решение, безупречное на десяти тестовых запросах, может оказаться нерентабельным на тысяче реальных.
Из этого следует практический вывод: этапы существуют не ради бюрократии, а чтобы получить ответы на эти два вопроса до того, как потрачены основные деньги. Каждый этап — это точка, где проект можно остановить дёшево. Чем позже обнаруживается препятствие, тем дороже стоит остановка: на этапе проверки это неделя работы, после промышленного запуска — весь проект плюс подорванное доверие к теме внутри компании.
Этап 1. Выбор процесса
Определяется, что именно автоматизируется. Это решение влияет на исход сильнее, чем выбор модели или подрядчика.
Хороший кандидат для первого проекта — не самый ценный процесс компании, а тот, где польза достижима, а цена ошибки низка. Ключевые условия: операция регулярная, результат проверяем, данные существуют в электронном виде, ошибка заметна и не приводит к необратимым последствиям.
Результат этапа: выбран один процесс, у него есть внутренний заказчик, зафиксирован показатель «до» — то, с чем потом будем сравнивать. Подробный разбор критериев и матрица оценки кандидатов — в статье «Как выбрать процесс для первого ИИ-проекта».
Частая ошибка: взять несколько процессов сразу или начать с ключевого. Универсальное решение дольше разрабатывается и рискованнее, а провал на видном месте закрывает тему внутри организации надолго.
Этап 2. Discovery: проверка достижимости и экономики
Самый недооценённый этап и одновременно самый дешёвый способ не потерять бюджет. Здесь на реальных данных проверяется, достижимо ли нужное качество, и считается, сколько будет стоить эксплуатация.
Что происходит:
- Проверка данных. Берётся выборка реальных материалов — не показательных, а обычных. Часто именно здесь выясняется, что регламенты устарели, существуют в трёх редакциях или противоречат друг другу.
- Прототип на реальных примерах. Не интерфейс и не интеграции — только ядро: получает ли система правильный ответ на настоящих запросах.
- Расчёт стоимости обращения. Средний размер контекста и ответа замеряются на прототипе, умножаются на реальный объём процесса. Методика — в статье «Сколько стоит эксплуатация ИИ-решения».
- Определение ограничений на данные. Если в процессе есть персональные данные, требования закона определяют архитектуру — облако или локальное развёртывание.
Результат этапа: обоснованный ответ «делаем / не делаем / сначала приводим в порядок данные», с цифрами, а не ощущениями.
Частая ошибка: проводить discovery на идеальных данных, специально отобранных для демонстрации. Такая проверка всегда успешна и ничего не доказывает.
Этап 3. Пилот на реальных данных
Решение работает в боевых условиях, но на ограниченном участке: один отдел, часть потока обращений, определённый тип документов. Обязательное условие пилота — человек остаётся в контуре и проверяет результат.
Задача пилота не техническая, а организационная. Прототип уже показал, что технология справляется. Пилот показывает другое: пользуются ли решением люди, что происходит на нетипичных случаях, сколько времени реально уходит на проверку, где система ломается о живой процесс.
Именно на пилоте обнаруживаются вещи, невидимые в кабинете: половина обращений приходит не в том формате, сотрудники обходят систему привычным способом, а «редкий» сценарий на деле составляет четверть потока.
Результат этапа: измеренное качество на живом потоке, список доработок, решение о масштабировании.
Этап 4. Промышленный запуск
Решение переводится на полный объём, доводятся интеграции, настраиваются мониторинг и лимиты расходов, обучаются пользователи, пишутся регламенты — что делать, когда система ошиблась или недоступна.
Ключевое отличие от пилота — меняется цена сбоя. На пилоте ошибку ловил внимательный сотрудник, знающий, что идёт эксперимент. В промышленной эксплуатации решение встроено в поток, и на него полагаются. Поэтому здесь появляется то, чего не было раньше: ограничение расходов с автоматической остановкой, оповещения об аномалиях, запасной сценарий на случай недоступности.
Результат этапа: решение в постоянной работе, у процесса есть владелец, зафиксирован показатель «после».
Этап 5. Сопровождение
Единственный этап без конца. ИИ-решение не является программой, которую один раз написали и забыли: меняются документы, приходят новые типы обращений, обновляются и снимаются с поддержки модели.
Регулярные работы: контроль качества на выборке ответов, обновление базы знаний, оптимизация расходов, миграция при смене модели. Решение без сопровождения деградирует не сразу и незаметно — качество падает постепенно, по мере того как реальность расходится с базой знаний, на которой система была построена.
Этапы одной таблицей
| Этап | На какой вопрос отвечает | Результат | Условие перехода дальше |
|---|---|---|---|
| Выбор процесса | Что автоматизируем и зачем | Один процесс, заказчик, метрика «до» | Процесс прошёл по критериям, есть кому пользоваться |
| Discovery | Достижимо ли качество и сколько стоит | Прототип, расчёт, решение «делаем/нет» | Качество достижимо, экономика сходится |
| Пилот | Работает ли в живом процессе | Замеренное качество, список доработок | Люди пользуются, эффект виден |
| Промышленный запуск | Выдержит ли полный объём | Решение в работе, метрика «после» | Стабильная работа, есть владелец |
| Сопровождение | Не деградирует ли со временем | Поддерживаемое качество | — |
Сколько это занимает
Точные сроки зависят от процесса, но соотношение между этапами устойчиво. Discovery — самый короткий и самый решающий: обычно недели, а не месяцы. Пилот занимает больше, потому что нужен не столько прогон, сколько накопление статистики на реальном потоке — за неделю она не набирается.
Основной срок съедает не разработка, а два фактора, которые заказчики систематически недооценивают: приведение данных в порядок и интеграции с существующими системами. Если ключевая информация лежит на бумаге или в голове у сотрудника, проект начинается не с ИИ, а с оцифровки, и это отдельный по объёму этап.
Где проекты срываются чаще всего
- Перепрыгнули discovery. Разработка началась до проверки на данных. Выясняется после, что нужного качества на этих материалах не получить.
- Пилот на идеальной выборке. Проверяли на подготовленных примерах, в живом потоке качество оказалось другим.
- Нет внутреннего владельца. Подрядчик сделал, передать некому, решением никто не пользуется.
- Не зафиксирован показатель «до». Эффект есть, доказать нечем, финансирование продолжения не получено.
- Забыли про сопровождение. Запустили и оставили; через полгода база знаний устарела и ответы перестали быть верными.
Частые вопросы
Можно ли пропустить discovery, если задача понятная?
Понятность задачи и достижимость результата — разные вещи. Discovery отвечает не на вопрос «что нужно сделать», а на вопрос «получится ли на ваших данных и сколько это будет стоить в эксплуатации». Пропуск этапа не отменяет этих вопросов, а переносит ответ на момент, когда деньги уже потрачены. Это самый дешёвый этап и самая дорогая экономия.
Сколько длится внедрение целиком?
От выбора процесса до промышленной эксплуатации простой сценарий проходит за несколько месяцев, сложный — дольше. Основное время уходит не на разработку, а на подготовку данных и интеграции с существующими системами. Если данные разрознены или лежат вне электронного вида, срок определяется именно их приведением в порядок.
Чем пилот отличается от PoC?
PoC отвечает на технический вопрос: достижимо ли нужное качество в принципе, на реальных данных, без интерфейса и интеграций. Пилот отвечает на организационный: работает ли решение в живом процессе и пользуются ли им люди. PoC можно провести за пару недель силами подрядчика, пилот требует участия сотрудников и времени на накопление статистики.
На каком этапе платить подрядчику?
Разумная схема — оплата по этапам с точкой выхода после discovery. Заказчик оплачивает проверку достижимости отдельно и получает право не продолжать, если результат отрицательный. Это защищает обе стороны: заказчик не платит за разработку решения, которое не даст качества, подрядчик не берётся за обязательства, выполнимость которых не проверена.
Что делать, если на этапе проверки выяснилось, что качество недостижимо?
Остановиться и разобраться в причине — это нормальный, а не провальный исход. Чаще всего дело не в модели, а в данных: они противоречивы, устарели или не содержат нужной информации. Тогда проект превращается в задачу подготовки данных, после которой к ИИ можно вернуться. Если же недостижимость связана с самой природой задачи, дешевле узнать это на этапе проверки, чем после разработки.
Что дальше
Этапы задают порядок работ, но каждый требует отдельных решений. Как выбрать сам процесс — «Как выбрать процесс для первого ИИ-проекта». Как считать экономику до разработки — «Сколько стоит эксплуатация ИИ-решения». Полная картина внедрения — в опорной статье «Внедрение ИИ в бизнес».
Прохождение этапов от discovery до сопровождения — это то, из чего состоит работа по разработке и внедрению ИИ; начать можно с аудита процессов.