IA e privacy a scuola: 10 controlli prima di caricare PEI e PDP

Copiare un testo in una chat di intelligenza artificiale richiede pochi secondi. Capire quale percorso compiano quel testo e i suoi allegati è molto più difficile. A scuola la differenza è decisiva: un PEI, un PDP, un profilo di funzionamento, un verbale del GLO o una verifica adattata possono descrivere salute, disabilità, difficoltà, valutazioni e condizioni familiari di un minore.

Dal dossier tecnico-normativo di Orizzonte Insegnanti emerge una regola semplice: “non usato per addestrare” non significa automaticamente “non conservato”. E “in locale” non significa automaticamente “sicuro”. Per scegliere uno strumento non basta quindi conoscere il nome del modello o pagare un abbonamento: occorre verificare il servizio concreto, la configurazione attiva e l'intero percorso del dato.

Perché PEI e PDP richiedono una cautela superiore

Il GDPR considera particolarmente protetti, tra gli altri, i dati relativi alla salute. Nel contesto scolastico il rischio non riguarda soltanto la diagnosi scritta in chiaro. Obiettivi, descrizioni del funzionamento, misure dispensative, episodi comportamentali, nomi dei familiari, scuola, classe e date possono rendere identificabile lo studente anche dopo aver sostituito nome e cognome con una sigla.

Per questo cambiare il nome non equivale sempre ad anonimizzare. È spesso una pseudonimizzazione utile, ma l'identità può essere ricostruita combinando gli altri elementi. La minimizzazione deve riguardare l'intero contenuto: trasmettere soltanto la porzione necessaria, eliminare dettagli non pertinenti e preferire esempi sintetici quando l'obiettivo è ottenere una struttura, una spiegazione o una proposta generale.

Chat consumer, API controllata e IA locale non sono la stessa cosa

La parola “IA” riunisce architetture molto diverse. Lo stesso modello può essere offerto in una chat personale, in un servizio aziendale, tramite API o dentro un'applicazione costruita da terzi. Cambiano contratto, ruoli privacy, funzioni, tempi di conservazione, controlli amministrativi e possibilità di impedire usi non autorizzati.

Nessuna riga della tabella è automaticamente “sicura” o “insicura”. Una piattaforma via API ben governata può offrire garanzie molto più solide di una chat personale; un sistema locale non aggiornato o accessibile a troppe persone può invece creare nuovi rischi. Conta il sistema reale, non l'etichetta commerciale.

No-training, retention e ZDR: tre concetti da non confondere

• No-training: il contenuto non viene usato per addestrare o migliorare i modelli secondo le condizioni applicabili.
• Retention limitata: il contenuto può essere conservato per un periodo definito, per esempio per sicurezza, funzionamento o obblighi giuridici.
• Zero Data Retention (ZDR): nel perimetro dichiarato e alle condizioni previste, il provider non conserva il contenuto del cliente dopo l'elaborazione.

La ZDR è una garanzia importante, ma deve essere letta con precisione. Può riferirsi a uno specifico progetto, prodotto o insieme di endpoint; alcune funzioni che memorizzano stato, file, cache o risultati possono avere regole diverse. La documentazione Google, per esempio, distingue il prompt logging dalle funzioni di grounding, file storage, caching e API stateful. La verifica va quindi svolta sulla configurazione realmente usata, non su una promessa generica del marchio.

I 10 controlli prima di caricare un documento scolastico

1. Definisci la finalità e chi ha autorizzato l'uso

“Mi aiuta a fare prima” non è una finalità organizzativa sufficiente. Occorre sapere quale attività si sta svolgendo, quali dati sono necessari, chi è titolare del trattamento e se lo strumento rientra tra quelli autorizzati dalla scuola o dall'ente. Per i trattamenti più rischiosi vanno coinvolti dirigenza, responsabile della protezione dei dati e funzioni tecniche competenti; quando ricorrono i presupposti, va valutata una DPIA.

2. Classifica i dati prima di copiarli

Un regolamento pubblico e un PEI compilato non hanno lo stesso rischio. Se il testo contiene salute, disabilità, dati di minori, valutazioni individuali, vicende familiari o procedimenti, fermati prima dell'upload. Chiediti se puoi ottenere lo stesso risultato con un modello vuoto, un estratto ridotto o un caso fittizio.

3. Riduci il contenuto, non soltanto il nome

Rimuovi identificativi diretti e indiretti non necessari: nome, data di nascita, scuola, classe, territorio, riferimenti familiari, date precise e combinazioni rare. Suddividi il compito in passaggi e invia soltanto ciò che serve per quel passaggio. La minimizzazione è più efficace quando è progettata nel flusso, non affidata alla memoria dell'utente.

4. Identifica il prodotto esatto e le sue condizioni

Non basta scrivere “usiamo il modello X”. Servono il tipo di account, il piano, il servizio, il progetto cloud, la regione, l'endpoint e le funzioni attive. Le condizioni di una chat gratuita possono differire da quelle di un servizio a pagamento o di un'API. Anche nello stesso ecosistema, caricamento file, ricerca web, cronologia e connettori possono seguire regole diverse.

5. Separa addestramento, logging e memoria funzionale

Chiedi risposte distinte: i dati vengono usati per migliorare i modelli? Per quanto tempo prompt e output restano nei log? Esistono revisioni umane? La conversazione viene salvata? I file devono essere cancellati manualmente? La cache è in memoria o persistente? Una sola frase “i tuoi dati sono protetti” non risponde a queste domande.

6. Leggi DPA, ruoli, subfornitori e trasferimenti

Nei contesti organizzativi servono condizioni applicabili al rapporto reale: accordo sul trattamento dei dati, ruoli delle parti, sub-responsabili, localizzazione e trasferimenti, misure di sicurezza, assistenza nell'esercizio dei diritti e gestione degli incidenti. Una pagina marketing non sostituisce la documentazione contrattuale.

7. Valuta l'applicazione che sta davanti al modello

Quando si usa un'applicazione, il dato non incontra soltanto il provider IA. Attraversa interfaccia, backend e servizi tecnici del prodotto. Bisogna quindi verificare che l'applicazione applichi controlli coerenti con la garanzia dichiarata dal provider e non trasformi una richiesta temporanea in una copia permanente non necessaria.

8. Limita accessi, log, esportazioni e backup

Chi può leggere prompt, output e documenti? Gli amministratori vedono il contenuto? I log registrano soltanto eventi tecnici o anche testi? Le esportazioni vengono cifrate? La cancellazione raggiunge copie, code e backup secondo tempi definiti? Sono domande che riguardano qualsiasi piattaforma, anche quando il provider del modello offre ZDR.

9. Mantieni il docente responsabile del risultato

L'IA può preparare una bozza, evidenziare incoerenze o proporre alternative; non conosce da sola lo studente e non sostituisce GLO, consiglio di classe, docente o valutazione professionale. Gli output vanno verificati per correttezza, appropriatezza, linguaggio e possibili inferenze discriminatorie. Il documento finale resta una decisione umana.

10. Conserva le prove e ripeti la verifica

Registra versione delle condizioni, configurazione, data della verifica, responsabili e test effettuati. I servizi IA cambiano rapidamente: una funzione aggiunta, un endpoint diverso o una nuova impostazione possono modificare il percorso del dato. La conformità non è una spunta permanente, ma un processo controllato.

Una matrice pratica: verde, giallo e rosso

Il risultato ottenuto da Orizzonte Insegnanti con Google ZDR

Il 30 luglio 2026 Google ha approvato per lo specifico progetto Gemini API di Orizzonte Insegnanti la richiesta di eccezione al prompt logging prevista dal percorso Zero Data Retention. Secondo la documentazione ufficiale, dopo l'approvazione i contenuti utente e i metadati identificabili vengono rimossi prima della registrazione destinata al monitoraggio degli abusi, nel perimetro coperto e rispettando le condizioni previste.

Per noi questo è un traguardo concreto perché non viene usato come un bollino isolato. Lo abbiamo integrato con Architettura OI, il sistema applicativo proprietario con cui governiamo i servizi di Orizzonte Insegnanti: il valore nasce dall'abbinamento tra la garanzia ottenuta dal provider e un'applicazione progettata, testata e verificata per preservarla nei flussi dichiarati. Il nome di un singolo modello non è il centro della protezione; lo sono l'architettura e le regole che governano il servizio.

Quando l'IA locale può essere la scelta giusta

Un sistema locale o privato può ridurre in modo sostanziale l'esposizione del contenuto a terzi e può essere utile per pre-elaborare, segmentare o de-identificare documenti prima di qualsiasi passaggio successivo. Può anche offrire un contesto circoscritto all'attività dell'ente. Ma richiede competenze, hardware adeguato, aggiornamenti, controllo degli accessi, blocco delle comunicazioni non necessarie e test di qualità.

La scelta non deve diventare una gara ideologica tra cloud e locale. In alcuni casi la soluzione migliore è locale; in altri è un'API con condizioni e retention controllate; spesso è un'architettura ibrida che assegna a ogni componente soltanto i dati indispensabili. Il criterio resta lo stesso: ridurre l'esposizione senza sacrificare controllo, qualità e responsabilità.

Cosa può fare una scuola già da domani

1. vietare l'inserimento di documenti identificabili nelle chat consumer non autorizzate;
2. pubblicare una regola interna breve con esempi concreti di dati ammessi e vietati;
3. mappare gli strumenti già usati da docenti, segreteria e fornitori;
4. chiedere ai fornitori risposte scritte su training, retention, funzioni e percorso completo del dato;
5. predisporre modelli di minimizzazione e casi sintetici per le attività formative;
6. coinvolgere DPO e responsabili tecnici prima di estendere l'uso a PEI, PDP o altri documenti sensibili;
7. formare il personale non soltanto sui prompt, ma sulle conseguenze organizzative di ogni upload.

L'obiettivo non è fermare l'innovazione. È evitare che la facilità d'uso trasformi un gesto individuale in una comunicazione di dati non valutata. Gli strumenti di IA possono davvero migliorare il lavoro scolastico quando la protezione dei dati è parte della progettazione, non una correzione aggiunta alla fine.

Questo approfondimento ha finalità informativa e operativa e non sostituisce la valutazione giuridica, tecnica o organizzativa del singolo trattamento.