Компанія підключила ChatGPT для роботи з документами. Менеджери задоволені — відповіді швидкі, зручно. Через пів року приходить аудит GDPR. Перше питання регулятора: "Де зберігаються дані ваших клієнтів і хто має до них доступ?" Відповідь "ми використовуємо ChatGPT" — це не відповідь. Це початок проблем. Коротка відповідь: більшість бізнесів не усвідомлюють ризиків витоку корпоративних даних через AI-сервіси до першого інциденту або аудиту. У цій статті — шість реальних сценаріїв і як їх запобігти.
⚡ Коротко
- 🤖 Ризик 1: тренування моделі на ваших даних — провайдер може використовувати ваші документи для покращення своїх продуктів
- 💾 Ризик 2: зберігання запитів на серверах провайдера — кожне питання до AI фіксується в логах
- 🔓 Ризик 3: витік через API без належного шифрування — дані в транзиті вразливі
- 👁️ Ризик 4: доступ співробітників провайдера до ваших файлів — технічний персонал може переглядати контент
- 🌍 Ризик 5: юрисдикція сервера поза ЄС — сервери в США = GDPR-порушення без додаткових заходів
- 👤 Ризик 6: несанкціоноване використання AI співробітниками — shadow AI як найнебезпечніший сліпий кут
- 👇 Нижче — як перевірити і що робити якщо витік вже стався
📚 Зміст
- Ризик 1: тренування моделі на ваших даних
- Ризик 2: зберігання запитів на серверах провайдера
- Ризик 3: витік через API без шифрування
- Ризик 4: доступ співробітників провайдера до ваших файлів
- Ризик 5: юрисдикція сервера поза ЄС
- Ризик 6: несанкціоноване використання AI співробітниками
- Як перевірити чи ваш AI-сервіс безпечний
- Що робити якщо витік вже стався
- Часті питання
- Висновки
- Хочете перевірити свою систему?
Ризик 1: тренування моделі на ваших даних
Деякі AI-сервіси за замовчуванням використовують ваші запити і завантажені документи для покращення своїх моделей. Якщо ви не вимкнули цю опцію — ваші корпоративні дані можуть стати частиною тренувального датасету.
Це найменш очевидний ризик — і саме тому найнебезпечніший. Більшість користувачів вважають що "AI просто відповідає на питання". Насправді за замовчуванням у багатьох сервісів — особливо безкоштовних і Plus-планах — ваші взаємодії з моделлю можуть зберігатися і використовуватися для подальшого тренування.
Що конкретно може відбуватися з вашими даними
Запити і відповіді. Кожне питання яке ви задаєте AI — це текст який зберігається в системах провайдера. Для безкоштовних планів він може переглядатися командою з безпеки або якості і потенційно включатися в тренувальні датасети. Навіть якщо у запиті немає назви вашої компанії — комбінація теми, термінології і контексту може ідентифікувати вас або вашого клієнта.
Завантажені файли. В деяких сервісах файли зберігаються навіть після завершення сесії — доки ви їх вручну не видалите через налаштування акаунту. Більшість користувачів цього не роблять — просто тому що не знають що файли продовжують зберігатися. У OpenAI FileSearch, наприклад, файли у бібліотеці зберігаються до ручного видалення або закриття акаунту.
Непряме тренування. Найскладніший для перевірки сценарій. Навіть якщо провайдер офіційно заявляє "ми не тренуємо моделі на ваших даних" — перевірити це технічно неможливо. Ви не маєте доступу до їхньої інфраструктури і не можете підтвердити що ваші дані справді виключені з тренувальних процесів.
Fine-tuning і RLHF. Окрім базового тренування, провайдери використовують зворотний зв'язок користувачів (оцінки відповідей "добре/погано") для процесу RLHF (Reinforcement Learning from Human Feedback). Ваші реакції на відповіді AI — це теж дані які формують поведінку моделі.
Як це виглядає на практиці — конкретний сценарій
Юрист компанії відкриває ChatGPT (безкоштовний план) і вставляє фрагмент договору з клієнтом: "Переформулюй цей пункт про відповідальність щоб він звучав м'якше". В тексті — назва клієнта, конкретні суми штрафів, юрисдикція і умови конфіденційності. Цей запит:
- ✔️ Зберігається на серверах OpenAI в США
- ✔️ За замовчуванням може використовуватися для тренування (якщо не вимкнено в налаштуваннях)
- ✔️ Може переглядатися командою OpenAI для забезпечення якості
- ✔️ Потенційно стає частиною того що модель "знає" про типові умови договорів у вашій галузі
Сам юрист навіть не підозрює що щойно передав фрагмент конфіденційного договору клієнта третій стороні — без відома клієнта і без правової бази для такої передачі.
Що кажуть провайдери — і що це означає насправді
Ось як основні провайдери описують свою політику щодо тренування:
- ✔️ OpenAI (безкоштовний / Plus): за замовчуванням може використовувати дані для тренування. Можна вимкнути в Settings → Data Controls → "Improve the model for everyone". Але навіть при вимкненні дані зберігаються 30 днів для моніторингу безпеки
- ✔️ OpenAI (API / Enterprise): офіційно не використовує для тренування. Але "офіційно" — це заява в документації, а не технічна неможливість
- ✔️ Notion AI: офіційно заявляє що не тренує моделі на даних клієнтів. Але передає дані субпроцесорам (Anthropic, OpenAI) — і їхня політика щодо тренування застосовується вже до цих переданих даних
- ✔️ Google Gemini (безкоштовний): за замовчуванням може переглядатися модераторами і використовуватися для покращення продуктів Google
Ключова проблема: між "офіційною заявою" і "технічною неможливістю" — прірва. DPA і умови використання регулюють поведінку людей і процеси. Але якщо у провайдера є технічний доступ до ваших даних — жоден документ не дає вам стовідсоткової гарантії.
Реальний прецедент
У 2024–2025 роках Garante (Італія) оштрафував OpenAI на €15 млн — зокрема за відсутність правової бази для обробки даних європейців при тренуванні моделей ChatGPT. Регулятор встановив що OpenAI не мав законної підстави для збору і використання персональних даних користувачів ЄС у тренувальних процесах. Це перший великий штраф за AI-тренування в Європі — але точно не останній.
Паралельно Garante вимагав від OpenAI провести шестимісячну публічну кампанію з інформування про права користувачів і впровадити суворіші заходи захисту. Це показує: регулятори не просто штрафують — вони змінюють поведінку компаній через юридичний тиск.
Як мінімізувати цей ризик
Якщо ви використовуєте хмарний сервіс:
- ✔️ Тільки платні API або Enterprise плани — де тренування офіційно відключено
- ✔️ Підпишіть DPA з провайдером — без нього будь-яка обробка персональних даних незаконна з точки зору GDPR
- ✔️ Ніколи не вставляйте в запити персональні дані клієнтів, медичну інформацію або тексти конфіденційних договорів
- ✔️ Для безкоштовних планів — вимкніть тренування в налаштуваннях (але пам'ятайте: це не технічна гарантія)
Якщо потрібна технічна гарантія:
Єдиний спосіб повністю виключити цей ризик — self-hosted рішення де дані фізично ніколи не покидають ваш сервер. Немає передачі — немає можливості тренування. Не тому що провайдер пообіцяв, а тому що фізично нема чого передавати. Детальніше про архітектуру — у статті Self-hosted AI vs хмарний: де залишаються ваші дані.
Ми в AskYourDocs після передачі проекту клієнту не маємо технічного доступу до його бази даних і документів. Тренування на даних клієнта фізично неможливе — не через обіцянку, а через архітектуру.
Ризик 2: зберігання запитів на серверах провайдера
Кожен запит до хмарного AI-сервісу — це текст який передається на сервер провайдера, обробляється там і зберігається в логах. Навіть якщо ви "просто задали питання" — цей запит може містити конфіденційну інформацію.
Уявіть що менеджер задає AI питання: "Порівняй умови нашого договору з клієнтом Acme Corp з нашими стандартними умовами і вкажи де ми відступили". Щоб отримати відповідь — він вставляє фрагменти реального договору в запит. Цей текст з назвою клієнта, цифрами і комерційними умовами тепер на серверах провайдера.
Що саме зберігається і як довго
Текст запиту (prompt). Повний текст того що ви написали AI — включно з будь-якими фрагментами документів які ви вставили для контексту. Якщо в запиті є ім'я клієнта, номер рахунку або медичний діагноз — він зберігається на серверах провайдера рівно в такому вигляді.
Відповідь моделі. Генерована відповідь також зберігається — і якщо вона містить перефразовані дані з вашого запиту, ці дані присутні і у відповіді в логах.
Метадані. Окрім тексту кожен запит супроводжується метаданими: IP-адреса з якої зроблено запит, точна часова мітка, ідентифікатор акаунту або API-ключа, ідентифікатор сесії або розмови. Це дозволяє прив'язати будь-який запит до конкретного співробітника і моменту часу — навіть якщо сам текст запиту здається "анонімним".
Контекст із завантажених документів. Якщо ви завантажили файл і задаєте по ньому питання — система RAG провайдера знаходить релевантні фрагменти і включає їх у prompt до моделі автоматично. Тобто у лог потрапляє не тільки ваше питання але і фрагмент документа — навіть якщо ви його не копіювали вручну.
Скільки часу зберігаються ваші запити
Терміни зберігання суттєво відрізняються залежно від провайдера і плану:
- ✔️ OpenAI (безкоштовний / Plus): історія розмов зберігається до ручного видалення. Навіть при вимкненому тренуванні — дані зберігаються 30 днів для моніторингу безпеки
- ✔️ OpenAI API: запити зберігаються до 30 днів за замовчуванням, потім видаляються — якщо інше не встановлено в налаштуваннях організації
- ✔️ Notion AI: дані зберігаються відповідно до загальної політики Notion — зазвичай до видалення акаунту або workspace. Для субпроцесорів (Anthropic, OpenAI) на Enterprise-плані — zero retention після обробки
- ✔️ Google Gemini (безкоштовний): активність зберігається до 18 місяців за замовчуванням і може переглядатися модераторами Google
Важливий нюанс: "видалення" з точки зору користувача і фактичне видалення з усіх систем провайдера — різні речі. Дані можуть зберігатися в резервних копіях, архівах або аналітичних системах ще деякий час після "видалення" у вашому інтерфейсі.
Чому це проблема з точки зору GDPR
З точки зору GDPR сам факт зберігання на серверах провайдера запиту що містить персональні дані — вже є обробкою персональних даних третьою стороною. Це автоматично тягне за собою ряд вимог:
- ✔️ DPA (Data Processing Agreement): обов'язковий договір між вами і провайдером як обробником даних. Без нього будь-яка обробка незаконна
- ✔️ Правова база для трансферу: якщо сервери провайдера поза ЄС — потрібні SCCs або інший механізм передачі даних за статтями 44–49 GDPR
- ✔️ DPIA (оцінка впливу): для систематичної обробки чутливих даних через AI — обов'язкова оцінка ризиків
- ✔️ Реєстр обробки: операція передачі даних AI-провайдеру повинна бути задокументована у вашому реєстрі операцій обробки
На практиці більшість малого і середнього бізнесу не виконує жодної з цих вимог — просто тому що не усвідомлює що кожен запит до ChatGPT з фрагментом договору є операцією обробки персональних даних.
Реальний сценарій: коли "невинний запит" стає порушенням
HR-менеджер просить ChatGPT: "Допоможи скласти план розвитку для співробітника. Ось його оцінка за минулий рік: [вставляє текст оцінки з ім'ям, посадою і конкретними зауваженнями]".
Що відбувається далі:
- ✔️ Персональні дані співробітника (ім'я, посада, оцінка роботи) потрапляють на сервери OpenAI в США
- ✔️ Це транскордонний трансфер персональних даних без правової бази
- ✔️ Співробітник не давав згоди на передачу своїх даних OpenAI
- ✔️ Компанія не має DPA з OpenAI (або має, але не для цього типу даних)
- ✔️ Оцінка роботи може вважатися даними про "економічну ситуацію" фізичної особи — підвищена категорія захисту
HR-менеджер вважав що "просто попросив допомоги у боті". Юридично — компанія щойно порушила мінімум дві статті GDPR.
Як мінімізувати цей ризик
Організаційні заходи:
- ✔️ Чітка корпоративна політика: які типи даних можна і не можна вставляти в запити до хмарного AI. Не "інструкція в папці" — а реальний онбординг кожного нового співробітника
- ✔️ Ніколи у запитах до хмарного AI: імена клієнтів і їхні дані, медична інформація, HR-оцінки і зарплатні дані, тексти конфіденційних договорів, фінансові показники що не є публічними
- ✔️ Підпишіть DPA з провайдером — для тих типів даних які все одно будуть оброблятися через хмару
Технічне рішення:
У гібридному режимі AskYourDocs документи зберігаються локально на вашому сервері. До зовнішнього LLM передаються лише знеособлені текстові фрагменти — без назв файлів, без метаданих, без ідентифікаторів. Провайдер LLM отримує контекст для відповіді але не отримує інформацію про те що це за компанія, чий це документ і про кого йдеться. При повністю закритому контурі (Ollama) — жоден запит не виходить за межі вашого сервера взагалі. Детальніше — у статті Self-hosted AI vs хмарний: де залишаються ваші дані.
Ризик 3: витік через API без шифрування
Якщо ваш AI-інструмент інтегрований через API — дані передаються між вашою системою і сервером провайдера через інтернет. Неправильна конфігурація або вразливість в інтеграції можуть створити точку витоку.
Це технічний ризик який актуальний для компаній що самостійно інтегрують AI через API — наприклад підключають OpenAI до свого CRM, сайту або внутрішньої системи. На відміну від попередніх ризиків де провайдер є джерелом проблеми — тут проблема може бути на вашому боці.
Важливо розуміти: цей ризик не стосується тих хто просто відкриває ChatGPT у браузері. Він актуальний для розробників і компаній що будують власні AI-продукти або інтеграції поверх API провайдерів. Але саме таких компаній стає дедалі більше — і саме вони часто припускаються найдорожчих помилок.
Чотири основні точки вразливості
API-ключ у відкритому коді. Це найпоширеніша і найдорожча помилка. Розробник поспішає, захардкожує API-ключ прямо в код або конфігураційний файл і пушить це в GitHub репозиторій — навіть приватний. Зловмисники автоматично сканують GitHub в пошуку відкритих ключів. Після отримання ключа вони мають повний доступ до вашого акаунту у провайдера: можуть читати всі завантажені файли, надсилати запити від вашого імені і нести витрати за ваш рахунок. За даними Reco AI Security Report 2025, витік API-ключів є одним з найшвидше зростаючих векторів атак на AI-системи.
Відсутність або неправильне налаштування HTTPS. Якщо з'єднання між вашим сервером і API провайдера не зашифроване — будь-який посередник в мережі (man-in-the-middle атака) може читати передані дані. На практиці більшість сучасних провайдерів вимагають HTTPS — але якщо ваша інтеграція написана неакуратно або використовує застаріву бібліотеку що ігнорує перевірку сертифікатів — з'єднання може бути вразливим навіть формально "через HTTPS".
Небезпечне логування на вашому боці. Ваш сервер отримує запити від користувачів, формує prompt і надсилає до API. Якщо при цьому логується повний текст запиту разом з контентом документів — у вас з'являється ще одна точка зберігання чутливих даних. Ці логи часто не захищені так само ретельно як основна база даних: вони можуть зберігатися у plain text, мати широкий доступ для розробників або взагалі не видалятися роками.
Вразливості у сторонніх інтеграціях і плагінах. Якщо ви використовуєте готовий AI-плагін для WordPress, Zapier-інтеграцію або SDK від стороннього розробника — ви успадковуєте всі його вразливості. У серпні 2025 зловмисник UNC6395 використав OAuth-токени з інтеграції Drift з Salesforce щоб отримати доступ до середовищ більш ніж 700 організацій — жодного експлойту, просто легітимний сторонній доступ через ланцюжок інтеграцій.
Реальний сценарій: від API-ключа до витоку за 20 хвилин
Розробник невеликої компанії підключає OpenAI до корпоративного чату підтримки. Поспішає до дедлайну — API-ключ тимчасово захардкожує в конфіг-файл і пушить у приватний GitHub репозиторій. Через тиждень забуває про це.
Що відбувається далі за типовим сценарієм атаки:
- ✔️ Автоматичний сканер зловмисника знаходить ключ у репозиторії — навіть приватні репозиторії можуть бути скомпрометовані через витік токена GitHub
- ✔️ Зловмисник отримує доступ до акаунту OpenAI: бачить всі завантажені файли, всі vector stores, може надсилати запити
- ✔️ Якщо в акаунті завантажені корпоративні документи — вони тепер доступні зловмиснику
- ✔️ Паралельно зловмисник генерує запити за рахунок компанії — рахунок за місяць може вирости в десятки разів
- ✔️ Компанія дізнається про це або після отримання рахунку або ніколи — якщо зловмисник діяв обережно
Весь цей процес — від знаходження ключа до отримання доступу до даних — займає хвилини. Виявлення компанією — тижні або місяці.
Supply chain атаки — новий масштаб загрози
Окремо варто зупинитися на атаках через ланцюжок постачальників. За даними Verizon DBIR 2025, третьо-стороння участь у витоках подвоїлась за рік. Це означає що зловмисники все рідше атакують вас напряму — натомість атакують ваших постачальників інструментів і інтеграцій.
Для AI-інтеграцій це особливо небезпечно: коли ви підключаєте сторонній AI-плагін до своєї CRM або сайту — ви надаєте йому доступ до ваших даних. Якщо цей плагін буде скомпрометований — зловмисник отримує ваші дані через легітимний канал, що значно важче виявити.
Як мінімізувати цей ризик
Для розробників і технічних команд:
- ✔️ API-ключі тільки у змінних середовища — ніколи в коді, ніколи в конфіг-файлах що потрапляють у репозиторій. Використовуйте `.env` файли і переконайтесь що `.gitignore` їх виключає
- ✔️ Ротація ключів: регулярно (раз на 30–90 днів) міняйте API-ключі. При будь-якій підозрі на компрометацію — негайна заміна
- ✔️ Принцип мінімальних прав: кожна інтеграція повинна мати ключ тільки з тими правами які їй потрібні — не більше
- ✔️ Обов'язково HTTPS і перевірка SSL-сертифікатів — не ігноруйте помилки сертифікатів навіть у dev-середовищі
- ✔️ Логуйте мінімум: якщо треба логувати запити — логуйте тільки метадані (час, тип запиту, статус відповіді), не повний текст з контентом документів
- ✔️ Аудит сторонніх залежностей: перед підключенням будь-якого AI-плагіна або SDK — перевірте його репутацію, дату останнього оновлення і чи є відомі вразливості
Якщо потрібна повна відсутність зовнішнього API:
У self-hosted архітектурі AskYourDocs при режимі закритого контуру (Ollama) зовнішній API взагалі відсутній — вся обробка відбувається всередині вашого сервера. Немає передачі через інтернет — немає точки перехоплення. При гібридному режимі зовнішній LLM API використовується, але до нього передаються тільки знеособлені текстові фрагменти без ідентифікаційних даних — навіть якщо з'єднання буде перехоплено, зловмисник отримає лише безконтекстні уривки тексту.
Детальніше про різницю між закритим контуром і гібридним режимом — у статті Закритий контур з Ollama: AI без інтернету для бізнесу.
Ризик 4: доступ співробітників провайдера до ваших файлів
Більшість хмарних AI-провайдерів технічно мають можливість переглядати контент який ви завантажуєте або надсилаєте — для цілей безпеки, модерації або усунення несправностей. Це не порушення з їхнього боку — але це факт якого більшість бізнесів не враховує.
OpenAI у своїй документації прямо зазначає: "OpenAI може переглядати контент для безпеки і покращення сервісу". Notion має аналогічні умови. Це стандартна практика для SaaS-провайдерів — і вона не означає зловживання. Але з точки зору GDPR і корпоративної безпеки це означає що існує технічна можливість доступу до ваших документів з боку третьої сторони.
Ключове слово тут — технічна можливість. Різниця між "провайдер не дивиться на ваші дані" і "провайдер фізично не може подивитися на ваші дані" — це різниця між обіцянкою і архітектурою. Для бізнесів у регульованих галузях важлива саме друга.
Хто і за яких умов може отримати доступ
Команда безпеки і модерації. Кожен великий AI-провайдер має команду Trust & Safety яка моніторить контент на предмет порушень умов використання — генерація шкідливого контенту, обхід обмежень моделі тощо. Для виконання цієї роботи їм потрібен технічний доступ до запитів і відповідей. Ваш юридичний договір може потрапити під перегляд якщо система автоматично позначить його як підозрілий — наприклад через специфічну юридичну термінологію.
Інженери технічної підтримки. Коли ви відкриваєте тікет підтримки — "щось не так з моїм vector store" або "чому AI дає неточні відповіді?" — інженер підтримки для діагностики може переглянути ваші завантажені файли і запити. Це стандартна практика підтримки. Ви самі надаєте неявний дозвіл на це, звертаючись за допомогою.
Юридичні запити від правоохоронних органів. Це найменш очевидний але потенційно найсерйозніший сценарій. Оскільки більшість великих AI-провайдерів — американські компанії, вони підпадають під юрисдикцію законодавства США. За Третім законом про зберігання даних (Stored Communications Act) і запитами за FISA американські правоохоронці можуть вимагати від компаній надати дані користувачів — без їхнього повідомлення. Для даних що зберігаються в США це реальний правовий ризик навіть якщо ваш бізнес знаходиться в ЄС.
Внутрішній зловмисник у провайдера. Ніяка система не захищена від людського фактора всередині самої компанії. Недобросовісний співробітник провайдера з технічним доступом може переглядати корпоративні документи клієнтів. Провайдери мають внутрішні контролі для запобігання цьому — але повна технічна неможливість такого доступу є тільки в архітектурі де даних взагалі немає на сторонньому сервері.
Витік через вразливість в інфраструктурі провайдера. У березні 2023 OpenAI мав серйозний інцидент безпеки через вразливість у бібліотеці Redis: дані частини користувачів — включаючи фрагменти розмов і платіжну інформацію — стали тимчасово видимі іншим користувачам. OpenAI швидко виправив проблему, але сам факт показує: навіть провайдер з найвищими стандартами безпеки не застрахований від технічних вразливостей.
Що це означає юридично для різних галузей
Для більшості бізнесів цей ризик — теоретичний. Але для певних галузей навіть теоретична можливість доступу є юридичною проблемою:
Адвокати і юридичні фірми. Адвокатська таємниця — один з фундаментальних принципів правової системи. У більшості юрисдикцій ЄС вона означає що матеріали клієнтської справи не можуть передаватися третім особам без явної згоди клієнта. "Третя особа" в даному контексті — це і є провайдер AI-сервісу. Формально, завантажуючи матеріали справи в хмарний AI, адвокат може порушувати адвокатську таємницю — незалежно від того чи хтось реально переглядав ці дані. Детальніше — у статті AI для юридичних компаній: безпека клієнтських даних.
Медичні заклади. Медична таємниця і вимоги до обробки медичних даних за статтею 9 GDPR вимагають що спеціальні категорії персональних даних обробляються з особливою увагою. Передача медичних записів або діагнозів провайдеру, співробітники якого технічно можуть отримати до них доступ — потребує окремої правової бази і явної згоди пацієнта. Детальніше — у статті AI в медицині: як обробляти медичні дані без порушення закону.
HR-відділи. Персональні дані співробітників — оцінки, зарплати, дисциплінарні справи — є персональними даними з підвищеними вимогами захисту. Співробітник не давав згоди на те щоб його персональні дані обробляв OpenAI або Notion. Якщо HR використовує хмарний AI для роботи з такими документами — кожен файл є потенційним порушенням.
Як мінімізувати цей ризик
Якщо залишаєтесь на хмарному рішенні:
- ✔️ Enterprise-план з чіткими умовами доступу: переконайтесь що в договорі прописано обмеження на перегляд вашого контенту співробітниками провайдера і умови за яких це можливо
- ✔️ DPA з деталізованими умовами: Data Processing Agreement повинен чітко описувати хто, за яких умов і з якою метою може отримати доступ до ваших даних
- ✔️ Не завантажуйте дані з підвищеним захистом: адвокатська таємниця, медичні записи, HR-документи — не для хмарного AI без спеціальної підготовки
- ✔️ Анонімізація перед завантаженням: якщо документ потрібно обробити через хмарний AI — видаліть імена, дати народження та інші ідентифікатори перед завантаженням
Якщо потрібна технічна гарантія відсутності доступу:
Ми в AskYourDocs після передачі проекту клієнту не маємо технічного доступу до його бази даних і документів — навіть як розробники. База даних і всі файли знаходяться на сервері клієнта. Ми передаємо повні доступи адміністратора і після цього фізично не можемо переглядати ваш контент. Це не обіцянка в договорі — це архітектурне рішення: нас просто немає в ланцюжку обробки ваших даних.
Для медичних центрів, адвокатських фірм і HR-відділів де конфіденційність є юридичною вимогою — це єдине рішення яке дає не обіцянку а технічну неможливість доступу. Детальніше про послуги — на сторінці askyourdocs.org/uk/services.
Ризик 5: юрисдикція сервера поза ЄС
Якщо сервери AI-провайдера знаходяться в США або іншій країні поза ЄС — передача туди персональних даних громадян ЄС є транскордонним трансфером який потребує окремої правової бази за GDPR. Більшість бізнесів цього не роблять.
Це найбільш "юридичний" з ризиків — але його наслідки найбільш відчутні фінансово. Регулятори ЄС стали значно активнішими: у 2025 році сукупні штрафи GDPR склали €1,15 млрд — і це тільки за один рік. При цьому важливо розуміти: штрафують не тільки великі корпорації. Малий і середній бізнес дедалі частіше потрапляє в поле зору регуляторів — особливо у регульованих галузях.
Чому юрисдикція має значення — технічне пояснення
GDPR побудований на принципі що персональні дані громадян ЄС не повинні виходити за межі ЄС якщо в країні призначення немає рівноцінного рівня захисту. США — не мають такого рівня захисту за замовчуванням. Це означає що будь-яка передача даних до США технічно є "ризикованим трансфером" і потребує окремого правового обґрунтування.
Правові механізми для трансферу до США за GDPR:
- ✔️ Standard Contractual Clauses (SCCs): стандартні договірні клаузули затверджені Єврокомісією. Більшість великих провайдерів їх підписують — але після рішення Schrems II (2020) суд підкреслив що SCCs самі по собі недостатні: потрібна ще й оцінка чи американське законодавство (зокрема FISA і CLOUD Act) не знецінює ці гарантії
- ✔️ EU-US Data Privacy Framework: новий механізм прийнятий у 2023 році — замінив Privacy Shield. Дозволяє передачу даних до сертифікованих американських компаній. Але вже зараз є судові оскарження і є ризик що він буде визнаний недійсним як і Privacy Shield до нього
- ✔️ Binding Corporate Rules (BCRs): внутрішні корпоративні правила для міжнародних груп — складний і дорогий механізм, недоступний для більшості МСБ
На практиці більшість малого і середнього бізнесу не знає що таке SCCs і не має підписаного DPA з провайдером. Вони просто "використовують ChatGPT для роботи" — і при цьому технічно порушують GDPR при кожному запиті що містить персональні дані.
Реальні штрафи — не великі корпорації а реальні кейси
Ось що вже відбулося і безпосередньо стосується AI і передачі даних:
TikTok — €530 млн (квітень 2025). Ірландський регулятор DPC оштрафував TikTok за те що дані європейців фактично передавалися на сервери в Китай — незважаючи на офіційні запевнення компанії що це не відбувається. Регулятор встановив що TikTok не провів належної оцінки ризиків китайського законодавства і не міг гарантувати рівноцінний захист. Це найбільший штраф за транскордонний трансфер даних — і прецедент для всіх компаній що зберігають дані ЄС за її межами.
OpenAI — €15 млн (2024). Garante (Італія) оштрафував OpenAI зокрема за те що компанія не мала правової бази для обробки даних громадян ЄС при тренуванні моделей — тобто для передачі і зберігання цих даних на американських серверах.
LinkedIn — €310 млн (жовтень 2024). Ірландський DPC оштрафував LinkedIn за незаконне використання поведінкових даних європейців для рекламних алгоритмів — без належної правової бази. Хоча цей кейс не про AI безпосередньо — він показує що регулятори системно переслідують незаконну обробку даних великими технологічними платформами.
Clearview AI — понад €100 млн сукупних штрафів від різних DPA ЄС. Американська компанія отримала штрафи від регуляторів Нідерландів (€30,5 млн), Франції, Греції, Італії та інших — за збір і обробку біометричних даних громадян ЄС без правової бази. Компанія не має офісу в ЄС — але регулятори все одно накладають штрафи і вимагають виконання.
EU AI Act — другий шар відповідальності з серпня 2026
З серпня 2026 повністю набуває чинності EU AI Act для систем високого ризику. Це додає другий шар регуляторної відповідальності поверх GDPR. Для AI-систем що обробляють персональні дані в критичних галузях (медицина, юриспруденція, фінанси, HR) — це означає подвійну перевірку відповідності.
- ✔️ Штрафи за AI Act: до €35 млн або 7% глобального річного обороту — більше ніж максимальні штрафи GDPR
- ✔️ Вимоги до систем високого ризику: обов'язкова реєстрація, технічна документація, журнали аудиту, нагляд людини над рішеннями
- ✔️ Паралельне застосування: EDPB і Єврокомісія вже готують спільні керівні принципи щодо взаємодії GDPR і AI Act — обидва регулятори діятимуть одночасно
За даними CMS Enforcement Tracker, з 2025 року регулятори ЄС отримують 443 повідомлення про витоки на день — на 22% більше ніж рік тому. Це не означає що кожне повідомлення закінчується штрафом — але це означає що апарат регулювання розрісся і став значно активнішим.
Практичний наслідок для вашого бізнесу
Якщо ваша компанія знаходиться або обслуговує клієнтів в ЄС і ви використовуєте хмарний AI-сервіс з серверами в США — запитайте себе:
- ✔️ Чи є підписаний DPA з провайдером?
- ✔️ Чи проведена оцінка Transfer Impact Assessment (TIA) для трансферу до США?
- ✔️ Чи є правова основа для обробки — згода, законний інтерес або контрактна необхідність?
- ✔️ Чи задокументована ця операція обробки у вашому реєстрі ROPA?
Якщо відповідь на хоча б одне питання "ні" або "не знаю" — ваш бізнес несе реальний GDPR-ризик прямо зараз. Не теоретичний — реальний, бо регулятори активно перевіряють саме ці аспекти.
Як мінімізувати цей ризик
Якщо залишаєтесь на хмарному рішенні:
- ✔️ Тільки Enterprise-план з data residency в ЄС — де дані фізично зберігаються на серверах в Європі. Стандартні плани цього не гарантують
- ✔️ Підпишіть DPA з провайдером — з чіткими умовами про місце зберігання і обробки
- ✔️ Проведіть Transfer Impact Assessment якщо провайдер американський — навіть при наявності SCCs
- ✔️ Задокументуйте правову базу для обробки і внесіть операцію в реєстр ROPA
Якщо потрібна гарантія без юридичних складнощів:
При self-hosted розгортанні AskYourDocs сервер знаходиться там де ви його розгорнули — ми рекомендуємо VPS в Німеччині, Австрії або Нідерландах. Ваші дані фізично не покидають ЄС. Транскордонного трансферу немає — і весь юридичний ланцюжок вимог (DPA з AI-провайдером, SCCs, TIA) просто не виникає. Детальніше про вибір сервера і GDPR-відповідність — у статті GDPR та AI на документах: що повинен знати бізнес у 2026.