Говернанс даних для AI: класифікація, доступ, зберігання та лінійність

Ми регулярно це бачимо: команда будує корпоративного асистента, індексує «все, що можна», а потім виявляється, що у векторній базі опинилися договори з конфіденційними положеннями, кадрові дані та історія листування з клієнтами — доступні для кожного працівника, який поставить відповідне запитання. Модель працює правильно. Проблема — у відсутності порядку над тим, що взагалі дозволено їй показувати. Говернанс даних — це робота, яку потрібно виконати до того, як перший документ потрапить до індексу, а не аудит, який проводять після інциденту.

Кожен документ, який ви розглядаєте як джерело для AI, повинен мати присвоєний клас чутливості. Це фундамент — від нього залежать усі подальші рішення щодо доступу, зберігання та хостингу. Без класифікації неможливо адекватно відповісти на запитання «чи може цей файл потрапити до хмарної моделі».

Зазвичай ми працюємо з чотирма рівнями. Чим вище рівень, тим суворіші правила обробки і тим більша ймовірність, що дані мають залишатися локально.

Класифікація не повинна бути ідеальною з першого дня. Достатньо, щоб вона була однозначною та призначалася автоматично там, де це можливо — за місцем у вихідній системі, міткою в SharePoint або правилом на рівні папки. Документ без класу за замовчуванням вважаємо конфіденційним, ніколи — публічним. Це безпечніший fallback.

Найпоширеніша помилка у впровадженнях RAG — це «плоский» індекс: одна колекція векторів, до якої кожен має однаковий доступ. Асистент успадковує максимально широкий доступ: достатньо вміло сформульованого запитання, щоб отримати фрагмент документа, якого запитувач ніколи не мав би бачити.

Правильний підхід — перенесення прав з вихідної системи до шару пошуку. Кожен фрагмент містить метадані про те, хто може його бачити (відділ, роль, рівень доступу), а запит фільтрує результати за ідентичністю користувача до передачі їх моделі. Модель ніколи не отримує контексту, до якого запитувач не має права — тому не може його розкрити навіть під тиском хитрого промпту.

На практиці це означає три речі: окремі колекції або фільтри метаданих для різних класів чутливості, мапінг корпоративних ролей на права в індексі та принцип «відмовляти, якщо не знаєш». Якщо система не може визначити права користувача, вона не показує чутливий фрагмент. Детальніше про те, як такі обмеження ми впроваджуємо на рівні самої моделі, описано в тексті про безпеку агентів AI.

Зберігання — це питання, на яке більшість компаній не має готової відповіді в контексті AI. Вхідні дані (документи в індексі) та операційні дані (логи розмов, запити, згенеровані відповіді) підлягають окремим політикам — і окремим ризикам.

Вхідні дані повинні існувати стільки, скільки вони актуальні та потрібні. Неактуальна процедура трирічної давнини в індексі — це не лише гірша якість відповідей, але й юридичний ризик, якщо містить персональні дані, підстава обробки яких вже закінчилася. Логи розмов — окрема тема: за замовчуванням застосовуємо нульову або мінімальну тривалість зберігання змісту запитів, оскільки користувачі вставляють в асистент дані, яких ніхто не передбачав.

Хороша політика зберігання відповідає на чотири запитання для кожного типу даних:

• Навіщо це зберігаємо? Мета обробки має бути конкретною — «бо може знадобитися» не є метою, сумісною з мінімізацією.
• Як довго? Конкретний термін з датою закінчення, не «безстроково».
• Що відбувається після терміну? Автоматичне видалення з індексу та з векторної бази, а не лише з вихідної системи.
• Як реалізуємо право на видалення? Вибіркове видалення фрагментів конкретної особи — вектори теж потрібно видалити, а не лише вихідний файл.

Останнє — напрочуд поширене упущення. Видалення файлу з SharePoint не видаляє його ембедінгів з векторної бази. Якщо пайплайн не підтримує вибіркового видалення, запит на видалення даних з RODO залишається технічно невиконаним.

Lineage (походження даних) — це здатність відстежити, з якого документа, в якій версії та з якого джерела походить кожен фрагмент в індексі — а зрештою кожне речення в відповіді асистента. Без цього неможливо відповісти на два критичні запитання: «чому модель це сказала?» та «чи ця інформація ще актуальна?».

На практиці кожен фрагмент у векторній базі повинен містити метадані походження: ідентифікатор вихідного документа, версію, дату, систему походження та клас чутливості. Коли асистент цитує фрагмент, він може вказати конкретне джерело — це фундамент довіри користувача та умова аудитованості. Лінійність — це також основа відповідності принципу підзвітності в RODO: ви повинні вміти продемонструвати, які персональні дані обробляються системою та звідки вони походять.

Надійна лінійність окупається й операційно: коли вихідний документ змінюється, ви точно знаєте, які фрагменти потрібно переіндексувати, замість того, щоб перераховувати весь корпус. Фундамент чистих вхідних даних, на яких lineage взагалі працює, описаний у тексті як підготувати корпоративні дані під AI.

Мінімізація — це принцип, який рятує найбільше проєктів: до AI потрапляє лише те, що необхідне для мети. Асистент, який відповідає на запитання про внутрішні процедури, не потребує повної бази CRM з історією клієнтів. Чим менше персональних даних у пайплайні, тим менший ризик і тим простіша відповідність вимогам.

На практиці мінімізація PII працює на двох рівнях. По-перше — селекція на вході: не індексуємо дані, які не потрібні для завдання асистента. По-друге — маскування на льоту: перш ніж фрагмент потрапить до зовнішньої генеративної моделі, автоматично виявляємо та замінюємо імена, номери телефонів, PESEL та адреси електронної пошти. Для даних, що підпадають під професійну таємницю, весь пайплайн може працювати локально, що усуває проблему передачі даних назовні — про це ми пишемо в тексті про self-hosted LLM та RODO.

DPIA, або оцінка впливу на захист даних, є обов’язковою, коли обробка може спричинити високий ризик для прав осіб — а впровадження AI на кадрові, медичні чи фінансові дані зазвичай належать до цієї категорії. DPIA — це не формальність: це вправа, яка змушує відповісти на запитання про мету, правову підставу, data residency та заходи безпеки, перш ніж система запрацює. Зроблена правильно, вона часто виявляє прогалини, які дешевше виправити на етапі проєкту, ніж після впровадження. Повний контекст обов’язків у тексті AI Act та RODO 2026.

Практичний чекліст, який ми проходимо перед кожним індексуванням. Якщо не можете поставити галочку — дані не потрапляють до індексу, доки прогалину не буде усунуто.

• Класифікація — кожне джерело має присвоєний клас чутливості; відсутність класу = обробляється як конфіденційне.
• Правова підстава — існує та задокументована для кожної мети обробки.
• Доступ за роллю — права з вихідної системи відображені у фільтрах індексу; принцип «відмовляти, якщо не знаєш».
• Мінімізація — індексуються лише дані, необхідні для завдання асистента.
• Маскування PII — автоматичне перед відправкою до зовнішньої моделі; перевірене на вибірці.
• Зберігання — термін зберігання та автоматичне видалення визначені для вхідних даних і логів.
• Право на видалення — пайплайн підтримує вибіркове видалення фрагментів, включаючи вектори.
• Лінійність — кожен фрагмент містить метадані походження; відповіді можна прив’язати до джерела.
• DPIA — виконана для областей високого ризику перед впровадженням.
• Хостинг — клас чутливості визначає, чи можуть дані залишити інфраструктуру.

Це не список для одноразового відмічання. Повертаємося до нього при кожній зміні обсягу даних, бо нове джерело — це новий ризик. Говернанс, який живе, дешевший за інцидент, який не живе.

Класична політика безпеки зосереджується на захисті даних у стані спокою та під час передачі — шифрування, доступ, резервні копії. Говернанс даних для AI додає специфічний для моделей шар: контроль над тим, що модель може «побачити» через RAG, маскування PII перед відправкою до моделі та лінійність відповідей. Це розширення існуючої політики, а не її заміна.

Не для кожного. DPIA є обов’язковою, коли обробка може спричинити високий ризик для прав осіб — зазвичай це стосується кадрових, медичних, фінансових даних або профілювання у великих масштабах. Асистент на публічному FAQ її не потребує. У разі сумнівів краще провести спрощену оцінку та задокументувати рішення, бо це саме по собі є доказом підзвітності, яку вимагає RODO.

Ключове те, що видалення вихідного файлу не видаляє його ембедінгів із векторної бази. Пайплайн повинен підтримувати вибіркове видалення фрагментів, пов’язаних з конкретною особою або документом — і саме lineage дозволяє їх знайти. Без метаданих походження запит на видалення є технічно невиконуваним, а це пряме порушення обов’язків з RODO.

Це залежить від класу даних та правової підстави, але маскування саме по собі зазвичай недостатнє для даних особливої категорії. Маскування знижує ризик для внутрішніх даних, проте для кадрових, юридичних чи медичних даних рекомендуємо повний self-hosting та data residency в інфраструктурі компанії. Тоді жоден контент не залишає вашого середовища — деталі в тексті про self-hosted LLM та RODO.

Почніть з однієї області, яку хочете додати до AI, і класифікуйте лише її — не всю компанію одразу. Пройдіть папку за папкою, призначте кожному джерелу один із чотирьох класів і застосуйте принцип, що документ без класу за замовчуванням є конфіденційним. Пілот на одній чистій, добре класифікованій області безпечніший і швидший, ніж спроба впорядкувати все — це те саме поетапне підхід, який ми рекомендуємо при підготовці корпоративних даних під AI.