Data protection impact assessment (DPIA)
QR Branding API — AI features
| Field | Value |
|---|---|
| Date | 2026-03-08 |
| Controller | QR Branding (Quartzon) |
| Version | 1.0 |
| Status | Approved |
| Next review | 2026-09-08 |
1. Description of the processing
1.1 Nature of the processing
QR Branding offers AI-powered QR code generation in two modes:
- With QR Branding's own LLM provider accounts: the AI designer on qr-branding.com and the managed marketplace endpoint (
POST /api/qr/ai/generate-managed). An internal fallback chain of providers (Groq, Google Gemini, OpenAI) serves each request. - With the customer's own key (BYOK): the marketplace endpoint
POST /api/qr/ai/generate. The customer supplies their own API key and chooses the provider (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek or Qwen, or their own OpenAI-compatible endpoint).
In both modes the user sends a natural-language design prompt (e.g. "modern blue QR code for a tech company") together with the QR content (URL, text, vCard, etc.). The system:
- Sends only the design prompt and the generation parameters to an external LLM provider: the one serving the request in QR Branding's fallback chain, or the one selected by the user (BYOK).
- Receives a JSON design configuration from the LLM.
- Generates the QR code with the supplied content and the suggested design.
- Returns the QR image to the user.
1.2 Scope
- Data processed: design prompts (free text), generation parameters (style preset, creativity, strict scannability), QR content (URLs, text, vCard contact details, WiFi credentials, geolocation), the customer's API key (BYOK only, transient).
- Estimated volume: up to 15 AI requests per minute per IP, 100 generations per minute globally.
- Data subjects affected: users of the qr-branding.com site, API users (developers, businesses) and, indirectly, the people whose data appears in the QR content (vCard contacts).
- Geographic area: global (public API on RapidAPI Marketplace).
1.3 Context
- Stateless service: there is no database and no QR content is persisted.
- QR Branding's own accounts (site and managed endpoint): QR Branding holds its own API keys with Groq, Google (Gemini) and OpenAI, which act as its processors and are listed on the subprocessors page. No email, billing data, IP address or customer identifier is sent to them.
- BYOK (Bring Your Own Key) model (
POST /api/qr/ai/generate): the customer supplies their own API key with each request; QR Branding does not use its own accounts for these requests. - QR content is never sent to AI providers; only the design prompt is.
- Sensitive fields generated by the LLM (URLs, base64) are nullified before rendering.
- The service runs on Azure Functions (Consumption Plan).
- On the BYOK endpoint, the contractual relationship with the LLM provider is a direct one between the customer and the provider.
1.4 Purpose
To let users generate customized QR designs from natural-language descriptions, removing the need to configure parameters by hand.
2. Necessity and proportionality
2.1 Legal basis
Performance of a contract (Art. 6(1)(b) GDPR): the processing is necessary to provide the specific service requested by the user.
2.2 Data minimization
| Principle | Implementation |
|---|---|
| Only necessary data | Only the prompt is sent to the LLM, not the QR content |
| No storage | In-memory processing; the prompt text and the QR content are discarded after the HTTP response. Only the generated design configuration may be cached for up to 30 days, under a key derived from a SHA-256 hash of the prompt and the parameters |
| No profiling | No user profiles or request histories are created |
| Anonymization | IP addresses anonymized in logs (last octet masked) |
| Segregation | QR content and AI prompt kept separate in the data flow |
2.3 Proportionality
The processing is proportionate because:
- The user actively chooses to use the AI feature (separate endpoint).
- On the BYOK endpoint the user selects the LLM provider; on the site and the managed endpoint the provider is one of the processors listed on the subprocessors page.
- Only the design prompt is transferred (not personal data from the QR content).
- There is no less intrusive alternative for generating designs from natural language.
3. Risk identification and assessment
3.1 Identified risks
| # | Risk | Likelihood | Impact | Level | Mitigation |
|---|---|---|---|---|---|
| R1 | Prompt injection: the user injects malicious instructions into the prompt | Medium | Medium | Medium | <user_request> delimiters, anti-leak instructions in the system prompt, URL/base64 fields nullified after the LLM |
| R2 | PII in prompts: the user includes personal data in the design description | Medium | Low | Low | We do not store the prompt text (the cache keeps only the generated design under a hash-derived key); the prompt is sent without any identifier of the user; documented usage policy |
| R3 | System prompt exfiltration: an attacker extracts the system instructions | Low | Low | Low | Anti-leak footer in the system prompt, sanitized output (HTML tags removed) |
| R4 | International transfer: prompts forwarded to providers outside the EEA | Medium | Low | Low | QR Branding's accounts: Groq, Google and OpenAI (USA) act as processors under each provider's data processing terms; only the design prompt and the parameters are sent. BYOK: the customer has a direct relationship with the provider and their own DPA; QR Branding only acts as a technical intermediary. Disclosure in the Privacy Policy and on the subprocessors page |
| R5 | Retention by the LLM provider: the provider retains data under its own policies | Medium | Low | Low | QR Branding's accounts: governed by each provider's data processing terms with QR Branding. BYOK: the customer's responsibility under their own terms with the provider |
| R6 | LLM response with malicious content: XSS, malicious URLs | Medium | Medium | Medium | HTML sanitization regex with timeout, URL/base64 fields nullified, MaxDepth=32 on deserialization |
| R7 | Denial of wallet: abuse of the AI endpoint to run up costs | Medium | High | High | Rate limiting (15 AI/min per IP, 100/min globally), RenderThrottle with semaphore, functionTimeout 1:30 |
| R8 | API key leakage in logs | Low | High | Medium | SanitizeForLog() redacts API key patterns, PII-free error messages |
3.2 Data flow map
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. Mitigation measures
4.1 Technical measures in place
| Measure | Risk mitigated | Status |
|---|---|---|
Prompt delimiters (<user_request>) | R1 | ✅ Implemented |
| Anti-leak footer in the system prompt | R1, R3 | ✅ Implemented |
| Nullification of LLM URL/base64 fields | R1, R6 | ✅ Implemented |
| HTML sanitization regex with timeout (3s) | R6 | ✅ Implemented |
| MaxDepth=32 in JsonSerializer | R6 | ✅ Implemented |
| AI rate limiting (15/min per IP, 100/min globally) | R7 | ✅ Implemented |
| RenderThrottle (semaphore, 4 concurrent) | R7 | ✅ Implemented |
| functionTimeout 1:30 | R7 | ✅ Implemented |
| SanitizeForLog(): API key redaction | R8 | ✅ Implemented |
| IP anonymization (last octet) | R2 | ✅ Implemented |
| PII-free error messages | R2 | ✅ Implemented |
| Output token cap on every LLM call | R7 | ✅ Implemented |
| Content-Length + post-read size check (1MB) | R7 | ✅ Implemented |
| Google systemInstruction separation | R1 | ✅ Implemented |
4.2 Organizational measures
| Measure | Risk mitigated | Status |
|---|---|---|
| Published Privacy Policy | R4, R5 | ✅ Implemented |
| Disclosure of LLM providers in the docs and on the subprocessors page | R4 | ✅ Implemented |
| DPAs with the LLM providers used with QR Branding's accounts (Groq, Google, OpenAI) | R4, R5 | ⚠️ Pending confirmation |
| DPAs with the LLM provider on the BYOK endpoint | R5 | Customer's responsibility |
| Documented DSR procedure | General | ✅ Documented |
| Incident response plan | General | ✅ Documented |
5. Conclusion
5.1 Residual risk
With all technical and organizational measures in place, the residual risk is assessed as LOW:
- The processing is stateless: neither the QR content nor the prompt text is persisted (the prompt cache keeps only generated designs under a hash-derived key).
- QR content (potentially sensitive) never leaves the Azure infrastructure.
- Only design prompts (which rarely contain PII) are transferred to third parties.
- All technical mitigations from the mega-audit are implemented and verified.
5.2 Decision
✅ The processing may proceed with the current measures.
Prior consultation with the supervisory authority (Art. 36 GDPR) is not required, since the residual risk is low.
5.3 Review
This DPIA will be reviewed:
- At least every 6 months.
- When new LLM providers are added.
- When the data flow of the AI endpoint changes.
- When new QR content types that may contain sensitive data are introduced.
Document generated on 2026-03-08. Next scheduled review: 2026-09-08.