Come costruire un onboarding AI in azienda
Alle 09:10 del primo giorno arriva l'invito al tool. Alle 09:18 la persona apre una chat vuota. Se il percorso finisce qui, non hai fatto onboarding. Hai distribuito un account.
Un onboarding AI utile porta una persona a usare 1 workflow nel proprio ruolo, controllarne l'output e fermarsi quando manca una prova. Il traguardo non è conoscere tutte le funzioni di ChatGPT, Claude o Gemini. È saper chiudere un compito ammesso senza scaricare il rischio sul collega che arriva dopo.
Il formato che proponiamo si chiama patente del processo: 4 checkpoint, 1 caso chiuso, 1 prova osservata. Il numero è una scelta di progetto, non uno standard universale.
Definisci il traguardo per ruolo
Parti da una frase che si può osservare.
La persona prepara una sintesi di 6 fonti approvate, collega ogni fatto alla fonte e manda in escalation le contraddizioni.
Qui ci sono un compito, un perimetro e uno stop. Puoi vedere se il lavoro è stato fatto. Una frase come usa bene l'AI non ti permette nessuna verifica.
DigComp 3.0 organizza i learning outcome per competenza, livello e tipo: conoscenza, abilità o atteggiamento. Integra la competenza AI nelle 21 competenze del framework. Non impone un onboarding aziendale in 4 passaggi. Ti dà però una distinzione utile per scrivere il traguardo.
Per lo stesso workflow puoi fissare 3 esiti:
| Tipo | Esito osservabile | Prova |
|---|---|---|
| Conoscenza | riconosce le fonti ammesse | seleziona soltanto i documenti approvati |
| Abilità | produce la sintesi nel formato richiesto | consegna un output confrontabile |
| Atteggiamento | non nasconde ciò che manca | usa il campo da verificare e coinvolge l'owner |
Una scelta netta: l'onboarding deve essere stretto. Se provi a coprire scrittura, immagini, analisi dati, automazioni e agent nello stesso giro, misuri la memoria del corso. Non il lavoro.
La mappatura delle competenze AI serve a scegliere il punto di partenza. Qui lo scopo è diverso: portare una persona fino a un uso controllato.
Checkpoint 1: accessi e confini
Il primo checkpoint dura finché la persona sa cosa può entrare nel tool, cosa deve restare fuori e chi decide le eccezioni.
Prepara una scheda di 1 pagina con questi campi:
| Campo | Esempio di progetto |
|---|---|
| Tool ammesso | account aziendale approvato |
| Compito ammesso | prima bozza di sintesi interna |
| Fonti ammesse | cartella didattica F01-F06 |
| Dati vietati | credenziali, PII, prezzi riservati |
| Output vietati | decisione finale, invio automatico |
| Owner | responsabile del processo |
| Escalation | canale e tempo di risposta |
| Evidenza | output, fonti usate e correzioni |
Il NIST AI RMF lega la formazione alle responsabilità che le persone devono svolgere. Chiede anche ruoli chiari per la supervisione delle configurazioni uomo-AI. Tradotto nel lavoro: non basta dire controlla sempre. Devi scrivere chi controlla, cosa controlla e cosa succede quando il controllo fallisce.
Fai una prova a libro aperto. Mostra 8 elementi e chiedi dove vanno: ammesso, vietato o da chiedere. Se le risposte dipendono dall'umore del manager, il confine non è pronto.
Qui tocca fermarsi. Se manca una regola sui dati o nessuno possiede l'escalation, non compensare con un prompt più lungo. Prima chiudi il perimetro, poi apri il tool.
La consulenza su roadmap e governance AI riguarda questo pezzo: ruoli, priorità e confini prima dell'uso.
Checkpoint 2: un caso chiuso
Il secondo checkpoint usa un lavoro già concluso. Hai input, risultato corretto e decisioni prese. Puoi quindi confrontare la bozza senza rischiare un'azione reale.
Costruisci il caso con 5 parti:
- materiali ripuliti e numerati,
- consegna con formato e limite,
- risultato di riferimento,
- errori inseriti di proposito,
- condizioni di stop.
Esempio ipotetico: 6 note di progetto fittizie, 2 date in conflitto, 1 link scaduto e 1 attività senza owner. La persona deve produrre 5 decisioni confermate e 3 punti aperti. I numeri descrivono l'esercizio, non un caso cliente.
La prima bozza del modello non è il risultato. È materiale da controllare.
Consegna possibile:
Prepara una sintesi operativa usando soltanto F01-F06.
Per ogni decisione indica l'ID fonte.
Se 2 fonti divergono, mostra entrambe.
Se manca un owner, scrivi ESCALATION.
Non completare date o nomi mancanti.
Chiudi con i controlli eseguiti dalla persona.
Il caso chiuso toglie una scusa frequente: non potevo sapere se era giusto. Il risultato era già noto. Resta da vedere se la persona sa trovarlo e difenderlo.
Checkpoint 3: controllo ed escalation
Al terzo checkpoint separi 3 oggetti che spesso finiscono nello stesso file:
- la prima bozza del modello,
- le correzioni della persona,
- la versione che può uscire dal workflow.
Per ogni correzione registra tipo, evidenza e decisione. Ho cambiato la frase non basta. Scrivi data corretta con F04 oppure owner lasciato aperto perché nessuna fonte lo indica.
Usa 4 esiti semplici:
| Esito | Significato | Azione |
|---|---|---|
| passa | prova presente e formato rispettato | prosegui |
| correggi | difetto locale con fonte disponibile | correggi e registra |
| chiedi | serve un owner o una regola | escalation |
| ferma | dato vietato o conseguenza non ammessa | interrompi |
Il NIST AI RMF include testing documentato e processi di verifica ripetibili. Non serve trasformare l'onboarding in un audit tecnico. Serve lasciare una traccia sufficiente per capire perché l'output è passato.
La capacità più importante qui non è trovare la parola migliore. È riconoscere il momento in cui il workflow non ha più diritto di procedere.
Checkpoint 4: prova osservata
La prova finale usa lo stesso tipo di compito, ma un set di materiali diverso. Il manager osserva il processo. Non interviene al primo errore.
Valuta 6 dimensioni, da 0 a 2:
| Dimensione | 0 | 1 | 2 |
|---|---|---|---|
| Perimetro | usa dati vietati | chiede tardi | rispetta i confini |
| Fonti | nessuna traccia | traccia parziale | ogni fatto ha prova |
| Istruzioni | cambia il compito | perde 1 vincolo | rispetta formato e limite |
| Controllo | accetta la bozza | trova alcuni difetti | corregge quelli critici |
| Escalation | decide da solo | coinvolge l'owner tardi | si ferma nel punto giusto |
| Evidenza | non salva nulla | salva il finale | conserva bozza, correzioni e decisione |
Il massimo è 12. La soglia non certifica una competenza generale. Decide soltanto se quella persona può eseguire quel workflow con quei confini.
Puoi usare una regola di progetto: 10/12, nessuno 0 su perimetro o escalation. Se il rischio del processo è alto, la soglia può non bastare. Va decisa dall'owner, non copiata da questo articolo.
Una scheda di onboarding in 10 righe
La scheda finale deve stare accanto al lavoro, non in una presentazione vista 3 settimane prima.
Ruolo:
Workflow:
Output ammesso:
Fonti ammesse:
Dati vietati:
Reviewer:
Condizioni di stop:
Evidenza da salvare:
Prova assegnata:
Stato: non avviato / assistito / autonomo / sospeso
Aggiorna la scheda quando cambia il tool, il processo o la policy. Una patente del processo vecchia non protegge il lavoro nuovo.
Misura il passaggio al lavoro
Non contare soltanto presenze e completamenti. Osserva il comportamento sul workflow.
Le misure utili sono concrete:
- prove completate con tutte le fonti,
- errori critici trovati prima dell'uso,
- escalation riconosciute,
- override spiegati,
- output fermati per dati o conseguenze non ammessi,
- tempo speso nella verifica.
Confronta sessioni soltanto quando compito, materiali e criteri restano simili. La misura della formazione AI tratta il passaggio successivo: capire se il comportamento regge nel lavoro su una finestra più lunga.
Il tempo più basso non vince. Una bozza in 3 minuti che richiede 20 minuti di correzione non è un vantaggio.
Gli errori che lasciano un account al posto di un metodo
- tour di tutte le funzioni del tool,
- 1 prompt uguale per ruoli diversi,
- dati reali usati perché l'esercizio sembra poco concreto,
- nessun risultato di riferimento,
- reviewer nominato ma senza tempo o canale,
- prova valutata sul testo finale e non sulle correzioni,
- superamento implicito dopo aver seguito il corso,
- assenza di una data di revisione.
Il corso può essere ottimo e l'onboarding può fallire lo stesso. Succede quando nessuno collega ciò che è stato visto al processo che deve girare lunedì mattina.
Il primo onboarding da costruire
Scegli 1 ruolo. Prendi 1 processo concluso questa settimana. Scrivi ciò che la persona deve saper fare e il punto in cui deve fermarsi. Poi prepara il caso chiuso.
La formazione AI per il team di MAIKER HUB parte dai processi. Porta il ruolo, i confini già decisi e 1 output che oggi richiede troppo controllo. Costruiamo la patente del processo, compresa la prova che può bocciarla.
Domande frequenti
Quanto deve durare un onboarding AI?
Dipende dal rischio e dalla frequenza del compito. Un percorso di 30 giorni con 4 checkpoint è un formato di progetto, non una regola. Un workflow raro o ad alta conseguenza può richiedere più osservazioni.
Serve conoscere tutti i tool?
No. Serve saper usare il tool approvato per il compito assegnato, compresi limiti e stop. Il catalogo si può aggiornare. Il criterio deve già esserci.
Posso usare documenti aziendali veri?
Solo nel perimetro approvato dall'organizzazione. Per la prima prova, il default sicuro è un caso chiuso con dati fittizi o ripuliti.
Quando una persona è autonoma?
Quando completa il workflow, verifica le fonti, registra le correzioni e coinvolge l'owner nel punto previsto. Autonomia non significa assenza di supervisione.
Cosa succede se il tool cambia?
Riapri almeno accessi, limiti, prova e condizioni di stop. Non dare per valido un risultato ottenuto su un sistema diverso.