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

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

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

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

Сначала понять, что именно доказал пилот

Успешный пилот легко переоценить. Например, система показала 90% качества на тестовой выборке. Но использовались ли в ней реальные данные? Были ли представлены редкие сценарии? Проверялась ли работа при нескольких одновременных запросах? Что происходило, когда нужной информации не было? Как часто требовалось вмешательство человека?

Перед следующим этапом полезно зафиксировать границы эксперимента:

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

Это помогает отделить подтверждённые свойства решения от предположений.

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

Определить границы первой промышленной версии

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

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

Тестовые данные нужно заменить реальным контуром

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

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

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

В промышленной версии данные становятся частью архитектуры, а не подготовленным материалом для эксперимента.

Права доступа должны наследоваться и в ИИ

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

При промышленном запуске необходимо определить:

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

ИИ не должен создавать новый способ обойти уже существующие правила доступа.

Для действий нужны более строгие ограничения, чем для ответов

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

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

Полезно также ограничивать доступные агенту инструменты и параметры. Если для бизнес-процесса ему достаточно читать данные о заказах, необязательно одновременно предоставлять возможность их удалять.

Интеграции должны переживать ошибки

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

• таймауты;
• повторные попытки;
• очереди;
• защита от дублей;
• обработка частичных ошибок;
• резервные сценарии;
• передача задачи человеку.

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

Нужен мониторинг не только серверов, но и самого ИИ

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

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

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

Качество после запуска может измениться

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

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

Нужны версии и возможность отката

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

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

Логи должны позволять восстановить ход операции

Когда агент ошибается, недостаточно увидеть только его финальный ответ. Для расследования может понадобиться понять:

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

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

Стоимость нужно пересчитать на реальном объёме

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

Например:

стоимость одной успешно выполненной задачи × ожидаемое количество задач в месяц + инфраструктура + сопровождение.

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

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

Производительность нужно проверить под нагрузкой

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

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

Должен быть понятен сценарий отказа

Что произойдёт, если ИИ временно недоступен?

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

Нужно заранее определить fallback-сценарий. Например, задача автоматически переходит сотруднику, используется более простая модель, операция ставится в очередь или процесс временно возвращается к ручной схеме.

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

Меняется не только система, но и работа людей

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

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

Лучше расширять эксплуатацию постепенно

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

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

На каждом этапе можно сравнивать реальные показатели с критериями, которые были определены для пилота:

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

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

Что проверить перед промышленным запуском

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

Область	Что должно быть понятно
Сценарии	Какие задачи ИИ выполняет и где проходят границы автоматизации
Качество	Какие показатели контролируются и какие значения допустимы
Данные	Откуда они поступают, обновляются и кто отвечает за качество
Доступ	Кто видит какие данные и какие действия может выполнять
Интеграции	Как система ведёт себя при ошибках внешних сервисов
Безопасность	Какие ограничения действуют для данных и операций
Наблюдаемость	Какие действия, ошибки и показатели можно отследить
Версии	Как проверяются изменения и можно ли откатить релиз
Производительность	Выдерживает ли система рабочую и пиковую нагрузку
Экономика	Сколько стоит успешно выполненная задача в реальном масштабе
Отказ	Что происходит, если ИИ или один из его компонентов недоступен
Процесс	Кто отвечает за систему и как с ней работают сотрудники

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

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

И только после этого ИИ перестаёт быть экспериментом и становится частью рабочей системы.