Впровадження AI-агентів у корпоративні системи документообігу (EDRMS) вимагає переходу від експериментального підходу до суворого архітектурного управління ризиками, щоб уникнути критичних вразливостей, таких як «надмірна агентність» (Excessive Agency). Інтеграція автономних моделей у контур EDRMS створює ризик неконтрольованого доступу до конфіденційних даних та виконання несанкціонованих дій, якщо архітектура не обмежує права моделі відповідно до існуючих політик безпеки користувачів. Безпечна інтеграція AI-агентів вимагає відмови від прямого доступу до бази даних на користь API-орієнтованої архітектури з жорстким контролем прав на рівні RBAC/RLS та ізоляцією в пісочниці згідно з методологією NIST AI RMF.
Еволюція від чат-ботів до AI-агентів: чому виникає ризик Excessive Agency за OWASP 2025
Межа між класичними Q&A чат-ботами та автономними AI-агентами полягає у рівні доступу до системних функцій. Якщо чат-боти генерують тексти на основі наданого контексту, то агенти мають автономію у виклику API та інструментів. Проте саме ця автономія породжує нові вектори атак. OWASP класифікує Excessive Agency (надмірна агентність) як окремий ризик для GenAI застосунків у своєму рейтингу Top 10 за 2025 рік. Це вразливість, за якої модель може виконувати дії, що виходять за межі намірів розробника.
Коли AI-агент отримує неконтрольований доступ (наприклад, загальний API-токен із правами адміністратора), система стає вразливою. Наприклад, через помилкову інтерпретацію запиту користувача або приховану інструкцію агент може ініціювати масове видалення документів або несанкціоновану передачу даних, якщо архітектура не обмежує його повноваження.
Анатомія загрози: як Prompt Injection перетворюється на несанкціонований доступ до документів
Згідно з базою знань MITRE ATLAS, ризики для AI-систем не обмежуються лише моделлю, а охоплюють дані, інфраструктуру та інтегровані сервіси. Найпоширенішим механізмом компрометації залишається атака типу Prompt Injection, коли маніпулятивні інструкції змушують модель порушувати закладені правила.
Якщо AI-агент отримує прямий доступ до сховища даних без проміжної перевірки прав, будь-яка успішна Prompt-ін'єкція може призвести до руйнівних наслідків. Практичним прикладом такої загрози є ситуація, коли AI-агент намагається отримати доступ до фінансового звіту, на який у поточного користувача немає прав (спроба порушення Row-Level Security, RLS). Жодна сучасна архітектура не гарантує абсолютно стовідсотковий захист від усіх видів атак на AI, але гранулярний контроль доступу на рівні API здатен суттєво обмежити «радіус ураження».
Каркас безпеки NIST AI RMF: чотири кроки до контрольованого ШІ в EDRMS
Для мінімізації загроз архітектори спираються на NIST AI RMF 1.0 (Artificial Intelligence Risk Management Framework). Хоча цей стандарт є добровільною рамкою, а не обов'язковим юридичним документом, він ефективно структурує управління ризиками AI через чотири функції:
- Govern (Урядування): Визначення відповідальності та політик. ШІ-агентам не можна приписувати здатність самостійно приймати етичні чи критичні бізнес-рішення без нагляду людини.
- Map (Картування): Ідентифікація контексту використання моделі та точок взаємодії агента з EDRMS.
- Measure (Вимірювання): Оцінка та тестування систем на стійкість до аномальних запитів.
- Manage (Управління): Впровадження архітектурних рішень для обмеження ризиків.
Як зазначається в AWS Well-Architected Framework, регулярний архітектурний огляд дозволяє виявити ці ризики ще до того, як вони стануть production-інцидентами.
Архітектурний паттерн «Пісочниця»: ізоляція AI-агента через RBAC та RLS на платформі UnityBase
Головне архітектурне правило полягає в тому, що AI-агент повинен взаємодіяти з EDRMS виключно через захищений API-шар, який успадковує права поточного користувача. Це реалізується через патерн ізольованої пісочниці.
Технологічним фундаментом для розгортання такої архітектури є low-code платформа UnityBase (спільна розробка компаній Intecracy Group). Завдяки вбудованим механізмам Role-Based Access Control (RBAC) та Row-Level Security (RLS) платформи UnityBase, AI-агент фізично не може вийти за межі прав користувача, який ініціював запит. Запит агента виконується в контексті сесії, де правила RLS автоматично фільтрують вибірку даних на рівні ядра платформи ще до того, як результати будуть передані моделі.
Практичний кейс: інтеграція AI Центру від InBase та збереження наскрізного аудит-трейлу
Прикладом промислового рішення, що враховує описані ризики, є AI Центр від компанії InBase (входить до Intecracy Group). Це рішення інтегрується в існуючий контур документообігу на базі UnityBase, забезпечуючи ізоляцію середовища виконання через проміжне ПЗ.
Критичним елементом такої інтеграції є забезпечення підзвітності. Як наголошує Thoughtworks Technology Radar, інженерна дисципліна та тестування інтеграцій є вкрай важливими при виборі архітектурних підходів. Для AI-агентів це означає наявність наскрізного журналу аудиту (Audit-trail). У рішеннях на базі UnityBase аудит-трейл фіксує кожен виклик API, здійснений AI-агентом: від ідентифікатора користувача та викликаного інструменту до конкретної LLM, яка обробила запит. Це гарантує підзвітність дій користувача та можливість швидкого розслідування інцидентів.
On-premises та LLM-агностичність: чому enterprise-сегмент обирає незалежність від хмарних провайдерів
Передача корпоративних документів через публічні API створює ризик розкриття конфіденційної інформації. Тому великі підприємства віддають перевагу архітектурі, яка підтримує локальне (on-premises) розгортання.
AI Центр від InBase побудований як LLM-агностичне рішення. Це дозволяє використовувати локальні open-source моделі без передачі даних третім сторонам. Такий підхід мінімізує ризики витоку інформації та відповідає вимогам ізоляції, залишаючи всі процеси генерації та обробки документів у межах захищеного периметра організації.
| Ризик за OWASP | Архітектурне рішення | Механізм контролю |
|---|---|---|
| Excessive Agency | Обмеження прав API-токенів агента рівнем доступу поточного користувача (імперсонація) | Платформа UnityBase RBAC/RLS |
| Sensitive Information Disclosure | Локальне (on-premises) розгортання LLM-моделі без передачі даних третім сторонам | LLM-агностична архітектура AI Центру InBase |
| Prompt Injection | Валідація та фільтрація вхідних запитів перед передачею в LLM, ізоляція середовища виконання | API Gateway та проміжне ПЗ Scriptum |
| Lack of Accountability | Обов'язкове логування кожного виклику інструменту та генерації відповіді | Наскрізний аудит-трейл (Audit-trail) системи документообігу |
Поширені питання
Як реалізувати Row-Level Security (RLS) для AI-агента, який шукає документи в корпоративній базі?
Взаємодія повинна відбуватися через захищений API-шар платформи (наприклад, UnityBase). AI-агент не здійснює прямих запитів до бази даних; замість цього його запити виконуються в контексті сесії користувача, де RLS автоматично фільтрує дані ще до передачі результатів у мовну модель.
Які вимоги NIST AI RMF є критичними для систем документообігу з ШІ?
NIST AI RMF не є обов'язковим юридичним стандартом, це добровільна рамка. Проте ключовими для enterprise-систем є функції Govern та Manage: жорстке розмежування доступу, ведення наскрізних логів аудиту дій ШІ та забезпечення нагляду з боку людини (Human-in-the-Loop).
Чому стандартні хмарні API від публічних вендорів можуть не підходити для enterprise-EDRMS?
Передача конфіденційної інформації через публічні хмарні сервіси створює ризики витоку даних (Sensitive Information Disclosure). У таких випадках доцільніше використовувати LLM-агностичну архітектуру з локальним (on-premises) розгортанням моделей у закритому контурі організації.