Почему 80% AI-пилотов не доходят до production

Вы запускаете AI-пилот. Команда показывает демо: модель отвечает точно, интерфейс выглядит убедительно, руководство довольно. Через три месяца выясняется, что пилот не готов к production. Данные в реальных системах оказались грязнее тестовой выборки, интеграция с 1С требует пересмотра архитектуры, а сотрудники, которые должны были стать владельцами системы, уже переключились на другие задачи. Пилот зависает — его не закрывают, но и не развивают.

По данным Gartner (2026), 72% крупных компаний запустили AI-пилоты, но только 11% довели хотя бы один до промышленной эксплуатации. В России ситуация жёстче: исследование Confluent и опросы на Хабре показывают, что 89% пилотов застревают на стадии тестирования. Причина — не техническая слабость моделей, а организационные и регуляторные разрывы, которые можно было выявить до старта.

Три типа барьеров на пути к production

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

Пример из российской практики: производственная компания запустила пилот AI-ассистента для отдела закупок. Модель обучалась на выгрузке из 1С за последний год. На демо точность составила 94%. При попытке масштабирования выяснилось, что в production-контуре данные разнесены между 1С:ERP, 1С:Документооборот и почтовыми архивами, а часть контрагентов ведётся в Excel-файлах на локальных дисках. Интеграция потребовала перепроектирования пайплайнов данных, и production-запуск отложили на 9 месяцев.

Pre-flight checklist: семь вопросов до подписания бюджета

Этот чеклист — инструмент для ЛПР. Если хотя бы на три вопроса нет чёткого ответа, пилот запускать рано.

1. Кто бизнес-владелец системы в production? {#q1}

Бизнес-владелец — не спонсор, не руководитель IT и не подрядчик. Это человек из бизнес-подразделения, чьи KPI напрямую зависят от работы системы. Он принимает решение о go/no-go, выделяет ресурсы на поддержку и отвечает за метрики эффективности.

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

Go/no-go: если владелец не назначен — пилот не начинается.

2. Какие данные будут использоваться в production и где они физически находятся? {#q2}

Пилот на «чистых» данных — иллюзия. В production данные распределены между 1С, CRM, файловыми хранилищами, почтой. Без карты источников и оценки их качества модель не переживёт масштабирования.

Что проверять: перечень систем-источников, формат данных, частота обновления, наличие дубликатов и устаревших записей, доля данных, требующих анонимизации по 152-ФЗ.

Go/no-go: если карта данных не составлена — пилот не начинается.

3. Какие метрики успеха привязаны к P&L? {#q3}

«Пользователи довольны» — не метрика. CFO утвердит production-бюджет только под конкретный бизнес-результат: сокращение времени обработки заявки на X%, рост конверсии на Y п.п., экономия Z FTE.

Что проверять: метрики сформулированы в деньгах или трудозатратах, есть baseline (текущее значение), определён пороговый уровень для перехода в production.

Go/no-go: если метрики не привязаны к P&L — пилот не начинается.

4. Как модель будет работать с реальной нагрузкой? {#q4}

Демо на 10 запросах не показывает latency p95 при 100 одновременных обращениях. Без нагрузочного тестирования на production-данных вы не знаете, уложится ли система в бизнес-требования по времени отклика.

Что проверять: определён целевой latency p95 (например, <2 секунд для клиентского сервиса), проведено тестирование на объёме, близком к реальному, зафиксирован cost per inference × ожидаемый месячный объём.

Go/no-go: если нагрузочное тестирование не проведено — пилот не начинается.

5. Как решён вопрос с 152-ФЗ и регуляторными рисками? {#q5}

Использование публичных LLM-API с реальными данными клиентов без анонимизации — прямой риск. Штрафы до 500 млн рублей, блокировка production-запуска службой безопасности, репутационные потери.

Что проверять: проведён аудит данных на наличие персональных, определён метод анонимизации или выбран on-premise/частный облачный контур, получено заключение ИБ-службы.

Go/no-go: если данные не анонимизированы и нет заключения ИБ — пилот не начинается. Подробнее о требованиях 152-ФЗ к генеративному ИИ — в нашем материале 152-ФЗ и генеративный ИИ.

6. Кто будет поддерживать систему после ухода подрядчика? {#q6}

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

Что проверять: определена внутренняя команда поддержки (хотя бы 1–2 человека), проведён трансфер знаний от подрядчика, заложен бюджет на обучение и поддержку в первый год production.

Go/no-go: если команда поддержки не назначена — пилот не начинается.

7. Есть ли план перехода от пилота к production с конкретными датами и бюджетами? {#q7}

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

Что проверять: документ с этапами, сроками и бюджетами утверждён спонсором и бизнес-владельцем, зафиксирована дата первого production-пользователя.

Go/no-go: если плана перехода нет — пилот не начинается.

152-ФЗ и LLM: что блокирует production

Российские компании часто запускают пилоты на зарубежных LLM-платформах, передавая туда реальные обращения клиентов. Это нарушает 152-ФЗ, который требует локализации персональных данных на серверах в РФ и получения согласия субъекта на обработку. Штрафы достигают 500 млн рублей, а служба безопасности может заблокировать production-запуск на этапе согласования.

Решение — либо анонимизация данных до отправки в API, либо использование моделей, развёрнутых в защищённом контуре (on-premise или частное облако). Выбор архитектуры должен быть сделан до старта пилота, иначе production окажется невозможным без полной переработки решения.

Зомби-пилот: как распознать и что делать

Зомби-пилот — это проект, который формально не закрыт, но не движется к production. Признаки:

• Прошло больше 6 месяцев, а бизнес-владелец так и не назначен.
• Метрики успеха не пересматривались с момента запуска, отчёты содержат только «качественные оценки».
• Команда пилота распалась: подрядчик завершил контракт, внутренние участники переключились на другие задачи.
• На вопрос «кто отвечает за систему в production?» нет фамилии.

Если вы обнаружили эти признаки — проведите go/no-go встречу с фиксацией решения. Либо назначайте владельца и реанимируйте проект с новым планом, либо официально закрывайте. Зомби-пилот потребляет ресурсы и блокирует запуск новых инициатив.

Метрики go/no-go для production

Чтобы CFO одобрил production-бюджет, вы должны предъявить конкретные цифры. Ниже — пороговые значения, которые работают в российской практике.

Payback period по функциям (данные The Agentics Co., 2026): customer service — около 4 месяцев, marketing ops — 7 месяцев, engineering workflows — 9 месяцев. Эти цифры помогут обосновать бюджет перед советом директоров.

Мини-кейс: интеграция с 1С остановила production

Российский финтех-оператор запустил пилот AI-ассистента для обработки клиентских обращений. Модель обучалась на выгрузке из CRM за 6 месяцев. Точность на демо — 92%. При подготовке к production выяснилось, что часть данных о клиентских договорах хранится в 1С:Управление торговлей, а история коммуникаций — в почтовом архиве. Интеграция с 1С потребовала доработки коннекторов и согласования с ИБ-службой, так как в договорах содержались персональные данные. Production-запуск отложили на 7 месяцев. Если бы карта данных была составлена до пилота, этот риск выявили бы на старте.

Кто должен быть назначен до запуска пилота

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

• Спонсор — руководитель уровня C-level или директор департамента. Выделяет бюджет, утверждает go/no-go.
• Бизнес-владелец — руководитель функции, чьи KPI зависят от системы. Принимает production-решение, отвечает за метрики эффективности.
• Владелец данных — сотрудник, который знает, где лежат данные, в каком они состоянии и кто имеет к ним доступ. Обеспечивает data readiness.
• Production-owner — технический руководитель (часто из IT), который будет отвечать за стабильность, мониторинг и поддержку системы в production.
• AI-чемпион в функции — сотрудник бизнес-подразделения, который понимает возможности ИИ и помогает коллегам адаптироваться к новому инструменту.

Все пять ролей должны быть названы пофамильно до старта пилота. Если хотя бы одна вакантна — пилот не начинается.

Материал подготовлен на основе данных Gartner, Confluent, MIT NANDA и российских кейсов. Если ваш AI-пилот застрял на этапе тестирования и вы не видите пути к production, мы можем разобрать вашу ситуацию и найти конкретные барьеры.