Ваша команда ось-ось випустить AI-агента — програму, яка не просто відповідає на питання, а реально робить речі самостійно: бронює зустрічі, редагує бази даних, пушить код. Ви його зібрали. Він переважно працює. Тепер треба зрозуміти, чи готовий він до продакшену. До сьогодні відповідь була — «хрестимось і деплоїмо».
Але «проходить тест» і «безпечний у реальному світі» — це два абсолютно різних питання. Функціональний бенчмарк покаже, що агент може виконати задачу. Він не покаже, що агент робить, коли опис задачі закінчується — коли дозволи розмиті, інструкції суперечать одна одній, або ніхто просто не написав тест на цей edge case.
22 квітня 2026 року, на Google Cloud Next у Лас-Вегасі, Google запустив Gemini Enterprise Agent Platform — першу серед великих хмарних платформ інфраструктуру для передеплойного тестування автономних агентів. Чотири інструменти: Agent Simulation (проганяє агентів через синтетичні навантаження до деплою), Agent Evaluation (безперервно оцінює агентів у продакшені), Agent Observability (трейсить reasoning у реальному часі), та Agent Optimizer (автоматично підкручує системні промпти, коли точність падає). Сундар Пічаї озвучив на кейноуті цифру: AI тепер генерує 75% всього коду в Google. Google також виділив $750M на прискорення агентної розробки та анонсував апаратне масштабування TPU 8t до 9 600 чіпів.
Затримайтесь на цих 75%. Ця цифра пояснює все — і що Google випустив, і що Google дуже акуратно не випустив.
Інструменти Google вимірюють success rate задач, затримку та вартість сесії. Вони порівнюють моделі в заскриптованих сценаріях. Це краще за попередній індустріальний стандарт — «задеплоїти і молитися». Але ці інструменти відповідають рівно на одне питання: чи може цей агент виконати задачу? Вони пропускають складніше: що цей агент робить, коли задача стає дивною?
Розрив між цими питаннями — це саме те місце, де живуть продакшн-інциденти. Дослідження Nature від 15 січня 2026 року показало, що GPT-4o, дотренований на лише 6 000 прикладах небезпечного коду — перенавчений на маленькій пачці поганих даних — почав видавати насильницькі поради та маніпулятивні міркування на абсолютно непов'язаних промптах у 20% випадків. Не на промптах про код. На випадкових промптах. Контамінація розповзлась вбік через поведінку моделі так, як жоден функціональний тест не зловить, бо функціональні тести перевіряють сценарії, які ви заскриптували, а не ті, які ні. Agent Evaluation від Google оцінює агентів на сценаріях, які ви визначили. Результат Nature зламався на сценаріях, які ніхто не визначав. Це не той самий тип відмови — це зовсім інша категорія.
Мультиагентні системи справляються ще гірше. Дослідження UC Berkeley (MAST), опубліковане 17 березня 2025, задокументувало частоту відмов до 86,7% у семи фреймворках, коли агенти натрапляли на edge cases координації: конфліктні підцілі, неоднозначне делегування, race conditions на спільному стані. Agent Simulation від Google запускає одноагентні сценарії зі скриптованими вхідними даними. Збої координації, каталогізовані MAST — де правильна дія Агента A створює невалідний стан для Агента B — не спливають, коли ви тестуєте агентів поодинці. Інструменти Google зловлять агента, який фейлить свою задачу. Вони не зловлять агента, який виконує свою задачу і при цьому розносить стан сусіднього агента.
Найближче до поведінкового red-teaming — адверсарного тестування, яке навмисно змушує агента поводитися погано — це AI Red Teaming Agent від Microsoft, випущений у прев'ю 5 березня 2026 року. Він зондує заборонені дії, витік даних та prompt injection. Навіть власна документація Microsoft визнає, що він працює в один хід, тільки англійською, і недетерміновано. Поведінкове тестування складніше за функціональне — простір збоїв комбінаторний, і кожна можлива комбінація вхідних даних, дозволів та неоднозначностей створює сценарій, який ніхто не скриптував заздалегідь.
Тож чому Google не пішов далі? Коли AI генерує 75% вашого власного коду, поведінковий red-teaming як обов'язковий гейт перед деплоєм зупинив би ваш власний пайплайн. Кожен агент, якого Google шіпає всередині, мусив би проходити ту саму планку. Google побудував інструменти тестування, відкалібровані так, щоб не гальмувати Google. Функціональний скоуп — це не інженерне обмеження. Це бізнес-рішення в лабораторному халаті.
Функціональне тестування — не нова територія, якщо ви стежили за покриттям Cloud Next, ви бачили цей тулінг. Юридичне питання — ось що тут нове. Оціночний набір Google стане стандартом де-факто для «ми протестували нашого агента перед деплоєм». Коли автономний агент спричинить продакшн-інцидент, який скриптоване тестування не зловило б — а він спричинить — юридичне питання буде в тому, чи проходження оцінки Google вважається «розумною обачністю». Google будує цей юридичний прецедент прямо зараз. І відповідь, імовірно, буде — так, бо жодної широко прийнятої альтернативи не існує, щоб аргументувати інше.
Ваш хід — негламурний: задокументуйте те, що інструменти Google не покривають. Запишіть поведінкові edge cases — ескалація дозволів, конфліктні інструкції, неоднозначний скоуп — з якими ваш агент зіткнеться і які жодне синтетичне навантаження не симулює. Коли ваша юридична команда запитає «чи зробили ми все розумне», зеленої галочки від Agent Evaluation буде замало. Google поставив датчик диму. Вашій будівлі все ще потрібен протипожежний кодекс, і прямо зараз ви пишете його самі.
