Управління даними як фундамент корпоративних RAG-систем
Ось тест, який швидко показує, чи готовий корпоративний AI-асистент до реальної роботи. Двом співробітникам із різними правами доступу дають однакове запитання про правила нарахування премій. Система має повернути кожному лише дозволену актуальну версію документа й показати джерело. Якщо один користувач бачить застарілий регламент, інший — конфіденційні дані, а повторний запит не вдається відтворити, проблема виникла ще до генерації відповіді.
Цей сценарій демонструє базову архітектурну проблему: сприйняття великої мовної моделі (LLM) як надійного сховища знань. У промислових RAG-системах (Retrieval-Augmented Generation) модель виконує роль процесора та інтерфейсу природної мови. Фактичним джерелом відповідей залишаються корпоративні системи. Якщо на етапі пошуку (retrieval) система витягує застарілі або конфіденційні дані, модель згенерує відповідну некоректну відповідь. Тому якість відповідей залежить не тільки від моделі, а й від правил підготовки та відбору даних.
Архітектура пошуку та межі відповідальності моделі
Для побудови безпечної архітектури необхідно розділяти навчальні дані (training data) та дані пошуку (retrieval data). Навчальні дані використовуються для створення моделі, інтегруючись у її ваги. Дані пошуку — це динамічний масив корпоративних документів, до яких RAG-система звертається в режимі реального часу під час обробки запиту. Векторна база даних шукає семантично схожі фрагменти тексту, але без належного налаштування вона не враховує контекст того, хто саме робить запит.
Згідно з практичними рекомендаціями OWASP (Top 10 for LLM Applications), інструкції у системному промпті не можуть бути єдиним механізмом обмеження доступу до конфіденційної інформації. Такі системи залишаються вразливими до атак типу ін'єкції промпту (prompt injection), коли користувач маніпулює запитом для обходу обмежень. Безпека має реалізовуватися на рівні прикладного програмного забезпечення. Додаток повинен відсікати вектори документів, на перегляд яких у користувача немає прав, до того, як ці фрагменти потраплять у контекстне вікно LLM.
Відстеження походження даних та контроль доступу
Для забезпечення прозорості роботи конвеєрів даних архітектори використовують інструменти відстеження походження інформації. Наприклад, відкритий стандарт OpenLineage збирає метадані про те, які завдання запускалися та як дані переміщувалися між системами. Він фіксує технічний шлях трансформації: від зчитування файлу з ERP до його збереження у векторній базі. Це допомагає відновити шлях даних до пошукового індексу, але не показує автоматично, який фрагмент став підставою конкретної відповіді.
Проте технічний моніторинг не замінює бізнес-управління даними. OpenLineage показує рух інформації, але самостійно не встановлює власників даних і не накладає політики доступу. Для побудови надійного контуру даних доцільно використовувати платформи з вбудованими механізмами безпеки. Наприклад, low-code платформа UnityBase, яка є технологічною основою рішень IQusion (зокрема систем Megapolis.DocNet та Scriptum.DMS), забезпечує контроль доступу на рівні записів (Row-Level Security) та ведення журналу аудиту. Це створює технічну можливість фільтрувати документи відповідно до прав користувача на рівні платформи ще до того, як інформація буде передана в пайплайн підготовки даних для мовної моделі.
Регуляторні рамки та управління ризиками
Вимоги до управління даними в AI-системах поступово формалізуються на законодавчому рівні. Регламент ЄС про штучний інтелект (EU AI Act), який набрав чинності у 2024 році, передбачає застосування більшості норм з 2 серпня 2026 року (з окремими винятками). Стаття 10 цього документа встановлює вимоги до управління даними, включаючи збір, підготовку та оцінку відповідності, але ці норми є обов'язковими виключно для систем, що класифікуються як високоризикові (high-risk).
Незалежно від юридичної класифікації системи, NIST пропонує добровільну рамку управління AI-ризиками. NIST AI Risk Management Framework (AI RMF 1.0) організує управління ризиками навколо чотирьох безперервних процесів: Govern (управління), Map (відображення), Measure (вимірювання) та Manage (керування). Його профіль для генеративного AI (NIST AI 600-1) окремо розглядає governance, content provenance, тестування перед розгортанням та повідомлення про інциденти. Згідно з цими документами, управління ризиками є постійним життєвим циклом, який вимагає документування меж знань системи та регулярного аудиту.
Конвеєр підготовки корпоративного контенту
Моделі штучного інтелекту оновлюються швидко. Перехід між LLM усе одно потребує адаптації інтеграції та повторного тестування. Проте контур підготовки даних зазвичай дорожче змінювати: він пов'язує джерела, метадані, права доступу та життєвий цикл документів.
У промисловій системі підключення моделі є лише одним із компонентів. Повноцінний конвеєр включає пайплайн збору сирих даних, їх парсинг, семантичний поділ (чанкінг) та збереження у векторній базі даних. Коректне розбиття на фрагменти має зберігати логічно пов'язані частини документа; його параметри потрібно перевіряти на документах конкретної предметної області. Саме цей інфраструктурний шар відповідає за те, щоб під час пошуку система знаходила релевантні фрагменти тексту, а не випадкові збіги за ключовими словами.
Оцінка готовності інфраструктури даних
Перед переходом від тестування до промислової експлуатації RAG-систем доцільно провести аудит поточної архітектури даних. Наведена нижче матриця містить базові критерії для перевірки.
| Вектор оцінки | Критерій готовності | Механізм реалізації |
|---|---|---|
| Походження (Provenance) | Можливість визначити першоджерело кожного фрагмента тексту, використаного AI. | Збереження ідентифікаторів документів у метаданих векторного сховища. |
| Актуальність | Система розрізняє версії документів та вилучає застарілі фрагменти з пошуку. | Пайплайн синхронізації, що реагує на події зміни статусу документа. |
| Права доступу (RLS/ACL) | Обмеження доступу до векторів працює незалежно від інструкцій моделі. | Row-Level Security у базі даних, інтегрована з корпоративним IAM. |
| Відтворюваність | Здатність системи повторити процес обробки даних для аудиту. | Фіксація технічного шляху трансформації даних (data lineage). |
| Аудит-лог | Запити користувачів та надані відповіді фіксуються для аналізу. | Журналювання подій із фіксацією контексту безпеки. |
Поширені питання
Чи усуває технологія RAG галюцинації мовних моделей?
Ні, технологія RAG зменшує ризик виникнення галюцинацій, надаючи моделі релевантний контекст із корпоративних джерел, але не усуває їх повністю. Для забезпечення точності необхідно впроваджувати механізми верифікації першоджерел на рівні прикладного програмного забезпечення.
Чому не варто обмежувати права доступу користувачів через системний промпт LLM?
Згідно з рекомендаціями OWASP, системні промпти вразливі до атак типу ін'єкції промпту (prompt injection). Користувач може сформулювати запит так, щоб обійти інструкції моделі. Розмежування доступу має реалізовуватися на рівні прикладного додатка до передачі інформації в контекстне вікно.
Чи поширюються вимоги статті 10 EU AI Act на всі корпоративні чатботи?
Ні, стаття 10 Регламенту ЄС про штучний інтелект встановлює обов'язкові вимоги до управління даними виключно для систем, які класифікуються як високоризикові (high-risk). Для інших систем ці норми не є обов'язковими, хоча можуть слугувати орієнтиром для побудови архітектури.
