ZDR Google e Architettura OI: una protezione concreta per i dati scolastici

Perché abbiamo chiesto la ZDR

Il 30 luglio 2026 il team Generative AI Services di Google ci ha comunicato l'approvazione della richiesta di eccezione alla policy di prompt logging per lo specifico progetto Google Cloud utilizzato nelle chiamate Gemini API. È una misura concreta, riferita a un progetto preciso, che interviene su uno dei punti più delicati della catena dei dati. Non è una certificazione dell'intera piattaforma: è una garanzia precisa che abbiamo inserito in un'architettura applicativa più ampia.

Abbiamo presentato la richiesta durante il riesame tecnico dei nostri flussi. Se un documento scolastico viene analizzato tramite IA, non basta sapere che non sarà usato per addestrare un modello. Occorre verificare il servizio effettivamente usato, il progetto coperto, le funzioni ammesse, i tempi dichiarati e i controlli applicativi che accompagnano la richiesta.

Che cosa ha approvato Google

Il progetto approvato è identificato dal numero 77022326671. La documentazione ufficiale della Gemini Developer API spiega che, quando una richiesta ZDR viene approvata, prompt, risposte e metadati identificabili vengono eliminati prima della registrazione destinata al monitoraggio degli abusi. Può rimanere un record tecnico sanificato, privo del contenuto dell'utente e degli identificativi associabili alla richiesta.

Questo passaggio è diverso dalla semplice restrizione di addestramento. Un servizio può non usare i dati per migliorare i modelli e conservarli comunque per finalità di sicurezza o funzionamento. L'eccezione approvata interviene proprio sulla conservazione dei contenuti nei log di abuse monitoring.

Perché è importante quando sono coinvolti dati scolastici

PEI, PDP, profili di funzionamento e verifiche adattate possono contenere informazioni riferite a minori, disabilità, salute, relazioni familiari e percorsi educativi. Cambiare soltanto il nome dell'interessato non rende automaticamente anonimo il documento: combinazioni di date, istituto, territorio, diagnosi ed eventi possono continuare a rendere una persona riconoscibile.

Per questo la prima misura resta la minimizzazione: inviare esclusivamente ciò che serve, omettere identificativi diretti non necessari e non caricare una certificazione completa quando è sufficiente descrivere il bisogno educativo. La ZDR aggiunge un livello ulteriore: riduce la possibilità che il contenuto sopravviva presso il provider come log destinato al controllo degli abusi.

La nostra protezione nasce da una catena, non da uno slogan

L'approvazione definisce ciò che accade nel perimetro del provider. Noi l'abbiamo inserita in un sistema che controlla anche le scelte applicative: quali dati sono davvero necessari, come raggiungono il provider, quali funzioni possono essere abilitate e quali controlli devono restare attivi nel tempo.

Per questo presentiamo la protezione come una catena composta da tre livelli:

1. 1. Provider. Condizioni del servizio, restrizione di addestramento ed eccezione approvata al prompt logging.
2. 2. Applicazione. Minimizzazione, flussi stateless dove appropriato, funzioni compatibili con il perimetro e controlli verificabili.
3. 3. Organizzazione. Base giuridica, minimizzazione, autorizzazioni, DPIA e regole operative per gli utenti.

Come abbiamo costruito il backend che accompagna la ZDR

Nelle funzioni che impiegano Gemini API usiamo flussi stateless nei casi coperti e inviamo soltanto i contenuti necessari alla richiesta. Nei flussi verificati escludiamo le funzioni opzionali che prevedono cicli di conservazione separati o non compatibili con il profilo adottato.

Manteniamo la chiave di produzione sul server e la limitiamo alla sola API necessaria e all'indirizzo IP autorizzato. Test automatici impediscono che configurazioni incompatibili con il profilo verificato vengano introdotte per errore. In questo modo una scelta di sicurezza non resta una dichiarazione: diventa una proprietà controllata nel codice.

I dati che l'utente salva volontariamente nella piattaforma per utilizzare il servizio seguono invece finalità e tempi definiti nella Privacy Policy. La ZDR delle chiamate al provider non equivale alla cancellazione immediata dei dati applicativi necessari a erogare le funzioni richieste.

Perché questo traguardo fa la differenza

Non chiediamo di fidarsi della parola “sicuro” o del nome di un provider. Rendiamo verificabile ciò che abbiamo ottenuto e spieghiamo come lo abbiamo inserito nel prodotto. Google ha approvato l'eccezione al prompt logging prevista per la ZDR dello specifico progetto Gemini API; noi abbiamo configurato e testato i flussi affinché le principali funzioni con conservazione incompatibile restino escluse.

Per chi usa le funzioni coinvolte significa poter contare su una tutela tecnica concreta: la protezione del provider e quella applicativa sono state progettate per lavorare insieme. È questo, più del nome del modello, a distinguere una piattaforma costruita intorno ai dati scolastici da una chat consumer generalista.