Компанія витратила три тижні на вибір AI-сервісу, підписала контракт і почала завантажувати клієнтські договори. Через місяць — запит від регулятора. Виявилось: жодного DPA не підписано, сервери в США, субпроцесори невідомі. Штраф і термінова міграція коштували вп'ятеро дорожче ніж власне впровадження. Цей чеклист існує щоб таке не сталося з вами. 20 питань які потрібно поставити провайдеру — і собі — перш ніж ваші корпоративні документи залишать ваш контроль.
⚡ Як використовувати цей чеклист
- 📋 20 питань у 5 блоках — пройдіть кожен перед вибором або аудитом AI-сервісу
- 🎯 Формат: питання → чому критично → що означає відповідь → наша рекомендація
- 🟢🟡🔴 В кінці: як інтерпретувати результати і що робити якщо провайдер мовчить
- 👥 Для кого: CTO, юрист, DPO, керівник що приймає рішення про впровадження AI
- ⏱️ Час: 30–45 хвилин на одного провайдера
📚 Зміст
- Блок 1: Де зберігаються дані (4 питання)
- Блок 2: Юридична відповідність (4 питання)
- Блок 3: Технічна безпека (4 питання)
- Блок 4: Контроль доступу (4 питання)
- Блок 5: Shadow AI і внутрішня політика (4 питання)
- Як інтерпретувати результати
- Що робити якщо провайдер не відповідає
- Часті питання
- Хочете перевірити свій AI-сервіс?
Блок 1: Де зберігаються дані
Найфундаментальніший блок. Відповіді тут визначають чи виникає транскордонний трансфер і яку правову базу потрібно будувати. Детальний розбір різниці між хмарним і self-hosted зберіганням — у статті Self-hosted AI vs хмарний: де залишаються ваші дані.
Питання 1.1: В якій країні фізично знаходяться сервери де зберігаються мої документи і запити?
Чому критично: GDPR забороняє передачу персональних даних за межі ЄС без окремої правової бази. Якщо сервери в США — кожен завантажений документ з персональними даними є транскордонним трансфером що потребує SCCs, TIA і DPA. Більшість компаній цього не роблять і несуть реальний ризик.
Що означає відповідь:
- ✔️ "Сервери в ЄС — Франкфурт, Амстердам, Відень" → базова відповідність щодо локації
- ⚠️ "Ми використовуємо AWS EU-West-1 (Ірландія)" → недостатньо: AWS — американська компанія, CLOUD Act застосовується незалежно від регіону
- 🔴 "Сервери в США" → потрібні SCCs + TIA + DPA — без цього обробка персональних даних незаконна
- 🔴 "Не знаємо" або "залежить від конфігурації" → критичний сигнал тривоги
Наша рекомендація: вимагайте конкретну відповідь — не назву хмарного провайдера а фізичний регіон і юрисдикцію. Єдина надійна відповідь для GDPR: сервер у ЄС яким керує неамериканська компанія (Hetzner, OVH, Contabo) або ваш власний self-hosted сервер. Тільки тоді CLOUD Act США не застосовується.
Питання 1.2: Скільки часу зберігаються мої документи і запити після завершення роботи?
Чому критично: принцип обмеження зберігання (Art. 5(1)(e) GDPR) вимагає що дані не зберігаються довше ніж необхідно. Якщо провайдер зберігає ваші дані "до видалення акаунту" без чіткого терміну — ви не можете виконати право на видалення (Art. 17 GDPR) і не знаєте де ваші дані знаходяться через рік після закінчення контракту.
Що означає відповідь:
- ✔️ "30 днів після останнього використання, потім автоматичне видалення" → прийнятно
- ⚠️ "До ручного видалення користувачем" → ризик, більшість не видаляють вручну
- 🔴 "До закриття акаунту" → дані зберігаються роками після закінчення роботи
- 🔴 Немає чіткої відповіді в документації → порушення вимог до прозорості GDPR
Наша рекомендація: уточніть різницю між "видалення з інтерфейсу" і "видалення з усіх систем включаючи резервні копії". Для self-hosted рішення ця проблема не виникає: ви самі контролюєте всі дані і терміни їх зберігання.
Питання 1.3: Чи передаються мої дані субпроцесорам і хто вони?
Чому критично: за GDPR провайдер зобов'язаний розкрити список субпроцесорів (Art. 28(2)). Якщо Notion передає ваші дані Anthropic і OpenAI — кожна з цих компаній є окремою ланкою ланцюжка з окремою юрисдикцією і окремими ризиками. Ви несете відповідальність за весь ланцюжок.
Що означає відповідь:
- ✔️ Публічний список субпроцесорів з можливістю підписки на сповіщення про зміни → відповідність Art. 28
- ⚠️ "Ми можемо залучати третіх сторін" без конкретики → недостатня прозорість
- 🔴 Списку немає або він недоступний → порушення вимог до договору обробки даних
Наша рекомендація: знайдіть і прочитайте повний список субпроцесорів. Для кожного субпроцесора запитайте: де його сервери і чи є DPA між провайдером і субпроцесором. Notion, наприклад, передає дані Anthropic і OpenAI — обидві американські компанії з серверами в США.
Питання 1.4: Чи використовує провайдер мої дані для тренування своїх моделей?
Чому критично: тренування моделі на ваших корпоративних документах без правової бази — це порушення GDPR. Навіть якщо провайдер "офіційно не тренує" — технічна перевірка цього неможлива. У 2024–2025 роках Garante (Італія) оштрафував OpenAI на €15 млн саме за відсутність правової бази для обробки даних при тренуванні моделей.
Що означає відповідь:
- ✔️ "API/Enterprise план: тренування вимкнено, задокументовано в DPA" → прийнятно
- ⚠️ "Ми не тренуємо моделі на ваших даних" без документального підтвердження → обіцянка але не гарантія
- 🔴 "Безкоштовний/Plus план за замовчуванням використовує дані" → неприйнятно для корпоративного використання
Наша рекомендація: вимагайте що заява "ми не тренуємо" була закріплена у підписаному DPA а не тільки в умовах використання. Умови використання провайдер може змінити в односторонньому порядку. DPA — юридично обов'язковий документ. Детальніше про ризики тренування — у статті 6 ризиків витоку даних через AI: як захистити бізнес.
Блок 2: Юридична відповідність
Цей блок визначає чи є у вас юридична основа для використання сервісу з персональними даними. Без позитивних відповідей на ці питання — будь-яка обробка персональних даних через AI незаконна незалежно від репутації провайдера. Детально про правову базу — у статті GDPR та AI на документах: що повинен знати бізнес у 2026.
Питання 2.1: Чи є підписаний Data Processing Agreement (DPA) з провайдером?
Чому критично: DPA — обов'язковий документ за Art. 28 GDPR коли ви залучаєте обробника персональних даних. Без нього будь-яка обробка незаконна. Це не "добре мати" а юридична вимога. За даними аудитів EU DPA, 73% AI-впроваджень у європейських компаніях мають GDPR-вразливості — і відсутній DPA є найпоширенішою.
Що означає відповідь:
- ✔️ DPA доступний онлайн, можна підписати без переговорів → прийнятно для старту
- ⚠️ DPA тільки для Enterprise → для стандартних планів обробка персональних даних незаконна
- 🔴 DPA недоступний або провайдер про нього не чув → негайна відмова від використання для персональних даних
Наша рекомендація: не починайте роботу до підписання DPA. Більшість великих провайдерів (OpenAI, Google, Microsoft, Anthropic) мають стандартний DPA на сайті. Якщо його немає — це або стартап без юридичної зрілості або свідоме ухилення від відповідальності. Обидва варіанти неприйнятні.
Питання 2.2: Яка правова база для транскордонного трансферу до США?
Чому критично: якщо сервери провайдера в США — передача туди персональних даних громадян ЄС потребує окремої правової бази за Art. 44–49 GDPR. Standard Contractual Clauses (SCCs) — найпоширеніший механізм, але після Schrems II (2020) вони самі по собі недостатні без Transfer Impact Assessment (TIA). Австрійський DSB у справі Google Analytics встановив що "малоймовірність" доступу спецслужб не є достатнім захистом.
Що означає відповідь:
- ✔️ "SCCs підписані + EU-US DPF сертифікація + TIA проведено" → юридично прийнятно з ризиками
- ⚠️ "Ми використовуємо SCCs" без TIA → недостатньо після Schrems II особливо для AT
- 🔴 "Не потрібно, ми зашифровані" → шифрування не є правовою базою для трансферу
Наша рекомендація: якщо провайдер американський — проведіть TIA до початку обробки персональних даних. Методологія EDPB доступна на edpb.europa.eu. Якщо TIA показує неприйнятний ризик — переходьте на EU-hosted або self-hosted рішення. Для DE/AT бізнесу детально — у статті AI та GDPR в Німеччині й Австрії: вимоги до систем 2026.
Питання 2.3: Чи ваша AI-система підпадає під EU AI Act як система "високого ризику"?
Чому критично: з 2 серпня 2026 AI-системи що використовуються в HR, кредитуванні, медицині, освіті або критичній інфраструктурі підпадають під повні вимоги EU AI Act — conformity assessment, реєстрація в EU AI database, система управління якістю. Штрафи: до €35 млн або 7% глобального обороту — вищі ніж GDPR.
Що означає відповідь:
- ✔️ AI використовується тільки для пошуку інформації в документах без впливу на рішення щодо осіб → зазвичай не high-risk
- ⚠️ AI допомагає відбирати кандидатів (HR), оцінювати кредитоспроможність, давати медичні рекомендації → high-risk, потрібна підготовка до серпня 2026
- 🔴 AI приймає або суттєво впливає на рішення щодо конкретних осіб без людського нагляду → потенційно заборонена практика
Наша рекомендація: більшість RAG-асистентів на корпоративних документах не є high-risk системами якщо вони тільки відповідають на питання без автоматичного прийняття рішень. Але якщо ваш AI впливає на HR, кредит або медичні рішення — готуйтесь до EU AI Act вимог вже зараз.
Питання 2.4: Чи зафіксовані всі операції обробки через AI у реєстрі ROPA?
Чому критично: Art. 30 GDPR вимагає від контролерів даних вести реєстр всіх операцій обробки (Record of Processing Activities). Регулятор при перевірці запитує ROPA першим. Якщо операції обробки через AI-сервіс там немає — це підстава для штрафу незалежно від того чи є DPA і SCCs.
Що означає відповідь:
- ✔️ AI-операції задокументовані в ROPA: мета обробки, категорії даних, отримувачі, терміни зберігання → відповідність
- ⚠️ ROPA є але AI-операції туди не внесені → часткова відповідність, потрібне оновлення
- 🔴 ROPA не ведеться взагалі → серйозне порушення незалежно від AI
Наша рекомендація: перед початком роботи з будь-яким AI-сервісом — внесіть операцію до ROPA. Мінімум: назва сервісу, мета використання, категорії даних що передаються, локація серверів, правова база, термін зберігання. Оновлюйте при зміні будь-якого параметра.
Блок 3: Технічна безпека
Цей блок оцінює реальний рівень технічного захисту — не задекларований а фактичний. Документи і сертифікати важливі але питання полягає в тому що відбувається технічно а не що написано в умовах використання.
Питання 3.1: Чи шифруються дані в стані спокою і при передачі — і чим конкретно?
Чому критично: шифрування — базова вимога Art. 32 GDPR. Але "ми шифруємо" без деталей — нічого не означає. Важливо: який стандарт шифрування, хто управляє ключами шифрування і чи може провайдер розшифрувати ваші дані технічно.
Що означає відповідь:
- ✔️ TLS 1.2+ при передачі + AES-256 at rest + ключі шифрування керуються клієнтом (BYOK) → максимальний захист
- ✔️ TLS + AES-256 з ключами провайдера → стандартний прийнятний рівень
- ⚠️ "Ми шифруємо" без специфіки → вимагайте деталі
- 🔴 HTTP або відсутня інформація про шифрування → категорично неприйнятно
Наша рекомендація: зверніть увагу на управління ключами. Якщо ключами управляє провайдер — він технічно може розшифрувати ваші дані. Для максимального захисту — BYOK (Bring Your Own Key) або self-hosted де ключами управляєте ви. Шифрування вирішує ризик перехоплення при передачі але не захищає від самого провайдера.
Питання 3.2: Чи є у провайдера сертифікати SOC 2 Type II або ISO 27001?
Чому критично: SOC 2 Type II — незалежний аудит що підтверджує реальні процеси безпеки протягом мінімум 6 місяців (а не разовий знімок як SOC 2 Type I). ISO 27001 — міжнародний стандарт системи управління інформаційною безпекою. Ці сертифікати не є GDPR-вимогою але є сильним сигналом зрілості безпеки.
Що означає відповідь:
- ✔️ SOC 2 Type II актуальний (не старше 12 місяців) + ISO 27001 → високий рівень довіри
- ⚠️ Тільки SOC 2 Type I або сертифікат старше року → є базовий контроль але без регулярного аудиту
- ⚠️ Жодних сертифікатів → не автоматично погано але потрібні додаткові питання
Наша рекомендація: запитайте сертифікат і перевірте дату. SOC 2 Type II оновлюється щорічно. Якщо провайдер не може надати актуальний сертифікат — запитайте їхній Security Overview документ і власноруч оцініть заходи захисту.
Питання 3.3: Як провайдер повідомляє про інциденти безпеки і в які терміни?
Чому критично: Art. 33 GDPR вимагає повідомити регулятора про витік протягом 72 годин після виявлення. Якщо провайдер дізнався про інцидент але не повідомив вам — ви пропустили дедлайн і несете відповідальність. Провайдер зобов'язаний повідомляти вас "без необґрунтованих зволікань" згідно Art. 28(3)(f) GDPR.
Що означає відповідь:
- ✔️ "Повідомляємо клієнтів протягом 24–48 годин після виявлення інциденту, процес описаний в DPA" → прийнятно
- ⚠️ "Повідомляємо відповідно до законодавства" без конкретних термінів → вимагайте деталі
- 🔴 Процедури сповіщення немає або вона не описана в DPA → критичний ризик для вашої GDPR-відповідності
Наша рекомендація: переконайтесь що в DPA є конкретний термін і канал повідомлення про інциденти. Ідеально — виділений security контакт а не загальна форма підтримки. У разі інциденту у провайдера у вас буде максимум 48 годин щоб оцінити масштаб і почати готувати повідомлення регулятору.
Питання 3.4: Чи проводив провайдер незалежне тестування на проникнення (penetration testing)?
Чому критично: pen-тести виявляють вразливості до того як їх знайдуть зловмисники. Відсутність регулярного pen-тестування — сигнал що провайдер не практикує проактивний підхід до безпеки. В березні 2023 OpenAI мав інцидент через вразливість у Redis — дані частини користувачів стали доступні іншим. Регулярні pen-тести зменшують таку ймовірність.
Що означає відповідь:
- ✔️ "Щорічний pen-тест незалежною компанією, результати доступні клієнтам за NDA" → хороша практика
- ⚠️ "Ми проводимо внутрішні аудити безпеки" → менш надійно ніж незалежний аудит
- 🔴 "Ні" або немає відповіді → серйозна прогалина в практиках безпеки
Наша рекомендація: для enterprise-рівня запитайте Executive Summary останнього pen-тесту. Провайдери з зрілою практикою безпеки надають такі документи під NDA без проблем. Відмова надати — це вже інформація.