Аналіз правових підстав обробки даних
QR Branding API — ст. 6 GDPR
| Поле | Значення |
|---|---|
| Контролер | QR Branding (Quartzon) |
| Дата | 2026-03-08 |
| Версія | 1.0 |
1. Принцип законності (ст. 6)
Будь-яка обробка персональних даних має ґрунтуватися щонайменше на одній із правових підстав, передбачених ст. 6(1) GDPR. Нижче проаналізовано кожну операцію обробки в QR Branding і відповідну правову підставу.
2. Аналіз за операціями обробки
2.1 Генерація QR-кодів, що містять персональні дані
| Аспект | Аналіз |
|---|---|
| Операція | Користувач надсилає вміст QR, який може містити персональні дані (vCard з ім’ям, email, телефоном і адресою; геолокацію; адреси email) |
| Правова підстава | Ст. 6(1)(b) — виконання договору |
| Обґрунтування | Обробка необхідна для надання послуги, яку користувач замовив через RapidAPI. Без обробки вмісту неможливо згенерувати запитаний QR-код |
| Пропорційність | Мінімальна: обробляється лише суворо необхідний вміст, у пам’яті, без зберігання |
| Менш інвазивна альтернатива | Немає: вміст QR і Є тими даними, які потрібно закодувати |
2.2 QR-коди, створені ШІ
Генерація ШІ працює у двох режимах:
- Власні облікові записи QR Branding (дизайнер ШІ на qr-branding.com і керований ендпоінт
POST /api/qr/ai/generate-managed): QR Branding надсилає промпт для дизайну провайдеру LLM зі свого внутрішнього ланцюжка резервування (Groq, Google Gemini, OpenAI), використовуючи власні ключі API. Ці провайдери діють як обробники QR Branding і зазначені на сторінці субобробників. - BYOK (Bring Your Own Key) (ендпоінт
POST /api/qr/ai/generate): клієнт надає власний ключ API і вибирає провайдера; QR Branding не використовує власні облікові записи для цих запитів.
| Аспект | Аналіз |
|---|---|
| Операція | Користувач надсилає промпт для дизайну. QR Branding пересилає промпт провайдеру LLM: із власними ключами (сайт і керований ендпоінт) або з ключем клієнта (llmApiKey, ендпоінт BYOK) |
| Модель | Власні облікові записи QR Branding у Groq, Google (Gemini) і OpenAI або BYOK (Bring Your Own Key) із провайдером, вибраним клієнтом |
| Правова підстава | Ст. 6(1)(b) — виконання договору |
| Обґрунтування | Користувач явно запитує дизайн, створений ШІ: на сайті та в керованому ендпоінті — запускаючи генерацію ШІ; в ендпоінті BYOK — також вибираючи провайдера й надаючи власний ключ API. Обробка необхідна для виконання цього конкретного запиту |
| Пропорційність | До LLM надсилаються лише промпт для дизайну та параметри генерації. Вміст QR, IP-адреси та ідентифікаційні дані НІКОЛИ не передаються. В ендпоінті BYOK ключ API клієнта не зберігається й не журналюється |
| Примітка | Користувач активно обирає використання генерації ШІ та промпт, який надсилає. В ендпоінті BYOK він також обирає провайдера LLM і надає власний ключ API, а відносини з провайдером LLM — це прямі відносини між клієнтом і провайдером |
2.3 Обмеження частоти запитів
| Аспект | Аналіз |
|---|---|
| Операція | Підрахунок запитів за ідентифікатором (користувач RapidAPI, ID підписки, анонімізована IP-адреса) для обмеження частоти використання |
| Правова підстава | Ст. 6(1)(f) — законний інтерес |
| Законний інтерес | Захист доступності сервісу для всіх користувачів і запобігання зловживанням і надмірним витратам |
| Тест балансу | |
| — Інтерес контролера | Високий: без обмеження частоти один користувач може вичерпати ресурси або спричинити непомірні витрати |
| — Вплив на суб’єкта даних | Мінімальний: для підрахунку запитів використовується лише псевдонімний ідентифікатор, дані зберігаються в оперативній пам’яті (2 хв), IP-адреси анонімізовано |
| — Розумні очікування | Так: користувачі API очікують обмеження частоти як стандартної галузевої практики |
| — Гарантії | Тимчасові дані (2 хв), анонімізація IP, обмеження відстеження (50 тис. IP), ідентифікатори не журналюються |
| Висновок | Законний інтерес явно переважає з огляду на мінімальний вплив на суб’єкта даних |
2.4 Телеметрія та діагностика (Application Insights)
| Аспект | Аналіз |
|---|---|
| Операція | Збір метрик продуктивності, помилок і метаданих запитів (без PII) |
| Правова підстава | Ст. 6(1)(f) — законний інтерес |
| Законний інтерес | Підтримання надійності й доступності сервісу та швидка діагностика проблем |
| Тест балансу | |
| — Інтерес контролера | Високий: без телеметрії неможливо виявляти й усувати інциденти |
| — Вплив на суб’єкта даних | Мінімальний: PII вилучено з повідомлень про помилки, ключі API замасковано, IP-адреси анонімізовано |
| — Розумні очікування | Так: моніторинг — стандартна практика для хмарних сервісів |
| — Гарантії | Зберігання 90 днів, журнали без PII, анонімізація IP, маскування ключів API |
| Висновок | Законний інтерес явно переважає |
2.5 Автентифікація RapidAPI
| Аспект | Аналіз |
|---|---|
| Операція | Перевірка заголовка X-RapidAPI-Proxy-Secret у кожному запиті |
| Правова підстава | Ст. 6(1)(f) — законний інтерес |
| Обґрунтування | Захист сервісу від несанкціонованого доступу |
| Примітка | Секрет — це дані сервера, а не дані користувача. На цьому етапі персональні дані взагалі не обробляються |
3. Правові підстави, на які ми НЕ спираємося
| Правова підстава | Ст. | Чому не використовується? |
|---|---|---|
| Згода | Ст. 6(1)(a) | Явна згода не збирається. Вона не потрібна: обробка ґрунтується на договорі й законному інтересі. Опора на згоду створила б додаткові обов’язки (можливість відкликання) без жодної користі |
| Юридичний обов’язок | Ст. 6(1)(c) | Жоден юридичний обов’язок не вимагає обробки цих даних |
| Життєво важливі інтереси | Ст. 6(1)(d) | Не застосовується: сервіс не обробляє дані для захисту життєво важливих інтересів |
| Суспільний інтерес | Ст. 6(1)(e) | Не застосовується: це приватний комерційний сервіс |
4. Особливі категорії даних (ст. 9)
QR Branding не запитує й не потребує особливих категорій персональних даних (етнічне походження, здоров’я, сексуальна орієнтація тощо).
Проте користувач може включити такі дані до вмісту QR (наприклад, QR-код із медичними даними). У такому разі:
- QR Branding діє як технічний обробник, що кодує дані, не інтерпретуючи їх.
- Відповідальність за обробку особливих категорій даних несе користувач, який вирішив їх включити.
- Правовою підставою в цьому сценарії буде явна згода суб’єкта даних, яку користувач має отримати до кодування даних.
- QR Branding не зберігає ці дані й видаляє їх одразу після генерації.
5. Дані дітей (ст. 8)
- QR Branding — це API-сервіс B2B/B2C, орієнтований на розробників і компанії.
- Він не призначений для дітей віком до 16 років.
- Дані про вік не збираються, перевірка віку не проводиться.
- Якщо користувач включає дані дітей до вмісту QR, відповідальність за отримання згоди батьків несе користувач.
6. Міжнародні передачі (ст. 44–49)
| Напрям | Правова підстава передачі | Провайдер |
|---|---|---|
| ЄС/США (Azure) | Online Services Terms + SCC | Microsoft Azure |
| США | Умови платформи | RapidAPI |
| США | Умови обробки даних кожного провайдера (див. сторінку субобробників) | Groq, Google (Gemini), OpenAI: генерація ШІ з обліковими записами QR Branding |
Примітка щодо провайдерів LLM: із власними обліковими записами QR Branding (сайт і керований ендпоінт) промпти для дизайну передаються Groq, Google (Gemini) або OpenAI, які діють як обробники QR Branding. В ендпоінті BYOK промпти передаються провайдеру, вибраному клієнтом (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek чи Qwen або власний OpenAI-сумісний ендпоінт клієнта), з використанням власного ключа API клієнта. Відповідальність за цю передачу несе клієнт, який має прямі договірні відносини з провайдером; QR Branding діє як технічний посередник.
Використання стандартного ендпоінту генерації QR не передбачає жодної передачі провайдерам LLM (обробка відбувається виключно в Azure).
7. Перегляд
Цей аналіз правових підстав необхідно переглядати:
- Коли додаються нові операції обробки
- Коли змінюються дані, що обробляються в наявних операціях
- Коли змінюються політики провайдерів LLM
- Щонайменше раз на рік
Документ створено 2026-03-08.