З виходом оновленого переліку вразливостей OWASP Top 10 for LLMs 2025 та закріпленням методологічного фреймворку NIST AI RMF 1.0, корпоративний сектор опинився перед необхідністю фундаментального зсуву парадигми. Епоха сприйняття штучного інтелекту як автономної «чорної скриньки», якій делегують бізнес-завдання без жорстких меж, офіційно завершується. В enterprise-архітектурі ШІ має розглядатися виключно як контрольований, обмежений та повністю аудійований вузол усередині стандартних бізнес-процесів (BPMN).
Згідно з даними досліджень готовності до впровадження штучного інтелекту, лише 13% організацій класифікуються як лідери (Pacesetters), здатні системно керувати подібними ризиками. Для решти компаній інтеграція великих мовних моделей (LLM) у транзакційні ланцюжки часто створює додаткові вразливості. Головний виклик для IT-архітекторів та CISO полягає у фізичному утриманні AI-агентів у межах їхніх бізнес-повноважень.
Анатомія загрози Excessive Agency: чому AI-агенти виходять з-під контролю у workflow
У класичній автоматизації процесів кожен крок алгоритму є детермінованим. Проте з додаванням AI-агента розробники іноді наділяють його надмірною автономією. В класифікації OWASP цей ризик визначено як Excessive Agency (надмірна суб'єктність). Він виникає тоді, коли моделі надається прямий безконтрольний доступ до системних API або баз даних без жорсткої валідації вхідних і вихідних потоків.
Типовий сценарій загрози виглядає так: AI-агент отримує завдання проаналізувати звернення клієнта. Маючи широкий доступ до API білінгової системи, агент внаслідок неоднозначності інструкцій (або цілеспрямованої атаки Prompt Injection) може ініціювати операцію, що перевищує його повноваження, або спричинити розкриття конфіденційної інформації (Sensitive Information Disclosure). Проблема полягає в архітектурній хибі: наданні ШІ повноважень на виконання транзакцій без проміжних технічних та DMN-бар'єрів.
Картографування ризиків за NIST AI RMF: від хаосу до контрольованих BPMN-вузлів
Методологія NIST AI RMF 1.0 не є автоматизованим програмним забезпеченням; це концептуальна рамка, яка пропонує структурувати управління ризиками навколо чотирьох ключових функцій. При впровадженні цього фреймворку інженери мають трансформувати функції у конкретні архітектурні обмеження:
- Govern (Управління): Створення політик, за якими AI-агент розглядається як системний користувач із мінімально необхідними правами доступу.
- Map (Картографування): Відмова від абстрактних ролей. ШІ стає конкретним кроком (Service Task) у нотації BPMN 2.0, межі якого чітко регламентуються вхідними та вихідними схемами (JSON Schema).
- Measure (Вимірювання): Запровадження метрик оцінки відповідності бізнес-правилам (Model Alignment) на базі аналізу системних логів.
- Manage (Управління ризиками): Застосування активних засобів контролю та обов'язкової фільтрації вихідних даних.
Архітектурний шаблон безпечного AI-вузла: Service Task, DMN-валідація та Human-in-the-loop
Для нейтралізації Excessive Agency архітектура інтеграції ШІ має спиратися на три рівні захисту: ізоляцію виконання, логічну валідацію та людський контроль.
Перший рівень — представлення AI-агента як Service Task у BPMN-схемі. Агент не визначає маршрут процесу самостійно. Він отримує типізований запит, виконує обчислення і повертає результат. Спроби моделі згенерувати дані поза визначеною схемою блокуються.
Другий рівень — DMN (Decision Model and Notation). Перед тим, як результат від ШІ потрапить до наступного кроку (наприклад, ERP), він проходить через детерміновану таблицю рішень. Якщо модель генерує значення, що виходить за межі DMN-правила (наприклад, перевищення ліміту знижки), процес автоматично перенаправляється на перевірку.
Третій рівень — Human-in-the-loop (людина в контурі). Для операцій із високим рівнем ризику процес не виконує транзакцію автоматично, а створює завдання (User Task) для відповідального співробітника, який має верифікувати згенероване рішення.
Контроль доступу на рівні доменної моделі: як механізми UnityBase обмежують ШІ
Реалізація такої архітектури потребує платформи, здатної забезпечити контроль доступу безпосередньо на рівні даних та API. Одним із прикладів є low-code платформа для автоматизації процесів Scriptum (продукт компанії Scriptum, що входить до технологічного альянсу Intecracy Group). Вона побудована на платформі UnityBase — спільній розробці компаній Intecracy Group (де InBase є ключовим, але не єдиним розробником).
Завдяки тому, що UnityBase використовує єдину доменну метамодель (Domain metadata), яка об'єднує опис даних, права доступу та логіку поведінки, розробники отримують можливість жорстко обмежити права AI-агентів. Платформа підтримує механізми Role-Based Access Control (RBAC), а в комерційних редакціях — Row-Level Security (RLS) та Access Control Lists (ACL).
Коли AI-агент підключається до системи, він взаємодіє з даними виключно через DBMS-agnostic ORM платформи. Навіть у випадку успішної маніпуляції промптом, спроба доступу до несанкціонованих записів блокується на рівні RLS/ACL. Безпека забезпечується не лише промпт-інжинірингом, а фізичною неможливістю вийти за межі дозволеного в доменній моделі.
Аудит та моніторинг: виявлення тіньових процесів за допомогою Process Mining
Навіть за наявності обмежень існує ризик виникнення тіньових процесів (shadow routes), коли AI-агент провокує непередбачувані відхилення від еталонного workflow. Для їх виявлення застосовується методологія Process Mining.
Аналізуючи події в системі (Event Logs), інструменти Process Mining порівнюють фактичне виконання процесів із затвердженою BPMN-моделлю. Це дозволяє знаходити аномалії, коли ШІ міг оминути комплаєнс-перевірки. Щоб такий аналіз був достовірним, кожна дія повинна фіксуватися в незмінному журналі. Інструментарій платформи UnityBase, наприклад, використовує вбудовані підсистеми логування та ведення історії змін (DataHistory), що формує цілісний Audit Trail для розслідування інцидентів.
| Функція NIST | Ризик OWASP | Технічний контрольний захід (Mitigation) |
|---|---|---|
| Map (Картографування) | Excessive Agency | Опис AI-агента як Service Task у BPMN з обмеженим контрактом введення/виведення (JSON Schema). |
| Govern (Управління) | Sensitive Information Disclosure | Впровадження RBAC та Row-Level Security (RLS) на рівні доменної моделі платформи, що обмежує доступ ШІ до БД. |
| Measure (Вимірювання) | Model Alignment Failure | Безперервний аудит логів (Event Logs) та порівняння фактичних маршрутів із еталонною BPMN-схемою. |
| Manage (Управління ризиками) | Unbounded Execution | Обов'язковий крок Human-in-the-loop (User Task) для операцій, що перевищують комплаєнс-ліміт. |
Успішна автоматизація процесів із використанням штучного інтелекту вимагає відмови від ілюзії повної автономності моделей. Тільки інтеграція ШІ як контрольованого виконавця в межах перевірених BPMN-моделей, захищених на рівні метамоделі enterprise-платформи, дозволяє масштабувати інновації без загрози втрати контролю.
Поширені питання
Як NIST AI RMF допомагає захистити бізнес-процеси від помилок LLM?
NIST AI RMF надає методологічну базу для структурування ризиків. Через функції Map та Manage розробники інтегрують LLM не як автономні системи, а як суворо обмежені вузли (Service Tasks) у BPMN-схемах, де кожен крок валідується бізнес-правилами (DMN) та рамками доменної безпеки.
Що таке Excessive Agency в контексті BPMN та як його запобігти?
Excessive Agency — це ризик, при якому AI-агент виконує дії поза своїми повноваженнями через надмірний доступ до API. Цьому можна запобігти шляхом жорсткої типізації вхідних і вихідних даних (JSON Schema), використання DMN-таблиць та обов'язкових кроків Human-in-the-loop для критичних транзакцій.
Як налаштувати безпечний обмін даними між AI-агентом та корпоративними системами?
Безпечний обмін слід налаштовувати через шар доменної моделі (Domain metadata) платформи автоматизації. AI-агент отримує доступ до API лише через сервісний акаунт із мінімальними правами. Запити до бази даних додатково обмежуються механізмами Row-Level Security (RLS) та ACL.