ІЇ агентам довіряють більше рішень, ніж компанії насправді можуть перевірити
Нове дослідження показує, що половина підприємств уже випустили ІЇ агента, який пройшов внутрішні тести, а потім щось поламав для реального клієнта. Лише 5% повністю довіряють тестуванню, яке мало б виявляти такі помилки.

Ключові моменти
- У дослідженні червня 2026 року, проведеному серед 157 корпоративних команд, 50% повідомили про випуск ІЇ агента або ІЇ функції, які пройшли внутрішне тестування і потім спричинили збій, помітний для клієнтів.
- Одна з чотирьох цих компаній зіткнулася з таким збоєм більше одного разу.
- 66% опитаних підприємств уже дозволяють розгортання деяких ІЇ без людського контролю або планують це робити протягом 12 місяців.
- Лише 5% респондентів сказали, що повністю довіряють автоматизованим системам тестування, які визначають готовність ІЇ до випуску.
- Більші компанії з 2500 або більше співробітниками рухаються найшвидше до повного відсутності контролю людиною, і вони також повідомляють про більше збоїв клієнтів, ніж менші фірми.
Уявіть контролера якості, який тихо признається, що контрольний список в основному невірний. Це приблизно та ситуація, яку дослідження, опубліковане VentureBeat, описує серед широкого спектра корпоративних ІЇ команд прямо зараз.
Дослідження VB Pulse за червень 2026 року запитало 157 людей у компаніях з 100 і більше співробітниками про те, як вони тестують і випускають ІЇ агентів — програмні системи, які можуть самостійно виконувати багатоетапні завдання, такі як обробка повернення платежу клієнтом, оновлення запису в базі даних або складання та відправка повідомлення без натиску людини на кнопку надсилання. Вибірка була добровільною, а не випадковою, тому цифри варто розглядати як сигнал, а не як перепис.
Сигнал неприємний. Половина опитаних компаній вже випустила агента, який пройшов кожен внутрішній тест і все ж завдав шкоди досвідові клієнта. Чверть зробила це більше одного разу.
Чому проходження тесту не гарантує, що агент буде працювати?
Тому що традиційне тестування програмного забезпечення перевіряє, чи фіксований вхідний сигнал виробляє очікуваний результат, а ІЇ агенти не працюють таким чином. Агент вибирає власну послідовність кроків, звертається до зовнішніх інструментів, отримує живі дані і може поводитися по-різному кожного разу, навіть на одному й тому ж завданні.
Агент може правильно виконати п'ять кроків і потім витекти конфіденційну інформацію на шостому. Він може скласти правильний повернення платежу і надіслати його без очікування затвердження. Кожне окреме рішення виглядає добре. Кінцевий результат — проблема.
Національний інститут стандартів і технологій США зробив подібне спостереження у своєму керівництві Generative AI Profile: поведінка, виміряна в контрольованому тестовому середовищі, часто не зберігається, коли з'являються реальні користувачі, непередбачувані запити та живі дані. Керівництво вимагає польового тестування та постійного моніторингу після запуску, а не лише передпускової оцінки.
Самі респонденти дослідження, схоже, розуміють це. Коли їх запитали, чому вони не довіряють автоматизованому тестуванню, найпоширеніша відповідь, дана 29%, була та, що результати тестів не відповідають тому, що насправді відбувається в реальному світі.
І все ж автономність продовжує розширюватися. Дві третини опитаних компаній уже працюють або активно роблять кроки до розгортання без людини в циклі взагалі. Лише 5% повністю довіряють автоматизованим перевіркам, які робили б роботу, яку раніше виконував людський рецензент.
Цей розрив, розширюється автономність, що спирається на ненадійне запевнення, є основною проблемою.
Керівництво Anthropic щодо оцінки агентів проводить корисну лінію тут: система, яка добре працює один раз, — це не те ж саме, що система, яка надійно добивається успіху. Для всього, що торкається клієнтів, грошей або даних, надійність — єдиний стандарт, що має значення.
Що компанії насправді повинні робити? Запустити кожен сценарій кілька разів. Змінити формулювання та контекст. Змоделювати відмови інструментів. Коли реальний інцидент відбувається у виробництві, перетворити його на постійний тестовий випадок, щоб та ж помилка не могла тихо повториться. І розширити нульовий контроль людиною лише там, де наслідки помилки справді незначні — складання внутрішнього резюме — це не те ж саме, що затвердження фінансової операції.
Вилучення людини з процесу не усуває ризик. Це просто усуває особу, яка могла б його виловити.



