Найбільшою проблемою GDPR при використанні AI є не сама модель, а потік даних. Коли запит з персональними даними потрапляє до API у хмарі, він виходить з-під вашого контролю: з’являється доручення обробки, питання про локацію серверів і про те, що постачальник робить із контентом. Self-hosting усуває цей крок.
Що саме змінює власний модель#
- Відсутність передачі третій стороні — дані залишаються на ваших серверах або у вашій приватній хмарі.
- Менше договорів доручення — ви не доручаєте обробку зовнішньому постачальнику LLM.
- Повний контроль над зберіганням — ви самостійно вирішуєте, що і як довго зберігається, і реально реалізуєте право на видалення.
- Локалізація обробки — ви знаєте, де фізично знаходяться дані, без припущень про регіон API.
Основою тут є не лише сам LLM, а й сервер ембедінгів BGE-M3, завдяки якому RAG на корпоративних даних працює локально — семантичний пошук за вашими документами без відправлення їх назовні.
Наведена нижче таблиця показує, що саме self-hosting змінює для кожного з основних обов’язків GDPR порівняно з API у хмарі. Self-hosting не усуває жодного обов’язку — він лише зміщує точку контролю з постачальника на вас.
| Обов’язок GDPR | API у хмарі | Self-hosted LLM |
|---|---|---|
| Правова основа обробки | Ваш обов’язок + основа для доручення постачальнику | Ваш обов’язок; немає окремої основи для передачі до LLM |
| Мінімізація даних | Потребує фільтрації промпту перед відправленням назовні | Дані не залишають організацію; мінімізація все одно рекомендована |
| Зберігання та видалення | Залежить від політики та логів постачальника | Повністю на вашому боці — власні TTL і процедури видалення |
| Право на видалення (ст. 17) | Треба охопити логи та індекс на боці постачальника | Видаляєте у себе, включно з індексом RAG |
| Передача за межі ЄЕЗ | Часто потребує SCC / оцінки локації серверів | Немає передачі, якщо інфраструктура стоїть у ЄЕЗ |
| Договір доручення (ст. 28) | Потрібен з кожним постачальником, який обробляє дані | Зазвичай не потрібен щодо постачальника моделі — див. договір доручення даних та AI |
Compliance-by-design, а не постфактум#
Відповідність проектуємо з самого початку, а не додаємо в кінці. На практиці це означає: мінімізацію даних (модель отримує лише те, що потрібно), маскування PII до того, як щось потрапить до моделі, логування доступу та чіткі межі того, що система може робити з даними.
Також варто заздалегідь запланувати оцінку впливу на захист даних (DPIA) — при обробці чутливих даних або у великому масштабі вона може бути обов’язковою незалежно від того, де стоїть модель. Докладніше про терміни й обов’язки AI Act та GDPR пишемо в посібнику про обов’язки компаній у 2026 за AI Act і GDPR.
Гібридний варіант: хмара там, де дозволено#
Не кожен сценарій вимагає локальності. Неперсональні або анонімізовані дані можна обробляти потужнішою моделлю у хмарі. Router направляє конфіденційні запити на локальну модель, а решту — у хмару, маскуючи PII перед будь-яким виходом назовні. На практиці такий LLM-роутер працює за простим правилом: якщо в запиті виявлено персональні дані, він повністю йде на локальну модель; якщо ні, промпт маскується, і лише анонімізована версія потрапляє у хмару. Безпека та GDPR важливіші за окрему функцію.
Приклад шляху для входу з PII виглядає так: виявити сутності (ім’я, ідентифікаційний номер, адреса) → замаскувати або направити на локальну модель → обробити → відновити контекст локально у відповіді. Лише запити без персональних даних ідуть на потужнішу модель у хмарі. Нижче ви можете перевірити, як модель розписала б таку політику маршрутизації для власного набору завдань.
FAQ#
Чи означає self-hosted LLM повну відповідність GDPR?#
Ні, не автоматично — але усуває найскладніший елемент, тобто передачу даних за межі організації. Ви все одно відповідаєте за правову основу, мінімізацію, зберігання та права осіб. Self-hosting дає вам повний контроль над цим.
Чи потрібен дорогий кластер GPU, щоб тримати модель у себе?#
Не обов’язково. Для багатьох застосувань — класифікація, екстракція, RAG за корпоративними документами — достатньо меншої моделі на одному GPU. Лише складне міркування, довгий контекст або велика кількість паралельних запитів виправдовують потужнішу машину чи кластер. Залізо ми трактуємо як постійну, амортизовану в часі статтю витрат, а не плату за кожен виклик — тому добираємо варіант під реальне навантаження та бюджет. Важлива передбачувана вартість, а не максимальне залізо.
Що з даними, які все ж таки йдуть у хмару?#
Маскуємо PII перед відправленням, обмежуємо обсяг до необхідного мінімуму та направляємо конфіденційні шляхи на локальну модель. Це гібридний підхід: локально там, де потрібно, хмара там, де дозволено.
Чи усуває self-hosting договір доручення повністю?#
Не завжди. Зникає договір доручення з постачальником моделі, бо саме постачальник перестає обробляти дані. Але якщо модель стоїть у чужій приватній хмарі, а інфраструктуру обслуговує зовнішній підрядник, договір доручення (ст. 28 GDPR) усе ще може бути потрібним щодо цього постачальника хостингу. Деталі описуємо у статті про договір доручення даних та AI.
Що з правом на видалення даних в індексі RAG?#
Векторний індекс також містить персональні дані, тож на нього поширюється право на видалення. При self-hosting ви маєте над цим повний контроль: видаляєте вихідний документ, а потім стираєте відповідні вектори й фрагменти з індексу (а також із кешу відповідей, якщо він є). Варто заздалегідь пов’язати ідентифікатор документа з його ембедінгами, щоб видалення було одним передбачуваним кроком, а не ручним пошуком у базі.