Разрыв пилот → прод AI: почему 72% не доходят до 11%

Есть одно число, которое я повторяю на каждой стратегической сессии с клиентами в 2026 году. 72% крупных компаний запустили хотя бы один AI-пилот. И только 11% довели хотя бы один пилот до продакшна (данные Gartner, начало 2026 года).

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

Причина первая: нет стандарта качества

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

Первое, что важно сделать на берегу, — договориться, что 100% качества не бывает. Даже люди ошибаются, не говоря о моделях. Договорённость должна быть вероятностной: мы говорим о доле успешных решений среди общей массы задач, а не о безошибочности.

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

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

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

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

Причина вторая: гигантизм

Вторая большая проблема — компании сразу пытаются внедрить что-то очень большое. Большую «умную модель», которую разворачивают на нескольких серверах H100. Бюджет и без того значительный, но всё равно не соответствует избыточным ожиданиям, которые возлагают на будущую систему.

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

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

Пример: аналитический агент

Если мы делаем внутреннего агента, который строит аналитические отчёты по запросу (подробнее — в статье про Gen BI Maturity Index), то нам важно:

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

Каждый из этих пунктов — отдельный уровень зрелости по шкале Gen BI, и каждый требует своей инфраструктуры и архитектуры.

Пример: анализ документов

Если мы делаем систему, которая извлекает данные из документов, то вертикальная декомпозиция выглядит так:

• Какие типы рабочих процессов мы автоматизируем?
• Для каждого процесса — какие типы документов?
• Для каждого типа — какие поля нужно извлечь и как их использовать?

Большую задачу можно поделить на процессы, процесс — на документы, документ — на извлекаемые элементы. И оперативно, постепенно автоматизировать обработку.

Итеративное повышение качества

В соответствии с первым пунктом (вероятностный подход), для всех типов документов и параметров мы устанавливаем долю успешных извлечений — и повышаем её итеративно:

• Первый этап — 50% качества: распознаются хорошо отсканированные документы или документы в формате Word.
• Второй этап — 75%: начинают распознаваться плохо отсканированные документы.
• Третий этап — выше: распознаются документы с рукописными фрагментами, нечёткий текст и пр.

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

Причина третья: нет предварительного тестирования инфраструктуры

Перед началом полноценного внедрения обязательно нужна пилотная фаза на небольшом элементе инфраструктуры. Например — арендовать GPU-сервер и прогнать на нём весь рабочий процесс на обезличенных данных. Это даёт понимание потенциальной нагрузки, скорости обработки, узких мест.

Важный момент: многие процессы внутри компании не требуют развёртывания собственного GPU-кластера, потому что данные не всегда имеют высокий уровень информационной безопасности. Например, работа с публичными закупками на zakupki.gov.ru может осуществляться с применением внешних API — и это нормально. Не нужно строить собственный контур там, где данные и так публичны.

Как это работает в больших проектах

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

Да, мы делаем большое техническое задание — чтобы показать совокупную стоимость владения и совокупную стоимость разработки. Но внутри этого большого ТЗ мы сразу декомпозируем проект вертикально на итерации. Это даёт три преимущества:

1. Поэтапное внедрение — каждая итерация приносит ценность, а не только «мы ещё разрабатываем».
2. Поэтапные платежи — заказчик платит за результат, а не за обещание.
3. Поэтапная валидация — если на второй итерации выясняется, что архитектура не подходит, мы потеряли два спринта, а не весь проект.

Что такое Agent Readiness

В терминологии, которая сейчас формируется в отрасли, всё вышеописанное начинают называть Agent Readiness — готовность процесса к принятию AI-агента. Это не техническая готовность (модель есть? есть!), а операционная готовность бизнес-процесса.

У меня Agent Readiness проверяется пятью вопросами:

1. Владелец — есть один человек с именем и фамилией, который отвечает за результат?
2. Метрика — есть одна измеряемая цифра (доля успешных решений, AHT, время обработки)?
3. Человек в контуре — определено, где в процессе стоит человек: до ответа, после, в критических точках?
4. Наблюдаемость — есть логирование, трассировка, возможность объяснить решение модели?
5. План деградации — что делать, если модель начнёт работать плохо: отключить, переключить на fallback, передать человеку?

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

Что делать прямо сейчас

Если у вас в компании есть застрявший пилот — вот что я рекомендую.

Первое — Диагностика автономности по конкретному пилоту. 90 минут, пять вопросов готовности. На выходе — понимание, где проблема.

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

Третье — не пытайтесь сделать всё сразу. Возьмите один пилот, один тип задач, одну метрику. Доведите до прода. Потом расширяйте. Методика дорожной карты внедрения ИИ прямо создана для этого.

Четвёртое — если проблема структурная, а не в одном пилоте, — корпоративная программа обучения, которая даст команде общий язык и методологию.

Разрыв между пилотом и продом — это не технический gap. Это управленческий и методологический gap. И решается он не улучшением моделей, а вероятностным подходом к качеству, вертикальной декомпозицией и дисциплиной инфраструктурного тестирования.

Записаться на сессию →