Агент не помилився, він вийшов за межі повноважень

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

ШІ-агент може ідеально дотримуватися своїх інструкцій і все одно здійснити дію, яку бізнес ніколи не санкціонував.

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

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

Це не обов’язково є помилками в міркуваннях ШІ. Це невдачі у розмежуванні технічних можливостей та бізнес-повноважень.

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

Захисні механізми залишаються необхідними. Але захисний механізм – це не модель повноважень.

Засоби контролю безпеки та права на прийняття рішень вирішують різні проблеми

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

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

Цей пробіл у керуванні стає все важче ігнорувати. У квітні 2026 року опитування Cloud Security Alliance виявило, що 65% респондентів пережили інцидент, пов’язаний з агентом ШІ, протягом попереднього року, тоді як 82% виявили раніше невідомих агентів, що працюють у їхніх середовищах. В опитуванні брали участь 418 фахівців з ІТ та безпеки, а спонсором виступила Token Security.

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

Довідник Світового економічного форуму за травень 2026 року відображає цей зсув. Він представляє Профіль можливостей та авторизації агентів, розроблений для того, щоб делеговані дії були аудитованими, застосовуваними та підзвітними.

Захисні механізми обмежують поведінку. Права на прийняття рішень визначають законні повноваження.

Надайте кожному виробничому агенту контракт на повноваження

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

Як мінімум, цей контракт повинен відповідати на сім запитань:

1. Хто несе відповідальність за результат? Вкажіть людину або бізнес-роль, а не іншу систему.

2. Що може робити агент? Читати, рекомендувати, писати чи виконувати?

3. До яких систем і даних він може отримати доступ?

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

5. Що призводить до ескалації? Невпевненість, аномалія, конфіденційні дані чи потенційний вплив?

6. Чи можна скасувати дію, і хто може її скасувати?

7. Коли закінчуються повноваження, і як їх відкликати?

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

Це не однакові перевірки.

Оновлена Модельна рамка управління ШІ для агентивних ШІ Сінгапуру проводить подібну відмінність. Вона розглядає контроль доступу, захисні механізми поведінки та людське схвалення як окремі засоби контролю та пов’язує вимоги нагляду зі сферою дії, можливістю скасування та потенційним впливом.

Перетворюйте кожну значущу дію на один з чотирьох результатів

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

Дозволити

Дії з низьким ризиком, обмежені та оборотні виконуються автономно.

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

Схвалити

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

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

Рекомендувати

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

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

Відхилити

Дія залишається поза повноваженнями агента, незалежно від його впевненості.

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

Одним моментом, який постійно упускають: “Відхилити” повинно застосовуватися поза системним запитом.

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

Приймайте рішення про повноваження в реальному часі

Статична конфігурація не може охопити кожну ситуацію.

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

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

1. Агент пропонує дію.

2. Рівень політики оцінює ідентифікатор агента, делегованого представника, запитуваний інструмент, залучені дані, контекст транзакції та потенційний вплив.

3. Політика повертає “Дозволити”, “Схвалити”, “Рекомендувати” або “Відхилити”.

4. Система записує рішення про повноваження, результат дії та наслідок.

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

У корпоративній комерції найнебезпечніша помилка ШІ – це не завжди помилкова відповідь. Це може бути технічно правильна дія, яку агент не мав права виконувати.

Відшкодування може бути точним, але перевищувати ліміт схвалення. Зміна замовлення може відповідати запиту клієнта, але скасувати фінансову умову. Обіцянка доставки може відображати наявні запаси, але не враховувати обмеження перевізника, застосоване годину тому.

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

Людський нагляд повинен бути зосереджений на винятках, а не на всьому

Вимога людського схвалення для кожної дії агента виглядає консервативно. У великих масштабах це може швидко перетворитися на формальне підтвердження.

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

Пропорційне уповноваження – це більш робоча модель.

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

Мета – не максимальна автономія. Це найвищий рівень автономії, який підприємство може відповідально спостерігати, керувати та скасовувати.

Вимірюйте, чи правильно калібровані повноваження

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

Підприємства також повинні відстежувати:

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

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

• Спроби несанкціонованих дій: Як часто агент намагається перевищити свою системну, дану чи операційну сферу?

• Рівень помилок, що впливають на бізнес: Як часто авторизовані дії завдають фінансової, нормативної, операційної шкоди або шкоди клієнту?

• Затримка прийняття рішень: Чи вимоги до схвалення керують ризиком, чи сповільнюють автоматизацію, яка вже була безпечною?

Ці показники перетворюють повноваження на керовану робочу змінну.

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

Пробіл у керуванні – не в моделі

Безпека моделі, контроль виводу та безпечне використання інструментів – все це важливо. Підприємства повинні продовжувати інвестувати в них.

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

Контракт на повноваження агента може.

Перш ніж запитувати, наскільки автономним може стати ШІ-агент, більш корисним запитанням є: що підприємство насправді готове делегувати, і як це делегування буде застосовуватися, спостерігатися та відкликатися?

Демонстрація роботи агента – це вже не найскладніше.

Ніксал Пател – керівник продукту. Висловлені погляди є його власними

Ласкаво просимо до спільноти VentureBeat!

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

Читайте більше з нашої програми гостьових публікацій – і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у внесенні власної статті!

Оригінал статті: venturebeat.com