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

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

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

Що саме пропонує це дослідження?

Центральна ідея — делегування повноважень AI-системі не є бінарним рішенням «довіряти чи ні». Дослідники розкладають його на шари стека: застосунок, операційна система, мережа, апаратне забезпечення (чип) — і для кожного шару пропонують окремо оцінювати, які саме дії система може виконувати самостійно і які наслідки матиме помилка чи зловживання на цьому рівні.

Такий поетапний розклад дає відповідь на питання, яке зазвичай губиться в загальних дискусіях про «безпечний AI»: ризик визначається не тим, наскільки модель розумна, а тим, наскільки глибоко в стек вона отримала прямий доступ.

Чому рівень стека має значення для ризику?

Повноваження на рівні застосунку зазвичай легше обмежити і відкликати: розробник контролює API, ліміти запитів, права доступу токена. Що нижче опускаються повноваження — до операційної системи чи апаратного рівня, — то важче їх ізолювати post factum, бо помилкове рішення AI-агента вже реалізується як фізична дія в системі, а не як виклик, який можна перехопити і заблокувати.

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

Кому і навіщо потрібен такий фреймворк оцінки ризиків?

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

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

Що з цього випливає для AI-білдерів?

Наша теза: питання «чи довіряти AI-агенту повноваження» завжди варто перекладати в питання «на якому рівні стека і з яким механізмом відкликання». Команди, які дають агенту прямий доступ до платежів чи інфраструктури без чіткого протоколу відкату на кожному рівні — від застосунку до заліза, — беруть на себе ризик, який складно оцінити постфактум, коли інцидент уже стався. Це особливо стосується стартапів, які поспішають додати агентам ширші права заради демо-ефекту, не встигнувши побудувати механізм миттєвого відкликання. Фреймворк із цього дослідження корисний саме як інструмент для попередньої розмови всередині команди, а не як остаточний вердикт про безпечність конкретного продукту.

Що таке «делегування повноважень» AI на рівні чипа?

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

Чи означає це, що AI-агенти вже масово керують апаратним рівнем?

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