Привет, Хабр! Меня зовут Алексей Постригайло, я старший партнер ИТ-интегратора «Энсайн». Больше 20 лет занимаюсь системной интеграцией и управлением проектами.

Сейчас почти каждая крупная компания тестирует искусственный интеллект. Где-то запускают поиск по внутренним документам, где-то автоматизируют поддержку, аналитику или подготовку отчетов.

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

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

Пилот и промышленная система живут в разных условиях

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

В таком режиме легко показать результат.

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

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

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

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

Данные становятся первой точкой сбоя

Исследование Confluent, которое разбирает TechRadar, связывает проблемы внедрения ИИ с состоянием корпоративных данных.

Во многих компаниях информация распределена между несколькими системами. Часть документов хранится в файловых папках. Что-то осталось в старом портале. Отдельные сведения ведутся в таблицах.

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

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

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

ИИ в таком случае не ускоряет работу. Он добавляет еще один слой проверки.

Ответ модели еще не дает бизнес-результат

Во многих пилотах основное внимание уделяют качеству ответа.

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

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

Если система нашла ошибку в заявке, кто ее исправляет? Если обнаружила риск, куда отправляется уведомление? Если подготовила документ, где он проходит согласование?

Материал ComNews как раз показывает переход от отчетов к действиям.

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

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

Интеграция быстро усложняет проект

Во время пилота решение может работать отдельно. Пользователь загружает файл и получает ответ.

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

На этом этапе проект начинает зависеть от старых систем компании.

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

В итоге простой помощник постепенно превращается в полноценную интеграционную систему.

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

ИТ-служба получает новую систему на поддержку

После завершения пилота решение должно перейти в постоянную эксплуатацию.

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

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

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

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

Без такого контроля ИТ-служба не готова принимать решение на поддержку. Это нормальная позиция. Ответственность за работу системы остается у компании.

Стоимость после запуска меняется

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

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

В материале Reuters приводится пример компании, которая потратила годовой бюджет на использование моделей за 4 месяца.

Проблема не только в цене запросов.

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

Поэтому стоимость нужно считать на предполагаемом объеме работы. Цена пилота почти ничего не говорит о расходах после запуска.

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

Еще одна причина остановки связана с организацией проекта.

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

После этого возникает вопрос: кто отвечает за дальнейшее развитие?

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

В колонке Forbes также разбирается проблема пилотов, которые не получают продолжения после демонстрации.

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

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

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

Как компании переходят от пилотов к внедрению

Один из показательных примеров приводит X5.

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

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

Похожий подход использует В2В-РТС. Как сообщает CNews, компания разрабатывает несколько ИИ-помощников, но запускает их постепенно.

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

Рынок движется в сторону управляемых систем

Крупные поставщики тоже меняют подход.

Google развивает инструменты для управления корпоративными ИИ-помощниками.

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

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

Что стоит определить до начала пилота

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

Параллельно нужно проверить данные. Если информация устарела или распределена между разными системами, это стоит учитывать еще до создания прототипа.

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

Отдельно стоит посчитать расходы при полном объеме использования. Это позволяет закрыть проект раньше, если его экономика не сходится.

Вывод

Большинство ИИ-пилотов останавливается не из-за качества моделей.

Главные сложности появляются после демонстрации. Решение нужно подключить к корпоративным данным, встроить в существующие процессы и передать на постоянную поддержку.

Чем раньше команда начинает проектировать промышленную систему, тем выше шанс, что пилот получит продолжение.

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

Здесь я обычно пишу про проекты, кейсы и ИТ-практику. А если хочется увидеть меня не только в рабочих текстах — приходите в мой ТГ https://t.me/alekseypostrigaylo. Там — сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.