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

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

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

Пилот проверяет идею, запуск проверяет систему

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

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

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

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

Данные быстро становятся главным ограничением

Одна из частых причин остановки ИИ-проектов - состояние корпоративных данных.

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

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

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

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

Для корпоративного ИИ качество данных становится частью архитектуры проекта. Его нельзя оставить на этап после пилота.

Хороший ответ модели не меняет процесс

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

Для демонстрации этого достаточно. Для промышленной эксплуатации - нет.

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

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

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

Интеграция часто сложнее настройки модели

На пилоте решение может жить отдельно. Пользователь загружает файл, задает вопрос и получает ответ.

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

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

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

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

Эксплуатация должна быть спроектирована заранее

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

Если этих механизмов нет, решение сложно принять в эксплуатацию.

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

Ответственность за сбой все равно остается на компании. Поэтому ИТ-служба закономерно требует прозрачности и управляемости.

Экономику нужно считать на промышленном объеме

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

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

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

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

У проекта должен быть владелец внутри бизнеса

ИИ-пилот часто начинается как технологический эксперимент. Команда делает прототип, пользователи видят пользу, руководство признает направление интересным.

Затем возникает вопрос: кто отвечает за дальнейшее развитие и какой результат должен получить бизнес?

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

Пилот должен начинаться с бизнес-задачи. Тогда после теста проще принять решение: масштабировать, доработать или закрыть проект.

Вывод для рынка

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

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

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