AI nelle scuole italiane: dal DM 166 ai primi deployment reali

Fino a ieri, in molte scuole italiane l'intelligenza artificiale stava in una zona grigia. Qualcuno la usava in classe. Qualcun altro la vietava. Quasi nessuno sapeva chi ne rispondeva.

Le Linee Guida del Ministero dell'Istruzione e del Merito (DM 166/2025) hanno chiuso quella zona. Dirigenti scolastici e DSGA sono «deployer» formali dei sistemi AI. Non è un titolo. È un ruolo: chi mette in produzione un sistema deve poterlo valutare, monitorare e, se serve, spegnere.

Il DM 219 ha messo i soldi accanto al mandato. 100 milioni di euro PNRR. Fino a 50.000 euro per istituto. La domanda non è più «possiamo usare l'AI». È «quale sistema teniamo in casa senza creare un problema di responsabilità».

Cosa significa «deployer» in una scuola

In un'azienda il deployer è spesso un CTO o un responsabile IT. In una scuola è il dirigente. Ha un incarico pubblico, un collegio docenti, famiglie, alunni minori, dati sensibili.

Un sistema che «aiuta i docenti» senza dire come decide, su quali dati, e chi può verificarlo, non è adottabile. Non per pigrizia. Per legge.

L'AI Act europeo classifica molti usi in ambito educativo come ad alto rischio. Valutazione degli studenti, ammissione, assegnazione di percorsi. Anche quando il prodotto si presenta come «tutor» o «assistente alla didattica», il confine è sottile. Va dichiarato prima, non dopo il primo piloto.

Noi partiamo da tre domande, sempre le stesse. Chi è il responsabile del sistema. Quali dati tocca. Come si dimostra, a un ispettore o a un genitore, che il sistema fa quello che dice.

Se una di queste tre non ha risposta, non si installa nulla.

I fondi arrivano. Il software no

Cinquanta mila euro per istituto sembrano tanti da fuori. Da dentro coprono poco, se si compra un prodotto chiuso con canone annuale, formazione extra e dati che escono dall'Unione.

Le scuole con cui lavoriamo non chiedono un chatbot. Chiedono tre cose concrete.

Un tutor didattico che parta dai materiali già in uso, non da un corpus generico. Stesso programma, livelli diversi. Il docente resta chi decide. Il sistema propone, non sostituisce.

Uno strumento per la progettazione dei percorsi personalizzati. Piani, adattamenti, evidenze. Quello che oggi sta in file Word sparsi e in riunioni che nessuno riesce a rivedere.

Dati che restano in EU. Meglio ancora: sotto il controllo dell'istituto. Account, log, backup, cancellazione. Cose noiose. Sono quelle che tengono in piedi un deployer.

Il vincolo vero non è il modello

Scegliere Claude, GPT o un modello locale è una decisione di secondo livello. Prima viene la governance.

Ogni sistema deve essere valutabile. Significa: un dirigente può aprire un report e capire cosa ha fatto il sistema questa settimana. Quante sessioni. Su quali classi. Con quali materiali. Dove ha sbagliato.

Deve essere monitorabile. Non un dashboard da marketing. Un registro. Chi ha accesso. Chi ha esportato. Quando si è spento un modulo.

Deve essere spegnibile. Se un docente segnala un output sbagliato su un alunno, il percorso si interrompe. Non «apriamo un ticket al fornitore americano».

Abbiamo visto selezioni pubbliche vinte e poi bloccate perché il fornitore non sapeva rispondere a queste tre. La feature c'era. La responsabilità no.

Cosa stiamo mettendo in produzione

Lavoriamo con istituti italiani su software conforme, non su demo.

I tutor usano i materiali della scuola. Programma, verifiche, adattamenti. Il livello si regola. Il docente vede la traccia. Niente «l'AI ha detto così» senza fonte.

I dati di alunni e famiglie non escono dal perimetro concordato. Hosting in EU. Contratti con DPA. Accessi nominativi. Conservazione limitata.

Il dirigente ha una vista da deployer: stato del sistema, log di uso, punti di spegnimento. Non è un extra. È il prodotto.

Il lavoro lento è a monte. Mappa dei processi. Chi tocca i dati. Quali usi sono alto rischio e quali no. Solo dopo si scrive il software.

Come partire senza bruciare il fondo

Un istituto non deve «adottare l'AI». Deve scegliere un processo. Uno. Didattica differenziata, oppure progettazione dei PDP, oppure sportello per i docenti. Non tre insieme.

Si misura prima. Quante ore ci vogliono oggi. Dove si perdono i materiali. Quali errori tornano ogni quadrimestre.

Si costruisce un pezzo visibile in settimane, non un piano triennale. Il collegio deve poterlo usare. Se non lo usa, si ferma.

Si scrive chi è responsabile. Per nome. Con i log. Prima della prima login degli studenti.

Se questo ordine vi sembra lento, è il contrario. È l'unico che arriva in produzione e resta acceso dopo l'ispezione.

Cosa abbiamo già visto andare storto

Un istituto ha comprato un tutor «chiavi in mano». I docenti lo hanno aperto. Gli alunni hanno incollato i compiti. Dopo tre settimane una famiglia ha chiesto quali dati fossero partiti, verso chi, e se si potessero cancellare. Il fornitore ha risposto con una FAQ in inglese. Il dirigente ha spento tutto. I 50.000 euro erano impegnati. Il sistema no.

Un altro ha fatto un piloto su una classe sola, senza log. È andato bene. All'estensione su tre plessi nessuno sapeva chi aveva accesso. Due account condivisi. Una password in una mail. Non è un problema di modello. È un problema di deployer che non ha gli strumenti per esserlo.

Il terzo caso è il più comune. Slide, comitato, nessuna scelta di processo. Sei mesi dopo, zero uso. Il fondo scade. Si compra formazione generica per «aver fatto qualcosa». Non è adozione. È un rendiconto.

Questi tre esiti si evitano con lo stesso gesto: un processo, un responsabile, un perimetro dati, un pezzo visibile. Prima del canone annuale.

Il docente non è un ostacolo

Spesso si racconta la scuola come resistente. Nei progetti che teniamo in piedi, i docenti chiedono cose precise. Vogliono materiali loro, non un corpus americano. Vogliono vedere il passaggio. Vogliono poter dire no a un output. Vogliono che il tempo guadagnato resti loro, non si trasformi in più report.

Se il sistema nasconde il ragionamento, il docente lo tratta come un oracolo o come un nemico. Tutti e due gli esiti sono inutili. La traccia visibile — fonte, livello, suggerimento — è ciò che rende il tutor uno strumento, non una sostituzione.

La formazione serve. Non un corso «cos'è l'AI». Un'ora sul flusso vero: come si carica un'unità, come si corregge un errore, come si spegne. Se quella ora non basta, il prodotto è sbagliato.

Se state scegliendo un fornitore

Chiedete dove stanno i dati. Chiedete chi è il deployer nel contratto. Chiedete come si spegne un modulo. Chiedete se il sistema è valutabile da voi, o solo dal vendor.

Se la risposta è una slide, non è una risposta.

Noi costruiamo sistemi su misura. Il codice resta della scuola o dell'ente che lo paga. I dati restano loro. Se volete vedere come impostiamo la governance prima del software, scriveteci.