Зі зростанням популярності автономних AI-агентів керівники з інформаційної безпеки (CISO) та ІТ-директори стикаються з критичним викликом: як інтегрувати можливості генеративного штучного інтелекту в корпоративні контури, не втрачаючи контролю над операційними процесами. Прагнення бізнесу делегувати штучному інтелекту складні завдання часто вступає у конфлікт із базовими вимогами кібербезпеки. Головне побоювання безпекових департаментів полягає в тому, що надання агентам свободи дій без належної оркестрації перетворить їх на неконтрольовані точки відмови.
Феномен Excessive Agency: чому CISO побоюються повної автономності AI
Проблема безпеки сучасних інтеграцій генеративного ШІ (GenAI) полягає в архітектурному підході до проєктування агентів. Коли розробники створюють AI-агента, вони часто надають йому прямий доступ до внутрішніх API або баз даних через механізм виклику функцій. У такій схемі велика мовна модель (LLM) самостійно вирішує, яку дію виконати, замість слідування визначеному бізнес-алгоритму.
Саме тут виникає загроза, яку експерти OWASP класифікують як Excessive Agency (надмірна автономність) — один із ключових ризиків для застосунків на базі GenAI відповідно до OWASP Top 10 for LLMs 2025. Цей ризик стоїть в одному ряду з непрямими ін'єкціями запитів (Prompt Injection, LLM01:2025) та витоком конфіденційної інформації (LLM02:2025). Якщо зловмисник зможе маніпулювати контекстом, який отримує агент, модель може виконати несанкціоновану дію: передати дані стороннім особам або модифікувати важливі записи.
За галузевими оцінками, до 49% вразливостей у впровадженнях автономних моделей пов'язані з надлишковими правами доступу, а близько 13% пілотних проєктів заморожуються на етапі безпекового аудиту через неконтрольовану поведінку агентів. Безпечна інтеграція AI у корпоративні контури можлива лише тоді, коли алгоритми діють як обмежені виконавці всередині жорстко оркестрованих процесів.
Архітектурний бар'єр: оркестрація AI-агентів через BPMN 2.0 та DMN
Щоб нейтралізувати ризик Excessive Agency, необхідно позбавити AI-агента можливості самостійно визначати послідовність кроків процесу. Замість того, щоб дозволяти моделі керувати логікою виконання, її слід вбудувати у виконувану модель BPMN 2.0 (Business Process Model and Notation).
Згідно зі специфікаціями Camunda, стандарт BPMN 2.0 є виконуваним: одна й та сама модель одночасно документує процес і керує його виконанням на рівні процесного рушія. У такій архітектурі AI-агент викликається виключно на конкретному кроці процесу (Service Task) і має доступ лише до тих даних, які йому передає рушій у межах поточного контексту задачі.
Для контролю за прийняттям рішень використовується стандарт DMN (Decision Model and Notation). Як зазначає Object Management Group (OMG), DMN дозволяє відокремити бізнес-логіку від потоку процесу, винісши її в окремі керовані таблиці рішень. Замість того, щоб покладатися на ймовірнісні висновки LLM при прийнятті операційних рішень, система пропускає згенеровані агентом дані через жорсткі правила.
Наприклад, у процесі перевірки лімітів транзакцій AI-агент може проаналізувати вхідні дані та ініціювати запит. Проте фінальне рішення про схвалення приймається виключно на основі DMN-таблиці з жорсткими бізнес-правилами, нівелюючи ризик галюцинації моделі.
Принцип Human-in-the-loop: як автоматизувати рутину без втрати контролю
Прагнення до повного автопілоту бізнес-процесів є невиправдано ризикованим. Ефективнішою є керована автоматизація, де суттєво рутинних операцій виконується автономно, проте зберігається значна частина контролю над фінальними рішеннями через принцип Human-in-the-loop (людина в контурі управління).
Типовий приклад — обробка вхідних документів. AI-агент класифікує вхідну інформацію, підтягує відповідні дані та готує проєкт відповіді. Проте фінальний підпис або підтвердження транзакції здійснюється уповноваженим співробітником через BPM-систему.
Рольова безпека (RBAC) на рівні процесу: обмежуємо права ШІ-виконавців
AI-агент повинен підпорядковуватися принципу найменших привілеїв (Least Privilege). Для цього на рівні кожного вузла BPMN-процесу впроваджується рольова модель доступу (RBAC) та безпека на рівні рядків даних (Row-Level Security — RLS).
Прикладом такої безпечної інтеграції є оркестрація AI-агентів через low-code платформу Scriptum. Scriptum використовує Camunda для управління бізнес-процесами та спирається на архітектурні механізми платформи UnityBase (спільної розробки компаній Intecracy Group, де InBase є ключовим розробником). Платформа використовує єдину доменну модель метаданих, що нерозривно пов'язує дані, API та правила безпеки.
Завдяки механізмам RLS та спискам контролю доступу (ACL), вбудованим у комерційні редакції UnityBase, права AI-агента жорстко обмежуються. Навіть у разі успішної спроби маніпуляції запитом (Prompt Injection), агент фізично не зможе звернутися до записів у базі даних, які не належать до його поточної задачі. Водночас для організацій, що потребують розробки складних спеціалізованих AI-рішень, компанія Softengi забезпечує кастомну розробку відповідно до вимог міжнародного стандарту управління штучним інтелектом ISO 42001.
Аудит та моніторинг: використання Process Mining для контролю поведінки AI
Навіть за наявності архітектурних обмежень дії штучного інтелекту вимагають безперервного аудиту. Для цього доцільно використовувати технологію Process Mining. Як пояснює Celonis, process mining дозволяє відновити реальний перебіг процесів на основі цифрових слідів (event logs), показуючи, як процес виконується насправді, а не як він був змодельований.
Аналізуючи логи, інструменти Process Mining порівнюють фактичні дії AI-агентів з еталонними BPMN-моделями, що дозволяє миттєво виявляти відхилення, обхід кроків погодження або появу shadow-процесів. Завдяки вбудованому аудиту дій (Audit Trail) на рівні платформи, фахівці з кібербезпеки завжди мають повну історію операцій кожного AI-агента.
Матриця розподілу відповідальності та обмеження ризиків AI-агентів
| Етап процесу | Роль AI-агента | Запобіжник безпеки (BPMN/DMN/RBAC) |
|---|---|---|
| Ініціація та збір даних | Первинний аналіз та класифікація | Обмеження доступу до БД через Row-Level Security (RLS) |
| Прийняття операційних рішень | Формування пропозиції/розрахунок | Жорсткі ліміти та правила в DMN-таблицях поза межами LLM |
| Затвердження та підписання | Підготовка проєкту документа | Обов'язковий крок Human-in-the-loop (верифікація людиною) |
| Виконання транзакції | Передача даних в legacy-системи | Обмежені API-ключі з мінімальними правами доступу (Least Privilege) |
Поєднуючи гнучкість генеративних моделей з суворим контролем виконуваних процесів через BPMN 2.0, таблиці DMN та надійний інфраструктурний шар безпеки, компанії отримують можливість масштабувати автоматизацію без загрози для власного цифрового периметра.
Поширені питання
Що таке Excessive Agency у контексті безпеки LLM та як йому запобігти?
Excessive Agency (надмірна автономність) — це критичний ризик за класифікацією OWASP, при якому AI-агент отримує занадто широкі права доступу до систем та API, самостійно вирішуючи, які дії виконувати. Запобігти цьому можна шляхом вбудовування агентів у жорсткі виконувані процеси BPMN та застосування принципу найменших привілеїв (Least Privilege).
Як інтегрувати AI-агента у BPMN-процес без ризику несанкціонованих дій?
AI-агент має викликатися виключно як виконавець конкретного сервісного завдання (Service Task) в межах процесного рушія. У такій архітектурі він отримує доступ лише до обмеженого контексту даних поточної задачі й не може самостійно змінювати логіку переходу між етапами процесу.
Яка роль стандарту DMN у контролі за рішеннями штучного інтелекту?
Стандарт DMN (Decision Model and Notation) дозволяє відокремити бізнес-правила від потоку процесу та логіки мовної моделі. Хоча AI-агент може пропонувати варіанти рішень, фінальна валідація, наприклад, розрахунок лімітів, здійснюється за жорстко заданими правилами в DMN-таблицях, унеможливлюючи помилки через 'галюцинації' ШІ.