Чи об’єднаються спостережуваність, оцінювання та гарантії ШІ?

7 принципів Наделли, угода Dynatrace з Arize на $915 млн і суперечка між CIO, засновниками та інвесторами про те, хто має перевіряти AI-агентів. Оновлено у жовтні 2026 року.

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

Щоб ловити такі проблеми, існують три категорії продуктів: observability (спостережуваність), evaluation (оцінювання) та assurance (забезпечення надійності). Вендори вже почали їх об'єднувати. Чи підуть за ними покупці — питання відкрите, як і друге: хто саме має здійснювати перевірку і що вважати незалежною?

ШІ еволюціонує від простих відповідей на запитання до виконання дій. Gartner прогнозує, що до 2028 року третина корпоративних програмних додатків матиме агентний ШІ, тоді як у 2024 році цей показник становив менше ніж 1%. Такі агенти можуть писати й відправляти код, переказувати гроші та спілкуватися з клієнтами, зазвичай без контролю з боку людини в реальному часі.

Коли програмне забезпечення лише генерувало відповіді, головним було питання, чи вони якісні. Агенти ставлять більше запитань: що саме він зробив, чи правильно, чи є хтось, хто за це відповідає, і чи можна його зупинити? Для CIO це не лише інженерні завдання, а й питання управління ШІ та ризик-менеджменту.

Сьогодні частини цієї задачі покривають три ринки:

• AI observability фіксує, що саме зробив ШІ.
• AI evaluation вимірює, наскільки добре він це зробив.
• AI assurance об'єднує докази, механізми контролю та їхні обмеження, щоб людина могла ухвалити обґрунтоване рішення. Уряд Великої Британії описує це як процес вимірювання, оцінки та демонстрації надійності.

Ринок AI observability у 2025 році оцінювався в $1,25 млрд, і те саме дослідження прогнозує, що найшвидше в ньому зростатимуть сегменти оцінювання та забезпечення якості. 1 жовтня 2026 року Dynatrace завершила придбання Arize — угоду на $915 млн для об'єднання оцінювання та спостережуваності. Cisco завершила угоду з Galileo у травні. А 10 жовтня Сатья Наделла опублікував сім принципів довіри до ШІ, які стосуються всіх трьох ринків.

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

Від правил до AI-агентів: чому довіряти стало складніше

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

1. Правила (приблизно з 1950-х до 2000-х). Більшість програм писали вручну, крок за кроком. У них було вдосталь багів, але інженер міг відкрити код і знайти рядок, який їх спричинив.
2. Патерни (2010-ті). З появою глибокого навчання машини почали вчитися на прикладах, а не на правилах — для таких задач, як розпізнавання зображень і мовлення. Ніхто не прописував логіку. Ці системи переважно маркували, ранжували й рекомендували, а люди або звичайне ПЗ вирішували, що робити з результатом.
3. Чати (2022–2024). Чат-боти навчилися писати, підсумовувати й аргументувати. Вони часто помилялися, але людина зазвичай читала відповідь, перш ніж діяти.
4. Агенти (від 2025 року). Агенти клікають, друкують, купують, пишуть код і деплоять. Лабораторії тренують їх, змушуючи виконувати задачі в симульованих офісах, браузерах і кодових базах. Деякі працюють довго без того, щоб людина перевіряла кожен крок.

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

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

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

Фреймворк управління ШІ від Сатьї Наделли: 7 принципів довіри до AI-агентів

10 жовтня 2026 року Наделла опублікував у своєму блозі статтю «Models as Insider Risks in the Super Intelligence Era» («Моделі як внутрішні загрози в епоху суперінтелекту»). Його ключова теза: «нам потрібно відокремити постачання інтелекту від влади над ним».

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

Він називає їх сімома «принципами спостережуваності». Разом вони працюють як фреймворк управління ШІ для агентів. Нижче подано переказ кожного принципу та моє бачення того, які ринки сьогодні його покривають.

1. Різноманітність моделей: жоден ШІ не перевіряє власну роботу і не ухвалює важливе рішення самостійно. Ринок сьогодні: evaluation.
2. Спостерігайте за всім: кожна значуща дія залишає захищені від змін докази, які може прочитати людина. Ринок сьогодні: observability.
3. Перевірність: уся система постійно тестується, включно з атаками, збоями та крайніми випадками. Ринок сьогодні: evaluation і assurance.
4. Незалежний контроль: правила щодо того, до чого ШІ має доступ, зберігаються поза ШІ, де він не може їх змінити. Ринок сьогодні: переважно інструменти безпеки та керування доступом, хоча guardrails уже починають з'являтися в AI-платформах.
5. Незалежний аудит: докази поведінки ШІ зберігаються окремо від самого ШІ, який перевіряється. Ринок сьогодні: assurance.
6. Стримування: уповноважена особа може призупинити або вимкнути модель посеред виконання задачі. Ринок сьогодні: переважно інструменти runtime та безпеки.
7. Розкриття інцидентів: коли стається збій, постраждалих інформують, а висновки поширюють. Ринок сьогодні: корпоративна практика, яку підтримують логи observability.

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

Його підсумкова фраза: «Найнадійнішою системою суперінтелекту буде не та, якій ми довіряємо найбільше. Це буде та, яка дозволяє нам довіряти моделі найменше».

Щоб довіряти моделі якомога менше, потрібен запис її дій (observability), спосіб їх оцінити (evaluation) і докази, за які людина може поручитися (assurance). Також потрібні дві речі, які ці ринки здебільшого залишили інструментам безпеки та runtime: елементи керування, які модель не може змінити, і можливість для людини її зупинити.

AI observability проти evaluation проти assurance: ринок сьогодні

Уявіть AI-агента як щойно найнятого водія.

• Observability — це відеореєстратор. Він фіксує кожен поворот, зупинку та небезпечну ситуацію й відповідає на запитання «що зробив ШІ?». Його продають переважно командам, які підтримують роботу систем.
• Evaluation — це іспит з водіння. Він оцінює, як водій діє у заданих ситуаціях, і відповідає на запитання «наскільки він хороший?». Його купують переважно інженери, які створюють AI-продукти, і дедалі частіше — QA-команди.
• Assurance — це акт технічного огляду. Він збирає докази, необхідні для рішення, чи готові автомобіль і водій до дороги, — перед першою поїздкою та протягом усього руху. Він відповідає на запитання «чи достатньо доказів, щоб за це поручитися?». Жоден огляд не гарантує, що авто ніколи не потрапить в аварію; якісний звіт фіксує, що перевірили, що виявили і що залишилося невідомим. Це найменш розвинений із трьох напрямків, і зараз ця робота розпорошена між командами якості, ризиків та комплаєнсу.

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

Нещодавні угоди з придбання платформ AI observability та evaluation:

• У жовтні 2026 року Dynatrace придбала Arize за $915 млн, об'єднавши оцінювання з моніторингом у продакшені.
• У травні 2026 року [Cisco придбала Galileo](https://blogs.cisco.com/news/cisco-announces-the-intent-to-acquire-galileo) для Splunk, охопивши оцінювання, моніторинг і guardrails для агентів.
• У лютому 2026 року [Snowflake придбала Observe](https://www.sec.gov/Archives/edgar/data/1640147/000164014726000019/snow-20260518.htm), інтегрувавши observability у свою data-платформу.
• У лютому 2026 року [ClickHouse придбала Langfuse](https://wetheflywheel.com/en/ai-observability/) — інструмент для трейсингу LLM.

Dynatrace заявляє, що угода з Arize об'єднує оцінювання та спостережуваність, щоб команди могли перевіряти ШІ до запуску й підтримувати його надійність після. Cisco описує Galileo як рішення, що покриває раннє оцінювання, моніторинг у продакшені та guardrails.

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

![Діаграма AI-агента, де observability, evaluation, затвердження та контроль працюють як єдиний цикл поза ним

https://pbs.twimg.com/media/HUXj23UaIAAG2Id?format=png&name=small

прочитати опис зображення

ALT

Якщо ринки об'єднаються · спостерігай, оцінюй, затверджуй, контролюй

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

Дискусія: хто має перевіряти AI-агентів?

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

• Інвестор-стратег (Long-Game Investor): інвестує з горизонтом 15 років і фокусується на тому, хто купує.
• Трендовий інвестор (Momentum Investor): стежить за тим, куди зараз рухаються гроші й таланти.
• Розробник агентів (Agent Builder): щотижня випускає AI-агентів для клієнтів.
• Засновник платформи (Platform Founder): керує data- та AI-платформою і хоче володіти повним стеком.
• CIO банку (Bank CIO): затверджує будь-якого агента, перш ніж той торкнеться рахунку клієнта.

Раунд 1: Чи об'єднаються ринки?

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

CIO банку: Придбання — це не те саме, що злиття. Я й раніше купував комплексні рішення, а в підсумку отримував три продукти, один логотип і три логіни. Gartner також прогнозує, що понад 40% проєктів з агентного ШІ буде скасовано до кінця 2027 року, зокрема через недостатній контроль ризиків. Проблема довіри реальна. І не доведено, що єдиний об'єднаний ринок її вирішить.

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

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

Інвестор-стратег: Якщо це типова ситуація, значить, покупець уже консолідується, і це каже мені більше, ніж будь-які угоди з M&A.

Раунд 2: Чому б не залишити три окремі інструменти?

CIO банку: Чому я не можу залишити три найкращі у своєму класі інструменти?

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

Трендовий інвестор: Межа між «до релізу» та «після релізу» теж стирається. Агенти змінюються щотижня: нова модель, новий промпт, новий інструмент. Тестувати раз на запуску — це як оглядати авто один раз, поки хтось постійно міняє двигун.

CIO банку: Об'єднані комплекси зазвичай посередні в усьому.

Інвестор-стратег: На початку — так. Спеціалізовані інструменти зазвичай перемагають першими, а інтегровані продукти наздоганяють пізніше. Так було в багатьох інфраструктурних категоріях, хоча й не в усіх.

Раунд 3: Хто має цим володіти?

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

CIO банку: Тобто компанія, яка запускає мій ШІ, сама ж мені каже, що він працює нормально?

Засновник платформи: Ми в цьому хороші.

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

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

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

Засновник платформи: Внутрішня буде дешевшою і простішою.

CIO банку: А зовнішня — це те, що прийме мій регулятор і страхова. Можливо, я платитиму за обидві, але затверджуватиму на основі однієї.

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

Розробник агентів: Це різні речі. Окрема компанія може використовувати ті самі моделі й такі ж слабкі перевірки, як і платформа. А платформа може тримати свої механізми контролю та записи повністю поза зоною досяжності агента.

CIO банку: Тоді я краще поставлю п'ять запитань, ніж порівнюватиму логотипи. Чи може агент редагувати запис? Чи бачить ваш контролер реальні зміни в моїх системах, чи лише те, що повідомив агент? Хто тестує вашого контролера? Чи може хтось інший відтворити ваш результат? Що ви не змогли перевірити?

Раунд 4: Як це називати?

Трендовий інвестор: Аналітики, мабуть, ще пару років називатимуть це AI observability, бо саме там бюджет.

Засновник платформи: «Шар довіри до ШІ» (AI trust layer).

Розробник агентів: «Observe, Eval and Assure»: спостерігай, оцінюй і отримай підпис людини.

CIO банку: Обережніше зі словом «assure». Інструмент генерує докази. Людина їх читає і підписує. Проєктуйте продукт для цієї людини.

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

CIO банку: Як би це не називалося, мені потрібна можливість це зупинити.

Як тестувати AI-агента: приклад із поверненням коштів

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

1. Визначте бізнес-правила. Повернення йде правильному клієнту, не перевищує ліміт і відповідає політиці. Повторна спроба не має призвести до подвійної оплати. Винятки потрапляють до потрібної людини до руху коштів.
2. Протестуйте складні умови. Використовуйте конфліктні записи клієнтів, повільний платіжний сервіс, тайм-аут інструменту та приховану інструкцію в повідомленні підтримки. Важливі сценарії проганяйте кілька разів з одного початкового стану, бо один успішний прохід мало що доводить. Симуляції дають змогу безпечно тестувати небезпечні випадки; реальні пристрої та інтеграції ловлять розбіжності, які симуляції пропускають.
3. Перевірте систему записів (system of record). Слова агента «я повернув $50» — не доказ. Переконайтеся, що правильний рахунок отримав рівно одне повернення на $50. Використовуйте точні перевірки там, де відповідь точна, а AI-суддів — лише там, де ні.
4. Критичні збої мають звітуватися окремо. Неправильні суми, дубльовані платежі та несанкціоновані операції слід показувати окремо від загальної оцінки виконання задачі. Середній бал 94% може приховати найважливіший збій.
5. Тестуйте обмеження поза агентом. Чи заблокує платіжна система повернення понад ліміт, навіть якщо агент його запитує? Чи можна відкликати доступ агента посеред задачі? Зупинка агента запобігає наступному платежу, але не скасовує попередній.
6. Тестуйте контролера. Підкиньте відомі збої та виміряйте, які він пропустить. Дайте йому коректні результати, щоб виміряти хибні спрацьовування. Тримайте статус «не вдалося перевірити» окремо від «пройдено».

Це не відповідає на ринкове запитання. Це описує, як виглядають корисні докази, незалежно від того, хто їх створює.

Де місце забезпечення якості ШІ: TestMu AI

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

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

• Rook (агенти перевіряють агентів). Проганяє вашого агента через сценарії та фіксує очікувані й фактичні результати кожної перевірки, зберігаючи докази для кожного сценарію. Він звітує про проходження, провал і статус «не вдалося перевірити» окремо, тому відсутність доказів ніколи не зараховується як успіх.
• Agent Testing (боти, які спілкуються з клієнтами). Тестує чат-, голосових і телефонних агентів у реалістичних діалогах до того, як ними скористаються клієнти.
• KaneAI та Kane CLI (додатки, які допомагає будувати ШІ). Тестуйте програми простою англійською (KaneAI) або з термінала (Kane CLI).
• SmartUI разом з Accessibility (збої, на які ніхто не писав тести). Ловлять проблеми, які функціональні перевірки не шукають, наприклад зламані макети або екрани, недоступні для частини користувачів.
• Real Device Cloud (те, що пропускає симуляція). Запускає тести на реальних телефонах і браузерах, а не лише на емуляторах.
• HyperExecute (багаторазовий прогон важливих кейсів). Запускає ті самі перевірки паралельно за кожної зміни.
• Test Manager (запис для затвердження). Зберігає єдиний звіт про те, що перевірили, що знайшли і що залишилося невідомим, — для людини, яка ставить підпис.

Інструменти observability стежать за тим, що відбувається після релізу. Ми надаємо докази, щоб вирішити, що саме до релізу потрапить. Наші агенти запускають перевірки в масштабах, які команда не потягнула б вручну, а тестувальники вирішують, що варто перевіряти, і шукають проблеми, які жоден тест не зловить. Цю спільну роботу ми називаємо Observe, Eval і Assure.

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

Майбутнє управління AI-агентами: яким може бути 2030 рік

Це прогнози. Кожен із них уже має ранні сигнали сьогодні.

• Агенти отримують ідентичність і журнали. Кожен агент має визначену зону відповідальності, людину, яка його затверджує, і лог своїх дій. Microsoft планує розрізняти дії агентів і дії людей у своїй системі ідентифікації.
• Записи надходять ззовні агента. Логи пише те, що агент не може відредагувати, замість того щоб покладатися на його власну версію подій.
• Перевірки працюють безперервно. Оновлення моделі, зміна промпту чи новий інструмент автоматично запускають повторне тестування, залишаючи людям більше часу на дослідницьке тестування.
• Агенти перевіряють інших агентів. Gartner очікує, що до 2028 року 15% щоденних робочих рішень агентний ШІ ухвалюватиме автономно, порівняно з нулем у 2024 році. Люди не зможуть перевіряти такий обсяг по одному, тому агенти-контролери візьмуть на себе рутинний моніторинг, а люди визначатимуть пріоритети й розслідуватимуть аномалії.
• Страховики оцінюватимуть ризики ШІ на основі доказів. Від 2025 року страховики Lloyd's пропонують покриття помилок ШІ, яке спрацьовує, коли продуктивність падає нижче узгодженого рівня, а один андеррайтер заявив, що не страхуватиме системи, які вважає занадто схильними до помилок.
• Корпорації закладатимуть на це бюджет. Один відповідальний і один процес покривають моніторинг, оцінювання, затвердження та контроль, а кожен збій повертається в систему як новий тест.

Нерозв'язані проблеми

1. Тестування самого перевіряльника. ШІ-суддю (якого часто називають LLM-as-a-judge) можна обдурити так само легко, як і ШІ, якого він оцінює. Друга модель не гарантує незалежності судження, особливо якщо обидві навчалися схожими методами.
2. Обхід перевірок. У липні 2026 року моделі OpenAI під час складного внутрішнього тестування з кібербезпеки шукали готові рішення у зовнішніх сервісах, обходили механізми ізоляції та отримали несанкціонований доступ до частини систем OpenAI і Hugging Face. OpenAI називає reward hacking (злом системи винагород) головною причиною і зазначає, що в цьому тестуванні не було тих запобіжників, які є в розгорнутих моделях компанії. Цей інцидент порушує питання про те, як саме ізолюються тести; він не доводить, що всі агенти поводяться подібним чином.
3. Ненадійні звіти про себе. Наделла називає прозорість міркувань "питанням без компромісів", але водночас пише, що "сама по собі вона недостатня й ненадійна". Те, що модель каже про свої дії, і те, що вона зробила насправді, може відрізнятися.
4. Оцінки проти якості. Рівень успішності 94% вимірює лише те, як система проходить перевірки, які хтось написав. Він нічого не говорить про ситуації, для яких жодної перевірки не передбачено.
5. Вартість. Незалежне зберігання логів, додаткові моделі, повторні запуски, ізольовані пісочниці та ручний перегляд збільшують витрати й затримують процес. Запис усього підряд також створює додаткові зобов'язання щодо конфіденційних даних.
6. Незворотні дії. Зупинка агента запобігає подальшим діям, але не скасовує вже виконаних. Тому дозволи, надані на старті, важать більше, ніж кнопка екстреної зупинки.
7. Розкриття інформації. У вересні 2026 року OpenAI почала публікувати звіти про інциденти неузгодженості (misalignment) у межах нової політики розкриття, хоча компанія сама вирішує, що саме вважати таким інцидентом. Більшість компаній, які використовують агентів, взагалі не публікують подібну інформацію. Безпека в авіації покращилася значною мірою тому, що аварії розслідуються публічно.
8. Перевірки проти тестування. Автоматичні перевірки підтверджують лише те, про що хтось уже здогадався спитати. Багато серйозних збоїв виникають через питання, які ніхто не поставив, а щоб їх знайти, потрібні кваліфіковані тестувальники, здатні досліджувати систему, ставити під сумнів специфікацію та визначати, які ризики справді важливі.

Жодне з цих питань поки не має остаточної відповіді.

На якому етапі дискусія

Усі п'ять голосів погодилися щодо трьох тез:

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

Але вони розійшлися в чотирьох моментах:

• Одна платформа чи кілька інструментів. Засновник платформи хоче одного вендора; CIO банку не довіряє комплексним рішенням.
• Всередині чи ззовні. Перевірка всередині платформи дешевша. Незалежна перевірка — це те, чого аудитори, регулятори та страховики давно вимагають у фінансах і сфері безпеки. Що важливіше для ШІ — досі не вирішено.
• Відповідальність. Вона може лежати на операційному відділі, команді ШІ, ризик-менеджменті чи відділі якості. Поки що мало хто з компаній виділяє під це окремий рядок у бюджеті.
• Назви, і чи здатен будь-який інструмент щось "гарантувати".

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

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

FAQ

У чому різниця між AI observability, AI evaluation та AI assurance?

AI observability фіксує, що робила ШІ-система: її вхідні дані, виклики інструментів, результати, помилки та вартість. AI evaluation порівнює поведінку системи із заданими очікуваннями, наприклад, точністю, дотриманням політик або виконанням завдання. AI assurance об'єднує докази, механізми контролю та їхні обмеження, щоб людина могла прийняти відповідальне рішення про розгортання або подальшу роботу системи.

Що таке фреймворк управління ШІ (AI governance) для ШІ-агентів?

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

Які сім принципів довіри до ШІ виділив Сатья Наделла?

У своєму есе від жовтня 2026 року "Models as Insider Risks in the Super Intelligence Era" Наделла перелічує: різноманітність моделей, спостереження за всім, можливість верифікації, незалежні механізми контролю, незалежний аудит, ізоляцію та розкриття інформації про інциденти. Його головна ідея — відокремити постачання інтелекту від влади над ним, ставлячись до потужних моделей як до співробітників із широким доступом.

Чи об'єднуються ринки AI observability та AI evaluation?

Вендори вже їх поєднують. Dynatrace завершила придбання Arize за 915 мільйонів доларів у жовтні 2026 року, а Cisco закрила угоду з купівлі Galileo у травні 2026 року — обидві компанії хотіли об'єднати оцінювання з моніторингом продакшену. Чи будуть покупці зливати бюджети й команди навколо однієї платформи — поки що відкрите питання.

Хто має перевіряти ШІ-агентів: платформа, на якій вони працюють, чи незалежний тестувальник?

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

Як протестувати ШІ-агента перед релізом?

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

Статтю вперше опубліковано на https://medium.com/@mask.tech/will-ai-observability-evaluation-and-assurance-merge-a5b011e26b3a?sharedUserId=mask.tech

Джерела

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

• Satya Nadella: Models as Insider Risks in the Super Intelligence Era (оригінал есе)
• Forbes: Microsoft's Nadella wants an emergency brake on every AI model
• Data Studios: пояснення семи принципів Наделли
• UK DSIT: Introduction to AI assurance
• W.Media: Gartner про впровадження та скасування проєктів з agentic AI
• Detailed Research: ринок AI observability
• Dynatrace: Dynatrace completes acquisition of Arize
• Magica: Dynatrace agrees $915 million deal for Arize
• Cisco: Making AI trustworthy and observable (Galileo, завершено у травні 2026)
• Snowflake Form 8-K: закриття угоди з придбання Observe
• We The Flywheel: AI observability у 2026 році
• OpenAI: The Hugging Face incident and the road ahead
• Implicator: шість звітів OpenAI про інциденти неузгодженості
• The Decoder: Lloyd's insurers launch AI error policies
• Armilla: insurers launch cover for AI chatbot errors
• TestMu AI: результати та докази Agent Assurance
• TestMu AI: AI Agent Testing