Головне
- Видаляйте персональні дані до індексації та ще раз перед кожним викликом моделі.
- Запускайте ембедінги та інференс в ЄС або на власних серверах із моделлю з відкритими вагами.
- Застосовуйте права доступу на рівні документів під час пошуку, а не в промпті.
- Зберігайте лише потрібні події аудиту, маскуйте зайві персональні дані та визначайте доступ і строки зберігання журналів.
Чому RAG створює ризик за GDPR
Система RAG знаходить фрагменти ваших документів і передає їх мовній моделі. Якщо вони містять персональні дані, GDPR стосується завантаження, векторів, пошуку, викликів моделі та журналів. Визначте законну мету й правову підставу, застосовуйте права доступу до пошуку та встановіть строки зберігання й видалення для всієї системи.
Спершу владнайте правові основи
- Ролі: ви зазвичай контролер, а кожен постачальник, що торкається даних (сервіс ембедінгів, хостинг векторної бази, хостинг моделі): обробник, якому потрібна угода за статтею 28.
- Правова підстава: запишіть мету помічника та правову підставу для кожного виду даних, до яких він має доступ.
- Оцінка впливу: коли обробка ймовірно має високий ризик, наприклад документи про здоров'я чи кадрові, проведіть DPIA за статтею 35 до запуску.
- Прозорість: повідомте працівників чи клієнтів, що з цими даними працює помічник зі ШІ, за статтями 13 і 14.
- Моделі: спитайте кожного постачальника, чи використовуються ваші дані для навчання, і закріпіть відповідь у договорі.
Референсна архітектура
- Завантаження: виявлення й маскування персональних даних, зворотне зіставлення лише там, де це справді потрібно, і запис джерела, власника та дати кожного документа.
- Індекс: векторне сховище в ЄС з мітками доступу для кожного документа та збереженим зв'язком кожного фрагмента з його документом, щоб його можна було видалити.
- Пошук: фільтрація за правами користувача до ранжування, щоб фрагмент, який користувач не має бачити, ніколи не був кандидатом.
- Генерація: модель у регіоні ЄС або на власних серверах без навчання на ваших даних, другий прохід видалення даних у промпті та вказівка відповідати лише зі знайдених уривків.
- Аудит: журнал запиту, джерел і відповіді, до якого можна лише дописувати, з видаленими значеннями та визначеним строком зберігання.
Вибір місця роботи моделі
| Варіант | Розташування даних | Зусилля |
|---|---|---|
| Перевірений провайдер, регіон ЄС | ЄС, за договором обробки | Низькі |
| Модель з відкритими вагами, хмара ЄС | ЄС, ваш обліковий запис | Середні |
| Модель з відкритими вагами, власні сервери | Ваші сервери | Вищі |
Регіон ЄС вирішує, де стоять сервери, а не чиє право може дістатися оператора, тож для найчутливіших документів ми схиляємося до провайдерів з ЄС або власних серверів. Наш посібник про платформи ШІ, розміщені в ЄС, розглядає варіанти й запитання, які варто ставити.
Які платформи рекомендують для RAG із розташуванням даних на власних серверах і відповідністю GDPR?
Єдиної рекомендованої платформи немає, бо RAG на власних серверах: це стек шарів, і для кожного є добрі варіанти з відкритим кодом та з ЄС. Важливо, щоб кожен шар працював на інфраструктурі, яку ви контролюєте, і нічого з неї не виходило. Типове власне налаштування виглядає так.
| Шар | Варіанти, що можуть працювати на ваших серверах | Що перевірити |
|---|---|---|
| Векторне сховище | Qdrant (Apache 2.0), Postgres із розширенням pgvector, Weaviate або Milvus | Фільтри доступу для кожного документа, резервні копії та шифрування у стані спокою. Pgvector зберігає вектори поруч з іншими даними, а деякі сховища мають більше компонентів для експлуатації |
| Обслуговування моделей | vLLM (Apache 2.0) для продакшен-трафіку, Ollama чи llama.cpp для малих розгортань і тестів | Потужність GPU, скільки запитів виконується одночасно, і API, сумісний з OpenAI, щоб можна було міняти модель |
| Оркестрація | Haystack, LlamaIndex або власний код | Наскільки легко перевіряти кожен крок і тестувати пошук окремо від генерації |
| Моделі | Мовні моделі та моделі ембедінгів з відкритими вагами, які ви розміщуєте самі | Умови ліцензії для комерційного використання, охоплення мов і точність на ваших документах |
| Доступ | Ваш наявний єдиний вхід із рольовим доступом | Права, застосовані під час пошуку, а не в промпті |
| Управління | Видалення даних, журнал аудиту, зберігання та видалення | Архітектура вище, перевірена від початку до кінця |
Що буде, коли хтось попросить видалити його дані?
Коли стаття 17 вимагає видалення, відстежте дані в документах, фрагментах, векторах, кешах і журналах. Видаліть або обмежте копії відповідно до обов’язку та обробіть резервні копії за задокументованим процесом відновлення й строків зберігання. Зафіксуйте зміни й перевірте, що пошук більше не розкриває дані.
Ставтеся до ембедінгів як до персональних даних, коли їх створено з персональних даних. Текст іноді можна вивести з векторів, тож векторна база даних не є кроком анонімізації.
Ризики безпеки, властиві RAG
| Ризик | Як проявляється | Захід |
|---|---|---|
| Ін'єкція промпта | Документ містить приховані інструкції, яких модель дотримується | Сприймати знайдений текст як дані, обмежити можливості моделі, фільтрувати виводи |
| Розкриття чутливої інформації | Відповідь розкриває дані, яких користувач не мав би бачити | Фільтр прав на етапі пошуку, видалення даних, перевірка виводів |
| Слабкості векторів і ембедінгів | Погано ізольовані індекси змішують клієнтів або витікає вміст | Окремі індекси чи суворі фільтри для кожного клієнта, контроль доступу до векторного сховища |
| Дезінформація | Впевнена відповідь, яку уривки не підтверджують | Цитування, вказівка відповідати лише з джерел і запасний варіант, коли пошук слабкий |
Чек-лист перед запуском
- Підписано угоди з обробниками з кожним постачальником у ланцюжку, зокрема із субобробниками.
- Завершено DPIA, де потрібно, із записаними рішеннями щодо видалення даних і хостингу.
- Перевірено фільтрацію за правами на облікових записах, що не мають бачити певні документи.
- Перевірено стирання від початку до кінця на тестовому документі.
- Встановлено строк зберігання журналів, а журнали очищено від даних.
- Набір реальних запитань із очікуваними джерелами для перевірки пошуку й відповідей.
Розкажіть, які документи потрібні асистенту та хто повинен мати до них доступ. Сплануємо RAG із правами доступу, маскуванням даних і відстежуваним видаленням.
Спланувати систему RAGFAQ
Чи можна використовувати провайдера моделей зі США?
Оцініть фактичні місця обробки, договори й доступ постачальника. Передачі поза ЄЕЗ потребують належної підстави глави V та відповідних гарантій. Регіон ЄС є вибором розгортання, а не повною оцінкою GDPR.
Чи є ембедінги персональними даними?
Їх слід вважати персональними даними, коли вони походять із персональних даних, бо іноді з них можна вивести вміст. Захищайте їх і видаляйте разом із вихідним документом.
Чи потрібна DPIA для внутрішнього помічника зі знань?
Якщо він має доступ до документів про здоров'я, кадрових чи інших чутливих або обробляє персональні дані у великому масштабі, найімовірніше потрібна. Для нешкідливої публічної бази знань зазвичай вистачає короткої письмової нотатки про попередню оцінку.
Джерела
- Регламент (ЄС) 2016/679 (GDPR), статті 5, 17, 25, 28, 32 і 35
- Настанови EDPB щодо захисту даних за задумом і за замовчуванням
- Європейська рада із захисту даних, Висновок 28/2024 щодо моделей ШІ
- OWASP Top 10 для застосунків із LLM
- Qdrant, open-source vector database (Apache 2.0)
- vLLM, open-source LLM inference and serving library (Apache 2.0)
Про автора
Artem Synytskyi · Співзасновник · ШІ
Artem очолює напрям ШІ в ESADEX і створює LLM, RAG та системи транскрипції для галузей із нормативними вимогами.
