Rientro a scuola, IA e dati degli studenti: le verifiche da non trascurare

Con il rientro a scuola riprende la produzione di PEI, PDP, verbali, relazioni educative, profili di funzionamento, verifiche adattate e altra documentazione che può contenere dati personali, informazioni sanitarie, elementi sulla disabilità, situazioni familiari e valutazioni riferite a minori.

L’intelligenza artificiale rende ormai molto semplice analizzare o riscrivere questi documenti, ottenendo in pochi secondi un risultato formalmente professionale. Proprio questa facilità può nascondere il passaggio più importante: quale percorso compiono i dati inseriti per generare la risposta?

Eliminare soltanto nome e cognome non garantisce sempre una reale anonimizzazione. Classe, territorio, diagnosi, date, episodi personali, composizione familiare e altri dettagli, soprattutto quando combinati, possono rendere nuovamente identificabile lo studente. Il rischio nasce spesso dalla buona fede: si ritiene di avere protetto il documento, mentre una parte significativa delle informazioni personali continua a essere presente.

La tesi del dossier

La tutela dei dati non dipende soltanto dal modello utilizzato o dal marchio del provider. Dipende dal percorso completo del dato, dal momento in cui l’utente lo inserisce fino alla cancellazione di ogni eventuale copia.

Tre concetti da tenere distinti

• No-training: indica che, nelle condizioni applicabili, input e output non vengono utilizzati per addestrare o migliorare i modelli. Non significa automaticamente che non siano conservati.
• Retention: indica se, dove e per quanto tempo il contenuto rimane memorizzato. I cicli possono variare tra conversazioni, file, cache, funzioni stateful, controlli antiabuso e servizi collegati.
• Zero Data Retention (ZDR): indica che, nel perimetro approvato e per le funzioni compatibili, il provider non conserva il contenuto dopo l’elaborazione, secondo le condizioni ed eventuali eccezioni dichiarate. Non è un bollino universale e non garantisce, da sola, l’intera applicazione cliente.

Anche quando il provider applica condizioni restrittive, reverse proxy, strumenti di monitoraggio, error tracking, code di elaborazione, database e backup dell’applicazione possono ricreare altrove la traccia che si voleva evitare.

Quattro ambienti che non devono essere confusi

1. Chat consumer — È governata dall’account individuale, dalle impostazioni e dalle condizioni del servizio rivolto al pubblico. Offre un controllo organizzativo ridotto e, secondo un approccio prudenziale, non dovrebbe essere utilizzata con documenti di terzi non pubblici o contenenti dati personali reali.
2. Servizio enterprise — Può offrire identità organizzative, amministrazione centralizzata, accordi sul trattamento dei dati e clausole no-training. Occorre comunque verificare retention, connettori, funzioni stateful, subprocessori e configurazione effettivamente attiva.
3. API dietro un gateway controllato — Consente all’organizzazione di inserire un’applicazione tra l’utente e il modello. Il backend può minimizzare e pseudonimizzare l’input, autorizzare soltanto determinati endpoint, disattivare funzioni non necessarie, applicare controlli e registrare metadati tecnici senza conservare il contenuto. L’API offre maggiori possibilità di governo, ma non è automaticamente priva di retention.
4. Sistema locale o privato — Può evitare che il contenuto venga trasmesso a un provider esterno. Anche in questo caso la sicurezza non è automatica: collegamenti in uscita, telemetria, log, accessi, raccolte RAG, aggiornamenti, librerie e backup devono essere realmente governati e verificati.

Sette conclusioni operative

1. La chat consumer è un canale esterno di trattamento. Prompt, allegati, servizi collegati e metadati seguono le condizioni del prodotto consumer.
2. Revisione e retention non sono ipotesi astratte. Le policy possono prevedere periodi di conservazione, eccezioni legate alla sicurezza e possibili revisioni umane.
3. No-training non equivale a Zero Data Retention. Addestramento e conservazione rispondono a finalità e controlli differenti.
4. L’API è preferibile soltanto se è controllata. Endpoint, parametri, log, storage e funzioni devono essere imposti e verificati dall’applicazione.
5. Il locale offre maggiore sovranità, non sicurezza automatica. Egress, telemetria, accessi, supply chain e backup restano rischi concreti.
6. Gli adempimenti normativi e le garanzie tecniche richiedono prove distinte. Contratto, documentazione e configurazione effettiva devono essere coerenti tra loro.
7. Per scuola e pubblica amministrazione la cautela deve essere più alta. Minori, salute, disabilità, PEI, PDP, valutazioni e procedimenti possono richiedere misure rafforzate e ambienti più controllati.

Otto verifiche prima di utilizzare l’IA con dati non pubblici

1. Il contenuto viene utilizzato per addestrare il modello? La clausola no-training deve coprire input, output, allegati e feedback.
2. Quale retention si applica? Occorre verificare lo specifico progetto, endpoint, modello e funzione utilizzata.
3. File e funzioni stateful seguono cicli separati? Conversazioni, file, vector store, cache, grounding e memoria possono avere regole diverse.
4. Chi può leggere il contenuto? Revisione umana, ruoli autorizzati, escalation e accessi devono essere documentati.
5. Dove avviene il trattamento? Regione, subprocessori, servizi globali ed eventuali trasferimenti richiedono una valutazione distinta.
6. Che cosa registra l’applicazione cliente? Proxy, monitoraggio, error tracking, database, code e backup non devono ricreare log contenenti i documenti.
7. Quali strumenti aggiungono altri destinatari? Web search, browser, connettori, MCP e servizi esterni possono avere proprie condizioni e retention.
8. Come viene provata la cancellazione? TTL, procedure automatiche e test periodici devono produrre un riscontro verificabile.

Che cosa il dossier non afferma

• Non sostiene che ogni servizio cloud sia illecito o insicuro.
• Non afferma che una chiamata API garantisca automaticamente l’assenza di retention.
• Non presenta un sistema locale come sicuro senza hardening e governance.
• Non considera la ZDR del provider una garanzia sufficiente per l’intera applicazione.
• Non sostituisce il parere del DPO o la valutazione giuridica del singolo trattamento.

La raccomandazione è proporzionare l’ambiente al rischio. Le chat consumer possono essere utilizzate per informazioni pubbliche o realmente sintetiche. Nei casi ordinari, un’API inserita in un gateway controllato può offrire maggiori possibilità di governo. Per le categorie più sensibili, un’elaborazione locale o privata può ridurre l’esposizione a terzi, purché l’infrastruttura sia realmente chiusa, mantenuta e sottoposta a verifica.

Dal dossier «No-training non significa Zero Data Retention» di Francesco Silvaggio.