Розбори · Чому проєкти зупиняються

Чому ШІ-пілоти не доходять до продакшену?

Коротка відповідь

Тому що більшість пілотів спроєктовані показати, що модель щось уміє, а не вижити в умовах реального процесу. Провали купчаться в чотирьох місцях: немає узгодженої метрики успіху, немає обробки винятків, немає власника після запуску та інтеграція залишена на кінець. Усі чотири — рішення, ухвалені до того, як написано код.

95%
Корпоративних GenAI-пілотів не дали ефекту в P&L — MIT Project NANDA, 2025
4
Режими відмови, на які припадає майже все
До впровадження
Коли кожен із них насправді вирішується
Автор: Max Pochinsky · Оновлено Серпень 2026 · Написано для тих, хто оцінює проєкт, а не для пошуковиків

Про цю цифру: що вона каже і чого не каже

Звіт MIT Project NANDA 2025 року «The GenAI Divide: State of AI in Business» виявив, що близько 95% корпоративних пілотів із генеративним ШІ не дали вимірного ефекту на P&L. Цифру цитують як доказ, що технологія не працює. Вимірює вона не це.

Вона вимірює провал доставки. Пілоти здебільшого робили те, для чого їх побудували; побудували їх показати можливість, а не змінити процес, а можливість у P&L не з’являється. Ті 5%, що дали ефект, — це переважно проєкти, вшиті в реальний робочий процес і з числом, прив’язаним до них із самого початку.

Провал перший: метрику успіху не узгоджено до впровадження

Якщо метрику обирають після того, як пілот відпрацював, пілот не може провалитися — а отже, і не може вдатися. Усі оголошують часткову перемогу, проєкт тихо завершується, і нічого не розгортається.

Лікування нудне й дієве: назвіть одне число, виміряйте його до старту і заздалегідь домовтеся, яке значення вважається успіхом. «Середній час обробки за цією категорією тикетів, зараз 11 хвилин, ціль — менше 7» — це метрика. «Покращити клієнтський досвід» — це спосіб метрики уникнути.

Ми узгоджуємо метрику успіху на аудиті, до того як буде спроєктовано пілот. Якщо не вдається знайти число, яке приймуть обидві сторони, це саме собою висновок — і зазвичай означає, що процес не підходить на роль першого.

Провал другий: винятки були поза обсягом

Пілоти демонструють на чистих 80%. Продакшен — це здебільшого решта 20%: викривлений ввід, постачальника немає в довіднику, клієнт, який водночас партнер, випадок, якого правила не передбачили.

Пілот без шляху винятків виглядає вражаюче і не може бути розгорнутий, бо перший же день у продакшені видає випадок, який він мовчки обробить неправильно. Проєктування шляхів відмови — повтор, передача людині, зупинка потоку — це не лоск, що додається наприкінці. Це різниця між демо і системою.

Провал третій: після запуску ним ніхто не володіє

Автоматизація — не результат, що лишається готовим. Постачальники змінюють формати, система випускає нову версію, обсяги зсуваються, змінюється політика. Без названого власника і дашборда, що показує дрейф, потік тихо деградує, і хтось зрештою його вимикає.

Для цього не потрібна команда. Потрібна одна людина, у якої це в посадових обов’язках, і вид моніторингу, що робить деградацію видимою раніше, ніж її знайде клієнт.

Провал четвертий: інтеграцію залишено на кінець

Найдорожча помилка в послідовності — спершу довести модель, а системи підключати потім. Ризик для строків живе саме в інтеграції: доступи, пісочниці, ліміти запитів, система без API, вендор, який відповідає три тижні.

У зворотному порядку — спершу переконатися, що дані можуть рухатися, потім довести модель на реальних даних на місці — це не коштує нічого додатково і прибирає режим відмови, за якого вдалий пілот не можна розгорнути з причин, виявлених на третій місяць.

Пілот, який працює на вивантажених таблицях, не перевірений проти того, що найімовірніше його й уб’є.

Як виглядає пілот, спроєктований вижити

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

У цьому весь аргумент за вузький обсяг: вузька річ у продакшені краща за широку в презентації, і це до того ж єдина версія, що дає докази, потрібні для фінансування наступної.

Уточнювальні питання

Про що питають далі.

Вона з дослідження MIT Project NANDA 2025 року щодо корпоративних впроваджень GenAI. Як будь-яке окреме дослідження, її варто читати як вказівку, а не як константу, і важлива не точна цифра, а описана закономірність: пілоти, які ніколи не були вшиті в процес, у фінансових результатах не з’являються.

Так і не зрозуміли, чи варто автоматизувати ваш процес?

Принесіть нам процес. Ми розберемо його разом із вами безкоштовно і дамо пряму відповідь — зокрема й тоді, коли відповідь «ні».