Скопировать ссылку
Причина провалов почти всегда не в модели. Проекты ломаются в тот момент, когда компанию приходится возвращать из режима «давайте попробуем ИИ» в режим нормального управленческого разговора: что именно мы меняем, на каких данных это будет работать, кто за это отвечает, как это встроено в существующие системы и сколько это будет стоить через год.
Вот пять ошибок, из-за которых GenAI-пилоты чаще всего так и не доходят до продакшена.
Успешный пилот ≠ успешное внедрение
Первая и, пожалуй, самая дорогая ошибка — считать, что успешный пилот автоматически означает успешное внедрение.
Пилот — это способ проверить, можно ли в принципе решить задачу с помощью GenAI. На пилоте, как правило, ограниченный набор сценариев, небольшой объем данных, почти нет реальной нагрузки. Неудобные вопросы вынесены за скобки: масштабирование, отказоустойчивость, ролевая модель, поддержка, стоимость эксплуатации, конфликт с существующими процессами.
На демо почти всегда все работает: бот отвечает, агент собирает данные, RAG ищет по документам, модель генерирует коммерческое предложение. Но как только возникает задача встроить это в живой процесс, начинается совсем другая история.
В продакшене GenAI работает не на специально подготовленном стенде, а внутри компании — с реальными данными, пользователями, ограничениями по доступам и безопасности. И тут выясняется, что пилот отвечал только на один вопрос: «Можно ли это показать?». Вопрос «Можно ли с этим работать?» вообще еще не обсуждался.
Сначала технология, бизнес-задача — потом
Вторая ошибка — компания изначально не понимает, зачем ей этот проект. Типичный заход выглядит так: «У нас много рутины, давайте внедрим ИИ-агента». Или: «Нам нужен корпоративный чат-бот на базе LLM». Или еще лучше: «Давайте сделаем что-нибудь с генеративным ИИ, чтобы не отставать от рынка».
Это не постановка задачи. С таким стартом проект почти всегда превращается в красивый эксперимент без понятного бизнес-эффекта.
У внедрения ИИ должна быть другая логика. Сначала — ответы на неудобные, но обязательные вопросы. Какой участок процесса сегодня работает плохо? Сколько времени занимает эта операция сейчас? Что именно должно измениться после внедрения: цикл сделки, скорость подготовки документов, нагрузка на первую линию, время ответа клиенту?
Если ответов нет, никакой GenAI не поможет. Получится очередной пилот ради пилота: конечно, можно будет выпустить пресс-релиз о том, что компания активно внедряет ИИ. Но когда кто-то задаст простой вопрос, что именно это дает бизнесу, внятного ответа не найдется.
Данные «в целом есть», но фактически их нет
Третья ошибка — классическая и поэтому особенно опасная. Почти в любой крупной компании есть CRM, ERP, документооборот, тикетные системы, базы знаний. Снаружи это выглядит как готовая среда для внедрения GenAI. Но на практике данные почти никогда не готовы к внедрению ИИ.
В CRM одна информация, в соседней системе — другая. У документов нет владельца — человека, который отвечает за их актуальность. Критически важные знания о процессах нередко вообще не зафиксированы нигде — они существуют только в головах сотрудников.
В пилот берут ограниченный и вручную очищенный набор данных, поэтому проблема остается незаметной. Но как только проект пытаются масштабировать, весь этот мусор вылезает наружу. И выясняется, что проблема не в модели, а в том, что компания пытается строить GenAI на данных, которыми сама никогда всерьез не занималась.
Переоценить модель, недооценить интеграцию
Четвертая ошибка — считать, что основная сложность проекта лежит в выборе модели, настройке промптов и красивом интерфейсе. В корпоративном GenAI львиная доля работы приходится на интеграции, права доступа, инфраструктуру и сопровождение.
GenAI должен взаимодействовать с корпоративными системами: забирать данные из CRM и ERP, работать с документами, внутренними справочниками. А это означает API, доступы, credentials, согласования с безопасностью, ограничения по ролям, конфликты между системами, которые исторически развивались независимо друг от друга.
На словах все выглядит просто: «подключим к CRM», «дадим доступ к базе знаний». На практике это месяцы работы и масса технических и организационных нюансов. Какие данные можно отдать модели? В каком виде? Кто разрешает доступ? Что делать с чувствительной информацией? Как разграничивать роли? Что делать, если данные в разных системах конфликтуют?
Модель — это только верхушка айсберга. Под ней лежит интеграционный и инфраструктурный пласт, который и определяет, сможет ли проект жить после презентации.
Ждать быстрого ROI и игнорировать стоимость эксплуатации
Пятая ошибка — оценивать GenAI-проект как обычный ИТ-пилот с быстрой окупаемостью.
Дело в том, что пилот почти никогда не показывает реальную экономику: он работает на ограниченном объеме данных, без полной нагрузки и без той инфраструктуры, которая понадобится в продакшене.
После пилота появляются затраты на сопровождение, доработки, MLOps и DevOps, безопасность, интеграции, поддержку пользователей, инфраструктуру, токены или собственные мощности. Считать нужно не только потенциальную экономию, но и стоимость владения через год, два, три. По оценкам Gartner, ежегодные затраты на поддержку корпоративного GenAI-решения составляют 15–20% от стоимости первоначального внедрения.
Если этого расчета нет, компания попадает в типичную ловушку: пилот вроде бы успешный, но как только проект начинают переводить в рабочий режим, он становится слишком дорогим или организационно неподъемным. Бизнес говорит: «Интересно, но давайте пока отложим». На этом история обычно и заканчивается.
Что делают компании, у которых GenAI доходит до продакшена
Успешные кейсы обычно выглядят намного прозаичнее, чем принято думать.
- Начинают с процесса, а не с модели. Не с вопроса «куда бы прикрутить ИИ», а с поиска участка работы, который сегодня отнимает больше всего времени, денег и ресурсов. Сначала описывают проблему и считают базовые метрики.
- Назначают конкретного владельца проекта. Не цифровую команду в целом и не абстрактный ИТ-блок, а человека с полномочиями, KPI и мотивацией довести внедрение до результата.
- Приводят в порядок данные хотя бы на одном контуре. Не пытаются автоматизировать всю компанию сразу: выбирают один сценарий, чистят источники, выстраивают доступы, проверяют актуальность и только после этого идут дальше.
- Не запускают десять пилотов одновременно. Рабочий путь выглядит иначе: один процесс, измеримый результат, анализ ограничений, доработка архитектуры и потом масштабирование.
- Пересобирают процесс, а не надстраивают над ним ИИ. Это и есть граница между красивым экспериментом и реальным внедрением. GenAI не украшение существующей схемы, под него меняются роли, логика работы и сам процесс.
Главная проблема GenAI-проектов
Большинство GenAI-проектов проваливается не потому, что выбрали не тот стек или не тот интерфейс. Они проваливаются потому, что бизнес пытается внедрить GenAI, не меняя ничего вокруг.
Пилот можно сделать почти на чем угодно — на открытых данных, на синтетике, на внешней или локальной модели. Но если за пилотом не стоит конкретная бизнес-задача, владелец, подготовленные данные и готовность менять сам процесс, дальше демо дело не пойдет. Это не rocket science, здесь нет никакой магии — те, кто внедрял SAP или любую ERP, сталкивались с тем же, с той лишь разницей, что в случае с ИИ цена ошибки несколько выше, а прогнозируемость ниже.
GenAI не лечит управленческий хаос. Он работает там, где компания сначала разобралась, что именно хочет изменить, и только потом выбрала под это технологию.
Главный вопрос перед запуском пилота — какой бизнес-процесс мы готовы пересобрать и как поймем, что это было не зря. Если ответа нет — очередной бот просто пополнит кладбище пилотов.
