Чому проєкти агентного ШІ скасовують і що дає змогу правильно зробити восьмитижневий пілот

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

За прогнозом Gartner, до кінця 2027 року буде скасовано понад 40% проєктів агентного ШІ через зростання витрат, нечітку бізнес-цінність і недостатній контроль ризиків. Якщо уважно придивитися, цей прогноз свідчить про те, що такі проєкти схвалюють на підставі демонстрації, майже не зважаючи на поточну вартість роботи чи на те, хто відповідає за результат.

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

Проблеми підприємства, які успадковує агент

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

Зазвичай проблема не в типових випадках, а у винятках: саме на них накопичуються операційні витрати, і саме їх демонстрації покликані оминати. За результатами дослідження Deloitte за 2026 рік, лише 5% організацій вважають свої бізнес-процеси добре підготовленими до роботи з ШІ-агентами. Цей показник промовистіший за будь-який тест моделі, адже свідчить, що ШІ буде готовий задовго до більшості процесів.

Бізнес-обґрунтування має враховувати роботу після автоматизації

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

Аналіз McKinsey щодо агента підтримки клієнтів у банківській сфері показує таку саму картину в масштабі: токени становили 20–25% змінних операційних витрат, а людський нагляд — 70–75%. Отже, більша частина витрат припадала не на модель. Якщо до написання коду не визначити базові показники, пілот може продемонструвати значний технічний поступ, але так і не перевірити інвестиційне обґрунтування. Щонайменше власник бізнес-процесу має чітко відповісти на такі запитання:

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

Агент має заслужити своє місце в робочому процесі

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

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

Автономність змінює підхід до безпеки

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

Рекомендації Gartner за травень 2026 року щодо управління агентами визначають чотири рівні автономності, що дає практичний спосіб вирішити, наскільки суворими мають бути засоби контролю:

1. Спостереження: агент отримує інформацію та виявляє закономірності, маючи доступ лише для читання.
2. Надання рекомендацій: агент пропонує дію, а рішення ухвалює працівник.
3. Дія з погодженням: агент готує або запускає дію, яку людина має схвалити, перш ніж її буде виконано.
4. Автономна дія: агент самостійно виконує схвалені дії в установлених межах; винятки відстежуються й передаються на розгляд відповідальним особам.

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

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

Оберіть процес, для якого використання агента буде виправданим

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

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

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

Восьмитижневий пілотний проєкт із чіткими етапами ухвалення рішень

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

Тижні 1–2: визначте, що потрібно поліпшити

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

Тиждень 3: визначте межі можливостей агента

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

Тижні 4–6: перевірте умови, за яких демонстрація дає збій

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

Тижні 7–8: залучіть до роботи реальних користувачів

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

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

Виміряйте результат, а потім вирішіть, скільки автономії надати

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

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

Масштабуйте рішення, коли компанія готова його підтримувати

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

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