Un corso AI per il team si giudica da esercizi e verifica, non dall'elenco degli argomenti

A chi in azienda deve scegliere un corso di formazione AI per il team capita di ricevere proposte che si somigliano. Un indice di argomenti: cos'è l'AI generativa, come si scrive una richiesta, i casi d'uso, i rischi, le regole europee. Una durata, un prezzo, un attestato a fine percorso. Messe una accanto all'altra, le proposte sembrano intercambiabili, e la scelta finisce per cadere sul prezzo o sul nome di chi le firma.

L'elenco degli argomenti dice di cosa parlerà il docente. Non dice cosa sapranno fare le persone alla fine, né come lo saprai tu. Due corsi con lo stesso indice possono essere due cose opposte: in uno il team ascolta e guarda una dimostrazione, nell'altro ogni persona scrive una richiesta su un'attività del proprio lavoro, controlla la risposta, trova l'errore e lo corregge. Sulla carta hanno gli stessi titoli. Il lunedì dopo, in ufficio, non lasciano al team la stessa cosa.

Questo articolo è per chi deve fare quella scelta: chi si occupa di persone e formazione, il referente di un team che ha appena ricevuto le licenze, la direzione che deve approvare un preventivo. Propone tre cose da guardare in un programma, cioè gli esercizi, la preparazione che li rende possibili e la verifica dell'apprendimento, e chiude con le domande da fare a chi lo propone.

Una premessa, perché è giusto dirla subito: progetto e propongo formazione AI per i team, quindi sono una delle parti che riceve queste domande. I criteri che seguono sono quelli con cui ho costruito il mio programma, che è pubblico. Valgono per qualsiasi proposta, la mia compresa, e il modo più onesto di usarli è applicarli anche a me.

Perché l'indice di un corso non basta per sceglierlo

Gli argomenti di un corso AI tendono a essere gli stessi, perché la materia è la stessa. Limiti ed errori dei modelli, dati da proteggere, come si formula una richiesta, come si controlla una risposta, quando serve una persona: un programma serio li tocca tutti, e uno meno serio li elenca comunque. Per questo l'indice discrimina poco. Serve a verificare che non manchi qualcosa di grosso, non a capire se il corso funzionerà.

La differenza sta altrove: in quanto tempo le persone passano a fare invece che ad ascoltare, su quali attività si esercitano, che cosa producono e come si verifica che abbiano imparato. Sono le parti che un indice non mostra, e sono quelle che decidono se il giorno dopo cambia qualcosa nel lavoro del team.

C'è anche una ragione più semplice. Le competenze che servono per lavorare con l'AI sono pratiche: decidere cosa affidare allo strumento, descrivere il compito con il contesto giusto, riconoscere una risposta sbagliata, rispondere del risultato. Le ho descritte in un articolo sulle quattro competenze dell'AI Fluency e non le ripeto qui. Una competenza pratica si impara facendo e si dimostra facendo. Un corso che non fa fare niente può spiegarla bene, ma non la insegna, e alla fine non ha niente da mostrarti.

Gli esercizi: cosa fanno le persone e cosa producono

La prima domanda da fare su un programma è la più concreta: per ogni incontro, che cosa fanno i partecipanti e che cosa resta in mano a loro alla fine. Se la risposta è una lista di temi trattati, non è una risposta.

Per dare un'idea della forma prendo il programma indicativo del percorso per le aziende che propongo. La configurazione di partenza è di quattro incontri, da adattare, e per ognuno è scritto cosa fanno le persone e cosa producono. Nella base comune riconoscono limiti ed errori, formulano richieste e distinguono i dati che possono usare: ne esce una scheda pratica con criteri condivisi. Nell'incontro sugli strumenti provano una richiesta, controllano la risposta, la correggono e discutono il metodo, e il prodotto è un elaborato di esercitazione con un riscontro. Nel terzo lavorano su un'attività scelta con i referenti, con i suoi passaggi, le eccezioni e i controlli, e producono una procedura provata in esercizio insieme alla lista dei controlli. Nell'ultimo definiscono responsabilità, verifica umana e condizioni per fermarsi, e chiudono con un piano di prima applicazione.

Non è l'unico modo di costruire un corso. È un esempio di cosa vuol dire rispondere alla domanda: un verbo per ciò che fanno le persone, un oggetto per ciò che producono. Un programma che sa rispondere così ha già preso molte decisioni, e le ha prese prima dell'aula.

Poi c'è la qualità degli esercizi, e qui conviene guardare quattro caratteristiche.

L'attività è pertinente al ruolo. Un esercizio su un compito che nessuno in sala svolge resta un esercizio di stile. Chi lavora sulle pratiche si esercita su una pratica, chi scrive ai clienti su una comunicazione. Per questo l'attività si sceglie con i referenti e non la decide il docente da solo. Gruppi con ruoli molto diversi spesso vanno separati: un gruppo tecnico può approfondire test, permessi e integrazioni, un gruppo operativo lavora su controllo, eccezioni e uso quotidiano.

Lo strumento è quello che l'azienda può usare davvero. Un laboratorio su uno strumento che l'IT non autorizza, o con account che il giorno dopo non esistono più, insegna qualcosa che non si potrà applicare. Prima dell'aula qualcuno deve aver verificato licenze, accessi e regole interne sui dati. Se nessuno lo ha fatto, il laboratorio rischia di trasformarsi in una sessione di configurazione.

C'è un errore da trovare. L'esercizio che insegna di più non è quello in cui l'AI risponde bene. È quello in cui la risposta contiene un errore plausibile e la persona deve accorgersene, dire perché e correggerlo. Controllare la risposta è la competenza che protegge l'azienda, e si allena solo se l'esercizio la chiede. Il tema ha un pezzo dedicato su come capire quando un output è sbagliato.

Il risultato atteso è scritto prima. Un esercizio senza un risultato atteso non si può valutare, perché qualsiasi risposta sembra accettabile. Se la prova ha criteri comunicati ai partecipanti prima di iniziare, chi la svolge sa su cosa viene giudicato e chi la corregge giudica tutti allo stesso modo.

I segnali opposti si riconoscono in fretta: il laboratorio che in realtà è una dimostrazione del docente, gli stessi esercizi per tutti i ruoli, casi d'uso generici presi da un altro settore, nessuna parola su che cosa i partecipanti consegnano alla fine.

La preparazione: chi mette cosa prima dell'aula

Esercizi così non si improvvisano la mattina del corso. La pertinenza si costruisce prima, e una parte del lavoro tocca all'azienda. Un fornitore che non ti chiede niente prima di iniziare sta preparando un corso uguale per tutti i suoi clienti.

Nel programma che propongo la preparazione è divisa in quattro passaggi, e per ognuno è scritto chi fa cosa. Su obiettivi e gruppi io curo il raccordo con il referente, una breve rilevazione iniziale e la proposta di programma, mentre l'azienda indica l'obiettivo prioritario, i ruoli coinvolti, il livello di partenza e chi segue l'edizione. Sugli strumenti preparo esercizi compatibili con l'ambiente concordato e verifico le condizioni per usarli, e l'azienda mette account e licenze, gli accessi consentiti, le indicazioni dell'IT e le regole interne sui dati. Sui casi didattici adatto i materiali ai ruoli e alle attività scelte, sintetici quando serve, e l'azienda fornisce esempi utilizzabili e autorizzati, con i dati ridotti al necessario. L'ultimo passaggio è il programma vero e proprio: moduli, esercizi, prove e consegne in una versione condivisa, che l'azienda conferma con gruppi, calendario e modalità prima dell'avvio.

La divisione conta più del dettaglio. Se una proposta non dice cosa serve dall'azienda, gli esercizi saranno costruiti su ipotesi, e chi non conosce il lavoro del team tende a ripiegare su casi d'uso generici.

Su un punto conviene essere rigidi: i documenti dell'azienda. Un caso reale in aula è più efficace di uno inventato, ma ci entra solo dopo un'autorizzazione, con i dati ridotti al necessario, un controllo umano e una prova tecnica dello strumento. Se queste condizioni mancano, si usa un caso sintetico costruito sullo stesso schema. Un fornitore che chiede di mandargli i documenti senza nominare nessuna di queste condizioni ti sta già dando un'informazione su come tratta i dati.

E un confine da chiarire subito: l'analisi dei processi aziendali, con interviste e mappatura, è un lavoro diverso dall'aula. Si può fare, ma ha un perimetro e un calendario propri. Un corso che promette di chiudersi con i processi dell'azienda mappati sta mescolando due incarichi, e conviene sapere quale dei due si sta comprando.

La verifica: presenza, conoscenze, pratica e adozione sono domande diverse

È la parte che dovrebbe interessare di più a chi approva il preventivo. Alla fine del corso, come sai cosa ha imparato il team?

Se la proposta risponde con un attestato, magari accompagnato da un questionario di gradimento, ha risposto a un'altra domanda. L'attestato dice che una persona era presente. Il gradimento dice se il corso è piaciuto. Sono informazioni vere, e non dicono se la persona sa fare qualcosa che prima non sapeva fare.

Nella formazione aziendale la distinzione è vecchia. Il modello di Kirkpatrick (consultato il 2026-10-13) separa la reazione dei partecipanti, l'apprendimento, il comportamento nel lavoro e i risultati per l'organizzazione, e avverte che la reazione da sola non basta a dire se il comportamento cambierà. Per un corso AI la traduco in quattro prove distinte, ognuna con la sua domanda.

Presenza. Il registro dice chi c'era. Serve, anche come documentazione di quello che l'azienda ha fatto, ma misura soltanto la partecipazione.

Conoscenze. Un quiz, su carta o digitale, dice se le persone ricordano i concetti: quali dati non si inseriscono, che tipo di errori fa un modello, quando serve una persona. È utile e costa poco. Superarlo non vuol dire saper usare il metodo su un compito vero.

Pratica. Una prova pratica con criteri comunicati prima mostra come una persona formula una richiesta, controlla la risposta e corregge un errore. È la prova più vicina al lavoro, e l'unica che dice qualcosa sulla competenza dimostrata in aula. Una sintesi seria, alla chiusura del percorso, distingue chi l'ha dimostrata da chi era soltanto presente.

Adozione. Se le persone usano davvero il metodo nelle settimane successive, e dove si bloccano, non si vede il giorno dell'ultimo incontro. Si vede dopo, con un seguito concordato: esempi di utilizzo, ostacoli, dubbi, correzioni. Un fornitore che certifica l'adozione alla fine dell'aula sta certificando qualcosa che non ha ancora potuto osservare.

Resta il livello che Kirkpatrick chiama risultati: tempi, errori, qualità del lavoro sul processo. Non appartiene al corso. Richiede un punto di partenza misurato, il tempo di vedere un cambiamento e un processo che nel frattempo non cambi per altri motivi. Per questo nel mio programma non c'è nessuna promessa di risparmio: senza una misura prima, qualsiasi cifra dopo sarebbe un'impressione.

Quando ricevi una proposta, chiedi quali di queste prove raccoglie, con quali strumenti e che cosa ti viene restituito alla fine. Una buona risposta tiene le prove separate. Una risposta debole le fonde in un attestato.

L'attestato e l'articolo 4 dell'AI Act

Molte aziende cercano un corso AI anche pensando all'articolo 4 dell'AI Act, quello sull'alfabetizzazione. Conviene leggere il testo in vigore, perché è cambiato. Dal 27 luglio 2026, con il regolamento (UE) 2026/1744 che ha modificato l'AI Act, l'articolo chiede a fornitori e deployer di adottare misure volte a sostenere lo sviluppo dell'alfabetizzazione del personale e di chi usa i sistemi per loro conto, tenendo conto di conoscenze, esperienza, formazione e contesto d'uso. E aggiunge una frase esplicita: l'obbligo non impone di garantire un livello specifico di alfabetizzazione per nessuna persona.

La pagina di domande e risposte della Commissione europea sull'alfabetizzazione AI (consultata il 2026-10-13, aggiornata al nuovo testo) aggiunge tre precisazioni utili a chi sceglie un corso. L'articolo non comporta un obbligo di misurare le conoscenze dei dipendenti. Non serve un certificato. L'organizzazione può tenere una registrazione interna delle formazioni e delle altre iniziative di orientamento.

Ne vengono due conseguenze pratiche. La prima: un attestato di partecipazione non è un'abilitazione professionale, e la norma non lo richiede. La seconda: quello che l'azienda può mostrare, se qualcuno le chiede cosa ha fatto, è il percorso stesso. Il programma, gli esercizi, le prove raccolte e tenute distinte, il piano di prima applicazione. Un corso che lascia queste tracce è più utile anche come documentazione, oltre che come formazione. Non è un parere legale: per un caso specifico serve chi si occupa di diritto.

Le domande da fare a chi propone un corso

Messe insieme, le parti precedenti diventano poche domande. Le propongo come griglia: si fanno a ogni fornitore nello stesso ordine, e le risposte si mettono in colonna, una per proposta.

Per ogni incontro, che cosa fanno le persone e che cosa producono? Cerca un verbo e un oggetto. «Si parlerà di» non è un'attività.

Su quale attività si esercitano, e chi la sceglie? La risposta buona coinvolge i referenti e distingue i ruoli. Quella debole è un elenco di casi d'uso uguale per tutti i clienti.

Con quali strumenti, e chi verifica prima che siano utilizzabili in azienda? Licenze, accessi e regole sui dati sono un lavoro preparatorio, non un dettaglio del primo giorno.

Con quali materiali? Sintetici o aziendali, e nel secondo caso a quali condizioni: autorizzazione, dati ridotti al necessario, controllo umano, prova tecnica.

Come si verifica l'apprendimento? La risposta deve tenere separate presenza, conoscenze e pratica, e dire con quali criteri si giudica la prova pratica.

Che cosa consegnate alla fine, e a chi? Materiali usati, esercizi, procedure prodotte, sintesi delle verifiche. Chi riceve cosa va scritto nella proposta, non deciso dopo.

Cosa succede dopo l'aula, e cosa non è compreso? Un seguito delimitato ha incontri, durata, canale e un termine. Sviluppo, integrazioni e assistenza continuativa sono un altro incarico, ed è meglio saperlo prima di firmare.

Come leggere le risposte

Le risposte non vanno giudicate dalla sicurezza con cui arrivano. Alcuni segnali aiutano a separare una proposta costruita da una proposta riciclata.

Un preventivo che arriva prima di qualsiasi domanda su persone, obiettivi e strumenti descrive un corso già pronto. Può andare bene per una base comune molto generale, non per i laboratori. Il contrario, un fornitore che sul prezzo risponde «dipende» finché non conosce il team, è normale: il prezzo dipende davvero da persone, formato e obiettivi.

Una promessa di risultati a fine corso, del tipo «il team risparmierà tot ore a settimana», va presa per quello che è: una cifra senza misura. Chi la fa dovrebbe saper dire su quale processo l'ha misurata, con quale punto di partenza e in quale periodo. Se non sa dirlo, è un'impressione. Vale anche per la mia proposta, che infatti non ne contiene.

Un programma senza nessun limite dichiarato è un altro segnale. Ogni percorso serio dice cosa non copre: l'analisi dei processi, lo sviluppo di sistemi, l'assistenza oltre il seguito concordato. Il limite scritto non indebolisce la proposta. È la parte che evita una discussione a lavoro iniziato.

Infine l'indice degli argomenti, che a questo punto torna utile per una cosa sola: controllare che non manchino le basi. Limiti ed errori dei modelli, dati da proteggere, controllo delle risposte, responsabilità di chi usa il risultato. Se manca una di queste, il resto della proposta conta poco.

Cosa un corso non può fare

Anche il corso migliore ha confini, ed è utile conoscerli prima di firmare.

Un corso non fa rispettare le regole. Insegna perché esistono e come si applicano, e alza la probabilità che le persone le seguano. Le regole che non devono mai saltare hanno bisogno d'altro: un controllo che stia sul percorso dell'azione, con qualcuno che ne risponde. Ne ho scritto in un articolo su istruzioni e controlli deterministici, pensato proprio per chi forma un team.

Un corso non garantisce l'adozione. Che le persone usino il metodo dipende anche da cose che stanno fuori dall'aula: strumenti autorizzati, tempo per provarci, un referente a cui chiedere, regole d'uso scritte. La formazione prepara le persone. L'organizzazione decide se possono usare quello che hanno imparato.

Un corso non produce da solo risultati misurabili sul processo. Li produce un processo che cambia, e per vederli bisogna misurarli prima e dopo.

C'è anche un limite di questo articolo, e lo dichiaro. I criteri che propongo vengono dal modo in cui ho progettato il mio programma e dalle fonti che ho citato. Non ho dati che confrontino l'efficacia di corsi costruiti in modi diversi, né dati sulle aziende che scelgono con questa griglia. Sono criteri di metodo, non una misura.

Da dove partire

Prima di chiedere preventivi conviene scrivere quattro cose in una pagina: l'obiettivo prioritario, i ruoli che si vogliono coinvolgere, gli strumenti che l'azienda permette di usare e una o due attività su cui il team potrebbe esercitarsi. Con questa pagina in mano le domande precedenti diventano facili da fare, e le risposte si confrontano senza fatica.

Il programma che propongo è pubblico, con le attività e i prodotti di ogni incontro e il modo in cui si verifica l'apprendimento: si può leggere come termine di paragone anche se poi si sceglie un altro fornitore. Se invece vuoi una proposta per il tuo team, il primo passo è un questionario su persone, obiettivi e strumenti, da cui preparo programma e preventivo.

L'elenco degli argomenti dice di cosa si parlerà. Gli esercizi e la verifica dicono cosa il team saprà fare, e come farai a saperlo.