Analisi della base giuridica del trattamento dei dati
API di QR Branding — art. 6 RGPD
| Campo | Valore |
|---|---|
| Titolare del trattamento | QR Branding (Quartzon) |
| Data | 2026-03-08 |
| Versione | 1.0 |
1. Principio di liceità (art. 6)
Ogni trattamento di dati personali deve fondarsi su almeno una delle basi giuridiche previste dall'art. 6, paragrafo 1, RGPD. Di seguito si analizzano le attività di trattamento di QR Branding e la base giuridica corrispondente a ciascuna.
2. Analisi per attività di trattamento
2.1 Generazione di codici QR contenenti dati personali
| Aspetto | Analisi |
|---|---|
| Attività | L'utente invia un contenuto per il QR che può includere dati personali (vCard con nome, email, telefono e indirizzo; geolocalizzazione; indirizzi email) |
| Base giuridica | Art. 6, par. 1, lett. b) — Esecuzione di un contratto |
| Giustificazione | Il trattamento è necessario per eseguire il servizio che l'utente ha sottoscritto tramite RapidAPI. Senza trattare il contenuto, non è possibile generare il codice QR richiesto |
| Proporzionalità | Minima: si tratta solo il contenuto strettamente necessario, in memoria, senza conservazione |
| Alternativa meno invasiva | Nessuna: il contenuto del QR È il dato da codificare |
2.2 Codici QR generati con l'IA
La generazione con l'IA funziona in due modalità:
- Account propri di QR Branding (il designer IA su qr-branding.com e l'endpoint gestito
POST /api/qr/ai/generate-managed): QR Branding invia il prompt di design, con le proprie chiavi API, a un fornitore di LLM della sua catena interna di fallback (Groq, Google Gemini, OpenAI). Questi fornitori agiscono come responsabili del trattamento di QR Branding e sono elencati nella pagina dei sub-responsabili. - BYOK (Bring Your Own Key) (l'endpoint
POST /api/qr/ai/generate): il cliente fornisce la propria chiave API e sceglie il fornitore; QR Branding non usa i propri account per queste richieste.
| Aspetto | Analisi |
|---|---|
| Attività | L'utente invia un prompt di design. QR Branding inoltra il prompt a un fornitore di LLM: con le proprie chiavi (sito ed endpoint gestito) o con la chiave del cliente (llmApiKey, endpoint BYOK) |
| Modello | Account propri di QR Branding presso Groq, Google (Gemini) e OpenAI, oppure BYOK (Bring Your Own Key) con il fornitore scelto dal cliente |
| Base giuridica | Art. 6, par. 1, lett. b) — Esecuzione di un contratto |
| Giustificazione | L'utente richiede esplicitamente un design generato con l'IA: sul sito e sull'endpoint gestito, avviando una generazione con l'IA; sull'endpoint BYOK, anche selezionando il fornitore e fornendo la propria chiave API. Il trattamento è necessario per eseguire quella specifica richiesta |
| Proporzionalità | Al LLM vengono inviati solo il prompt di design e i parametri di generazione. Il contenuto del QR, gli indirizzi IP e i dati identificativi non vengono MAI trasmessi. Sull'endpoint BYOK, la chiave API del cliente non viene né conservata né registrata nei log |
| Nota | L'utente sceglie attivamente di usare la generazione con l'IA e il prompt da inviare. Sull'endpoint BYOK sceglie anche il fornitore di LLM e fornisce la propria chiave API, e il rapporto con il fornitore di LLM è diretto tra il cliente e il fornitore |
2.3 Limitazione delle richieste
| Aspetto | Analisi |
|---|---|
| Attività | Conteggio delle richieste per identificatore (utente RapidAPI, ID dell'abbonamento, IP anonimizzato) per limitare la frequenza di utilizzo |
| Base giuridica | Art. 6, par. 1, lett. f) — Legittimo interesse |
| Legittimo interesse | Tutelare la disponibilità del servizio per tutti gli utenti e prevenire abusi e costi eccessivi |
| Test di bilanciamento | |
| — Interesse del titolare | Elevato: senza limiti di richieste, un solo utente potrebbe esaurire le risorse o generare costi proibitivi |
| — Impatto sull'interessato | Minimo: si usa solo un identificatore pseudonimo per contare le richieste, i dati restano in memoria volatile (2 min) e gli indirizzi IP sono anonimizzati |
| — Aspettativa ragionevole | Sì: chi usa un'API si aspetta limiti di richieste, prassi standard del settore |
| — Garanzie | Dati effimeri (2 min), anonimizzazione degli IP, limite di tracciamento (50K IP), nessuna registrazione degli identificatori nei log |
| Esito | Il legittimo interesse prevale chiaramente, dato l'impatto minimo sull'interessato |
2.4 Telemetria e diagnostica (Application Insights)
| Aspetto | Analisi |
|---|---|
| Attività | Raccolta di metriche di prestazione, errori e metadati delle richieste (senza dati personali identificativi) |
| Base giuridica | Art. 6, par. 1, lett. f) — Legittimo interesse |
| Legittimo interesse | Mantenere il servizio affidabile e disponibile e diagnosticare rapidamente i problemi |
| Test di bilanciamento | |
| — Interesse del titolare | Elevato: senza telemetria non è possibile rilevare né risolvere gli incidenti |
| — Impatto sull'interessato | Minimo: dati personali rimossi dai messaggi di errore, chiavi API oscurate, indirizzi IP anonimizzati |
| — Aspettativa ragionevole | Sì: il monitoraggio è una prassi standard dei servizi cloud |
| — Garanzie | Conservazione di 90 giorni, log privi di dati personali, anonimizzazione degli IP, oscuramento delle chiavi API |
| Esito | Il legittimo interesse prevale chiaramente |
2.5 Autenticazione RapidAPI
| Aspetto | Analisi |
|---|---|
| Attività | Verifica dell'intestazione X-RapidAPI-Proxy-Secret a ogni richiesta |
| Base giuridica | Art. 6, par. 1, lett. f) — Legittimo interesse |
| Giustificazione | Proteggere il servizio dagli accessi non autorizzati |
| Nota | Il segreto è un dato del server, non un dato dell'utente. In questa fase non viene trattato alcun dato personale |
3. Basi giuridiche NON utilizzate
| Base giuridica | Art. | Perché non si usa? |
|---|---|---|
| Consenso | Art. 6, par. 1, lett. a) | Non si raccoglie alcun consenso esplicito. Non è necessario: il trattamento si fonda sul contratto e sul legittimo interesse. Basarsi sul consenso creerebbe obblighi aggiuntivi (revocabilità) senza alcun beneficio |
| Obbligo legale | Art. 6, par. 1, lett. c) | Nessun obbligo legale impone il trattamento di questi dati |
| Interessi vitali | Art. 6, par. 1, lett. d) | Non applicabile: il servizio non tratta dati per tutelare interessi vitali |
| Interesse pubblico | Art. 6, par. 1, lett. e) | Non applicabile: si tratta di un servizio commerciale privato |
4. Categorie particolari di dati (art. 9)
QR Branding non richiede né necessita di categorie particolari di dati personali (origine etnica, salute, orientamento sessuale, ecc.).
Tuttavia, l'utente potrebbe includere tali dati nel contenuto del QR (ad es. un codice QR contenente dati medici). In tal caso:
- QR Branding agisce come responsabile tecnico del trattamento che codifica i dati senza interpretarli.
- La responsabilità del trattamento delle categorie particolari ricade sull'utente che decide di includerle.
- In questo scenario la base giuridica sarebbe il consenso esplicito dell'interessato, che l'utente deve ottenere prima di codificare i dati.
- QR Branding non conserva questi dati e li elimina subito dopo la generazione.
5. Dati dei minori (art. 8)
- QR Branding è un servizio API B2B/B2C rivolto a sviluppatori e aziende.
- Non è destinato a minori di 16 anni.
- Non si raccolgono dati sull'età né si effettua alcuna verifica dell'età.
- Se un utente include dati di minori nel contenuto del QR, la responsabilità di ottenere il consenso dei genitori ricade sull'utente.
6. Trasferimenti internazionali (artt. 44-49)
| Destinazione | Base giuridica del trasferimento | Fornitore |
|---|---|---|
| UE/USA (Azure) | Online Services Terms + CCS | Microsoft Azure |
| USA | Termini della piattaforma | RapidAPI |
| USA | Condizioni di trattamento dei dati di ciascun fornitore (vedi la pagina dei sub-responsabili) | Groq, Google (Gemini), OpenAI: generazione con l'IA con gli account di QR Branding |
Nota sui fornitori di LLM: con gli account propri di QR Branding (il sito e l'endpoint gestito), i prompt di design vengono trasferiti a Groq, Google (Gemini) o OpenAI, che agiscono come responsabili del trattamento di QR Branding. Sull'endpoint BYOK, i prompt vengono trasferiti al fornitore scelto dal cliente (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek o Qwen, oppure il proprio endpoint compatibile con OpenAI) usando la chiave API del cliente. La responsabilità di tale trasferimento ricade sul cliente, che ha un rapporto contrattuale diretto con il fornitore; QR Branding agisce come intermediario tecnico.
L'uso dell'endpoint standard di generazione dei QR non comporta alcun trasferimento ai fornitori di LLM (il trattamento avviene esclusivamente su Azure).
7. Revisione
Questa analisi della base giuridica va rivista:
- Quando si aggiungono nuove attività di trattamento
- Quando cambiano i dati trattati dalle attività esistenti
- Quando cambiano le policy dei fornitori di LLM
- Almeno una volta l'anno
Documento generato il 2026-03-08.