ИИ-трансформация: как выбрать стратегию внедрения

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

Сегодня для топ-менеджеров вопрос звучит не «нужен ли нам ИИ», а «как его внедрить правильно». От выбранной стратегии зависит, станет ли он драйвером роста или дорогостоящей ошибкой. В корпоративной практике есть три магистральных пути: строить самим (Build), заказывать под себя (Custom) или покупать готовое (Buy). Но прежде чем выбрать маршрут, почти каждая компания сталкивается с подготовительным этапом, который часто оказывается сложнее и дороже, чем планировалось.

Чаще всего все начинается с данных — они становятся фундаментом будущей системы. Кажется, что их много, и они готовы к работе, но на практике все иначе. Телеком-оператор, запустивший проект по прогнозированию оттока клиентов, был уверен, что располагает полным набором информации: звонки, SMS, интернет-трафик, платежи. Однако при сборке датасета выяснилось, что все хранится в десятках разных систем: детализация звонков в биллинге, параметры сети в мониторинге, поведение в приложениях в аналитике, обращения в техподдержку в CRM. На интеграцию ушло полгода вместо месяца, а данные о геопозиции и активности потребовали сложного обезличивания.

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

Когда фундамент готов, на очереди архитектура — каркас, на который ляжет вся нагрузка. Здесь также нередко вскрываются узкие места. Один крупный ритейлер внедрял персонализированные рекомендации и был уверен в стабильности своих систем. Но как только модель начала собирать поведенческие данные в реальном времени — каждый клик, просмотр товара, брошенную корзину — нагрузка на базы выросла в разы. API начали «падать», а аналитические запросы парализовали операционные процессы. Пришлось срочно перестраивать архитектуру и пересматривать подходы к интеграции.

Даже при готовых данных и архитектуре проект может застопориться на этапе постановки целей. Опыт производственной компании, решившей «оптимизировать логистику с помощью ИИ», показателен. Уже через три месяца разработки стало ясно, что у логистики, финансов, продаж и ИТ разные представления об оптимизации: одни говорили о скорости доставки, другие о сокращении затрат на топливо, третьи о качестве сервиса, а ИТ-направление — об упрощении интеграции. В итоге проект пришлось приостановить и месяц тратить на согласование KPI.

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

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

С кадрами вообще все непросто. Дефицит специалистов по ИИ затрагивает весь спектр ролей — от архитекторов данных до MLOps-инженеров. Даже если нанять «звезду» с рынка, может оказаться, что ее опыт в e-commerce плохо переносится, например, на промышленное оборудование. Один из клиентов FabricaONE.AI пошел по другому пути: отобрал перспективных сотрудников — аналитиков, разработчиков, менеджеров — и вложился в их переподготовку через сервисы корпоративного обучения. Это оказалось быстрее и надежнее, чем бесконечный поиск готовых специалистов.

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

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

Наконец, любой из подходов — Build, Custom или Buy — имеет скрытую стоимость владения. Build требует постоянных расходов на команду и инфраструктуру и чувствителен к уходу ключевых специалистов. Custom привязывает к подрядчику. Buy подразумевает лицензионные платежи и ограничения в глубокой кастомизации. Через несколько лет Build может оказаться экономичнее Buy — но только при стабильной команде и умеренных изменениях требований.

Главный урок этой статьи прост: выбор между Build, Custom и Buy имеет смысл только тогда, когда компания прошла всю «подводную» часть айсберга — разобралась со своими данными, архитектурой, кадрами и целями. Без этой работы стратегия превращается в лотерею.

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