Звіт ENISA Threat Landscape 2025 констатує тривожну динаміку: організації, що підпадають під регулювання директиви NIS2, стали мішенню у 53.7% усіх зафіксованих інцидентів. При цьому приблизно 27.7% витоків даних припадає на сектор цифрової інфраструктури та послуг. Для підприємств критичної інфраструктури та їхніх цифрових партнерів інтеграція штучного інтелекту в корпоративний ландшафт вимагає радикального перегляду архітектурних підходів. Використання зовнішніх хмарних API для роботи автономних AI-агентів створює неконтрольовані ризики для безпеки ланцюжків постачання (supply chain). Надійним сценарієм для секторів з підвищеними вимогами стає перехід до on-premises інтеграції, де обробка даних контролюється всередині захищеного периметра підприємства.
Дилема NIS2: Чому зовнішні AI-інтеграції є критичною вразливістю ланцюжка постачання
Директива NIS2 вимагає від суб'єктів критичної інфраструктури жорстко контролювати безпеку всіх сторонніх цифрових продуктів та послуг, що інтегруються в їхнє середовище. Коли підприємство підключає AI-агента до зовнішньої великої мовної моделі (LLM) через публічний API, воно фактично створює канал витоку інформації. Будь-який запит, що містить персональні дані клієнтів або технічну документацію об'єктів інфраструктури, передається третій стороні, що суперечить концепції суверенітету даних.
Згідно з настановами NIST Artificial Intelligence Risk Management Framework (AI RMF 1.0), при впровадженні AI в критичну інфраструктуру організації повинні в першу чергу оцінювати контекст, безпеку та підзвітність системи, а не лише фокусуватися на точності відповідей моделі. Зовнішні API позбавляють інженерів можливості контролювати ці параметри. Окрім ризику витоку даних під час транзиту, існує загроза компрометації самого провайдера AI-послуг, що робить підприємство заручником вразливостей зовнішнього вендора.
On-premises архітектура AI: Перехід від точкових API до керованої інфраструктури даних
Щоб усунути ризики ланцюжка постачання, підприємства переходять від хаотичної інтеграції за принципом point-to-point до впорядкованої локальної інфраструктури. Відповідно до класичних патернів Enterprise Integration Patterns (EIP) від Hohpe & Woolf, надійна інтеграція має будуватися на базі повідомлень (message-based integration), де канали, маршрутизатори, трансформери та адаптери забезпечують керованість потоками даних.
У такій архітектурі локально розгорнута LLM та її AI-агенти стають лише одними зі споживачів внутрішньої шини даних. Розгортання моделі у захищеному периметрі унеможливлює передачу конфіденційних даних через зовнішні мережі. Проте on-premises розгортання не усуває всі ризики кібербезпеки автоматично — воно лише переносить відповідальність за захист та контроль доступу на внутрішню інфраструктуру підприємства, що вимагає впровадження надійних архітектурних політик.
Контроль доступу на рівні метаданих: Як запобігти несанкціонованому доступу AI-агентів через RBAC та RLS
Однією з найбільших загроз при роботі з автономними AI-агентами є надання їм надлишкових повноважень. AI-агент, який здійснює пошук інформації в корпоративних базах даних для формування відповідей, може отримати доступ до ширшого спектра документів, ніж користувач, що ініціював запит. Це створює умови для несанкціонованого доступу до даних.
Безпека має забезпечуватися за принципом "data-as-infrastructure" за допомогою механізмів безпосередньо на рівні платформи даних:
- Role-Based Access Control (RBAC): AI-агент повинен успадковувати права доступу конкретного користувача, який ініціював сесію. Якщо користувач не має доступу до фінансового модуля, агент також не повинен отримувати ці дані для обробки.
- Row-Level Security (RLS): Обмеження доступу на рівні окремих рядків таблиць бази даних. Навіть якщо AI-агент має загальний доступ до таблиці, RLS гарантує, що він зчитає лише ті записи, які дозволені поточному користувачеві (наприклад, за регіональною приналежністю).
Аудитованість та Data Lineage: Побудова незмінних логів для комплаєнсу
Вимоги NIS2 передбачають забезпечення повної підзвітності та можливості проведення детального аудиту інцидентів. Для AI-систем це означає необхідність фіксації кожного кроку обробки інформації (data lineage). Кожен запит користувача, витягнутий з бази даних контекст та фінальна відповідь мають логуватися.
Як зазначають експерти Kong у дослідженнях архітектури API Gateway, централізація автентифікації, обмеження частоти запитів (rate limiting) та спостережуваність трафіку є критично важливими для безпеки. Використання локального інтеграційного шлюзу дозволяє вести наскрізний аудит кожного виклику AI-агента. Це створює надійний аудиторський слід, що дозволяє регуляторам перевірити, на основі яких саме даних AI-агент сформував відповідь.
Платформа UnityBase як фундамент для безпечної інтеграції AI в критичній інфраструктурі
Для реалізації такої архітектури підприємствам потрібен надійний технологічний стек. Одним із рішень є високопродуктивна full-stack JavaScript low-code платформа UnityBase (спільна розробка компаній консорціуму Intecracy Group, де InBase виступає ключовим розробником). UnityBase призначена для розробки та модернізації enterprise-систем із можливістю on-premises розгортання.
Завдяки архітектурі, що базується на єдиній моделі метаданих домену (Domain metadata), UnityBase дозволяє розгорнути AI-агентів у повністю контрольованому контурі, виступаючи захищеним інтеграційним шлюзом між даними та локальною мовною моделлю:
- Вбудована модель безпеки: Підтримка механізмів RBAC та RLS на рівні ядра платформи гарантує, що AI-агент отримає доступ лише до дозволених користувачеві даних.
- Розширений контроль доступу: У комерційних редакціях Enterprise (EE) та Defence (DE) доступні списки контролю доступу (ACL) та атрибутивна безпека.
- Повний аудит (Audit Trail): Платформа автоматично фіксує запити до системи, забезпечуючи логування транзакцій для регуляторного комплаєнсу.
Порівняльний аналіз архітектурних підходів до інтеграції AI-агентів за вимогами NIS2:
| Критерій порівняння | Зовнішні AI API (Cloud-based) | Локальна інтеграція (On-premises на UnityBase) |
|---|---|---|
| Контроль витоку даних | Низький (дані передаються третім сторонам) | Повний (дані не залишають захищений периметр) |
| Відповідність NIS2 (Supply Chain) | Високий ризик через залежність від вендора | Відповідність вимогам безпеки ланцюжка постачання |
| Аудит та логування запитів | Обмежений (залежить від логів провайдера) | Повний наскрізний аудит кожного виклику на рівні БД |
| Розмежування доступу (RLS/RBAC) | Складно реалізувати на рівні контексту моделі | Вбудоване розмежування на рівні платформи даних |
Перехід до on-premises інтеграції AI-агентів на базі рішень на кшталт UnityBase дозволяє підприємствам критичної інфраструктури впроваджувати автоматизацію, виконуючи вимоги NIS2 щодо безпеки ланцюжка постачання та контролю доступу до корпоративних даних.
Поширені питання
Як забезпечити відповідність вимогам NIS2 при використанні штучного інтелекту в критичній інфраструктурі?
Для забезпечення відповідності вимогам NIS2 необхідно відмовитися від зовнішніх хмарних API на користь локальної (on-premises) інтеграції AI-моделей. Це дозволяє зберегти суверенітет над даними, контролювати ланцюжок постачання цифрових послуг та створити надійний аудиторський слід для всіх дій системи.
Чому технологія RLS (Row-Level Security) є обов'язковою для інтеграції AI-агентів?
Технологія RLS обмежує доступ до інформації на рівні окремих рядків таблиць бази даних. Без RLS автономний AI-агент може отримати доступ до конфіденційних документів, які не призначені для поточного користувача. RLS гарантує, що агент взаємодіє лише з тими даними, на які ініціатор запиту має легітимні права.
Які переваги дає розгортання інтеграційної платформи UnityBase в контурі on-premises для безпеки даних?
UnityBase як технологічний фундамент забезпечує виконання архітектурних вимог NIS2 завдяки механізмам на рівні ядра: підтримці Domain metadata, RBAC, RLS та аудиту транзакцій (Audit Trail). У комерційних редакціях (EE/DE) також доступні ACL та розширені інструменти контролю доступу, що дозволяє безпечно інтегрувати AI-агентів у внутрішній ландшафт підприємства.