Чому проекти Agentic AI застряють у масштабі, і що підприємства повинні виправити спочатку

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

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

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

Середовище POC – це пастка

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

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

За даними звіту McKinsey про стан штучного інтелекту 2025 року, 88% організацій зараз використовують штучний інтелект принаймні в одній бізнес-функції, проте лише близько однієї третини успішно розгорнули його по всьому підприємству. Ця розрив між прийняттям і масштабуванням починається з того, як підприємства оцінюють і розгортають свої пілотні проекти. Команди, які успішно розгортають, розглядають аналіз режиму відмови як вимогу до проєкту. До розгортання вони створюють каталог того, як агент очікується впасти, і чого буде відповідь, коли це станеться. Це здається очевидним. Надзвичайно мало підприємств насправді це робить.

Сміття-дані, сміття-агенти

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

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

Дрейф даних і концептуальний дрейф роблять це гірше з часом. Коли розподіл реального входу зсувається від того, на якому була навчена модель, агент не викидає помилку. Він продовжує працювати і починає генерувати неправильні виходи, впевнено і у великому масштабі. Без MLOps або AIOps трубопроводу, побудованого в оркестраційний шар агента, немає механізму, щоб спіймати це до того, як шкода накопичиться. Агент, який працював прийнятно на запуску, тихо погіршується протягом тижнів, перш ніж хтось зв'язує якість виходу з проблемою даних, яка була там з початку.

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

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

Перевага уніфікованої платформи даних

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

Це пояснює, чому платформи, які підприємства обирають для уніфікації даних, мають величезне значення для результатів агентських штучних інтелектів. Уніфікований підхід Microsoft Fabric об'єднує Lakehouse, сховище даних, семантичну модель і трубопроводи в одному середовищі, надаючи підприємствам, орієнтованим на Microsoft (MSFT ), структурну перевагу при переході від експериментів до реального оперативного використання.

Databricks доставляє той же принцип через архітектуру Lakehouse і Unity Catalog, надаючи командам даних і штучного інтелекту уніфікований шар управління по всім структурованим і неструктурованим даним з інтеграцією MLflow для відстежування поведінки моделі у виробництві. Підхід Snowflake використовує свій Cortex AI і тісну взаємодію між хмарою даних і інференцією штучного інтелекту, дозволяючи підприємствам запускати агентські робочі потоки безпосередньо проти керованих, живих даних без затримки і ризиків несумісності, які виникають при переміщенні даних між системами.

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

Керування до, а не після

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

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

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

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

Від пілота до виробництва: Що це насправді потребує

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

Дослідження підприємства Deloitte показує, що доступ працівників до штучного інтелекту збільшився на 50% у 2025 році самому та частка компаній, які запускають більше 40% своїх проектів штучного інтелекту у повному виробництві, повинна подвоїтися протягом наступних шести місяців. Підприємства, які зараз виграють, не ті, у яких є найбільш просунуті моделі. Це ті, хто побудував оперативну інфраструктуру для роботи штучного інтелекту надійно і зробили це до того, як побудували агенти.

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

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