Di Monica Buonanno

Introduzione Editoriale

Le domande che si fanno prima di firmare

Questo numero contiene molte tesi. Ne contiene due che una scuola può usare la mattina dopo averle lette: una per chi insegna, e questa per chi decide.

Il contributo nasce da una rotazione di prospettiva che l’autrice formula così: non che cosa l’insegnante o lo studente debbano capire di un sistema che usano già, ma che cosa una scuola deve chiedere prima di far entrare quel sistema.

Monica Buonanno lavora su politiche integrate di lavoro e welfare, e porta un’analogia che viene dal suo mestiere: le clausole sociali in un appalto pubblico non correggono il mercato del lavoro a valle, lo orientano a monte. Allo stesso modo il capitolato di una piattaforma per la scuola non è un documento informatico: è l’unico punto della filiera in cui una scuola può ancora scegliere invece di subire.

Da qui dieci domande da porre a un fornitore prima della firma. Ma la parte più rigorosa del contributo è quella in cui l’autrice ne dichiara i limiti, distinguendo che cosa è oggi realmente esigibile e che cosa no — perché il rischio è che la checklist appaia più esigibile di quanto non sia.

E il passaggio che vale l’intero testo riguarda la domanda sui test relativi ai bias: il suo valore non sta in una risposta documentata, che oggi quasi mai arriverà, ma nel fatto che la sua assenza è già un’informazione.

Una domanda che funziona anche quando non riceve risposta.

Carmine Marinucci

La domanda su chi decide, con quali dati, secondo quali criteri? nell’uso dell’intelligenza artificiale nelle scuole corre il rischio di rimanere senza risposta. Come si sta osservando in ambienti anche molto differenti tra loro, la proposta Ora Lege et Labora di DiCultHer – pure nella sua altissima valenza – può arenarsi a un livello di riflessione per soli esperti tecnici, mentre l’impianto decisionale continua a essere responsabilità di altri.

Qui provo a fare un passo che la prima riflessione lasciava aperto: non che cosa l’insegnante o la studentessa e lo studente debbano capire di un sistema che usano già, ma che cosa una scuola deve chiedere prima di far entrare quel sistema. Diventa così una importante rotazione di responsabilità, ovvero il passaggio da chi impara a usare la tecnologia a chi firma il contratto che la introduce.

Di certo, ed è corretto così, nessuna scuola è chiamata a progettare i sistemi di intelligenza artificiale che utilizza e, soprattutto, nessuna scuola dovrebbe provare a farlo, non essendo quella la competenza da costruire (a meno che naturalmente non si tratti di materia di indirizzo e in tal condizione parliamo di altro). Prima che la questione diventi tecnica, la scuola ha il pieno ed esclusivo potere di decisione di adozione del sistema di intelligenza artificiale. È il momento in cui un dirigente scolastico come un collegio docenti o una rete di scuole sono chiamati a scegliere il fornitore, accettando condizioni contrattuali che quasi mai vengono lette come questioni educative e pedagogiche.

Chi, come me, si occupa di politiche del lavoro integrate al welfare conosce piuttosto bene il meccanismo della committenza pubblica. Le clausole sociali in un appalto non correggono il mercato del lavoro a valle ma lo orientano a monte, nel momento in cui l’ente decide che cosa comprare e a quali condizioni. Il capitolato di una piattaforma di intelligenza artificiale per la scuola ha, dal punto di vista del potere che esercita, il medesimo valore, cioè non solo un documento informatico, ma l’unico punto della filiera in cui la scuola può ancora non subire condizioni che probabilmente alterano i principi educativi e pedagogici della scuola stessa.

A questo punto propongo, attraverso il ragionamento, uno strumento di autovalutazione preventiva – a supporto della elaborazione e redazione del capitolato – che serve a una condizione, cioè a spostare la domanda dal  funziona bene? al che cosa comporta adottarlo? Ovviamente prima che il contratto sia firmato e non dopo che il problema si è manifestato in classe o, comunque, nella scuola. Non richiede competenze tecniche ma che qualcuno nell’organizzazione abbia il mandato e il tempo per farla e che le risposte del fornitore diventino parte della decisione e non un allegato trascurato.

La checklist, infatti, è pensata per chi partecipa alla decisione di adozione del sistema e non per chi userà lo strumento una volta adottato e introdotto.

La proposta di checklist

  1. Dati raccolti: quali dati raccoglie la piattaforma, sono realmente necessari alla sua funzione dichiarata? Dove vengono conservati, in quale Paese, per quanto tempo?
  2. Minori: quali garanzie specifiche, distinte da quelle generiche sulla privacy, sono previste per i dati di studentesse e studenti minorenni?
  3. Addestramento: i dati inseriti dagli utenti (elaborati, testi, valutazioni) vengono riutilizzati per addestrare o migliorare il sistema? Con quale consenso e revocabile da chi?
  4. Bias e discriminazioni: sono stati condotti test specifici su bias di genere, culturali, linguistici o legati alle disabilità? Il fornitore può mostrarne i risultati, non solo dichiararne l’esistenza?
  5. Trasparenza: quali informazioni sul funzionamento e sui limiti del sistema sono disponibili in forma comprensibile non solo ai tecnici esperti informatici?
  6. Errore e controllo umano: è sempre previsto un controllo umano prima che una risposta del sistema produca un effetto su una persona (un orientamento, una valutazione, un’esclusione)? Chi lo esercita, con quale formazione?
  7. Responsabilità: chi risponde, contrattualmente, degli effetti prodotti da un errore o da una decisione discriminatoria del sistema? La scuola, il fornitore, entrambi in che misura?
  8. Reversibilità: la scuola può interrompere il servizio e ottenere la cancellazione effettiva, verificabile, dei dati raccolti?
  9. Coerenza educativa: l’uso della piattaforma resta coerente con le finalità educative dichiarate dalla scuola o le ridefinisce silenziosamente?
  10. Equità: il sistema, nel tempo, sta riducendo le disuguaglianze che la scuola dichiara di voler contrastare oppure le sta automatizzando sotto forma di previsione neutrale?

A questo punto vale la pena essere onesti sui limiti della checklist stessa che io definisco importante anche dal punto di vista metodologico. Evidenzio che non tutte le dieci domande hanno allo stato attuale la stessa esigibilità e vanno distinte su tre livelli (il rischio altrimenti è che la checklist appaia più esigibile di quanto non sia realmente).

Il livello già dovuto. Dati raccolti, luogo di conservazione, tempi di retention, cancellazione in uscita non sono materia specifica dell’intelligenza artificiale: ricadono negli obblighi generali del Regolamento (UE) 2016/679 (GDPR) — minimizzazione (art. 5), individuazione di un responsabile del trattamento (art. 28), garanzie rafforzate per i minori (art. 8) — e nel Codice in materia di protezione dei dati personali, il d.lgs. 196/2003 come modificato dal d.lgs. 101/2018. Un fornitore serio deve poterli documentare a prescindere dal sistema che vende. Se non risponde nemmeno a questo, la risposta è già pronta.

Il livello in transizione. L’istruzione rientra tra i settori ad alto rischio elencati nell’Allegato III del Regolamento (UE) 2024/1689 (AI Act), la cui classificazione discende dall’articolo 6 e comporta, agli articoli 9-15, obblighi di gestione del rischio, governance dei dati, documentazione tecnica, tracciabilità, sorveglianza umana e accuratezza. Questi obblighi pieni, inizialmente previsti dal 2 agosto 2026, sono stati prorogati al 2 dicembre 2027 dal Regolamento (UE) 2026/1744 — il cosiddetto “Digital Omnibus on AI”, in vigore dal 27 luglio 2026 — mentre restano confermati dal 2 agosto 2026 gli obblighi di trasparenza dell’articolo 50. In Italia, però, il vuoto non è totale visto che il decreto ministeriale n. 166 del 9 agosto 2025 ha adottato le Linee guida del Ministero dell’Istruzione e del Merito per l’introduzione dell’IA nelle scuole, validate dal Garante per la protezione dei dati personali. Lo stesso Garante ha inserito tra le proprie attività ispettive per il periodo gennaio-luglio 2026 (delibera n. 797/2025) verifiche mirate sull’uso di strumenti di IA in ambito scolastico. Significa che, mentre l’obbligo europeo pieno resta sospeso fino al 2027, in Italia le domande della checklist sono già, in pratica, oggetto di vigilanza attiva. Farne richiesta oggi non è solo lecito, ma rappresenta ciò che un’ispezione potrebbe chiedere alla scuola stessa.

Il livello debole. È quello dei test sui bias, ed è il più critico per il tema di cui ci occupiamo. Un’analisi di EFF su 152 strumenti EdTech[1] ha rilevato assenza di informazioni su conservazione dei dati, sicurezza e de-identificazione in buona parte dei casi esaminati, con raccolta di dati sensibili talvolta condivisi con terzi. Uno studio più recente, condotto su tredici responsabili EdTech in sette istituzioni universitarie, descrive difficoltà strutturali nel rendere i fornitori responsabili per mancanza di visibilità sui sistemi e asimmetria di potere — il titolo dello studio, Trust, Because You Can’t Verify, riassume la condizione in cui si trova oggi chi acquista[2]. Le prove di test sui bias, quando esistono, restano quasi sempre interne al fornitore: non certificate da terzi, né standardizzate, né rese pubbliche.

Ci tengo a sottolineare che il valore della relativa domanda tematica n. 4 non sta in una risposta documentata — oggi, nella maggior parte dei casi, non arriverà — ma nel fatto che la sua assenza è già un’informazione. Una scuola che pone quella domanda e non ottiene nulla di verificabile sa, a quel punto, che la responsabilità di gestire il rischio resta interamente sua. È una scuola che scopre (e su questo si attiva il valore della metodologia) quanto della propria responsabilità educativa possa ancora essere delegata.

Il bias di genere resta, dunque, il laboratorio più concreto per capire perché la checklist e la metodologia che rivela non sono solo un esercizio burocratico. Ad esempio, un sistema di orientamento addestrato su dati storici, in cui certe professioni risultano prevalentemente maschili o femminili, tende a riprodurre quella distribuzione anche quando la presenta come suggerimento personalizzato e neutro. Il punto non è soltanto pedagogico (insegnare a studentesse e studenti a riconoscere il bias nella risposta che ricevono) ma contrattuale. Prima ancora che quella risposta esista, infatti, qualcuno nella scuola ha scelto quel fornitore senza aver chiesto se il sistema fosse mai stato testato per quel rischio specifico. La domanda 4 della checklist non è una clausola qualsiasi, ma è la clausola che identifica se il problema si può ancora prevenire o si potrà soltanto correggere dopo che si è già presentato.

Una scuola non deciderà mai come viene addestrato un modello. Può decidere, con margini reali e già oggi, quale modello far entrare nelle proprie aule e a quali condizioni. È una responsabilità inferiore al “governo” in senso stretto dell’intelligenza artificiale ma decisamente più esercitabile in quanto richiede che qualcuno, nella scuola, ponga dieci domande prima di firmare invece che dopo aver scoperto la risposta. Le scuole che ricorrono al servizio si configurano come consumatori finali. Probabilmente, tra i parametri apprezzati vi saranno stati il prezzo d’acquisto, la rapidità della fornitura, alcuni servizi aggiuntivi. Ma reti di scuole se non, addirittura, l’intero sistema scolastico hanno un potere negoziale che va ben oltre questi margini. E, soprattutto in merito all’addestramento del programma di IA prescelto, potrebbero svolgere una funzione vitale.

MONICA BUONANNO

Esperta in Politiche integrate Lavoro Sviluppo Welfare Specializzazioni: Politiche di contrasto e riduzione dei divari di genere, generazionali e di cittadinanza e Interventi di sviluppo territoriale nelle aree interne e nelle periferie urbane del Paese.

[1] Electronic Frontier Foundation, Spying on Students: School-Issued Devices and Student Privacy, a cura di Frida Alim, Nate Cardozo, Gennie Gebhart, Karen Gullo, Amul Kalia, aprile 2017. https://www.eff.org/files/2017/04/13/student-privacy-report.pdf

[2] Easton Kelso, Ananta Soneji, Sazzadur Rahaman, Yan Soshitaishvili, Rakibul Hasan, Trust, Because You Can’t Verify: Privacy and Security Hurdles in Education Technology Acquisition Practices, in Proceedings of the 2024 ACM SIGSAC Conference on Computer and Communications Security (CCS ’24), Settembre 2024. DOI: https://doi.org/10.1145/3658644.3690353 Preprint disponibile su arXiv: https://arxiv.org/abs/2405.11712