Компанія витратила три тижні на вибір AI-сервісу, підписала контракт і почала завантажувати клієнтські договори. Через місяць — запит від регулятора. Виявилось: жодного DPA не підписано, сервери в США, субпроцесори невідомі. Штраф і термінова міграція коштували вп'ятеро дорожче ніж власне впровадження.
Цей чеклист існує щоб таке не сталося з вами. 20 питань які потрібно поставити провайдеру — і собі — перш ніж ваші корпоративні документи залишать ваш контроль.
⚡ Як використовувати цей чеклист
- 📋 20 питань у 5 блоках — пройдіть кожен перед вибором або аудитом AI-сервісу
- 🎯 Формат: питання → чому критично для бізнесу → що означає відповідь → наша рекомендація
- 🟢🟡🔴 В кінці: як інтерпретувати результати і що робити якщо провайдер мовчить
- 👥 Для кого: CTO, юрист, DPO, керівник що приймає рішення про впровадження AI
- ⏱️ Час: 30–45 хвилин на одного провайдера
📚 Зміст
Блок 1: Де зберігаються дані
Найфундаментальніший блок. Саме тут вирішується чи виникає транскордонний трансфер і яку правову базу потрібно будувати. Ми в AskYourDocs бачимо що більшість компаній, які отримують запити від регуляторів, не змогли відповісти саме на ці чотири питання. Детальний розбір різниці між хмарним і self-hosted зберіганням — у статті Self-hosted AI vs хмарний: де залишаються ваші дані.
Питання 1.1: В якій країні фізично знаходяться сервери де зберігаються мої документи і запити?
Чому критично для бізнесу: це не технічне питання — це питання юридичної відповідальності. Якщо сервери в США — кожен завантажений документ з персональними даними є транскордонним трансфером що потребує SCCs, TIA і DPA. Регулятор не буде з'ясовувати чи знали ви про це: незнання не звільняє від штрафу. Ми бачили компанії що витрачали €30,000–80,000 на термінову юридичну і технічну міграцію — лише тому що ніхто не поставив це питання на старті.
Що означає відповідь:
- ✔️ "Сервери в ЄС — Франкфурт, Амстердам, Відень" → базова відповідність щодо локації
- ⚠️ "Ми використовуємо AWS EU-West-1 (Ірландія)" → недостатньо: AWS — американська компанія, CLOUD Act застосовується незалежно від регіону
- 🔴 "Сервери в США" → потрібні SCCs + TIA + DPA — без цього обробка персональних даних незаконна
- 🔴 "Не знаємо" або "залежить від конфігурації" → критичний сигнал тривоги
Наша рекомендація: вимагайте конкретну відповідь — не назву хмарного провайдера, а фізичний регіон і юрисдикцію. Надійна відповідь для GDPR: сервер у ЄС яким керує неамериканська компанія (Hetzner, OVH, Contabo) або ваш власний self-hosted сервер. Тільки тоді CLOUD Act США не застосовується і транскордонного трансферу немає.
Питання 1.2: Скільки часу зберігаються мої документи і запити після завершення роботи?
Чому критично для бізнесу: ви підписали контракт і завантажили документи — а через рік після закінчення контракту вони досі лежать на серверах провайдера. Звучить теоретично — але саме з цього починаються реальні GDPR-справи. Принцип обмеження зберігання (Art. 5(1)(e)) — одна з найчастіших підстав для штрафів у 2024–2025 роках. І виконати право на видалення (Art. 17) ви зможете тільки якщо знаєте де і скільки зберігаються ваші дані.
Що означає відповідь:
- ✔️ "30 днів після останнього використання, потім автоматичне видалення" → прийнятно
- ⚠️ "До ручного видалення користувачем" → ризик: більшість не видаляють вручну, дані залишаються роками
- 🔴 "До закриття акаунту" → дані зберігаються роками після закінчення роботи з провайдером
- 🔴 Немає чіткої відповіді в документації → порушення вимог GDPR до прозорості
Наша рекомендація: уточніть різницю між "видалення з інтерфейсу" і "видалення з усіх систем включаючи резервні копії" — це різні речі і провайдери часто мають на увазі перше коли описують друге. З self-hosted рішенням ця проблема не виникає: ви самі контролюєте де і скільки зберігаються дані.
Питання 1.3: Чи передаються мої дані субпроцесорам і хто вони?
Чому критично для бізнесу: ви підписали DPA з Notion — але Notion передає ваші дані Anthropic і OpenAI. З точки зору GDPR ви несете відповідальність за весь ланцюжок, а не тільки за прямого провайдера. Якщо субпроцесор порушить безпеку або передасть дані далі — претензії прийдуть до вас як до контролера даних. Провайдер зобов'язаний розкрити повний список субпроцесорів (Art. 28(2)), і це не прохання, а юридична вимога.
Що означає відповідь:
- ✔️ Публічний список субпроцесорів з можливістю підписки на сповіщення про зміни → відповідність Art. 28
- ⚠️ "Ми можемо залучати третіх сторін" без конкретики → недостатня прозорість, вимагайте деталі
- 🔴 Списку немає або він недоступний → порушення вимог GDPR до договору обробки даних
Наша рекомендація: знайдіть і прочитайте повний список субпроцесорів. Для кожного — де його сервери і чи є DPA між провайдером і субпроцесором. Notion, наприклад, передає дані Anthropic і OpenAI — обидві американські компанії з серверами в США. Це означає що "EU-hosted Notion" насправді включає американських субпроцесорів.
Питання 1.4: Чи використовує провайдер мої дані для тренування своїх моделей?
Чому критично для бізнесу: тренування моделі на ваших корпоративних документах без правової бази — пряме порушення GDPR. Але навіть якщо провайдер "офіційно не тренує" — технічна перевірка цього неможлива. Тому важлива не обіцянка а юридичне зобов'язання, зафіксоване в DPA. Регулятори вже перевіряють цей аспект: у грудні 2024 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. Без нього будь-яка обробка персональних даних незаконна — незалежно від того скільки ви заплатили і який гарний продукт. За нашим досвідом, це найпоширеніша прогалина: компанія рік використовує AI-сервіс, передає туди договори і листування — і лише при підготовці до аудиту виявляє що DPA ніхто не підписував.
Що означає відповідь:
- ✔️ DPA доступний онлайн, можна підписати без переговорів → прийнятно для старту
- ⚠️ DPA тільки для Enterprise → для стандартних планів обробка персональних даних юридично незаконна
- 🔴 DPA недоступний або провайдер про нього не чув → негайна відмова від використання для персональних даних
Наша рекомендація: не починайте роботу до підписання DPA. Більшість великих провайдерів (OpenAI, Google, Microsoft, Anthropic) мають стандартний DPA на сайті — пошук займає 5 хвилин. Якщо 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 як система "високого ризику"?
Чому критично для бізнесу: EU AI Act вводить обов'язкові вимоги для AI-систем залежно від їхнього ризику. Для систем "високого ризику" — це conformity assessment, реєстрація в EU AI database і система управління якістю. Терміни і штрафи суворі. Але важливий нюанс: більшість RAG-асистентів на корпоративних документах до категорії high-risk не потрапляють — якщо правильно розуміти класифікацію.
Актуальні дедлайни (оновлено): Digital Omnibus agreement від 7 травня 2026 відклав вимоги для use-based high-risk систем (Annex III) з 2 серпня 2026 до 2 грудня 2027. Для AI вбудованого в медичні прилади та інші регульовані продукти (Annex I) — до 2 серпня 2028. Більше часу на підготовку — але не причина ігнорувати класифікацію вже зараз.
Штрафи за EU AI Act (Art. 99):
- Заборонені AI практики (соціальний скоринг, маніпулятивний AI) → до €35 млн або 7% обороту
- Невідповідність вимогам для high-risk систем (HR, кредити, медицина) → до €15 млн або 3% обороту
- Надання неправдивих даних регулятору → до €7.5 млн або 1.5%
Що означає відповідь:
- ✔️ AI використовується тільки для пошуку інформації в документах без впливу на рішення щодо осіб → зазвичай не high-risk
- ⚠️ AI допомагає відбирати кандидатів (HR), оцінювати кредитоспроможність, давати медичні рекомендації → high-risk, потрібна підготовка до грудня 2027
- 🔴 AI приймає рішення щодо конкретних осіб без людського нагляду → потенційно заборонена практика
Наша рекомендація: більшість RAG-асистентів на корпоративних документах не є high-risk якщо вони тільки відповідають на питання без автоматичного прийняття рішень. Але якщо ваш AI впливає на HR, кредит або медичні рішення — класифікуйте систему і починайте готуватись до EU AI Act вимог вже зараз — 2027 рік наближається швидше ніж здається.
Питання 2.4: Чи зафіксовані всі операції обробки через AI у реєстрі ROPA?
Чому критично для бізнесу: при будь-якій перевірці регулятор запитує ROPA першим. Якщо операції обробки через AI-сервіс там немає — це підстава для штрафу незалежно від того чи є DPA і SCCs. На практиці компанії ретельно обирають провайдера, підписують DPA, проводять TIA — і забувають внести операцію в ROPA. Ми завжди перевіряємо це при аудиті — і знаходимо прогалину у більшості клієнтів.
Що означає відповідь:
- ✔️ AI-операції задокументовані в ROPA: мета, категорії даних, отримувачі, локація серверів, термін зберігання → відповідність Art. 30
- ⚠️ ROPA є але AI-операції туди не внесені → часткова відповідність, потрібне оновлення
- 🔴 ROPA не ведеться взагалі → серйозне порушення незалежно від AI
Наша рекомендація: перед початком роботи з будь-яким AI-сервісом — одразу вносьте операцію до ROPA. Мінімум: назва сервісу, мета використання, категорії даних що передаються, локація серверів, правова база, термін зберігання. Займає 15 хвилин — і рятує від штрафу при перевірці. Оновлюйте при будь-якій зміні параметрів.
Блок 4: Контроль доступу
Цей блок перевіряє хто і за яких умов може отримати доступ до ваших даних — з боку провайдера і всередині вашої організації. Контроль доступу — одна з ключових вимог GDPR до технічних і організаційних заходів (TOM). На нашому досвіді — саме тут найбільший розрив між тим що компанії думають і тим що є насправді.
Питання 4.1: Чи може персонал провайдера технічно переглядати ваші документи і запити?
Чому критично для бізнесу: для юридичних фірм, медичних центрів і HR — навіть теоретична можливість доступу третьої сторони є юридичною проблемою незалежно від намірів провайдера. Адвокатська таємниця і медична конфіденційність захищені кримінальним законодавством в Австрії і Німеччині — і "ми не дивимось" провайдера не є юридичним захистом. Питання не в тому чи дивляться — а чи можуть технічно. "Ми не дивимось на ваші дані" — це заява. "Ми технічно не можемо подивитись" — це архітектура. Різниця принципова.
Що означає відповідь:
- ✔️ "Тільки автоматизовані системи, людський доступ технічно виключено" → максимальна гарантія
- ⚠️ "Доступ можливий тільки для безпеки і підтримки з вашого запиту" → є обмеження але не технічна неможливість
- 🔴 "Наша команда може переглядати контент для якості сервісу" → неприйнятно для конфіденційних галузей
Наша рекомендація: ми в AskYourDocs після передачі проекту клієнту не маємо технічного доступу до його бази і документів — не тому що пообіцяли, а тому що архітектурно відсутні в ланцюжку обробки. Саме це і є різницею між обіцянкою і системою. Запитайте будь-якого провайдера: "Покажіть технічно як влаштоване розмежування доступу до даних клієнтів" — відповідь на це питання скаже більше ніж будь-яка документація.
Питання 4.2: Чи є розмежування прав доступу всередині вашої організації?
Чому критично для бізнесу: навіть якщо провайдер ідеальний — нерегульований доступ всередині компанії є власним ризиком. Якщо будь-який співробітник може завантажувати будь-які документи і задавати будь-які питання — ви не контролюєте що потрапляє в систему. При інциденті регулятор запитає: хто і коли завантажив конкретний документ? Без логів і розмежованих прав — відповіді немає. Це порушує принцип мінімізації доступу (need-to-know) і унеможливлює аудит.
Що означає відповідь:
- ✔️ Ролі і права налаштовані: адміністратор, редактор, читач → базовий рівень контролю
- ✔️ Колекції документів розділені по відділах: юристи бачать юридичні, HR — кадрові → хороша практика
- ⚠️ Всі мають однаковий доступ до всіх документів → потрібне налаштування прав
- 🔴 Немає логування хто і що питав → неможливий аудит у разі інциденту
Наша рекомендація: перед запуском визначте три речі: хто адмініструє систему, хто завантажує документи, хто тільки задає питання. Плюс — які колекції документів доступні яким відділам. Для медичного центру: персонал бачить протоколи, пацієнти — публічний FAQ, кардіологія не бачить документів хірургії. Цей крок займає 30 хвилин при впровадженні і рятує від набагато дорожчих проблем при аудиті.
Питання 4.3: Чи логуються всі запити до AI-системи і як довго зберігаються логи?
Чому критично для бізнесу: логи запитів — це ваш аудиторський слід. Без них ви не зможете довести регулятору що система діяла коректно, не зможете розслідувати інцидент і не зможете відповісти на питання "хто і коли завантажив цей документ". Одночасно самі логи містять персональні дані і теж підпадають під вимоги GDPR — тобто потребують визначеного терміну зберігання і захисту. Відсутність логів і відсутність їх контролю — однаково погано.
Що означає відповідь:
- ✔️ Всі запити логуються, адміністратор має доступ, термін зберігання визначений (90 днів) → хороша практика
- ⚠️ Логи є але адміністратор не має до них доступу → інструмент без можливості використання
- 🔴 Логів немає взагалі → неможливий аудит і розслідування інцидентів
Наша рекомендація: перевірте чи ви як адміністратор бачите логи запитів — хто питав, що питав, коли. Це одночасно аналітика (що запитують найчастіше) і безпека (хто і коли мав доступ). Термін зберігання визначте в DPA або внутрішній політиці — зазвичай 30–90 днів достатньо. Довше — вже самі логи стають джерелом GDPR-ризику.
Питання 4.4: Чи є механізм видалення конкретних даних на запит суб'єкта (право на видалення)?
Чому критично для бізнесу: клієнт або колишній співробітник має право вимагати видалення своїх персональних даних (Art. 17 GDPR) — і ви зобов'язані виконати це в усіх системах, включаючи AI-асистент. На практиці ми бачимо одну і ту саму ситуацію: компанія каже "ми видалили" — але AI досі відповідає на основі видаленого документа тому що вектори залишились у базі. Це часткове виконання права на видалення — і регулятор його не прийме.
Що означає відповідь:
- ✔️ "Видалення документа автоматично видаляє його вектори з бази і він більше не з'являється у відповідях" → правильна архітектура
- ⚠️ "Документ видаляється але вектори можуть залишатись" → часткове виконання, потребує допрацювання
- 🔴 "Видалення неможливе або займає тижні" → критичне порушення Art. 17 GDPR
Наша рекомендація: перевірте це технічно до підписання контракту — видаліть тестовий документ і задайте питання з його контенту. Якщо AI досі відповідає — вектори не видалені. Займає 10 хвилин але дає юридичну впевненість що право на видалення виконується реально а не на папері.
Блок 5: Shadow AI і внутрішня політика
Найчастіше ігнорований блок — і найнебезпечніший. Компанія може ідеально вибрати провайдера з усіма сертифікатами і DPA — але якщо більшість співробітників паралельно використовують особисті ChatGPT-акаунти для роботи з корпоративними документами, всі попередні заходи не мають значення. Ми в AskYourDocs завжди проходимо цей блок з клієнтом першим — бо він часто виявляє що реальний ризик вже існує, поки компанія ще тільки обирає "правильний" провайдер. Детально про shadow AI — у статті 6 ризиків витоку даних через AI.
Питання 5.1: Чи знаєте ви які AI-інструменти зараз використовують ваші співробітники?
Чому критично для бізнесу: дослідження кібербезпеки стабільно фіксують одну картину: більшість співробітників що вставляють корпоративні дані в AI-сервіси роблять це через особисті акаунти — поза будь-яким корпоративним контролем. Це не зловмисність — це зручність. І кожен такий запит з клієнтськими даними, умовами договорів або кадровою інформацією є потенційним витоком. Нові виявляються при інцидентах, а не при аудитах — і тоді вже дорого.
Що означає відповідь:
- ✔️ "Є реєстр AI-інструментів, IT знає що використовується і з якими даними" → базовий контроль
- ⚠️ "Переважно ChatGPT і Google, деталі невідомі" → типова ситуація — shadow AI вже є, питання в масштабі
- 🔴 "Не знаємо що використовують співробітники" → shadow AI є і ніхто не контролює
Наша рекомендація: проведіть анонімне опитування серед співробітників — які AI-інструменти вони використовують для роботи і з якими типами даних. Анонімність критична: без неї отримаєте соціально прийнятні відповіді а не реальну картину. Результати зазвичай шокують навіть CTO. Без розуміння реального стану — будь-яка AI-політика є декларацією а не захистом.
Питання 5.2: Чи є корпоративна AI-політика і чи всі співробітники її знають?
Чому критично для бізнесу: з лютого 2025 Art. 4 EU AI Act вимагає забезпечити AI literacy для персоналу — це вже обов'язкова вимога, не рекомендація. Але навіть якщо відкласти регуляторний аспект: більшість співробітників що допускають витоки через AI не вважають що роблять щось неправильне. Вони просто не знають де межа. Без конкретної корпоративної AI-політики — кожен встановлює її для себе сам. І результати передбачувані.
Що означає відповідь:
- ✔️ Є конкретний документ: дозволені інструменти, заборонені типи даних, що робити при помилці AI + щорічне навчання → відповідність AI Act і реальний захист
- ⚠️ "Є загальна IT-політика де згадується AI" → недостатньо конкретно для реального захисту
- 🔴 Немає жодної AI-політики → порушення Art. 4 EU AI Act і відсутність будь-якого захисту
Наша рекомендація: мінімальна AI-політика — це 1–2 сторінки з трьома конкретними відповідями: які інструменти дозволені, які типи даних не можна передавати в AI (персональні дані клієнтів, медична інформація, умови контрактів), куди звертатись якщо щось пішло не так. Складність не важлива — важлива конкретність і те щоб кожен співробітник міг сказати "я знаю що можна а що ні".
Питання 5.3: Чи є зручна корпоративна AI-альтернатива яка замінить особисті акаунти?
Чому критично для бізнесу: заборони не працюють без зручної альтернативи — це не припущення, це практика. Співробітник використовує особистий ChatGPT не зі злого умислу: він шукає спосіб працювати ефективніше. Якщо корпоративна система незручна, вимагає VPN або окремого логіну — він повернеться до звичного інструменту через тиждень. Ми бачили це десятки разів: компанія впроваджує корпоративний AI — і паралельно 70% співробітників продовжують використовувати особисті акаунти бо "так зручніше".
Що означає відповідь:
- ✔️ Є корпоративний AI-асистент через Telegram або чат на сайті — в тому ж місці де вже спілкується команда → природно витісняє особисті акаунти
- ⚠️ Є система але вона потребує окремого входу або незручна у використанні → бар'єр залишається, shadow AI продовжується
- 🔴 Корпоративної альтернативи немає і не планується → заборони без альтернативи не працюють
Наша рекомендація: найефективніший захист від shadow AI — не заборона а заміна. Корпоративний AI-асистент на ваших документах через Telegram відповідає точніше ніж загальний ChatGPT (знає ваші конкретні документи і регламенти), безпечніше (дані на вашому сервері) і зручніше (звичний месенджер). Потреба в особистому ChatGPT зникає сама — не через заборону, а тому що корпоративний варіант просто кращий для їхньої конкретної роботи.
Питання 5.4: Чи проводилось навчання співробітників щодо безпечного використання AI?
Чому критично для бізнесу: Art. 4 EU AI Act вимагає AI literacy для персоналу — з лютого 2025 це обов'язкова вимога з можливістю перевірки регулятором. Але є практичний аспект важливіший за регуляторний: переважна більшість співробітників що допускають витоки через shadow AI не вважали що роблять щось неправильне. Вони просто не знали. Одне конкретне 30-хвилинне навчання з реальними прикладами що сталось з іншими компаніями — ефективніше ніж будь-яка IT-заборона або довгий документ з правилами.
Що означає відповідь:
- ✔️ Регулярне навчання (раз на рік мінімум) з документуванням проходження → відповідність EU AI Act і реальна обізнаність
- ⚠️ "Розіслали листа з правилами" → недостатньо ні для AI Act ні для реального розуміння
- 🔴 Навчання не проводилось → порушення Art. 4 EU AI Act, регулятор може вимагати докази
Наша рекомендація: формат важливіший за тривалість. 30-хвилинна сесія з конкретними прикладами ("ось що сталось з компанією X через особистий ChatGPT-акаунт", "ось які дані не можна вставляти і чому") плюс відповіді на питання — краще ніж 2-годинна лекція з абстрактними правилами. Документуйте проходження: ім'я, дата, підпис або підтвердження — регулятор може запросити докази і "ми проводили навчання" без документації не рахується.
Як інтерпретувати результати чеклисту
Підрахуйте скільки відповідей потрапило в кожну зону. Ми пропонуємо цю шкалу не як абстрактний рейтинг, а як інструмент для прийняття конкретного рішення: чи можна зараз використовувати сервіс для персональних даних — і якщо ні, що конкретно виправити.
🟢 Зелена зона: 16–20 відповідей "✔️"
Провайдер демонструє зрілу практику безпеки і GDPR-відповідності. Можна використовувати для обробки персональних даних при дотриманні внутрішніх процедур: ROPA оновлено, DPA підписано, TIA проведено. Рекомендуємо повторний огляд через 6 місяців або при суттєвих змінах у системі провайдера — практики безпеки і умови договорів змінюються.
🟡 Жовта зона: 10–15 відповідей "✔️"
Є базовий рівень захисту але є прогалини. До початку обробки персональних даних — усуньте всі "🔴" відповіді і виправте більшість "⚠️". Типові кроки які ми проходимо з клієнтами: підписати DPA (якщо не підписано — займає один день), провести TIA, оновити ROPA, запровадити корпоративну AI-політику. Хмарний сервіс без data residency в ЄС — прийнятний тільки для неперсональних даних.
🔴 Червона зона: менше 10 відповідей "✔️"
Серйозні прогалини що створюють реальний GDPR-ризик. Не використовуйте цей сервіс для обробки персональних даних до усунення критичних проблем. Якщо провайдер не може або не хоче їх усунути — розгляньте перехід на self-hosted рішення, де більшість питань цього чеклисту просто не виникають: дані ніколи не покидають ваш сервер і ви є і контролером і процесором одночасно.
Швидка таблиця рішень
| Ситуація |
Рекомендація |
| Всі відповіді ✔️, сервери в ЄС, неамериканський провайдер |
✅ Можна використовувати для персональних даних |
| Є DPA і SCCs, сервери в США |
⚠️ Потрібен TIA. Для медицини і юристів — не рекомендуємо |
| Немає DPA або провайдер відмовляється надати |
🔴 Не використовувати для персональних даних — крапка |
| Shadow AI є, корпоративної альтернативи немає |
⚠️ Впровадити корпоративний AI-асистент — заборона без альтернативи не працює |
| Self-hosted рішення на EU-сервері |
✅ Більшість питань цього чеклисту не виникають — дані у вас |
Що робити якщо провайдер не відповідає на питання
Якщо провайдер не може або не хоче відповісти на питання з цього чеклисту — це вже інформація. Ми в AskYourDocs бачили достатньо таких розмов щоб розпізнати типові відмовки — і пояснити що за ними стоїть.
"Ми не можемо розкрити цю інформацію з міркувань безпеки."
Це маніпуляція. Реальна безпека не вимагає приховувати від клієнта де зберігаються його дані або чи є DPA. Провайдери з зрілою практикою безпеки охоче діляться Security Overview, актуальними сертифікатами і шаблонним DPA — бо це конкурентна перевага, а не слабке місце. Якщо провайдер відмовляє — він ховає не "секрети безпеки", а відсутність юридичної зрілості.
"Перевірте наші умови використання — там все написано."
Умови використання пишуться в інтересах провайдера і він може змінити їх в односторонньому порядку без вашої згоди. DPA — юридично обов'язковий документ з конкретними зобов'язаннями що захищають вас. Якщо замість DPA пропонують "читати Terms of Service" — провайдер свідомо уникає юридичної відповідальності.
"Ми дуже великі і відомі — нам можна довіряти."
Шведський регулятор у 2024 оштрафував аптечну мережу Apoteket на SEK 37 млн (≈ €3.2 млн) — не за витік даних, а за відсутність належної правової підстави при передачі медичних даних клієнтів третій стороні. Meta отримала мільярдні штрафи. Розмір компанії не замінює юридичну документацію — регулятор не пом'якшує вимоги тому що ви використовуєте відому платформу.
Алгоритм дій при відсутності відповідей:
- Задокументуйте питання і відповіді (або їх відсутність) письмово — лист електронною поштою з підтвердженням читання
- Escalate до юридичного відділу або DPO — офіційний запит часто отримує відповідь там де неформальне прохання ігнорується
- Якщо критичні питання (DPA, локація серверів) залишаються без відповіді — не використовуйте сервіс для персональних даних до їх вирішення
- Розгляньте self-hosted рішення — де відповідь на більшість питань цього чеклисту: "ваші дані на вашому сервері і тільки у вас"
Часті питання
Чи потрібно проходити весь чеклист для кожного AI-сервісу?
Так — для кожного сервісу що обробляє персональні дані. Для сервісів що працюють тільки з публічними або знеособленими даними — достатньо Блоку 3 (технічна безпека) і Блоку 5 (shadow AI). Блок 5 є обов'язковим для всіх незалежно від типу даних — shadow AI існує у кожній організації де є AI-інструменти без корпоративної альтернативи.
Як часто потрібно оновлювати результати чеклисту?
Раз на 6 місяців — або при зміні провайдера, суттєвому оновленні сервісу, зміні типів даних що обробляються, появі нових регуляторних вимог. Також обов'язково — при будь-якому інциденті безпеки у провайдера навіть якщо він вас безпосередньо не стосується: зміни в системі безпеки провайдера після інциденту можуть впливати на ваш DPA і ROPA.
Що якщо наш поточний AI-сервіс не пройшов чеклист?
Перш за все — не вимикайте систему і не панікуйте. Оцініть конкретно які питання не пройдені. Відсутній DPA виправляється за день — більшість провайдерів мають його на сайті. Сервери в США без TIA — виправляється за тижні через проведення TIA і підписання SCCs. Якщо критичні питання (DPA, локація серверів) не можуть бути виправлені провайдером — це сигнал розглянути міграцію на self-hosted. Ми допомагаємо оцінити конкретну ситуацію — напишіть нам у Telegram.
Чи потрібен окремий чеклист для self-hosted рішення?
Для self-hosted питання Блоків 1 і 2 переважно не виникають — ви одночасно контролер і процесор, транскордонного трансферу немає. Але Блоки 3, 4 і 5 залишаються повністю актуальними: технічна безпека вашого сервера, контроль доступу і shadow AI — це ваша відповідальність незалежно від архітектури. Правильно налаштована self-hosted система вирішує більшість питань Блоків 1–2, але не звільняє від уваги до 3–5.
Хочете перевірити свій AI-сервіс?
Надішліть нам відповіді на цей чеклист — і за 30 хвилин ми покажемо де є реальні GDPR-ризики і як їх усунути технічно, без дорогих юридичних консультацій. Якщо ризики критичні — запропонуємо конкретний план міграції на self-hosted з оцінкою вартості і часу.
Написати в Telegram →
Впровадження self-hosted AI-асистента під ключ за 5–7 днів. Сервер в ЄС під вашим контролем. Дані залишаються тільки у вас.
Читайте також
⸻
Джерела: Secure Privacy — GDPR Compliance 2026 · Parloa — AI Privacy Rules: GDPR, EU AI Act 2026 · TechnovaPartners — Security and GDPR in AI Agents · Vectra AI — GDPR Compliance Security Requirements 2026 · GDPR Local — EU AI Act Summary · EDPB — European Data Protection Board · IMY — Fines against Apoteket and Apohem (2024)