Корпоративні дані та ШІ: договір доручення та правова основа

Компанія впроваджує асистента ШІ для обслуговування клієнтів. Модель відповідає на запитання, цитує процедури з внутрішньої бази знань, іноді бачить ім’я та номер замовлення клієнта. Правове питання виникає через тиждень використання, а не перед впровадженням: чи підписали ми договір з постачальником моделі? Відповідь «не знаємо» — це найпоширеніша прогалина, яку ми виявляємо під час аудитів. Цієї прогалини немає в системах, спроектованих від першого рядка з урахуванням відповідності вимогам.

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

Стаття 28 RODO прямо говорить: кожне таке доручення має бути задокументоване договором або іншим правовим інструментом, який визначає предмет, тривалість, характер і мету обробки, тип даних, категорії осіб, обов’язки та права адміністратора.

Обов’язок виникає, коли до персональних даних має доступ зовнішній суб’єкт, що діє за вашим дорученням. У контексті ШІ це конкретно:

• Постачальник мовної моделі (хмарні API), який бачить зміст промптів, що містять дані користувачів.
• Платформа автоматизації (n8n у хмарі, Make, Zapier), через яку проходять дані з CRM або пошти.
• Постачальник інфраструктури (AWS, Azure, GCP), на якій працює ваша система ШІ та де зберігаються логи бесід.
• Компанія з впровадження (як наша), яка має доступ до даних під час налаштування, тестування та супроводу системи.

Договір не потрібен, коли зовнішній суб’єкт обробляє дані як окремий адміністратор (наприклад, банк, що здійснює платіж) або коли дані ніколи не залишають вашої інфраструктури (архітектура self-hosted, локальні моделі).

Стандартний DPA містить розділи, передбачені ст. 28 RODO. При впровадженнях ШІ додаються положення, яких бракує в шаблонах, написаних до ери мовних моделей.

Положення «заборона навчання на даних клієнта» — це пункт, який відрізняє серйозних постачальників ШІ від тих, хто поглинає ваші дані у глобальну модель. При хмарних API багато постачальників пропонують таке положення в корпоративних угодах — але за замовчуванням часто буває навпаки. Завжди перевіряйте умови API перед першим продуктивним запитом.

Постачальник моделі ШІ не завжди є обробником. Межа залежить від того, чи і як він може використовувати ваші дані у власних цілях.

Чистий обробник (достатньо договору доручення): постачальник запускає модель виключно за вашим дорученням, не використовує дані у власних цілях, не навчає на них, не зберігає поза узгодженим TTL.

Співадміністратор (потрібен договір про співадміністрування, ст. 26 RODO): постачальник має власний інтерес у даних, наприклад, проводить власну аналітику запитів, будує на них продукти, профілює ваших користувачів. Ситуація рідкісна при моделях ШІ, але можлива при SaaS-платформах зі вбудованим ШІ.

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

На практиці переважна більшість API мовних моделей у корпоративному режимі — це обробники, і саме тому DPA є стандартним вимогою тендерів ІТ з 2023 року.

Мовні моделі часто працюють на серверах за межами Європи. Передача персональних даних за межі Європейського економічного простору дозволена, але вимагає правової основи передачі: стандартних договірних положень (SCCs), рішення про адекватність або обов’язкових корпоративних правил (BCRs).

На практиці при впровадженні ШІ ви повинні:

1. Визначити, де фізично обробляються дані (регіон серверів постачальника API).
2. Перевірити, чи пропонує постачальник SCCs або працює в регіоні з рішенням про адекватність (наприклад, ЄЕЗ, Велика Британія, Японія).
3. Задокументувати основу передачі в реєстрі операцій обробки (РОО).
4. Розглянути, чи data-residency в ЄС (примусово за договором або через self-hosting) усуває проблему передачі.

Архітектура self-hosted з локальною моделлю та локальною векторною базою (Qdrant, BGE-M3) усуває питання передачі, оскільки персональні дані ніколи не залишають вашої інфраструктури. Це особливо важливо для компаній з чутливими даними: юридичні фірми, медичні установи, фінтех.

Правова відповідність і технічна відповідність — це дві сторони однієї медалі. Договір доручення задає правові рамки, але система має їх технічно дотримуватися. Конкретно:

Маскування PII перед моделлю. Перш ніж текст з персональними даними потрапляє до LLM, наш router маскує чутливі змінні (імена, номери, електронні адреси). Модель бачить [ІМ'Я] замість «Іван Коваленко». Якщо відповідь не вимагає цих даних, модель їх не отримує.

Zero-retention з боку моделі. При хмарних API обираємо ендпоінти з підтвердженою політикою zero-retention промптів. При локальній архітектурі дані не виходять за межі сервера. Guardrails блокують відповіді, що містять дані, про які модель не повинна запитувати.

TTL на логах. Логи бесід (потрібні для налагодження та аудиту якості) мають визначений термін життя та процедуру purge. Особи можуть вимагати видалення своїх даних — система обробляє це запит end-to-end, включаючи вектори в базі та логи.

Human-gate для незворотних дій. Агенти ШІ, які можуть надсилати електронні листи, створювати документи або змінювати дані, проходять підтвердження людиною. Жодна дія, що стосується персональних даних, не є повністю автономною без чітко визначеного обсягу. Це технічна вимога, що підсилює людський нагляд з AI Act.

Детальніше про саму архітектуру безпеки агентів ШІ у статті безпека агентів ШІ.

AI Act та RODO — це два різні режими, але в сфері даних вони перетинаються. AI Act додає до договорів з постачальниками ШІ додаткові елементи:

• Технічна документація системи — постачальник системи високого ризику має її надати. Для низького ризику достатньо прозорості.
• Реєстр — системи високого ризику вимагають реєстрації в базі ЄС та документації управління ризиками.
• DPIA — коли система ШІ профілює, оцінює або приймає автоматизовані рішення щодо людей, RODO вимагає оцінки наслідків, а AI Act — аналізу ризиків. На практиці: один документ, що покриває обидві вимоги.

У договорі з постачальником ШІ варто прямо зазначити, який рівень ризику AI Act представляє система, хто відповідає за технічну документацію та як обробляються інциденти безпеки ШІ. Без цього адміністратору (вам) буде важко довести відповідність при можливій перевірці.

Детальний огляд AI Act для компаній, що впроваджують ШІ в Польщі, ви знайдете у статті AI Act та RODO 2026.

Перш ніж підписати договір з постачальником моделі, платформи або інфраструктури:

• Чи пропонує постачальник DPA, що відповідає ст. 28 RODO? (Якщо ні — відмовтеся або обробляйте дані анонімно.)
• Чи містить договір положення про заборону навчання на ваших даних?
• Чи визначено регіони обробки та основу передачі за межі ЄЕЗ?
• Чи є перелік субпроцесорів з обов’язком інформування про зміни?
• Чи точно визначено TTL логів та процедуру purge?
• Чи визначено, як постачальник обробляє запити осіб (доступ, видалення)?
• Чи маєте ви право на звіт про інцидент протягом 72 годин (вимога RODO)?

Якщо ваш договір містить усі ці пункти, у вас є надійна основа. Якщо ні — варто це доповнити перед запуском у продакшн, а не після першого запиту від Уповноваженого з захисту даних.

Готовність організації з точки зору даних та відповідності можна попередньо перевірити у оцінці готовності ШІ або розрахувати вартість належної архітектури у калькуляторі ROI. Деталі архітектури обговоримо на безкоштовному пілоті.

Опишіть свій випадок впровадження ШІ, а модель вкаже, які елементи договору доручення є критичними та на що звернути увагу при виборі постачальника. Це відправна точка для перевірки з юристом, а не юридична порада. PII маскуються перед моделлю, zero-retention.

Обов’язок виникає, коли зовнішній суб’єкт стикається з персональними даними та обробляє їх виключно за вашим дорученням. На практиці ШІ: коли API мовної моделі, платформа автоматизації або постачальник хостингу бачить зміст, що містить дані ваших клієнтів або працівників. Відсутність DPA в цій ситуації — це порушення ст. 28 RODO незалежно від того, чи стався інцидент взагалі.

Більшість великих постачальників API мають DPA, доступні в корпоративних програмах. Проблема полягає в тому, що стандартні умови для споживачів або безкоштовних тарифів часто не містять DPA або містять положення, що дозволяють навчання на даних. Перед використанням будь-якого API у продакшні з персональними даними необхідно завантажити та підписати DPA з постачальником, не припускаючи, що стандартні ToS достатньо.

Так, щодо моделі та інфраструктури, яка повністю перебуває під вашим контролем. Якщо мовна модель, векторна база та логи бесід працюють на ваших серверах і жодні персональні дані не залишають вашої мережі, немає обробника, якому потрібно доручати дані. Договір доручення все ще потрібен з компанією з впровадження, яка має доступ до системи під час встановлення та супроводу. Детальніше про архітектуру self-hosting.

Це залежить від архітектури. Генеративні моделі не «запам’ятовують» бесіди між сесіями, але постачальники API можуть зберігати логи промптів до 30 днів (або довше) для налагодження та безпеки. У договорі доручення слід визначити TTL логів та механізм їх видалення. При локальному LLM та zero-retention з боку моделі дані бесіди не виходять за межі вашої інфраструктури. Вектори ембедінгів у векторній базі є окремим ресурсом, що вимагає окремої політики зберігання та purge.

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