Come documentare le misure di AI literacy in azienda

Un foglio contiene 146 nomi e una colonna verde: corso completato. Nessuna riga dice quali sistemi AI usano quelle persone, cosa fanno con l'output o quale rischio devono riconoscere.

Quel foglio prova una presenza. Non descrive l'AI literacy dell'organizzazione.

Per documentare le misure serve una catena più concreta: sistemi in uso, ruoli coinvolti, contesto, rischi, azioni scelte, prove dell'esecuzione e data della revisione. L'attestato può stare dentro la catena. Da solo non basta.

Il punto normativo va letto sulla fonte aggiornata. Il testo consolidato dell'AI Act al 27 luglio 2026 chiede a provider e deployer di adottare misure a sostegno dello sviluppo dell'AI literacy, tenendo conto di conoscenze tecniche, esperienza, istruzione, formazione, contesto d'uso e persone interessate. La Q&A della Commissione aggiunge tre limiti utili: niente livello individuale universale da garantire, niente certificato obbligatorio e nessuna struttura di governance imposta solo per l'articolo 4.

Per inquadrare obblighi, ruoli e tempi prima di progettare il registro, consulta anche la guida sull'AI Act per le aziende italiane.

Questa guida spiega come costruire un registro operativo. Non certifica la conformità e non sostituisce la valutazione legale del caso.

Parti dagli usi, non dal catalogo corsi

La prima domanda non è chi ha seguito il webinar?. Chiedi quali sistemi AI entrano nel lavoro e chi prende decisioni prima o dopo il loro output.

Per ogni sistema raccogli almeno:

• nome e versione o servizio

• finalità approvata

• provider o deployer, quando rilevante

• funzioni e persone che lo usano

• dati ammessi e vietati

• persone su cui può produrre conseguenze

• output e decisioni collegate

• supervisione ed escalation

• rischi conosciuti

• owner del sistema e della misura formativa

La mappatura delle competenze AI del team fotografa capacità e gap. Qui il punto di partenza è più stretto: collegare ogni uso a persone, conoscenze necessarie e azioni già fatte.

Un account aperto ma non usato non richiede la stessa misura di un assistente che prepara comunicazioni esterne. Un team tecnico che costruisce il sistema e una persona che ne legge il risultato hanno compiti diversi. Metterli nello stesso corso rende più semplice il calendario e più debole la prova.

Collega sistemi, ruoli e contesto

La Commissione suggerisce un approccio che considera ruolo dell'organizzazione, rischio, conoscenze delle persone, contesto e finalità. Trasformalo in una matrice leggibile.

Le righe sono esempi, non un elenco obbligatorio. Un sistema ad alto rischio o un uso regolato può richiedere misure ulteriori e competenze specifiche.

Evita categorie vaghe come utente base e utente avanzato se non cambiano il compito. Sa usare ChatGPT non dice se la persona riconosce una fonte scaduta, protegge un dato o sa quando fermarsi.

Definisci un risultato osservabile per ogni gruppo

Una misura diventa verificabile quando dichiara cosa dovrebbe saper fare la persona nel proprio contesto.

Comprendere i rischi dell'AI è troppo largo. Una formulazione osservabile può essere:

Preparare una bozza da tre fonti approvate, collegare ogni claim alla fonte e passare il caso al knowledge owner quando le fonti sono in conflitto.

Il risultato contiene:

1. ruolo e compito

2. sistema e input ammessi

3. output richiesto

4. limite da riconoscere

5. azione in caso di dubbio

6. livello di autonomia previsto

DigComp 3.0 può aiutare a descrivere conoscenze, capacità e progressione. Resta un riferimento. Non trasforma una rubrica interna in certificazione né decide quali rischi appartengono al tuo sistema.

Il test d'ingresso per un corso AI aziendale serve a calibrare punto di partenza e supporto. Non deve diventare una classifica nominativa priva di finalità.

Scegli misure diverse per bisogni diversi

La Q&A della Commissione non impone un unico formato. Leggere le istruzioni può essere insufficiente in molti casi, ma non ogni gap richiede un corso di otto ore.

Una misura può essere:

• onboarding sul sistema e sui dati ammessi

• guida breve dentro il processo

• laboratorio su casi reali autorizzati

• simulazione di errore ed escalation

• office hours su casi dubbi

• review periodica di output campionati

• formazione per manager e supervisori

• aggiornamento dopo una nuova versione o finalità

Collega il formato al comportamento atteso. Se il problema è riconoscere una citazione falsa, una presentazione frontale non basta. Serve una prova. Se il problema è sapere dove trovare la policy, una guida dentro il flusso può funzionare meglio di un corso.

Il repository europeo raccoglie più di 40 pratiche, dall'e-learning ai bootcamp e alle collaborazioni con università. La Commissione precisa che copiarne una non dà automaticamente presunzione di conformità. Usale come esempi, poi torna al tuo contesto.

Costruisci un registro minimo

Il registro deve permettere a una persona esterna al progetto di ricostruire la scelta senza aprire venti cartelle.

measure_id: AIL-2026-017
ai_system_id: assistant-procedure
roles:
  - customer-operations
use_context: search-and-draft
affected_groups:
  - customers
risk_topics:
  - stale-source
  - unsupported-claim
learning_outcome: cite-approved-source-and-escalate-conflict
action_type: scenario-workshop
materials_version: v3
delivered_at: 2026-09-10
evidence_refs:
  - attendance-record
  - scenario-scorecard-aggregate
review_due_at: 2026-11-10
owner: learning-and-development
limitations: no-individual-certification

Il record lega la misura al sistema e al ruolo. Conserva anche versione dei materiali, data, owner e limite. Se cambia il sistema, puoi vedere quali misure vanno riesaminate.

Completato non basta come stato. Usa esiti che dicano cosa manca: planned, delivered, evidence_pending, review_due, superseded, closed. Un corso sostituito non va cancellato. Serve a capire quale versione ha ricevuto il gruppo.

Conserva prove che si possano riesaminare

La Commissione dice che le organizzazioni possono tenere un registro interno di training e altre iniziative di guida. La prova va proporzionata alla misura.

Può includere:

• programma e materiali versionati

• destinatari per ruolo o gruppo

• data e modalità

• presenza, quando serve

• esercizio o simulazione

• rubrica e risultato aggregato

• domande emerse e correzioni

• guida pubblicata nel processo

• ricevuta di lettura per procedure critiche

• review su campioni autorizzati

Non raccogliere dati personali solo perché il foglio lo permette. Se basta sapere che un gruppo ha svolto la simulazione e quali errori ricorrono, evita una graduatoria individuale. Finalità, accessi e conservazione vanno concordati con le funzioni competenti.

La prova più forte non è sempre il quiz. Un compito osservabile può mostrare se la persona usa la fonte corretta, riconosce il limite e passa il caso all'owner. Il controllo del trasferimento della formazione AI guarda ciò che succede dopo il corso, con una finestra coerente col compito.

Versiona materiali e decisioni

L'AI cambia. Anche uso, policy e rischio cambiano. Il registro deve indicare quale versione era valida quando la misura è stata svolta.

Attiva una review quando cambia almeno uno di questi elementi:

• sistema o modello

• tool disponibili

• finalità d'uso

• dati trattati

• persone interessate

• output o decisione

• rischio conosciuto

• istruzioni del provider

• norma o guida applicabile

Non rifare tutto a ogni release minore. Valuta il delta. Un nuovo pulsante può richiedere una nota. Un agent che ottiene accesso a un gestionale cambia il profilo del compito e merita una nuova prova.

La review chiude con una decisione: misura ancora adeguata, aggiornamento mirato, nuova attività o stop dell'uso finché il gap non viene coperto.

Separa documentazione e sorveglianza

Documentare le misure non significa misurare ogni persona in modo continuo. La Q&A della Commissione dice che l'articolo 4 non impone di misurare la conoscenza AI dei dipendenti né di garantire un livello individuale specifico.

Un registro prudente separa:

• inventario dei sistemi

• decisione sulla misura

• prova che la misura è avvenuta

• verifica del processo

• dati individuali strettamente necessari

Se una valutazione influenza ruolo, performance o rapporto di lavoro, serve un perimetro definito con HR, privacy, rappresentanze e funzioni competenti. Non nascondere una valutazione del personale dentro un progetto di AI literacy.

Esempio fittizio

Un'azienda usa tre sistemi: un assistente per procedure interne, un generatore di copy e un classificatore di richieste. Il vecchio registro contiene una sola voce: webinar introduttivo, 92 partecipanti.

Il team ricostruisce gli usi. L'assistente coinvolge 34 persone e richiede verifica di fonte e freschezza. Il generatore di copy coinvolge 11 persone e richiede claim tracciati e review. Il classificatore coinvolge 6 operatori e un process owner, con una procedura di escalation per casi fuori tassonomia.

Nascono tre misure. Un laboratorio documentale, una prova di copy su fonti approvate e una simulazione sul classificatore. Il webinar resta nel registro come base comune, ma non pretende più di coprire tutti i compiti.

Dopo due mesi, la review trova che il classificatore ha una nuova categoria e che il runbook non la descrive. Il team aggiorna guida e scenario solo per quel gruppo. Nessun attestato viene revocato. La misura cambia insieme al sistema.

Think, Build, Enable applicato all'AI literacy

Think: inventaria sistemi, ruoli, contesto, persone interessate e rischi. Scrivi il comportamento atteso.

Build: crea matrice, misure differenziate, registro, materiali versionati e prove proporzionate.

Enable: assegna owner e review, prova i limiti sul lavoro e aggiorna la misura quando cambia l'uso.

Porta sistemi, ruoli e casi d'uso alla formazione team aziendale AI di MAIKER HUB. Il risultato utile non è una colonna tutta verde. È sapere chi deve saper fare cosa, con quale sistema e quale prova.