Оцінка впливу на захист даних (DPIA)
QR Branding API — функції ШІ
| Поле | Значення |
|---|---|
| Дата | 2026-03-08 |
| Контролер | QR Branding (Quartzon) |
| Версія | 1.0 |
| Статус | Затверджено |
| Наступний перегляд | 2026-09-08 |
1. Опис обробки
1.1 Характер обробки
QR Branding пропонує генерацію QR-кодів за допомогою ШІ у двох режимах:
- Із власними обліковими записами QR Branding у провайдерів LLM: дизайнер ШІ на qr-branding.com і керований ендпоінт маркетплейсу (
POST /api/qr/ai/generate-managed). Кожен запит обслуговує внутрішній ланцюжок резервування провайдерів (Groq, Google Gemini, OpenAI). - Із власним ключем клієнта (BYOK): ендпоінт маркетплейсу
POST /api/qr/ai/generate. Клієнт надає власний ключ API і вибирає провайдера (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek чи Qwen або власний OpenAI-сумісний ендпоінт).
В обох режимах користувач надсилає промпт для дизайну природною мовою (наприклад, «сучасний синій QR-код для технологічної компанії») разом із вмістом QR (URL, текст, vCard тощо). Система:
- Надсилає лише промпт для дизайну та параметри генерації зовнішньому провайдеру LLM: тому, що обслуговує запит у ланцюжку резервування QR Branding, або вибраному користувачем (BYOK).
- Отримує від LLM конфігурацію дизайну у форматі JSON.
- Генерує QR-код із наданим вмістом і запропонованим дизайном.
- Повертає зображення QR користувачеві.
1.2 Обсяг
- Дані, що обробляються: промпти для дизайну (довільний текст), параметри генерації (пресет стилю, креативність, сувора сканованість), вміст QR (URL, текст, контактні дані vCard, облікові дані WiFi, геолокація), ключ API клієнта (лише BYOK, тимчасово).
- Орієнтовний обсяг: до 15 запитів ШІ на хвилину з однієї IP-адреси, 100 генерацій на хвилину глобально.
- Суб’єкти даних, яких це стосується: користувачі сайту qr-branding.com, користувачі API (розробники, компанії) та опосередковано особи, чиї дані містяться у вмісті QR (контакти vCard).
- Географічне охоплення: глобальне (публічний API на RapidAPI Marketplace).
1.3 Контекст
- Сервіс без збереження стану: бази даних немає, вміст QR не зберігається.
- Власні облікові записи QR Branding (сайт і керований ендпоінт): QR Branding має власні ключі API в Groq, Google (Gemini) і OpenAI, які діють як його обробники та зазначені на сторінці субобробників. Їм не надсилаються електронна пошта, платіжні дані, IP-адреса чи ідентифікатор клієнта.
- Модель BYOK (Bring Your Own Key) (
POST /api/qr/ai/generate): клієнт надає власний ключ API в кожному запиті; QR Branding не використовує власні облікові записи для цих запитів. - Вміст QR ніколи не надсилається провайдерам ШІ; надсилається лише промпт для дизайну.
- Чутливі поля, згенеровані LLM (URL, base64), обнуляються перед рендерингом.
- Сервіс працює на Azure Functions (Consumption Plan).
- В ендпоінті BYOK договірні відносини з провайдером LLM — це прямі відносини між клієнтом і провайдером.
1.4 Мета
Дати користувачам змогу генерувати персоналізовані дизайни QR за описом природною мовою, без потреби налаштовувати параметри вручну.
2. Необхідність і пропорційність
2.1 Правова підстава
Виконання договору (ст. 6(1)(b) GDPR): обробка необхідна для надання конкретної послуги, запитаної користувачем.
2.2 Мінімізація даних
| Принцип | Реалізація |
|---|---|
| Лише необхідні дані | До LLM надсилається лише промпт, а не вміст QR |
| Без зберігання | Обробка в пам’яті; текст промпту та вміст QR видаляються після HTTP-відповіді. Лише згенерована конфігурація дизайну може кешуватися до 30 днів під ключем, похідним від хешу SHA-256 промпту та параметрів |
| Без профілювання | Профілі користувачів чи історії запитів не створюються |
| Анонімізація | IP-адреси в журналах анонімізовано (останній октет замасковано) |
| Розділення | Вміст QR і промпт ШІ розділено в потоці даних |
2.3 Пропорційність
Обробка є пропорційною, оскільки:
- Користувач активно обирає використання функції ШІ (окремий ендпоінт).
- В ендпоінті BYOK користувач сам вибирає провайдера LLM; на сайті та в керованому ендпоінті провайдер — один з обробників, зазначених на сторінці субобробників.
- Передається лише промпт для дизайну (а не персональні дані із вмісту QR).
- Менш інвазивної альтернативи для генерації дизайнів із природної мови не існує.
3. Виявлення та оцінка ризиків
3.1 Виявлені ризики
| # | Ризик | Імовірність | Вплив | Рівень | Пом’якшення |
|---|---|---|---|---|---|
| R1 | Ін’єкція в промпт: користувач вставляє в промпт шкідливі інструкції | Середня | Середній | Середній | Розмежувачі <user_request>, інструкції проти витоку в системному промпті, обнулення полів URL/base64 після LLM |
| R2 | PII у промптах: користувач включає персональні дані в опис дизайну | Середня | Низький | Низький | Текст промпту не зберігається (кеш зберігає лише згенерований дизайн під ключем, похідним від хешу); промпт надсилається без жодного ідентифікатора користувача; задокументована політика використання |
| R3 | Витік системного промпту: зловмисник вилучає системні інструкції | Низька | Низький | Низький | Захисний футер проти витоку в системному промпті, очищення виводу (видалення HTML-тегів) |
| R4 | Міжнародна передача: промпти пересилаються провайдерам за межами ЄЕЗ | Середня | Низький | Низький | Облікові записи QR Branding: Groq, Google і OpenAI (США) діють як обробники згідно з умовами обробки даних кожного провайдера; надсилаються лише промпт для дизайну та параметри. BYOK: клієнт має прямі відносини з провайдером і власну DPA; QR Branding діє лише як технічний посередник. Розкрито в Політиці конфіденційності та на сторінці субобробників |
| R5 | Зберігання провайдером LLM: провайдер зберігає дані за власними політиками | Середня | Низький | Низький | Облікові записи QR Branding: регулюється умовами обробки даних кожного провайдера з QR Branding. BYOK: відповідальність клієнта згідно з його власними умовами з провайдером |
| R6 | Відповідь LLM зі шкідливим вмістом: XSS, шкідливі URL | Середня | Середній | Середній | Регулярний вираз для очищення HTML з тайм-аутом, обнулення полів URL/base64, MaxDepth=32 під час десеріалізації |
| R7 | Denial of wallet: зловживання ендпоінтом ШІ для роздування витрат | Середня | Високий | Високий | Обмеження частоти (15 ШІ/хв на IP, 100/хв глобально), RenderThrottle із семафором, functionTimeout 1:30 |
| R8 | Витік ключа API в журнали | Низька | Високий | Середній | SanitizeForLog() маскує шаблони ключів API, повідомлення про помилки без PII |
3.2 Схема потоку даних
User → qr-branding.com or RapidAPI Proxy → Azure Functions
↓
[Design prompt + parameters only]
↓
LLM provider (QR Branding's fallback chain,
or the user's choice on BYOK)
↓
[Design JSON config]
↓
QR Rendering (SkiaSharp)
+ QR content (never leaves the server)
↓
QR image → User
4. Заходи з пом’якшення
4.1 Запроваджені технічні заходи
| Захід | Пом’якшений ризик | Статус |
|---|---|---|
Розмежувачі промпту (<user_request>) | R1 | ✅ Реалізовано |
| Захисний футер проти витоку в системному промпті | R1, R3 | ✅ Реалізовано |
| Обнулення полів URL/base64 від LLM | R1, R6 | ✅ Реалізовано |
| Регулярний вираз для очищення HTML з тайм-аутом (3 с) | R6 | ✅ Реалізовано |
| MaxDepth=32 у JsonSerializer | R6 | ✅ Реалізовано |
| Обмеження частоти ШІ (15/хв на IP, 100/хв глобально) | R7 | ✅ Реалізовано |
| RenderThrottle (семафор, 4 одночасно) | R7 | ✅ Реалізовано |
| functionTimeout 1:30 | R7 | ✅ Реалізовано |
| SanitizeForLog(): маскування ключів API | R8 | ✅ Реалізовано |
| Анонімізація IP (останній октет) | R2 | ✅ Реалізовано |
| Повідомлення про помилки без PII | R2 | ✅ Реалізовано |
| Обмеження кількості вихідних токенів у кожному виклику LLM | R7 | ✅ Реалізовано |
| Content-Length + перевірка розміру після читання (1MB) | R7 | ✅ Реалізовано |
| Відокремлення systemInstruction для Google | R1 | ✅ Реалізовано |
4.2 Організаційні заходи
| Захід | Пом’якшений ризик | Статус |
|---|---|---|
| Опублікована Політика конфіденційності | R4, R5 | ✅ Реалізовано |
| Розкриття провайдерів LLM у документації та на сторінці субобробників | R4 | ✅ Реалізовано |
| DPA з провайдерами LLM, що використовуються з обліковими записами QR Branding (Groq, Google, OpenAI) | R4, R5 | ⚠️ Очікує підтвердження |
| DPA з провайдером LLM в ендпоінті BYOK | R5 | Відповідальність клієнта |
| Задокументована процедура DSR | Загальний | ✅ Задокументовано |
| План реагування на інциденти | Загальний | ✅ Задокументовано |
5. Висновок
5.1 Залишковий ризик
З урахуванням усіх технічних і організаційних заходів залишковий ризик оцінюється як НИЗЬКИЙ:
- Обробка відбувається без збереження стану: не зберігаються ні вміст QR, ні текст промпту (кеш промптів зберігає лише згенеровані дизайни під ключем, похідним від хешу).
- Вміст QR (потенційно чутливий) ніколи не залишає інфраструктуру Azure.
- Третім особам передаються лише промпти для дизайну (які рідко містять PII).
- Усі технічні заходи з пом’якшення за результатами масштабного аудиту реалізовано й перевірено.
5.2 Рішення
✅ Обробку можна здійснювати за наявних заходів.
Попередня консультація з наглядовим органом (ст. 36 GDPR) не потрібна, оскільки залишковий ризик низький.
5.3 Перегляд
Цю DPIA буде переглянуто:
- Щонайменше кожні 6 місяців.
- Коли додаються нові провайдери LLM.
- Коли змінюється потік даних ендпоінту ШІ.
- Коли з’являються нові типи вмісту QR, що можуть містити чутливі дані.
Документ створено 2026-03-08. Наступний плановий перегляд: 2026-09-08.