У 2025 році захоплення автономними AI-агентами поступається місцем тверезому інженерному підходу. ІТ-директори та архітектори корпоративних систем більше не намагаються впроваджувати ШІ заради самого ШІ. Фокус змістився на інтеграцію інтелектуальних агентів у жорстко керовані, безпечні та аудійовані робочі процеси (workflows). Спроби впровадити AI-агентів безпосередньо в бізнес-процеси без зовнішнього управління призводять до неконтрольованих «тіньових» сценаріїв і нових вразливостей. Головне завдання архітектора — побудувати систему контролю, яка унеможливить несанкціоновані дії ШІ поза межами визначеного workflow.
Еволюція AI-агентів: чому автономність потребує жорстких меж
Штучний інтелект стрімко еволюціонує від експериментальних чат-ботів до повноцінних компонентів корпоративного рівня. Коли AI-агент отримує можливість не лише генерувати текст, а й самостійно викликати зовнішні API та приймати рішення без нагляду з боку процесного движка, виникає серйозний ризик.
У своєму звіті Top 10 Risk & Mitigations for LLMs and Gen AI Apps 2025 організація OWASP визначає «Excessive Agency» (надмірну автономність) та «Prompt Injection» як критичні загрози для корпоративних систем. Якщо AI-агент отримує забагато автономії без контролю, зловмисники або непередбачувані галюцинації моделі можуть ініціювати несанкціоновані дії (наприклад, зміну статусу платежу). Саме тому AI-агент не повинен керувати процесом end-to-end; його дії мають бути ізольованими та підпорядкованими жорсткому governance-каркасу.
Архітектурний підхід: розділення процесу (BPMN) та бізнес-правил (DMN)
Для побудови надійної автоматизації необхідно відокремити логіку маршрутизації від алгоритмів прийняття рішень та моделей ШІ. Індустріальні стандарти BPMN 2.0 (Business Process Model and Notation) та DMN (Decision Model and Notation) ідеально вирішують це завдання.
Згідно з даними компанії Camunda, стандарт BPMN 2.0 забезпечує єдину виконувану модель, що гарантує видимість стану кожного екземпляра процесу. Процесний движок завжди знає, на якому етапі перебуває транзакція. У цій архітектурі AI-агент виконує роль Service Task (сервісного завдання) — він лише обробляє передані йому дані, не маючи змоги самовільно змінити маршрут документа.
У свою чергу, використання таблиць DMN (стандарт від Object Management Group) дозволяє відокремити жорсткі бізнес-правила від процесу. Наприклад, AI-агент може проаналізувати заявку і запропонувати фінансове рішення, але остаточну перевірку лімітів здійснює DMN-движок. Це унеможливлює ситуацію, коли ШІ через Prompt Injection спробує перевищити дозволений кредитний ліміт, адже DMN містить жорсткі, незмінні для нейромережі ліміти.
Аналіз реального стану: як Process Mining підсвічує зони для автоматизації
Перед інтеграцією інтелектуальних компонентів необхідно виявити реальні, а не теоретичні проблеми в процесах. Як зазначає Celonis, аналіз процесів (Process Mining) є критичним для виявлення реальних відхилень від задокументованих моделей та підсвічування вузьких місць.
На практиці process mining часто показує, що до 49% транзакцій можуть обходити стандартні маршрути через операційне тертя або необхідність ручного втручання. Замість того, щоб намагатися застосувати ШІ для покриття всього процесу, архітектори можуть точково інтегрувати AI-агентів для класифікації та обробки винятків. Такий підхід суттєво підвищує шанси на успіх проєкту, адже без попереднього аналізу лише близько 13% компаній досягають запланованого ROI від хаотичного впровадження ШІ.
Безпека агентів: протидія Excessive Agency та Prompt Injection
Для протидії загрозам, визначеним OWASP, застосовується принцип найменших привілеїв та патерн «Human-in-the-loop» (людина в контурі управління). Наприклад, у BPMN-процесі AI-агент може бути обмежений виключно завданням з підготовки чорновика відповіді клієнту або класифікації вхідного документа. Наступним кроком обов'язково є User Task, де співробітник валідує роботу агента.
Крім того, на рівні архітектури потрібні жорсткі інтерфейси доступу. AI-агент ніколи не отримує прямого підключення до бази даних, а спілкується з платформою через захищені API, які відфільтровують потенційні ін'єкції в промптах.
Практична реалізація: інтеграція інтелектуальних агентів у low-code інфраструктуру UnityBase
Ефективним способом реалізувати таку безпечну архітектуру є використання корпоративних low-code платформ із потужними механізмами управління метаданими. Наприклад, low-code система Scriptum, яка дозволяє проектувати процеси за стандартами BPMN 2.0 та DMN, будується на базі платформи UnityBase.
UnityBase — це спільна розробка компаній технологічного альянсу Intecracy Group (де InBase виступає ключовим розробником). Вона виконує роль надійного платформного шару, який забезпечує наскрізний контроль за даними, процесами та API. Завдяки єдиній моделі Domain metadata, інтеграція AI-агентів (наприклад, рішень від Softengi) у системи на базі UnityBase відбувається із дотриманням найвищих стандартів безпеки:
- Контроль доступу: Механізми Role-Based Access Control (RBAC), Row-Level Security (RLS), а також Access Control Lists (ACL, доступні в комерційних редакціях Enterprise та Defence) гарантують, що AI-агенту передаються лише ті об'єкти, які потрібні для виконання локального Service Task. Агент фізично не може звернутися до закритої частини бази даних.
- Наскрізний аудит: Усі дії, зміни статусу процесу та метадані генерації автоматично фіксуються в системному журналі Audit Trail, що забезпечує прозорість дій ШІ та спрощує комплаєнс-перевірки.
- Ізольовані API: Агенти інтегруються через автоматично згенеровані REST API, що обмежує їхні можливості та мінімізує вплив на ядро системи.
Для high-load проєктів або систем із підвищеними вимогами до безпеки офіційна документація UnityBase рекомендує використовувати комерційні редакції Enterprise або Defence, які додатково підтримують розширені методи автентифікації та інтеграцію із засобами КЕП.
Матриця розподілу відповідальності між BPM-платформою та AI-агентом
| Критерій | BPM-платформа (на базі UnityBase / Scriptum) | AI-агент |
|---|---|---|
| Маршрутизація процесу | Контролює послідовність кроків за BPMN 2.0. Не дозволяє самовільної зміни графа процесу. | Виконує локальне завдання в межах поточного кроку. Не керує загальним маршрутом. |
| Прийняття рішень | DMN-таблиці на рівні движка жорстко контролюють ліміти та правила комплаєнсу. | Формує рекомендації та пропонує рішення виключно в рамках встановлених DMN лімітів. |
| Доступ до даних | Обмежує права (RLS/ACL) і передає лише необхідний мінімум даних. | Обробляє тільки ті метадані, які отримав через захищений API для конкретної задачі. |
| Обробка винятків | Зупиняє автоматичне виконання та маршрутизує завдання на людину (Human-in-the-loop). | Аналізує нетипові патерни та сигналізує системі про невпевненість у класифікації. |
| Аудит та логування | Записує всі зміни станів та атрибутів у незмінний Audit Trail. | Передає метадані генерації та системні промпти платформі для логування якості. |
Поширені питання
Як інтегрувати AI-агента в існуючий BPMN процес без переписування коду?
В архітектурі на базі стандартів BPMN 2.0 AI-агент додається як Service Task. Процесний движок викликає його через захищений REST API, передає вхідні змінні та очікує структуровану відповідь (наприклад, у форматі JSON) для переходу до наступного кроку. Це не вимагає переписування ядра системи.
Які ризики безпеки виникають при наданні AI-агентам доступу до корпоративних API?
Згідно з класифікацією OWASP, головні ризики — Excessive Agency (надмірна автономність) та Prompt Injection (маніпуляція підказками). Якщо агент не обмежений платформними правами (такими як RLS в UnityBase) і може діяти без підтвердження (Human-in-the-loop), зловмисники можуть примусити його до несанкціонованих транзакцій.
Чому використання DMN краще за хардкодинг правил прийняття рішень всередині AI-сервісу?
DMN (Decision Model and Notation) відокремлює бізнес-правила від логіки виконання. Це означає, що жорсткі корпоративні ліміти та перевірки не можуть бути обійдені AI-агентом навіть у разі 'галюцинації' моделі. Крім того, оновлення правил у DMN-таблицях не потребує зміни коду самої моделі чи інтеграційного шлюзу.