L’intelligenza artificiale è già entrata nelle aziende. A volte attraverso progetti strutturati, più spesso attraverso strumenti molto più comuni: ChatGPT, Copilot, Gemini, funzionalità integrate nei software gestionali, sistemi HR, applicazioni di marketing, strumenti di analisi documentale o assistenti per lo sviluppo del codice.
Il problema è che l’adozione dell’AI sta spesso correndo più velocemente della capacità delle organizzazioni di governarla.
I dipendenti utilizzano strumenti di intelligenza artificiale, ma non sempre sanno quali informazioni possono inserire, quanto sia affidabile un output, quando sia necessaria una verifica umana o quali sistemi siano effettivamente autorizzati dall’azienda.
A questo primo problema se ne aggiunge un altro, meno evidente ma altrettanto importante: molte organizzazioni non hanno ancora chiarito quale ruolo ricoprono rispetto ai sistemi di AI che utilizzano, sviluppano o commercializzano.
Ed è proprio da qui che dovrebbe partire qualsiasi percorso serio di adeguamento.
AI literacy: il problema non è semplicemente “fare un corso”
L’articolo 4 dell’AI Act disciplina la cosiddetta AI literacy, cioè l’insieme delle competenze necessarie per comprendere e utilizzare consapevolmente i sistemi di intelligenza artificiale.
Dal 2 febbraio 2025 provider e deployer sono tenuti ad adottare misure per sostenere lo sviluppo dell’AI literacy del personale e delle altre persone che operano o utilizzano sistemi di AI per loro conto. Le regole relative alla vigilanza e all’enforcement sono applicabili dal 3 agosto 2026.
Nel luglio 2026 il Digital Omnibus sull’AI ha inoltre modificato la formulazione originaria dell’articolo 4. La norma oggi chiarisce che le organizzazioni devono sostenere lo sviluppo delle competenze, tenendo conto delle conoscenze tecniche, dell’esperienza, della formazione e del contesto di utilizzo, senza essere obbligate a garantire uno specifico livello individuale di AI literacy. Si tratta di una precisazione importante.
L’AI Act non stabilisce che tutte le aziende debbano acquistare lo stesso corso, della stessa durata, e rilasciare lo stesso attestato a tutti i dipendenti. La stessa Commissione europea chiarisce che non esiste un modello “one size fits all”: possono essere appropriati livelli e percorsi differenti e non è richiesta una particolare certificazione. È possibile, invece, conservare internamente evidenza delle attività formative e delle altre iniziative adottate.
La domanda da porsi, quindi, non è semplicemente: “Abbiamo fatto il corso sull’AI?” , ma piuttosto: “Le persone che utilizzano o governano i nostri sistemi di AI hanno competenze adeguate rispetto a ciò che fanno concretamente?”
Prima della formazione viene una domanda: quali sistemi di AI utilizziamo?
Immaginiamo un’azienda nella quale:
- il marketing utilizza ChatGPT per predisporre contenuti;
- l’amministrazione utilizza Copilot per sintetizzare documenti;
- HR utilizza una piattaforma che incorpora funzioni di AI;
- gli sviluppatori utilizzano assistenti per il coding;
- il commerciale utilizza strumenti generativi per preparare offerte;
- un software proprietario integra tramite API un modello sviluppato da un altro fornitore.
Dal punto di vista organizzativo diciamo semplicemente che “l’azienda utilizza l’intelligenza artificiale”. Dal punto di vista dell’AI Act, però, non è sufficiente. Occorre capire quali sistemi vengono utilizzati, per quali finalità, da chi, con quali dati e soprattutto quale posizione assume l’organizzazione rispetto a ciascun sistema. Questo è anche il motivo per cui un buon percorso di AI governance dovrebbe partire da un censimento dei casi d’uso e non dalla scelta del corso di formazione.
Provider o deployer? La differenza è fondamentale
Tra i termini più importanti introdotti dall’AI Act ci sono provider e deployer.
Sembrano definizioni riservate agli avvocati o agli specialisti di compliance. In realtà determinano concretamente quali responsabilità ricadono sull’organizzazione.
Chi è il deployer
Il deployer è, in termini semplificati, il soggetto che utilizza un sistema di intelligenza artificiale sotto la propria autorità, al di fuori di un utilizzo personale e non professionale. È probabilmente la posizione nella quale si trovano oggi moltissime imprese.
Un’azienda che mette a disposizione dei propri dipendenti un sistema di AI generativa sviluppato da un altro soggetto, ad esempio, potrà normalmente assumere il ruolo di deployer rispetto a quell’utilizzo. Lo stesso può accadere quando vengono utilizzati sistemi AI in ambito HR, marketing, customer care, cybersecurity o analisi documentale. Essere deployer non significa essere un semplice utilizzatore privo di responsabilità.
Significa invece dover comprendere come il sistema viene impiegato all’interno della propria organizzazione, con quali persone, quali dati e quali possibili conseguenze.
Questo diventa particolarmente evidente in ambito HR, dove l’impiego dell’AI può incidere direttamente sulle persone e sulle decisioni che le riguardano. È un tema che abbiamo approfondito nell’articolo dedicato a AI nei processi HR nel 2026: la compliance che protegge persone, decisioni e reputazione.
Chi è il provider
Il provider è invece il soggetto che sviluppa o fa sviluppare un sistema di AI o un modello di AI per finalità generali e lo immette sul mercato o lo mette in servizio con il proprio nome o marchio, gratuitamente o a pagamento. È una definizione molto importante per software house, startup e aziende SaaS. Il provider, infatti, non coincide necessariamente con chi ha scritto materialmente ogni riga di codice o addestrato il modello di base. Un’azienda può integrare componenti sviluppate da terzi, costruire attorno a esse un proprio sistema e commercializzarlo con il proprio marchio.
Nel 2026 l’AI Act ha anche introdotto espressamente la figura del downstream provider, cioè un provider di un sistema AI che integra un modello di AI, sia esso sviluppato internamente oppure fornito da un altro soggetto sulla base di rapporti contrattuali.
È un punto particolarmente rilevante per chi sviluppa software.
La stessa azienda può essere deployer e provider
Questo è uno dei passaggi più importanti da comprendere.
Provider e deployer non sono etichette assegnate una volta per tutte all’impresa.
Il ruolo deve essere valutato rispetto allo specifico sistema e allo specifico caso d’uso.
Prendiamo una software house.
Per supportare i propri programmatori utilizza un coding assistant sviluppato da un’altra società: rispetto a quel sistema opera come deployer. La stessa software house integra però un modello linguistico di terzi all’interno della propria piattaforma SaaS e offre ai clienti una nuova funzionalità intelligente sotto il proprio marchio. Rispetto a quel prodotto, il suo ruolo deve essere analizzato diversamente e potrebbe assumere la posizione di provider. È un caso tutt’altro che teorico. Nell’esperienza applicativa, l’inserimento di una componente AI all’interno di un SaaS già esistente può modificare significativamente il perimetro di compliance del prodotto.
La conseguenza è semplice: non basta classificare l’azienda. Occorre classificare le relazioni tra azienda e singoli sistemi di AI.
Non esistono solo provider e deployer
Provider e deployer sono i ruoli più frequenti nella realtà aziendale, ma l’AI Act individua anche altri soggetti.
| Ruolo | Cosa fa, in termini semplici |
|---|---|
| Provider | sviluppa o fa sviluppare un sistema AI e lo commercializza o mette in servizio con il proprio nome o marchio |
| Deployer | utilizza un sistema AI sotto la propria autorità |
| Downstream provider | integra un modello AI, proprio o di terzi, all’interno di un sistema AI che fornisce |
| Importatore | introduce nel mercato UE un sistema AI che porta il nome o marchio di un soggetto stabilito fuori dall’Unione |
| Distributore | rende disponibile sul mercato UE un sistema AI senza essere il provider o l’importatore |
| Rappresentante autorizzato | opera nell’UE sulla base di un mandato conferito da un provider che deve essere rappresentato nell’Unione |
| Fabbricante del prodotto | immette sul mercato o mette in servizio determinati prodotti insieme a un sistema AI sotto il proprio nome o marchio |
Il Regolamento utilizza il termine “operatore” per ricomprendere provider, fabbricante del prodotto, deployer, rappresentante autorizzato, importatore e distributore. Per la maggior parte delle PMI che acquistano e utilizzano strumenti sviluppati da terzi la distinzione principale sarà quella tra deployer e provider. Ma per aziende tecnologiche, produttori, integratori e software house la catena può diventare molto più articolata.
Attenzione: in alcuni casi il ruolo può cambiare
C’è poi un altro elemento che rende pericoloso ragionare per etichette fisse: l’articolo 25 dell’AI Act disciplina le responsabilità lungo la catena del valore e prevede che, per i sistemi ad alto rischio, un distributore, importatore, deployer o altro soggetto possa essere considerato provider in determinate circostanze. Può accadere, ad esempio, quando appone il proprio nome o marchio su un sistema già immesso sul mercato, quando apporta una modifica sostanziale o quando cambia la finalità prevista di un sistema trasformandolo in un sistema ad alto rischio. Tradotto in termini aziendali:
“Non abbiamo sviluppato noi il modello” non significa automaticamente “non siamo provider”.
La qualificazione deve essere verificata sul concreto modello di business e sulle modifiche apportate al sistema.
E allora: chi bisogna formare?
Una volta compresi sistemi, utilizzi e ruoli, anche la formazione diventa molto più semplice da progettare. Non tutti devono sapere le stesse cose. Chi utilizza occasionalmente un assistente generativo per scrivere un testo dovrebbe almeno conoscere:
- limiti e possibilità dello strumento;
- rischio di errori e allucinazioni;
- necessità di verificare gli output;
- informazioni che possono o non possono essere inserite;
- strumenti autorizzati dall’organizzazione.
La Commissione europea cita espressamente il caso dei dipendenti che utilizzano strumenti come ChatGPT per scrivere contenuti o effettuare traduzioni: anche in questi casi devono essere informati sui rischi specifici, come quello delle allucinazioni. Chi lavora in HR avrà invece bisogno di comprendere anche rischi di bias, discriminazione, automazione delle decisioni e trattamento dei dati dei candidati. Chi opera nel procurement dovrà saper riconoscere quando l’acquisto di un software introduce anche una componente di AI e quali verifiche chiedere al fornitore. Gli sviluppatori avranno necessità ancora diverse: documentazione, caratteristiche dei modelli integrati, sicurezza, testing, limiti del sistema, privacy e obblighi collegati al ruolo assunto nella catena AI. Il management, infine, non deve necessariamente conoscere l’architettura tecnica di un modello, ma deve essere in grado di comprendere rischi, responsabilità, criteri di autorizzazione e meccanismi di escalation. E per chi è incaricato della supervisione umana di sistemi ad alto rischio l’AI Act prevede un requisito ulteriore: il deployer deve affidare questa funzione a persone dotate della competenza, formazione, autorità e supporto necessari.
Ecco perché un unico corso identico per tutta l’azienda difficilmente rappresenta il modello migliore.
Il vero rischio: l’AI utilizzata senza regole
La mancanza di competenze non produce soltanto una possibile non conformità all’AI Act, produce problemi molto più immediati. Un dipendente può inserire in un chatbot:
- dati personali di clienti o lavoratori;
- contratti;
- documentazione riservata;
- informazioni commerciali;
- dati tecnici;
- segreti aziendali.
Oppure può utilizzare un output errato senza verificarlo, incorporarlo in una decisione aziendale o inviarlo direttamente a un cliente. Sono comportamenti che possono generare contemporaneamente rischi privacy, cybersecurity, contrattuali, reputazionali e organizzativi. Nel caso dell’AI generativa, abbiamo già analizzato su ServizioDPO alcuni di questi scenari concreti:
Il punto è quindi più ampio della semplice formazione. L’AI literacy è una misura di governo del rischio.
E diventa tanto più importante quanto più l’intelligenza artificiale smette di essere uno strumento passivo e acquisisce capacità di operare autonomamente sui sistemi e sui processi aziendali. Su questo tema abbiamo già affrontato anche il rischio dell’AI autonoma e dell’agentic misalignment.
Formazione e policy devono lavorare insieme
Spiegare ai dipendenti come utilizzare correttamente l’AI è fondamentale, ma senza regole aziendali il percorso resta incompleto. Una formazione efficace dovrebbe essere accompagnata almeno da indicazioni chiare su:
- quali strumenti possono essere utilizzati;
- quali utilizzi richiedono una preventiva autorizzazione;
- quali categorie di dati e documenti non possono essere inserite;
- quando un output deve essere sottoposto a verifica umana;
- chi contattare in caso di dubbi;
- come proporre l’introduzione di un nuovo strumento;
- come segnalare errori, incidenti o utilizzi impropri.
Non è necessario trasformare ogni PMI in una struttura burocratica.Serve però evitare che ogni dipendente stabilisca autonomamente quale AI usare, con quali dati e per fare cosa. Il problema dello shadow AI, cioè dell’utilizzo di sistemi non conosciuti o non governati dall’organizzazione, nasce esattamente qui. Abbiamo già visto, commentando il caso delle funzionalità AI disabilitate sui dispositivi del Parlamento europeo, quanto sia importante conoscere le funzioni AI presenti negli strumenti di lavoro prima che diventino parte invisibile dei processi aziendali.
Il corso da solo non dimostra che l’AI sia governata
Un attestato può dimostrare che una persona ha partecipato a una sessione formativa ma non dimostra necessariamente che:
- l’azienda conosca tutti i sistemi AI effettivamente utilizzati;
- siano stati individuati provider, deployer e altri ruoli;
- il personale conosca gli strumenti autorizzati;
- esistano regole sull’inserimento di informazioni riservate;
- gli output siano verificati prima di produrre effetti;
- nuovi sistemi AI vengano valutati prima di essere introdotti;
- formazione e istruzioni siano aggiornate quando cambiano strumenti e processi.
La Commissione europea non richiede uno specifico certificato per l’articolo 4 e indica espressamente che le organizzazioni possono documentare le iniziative adottate attraverso registrazioni interne delle attività formative e delle altre misure di orientamento. Quello che conta, quindi, è poter ricostruire un percorso coerente.
Da dove partire: una roadmap semplice per le aziende
Per molte organizzazioni non serve iniziare con un progetto enorme. Serve iniziare nell’ordine corretto.
1. Censire i sistemi AI realmente utilizzati
Non soltanto quelli acquistati formalmente dall’IT, ma anche funzionalità integrate nei software e strumenti utilizzati autonomamente dalle diverse funzioni.
2. Descrivere i casi d’uso
Uno stesso strumento può essere utilizzato per attività molto diverse. Generare una bozza di testo marketing non equivale a valutare un candidato o supportare una decisione sanitaria.
3. Identificare il ruolo dell’organizzazione
Per ogni sistema bisogna chiedersi: siamo deployer? Provider? Stiamo integrando un modello in un nostro prodotto? Operiamo anche in un altro ruolo della catena?
4. Valutare rischi e persone coinvolte
Quali dati vengono utilizzati? Su chi può avere effetto il sistema? Quanto è rilevante l’output? Chi lo controlla?
5. Definire livelli di AI literacy differenti
Una base comune può essere utile, ma deve essere integrata da formazione specifica per i ruoli che presentano maggiore esposizione.
6. Formalizzare le regole di utilizzo
Policy, istruzioni operative, elenco degli strumenti autorizzati e processo di valutazione dei nuovi sistemi aiutano a trasformare la conoscenza acquisita in comportamento organizzativo.
7. Conservare evidenze e aggiornare il sistema
Registri della formazione, materiali, istruzioni distribuite, eventuali test e aggiornamenti permettono di dimostrare che l’AI literacy non è stata affrontata come un evento isolato.
AI literacy significa soprattutto consapevolezza organizzativa
L’AI Act non chiede alle imprese di trasformare ogni dipendente in un esperto di intelligenza artificiale, chiede però a provider e deployer di prendere sul serio le competenze delle persone che utilizzano e governano questi sistemi. E questo porta a una conclusione molto concreta. Prima di acquistare un corso standard sull’AI sarebbe opportuno sapere: quali sistemi stiamo utilizzando, per quali attività, con quali rischi, da parte di quali persone e con quale ruolo ai sensi dell’AI Act.
Solo a quel punto è possibile costruire una formazione realmente proporzionata. L’obiettivo non è poter dire “abbiamo formato i dipendenti”. L’obiettivo è poter dimostrare che l’azienda sa dove viene utilizzata l’intelligenza artificiale e che le persone coinvolte sanno come utilizzarla in modo consapevole, sicuro e coerente con il proprio ruolo.
Come può supportarti FinData
Se la tua organizzazione utilizza già sistemi di intelligenza artificiale ma non ha ancora censito i casi d’uso, definito i ruoli o strutturato un percorso di AI literacy, FinData può supportarti nella costruzione di un modello proporzionato alla realtà aziendale: dalla mappatura dei sistemi alla qualificazione dei ruoli, fino a policy, formazione e governance operativa.
La compliance AI non dovrebbe partire dai documenti. Dovrebbe partire da una domanda molto più semplice: dove stiamo già usando l’AI e sappiamo davvero cosa stiamo facendo?