Valutazione d'impatto sulla protezione dei dati (DPIA)
API di QR Branding — funzionalità IA
| Campo | Valore |
|---|---|
| Data | 2026-03-08 |
| Titolare del trattamento | QR Branding (Quartzon) |
| Versione | 1.0 |
| Stato | Approvata |
| Prossima revisione | 2026-09-08 |
1. Descrizione del trattamento
1.1 Natura del trattamento
QR Branding offre la generazione di codici QR con l'IA in due modalità:
- Con gli account propri di QR Branding presso i fornitori di LLM: il designer IA su qr-branding.com e l'endpoint gestito del marketplace (
POST /api/qr/ai/generate-managed). Una catena interna di fornitori di fallback (Groq, Google Gemini, OpenAI) serve ogni richiesta. - Con la chiave propria del cliente (BYOK): l'endpoint del marketplace
POST /api/qr/ai/generate. Il cliente fornisce la propria chiave API e sceglie il fornitore (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek o Qwen, oppure il proprio endpoint compatibile con OpenAI).
In entrambe le modalità l'utente invia un prompt di design in linguaggio naturale (ad es. "codice QR blu e moderno per un'azienda tecnologica") insieme al contenuto del QR (URL, testo, vCard, ecc.). Il sistema:
- Invia solo il prompt di design e i parametri di generazione a un fornitore esterno di LLM: quello che serve la richiesta nella catena di fallback di QR Branding, oppure quello scelto dall'utente (BYOK).
- Riceve dal LLM una configurazione di design in JSON.
- Genera il codice QR con il contenuto fornito e il design suggerito.
- Restituisce all'utente l'immagine del QR.
1.2 Ambito
- Dati trattati: prompt di design (testo libero), parametri di generazione (stile predefinito, creatività, scansionabilità rigorosa), contenuto del QR (URL, testo, dati di contatto vCard, credenziali WiFi, geolocalizzazione), chiave API del cliente (solo BYOK, transitoria).
- Volume stimato: fino a 15 richieste IA al minuto per IP, 100 generazioni al minuto a livello globale.
- Interessati coinvolti: utenti del sito qr-branding.com, utenti dell'API (sviluppatori, aziende) e, indirettamente, le persone i cui dati compaiono nel contenuto del QR (contatti vCard).
- Area geografica: globale (API pubblica su RapidAPI Marketplace).
1.3 Contesto
- Servizio stateless: non esiste alcun database e nessun contenuto dei QR viene reso persistente.
- Account propri di QR Branding (sito ed endpoint gestito): QR Branding dispone di chiavi API proprie presso Groq, Google (Gemini) e OpenAI, che agiscono come suoi responsabili del trattamento e sono elencati nella pagina dei sub-responsabili. A loro non viene inviato alcun indirizzo email, dato di fatturazione, indirizzo IP o identificativo del cliente.
- Modello BYOK (Bring Your Own Key) (
POST /api/qr/ai/generate): il cliente fornisce la propria chiave API a ogni richiesta; QR Branding non usa i propri account per queste richieste. - Il contenuto del QR non viene mai inviato ai fornitori di IA; viene inviato solo il prompt di design.
- I campi sensibili generati dal LLM (URL, base64) vengono annullati prima del rendering.
- Il servizio gira su Azure Functions (Consumption Plan).
- Sull'endpoint BYOK, il rapporto contrattuale con il fornitore di LLM è diretto tra il cliente e il fornitore.
1.4 Finalità
Consentire agli utenti di generare design di QR personalizzati a partire da descrizioni in linguaggio naturale, senza dover configurare i parametri a mano.
2. Necessità e proporzionalità
2.1 Base giuridica
Esecuzione di un contratto (art. 6, par. 1, lett. b), RGPD): il trattamento è necessario per fornire il servizio specifico richiesto dall'utente.
2.2 Minimizzazione dei dati
| Principio | Attuazione |
|---|---|
| Solo i dati necessari | Al LLM viene inviato solo il prompt, non il contenuto del QR |
| Nessuna conservazione | Trattamento in memoria; il testo del prompt e il contenuto del QR vengono eliminati dopo la risposta HTTP. Solo la configurazione di design generata può essere conservata in cache fino a 30 giorni, con una chiave derivata da un hash SHA-256 del prompt e dei parametri |
| Nessuna profilazione | Non vengono creati profili utente né cronologie delle richieste |
| Anonimizzazione | Indirizzi IP anonimizzati nei log (ultimo ottetto mascherato) |
| Separazione | Contenuto del QR e prompt IA tenuti separati nel flusso di dati |
2.3 Proporzionalità
Il trattamento è proporzionato perché:
- L'utente sceglie attivamente di usare la funzionalità IA (endpoint separato).
- Sull'endpoint BYOK l'utente seleziona il fornitore di LLM; sul sito e sull'endpoint gestito il fornitore è uno dei responsabili del trattamento elencati nella pagina dei sub-responsabili.
- Viene trasferito solo il prompt di design (non i dati personali contenuti nel QR).
- Non esiste un'alternativa meno invasiva per generare design a partire dal linguaggio naturale.
3. Identificazione e valutazione dei rischi
3.1 Rischi identificati
| # | Rischio | Probabilità | Impatto | Livello | Mitigazione |
|---|---|---|---|---|---|
| R1 | Prompt injection: l'utente inserisce istruzioni malevole nel prompt | Media | Medio | Medio | Delimitatori <user_request>, istruzioni anti-fuga nel prompt di sistema, campi URL/base64 annullati dopo il LLM |
| R2 | Dati personali nei prompt: l'utente include dati personali nella descrizione del design | Media | Basso | Basso | Non conserviamo il testo dei prompt (la cache conserva solo il design generato con una chiave derivata da un hash); il prompt viene inviato senza alcun identificativo dell'utente; policy d'uso documentata |
| R3 | Esfiltrazione del prompt di sistema: un attaccante estrae le istruzioni di sistema | Bassa | Basso | Basso | Chiusura anti-fuga nel prompt di sistema, output sanificato (tag HTML rimossi) |
| R4 | Trasferimento internazionale: prompt inoltrati a fornitori al di fuori del SEE | Media | Basso | Basso | Account di QR Branding: Groq, Google e OpenAI (USA) agiscono come responsabili del trattamento secondo le condizioni di trattamento dei dati di ciascun fornitore; vengono inviati solo il prompt di design e i parametri. BYOK: il cliente ha un rapporto diretto con il fornitore e un proprio DPA; QR Branding agisce solo come intermediario tecnico. Informazione nell'Informativa sulla privacy e nella pagina dei sub-responsabili |
| R5 | Conservazione da parte del fornitore di LLM: il fornitore conserva i dati secondo le proprie policy | Media | Basso | Basso | Account di QR Branding: regolata dalle condizioni di trattamento dei dati di ciascun fornitore con QR Branding. BYOK: responsabilità del cliente secondo i propri termini con il fornitore |
| R6 | Risposta del LLM con contenuto malevolo: XSS, URL malevoli | Media | Medio | Medio | Regex di sanificazione HTML con timeout, campi URL/base64 annullati, MaxDepth=32 nella deserializzazione |
| R7 | Denial of wallet: abuso dell'endpoint IA per far lievitare i costi | Media | Alto | Alto | Limitazione delle richieste (15 IA/min per IP, 100/min a livello globale), RenderThrottle con semaforo, functionTimeout 1:30 |
| R8 | Fuga di chiavi API nei log | Bassa | Alto | Medio | SanitizeForLog() oscura i pattern delle chiavi API, messaggi di errore privi di dati personali |
3.2 Mappa del flusso di dati
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. Misure di mitigazione
4.1 Misure tecniche adottate
| Misura | Rischio mitigato | Stato |
|---|---|---|
Delimitatori del prompt (<user_request>) | R1 | ✅ Implementata |
| Chiusura anti-fuga nel prompt di sistema | R1, R3 | ✅ Implementata |
| Annullamento dei campi URL/base64 del LLM | R1, R6 | ✅ Implementata |
| Regex di sanificazione HTML con timeout (3s) | R6 | ✅ Implementata |
| MaxDepth=32 in JsonSerializer | R6 | ✅ Implementata |
| Limitazione delle richieste IA (15/min per IP, 100/min a livello globale) | R7 | ✅ Implementata |
| RenderThrottle (semaforo, 4 simultanei) | R7 | ✅ Implementata |
| functionTimeout 1:30 | R7 | ✅ Implementata |
| SanitizeForLog(): oscuramento delle chiavi API | R8 | ✅ Implementata |
| Anonimizzazione degli IP (ultimo ottetto) | R2 | ✅ Implementata |
| Messaggi di errore privi di dati personali | R2 | ✅ Implementata |
| Limite di token in uscita in ogni chiamata al LLM | R7 | ✅ Implementata |
| Content-Length + controllo della dimensione dopo la lettura (1MB) | R7 | ✅ Implementata |
| Separazione di systemInstruction per Google | R1 | ✅ Implementata |
4.2 Misure organizzative
| Misura | Rischio mitigato | Stato |
|---|---|---|
| Informativa sulla privacy pubblicata | R4, R5 | ✅ Implementata |
| Indicazione dei fornitori di LLM nella documentazione e nella pagina dei sub-responsabili | R4 | ✅ Implementata |
| DPA con i fornitori di LLM usati con gli account di QR Branding (Groq, Google, OpenAI) | R4, R5 | ⚠️ In attesa di conferma |
| DPA con il fornitore di LLM sull'endpoint BYOK | R5 | Responsabilità del cliente |
| Procedura documentata per le richieste degli interessati | Generale | ✅ Documentata |
| Piano di risposta agli incidenti | Generale | ✅ Documentato |
5. Conclusione
5.1 Rischio residuo
Con tutte le misure tecniche e organizzative adottate, il rischio residuo è valutato come BASSO:
- Il trattamento è stateless: né il contenuto del QR né il testo del prompt vengono resi persistenti (la cache dei prompt conserva solo i design generati con una chiave derivata da un hash).
- Il contenuto del QR (potenzialmente sensibile) non lascia mai l'infrastruttura Azure.
- A terzi vengono trasferiti solo i prompt di design (che raramente contengono dati personali).
- Tutte le mitigazioni tecniche individuate nella mega-audit sono implementate e verificate.
5.2 Decisione
✅ Il trattamento può proseguire con le misure attuali.
Non è necessaria la consultazione preventiva dell'autorità di controllo (art. 36 RGPD), poiché il rischio residuo è basso.
5.3 Revisione
Questa DPIA sarà rivista:
- Almeno ogni 6 mesi.
- Quando si aggiungono nuovi fornitori di LLM.
- Quando cambia il flusso di dati dell'endpoint IA.
- Quando si introducono nuovi tipi di contenuto del QR che possono contenere dati sensibili.
Documento generato il 2026-03-08. Prossima revisione programmata: 2026-09-08.