З переходом підприємств від простих ШІ-чат-ботів до автономних мультиагентних систем головним викликом стає не стільки технічна спроможність моделей, скільки побудова архітектурних обмежень (guardrails). Це необхідно для запобігання неконтрольованим діям штучного інтелекту без втрати швидкості операцій. Організації часто не можуть масштабувати автоматизацію, оскільки не мають фреймворку управління, який би збалансував автономність агентів із жорстким бізнес-комплаєнсом. У результаті бізнес стикається з двома крайнощами: або повільними процесами з постійним ручним підтвердженням, або ризикованим виконанням операцій ШІ в обхід бізнес-логіки.
Надійна робота мультиагентних BPM-систем досягається не шляхом обмеження інтелекту самих агентів, а через жорстку архітектурну оркестрацію процесу в BPMN 2.0, відокремлення бізнес-правил у DMN та системний контроль доступу на рівні платформи.
Феномен Excessive Agency: чому автономні агенти ламають класичну автоматизацію
У класифікації загроз Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025 організація OWASP визначає «Excessive Agency» (надмірні повноваження) як критичний ризик безпеки. Ця вразливість виникає, коли автономному агенту надають ширші повноваження, ніж це необхідно, або прямий доступ до системних функцій без належного контролю.
На відміну від класичних скриптів, які діють за жорсткими алгоритмами, LLM-агенти мають певну свободу вибору дій. Якщо бізнес-правила та ліміти вшиті безпосередньо в текстовий промпт (system prompt), виникає загроза компрометації. Шляхом маніпуляції контекстом зловмисник може змусити агента виконати несанкціоновану дію — наприклад, погодити платіж. Безвідповідальний ШІ здатний діяти всупереч політиці компанії, якщо його повноваження не обмежуються зовнішнім рушієм оркестрації.
Від Human-in-the-loop до Human-on-the-loop: зміна парадигми контролю
Традиційний підхід Human-in-the-loop (людина в циклі) вимагає, щоб кожен крок ШІ перевірявся оператором. Це безпечно, але нівелює переваги автоматизації через створення операційного «пляшкового горла». Сучасні системи управління орієнтовані на перехід до парадигми Human-on-the-loop (людина над циклом).
Відповідно до Artificial Intelligence Risk Management Framework (AI RMF 1.0) від NIST, управління ризиками ШІ має структуруватися через функції Govern, Map, Measure та Manage, забезпечуючи підзвітність та надійність моделей. Управління за винятками (exception-based) дозволяє агентам виконувати стандартні кроки автономно, а ескалація на людину відбувається лише при відхиленнях. Операційні моделі засвідчують, що такий фреймворк може залишати за людиною близько 13% специфічних або ризикових транзакцій, тоді як інші виконуються автоматично. Це дозволяє досягати до 49% приросту швидкості наскрізного процесу, зберігаючи надійний рівень Governance.
Архітектурний трикутник безпеки: BPMN, DMN та ізольовані AI-сервіси
Для побудови масштабованої системи необхідно чітко розподілити сфери відповідальності. Цей архітектурний «трикутник» спирається на такі компоненти:
- BPMN 2.0: є відкритим виконуваним стандартом, що дозволяє одній моделі одночасно документувати та керувати виконанням процесу. BPMN-рушій виступає єдиним джерелом правди для станів процесу, не дозволяючи ШІ-агенту самовільно змінювати етапи.
- DMN (Decision Model and Notation): відокремлює бізнес-правила від потоку процесу. Таблиці рішень, ліміти та матриці повноважень існують незалежно від коду та промптів, що спрощує оновлення логіки без зміни самої моделі маршрутизації.
- Ізольовані AI-сервіси: агенти виступають лише виконавцями вузьких сервісних завдань, позбавленими прямого доступу до транзакційних баз даних.
Реальний приклад: AI-агент з обробки інвойсів зчитує суму та реквізити, проте він обмежений таблицею DMN, яка блокує автоматичне погодження платежів понад заданий ліміт. Якщо сума вища, DMN автоматично переспрямовує маршрут у BPMN на крок ручного затвердження, нівелюючи ризик Excessive Agency на базовому рівні архітектури.
Платформний рівень захисту: системні guardrails в UnityBase та Scriptum
BPMN і DMN — це інструменти оркестрації, які вимагають надійного технологічного фундаменту. В корпоративному сегменті ці задачі вирішуються за допомогою платформних рішень, таких як low-code платформа Scriptum, що працює на базі UnityBase. UnityBase (спільна розробка компаній Intecracy Group) діє як full-stack JavaScript framework для побудови систем із високими вимогами до безпеки.
Для інтеграції AI-агентів UnityBase забезпечує системні guardrails (запобіжники):
- RBAC (Role-Based Access Control) та RLS (Row-Level Security): Агент отримує вузьку системну роль. Навіть у разі компрометації промпту ШІ фізично не зможе прочитати або змінити записи в базі даних, до яких у нього немає доступу на рівні рядків.
- Domain metadata: Усі взаємодії проходять через єдину доменну модель метаданих, що генерує REST API та жорстко контролює дозволені атрибути сутностей.
Платформа Scriptum, діючи як оркестратор, запускає агентів лише як ізольовані сервісні задачі (Service Tasks) в межах BPMN-схем, підкріплюючи логіку процесу системним захистом рівня UnityBase.
Моніторинг та аудит: виявлення відхилень через Process Mining
Поведінка LLM-моделей залишається ймовірнісною, тому архітектура потребує постійного моніторингу. Згідно з підходами до Process Mining, аналіз журналів подій (event logs) використовується для виявлення тіньових процесів або відхилень від стандартних операційних моделей.
Рушій процесів логує кожну дію агента у захищеному системному журналі аудиту (Audit Trail). Інструменти Process Mining дозволяють відстежити, чи не намагається агент перевищити свої повноваження або звернутися до нетипових API-ендпоінтів, що миттєво сигналізує системі управління безпекою про необхідність втручання.
| Рівень архітектури | Основна функція | Захисний запобіжник (Guardrail) |
|---|---|---|
| Рівень оркестрації (BPMN Engine) | Визначає послідовність кроків, фіксує переходи станів процесу, викликає агентів як сервіси. | Унеможливлює хаотичну зміну бізнес-логіки агентом, контролює маршрут. |
| Рівень бізнес-правил (DMN) | Зберігає таблиці рішень, ліміти, матриці повноважень окремо від промптів. | Запобігає несанкціонованому погодженню транзакцій агентом. |
| Рівень платформи (RBAC/RLS) | Обмежує права доступу агента до БД на рівні записів, веде системний аудит. | Блокує спроби агента прочитати або змінити чужі дані. |
| Рівень виконання (AI-агент) | Обробляє неструктуровані дані, класифікує запити, готує чернетки. | Забезпечує автономність виконання лише у межах ізольованого кроку. |
Розподіл відповідальності між AI-виконавцями, рушіями BPMN/DMN та захищеною платформою дозволяє enterprise-компаніям безпечно масштабувати автоматизацію процесів без ризику втрати контролю.
Поширені питання
Як запобігти виходу AI-агента за межі його повноважень (Excessive Agency)?
Запобігання Excessive Agency досягається через архітектурне розділення: AI-агент не повинен мати прямого доступу до API чи баз даних. Його дії оркеструються BPMN-рушієм, а бізнес-правила жорстко контролюються через DMN-таблиці та системні обмеження платформи (наприклад, RBAC/RLS).
У чому різниця між підходами Human-in-the-loop та Human-on-the-loop?
У моделі Human-in-the-loop людина перевіряє кожну дію ШІ перед її виконанням, що сповільнює процес. У моделі Human-on-the-loop ШІ виконує операції автономно, а людина підключається лише за винятками (exceptions), коли процес виходить за межі правил DMN або виникає високий рівень ризику.
Як інтегрувати AI-агентів у корпоративні системи на базі UnityBase?
AI-агенти інтегруються як ізольовані кроки (Service Tasks) у процесах BPMN, наприклад, у low-code платформі Scriptum. UnityBase надає агенту обмежену системну роль із чіткими правами доступу на рівні рядків (RLS), а всі дії фіксуються в захищеному журналі аудиту.