Chatbot cloud, API con retention controllata e IA locale

Protezione dei dati, tracciamento delle chiamate e architetture sicure per scuole, PA e imprese

Versione corretta e ampliata

A cura di Francesco Silvaggio e del Team di Orizzonte Insegnanti

Aggiornato al 27 luglio 2026

Un dossier sulle architetture e sul percorso dei dati, non una campagna contro l’IA.

Il problema non è che ogni servizio cloud utilizzi automaticamente ogni prompt per addestrare il modello. Il problema è che, quando un dipendente usa una chat pubblica, l’organizzazione perde il controllo tecnico e contrattuale sul trattamento: quali dati sono inviati, quali log sono generati, per quanto tempo rimangono, chi può esaminarli, quali funzioni stateful o connettori li copiano altrove e quali trasferimenti internazionali si producono.

Il dossier distingue quattro modelli: chatbot consumer; SaaS enterprise; API attraverso un gateway organizzativo; IA locale o on-premise. La distinzione è decisiva, perché “cloud”, “business”, “API”, “no-training” e “zero data retention” non sono sinonimi.

La ricerca usa fonti primarie: GDPR ed EUR-Lex, Garante per la protezione dei dati personali, EDPS, EDPB, NIST, NCSC, OWASP e documentazione ufficiale dei fornitori. Le fonti sono state ricontrollate il 27 luglio 2026 e le variazioni rilevanti sono già integrate nel corpo del dossier; il registro finale rende tracciabili gli aggiornamenti. Sono escluse percentuali promozionali prive di una fonte primaria riproducibile.

Fonti chiave: [R1] GDPR; [R2] EDPS; [R4] NIST AI 600-1; [R5] NCSC; [R8-R9] Garante privacy e scuola; [P3] OpenAI API Data Controls; [P7-P8, P12] Anthropic retention/ZDR; [P9-P11, P13] Microsoft, Google Cloud e AWS.

Mappa del dossier

Sette conclusioni operative supportate dalle fonti.

1. La chat consumer è un canale esterno di trattamento. Prompt, file, immagini, audio, video, dati dei servizi collegati e metadati sono trattati secondo condizioni consumer. L’organizzazione non dispone di un perimetro tecnico centralizzato né di garanzie equivalenti a un DPA enterprise. [P1-P5]

2. Revisione umana e retention non sono ipotesi astratte. Google invita a non inserire informazioni confidenziali che non si vorrebbero mostrare a un revisore e indica periodi fino a tre anni per conversazioni già revisionate. OpenAI e Anthropic prevedono retention ed eccezioni di sicurezza o legali. [P1, P4-P5]

3. No-training non equivale a zero retention. Un provider può non addestrare i modelli sui dati del cliente e, nello stesso tempo, conservare contenuti per abuse monitoring, file, funzioni stateful, feedback, supporto, obblighi legali o regole specifiche del modello. [P3, P6-P10, P12-P13]

4. L’API è preferibile solo se è controllata. L’API permette di imporre identità, finalità, DLP, pseudonimizzazione, allowlist di endpoint, retention verificata e audit senza contenuto. Senza questi controlli una webapp può replicare i rischi della chat pubblica registrando prompt e risposte nei propri log. [R4, R6, P3, P7-P10]

5. L’IA locale offre la maggiore sovranità del dato. Se il runtime non ha egress, la telemetria è disattivata e prompt, embeddings e documenti RAG restano nell’infrastruttura dell’ente, il contenuto non viene trasmesso a un provider di modello. Rimangono rischi interni, di supply chain, accesso, patching e backup. [R4, R5, R7]

6. GDPR e AI Act impongono progettazione, prova e obblighi distinti ma concorrenti. Minimizzazione, privacy by design/default, sicurezza, contratto con il responsabile, DPIA, trasparenza e controllo dei trasferimenti devono essere documentati. La configurazione effettiva va verificata, non solo promessa. [R1-R3, R8-R11]

7. Per scuola e PA la cautela deve essere più alta. Dati di minori, salute, disabilità, BES/DSA, PEI/PDP, valutazioni, procedimenti e dati dei dipendenti possono essere particolarmente delicati. In questo dossier si raccomanda, come regola organizzativa prudenziale e non come divieto normativo generalizzato, di vietare la chat consumer con dati non pubblici; l’API richiede un percorso formalizzato e il locale è preferibile per le classi più sensibili.

Figura 1 - I quattro modelli devono essere valutati separatamente.

Per giudicare il rischio bisogna identificare chi tratta il dato, con quale contratto e con quali funzioni.

1.1 Chatbot consumer in cloud

È il servizio utilizzato direttamente da un individuo tramite sito o app pubblica. Account, impostazioni, cronologia e connettori sono governati dalla policy consumer. L’organizzazione può vietarne l’uso, ma spesso non può verificare centralmente quali prompt siano inviati né garantire che ogni dipendente abbia configurato correttamente opt-out, chat temporanee e cancellazioni.

• Il contenuto può comprendere prompt, allegati, immagini, audio, video, codice, URL e dati provenienti da servizi collegati.

• Possono essere raccolti log di utilizzo, dati del dispositivo, indirizzi IP, identificatori e informazioni di posizione o feedback.

• Training, revisione umana e retention dipendono dalla policy e dalle impostazioni del singolo servizio.

• La cancellazione dall’interfaccia non implica necessariamente eliminazione immediata da ogni sistema o da contenuti già dissociati.

1.2 SaaS enterprise

È una chat gestita in un tenant aziendale o scolastico, con amministrazione centralizzata, identità organizzative e condizioni commerciali. Di norma offre no-training, DPA, audit, gestione degli utenti e controlli di retention. Rimane però un servizio cloud: il contenuto è processato dal fornitore e può essere conservato da funzioni stateful, sistemi di sicurezza, connettori o impostazioni dell’amministratore.

1.3 API attraverso un gateway organizzativo

L’utente non accede al fornitore. Usa una webapp dell’ente che applica controlli prima e dopo la chiamata: autenticazione, autorizzazione, filtro DLP, pseudonimizzazione, limite di finalità, selezione dell’endpoint, disattivazione dello storage, filtro dell’output e audit tecnico. L’invio al provider non scompare, ma diventa un trattamento controllato dall’amministrazione.

Questo è il modello raccomandato per la maggior parte dei casi organizzativi, ma solo quando le garanzie di retention sono provate per lo specifico endpoint. “OpenAI API”, “Anthropic API” o “Gemini API” non sono una singola configurazione: conversazioni, file, thread, vector store, grounding e cache possono avere retention diversa.

1.4 IA locale, on-premise o privata

Il modello viene eseguito su server, workstation o infrastruttura privata controllata dall’organizzazione. Prompt, output, embeddings e documenti RAG possono restare nel perimetro locale. Il vantaggio è architetturale: non è necessario trasmettere il contenuto a un provider esterno per ottenere l’inferenza. Perché questa proprietà sia reale, occorre disattivare telemetria e crash reporting, impedire l’egress del processo, verificare il codice e i pesi, evitare log di prompt e risposta, proteggere il vector database, cifrare dischi e backup e applicare RBAC e patching.

Il rischio non si esaurisce nell’addestramento del modello.

2.1 Il prompt è una comunicazione di dati a un sistema esterno

Quando nel prompt compaiono nome, diagnosi, valutazione, codice sorgente, contratto, credenziale o documento interno, il trattamento non riguarda soltanto la frase digitata. Include il contenuto, il contesto della conversazione, gli allegati, gli identificatori di account, i metadati tecnici e, in presenza di strumenti, i dati recuperati da altre fonti.

NIST definisce il rischio di data privacy della generative AI in termini di leakage, uso o divulgazione non autorizzata e de-anonimizzazione di dati personali o sensibili. OWASP include tra le informazioni esposte PII, dati finanziari e sanitari, credenziali, documenti legali e dati aziendali confidenziali. [R4, R6]

2.2 Otto vettori da considerare separatamente

2.3 Metadati: “non salvo il testo” non significa “non traccio la chiamata”

Anche eliminando prompt e risposta, un sistema può registrare utente, timestamp, IP, organizzazione, modello, token, latenza, classificazioni di sicurezza, endpoint, file ID, errori e identificatori di richiesta. Questi metadati possono essere necessari per sicurezza e fatturazione, ma devono essere distinti dal contenuto e sottoposti a una retention definita.

2.4 Perché i filtri testuali non bastano

Una regola nel system prompt del tipo “non rivelare dati riservati” è utile ma non è una barriera di sicurezza. OWASP osserva che le restrizioni del prompt possono essere aggirate e raccomanda sanitizzazione, validazione, least privilege, separazione dei contenuti non attendibili e approvazione umana per operazioni ad alto rischio. [R7]

Training, retention, revisione e funzioni stateful: cosa dichiarano i fornitori.

3.1 La prova più chiara: i provider distinguono consumer e business/API

OpenAI precisa che la privacy policy consumer non si applica ai contenuti trattati per i clienti business/API e che, per i prodotti business, input e output non sono usati per training per default. Anthropic separa i servizi consumer da quelli commerciali e nei termini commerciali dichiara che non può addestrare modelli sul Customer Content. Questa separazione conferma che l’architettura e il contratto contano almeno quanto il nome del modello. [P1-P3, P5-P6]

3.2 API: eccezioni che devono entrare nel capitolato

La documentazione OpenAI mostra che Chat Completions e Responses non sono usate per training, ma in configurazione standard generano abuse monitoring fino a 30 giorni. /v1/responses conserva application state per 30 giorni per default o con store=true; Conversations, ChatKit, Assistants, Threads, vector store e file seguono cicli distinti e non sono tutti eleggibili per ZDR. Prompt caching può conservare tensori cifrati su GPU fino a 24 ore; tool/MCP terzi seguono le proprie policy; Safety Retention può introdurre eccezioni comunicate al cliente. Non basta quindi scegliere “OpenAI API”: occorre specificare endpoint, parametri, modello, funzioni vietate e prova della configurazione ZDR/MAM. [P3]

Anthropic dichiara cancellazione standard entro 30 giorni per l’API, con eccezioni per Files API, enforcement, accordi e legge. Lo ZDR è soggetto ad approvazione e copre solo organizzazioni e prodotti eleggibili; restano alcuni risultati dei classificatori di sicurezza. Dal 9 giugno 2026, inoltre, i “Covered Models” designati richiedono 30 giorni di retention di prompt e output anche quando l’accesso avviene in contesti ZDR, compresi i cloud partner. [P7-P8, P12]

Microsoft, Google Cloud e AWS confermano lo stesso principio generale: il core inference può essere no-training, ma abuse monitoring, feature stateful, grounding, cache, request-response logging e regole del singolo modello richiedono controlli distinti. In Bedrock, store=false non garantisce ZDR: occorre verificare la modalità effettiva e gli allowed_modes del modello. [P9-P11, P13]

3.3 “No-training” è necessario ma non sufficiente

Il titolare deve dimostrare perché il trattamento è necessario, proporzionato e sicuro.

4.1 Principi applicabili

[R1] Regolamento (UE) 2016/679, testo ufficiale EUR-Lex.

4.2 DPIA, DPO e riferimenti per la scuola

Le Guidance EDPS sulla generative AI sono rivolte direttamente alle istituzioni e agli organi dell’Unione soggetti al regolamento (UE) 2018/1725; in questo dossier sono usate come autorevole riferimento interpretativo, non come fonte direttamente vincolante per le scuole italiane. Per queste ultime il quadro applicabile resta fondato su GDPR, normativa nazionale e provvedimenti del Garante. [R2]

Nel parere del 4 agosto 2025 sulle Linee guida MIM, il Garante richiede di usare dati personali di studenti e docenti solo quando strettamente indispensabili, preferire ove possibile dati sintetici, impedire conservazione dei prompt, profilazione e tracciamento, formare il personale, svolgere audit periodici e valutare l’impatto. La richiesta di informazioni del 3 giugno 2026 a due istituti non accerta una violazione, ma conferma l’attenzione dell’Autorità su provider, flussi di dati e DPIA. [R8-R9]

GDPR e AI Act operano in parallelo. Il Regolamento (UE) 2024/1689 è applicabile in via generale dal 2 agosto 2026 e le regole di trasparenza decorrono da agosto 2026; dopo l’AI Omnibus, le regole per i sistemi ad alto rischio in settori tra cui l’istruzione si applicano dal 2 dicembre 2027 e quelle per i sistemi incorporati in prodotti regolamentati dal 2 agosto 2028. Questa scansione non sospende gli obblighi GDPR già applicabili. [R10-R11]

La DPIA non è un modulo da compilare dopo il rilascio. Deve descrivere flussi di dati, categorie e interessati, necessità e proporzionalità, provider e subprocessori, retention, controlli tecnici, rischio residuo, test e gestione degli incidenti. Per un chatbot scolastico con dati di minori o documenti individuali, la soglia di cautela è elevata.

4.3 Ruoli e accountability

API-first per l’uso ordinario; local-first per i dati più sensibili.

5.1 Gateway API con retention controllata

Figura 2 - Il provider è un componente dietro controlli organizzativi.

Il gateway deve essere il solo componente autorizzato a conoscere le chiavi del provider. Gli utenti non ricevono API key e non possono selezionare liberamente endpoint o connettori. Il flusso consigliato è:

1. Autenticazione SSO/MFA e autorizzazione per ruolo, struttura e finalità.

2. Classificazione del caso d’uso e del dato; blocco immediato delle categorie vietate.

3. DLP, secret scanning, rimozione di identificativi e pseudonimizzazione prima della chiamata.

4. Selezione da allowlist di provider, modello, regione, endpoint e parametri compatibili con la retention approvata.

5. Chiamata stateless con storage disabilitato; ZDR/no content logging verificati dove richiesti.

6. Filtro dell’output per PII, segreti, contenuto non autorizzato e prompt leakage.

7. Re-identificazione soltanto nell’applicazione interna e solo per gli utenti autorizzati.

8. Audit metadata-only con retention breve; nessun prompt o output nei log ordinari.

5.2 Requisiti tecnici del gateway

5.3 IA locale / on-premise

Figura 3 - Il contenuto resta nel perimetro, ma il perimetro deve essere realmente chiuso e gestito.

L’IA locale è la soluzione preferibile quando il danno derivante dalla divulgazione è elevato o quando il trattamento riguarda categorie particolari, minori, segreti o dossier individuali. L’obiettivo non è costruire un “chatbot senza regole”, ma mantenere inferenza, RAG e storage sotto il controllo dell’organizzazione.

• Egress negato al runtime; gli aggiornamenti passano da un canale separato, autenticato e approvato.

• Telemetria, crash dump, analytics e invio automatico di prompt disattivati e verificati con network monitoring.

• Pesi e container acquisiti da fonti autorizzate, con hash/firme, SBOM e vulnerability scanning.

• Model server senza request/response logging; system log separati e sanitizzati.

• Vector database cifrato, con ACL per collezione e retrieval limitato al ruolo dell’utente.

• Documenti RAG classificati, versionati e sottoposti a retention; nessun accesso indiscriminato a file share.

• Backup cifrati e separati, con ciclo di cancellazione coerente con l’applicazione.

• Human-in-the-loop per decisioni o documenti con effetti sulle persone.

5.4 Quando una API è preferibile al locale

Il locale non è sempre la scelta migliore. Una API cloud ben contrattualizzata può offrire modelli più capaci, patch rapide, compliance certificata e minore onere operativo. È preferibile quando i dati possono essere minimizzati o pseudonimizzati, il provider offre retention adeguata, la regione è accettabile e il rischio residuo è più basso rispetto a un’infrastruttura locale non gestita.

La scelta corretta confronta il rischio del trasferimento a terzi con il rischio operativo interno. L’organizzazione deve dimostrare perché l’architettura selezionata è adeguata allo specifico caso d’uso.

La matrice C0-C3 è un modello interno di classificazione del rischio, non una tassonomia prevista dal GDPR o dall’AI Act e non sostituisce base giuridica, DPIA o valutazione del caso concreto. La soluzione dipende dalla sensibilità e dalla finalità del trattamento, non dalla comodità dell’utente.

6.1 Scuola

Nel contesto scolastico, la combinazione di minori, dati sanitari, disabilità, BES/DSA, valutazioni e relazioni familiari rende particolarmente pericolosa la copia di documenti in una chat pubblica. Devono essere considerati C3 almeno:

• PEI, PDP, diagnosi, certificazioni, verbali GLO, relazioni di sostegno e documenti dei servizi sociali;

• nomi associati a voti, note disciplinari, assenze, comportamenti, fragilità o bisogni educativi;

• registrazioni audio/video, fotografie, elaborati identificabili e comunicazioni scuola-famiglia;

• dati del personale, procedimenti, malattia, permessi, contenzioso e documentazione sindacale;

• credenziali, token, esportazioni dal registro elettronico e archivi amministrativi.

6.2 Pubblica amministrazione

La PA deve evitare che istanze, protocolli, dati tributari, anagrafici, sanitari, giudiziari o di vulnerabilità finiscano in servizi consumer. Anche la semplice richiesta può rivelare informazioni: il ruolo dell’utente, la data e il contesto di una domanda possono avere valore sensibile. L’uso ammesso deve passare da strumenti istituzionali, con DPA, registro dei trattamenti, controllo dei fornitori e audit.

6.3 Impresa e professioni

Sono ad alto rischio codice sorgente, roadmap, contratti, listini non pubblici, credenziali, dati clienti, M&A, brevetti, strategie, documenti legali e HR. L’API controllata permette di automatizzare classificazione, riepilogo, traduzione e drafting senza consegnare agli utenti le chiavi e senza registrare il contenuto nei log; i segreti più critici restano su un modello locale o in un private cloud isolato.

Le garanzie devono diventare requisiti contrattuali e test tecnici.

7.1 Checklist per il fornitore

• DPA conforme all’art. 28 e chiara qualificazione dei ruoli.

• Divieto di training o miglioramento su input, output, allegati, embeddings e feedback, salvo opt-in scritto.

• Retention per endpoint e funzione, con elenco delle eccezioni; ZDR/no content logging dove richiesto.

• Procedura e prova tecnica per verificare la configurazione effettiva.

• Elenco subprocessori, localizzazione, trasferimenti e meccanismi ex artt. 44-49 GDPR.

• Cancellazione di file, thread, vector store, cache, backup e dati alla cessazione.

• Regole di human review, accessi privilegiati e registrazione degli accessi al contenuto.

• Notifica degli incidenti, tempi, collaborazione forense e disponibilità dei log di sicurezza.

• Cifratura in transito e a riposo, gestione chiavi, private connectivity e segregazione dei tenant.

• Portabilità, export, exit plan e distruzione dei dati alla fine del contratto.

• Clausole su preview/beta: vietate per dati reali salvo nuova valutazione.

• Diritto di audit, attestazioni indipendenti e documentazione tecnica aggiornata.

7.2 Clausole tecniche da non confondere

7.3 Policy interna: dieci regole non negoziabili

1. È vietato inserire dati C2/C3 in chatbot consumer o account personali.

2. Si usano esclusivamente strumenti approvati e accessibili con identità organizzativa.

3. Ogni caso d’uso ha un owner, una finalità documentata e una classe di dati ammessa.

4. I dati vengono minimizzati e pseudonimizzati prima dell’invio.

5. API key e credenziali restano nel backend; mai nel browser, nel client o nel prompt.

6. Prompt e output non vengono salvati nei log, nei ticket o nei sistemi APM.

7. File, thread e vector store hanno TTL e cancellazione automatica verificata.

8. Connettori, web search e tool sono disattivati per default e autorizzati singolarmente.

9. Gli output sono sempre revisionati da una persona per atti, valutazioni o decisioni.

10. Ogni incidente o invio errato viene segnalato immediatamente a IT/DPO/CISO.

Dalla ricerca a una governance verificabile.

8.1 Test di accettazione prima del go-live

• Inviare un identificatore fittizio e verificare che venga redatto prima della API call.

• Generare un errore e controllare che prompt e risposta non compaiano in proxy, APM, Sentry, Celery, database o console.

• Creare e cancellare un file/vector store, verificando API, dashboard e job di retention.

• Verificare la configurazione ZDR/no content logging con prova esportabile o screenshot amministrativo.

• Tentare di usare un endpoint o connettore non allowlisted: la richiesta deve essere bloccata.

• Inserire una prompt injection in un documento RAG e verificare che non possa estrarre altri documenti o invocare tool.

• Sul locale, osservare il traffico di rete durante inferenza e crash: nessun egress non autorizzato.

• Verificare RBAC: un utente non deve recuperare embeddings o documenti di un’altra collezione.

• Testare kill switch, revoca chiavi, cancellazione e procedura di incidente.

8.2 Indicatori utili

Controllare il flusso dei dati prima di scegliere il modello.

Le fonti ufficiali dei provider confermano che le modalità consumer possono comprendere training, retention, revisione umana, dati dei servizi collegati e trasferimenti. Le stesse fonti confermano anche che le offerte business e API possono prevedere no-training, retention limitata, ZDR, regioni e controlli amministrativi. La conclusione corretta non è “il cloud è sempre illecito”, ma “la chat pubblica è inadeguata ai dati non pubblici e il cloud deve essere reso controllabile attraverso contratto, configurazione e architettura”.

L’API è il punto di equilibrio per molti casi: consente di ridurre il dato prima dell’invio, imporre endpoint e provider approvati, disattivare lo storage, evitare log di contenuto e mantenere un audit minimo. Tuttavia, la zero retention deve essere provata per ogni funzione, e l’applicazione cliente deve essere progettata per non ricreare la traccia che si voleva evitare.

L’IA locale è preferibile per i dati più sensibili perché può eliminare la trasmissione a un terzo. Questa proprietà esiste soltanto se il runtime è realmente isolato, la telemetria è spenta, il RAG è segregato, i log non contengono dati e l’organizzazione è in grado di mantenere la piattaforma.

Regola finale per modello

Requisiti implementativi traducibili in backlog e criteri di collaudo.

Esempio di record di audit ammesso

request_id=7f… user_role=docente use_case=bozza_didattica data_class=C1 provider=azure model=approved-model-v3 input_tokens=542 output_tokens=388 policy=ALLOW_REDACTED pii_redactions=2 stateful=false content_logged=false ttl_days=30

Non devono essere inclusi prompt, risposta, allegati, nomi, email, token di autenticazione o stack trace contenenti il body della richiesta.

Fonti ricontrollate il 27 luglio 2026. Verificare nuovamente policy, contratto e configurazione prima della pubblicazione, dell’acquisto o del go-live.

[R1] Unione europea - Regolamento (UE) 2016/679 (GDPR), EUR-Lex. [Apri la fonte](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

[R2] European Data Protection Supervisor - Guidance on generative AI and data protection for EU institutions, revised 28 ottobre 2025. [Apri la fonte](https://www.edps.europa.eu/data-protection/our-work/publications/guidelines/2025-10-28-guidance-generative-ai-strengthening-data-protection-rapidly-changing-digital-era_en)

[R3] European Data Protection Board - Opinion 28/2024 on certain data protection aspects related to AI models, 18 dicembre 2024. [Apri la fonte](https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en)

[R4] NIST - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 2024. [Apri la fonte](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)

[R5] UK National Cyber Security Centre - ChatGPT and LLMs: what’s the risk. [Apri la fonte](https://www.ncsc.gov.uk/blog-post/chatgpt-and-large-language-models-whats-the-risk)

[R6] OWASP GenAI Security Project - LLM02:2025 Sensitive Information Disclosure. [Apri la fonte](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/)

[R7] OWASP GenAI Security Project - LLM01:2025 Prompt Injection. [Apri la fonte](https://genai.owasp.org/llmrisk/llm01-prompt-injection/)

[R8] Garante per la protezione dei dati personali - Parere sulle Linee guida MIM per l’IA nelle istituzioni scolastiche, 4 agosto 2025. [Apri la fonte](https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10162698)

[R9] Garante per la protezione dei dati personali - IA a scuola: richiesta di informazioni a due istituti, 3 giugno 2026. [Apri la fonte](https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10257612)

[R10] Unione europea - Regolamento (UE) 2024/1689 (AI Act), EUR-Lex. [Apri la fonte](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=it)

[R11] Commissione europea - AI Act: quadro e calendario di applicazione aggiornato dopo l’AI Omnibus. [Apri la fonte](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)

[P1] OpenAI - Europe Privacy Policy, aggiornata 4 giugno 2026. [Apri la fonte](https://openai.com/en-GB/policies/eu-privacy-policy/)

[P2] OpenAI Help Center - How your data is used to improve model performance. [Apri la fonte](https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance)

[P3] OpenAI Developers - Data controls in the OpenAI platform. [Apri la fonte](https://developers.openai.com/api/docs/guides/your-data#default-usage-policies-by-endpoint)

[P4] Google - Gemini Apps Privacy Hub. [Apri la fonte](https://support.google.com/gemini/answer/13594961)

[P5] Anthropic Privacy Center - Is my data used for model training? [Apri la fonte](https://privacy.claude.com/en/articles/10023580-is-my-data-used-for-model-training)

[P6] Anthropic - Commercial Terms of Service. [Apri la fonte](https://www.anthropic.com/legal/commercial-terms)

[P7] Anthropic Privacy Center - How long do you store my organization’s data? [Apri la fonte](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data)

[P8] Anthropic Privacy Center - Zero data retention: eligible products and limitations. [Apri la fonte](https://privacy.claude.com/en/articles/8956058-i-have-a-zero-data-retention-agreement-with-anthropic-what-products-does-it-apply-to)

[P9] Microsoft Learn - Data, privacy, and security for Models sold by Azure in Microsoft Foundry. [Apri la fonte](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy)

[P10] Google Cloud - Gemini Enterprise Agent Platform and zero data retention. [Apri la fonte](https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/zero-data-retention)

[P11] Amazon Web Services - Data protection in Amazon Bedrock. [Apri la fonte](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html)

[P12] Anthropic Privacy Center - Data retention practices for Covered Models. [Apri la fonte](https://privacy.claude.com/en/articles/15425996-data-retention-practices-for-covered-models)

[P13] Amazon Web Services - Data retention in Amazon Bedrock. [Apri la fonte](https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html)

Dossier aggiornato al 27 luglio 2026

Sintesi delle verifiche

Le verifiche sulle fonti primarie effettuate il 27 luglio 2026 sono già incorporate nel corpo del dossier. Questo registro documenta le variazioni sostanziali e consente di distinguere i dati rimasti confermati dalle correzioni rese necessarie dall’evoluzione delle policy e del quadro europeo.

Modifiche integrate nel corpo

1. OpenAI. Per l’API restano confermati no-training per default e abuse monitoring fino a 30 giorni nella configurazione standard. Sono ora esplicitati anche i 30 giorni di application state predefinito di /v1/responses, la cache di prompt fino a 24 ore, le policy proprie dei tool/MCP terzi e le possibili eccezioni di Safety Retention. [P3]

2. Google Gemini consumer. Con Keep Activity disattivato, le chat future non sono usate per il training salvo feedback e sono conservate per 72 ore; le conversazioni già revisionate possono restare fino a tre anni, disconnesse dall’account. [P4]

3. Anthropic. Le regole standard di retention e ZDR sono confermate, ma dal 9 giugno 2026 i “Covered Models” designati richiedono 30 giorni di retention di prompt e output anche nei contesti ZDR e tramite cloud partner. Modello e piattaforma devono quindi essere verificati insieme. [P7-P8, P12]

4. Google Cloud Agent Platform. Grounding con Google Search conserva dati fino a 3 giorni, non 30; Maps arriva a 30 giorni. Session resumption arriva a 24 ore. La cache in-memory ha TTL di 24 ore ed è dichiarata compatibile con ZDR, pur essendo disattivabile. [P10]

5. Microsoft Foundry/Azure. Sono confermati no-training senza autorizzazione, controlli distinti per abuse monitoring e la necessità di verificare l’effettiva approvazione al modified abuse monitoring e il valore ContentLogging=false. [P9]

6. Amazon Bedrock. Non è più corretta una descrizione assoluta di assenza di storage o condivisione. La retention dipende dalla modalità effettiva e dagli allowed_modes del modello: none impedisce storage durevole e condivisione, provider_data_share li consente per i modelli che lo richiedono e store=false, da solo, non garantisce ZDR. [P11, P13]

7. Quadro italiano ed europeo. Sono stati integrati il parere del Garante sulle Linee guida MIM, la richiesta di informazioni del 3 giugno 2026, il corretto ambito delle Guidance EDPS e il calendario aggiornato dell’AI Act: applicazione generale dal 2 agosto 2026, trasparenza da agosto 2026, sistemi ad alto rischio in settori tra cui l’istruzione dal 2 dicembre 2027 e sistemi incorporati in prodotti regolamentati dal 2 agosto 2028. [R2, R8-R11]

Nota editoriale

Il dossier è informativo e tecnico-organizzativo e non costituisce consulenza legale. Prima di acquisto, rinnovo o uso con dati personali occorre ricontrollare contratto, DPA, subprocessori, regione, modello, endpoint, parametri, funzioni attive e configurazione effettiva del tenant o del progetto.