# ZeroFive.AI, testo integrale degli articoli > Indice esteso per i motori AI. Indice sintetico: https://zerofive.ai/llms.txt --- # Nessun agente in produzione senza un owner con nome e cognome URL: https://zerofive.ai/blog/ai-governance/agenti-ai-owner-nominativo-produzione Data: 2026-10-09 Abstract: Inventario degli agenti, poteri reali dell'owner, identità dedicate e permessi minimi. Quando un agente ricade in Allegato III. **In sintesi.** La regola più efficace sugli agenti AI è anche la più semplice da verificare: nessun agente va in produzione senza una persona con nome e cognome che ne risponde. È una regola organizzativa, costa poco, e separa le aziende che sanno cosa gira in casa da quelle che lo scopriranno quando qualcosa andrà storto. Quasi tre quarti delle organizzazioni prevede di adottare agenti entro due anni, e circa una su cinque dichiara un modello di governance maturo per gestirli. Un agente è diverso da un modello che risponde a una domanda, perché pianifica, usa strumenti, scrive su sistemi aziendali e produce effetti fuori dalla conversazione, dall'apertura di un ticket alla modifica di un record. Il rischio si sposta dall'output all'azione, e un'azione sbagliata non si corregge rileggendo la risposta. ## Perché l'ownership viene saltata Gli agenti nascono quasi sempre fuori dai processi formali. Qualcuno attiva una funzione dentro una piattaforma già in uso, un team costruisce un'automazione interna, un fornitore propone un modulo che esegue operazioni al posto di un operatore. Nessuno di questi passaggi somiglia all'acquisto di un software, quindi nessuno attiva la procedura che prevede un responsabile. Il risultato è che in molte organizzazioni gli agenti attivi sono più numerosi di quelli censiti, la domanda su chi li ha autorizzati non trova risposta, e quando qualcosa va storto la ricostruzione parte dalle persone invece che dai registri. Vale la stessa dinamica che abbiamo descritto per la [shadow AI](/blog/approfondimenti/shadow-ai-azienda-rischi-policy), con una differenza: qui il sistema agisce. ## Cosa significa essere owner Il nome sul documento serve a poco se non porta con sé poteri concreti. Un owner che non può fermare l'agente è una firma di comodo. | Prerogativa | Perché serve | |---|---| | Fermare l'agente senza passare da altri | Un comportamento anomalo va interrotto in minuti, non in giorni | | Modificare i limiti di autonomia | Le soglie si tarano con l'uso, non si decidono una volta sola | | Accedere ai log delle azioni | Senza tracciamento non si ricostruisce cosa è successo | | Approvare l'estensione a nuovi sistemi | Un agente che guadagna accessi cambia profilo di rischio | | Rispondere del risultato davanti alla direzione | È la parte che rende la responsabilità reale | L'owner è una figura di business. Chi risponde di un agente che gestisce i solleciti di pagamento sta nella funzione amministrativa, con il supporto dell'IT sulla parte tecnica, perché le conseguenze di un sollecito sbagliato ricadono sul rapporto con il cliente e non sull'infrastruttura. ## L'inventario degli agenti Serve un elenco separato da quello dei sistemi AI generici, perché le informazioni da tenere sono diverse. Per ogni agente vanno registrati scopo, owner, sistemi su cui può scrivere, dati a cui accede, limiti di autonomia, modalità di arresto, ambiente in cui gira. La parte che viene dimenticata più spesso è l'elenco dei sistemi su cui l'agente può agire, che è anche quella che distingue i profili di rischio: un assistente che legge documenti espone informazioni, mentre un agente che modifica un ordine o invia una comunicazione a un cliente produce effetti operativi e contrattuali difficili da annullare. ## Identità e permessi Un agente che usa le credenziali di una persona rende impossibile distinguere le azioni dell'uno da quelle dell'altra. È il problema di fondo che rende inutile buona parte del logging: i registri esistono e attribuiscono tutto a un account umano che in quel momento stava facendo altro. La direzione giusta è l'identità dedicata per ogni agente, con permessi minimi e separati per ambiente, e richiede lavoro sull'infrastruttura di identità che va messo nel budget del progetto invece di emergere a metà strada. Raramente compare nelle stime iniziali. ## Quando l'agente ricade in Allegato III Se un agente opera dentro un caso d'uso ad alto rischio, gli obblighi sull'alto rischio si applicano a quel caso d'uso. Un agente che smista candidature sta nella gestione del personale, e la classificazione non cambia perché il sistema si chiama assistente. C'è un secondo passaggio da conoscere. Un deployer che usa un agente in modo diverso da quanto previsto dal fornitore può diventare fornitore di un sistema ad alto rischio, con gli obblighi che ne derivano. La distinzione tra uso previsto e uso effettivo va documentata, e il posto dove farlo è il [registro dei sistemi](/blog/compliance/registro-sistemi-ai-come-costruirlo). ## Da dove partire Il punto di ingresso è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), esteso agli agenti con i campi aggiuntivi descritti sopra. I criteri per capire se un progetto agentico ha senso sono in [PoC con agenti AI](/blog/strategia/poc-agenti-ai-come-farle-funzionare), mentre l'inquadramento generale è in [agenti AI in azienda](/blog/approfondimenti/agenti-ai-azienda). Per capire quali agenti sono attivi nella tua organizzazione e chi ne risponde puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # AI Act: cosa succede davvero il 2 dicembre 2027 URL: https://zerofive.ai/blog/compliance/ai-act-2-dicembre-2027-quattordici-mesi Data: 2026-10-07 Abstract: Il rinvio degli obblighi sull'alto rischio non è una pausa. Il calendario aggiornato e il lavoro che serve davvero nei quattordici mesi che restano. **In sintesi.** Il Digital Omnibus ha spostato gli obblighi sui sistemi ad alto rischio dell'Allegato III dal 2 agosto 2026 al 2 dicembre 2027, e quelli dei sistemi incorporati in prodotti regolamentati al 2 agosto 2028. La lettura diffusa è che ci sia tempo. Contando il lavoro reale che serve per arrivare pronti, quattordici mesi sono una scadenza stretta per un'organizzazione che oggi non sa quali sistemi AI ha in produzione. Il Regolamento UE 2026/1744 è entrato in vigore il 27 luglio 2026, a pochi giorni dalla scadenza che avrebbe reso applicabili gli obblighi sull'alto rischio. Il risultato pratico è che molte aziende hanno interrotto il lavoro appena iniziato, interpretando il rinvio come un via libera a rimandare. È la lettura che costa di più. ## Cosa è stato rinviato e cosa no Il rinvio riguarda un perimetro preciso. Restano applicabili le pratiche vietate e l'obbligo di alfabetizzazione dell'articolo 4, in vigore da febbraio 2025, gli obblighi per i fornitori di modelli di uso generale da agosto 2025, e dal 2 agosto 2026 l'applicazione generale del regolamento con gli obblighi di trasparenza dell'articolo 50, le autorità nazionali e il regime sanzionatorio. | Cosa | Da quando | |---|---| | Pratiche vietate e obbligo di alfabetizzazione | 2 febbraio 2025 | | Obblighi per i fornitori di modelli di uso generale | 2 agosto 2025 | | Applicazione generale, trasparenza dell'articolo 50, sanzioni | 2 agosto 2026 | | Sistemi ad alto rischio autonomi dell'Allegato III | 2 dicembre 2027 | | Sistemi ad alto rischio incorporati in prodotti regolamentati | 2 agosto 2028 | | Sistemi ad alto rischio destinati alle autorità pubbliche | 2 agosto 2030 | Un chatbot che non dichiara di essere un sistema automatico è già fuori norma oggi, e un software di selezione del personale resta soggetto al GDPR e al diritto del lavoro, con tutti gli obblighi che ne discendono, indipendentemente dalla data in cui scatteranno quelli dell'AI Act. ## Quattordici mesi, contati sul serio La distanza tra oggi e dicembre 2027 sembra ampia finché non si mette in fila il lavoro. Questa è la sequenza che vediamo nei progetti reali, con le durate che osserviamo in organizzazioni di media dimensione. | Fase | Durata tipica | |---|---| | Inventario dei sistemi AI, inclusi i moduli dentro software già in uso | 6-10 settimane | | Classificazione per rischio e identificazione del ruolo, fornitore o deployer | 4-6 settimane | | Gap analysis sui sistemi che risultano ad alto rischio | 4-8 settimane | | Rinegoziazione contrattuale con i fornitori su documentazione e log | 3-6 mesi | | Documentazione, valutazione dei rischi, sorveglianza umana | 4-6 mesi | | Formazione per ruolo con evidenza individuale | continuativa | | Verifica interna prima della scadenza | 2 mesi | Le fasi non sono tutte in sequenza, ma due di queste dipendono da soggetti esterni e non si comprimono. La rinegoziazione con un fornitore che non ha mai prodotto la documentazione richiesta richiede il tempo del suo ciclo di rilascio, non quello del vostro progetto. ## Il lavoro che non parte dal legale L'errore ricorrente è affidare la preparazione alla funzione legale o compliance e aspettare il risultato. Quelle funzioni sanno leggere il regolamento, non sanno quali sistemi sono accesi in azienda, e non possono saperlo, perché l'informazione è distribuita tra chi ha firmato i contratti, chi ha attivato i moduli e chi li usa tutti i giorni. Il primo passo è tecnico e organizzativo insieme. Serve una ricognizione che parta dai contratti software attivi e dai gestionali in uso, e che chieda a ogni funzione quali moduli predittivi sono stati attivati negli ultimi due anni. Nei progetti che abbiamo seguito, tra un terzo e la metà dei sistemi rilevanti non era noto a chi si occupava di compliance. Il secondo passo riguarda il ruolo. Un'azienda che usa un modello di un fornitore è deployer, con obblighi propri, e può diventare fornitore se modifica il sistema in modo sostanziale, lo rimarchia o lo impiega per una finalità diversa da quella dichiarata dal fornitore, e in quel caso la quantità di lavoro richiesta cambia di ordine di grandezza. La distinzione va fatta prima di costruire qualunque piano. ## Chi arriva tardi, e come si riconosce Arrivano tardi le organizzazioni che aspettano gli standard tecnici armonizzati per cominciare, perché quegli standard servono a dimostrare la conformità in modo presunto, mentre sapere quali sistemi avete, chi li ha autorizzati e che cosa fanno è un lavoro che non dipende da nessuno standard e si può fare adesso. Arriva tardi anche chi tratta la scadenza come un progetto una tantum. I sistemi ad alto rischio richiedono monitoraggio successivo alla messa in servizio, aggiornamento della documentazione e registrazione degli incidenti, quindi un'organizzazione che costruisce tutto nei tre mesi precedenti la scadenza arriva al traguardo con i documenti in ordine e senza il presidio che serve dal giorno dopo. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), seguito dalla [classificazione per rischio](/blog/compliance/classificazione-sistemi-ai-rischio) e dal [registro dei sistemi](/blog/compliance/registro-sistemi-ai-come-costruirlo). Il dettaglio di cosa è già vincolante dal 2 agosto 2026 è in [AI Act: cosa è vincolante](/blog/compliance/ai-act-2-agosto-2026-cosa-e-vincolante), mentre il contenuto del pacchetto che ha spostato le date è in [Digital Omnibus](/blog/compliance/digital-omnibus-regolamento-2026-1744). Per misurare la distanza tra la vostra situazione e quello che servirà a dicembre 2027 c'è la pagina [AI Rating](/servizi/ai-rating). Per una valutazione puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # Collegare l'AI ai dati aziendali: perché serve un AI Company OS URL: https://zerofive.ai/blog/strategia/collegare-ai-dati-aziendali-ai-company-os Data: 2026-10-03 Abstract: Collegare ChatGPT, Claude o Copilot ai dati aziendali in sicurezza: MCP, ontologia, classificazione dei dati e approvazione umana in un AI Company OS. **In sintesi.** Collegare ChatGPT, Claude o Copilot alla posta, a Drive e al CRM oggi richiede pochi minuti, e quasi tutte le aziende lo stanno provando. Il risultato però dipende da com'è organizzata la conoscenza che il modello legge: senza tipi e regole di approvazione l'assistente produce risposte plausibili di cui nessuno conosce l'origine. Un AI Company OS è lo strato che mette ordine prima del modello, e decide quali dati vanno a quale AI e con quali permessi. Nell'ultimo anno i connettori hanno cambiato il modo in cui le aziende usano l'AI generativa. Con il Model Context Protocol (MCP), lo standard aperto pubblicato da Anthropic a novembre 2024 e adottato nei mesi successivi da OpenAI, Google e Microsoft, un assistente può leggere una casella di posta, aprire un documento, consultare un calendario o interrogare un gestionale senza che qualcuno copi e incolli niente. La parte tecnica, che fino a poco tempo fa richiedeva un progetto di integrazione, è diventata un'impostazione da attivare. Questo ha spostato il problema altrove, e molte aziende se ne accorgono dopo qualche settimana di uso. ## La conoscenza aziendale è dispersa in troppi posti In quasi tutte le organizzazioni la conoscenza di un progetto vive in sette o otto posti diversi: le registrazioni delle riunioni, la posta, una cartella su Drive e un'altra su Dropbox, il calendario, il CRM, i canali di Slack o di Teams, le schede di Jira o di Asana, le note personali. Ciascuno funziona bene da solo, e nessuno sa dell'esistenza degli altri. ![La conoscenza che oggi si perde tra le fonti aziendali](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/03-fonti-it.webp) A queste fonti se n'è aggiunta una che fino a due anni fa non esisteva, le conversazioni che ogni persona ha con il proprio assistente AI mentre prepara una proposta o analizza un problema. Lì finisce spesso il ragionamento più utile della giornata, e sparisce quando si chiude la finestra, perché nessun sistema aziendale lo raccoglie. ## Cosa succede quando un LLM legge tutto La reazione più diffusa è collegare il modello a tutte le fonti e aspettarsi che dal collegamento nasca una visione d'insieme. Succede quasi sempre il contrario. Il modello ricostruisce da solo il significato delle informazioni, ogni volta in modo leggermente diverso, e due risposte alla stessa domanda a una settimana di distanza non coincidono. I casi tipici sono tre. Un cliente compare nel CRM con un decisore e in un verbale di riunione con un altro, e l'assistente sceglie a caso quale citare. Una decisione presa in call contraddice un documento di qualche giorno prima, e il riassunto le fonde come se dicessero la stessa cosa. Un'informazione riservata, come un margine o un dato personale, finisce in una risposta letta da chi non avrebbe dovuto vederla, perché il connettore usava un'utenza con accesso a tutto. Nessuno di questi errori dipende dalla qualità del modello. Un modello più capace produce risposte più convincenti sugli stessi frammenti, e rende l'errore più difficile da vedere. ## Cos'è un AI Company OS Chiamiamo AI Company OS lo spazio di lavoro in cui la conoscenza dell'azienda diventa leggibile dai modelli e governata dalle persone. Ogni informazione, una nota di riunione, un task, un documento, un referente, diventa un oggetto con un tipo, un autore, una data e un posto nel progetto. I modelli lo leggono con i permessi reali di chi li usa, e niente entra nella memoria comune senza che una persona l'abbia approvato. Il sistema si progetta in sei livelli: centralizzazione, ontologia, grafo, connettori e modelli, skill, governo. Il dettaglio del metodo e della piattaforma con cui lo realizziamo è nella pagina del servizio [AI Company OS](/servizi/ai-company-os); qui conviene fermarsi sui tre punti che cambiano di più il modo di lavorare. ![La dashboard del Workspace, la piattaforma che usiamo sui nostri progetti e mettiamo a disposizione delle aziende](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/12-workspace-dashboard.webp) ## Il significato viene prima dei dati L'ontologia è il punto in cui un'azienda decide cosa significano le sue informazioni, prima che lo decida un modello al suo posto. Si stabilisce che un appunto non pesa quanto una decisione, che un rischio genera attenzione, che i tag hanno un vocabolario controllato e non nascono tre varianti dello stesso nome. La parte più delicata riguarda le contraddizioni. Quando due fonti affermano cose diverse sullo stesso punto, un sistema ingenuo tiene l'ultima o le fonde in un riassunto. In un AI Company OS la divergenza diventa un collegamento esplicito, apre una verifica assegnata a una persona e si chiude con una nota che dichiara quale fonte è stata confermata e quale superata, lasciando intatti gli originali. ![Quando due fonti non tornano: divergenza, verifica e nota di conoscenza](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/05-collisioni-it.webp) ## Quale AI per quali dati Se la conoscenza è strutturata, la scelta del modello diventa una decisione di costo e di riservatezza. Il cuore del sistema è un server di accesso, oggi quasi sempre un server MCP, indipendente dal modello: lo stesso server serve Claude, ChatGPT o un modello aperto installato su una macchina aziendale, e opera sempre con i permessi della persona che lo sta usando, mai con un'utenza tecnica onnipotente. ![Quale modello per quali dati: tre classi di informazioni](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/07-modelli-e-dati-it.webp) Un modo pratico di decidere è classificare le informazioni su tre livelli. Quelle che possono uscire, come ricerche pubbliche e bozze, vanno al modello commerciale più capace. Quelle interne vanno solo verso fornitori con garanzie contrattuali adeguate. Quelle che non devono uscire, come dati economici riservati o dati personali, restano su un modello locale o vengono anonimizzate prima dell'invio. Cambiare fornitore, o affiancarne due, non richiede di migrare niente. ## Il lavoro delle persone cambia natura Con un AI Company OS si inseriscono meno dati e si approvano molte più informazioni preparate dal modello. Il verbale di una riunione arriva già scritto, con i task estratti e collegati alle persone giuste, e il compito di chi lo riceve è dire se è corretto. Il modello prepara proposte con la fonte, un estratto e un livello di confidenza, e quando la confidenza è bassa non sceglie: la decisione torna a una persona. Questa regola produce anche tracciabilità, perché ogni oggetto ha un'origine e un responsabile. Se tra sei mesi qualcuno chiede perché è stata presa una decisione, la risposta porta a una riunione, a una persona, a una data, ed è lo stesso tipo di evidenza che un sistema di gestione dell'AI secondo la ISO/IEC 42001 chiede di poter mostrare. ## Da dove partire Chi parte da zero dovrebbe cominciare dalla carta e lasciare gli strumenti per dopo: un inventario delle informazioni che il team produce in una settimana normale, comprese quelle che oggi si perdono nelle chat e nelle conversazioni con l'AI, e del sistema che ne è proprietario. La parte tecnica è spesso la più rapida, perché le fonti hanno già i loro connettori. Il lavoro lungo è mettersi d'accordo su cosa conta come decisione e su chi può chiudere una divergenza. Noi lo facciamo partendo da un solo team, con un metodo e una piattaforma che abbiamo costruito prima per noi stessi. Se volete capire come applicarlo nella vostra azienda, potete [prenotare una sessione di inventario di 30 minuti](https://calendly.com/fabiolalli/zerofive) oppure leggere come funziona il servizio [AI Company OS](/servizi/ai-company-os). --- # AI e industrie: il settore decide da dove arriva il rischio URL: https://zerofive.ai/blog/strategia/ai-e-industrie-mappa-per-settore Data: 2026-10-02 Abstract: Finance, assicurazioni, telco, sport, industria e retail: da dove arriva l'alto rischio e quale gate blocca il rating in ciascun comparto. **In sintesi.** La domanda su cosa comporti l'AI Act per un'azienda non ha una risposta unica, perché il settore decide da dove arriva l'alto rischio e quale gate blocca il rating. In banca arriva dal credito, in assicurazione dai modelli dei fornitori, nello sport dagli atleti come lavoratori, nel retail dai sistemi che gestiscono i turni, in manifattura dal prodotto venduto, in telco dai sistemi commerciali. Il resto del metodo resta lo stesso ovunque. Abbiamo lavorato su sei settori con la stessa sequenza, inventario dei sistemi, classificazione, misurazione delle quattro dimensioni, e ogni volta il punto che blocca l'organizzazione è arrivato da una direzione diversa da quella che la dirigenza si aspettava. Qui sotto c'è la mappa, con i rimandi ai pezzi di dettaglio. ## Il settore decide da dove arriva il rischio | Settore | Da dove arriva l'alto rischio | Il gate ricorrente | |---|---|---| | [Finance](/settori/finance) | Valutazione del merito creditizio, Allegato III | Inventario assente su sistemi già in produzione | | [Assicurazioni](/settori/insurance) | Pricing e selezione dei rischi su modelli di terzi | Perimetro: la compagnia assicurativa è deployer di modelli che non ha costruito | | [Telco](/settori/telco) | Sistemi commerciali, a partire dalla valutazione creditizia dei clienti | Classificazione mai fatta su sistemi nati come gestionali | | [Sport](/settori/sport) | Atleti come lavoratori, biometria negli stadi, formazione di tecnici e ufficiali di gara | Proprietà dei dati, quasi sempre dei fornitori | | [Industria](/settori/industria) | Prodotto con AI incorporata, Allegato I | Separazione mancata tra sistemi di stabilimento e sistemi destinati al prodotto | | [Retail](/settori/retail) | Pianificazione turni e valutazione del personale, Allegato III | Moduli predittivi dentro software di workforce management | ## In finance e assicurazioni il perimetro conta più dell'impianto Sono i due settori che arrivano più preparati, perché la validazione indipendente dei modelli esiste da prima dell'AI Act e la documentazione è un'abitudine consolidata. Quello che manca è il confine: quali sistemi rientrano, chi li ha costruiti, quali obblighi restano in capo a chi li usa. In banca la formazione si innesta su percorsi già obbligatori e i ruoli critici sono tre, come spiega [AI literacy in banca](/blog/compliance/ai-literacy-banche-formazione-settore-finanziario). La scelta del primo caso d'uso viene quasi sempre fatta al contrario, e il motivo è in [AI adoption in banca](/blog/strategia/ai-adoption-banche-primo-caso-uso). Il modo in cui il rating pesa le quattro dimensioni è in [AI Rating in banca](/blog/strategia/ai-rating-banche-quattro-dimensioni-gate). Sul lato assicurativo la cultura del modello aiuta e il perimetro dimenticato è la rete agenziale, come racconta [AI literacy in compagnia assicurativa](/blog/compliance/ai-literacy-assicurazioni-formazione-compagnie). Il caso d'uso più prezioso è anche quello che ricade in Allegato III, e il ragionamento è in [AI adoption in compagnia assicurativa](/blog/strategia/ai-adoption-assicurazioni-primo-caso-uso). Il gate che decide la classe è descritto in [AI Rating in compagnia assicurativa](/blog/strategia/ai-rating-assicurazioni-perimetro-gate). ## Telco e manifattura: dove la tecnica non è il problema Qui le aziende hanno dati propri, infrastrutture solide e cicli di rilascio maturi, e proprio per questo si presentano alla misurazione convinte di essere avanti. Il punteggio cade altrove. Negli operatori telco la difficoltà della formazione è la scala, con migliaia di persone che non sono alle dipendenze dell'operatore, e la soluzione è in [AI literacy in una telco](/blog/compliance/ai-literacy-telco-formazione-scala). L'area con più valore è anche quella con meno attrito, caso raro spiegato in [AI adoption in una telco](/blog/strategia/ai-adoption-telco-rete-commerciale), mentre il gate sta sui sistemi commerciali, come mostra [AI Rating in una telco](/blog/strategia/ai-rating-telco-sistemi-commerciali). In manifattura tutto ruota attorno a una separazione che precede ogni altra valutazione, quella tra sistema che resta in stabilimento e sistema che finisce dentro un prodotto venduto. La formazione si innesta sulla sicurezza sul lavoro, con il rischio descritto in [AI literacy in fabbrica](/blog/compliance/ai-literacy-manifattura-formazione-fabbrica). La scelta del primo caso è in [AI adoption in manifattura](/blog/strategia/ai-adoption-manifattura-stabilimento-prodotto), e la debolezza sui dati che sorprende le aziende tecnologicamente avanzate è in [AI Rating in manifattura](/blog/strategia/ai-rating-manifattura-dati-e-prodotto). ## Retail e sport, il rischio dove nessuno guarda Questi due settori condividono una caratteristica: l'attenzione della dirigenza sta sul cliente e sul tifoso, mentre l'esposizione vera riguarda chi lavora. Nel retail il turnover rende inutile il piano formativo annuale, e l'alternativa è in [AI literacy nel retail](/blog/compliance/ai-literacy-retail-formazione-negozi). Il caso d'uso che rende e quello che espone sono distinti in [AI adoption nel retail](/blog/strategia/ai-adoption-retail-primo-caso-uso), mentre il gate sui moduli predittivi dentro i gestionali del personale è in [AI Rating nel retail](/blog/strategia/ai-rating-retail-sistemi-personale). Nello sport le popolazioni da formare sono due nei club e tre nelle federazioni, come spiega [AI literacy nello sport](/blog/compliance/ai-literacy-club-sportivi-formazione). Il punto di partenza cambia tra club e federazioni, e la differenza è in [AI adoption nello sport](/blog/strategia/ai-adoption-club-sportivi-primo-caso-uso). Il gate sulla proprietà dei dati, che nei club è quasi sempre dei fornitori, è in [AI Rating nello sport](/blog/strategia/ai-rating-club-sportivi-proprieta-dati). ## Le costanti che attraversano i comparti Tre cose tornano ovunque, indipendentemente dal comparto. La prima è che i sistemi più esposti arrivano dentro software comprati per altro, moduli predittivi accesi dentro gestionali che nessuno ha rivalutato dopo l'acquisto. La seconda è che la formazione per ruolo esiste già su altri fronti, dalla sicurezza sul lavoro all'antiriciclaggio, e innestarsi su quei percorsi costa molto meno che costruirne di nuovi. La terza riguarda i dati, che in quasi tutti i settori appartengono contrattualmente a un fornitore, e un'azienda che non può esportare quello su cui lavora non controlla i propri sistemi. Il modo in cui queste tre cose pesano sul punteggio è descritto in [le quattro dimensioni della maturità AI](/blog/ai-governance/quattro-dimensioni-maturita-ai) e in [i gate critici](/blog/ai-governance/gate-critici-maturita-ai). ## Da dove partire Il prerequisito è lo stesso in tutti i settori, e non dipende dalla dimensione dell'azienda: l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), costruito guardando anche dentro i software già in uso. Da lì si passa alla [classificazione per rischio](/blog/compliance/classificazione-sistemi-ai-rischio) e alla misurazione, descritta nella pagina [AI Rating](/servizi/ai-rating). La mappa completa dei settori è nella pagina [Settori](/settori). Per capire da dove arriva l'esposizione nella tua organizzazione puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # Da oggi la documentazione AI è anche materiale di prova URL: https://zerofive.ai/blog/compliance/documentazione-ai-difesa-dlgs-160-2026 Data: 2026-09-30 Abstract: Con il D.Lgs. 160/2026 in vigore, log, documentazione tecnica e sorveglianza umana diventano materiale di prova. Come rileggere inventario, design e competenze. **In sintesi.** Da oggi il decreto legislativo 160/2026 è in vigore, e in un'azione di risarcimento per danni da sistemi di AI il giudice può ordinare l'esibizione di log, documentazione sui rischi, documentazione tecnica e modalità di sorveglianza umana. Gli stessi documenti che una serie di articoli ha descritto come requisiti di uno standard volontario diventano, in quella sede, il materiale con cui un'azienda sostiene la propria posizione. Questo articolo rilegge il percorso da quel punto di vista. Per un mese abbiamo scritto di inventari, impact assessment, logging, supervisione umana, competenze e certificazione, con l'argomento tipico della compliance: serve per l'audit, conviene farlo prima, ricostruirlo dopo costa di più. Da oggi quell'argomento ha un secondo piano, e vale la pena rimetterlo in ordine ora che il decreto è operativo. ## Cosa succede da oggi Il decreto legislativo 9 settembre 2026, n. 160, pubblicato in Gazzetta Ufficiale il 15 settembre, entra in vigore il 30. Gli articoli da 16 a 20 riguardano le azioni civili di risarcimento per danni cagionati nell'utilizzo di un sistema di AI, e li abbiamo descritti in dettaglio nell'articolo su [accesso alle prove e nesso causale](/blog/compliance/danni-ai-prove-nesso-causale-dlgs-160-2026). Tre meccanismi agiscono insieme. Il giudice può ordinare l'esibizione degli elementi di prova sul funzionamento del sistema, e chi non adempie senza giustificato motivo rischia che i fatti allegati dalla controparte siano considerati ammessi. Quando il danno deriva dalla violazione di obblighi dell'AI Act il nesso causale è presunto, salvo prova contraria. La conformità al regolamento, anche certificata, non esclude di per sé la responsabilità. Vale la pena tenere a mente due limiti, perché il perimetro effettivo è più stretto di quanto i titoli suggeriscano. La presunzione del nesso opera solo dove il danno discende da una violazione dell'AI Act, e diversi obblighi sull'alto rischio si applicano dal dicembre 2027 per l'Allegato III e dall'agosto 2028 per l'Allegato I. L'accesso alle prove, invece, vale da subito per qualunque azione di risarcimento legata all'uso di un sistema di AI, a prescindere dalla classe di rischio. ## Gli stessi documenti, due destinatari I quattro tipi di documento che l'articolo 17 indica come esibibili sono quelli che l'AI Act già prevede: registri automatici, sistema di gestione dei rischi, documentazione tecnica, parametri e modalità di sorveglianza umana. Sono anche, quasi uno per uno, quelli che un sistema di gestione conforme a ISO/IEC 42001 produce lungo il ciclo di vita. La differenza sta in chi li legge e con quale domanda. Un auditor verifica che il sistema di gestione funzioni e campiona per accertarsene, con una logica di conformità a un modello. Un giudice guarda un singolo episodio e chiede cosa è successo quel giorno, su quell'input, con quale intervento umano. Il primo può accettare che una procedura descriva un controllo, il secondo vuole la traccia di quel controllo nel caso concreto. Questa distanza spiega perché alcuni documenti perfettamente adeguati per un audit diventano deboli in un contenzioso. Una procedura di sorveglianza umana approvata e aggiornata supera un audit; se però nessuno registra gli interventi effettivi, in giudizio non dimostra che quel giorno qualcuno abbia guardato. ## Dove i pezzi della serie cambiano peso L'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001) serviva a sapere cosa governare. Da oggi serve anche a sapere, quando arriva una contestazione su un sistema specifico, chi ne è responsabile, quali dati tratta e dove sono i suoi log. Un'azienda che non riesce a rispondere in tempi ragionevoli a queste domande parte in svantaggio. Le scelte descritte in [progettare un sistema AI ISO-ready](/blog/compliance/progettare-sistema-ai-iso-ready) diventano più rilevanti di quanto sembrasse. Un log che registra solo l'output non permette di ricostruire una decisione, e questo passa da limite tecnico a difficoltà probatoria. Lo stesso vale per la supervisione umana progettata senza strumenti di intervento tracciabili. Sulle competenze, la [clausola 7](/blog/compliance/clausola-7-iso-42001-competenze) e la [matrice ruoli-competenze](/blog/compliance/matrice-ruoli-competenze-ai) si collegano alla sorveglianza umana. Dimostrare che il presidio esisteva significa anche mostrare che chi lo esercitava aveva gli strumenti per farlo, il che riporta alle evidenze individuali per i ruoli critici di cui parla [AI literacy e competenze ISO 42001](/blog/compliance/ai-literacy-competenze-iso-42001). Sulla certificazione, l'articolo 19 chiude il discorso in modo esplicito. Gli articoli sulla [mappa degli organismi accreditati](/blog/compliance/certificazione-iso-42001-italia-accredia) e sui [tre percorsi di certificazione](/blog/compliance/lead-implementer-auditor-certificazione-aziendale) restano validi per quello che dicono, e vanno letti sapendo che il certificato attesta l'esistenza di un sistema a una certa data, mentre la difesa in un caso concreto la costruiscono le evidenze operative. ## La domanda che cambia la prospettiva Chi vuole verificare in mezz'ora quanto è esposto può provare un esercizio semplice. Si sceglie un sistema AI in uso e si fissa una data qualunque delle ultime settimane, poi si prova a ricostruire una singola decisione presa quel giorno: quale input ha ricevuto il sistema, quale versione del modello era attiva, quale esito ha prodotto, se qualcuno è intervenuto e chi. Se la ricostruzione richiede di chiedere file a un fornitore, se i log sono stati ruotati, se l'intervento umano non risulta da nessuna parte, quella è la posizione in cui l'azienda si troverebbe davanti a un ordine di esibizione. La differenza è che oggi l'esercizio si può fare con calma, e il risultato non finisce agli atti. ## Le verifiche più urgenti Le tre verifiche più urgenti riguardano i contratti, i tempi di conservazione e la tracciabilità degli interventi. Sui contratti con i fornitori, va verificato se esiste una clausola che garantisce l'accesso a log e documentazione tecnica in caso di contenzioso, con tempi compatibili con un ordine del giudice. Un fornitore che conserva i log per trenta giorni e non ha obbligo di rilascio lascia l'azienda senza il materiale principale. Sui tempi di conservazione, l'articolo 26 dell'AI Act prevede per i sistemi ad alto rischio almeno sei mesi, che è un pavimento e non necessariamente la durata giusta rispetto ai tempi in cui un danno emerge e viene contestato. Sulla tracciabilità degli interventi umani, serve verificare se l'atto di supervisione lascia una traccia, o se resta una prassi descritta nelle procedure e invisibile nei dati. ## Perché il metodo resta lo stesso Chi ha costruito un sistema di gestione perché voleva certificarsi ha già gran parte di quello che serve, e deve soprattutto verificare che le evidenze siano ricostruibili per singolo caso e non solo per campione. Chi non si certifica non ha obblighi documentali equivalenti, e ha comunque interesse a produrre lo stesso materiale, perché l'ordine di esibizione non distingue tra aziende certificate e non. L'inversione è tutta qui: la documentazione di governance smette di essere un costo sostenuto per ottenere un titolo e diventa il modo in cui un'azienda racconta, con elementi verificabili, cosa ha fatto il proprio sistema. È il motivo per cui conviene costruirla quando non serve, perché nel momento in cui serve non si costruisce più. ## Il passo successivo Questo articolo chiude la serie su ISO/IEC 42001 iniziata il 1° settembre. L'indice completo è in fondo all'articolo sui [tre percorsi di certificazione](/blog/compliance/lead-implementer-auditor-certificazione-aziendale), e il quadro normativo generale nella [guida completa all'AI Act](/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati). Con l'[AI Rating](/servizi/ai-rating) misuriamo la maturità di un'azienda anche sulla dimensione AI Risk, che copre governance dei rischi, compliance e tracciabilità. Per discutere la tua posizione puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive) oppure scrivere a hello@zerofive.ai. *Questo articolo descrive il testo normativo e le sue implicazioni organizzative, e non costituisce parere legale.* **Fonti.** Decreto legislativo 9 settembre 2026, n. 160, Gazzetta Ufficiale, Serie generale, n. 214 del 15 settembre 2026, articoli 16-20; Regolamento (UE) 2024/1689 (AI Act) come modificato dal Regolamento (UE) 2026/1744, articoli 9, 11, 12, 14 e 26; ISO/IEC 42001:2023, clausole 7 e 9, Annex A. --- # Sistemi AI ad alto rischio: come si legge l'articolo 6 dell'AI Act URL: https://zerofive.ai/blog/compliance/sistemi-ai-alto-rischio-articolo-6-ai-act Data: 2026-09-28 Abstract: Allegato I, Allegato III, eccezioni dell'art. 6(3) e obblighi per fornitori e deployer: come classificare i sistemi AI prima del 2 dicembre 2027. **In sintesi.** Un sistema AI diventa ad alto rischio per due strade: come componente di sicurezza di un prodotto regolato dall'Allegato I, oppure perché il suo scopo previsto rientra in uno degli otto ambiti dell'Allegato III. Il Digital Omnibus ha spostato gli obblighi al 2 dicembre 2027 e al 2 agosto 2028, ma la classificazione va fatta adesso, perché decide costi, contratti e architetture dei progetti già in corso. Il 19 maggio 2026 la Commissione europea ha pubblicato la bozza delle linee guida sulla classificazione dei sistemi di intelligenza artificiale ad alto rischio, previste dall'articolo 6, paragrafo 5, del Regolamento (UE) 2024/1689. Dovevano arrivare entro il 2 febbraio, sono arrivate con più di tre mesi di ritardo, la consultazione con gli stakeholder si è chiusa in estate e la versione definitiva è attesa entro la fine del 2026. Nel frattempo il Digital Omnibus, pubblicato come Regolamento (UE) 2026/1744 il 24 luglio, ha spostato il calendario: gli obblighi per i sistemi elencati nell'Allegato III si applicano dal 2 dicembre 2027, quelli per l'AI integrata nei prodotti regolati dell'Allegato I dal 2 agosto 2028. In queste settimane il tema è ovunque, tra webinar, post e checklist, e la reazione che osserviamo più spesso nelle aziende è una specie di sollievo, perché quattordici mesi sembrano tanti. Secondo me è una lettura pericolosa. La classificazione di un sistema AI decide quanto costa svilupparlo, come va scritto il contratto con il fornitore, quale documentazione va prodotta mentre il progetto nasce, chi in azienda deve firmare. L'Osservatorio Artificial Intelligence del Politecnico di Milano, nella ricerca presentata a febbraio 2026, rileva che il 71% delle grandi imprese italiane ha progetti AI attivi e solo il 9% ha una governance strutturata: in quello scarto ci sono sistemi che nessuno ha ancora classificato, e che tra un anno qualcuno dovrà classificare in fretta. ## Le due strade dell'articolo 6 L'articolo 6 apre due porte distinte verso l'alto rischio, e confonderle è l'errore più comune. La prima, al paragrafo 1, riguarda i sistemi AI che sono essi stessi un prodotto, o un componente di sicurezza di un prodotto, coperto dalla normativa europea di armonizzazione elencata nell'Allegato I, a condizione che quel prodotto debba passare da una valutazione di conformità di terza parte. La seconda, al paragrafo 2, riguarda i sistemi il cui scopo previsto rientra in uno dei casi d'uso dell'Allegato III, indipendentemente dal prodotto in cui girano. Sono due logiche diverse. La prima ragiona sul prodotto e sulla sicurezza fisica, eredita il linguaggio del New Legislative Framework e si innesta su processi di certificazione che i produttori di macchinari o dispositivi medici conoscono da anni. La seconda ragiona sull'uso e sui diritti fondamentali, e colpisce aziende che non si sono mai considerate "regolate", come chi seleziona personale o valuta il merito creditizio. In entrambi i casi la variabile decisiva è lo scopo previsto, cioè l'uso che il fornitore dichiara nella documentazione, nelle istruzioni, nel materiale commerciale. La bozza di linee guida insiste molto su questo punto: lo scopo va descritto in modo coerente in tutti i documenti, e un sistema presentato come generico nella scheda tecnica ma venduto per lo screening dei candidati sul sito verrà letto per quello che fa. ## I prodotti regolati dell'Allegato I Per l'AI integrata nei prodotti, la domanda da farsi è tecnica prima che giuridica. L'Allegato I elenca la normativa di prodotto rilevante: macchine, giocattoli, apparecchiature radio, dispositivi medici e diagnostici in vitro, ascensori, attrezzature a pressione, veicoli, aviazione civile e altro ancora. Se il prodotto rientra in una di queste discipline e richiede l'intervento di un organismo notificato, bisogna capire se il sistema AI svolge una funzione di sicurezza o se un suo malfunzionamento può mettere a rischio la salute o la sicurezza delle persone, secondo la definizione di componente di sicurezza dell'articolo 3, punto 14. Le linee guida chiariscono che conta la funzione, non il modo in cui l'AI viene distribuita: un modulo di visione che ferma una pressa quando rileva una mano nella zona di lavoro è un componente di sicurezza sia che giri a bordo macchina sia che arrivi come servizio cloud. Per chi produce in Italia, e il nostro manifatturiero è pieno di macchine sempre più intelligenti, significa che la classificazione va fatta dentro il fascicolo tecnico del prodotto, con le stesse persone che oggi gestiscono la marcatura CE. ## Gli otto ambiti dell'Allegato III L'Allegato III è l'elenco che interessa la maggior parte delle aziende di servizi. Gli ambiti sono otto: - biometria, inclusa l'identificazione a distanza e il riconoscimento delle emozioni dove consentito; - infrastrutture critiche, come la gestione di reti idriche, gas, elettricità e traffico; - istruzione e formazione professionale, dall'ammissione alla valutazione degli apprendimenti; - occupazione e gestione dei lavoratori, dalla selezione alle decisioni su promozioni, cessazioni e assegnazione dei compiti; - accesso a servizi essenziali pubblici e privati, tra cui il merito creditizio e la determinazione del premio nelle assicurazioni vita e salute; - attività di contrasto; - migrazione, asilo e controllo delle frontiere; - amministrazione della giustizia e processi democratici. Chi lavora in banca, in assicurazione o in una direzione HR si trova dentro questo elenco anche senza sviluppare nulla in casa, perché gli obblighi seguono il sistema lungo la catena e ricadono in parte su chi lo usa. La bozza della Commissione aggiunge un chiarimento che molte aziende non avevano messo in conto: un sistema che orienta in modo rilevante una decisione sul lavoro resta ad alto rischio anche se l'ultima parola spetta a una persona, perché la supervisione umana è un obbligo dell'articolo 14 e non una via d'uscita dalla classificazione. ## Le eccezioni dell'articolo 6, paragrafo 3 In questo spazio si concentreranno le discussioni più accese con le autorità di vigilanza. Un sistema che rientra nell'Allegato III può non essere considerato ad alto rischio se non influenza in modo sostanziale l'esito delle decisioni, e l'articolo 6, paragrafo 3, individua quattro condizioni alternative, per cui ne basta una: - il sistema esegue un compito procedurale limitato, come classificare documenti in entrata; - migliora il risultato di un'attività umana già completata, ad esempio rivedendo la forma di un testo scritto da una persona; - rileva schemi decisionali o scostamenti rispetto a decisioni precedenti, senza sostituire la valutazione umana; - svolge un compito preparatorio rispetto a una valutazione che resta umana. Con un limite che non ammette interpretazioni: se il sistema effettua profilazione di persone fisiche, nessuna delle quattro condizioni lo salva. Chi si avvale dell'eccezione deve documentare la propria valutazione prima dell'immissione sul mercato e metterla a disposizione delle autorità che la chiedono, per cui la deroga è una scelta attiva, firmata, che qualcuno deve poter difendere. Le linee guida chiudono anche la scorciatoia architetturale: se più componenti, magari agenti distinti, concorrono insieme a una decisione che rientra nell'Allegato III, la configurazione complessiva viene trattata come un unico sistema, e spezzare il flusso in pezzi che singolarmente sembrano innocui non cambia l'esito. ## Gli obblighi per fornitori e deployer Una volta classificato il sistema come ad alto rischio, il fornitore si fa carico del grosso. Deve istituire un sistema di gestione dei rischi lungo tutto il ciclo di vita, governare la qualità dei dati di addestramento, validazione e test, produrre la documentazione tecnica, garantire la registrazione automatica degli eventi, fornire istruzioni d'uso comprensibili, progettare la supervisione umana, assicurare livelli adeguati di accuratezza, robustezza e cybersicurezza. A questo si aggiungono un sistema di gestione della qualità, la valutazione della conformità con marcatura CE, la registrazione nella banca dati europea, il monitoraggio successivo all'immissione sul mercato e la segnalazione degli incidenti gravi. Il deployer, cioè l'azienda che usa il sistema nella propria attività, ha obblighi più leggeri ma tutt'altro che formali. L'articolo 26 gli chiede di usare il sistema secondo le istruzioni, di affidare la supervisione a persone con competenza e autorità adeguate, di verificare la pertinenza dei dati di input che controlla, di monitorare il funzionamento, di conservare i log generati automaticamente per almeno sei mesi e di informare i lavoratori quando il sistema viene impiegato sul luogo di lavoro. Per gli enti pubblici, per i privati che erogano servizi pubblici e per chi usa sistemi di valutazione del merito creditizio o di pricing nelle assicurazioni vita e salute, l'articolo 27 aggiunge la valutazione d'impatto sui diritti fondamentali. L'articolo 25 prevede che un deployer diventi fornitore, con tutti i relativi obblighi, se modifica in modo sostanziale un sistema ad alto rischio, se ne cambia lo scopo previsto facendolo diventare ad alto rischio, o se lo mette in commercio con il proprio nome. Chi prende un modello generico e lo configura per lo screening dei curriculum dei propri clienti sta attraversando questa linea, spesso senza accorgersene. ## La classificazione come decisione di governance Davanti a questo elenco molte aziende sono tentate di trattare tutto come un problema legale da delegare. È comprensibile, e un parere legale su un caso limite serve davvero, ma la classificazione nasce prima, nel momento in cui qualcuno in azienda decide lo scopo di un sistema, sceglie un fornitore, disegna un flusso di lavoro. Chi arriva dal legale con un inventario vuoto riceverà un parere su un'ipotesi. Il lavoro che vediamo mancare quasi ovunque è a monte: un registro dei sistemi AI in uso e in sviluppo, con per ciascuno lo scopo previsto dichiarato, il ruolo dell'azienda (fornitore, deployer, o entrambi), la strada dell'articolo 6 che potrebbe applicarsi e, se si invoca un'eccezione, la motivazione scritta e il nome di chi l'ha approvata. È lo stesso tipo di disciplina che chiede la ISO/IEC 42001 per un sistema di gestione dell'AI, ed è quello che nel nostro AI Rating misuriamo nella dimensione Risk, con un gate che non si compensa con punteggi alti altrove: un'azienda che non sa quali sistemi ha non può essere matura sull'AI, qualunque sia la qualità dei suoi modelli. Il calendario del Digital Omnibus dà tempo per costruire documentazione, test, contratti e processi di supervisione, a condizione che la classificazione sia fatta adesso. Chi la rimanda al 2027 si troverà a classificare sistemi già in produzione, con contratti già firmati e architetture già decise, e a quel punto ogni risposta scomoda costa il doppio. La bozza della Commissione verrà rivista, gli esempi cambieranno, alcune interpretazioni si sposteranno. Un registro cominciato oggi sarà pronto ad accogliere la versione finale, e dirà all'azienda quanti dei suoi "strumenti di supporto" sono in realtà sistemi che orientano decisioni sulle persone. --- # Corso AI obbligatorio: cosa copre dopo l'Omnibus e cosa manca per ISO 42001 URL: https://zerofive.ai/blog/compliance/corso-ai-obbligatorio-non-basta Data: 2026-09-23 Abstract: Il corso AI standard dopo il Digital Omnibus: cosa copre dell'articolo 4 dell'AI Act, cosa manca per la clausola 7 di ISO/IEC 42001 e come integrarlo. **In sintesi.** Un corso AI standard acquistato per rispondere all'articolo 4 dell'AI Act copre una base utile, e resta lontano da quello che la clausola 7 di ISO/IEC 42001 richiede. Dopo il Digital Omnibus l'obbligo di AI literacy consiste nell'adottare misure di sostegno all'alfabetizzazione, e un corso generale può rientrarvi. La clausola 7 chiede invece competenze determinate per ruolo, evidenze documentate e aggiornamenti legati ai sistemi in uso. Qui trovate cosa un corso standard non può contenere per costruzione, quanto costa aggiungerlo e cosa chiedere a un fornitore prima di firmare. Con l'entrata in applicazione di una parte ampia dell'AI Act il 2 agosto 2026, molte aziende si chiedono se il corso obbligatorio acquistato nei mesi scorsi basti a considerarsi in regola. Per l'articolo 4, dopo le modifiche del Digital Omnibus, la risposta dipende da come il corso si inserisce nelle misure che l'azienda ha adottato. Per chi punta alla certificazione ISO/IEC 42001 la risposta è quasi sempre negativa. ## Il mercato dei corsi standard Da quando l'obbligo di AI literacy è applicabile, dal 2 febbraio 2025, è cresciuta un'offerta ampia di corsi standard, di durata breve e uguali per ogni cliente, spesso presentati come soluzione completa all'articolo 4. Il corso in sé è uno strumento legittimo. Il problema nasce quando viene considerato l'ultimo passo invece del primo. Tre formulazioni commerciali meritano attenzione perché promettono più di quanto un corso possa dare. La prima è la conformità garantita all'AI Act, che nessun fornitore di formazione può assicurare, perché la conformità dipende dai sistemi che usate e da come li governate. La seconda è il corso valido per la certificazione ISO/IEC 42001, formula che confonde un contenuto formativo con l'evidenza che un organismo di certificazione valuterà. La terza è l'attestato riconosciuto, dove il riconoscimento spesso proviene dallo stesso soggetto che eroga il corso. Nessuna delle tre rende il corso inutile. Tutte e tre segnalano che il fornitore sta vendendo tranquillità invece di competenza, e conviene saperlo prima di considerare chiusa la questione. ## L'articolo 4 dopo il Digital Omnibus La modifica al regolamento, in vigore dal 27 luglio 2026, ha reso l'obbligo meno rigido di quanto molti fornitori continuino a raccontare: le organizzazioni devono adottare misure di sostegno all'alfabetizzazione del personale, senza garantire a ciascuna persona uno specifico livello dimostrato. Per chi organizza la formazione su larga scala è una semplificazione concreta, e un corso generale ben scelto può far parte di quelle misure, soprattutto se accompagnato da indicazioni sull'uso dei sistemi presenti in azienda. Restano fermi i criteri con cui le misure vanno calibrate, tra cui il contesto d'uso dei sistemi, ed è proprio quel criterio che un corso uguale per tutti non soddisfa da solo. Va aggiunto un limite che l'alleggerimento non tocca. Gli obblighi di competenza per chi esercita la sorveglianza umana sui sistemi ad alto rischio restano pieni, e su quei ruoli la partecipazione a un corso generale non è sufficiente nemmeno rispetto all'AI Act. ## Cosa copre un corso standard | Contenuto | Corso standard | Clausola 7 ISO/IEC 42001 | |---|---|---| | Concetti di base su modelli e rischi | Coperto | Utile come base | | Principi di uso responsabile | Coperto | Utile come base | | Competenze specifiche per ruolo | Di norma assente | Richiesto (7.2) | | Riferimento ai sistemi in inventario | Assente | Richiesto per ruoli che incidono sull'AIMS | | Consapevolezza della politica AI e del proprio contributo | Parziale | Richiesto (7.3) | | Evidenza collegata alla persona e al ruolo | Attestato generico | Informazioni documentate (7.5) | | Valutazione dell'efficacia | Questionario di gradimento | Richiesta (7.2) | | Aggiornamento quando cambiano i sistemi | Assente | Atteso dal sistema di gestione | ## I cinque elementi che nessun fornitore può scrivere Vale la pena essere chiari su un punto che nella discussione si perde: alcune cose mancano nei corsi standard non per pigrizia del fornitore, ma perché un contenuto uguale per tutti i clienti non può contenerle per costruzione. La vostra politica AI, che è un documento vostro e che la clausola 7.3 chiede di far conoscere alle persone. L'elenco dei sistemi effettivamente in uso da voi, con cosa fanno e quali decisioni supportano. Il nome del referente a cui segnalare un comportamento anomalo. La procedura interna che descrive cosa succede dopo quella segnalazione. I casi limite osservati sui vostri sistemi, che sono l'informazione più utile in assoluto per chi li usa ogni giorno. Sono cinque elementi che nessun fornitore esterno può scrivere al posto vostro, e sono anche quelli che trasformano una formazione generica in una formazione che cambia il comportamento delle persone. La buona notizia è che costano poco: trenta o quaranta minuti per sistema, preparati da chi quel sistema lo conosce già. ## La distanza dalla clausola 7 Il corso standard tratta i modelli, i rischi in astratto e i principi generali, mentre raramente entra nel ruolo di chi lo segue. Un risk owner e un addetto alla logistica escono con lo stesso attestato, senza collegamento con i sistemi che useranno, e in audit quell'attestato dimostra una partecipazione più che una competenza. Anche un'organizzazione in regola con l'articolo 4 resta quindi lontana dalla clausola 7, che chiede competenze determinate per ruolo, evidenze conservate e un piano che si aggiorna quando cambiano i sistemi, come descritto nella [matrice ruoli-competenze](/blog/compliance/matrice-ruoli-competenze-ai). C'è poi un requisito che i corsi standard non affrontano quasi mai, ed è la valutazione dell'efficacia richiesta dalla clausola 7.2. Il questionario di gradimento somministrato a fine corso misura quanto è piaciuto, non quanto è rimasto, e non copre quell'obbligo. ## Cosa c'è scritto sull'attestato L'attestato tipico riporta il nome della persona, il titolo del corso, la durata e la data. Sono informazioni utili a dimostrare che qualcosa è stato erogato, e insufficienti a dimostrare che una competenza è stata acquisita. Per essere utilizzabile come evidenza, un attestato dovrebbe permettere di rispondere a tre domande senza consultare altri documenti: quale competenza della matrice quella persona ha coperto, rispetto a quale ruolo, e con quale verifica dell'apprendimento. Quasi nessun attestato standard risponde a tutte e tre. La soluzione non richiede di rifare il corso. Basta produrre internamente un documento che colleghi l'attestato al ruolo e alla competenza, conservato insieme all'attestato stesso, che è esattamente quello che le informazioni documentate della clausola 7.5 chiedono. ## Un esempio ipotetico Un'azienda di distribuzione ha acquistato per tutti i dipendenti un corso online sull'AI e sta preparando la certificazione ISO/IEC 42001. In fase di gap analysis emerge che il corso copre bene la parte generale ma non tocca i due sistemi in inventario, e che gli attestati non indicano il ruolo delle persone. L'azienda tiene il corso come modulo introduttivo, aggiunge un laboratorio per i risk owner e moduli brevi per gli operatori dei due sistemi, e collega ogni attestato alla matrice dei ruoli. L'esempio è illustrativo e non descrive un caso reale. ## Il corso e la prova C'è una ragione ulteriore, esterna alla norma tecnica, per cui un corso standard non chiude la questione. Dal 30 settembre 2026 il decreto legislativo 160/2026 permette al giudice di ordinare l'esibizione delle modalità di sorveglianza umana adottate, e in quella sede l'attestato di partecipazione a un corso generico dice poco su quale competenza avesse la persona che avrebbe dovuto accorgersi dell'errore. L'alleggerimento dell'articolo 4 operato dall'Omnibus riguarda il livello di alfabetizzazione richiesto in generale, e non tocca gli obblighi di competenza per chi esercita la sorveglianza umana sui sistemi ad alto rischio. Su quei ruoli l'evidenza deve restare individuale e riferita al sistema specifico, che è anche quello che la clausola 7 chiede. Il quadro processuale è descritto nell'articolo su [accesso alle prove e nesso causale nel D.Lgs. 160/2026](/blog/compliance/danni-ai-prove-nesso-causale-dlgs-160-2026). ## Come estendere il corso già acquistato Rifare tutto è lo spreco più comune quando emerge il divario, e quasi mai serve. Il corso pagato resta valido per quello che copre, e va usato come primo strato di un piano che ne ha tre. - Registrate il corso come modulo introduttivo del piano, con l'elenco dei contenuti che copre davvero. - Collegate ogni attestato al ruolo della persona nella matrice, con un documento interno che faccia da ponte. - Aggiungete un modulo breve per ciascun sistema in inventario, destinato a chi lo usa e a chi ne possiede il rischio. Mezz'ora per sistema, preparata internamente, copre quello che il corso non poteva contenere. - Prevedete una sessione dedicata alla direzione, centrata sulle decisioni che deve prendere e non sui concetti tecnici. - Definite la verifica di efficacia, almeno per i ruoli critici, con un caso pratico o una revisione del lavoro reale. - Fissate l'innesco di aggiornamento, tipicamente l'adozione di un nuovo sistema o il cambio di ruolo di una persona. Il costo aggiuntivo si concentra nelle ore interne di chi prepara i moduli specifici, che sono anche le persone che conoscono i sistemi. Comprarli all'esterno raramente conviene, perché il fornitore dovrebbe prima imparare da voi quello che deve insegnare ai vostri. ## Le domande da fare prima di comprare Chi deve ancora scegliere un corso può evitare buona parte del lavoro successivo con cinque domande in fase di selezione. - Il programma può essere integrato con contenuti sui nostri sistemi, e a quali condizioni? - Gli attestati possono riportare il ruolo e le competenze coperte, o sono standard? - È prevista una verifica dell'apprendimento distinta dal questionario di gradimento? - I contenuti sono aggiornati all'AI Act come modificato dal Digital Omnibus del luglio 2026? - Chi aggiorna il programma quando cambia la normativa, e con quale frequenza? Un fornitore che risponde in modo vago alla prima e alla terza sta offrendo un prodotto, non un percorso, e va valutato per quello che è. ## Il passo successivo Il corso già pagato è una base da estendere. Il coordinamento tra i due obblighi è descritto in [AI literacy e competenze ISO 42001](/blog/compliance/ai-literacy-competenze-iso-42001), la costruzione dei livelli nella [matrice ruoli-competenze](/blog/compliance/matrice-ruoli-competenze-ai), e gli errori più frequenti in audit in [gli errori che fanno bocciare un piano di formazione AI](/blog/compliance/errori-piano-formazione-audit-ai). L'approccio con cui costruiamo i percorsi per ruolo è descritto nella pagina [AI Training](/servizi/ai-training). Per valutare cosa manca al tuo piano puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Gli errori che fanno bocciare un piano di formazione AI in audit URL: https://zerofive.ai/blog/compliance/errori-piano-formazione-audit-ai Data: 2026-09-22 Abstract: Quattro errori che fanno contestare un piano di formazione AI in audit ISO/IEC 42001, come emergono e quali evidenze li prevengono. **In sintesi.** Un piano di formazione AI viene contestato in un audit ISO/IEC 42001 per sei ragioni ricorrenti: l'erogato non coincide con il dichiarato, mancano evidenze collegate al ruolo, l'efficacia non è mai stata valutata, il piano non si aggiorna quando cambiano sistemi e persone, chi approva non ha compreso cosa approva, il perimetro si ferma ai dipendenti. Le sei hanno la stessa origine, una formazione trattata come adempimento e scollegata dall'inventario dei sistemi. Qui trovate come ciascuna emerge, quale evidenza la previene e quando il rilievo diventa una non conformità maggiore. Durante un audit di certificazione l'auditor confronta il piano con i registri di partecipazione, campiona alcune persone e pone domande dirette su quello che hanno imparato e su come lo applicano. In quel confronto tra carta e realtà emergono quasi tutte le non conformità legate alla clausola 7, anche in aziende che hanno investito budget consistenti in formazione. ## Dove si rompe il piano tra stage 1 e stage 2 La certificazione si svolge in due fasi, e la formazione si comporta diversamente nelle due. Nello stage 1 l'auditor verifica che i documenti esistano e siano coerenti: c'è un piano, c'è una matrice dei ruoli, c'è una procedura che descrive come si determina la competenza. Superarlo è relativamente facile, perché basta che la carta sia in ordine. Nello stage 2 la verifica cambia natura. L'auditor controlla che quel piano sia stato attuato e abbia prodotto l'effetto dichiarato, e lo fa parlando con le persone. È la fase in cui la maggior parte dei rilievi sulla clausola 7 compare, e il salto tra le due spiega perché aziende convinte di essere pronte dopo lo stage 1 si trovano con un elenco di osservazioni nello stage 2. Chi prepara la certificazione guardando solo alla completezza documentale sta preparando metà audit. ## Il piano che non corrisponde all'erogato Il piano esiste, magari con un calendario ordinato e fornitori riconosciuti, ma quello che è stato erogato davvero è diverso. Succede quando un corso viene acquistato per un gruppo più ampio di quello che poi partecipa, o quando il fornitore modifica il programma in corsa e la documentazione interna resta ferma alla versione iniziale. Le discrepanze più frequenti sono tre e si riconoscono tutte dai registri: persone previste nel piano che non compaiono tra i partecipanti, moduli erogati con contenuti diversi da quelli descritti, sessioni rinviate e mai recuperate che nel piano risultano completate. Nessuna di queste è grave in sé, ma insieme raccontano un processo che nessuno governa, ed è quella la conclusione che l'auditor annota. La prevenzione costa poco: una revisione del piano a ogni variazione del programma, con data e motivo della modifica, che trasforma la discrepanza in una decisione tracciata. ## Le evidenze generiche Anche quando la formazione è stata svolta, spesso manca la prova che serve: un registro con data verificabile, il collegamento tra chi ha partecipato e il ruolo che ricopre, un attestato che descriva i contenuti con un dettaglio superiore a "corso AI base". Gli attestati generici del fornitore, privi di riferimenti alle competenze richieste per il ruolo, non dimostrano che quella competenza sia stata coperta. Il test pratico è semplice. Prendete un attestato a caso e chiedetevi se, leggendolo senza altre informazioni, si capisce quale competenza della matrice quella persona ha acquisito. Se la risposta richiede di aprire altri tre documenti e fare un ragionamento, l'auditor arriverà alla stessa difficoltà e la annoterà. ## La valutazione di efficacia che non esiste Questo è il rilievo più costoso, e spesso il più inatteso, perché arriva in aziende che hanno fatto tutto il resto correttamente. La clausola 7.2 chiede di intraprendere azioni per acquisire la competenza necessaria e di valutare l'efficacia di quelle azioni, che sono due obblighi distinti. Un registro di partecipazione documenta l'erogazione. Non dice nulla sull'efficacia, e quando l'auditor chiede come sia stata verificata, la risposta più comune è il questionario di gradimento, che misura la soddisfazione di chi ha seguito il corso e non la competenza acquisita. Le forme di valutazione che reggono sono altre: un caso pratico svolto e corretto, un lavoro reale rivisto da qualcuno più esperto, una verifica sul campo a distanza di settimane, un colloquio strutturato con esito registrato. Nessuna richiede strumenti particolari, tutte richiedono di essere previste prima invece che ricostruite dopo. ## Il piano fermo nel tempo Un piano scritto un anno fa e mai rivisto perde validità anche se era corretto al momento della stesura. Nel frattempo sono arrivati nuovi sistemi AI, sono cambiati i rischi associati e sono entrate persone che quel piano non l'hanno mai visto. Il controllo che l'auditor fa è meccanico: confronta la data dell'ultima revisione del piano con la data di ingresso dell'ultimo sistema in inventario e con l'elenco delle assunzioni recenti. Se l'inventario si è mosso e il piano no, il meccanismo di aggiornamento non funziona, indipendentemente da quanto sia completo il piano per chi c'era prima. La formazione, come l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), ha bisogno di un innesco che la aggiorni quando cambia qualcosa di rilevante. Gli inneschi che funzionano sono due, l'ingresso di un nuovo sistema e il cambio di ruolo di una persona, entrambi agganciati a processi che esistono già e che nessuno può saltare. ## L'approvazione senza comprensione È l'errore più delicato: una persona con autorità di approvazione firma senza aver compreso cosa sta approvando. Accade più spesso a livello di direzione che nei team operativi, perché la formazione per chi governa viene percepita come meno urgente di quella tecnica. Bastano poche domande dell'auditor per farlo emergere, e la conseguenza non riguarda solo la formazione. Un'approvazione priva di comprensione mette in discussione la tenuta del processo decisionale sull'AI, che è il cuore di quello che la norma chiede alla direzione. Il rilievo tende quindi a risalire dalla clausola 7 alla clausola 5 sulla leadership, ed è il motivo per cui pesa più di quanto sembri. ## Il perimetro che si ferma ai dipendenti La clausola 7.3 parla di persone che lavorano sotto il controllo dell'organizzazione, formula che comprende somministrati, consulenti, contractor e personale di fornitori che operano dentro i vostri processi. Quasi tutti i piani si fermano al libro paga, perché è lì che arriva il sistema di gestione del personale da cui il piano viene costruito. L'auditor se ne accorge in modo indiretto, notando che una persona incontrata durante la visita non compare in nessun registro. Il caso tipico è l'agenzia esterna che gestisce il servizio clienti usando uno strumento assistito, dove le persone che usano il sistema ogni giorno non sono vostre e nessun piano formativo le copre. L'unico strumento che funziona qui è il contratto, che deve prevedere requisiti di competenza e l'obbligo di fornire evidenza del loro soddisfacimento. ## Come emergono in audit | Errore | Come emerge | Evidenza che lo previene | |---|---|---| | Piano diverso dall'erogato | Confronto tra piano e registri di partecipazione | Registri aggiornati e piano rivisto a ogni variazione del programma | | Evidenze generiche | Richiesta di collegare attestati e ruoli | Attestati con contenuti dettagliati, collegati alla matrice dei ruoli | | Efficacia non valutata | Domanda su come è stata verificata la competenza acquisita | Casi pratici corretti, lavori rivisti, verifiche sul campo con esito registrato | | Piano fermo nel tempo | Confronto tra data del piano, inventario e organigramma | Inneschi documentati per nuovi sistemi e nuovi ingressi | | Approvazione senza comprensione | Domande dirette a chi ha firmato | Verbali della formazione della direzione e delle decisioni successive | | Perimetro limitato ai dipendenti | Persone incontrate in visita e assenti dai registri | Requisiti di competenza nei contratti con fornitori e agenzie | ## Il campione dell'auditor Il campionamento non è casuale, e sapere come viene costruito permette di simularlo in anticipo. L'auditor parte dalla matrice dei ruoli e sceglie tre o cinque persone su profili diversi, privilegiando tre categorie: chi esercita la supervisione umana su un sistema rilevante, chi è entrato da poco, chi ha firmato un'approvazione. Le domande sono semplici e quasi sempre le stesse. Qual è la politica AI dell'azienda e dove si trova. Cosa fa il sistema che usi ogni giorno. Cosa faresti se ti accorgessi che sta sbagliando. A chi lo segnaleresti. Quando la persona campionata non sa rispondere, la non conformità non riguarda lei. Riguarda il sistema di gestione, che ha previsto un'azione formativa senza verificarne l'efficacia, il che riporta al terzo errore di questo elenco. ## Quando il rilievo blocca il certificato Non tutti i rilievi pesano allo stesso modo, e la differenza determina se la certificazione arriva o slitta. Una non conformità minore è un'attuazione parziale di un requisito, un caso isolato, un'evidenza mancante su una persona. Si tratta con un piano di azione correttiva da presentare di norma entro tre mesi, e non blocca il rilascio del certificato. Sale a maggiore quando manca sistematicamente un requisito, o quando un fallimento compromette la capacità del sistema di raggiungere i propri obiettivi. L'assenza totale di valutazione dell'efficacia, ripetuta su tutti i moduli, ha le caratteristiche per esserlo, e in quel caso il certificato non viene emesso finché il rilievo non è chiuso e verificato, spesso con una visita aggiuntiva. La distinzione pratica è tra un errore che si ripete e un errore isolato. Un attestato generico su una persona è un caso. Attestati generici su tutte le persone sono un processo che non funziona. ## Un esempio ipotetico Un responsabile di funzione ha firmato come completata la formazione del suo team su un sistema AI di supporto alle vendite. Durante l'audit l'auditor gli chiede quali rischi del sistema il corso trattasse, come i collaboratori riconoscano un output da verificare e a chi segnalino un'anomalia. Alla terza domanda il responsabile ammette di non conoscere i contenuti del corso, e la non conformità riguarda sia l'evidenza della competenza sia il processo di approvazione. L'esempio è illustrativo e non descrive un caso reale. ## La stessa lacuna, in una sede diversa Un piano di formazione che non regge in audit ha da fine settembre un secondo luogo in cui può presentare il conto. Il decreto legislativo 160/2026, in vigore dal 30 settembre, consente al giudice di ordinare l'esibizione dei parametri e delle modalità di sorveglianza umana previsti dall'articolo 14 dell'AI Act, e stabilisce che la mancata esibizione senza giustificato motivo porta a considerare ammessi i fatti allegati da chi chiede il risarcimento. Dimostrare la sorveglianza umana significa anche dimostrare che chi la esercitava era in grado di farlo. Le evidenze generiche descritte sopra, il registro presenze senza verifica di efficacia e l'approvazione senza comprensione, sono esattamente ciò che in quella sede non permette di sostenere che il presidio esisteva davvero. Il difetto è lo stesso che fa scattare un rilievo in audit, con conseguenze di natura diversa. Chi prepara il piano per l'audit sta quindi preparando, senza saperlo, materiale che può servire altrove. Il contesto è descritto nell'articolo su [accesso alle prove e nesso causale nel D.Lgs. 160/2026](/blog/compliance/danni-ai-prove-nesso-causale-dlgs-160-2026). ## Prima dell'audit, un campionamento simulato La verifica più utile consiste nel fare quello che farà l'auditor, qualche settimana prima e su un campione costruito con gli stessi criteri. - Il piano corrisponde, modulo per modulo, a quanto risulta dai registri? - Ogni evidenza è collegata al ruolo della persona nella matrice? - Per ogni modulo, esiste una valutazione dell'efficacia distinta dal gradimento? - Esiste un meccanismo che aggiorna il piano quando entra un nuovo sistema o una nuova persona? - Chi approva la formazione ha seguito il percorso previsto per il suo livello? - I contractor con accesso ai sistemi compaiono nel piano o nei contratti? - Scelte tre persone con i criteri dell'auditor, sanno rispondere alle quattro domande tipiche? L'ultimo punto è quello che dà l'informazione più affidabile, e richiede mezz'ora. Se due persone su tre esitano, il problema non è il loro, ed è meglio scoprirlo adesso. ## Il passo successivo La prevenzione di tutti gli errori di questo elenco passa da una formazione collegata ai ruoli e ai sistemi. I livelli sono descritti in [la matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai), il coordinamento con l'AI Act in [AI literacy e competenze ISO 42001](/blog/compliance/ai-literacy-competenze-iso-42001), e i requisiti completi della clausola in [la clausola 7 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze). Se vuoi una verifica del tuo piano prima dell'audit, l'[AI Rating](/servizi/ai-rating) è il punto di partenza, oppure puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Lead Implementer vs Lead Auditor vs certificazione aziendale: tre percorsi diversi URL: https://zerofive.ai/blog/compliance/lead-implementer-auditor-certificazione-aziendale Data: 2026-09-22 Abstract: Lead Implementer, Lead Auditor e certificazione aziendale ISO/IEC 42001: chi viene certificato, chi rilascia, cosa attesta e in che ordine sceglierli. **In sintesi.** Dietro l'espressione "certificazione ISO 42001" ci sono tre percorsi distinti: Lead Implementer e Lead Auditor sono credenziali personali, che attestano rispettivamente la competenza a costruire un sistema di gestione dell'AI e quella a verificarlo. La certificazione aziendale riguarda invece l'organizzazione ed è rilasciata da un organismo accreditato dopo un audit sul sistema di gestione. I percorsi sono indipendenti: un'azienda può essere certificata senza persone con queste credenziali, e una persona può averle in un'azienda non certificata. Qui trovate chi serve davvero per gli audit interni, come rispondere a una gara senza sbagliare, e cosa si può scrivere nei materiali commerciali. La domanda "siete certificati ISO 42001?" compare sempre più spesso nei questionari dei clienti e nei capitolati di gara, e chi la pone non sempre sa quale dei tre percorsi ha in mente. Chi risponde, a sua volta, rischia di confondere una credenziale personale con la certificazione dell'organizzazione, con conseguenze che vanno dall'esclusione da una gara a una contestazione in fase di verifica. ## Tre percorsi con lo stesso nome | Percorso | Chi viene certificato | Chi rilascia | Cosa attesta | Come si ottiene | |---|---|---|---|---| | Lead Implementer | Una persona | Ente di certificazione del personale | Competenza a progettare, implementare e gestire un AIMS | Corso di più giorni ed esame | | Lead Auditor | Una persona | Ente di certificazione del personale | Competenza a pianificare e condurre audit su un AIMS | Corso di più giorni, esame ed esperienza di audit | | Certificazione aziendale | L'organizzazione, per un campo di applicazione definito | Organismo di certificazione accreditato | Conformità del sistema di gestione alla ISO/IEC 42001 | Audit in due fasi, sorveglianza periodica, rinnovo | La differenza che conta di più è nell'ultima colonna a sinistra. Le prime due righe certificano quello che una persona sa fare, la terza certifica quello che un'organizzazione ha effettivamente costruito, e sono affermazioni di natura diversa che il mercato tratta in modo diverso. ## La credenziale Lead Implementer La credenziale certifica una persona e si ottiene con percorsi formativi di più giorni con esame finale, erogati da enti di certificazione del personale, tra cui PECB, Exemplar Global e diversi organismi nazionali sono tra i più diffusi. Chi la possiede, in sostanza, ha dimostrato di conoscere i requisiti della norma e il modo di tradurli in un sistema di gestione funzionante, dalla politica AI alla valutazione dei rischi fino ai controlli dell'Annex A. È il percorso più coerente per chi deve guidare un'organizzazione nella costruzione pratica del sistema. Due aspetti pratici vengono spesso scoperti dopo l'iscrizione. Il primo è che molte credenziali hanno un mantenimento, con rinnovo periodico e crediti formativi da accumulare, e vanno considerate un costo ricorrente. Il secondo è che il valore della credenziale dipende dall'ente che la rilascia: prima di iscriversi conviene verificare che l'ente sia a sua volta accreditato secondo la ISO/IEC 17024, la norma sui requisiti per chi certifica le persone. ## Il ruolo del Lead Auditor Il percorso formativo ha una struttura simile ma forma una competenza diversa, cioè condurre audit interni o per conto di un organismo di certificazione e verificare la conformità di un sistema costruito da altri. Per lavorare come auditor di un organismo accreditato la credenziale non basta: bisogna essere selezionati, qualificati e incaricati da quell'organismo, che valuta anche l'esperienza di audit maturata sul campo e in molti casi richiede un affiancamento iniziale. Per questo il titolo raramente si mette a frutto in autonomia, mentre resta utile a chi lo usa all'interno della propria organizzazione. ## Certificare l'organizzazione Un'azienda ottiene la certificazione del proprio sistema di gestione attraverso l'audit di un organismo accreditato, secondo il percorso descritto in [certificazione ISO/IEC 42001 in Italia](/blog/compliance/certificazione-iso-42001-italia-accredia). Il certificato riguarda un campo di applicazione preciso, cioè i sistemi, i processi e le sedi dichiarati, e non si estende automaticamente al resto dell'attività. Avere in organico un Lead Implementer aiuta a prepararsi, ma l'organismo valuta il sistema, a prescindere dalle credenziali delle persone. Vale anche il contrario: un'azienda che ha costruito un buon sistema con il supporto di un consulente esterno può certificarsi senza avere nessuna credenziale personale al proprio interno. ## Chi conduce gli audit interni Qui si concentra l'equivoco più costoso, perché riguarda un requisito obbligatorio e non una scelta. La clausola 9.2 richiede audit interni a intervalli pianificati, e chiede due cose a chi li conduce: competenza adeguata e imparzialità rispetto all'area verificata. Non chiede una credenziale Lead Auditor. Un auditor interno competente e indipendente soddisfa il requisito anche senza titoli formali, purché la competenza sia dimostrabile con evidenze, che è lo stesso principio della clausola 7 applicato a un ruolo specifico. Il vincolo vero è l'imparzialità. Chi ha costruito il sistema di gestione non può verificare il proprio lavoro, il che significa che serve una seconda persona interna, oppure un auditor esterno incaricato per quella attività. È il motivo per cui molte organizzazioni formano due persone con ruoli separati, una che implementa e una che verifica, ed è una scelta organizzativa prima che formativa. ## Un esempio ipotetico Un fornitore di servizi digitali partecipa a una gara che assegna un punteggio aggiuntivo a chi possiede la "certificazione ISO/IEC 42001". Nel team c'è una persona con credenziale Lead Implementer, l'ufficio commerciale dichiara il requisito come posseduto e, in fase di verifica, la stazione appaltante chiede il certificato dell'organizzazione rilasciato da un organismo accreditato, che l'azienda non ha, e il punteggio viene tolto. L'esempio è illustrativo, e non descrive un caso reale. ## Come si risponde a una gara Prima di compilare la risposta conviene capire cosa il richiedente sta effettivamente chiedendo, perché la formulazione dei capitolati è spesso imprecisa quanto quella di chi risponde. Se il documento parla di certificazione dell'organizzazione, di sistema di gestione o chiede il numero di certificato, il riferimento è alla certificazione aziendale, e l'unica risposta corretta è possederla o dichiarare di non possederla. Se parla di personale qualificato, di competenze del team o di figure certificate, allora le credenziali personali sono pertinenti e vanno indicate con il nome esatto della credenziale e dell'ente che l'ha rilasciata. Quando il requisito è ambiguo, la richiesta di chiarimento in fase di gara costa molto meno di una contestazione successiva. E quando la certificazione aziendale manca ma il percorso è avviato, dichiararlo con precisione, indicando l'organismo scelto e la fase raggiunta, è una posizione difendibile, mentre l'affermazione generica non lo è. ## Cosa si può scrivere nei materiali Le formulazioni corrette costano quanto quelle imprecise e reggono a un controllo. Su una persona: certificata Lead Implementer ISO/IEC 42001, con indicazione dell'ente. Su un team: team con competenze certificate sulla ISO/IEC 42001. Su un'azienda che ha il certificato: sistema di gestione dell'AI certificato ISO/IEC 42001 da un organismo accreditato, con il campo di applicazione e il numero di certificato. Le formulazioni da evitare sono altrettanto chiare. Siamo certificati ISO 42001 detto in assenza del certificato aziendale. Azienda ISO 42001, che non significa nulla di verificabile. Conformi alla ISO 42001, che è un'autodichiarazione e va distinta dalla certificazione, anche quando corrisponde al vero. La differenza emerge esattamente nel momento in cui qualcuno chiede il documento, che è anche il momento peggiore per scoprirla. ## L'ordine delle scelte Per chi deve costruire un sistema di gestione il primo investimento sensato è la formazione Lead Implementer su una o due persone chiave, che guideranno il lavoro su documentazione, inventario e controlli. La certificazione aziendale arriva quando il campo di applicazione è maturo e il sistema ha prodotto evidenze per qualche mese, mentre la credenziale Lead Auditor ha senso per chi gestirà gli audit interni o intende collaborare con un organismo di certificazione. La dimensione dell'organizzazione sposta il calcolo. In una realtà piccola conviene spesso una sola persona formata come Implementer e un auditor interno esterno incaricato all'occorrenza, perché mantenere due competenze interne costa più di quanto renda. In una struttura articolata su più funzioni la separazione tra chi implementa e chi verifica diventa invece naturale, e formare entrambe le figure internamente si ripaga già dal primo ciclo di sorveglianza. Prima di rispondere a un questionario o a una gara conviene verificare quale dei tre percorsi viene richiesto e dichiarare con precisione quello che si possiede. ## La serie su ISO/IEC 42001 Questo articolo fa parte della serie di settembre dedicata a documentazione, formazione e certificazione: - [La documentazione minima di un AIMS](/blog/compliance/documentazione-minima-aims-iso-42001) - [AI system impact assessment: DPIA, AI Act e ISO/IEC 42001 a confronto](/blog/compliance/impact-assessment-dpia-ai-act-iso-42001) - [L'inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001) - [Progettare un sistema AI ISO-ready](/blog/compliance/progettare-sistema-ai-iso-ready) - [La clausola 7 di ISO/IEC 42001 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze) - [La matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai) - [AI literacy e competenze ISO 42001](/blog/compliance/ai-literacy-competenze-iso-42001) - [Gli errori che fanno bocciare un piano di formazione AI in audit](/blog/compliance/errori-piano-formazione-audit-ai) - [Corso AI obbligatorio e clausola 7](/blog/compliance/corso-ai-obbligatorio-non-basta) - [Certificazione ISO/IEC 42001 in Italia](/blog/compliance/certificazione-iso-42001-italia-accredia) - [Da oggi la documentazione AI è anche materiale di prova](/blog/compliance/documentazione-ai-difesa-dlgs-160-2026), in uscita il 30 settembre ## Il passo successivo ZeroFive non rilascia certificazioni: accompagniamo le aziende nella costruzione del sistema e nella preparazione all'audit, come descritto nella pagina [Compliance AI](/compliance-ai). Per capire da quale percorso partire puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive) oppure scrivere a hello@zerofive.ai. --- # Certificazione ISO/IEC 42001 in Italia: la mappa degli organismi accreditati Accredia URL: https://zerofive.ai/blog/compliance/certificazione-iso-42001-italia-accredia Data: 2026-09-21 Abstract: Certificazione ISO/IEC 42001 in Italia: perché conta l'accreditamento Accredia, la circolare DC 08/2026, gli organismi accreditati e le fasi dell'audit. **In sintesi.** Un certificato ISO/IEC 42001 ha peso in una due diligence, in una gara pubblica o davanti a un regolatore quando è rilasciato da un organismo accreditato, che in Italia significa accreditato da Accredia. L'accreditamento specifico per questa norma è stato reso possibile dalla circolare tecnica Accredia DC N° 08/2026, che integra la ISO/IEC 17021-1 con la ISO/IEC 42006. Qui trovate chi può certificare oggi, come si verifica un certificato altrui, cosa determina tempi e costi, e perché il campo di applicazione è la decisione che pesa più di tutte. Chiunque, in linea di principio, può emettere un documento che attesta la conformità a una norma ISO, e quello che cambia il valore di quel documento è l'accreditamento dell'organismo che lo rilascia. Per ISO/IEC 42001 in Italia l'accreditamento specifico è arrivato solo nel 2026. Prima di allora esistevano certificati emessi da organismi seri ma privi di quel riconoscimento formale. ZeroFive non è un organismo di certificazione e non rilascia certificati: accompagniamo le aziende nella preparazione al percorso, e sapere chi può certificare è il primo filtro nella scelta. ## Il valore dell'accreditamento L'accreditamento garantisce che l'organismo di certificazione sia stato a sua volta verificato secondo regole internazionali condivise, con competenze, imparzialità e procedure controllate. In Italia l'ente unico di accreditamento è Accredia, e un certificato accreditato è riconosciuto nelle gare, nelle verifiche dei clienti e nei rapporti con le autorità, mentre un certificato non accreditato resta un'attestazione privata. Il riconoscimento non si ferma ai confini nazionali. Gli accordi di mutuo riconoscimento internazionali fanno sì che un certificato rilasciato da un organismo accreditato da un ente estero firmatario abbia lo stesso valore di uno accreditato Accredia, il che conta quando si valuta un fornitore straniero. Quello che va verificato, in quel caso, è che l'ente di accreditamento sia effettivamente firmatario e che l'accreditamento copra ISO/IEC 42001 e non genericamente i sistemi di gestione. ## La circolare tecnica DC N° 08/2026 La circolare tecnica Accredia DC N° 08/2026, che ha aperto la strada all'accreditamento degli organismi per ISO/IEC 42001, integra i requisiti generali della UNI CEI EN ISO/IEC 17021-1, valida per tutti gli organismi che certificano sistemi di gestione, con quelli della ISO/IEC 42006, la norma che stabilisce i requisiti per chi verifica e certifica i sistemi di gestione dell'AI, compreso il riferimento ai controlli dell'Annex A e alla guida dell'Annex B della ISO/IEC 42001. Da quel momento gli organismi hanno potuto chiedere un accreditamento specifico. La conseguenza pratica riguarda anche i certificati emessi prima. Un'azienda certificata da un organismo che all'epoca non poteva essere accreditato per questa norma non ha un documento privo di valore, ha un documento che al primo rinnovo conviene ricondurre sotto accreditamento, perché è quello che i clienti inizieranno a chiedere. ## Gli organismi accreditati | Organismo | Nota | |---|---| | CSQA | Primo organismo accreditato in Italia per ISO/IEC 42001 | | Bureau Veritas | Accreditato | | DNV | Accreditato | | TÜV Italia | Accreditato | | ACM CERT | Accreditato | L'elenco riflette la situazione alla data di pubblicazione ed è destinato a crescere, per cui la fonte da consultare resta la banca dati di Accredia. ## Come si verifica un certificato Chi riceve il certificato di un fornitore e vuole capire quanto vale ha a disposizione una verifica che richiede pochi minuti, e che conviene rendere parte standard della qualifica fornitori. Il primo controllo è sulla banca dati Accredia, cercando l'organismo che ha emesso il documento e verificando che l'accreditamento riguardi specificamente ISO/IEC 42001. Il secondo è sul campo di applicazione riportato sul certificato, che va confrontato con l'attività per cui state valutando quel fornitore: un certificato valido per la sede di Milano non copre lo stabilimento in un altro paese, e un certificato che copre lo sviluppo software non copre necessariamente il sistema AI che il fornitore usa per gestire il vostro servizio. Il terzo è sulla data di validità e sullo stato, perché un certificato può essere stato sospeso o revocato nel frattempo, e sul documento cartaceo quell'informazione non compare. Il quarto, quando serve, è la richiesta diretta all'organismo, che conferma l'esistenza e lo stato del certificato. ## Il campo di applicazione, la decisione che pesa di più Lo scope è la parte del certificato che quasi nessuno discute abbastanza in fase di preparazione, ed è quella che ne determina l'utilità. Definirlo troppo ampio allunga l'audit, aumenta i giorni-uomo e quindi il costo, e soprattutto espone a rilievi su aree che non erano pronte. Definirlo troppo stretto produce un certificato tecnicamente valido e commercialmente poco utile, perché il cliente che lo legge cerca la copertura del sistema che lo riguarda e non la trova. Il criterio pratico è partire dai sistemi in inventario e da chi chiederà il certificato. Se la richiesta arriva da clienti che comprano un servizio specifico, lo scope deve coprire i sistemi AI che entrano in quel servizio, con la relativa struttura organizzativa. Allargare dopo è possibile, si fa in occasione di una sorveglianza o di un rinnovo, e costa meno che restringere. ## Le fasi dell'audit | Fase | Cosa verifica | Evidenze tipiche | |---|---|---| | Stage 1 | Esistenza e adeguatezza della struttura documentale dell'AIMS | Politica AI, campo di applicazione, valutazione dei rischi, dichiarazione di applicabilità | | Stage 2 | Applicazione effettiva del sistema | Interviste al personale, campioni di registri, evidenze di controllo sui sistemi in inventario | | Sorveglianza | Mantenimento nel tempo, di norma con cadenza annuale | Audit interni, riesame della direzione, azioni correttive | | Rinnovo | Conformità complessiva al termine del ciclo triennale | Storia del sistema nel triennio | La struttura è la stessa degli altri sistemi di gestione, come ISO/IEC 27001 e ISO 9001, e chi ha già vissuto quelle certificazioni ritrova una logica familiare, con contenuti tecnici diversi. Tra stage 1 e stage 2 passano di norma alcune settimane, che servono a chiudere le osservazioni emerse nella prima fase. È una finestra da usare, perché i rilievi dello stage 1 anticipano quasi sempre dove lo stage 2 andrà a guardare. ## Cosa determina tempi e costi Il preventivo di un organismo si costruisce sui giorni-uomo di audit, e i giorni-uomo dipendono da quattro variabili: il numero di persone coinvolte nel campo di applicazione, il numero di siti da visitare, la quantità e la criticità dei sistemi AI in inventario, e l'esistenza di altri sistemi di gestione già certificati con cui integrare la verifica. L'ultimo punto è quello che fa risparmiare di più. Un'azienda già certificata ISO/IEC 27001 può richiedere un audit integrato, dove le parti comuni alle due norme, dalla documentazione alla gestione delle non conformità al riesame della direzione, vengono verificate una volta sola. Il risparmio è concreto e riguarda anche il tempo delle persone interne, che è il costo meno visibile e spesso il più alto. Sul calendario, la variabile dominante non è l'audit ma la preparazione. La distanza tipica tra la decisione di certificarsi e lo stage 2 si misura in mesi, e dipende quasi interamente da quanto del sistema di gestione esiste già e funziona davvero. ## La distanza da 27001 e 9001 Chi arriva da altre certificazioni trova la struttura familiare e tre differenze sostanziali. La prima è l'oggetto. Un sistema AI cambia comportamento nel tempo, con il modello che viene aggiornato dal fornitore o riaddestrato internamente, mentre un asset informativo o un processo produttivo restano più stabili. Questo rende l'inventario dei sistemi un documento che si muove, non un allegato che si aggiorna una volta l'anno. La seconda è l'impact assessment sulle persone e sui gruppi, che non ha un equivalente diretto in 27001, dove l'analisi guarda agli asset e alla sicurezza dell'informazione. La terza è la presenza di una normativa che corre in parallelo. Un auditor ISO 9001 non deve tenere conto di un regolamento europeo in evoluzione, mentre su ISO/IEC 42001 il rapporto con l'AI Act è parte del contesto, ed è anche il motivo per cui gli auditor con esperienza specifica valgono più di quelli generalisti. ## Un esempio ipotetico Un'azienda di software riceve da un fornitore la copia di un certificato ISO/IEC 42001 e lo allega alla documentazione di una gara. In fase di verifica la stazione appaltante chiede se l'organismo sia accreditato per quella norma, e il controllo sulla banca dati Accredia dà esito negativo: il certificato è autentico, ma non ha il valore che la gara richiedeva. L'esempio è illustrativo e non descrive un caso reale. ## Cosa il certificato non copre Dal 30 settembre 2026 è in vigore il decreto legislativo 160/2026, il cui articolo 19 stabilisce che la conformità agli obblighi dell'AI Act, anche quando è certificata con le procedure di valutazione previste dal regolamento, non esclude di per sé la responsabilità in un'azione di risarcimento. La norma parla della certificazione prevista dall'AI Act, e la stessa logica riguarda qualunque attestazione volontaria, compresa quella su ISO/IEC 42001. La distinzione è netta. Un certificato attesta che a una certa data, su un certo campo di applicazione, un organismo ha verificato l'esistenza di un sistema di gestione. In un contenzioso si discute invece di come un singolo sistema si è comportato in un caso specifico, e quella ricostruzione la forniscono i log, le evidenze di sorveglianza umana e le decisioni documentate, non l'attestato appeso in bacheca. Chi affronta il percorso di certificazione sapendo questo lo imposta diversamente: tiene insieme il certificato e le evidenze operative che lo stesso sistema produce ogni giorno, perché servono in due sedi diverse. Il quadro completo è nell'articolo su [accesso alle prove e nesso causale nel D.Lgs. 160/2026](/blog/compliance/danni-ai-prove-nesso-causale-dlgs-160-2026). ## Quando conviene rimandare La certificazione certifica un sistema che funziona, e non lo crea. Un'organizzazione che non ha un inventario dei sistemi aggiornato, o che ha politiche scritte e mai applicate, affrontando l'audit adesso rischia il percorso più caro di tutti: rilievi in stage 2, azioni correttive sotto pressione, una visita aggiuntiva, e un sistema costruito in fretta per superare la verifica invece che per governare i rischi. Il segnale che il momento è arrivato è semplice da riconoscere. Esiste un inventario aggiornato negli ultimi mesi, esistono valutazioni del rischio firmate da persone con un nome, esiste un piano di formazione con evidenze collegate ai ruoli, ed esiste almeno un riesame della direzione documentato. Quando questi quattro elementi ci sono, l'audit verifica qualcosa che esiste già. Quando mancano, i mesi spesi a costruirli prima valgono più dei mesi spesi a rincorrere i rilievi dopo. ## Le domande da fare a un organismo - L'organismo è accreditato Accredia, o da un ente firmatario degli accordi di mutuo riconoscimento, specificamente per ISO/IEC 42001? - Il campo di applicazione proposto coincide con i sistemi che l'azienda intende certificare? - Gli auditor assegnati hanno esperienza su sistemi AI comparabili? - Come sono organizzati tempi e costi per stage 1, stage 2 e sorveglianza? - È possibile integrare l'audit con le certificazioni già in essere, e con quale risparmio di giorni? - Cosa succede in caso di non conformità maggiori emerse in stage 2, e con quali tempi di chiusura? - Quanto preavviso serve per programmare lo stage 1, considerati i vostri tempi di agenda? ## Il passo successivo Arrivare all'audit con un sistema che funziona richiede documentazione, inventario e formazione coerenti. Il punto di partenza è [la documentazione minima di un AIMS](/blog/compliance/documentazione-minima-aims-iso-42001), seguito dall'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), mentre i rilievi più frequenti sulla formazione sono in [gli errori che fanno bocciare un piano di formazione AI](/blog/compliance/errori-piano-formazione-audit-ai). Il nostro approccio alla preparazione è descritto nella pagina [Compliance AI](/compliance-ai). Per capire quanto sei distante dall'audit puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # AI literacy e competenze ISO 42001: un piano di formazione, due obblighi URL: https://zerofive.ai/blog/compliance/ai-literacy-competenze-iso-42001 Data: 2026-09-18 Abstract: Articolo 4 dell'AI Act dopo il Regolamento (UE) 2026/1744 e clausola 7 di ISO/IEC 42001 a confronto: un solo piano di formazione per entrambi gli obblighi. **In sintesi.** L'obbligo di AI literacy dell'articolo 4 dell'AI Act e i requisiti di competenza della clausola 7 di ISO/IEC 42001 toccano in larga parte le stesse persone, e gestirli come due progetti separati porta a pagare due volte la stessa base formativa. Il Digital Omnibus ha riscritto l'articolo 4 trasformandolo da obbligo di risultato a obbligo di mezzi, senza però toccare i requisiti di competenza previsti per chi esercita la supervisione umana sui sistemi ad alto rischio. Un solo piano mappato sui ruoli, con l'indicazione di quale obbligo copre ciascun modulo, risponde a entrambi. Nelle aziende che affrontano insieme AI Act e certificazione ISO/IEC 42001, la formazione nasce spesso da due uffici diversi: l'ufficio legale parte dall'articolo 4, il responsabile qualità dalla clausola 7. I due percorsi finiscono con fornitori, budget e calendari separati, e nessuno controlla quanto si sovrappongono finché qualcuno non confronta i programmi. ## Due obblighi con origini diverse L'articolo 4 dell'AI Act è applicabile dal 2 febbraio 2025 e riguarda fornitori e deployer. È una norma di legge, con autorità nazionali di vigilanza del mercato incaricate di farla rispettare, e vale anche per le organizzazioni che non perseguono alcuna certificazione. La clausola 7 di ISO/IEC 42001 nasce invece da uno standard volontario, e chiede di determinare le competenze necessarie per ciascun ruolo dentro un sistema di gestione documentato, di assicurarle, di valutare l'efficacia delle azioni intraprese e di conservarne le evidenze. Chi la applica lo fa perché ha scelto di certificarsi, o perché vuole un metodo che regga in una due diligence. ## Cosa è cambiato il 27 luglio Il Regolamento (UE) 2026/1744, il Digital Omnibus sull'AI, è stato pubblicato in Gazzetta Ufficiale dell'Unione il 24 luglio 2026 ed è in vigore dal 27 luglio. All'articolo 1, punto 5, sostituisce integralmente l'articolo 4 dell'AI Act. La versione originaria chiedeva a fornitori e deployer di adottare misure per assicurare, nella misura del possibile, un livello sufficiente di alfabetizzazione in materia di AI del proprio personale. Il testo nuovo chiede di adottare misure per sostenere lo sviluppo dell'alfabetizzazione, e aggiunge una precisazione esplicita: la norma non impone di garantire uno specifico livello di alfabetizzazione in capo a ciascun individuo. La differenza tecnica è il passaggio da un'obbligazione di risultato a un'obbligazione di mezzi. Restano immutati i criteri con cui le misure vanno calibrate: conoscenze tecniche, esperienza, istruzione e contesto d'uso dei sistemi. ## L'alleggerimento che non vale per tutti Letto in fretta, il nuovo articolo 4 sembra togliere pressione a chiunque. Sposta il piano della verifica, senza toglierlo, e per una parte delle organizzazioni non cambia praticamente nulla. Gli obblighi che riguardano le persone incaricate della supervisione umana sui sistemi ad alto rischio non sono stati toccati. Chi affida a una persona il compito di sorvegliare un sistema di questo tipo deve assicurarsi che abbia competenza, formazione e autorità adeguate, e questo requisito non è un'obbligazione di mezzi. Un'organizzazione con sistemi che ricadono nell'Allegato III si trova quindi con un obbligo generale alleggerito e un obbligo specifico intatto, esattamente sul personale più esposto. La conseguenza pratica è che l'alleggerimento riguarda soprattutto il perimetro largo, cioè la base di personale che usa strumenti a rischio contenuto. Sui ruoli critici la distanza tra articolo 4 e clausola 7 si riduce, invece di aumentare. ## Il confronto | Aspetto | AI literacy (AI Act, art. 4) | Competenza (ISO/IEC 42001, cl. 7.2 e 7.3) | |---|---|---| | Natura | Obbligo legale, di mezzi dopo il Digital Omnibus | Requisito di uno standard volontario | | Destinatari | Personale di fornitori e deployer e altre persone che usano i sistemi per loro conto | Persone che lavorano sotto il controllo dell'organizzazione e incidono sulle prestazioni dell'AIMS | | Contenuto | Misure di sostegno calibrate su competenze, esperienza, istruzione e contesto d'uso | Competenze determinate per ruolo, acquisite e verificate | | Livello individuale | Non deve essere garantito per il singolo | Determinato per ciascun ruolo | | Evidenze | Non prescritte in dettaglio | Informazioni documentate richieste dalla norma | | Efficacia | Non richiesta esplicitamente | Valutazione dell'efficacia obbligatoria | | Chi verifica | Autorità nazionali di vigilanza del mercato | Audit interni e organismo di certificazione | | Aggiornamento | Legato al contesto d'uso | Legato ai cambiamenti dell'AIMS e dei sistemi | ## Chi rientra nel perimetro Entrambe le norme guardano oltre il libro paga, e con formule simili. L'articolo 4 copre il personale e le altre persone che si occupano del funzionamento e dell'uso dei sistemi per conto del fornitore o del deployer. La clausola 7.3 parla di persone che lavorano sotto il controllo dell'organizzazione. In tutti e due i casi rientrano consulenti, somministrati, contractor e personale di fornitori che operano dentro i vostri processi. L'agenzia esterna che gestisce il servizio clienti con uno strumento assistito è dentro il perimetro di entrambi, e in entrambi i casi l'unico strumento per governarla è il contratto, perché su quelle persone non avete un piano formativo. Questo è anche il punto in cui i due obblighi si allineano meglio: un'organizzazione che ha già fatto la mappatura per la clausola 7 conosce già il proprio perimetro esteso, e non deve rifarla per l'articolo 4. ## Perché "contestuale" cambia cosa comprare La riscrittura dell'articolo 4 lascia in piedi il riferimento al contesto d'uso, e la rimozione del livello individuale sposta di fatto il baricentro proprio lì. Le misure si giudicano rispetto ai sistemi effettivamente in uso, ai ruoli che ci lavorano intorno, ai rischi che comportano. Questo rende poco utile il prodotto formativo più venduto del momento, cioè il corso generico sull'AI Act. Sapere come è strutturato il regolamento non aiuta un operatore a riconoscere quando lo strumento che usa ogni giorno sta sbagliando. Un'ora sul sistema che quella persona ha davanti vale più di quattro ore sulla norma, e risponde meglio a entrambi gli obblighi. ## I punti di contatto Entrambi chiedono una formazione calibrata sul ruolo e sul contesto d'uso, ed entrambi finiscono per riguardare le persone che decidono l'adozione, usano gli strumenti o ne valutano i rischi. Un piano costruito sulla [matrice ruoli-competenze](/blog/compliance/matrice-ruoli-competenze-ai) copre già buona parte di quello che l'articolo 4 chiede. ## Le differenze che restano L'AI literacy è un pavimento, che si applica anche a chi non ha e non intende avere un sistema di gestione, mentre la competenza ISO 42001 richiede evidenze verificabili collegate ai rischi dei sistemi in inventario. Un'organizzazione può rispettare l'articolo 4 restando lontana dalla clausola 7; il contrario è difficile, perché chi soddisfa la clausola 7 ha già coperto nei fatti l'alfabetizzazione del personale coinvolto. Due requisiti della clausola 7 non hanno un equivalente nell'articolo 4. Il primo è la valutazione dell'efficacia delle azioni formative, che obbliga a misurare l'esito e non solo l'erogazione. Il secondo è il meccanismo di aggiornamento innescato dai cambiamenti del sistema di gestione o dei sistemi in uso. Chi costruisce il piano solo per l'articolo 4 tende a saltarli entrambi, e sono proprio quelli che rendono un piano utile oltre la data dell'audit. ## Mappare i moduli sugli obblighi Il metodo consiste nel mappare ogni modulo del piano sugli obblighi che soddisfa. Nella pratica la struttura che funziona ha tre strati. Uno strato di base per tutto il personale toccato da un sistema AI, breve, centrato su cosa fa il sistema che usano, dove finisce la responsabilità del sistema e comincia la loro, e a chi segnalare un'anomalia. Risponde all'articolo 4 e, per i ruoli non critici, alla consapevolezza della clausola 7.3. Uno strato per ruolo, costruito sulla matrice, che risponde alla competenza della 7.2 e che per i ruoli operativi copre anche l'articolo 4 con maggiore profondità di quanto servirebbe. Uno strato specialistico per chi conduce valutazioni del rischio, chi esercita la supervisione umana sui sistemi ad alto rischio e chi risponde delle decisioni. Qui l'evidenza deve essere individuale e verificabile, perché è il punto in cui gli obblighi specifici sulla supervisione umana e i requisiti della clausola 7 chiedono la stessa cosa. La mappatura va conservata, perché in un audit o in un'ispezione permette di mostrare rapidamente come l'azienda ha risposto a ciascun requisito. ## Cosa conserva chi non si certifica Un'organizzazione che non punta a ISO/IEC 42001 non ha obblighi documentali dettagliati sull'articolo 4, il che non equivale a non dover mostrare nulla. Un'autorità che chieda conto delle misure adottate si aspetta di vedere qualcosa di più di un'affermazione. Il minimo ragionevole è un documento che descriva quali misure sono state adottate e per quali gruppi di personale, l'elenco dei sistemi AI in uso a cui quelle misure si riferiscono, la traccia di quando sono state erogate e a chi, e una data di riesame. Sono quattro elementi che una funzione HR produce in una settimana, e che trasformano una dichiarazione in una posizione difendibile. ## Un esempio ipotetico Un gruppo industriale ha due progetti di formazione AI aperti, affidati a fornitori diversi e con budget separati, uno avviato dall'ufficio legale per l'articolo 4 e l'altro dalla funzione qualità per la certificazione ISO 42001. Mappando i moduli sui ruoli emerge che gran parte dei contenuti si sovrappone e che i due fornitori usano definizioni diverse di sistema ad alto rischio. Il gruppo unifica il piano, mantiene un fornitore per la parte generale e affida all'altro i moduli specialistici. L'esempio è illustrativo e non descrive un caso reale. ## Le domande prima di firmare con un fornitore - Quali moduli rispondono all'articolo 4 e quali alla clausola 7? - Le evidenze prodotte sono collegate al ruolo della persona? - I contenuti usano le definizioni dell'AI Act come modificato dal Digital Omnibus? - Quanta parte del programma riguarda i sistemi realmente in uso da noi, e quanta la norma in generale? - Come viene misurata l'efficacia, al di là del questionario di gradimento? - Chi aggiorna i contenuti quando cambiano i sistemi in uso? - Il nuovo piano tiene conto di quello che l'azienda ha già erogato? ## Gli errori più frequenti Il primo è leggere la modifica dell'articolo 4 come un rinvio. L'obbligo è applicabile dal febbraio 2025, la vigilanza nazionale è operativa, e un'organizzazione che non ha adottato alcuna misura non si trova in una posizione migliore dopo il Digital Omnibus. Il secondo è comprare il corso sulla norma invece che sul sistema, che produce personale in grado di citare l'articolo 6 e incapace di accorgersi che uno strumento sta restituendo esiti anomali. Il terzo è trattare l'articolo 4 e la clausola 7 come se il primo fosse un sottoinsieme della seconda in ogni punto. Per il perimetro largo è quasi vero, per i ruoli di supervisione lo è meno di quanto sembri, perché gli obblighi specifici dell'AI Act su quelle persone restano pieni. L'ultimo è costruire il piano senza sapere quali sistemi AI sono effettivamente in uso. Senza l'[inventario dei sistemi](/blog/compliance/inventario-sistemi-ai-iso-42001) il contesto d'uso è un'ipotesi, e la formazione calibrata sul contesto diventa formazione calibrata su un'idea del contesto. ## Il passo successivo Prima di sdoppiare il budget conviene confrontare i programmi esistenti sulla matrice dei ruoli. I requisiti completi sono in [la clausola 7 di ISO/IEC 42001 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze), e la costruzione dei livelli è in [la matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai). L'approccio con cui impostiamo i percorsi è descritto nella pagina [AI Training](/servizi/ai-training). Per verificare le sovrapposizioni nel tuo piano puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Chi deve essere formato e su cosa: la matrice ruoli-competenze per l'AI URL: https://zerofive.ai/blog/compliance/matrice-ruoli-competenze-ai Data: 2026-09-17 Abstract: Matrice ruoli-competenze per la formazione AI secondo ISO/IEC 42001: board, risk owner, utenti operativi, formati, evidenze per l'audit e aggiornamenti. **In sintesi.** Un piano di formazione AI costruito per reparto forma due volte alcune persone e ne lascia scoperte altre. La clausola 7 di ISO/IEC 42001 chiede competenze legate al ruolo, e per la maggior parte delle organizzazioni bastano tre livelli: chi governa e approva, chi possiede il rischio di un sistema specifico, chi usa gli strumenti nel lavoro quotidiano. La matrice ruoli-competenze collega ogni ruolo a ciò che deve saper fare, al formato della formazione, all'evidenza da conservare per l'audit e alla frequenza di aggiornamento. Dopo aver capito che la clausola 7 chiede più di un corso uguale per tutti, molte aziende passano a percorsi diversi ma continuano a decidere i contenuti per dipartimento. Capita così che un responsabile di processo e un addetto dello stesso ufficio seguano lo stesso corso, anche se rispetto al sistema AI uno decide e l'altro esegue, mentre persone di altri reparti che firmano valutazioni di rischio restano fuori dal percorso giusto. Il criterio che funziona guarda a ciò che la persona deve decidere o fare rispetto a un sistema specifico, e l'organigramma diventa un dato di partenza da incrociare con l'inventario. ## I livelli di competenza Il board e l'alta direzione approvano l'adozione dei sistemi, accettano i rischi residui e rispondono delle scelte davanti a soci e autorità. I risk owner sono le persone a cui è assegnato il rischio di un sistema preciso, tengono aggiornata la valutazione e avviano l'escalation quando qualcosa cambia. Gli utenti operativi usano gli strumenti ogni giorno, e sono il punto in cui un errore del sistema diventa un errore del processo. Ogni livello richiede una profondità diversa, e un corso unico annoia il primo gruppo e lascia impreparato il terzo, e nessuno dei due problemi emerge finché un auditor non comincia a fare domande. ## La matrice | Ruolo | Cosa deve saper fare | Formato | Evidenza per l'audit | Aggiornamento | |---|---|---|---|---| | Board e alta direzione | Leggere un rating AI, chiedere perché un rischio è stato accettato, capire le responsabilità legate all'approvazione | Sessione di alcune ore su casi aziendali | Verbale con domande poste e decisioni prese | Annuale e a ogni nuovo sistema ad alto rischio | | Risk owner | Condurre e aggiornare la valutazione del rischio, riconoscere un cambiamento sostanziale, attivare l'escalation | Laboratorio operativo sui sistemi in inventario | Valutazioni firmate e aggiornate, escalation registrate | A ogni modifica del sistema e almeno una volta l'anno | | Utenti operativi | Riconoscere quando un output richiede verifica, sapere a chi segnalare un'anomalia | Moduli brevi nel contesto dello strumento | Registro di partecipazione collegato al ruolo, verifica pratica | All'adozione e a ogni cambio di versione | | Funzioni di controllo | Verificare la coerenza tra inventario, rischi e controlli | Percorso tecnico e normativo | Piano di audit interno e rapporti | Annuale | | Contractor con accesso ai sistemi | Rispettare procedure e limiti d'uso definiti | Clausole contrattuali e briefing | Accettazione documentata | A ogni rinnovo del contratto | ## Il board Chi siede in consiglio non deve saper leggere un modello, deve saper leggere un rapporto di rating AI e chiedere perché un certo rischio è stato accettato invece che mitigato, con la consapevolezza di cosa comporta firmare un'approvazione senza aver posto quella domanda. La formazione a questo livello dura ore e si misura sulla qualità delle domande che il board pone nelle riunioni successive, più che sui minuti di corso completati. ## I risk owner Un risk owner non può limitarsi a firmare una valutazione preparata da un consulente esterno. Deve riconoscere quando il sistema che possiede è cambiato abbastanza da richiedere un'analisi nuova, per esempio dopo un aggiornamento del modello o un'estensione a una nuova categoria di utenti, e deve sapere come attivare l'escalation prima che il problema emerga da solo. Qui la formazione lavora sui sistemi presenti nell'inventario aziendale, perché gli esempi generici non preparano a riconoscere i segnali del proprio contesto. ## Gli utenti operativi L'operatore che usa uno strumento assistito dall'AI ha bisogno di sapere quando un output richiede una verifica umana prima di procedere e a chi segnalare un comportamento anomalo, con esempi presi dal suo lavoro. È il livello più numeroso e spesso il più trascurato, anche se è quello a contatto quotidiano con l'errore reale. ## Un esempio ipotetico Una compagnia assicurativa con quattro sistemi AI in inventario, tra cui uno che assiste la valutazione dei sinistri, costruisce la matrice incrociando l'organigramma con l'elenco dei sistemi. Il responsabile liquidazioni, che in un piano per reparto avrebbe seguito il corso degli utenti, risulta risk owner del sistema sui sinistri e passa al laboratorio sulla valutazione del rischio, mentre i liquidatori del suo team ricevono moduli brevi sulla verifica degli output e sulla segnalazione delle anomalie. L'esempio è illustrativo e non descrive un caso reale. ## Errori da evitare - Assegnare i contenuti in base al reparto senza guardare al ruolo rispetto al sistema. - Trattare il board come destinatario secondario perché la sua formazione è breve. - Dimenticare i contractor che operano sui sistemi. - Registrare la presenza senza collegarla al ruolo ricoperto. - Costruire la matrice una volta e non aggiornarla quando cambiano persone o sistemi. ## Il passo successivo La matrice parte dall'elenco dei sistemi e dei ruoli che li toccano, e il metodo per costruirlo è nella guida all'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), mentre i requisiti completi della clausola 7 sono descritti in [la clausola 7 di ISO/IEC 42001 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze). L'approccio con cui impostiamo i percorsi per ruolo è descritto nella pagina [AI Training](/servizi/ai-training). Per costruire la matrice sulla tua organizzazione puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Danni da sistemi di AI: accesso alle prove e nesso causale nel D.Lgs. 160/2026 URL: https://zerofive.ai/blog/compliance/danni-ai-prove-nesso-causale-dlgs-160-2026 Data: 2026-09-16 Abstract: D.Lgs. 160/2026 e danni da AI: esibizione di log e documentazione, nesso causale presunto, limiti della conformità e azione diretta verso l'assicuratore. **In sintesi.** Il decreto legislativo 160/2026, in vigore dal 30 settembre, cambia il modo in cui si discute in tribunale di un danno causato da un sistema di intelligenza artificiale. Il giudice può ordinare di esibire log, documentazione tecnica, gestione dei rischi e parametri di sorveglianza umana, e se quei documenti non arrivano senza un giustificato motivo i fatti allegati dal danneggiato si considerano ammessi. Quando il danno deriva da una violazione dell'AI Act il nesso causale è presunto, mentre la conformità, anche certificata, non basta da sola a escludere la responsabilità. Per un'azienda che usa AI la documentazione di governance diventa materiale di prova. Il 15 settembre 2026 la Gazzetta Ufficiale n. 214 ha pubblicato il decreto legislativo 9 settembre 2026, n. 160, un altro pezzo dell'adeguamento italiano al Regolamento (UE) 2024/1689. Il testo tiene insieme due materie lontane, l'uso dell'AI da parte delle Forze di polizia, che occupa la prima metà, e la responsabilità civile e penale legata ai sistemi di AI, che riguarda direttamente le imprese. Della parte penale, con il nuovo articolo 437-bis del codice penale e l'articolo 25-vicies del decreto 231, ci occupiamo nell'[articolo aggiornato sul D.Lgs. 231/2001](/blog/compliance/dlgs-231-articolo-25-vicies-ai). Qui guardiamo agli articoli da 16 a 20, gli strumenti processuali civili per chi chiede il risarcimento di un danno: cinque articoli brevi che interessano chi firma i contratti con i fornitori, approva le polizze e risponde al consiglio di amministrazione, anche senza essere avvocato. ZeroFive non è uno studio legale, per cui descriviamo il testo e le sue conseguenze organizzative, lasciando l'interpretazione a giurisprudenza e dottrina. ## Il perimetro delle nuove regole L'articolo 16 distingue due livelli. Le regole sull'accesso alle prove valgono per tutte le azioni di risarcimento, contrattuali ed extracontrattuali, per danni cagionati nell'utilizzo di un sistema di AI, qualunque sia la sua classe di rischio, mentre la presunzione del nesso causale e la regola sulla conformità si applicano solo quando il danno deriva dalla violazione di uno o più obblighi dell'AI Act. Restano ferme due discipline parallele, il risarcimento previsto dall'articolo 82 del GDPR e la futura norma italiana di recepimento della direttiva (UE) 2024/2853 sulla responsabilità per prodotti difettosi, che include il software e va recepita entro il 9 dicembre 2026. Per le persone fisiche che agiscono fuori dalla propria attività professionale il decreto aggiunge la competenza del giudice del luogo di residenza o domicilio: un consumatore può fare causa vicino a casa, anche contro un'impresa che ha sede altrove. ## L'esibizione delle prove L'articolo 17 permette al giudice, su istanza di chi afferma di aver subito il danno, di ordinare all'altra parte o a un terzo l'esibizione degli elementi di prova relativi al funzionamento del sistema. La condizione è che l'istante presenti fatti ed elementi che rendano verosimile la domanda, compreso il collegamento tra il risultato prodotto dal sistema e il danno lamentato. Il testo indica quattro categorie di documenti, tutte già previste dall'AI Act. | Documento | Riferimento AI Act | Cosa permette di ricostruire | Chi lo tiene di norma | |---|---|---|---| | Registri automatici (log) | Art. 12 | Cosa ha fatto il sistema, quando e su quali input | Fornitore; il deployer conserva quelli sotto il proprio controllo (art. 26) | | Sistema di gestione dei rischi | Art. 9 | Quali rischi erano noti e con quali misure sono stati trattati | Fornitore | | Documentazione tecnica | Art. 11 | Come il sistema è stato progettato, addestrato e testato | Fornitore | | Parametri e modalità di sorveglianza umana | Art. 14 | Chi poteva intervenire, con quali strumenti e in quali casi | Fornitore per il disegno, deployer per l'attuazione | L'ordine deve restare limitato a quanto necessario e proporzionato, e il giudice tutela segreti commerciali e informazioni riservate richiamando l'articolo 121-ter del codice della proprietà industriale. La parte che non esibisce senza giustificato motivo si espone a due conseguenze di peso diverso: il giudice può desumerne argomenti di prova secondo l'articolo 116 del codice di procedura civile, e quando l'inadempimento riguarda proprio i documenti della tabella, valutato ogni altro elemento, ritiene come ammessi i fatti allegati dall'istante. Il terzo che non esibisce, per esempio un fornitore che conserva log a cui l'azienda cliente non ha accesso, rischia una pena pecuniaria da 1.500 a 10.000 euro. Per un'azienda è la norma con l'effetto più immediato. Un registro dei log che non esiste, o che esiste presso un fornitore senza clausole di accesso, smette di essere una lacuna da sistemare nel prossimo audit e diventa un fatto che il giudice può leggere contro chi avrebbe dovuto tenerlo. ## Il nesso causale presunto L'articolo 18 è una frase sola: quando il danno deriva dalla violazione di uno o più obblighi dell'AI Act, il nesso di causalità tra violazione e danno è presunto, salvo prova contraria. La formulazione ha una circolarità evidente, perché dà per acquisito che il danno derivi dalla violazione, e toccherà ai giudici stabilire quanto il danneggiato debba dimostrare prima che la presunzione operi. L'effetto atteso è uno spostamento dell'onere verso il convenuto, che dovrà provare un'origine diversa del danno. Diventa quindi rilevante sapere quali obblighi del regolamento sono già applicabili. Le pratiche vietate dell'articolo 5 e l'alfabetizzazione dell'articolo 4 valgono dal 2 febbraio 2025, gli obblighi sui modelli di AI per finalità generali dal 2 agosto 2025, la trasparenza dell'articolo 50 dal 2 agosto 2026. Gli obblighi per i sistemi ad alto rischio dell'Allegato III, dopo il Digital Omnibus (Regolamento (UE) 2026/1744), si applicano dal 2 dicembre 2027, quelli dell'Allegato I dal 2 agosto 2028: dal 30 settembre la presunzione lavora su un perimetro ridotto, che si allarga man mano che entrano in applicazione gli obblighi sull'alto rischio. ## La conformità come difesa parziale L'articolo 19 stabilisce che la conformità del sistema agli obblighi dell'AI Act, anche quando è certificata con le procedure di valutazione della conformità previste dal regolamento, non esclude di per sé la responsabilità del convenuto, fatto salvo quanto disporrà la norma di recepimento della direttiva sui prodotti difettosi. La regola parla della certificazione prevista dall'AI Act, e la sua logica si estende a qualunque attestazione volontaria, compresa una certificazione ISO/IEC 42001 del sistema di gestione. Un certificato racconta che a una certa data esisteva un insieme di controlli, mentre in giudizio si discute di come il sistema ha funzionato in quel caso specifico, e quella prova la forniscono i log, le evidenze di sorveglianza e le decisioni documentate. ## Polizza assicurativa e azione diretta L'articolo 20 riguarda il CFO prima ancora dell'ufficio legale. Chi intende agire può chiedere al presunto responsabile se ha una polizza di responsabilità civile che copre quel danno, e il destinatario deve rispondere entro trenta giorni indicando gli estremi del contratto e la compagnia assicurativa. La richiesta non condiziona la possibilità di fare causa, però una risposta omessa o incompleta può essere valutata dal giudice come argomento di prova. Il danneggiato ha poi azione diretta contro l'assicuratore, nei limiti del massimale, con il responsabile chiamato in giudizio come litisconsorte necessario. L'assicuratore può opporre le eccezioni contrattuali anteriori al sinistro e, dopo aver pagato, rivalersi sull'assicurato nella misura in cui avrebbe potuto rifiutare o ridurre la prestazione. Una polizza che esclude i danni da sistemi automatizzati, o che lega la copertura a controlli mai attuati, lascia l'azienda scoperta proprio quando la causa arriva. ## Un esempio ipotetico Un'azienda di servizi usa il sistema di AI di un fornitore esterno per smistare le richieste di assistenza e decidere quali pratiche passano a un operatore. Un cliente la cui richiesta è stata archiviata in automatico subisce un danno economico e chiede il risarcimento, allegando le comunicazioni ricevute e la tempistica della vicenda, così il giudice ordina di esibire i log delle decisioni e le modalità di sorveglianza umana. L'azienda scopre in quel momento che i log restano sui server del fornitore per trenta giorni, che il contratto non ne prevede il rilascio in caso di contenzioso e che la supervisione degli operatori non è mai stata descritta per iscritto. Il fornitore può essere chiamato a esibire come terzo, ma sulla sorveglianza umana l'azienda non ha nulla da produrre, e su quel punto i fatti allegati dal cliente rischiano di essere considerati ammessi. L'esempio è illustrativo, serve a mostrare il meccanismo e non descrive un caso reale. ## Le verifiche da fare adesso - Esiste un registro dei sistemi di AI in uso, con un responsabile per ciascuno e la classificazione di rischio secondo l'AI Act? - Per ogni sistema, chi conserva i log, per quanto tempo e in quale formato esportabile? - I contratti con i fornitori prevedono l'accesso a log, documentazione tecnica e gestione dei rischi in caso di contenzioso, con tempi compatibili con un ordine del giudice? - La sorveglianza umana è descritta per iscritto, con chi interviene, su quali segnali e con quale traccia dell'intervento? - Le polizze di responsabilità civile coprono i danni da sistemi di AI, e con quali esclusioni o condizioni? - Chi in azienda risponde entro trenta giorni a una richiesta sull'esistenza della copertura? - Il modello organizzativo 231 tiene conto del nuovo articolo 25-vicies? ## Il passo successivo Quasi tutte le domande della lista trovano risposta solo dopo un inventario dei sistemi e una fotografia delle evidenze che l'azienda produce davvero. Per il metodo puoi partire dalla guida all'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001) e da quella sulla [documentazione minima di un AIMS](/blog/compliance/documentazione-minima-aims-iso-42001), mentre il quadro degli obblighi per ruolo è nella [guida completa all'AI Act](/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati). Con l'[AI Rating](/servizi/ai-rating) misuriamo la maturità dell'azienda anche sulla dimensione AI Risk, che copre compliance, sicurezza e governance dei rischi. Per discutere il tuo caso puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive) oppure scrivere a hello@zerofive.ai. *Questo articolo descrive il testo normativo e le sue implicazioni organizzative, e non costituisce parere legale.* **Fonti.** Decreto legislativo 9 settembre 2026, n. 160, Gazzetta Ufficiale, Serie generale, n. 214 del 15 settembre 2026, articoli 16-20; Regolamento (UE) 2024/1689 (AI Act) come modificato dal Regolamento (UE) 2026/1744, articoli 4, 5, 9, 11, 12, 14, 26 e 50; Regolamento (UE) 2016/679, articolo 82; Direttiva (UE) 2024/2853; codice di procedura civile, articolo 116; decreto legislativo 10 febbraio 2005, n. 30, articolo 121-ter. --- # La clausola 7 di ISO/IEC 42001 spiegata senza gergo: competenze e consapevolezza URL: https://zerofive.ai/blog/compliance/clausola-7-iso-42001-competenze Data: 2026-09-15 Abstract: Clausola 7 ISO/IEC 42001 per intero: 7.1 risorse, 7.2 competenza, 7.3 consapevolezza, 7.4 comunicazione, 7.5 informazioni documentate. Evidenze e campionamento in audit. "La formazione AI l'abbiamo già fatta" è una frase che nella maggior parte dei casi significa un corso online di due ore, identico per tutti dal magazzino al risk management, senza traccia verificabile di chi lo abbia completato e senza alcun controllo su cosa sia rimasto utile al singolo ruolo. In sede di audit quella frase non regge, e il motivo non è la durata del corso. ## La clausola 7 ha cinque parti, non due Quasi tutti la conoscono come "la clausola della formazione". Nella struttura armonizzata che ISO/IEC 42001 condivide con ISO 27001 e ISO 9001, la clausola 7 si chiama Supporto e contiene cinque sotto-clausole: risorse (7.1), competenza (7.2), consapevolezza (7.3), comunicazione (7.4) e informazioni documentate (7.5). Chi prepara la certificazione lavorando solo su 7.2 e 7.3 copre due quinti del requisito e scopre le altre tre durante l'audit, quando non c'è più tempo per costruirle. Le tre ignorate sono anche quelle su cui è più facile produrre evidenza, perché in buona parte esistono già in altri sistemi di gestione dell'organizzazione. ## Le risorse prima delle persone La 7.1 chiede di determinare e fornire le risorse necessarie a stabilire, attuare, mantenere e migliorare il sistema di gestione. Il verbo che conta è determinare: l'organizzazione deve poter mostrare come è arrivata a stabilire che quelle risorse fossero quelle giuste, non solo che qualcosa è stato allocato. Nel contesto AI le risorse non sono soltanto persone. L'area A.4 dell'Annex A tratta specificamente le risorse per i sistemi AI e distingue dati, strumenti, risorse computazionali e risorse umane, chiedendo che siano identificate e documentate. Un sistema di gestione dichiarato senza che nessuno abbia tempo allocato per mantenerlo, o senza accesso ai dati necessari a valutare quello che si vuole valutare, è una dichiarazione di intenti. La domanda che un auditor pone qui è diretta: quante ore a settimana sono assegnate a chi tiene aggiornato il registro dei sistemi e conduce le valutazioni, e da quale decisione risultano. ## Cosa significa determinare una competenza La 7.2 si articola in quattro passaggi, e il terzo è quello che smonta l'equivalenza tra corso e competenza. L'organizzazione deve determinare la competenza necessaria per le persone il cui lavoro incide sulle prestazioni del sistema, assicurare che siano competenti, dove applicabile intraprendere azioni per acquisire la competenza mancante e valutare l'efficacia di quelle azioni, e conservare evidenza documentata. Valutare l'efficacia è un obbligo distinto dall'erogazione. Un registro di partecipazione dimostra che una persona era collegata, non che l'azione formativa ha prodotto l'effetto voluto. Serve qualcosa che misuri l'esito: un caso pratico svolto, un lavoro reale rivisto da qualcuno più esperto, una verifica sul campo a distanza di settimane. C'è un secondo elemento che quasi tutti trascurano. La norma riconosce la competenza acquisita tramite istruzione, formazione o esperienza. La congiunzione è alternativa, il che significa che l'esperienza pregressa vale come evidenza, purché sia documentata invece che presunta. ## Dimostrare competenza senza passare da un corso Per diversi ruoli la formazione formale è il percorso meno efficiente, e la norma non la impone. Le forme di evidenza che reggono in audit sono altre. L'esperienza documentata, quando alla persona è associata una descrizione di cosa ha effettivamente fatto e non solo un profilo professionale. Il campione di lavoro, cioè una valutazione del rischio o un impact assessment realmente condotti da quella persona, datati e firmati, che valgono più di qualsiasi attestato. La revisione tra pari, con un esito registrato. L'affiancamento strutturato, con una data di inizio, una di fine e una valutazione finale di chi affiancava. Le certificazioni esterne rientrano tra le opzioni, non le esauriscono, e da sole non dimostrano che la persona sappia applicare quelle nozioni ai sistemi specifici dell'organizzazione. ## Il perimetro della consapevolezza Secondo la 7.3, le persone che lavorano sotto il controllo dell'organizzazione devono conoscere la politica AI, capire in che modo contribuiscono all'efficacia del sistema di gestione e sapere cosa comporta non rispettarne i requisiti. L'espressione "sotto il controllo dell'organizzazione" è più larga di "dipendenti". Comprende somministrati, consulenti che operano dentro i vostri processi, contractor, e in molti casi il personale di fornitori che eseguono attività per vostro conto. L'agenzia esterna che gestisce il vostro servizio clienti usando uno strumento assistito rientra nel perimetro, e l'unico modo per governarla è il contratto, perché sulle persone di quell'agenzia non avete un piano formativo. Il contenuto della consapevolezza, per la maggior parte dei ruoli, si riduce a tre cose: cosa fa il sistema che usano, dove finisce la responsabilità del sistema e comincia la loro, e a chi segnalare un comportamento anomalo. Nessuno di loro deve saper costruire un modello. ## La comunicazione che quasi nessuno pianifica Determinare cosa comunicare a proposito del sistema di gestione, quando, a chi, come e chi se ne occupa: questo prevede la 7.4. È una sotto-clausola breve, ignorata quasi sempre, e con conseguenze concrete quando serve. Le domande a cui risponde sono operative. Chi risponde a un cliente che chiede se la decisione che lo riguarda è stata presa o suggerita da un sistema automatico, e con quale formulazione. Chi comunica all'interno che un sistema è stato sospeso, e in quanto tempo. Chi parla con un'autorità se arriva una richiesta. Questo si incrocia direttamente con gli obblighi di trasparenza dell'articolo 50 dell'AI Act, in vigore da agosto, che in diversi casi impongono di informare le persone che stanno interagendo con un sistema AI. Senza un piano, la risposta la improvvisa chi riceve la domanda per primo, che di solito è la persona meno attrezzata per darla. ## Mantenere e conservare sono verbi diversi La 7.5 distingue due obblighi che vengono regolarmente confusi. Alcune informazioni documentate vanno mantenute, cioè tenute aggiornate perché descrivono uno stato corrente: il campo di applicazione del sistema di gestione, la politica AI, le procedure. Altre vanno conservate, cioè trattenute come prova che qualcosa è accaduto: valutazioni del rischio completate, impact assessment, registri di formazione, esiti delle verifiche di efficacia. La 7.5.2 aggiunge come si creano e si aggiornano: identificazione, formato adeguato, riesame e approvazione prima dell'uso. La 7.5.3 aggiunge il controllo: disponibilità dove e quando serve, protezione da perdita o uso improprio, gestione delle versioni e degli accessi. La conseguenza pratica è netta. Un documento senza versione, senza data e senza evidenza di approvazione non è informazione documentata ai fini della norma, è un file. La distinzione si vede al primo campionamento, quando l'auditor chiede quale sia la versione in vigore di una procedura e ne circolano due leggermente diverse in due cartelle. ## Cosa succede davvero durante l'audit L'auditor non verifica tutte le persone. Ne campiona tre o cinque su ruoli diversi e fa domande semplici, di solito le stesse: qual è la politica AI dell'azienda e dove si trova, cosa fa il sistema che usi ogni giorno, cosa faresti se ti accorgessi che sta sbagliando, chi è il responsabile a cui lo segnaleresti. Quando la persona campionata non sa rispondere, la non conformità non riguarda quella persona. Riguarda il sistema di gestione, che ha previsto un'azione formativa senza verificarne l'efficacia. Per questo la verifica dell'efficacia conviene farla prima, e su un campione analogo a quello che userà l'auditor. Un secondo controllo ricorrente riguarda chi è entrato di recente. Se qualcuno lavora in azienda da tre mesi su un processo toccato da un sistema AI e non ha ricevuto nulla, il meccanismo di aggiornamento previsto dalla 7.2 non funziona, indipendentemente da quanto sia completo il piano per chi c'era prima. ## Gli errori più frequenti Il corso unico per tutti è il più visibile, ma non il più costoso. Il più costoso è trattare il registro delle presenze come evidenza di competenza, perché produce la sensazione di essere a posto fino al momento in cui l'auditor chiede la valutazione di efficacia e non esiste. Segue la consapevolezza limitata a chi scrive codice, che lascia scoperti proprio i ruoli dove le decisioni assistite da un sistema toccano persone reali. Poi il perimetro dei contractor, dimenticato perché non compare nei sistemi di gestione del personale. Poi le sotto-clausole 7.4 e 7.5, mai affrontate perché nessuno le associa alla parola formazione. L'ultimo è l'assenza di un innesco: nessun meccanismo che faccia scattare un aggiornamento quando una persona cambia ruolo o quando cambia il sistema che utilizza. Un piano costruito una volta e mai più toccato smette di essere valido nel momento in cui l'organizzazione si muove, e le organizzazioni si muovono. ## Il passo successivo Separare competenza e consapevolezza, assegnarle ai ruoli giusti e prevedere come si verificano è il lavoro che manca nella maggior parte delle aziende che dicono di aver già fatto la formazione. Il pezzo successivo entra nel dettaglio operativo con la matrice che collega ogni ruolo a quello che deve saper fare, e con il modo di tenerla allineata quando l'organizzazione cambia. --- # Budget di un progetto AI: costi dal pilota alla produzione URL: https://zerofive.ai/blog/strategia/budget-progetto-ai-pilota-produzione Data: 2026-09-12 Abstract: Come stimare il costo totale di un progetto AI: dati, licenze, integrazioni, supervisione e manutenzione, con scenari e domande per i fornitori. **Il budget di un progetto AI deve coprire il processo completo, non solo il modello.** Licenze e consumi sono una parte del costo: dati, integrazioni, valutazione, supervisione, formazione e manutenzione determinano la sostenibilità della produzione. Il pilota serve anche a misurare queste voci, prima di autorizzare un impegno più ampio. ## Perché il costo del pilota non è il costo della produzione Una dimostrazione può usare dati preparati, pochi utenti e controlli manuali. In produzione arrivano casi incompleti, utenti con permessi diversi, picchi di domanda e richieste di assistenza. Il lavoro cambia: occorrono disponibilità, monitoraggio, gestione delle eccezioni e manutenzione delle fonti. Non esiste un moltiplicatore universale tra pilota e produzione. Un progetto circoscritto può restare semplice; un’integrazione su processi critici richiede controlli diversi. Le stime vanno costruite sulle condizioni reali dell’azienda, distinguendo informazioni note e ipotesi. ## La tabella del costo totale | Voce | Costi iniziali | Costi ricorrenti | Cosa verificare | |---|---|---|---| | Dati | Pulizia, permessi, preparazione | Aggiornamento e controllo | Chi mantiene le fonti? | | Integrazione | Collegamenti e accessi | Compatibilità e modifiche | Quali sistemi possono cambiare? | | Modelli e strumenti | Configurazione | Licenze, consumi, archiviazione | Quali limiti contrattuali esistono? | | Valutazione | Campione e criteri | Test dopo modifiche | Chi decide se la qualità regge? | | Supervisione | Disegno dei controlli | Revisione ed eccezioni | Quanto tempo umano resta necessario? | | Formazione | Esercizi e materiali | Nuovi utenti e aggiornamenti | Le persone sanno gestire i casi dubbi? | | Operatività | Monitoraggio e ripristino | Assistenza e incidenti | Chi interviene e con quale priorità? | La struttura evita di trattare il lavoro interno come gratuito. Registra ore e competenze necessarie anche quando non generano una fattura esterna: possono sottrarre capacità ad altre attività. ## Un modello calcolabile Per un periodo definito, il costo totale è la somma di avvio, costi fissi, costi variabili, lavoro umano e manutenzione. Per confrontare alternative, usa lo stesso periodo e lo stesso perimetro. Se una proposta esclude integrazione o supervisione, rendilo visibile prima del confronto. Il costo per esito accettato divide il costo del processo per il numero di risultati effettivamente utilizzabili. Contare ogni generazione come un risultato utile nasconde tentativi, errori e revisioni. Per sistemi che richiamano strumenti o ripetono passaggi, considera anche il numero di operazioni per caso. ## Tre scenari, non una cifra unica Costruisci uno scenario contenuto, uno atteso e uno di pressione. Varia volumi, lunghezza dei documenti, numero di tentativi, percentuale di revisione e frequenza delle modifiche. Le variazioni devono avere una motivazione: dati storici, misure del pilota o un’ipotesi esplicitamente dichiarata. | Variabile | Perché influenza il budget | Evidenza utile | |---|---|---| | Volume | Aumenta consumi e lavoro | Domanda storica e stagionalità | | Complessità | Aumenta elaborazione e controlli | Distribuzione dei tipi di caso | | Rilavorazione | Riduce gli esiti utilizzabili | Correzioni osservate | | Aggiornamento | Richiede manutenzione e test | Frequenza di cambio delle fonti | | Adozione | Determina uso reale e supporto | Utenti attivi nel processo | ## Esempio ipotetico: assistente documentale Un’impresa valuta un assistente sulle procedure interne. Il budget iniziale comprende selezione delle fonti, permessi, configurazione e test. Il budget operativo comprende aggiornamento dei documenti, consumi, controllo delle risposte, assistenza e revisione degli accessi. Se cambiano spesso le procedure, il costo di mantenere fonti affidabili può essere più rilevante della singola richiesta al modello. Se molte risposte richiedono verifica, il tempo umano deve comparire nel calcolo. Questo esempio descrive una struttura di stima, non un preventivo o un risultato misurato. ## Collegare costo e beneficio Definisci la baseline prima del test. Misura il tempo complessivo, compresa la verifica, e separa capacità liberata da risparmio finanziario. Il beneficio deve avere un responsabile che spieghi come verrà utilizzato. Un miglioramento della qualità può giustificare un investimento anche senza ridurre il tempo, purché sia misurato e collegato a un obiettivo. La valutazione dei rischi resta parte della decisione. Il [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) offre una struttura per governare, mappare, misurare e gestire rischi; non fornisce prezzi o rendimenti standard. Non usare un ritorno economico elevato per ignorare un vincolo sui dati o un controllo necessario. ## Le domande da fare prima della firma - Quali attività sono incluse e quali restano al team interno? - Quali consumi sono misurati e quali soltanto stimati? - Cosa cambia se aumentano volumi o complessità? - Chi paga e realizza i test dopo un aggiornamento? - Come si esportano dati, configurazioni e documentazione? - Quali condizioni consentono di interrompere o ridimensionare il servizio? - Quale soglia richiede una nuova approvazione di spesa? ## Finanziare per decisioni successive Separa il budget di esplorazione, validazione e produzione. Ogni passaggio deve avere evidenze attese, limiti di spesa e un responsabile della decisione. Il gate [PROTOT.AI](/protot-ai) serve a validare prima di impegnare risorse per la produzione; [AI Strategy](/servizi/ai-strategy) collega le iniziative alle priorità. Leggi anche [cosa deve consegnare una consulenza AI](/blog/strategia/consulenza-ai-cosa-deve-consegnare) e [come scegliere il primo caso d’uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso). Per discutere vincoli e ipotesi del tuo progetto, [fissa un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # AI transformation: processi, responsabilità e indicatori di risultato URL: https://zerofive.ai/blog/strategia/ai-transformation-processi-responsabilita-indicatori Data: 2026-09-12 Abstract: Come misurare la trasformazione AI: baseline, responsabilità, qualità, costi ed eccezioni. Una guida per passare dagli strumenti ai risultati. **AI transformation significa cambiare come un’organizzazione produce risultati, prende decisioni e risponde degli esiti.** Distribuire strumenti è un’attività abilitante; la trasformazione si vede quando cambiano processi, responsabilità e misure. Il punto di partenza è una baseline del lavoro attuale, non il numero di licenze attivate. ## Tre livelli da distinguere | Livello | Cosa cambia | Evidenza utile | |---|---|---| | Uso individuale | Preparazione di un’attività | Qualità e tempo del singolo compito | | Automazione | Esecuzione di un passaggio | Tempi, errori e rilavorazioni del passaggio | | Trasformazione | Processo completo e decisioni | Risultato complessivo, costo e responsabilità | I tre livelli possono coesistere. Un assistente personale non è un progetto minore: può essere la risposta corretta. Diventa trasformazione quando il suo utilizzo modifica passaggi tra funzioni, criteri di approvazione o modalità di erogazione del servizio. ## Disegnare il processo prima dell’organigramma Mappa ingresso, attività, decisioni, verifiche e uscita. Per ogni passaggio chiedi quali informazioni servono, chi le possiede e come si gestiscono le eccezioni. La qualità finale dipende anche da attese, autorizzazioni e dati mancanti: accelerare la scrittura di una risposta serve poco se la risposta aspetta giorni per un’approvazione. La nuova configurazione deve conservare un responsabile del risultato. Il sistema può suggerire, classificare o eseguire azioni delimitate; l’organizzazione continua a decidere finalità, limiti e controlli. Il [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) offre un riferimento per collegare governance, contesto, misurazione e gestione dei rischi. ## La matrice delle responsabilità | Ruolo | Decisione di cui risponde | Evidenza da mantenere | |---|---|---| | Sponsor | Priorità e investimento | Obiettivi e vincoli approvati | | Responsabile di processo | Risultato operativo | Baseline, indicatori e gestione eccezioni | | Responsabile dati | Uso e qualità delle fonti | Accessi, provenienza e regole di aggiornamento | | Responsabile tecnico | Disponibilità e modifiche | Versioni, test e monitoraggio | | Funzioni di controllo | Valutazioni di competenza | Rischi, verifiche e azioni concordate | | Utenti | Uso entro le regole | Segnalazioni e correzioni | Sono ruoli da assegnare, non necessariamente nuove assunzioni. Nelle organizzazioni piccole una persona può coprire più ruoli, purché siano chiari i conflitti e i controlli necessari. Il trasferimento di competenze va verificato con attività svolte autonomamente, non solo con la partecipazione a un corso. ## Misurare il risultato, non l’attività Una baseline descrive un periodo e un campione: volumi, mix di casi, tempo, errori e risorse. Dopo l’introduzione dell’AI, confronta condizioni quanto più possibile equivalenti. Un mese con richieste più semplici non dimostra un miglioramento del sistema. | Indicatore | Come leggerlo | Limite | |---|---|---| | Tempo complessivo | Dall’ingresso alla chiusura | Comprende attese non dipendenti dall’AI | | Qualità al primo passaggio | Casi conclusi senza correzione | Richiede una definizione condivisa di errore | | Costo per caso completato | Costi del processo divisi per esiti accettati | Deve includere supervisione e manutenzione | | Eccezioni | Casi che richiedono intervento | Un aumento può riflettere rilevazione migliore | | Adozione effettiva | Uso nel processo previsto | Gli accessi non equivalgono a valore | Il tempo liberato non è automaticamente risparmio economico. Indica come viene utilizzato: più capacità, maggiore qualità, minore arretrato o riduzione di un costo effettivo. Evita di sommare lo stesso beneficio in categorie diverse. ## Esempio ipotetico: gestione di una richiesta Un servizio introduce AI per estrarre informazioni e preparare una bozza. Il tempo di stesura diminuisce, ma aumenta quello di controllo perché le fonti non sono visibili. Il risultato di processo potrebbe restare invariato. La decisione utile è migliorare tracciabilità e gestione delle eccezioni, non estendere immediatamente l’uso. Nella configurazione successiva, l’operatore vede le fonti, può correggere l’estrazione e segnala i casi dubbi. Il confronto va ripetuto includendo tempo di verifica ed errori. Questo scenario illustra un metodo di valutazione; non riporta un risultato ottenuto da ZeroFive. ## Governare il cambiamento continuo Modelli, istruzioni e fonti cambiano. Ogni modifica rilevante richiede una valutazione proporzionata: quali casi può influenzare, quali test ripetere e chi autorizza il rilascio. Conserva un insieme di casi di controllo, una cronologia delle versioni e una procedura di ripristino. Anche le persone cambiano ruolo. La formazione deve includere esercizi sul lavoro reale e criteri di escalation. Gli strumenti vengono scelti considerando esigenze e licenze dell’azienda, non imponendo una piattaforma identica a tutti. ## Il documento per la revisione periodica Porta alla revisione una pagina con obiettivo, baseline, risultati osservati, costi, incidenti, limitazioni e decisione richiesta. Distingui fatti, stime e ipotesi. Assegna un responsabile e una data a ogni azione correttiva. La frequenza dipende dalla criticità e dal ritmo delle modifiche, non da una cadenza universale. Le possibili decisioni sono estendere, mantenere, correggere o sospendere. Una sospensione motivata è gestione dell’investimento: permette di preservare risorse e imparare dal test. Per impostare il percorso, approfondisci [AI Strategy](/servizi/ai-strategy), [AI Shift](/servizi/ai-shift) e i [paper](/papers). Per scegliere il punto di partenza leggi [come selezionare il primo caso d’uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso). [Fissa un incontro di valutazione](https://calendly.com/fabiolalli/zerofive) oppure avvia l’[autovalutazione aziendale](/avvia-ai-rating). --- # AI adoption: come scegliere il primo caso d’uso URL: https://zerofive.ai/blog/strategia/ai-adoption-scegliere-primo-caso-uso Data: 2026-09-11 Abstract: Scegli il primo caso d’uso AI con una matrice di valore, dati, fattibilità e rischio. Esempio operativo e criteri per decidere sul pilota. **Il primo caso d’uso AI va scelto per la sua verificabilità, non per l’effetto della demo.** Deve avere un responsabile, un processo osservabile, dati utilizzabili e un risultato confrontabile con il lavoro attuale. Valore, fattibilità e rischio si valutano insieme: un beneficio elevato non compensa controlli mancanti. ## Dalla lista delle idee alla decisione Un assistente documentale, la classificazione delle richieste e la preparazione di preventivi sono candidati, non progetti. Per diventare progetti devono specificare chi usa il risultato, quale attività cambia e quale decisione resta umana. La domanda iniziale è: quale passaggio del processo vogliamo migliorare e come sapremo se è migliorato? La [guida all’AI adoption](/ai-adoption) descrive il percorso complessivo. Qui il problema è più circoscritto: selezionare un esperimento che produca evidenze utili per una decisione di investimento. ## La scheda di selezione | Dimensione | Evidenza richiesta | Domanda decisionale | |---|---|---| | Valore | Volumi, tempo attuale, rilavorazioni | Quale costo o risultato può cambiare? | | Fattibilità | Accesso ai sistemi e competenze | Possiamo provare l’ipotesi senza rifare il processo? | | Dati | Campione rappresentativo e permessi | I dati sono utilizzabili per questa finalità? | | Rischio | Impatti, reversibilità, controlli | Possiamo intercettare e correggere un errore? | | Adozione | Responsabile e utenti coinvolti | Chi userà il risultato nel lavoro reale? | Assegna a ogni dimensione una valutazione motivata: evidenza disponibile, evidenza parziale, evidenza assente. Un punteggio sintetico aiuta a discutere, ma non deve nascondere un vincolo bloccante. Se mancano i diritti sui dati, il progetto richiede prima una decisione su quei dati. ## Prima i vincoli, poi la graduatoria Il [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) distingue Govern, Map, Measure e Manage. È un riferimento volontario per organizzare gestione e misurazione dei rischi, non una certificazione. In pratica, prima di ordinare le idee, chiarisci contesto, persone interessate e responsabilità. Una decisione che influisce su persone richiede attenzione diversa da una bozza interna. Verifica la normativa applicabile con le funzioni competenti: la matrice non sostituisce la classificazione giuridica. Per i dati personali, finalità, minimizzazione e sicurezza restano temi distinti dalla qualità del modello. ## Esempio ipotetico: classificare richieste in ingresso Un’impresa valuta un sistema che suggerisce la categoria di una richiesta. Il suggerimento resta modificabile dall’operatore e non viene inviato al cliente. Il responsabile del servizio raccoglie un campione con casi ordinari, ambigui e rari, definisce le categorie e confronta le assegnazioni automatiche con quelle revisionate. L’ipotesi non è semplicemente “il modello classifica bene”. È: il processo completo richiede meno tempo, mantenendo un livello di errore accettato in anticipo. Vanno quindi misurati anche il tempo di verifica e le correzioni. L’esempio è illustrativo, non un risultato di un cliente. | Voce della scheda | Esempio da compilare prima del test | |---|---| | Responsabile | Titolare del processo di gestione richieste | | Baseline | Tempo e qualità misurati sul processo attuale | | Campione | Richieste rappresentative, separate dai casi di sviluppo | | Misure | Errori per categoria, tempo totale, correzioni | | Supervisione | Conferma dell’operatore prima dell’instradamento | | Arresto | Soglia concordata di errori critici o indisponibilità | ## Scrivere il criterio di accettazione Un criterio completo contiene misura, campione, soglia, responsabile e conseguenza. Le soglie non si copiano da un altro progetto: dipendono dal costo dell’errore e dalla qualità attuale. Va distinto un errore recuperabile da uno che produce un danno difficile da correggere. Tieni separati i dati usati per migliorare il sistema da quelli impiegati nella verifica finale. Registra versione del modello, istruzioni e fonti usate: altrimenti il risultato non è confrontabile dopo una modifica. Considera anche gli utenti meno esperti e i casi incompleti, non solo le richieste ben scritte. ## Il passaggio dal pilota al lavoro reale Una prova positiva autorizza una decisione, non un’estensione automatica a tutti gli utenti. Prima della produzione servono accessi, gestione degli incidenti, controllo dei costi, monitoraggio e un processo alternativo se il sistema non è disponibile. Il responsabile deve poter sospendere l’uso senza bloccare l’attività essenziale. La formazione riguarda il processo: quando fidarsi del suggerimento, quando controllare le fonti e quando coinvolgere una persona competente. Misurare solo gli accessi allo strumento non dice se il lavoro è migliorato. ## Checklist per la riunione di selezione - Un processo specifico e un responsabile nominato. - Una baseline osservata, non stimata per impressione. - Dati accessibili e utilizzabili per la finalità prevista. - Un campione di verifica con casi difficili. - Soglie concordate prima di vedere i risultati. - Un controllo umano e un percorso di ripristino. - Una decisione esplicita: proseguire, correggere o fermare. Se questi elementi mancano, il passo utile è completare la scheda, non comprare altre licenze. [AI Assessment](/servizi/ai-assessment) aiuta a collegare processi e opportunità; [PROTOT.AI](/protot-ai) è il gate di validazione prima della produzione. Per stimare l’impegno complessivo, leggi il [budget dal pilota alla produzione](/blog/strategia/budget-progetto-ai-pilota-produzione). Puoi iniziare dall’[autovalutazione aziendale](/avvia-ai-rating) oppure [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Consulente AI, fornitore o team interno: come scegliere URL: https://zerofive.ai/blog/strategia/consulente-ai-fornitore-o-team-interno Data: 2026-09-11 Abstract: Quando costruire internamente, quando acquistare e quando serve un consulente indipendente: matrice di scelta e domande da fare in selezione. **In sintesi.** La scelta tra team interno, fornitore di soluzione e consulente indipendente non dipende dalla dimensione dell'azienda ma da tre variabili: quanto la capacita AI e un elemento distintivo del tuo business, quanto sono sensibili i dati coinvolti e quanto il risultato deve restare governabile nel tempo. Se la capacita e distintiva conviene costruirla dentro. Se e una funzione standard conviene acquistarla. Se il problema e decidere cosa fare, in che ordine e con quali controlli, serve una figura indipendente dalla vendita. Molte aziende affrontano questa decisione al contrario: scelgono prima il fornitore e poi cercano di capire quale problema risolvere. Il risultato e prevedibile: strumenti attivi, licenze pagate, uso reale limitato a pochi utenti entusiasti. ## I tre modelli a confronto | Aspetto | Team interno | Fornitore di soluzione | Consulente indipendente | |---|---|---|---| | Adatto quando | La capacita e distintiva e ricorrente | Il bisogno e standard e diffuso | Servono priorita, criteri e governance | | Tempo per il primo risultato | Piu lungo, dipende dal reclutamento | Breve, la soluzione esiste gia | Medio, dipende dalla qualita dei dati | | Costo prevalente | Persone e mantenimento | Licenze e integrazione | Giorni di lavoro e trasferimento di competenza | | Rischio principale | Sottodimensionamento e turnover | Dipendenza dal fornitore | Consegne teoriche senza applicazione | | Cosa resta in azienda | Conoscenza e codice | Configurazione e dati nel sistema | Documenti, criteri e competenze | | Conflitto di interesse | Assente | Presente, vende cio che consiglia | Assente se non rivende licenze | Nessuno dei tre e migliore in assoluto. La maggior parte delle organizzazioni usa una combinazione: un consulente per impostare priorita e controlli, fornitori per le funzioni standard, un nucleo interno per cio che non conviene delegare. ## La domanda che precede tutte le altre Prima di scegliere il modello, occorre stabilire se la capacita in questione e distintiva. La distinzione e semplice: una capacita e distintiva se un concorrente che la copiasse ridurrebbe il tuo vantaggio. La generazione di testi per comunicazioni interne raramente lo e. Un modello di priorita costruito sui tuoi dati storici, sulle tue regole operative e sul tuo linguaggio di settore spesso lo e. Le capacita distintive vanno costruite o almeno controllate internamente, perche vivono di iterazione continua e di conoscenza implicita. Le capacita standard vanno acquistate, perche costruirle internamente significa pagare due volte lo stesso lavoro. ## Matrice di scelta Valuta ogni iniziativa su quattro dimensioni, con un punteggio da 1 a 5: 1. **Distintivita**: quanto la capacita incide sul vantaggio competitivo. 2. **Sensibilita dei dati**: quanto i dati coinvolti sono riservati o personali. 3. **Frequenza d'uso**: quanto l'attivita si ripete nel tempo. 4. **Competenze disponibili**: quanto il team interno e in grado di mantenerla. Letture tipiche: - Distintivita alta, competenze alte: costruire internamente, con supporto esterno solo nelle fasi iniziali. - Distintivita alta, competenze basse: costruire con affiancamento, prevedendo esplicitamente il trasferimento di competenza. - Distintivita bassa, frequenza alta: acquistare una soluzione, negoziando portabilita dei dati e condizioni di uscita. - Sensibilita alta in qualsiasi scenario: la scelta del modello viene dopo la definizione dei controlli, non prima. La matrice non produce una risposta automatica. Serve a rendere esplicito il ragionamento e a consentire una discussione tra funzioni diverse sulla stessa base. ## Come valutare un fornitore Un fornitore di soluzione e la scelta corretta in molti casi, purche si valutino gli aspetti che emergono dopo la firma: - Dove risiedono i dati e chi puo accedervi. - Se i dati vengono usati per addestrare modelli, e con quali possibilita di esclusione. - Quale documentazione tecnica viene fornita per soddisfare obblighi interni ed esterni. - Cosa succede ai dati e alle configurazioni in caso di interruzione del contratto. - Con quale preavviso possono cambiare modelli sottostanti, prezzi e limiti di utilizzo. - Quali metriche di qualita vengono misurate e condivise. Queste risposte, messe per iscritto, valgono piu di una demo. ## Come valutare un consulente Il criterio decisivo e l'indipendenza dalla vendita: chi consiglia una tecnologia e ne percepisce un margine non e nella posizione di sconsigliarla. Le domande utili sono poche: 1. Rivendete licenze o avete accordi di canale con fornitori? 2. Quali documenti restano in azienda alla fine, e chi li mantiene? 3. Come misurate il trasferimento di competenza alle persone interne? 4. Cosa fate se l'analisi mostra che il progetto non conviene? 5. Chi lavora concretamente sul progetto, con quale presenza? La quarta domanda e la piu rivelatrice. Una consulenza che non contempla la risposta "non conviene farlo" non sta valutando: sta vendendo. ## Quando costruire un team interno Un nucleo interno diventa sostenibile quando esistono almeno tre condizioni: un flusso continuo di casi d'uso, dati accessibili e di qualita ragionevole, e una funzione che risponda degli esiti. Senza la terza condizione il team produce prototipi che nessuno adotta. Conviene partire piccoli, con due o tre persone che uniscano conoscenza del processo e capacita tecnica, e crescere sulla base di casi d'uso conclusi, non di previsioni di crescita. ## Un esempio ipotetico Un'azienda manifatturiera valuta tre iniziative: assistenza alla scrittura di documenti interni, analisi dei reclami e previsione della manutenzione. La prima ha distintivita bassa e frequenza alta: acquistare. La seconda tocca dati di clienti e richiede regole interne: acquistare con controlli aggiuntivi oppure costruire, a seconda della sensibilita. La terza dipende da dati storici propri e incide direttamente sui costi: costruire, con affiancamento iniziale. Esempio illustrativo, utile a mostrare il ragionamento e non un risultato misurato. ## Il passo successivo La scelta del modello diventa semplice quando esistono priorita chiare e una fotografia realistica delle competenze interne. Puoi approfondire il percorso nella pagina [Come lavoriamo](/come-lavoriamo), leggere [cosa deve consegnare un progetto di consulenza AI](/blog/strategia/consulenza-ai-cosa-deve-consegnare) oppure iniziare dall'[autovalutazione della tua azienda](/avvia-ai-rating). Per un confronto diretto sul tuo caso, puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Consulenza AI per aziende: cosa deve consegnare un progetto URL: https://zerofive.ai/blog/strategia/consulenza-ai-cosa-deve-consegnare Data: 2026-09-11 Abstract: Consulenza AI e consulenza in intelligenza artificiale: quali documenti restano in azienda, come si sceglie il consulente, durate tipiche e modelli di ingaggio. **In sintesi.** Una consulenza AI utile non consegna una presentazione: consegna decisioni prese e documenti che restano in azienda anche quando il consulente esce. Quattro artefatti distinguono un progetto solido da un esercizio teorico: inventario dei sistemi e dei casi d'uso, valutazione del rischio per ciascuno, criteri di accettazione misurabili e un modello di responsabilità che dica chi decide e chi risponde. Sotto trovi la tabella fase per fase, con l'artefatto atteso, chi lo approva e il criterio che permette di chiudere la fase. Chi valuta una consulenza AI si trova quasi sempre davanti allo stesso problema: le proposte si assomigliano. Tutte parlano di assessment, roadmap, casi d'uso e change management. La differenza non sta nelle parole, sta in cosa resta in azienda alla fine. Un progetto si giudica dagli oggetti verificabili che produce, perché sono gli unici che sopravvivono al cambio di fornitore, di responsabile o di priorità. ## Il criterio che separa un progetto da una presentazione Un artefatto è utile quando qualcuno può usarlo per decidere senza chiedere spiegazioni a chi lo ha scritto. Una matrice di prioritizzazione senza i criteri espliciti non è un artefatto: è un'opinione impaginata. Un registro dei rischi che non indica chi lo aggiorna diventa obsoleto in poche settimane. Tre domande bastano per valutare qualsiasi consegna: - Chi la userà dopo la fine del progetto, e per quale decisione? - Come si aggiorna, con quale frequenza e a cura di chi? - Cosa succede se la risposta non arriva: quale decisione resta bloccata? Se una consegna non supera queste tre domande, il suo valore finisce con l'ultima riunione. ## Le fasi e cosa deve produrre ciascuna | Fase | Decisione da abilitare | Artefatto atteso | Chi approva | Criterio di chiusura | |---|---|---|---|---| | Inquadramento | Su quale ambito conviene intervenire | Mappa dei processi candidati con obiettivi misurabili | Direzione sponsor | L'ambito e scritto, con cosa resta fuori | | Assessment | Quanto l'organizzazione è pronta | Fotografia di dati, competenze, processi e governance | Sponsor e responsabili di funzione | Ogni dimensione ha evidenze, non percezioni | | Portfolio | Quali casi d'uso finanziare | Elenco valutato su valore, fattibilita, rischio e dati disponibili | Comitato di indirizzo | Le priorita sono ordinate con criteri scritti | | Validazione | Se l'ipotesi regge | Prototipo con criteri di accettazione definiti in anticipo | Responsabile di processo | Il risultato dichiara passa oppure non passa | | Messa in produzione | Se il sistema può entrare nei processi ufficiali | Documentazione tecnica, controlli e piano di monitoraggio | Responsabile di processo e funzione rischio | I controlli sono attivi, non pianificati | | Continuita | Chi mantiene il sistema nel tempo | Modello di responsabilità e piano di revisione | Direzione | Nomi, frequenze e soglie sono assegnati | La sequenza conta piu della durata. Saltare l'assessment porta a finanziare casi d'uso che l'organizzazione non puo assorbire. Saltare i criteri di accettazione porta a piloti che non si chiudono mai, perche nessuno ha stabilito prima cosa significa riuscire. ## I quattro documenti che devono restare ### Inventario dei sistemi e dei casi d'uso È il documento su cui poggiano tutti gli altri. Deve elencare, per ciascun sistema o caso d'uso: finalità, dati utilizzati, chi lo usa, chi ne risponde, in quale processo entra e quale decisione influenza. Senza questo elenco non è possibile valutare il rischio, né rispondere a una richiesta di chiarimento interna o esterna. La stessa struttura serve poi per la gestione del rischio e per gli obblighi documentali, quindi conviene costruirla una volta sola e riutilizzarla. ### Valutazione del rischio per caso d'uso Il rischio non è una proprietà della tecnologia: dipende dall'uso. Lo stesso modello può essere irrilevante in una bozza interna e delicato in una decisione che riguarda persone. La valutazione deve indicare il tipo di impatto, chi puo essere toccato, quali controlli sono previsti e chi supervisiona. Il [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organizza questo lavoro in quattro funzioni, governare, mappare, misurare e gestire, ed è un riferimento utile perché non richiede certificazione per essere adottato. ### Criteri di accettazione Sono la difesa piu efficace contro i piloti infiniti. Vanno scritti prima di iniziare e devono includere: la misura di riferimento attuale, il risultato atteso, come si misura, su quale campione, chi verifica e cosa si fa se il risultato non arriva. Un criterio accettabile è verificabile da una persona diversa da chi ha costruito il sistema. ### Modello di responsabilità Per ogni sistema in produzione servono tre nomi: chi lo usa nel processo, chi risponde degli esiti, e chi verifica che continui a funzionare come previsto. Quando questi ruoli non sono assegnati, la supervisione umana resta un principio dichiarato e non un controllo reale. ## Come leggere una proposta Una proposta si valuta meglio con domande concrete che con il confronto tra prezzi: 1. Quali documenti resteranno in azienda, e in quale formato modificabile? 2. Chi li mantiene dopo la chiusura del progetto? 3. Quali criteri decidono se un caso d'uso passa in produzione? 4. Cosa accade se l'assessment mostra che l'ambito iniziale non è il più adatto? 5. Quali competenze vengono trasferite alle persone interne, e come si verifica il trasferimento? 6. Quale parte del lavoro dipende da strumenti o licenze specifiche, e cosa resta se cambiano? L'ultima domanda merita attenzione particolare. Una consulenza legata in modo rigido a una piattaforma produce risultati che si trasferiscono male quando le condizioni cambiano, e le condizioni nel campo dell'AI cambiano spesso. ## Un esempio ipotetico Un'azienda di servizi vuole ridurre il tempo di risposta alle richieste dei clienti. Un progetto impostato correttamente non parte dallo strumento: parte dalla misura attuale, per esempio il tempo medio e la percentuale di richieste che richiedono una seconda lavorazione. Definisce poi cosa significa migliorare, quale margine di errore è tollerabile, chi verifica le risposte prima dell'invio nei primi mesi e quando la supervisione può essere ridotta. Al termine, l'azienda possiede una misura, un criterio, un controllo e un responsabile. Questo esempio è illustrativo e serve a mostrare la struttura, non descrive un risultato ottenuto. ## Cosa evitare - Roadmap dettagliate su dodici mesi costruite prima di conoscere la qualita dei dati. - Elenchi di quaranta casi d'uso senza criteri di selezione. - Stime di beneficio senza la misura di partenza corrispondente. - Documenti consegnati solo in formato presentazione, non aggiornabili. - Governance descritta come principio, senza nomi e frequenze. ## Come si sceglie una consulenza in intelligenza artificiale Le proposte si assomigliano perché descrivono tutte lo stesso percorso, quindi la selezione va fatta su tre criteri che si verificano con domande dirette invece che leggendo le referenze. Il primo è l'indipendenza dai fornitori. Un consulente che arriva con una piattaforma da installare ha già deciso il finale, e la valutazione dei casi d'uso tenderà a convergere su quello che quella piattaforma sa fare. La domanda utile riguarda cosa succede se l'azienda sceglie una tecnologia diversa da quella proposta. Il secondo è il trasferimento di metodo, perché un progetto che lascia documenti aggiornabili e persone capaci di mantenerli vale più di uno che consegna un risultato migliore e nessuna autonomia. Vale la pena chiedere chi scrive materialmente i documenti, in quale formato restano e chi li aggiornerà sei mesi dopo la chiusura. Il terzo è la disponibilità a dire di no. Un fornitore che non ha mai sconsigliato un progetto a un cliente ha un conflitto evidente, perché il suo ricavo dipende dal fatto che si proceda. Chiedere un caso concreto in cui hanno raccomandato di fermarsi è la domanda più informativa di tutta la selezione. ## Quanto dura un progetto e come si confronta il costo La durata dipende dall'ampiezza del perimetro e dal numero di funzioni coinvolte, e queste sono le finestre che osserviamo nei progetti con un singolo sponsor, un ambito definito e una disponibilità ragionevole delle persone interne. | Tipo di intervento | Durata tipica | |---|---| | Valutazione della maturità con punteggio e gap | 3-5 settimane | | Assessment dei casi d'uso con stima di valore | 4-8 settimane | | Progettazione e piano a dodici mesi | 6-10 settimane | | Validazione di un prototipo con criteri di accettazione | 2-8 settimane | | Affiancamento continuativo alla governance | a giornate, su base mensile | I modelli di ingaggio sono tre, e la scelta cambia il rapporto più del prezzo. L'intervento a progetto ha un perimetro chiuso, un elenco di consegne e una data di fine, quindi funziona quando la domanda è già definita e l'azienda sa cosa vuole ottenere. L'affiancamento a giornate serve quando l'azienda ha già un piano e le manca capacità di esecuzione su alcuni passaggi. Il retainer continuativo ha senso quando la decisione da prendere non è una sola, e serve qualcuno che resti nel tempo a controllare che le scelte reggano. Il confronto economico tra proposte va fatto sul costo della decisione che abilitano, non sulla tariffa giornaliera. Due proposte con lo stesso importo possono produrre una roadmap impaginata oppure un inventario, una classificazione e tre criteri di stop, e solo la seconda riduce il rischio di spendere male il budget di progetto. La scelta tra consulenza esterna, fornitore di tecnologia e costruzione di un team interno è trattata in [consulente AI, fornitore o team interno](/blog/strategia/consulente-ai-fornitore-o-team-interno). ## Il passo successivo Se stai valutando una consulenza AI, conviene partire da una fotografia sincera del punto in cui sei: cosa è già in uso, con quali dati, con quali responsabilita assegnate. Puoi approfondire il nostro approccio nella pagina [Servizi](/servizi) e nella [guida al framework di AI adoption](/blog/strategia/framework-ai-adoption-guida-pratica-imprese), oppure iniziare con l'[autovalutazione della tua azienda](/avvia-ai-rating). Se preferisci discuterne direttamente, puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive): in trenta minuti chiariamo ambito, vincoli e quali documenti servirebbero davvero nel tuo caso. --- # Progettare un sistema AI ISO-ready: cosa preparare prima di sviluppare URL: https://zerofive.ai/blog/compliance/progettare-sistema-ai-iso-ready Data: 2026-09-10 Abstract: Progettare un sistema AI ISO-ready: cosa non si recupera a posteriori, logging e supervisione come scelte di design, gate con criteri di uscita e cosa chiedere al fornitore. Il momento in cui un progetto AI scopre di dover rispondere a ISO/IEC 42001 arriva quasi sempre troppo tardi, di solito quando il sistema è già in staging e qualcuno chiede se è stato fatto un risk assessment. Da lì partono due o tre settimane di ricostruzione a ritroso, con un team che cerca di documentare decisioni prese mesi prima e un lancio che slitta. La parte fastidiosa è che una porzione di quel lavoro non è recuperabile in nessun modo, per quanto tempo ci si metta. ## Cosa non si può ricostruire a posteriori Policy, procedure, manuali d'uso si scrivono anche a fine progetto. Sono documenti che descrivono uno stato, e lo stato è verificabile in qualsiasi momento. Quattro cose invece esistono solo se sono state prodotte mentre il sistema veniva costruito. La prima è la provenienza dei dati usati per addestrare o mettere a punto il modello. Se nessuno ha tracciato da dove arriva ciascun insieme di dati, con quale base e con quali diritti d'uso, dopo sei mesi quella catena non si ricostruisce, si può solo dichiarare. Un auditor conosce la differenza. La seconda sono le alternative scartate. La domanda su perché sia stata scelta questa architettura, questo modello, questo fornitore, ha una risposta credibile solo se le opzioni erano sul tavolo nello stesso momento. Ricostruirla dopo produce una giustificazione, che è un'altra cosa. La terza è la baseline del processo prima dell'introduzione del sistema. Quanto durava, quanti errori produceva, quanto costava. Senza quel numero misurato prima, il monitoraggio successivo non ha un termine di paragone e nessuno può dire se il sistema stia migliorando o peggiorando la situazione. È anche il motivo per cui molti progetti AI non riescono a dimostrare il proprio ritorno: nessuno ha registrato il punto di partenza. La quarta sono i criteri di accettazione. Stabilire cosa deve essere vero perché il sistema si consideri riuscito, prima di vedere i risultati, è una cosa. Stabilirlo dopo, guardando le metriche che sono uscite, è un esercizio che si adatta a qualsiasi esito. ## Decisioni tecniche con conseguenze di conformità Alcune scelte che nel piano di progetto sembrano puramente architetturali determinano se il sistema potrà essere governato o no. Cambiarle dopo significa rimettere mano al codice, non alla documentazione. **Il logging.** L'articolo 12 dell'AI Act chiede che i sistemi ad alto rischio consentano tecnicamente la registrazione automatica degli eventi per tutta la durata di vita del sistema, e l'articolo 26(6) impone al deployer di conservare quei log per almeno sei mesi. Il punto operativo però non è attivare i log, è decidere cosa registrano. Un log che contiene solo l'output non permette di ricostruire una singola decisione a distanza di mesi. Per farlo servono l'input ricevuto, la versione del modello attiva in quel momento, l'esito prodotto e l'eventuale intervento umano con il suo autore. Aggiungere questi campi dopo tocca lo schema dati, spesso la latenza, a volte l'intera pipeline. **La supervisione umana.** L'articolo 14 chiede che i sistemi ad alto rischio siano progettati in modo da poter essere effettivamente sorvegliati da persone. Nella pratica questo si traduce in tre domande di design: chi può fermare il sistema, in quanto tempo, e con quali informazioni davanti nel momento in cui deve decidere. Un operatore che vede solo l'esito senza gli elementi che lo hanno prodotto non è in condizione di contestarlo, e l'articolo 13 sulla trasparenza verso chi utilizza il sistema esiste proprio perché una supervisione senza comprensione resta formale. **Il livello di spiegabilità.** Quanto il sistema debba saper motivare i propri esiti dipende da cosa decide e su chi ricade. È un requisito che vincola l'architettura: scegliere un modello non interpretabile per un caso d'uso che richiede una motivazione è una decisione che nessuna quantità di documentazione successiva annulla. **Il percorso di ricaduta.** Cosa succede quando il sistema è indisponibile, o quando produce un esito che l'operatore rifiuta. Se non esiste un percorso manuale praticabile, il sistema di fatto non è disattivabile, e un sistema non disattivabile è un rischio che nessun controllo compensa. ## Quando una scelta tecnica cambia il vostro ruolo giuridico Nel pezzo sull'inventario abbiamo visto che l'articolo 25 dell'AI Act elenca tre situazioni in cui chi utilizza un sistema ne diventa il fornitore, assumendo gli obblighi dell'articolo 16. Due di quelle tre situazioni nascono da decisioni che si prendono in fase di progettazione. Il fine-tuning su dati proprietari e la modifica di una soglia decisionale possono ricadere nella nozione di modifica sostanziale. Cambiare la finalità di un sistema non classificato come ad alto rischio in modo che lo diventi produce lo stesso effetto. La riclassificazione non richiede una notifica o una registrazione, si verifica quando ricorrono le condizioni. La conseguenza pratica è che la frase "partiamo dal modello del fornitore e lo adattiamo ai nostri dati" non è solo una scelta di implementazione. Va presa sapendo cosa comporta, e la fase in cui va posta la domanda è il design, quando cambiare strada costa una riunione. ## Le domande da porre, e cosa fare se la risposta è vaga Un elenco di domande serve poco se non si sa riconoscere una risposta insufficiente. Queste sei hanno tutte un criterio di uscita. - **Esiste un'alternativa non basata su AI, e perché è stata scartata?** Se nessuno ha considerato l'alternativa, il progetto non ha ancora un caso, ha un'ipotesi. Questa domanda ferma più progetti di tutte le altre messe insieme, ed è la ragione per cui va posta per prima. - **Che decisione produce il sistema, e su chi ricade?** La risposta determina la classificazione di rischio e quindi tutto il resto. Se la risposta è "supporta l'operatore", va chiesto quante volte l'operatore si discosta dal suggerimento: sotto una certa soglia, il sistema decide. - **Chi ne è owner in produzione?** Serve un nome, non un reparto. Se nessuno accetta il ruolo prima del rilascio, nessuno lo accetterà dopo. - **Qual è la baseline attuale, misurata?** Senza un numero raccolto prima, il monitoraggio successivo non è confrontabile con nulla. - **Cosa deve essere vero perché il sistema si consideri riuscito?** Scritto prima, con soglie numeriche, altrimenti a valle si troverà sempre una metrica che conferma la decisione già presa. - **Cosa succede quando sbaglia?** Chi se ne accorge, in quanto tempo, e cosa fa. Se la risposta è che se ne accorgerà l'utente finale, il progetto ha un problema di design, non di documentazione. ## I gate e i criteri per superarli Servono pochi passaggi di controllo, ma con criteri di uscita espliciti, altrimenti diventano riunioni in cui si prende atto di quello che è già stato deciso. Al **kickoff** si risponde alle prime due domande sopra e si prende una posizione sulla classificazione di rischio attesa e sul ruolo che l'organizzazione assumerà. È il gate più economico e quello che viene saltato più spesso. Alla **design review** si verificano le scelte con conseguenze di conformità: cosa registrano i log, come è progettata la supervisione, quale livello di spiegabilità è richiesto, quale percorso di ricaduta esiste. Uscire da questo gate con uno di questi punti aperto significa che verrà chiuso male e in fretta più avanti. **Prima della produzione** si controllano evidenze, non intenzioni: la baseline misurata, i log attivi e verificati su un caso reale ricostruito end-to-end, l'owner nominato, la riga aperta nell'inventario dei sistemi AI, il piano di monitoraggio con le sue soglie. **A trenta o novanta giorni dal lancio** si confronta il comportamento reale con la baseline e con i criteri di accettazione fissati all'inizio. È il gate che quasi nessuno mette in calendario, ed è quello che dice se il sistema sta facendo quello per cui è stato costruito. ## Se il sistema non lo costruite voi La maggior parte delle organizzazioni non sviluppa da zero, compra o integra. Le stesse domande valgono, ma vanno poste al fornitore in fase di selezione, perché dopo la firma il potere negoziale è finito. Le informazioni da chiedere in gara sono cinque: la documentazione tecnica del sistema, il ruolo che il fornitore dichiara di assumere rispetto all'AI Act, quali log produce il sistema e in che formato sono accessibili, quali test di validazione sono stati eseguiti e con quali risultati, e con quale preavviso viene comunicato un cambio del modello sottostante. Un fornitore che non risponde a queste domande in fase di gara non risponderà nemmeno dopo, e quell'assenza di risposta è a sua volta un'informazione utile per la decisione. ## Perché qui una policy non basta Su buona parte dei controlli dell'Annex A di ISO/IEC 42001, una procedura scritta e approvata è evidenza sufficiente. Sull'area A.6, quella dedicata al ciclo di vita del sistema, non lo è. I controlli di quest'area riguardano la documentazione delle scelte di progettazione, la verifica e validazione, il rilascio, il monitoraggio operativo e la registrazione degli eventi. Per ciascuno, un auditor chiede il record prodotto dal sistema mentre funzionava, non il documento che descrive come dovrebbe funzionare. Un piano di test vale se esistono i risultati dei test. Una procedura di rilascio vale se esiste la traccia dei controlli fatti prima dell'ultimo rilascio. Questa distinzione cambia cosa bisogna costruire, e soprattutto quando. Le evidenze di quest'area si producono solo mentre il sistema viene sviluppato e usato, il che riporta al punto di partenza. ## Gli errori più frequenti Il più comune di tutti è il proof of concept che scivola in produzione senza passare da nessun gate, perché funzionava e c'era fretta. Nasce come esperimento, quindi senza documentazione, e si ritrova a gestire casi reali con un livello di controllo pensato per una demo. Il secondo è la supervisione umana nominale, l'operatore che approva trecento casi al giorno e che nei fatti timbra. Formalmente il presidio esiste, sostanzialmente il sistema decide da solo, e la differenza emerge al primo incidente. Il terzo è la documentazione scritta per l'auditor invece che per chi manterrà il sistema. Si riconosce perché nessuno del team la consulta mai, e perché invecchia senza che nessuno se ne accorga. ## Il legame con il resto della serie Chi progetta sapendo fin dall'inizio che il sistema dovrà rispondere a queste domande non fa un lavoro in più, lo fa in un ordine diverso e più economico. Le stesse informazioni servono comunque: la differenza è che raccolte durante costano ore, ricostruite dopo costano settimane, e in quattro casi non si raccolgono affatto. Il prossimo pezzo di questa serie lascia la documentazione tecnica e passa alle persone, con quello che la norma chiede in tema di competenze e con il motivo per cui è un requisito verificabile quanto un registro dei rischi. --- # L'inventario dei sistemi AI: cosa deve contenere e come si aggiorna URL: https://zerofive.ai/blog/compliance/inventario-sistemi-ai-iso-42001 Data: 2026-09-08 Abstract: Come costruire un inventario dei sistemi AI che regge un audit: definizione del perimetro, campi obbligatori, articolo 25 AI Act, discovery della shadow AI e piano a 90 giorni. Se guardate al registro dei sistemi AI della maggior parte delle aziende in questo momento, ammesso che esista, trovereste quasi sempre la stessa scena: poche righe ferme da mesi, sistemi ormai dismessi ancora segnati come attivi, due o tre strumenti che il team commerciale usa tutti i giorni e che nessuno ha mai inserito perché non sembravano "AI vera". È successo anche a noi, prima di mettere ordine. L'inventario è il documento su cui poggia tutto il resto di un sistema di gestione dell'AI. La valutazione del rischio ha bisogno di sapere cosa valutare, l'impact assessment ha bisogno di un perimetro, il piano di formazione ha bisogno di sapere chi usa cosa. Quando l'inventario è sbagliato, tutti i documenti costruiti sopra ereditano lo stesso errore senza che nessuno se ne accorga fino all'audit. ## Prima dei campi viene la definizione La domanda che blocca quasi tutti i progetti di inventario nella prima settimana non è quale colonna aggiungere. È cosa conta come sistema AI. ISO/IEC 42001 e l'AI Act partono entrambi da una definizione ampia, allineata a quella OCSE: un sistema che, a partire da input, genera output come previsioni, contenuti, raccomandazioni o decisioni, con un certo grado di autonomia. Applicata alla realtà di un'azienda, quella definizione include parecchie cose che nessuno chiamerebbe spontaneamente intelligenza artificiale. I casi che nei nostri assessment generano più discussione sono sempre gli stessi quattro. Il foglio di calcolo con un modello di scoring costruito internamente da qualcuno che non lavora più in azienda. La funzione AI attivata dentro un software che avevate già, aggiunta dal fornitore in un aggiornamento senza che nessuno l'abbia scelta. Il chatbot sul sito, spesso considerato marketing e quindi mai passato dall'IT. E il modello acquistato tramite API, integrato in un flusso interno da un team di prodotto, che nell'organigramma non compare da nessuna parte. La regola pratica che suggeriamo: se un output di quel sistema influenza una decisione che riguarda una persona, un cliente o un fornitore, entra nell'inventario. La classificazione del rischio arriva dopo, e serve proprio a distinguere i casi banali da quelli seri. Escludere qualcosa prima di averlo registrato significa decidere senza avere gli elementi per farlo. ## Una riga per strumento o una riga per uso Questa scelta determina se l'inventario resterà utile o diventerà ingestibile, e va fatta all'inizio perché rifarla dopo costa parecchio. Lo stesso assistente generativo usato dal marketing per scrivere bozze di testi e dalle risorse umane per fare una prima scrematura di candidature è, tecnicamente, lo stesso strumento. Dal punto di vista del rischio sono due mondi diversi: il primo è un uso a impatto contenuto, il secondo ricade nella categoria di casi che l'Allegato III dell'AI Act tratta come ad alto rischio. Un inventario organizzato per strumento appiattisce questa differenza e produce righe che non dicono nulla di utile. Un inventario organizzato per coppia sistema più finalità la rende visibile: due righe, due owner, due classificazioni di rischio, due percorsi di controllo. Costa qualche riga in più e fa risparmiare mesi quando arriva il momento di dimostrare che le finalità critiche sono state trattate come tali. ## Provider o deployer, il campo che quasi nessuno compila La maggior parte delle aziende italiane presume di essere deployer di sistemi altrui, e quindi soggetta a obblighi più leggeri. La presunzione regge finché non incontra l'articolo 25 dell'AI Act, che elenca tre situazioni in cui chi utilizza un sistema ne diventa il fornitore a tutti gli effetti, assumendo gli obblighi previsti dall'articolo 16. La prima è mettere il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, tipicamente in scenari di white label o rivendita, salvo diversa allocazione contrattuale. La seconda è apportare una modifica sostanziale a un sistema ad alto rischio che resta tale: l'articolo 3(23) la definisce come una modifica non prevista nella valutazione di conformità iniziale che incide sulla conformità stessa o sulla finalità prevista. La terza è cambiare la finalità di un sistema non classificato come ad alto rischio in modo che lo diventi. La seconda è quella che coglie più aziende di sorpresa, perché il perimetro della "modifica sostanziale" è più largo di quanto sembri: il fine-tuning su dati proprietari, la modifica di una soglia decisionale in un classificatore, la ristrutturazione di una pipeline di retrieval possono tutti ricadervi. La riclassificazione non passa da una notifica o da una registrazione, avviene per il solo verificarsi delle condizioni. Per questo l'inventario deve portare il ruolo assunto per ogni riga, e la data in cui quel ruolo è stato valutato l'ultima volta. È il campo che trasforma il registro da elenco descrittivo a strumento che segnala un'esposizione prima che diventi un problema. ## Cosa guarda un auditor in ciascun campo - **Nome e finalità**, descritta in linguaggio comprensibile a chi non ha costruito il sistema. Se la finalità è copiata dal materiale commerciale del fornitore, l'auditor lo capisce alla prima lettura e la considera un segnale sulla qualità dell'intero registro. - **Owner**, una persona con nome e cognome che risponde delle decisioni prese dal sistema. Un reparto non è un owner: quando la responsabilità è di tutti, in sede di audit non è di nessuno. - **Dati trattati e provenienza**, che è anche il collegamento diretto con la mappatura già richiesta dalla DPIA e con i requisiti sui dati dell'Annex A di ISO/IEC 42001. Compilare due volte le stesse informazioni in documenti separati è la ragione più comune per cui divergono. - **Stato nel ciclo di vita**: sviluppo, pilota, produzione, dismissione. Lo stato è quello che rende l'inventario leggibile a colpo d'occhio, e il passaggio da pilota a produzione è il momento in cui più spesso l'aggiornamento salta. - **Ruolo assunto**, provider o deployer, con la data dell'ultima valutazione. - **Livello di rischio**, allineato alla classificazione dell'AI Act dove applicabile, con la motivazione della classificazione, non solo l'esito. Un auditor non contesta quasi mai il livello scelto, contesta l'assenza di un ragionamento dietro. - **Origine**: sviluppato internamente, acquistato, o costruito sopra un modello di base esterno. Determina quali informazioni potete produrre da soli e quali dovete chiedere a qualcun altro, il che si traduce direttamente in clausole contrattuali. - **Fornitore e versione del modello**, quando il sistema poggia su componenti di terzi. - **Data dell'ultima revisione**, il campo che manca più spesso ed è il primo che viene guardato. Su quest'ultimo punto vale la pena essere espliciti su cosa segnala. Se tutte le righe riportano la stessa data di revisione, il registro racconta un esercizio fatto in blocco per prepararsi a qualcosa, non un processo vivo. Date diverse e distribuite nel tempo raccontano il contrario. ## Come si trova quello che non sapete di avere Chiedere ai responsabili di reparto quali sistemi AI usano produce liste incomplete, e non per reticenza. Chi usa uno strumento per andare più veloce non lo classifica mentalmente come sistema AI, lo classifica come il modo in cui fa il proprio lavoro. Per questo cinque fonti diverse danno risultati migliori di un questionario. Le note spese e gli estratti delle carte aziendali, cercando i nomi dei fornitori noti, fanno emergere gli abbonamenti individuali che non sono mai passati dagli acquisti. I log del provider di identità mostrano su quali applicazioni le persone si sono effettivamente autenticate, che è un dato di fatto e non un'autodichiarazione. L'inventario delle estensioni browser sui dispositivi gestiti intercetta una categoria che sfugge quasi sempre. La rilettura dei contratti SaaS già in essere fa emergere le funzionalità AI attivate dal fornitore dentro prodotti che avevate da anni, spesso senza una decisione esplicita da parte vostra. E la domanda ai team, se posta come "cosa usate per fare prima" invece di "usate strumenti di AI", ottiene risposte molto più accurate. ## Il fornitore che cambia modello senza dirvelo Un prodotto SaaS può sostituire il modello sottostante da una release all'altra. La finalità dichiarata resta identica, l'interfaccia pure, e il comportamento del sistema cambia senza che nulla nell'inventario lo registri. È un rischio che si governa dove nasce, cioè nel contratto. Le clausole che vediamo funzionare chiedono tre cose: preavviso in caso di cambio del modello o di modifiche rilevanti al comportamento del sistema, accesso alla documentazione tecnica necessaria per mantenere aggiornata la vostra valutazione, e indicazione esplicita del ruolo che il fornitore assume rispetto all'AI Act. Senza quelle clausole l'inventario resta accurato solo per il tempo che intercorre fino al primo aggiornamento silenzioso. ## Quando serve una riga nuova Un cambio di finalità apre sempre una riga nuova, perché cambia la classificazione del rischio e potenzialmente il ruolo assunto. Un cambio di versione del modello a parità di finalità aggiorna la riga esistente e fa scattare una revisione. Un nuovo reparto che adotta lo stesso sistema per la stessa finalità si aggiunge alla riga esistente. Un nuovo reparto che lo adotta per una finalità diversa apre una riga nuova. Le righe dismesse restano, con data e motivo. Un registro senza storico è un registro che qualcuno riscrive ogni volta invece di mantenerlo, e la differenza si vede subito. ## Chi lo aggiorna, e con quale innesco Un inventario che dipende dalla buona volontà di qualcuno che se ne ricorda non sopravvive un trimestre. Gli inneschi che reggono nel tempo sono quelli agganciati a processi che esistono già e che nessuno può saltare. Il primo è l'approvvigionamento: ogni acquisto software passa da una domanda che verifica la presenza di componenti AI, e la risposta positiva genera una riga. Il secondo è il passaggio in produzione: la procedura di messa in esercizio aggiorna lo stato del sistema corrispondente prima del rilascio, non dopo. Il terzo è un riesame periodico, trimestrale per le organizzazioni più esposte e semestrale per le altre, che recupera quello che è sfuggito ai primi due. Sopra i tre inneschi serve un responsabile del registro nel suo insieme, distinto dagli owner dei singoli sistemi. Non deve compilare le righe, deve accorgersi quando smettono di essere aggiornate. ## Foglio di calcolo o piattaforma Sotto le venti o trenta righe, un foglio di calcolo con controllo delle versioni e permessi in scrittura ristretti funziona bene e si costruisce in un pomeriggio. Il momento in cui conviene passare a uno strumento dedicato arriva quando servono tracciabilità delle modifiche, collegamenti automatici tra inventario, registro dei rischi e impact assessment, o quando il numero di owner coinvolti rende il coordinamento manuale più costoso della licenza. Partire dallo strumento è l'errore che vediamo più spesso in questa fase. Una piattaforma popolata con dati raccolti male produce gli stessi problemi di un foglio di calcolo, con in più il costo della licenza e la falsa sicurezza di avere risolto qualcosa. ## Prima di costruire il prossimo documento Senza un inventario aggiornato, l'impact assessment di cui abbiamo parlato nel pezzo precedente valuta sistemi che potrebbero non esistere più, o ne ignora altri che nel frattempo sono entrati in produzione. Il prossimo pezzo di questa serie parte proprio da qui, da cosa cambia se si progetta un sistema AI sapendo fin dall'inizio che dovrà finire in questo registro, invece di scoprirlo a lancio già avvenuto. --- # Vibecoding in produzione: perimetro normativo, rischi reali e i controlli prima del deploy URL: https://zerofive.ai/blog/compliance/vibecoding-produzione-cra-ai-act-controlli Data: 2026-09-07 Abstract: Perimetro CRA e AI Act per le app generate con AI, problemi strutturali del metodo e le otto verifiche da fare prima di andare in produzione. Un giovane imprenditore ci ha mostrato a giugno la sua applicazione, costruita in undici giorni con un generatore di codice e già usata da quattro clienti paganti. Funzionava bene. Alla domanda su quali pacchetti npm ci fossero dentro ha risposto che non lo sapeva, perché li aveva scelti il modello. Alla domanda su chi potesse leggere la tabella degli utenti ha aperto la console del database e ha scoperto una policy permissiva su tutte le righe, scritta dal generatore al secondo giorno e mai più guardata da nessuno. Il vibecoding ha spostato il collo di bottiglia dello sviluppo software dalla scrittura del codice alla sua verifica, e il salto tra prototipo e produzione, che prima richiedeva settimane di lavoro visibile, adesso avviene senza che nessuno se ne accorga. Questo articolo ricostruisce dove cadono davvero gli applicativi generati con questi strumenti dentro il perimetro normativo europeo, quali problemi strutturali il metodo introduce a prescindere dalla normativa, e quali controlli concreti vanno fatti sui fornitori e sul team prima di mettere qualcosa davanti a un utente reale. In coda trovate un vocabolario dei termini usati. ![Vibecoding Production Gate: triage di perimetro Cyber Resilience Act e le otto verifiche prima del rilascio in produzione](/vibecoding-production-gate-it.png) ## Il perimetro del Cyber Resilience Act L'assunzione diffusa è che il Cyber Resilience Act colpisca qualunque software. Sul punto che riguarda la maggior parte delle applicazioni generate con questi strumenti, la guidance della Commissione dice esattamente il contrario. Il 27 luglio 2026 la Commissione ha approvato la guidance applicativa richiesta dall'articolo 26 del regolamento, documento con riferimento C(2026) 5252, con l'obiettivo dichiarato di rendere la conformità più praticabile per le piccole e medie imprese. La parte più estesa riguarda proprio l'ambito di applicazione. Il criterio è dove il software viene eseguito. Il software che gira sul dispositivo dell'utente, quindi un'app scaricata, un'estensione del browser, un client installato localmente, è un prodotto con elementi digitali. Il software semplicemente raggiunto da remoto attraverso un browser non lo è su questa sola base, e le web app usate soltanto tramite browser insieme ai siti che si limitano a presentare informazioni non sono in genere prodotti con elementi digitali. Rientrano soltanto quando si qualificano come elaborazione dati a distanza che supporta la funzione di un prodotto. La bozza di guidance del 3 marzo 2026 aveva già confermato in modo esplicito che il SaaS autonomo resta fuori ambito. Cloud e SaaS rientrano solo dove il componente si qualifica come remote data processing solution, e questo richiede tre condizioni simultanee: che elabori dati a distanza, che il prodotto non riesca a svolgere una funzione essenziale senza di esso, e che sia stato progettato dallo stesso fabbricante del prodotto supportato o sotto la sua responsabilità. Solo i componenti che soddisfano tutte e tre le condizioni rientrano come elaborazione dati a distanza. Anche quando il SaaS resta fuori dal Cyber Resilience Act, erogarlo nell'Unione può far scattare la direttiva NIS2 in capo all'organizzazione. Un'altra precisazione utile a chi lavora con repository pubblici: la definizione di software del regolamento copre sia il codice macchina sia il codice sorgente, ma la semplice condivisione di codice open source su un repository pubblico non costituisce in genere immissione sul mercato. Tradotto in una tabella di triage utilizzabile in mezz'ora: | Cosa avete portato in produzione | Cyber Resilience Act | Cosa si applica comunque | |---|---|---| | Web app usata solo da browser | fuori ambito | AI Act, GDPR, NIS2 se siete in perimetro | | App mobile scaricabile da uno store | dentro, insieme al backend che la fa funzionare | tutto il resto | | Applicazione desktop, Electron, estensione browser, CLI | dentro | tutto il resto | | SaaS con agente installabile o SDK distribuito | dentro, e il backend entra col prodotto | tutto il resto | | Backend che fa funzionare un dispositivo del cliente | dentro come elaborazione dati a distanza | tutto il resto | | Progressive web app installabile sul dispositivo | zona grigia, va documentata caso per caso | tutto il resto | Per il portafoglio tipico di chi lavora con questi strumenti la maggior parte delle applicazioni resta fuori dal Cyber Resilience Act, e l'esposizione reale arriva da altre direzioni. Le eccezioni ricorrenti sono le progressive web app installabili, le applicazioni pubblicate sugli store e qualunque estensione del browser, categorie che in questi ambienti si producono con la stessa facilità di una pagina web. Vale la pena scrivere il risultato del triage e archiviarlo con la motivazione, perché la domanda arriverà da un cliente enterprise molto prima che da un'autorità, e una risposta documentata vale più di una risposta corretta improvvisata. ## Gli obblighi che valgono comunque Fuori dal Cyber Resilience Act non significa fuori da tutto. Le quattro esposizioni che seguono valgono per un'applicazione generata in tre giorni esattamente come per un prodotto sviluppato in tre anni. **Trasparenza dell'AI Act, applicabile dal 2 agosto 2026.** Se l'applicazione espone un chatbot, un assistente, un generatore di testo o di immagini, esiste già oggi un obbligo di informare l'utente che sta interagendo con un sistema di intelligenza artificiale, e di marcare i contenuti sintetici in modo leggibile automaticamente. È l'esposizione più probabile e la più economica da sanare, e quasi nessuna applicazione costruita in un fine settimana la copre. **Alfabetizzazione, applicabile dal 2 febbraio 2025.** L'obbligo riguarda sia chi sviluppa sia chi utilizza sistemi di intelligenza artificiale, e si dimostra con evidenze documentate. Un team che genera codice con un modello senza saper leggere quello che il modello produce è il caso che la norma intende coprire, e la formazione qui non è un adempimento formale ma la condizione per accorgersi di un errore. **Alto rischio, applicabile dal 2 dicembre 2027.** Un'applicazione costruita in tre giorni può essere ad alto rischio senza che nessuno lo abbia deciso. Screening di candidature, valutazione o assegnazione di compiti ai dipendenti, scoring per l'accesso al credito o a servizi essenziali, valutazione in ambito educativo. Sono tutti casi dell'Allegato III e sono tutti fra i primi che un giovane imprenditore prova a risolvere con un generatore, perché sembrano problemi di interfaccia e di database. Chi rientra dovrà avere sistema di gestione del rischio, governance dei dati, documentazione tecnica, registrazione automatica degli eventi, sorveglianza umana e valutazione di conformità. **NIS2 e protezione dei dati.** Erogare un servizio nell'Unione può far entrare l'organizzazione nel perimetro NIS2 in base a settore e dimensione, in modo indipendente dal Cyber Resilience Act. La normativa sui dati personali si applica sempre, con una particolarità: un database generato da prompt ha quasi sempre una minimizzazione che nessuno ha progettato, perché il modello aggiunge colonne quando servono e non le toglie mai. ## I punti deboli del metodo Questi valgono a prescindere dal perimetro normativo, perché sono problemi di ingegneria prima che di conformità. Li elenco nell'ordine in cui li abbiamo incontrati sul campo. **Nessuno sa cosa c'è dentro.** La distinta base del software presuppone che qualcuno abbia scelto le dipendenze. Nel vibecoding le sceglie il modello, spesso pescando pacchetti per nome plausibile, e la catena transitiva resta invisibile a chi ha scritto soltanto prompt. Il rischio di pacchetti abbandonati o di nomi costruiti per assomigliare a librerie note non è teorico, ed è aggravato dal fatto che il generatore non ha alcun modo di sapere se un pacchetto è stato compromesso la settimana scorsa. Anche restando fuori dal Cyber Resilience Act, l'elenco dei componenti è la prima cosa che un ufficio acquisti strutturato chiede in fase di qualifica fornitore. **Il default di sicurezza del generatore.** La classe di errore più frequente riguarda le regole di autorizzazione sulle righe dei database gestiti, le chiavi di servizio finite dentro il bundle consegnato al browser e le funzioni serverless esposte senza autenticazione. Il generatore produce codice che funziona, e funzionare non coincide con essere protetto. Chi non sa che cosa sia una policy di sicurezza a livello di riga non può verificarne una scritta da un modello, e il modello la scrive permissiva perché così l'applicazione parte al primo tentativo. **Il confine tra prototipo e produzione evapora.** Questo è il punto centrale. In questi ambienti il prototipo è deployato su un dominio pubblico dal primo minuto, quindi manca il momento in cui qualcuno decide consapevolmente di andare in produzione. La decisione avviene per accumulo, quando il primo utente reale entra e nessuno se ne accorge. Ogni presidio successivo dipende dal ripristino di quel momento decisionale. **Non c'è tracciabilità delle modifiche.** Senza revisione del codice e senza registro delle modifiche nessuno può rispondere alla domanda su quando sia stata introdotta una modifica sostanziale, che è il test capace di riaprire la valutazione di conformità nel Cyber Resilience Act e la documentazione tecnica nell'AI Act. Nessuno può nemmeno ricostruire quale versione fosse in esecuzione nel momento in cui si è verificato un incidente, che è la prima domanda di qualunque analisi post-evento. **Registrazione degli eventi e conservazione.** Per i sistemi ad alto rischio l'AI Act richiede registrazione automatica e conservazione per un periodo definito. Le applicazioni generate hanno quasi sempre una registrazione da ambiente di sviluppo, verbosa dove non serve e assente dove servirebbe, con dati personali che finiscono nei log senza che nessuno lo abbia deciso. **Regressioni senza rete di protezione.** Un singolo prompt può riscrivere una funzione che nessuno stava guardando. In assenza di test automatici la verifica è visiva, e la verifica visiva non copre autorizzazioni, casi limite e condizioni di errore. La velocità di modifica che rende attraente il metodo è la stessa che rende probabile la regressione silenziosa. **Il periodo di supporto.** Chi rientra nel Cyber Resilience Act deve dichiarare per quanto tempo manterrà il prodotto, con un orizzonte che in linea di principio non scende sotto i cinque anni. Un'applicazione generata da un singolo startupper, su una piattaforma che potrebbe cambiare modello sottostante due volte l'anno, ha un problema di sostenibilità della promessa prima ancora che di conformità. **Chi è il fabbricante.** Se mettete sul mercato con il vostro marchio, il fornitore ai sensi dell'AI Act e il fabbricante ai sensi del Cyber Resilience Act siete voi. La piattaforma su cui avete generato il codice non compare da nessuna parte in quella catena di responsabilità. Vale anche in direzione opposta, e riguarda direttamente chi fa consulenza: se un'unità di prototipazione consegna un prototipo e il committente lo porta in produzione così com'è, il confine di responsabilità va scritto nel contratto prima della consegna. ## La dipendenza da tre fornitori Un'applicazione vibecoded tipica poggia contemporaneamente su tre fornitori: la piattaforma di generazione e hosting, il database gestito, il fornitore del modello. Ciascuno con la propria giurisdizione di controllo societario, il proprio calendario di deprecazione e la propria politica sugli incidenti. La domanda di due diligence che si pone oggi su questi tre fornitori riguarda quasi sempre il prezzo e la velocità. Le domande che il quadro europeo rende rilevanti sono di natura diversa, e il pacchetto cyber presentato dalla Commissione il 20 gennaio 2026 le rende attuali anche per progetti molto piccoli, perché introduce la possibilità di designare fornitori come ad alto rischio con obblighi di dismissione progressiva. Il costo di uscita da queste tre dipendenze cresce più rapidamente di quanto uno startupper stimi, perché al contratto si sommano progressivamente lo schema del database, le funzioni serverless scritte per quella piattaforma, i prompt tarati su quel modello e le abitudini del team. Verificare l'esportabilità reale del codice prima del terzo cliente costa un pomeriggio, verificarla dopo il trentesimo costa un trimestre. ## Le verifiche sui fornitori Sulla piattaforma di generazione e sull'infrastruttura, otto punti da chiudere per iscritto: - Esportabilità reale del codice e proprietà del repository, provata con un export effettivo e non con una voce di documentazione - Trattamento dei prompt e del codice, con conferma esplicita sull'uso o sul non uso a fini di addestramento - Elenco dei sub-responsabili del trattamento e residenza dei dati, aggiornato e non genericamente dichiarato - Certificazioni e verifiche indipendenti disponibili, con la data dell'ultima verifica di sicurezza offensiva - Canale e tempi di divulgazione delle vulnerabilità, verificando la compatibilità con una finestra di ventiquattro ore nel caso in cui l'obbligo di segnalazione ricada su di voi - Controllo societario e giurisdizione, in ottica di designazione futura della catena di fornitura - Posizione del fornitore rispetto a NIS2, perché un fornitore già in perimetro ha processi che potete ereditare invece di costruire - Storico degli incidenti e delle interruzioni, ricostruito in modo indipendente e non chiesto al fornitore Sul fornitore del modello vanno aggiunte quattro verifiche specifiche: politica di versioning e preavviso di deprecazione, comportamento in caso di aggiornamento del modello sotto lo stesso nome commerciale, luogo di elaborazione dei dati, e clausole contrattuali sull'uso degli input inviati in inferenza. Su ciascuno di questi punti la risposta accettabile è un documento o una clausola. Una risposta ricevuta a voce in una call di vendita non serve a nulla quando serve davvero. ## Competenze e responsabilità nel team Le verifiche sul team sono meno numerose e più difficili da superare, perché toccano competenze e responsabilità invece che documenti. **Titolarità nominata.** Serve una persona con nome e cognome responsabile dell'applicativo, che risponde della segnalazione e della documentazione. In assenza di questo ogni altro presidio resta teoria, perché nel momento dell'incidente la prima cosa che manca è qualcuno che decida. **Chi può mandare in produzione.** Un secondo paio di occhi sul rilascio, anche in un team di due persone. Il vibecoding rende il rilascio così economico che la barriera va reintrodotta a mano. **Competenza di lettura.** Almeno una persona in grado di leggere il codice generato su tre dimensioni: autorizzazioni, gestione dei segreti, validazione degli input. Se questa competenza non esiste internamente va acquistata a ore, e costa meno di un incidente su dati di clienti. **Alfabetizzazione documentata.** L'obbligo dell'AI Act si dimostra con registri di formazione e contenuti, non con la percezione che il team sia bravo. Serve una traccia con date, contenuti e partecipanti. **Presidio dell'orologio.** Chi riceve la segnalazione di sicurezza il venerdì sera, attraverso quale canale, con quale procedura di escalation e con quale sostituto in ferie. Ventiquattro ore non consentono di costruire il processo mentre l'incidente è in corso. **Conoscenza del perimetro.** Il team deve sapere se l'applicazione che sta costruendo ricade nell'Allegato III, e questa domanda va posta prima del primo prompt. Scoprirlo a prodotto avviato significa rifare l'architettura dei dati e della sorveglianza umana. ## Il gate pre-produzione Otto verifiche, tutte rispondibili in mezza giornata, nessuna delle quali richiede un consulente per essere impostata la prima volta. 1. **Triage di perimetro scritto e archiviato.** Cyber Resilience Act sì o no, AI Act sì o no, Allegato III sì o no, ciascuna risposta con la sua motivazione e la data. 2. **Distinta base generata e archiviata**, con scansione delle vulnerabilità note sui componenti e una data di riscansione programmata. 3. **Revisione manuale delle regole di autorizzazione** sul database, tabella per tabella, con un test negativo che dimostra che un utente non autorizzato riceve un rifiuto. 4. **Nessun segreto nel bundle client**, verificato con una ricerca testuale sul pacchetto di produzione e non sul codice sorgente. 5. **Trasparenza implementata** ovunque esista un componente generativo esposto all'utente, con marcatura dei contenuti sintetici. 6. **Registrazione strutturata degli eventi** con periodo di conservazione definito, informativa allineata e verifica che i log non contengano dati che non dovrebbero contenere. 7. **Contatto di sicurezza pubblicato** e procedura di segnalazione scritta, con i tempi interni definiti a ritroso dalle ventiquattro ore. 8. **Titolare nominato** e confine di responsabilità con il committente messo per iscritto, incluso il caso della consegna di un prototipo. Chi non passa questi otto punti ha un prototipo. La distinzione tra prototipo e prodotto è una decisione che qualcuno deve prendere consapevolmente, e in questi ambienti va reintrodotta come artefatto formale perché la tecnologia l'ha rimossa. ## La checklist Il gate, il triage di perimetro e le domande da porre a fornitori e team sono raccolti in un documento di tre pagine costruito per essere compilato invece che letto. **A cosa serve.** A trasformare una decisione implicita in una decisione registrata, con una data e un nome accanto. Oggi il passaggio in produzione avviene per accumulo e nessuno lo scrive da nessuna parte, quindi quando arriva la domanda, da un cliente in fase di qualifica fornitore o da chi indaga un incidente, non esiste nulla da mostrare. La checklist produce quella traccia in mezza giornata, ed è la stessa traccia che serve a voi sei mesi dopo, quando nessuno ricorda più perché una scelta era stata fatta in quel modo. **Come si usa.** La prima pagina si compila una volta per applicativo e si rivede a ogni modifica sostanziale: il triage di perimetro stabilisce quali regimi si applicano e perché. La seconda pagina si usa in fase di selezione o di rinnovo dei fornitori, e le sue righe funzionano bene anche come allegato a una richiesta di offerta. Il gate a otto punti si ripercorre a ogni rilascio, e dopo la prima volta richiede un'ora. **Chi la compila.** Il titolare nominato dell'applicativo per le parti di perimetro e di titolarità, chi esegue il rilascio per il gate, chi si occupa di acquisti per le verifiche sui fornitori. In un team di due persone le tre figure coincidono, e va bene lo stesso, purché il nome scritto sia quello di una persona e non quello di un reparto. **Che cosa non è.** Non è un'attestazione di conformità, non sostituisce un parere legale e non certifica nulla, perché nessun documento compilato da chi costruisce può fare quel lavoro. È uno strumento di decisione, e serve a sapere dove siete prima di aprire un cantiere e di spendere un budget. **Licenza e crediti.** Il documento è rilasciato con licenza Creative Commons Attribuzione e Non commerciale 4.0. Potete usarlo, stamparlo, compilarlo e adattarlo dentro la vostra organizzazione, anche se siete un'impresa, e condividerlo con colleghi, fornitori e clienti. Non potete rivenderlo né includerlo in servizi di consulenza, audit o formazione a pagamento erogati a terzi. Ogni riproduzione o citazione deve riportare la fonte, ZeroFive.AI, con collegamento a zerofive.ai quando il formato lo consente. Per usi commerciali scrivete a hello@zerofive.ai. [**Scarica la checklist in PDF, tre pagine**](/checklist-vibecoding-produzione-zerofive.pdf) e tenetela accanto al repository, perché il momento in cui serve è quello del rilascio e non quello della lettura. ## L'esecuzione dei controlli Le verifiche del gate diventano gestibili quando si traducono in operazioni concrete. Quelle che seguono sono eseguibili da chiunque abbia accesso al repository e alla console dell'infrastruttura. **Distinta base.** Generatela dal gestore di pacchetti in formato standard, archiviatela con la data e il commit di riferimento, e passatela a uno strumento di scansione delle vulnerabilità note. Il primo passaggio produce quasi sempre un elenco lungo, e la parte utile è distinguere le segnalazioni che riguardano codice effettivamente eseguito da quelle su dipendenze di sviluppo. Fissate le versioni invece di lasciare intervalli aperti, perché un intervallo aperto significa che il prodotto in produzione cambia senza che nessuno lo rilasci. **Autorizzazioni sul database.** Elencate le tabelle, verificate che la sicurezza a livello di riga sia attiva su ciascuna, e leggete la condizione di ogni policy. Qualunque condizione sempre vera va riscritta. Il controllo che conta arriva dopo: aprite una sessione con un utente qualsiasi e provate a leggere una riga che appartiene a un altro utente. Finché non avete visto un rifiuto con i vostri occhi, la policy è un'ipotesi. **Segreti.** Cercate le stringhe delle vostre chiavi dentro il pacchetto di produzione servito al browser, non dentro il codice sorgente, perché il processo di build può includere variabili che non vi aspettate. Ripetete la ricerca sulla cronologia del repository, dove una chiave rimossa tre settimane fa continua a essere leggibile. Le chiavi trovate vanno ruotate, e la rimozione dal codice non sostituisce la rotazione. **Superficie esposta.** Elencate le funzioni serverless e gli endpoint pubblicati, e per ciascuno verificate quale controllo di autenticazione applica. Il generatore tende a creare endpoint di supporto durante lo sviluppo e a non rimuoverli, e quelli restano raggiungibili. **Log applicativi.** Leggete una giornata di registrazioni e cercate quello che non dovrebbe esserci: indirizzi email, contenuti inseriti dagli utenti, token. Definite un periodo di conservazione e applicatelo, perché una conservazione indefinita è una posizione difficile da difendere. **Regressione.** Prima ancora di una suite di test completa, scrivete i tre test che coprono le operazioni sui dati più sensibili dell'applicazione ed eseguiteli a ogni rilascio. Tre test eseguiti battono trenta test pianificati. ## Il confine contrattuale La questione della responsabilità merita un trattamento separato, perché è quella che produce i danni più costosi e le conversazioni più imbarazzanti. Chi immette sul mercato con il proprio marchio è il fabbricante per il Cyber Resilience Act e il fornitore per l'AI Act, indipendentemente da chi abbia materialmente prodotto il codice. Una piattaforma di generazione non entra in quella catena, e non ci entra nemmeno il consulente che ha costruito il prototipo, salvo che il contratto dica altro. Quando un prototipo passa di mano il contratto dovrebbe dire almeno quattro cose. Che l'artefatto è un prototipo destinato alla validazione e non al servizio di utenti reali. Quali verifiche sono state eseguite e quali sono state esplicitamente escluse, con l'elenco. Che il passaggio in produzione richiede un intervento ulteriore, definito nel perimetro e nel prezzo. Chi assume la titolarità dal momento della consegna e con quale decorrenza. Questa non è cautela legale fine a se stessa. Un prototipo consegnato senza queste quattro righe finisce in produzione nella maggior parte dei casi, perché funziona e perché costa zero metterlo online, e il primo incidente riapre la discussione su chi avesse detto cosa mesi prima. ## Vocabolario **Allegato III dell'AI Act.** Elenco dei casi d'uso che qualificano un sistema come ad alto rischio, tra cui selezione del personale, gestione dei lavoratori, accesso a servizi essenziali, biometria e istruzione. **Bundle client.** Il pacchetto di codice che il browser dell'utente scarica ed esegue. Tutto quello che si trova al suo interno è leggibile da chiunque, comprese le chiavi che non dovrebbero essere lì. **Catena transitiva delle dipendenze.** L'insieme dei pacchetti che il vostro progetto installa indirettamente, perché richiesti dai pacchetti che avete scelto. In un progetto moderno supera facilmente il migliaio di elementi. **Distinta base del software, o SBOM.** Elenco strutturato dei componenti software di un prodotto, comprese le dipendenze di terze parti e open source. **Elaborazione dati a distanza.** Categoria del Cyber Resilience Act che porta in ambito un servizio cloud quando elabora dati a distanza, quando il prodotto non funziona senza di esso e quando è progettato dallo stesso fabbricante del prodotto. **Fabbricante.** Chi immette un prodotto sul mercato europeo con il proprio nome o marchio assumendone la responsabilità commerciale. Non coincide necessariamente con chi ha scritto il codice, né con la piattaforma che lo ha generato. **Funzione serverless.** Frammento di codice eseguito su infrastruttura gestita, tipicamente esposto su un indirizzo pubblico. Se non ha controlli di autenticazione, chiunque conosca l'indirizzo può richiamarlo. **Modifica sostanziale.** Cambiamento a un prodotto già sul mercato tale da riaprire la valutazione di conformità. La guidance della Commissione del luglio 2026 dedica una sezione a definirne i confini. **Periodo di supporto.** Arco temporale durante il quale il fabbricante si impegna a gestire le vulnerabilità del prodotto, dichiarato all'utente e in linea di principio non inferiore a cinque anni. **Policy di sicurezza a livello di riga.** Regola che stabilisce quali righe di una tabella un determinato utente può leggere o scrivere. Una policy permissiva rende l'intera tabella accessibile a chiunque riesca a interrogare il database. **Prodotto con elementi digitali.** Categoria del Cyber Resilience Act che comprende hardware e software con connessione diretta o indiretta a dispositivi o reti, insieme alla relativa elaborazione dati a distanza. **Progressive web app.** Applicazione web che può essere installata sul dispositivo e funzionare in parte offline. È la zona grigia più frequente nel triage di perimetro. **Test negativo.** Verifica che accerta che un'operazione vietata venga effettivamente rifiutata. È il test che manca quasi sempre, perché nessuno pensa a provare quello che non deve funzionare. **Typosquatting.** Pubblicazione di pacchetti con nomi simili a librerie note, allo scopo di essere installati per errore o per suggerimento automatico. **Vibecoding.** Sviluppo di software condotto descrivendo il risultato desiderato in linguaggio naturale a un modello generativo, con verifica prevalentemente sul comportamento osservato invece che sul codice prodotto. ## In sintesi La velocità che questi strumenti hanno introdotto è reale e conviene tenersela. Quello che è saltato è il momento in cui qualcuno decideva che una cosa era pronta, e quel momento va ricostruito a mano perché nessuna piattaforma lo restituirà. Le otto verifiche del gate costano mezza giornata la prima volta e un'ora a ogni rilascio successivo. Un incidente su dati di clienti costa la relazione con quei clienti, e il costo non si recupera con la velocità di sviluppo. Chi vuole capire dove si trova la propria organizzazione su questi presidi prima di aprire un cantiere di conformità può scrivere a hello@zerofive.ai oppure prenotare un confronto su calendly.com/fabiolalli/zerofive. **Fonti.** Commissione europea, guidance sull'applicazione del Regolamento (UE) 2024/2847 approvata il 27 luglio 2026, documento C(2026) 5252, e bozza di guidance interpretativa del 3 marzo 2026. Testi normativi citati: Cyber Resilience Act, Regolamento (UE) 2024/2847; AI Act, Regolamento (UE) 2024/1689 come modificato dal Regolamento (UE) 2026/1744; direttiva NIS2, Direttiva (UE) 2022/2555. Commissione europea, pacchetto cyber del 20 gennaio 2026, proposte COM(2026) 11 e COM(2026) 13. --- # Cybersecurity Act 2, Cyber Resilience Act e AI Act: perché dicembre 2027 è una sola scadenza URL: https://zerofive.ai/blog/compliance/cybersecurity-act-2-cra-ai-act-dicembre-2027 Data: 2026-09-06 Abstract: CRA dall'11 settembre 2026, AI Act dal 2 dicembre 2027, piena applicazione CRA dall'11 dicembre. Perimetro, impatti e sequenza operativa. Un cliente ci ha scritto in agosto per chiederci se il Cyber Resilience Act lo riguardasse, visto che il suo prodotto è un gestionale in cloud e non un dispositivo connesso. La risposta ha richiesto una telefonata di quaranta minuti, perché la domanda giusta non era quella. Quel gestionale incorpora un assistente conversazionale fornito da terzi, viene distribuito con il marchio dell'azienda e serve un processo di selezione del personale. Tre normative diverse lo toccano, e due di esse chiudono a nove giorni di distanza. Tra l'11 settembre 2026 e il dicembre 2027 il quadro europeo su sicurezza dei prodotti digitali e intelligenza artificiale si salda. Chi produce, integra o acquista software con componenti AI ha davanti obblighi che sembrano appartenere a mondi separati e che invece condividono documentazione, evidenze e responsabilità. Questo articolo ricostruisce che cosa è stato proposto il 20 gennaio 2026, che cosa diventa applicabile adesso, chi rientra davvero nel perimetro e quali decisioni conviene prendere prima di firmare il prossimo contratto di fornitura. In fondo trovate un vocabolario di tutti gli acronimi e dei termini tecnici usati, perché in questa materia la barriera d'ingresso è quasi sempre lessicale. ![Convergenza dicembre 2027: calendario CRA e AI Act, ponte dell'articolo 12 e catena di fornitura del Cybersecurity Act 2](/csa2-cra-ai-act-dicembre-2027-it.png) ## Undici settembre, due dicembre, undici dicembre La prima scadenza è già arrivata. Dall'11 settembre 2026 diventa applicabile l'articolo 14 del Cyber Resilience Act, e i produttori di prodotti con elementi digitali immessi sul mercato europeo devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi secondo tempistiche molto strette. La seconda arriva il 2 dicembre 2027, quando si applicano gli obblighi dell'AI Act per i sistemi ad alto rischio dell'Allegato III, secondo il calendario riscritto dal Regolamento (UE) 2026/1744, pubblicato in Gazzetta ufficiale il 24 luglio 2026 ed entrato in vigore il terzo giorno successivo alla pubblicazione. La terza cade l'11 dicembre 2027, con la piena applicazione del Cyber Resilience Act e dei requisiti essenziali di cybersicurezza del suo Allegato I. Nove giorni separano le due scadenze piene. Per un'azienda che sviluppa o integra software con componenti di intelligenza artificiale destinati al mercato europeo questo significa una sola finestra di preparazione e un solo budget, anche quando la governance interna oggi tratta i due temi in direzioni separate e con due responsabili che non si parlano. ## Che cosa è successo il 20 gennaio 2026 Quel giorno la Commissione europea ha presentato un pacchetto cyber composto da due proposte legislative collegate. La prima sostituisce il Cybersecurity Act del 2019 con un nuovo Cybersecurity Act 2, la seconda modifica in modo mirato la direttiva NIS2 allineandola alla prima. Il testo di riferimento della prima proposta è COM(2026) 11, che riguarda l'agenzia europea per la cybersicurezza, il quadro europeo di certificazione e la sicurezza della catena di fornitura ICT, e che abroga il Regolamento (UE) 2019/881. Il secondo testo è COM(2026) 13, proposta di direttiva su misure di semplificazione e allineamento al Cybersecurity Act. La Commissione descrive la proposta principale attraverso quattro blocchi costitutivi: un quadro orizzontale per la sicurezza della catena di fornitura ICT che affronta anche le dipendenze strategiche e i rischi di interferenza straniera, un quadro europeo di certificazione semplificato e potenziato, misure di semplificazione collegate all'attuazione di NIS2, e un mandato rafforzato per l'agenzia. Sul ruolo dell'agenzia la proposta interviene in profondità. ENISA verrebbe abilitata a emettere allerte precoci su minacce e incidenti, a gestire repository europei di minacce e incidenti, a operare una piattaforma unificata di notifica, a supportare le organizzazioni nella risposta e nel recupero da attacchi ransomware e a contribuire allo sviluppo degli schemi di certificazione. È il passaggio da agenzia di coordinamento a centro operativo europeo della cybersicurezza, con tutto quello che comporta in termini di aspettative sulla velocità di risposta. ## La parte che cambia le regole del procurement Il blocco sulla catena di fornitura merita attenzione da parte di chiunque acquisti tecnologia, non solo da parte di chi la produce, e questo è il motivo per cui il tema entra a pieno titolo nella governance dell'intelligenza artificiale. La proposta esce dal perimetro della cybersicurezza come tradizionalmente intesa nel diritto dell'Unione. Avrebbe conseguenze rilevanti per diciotto settori critici e per i loro fornitori ICT, con implicazioni ampie sul commercio internazionale e sui rapporti con i partner commerciali. È la prima volta che l'Unione utilizza uno strumento vincolante per imporre restrizioni commerciali fondate su ragioni geopolitiche e di sicurezza nazionale con effetti sulle catene di fornitura tecnologica dei settori critici. Il meccanismo funziona così. La Commissione verrebbe abilitata a designare paesi terzi come portatori di preoccupazioni di cybersicurezza e a classificare come ad alto rischio i fornitori controllati da quei paesi. Una designazione di questo tipo comporterebbe l'esclusione automatica da finanziamenti europei, standardizzazione e appalti pubblici, e potrebbe imporre obblighi di dismissione progressiva che richiedono a soggetti di tutti i settori critici di rimuovere apparecchiature acquisite in modo del tutto legittimo. La Commissione potrebbe specificare i periodi di dismissione per ciascun tipo di componente: per le reti mobili, a titolo di esempio, tali periodi non potranno eccedere trentasei mesi dalla pubblicazione dell'elenco dei fornitori ad alto rischio, secondo l'articolo 110, paragrafo 3, della proposta. Sul piano sanzionatorio l'impianto proposto è a scaglioni, con un massimo dell'1 per cento del fatturato mondiale annuo totale per determinate violazioni relative agli obblighi informativi, del 2 per cento per altre inadempienze e del 7 per cento per le infrazioni più gravi. Qui serve una precisazione che molti commenti omettono, e che conviene tenere ben ferma nelle discussioni con il board. Il Cybersecurity Act 2 è una proposta in corso di negoziato, non diritto vigente. Il testo procede attraverso la procedura legislativa ordinaria, con negoziati in Parlamento e Consiglio attesi lungo tutto il 2026, e una volta adottato si applicherà direttamente in tutti gli Stati membri, mentre per le regole sulla catena di fornitura saranno gli atti di esecuzione della Commissione a fissare i periodi di transizione settoriali. Il percorso ha già incontrato attrito. Nel Progress Report del 22 maggio 2026 il Consiglio dell'Unione europea ha segnalato criticità sul quadro proposto e ha chiesto maggiore chiarezza sulla metodologia e sulle procedure di identificazione dei fornitori ad alto rischio, oltre che sull'ambito e sull'impatto probabile delle misure. Chi pianifica oggi deve quindi trattare questa parte come segnale di direzione più che come obbligo imminente, tenendo però presente che le decisioni di acquisto prese nei prossimi diciotto mesi produrranno i loro effetti dentro quel quadro. ## L'obbligo che scatta l'11 settembre Il Cyber Resilience Act, a differenza del pacchetto di gennaio, è già diritto vigente. Il regolamento è entrato in vigore il 10 dicembre 2024 e segue un calendario di applicazione scaglionato. Un primo pezzo è operativo dall'11 giugno 2026, il capo IV con gli articoli dal 35 al 51, che disciplina le autorità e gli organismi responsabili del controllo di conformità. Il secondo pezzo arriva ora. La cascata delle segnalazioni è la parte che cambia il lavoro quotidiano dei team. Per una vulnerabilità attivamente sfruttata il produttore deve trasmettere una prima allerta entro ventiquattro ore dal momento in cui ne viene a conoscenza, seguita da una notifica completa entro settantadue ore con le informazioni disponibili sulla vulnerabilità e sulle misure correttive, e da un rapporto finale entro quattordici giorni dalla disponibilità di una misura correttiva o di mitigazione. Per un incidente grave che incide sulla sicurezza del prodotto la sequenza iniziale è identica, mentre la relazione finale va presentata entro un mese dalla notifica delle settantadue ore. Il canale è unico e centralizzato. Le comunicazioni passano attraverso la Single Reporting Platform gestita da ENISA, con un solo invio da parte del produttore, indirizzato al CSIRT designato come coordinatore e, salvo circostanze eccezionali, reso disponibile simultaneamente all'agenzia europea. In Italia il CSIRT nazionale competente opera all'interno dell'Agenzia per la Cybersicurezza Nazionale. L'obbligo di segnalazione si applica anche ai prodotti messi a disposizione sul mercato prima dell'11 dicembre 2027, e questa previsione allarga il perimetro di parecchi portafogli prodotto. Il parco installato non è escluso, quindi il processo di notifica deve coprire anche versioni che l'azienda considerava in manutenzione o addirittura a fine vita commerciale. Il 27 luglio 2026 la Commissione ha pubblicato le linee guida applicative allegate alla Comunicazione C(2026) 5252, un documento non vincolante articolato in nove sezioni con esempi pratici e casi d'uso, che chiarisce ambito di applicazione, trattamento del software libero e open source, definizione di modifica sostanziale e obblighi di segnalazione. Le linee guida dedicano un passaggio esplicito a microimprese e piccole imprese, suggerendo percorsi semplificati di autovalutazione senza però ridurre la sostanza degli obblighi, perché chi vende un prodotto connesso sul mercato europeo li deve rispettare indipendentemente dalle proprie dimensioni. Vale la pena ricordare quanto sia largo l'ambito oggettivo, perché la parola prodotto porta fuori strada. Il regolamento si applica a un numero molto ampio di dispositivi connessi a internet e di software, tra cui router, modem, prodotti per la casa intelligente, giocattoli connessi, orologi e altri indossabili, sistemi operativi, firewall, VPN, browser e antivirus. Un software distribuito commercialmente rientra anche senza alcun hardware associato, e un modello linguistico impacchettato dentro un prodotto software immesso sul mercato europeo rientra insieme al prodotto che lo contiene. ## Il perimetro reale di chi è coinvolto La domanda che le aziende pongono per prima riguarda quasi sempre l'appartenenza al perimetro, e la risposta dipende da come il prodotto arriva sul mercato più che dalla quantità di codice scritto internamente. Il primo profilo è quello di chi immette sul mercato con il proprio marchio, ed è il fabbricante ai sensi del regolamento. Deve avere un processo di rilevazione e notifica funzionante già da settembre 2026, una distinta base del software, una valutazione della distanza dai requisiti essenziali dell'Allegato I e, entro dicembre 2027, documentazione tecnica e valutazione di conformità completate. La responsabilità non si trasferisce a monte per via contrattuale, per quanto il contratto sia lo strumento con cui si ottengono in tempo utile le informazioni necessarie. Il secondo profilo riguarda chi integra componenti di terzi. Un'azienda che incorpora un modello, una libreria o un servizio esterno dentro un prodotto proprio e lo immette sul mercato assume la responsabilità di fabbricante su quel prodotto. Il punto contrattuale critico diventa la notifica a monte, perché se il fornitore del componente scopre una vulnerabilità attivamente sfruttata e la comunica al cliente in cinque giorni le ventiquattro ore sono già bruciate da un pezzo. Le clausole di notifica accelerata nei contratti di fornitura software passano così da raffinatezza legale a requisito operativo. Il terzo profilo è quello di chi compra e utilizza, formalmente fuori dagli obblighi di fabbricante e sostanzialmente esposto su tre fronti diversi. Come utilizzatore ai sensi dell'AI Act, se impiega sistemi ad alto rischio. Come soggetto NIS2, se opera in un settore rientrante nell'ambito della direttiva. Come acquirente, nel caso in cui un proprio fornitore venisse designato ad alto rischio secondo il futuro impianto del Cybersecurity Act 2. Questo terzo profilo copre la maggioranza delle imprese italiane ed è oggi quello che si percepisce come meno coinvolto. ## Dove entra l'intelligenza artificiale Fino a qui il discorso appartiene alla sicurezza dei prodotti. Il passaggio successivo è quello che trasforma la materia in una questione di governance dell'intelligenza artificiale, e passa da una norma di raccordo che quasi nessuno sta usando. L'articolo 12 del Cyber Resilience Act stabilisce che, fatti salvi i requisiti di accuratezza e robustezza dell'articolo 15 dell'AI Act, i prodotti con elementi digitali che rientrano nell'ambito del regolamento e che sono classificati come sistemi di intelligenza artificiale ad alto rischio ai sensi dell'articolo 6 dell'AI Act si considerano conformi ai requisiti di cybersicurezza dell'articolo 15 dell'AI Act quando soddisfano i requisiti essenziali della Parte I dell'Allegato I, quando i processi messi in atto dal fabbricante rispettano i requisiti essenziali della Parte II dell'Allegato I, e quando il raggiungimento del livello di protezione richiesto viene dimostrato nella dichiarazione di conformità emessa ai sensi del regolamento stesso. La stessa norma prevede una semplificazione anche sul lato degli organismi, perché gli organismi notificati competenti a controllare la conformità dei sistemi ad alto rischio ai sensi dell'AI Act sono competenti anche a controllare la conformità di quegli stessi sistemi ai requisiti dell'Allegato I del Cyber Resilience Act, a condizione che la loro conformità ai requisiti dell'articolo 39 sia stata valutata nell'ambito della procedura di notifica prevista dall'AI Act. Un secondo ponte passa dal quadro di certificazione. L'articolo 42 dell'AI Act stabilisce che un sistema di intelligenza artificiale il quale abbia ottenuto una certificazione di cybersicurezza pertinente ai sensi del Cybersecurity Act può presumersi conforme a determinati requisiti di cybersicurezza dell'AI Act, il che apre una strada di riuso delle evidenze già prodotte. Il significato operativo di queste due norme è semplice e ampiamente sottoutilizzato. L'evidenza prodotta per il regime cyber vale come evidenza per il regime dell'intelligenza artificiale, a condizione che il perimetro documentale venga progettato con questo obiettivo fin dall'inizio. Chi costruisce due dossier separati paga due volte lo stesso lavoro, ottiene due volte lo stesso risultato e in più si espone al rischio di produrre affermazioni tecniche che divergono tra un fascicolo e l'altro, con tutto quello che questo comporta quando arriva un auditor. ## L'articolo 15 dell'AI Act letto per intero Il testo è tecnico ma vale la pena riportarlo, perché definisce il campo di gioco per chi sviluppa sistemi destinati a usi ad alto rischio. I sistemi ad alto rischio devono essere progettati e sviluppati in modo da conseguire un livello adeguato di accuratezza, robustezza e cybersicurezza, e da funzionare in modo coerente sotto questi profili lungo tutto il ciclo di vita. Devono inoltre essere resilienti rispetto ai tentativi di terzi non autorizzati di alterarne l'uso, gli output o le prestazioni sfruttando le vulnerabilità del sistema. Le vulnerabilità considerate sono specifiche dell'intelligenza artificiale, e questo è il punto in cui il tema si allontana dalla sicurezza informatica tradizionale. Le soluzioni tecniche devono includere, ove opportuno, misure per prevenire, rilevare, rispondere, risolvere e controllare gli attacchi che tentano di manipolare il set di dati di addestramento, i componenti pre-addestrati utilizzati nell'addestramento, gli input progettati per indurre il modello all'errore, oltre agli attacchi alla riservatezza e ai difetti del modello. In gergo tecnico si parla di data poisoning, model poisoning, adversarial examples e model evasion, e sono categorie che il team di sicurezza tradizionale in azienda quasi mai presidia. Per chi lavora su architetture ad agenti il perimetro si allarga ulteriormente. Un sistema che pianifica, invoca strumenti esterni e compie azioni porta dentro il confine di conformità l'autenticazione tra agenti, i permessi associati a ciascuna chiamata di strumento e la registrazione che consente di ricostruire a posteriori che cosa è successo e su quale base. In un'architettura multi-agente ogni componente che svolge una funzione ad alto rischio nella catena rientra nel perimetro, non soltanto quello che produce la decisione finale. ## Il calendario dell'AI Act dopo il Digital Omnibus Il rinvio dell'estate 2026 ha spostato le scadenze senza cancellare gli obblighi, e la distinzione è tutt'altro che formale. Il Regolamento (UE) 2026/1744 ha rinviato l'applicazione delle disposizioni sull'alto rischio. I sistemi autonomi riconducibili all'Allegato III dovranno rispettare i requisiti a partire dal 2 dicembre 2027, mentre i sistemi ad alto rischio integrati in prodotti già soggetti alla normativa di armonizzazione dell'Unione elencata nell'Allegato I, sezione A, avranno tempo fino al 2 agosto 2028. Resta pienamente applicabile dal 2 agosto 2026 tutto ciò che il rinvio non tocca, compresi i divieti dell'articolo 5 e gli obblighi di trasparenza dell'articolo 50. Il rinvio va letto per quello che è. Le date sono fisse e non risultano condizionate alla disponibilità delle norme armonizzate, perché il meccanismo condizionale inizialmente proposto dalla Commissione è stato abbandonato nel corso del negoziato. Chi aveva pianificato la conformità sul 2 agosto 2026 dispone quindi di tempo aggiuntivo e non di una sospensione a data indeterminata. C'è poi un cambio di interlocutore che passa quasi sempre inosservato e che vale la pena verificare nei gruppi societari. L'utilizzatore che faccia parte della stessa impresa del fornitore passa sotto la vigilanza esclusiva dell'AI Office a decorrere dal 2 agosto 2026. Per un gruppo che sviluppa internamente e distribuisce alle proprie controllate cambia l'autorità competente, e con essa cambiano interlocutori, tempi e forma della documentazione da tenere pronta. ## La catena di fornitura come rischio di intelligenza artificiale Nel nostro modello di AI Rating la dimensione dedicata al rischio copre compliance, etica, bias, sicurezza e privacy. Il pacchetto del 2026 introduce una variabile che finora pesavamo poco, ossia la sostenibilità del fornitore nel tempo. La quasi totalità delle imprese italiane non addestra modelli ma li acquista, e le domande di due diligence che si pongono oggi su un fornitore riguardano accuratezza, costo per token, latenza e residenza dei dati. Le domande che il quadro proposto rende rilevanti sono di natura diversa: chi controlla societariamente il fornitore, da quale giurisdizione, con quali dipendenze infrastrutturali a monte, e che cosa accadrebbe al servizio se quel fornitore finisse in un elenco di soggetti ad alto rischio con obbligo di dismissione entro un numero definito di mesi. Per un'azienda che ha appena costruito un processo core su un assistente conversazionale di terze parti questa diventa una questione di continuità operativa prima ancora che di conformità formale. Il costo di uscita da una dipendenza di intelligenza artificiale cresce con il tempo di adozione, e cresce più rapidamente di quanto i piani di procurement tendano ad assumere, perché al contratto si aggiungono progressivamente prompt, integrazioni, dati storici e abitudini di lavoro. Tre indicatori entrano quindi in modo naturale nella valutazione di rischio, senza bisogno di modificare l'impianto a quattro dimensioni del modello: la capacità dimostrata di notificare entro ventiquattro ore, l'esistenza e la manutenzione di una distinta base del software, la mappatura dell'esposizione verso fornitori potenzialmente designabili. ## NIS2 e il resto del quadro La proposta di modifica della direttiva NIS2 lavora sulla semplificazione più che sull'ampliamento, e questo la rende meno visibile di quanto meriti. Le modifiche mirate proposte il 20 gennaio 2026 puntano ad aumentare la chiarezza giuridica, semplificando la conformità alle regole europee e ai requisiti di gestione del rischio per le imprese che operano nell'Unione, con un beneficio stimato dalla Commissione su 28.700 imprese, tra cui 6.200 microimprese e piccole imprese. Il pacchetto promette confini di ambito più chiari, regole giurisdizionali semplificate, strumenti di vigilanza transfrontaliera più efficaci e un approccio unificato alla raccolta dei dati sugli attacchi ransomware, incoraggiando l'uso degli schemi di certificazione europei come percorso rapido per dimostrare la conformità. Sui tempi conviene non farsi illusioni. La proposta è attesa in adozione a fine 2026 o, più realisticamente, nel 2027, dopodiché gli Stati membri avranno dodici mesi per il recepimento e solo a quel punto la Commissione fisserà i requisiti tecnici e settoriali di dettaglio. Il perimetro soggettivo si allarga in alcuni punti specifici, perché la proposta estende l'ambito del settore delle infrastrutture digitali includendo i fornitori di portafogli europei di identità digitale e di portafogli aziendali europei, oltre agli operatori di infrastrutture sottomarine di trasmissione dati. Compare inoltre una categoria dimensionale intermedia, quella delle small mid-cap, designate come soggetti importanti anziché essenziali e quindi sottoposte a un regime di vigilanza e sanzionatorio più leggero. Un elemento è passato quasi inosservato e merita un posto stabile nel piano pluriennale di chiunque gestisca infrastrutture. Il nuovo articolo 7, paragrafo 2, lettera k), richiederebbe a ogni Stato membro di adottare all'interno delle proprie strategie nazionali di cybersicurezza le politiche per la transizione alla crittografia post-quantistica, allineate a tempistiche e requisiti già delineati in atti giuridici e documenti di indirizzo dell'Unione. È il momento in cui il rischio quantistico smette di essere un tema da conferenza e diventa una voce di programmazione. ## Gli impatti sui singoli ambiti aziendali Sul fronte del prodotto e dello sviluppo la distinta base del software smette di essere una buona pratica e diventa documentazione attesa. Le modifiche sostanziali a un prodotto già in commercio riaprono la valutazione di conformità, e le linee guida di luglio dedicano spazio proprio a definire quando una modifica debba considerarsi sostanziale. Il ciclo di rilascio va quindi progettato tenendo conto della finestra di supporto dichiarata all'utente. Per gli acquisti e per il legale i contratti software esistenti vanno riletti almeno su due voci: l'obbligo del fornitore di notificare entro tempi compatibili con le ventiquattro ore, e il diritto di ottenere la distinta base dei componenti forniti. Nessuna delle due è standard nei contratti firmati prima del 2025, e la rinegoziazione realistica avviene ai rinnovi. Sul fronte della sicurezza e delle operazioni serve un punto di contatto identificato e realmente raggiungibile, una procedura di triage che distingua una vulnerabilità attivamente sfruttata da una vulnerabilità semplicemente nota, e la registrazione alla piattaforma di segnalazione. Ventiquattro ore non consentono di costruire il processo mentre l'incidente è in corso, tanto più se l'evento arriva di venerdì sera o durante una chiusura aziendale. Per il consiglio di amministrazione e il comitato rischi l'esposizione va rappresentata su un'unica mappa con una sola scadenza. Portare in consiglio due roadmap separate, una cyber e una sull'intelligenza artificiale, produce due decisioni di budget scoordinate su un problema che ne richiede una sola. Sul versante finanziario il costo di conformità va stimato al netto delle sovrapposizioni. Le presunzioni di conformità dell'articolo 12 del Cyber Resilience Act e dell'articolo 42 dell'AI Act rappresentano, in termini pratici, una voce di risparmio concreta, a condizione che la documentazione venga impostata una volta sola e con entrambi i regimi in mente. ## La sequenza operativa da seguire La prima mossa riguarda il processo di notifica e ha scadenza già maturata. Serve un responsabile nominato, un flusso interno di valutazione delle segnalazioni e l'accesso alla piattaforma europea. È l'unico obbligo la cui data è passata mentre leggete. La seconda mossa, da chiudere entro la fine del 2026, è l'inventario. Servono due elenchi che quasi nessuna azienda possiede in forma aggiornata: i prodotti con elementi digitali immessi sul mercato, compresi quelli antecedenti alla piena applicazione, e i sistemi di intelligenza artificiale in uso o in sviluppo, ciascuno con fornitore, giurisdizione di controllo societario e criticità del processo servito. La terza mossa, collocabile nel primo trimestre 2027, è la valutazione congiunta della distanza dai requisiti. Una sola analisi che copra i requisiti essenziali dell'Allegato I del Cyber Resilience Act e i requisiti del Capo III dell'AI Act, con mappatura esplicita delle evidenze riutilizzabili tra i due regimi. Due esercizi separati costano di più e producono contraddizioni documentali difficili da spiegare. La quarta mossa occupa il 2027 e riguarda la conformità vera e propria: classificazione dei prodotti, scelta della procedura applicabile, coinvolgimento di un organismo notificato dove richiesto, documentazione tecnica e dichiarazione di conformità. In parallelo a tutto questo va condotta la revisione contrattuale, con le clausole corrette dalla prima firma sui fornitori nuovi e la rinegoziazione progressiva sui fornitori esistenti. ## Tre errori che vediamo ricorrere Il primo consiste nel guardare soltanto al 2027. La scadenza di settembre 2026 non richiede conformità di prodotto ma un processo funzionante, e chi la salta arriva al 2027 senza il presupposto organizzativo su cui poggia tutto il resto. Il secondo consiste nel separare la sicurezza informatica dalla governance dell'intelligenza artificiale. Sono due direzioni normative con un raccordo giuridico esplicito, e trattarle come progetti indipendenti significa produrre due volte le stesse evidenze rinunciando alle presunzioni di conformità che il legislatore ha previsto proprio per evitarlo. Il terzo consiste nel delegare al fornitore. La responsabilità di chi immette un prodotto sul mercato con il proprio marchio non si sposta a monte per via contrattuale, e il contratto serve a ottenere le informazioni in tempo utile più che a trasferire l'obbligo. ## Vocabolario dei termini usati **ACN, Agenzia per la Cybersicurezza Nazionale.** Autorità italiana competente in materia di cybersicurezza. Ospita il CSIRT Italia, destinatario delle notifiche previste dal Cyber Resilience Act per i soggetti italiani. **AI Act.** Regolamento (UE) 2024/1689 sull'intelligenza artificiale. Classifica i sistemi per livello di rischio e impone obblighi differenziati a fornitori e utilizzatori. **AI Office.** Ufficio europeo per l'intelligenza artificiale, struttura della Commissione con compiti di vigilanza e coordinamento sull'applicazione dell'AI Act, in particolare sui modelli per finalità generali. **Allegato I del Cyber Resilience Act.** Elenco dei requisiti essenziali di cybersicurezza, diviso in Parte I sui requisiti di prodotto e Parte II sui processi di gestione delle vulnerabilità in capo al fabbricante. **Allegato III dell'AI Act.** Elenco dei casi d'uso che qualificano un sistema come ad alto rischio, tra cui selezione del personale, gestione dei lavoratori, accesso a servizi essenziali, biometria e istruzione. **Allegati III e IV del Cyber Resilience Act.** Elenchi dei prodotti definiti importanti e critici, sottoposti a procedure di valutazione della conformità più severe rispetto al regime ordinario. **Atto di esecuzione e atto delegato.** Strumenti con cui la Commissione specifica il dettaglio tecnico di un regolamento dopo la sua adozione. Molti aspetti operativi del Cybersecurity Act 2 sono rinviati a questi atti. **CER.** Direttiva (UE) 2022/2557 sulla resilienza dei soggetti critici, complementare a NIS2 sul versante della sicurezza fisica. **COM seguito da anno e numero.** Codice identificativo di un documento della Commissione europea. COM(2026) 11 è la proposta di Cybersecurity Act 2, COM(2026) 13 la proposta di modifica di NIS2. **CRA, Cyber Resilience Act.** Regolamento (UE) 2024/2847 sui requisiti di cybersicurezza dei prodotti con elementi digitali. **CSA, Cybersecurity Act.** Regolamento (UE) 2019/881, istitutivo del mandato di ENISA e del quadro europeo di certificazione. Il Cybersecurity Act 2 è la proposta destinata a sostituirlo. **CSIRT.** Squadra nazionale di risposta agli incidenti informatici, designata per ricevere e gestire segnalazioni di incidenti e vulnerabilità. **Data poisoning.** Manipolazione deliberata dei dati di addestramento allo scopo di alterare il comportamento di un modello. Rientra tra le vulnerabilità citate dall'articolo 15 dell'AI Act. **Dichiarazione di conformità.** Documento con cui il fabbricante attesta sotto la propria responsabilità che il prodotto soddisfa i requisiti applicabili. È il punto in cui si materializza il raccordo tra Cyber Resilience Act e AI Act. **Digital Omnibus.** Pacchetto di semplificazione della normativa digitale europea. Sul versante dell'intelligenza artificiale ha prodotto il Regolamento (UE) 2026/1744, che ha modificato il calendario dell'AI Act. **DORA.** Regolamento (UE) 2022/2554 sulla resilienza operativa digitale del settore finanziario. **ECCF.** Quadro europeo di certificazione della cybersicurezza istituito dal Cybersecurity Act, oggi a partecipazione volontaria. **ENISA.** Agenzia dell'Unione europea per la cybersicurezza. Gestisce la piattaforma unica di segnalazione e il database europeo delle vulnerabilità. **Fabbricante.** Chi immette un prodotto sul mercato europeo con il proprio nome o marchio assumendone la responsabilità commerciale. Non coincide necessariamente con chi ha scritto il codice. **Incidente grave.** Evento che incide negativamente sulla sicurezza di un prodotto con elementi digitali, secondo la soglia definita dal regolamento. Attiva la cascata di ventiquattro ore, settantadue ore e un mese. **ISO/IEC 42001.** Standard internazionale per i sistemi di gestione dell'intelligenza artificiale, certificabile da organismi accreditati. Utile come impianto documentale, distinto però dagli obblighi di legge. **NIS2.** Direttiva (UE) 2022/2555 sulla sicurezza delle reti e dei sistemi informativi. Impone misure di gestione del rischio e obblighi di segnalazione a soggetti essenziali e importanti nei settori individuati. **Organismo notificato.** Soggetto terzo autorizzato da uno Stato membro a svolgere valutazioni di conformità. Il capo IV del Cyber Resilience Act ne disciplina la notifica ed è applicabile dall'11 giugno 2026. **PQC, crittografia post-quantistica.** Insieme di algoritmi crittografici progettati per resistere ad attacchi condotti con computer quantistici. La proposta di modifica di NIS2 li nomina espressamente. **Presunzione di conformità.** Meccanismo per cui il rispetto di un requisito in un regime normativo fa considerare soddisfatto il requisito corrispondente in un altro regime. È il fulcro dell'articolo 12 del Cyber Resilience Act. **Procedura legislativa ordinaria.** Iter con cui Parlamento europeo e Consiglio adottano congiuntamente un atto su proposta della Commissione. Comprende la fase di negoziato informale detta trilogo. **Prodotto con elementi digitali.** Categoria del Cyber Resilience Act che comprende hardware e software con connessione diretta o indiretta a dispositivi o reti. **SBOM, distinta base del software.** Elenco strutturato dei componenti software di un prodotto, comprese le dipendenze di terze parti e open source. **Small mid-cap.** Categoria dimensionale intermedia tra piccola e media impresa e grande impresa, introdotta nella proposta di modifica di NIS2 con un regime alleggerito. **SRP, Single Reporting Platform.** Piattaforma unica gestita da ENISA per ricevere le segnalazioni previste dal Cyber Resilience Act, con inoltro automatico ai CSIRT interessati. **Utilizzatore.** Nel linguaggio dell'AI Act, chi impiega un sistema di intelligenza artificiale sotto la propria autorità nell'ambito di un'attività professionale. Si distingue dal fornitore, che sviluppa e immette sul mercato. **Vulnerabilità attivamente sfruttata.** Difetto di sicurezza per cui esistono prove di sfruttamento in corso da parte di un attore malevolo. È la condizione che attiva l'obbligo di allerta entro ventiquattro ore. ## Il punto di decisione La convergenza di dicembre 2027 rende visibile una cosa che era già vera da tempo. La governance dell'intelligenza artificiale in azienda passa dalla catena di fornitura tecnologica almeno quanto passa dai modelli, e chi non sa quali sistemi utilizza, chi glieli fornisce e da quale giurisdizione non possiede gli elementi minimi per stimare la propria esposizione su nessuno dei due versanti. La misurazione precede la decisione. Prima di aprire un cantiere di conformità conviene sapere a che punto si trova l'organizzazione: quali sistemi sono in uso, quale documentazione esiste già, quali evidenze sono riutilizzabili tra i due regimi, quali fornitori rappresentano una dipendenza critica e quanto costerebbe uscirne. Per una valutazione strutturata della maturità e dell'esposizione normativa scrivete a hello@zerofive.ai oppure prenotate un confronto su calendly.com/fabiolalli/zerofive. **Fonti.** Commissione europea, proposte COM(2026) 11 e COM(2026) 13 del 20 gennaio 2026, e Comunicazione C(2026) 5252 del 27 luglio 2026. Testi normativi citati: Cyber Resilience Act, Regolamento (UE) 2024/2847; AI Act, Regolamento (UE) 2024/1689; Digital Omnibus sull'intelligenza artificiale, Regolamento (UE) 2026/1744 pubblicato in Gazzetta ufficiale il 24 luglio 2026. Consiglio dell'Unione europea, Progress Report del 22 maggio 2026. Agenzia per la Cybersicurezza Nazionale, comunicazione di settembre 2026. --- # Agenti AI: cosa sono, cosa fanno e dove conviene usarli in azienda URL: https://zerofive.ai/blog/ai-governance/agenti-ai-guida-aziende Data: 2026-09-04 Abstract: Cosa distingue un agente da un assistente, i quattro schemi che funzionano, dove si rompono i progetti e cosa serve prima della produzione. **In sintesi.** Un agente AI non si limita a rispondere, ma esegue: pianifica una sequenza di passi, usa strumenti, legge e scrive su sistemi aziendali e produce effetti che restano. È la ragione per cui funziona meglio di un assistente sui processi ripetitivi e la ragione per cui fallisce più spesso, visto che fino al 46% dei progetti agentici non arriva in produzione. Prima di costruirne uno conviene sapere quali schemi reggono, cosa costa davvero e dove l'automazione tocca obblighi normativi. La parola agente viene usata per cose molto diverse, dalla macro che invia una mail al sistema che negozia un ordine. Questa guida separa i casi, con i criteri per capire quale conviene a un'azienda e quale è meglio rimandare. ## Cosa distingue un agente da un assistente Un assistente produce testo e si ferma lì, lasciando alla persona la decisione e l'azione. Un agente riceve un obiettivo, decide i passi necessari, chiama strumenti esterni e agisce. La differenza pratica riguarda l'errore. Un assistente che sbaglia produce una risposta che qualcuno legge, valuta e scarta. Un agente che sbaglia apre un ticket, invia una comunicazione o modifica un record, e il recupero richiede tempo e spesso una spiegazione a qualcuno fuori dall'azienda. Questo sposta il baricentro del progetto. Nei sistemi conversazionali il lavoro sta nella qualità delle risposte, mentre nei sistemi agentici sta nei limiti: cosa può toccare, fino a che punto può procedere da solo, quando deve fermarsi e chiedere. ## I quattro schemi che funzionano in azienda | Schema | Cosa fa | Dove conviene | |---|---|---| | Agente di lettura | Raccoglie informazioni da più fonti e produce un riepilogo | Istruttoria di pratiche, preparazione di riunioni | | Agente di controllo | Verifica che un documento o un dato rispetti regole note | Contratti, pratiche, dati anagrafici | | Agente di smistamento | Classifica richieste in arrivo e le instrada | Assistenza clienti, posta condivisa, ticket | | Agente operativo sorvegliato | Esegue operazioni su sistemi, con approvazione su soglia | Ordini ricorrenti, solleciti, aggiornamenti anagrafici | I primi tre schemi producono valore con rischio contenuto, perché l'azione finale resta a una persona. Il quarto è quello che genera il risparmio più visibile ed è anche quello che richiede il presidio più serio, con soglie di autorizzazione, registrazione delle azioni e possibilità di arresto immediato. Fuori da questi quattro schemi ci sono i progetti che partono con obiettivi ampi, del tipo gestire il processo degli acquisti. Sono quelli che consumano budget per mesi e si fermano al test, perché nessuno riesce a definire cosa significhi successo. ## Dove si rompono I dati di mercato raccontano un divario netto tra intenzione e risultato: quasi tre quarti delle organizzazioni prevede di adottare agenti entro due anni, circa una su cinque dichiara una governance matura per gestirli, e una quota vicina alla metà dei proof of concept non supera la fase di test. Le cause che vediamo nei progetti si ripetono. Mancano i KPI, quindi non esiste un criterio per dire se l'agente ha funzionato. Mancano le integrazioni, perché l'agente legge un sistema e scrive in un foglio invece che nel gestionale. Manca lo sponsor, e il progetto resta un esperimento tecnico senza una funzione che lo adotti. C'è poi una causa meno discussa e molto frequente. L'agente funziona nei casi normali e si comporta in modo imprevedibile nei casi limite, e nelle operazioni reali i casi limite sono la maggioranza del valore. Un agente che gestisce il 70% delle pratiche e consegna il 30% peggiore a una persona senza spiegazioni crea più lavoro di quanto ne tolga. ## Cosa serve prima di metterne uno in produzione Serve un elenco scritto dei sistemi su cui l'agente può agire, con il livello di accesso per ciascuno. Serve un'identità dedicata, perché un agente che usa le credenziali di una persona rende impossibile distinguere le azioni e inutile il registro. Serve una soglia oltre la quale l'agente si ferma e chiede conferma, tarata sull'impatto economico o sulla visibilità verso il cliente. Serve soprattutto un responsabile, con il potere di fermare il sistema senza passare da altri. Su questo abbiamo scritto in dettaglio in [nessun agente in produzione senza un owner](/blog/ai-governance/agenti-ai-owner-nominativo-produzione). ## Quanto consuma e quanto costa Un agente costa più di un assistente a parità di richieste, perché ogni obiettivo genera più passaggi, e ogni passaggio consuma. Un flusso che a un assistente costa una chiamata può costarne otto o dieci a un agente che ragiona, verifica e riprova. La stima va fatta sul volume reale e sul comportamento peggiore, non su quello medio. Un agente che in condizioni normali esegue tre passi e in condizioni difficili ne esegue venti va dimensionato sul secondo numero, perché i casi difficili tendono a concentrarsi nei periodi di picco. A questo si aggiunge il costo di sorveglianza nei primi mesi, che è tempo di persone esperte, e la manutenzione quando cambia un sistema a valle. Un'integrazione che si rompe lascia l'agente a metà di una sequenza, e quella condizione va gestita prima che accada. ## Quando un agente ricade in Allegato III La classificazione segue il caso d'uso, non il nome del sistema. Un agente che smista candidature opera nella gestione del personale, quindi ricade nell'Allegato III dell'AI Act insieme agli obblighi che ne derivano, e lo stesso vale per un agente che interviene nella valutazione del merito creditizio o nell'accesso a servizi essenziali. C'è un secondo passaggio da conoscere. Un'azienda che usa un agente in modo diverso da quanto previsto dal fornitore, o che lo modifica in modo sostanziale, può assumere il ruolo di fornitore e gli obblighi che lo accompagnano. La distinzione tra uso previsto e uso effettivo va messa per iscritto nel [registro dei sistemi](/blog/compliance/registro-sistemi-ai-come-costruirlo). ## Come si sceglie il primo Il primo agente va scelto dove il volume è alto, le regole sono chiare e l'errore è recuperabile. Lo smistamento della posta condivisa risponde a tutti e tre i criteri, la gestione dei reclami a nessuno. Il perimetro iniziale deve essere stretto, con un sottoinsieme di casi e un periodo definito, e con la baseline misurata prima: quante richieste arrivano, quanto tempo richiedono oggi, quale percentuale viene gestita male. Senza quei numeri la valutazione finale diventa una discussione tra impressioni. L'ultima raccomandazione riguarda l'uscita. Va deciso in anticipo cosa succede se l'agente va fermato, chi riprende il lavoro e con quale procedura, perché un processo che dipende da un sistema senza alternativa manuale diventa un rischio operativo. ## Da dove partire Per capire se un progetto agentico ha senso nel vostro contesto ci sono [PoC di agenti AI](/blog/strategia/poc-agenti-ai-come-farle-funzionare) e [agenti AI in azienda](/blog/approfondimenti/agenti-ai-azienda). La parte di governo è in [nessun agente in produzione senza un owner](/blog/ai-governance/agenti-ai-owner-nominativo-produzione), mentre l'inquadramento normativo generale è in [AI Act: guida completa](/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati). Per valutare quali processi reggono un agente e quali no puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # AI system impact assessment: DPIA, AI Act e ISO/IEC 42001 a confronto URL: https://zerofive.ai/blog/compliance/impact-assessment-dpia-ai-act-iso-42001 Data: 2026-09-03 Abstract: DPIA, conformity assessment AI Act e AI system impact assessment ISO 42001: cosa valutano davvero e come evitare di farne tre separati. In una valutazione recente ci siamo trovati davanti a tre documenti diversi, prodotti da tre consulenti diversi, che rispondevano tutti alla stessa domanda: questo sistema AI è rischioso? Nessuno dei tre sapeva dell'esistenza degli altri due, e nessuno dei tre copriva davvero l'intero perimetro del rischio. ## Tre valutazioni, tre scopi diversi La DPIA nasce dal GDPR e guarda ai dati personali: cosa si raccoglie, con quale base giuridica, con quale impatto sulla persona. La conformity assessment dell'AI Act guarda alla classificazione del sistema per fascia di rischio, e agli obblighi che ne derivano se il sistema finisce in Allegato III. L'AI system impact assessment richiesto da ISO/IEC 42001 guarda a un perimetro più ampio ancora: non solo dati e non solo classificazione normativa, ma impatto complessivo su persone, organizzazione e società, incluso quello che non tocca la privacy e non rientra nelle categorie ad alto rischio dell'AI Act. Un sistema di raccomandazione interno che non tratta dati personali sensibili può non avere bisogno di DPIA, restare fuori dalle categorie critiche dell'AI Act, e avere comunque bisogno di un impact assessment ISO 42001, perché incide su decisioni che riguardano persone reali. ## Dove si sovrappongono (e dove no) - **Perimetro dati**: coperto da tutte e tre, ma la DPIA lo tratta in profondità, le altre due lo toccano solo come una delle dimensioni di rischio - **Classificazione del rischio**: proprietà quasi esclusiva dell'AI Act, ISO 42001 la richiama come input ma non la sostituisce - **Impatto su gruppi non individuabili**: bias su categorie di persone, effetti sistemici, terreno che la DPIA non copre e che ISO 42001 tratta esplicitamente - **Governance e responsabilità**: chi ha approvato, chi ne risponde, presente in tutte e tre ma con owner spesso diversi, privacy officer per la DPIA, risk owner per l'AI Act, process owner per ISO 42001 La sovrapposizione in sé pesa meno del vero rischio concreto: che tre uffici diversi producano tre valutazioni parallele che non si parlano tra loro, ognuna convinta di aver coperto il problema per intero. ## Un processo solo, tre lenti applicate Le organizzazioni che gestiscono bene questo terreno non scrivono tre documenti separati, costruiscono un unico processo di valutazione con sezioni modulari: una parte comune che raccoglie i fatti del sistema, che dati usa, che decisioni automatizza, chi ne è coinvolto, e poi tre lenti applicate agli stessi fatti. Chi ha già una DPIA matura ha già l'ottanta per cento del lavoro fatto, deve solo aggiungere le domande che mancano. ## Chi si parla con chi prima che il sistema parta Un processo unico da solo non basta se privacy, risk e AI governance continuano a lavorare in stanze separate: più che di template condivisi, la questione riguarda chi si parla con chi prima che il sistema entri in produzione, non dopo che qualcuno ha già firmato l'autorizzazione al lancio. È spesso qui, non nella tecnica della valutazione, che le organizzazioni perdono settimane in rilavorazioni evitabili. ## Prima di scrivere il primo assessment Chi deve avviare questo lavoro fa bene a partire da un solo documento condiviso, non da tre moduli separati, e a coinvolgere chi già fa le DPIA prima di iniziare da zero. Il pezzo successivo di questa serie entra nel dettaglio del prossimo passo naturale: l'inventario dei sistemi AI, la base senza cui nessun impact assessment sa davvero cosa sta valutando. --- # AI Act: guida completa a obblighi, responsabilità e dati URL: https://zerofive.ai/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati Data: 2026-09-02 Abstract: Obblighi AI Act per fornitori e deployer, classi di rischio, dati e diritti, sanzioni e piano operativo per fasi. Guida per le aziende. L'AI Act non è una norma tecnica per addetti ai lavori: è la cornice che decide quali sistemi di intelligenza artificiale un'azienda può mettere sul mercato o usare in Europa, con quali controlli e con quale catena di responsabilità. Questa guida raccoglie in un unico punto le definizioni, la classificazione del rischio, gli obblighi per ruolo, il trattamento dei dati e i diritti delle persone, il calendario applicativo e le sanzioni. È pensata per chi deve prendere decisioni: direzione generale, legale, compliance, data protection, IT e business owner dei progetti AI. ## 1. Cos'è l'AI Act e a chi si applica Il Regolamento (UE) 2024/1689 è il primo quadro normativo orizzontale al mondo sull'intelligenza artificiale. Non regola una tecnologia specifica ma il modo in cui i sistemi di AI vengono immessi sul mercato, messi in servizio e utilizzati, applicando obblighi proporzionati al rischio che generano per la salute, la sicurezza e i diritti fondamentali. **Definizione di sistema di AI.** Un sistema automatizzato progettato per operare con livelli variabili di autonomia, che può mostrare adattività dopo la messa in servizio e che, a partire dagli input ricevuti, deduce come generare output (previsioni, contenuti, raccomandazioni, decisioni) capaci di influenzare ambienti fisici o virtuali. La deduzione è l'elemento discriminante: un software che applica regole deterministiche scritte da una persona non rientra nel perimetro, un modello che apprende relazioni dai dati sì. **Modelli per finalità generali (GPAI).** I modelli generativi di grandi dimensioni hanno un capitolo dedicato, con obblighi di documentazione tecnica, informativa a valle, politica di rispetto del diritto d'autore e sintesi pubblica dei dati di addestramento. Per i modelli che presentano rischio sistemico si aggiungono valutazione avversariale, mitigazione dei rischi, tracciamento degli incidenti gravi e sicurezza informatica rafforzata. **Ambito extraterritoriale.** Il regolamento si applica a fornitori stabiliti fuori dall'Unione quando l'output del sistema viene utilizzato nell'Unione. Una società italiana che integra un modello sviluppato negli Stati Uniti non trasferisce il rischio al fornitore: assume obblighi propri come deployer e, in certi casi, diventa essa stessa fornitore. **Cosa resta fuori.** Sistemi usati esclusivamente per scopi militari, di difesa o sicurezza nazionale; attività di ricerca e sviluppo prima dell'immissione sul mercato; uso strettamente personale non professionale; componenti rilasciate con licenza libera e open source, salvo quando ricadono in categorie vietate o ad alto rischio. **Rapporto con il Digital Omnibus.** Il pacchetto di semplificazione ha ricalibrato tempi e adempimenti su alcuni fronti, ma non ha modificato l'impianto: divieti, classificazione del rischio, obblighi per i sistemi ad alto rischio e regime GPAI restano il centro della norma. Ne abbiamo scritto in dettaglio nell'analisi sul [Digital Omnibus](/blog/compliance/digital-omnibus-regolamento-2026-1744) e nel punto sulle [scadenze del 2 agosto 2026](/blog/compliance/ai-act-2-agosto-2026-cosa-e-vincolante). ## 2. Le quattro classi di rischio La classificazione è il primo esercizio operativo: senza di essa ogni valutazione successiva è arbitraria. | Classe | Esempi aziendali | Conseguenza | |---|---|---| | Rischio inaccettabile | Social scoring, riconoscimento delle emozioni sul posto di lavoro, tecniche manipolative, scraping non mirato di volti per costruire database biometrici | Divieto assoluto, già applicabile | | Alto rischio | Screening e selezione dei candidati, valutazione delle prestazioni e promozioni, scoring creditizio, pricing e sottoscrizione assicurativa vita e salute, componenti di sicurezza di prodotti regolamentati, sistemi usati in istruzione, servizi essenziali, giustizia | Regime completo di conformità, valutazione di conformità, marcatura CE, registrazione | | Rischio limitato | Chatbot verso il cliente, generazione di contenuti sintetici, deepfake, sistemi che interagiscono con persone fisiche | Obblighi di trasparenza e marcatura dei contenuti | | Rischio minimo | Filtri antispam, ottimizzazione logistica interna, suggerimenti di prodotto non determinanti | Nessun obbligo specifico, codici di condotta volontari | Due precisazioni che generano la maggior parte degli errori di classificazione. La prima: un sistema elencato tra quelli ad alto rischio può essere declassato se svolge un compito procedurale ristretto, migliora il risultato di un'attività umana già completata, rileva soltanto deviazioni da schemi decisionali senza sostituire la valutazione umana o esegue un compito preparatorio. Il declassamento va documentato, non presunto, e cade comunque quando il sistema effettua profilazione di persone fisiche. La seconda: la classe dipende dalla finalità d'uso, non dalla tecnologia. Lo stesso modello linguistico è a rischio limitato in un chatbot informativo e ad alto rischio se filtra curricula. La classificazione va tenuta in un registro dei sistemi AI, con owner, finalità, dati trattati, ruolo dell'azienda e classe di rischio. È il punto di partenza dell'[AI Assessment](/servizi/ai-assessment) e la base su cui costruiamo l'[AI Rating](/servizi/ai-rating). ## 3. Ruoli e responsabilità lungo la catena L'AI Act distribuisce gli obblighi su cinque ruoli. Un'azienda può ricoprirne più di uno contemporaneamente, per sistemi diversi o addirittura per lo stesso sistema in mercati diversi. | Ruolo | Chi è | Obblighi principali | |---|---|---| | Fornitore | Sviluppa il sistema o lo fa sviluppare e lo immette sul mercato con il proprio nome o marchio | Sistema di gestione della qualità e del rischio, documentazione tecnica, valutazione di conformità, marcatura CE, registrazione nella banca dati UE, monitoraggio post commercializzazione, segnalazione degli incidenti gravi | | Deployer | Utilizza il sistema sotto la propria autorità nell'ambito di un'attività professionale | Uso conforme alle istruzioni, sorveglianza umana con persone competenti, qualità dei dati di input controllabili, conservazione dei log, informativa ai lavoratori e agli interessati, valutazione d'impatto sui diritti fondamentali nei casi previsti | | Importatore | Immette sul mercato UE un sistema di un fornitore extra UE | Verifica di conformità, documentazione, tracciabilità, cooperazione con le autorità | | Distributore | Rende disponibile il sistema sul mercato senza esserne fornitore o importatore | Verifica di marcatura e documentazione, sospensione della distribuzione in caso di non conformità | | Rappresentante autorizzato | Soggetto nell'Unione designato da un fornitore extra UE | Custodia della documentazione, interfaccia con le autorità | **Quando un deployer diventa fornitore.** È lo scenario più sottovalutato e il più frequente nelle aziende che adottano AI senza svilupparla. Si diventa fornitori quando si appone il proprio nome o marchio su un sistema ad alto rischio già immesso sul mercato, quando si modifica sostanzialmente un sistema ad alto rischio già in uso, oppure quando si modifica la finalità di un sistema in modo che diventi ad alto rischio. Un esempio concreto: un modello generale integrato in un flusso di valutazione dei candidati e riesposto internamente come strumento HR aziendale trasforma il deployer in fornitore, con l'intero pacchetto di obblighi che ne consegue. Su questo punto la governance vale più della tecnologia: serve una regola interna che stabilisca chi autorizza integrazioni e modifiche e con quale istruttoria. È il lavoro che facciamo nel percorso di [AI Governance](/ai-governance) e nella definizione della [AI Strategy](/servizi/ai-strategy). ## 4. Obblighi operativi per i sistemi ad alto rischio Per i sistemi in classe alta il regolamento richiede un sistema di conformità permanente, non un adempimento una tantum. **Sistema di gestione del rischio.** Processo iterativo che copre l'intero ciclo di vita: identificazione dei rischi ragionevolmente prevedibili per salute, sicurezza e diritti fondamentali, stima dei rischi in condizioni d'uso previste e di uso improprio prevedibile, adozione di misure di mitigazione, test con metriche e soglie definite in anticipo. **Governance dei dati.** I set di addestramento, validazione e test devono essere pertinenti, sufficientemente rappresentativi e, per quanto possibile, privi di errori e completi rispetto alla finalità. Vanno esaminate le possibili distorsioni che incidono su salute, sicurezza e diritti, con misure di rilevazione e correzione. Questo è il capitolo che collega direttamente l'AI Act al lavoro sui dati che trattiamo in [AI Data](/servizi/ai-data). **Documentazione tecnica e registrazione automatica.** La documentazione deve dimostrare la conformità prima dell'immissione sul mercato e restare aggiornata. I sistemi devono registrare automaticamente gli eventi lungo il ciclo di vita, con log conservati per un periodo adeguato alla finalità e comunque non inferiore a sei mesi salvo diversa previsione. **Trasparenza verso il deployer.** Istruzioni per l'uso chiare, con caratteristiche, capacità, limiti di prestazione, livelli di accuratezza attesi, condizioni che possono generare rischi, misure di sorveglianza umana previste e vita utile attesa. **Sorveglianza umana.** Il sistema deve essere progettato perché una persona possa comprenderne le capacità e i limiti, interpretarne correttamente l'output, decidere di non usarlo, ignorarne il risultato o interromperne il funzionamento. La sorveglianza umana non è una firma finale su un output già formato: se chi supervisiona non ha il tempo, l'informazione e l'autorità per dissentire, l'obbligo non è soddisfatto. **Accuratezza, robustezza e cybersicurezza.** Livelli adeguati e coerenti lungo il ciclo di vita, con resilienza a errori, guasti, incoerenze e tentativi di manipolazione dei dati o del modello, incluso il data poisoning e gli attacchi avversariali. **Valutazione di conformità e marcatura CE.** A seconda del caso, controllo interno o intervento di un organismo notificato, seguito da dichiarazione di conformità UE, marcatura CE e registrazione nella banca dati europea. **Monitoraggio post commercializzazione.** Raccolta e analisi sistematica dei dati sulle prestazioni reali, con obbligo di segnalare gli incidenti gravi alle autorità entro termini stretti. ## 5. Dati e diritti delle persone L'AI Act non sostituisce il GDPR: si sovrappone. Ogni sistema che tratta dati personali deve soddisfare entrambi i regimi, e nella pratica è qui che si concentrano i contenziosi e le contestazioni interne. **Base giuridica e minimizzazione.** Prima di ogni valutazione tecnica serve una base giuridica valida per l'addestramento, per il fine tuning e per l'inferenza, con finalità distinte e documentate. Riusare dati raccolti per l'erogazione di un servizio per addestrare un modello è un cambio di finalità che va giustificato, non una prosecuzione naturale. **Decisioni automatizzate.** L'articolo 22 del GDPR limita le decisioni interamente automatizzate che producono effetti giuridici o incidono in modo analogamente significativo sulla persona. Non basta inserire un revisore formale: serve un intervento umano significativo. Abbiamo approfondito il tema nell'articolo sull'[articolo 22 del GDPR nelle decisioni aziendali](/blog/compliance/articolo-22-gdpr-decisioni-automatizzate-azienda). **DPIA e valutazione d'impatto sui diritti fondamentali.** La DPIA resta l'obbligo del GDPR quando il trattamento presenta rischi elevati. La FRIA è l'obbligo dell'AI Act per determinati deployer di sistemi ad alto rischio, in particolare organismi pubblici e soggetti che erogano servizi pubblici essenziali oltre a specifici casi in ambito creditizio e assicurativo. Sono strumenti distinti ma con evidenze in larga parte comuni: conviene progettarli come un unico fascicolo con due viste, non come due esercizi paralleli. **Trasparenza verso le persone.** Chi interagisce con un sistema di AI deve saperlo, salvo che sia palese dal contesto. I contenuti sintetici vanno marcati in formato leggibile dalla macchina. I deepfake e i testi pubblicati per informare il pubblico su questioni di interesse generale richiedono dichiarazione esplicita. Nei luoghi di lavoro, i lavoratori e i loro rappresentanti vanno informati prima della messa in servizio di un sistema ad alto rischio. **Diritto alla spiegazione.** La persona soggetta a una decisione presa da un sistema ad alto rischio che produce effetti giuridici o incide significativamente su di lei ha diritto a ottenere dal deployer spiegazioni chiare e significative sul ruolo del sistema nella decisione e sui principali elementi che l'hanno determinata. Tradotto in requisito tecnico: servono log a livello di singola decisione, versionamento del modello e delle regole, e una spiegazione comprensibile senza gergo statistico. **Dati nei modelli e diritti degli interessati.** Cancellazione, rettifica e opposizione vanno gestite anche quando i dati sono confluiti nell'addestramento. Le strade praticabili sono la filtrazione a monte, la separazione fra base di conoscenza recuperabile e pesi del modello, e la scelta architetturale del recupero documentale rispetto al fine tuning quando i dati personali sono in gioco. ## 6. AI literacy e obblighi trasversali L'obbligo di alfabetizzazione riguarda tutti i fornitori e i deployer, indipendentemente dalla classe di rischio dei sistemi utilizzati: il personale che si occupa del funzionamento e dell'uso dei sistemi deve avere un livello sufficiente di competenza, tenuto conto del contesto e delle persone su cui il sistema incide. Non è un corso una tantum ma un programma proporzionato al ruolo: chi seleziona i fornitori, chi supervisiona gli output e chi progetta i processi hanno bisogni formativi diversi. È esattamente la logica dei percorsi [AI Training](/servizi/ai-training) e dei [corsi e workshop aziendali](/corsi). ## 7. Sanzioni e calendario | Violazione | Massimale | |---|---| | Pratiche vietate | 35 milioni di euro o 7% del fatturato mondiale annuo | | Violazione degli obblighi su sistemi ad alto rischio, trasparenza, GPAI | 15 milioni di euro o 3% del fatturato | | Informazioni inesatte, incomplete o fuorvianti alle autorità | 7,5 milioni di euro o 1% del fatturato | Si applica il valore più elevato tra importo fisso e percentuale, con soglie ridotte per le PMI. Il calendario è scaglionato: i divieti e gli obblighi di alfabetizzazione sono già applicabili, il regime GPAI è entrato in vigore nella seconda fase, gli obblighi sui sistemi ad alto rischio seguono con tempi differenziati fra i sistemi elencati negli allegati e quelli che sono componenti di sicurezza di prodotti già regolamentati. In Italia si aggiunge il quadro nazionale, con la legge 132/2025 e l'estensione della responsabilità amministrativa degli enti attraverso il [nuovo articolo 25-vicies del D.Lgs. 231/2001](/blog/compliance/dlgs-231-articolo-25-vicies-ai): un profilo che sposta il tema dal budget della compliance a quello del consiglio di amministrazione. ## 8. Dalla norma alla governance interna La conformità non si ottiene con un documento: si ottiene con un sistema di gestione che produce evidenze in modo ripetibile. ISO/IEC 42001 è oggi lo strumento più efficace per farlo, perché fornisce la struttura organizzativa (politica, ruoli, obiettivi, controlli, audit interni, riesame della direzione) su cui appoggiare i requisiti dell'AI Act. Il confronto puntuale fra i due impianti è nella nostra [guida ai framework di AI governance](/blog/ai-governance/guida-framework-ai-governance-iso-42001-eu-ai-act). Gli elementi minimi di una governance che regge un'ispezione sono cinque: una policy AI approvata dal vertice, un registro dei sistemi con classificazione motivata, un processo di autorizzazione dei nuovi casi d'uso con gate espliciti, log e documentazione conservati per sistema, un ciclo di riesame periodico con owner nominati. Il resto è dettaglio implementativo. Chi vuole misurare la propria distanza da questo punto può partire dal nostro percorso di [compliance AI](/compliance-ai). ## 9. Un piano operativo per fasi **Prima fase, inventario e classificazione.** Censimento di tutti i sistemi di AI in uso, inclusi quelli acquistati come funzionalità dentro software di terze parti e quelli introdotti da singoli team senza autorizzazione. Per ciascuno: finalità, ruolo dell'azienda, dati trattati, classe di rischio, owner. L'output è il registro dei sistemi AI e una lista di priorità. **Seconda fase, gap analysis e decisioni.** Confronto fra obblighi applicabili ed evidenze esistenti, per sistema. Decisioni esplicite su cosa dismettere, cosa portare a conformità, cosa rinegoziare con i fornitori. Qui si scrive la policy AI e si definisce il processo di autorizzazione. **Terza fase, remediation e prova.** Chiusura dei gap prioritari, attivazione del logging, formalizzazione della sorveglianza umana, avvio del programma di AI literacy, test del processo su un caso reale. La durata di ciascuna fase dipende dal numero di sistemi in uso, dalla maturità dei processi esistenti e dalla disponibilità delle evidenze: quello che conta è l'ordine, non il calendario. Al termine si deve poter rispondere a tre domande con documenti alla mano: quali sistemi usiamo, chi ne risponde, come dimostriamo che sono sotto controllo. Sul lato adozione il principio è simmetrico: nessun sistema arriva in produzione senza validazione. È la logica del percorso di [AI Adoption](/ai-adoption), della validazione rapida con [PROTOT.AI](/protot-ai) e della messa in esercizio degli [agenti AI](/servizi/ai-agents). ## 10. Domande frequenti **L'AI Act si applica anche se usiamo solo strumenti di terze parti?** Sì. Chi utilizza un sistema di AI nell'ambito di un'attività professionale è un deployer e ha obblighi propri, che non si trasferiscono al fornitore per contratto. **Un chatbot interno è ad alto rischio?** Di norma no, se serve a rispondere a domande e non concorre a decisioni su persone. Diventa ad alto rischio se entra in processi di selezione, valutazione, accesso a servizi essenziali o credito. **Basta inserire un revisore umano per uscire dall'alto rischio?** No. La sorveglianza umana è un requisito dei sistemi ad alto rischio, non una via di uscita dalla classificazione. Il declassamento è possibile solo nei casi tipizzati e va documentato. **Che differenza c'è fra DPIA e FRIA?** La DPIA riguarda i rischi per la protezione dei dati ed è un obbligo GDPR. La FRIA riguarda l'impatto sui diritti fondamentali ed è un obbligo AI Act per determinati deployer di sistemi ad alto rischio. Condividono gran parte delle evidenze. **Se modifichiamo un modello acquistato diventiamo fornitori?** Se la modifica è sostanziale su un sistema ad alto rischio, o se cambia la finalità rendendolo ad alto rischio, sì. Anche apporre il proprio marchio produce lo stesso effetto. **Quanto tempo serve per essere conformi?** Per un'azienda con pochi sistemi non critici, un trimestre di lavoro strutturato è sufficiente a chiudere l'impianto. Per portafogli con sistemi ad alto rischio i tempi dipendono dalla valutazione di conformità e dal livello di documentazione già disponibile. **Le PMI hanno un regime più leggero?** Non sono esentate, ma beneficiano di massimali sanzionatori ridotti, documentazione semplificata in alcuni casi e accesso prioritario alle sandbox normative nazionali. ## Il passo successivo Le organizzazioni che affrontano bene l'AI Act non sono quelle che leggono più articoli del regolamento: sono quelle che trasformano il testo in un registro, un processo di autorizzazione e un insieme di evidenze aggiornate. È un lavoro di governo, non di adempimento. Se vuoi capire dove si trova la tua azienda rispetto a questo quadro, il modo più veloce è una conversazione di trenta minuti oppure un [AI Rating](/servizi/ai-rating), la nostra valutazione strutturata della maturità e dell'esposizione normativa. Da lì si costruisce un piano che tiene insieme conformità e capacità di portare l'AI in produzione. --- # Formazione sull'intelligenza artificiale in azienda: come si costruisce un piano che serve URL: https://zerofive.ai/blog/compliance/formazione-intelligenza-artificiale-aziende Data: 2026-09-01 Abstract: Perché i corsi generali non lasciano traccia, le cinque popolazioni da formare, cosa chiede l'articolo 4 dell'AI Act e le evidenze che servono in audit. **In sintesi.** La formazione sull'intelligenza artificiale in azienda fallisce quasi sempre per la stessa ragione: viene comprata come corso generale e consegnata a tutti nello stesso formato, quando serve l'opposto, cioè contenuti diversi per popolazioni diverse e un'evidenza di chi ha ricevuto cosa. L'articolo 4 dell'AI Act rende questa impostazione obbligatoria dal 2 febbraio 2025, e il modo in cui un piano viene costruito decide se regge o meno davanti a una verifica. Il problema non è la disponibilità di contenuti, che abbondano. È la distanza tra quello che un corso generale racconta e quello che una persona deve sapere per usare bene lo strumento che ha sul proprio schermo. ## Perché i corsi generali non lasciano traccia Un corso su cosa sia l'intelligenza artificiale produce consapevolezza e si dimentica in poche settimane, perché nessuno lo applica il giorno dopo. Un modulo di dieci minuti che spiega quando non fidarsi del suggerimento di uno strumento specifico cambia comportamento, perché arriva nel momento in cui serve. C'è anche un problema di evidenza. Un webinar con duecento partecipanti e nessuna registrazione individuale non dimostra nulla, e in una verifica l'organizzazione si trova a dichiarare di aver formato senza poter mostrare chi, su cosa e quando. La terza ragione riguarda il tempo. Un piano che richiede giornate intere di aula viene rimandato, mentre un piano costruito su interventi brevi inseriti in percorsi già esistenti viene erogato davvero. ## Le popolazioni da formare | Popolazione | Cosa deve sapere | Durata e cadenza | |---|---|---| | Direzione e consiglio | Cosa si approva quando si autorizza un sistema, quali rischi restano in capo all'azienda | Mezza giornata, annuale | | Funzioni che configurano sistemi | Parametri, limiti, classificazione del sistema che gestiscono | Mezza giornata all'ingresso, aggiornamento annuale | | Chi usa gli strumenti ogni giorno | Cosa fa lo strumento, quando non fidarsi, a chi segnalare | 10-20 minuti per strumento, all'ingresso | | Funzioni di controllo | Come si verifica un sistema, quali evidenze chiedere | Una giornata, annuale | | Rete esterna e collaboratori | Le stesse istruzioni d'uso del personale interno | 10 minuti, in fase di abilitazione | L'ultima riga è quella dimenticata più spesso, e in molti settori è anche la più numerosa. Agenti, affiliati, consulenti e fornitori che usano strumenti forniti dall'azienda rientrano nel perimetro, e lo strumento per coprirli è il contratto. ## Cosa chiede l'articolo 4 dell'AI Act L'obbligo riguarda sia i fornitori sia gli utilizzatori di sistemi AI, e chiede di assicurare un livello sufficiente di alfabetizzazione del personale e di chiunque usi i sistemi per conto dell'organizzazione, tenendo conto delle conoscenze, dell'esperienza e del contesto d'uso. Due parole contano più delle altre. Sufficiente significa proporzionato al ruolo, quindi un piano identico per tutti è sbagliato per eccesso su alcuni e per difetto su altri. Per conto significa che il perimetro si estende oltre i dipendenti. L'obbligo è in vigore dal 2 febbraio 2025 e non è stato toccato dagli spostamenti di calendario introdotti dal Digital Omnibus, che riguardano i sistemi ad alto rischio. ## Durata, formato, cadenza Il formato che funziona è breve e ancorato allo strumento. Dieci minuti su un assistente che il reparto usa davvero valgono più di tre ore su scenari generali, e permettono di ripetere l'intervento quando lo strumento cambia. L'innesco migliore è l'ingresso della persona o l'abilitazione all'uso di un sistema, perché è il momento in cui l'informazione viene cercata. Nei settori con ricambio alto questo è l'unico meccanismo che tiene il piano allineato alla popolazione reale. La revisione annuale resta utile per chi rimane e per aggiornare i contenuti quando i sistemi cambiano, ma non può essere l'unico momento di erogazione. ## Come si misura se è servita Il numero di partecipanti dice poco. Le misure utili sono tre: quanti usano lo strumento dopo la formazione, quante segnalazioni di anomalia arrivano da chi lo usa, quante volte l'output viene corretto prima di essere usato. La seconda misura è controintuitiva e vale la pena spiegarla. Un aumento delle segnalazioni dopo la formazione è un buon segno, perché significa che le persone hanno capito quando qualcosa non torna. Un silenzio totale dopo un corso significa quasi sempre che il corso non ha inciso. ## L'evidenza che serve in audit Serve un registro individuale che leghi persona, contenuto, data e sistema di riferimento. Serve la matrice che associa ruoli e competenze richieste, perché è il documento che spiega perché quella persona ha ricevuto quel contenuto. Serve la tracciabilità degli aggiornamenti, quando un sistema cambia e la formazione viene rifatta. Senza questi tre elementi un piano formativo esiste nella pratica e non nei documenti, che è la condizione in cui si trovano molte organizzazioni al momento della verifica. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), perché il contenuto della formazione dipende da quali strumenti sono realmente in uso. Da lì si costruisce [la matrice ruoli-competenze](/blog/compliance/matrice-ruoli-competenze-ai), e i requisiti formali sono descritti in [la clausola 7 della ISO 42001](/blog/compliance/clausola-7-iso-42001-competenze) e in [AI literacy e competenze](/blog/compliance/ai-literacy-competenze-iso-42001). Gli errori che fanno bocciare un piano sono raccolti in [errori del piano di formazione](/blog/compliance/errori-piano-formazione-audit-ai). L'approccio ai percorsi per ruolo è nella pagina [AI Training](/servizi/ai-training). Per valutare il piano della tua organizzazione puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # La documentazione minima di un AIMS: cosa chiede davvero ISO/IEC 42001 URL: https://zerofive.ai/blog/compliance/documentazione-minima-aims-iso-42001 Data: 2026-09-01 Abstract: I documenti minimi richiesti da ISO/IEC 42001 per un AI Management System: cosa serve davvero, cosa no, e in che ordine costruirli. Nelle valutazioni di maturità AI che facciamo, la scena si ripete quasi sempre uguale: una cartella condivisa piena di PDF, una policy scritta un anno fa e mai più aperta, qualche slide di presentazione spacciata per procedura. L'azienda pensa di avere già la documentazione per un sistema di gestione dell'intelligenza artificiale. Ne ha, in realtà, solo i frammenti sparsi. ## Il malinteso di partenza Il primo equivoco su [ISO/IEC 42001](/blog/compliance/iso-42001-ai-management-system) riguarda cosa un audit va davvero a cercare: la quantità di pagine prodotte pesa meno di quanto si creda, quello che un auditor verifica è se quei documenti vengono usati per decidere. Un registro dei rischi aggiornato l'ultima volta prima del lancio del progetto non serve a nessuno, tantomeno a chi chiede di vedere l'ultima revisione e la relativa data. La documentazione, in un AI Management System, funziona più come infrastruttura decisionale che come prova di conformità: permette a un'organizzazione di scegliere con basi solide, e di rendere conto di una decisione quando qualcuno la mette in discussione, perché quel modello è stato scelto, chi ha valutato il rischio, cosa succede se il sistema smette di comportarsi come previsto. ## I documenti che la norma chiede davvero Tolto il rumore, il nucleo minimo si riduce a poche famiglie di documenti, collegate tra loro più che elencate una per una. - **Policy AI e obiettivi**, il punto di partenza che fissa cosa l'organizzazione intende per uso responsabile dell'AI e con quali obiettivi misurabili - **Ruoli e responsabilità**, chi possiede ogni sistema AI, chi ne risponde, chi approva le eccezioni - **Valutazione e trattamento del rischio**, la procedura con cui ogni sistema viene classificato prima di entrare in produzione - **Registro dei rischi AI**, vivo, non un documento chiuso alla firma del progetto - **Inventario dei sistemi AI**, l'elenco aggiornato di cosa l'organizzazione usa, sviluppa o acquista, con lo stato nel ciclo di vita - **Procedure operative**, come si monitora un sistema in produzione, come si gestisce un incidente, come si aggiorna un modello - **Piano di formazione**, terreno che merita un pezzo a sé, perché la competenza delle persone è essa stessa un requisito verificabile in audit - **Verbali di riesame di direzione**, la prova che il sistema viene rivisto periodicamente da chi ha potere di decidere, non solo mantenuto da chi lo ha scritto Otto famiglie di documenti, collegate tra loro, non ottanta file sparsi in una cartella condivisa. ## Il trattato che non serve Molte aziende partono convinte di dover scrivere un trattato, e si bloccano prima di iniziare. Serve un sistema proporzionato alla scala e al rischio reale dei sistemi AI in uso, non un manuale enciclopedico pensato per una multinazionale con cento use case in produzione quando gli use case reali sono tre. Chi ha già un sistema di gestione certificato, ISO 27001 sulla sicurezza delle informazioni o ISO 9001 sulla qualità, parte in vantaggio. La struttura armonizzata che ISO/IEC 42001 condivide con questi standard permette di riusare l'analisi del contesto, la gestione documentale, il riesame di direzione, senza duplicare da zero. Il registro dei rischi può diventare un'estensione di quello già esistente, non un sistema parallelo che nessuno guarda più dopo il primo mese. ## L'ordine conta più del contenuto L'errore più comune riguarda la sequenza più che la tecnica: si scrivono procedure prima di aver definito il contesto e gli obiettivi, oppure si costruisce l'inventario dei sistemi AI quando sono già in produzione da mesi, documentando a posteriori quello che si sarebbe dovuto decidere prima di cominciare. Un AIMS assemblato così somiglia a una giustificazione scritta dopo i fatti, e un audit lo smonta con poche domande mirate. L'ordine corretto parte dal contesto, chi sono le parti interessate e cosa si aspettano da come l'organizzazione usa l'AI, per poi passare alla policy, alla valutazione dei rischi, all'inventario e infine ai controlli operativi. Ogni passaggio si appoggia al precedente. Saltarne uno per arrivare prima al certificato produce un sistema fragile, che tiene sulla carta e cede alla prima verifica sul campo. ## Prima di cominciare Chi si trova a mettere ordine da questo punto di partenza fa bene a fermarsi prima di scrivere il primo documento, e a chiedersi cosa l'organizzazione sa già di sé: quanti sistemi AI ha davvero, con quale rischio, con quale maturità. È lo stesso terreno che copriamo con l'AI Assessment, mappare prima di formalizzare, perché un documento scritto senza quella mappa resta carta con una data sopra, non un sistema di gestione ai sensi della ISO/IEC 42001. La domanda su cui torneremo nel prossimo pezzo di questa serie riguarda l'inventario dei sistemi AI: come si costruisce, cosa deve contenere davvero, e perché quasi nessuna azienda ce l'ha aggiornato quando dice di averlo. --- # Da dove ripartire con l'AI a settembre 2026 URL: https://zerofive.ai/blog/strategia/da-dove-ripartire-ai-settembre-2026 Data: 2026-08-31 Abstract: Digital Omnibus stabilizzato, decreto 231 in arrivo. Le tre domande da farsi prima del budget AI di fine anno, e perché misurare viene prima di stanziare. A settembre i board italiani tornano a riunirsi con lo stesso rito ogni anno: si guarda cosa è stato speso nei primi otto mesi, si discute cosa resta del budget, si fissano le priorità degli ultimi quattro. Per l'AI, quest'anno, quel rito arriva in un momento particolare. Il calendario normativo del 2026 ha appena smesso di muoversi, dopo mesi di rinvii e correzioni, e per la prima volta da tempo le aziende hanno davanti una finestra abbastanza stabile da poter pianificare sul serio, invece di rincorrere l'ultima modifica. Vale la pena essere precisi su cosa è fermo e cosa no, perché nelle conversazioni di questi giorni circola più di una semplificazione. Dal 2 agosto sono vincolanti gli obblighi di trasparenza dell'articolo 50 dell'AI Act, le sanzioni sono applicabili, e la vigilanza nazionale è affidata ad ACN e AgID in base alla legge 132/2025. Gli obblighi per i sistemi ad alto rischio dell'Allegato III, invece, sono stati spostati dal Digital Omnibus al 2 dicembre 2027, e quelli per i sistemi integrati nei prodotti dell'Allegato I all'agosto 2028. I nuovi divieti su immagini intime non consensuali e materiale di abuso su minori generati da AI entrano in vigore il 2 dicembre 2026. In Italia, a completare il quadro, c'è il decreto approvato in via definitiva il 4 agosto che inserisce l'intelligenza artificiale tra i reati presupposto del d.lgs. 231/2001, ancora in attesa di pubblicazione in Gazzetta Ufficiale. ## Sedici mesi non sono una scusa per aspettare La tentazione, davanti a scadenze spostate al 2027, è leggerle come tempo guadagnato da non usare subito. È l'errore opposto a quello giusto. Sedici mesi sono esattamente il tempo che serve per costruire con calma quello che, fatto sotto pressione a ridosso di una scadenza, viene sempre fatto peggio e costa sempre di più: un registro dei sistemi AI in uso, un processo di valutazione del rischio per ogni nuovo caso d'uso, una governance che non dipenda dalla memoria di una persona ma da un metodo scritto e ripetibile. Le aziende che a dicembre 2027 si troveranno pronte non saranno quelle che hanno aspettato novembre 2027 per iniziare. Saranno quelle che a settembre 2026 hanno usato il tempo residuo dell'anno per misurare da dove partono davvero, prima di decidere dove investire nel 2027. ## Misurare prima di stanziare, non dopo È qui che si incrocia quello che abbiamo scritto nelle ultime settimane su costi e adozione: le aziende che superano il budget AI lo fanno quasi sempre perché hanno scalato un progetto senza aver verificato prima se l'organizzazione poteva sostenerlo, e il 71% che ha iniziato senza arrivare a una governance strutturata condivide la stessa causa, l'assenza di una fotografia iniziale onesta. Il nostro AI Rating nasce per rispondere proprio a questo, prima di qualunque decisione di budget o di roadmap. Misura la maturità su quattro dimensioni, readiness, cioè quanto l'organizzazione è pronta in termini di dati, competenze e strategia, delivery, cioè quanto i processi tecnici reggono la produzione e non solo il prototipo, risk, cioè quanto la governance copre compliance ed etica, confidence, cioè quanto board e utenti si fidano davvero di quello che è stato costruito. Il risultato è un punteggio da zero a cinque e una classe da A a D, con gate critici non compensabili: un'eccellenza in tre aree su quattro non basta a coprire una carenza grave nella quarta. ## Tre domande prima di chiudere il budget di settembre Prima di stanziare il budget AI per l'ultimo trimestre, tre domande separano chi decide con evidenze da chi decide per abitudine. Quali sistemi AI sono già in uso in azienda, mappati con responsabile e livello di rischio, e non solo quelli approvati ufficialmente. Quale caso d'uso, tra quelli in corso o proposti, ha un criterio di successo scritto prima di partire, non stimato a consuntivo quando ormai è tardi per fermarsi. E se un revisore o un board chiedesse oggi conto della governance AI dell'azienda, la risposta arriverebbe da un documento verificabile o da una sensazione condivisa in riunione. Chi risponde con sicurezza a tutte e tre probabilmente ha già fatto il lavoro che descriviamo in questo articolo, ed è pronto a discutere di scala, non di fondamenta. Chi esita anche solo su una ha appena trovato il punto da cui ripartire a settembre, prima ancora di guardare il resto del budget. ## Il vantaggio di chi misura prima degli altri Un rating strutturato produce anche una roadmap a novanta giorni, con priorità ordinate per impatto e rischio, non un elenco generico di raccomandazioni. È lo strumento che permette a un board di arrivare a dicembre con un piano concreto per il 2027, invece che con la sensazione di aver rincorso l'anno precedente un mese alla volta. Le organizzazioni che a settembre scelgono di misurare prima di investire arrivano all'anno nuovo con un vantaggio che non si vede subito ma pesa parecchio nel tempo: sanno dove stanno mettendo i soldi, e sanno perché. --- # Il 71% parte, il 9% arriva: cosa succede in mezzo URL: https://zerofive.ai/blog/ai-governance/adozione-ai-tra-71-e-9-per-cento Data: 2026-08-28 Abstract: Il 71% delle grandi imprese ha progetti AI attivi, solo il 9% ha governance strutturata. Shadow AI, gate di rischio e cosa distingue chi chiude il divario. Il 71% delle grandi imprese italiane ha progetti AI attivi, solo il 9% ha raggiunto una governance strutturata (Osservatorio Artificial Intelligence, Politecnico di Milano, febbraio 2026). Il divario tra i due numeri non descrive aziende in ritardo. Descrive aziende che hanno iniziato, in tanti casi anche bene, e che si sono fermate in un punto intermedio dove l'AI produce attività senza produrre ancora un sistema. L'ISTAT racconta la stessa distanza da un'altra angolazione: nel 2024 l'8,2% delle imprese italiane aveva adottato tecnologie di intelligenza artificiale, contro una media europea del 13,5%. Non è un problema di curiosità o di budget disponibile, l'Italia investe, sperimenta, avvia pilot in ogni settore. È un problema di cosa succede dopo il primo progetto, quando l'entusiasmo dell'avvio incontra la mancanza di un metodo per governare quello che viene dopo. ## L'AI dei dipendenti arriva prima delle policy che dovrebbero coprirla Un'analisi pubblicata a maggio descrive un fenomeno che nei nostri assessment vediamo con regolarità impressionante: gli strumenti AI usati ogni giorno dai dipendenti corrono più veloci delle policy pensate per governarli. Chi lavora cerca un modo più rapido per scrivere un report, riassumere un contratto, preparare una presentazione, e trova quel modo in un tool che l'azienda non ha mai valutato, spesso senza nemmeno saperlo. Il caso più citato resta quello di Samsung nel 2023: dipendenti che, per velocizzare il proprio lavoro, avevano caricato codice sorgente proprietario in un chatbot pubblico, senza alcuna intenzione di causare un danno, semplicemente perché quello strumento funzionava e nessuno aveva detto di no. Tre anni dopo lo scenario si è moltiplicato, non ridotto: più strumenti disponibili, più dipendenti abituati a usarli fuori dal perimetro aziendale, e una distanza tra adozione informale e governance formale che in molte organizzazioni resta identica a prima. ## Il 71% misura l'iniziativa, il 9% misura il controllo I due numeri dell'Osservatorio non sono in contraddizione, misurano cose diverse. Il 71% conta chi ha avviato qualcosa, un pilot, un progetto pilota in un reparto, un accordo con un vendor. Il 9% conta chi sa, con evidenze verificabili e non con la sensazione di averlo fatto, dove quei sistemi sono in uso, chi ne è responsabile, quali rischi comportano e con quale frequenza vengono controllati. Nel nostro AI Rating questa distanza corrisponde quasi sempre a un pattern preciso: punteggi alti su Readiness e Confidence, perché l'azienda ha voglia di innovare e il management ci crede, e un punteggio basso su Risk, la dimensione che misura compliance, gestione del rischio, presenza di un registro dei sistemi AI in uso. È un gate critico, non compensabile, un'eccellenza tecnica altrove non lo pareggia. Un'azienda che innova con entusiasmo ma non sa elencare i propri sistemi AI resta bloccata in classe C, indipendentemente da quanto sia avanti sulla carta. ## Cosa distingue chi chiude il divario Le organizzazioni che passano dal 71% al 9%, cioè che trasformano l'iniziativa sparsa in governance reale, hanno in comune un passaggio preciso: smettono di trattare ogni progetto AI come un caso a sé e costruiscono un registro unico, un punto dove ogni sistema in uso viene mappato con lo stesso livello di dettaglio, chi lo ha attivato, con quali dati lavora, quale livello di rischio comporta secondo la classificazione dell'AI Act, chi risponde se qualcosa va storto. Questo passaggio non richiede necessariamente più budget. Richiede una decisione organizzativa, spesso presa a livello di board, che l'AI smette di essere gestita reparto per reparto e diventa un capitolo unico della governance aziendale, con un responsabile identificato e un processo di revisione periodico. Le aziende che lo fanno prima, lo fanno perché hanno misurato la propria situazione reale invece di darla per scontata, e la misurazione, quasi sempre, è il primo passo che manca. ## Il rischio di restare nel mezzo Restare nel gruppo del 71% senza muoversi verso il 9% non è una posizione neutra, è un rischio che cresce nel tempo. Ogni mese che passa senza un registro dei sistemi AI aumenta il numero di strumenti in uso non mappati, e con il decreto che inserisce l'intelligenza artificiale tra i reati presupposto del d.lgs. 231/2001 in dirittura d'arrivo, la distanza tra adozione informale e modello organizzativo adeguato smette di essere un tema di efficienza e diventa un tema di esposizione legale per l'ente. La domanda che vale la pena porsi prima che il divario si allarghi ulteriormente è semplice da formulare e scomoda da rispondere con onestà: se un revisore, un board o un giudice chiedesse oggi l'elenco completo dei sistemi AI in uso in azienda, con relativo livello di rischio e responsabile, quella lista esisterebbe già, oppure andrebbe costruita da zero in fretta e furia. --- # Perché il budget AI salta (e non è colpa dei token) URL: https://zerofive.ai/blog/strategia/costo-ai-budget-non-previsto Data: 2026-08-27 Abstract: Billing a consumo, headcount tagliato per finanziare i token, PoC scalate senza misurare. Perché i costi AI sfuggono al budget e come prevederli con l'AI Rating. A metà luglio un report di Forrester, ripreso da The Register, ha messo per iscritto quello che in diverse aziende italiane si sospettava già: il prossimo anno le bollette del software cresceranno, e a spingerle sarà soprattutto l'AI. Anthropic, OpenAI e GitHub sono già passati al billing a consumo, Microsoft ha lanciato una licenza premium, e il messaggio implicito ai clienti enterprise è identico ovunque, l'infrastruttura che fa girare i modelli costa, e quel costo va fatto atterrare da qualche parte. Il report però aggiunge una frase quasi di passaggio, che vale più del resto: il successo di un investimento AI dipende da quanto un'azienda ha costruito le fondamenta giuste, più che da quanto ha speso in AI in senso stretto. Le fondamenta giuste sono, in un'azienda che non ha mai misurato la propria maturità, la prima cosa che manca. ## La bolletta a consumo cambia chi controlla il budget Finché l'AI si comprava a licenza, il costo era prevedibile: un numero all'anno, negoziato una volta, rivisto al rinnovo. Il billing a consumo funziona diversamente. Cresce con l'uso, con la lunghezza dei contesti, con il numero di chiamate che un processo genera senza che nessuno le conti una per una. Un agente che gira ventiquattro ore su ventiquattro, che richiama un modello a ogni step di un flusso, che ripete una ricerca perché il primo tentativo non ha trovato la risposta giusta, produce una curva di spesa che il CFO vede solo a fattura arrivata. Non è un problema tecnico da lasciare all'IT. È un problema di governance del consumo, che richiede soglie, alert e responsabilità chiare su chi autorizza cosa, esattamente come un'azienda tratta qualsiasi altra voce di costo variabile. Le tecniche esistono e sono documentate bene, dal caching dei prompt al dimensionamento corretto del modello per ogni task, fino al retrieval mirato che evita di ricaricare contesto inutile a ogni chiamata. Restano tecniche di ottimizzazione, non di decisione: dicono come spendere meno per un uso già scelto, non se quell'uso avesse senso fin dall'inizio. ## Il baratto tra persone e token che non sta rendendo Un secondo filone di notizie, uscite nelle stesse settimane, racconta un'altra faccia dello stesso problema. Diverse aziende, tra cui nomi noti come Klarna, Uber e Walmart, hanno spostato budget dal personale ai token, tagliando ruoli per finanziare l'adozione di AI. I primi dati che arrivano da quelle scelte, però, non mostrano il ritorno atteso: soddisfazione dei clienti in calo in alcuni casi, processi che richiedono comunque supervisione umana, risparmi sulla carta che si consumano in correzioni e rilavorazioni. Il problema non è l'AI in sé, è la sequenza. Tagliare prima e misurare dopo inverte l'ordine che rende un investimento difendibile. Il nostro AI Rating misura la maturità su quattro dimensioni, Readiness, Delivery, Risk, Confidence, proprio perché un'azienda può avere un caso d'uso tecnicamente valido e comunque perdere soldi, se manca la capacità organizzativa di gestirlo a regime. Un modello che funziona bene in laboratorio e male in produzione racconta quasi sempre una valutazione saltata prima di scalare, più che un limite della tecnologia. ## Dove il costo nasce davvero Nei nostri assessment la domanda "quanto costa l'AI" arriva quasi sempre troppo tardi, quando il progetto è già stato deciso e il costo da giustificare è quello sostenuto, non quello evitabile. La domanda che fa risparmiare arriva prima: questo caso d'uso, con questi dati, in questa organizzazione, dove genererà valore e dove genererà solo consumo? Un esempio ricorrente: un'azienda automatizza un processo di assistenza clienti con un agente conversazionale, misura una riduzione dei tempi di prima risposta e la presenta come successo. Sei mesi dopo, i costi operativi sono raddoppiati per via delle chiamate ripetute su casi ambigui che l'agente non sa chiudere da solo, e il personale che doveva essere liberato viene invece riassegnato a controllare le risposte prima che arrivino al cliente. Il costo non è comparso all'improvviso. Era prevedibile fin dal primo mese, se qualcuno avesse misurato il tasso di escalation prima di scalare il progetto su tutti i canali. ## Cosa cambia se si misura prima Le aziende che arrivano da noi già con una AI Rating in classe B o superiore affrontano queste conversazioni in modo diverso. Sanno quali processi hanno dati abbastanza puliti da sostenere un agente in autonomia, quali richiedono ancora supervisione, quali gate di rischio bloccano la scalabilità a prescindere da quanto il caso d'uso sembri promettente. Il costo, a quel punto, si discute per componenti separate: costo di sviluppo, costo di esercizio, costo di governance, e ciascuno viene stimato prima, non ricostruito dopo dalla fattura. Vale anche il contrario. Un'azienda in classe D o C che investe comunque in scala rischia di pagare due volte, la prima per il progetto che non regge, la seconda per rifarlo bene una volta capito cosa non aveva funzionato. È il pattern che vediamo più spesso nei progetti che finiscono da noi dopo essere partiti altrove: non mancava il budget, mancava la sequenza. Con i budget del 2027 in discussione nei prossimi mesi, la domanda utile non è quanto stanziare per l'AI. È se l'organizzazione sa già, con evidenze e non con impressioni, dove quel budget produrrà valore misurabile e dove produrrà solo una bolletta più alta a dicembre. --- # AI Rating in manifattura: automazione alta, dati inutilizzabili URL: https://zerofive.ai/blog/strategia/ai-rating-manifattura-dati-e-prodotto Data: 2026-08-26 Abstract: Sensori ovunque e dati inservibili. Il gate della separazione stabilimento e prodotto e perché il 2028 condiziona già le progettazioni di oggi. **In sintesi.** In manifattura il profilo di maturità AI ha una debolezza che sorprende le aziende tecnologicamente avanzate: Readiness bassa per la qualità dei dati, non per l'infrastruttura. Uno stabilimento pieno di sensori può avere dati inutilizzabili, perché raccolti per il controllo e non per l'analisi. Il gate ricorrente è però un altro, e riguarda la mancata separazione tra sistemi di stabilimento e sistemi destinati ai prodotti. Le aziende manifatturiere arrivano al rating con l'aspettativa di un risultato alto sulla dimensione tecnica, perché investono in automazione da anni. Il risultato le sorprende, e la ragione è che il modello misura la governabilità dei sistemi AI, non il livello di automazione. ## Le quattro dimensioni in manifattura **Readiness** misura preparazione, dati, competenze, infrastrutture. È la dimensione con lo scarto più grande tra percezione e realtà. I dati esistono in quantità enorme, e sono spesso inutilizzabili per l'AI perché raccolti con logiche di controllo di processo, con granularità e storicizzazione inadeguate. **Delivery** misura la capacità di portare in produzione e mantenere. In fabbrica è limitata dal fatto che i sistemi arrivano dentro macchine, e il ciclo di vita del software segue quello del macchinario, che è di anni. **Risk** misura governance, compliance ed etica. È scoperta su due fronti diversi: i sistemi che misurano le persone, quasi mai classificati, e i sistemi destinati ai prodotti, dove la scadenza lontana ha prodotto rinvio. **Confidence** misura commitment della direzione e fiducia degli utenti. In manifattura è spesso alta in direzione e bassa in reparto, e lo scarto conta, perché un sistema che gli operatori non si fidano di usare viene aggirato. ## Il gate: stabilimento e prodotto mescolati Il vincolo ricorrente è la mancanza di una separazione formale tra i sistemi che restano dentro l'azienda e quelli che finiscono nei prodotti venduti. Finché quella separazione non esiste, l'inventario non permette di determinare il ruolo, e senza il ruolo non si possono assegnare gli obblighi. Un'azienda può avere una governance ordinata sui sistemi di stabilimento e nessuna consapevolezza di essere già, su una linea di prodotto, un fornitore ai sensi del regolamento. Il rilievo non riguarda la mancanza di controlli. Riguarda l'impossibilità di sapere quali controlli servono, che è un problema diverso e precedente. ## Quando i dati sembrano esserci e non bastano Nelle valutazioni manifatturiere la dimensione Readiness cade su un punto specifico. Un'azienda dichiara di avere dieci anni di storico di manutenzione, e alla verifica emerge che le causali di guasto sono campi liberi compilati in modo diverso da turno a turno, oppure che i dati di processo sono conservati in forma aggregata perché il sistema di controllo non li storicizzava. Il problema riguarda la struttura più che il volume, e non si risolve con la tecnologia. Va affrontato prima, perché condiziona qualunque progetto successivo. ## Cosa significa una classe, in pratica | Classe | Situazione tipica in manifattura | Cosa è ragionevole fare | |---|---|---| | D | Sistemi AI dentro macchine, nessuna mappatura, dati non strutturati | Mappare i sistemi e verificare la qualità dello storico | | C | Inventario presente, nessuna separazione prodotto e stabilimento | Separare i due percorsi e assegnare i ruoli | | B | Separazione fatta, sistemi di stabilimento governati | Avviare il percorso di conformità sui prodotti con AI | | A | Sistema maturo verificato su tutte le dimensioni | Riservata alle valutazioni verificate, non alle autovalutazioni | Il salto da C a B è quello che le aziende manifatturiere rinviano più spesso, perché la scadenza dell'Allegato I è lontana. È anche quello che condiziona i prodotti già in progettazione oggi. ## Perché misurare prima di progettare il prossimo prodotto Il momento utile per una valutazione in manifattura non è l'inizio dell'esercizio, è l'avvio del ciclo di sviluppo di una nuova linea di prodotto. Un sistema AI integrato in un prodotto soggetto a normativa di armonizzazione richiede documentazione tecnica, gestione del rischio e valutazione di conformità, e tutto questo si progetta insieme al prodotto. Aggiungerlo dopo significa riaprire scelte architetturali già fatte, con costi che nessuno aveva previsto. Un'azienda che avvia oggi lo sviluppo di un prodotto destinato al 2028 sta già decidendo, senza saperlo, quanto costerà la conformità. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), costruito separando dal primo momento i sistemi di stabilimento da quelli destinati ai prodotti. Il modello completo, con le quattro dimensioni e la logica dei gate, è nella pagina [AI Rating](/servizi/ai-rating). Il quadro normativo del settore è nella pagina [AI governance per la manifattura](/settori/industria). Per una valutazione della posizione della tua azienda puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # AI, normative e certificazioni: 11 articoli su ISO/IEC 42001 URL: https://zerofive.ai/blog/approfondimenti/piano-editoriale-settembre-iso-42001 Data: 2026-08-25 Abstract: Dal 27 agosto al 30 settembre, due articoli su costi e adozione, poi la serie completa su ISO/IEC 42001. Calendario e iscrizione alla newsletter. Nei prossimi giorni pubblichiamo tre articoli su costi, adozione, e su dove ripartire con l'AI a settembre. Il filo che li lega porta dritto a una domanda molto pratica, che ci sentiamo fare in quasi ogni assessment: una volta deciso di colmare il divario tra iniziativa e governance, con cosa lo si fa, concretamente, il lunedì mattina. La risposta che diamo più spesso è ISO/IEC 42001, lo standard internazionale per i sistemi di gestione dell'intelligenza artificiale. Non è un documento da leggere una volta e archiviare in un cassetto, è un metodo operativo, con clausole precise su documentazione, competenze, valutazione del rischio, audit. Da martedì 1 settembre pubblichiamo undici articoli che lo attraversano un pezzo alla volta, dal primo documento da scrivere fino alla certificazione. ## La sequenza non è casuale Il primo blocco riguarda le fondamenta: quali documenti chiede davvero un sistema di gestione dell'AI, come si costruisce un inventario dei sistemi in uso, come si fa un impact assessment che tenga insieme DPIA e AI Act senza duplicare il lavoro due volte, cosa preparare prima di scrivere una riga di codice se l'obiettivo è un sistema ISO-ready fin dal disegno. Il secondo blocco si sposta sulle persone. La clausola 7 sulle competenze spiegata senza il gergo dello standard, una matrice che dice chi va formato e su cosa, dove finisce l'AI literacy richiesta dall'AI Act e dove inizia la competenza chiesta da ISO 42001, gli errori che fanno bocciare un piano di formazione in sede di audit, perché il corso obbligatorio da solo non basta. Il terzo blocco chiude sulla certificazione: la mappa degli organismi accreditati Accredia in Italia, e la differenza reale tra diventare Lead Implementer, Lead Auditor, o portare l'intera organizzazione alla certificazione. ## Perché adesso Il calendario normativo si è appena stabilizzato, ne abbiamo scritto la settimana scorsa, e i board stanno chiudendo il budget dell'ultimo trimestre. È il momento in cui la domanda passa da se investire in governance AI a con quale metodo farlo, e ISO 42001 resta il riferimento più concreto che esiste oggi per rispondere: a differenza dell'AI Act non si limita a descrivere cosa evitare, descrive cosa costruire. ## Il calendario completo Un articolo ogni due o tre giorni, fino al 30 settembre. Ogni pezzo è pensato per stare in piedi da solo: utile anche se leggete solo quello che vi serve in questo momento. | Data | Articolo | |---|---| | 27 agosto | Perché il budget AI salta (e non è colpa dei token) | | 28 agosto | Il 71% parte, il 9% arriva: cosa succede in mezzo | | 31 agosto | Da dove ripartire con l'AI a settembre 2026 | | 1 settembre | La documentazione minima di un AIMS | | 3 settembre | Impact assessment: DPIA, AI Act e ISO/IEC 42001 a confronto | | 8 settembre | L'inventario dei sistemi AI | | 10 settembre | Progettare un sistema AI ISO-ready | | 15 settembre | La clausola 7 di ISO/IEC 42001 spiegata senza gergo | | 17 settembre | Chi deve essere formato e su cosa: la matrice ruoli-competenze | | 18 settembre | AI literacy e competenze ISO 42001 | | 22 settembre | Gli errori che fanno bocciare un piano di formazione AI in audit | | 23 settembre | Il corso AI obbligatorio non basta | | 24 settembre | Certificazione ISO/IEC 42001 in Italia: la mappa Accredia | | 29 settembre | Lead Implementer vs Lead Auditor vs certificazione aziendale | Se preferite non tornare a controllare il blog ogni due giorni, potete iscrivervi alla newsletter. --- **Non perdere le prossime uscite.** [Iscriviti alla newsletter ZeroFive](https://zerofive.ai/papers): un'email a ogni articolo pubblicato, niente altro nel mezzo. --- # Quanto costa una consulenza AI, e perché le proposte sono così diverse URL: https://zerofive.ai/blog/strategia/quanto-costa-consulenza-ai Data: 2026-08-25 Abstract: Le quattro variabili che determinano il prezzo, come è composto il conto, dove si gonfia senza valore e le quattro domande per confrontare due offerte. **In sintesi.** Le proposte di consulenza AI arrivano con prezzi che variano di cinque volte a parità di titolo, e la ragione quasi mai sta nella bravura di chi la firma. Dipende da cosa viene incluso: una valutazione su documenti costa poco e vale poco, un lavoro che entra nei processi, parla con le funzioni e produce documenti verificabili richiede giornate che qualcuno deve pagare. Confrontare il prezzo senza confrontare il perimetro porta a scegliere l'offerta che consegna meno. Chi chiede un preventivo si aspetta un numero. La risposta onesta è che il numero dipende da quattro variabili, e che conoscerle permette di leggere qualunque proposta in dieci minuti. ## Cosa determina il prezzo | Variabile | Effetto sul costo | |---|---| | Ampiezza del perimetro | Una funzione sola costa una frazione di un intervento su tutta l'azienda | | Numero di persone da intervistare | Ogni funzione coinvolta aggiunge interviste, verifiche e riconciliazioni | | Profondità delle evidenze | Raccogliere documenti e verificarli costa più che raccogliere opinioni | | Presenza di sistemi già in produzione | Censire e classificare l'esistente richiede più lavoro che progettare da zero | La variabile che pesa di più è la terza. Una valutazione basata su un questionario compilato dai responsabili si chiude in pochi giorni e produce un punteggio che riflette la percezione interna. Una valutazione basata su evidenze richiede di guardare contratti, log, documentazione dei fornitori e configurazioni, e quel lavoro non si comprime senza perdere il senso dell'esercizio. ## Le voci che compongono il conto Il tempo delle persone è quasi tutto il costo, quindi la domanda utile riguarda come viene speso. In un intervento costruito bene la ripartizione assomiglia a questa: un terzo per raccogliere e verificare, un terzo per analizzare e decidere con il cliente, un terzo per scrivere documenti che restano utilizzabili. Quando la terza parte scende sotto il venti per cento il progetto consegna presentazioni, e quando la prima scende troppo l'analisi si appoggia a quello che il cliente già credeva di sapere. Entrambe le deformazioni abbassano il prezzo e tolgono valore. C'è poi una voce che compare raramente nelle proposte e che vale la pena chiedere: il tempo delle vostre persone. Un assessment serio richiede dalle quattro alle dieci ore per ciascuna funzione coinvolta, e quelle ore vanno pianificate, perché un progetto che le trova in mezzo ad altre urgenze si allunga e costa di più su entrambi i lati. ## Dove il conto si gonfia senza aggiungere valore La causa più frequente è il perimetro non definito. Un incarico che parte come valutazione della maturità e durante il percorso assorbe la mappatura dei processi, la selezione di un fornitore e la stesura di una policy diventa tre progetti pagati come uno, con tempi che si dilatano e consegne che si assottigliano. La seconda causa è la moltiplicazione degli interlocutori senza una decisione chiara su chi approva. Ogni riunione aggiuntiva ha un costo, e un progetto con sei approvatori impiega il doppio del tempo di uno con due approvatori e quattro persone informate. La terza è la richiesta di materiale sempre più dettagliato su scenari che non verranno realizzati. Una stima di valore a tre cifre decimali su un caso d'uso che nessuno ha ancora deciso di finanziare è lavoro buttato. ## Come si tiene sotto controllo Serve un perimetro scritto, con l'elenco di cosa resta fuori, perché quella lista protegge entrambe le parti e rende possibile un confronto successivo sul prezzo di un'estensione. Serve un numero di consegne limitato e verificabile, meglio tre documenti usabili che otto allegati. Serve una data di fine, perché un progetto senza data tende a durare quanto la pazienza dello sponsor. Infine conviene separare la decisione dall'esecuzione. Un primo incarico breve che produce la fotografia e i criteri costa poco e permette di decidere con cognizione se finanziare il resto, invece di impegnare un budget grande su un'ipotesi non verificata. ## Il confronto che ha senso Due proposte si confrontano su quattro domande: quali documenti restano in azienda, chi li mantiene dopo la chiusura, quali decisioni saranno prese entro la fine del progetto, cosa succede se l'analisi mostra che la strada scelta non è quella giusta. Un'offerta che costa meno e non risponde a queste domande è più cara, perché il lavoro andrà rifatto. Un'offerta che costa di più e non le risponde è semplicemente da scartare. ## Da dove partire Il dettaglio di cosa deve consegnare un progetto, fase per fase, è in [consulenza AI per aziende](/blog/strategia/consulenza-ai-cosa-deve-consegnare), mentre la scelta tra esterno e interno è in [consulente AI, fornitore o team interno](/blog/strategia/consulente-ai-fornitore-o-team-interno). Sui costi di un progetto AI nel suo complesso, oltre la consulenza, ci sono [quanto costa davvero un progetto AI](/blog/strategia/quanto-costa-davvero-progetto-ai) e [il costo che nessuno mette a budget](/blog/strategia/costo-ai-budget-non-previsto). Per capire quale perimetro ha senso nel vostro caso puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # L'articolo 22 del GDPR e le decisioni automatizzate in azienda URL: https://zerofive.ai/blog/compliance/articolo-22-gdpr-decisioni-automatizzate-azienda Data: 2026-08-24 Abstract: La multa da 825 milioni a Uber spiega cosa chiede l'articolo 22. Come censire i flussi automatici e dove mettere il punto di fermata a monte. Il 21 agosto 2026 l'Autoriteit Persoonsgegevens, l'autorità olandese per la protezione dei dati, ha sanzionato Uber per 824.990.000 euro. È la seconda sanzione più alta mai comminata sotto il GDPR. La contestazione riguarda un sistema che disattivava gli account dei conducenti in modo interamente automatizzato, senza che una persona esaminasse il caso prima del blocco. La condotta contestata copre il periodo 2018-2022. Uber ha presentato ricorso, sostenendo che la maggior parte delle sospensioni sono brevi, che nessuna disattivazione permanente avviene senza revisione umana e che i conducenti possono fare appello. La difesa di Uber è la parte più utile del caso per chiunque stia valutando la propria esposizione. Esistevano una revisione umana e un canale di appello, e non sono bastati. ## Cosa contesta l'autorità La base giuridica è l'articolo 22 del GDPR, che vieta di sottoporre una persona a una decisione basata unicamente su un trattamento automatizzato quando quella decisione produce effetti giuridici o incide in modo analogo in misura significativa. A questa si aggiungono gli obblighi di informazione e trasparenza degli articoli 12-15, per non aver spiegato adeguatamente il funzionamento del processo decisionale. Monique Verdier, vicepresidente dell'autorità, ha sintetizzato il principio dicendo che un computer non dovrebbe prendere da solo decisioni con conseguenze rilevanti per una persona, e che quelle decisioni avrebbero dovuto essere esaminate prima da un essere umano. Le due parole che contano nella frase sono "da solo" e "prima". Non è in discussione se l'algoritmo funzioni bene. Non è in discussione se esista un rimedio successivo. Quello che l'autorità misura è se, nel momento in cui la decisione produce effetto, una persona con potere di fermarla sia stata coinvolta. ## Il perimetro reale del problema Il caso arriva dal ride hailing, e questo porta molte aziende ad archiviarlo come questione di piattaforme e lavoro digitale. È una lettura che costa cara, perché il pattern sanzionato è tra i più diffusi nei sistemi gestionali di aziende del tutto tradizionali. Alcuni esempi che incontriamo regolarmente nei nostri assessment: - **Sospensione automatica di un fornitore** dal portale acquisti al superamento di una soglia di scoring, di ritardo o di non conformità documentale - **Blocco automatico del credito** a un cliente al raggiungimento di un parametro di rischio calcolato dal sistema - **Scarto automatico di candidature** in fase di screening, con filtri o punteggi applicati prima di qualsiasi lettura umana - **Declassamento automatico** di un rivenditore o di un agente da una fascia commerciale a un'altra, con effetti su provvigioni e condizioni - **Revoca automatica di accessi o abilitazioni** a un collaboratore in base a metriche di utilizzo o a segnalazioni del sistema - **Rifiuto automatico di rimborsi o pratiche** in flussi assicurativi, sanitari, di garanzia In quasi tutti i casi che abbiamo visto, questi flussi non sono stati progettati come decisioni automatizzate. Sono nati come regole di efficienza dentro un ERP, un CRM o un portale, sono stati configurati anni fa da un fornitore che non c'è più, e nessuno li ha mai censiti come trattamento rilevante ai sensi dell'articolo 22. ## L'incastro con l'AI Act Dal 2 agosto 2026 la Commissione europea, attraverso l'AI Office e insieme alle autorità nazionali, ha avviato l'enforcement dell'AI Act ([cosa è davvero vincolante da quella data](/blog/compliance/ai-act-2-agosto-2026-cosa-e-vincolante)), e sono diventati applicabili gli obblighi di trasparenza dell'articolo 50, con sanzioni fino a 15 milioni di euro o al 3% del fatturato mondiale annuo. Diciannove giorni dopo, la prima sanzione europea di peso su una decisione algoritmica che incide sul lavoro non arriva dall'AI Act. Arriva dal GDPR. Questo dice due cose a chi deve allocare un budget di compliance nei prossimi sei mesi. La prima è che l'apparato con capacità operativa immediata è quello della protezione dei dati, che dispone di autorità strutturate, otto anni di prassi e una giurisprudenza consolidata. La seconda riguarda la sequenza. L'Allegato III dell'AI Act classifica come ad alto rischio i sistemi usati per l'assunzione, la selezione, la promozione, la cessazione dei rapporti e l'assegnazione dei compiti, ma i relativi obblighi non sono ancora applicabili: il Digital Omnibus li ha spostati al 2 dicembre 2027. Chi legge questo come una tregua sta leggendo male. L'articolo 22 copre già oggi buona parte di quello stesso perimetro, con un'autorità che sanziona e un massimale che il caso Uber ha appena mostrato. Un'azienda che censisce i propri flussi automatici adesso per il GDPR sta costruendo l'inventario che le servirà nel 2027 per l'AI Act, con diciassette mesi di margine invece che sotto scadenza. Fare due volte lo stesso lavoro, con due gruppi di lavoro diversi e due fornitori diversi, è l'errore di sequenza più costoso che vediamo in questo momento. ## L'inventario delle decisioni automatizzate Nel 05 Framework questa attività appartiene alla fase ASSESS, prima che qualsiasi use case venga selezionato. La ragione è di ordine pratico: un'azienda che non sa quali decisioni automatiche ha già in produzione non è in grado di valutare il rischio di quelle che sta per aggiungere. Il censimento parte da cinque domande, applicate a ogni flusso in cui un sistema produce un esito su una persona fisica. 1. **Quale esito produce il sistema, e su chi.** Un dipendente, un collaboratore, un candidato, un cliente persona fisica, un titolare di ditta individuale. Le persone giuridiche non rientrano nell'articolo 22, ma spesso il flusso colpisce entrambe e nessuno ha separato i due casi. 2. **L'esito ha effetti significativi.** Perdita di reddito, esclusione da un'opportunità, interruzione di un rapporto, limitazione di un accesso, peggioramento di condizioni economiche. 3. **Esiste un punto di fermata a monte.** Non un canale di reclamo, non una revisione successiva: una persona con l'autorità e il tempo materiale di bloccare l'esito prima che produca effetto. 4. **Quella persona ha gli elementi per decidere.** Un operatore che vede solo un punteggio e un pulsante di conferma non è un controllo umano, è una firma. L'autorità olandese ha valutato la sostanza del coinvolgimento, non la sua esistenza formale. 5. **La persona colpita sa che la decisione è automatizzata**, e le è stata fornita una spiegazione comprensibile della logica applicata. Chi risponde no alla terza o alla quarta domanda su un flusso che ha superato le prime due ha trovato un'esposizione, indipendentemente dal fatto che nel flusso ci sia o meno un modello di AI. ## Human in the loop come requisito di architettura L'esito più frequente di questo censimento è la decisione di scrivere una policy. È la risposta sbagliata, e il caso Uber lo mostra bene: una procedura che prevede la revisione umana non protegge se il sistema è comunque in grado di produrre l'esito senza attenderla. Il presidio va messo nel flusso, non nel documento. In termini concreti significa che il sistema non deve poter chiudere l'operazione finché un'autorizzazione non è stata registrata, che l'autorizzazione deve essere tracciata con identità e timestamp, e che chi autorizza deve vedere il caso e non solo il punteggio. È una decisione di architettura, e come tale va presa in fase ARCHITECT insieme al resto del disegno, non aggiunta in fase ACTIVATE quando il sistema è già in produzione. Il costo di inserire un punto di autorizzazione in un flusso già rilasciato è, nella nostra esperienza, tra le tre e le sei volte quello di prevederlo nel disegno iniziale. ## Da dove partire Un'azienda strutturata italiana ha in media tra i quindici e i quaranta flussi che meritano la verifica, distribuiti tra ERP, CRM, portali fornitori, sistemi HR e piattaforme di customer service. Il censimento richiede da due a quattro settimane di lavoro e produce tre risultati: la mappa dei flussi, la classificazione del rischio per ciascuno, e la lista dei punti di autorizzazione da inserire in ordine di priorità. Lo stesso inventario serve poi come base per la classificazione ai sensi dell'Allegato III dell'AI Act quando gli obblighi diventeranno applicabili nel dicembre 2027, senza doverlo rifare da capo. --- **Fonti** - [Autoriteit Persoonsgegevens, comunicato del 21 agosto 2026](https://autoriteitpersoonsgegevens.nl/en/current/uber-fined-nearly-825-million-euros-for-automated-driver-blocking) - [Commissione europea, avvio dell'enforcement dell'AI Act, 2 agosto 2026](https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1714) - [Cooley, obblighi di trasparenza dell'articolo 50 in vigore dal 2 agosto 2026](https://www.cooley.com/news/insight/2026/2026-08-03-eu-ai-act-transparency-obligations-take-effect-2-august-2026) - [TechCrunch, la posizione di Uber e il ricorso, 23 agosto 2026](https://techcrunch.com/2026/08/23/uber-faces-fine-of-nearly-1b-over-automated-driver-suspensions/) --- # AI adoption in manifattura: stabilimento o prodotto, la scelta che viene prima URL: https://zerofive.ai/blog/strategia/ai-adoption-manifattura-stabilimento-prodotto Data: 2026-08-21 Abstract: Lo stesso modello cambia regime secondo la destinazione. La mappa dei casi, la verifica sullo storico e perché un pilota non si replica da solo. **In sintesi.** In manifattura la scelta del primo caso d'uso si gioca su una separazione che precede ogni altra valutazione: se il sistema resta in stabilimento o finisce dentro un prodotto venduto. Nel primo caso l'azienda è deployer e il percorso è breve, nel secondo diventa fornitore ai sensi del regolamento e il percorso passa dalla valutazione di conformità del prodotto. Partire dallo stabilimento consente di imparare prima di assumersi obblighi di prodotto, ed è per questo che conviene, al di là della prudenza. In fabbrica la conversazione sull'AI parte quasi sempre da manutenzione predittiva e controllo qualità, e questa volta l'istinto è corretto. Il problema arriva dopo, quando la stessa tecnologia viene proposta per il prodotto senza che nessuno abbia notato il cambio di regime. ## Una separazione che viene prima di tutto Un modello di visione artificiale che controlla i pezzi sulla linea è un sistema che l'azienda usa per sé. Lo stesso identico modello, integrato dentro una macchina che l'azienda vende a un cliente, diventa un sistema che l'azienda immette sul mercato, con tutto quello che ne consegue in termini di documentazione e responsabilità. Cambia tutto. Il primo comporta obblighi da utilizzatore. Il secondo comporta obblighi da fornitore, con documentazione tecnica, valutazione di conformità e responsabilità verso chi acquista. La tecnologia è identica, il regime no. Questa separazione va fatta prima di costruire il portfolio, perché determina tempi, costi e competenze necessarie. Un'azienda che la scopre a progetto avviato si trova con un prodotto in sviluppo e nessuna preparazione sul percorso di conformità. ## La mappa dei casi candidati | Caso d'uso | Valore | Attrito regolamentare | Adatto come primo | |---|---|---|---| | Manutenzione predittiva su impianti | Alto, in fermi evitati | Basso | Sì | | Controllo qualità visivo non di sicurezza | Alto, in scarti | Basso | Sì | | Ottimizzazione di schedulazione e consumi | Medio-alto | Basso | Sì | | Assistenza documentale per manutentori | Medio, in tempo | Basso | Sì | | Controllo con funzione di sicurezza | Alto | Alto, cambia classe | No, non come primo | | AI integrata in prodotti venduti | Il più alto strategicamente | Alto, Allegato I | No, richiede percorso dedicato | | Monitoraggio produttività dei lavoratori | Medio, contestato | Alto, Allegato III e diritto del lavoro | Da valutare con le rappresentanze | L'ultima riga merita una nota che non è normativa. Questi sistemi vengono spesso introdotti come strumenti di efficienza, e producono conflitto interno quando le persone capiscono cosa misurano. Il costo del conflitto raramente entra nel business case. ## Il vincolo sta nel dato, non nel modello In manifattura il fattore che determina il risultato è quasi sempre la qualità dello storico. La manutenzione predittiva funziona se esistono dati di guasto etichettati correttamente, e in molti stabilimenti quei dati sono in un gestionale di manutenzione compilato in modo discontinuo. La verifica da fare prima di qualunque pilota è banale e la saltano in molti: prendere un anno di storico, contare quanti eventi di guasto sono registrati con causa e data affidabili, e verificare se sono abbastanza per addestrare qualcosa. Quando la risposta è no, il primo progetto sensato riguarda la raccolta dei dati e non un modello. La direzione non vuole sentirselo dire, e sentirlo evita di spendere per un pilota che non può riuscire. ## Un pilota su una linea non si replica da solo Il perimetro giusto in fabbrica è una linea, una cella o un impianto. La baseline si misura su quella linea, non sulla media di stabilimento, e i criteri di accettazione si fissano prima. C'è però una specificità: quello che funziona su una linea non funziona automaticamente su un'altra, perché cambiano macchine, materiali e operatori. L'estensione va trattata come un nuovo progetto con una sua verifica, non come una replica. Molte aziende scoprono questo punto dopo aver comprato licenze per tutto lo stabilimento. ## Chi deve poter fermare il sistema La responsabilità di un sistema AI in fabbrica non può stare sull'IT, che non conosce il processo, né sul responsabile di produzione, che è misurato sull'output e non ha tempo. Il punto di equilibrio è di solito il responsabile di manutenzione o il responsabile qualità, a seconda del caso d'uso, con un riferimento in direzione operations. La persona deve avere l'autorità di fermare il sistema quando serve. Un proprietario che non può spegnere resta tale solo sulla carta. ## Da dove partire La sequenza parte dall'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), separando stabilimento e prodotto fin dalla prima riga. I criteri generali di selezione sono in [AI adoption: come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso), il modello di costo in [budget di un progetto AI](/blog/strategia/budget-progetto-ai-pilota-produzione). Il quadro normativo del settore è nella pagina [AI governance per la manifattura](/settori/industria). Per valutare quali casi d'uso hanno senso nella tua azienda puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in manifattura: dove innestarsi senza snaturare URL: https://zerofive.ai/blog/compliance/ai-literacy-manifattura-formazione-fabbrica Data: 2026-08-19 Abstract: OT e IT non si parlano. I tre ruoli con evidenza individuale e la finestra naturale dell'avvio di una nuova linea produttiva. **In sintesi.** In manifattura la formazione AI incontra un impianto formativo che esiste già ed è obbligatorio per legge, quello sulla sicurezza sul lavoro. È il punto di innesto più efficiente, e allo stesso tempo il rischio, perché parlare di AI dentro il modulo sicurezza porta a trattarla come un pericolo invece che come uno strumento da governare. I ruoli con evidenza individuale sono tre, e uno di questi, il progettista di prodotto, in molte aziende non è ancora consapevole di esserlo. In fabbrica la formazione ha una tradizione lunga e una struttura definita, con preposti, addetti e responsabili, ruoli che la legge nomina e a cui assegna compiti precisi. Chi arriva a costruire il piano AI trova già linguaggio, calendario e tracciamento, e la tentazione di appoggiarsi interamente a quell'impianto è forte. Conviene resistere in parte. ## Due mondi che non si parlano In manifattura convivono due popolazioni con competenze e culture diverse. Il mondo OT, che governa macchine e linee, con una cultura di affidabilità e sicurezza costruita in decenni. Il mondo IT, che governa gestionali e dati, con una cultura di processo e progetto. I sistemi AI cadono in mezzo, e questo crea un problema formativo specifico: chi conosce la macchina non conosce il modello, chi conosce il modello non conosce il processo produttivo. Un piano che forma separatamente le due popolazioni lascia scoperto proprio il punto di contatto, che è dove i problemi nascono. La soluzione praticabile non è formare tutti su tutto. È costruire un modulo comune breve sui punti di contatto, e poi percorsi separati sulla parte specifica. ## I tre ruoli con evidenza individuale **Chi progetta prodotti che incorporeranno AI.** È il ruolo che in molte aziende non sa ancora di essere critico. Un sistema AI integrato in un prodotto soggetto a normativa di armonizzazione ricade in Allegato I, e la valutazione di conformità si progetta insieme al prodotto. Chi disegna quelle scelte deve conoscerne le conseguenze, e la scadenza del 2028 non rende la formazione rinviabile, perché i prodotti in progettazione oggi arrivano sul mercato allora. **Chi introduce sistemi che misurano le persone.** Monitoraggio della produttività, assegnazione dei compiti, valutazione delle prestazioni: sono sistemi in Allegato III, e in Italia si sommano i vincoli del diritto del lavoro. Chi li propone o li configura deve sapere cosa comporta. **Chi esercita sorveglianza umana su sistemi con funzione di sicurezza.** Qui la competenza si somma a quella già richiesta dalla normativa antinfortunistica, e la documentazione deve tenerle insieme. ## Dove si innesta, senza snaturarlo | Impianto esistente | Cosa copre già | Cosa aggiungere per l'AI | |---|---|---| | Formazione sicurezza per addetti | Uso corretto delle macchine, rischi | Comportamento dei sistemi adattivi e quando fermarsi | | Formazione preposti | Vigilanza e responsabilità | Cosa segnalare su un sistema che decide | | Formazione progettisti | Conformità di prodotto e marcatura | Requisiti che arrivano dall'AI Act sui sistemi integrati | | Addestramento su nuova linea | Uso operativo | Limiti noti del sistema e casi in cui il dato non regge | | Formazione qualità | Controlli e non conformità | Differenza tra un controllo deterministico e uno probabilistico | L'ultima riga è quella che produce più valore immediato. Chi lavora in qualità ragiona per soglie e tolleranze, e un sistema di controllo visivo basato su modelli funziona diversamente: sbaglia in modo differente, e il modo in cui sbaglia va insegnato. ## Quando formare, dentro un ciclo produttivo In fabbrica la formazione ha una finestra naturale che altri settori non hanno, e coincide con l'introduzione di una nuova linea o di un nuovo macchinario, quando l'addestramento è già previsto a budget, le persone sono state liberate dalla produzione e il tecnico del fornitore è fisicamente presente in reparto. È la condizione migliore possibile. Innestare lì i contenuti AI costa quasi nulla in più e produce competenza legata al sistema specifico, che è esattamente quello che la clausola 7 chiede. Fuori da quella finestra la formazione compete con la produzione, e perde. ## Il fornitore della macchina non è il fornitore del modello Una complicazione tipica della manifattura riguarda la catena. Il costruttore della macchina integra componenti di terzi, che a loro volta incorporano modelli sviluppati da altri. Quando qualcosa non funziona, capire chi risponde richiede di risalire una catena che nessuno ha mappato. Sul piano formativo l'azienda deve quindi pretendere dal costruttore informazioni sui limiti noti del sistema, e non accontentarsi del manuale d'uso. Senza quelle informazioni la formazione resta generica, e in caso di incidente non dimostra nulla. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), che in manifattura deve separare i sistemi di stabilimento da quelli destinati ai prodotti, perché i due gruppi hanno regimi e scadenze diverse. Da lì si costruisce la matrice, descritta in [la matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai). I requisiti completi sono in [la clausola 7 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze). Il quadro normativo del settore è nella pagina [AI governance per la manifattura](/settori/industria). L'approccio ai percorsi per ruolo è nella pagina [AI Training](/servizi/ai-training). Per valutare il piano della tua azienda puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # L'intelligenza artificiale nel D.Lgs. 231/2001: il nuovo articolo 25-vicies, perimetro e obblighi URL: https://zerofive.ai/blog/compliance/dlgs-231-articolo-25-vicies-ai Data: 2026-08-18 Abstract: Articolo 25-vicies D.Lgs. 231/2001 dopo il D.Lgs. 160/2026: reati 437-bis e 612-quater, sanzioni, tempi e aggiornamento del modello organizzativo. > **Aggiornamento del 16 settembre 2026.** Il decreto è stato pubblicato nella Gazzetta Ufficiale n. 214 del 15 settembre 2026 come decreto legislativo 9 settembre 2026, n. 160, ed entra in vigore il 30 settembre. L'articolo è stato rivisto sul testo ufficiale: numerazione e sanzioni sono confermate, mentre la descrizione dell'articolo 437-bis è stata corretta rispetto alla versione del 18 agosto, scritta sul testo approvato dal Consiglio dei ministri. **In sintesi.** Il nuovo articolo 25-vicies del D.Lgs. 231/2001 rende le società responsabili per due reati legati all'AI: l'omessa adozione di misure di sicurezza e di sorveglianza umana nei sistemi ad alto rischio, insieme all'alterazione illecita di quei sistemi (articolo 437-bis del codice penale), e la diffusione illecita di deepfake (articolo 612-quater). Le sanzioni pecuniarie vanno da 600 a 1.000 quote per il primo reato e da 200 a 700 quote per il secondo, con una selezione delle sanzioni interdittive. Per chi usa un sistema ad alto rischio senza averlo sviluppato il reato richiede che la sorveglianza umana sia omessa intenzionalmente. L'aggiornamento del modello organizzativo 231 parte dall'inventario dei sistemi AI. ## La fonte della nuova responsabilità L'estensione della responsabilità degli enti arriva da una scelta del legislatore italiano, esercitata con la delega dell'articolo 24 della legge 132/2025, che chiedeva al Governo di precisare i criteri di imputazione della responsabilità amministrativa degli enti per gli illeciti legati ai sistemi di AI; il regolamento europeo, da solo, non la prevede. Il decreto 160/2026, che nella prima parte disciplina l'uso dell'AI da parte delle Forze di polizia, esegue quella delega con l'articolo 15, che inserisce nel decreto 231 l'articolo 25-vicies, rubricato "Reati commessi con l'uso di sistemi di intelligenza artificiale". Il nuovo articolo si colloca dopo il 25-undevicies, in un catalogo di reati presupposto che negli ultimi anni si è allungato quasi a ogni semestre, e porta dentro il perimetro 231 un rischio che molte aziende finora trattavano soltanto come tema tecnico o di protezione dei dati. ## Due reati presupposto | Reato | Sanzione pecuniaria all'ente | Sanzioni interdittive | |---|---|---| | Art. 437-bis c.p., omessa adozione di misure di sicurezza nei sistemi di AI e alterazione illecita dei sistemi | Da 600 a 1.000 quote | Art. 9, comma 2, lettere b), c), d), e) | | Art. 612-quater c.p., illecita diffusione di contenuti generati o alterati con sistemi di AI | Da 200 a 700 quote | Art. 9, comma 2, lettere b), c), d), e) | Le interdittive richiamate sono la sospensione o revoca di autorizzazioni, licenze o concessioni, il divieto di contrattare con la pubblica amministrazione, l'esclusione da agevolazioni, finanziamenti e contributi, il divieto di pubblicizzare beni o servizi. Resta fuori la lettera a), l'interdizione dall'esercizio dell'attività, che è la sanzione più pesante del sistema 231. L'articolo 612-quater, la norma sui deepfake, esiste dal 2025 perché è stato introdotto dalla legge 132, e punisce chi diffonde senza consenso immagini, video o voci falsificati, idonei a ingannare sulla loro autenticità, cagionando un danno ingiusto. Con il 25-vicies diventa anche reato presupposto, quando è commesso nell'interesse o a vantaggio dell'ente. ## La struttura dell'articolo 437-bis L'articolo 437-bis, introdotto dall'articolo 12 del decreto, ha quattro commi con destinatari e condotte diversi. | Comma | Chi | Condotta | Pena | |---|---|---|---| | Primo | Chiunque, nella progettazione, nell'addestramento, nella produzione e nell'immissione sul mercato di sistemi ad alto rischio | Omette le misure tecniche di sicurezza previste, idonee a prevenire malfunzionamenti o alterazioni, oppure omette le misure di sorveglianza umana | Reclusione da 1 a 5 anni se ne deriva pericolo per la vita o l'incolumità pubblica o individuale; da 2 a 8 anni se il pericolo riguarda la sicurezza dello Stato | | Secondo | Chiunque, fuori dai casi del primo comma | Altera sistemi di AI ad alto rischio | Reclusione da 2 a 6 anni; da 3 a 10 anni se il pericolo riguarda la sicurezza dello Stato, salvo che il fatto costituisca più grave reato | | Terzo | Autori dei fatti del primo comma | Stessi fatti commessi per colpa grave | Pena ridotta da un terzo a un sesto | | Quarto | Utilizzatore professionale di sistemi ad alto rischio | Omette intenzionalmente di adottare le misure di sorveglianza umana | Le pene del primo comma, secondo il tipo di pericolo | Il primo comma riguarda la filiera che costruisce e mette in commercio il sistema, quindi la posizione che l'AI Act assegna al fornitore e ai soggetti che intervengono a monte. L'utilizzatore professionale, figura vicina al deployer dell'AI Act, ha una norma dedicata nel quarto comma, che richiede l'omissione intenzionale: la riduzione per colpa grave del terzo comma rimanda solo ai fatti del primo, e per chi usa un sistema senza averlo sviluppato una forma colposa non è prevista. Tutte le ipotesi, per come è scritto il testo, richiedono che dalla condotta derivi un pericolo per la vita, per l'incolumità pubblica o individuale o per la sicurezza dello Stato. La mancanza di un adempimento formale, da sola, non integra il reato, e questo sposta l'attenzione sulla sorveglianza umana esercitata davvero, giorno per giorno, più che sulla sua descrizione nei documenti. ## I tempi di applicazione Il decreto è in vigore dal 30 settembre 2026, però il 437-bis rinvia alle misure "previste" per i sistemi ad alto rischio, e nell'AI Act quegli obblighi, dopo il Digital Omnibus (Regolamento (UE) 2026/1744), si applicano dal 2 dicembre 2027 per i sistemi dell'Allegato III e dal 2 agosto 2028 per quelli dell'Allegato I. Il rapporto tra le due date è una questione che chiariranno penalisti e giurisprudenza. Per l'organizzazione aziendale la conclusione cambia poco. Un modello 231 descrive presidi che devono esistere prima che il rischio si concretizzi, e costruirli su un parco di sistemi AI richiede mesi di lavoro tra inventario, contratti e procedure. ## Il meccanismo che attiva la responsabilità dell'ente Perché scatti la responsabilità della società servono le due condizioni che valgono per tutto il catalogo 231: il reato è commesso nell'interesse o a vantaggio dell'ente da un soggetto apicale o da un sottoposto, e l'ente non dimostra di aver adottato ed efficacemente attuato un modello idoneo a prevenirlo. La colpa di organizzazione è un criterio vecchio quanto il decreto. Cambia il suo oggetto, che adesso comprende le scelte fatte a monte sui sistemi di AI, cioè come sono stati selezionati, con quali criteri configurati, con quale continuità sorvegliati e con quale rigore documentati. L'esonero resta possibile con i presidi di sempre, un modello adottato prima del fatto, un organismo di vigilanza con poteri autonomi e un sistema disciplinare, a condizione che il modello tratti il rischio algoritmico in modo specifico e non come una variante del rischio informatico generico. ## L'aggiornamento del modello 231 | Attività | Cosa produce | Chi la guida | |---|---|---| | Inventario dei sistemi di AI | Elenco con finalità, classe di rischio AI Act e ruolo dell'azienda nella filiera | Compliance con IT e responsabili di processo | | Incrocio con i processi sensibili 231 | Mappa dei punti in cui un sistema ad alto rischio tocca un processo già esposto | Compliance e organismo di vigilanza | | Assegnazione delle responsabilità | Nomi per adozione, configurazione, sorveglianza e gestione delle anomalie | Direzione | | Procedure di sorveglianza umana | Regole scritte su chi interviene, su quali segnali e con quale traccia | Responsabile del processo | | Conservazione delle evidenze | Log, interventi umani e anomalie, con tempi di conservazione definiti | IT e fornitori, con clausole contrattuali | | Formazione mirata | Contenuti differenziati per ruolo | HR e compliance | Le evidenze della tabella servono anche fuori dal perimetro penale. Lo stesso decreto, negli articoli da 16 a 20, rende log e documentazione di sorveglianza oggetto di ordini di esibizione nelle cause civili per danni da AI, con conseguenze pesanti per chi non li produce, come spieghiamo nell'articolo su [accesso alle prove e nesso causale](/blog/compliance/danni-ai-prove-nesso-causale-dlgs-160-2026). ## Una riforma del decreto 231 in parallelo Nella stessa riunione del 4 agosto 2026 il Consiglio dei ministri ha approvato anche un disegno di legge di riforma più ampia del decreto 231, che interviene tra l'altro sulla prescrizione dell'illecito amministrativo e sull'onere della prova nei reati colposi. Quel testo deve ancora compiere l'intero iter parlamentare, con tempi più lunghi di un decreto attuativo, e nel monitoraggio normativo le due riforme vanno tenute separate: il 25-vicies è legge dal 30 settembre, il disegno di legge è ancora una proposta. ## Il passo successivo L'aggiornamento del modello 231 parte dall'inventario, perché senza sapere quali sistemi sono in uso e con quale ruolo nessuna attività della tabella ha un oggetto. Il metodo è nella guida all'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), e gli obblighi dell'AI Act già vincolanti sono ricostruiti in [AI Act, 2 agosto 2026: cosa è davvero vincolante](/blog/compliance/ai-act-2-agosto-2026-cosa-e-vincolante). Con l'[AI Rating](/servizi/ai-rating) misuriamo la maturità dell'azienda anche sulla dimensione AI Risk, che copre compliance, sicurezza e governance dei rischi. Per un confronto sul tuo modello organizzativo puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive) oppure scrivere a hello@zerofive.ai. *Questo articolo descrive il testo normativo e le sue implicazioni organizzative, e non costituisce parere legale.* **Fonti.** Decreto legislativo 9 settembre 2026, n. 160, Gazzetta Ufficiale, Serie generale, n. 214 del 15 settembre 2026, articoli 12 e 15; decreto legislativo 8 giugno 2001, n. 231, articoli 9 e 25-vicies; legge 23 settembre 2025, n. 132, articolo 24; Regolamento (UE) 2024/1689 come modificato dal Regolamento (UE) 2026/1744; Consiglio dei ministri, comunicato del 4 agosto 2026. --- # Automazione AI dei processi: cosa si automatizza davvero e cosa conviene lasciare com'è URL: https://zerofive.ai/blog/strategia/automazione-ai-processi-aziendali Data: 2026-08-18 Abstract: Differenze con l'automazione classica, i processi che si prestano, come si misura il risparmio e dove l'automazione diventa un progetto organizzativo. **In sintesi.** L'automazione AI si distingue da quella classica per un dettaglio che cambia tutto il progetto: l'automazione tradizionale esegue regole scritte da qualcuno, mentre quella con AI interpreta input non strutturati e produce output che vanno verificati. Questo la rende utilizzabile dove prima non si poteva automatizzare, documenti, messaggi, pratiche eterogenee, e insieme la rende inadatta ai processi dove l'errore non è recuperabile. Il confine tra i due mondi non è tecnologico. Riguarda la domanda su chi controlla il risultato e cosa succede quando il risultato è sbagliato. ## Automazione classica e automazione con AI | Aspetto | Automazione classica | Automazione con AI | |---|---|---| | Input | Strutturato, campi noti | Anche non strutturato, documenti e testo libero | | Comportamento | Deterministico, stesso input stesso output | Variabile, due esecuzioni possono differire | | Errore | Prevedibile, si corregge la regola | Statistico, si riduce ma non si azzera | | Manutenzione | Alla modifica del processo | Anche quando cambia il modello o il fornitore | | Verifica | Test sui casi noti | Campionamento continuo sugli output reali | La riga sul comportamento è quella che cambia la progettazione. Un'automazione classica si collauda una volta, mentre un'automazione con AI va osservata nel tempo, perché il comportamento può cambiare dopo un aggiornamento che non avete deciso voi. Le due tecnologie convivono bene. Nei progetti che funzionano l'AI si occupa del passaggio interpretativo, leggere un documento, classificare una richiesta, estrarre dati, e le regole deterministiche si occupano di tutto il resto, perché sono più economiche e più prevedibili. ## I processi che si prestano | Processo | Perché funziona | |---|---| | Classificazione di richieste in arrivo | Volume alto, regole chiare, errore recuperabile | | Estrazione di dati da documenti | Il risultato è verificabile campo per campo | | Controllo di completezza su pratiche | L'output è una lista di anomalie, non una decisione | | Preparazione di bozze e riepiloghi | La persona resta l'autore finale | | Riconciliazione tra fonti diverse | Il confronto produce differenze misurabili | Si prestano male i processi dove una decisione sbagliata produce effetti su una persona, quelli dove il recupero richiede una comunicazione esterna, e quelli con volumi bassi, dove il costo di costruzione e presidio non rientra mai. C'è poi un caso intermedio che vale la pena nominare. Un processo con volume alto e regole instabili, che cambiano ogni pochi mesi, è un cattivo candidato per l'automazione classica e un candidato ragionevole per quella con AI, a condizione che qualcuno aggiorni gli esempi di riferimento quando le regole cambiano. ## Come si misura il risparmio Il numero che conta non è la percentuale di casi gestiti dal sistema, è il tempo che le persone smettono di spendere. Sono due cose diverse, perché un'automazione che gestisce il settanta per cento dei casi e obbliga a ricontrollare tutto non libera nulla. Servono tre misure prese prima di iniziare: il tempo medio per caso, il volume nel periodo e la percentuale di casi che oggi richiede una rilavorazione. Dopo il rilascio, le stesse tre misure dicono se il progetto ha funzionato, e nessuna di queste richiede strumenti sofisticati per essere raccolta. A queste va aggiunta una quarta misura, che riguarda la fiducia: quanto spesso gli operatori modificano l'output del sistema. Se la percentuale resta alta dopo due mesi, il sistema sta producendo lavoro invece di toglierne. ## Dove l'automazione tocca le persone Un'automazione che cambia come lavora un reparto è un progetto organizzativo prima che tecnico, e il punto delicato arriva quando il sistema smista, assegna o misura il lavoro delle persone. Quei casi ricadono nell'Allegato III dell'AI Act, perché riguardano la gestione dei lavoratori, e in Italia si sommano i vincoli del diritto del lavoro e il confronto con le rappresentanze. Un software che distribuisce carichi di lavoro tra operatori non diventa innocuo perché è stato comprato come modulo gestionale. La regola pratica è separare presto i due perimetri. L'automazione dei processi che trattano documenti e richieste è un progetto di efficienza, l'automazione che tocca l'organizzazione del lavoro è un progetto che richiede classificazione, documentazione e confronto interno. ## Gli errori che si ripetono Il primo è automatizzare un processo rotto. Se il flusso attuale ha passaggi inutili, l'automazione li rende più veloci e li cristallizza, quindi conviene semplificare prima e automatizzare dopo. Il secondo è costruire senza una via di ritorno. Un processo che dipende da un sistema automatico senza alternativa manuale diventa un rischio operativo il giorno in cui il fornitore ha un disservizio. Il terzo è sottovalutare i casi limite, che nelle operazioni reali contengono la parte più costosa del lavoro. Un sistema che consegna i casi difficili a una persona senza spiegare perché li ha scartati trasferisce il problema invece di risolverlo. ## Da dove partire Il punto di ingresso è l'inventario di quello che esiste già, descritto in [inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), perché molte aziende hanno moduli di automazione con AI accesi dentro gestionali comprati per altro. Per la scelta del processo da cui cominciare ci sono [come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso) e il metodo del [value case con l'alternativa non-AI](/blog/strategia/value-case-alternativa-non-ai-scartata). Sugli agenti, che sono la forma di automazione più discussa, c'è [agenti AI: guida per le aziende](/blog/ai-governance/agenti-ai-guida-aziende). Per capire quali processi reggono l'automazione nella vostra organizzazione puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Intelligenza artificiale per aziende: cosa serve davvero prima di investire URL: https://zerofive.ai/blog/strategia/intelligenza-artificiale-per-aziende Data: 2026-08-11 Abstract: Cosa valutare prima di investire in AI: maturità, casi d'uso che si misurano in un trimestre, costi reali e obblighi già in vigore. **In sintesi.** L'intelligenza artificiale per aziende è diventata una voce di budget prima di diventare una competenza, e questo spiega perché il 71% delle grandi imprese italiane ha avviato progetti mentre solo una minoranza ottiene risultati misurabili. Le decisioni che contano si prendono prima di scegliere la tecnologia: quale problema si risolve, quanto vale, cosa succede se il sistema sbaglia, chi risponde del risultato. Questa guida mette in fila quello che serve sapere prima di investire, con i numeri di partenza, i casi d'uso che si verificano in poche settimane, il costo reale e gli obblighi già in vigore. ## Dove sono davvero le aziende italiane Il mercato italiano dell'AI ha superato 1,8 miliardi di euro nel 2025, con una crescita vicina al 50% in un anno. L'adozione tra le grandi imprese è salita al 71%, mentre tra le piccole e medie imprese resta intorno all'8%. Quel divario racconta due cose. La prima è che la tecnologia non è più il fattore limitante, perché gli stessi strumenti sono accessibili a un'azienda da venti persone e a una da cinquemila. La seconda è che il fattore limitante è organizzativo: serve qualcuno che decida cosa automatizzare, qualcuno che validi i risultati e qualcuno che risponda quando il sistema produce un errore. C'è anche un dato meno citato e più utile. In molte organizzazioni che dichiarano di avere progetti AI attivi, quei progetti sono esperimenti isolati dentro una funzione, senza integrazione con i sistemi gestionali e senza una misura del ritorno. Restano fermi lì per mesi, consumano budget e generano la sensazione che l'AI non funzioni. ## I tre errori che bruciano il primo budget Il primo errore è partire dalla tecnologia. Un'azienda sceglie una piattaforma, la paga, e solo dopo cerca il problema da risolvere. L'ordine giusto parte dal processo che costa di più o che sbaglia di più, e la tecnologia arriva alla fine. Il secondo errore è scegliere un caso d'uso vistoso invece di uno verificabile. Un assistente che parla con i clienti si vede subito e si misura con difficoltà, perché il risultato dipende da variabili che cambiano ogni settimana. Un controllo automatico su un flusso documentale interno è meno raccontabile e produce un numero chiaro in quattro settimane. Il terzo errore è non misurare la situazione di partenza. Senza la baseline, qualunque risultato diventa opinabile, e la discussione sul rinnovo del budget si sposta sulle impressioni di chi ha gestito il progetto. ## Una PMI non ha lo stesso problema di una grande impresa Nelle grandi organizzazioni il problema è il coordinamento. Esistono più iniziative parallele, spesso ignote l'una all'altra, e la difficoltà è mettere ordine, evitare duplicazioni e stabilire chi decide. Il valore di un intervento esterno sta nel costruire il quadro generale e i criteri di selezione. Nelle PMI strutturate il problema è opposto. Le competenze interne sono concentrate su poche persone che hanno già un lavoro a tempo pieno, e il rischio è comprare una soluzione che nessuno avrà il tempo di presidiare. Qui il valore sta nel scegliere pochissimi casi d'uso e portarli fino in fondo, con un presidio sostenibile. | Dimensione | Problema tipico | Primo passo utile | |---|---|---| | Grande impresa | Iniziative parallele non coordinate | Inventario e criteri di priorità | | PMI strutturata | Competenze concentrate su poche persone | Un solo caso d'uso, portato in produzione | | Azienda con pilot fermi | Nessun passaggio dal test alla produzione | Analisi del punto in cui i progetti si bloccano | ## I casi d'uso che si misurano in un trimestre Un primo progetto serve a imparare e a costruire fiducia interna, quindi conta più la verificabilità del potenziale teorico. | Caso d'uso | Tempo per una verifica | Rischio normativo | |---|---|---| | Ricerca e sintesi su documenti interni | 3-4 settimane | Basso | | Controllo di completezza su pratiche e contratti | 4-6 settimane | Basso | | Previsione della domanda o dei consumi | 4-8 settimane | Basso | | Assistente per il servizio clienti | 6-8 settimane | Basso, obbligo di trasparenza | | Supporto alla preventivazione | 6-10 settimane | Medio, dipende dai dati | | Selezione del personale | non adatto come primo | Alto, Allegato III | | Valutazione del merito creditizio | non adatto come primo | Alto, Allegato III | Le ultime due righe non sono un divieto. Sono casi d'uso che richiedono documentazione, valutazione dei rischi e sorveglianza umana, quindi vanno affrontati quando l'organizzazione ha già una struttura di governo, non come prima esperienza. ## Quanto costa l'AI per un'azienda Le stime che circolano guardano al costo delle licenze, che è la parte più visibile e spesso la meno rilevante. Questo è il quadro completo delle voci che vediamo nei progetti reali. | Voce | Peso tipico | |---|---| | Licenze e consumo del modello | 10-20% | | Integrazione con i sistemi esistenti | 25-40% | | Preparazione e pulizia dei dati | 15-30% | | Tempo interno di validazione nei primi mesi | 10-20% | | Formazione e accompagnamento | 5-10% | | Presidio e manutenzione dopo il rilascio | 10-20% all'anno | Il presidio è la voce che manca quasi sempre nei business case. Un sistema in produzione va monitorato, i modelli cambiano comportamento con gli aggiornamenti del fornitore, e la documentazione va mantenuta. Un progetto che non prevede questa linea di budget nasce con una scadenza implicita. ## Cosa è obbligatorio adesso e cosa lo diventa nel 2027 Parte degli obblighi è già in vigore, e il Digital Omnibus ha spostato in avanti soltanto quelli sui sistemi ad alto rischio. | Cosa | Da quando | |---|---| | Pratiche vietate e obbligo di alfabetizzazione, articolo 4 | 2 febbraio 2025 | | Obblighi per i fornitori di modelli di uso generale | 2 agosto 2025 | | Applicazione generale, trasparenza dell'articolo 50, sanzioni | 2 agosto 2026 | | Sistemi ad alto rischio dell'Allegato III | 2 dicembre 2027 | | Sistemi ad alto rischio incorporati in prodotti regolamentati | 2 agosto 2028 | L'obbligo di alfabetizzazione è quello che sorprende più spesso, perché riguarda chiunque usi sistemi AI per conto dell'azienda, inclusi collaboratori esterni e personale di rete. La conseguenza pratica per un'azienda che sta cominciando adesso è semplice. Un assistente che risponde ai clienti va dichiarato come sistema automatico già oggi, e un sistema che valuta persone va trattato fin dall'inizio come se gli obblighi fossero già in vigore, perché la documentazione si costruisce durante il progetto e non si recupera dopo. ## Come si decide se partire La decisione si prende su quattro domande, e tutte e quattro hanno bisogno di una risposta scritta. La prima riguarda il numero di partenza. Se nessuno sa quante ore costa oggi quel processo o quanti errori produce, il primo lavoro è misurarlo, perché senza quella cifra non esiste modo di dire se il progetto ha funzionato. Poi viene l'alternativa più semplice, che va valutata e scartata per iscritto: molti problemi si risolvono cambiando una soglia di autorizzazione, riordinando un archivio o correggendo un modulo, e senza quel passaggio il confronto resta tra fare il progetto e non fare nulla. La terza domanda riguarda chi risponde. Un progetto senza un responsabile che abbia il potere di fermarlo prosegue finché c'è budget, indipendentemente dai risultati. L'ultima riguarda i dati, ed è quella su cui si ferma la maggior parte delle iniziative, quando emerge che le informazioni necessarie appartengono contrattualmente a un fornitore oppure vivono dentro sistemi che non si parlano. ## Da dove partire Il punto di ingresso è la misurazione della maturità, descritta nella pagina [AI Rating](/servizi/ai-rating), che restituisce un punteggio sulle quattro dimensioni e indica il vincolo da sciogliere per primo. Per il metodo di selezione dei casi d'uso ci sono [come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso) e [prioritizzare gli use case](/blog/strategia/prioritizzare-use-case-ai). Il quadro completo dell'adozione è in [framework di AI adoption](/blog/strategia/framework-ai-adoption-guida-pratica-imprese), mentre i costi sono trattati in [quanto costa davvero un progetto AI](/blog/strategia/quanto-costa-davvero-progetto-ai). Sugli obblighi normativi il riferimento è [AI Act: guida completa](/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati), e per i vincoli specifici del vostro comparto c'è la pagina [Settori](/settori). Per capire da dove conviene partire nella vostra organizzazione puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # AI Act 2 agosto 2026: cosa è davvero vincolante URL: https://zerofive.ai/blog/compliance/ai-act-2-agosto-2026-cosa-e-vincolante Data: 2026-08-06 Abstract: Cosa scatta davvero il 2 agosto 2026: articolo 50, sanzioni e vigilanza ACN. L'Allegato III slitta al 2 dicembre 2027 con il Digital Omnibus. Nei giorni intorno al 2 agosto abbiamo letto decine di titoli sull'AI Act, e non dicono tutti la stessa cosa. Alcuni parlano di trasparenza e sanzioni, altri aggiungono i sistemi ad alto rischio come se scattassero anche quelli, altri ancora mescolano scadenze di anni diversi in un unico paragrafo. Per un board che deve decidere cosa fare lunedì mattina, la sfumatura pesa: separa un adempimento reale da un allarme fuori tempo. Proviamo a mettere ordine, con le fonti verificate una per una. ## Tre obblighi diventano operativi oggi Tre cose diventano operative il 2 agosto 2026, e sono reali. La prima è la trasparenza dell'articolo 50: chi fornisce chatbot, assistenti vocali o sistemi che interagiscono con le persone deve renderne riconoscibile la natura artificiale, e lo stesso vale per testi, immagini, audio e video generati o alterati dall'AI, marcati in modo leggibile nei limiti tecnici disponibili. Il Digital Omnibus concede però una finestra fino al 2 dicembre 2026 per i sistemi già presenti sul mercato prima di oggi: chi ha lanciato uno strumento a giugno ha ancora quattro mesi, chi lo lancia domani no. La seconda è il regime sanzionatorio, che da oggi diventa pienamente esigibile per le violazioni di questi obblighi di trasparenza e per i divieti dell'articolo 5, quelli in vigore dal febbraio 2025. Le cifre sono precise: fino a 15 milioni di euro o il 3% del fatturato globale per la trasparenza, fino a 35 milioni o il 7% per le pratiche vietate. Non sono massimali teorici, la Commissione ha pubblicato linee guida operative nei giorni precedenti proprio per renderli applicabili da subito. La terza è meno visibile ma pesa per chi opera in Italia: da oggi la vigilanza nazionale è pienamente operativa. La legge 132/2025 ha designato l'Agenzia per la Cybersicurezza Nazionale come autorità con poteri ispettivi e sanzionatori, e l'Agenzia per l'Italia Digitale per notifica e accreditamento, mentre Banca d'Italia, CONSOB e IVASS mantengono la competenza per i sistemi usati in ambito finanziario e assicurativo. Un'ispezione, da qui in avanti, ha un interlocutore preciso con un nome e un numero di telefono. ## L'equivoco sull'Allegato III Qui sta l'equivoco che circola di più. Diversi articoli pubblicati prima del 24 luglio, quando il Digital Omnibus era ancora una bozza, elencavano il 2 agosto 2026 come la data in cui sarebbero scattati anche gli obblighi per i sistemi ad alto rischio dell'Allegato III: selezione del personale, credito, istruzione, servizi essenziali. Era vero quando è stato scritto. Il Regolamento (UE) 2026/1744, pubblicato in Gazzetta Ufficiale il 24 luglio ed entrato in vigore il 27, ha spostato quella scadenza al 2 dicembre 2027. Quegli articoli sono rimasti online, indicizzati, e circolano oggi come se descrivessero la situazione attuale. Il risultato pratico: se un sistema aziendale ricade nell'Allegato III, non violate nulla stamattina. Non è possibile sanzionare per un obbligo che non è ancora applicabile, ed è proprio questo il punto che il rumore di questi giorni non chiarisce abbastanza. Per i sistemi ad alto rischio incorporati in prodotti già regolamentati, l'Allegato I, la scadenza è ulteriore: 2 agosto 2028. ## Due obblighi restano dove erano Due obblighi non sono una novità di agosto, semplicemente restano fermi dove erano. I divieti dell'articolo 5, quelli su pratiche manipolative, punteggio sociale, riconoscimento delle emozioni sul lavoro, sono in vigore dal 2 febbraio 2025. Gli obblighi sui modelli di AI per finalità generali, GPAI, sono operativi dal 2 agosto 2025, insieme alla governance europea e alla designazione delle autorità nazionali. Chi non aveva ancora affrontato questi due fronti non ha una nuova scadenza da agosto, ne ha una scaduta. ## La mappa conta più della data La domanda giusta per un'azienda non è quale sia la data esatta, è cosa ha effettivamente in casa. Il censimento dei sistemi AI in uso o in acquisto, con una prima classificazione rispetto agli Allegati I e III, vale oggi quanto varrà a dicembre 2027: senza quella mappa, ogni scadenza normativa arriva come una sorpresa, indipendentemente da quando cade. Secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano, il 71% delle grandi imprese italiane ha progetti AI attivi, ma solo il 9% ha una governance strutturata. Il divario si allarga proprio in momenti come questo, quando le scadenze si moltiplicano e le notizie contraddittorie rendono difficile capire cosa fare per primo. Chi ha già una mappa dei propri sistemi legge il 2 agosto come una scadenza tra le altre. Chi non ce l'ha rischia di reagire alla notizia sbagliata, oppure di ignorare quella giusta. Il riferimento resta il testo consolidato: Regolamento (UE) 2024/1689 (AI Act) come modificato dal Regolamento (UE) 2026/1744, pubblicato in Gazzetta Ufficiale dell'Unione europea il 24 luglio 2026, insieme alla Legge 132/2025 per l'assetto italiano delle autorità competenti. Ogni altra fonte, comprese le più recenti, va verificata sulla data di pubblicazione prima di essere presa per buona. Le scadenze normative sono fatte per essere gestite, non per essere lette due volte con due significati diversi. --- # AI Rating in una telco: il gate sta nel commerciale URL: https://zerofive.ai/blog/strategia/ai-rating-telco-sistemi-commerciali Data: 2026-08-04 Abstract: Readiness e Delivery alte, Risk scoperta. La classificazione dei sistemi di vendita e il costo del doppio impianto AI Act e NIS2. **In sintesi.** Negli operatori telco il profilo di maturità AI è squilibrato verso l'alto su Readiness e Delivery, perché sono aziende tecnologiche con dati propri e cicli di rilascio maturi. Il gate che blocca la classe sta su Risk, e più precisamente su un punto: i sistemi commerciali che nessuno ha classificato, a partire dalla valutazione creditizia dei clienti. È l'unico settore dove la dimensione tecnica non è il problema. Un operatore che si misura si aspetta un risultato alto, e spesso lo ottiene su tre dimensioni su quattro, con punteggi che in altri settori sarebbero irraggiungibili. Il salto di classe, però, si gioca tutto sulla quarta, e nessun vantaggio tecnico lo compensa. ## Le quattro dimensioni in una telco **Readiness** misura preparazione, dati, competenze, infrastrutture. È alta: gli operatori possiedono i propri dati, hanno infrastrutture proprie e competenze tecniche interne. È la condizione opposta a quella di club sportivi e molte compagnie assicurative. **Delivery** misura la capacità di portare in produzione e mantenere. Anche questa è alta, perché il ciclo di rilascio software esiste e funziona su scala. Il limite è che quel ciclo copre i sistemi sviluppati internamente e non quelli attivati dentro piattaforme di vendor. **Risk** misura governance, compliance ed etica. Qui si concentra tutto. L'impianto NIS2 esiste, è maturo e copre bene la resilienza operativa, mentre la governance dei sistemi AI letta in chiave di effetto sulla persona è quasi sempre scoperta, perché nessuno l'ha mai chiesta prima e la funzione che dovrebbe presidiarla non è la stessa. **Confidence** misura commitment della direzione e fiducia degli utenti. È generalmente buona in azienda e più debole sulla rete indiretta, che usa strumenti senza sapere cosa facciano. ## Il gate: i sistemi commerciali mai classificati Il vincolo ricorrente non sta dove ci si aspetta. Gli operatori governano bene i sistemi di rete, perché li considerano critici, e governano male i sistemi commerciali, perché li considerano strumenti di vendita. Il caso emblematico è la valutazione del merito creditizio associata alla rateizzazione dei dispositivi. Nasce come regola commerciale, spesso implementata dentro un CRM, e ricade in Allegato III. Finché non viene classificata come sistema ad alto rischio, la dimensione Risk resta sotto soglia, e poiché i gate non sono compensabili la classe scende al livello del vincolo anche con Readiness e Delivery eccellenti. Il secondo punto scoperto riguarda le funzionalità AI attivate dentro piattaforme già in uso, dove l'operatore è deployer senza averlo deciso e spesso senza saperlo. ## Quando i due impianti divergono C'è un rilievo che emerge solo negli operatori maturi ed è costoso. Un'azienda che ha costruito la documentazione NIS2 e poi ha costruito separatamente quella AI Act sugli stessi sistemi ha due impianti che divergono. Sul rating questo non aiuta come sembrerebbe, perché l'evidenza che conta è quella coerente. Due documenti che descrivono lo stesso sistema in modo diverso indeboliscono entrambi, e in verifica la domanda diventa quale dei due riflette la realtà. La classe migliora quando gli impianti si coordinano, non quando si moltiplicano. ## Cosa significa una classe, in pratica | Classe | Situazione tipica in una telco | Cosa è ragionevole fare | |---|---|---| | D | Sistemi AI attivi in piattaforme di vendor, nessuna mappatura | Costruire l'inventario includendo le funzionalità attivate | | C | Rete governata, commerciale non classificato | Classificare i processi commerciali, a partire dal credito | | B | Classificazione completa, coordinamento con NIS2 avviato | Completare le evidenze sui sistemi in Allegato III | | A | Sistema maturo verificato su tutte le dimensioni | Riservata alle valutazioni verificate, non alle autovalutazioni | Il passaggio da C a B in un operatore è quasi sempre un lavoro di classificazione e di coordinamento documentale, non di tecnologia. È anche il motivo per cui viene rimandato: non produce nulla di visibile. ## Perché misurare prima del prossimo ciclo di investimento Gli operatori pianificano gli investimenti su cicli lunghi e su budget importanti. Una valutazione fatta prima di quel ciclo permette di includere nei capitolati i requisiti di documentazione e accesso ai log verso i vendor, che è il momento in cui si ha la leva. Dopo la firma cambia tutto. Ottenere dal fornitore la documentazione tecnica di un modello, i log o la garanzia di preavviso su un aggiornamento costa molto di più, richiede una rinegoziazione che nessuno vuole aprire, e in diversi casi semplicemente non è possibile perché il fornitore non li produce. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), costruito includendo le funzionalità attivate dentro piattaforme esistenti e i processi commerciali con effetti sul cliente. Il modello completo, con le quattro dimensioni e la logica dei gate, è nella pagina [AI Rating](/servizi/ai-rating). Il quadro normativo del settore è nella pagina [AI governance per operatori di telecomunicazioni](/settori/telco). Per una valutazione della posizione del tuo operatore puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # PoC di agenti AI: come impostarle perché arrivino in produzione URL: https://zerofive.ai/blog/strategia/poc-agenti-ai-come-farle-funzionare Data: 2026-08-02 Abstract: Il 40% dei progetti agentici verrà cancellato entro il 2027. Come impostare una PoC di agenti AI con criteri di successo, costi realistici e conformità AI Act. Un agente che prenota, un agente che risponde ai clienti, un agente che riconcilia fatture. Nei board di cui faccio parte la domanda è sempre la stessa: facciamo una PoC? La risposta giusta esiste, ma dipende da come la PoC viene impostata, da cosa deve dimostrare e da chi decide cosa succede dopo. Perché il problema non è partire. Il 71% delle grandi imprese italiane ha progetti AI attivi, solo il 9% ha una governance strutturata (Osservatorio Artificial Intelligence, Politecnico di Milano, febbraio 2026). Le PoC si fanno, tante. Poi restano lì, in quel limbo che chiamiamo pilot purgatory: dimostrazioni che hanno funzionato una volta, davanti alle persone giuste, e che nessuno ha mai portato oltre. ## Il 40% dei progetti agentici verrà cancellato entro il 2027 La stima è di Gartner, giugno 2025: oltre il 40% dei progetti di agentic AI verrà cancellato entro fine 2027 per costi crescenti, valore di business poco chiaro o controlli di rischio inadeguati. Anushree Verma, analista di Gartner, dichiara che la maggior parte dei progetti agentici oggi sono esperimenti o proof of concept guidati dall'hype, spesso applicati male. Il MIT, con il progetto NANDA, era arrivato a una conclusione ancora più dura nell'estate 2025: il 95% dei pilot di AI generativa non produce impatto misurabile sul conto economico. Ecco, questi numeri raccontano una cosa precisa, che vediamo ogni settimana nei nostri assessment: le PoC falliscono quando nascono per impressionare qualcuno invece che per informare una decisione. E una PoC che non serve a decidere è un costo travestito da innovazione. ## Una PoC senza criteri definiti a monte è una demo La differenza tra una demo e una proof of concept sta tutta in un documento che quasi nessuno scrive: i criteri di successo, fissati prima di scrivere una riga di codice. Per un agente AI i criteri non possono limitarsi a "funziona". Un agente prende decisioni in autonomia, tocca sistemi reali, produce output che qualcuno userà, e quindi va misurato su dimensioni che una demo non mostra mai: il tasso di completamento del task su casi reali e non su esempi selezionati, il comportamento sugli edge case, il costo per esecuzione (token, chiamate API, tempo di supervisione umana), la frequenza con cui serve l'intervento di una persona, cosa succede quando l'agente sbaglia. Nel nostro modello lo formalizziamo così: la PoC parte con dati e contesto reali, con criteri di successo definiti a monte, e produce tre output possibili, scala, correggi, ferma. Il prototipo non è un fine, è uno strumento decisionale. Se alla fine della PoC non sapete cosa costerebbe portarla in produzione e quali condizioni la renderebbero sostenibile, la PoC vi ha regalato applausi e nessuna risposta. C'è anche un test preliminare che consigliamo sempre, perché filtra metà delle richieste: questo caso d'uso ha davvero bisogno di un agente? Molti processi si risolvono con automazione tradizionale o con un assistente ben integrato, a costi e rischi molto più bassi. Gartner segnala che gran parte dei casi d'uso presentati come agentici non richiedono affatto implementazioni agentiche. Scegliere l'agente quando basta un workflow è il primo errore economico, e si commette prima ancora di iniziare. ## L'errore economico: la PoC che diventa produzione per inerzia La scena tipica: la PoC piace, lo sponsor vuole andare veloce, e il team porta in produzione la stessa architettura della PoC. Nessuno ha stimato i costi a regime, nessuno ha verificato l'integrazione con ERP e CRM, nessuno ha previsto il monitoraggio. Sei mesi dopo i costi operativi sono il doppio o il triplo delle stime, perché una PoC ottimizza per la velocità di dimostrazione, non per l'efficienza di esercizio. Un agente che in demo costa pochi centesimi a esecuzione, in produzione, con retry, contesto ampio, orchestrazione di più modelli e supervisione umana, cambia ordine di grandezza. La PoC ben fatta contiene già l'antidoto: tra i criteri di successo c'è la stima realistica di costi e complessità di produzione. Se la PoC dimostra che il caso d'uso funziona ma costerebbe più del processo che sostituisce, è una PoC riuscita, con esito negativo. Ha evitato un investimento sbagliato, che è esattamente il suo lavoro. La nostra proposta di valore include il dire "stop", quando i numeri lo dicono. ## L'errore normativo: la PoC come zona franca Qui vediamo l'ingenuità più diffusa. "È solo una PoC" viene usato come esenzione implicita: dati reali dei clienti dentro un prototipo, nessun registro, nessuna valutazione del rischio, fornitori scelti senza verifiche. Una PoC che usa dati personali reali è un trattamento a tutti gli effetti, e il GDPR non prevede sconti per gli esperimenti. E con l'AI Act la classificazione del rischio va fatta all'inizio, non alla fine: se il caso d'uso che state prototipando rientra tra i sistemi ad alto rischio (selezione del personale, credito, accesso a servizi essenziali), le scelte fatte in PoC, dai dataset alla supervisione umana, determinano quanto costerà la conformità dopo. Il calendario aggiornato dal regolamento 2026/1744 sposta gli obblighi per i sistemi ad alto rischio dell'Allegato III al 2 dicembre 2027, con i nuovi divieti in vigore dal 2 dicembre 2026: finestre di decisione, per chi sta prototipando adesso, più che scadenze amministrative. Per gli agenti il tema si amplifica, perché un agente agisce: scrive su sistemi reali e prende micro-decisioni per conto vostro. La supervisione umana richiesta dalla normativa per i casi rilevanti va progettata nel prototipo, insieme a log delle azioni e possibilità di intervento, perché aggiungerla dopo significa riprogettare. Nel nostro AI Rating questa è la dimensione Risk, e contiene quelli che chiamiamo gate critici: parametri non compensabili, dove un'eccellenza tecnica altrove non ripaga una carenza su compliance o etica. Un'azienda con delivery da classe A e un registro dei sistemi AI inesistente resta in classe C, e la logica vale identica per le PoC. ## Prima il rating, poi il prototipo Tutto questo spiega la sequenza del nostro metodo, che a qualcuno all'inizio sembra lenta e poi si rivela il modo più rapido per arrivare in produzione davvero. Prima si misura: l'AI Rating fotografa la maturità su quattro dimensioni (Readiness, Delivery, Risk, Confidence) e dice se l'organizzazione ha le condizioni per portare un agente oltre il prototipo. Una PoC di agente in un'azienda senza dati accessibili, senza ownership chiara e senza pratiche di monitoraggio produrrà una bella demo e nient'altro, e saperlo prima costa una frazione di quanto costa scoprirlo dopo. Poi si decide: quale caso d'uso, con quali criteri di successo, con quale soglia di stop. Poi si valida, ed è il mestiere di protot.ai, la nostra unit di fast prototyping: prototipi in una-tre settimane, MVP in quattro-otto, su dati reali, con l'esplicito mandato di mettere alla prova l'ipotesi prima della produzione. protot.ai prova, ZeroFive costruisce in produzione e governa: la separazione è voluta, perché chi valida non deve avere interesse a vendere l'implementazione, altrimenti ogni PoC finisce miracolosamente per "funzionare". Nei 34 e più assessment e progetti che abbiamo condotto, la correlazione più netta è questa: le PoC che arrivano in produzione sono quelle nate dentro un percorso di decisione, con uno sponsor executive che ha già stabilito cosa farà con l'esito, qualunque esso sia. La domanda da farsi, prima di stanziare il budget per la prossima PoC di agenti, viene molto prima della scelta del modello o del vendor: se il prototipo funzionasse, sareste in grado di portarlo in produzione e di governarlo? Se la risposta è incerta, la PoC da fare per prima è quella sulla vostra organizzazione. --- # Il Digital Omnibus è legge: l'orologio della compliance riparte URL: https://zerofive.ai/blog/compliance/digital-omnibus-regolamento-2026-1744 Data: 2026-07-31 Abstract: Il Regolamento (UE) 2026/1744 rinvia gli obblighi high-risk al 2027 e 2028, amplia i divieti e accentra la vigilanza. Come usare i sedici mesi. Nei tavoli con i board a cui lavoriamo, la primavera del 2026 è stata dominata da una data: 2 agosto. Piani di adeguamento compressi, fornitori interrogati sulla classificazione dei sistemi, budget di compliance approvati in fretta, con la sensazione diffusa che il tempo non bastasse. Il 24 luglio la Gazzetta Ufficiale dell'Unione europea ha cambiato quel calendario. Il Regolamento (UE) 2026/1744, il Digital Omnibus sull'AI, è entrato in vigore il 27 luglio 2026. Modifica l'AI Act (Regolamento 2024/1689), il Regolamento Macchine e il Regolamento sull'aviazione civile, senza toccare l'architettura basata sul rischio. Le date si spostano, i divieti si ampliano, la vigilanza si accentra. Chi legge questo intervento come un rinvio ha capito metà della notizia. ## Le date si muovono, l'impianto no Il cuore della modifica sta nella riscrittura dell'articolo 113 dell'AI Act. Gli obblighi per i sistemi ad alto rischio dell'Allegato III, quelli autonomi usati in ambiti come selezione del personale, credito, istruzione, servizi essenziali, slittano dal 2 agosto 2026 al 2 dicembre 2027. Per i sistemi ad alto rischio incorporati in prodotti già regolamentati, l'Allegato I, la nuova scadenza è il 2 agosto 2028. Restano invariati i divieti in vigore dal febbraio 2025, il regime sui modelli di AI per finalità generali, il quadro sanzionatorio e la data di applicazione generale del 2 agosto 2026. Gli obblighi di trasparenza dell'articolo 50, quelli sulla marcatura dei contenuti generati, guadagnano un periodo di grazia fino al 2 dicembre 2026 per i sistemi già sul mercato. Ed entra qualcosa di nuovo, che nei commenti di questi giorni passa in secondo piano: dal 2 dicembre 2026 saranno vietati i sistemi progettati per generare materiale intimo non consensuale o materiale di abuso su minori, incluse le app di nudificazione. Il legislatore alleggerisce il calendario e, nello stesso atto, alza l'asticella su ciò che considera inaccettabile. ## Sedici mesi in più, per fare cosa La lettura più comoda del rinvio è anche la più pericolosa: abbiamo tempo, se ne riparla nel 2027. È la stessa logica che ha prodotto i numeri che conosciamo. Secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano (febbraio 2026), il 71% delle grandi imprese italiane ha progetti AI attivi, ma solo il 9% ha una governance strutturata. Il divario tra le due percentuali non nasce dalla mancanza di tempo, nasce dalla mancanza di decisioni. Chi ad agosto 2026 sarebbe arrivato impreparato, a dicembre 2027 arriverà impreparato uguale, se usa la proroga per congelare il tema. Chi invece tratta i sedici mesi come una finestra di lavoro può fare ciò che la scadenza ravvicinata rendeva quasi impossibile: mappare i sistemi in uso, capire quali ricadranno nell'Allegato III, misurare la propria maturità reale su dati e competenze, e solo dopo costruire il piano di adeguamento. La compliance fatta sotto scadenza produce documenti, la governance costruita con metodo produce capacità. ## L'alfabetizzazione da obbligo a scelta C'è un secondo passaggio del Regolamento che merita più attenzione di quanta ne stia ricevendo. L'obbligo di alfabetizzazione AI dell'articolo 4 viene attenuato: dalla formulazione prescrittiva si passa a misure necessarie per sviluppare l'alfabetizzazione, con un margine di interpretazione più ampio lasciato alle organizzazioni. Nella nostra esperienza il bisogno resta intero, cambia chi se ne assume la responsabilità. Quando la formazione era un adempimento, molte aziende la trattavano come tale: un corso registrato, un attestato, una casella spuntata. Ora che il vincolo formale si allenta, la differenza la farà chi forma le persone perché gli serve, perché senza un linguaggio comune tra business, IT e risk i progetti si bloccano ai pilot, e i pilot bloccati sono esattamente ciò che il 71% delle imprese ha già in casa. La formazione decisa per convinzione vale più di quella subita per obbligo, e da settembre si vedrà chi appartiene a quale gruppo. ## La vigilanza si accentra Il Regolamento attribuisce all'AI Office competenze di controllo più chiare e centralizzate sui sistemi che integrano modelli per finalità generali e su quelli collegati alle grandi piattaforme online. Nello stesso tempo la scadenza per i sandbox regolatori nazionali slitta al 2 agosto 2027, e vengono introdotte misure di semplificazione per PMI e piccole imprese a media capitalizzazione. Il disegno che emerge, letto per intero, descrive un enforcement che si sposta verso Bruxelles mentre il livello nazionale prende tempo. Per un'azienda italiana significa una cosa concreta: l'interlocutore che verificherà i sistemi più rilevanti sarà europeo, con poteri estesi, e la qualità della documentazione interna, registri, valutazioni d'impatto, log delle decisioni, peserà più delle interpretazioni locali. Prepararsi a un controllore centralizzato richiede tracciabilità, e la tracciabilità non si improvvisa a ridosso della scadenza. ## Da qui a dicembre 2027 Il calendario ragionevole per un board, visto dai tavoli dove operiamo, ha tre tappe. Entro fine 2026: censimento dei sistemi AI in uso e in acquisto, con una prima classificazione rispetto agli Allegati I e III, perché la proroga vale solo per chi sa cosa ha. Nel 2027: misurazione della maturità organizzativa, gap analysis su governance e processi, decisioni esplicite su cosa scalare e cosa fermare, e su cosa merita un prototipo prima dell'investimento pieno. A ridosso della scadenza: l'adeguamento formale, che a quel punto è la parte facile. Il riferimento resta il testo pubblicato: Regolamento (UE) 2026/1744, Gazzetta Ufficiale dell'Unione europea, Serie L del 24 luglio 2026, insieme all'AI Act consolidato e alla ISO/IEC 42001 per chi vuole un sistema di gestione strutturato. Tutto il resto, commenti inclusi, va verificato contro la fonte. L'Unione ha resettato l'orologio della conformità senza spegnerlo. La domanda che conta adesso non riguarda Bruxelles, riguarda le imprese: quante useranno questi sedici mesi per decidere, e quante li useranno soltanto per aspettare? --- # AI adoption in una telco: la rete è facile, il commerciale no URL: https://zerofive.ai/blog/strategia/ai-adoption-telco-rete-commerciale Data: 2026-07-30 Abstract: L'area con più valore ha meno attrito regolamentare. Il coordinamento con NIS2, la valutazione creditizia nascosta e il pilota sui grandi volumi. **In sintesi.** Gli operatori telco hanno una condizione rara: l'area con più valore, l'ottimizzazione della rete, è anche quella con meno attrito regolamentare, perché resta a rischio minimo sotto l'AI Act. È il contrario di quello che accade in banca e in assicurazione. Il vincolo qui riguarda la sovrapposizione con NIS2, che va coordinata invece di duplicata, più che la norma in sé. Il caso d'uso da trattare con più cautela è quello commerciale, dove si nasconde una valutazione creditizia. Negli operatori la maturità tecnica è alta, e la domanda riguarda l'impatto più che la fattibilità. Questo sposta il problema su un terreno diverso da quello di altri settori, dove la discussione si ferma prima, su cosa sia possibile costruire con i dati disponibili. ## Due aree, due logiche Sulla rete il valore si misura in costi operativi, guasti evitati e capacità recuperata. Sono numeri che l'operatore già raccoglie ogni giorno per ragioni sue, il che rende il business case verificabile in mesi invece che in anni e toglie di mezzo la discussione su come si misura. Questo conta. Sul commerciale il valore si misura in churn evitato, conversione e margine per cliente. Anche questi sono numeri disponibili, con una complicazione: attribuire un cambiamento di churn a un modello richiede un gruppo di controllo, e in una telco tenerlo significa rinunciare a trattare una parte della base clienti. La differenza pratica è che sulla rete si può partire senza discussioni normative, mentre sul commerciale serve prima capire in quale classe di rischio si sta lavorando. ## La mappa dei casi candidati | Caso d'uso | Valore | Attrito regolamentare | Adatto come primo | |---|---|---|---| | Manutenzione predittiva sulla rete | Alto e misurabile | Basso, restano obblighi NIS2 | Sì | | Ottimizzazione della capacità | Alto | Basso | Sì | | Assistenza al servizio clienti | Medio-alto, in volumi | Basso, articolo 50 | Sì | | Modelli di churn e propensione | Alto | Medio, profilazione GDPR | Come secondo passo | | Rilevazione frodi sul traffico | Alto | Medio, dipende dall'effetto sul cliente | Come secondo passo | | Valutazione creditizia per rateizzazione | Alto | Alto, Allegato III | No, non come primo | L'ultima riga è quella che negli operatori resta invisibile più a lungo, perché quel processo nasce nella funzione commerciale e viene trattato come una regola di vendita, non come un sistema di scoring. ## Coordinare con NIS2 invece di duplicare Un operatore telco produce già documentazione su gestione del rischio, resilienza e fornitori critici. Molti dei requisiti che l'AI Act chiede sui sistemi rilevanti si sovrappongono a quel lavoro. Costruire un secondo impianto separato significa pagare due volte per lo stesso sistema, con il risultato che le due documentazioni divergono nel tempo e nessuna delle due è affidabile. Il coordinamento è un lavoro di mappatura dei requisiti, non di riscrittura: si stabilisce quali evidenze soddisfano entrambe le norme, quali servono a una sola, e chi le mantiene. È anche il modo per non far ricadere tutto sulla funzione sicurezza, che in molti operatori è già il collo di bottiglia. ## Il pilota quando i volumi sono enormi La tentazione ricorrente è saltare il pilota, perché i volumi sono tali che un test su un perimetro ristretto sembra poco significativo, e la pressione a scalare subito è forte. Conviene resistere per una ragione pratica: su volumi grandi un errore sistematico produce danni per settimane prima che qualcuno se ne accorga, e il costo del recupero supera quello del test evitato. Il perimetro giusto per un pilota in una telco è una regione, un segmento di clientela o una tipologia di impianto, con baseline misurata sullo stesso perimetro e criteri di accettazione fissati prima. Il piano di uscita, qui, riguarda soprattutto l'integrazione con i sistemi di billing e di gestione della rete, che è la parte che allunga i tempi più di qualunque questione di modello. ## Quando il modello arriva dal vendor Gran parte dei sistemi AI in una telco arriva dentro piattaforme di vendor, e non viene sviluppata internamente. Questo cambia la domanda: non è cosa vogliamo costruire, è cosa stiamo già usando e chi risponde di cosa. La definizione del ruolo contrattuale va fatta sistema per sistema, prima di estendere l'uso e non dopo, perché la scelta tra provider e deployer determina quali obblighi ricadono sull'operatore e quali restano al fornitore che ha costruito il modello. Non è una formalità. Un operatore che attiva una funzionalità AI dentro una piattaforma esistente si assume obblighi che nessuno ha valutato al momento dell'attivazione. ## Da dove partire La sequenza parte dall'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), che in una telco deve coprire anche le funzionalità attivate dentro piattaforme di vendor. I criteri generali di selezione sono in [AI adoption: come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso), il modello di costo in [budget di un progetto AI](/blog/strategia/budget-progetto-ai-pilota-produzione). Il quadro normativo del settore è nella pagina [AI governance per operatori di telecomunicazioni](/settori/telco). Per valutare quali casi d'uso hanno senso nel tuo operatore puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in una telco: il problema è la scala URL: https://zerofive.ai/blog/compliance/ai-literacy-telco-formazione-scala Data: 2026-07-28 Abstract: Migliaia di persone, molte non dipendenti. I pochi ruoli con evidenza individuale e cosa si riusa dall'impianto NIS2 già esistente. **In sintesi.** In una telco il problema della formazione AI è la scala: migliaia di persone tra call center, negozi e rete commerciale, gran parte delle quali non è alle dipendenze dell'operatore. La formazione uniforme che funziona su quei numeri copre l'obbligo di alfabetizzazione e non copre la clausola 7, che chiede competenza per ruolo. La soluzione non è formare tutti allo stesso modo, è distinguere i pochi ruoli che richiedono evidenza individuale dalla massa che richiede consapevolezza. Gli operatori telco hanno impianti formativi enormi e ben rodati, costruiti su compliance, sicurezza e prodotto. L'AI ci entra facilmente come modulo, e questo è insieme il vantaggio e il rischio: un modulo aggiunto a un sistema pensato per la scala non produce competenza specifica su nessun sistema. ## Il perimetro è più grande dell'organico La clausola 7.3 parla di persone che lavorano sotto il controllo dell'organizzazione, e in una telco quel perimetro comprende il call center in outsourcing, i negozi in franchising, gli agenti e i tecnici di installazione. Sono persone che usano ogni giorno strumenti di assistenza, preventivazione e diagnostica, e che nella maggior parte dei casi non compaiono in nessun piano formativo dell'operatore. Questa è la prima distanza da colmare, ed è un lavoro contrattuale. I requisiti di competenza vanno nei contratti di servizio con i partner, insieme all'obbligo di fornire evidenza. La seconda distanza riguarda il turnover. In un call center il ricambio annuo è alto, e un piano formativo con cadenza annuale copre una popolazione che nel frattempo è cambiata per metà. Serve un innesco legato all'ingresso della persona, non al calendario. ## I ruoli con evidenza individuale Sulla grande maggioranza della popolazione serve consapevolezza: cosa fa lo strumento, quando va verificato, a chi si segnala. Su tre gruppi l'evidenza deve essere nominale. **Chi opera su valutazione creditizia.** È il punto che sorprende in una telco. La rateizzazione dei dispositivi comporta una valutazione del merito creditizio del cliente, che ricade in Allegato III, e chi lavora su quel processo ha obblighi di competenza pieni. **Chi esercita sorveglianza umana su sistemi di rete critici.** Non per l'AI Act, dove quei sistemi restano a rischio basso, ma per NIS2, che sulla resilienza chiede competenza dimostrabile. **Chi approva l'adozione di una piattaforma.** In una telco le adozioni passano spesso da procurement, e chi firma deve sapere cosa sta approvando in termini di ruolo e obblighi. ## Cosa si riusa da NIS2 L'impianto costruito per NIS2 copre già una parte del lavoro, e vale la pena mapparlo prima di costruire. | Elemento | Esiste per NIS2 | Cosa manca per l'AI | |---|---|---| | Formazione su sicurezza e resilienza | Sì, strutturata | Estensione ai sistemi AI | | Tracciamento delle evidenze | Sì, per obbligo | Collegamento al ruolo e al sistema | | Gestione dei fornitori critici | Sì | Requisiti di competenza sull'AI nei contratti | | Cultura del rischio operativo | Sì | Traduzione sul rischio per la persona | | Verifica di efficacia | Esercitazioni | Casi pratici sui sistemi AI in uso | L'ultima riga è quella più semplice da colmare e più spesso ignorata. Le telco fanno esercitazioni su incidenti di sicurezza, e lo stesso formato applicato a un output anomalo di un sistema AI produce un'evidenza di efficacia che il questionario non dà. ## Il modulo che nessun fornitore può scrivere Come in ogni settore, la parte utile richiede informazioni che ha solo l'operatore: quali sistemi sono attivi su quali processi, quali casi limite sono già emersi in assistenza, a chi si segnala un comportamento anomalo e cosa succede dopo. In una telco questo si traduce in contenuti brevi e ripetibili, perché devono raggiungere migliaia di persone con turnover alto. Trenta minuti per sistema, aggiornati quando il sistema cambia, distribuiti sugli stessi canali già usati per il prodotto. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), che in una telco va costruito sapendo che molti sistemi sono arrivati dentro piattaforme di vendor di rete e non sono mai stati classificati. Da lì si costruisce la matrice, descritta in [la matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai), separando i pochi ruoli con evidenza individuale dalla popolazione ampia. I requisiti completi sono in [la clausola 7 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze). Il quadro normativo del settore è nella pagina [AI governance per operatori di telecomunicazioni](/settori/telco). L'approccio ai percorsi per ruolo è nella pagina [AI Training](/servizi/ai-training). Per valutare il piano del tuo operatore puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # Framework di AI adoption: guida pratica per portare l'AI in produzione URL: https://zerofive.ai/blog/strategia/framework-ai-adoption-guida-pratica-imprese Data: 2026-07-23 Abstract: Framework di AI adoption in 5 fasi: assessment, casi d'uso, piloti, scale-up, cambiamento. Con KPI, ruoli e roadmap 90-180 giorni per portare l'AI in produzione. ## Perché serve un framework di AI adoption La maggior parte dei progetti AI in azienda non fallisce nel modello: fallisce nell'adozione. Il pilota funziona in laboratorio, poi si ferma. Nessuno lo usa, nessuno lo mantiene, nessuno misura l'impatto. Dopo sei mesi resta una demo e un investimento a bilancio. Un **framework di AI adoption** è il metodo strutturato per passare dai proof of concept ai sistemi in produzione che generano valore misurabile. Non è un metodo di sviluppo software: è un metodo di **trasformazione operativa**, in cui la tecnologia è la parte più semplice. Nel 2026 il divario tra chi adotta bene e chi resta ai piloti è diventato strategico. Non è più questione di "fare AI": è questione di **quanti processi core** sono davvero potenziati dall'AI, con quale ROI, con quale livello di rischio residuo. ## Le cinque fasi di un framework di AI adoption Un framework operativo si articola su cinque fasi sequenziali, ognuna con criteri di uscita chiari. ### Fase 1: Assessment di maturità e ambizione Prima di adottare, capire il punto di partenza. Un assessment strutturato copre cinque dimensioni: **strategia** (visione AI, allineamento al business plan), **dati** (qualità, accessibilità, governance), **tecnologia** (piattaforme, MLOps, integrazioni), **persone** (competenze, cultura, leadership) e **governance** (policy, risk, compliance). L'output è una fotografia della maturità (tipicamente su scala 1-5) e un'ambizione target realistica. Saltare questa fase è il primo errore: si finanziano piloti che il resto dell'organizzazione non può assorbire. ### Fase 2: Portfolio dei casi d'uso Non si adotta "l'AI": si adottano casi d'uso specifici. Serve un **portfolio strutturato** che nasce da un doppio movimento: dall'alto (obiettivi strategici tradotti in ambiti di applicazione) e dal basso (idee dai team operativi). Ogni caso d'uso va valutato su tre assi: **valore atteso** (ricavi, costi, rischio, esperienza), **fattibilità** (dati, tecnologia, cambiamento richiesto), **rischio** (compliance, sicurezza, reputazione). La matrice valore/fattibilità produce la lista dei piloti prioritari, non un desiderata di 40 idee. ### Fase 3: Piloti con criteri di successo espliciti Un pilota AI non è "proviamo e vediamo". È un esperimento con **ipotesi, KPI, soglia di successo e criterio di kill** definiti prima di iniziare. Durata tipica: 8-12 settimane. Team ristretto ma multidisciplinare (business owner, data, engineering, change). Al termine, tre esiti possibili: **scala** (il pilota supera le soglie e diventa progetto di scale-up), **itera** (i risultati sono promettenti ma servono aggiustamenti), **stop** (il caso d'uso non funziona: si chiude senza colpevoli). La capacità di fermare i piloti falliti è un indicatore di maturità. ### Fase 4: Scale-up e industrializzazione Il passaggio da pilota a produzione è il momento in cui la maggior parte dei programmi si blocca. Servono elementi che il pilota non ha: **integrazione** nei sistemi core, **MLOps** per il ciclo di vita dei modelli, **osservabilità** (performance, drift, incidenti), **supporto** (SLA, runbook, escalation), **formazione** degli utenti finali, **change management** strutturato. Regola pratica: il costo dello scale-up è tipicamente **3-5 volte** il costo del pilota. Sottostimarlo genera i progetti "quasi in produzione" che restano tali per anni. ### Fase 5: Cambiamento organizzativo e cultura L'AI cambia i ruoli, i processi, il modo di decidere. Se il cambiamento organizzativo non è pianificato, l'adozione non avviene. Componenti chiave: **comunicazione** interna trasparente su cosa cambia e cosa no, **formazione** differenziata per livello (executive, manager, operativi), **incentivi** allineati (chi usa l'AI viene riconosciuto), **community** interne di pratica, **governance** dei prompt e dei tool ammessi. Il cambiamento culturale non è un modulo di training: è un lavoro continuo di 12-24 mesi. ## Ruoli e struttura di governance Un programma di AI adoption ha bisogno di ruoli chiari, non necessariamente di nuove funzioni. **Sponsor esecutivo**: un membro del comitato di direzione risponde del programma. Senza sponsorship visibile, i piloti non superano i confini funzionali. **AI Adoption Lead**: coordina il portfolio, i piloti e lo scale-up. Spesso interno alla funzione Innovation o Digital, con seniority sufficiente per interagire con i direttori di business. **Business Owner** per ciascun caso d'uso: è la persona che vive del risultato del caso d'uso, non un consulente. Senza business owner, il pilota non ha domanda. **Team tecnico**: data engineering, ML engineering, prompt engineering, integration. Interno, esterno o misto in base alla maturità. **Center of Excellence (CoE)**: modello frequente per aziende con più business unit. Il CoE fornisce metodologia, piattaforme, standard e supporto; le business unit sono responsabili dell'adozione. ## KPI di un programma di AI adoption Misurare l'adozione, non solo lo sviluppo. KPI utili: - **Copertura**: numero di processi core con almeno un caso d'uso AI in produzione - **Adozione**: percentuale di utenti target che usa attivamente ogni sistema (weekly active users) - **Time-to-production**: settimane medie tra approvazione del caso d'uso e go-live - **ROI per caso d'uso**: benefici realizzati vs investimento - **Tasso di piloti che scalano**: percentuale dei piloti che diventano produzione (benchmark realistico: 20-35%) - **Incidenti** e livello di rischio residuo - **Maturità AI** rivalutata annualmente sulle cinque dimensioni Il KPI più sottovalutato è il **weekly active users** dei sistemi in produzione: senza uso reale, il ROI è teorico. ## Roadmap 90-180 giorni Un framework di AI adoption diventa operativo in due trimestri. **Giorni 1 - 30: Fondamenta** - AI Rating iniziale (maturità e ambizione) - Nomina dello sponsor e dell'AI Adoption Lead - Kickoff del portfolio dei casi d'uso **Giorni 31 - 90: Primi piloti** - Selezione di 3-5 piloti prioritari con criteri di successo espliciti - Setup della governance leggera (comitato piloti, template, cadenza review) - Prima ondata di formazione per manager e power user **Giorni 91 - 180: Scale-up e istituzionalizzazione** - Piano di scale-up per i piloti che superano le soglie - Definizione del target operating model (CoE, business owner, ruoli) - Dashboard di programma (copertura, adozione, ROI, rischio) - Roadmap 12 mesi condivisa con il comitato di direzione ## Errori comuni da evitare **Iniziare dalla tecnologia.** La scelta della piattaforma prima dei casi d'uso produce investimenti mal calibrati. **Piloti senza business owner.** Un pilota "dell'IT" non genera adozione: genera una demo. **Confondere velocità e maturità.** Fare venti piloti in un anno senza portarne nessuno in produzione è peggio che farne tre e industrializzarne due. **Ignorare il costo di scale-up.** Il pilota è la parte economica; l'industrializzazione è dove serve il budget vero. **Sottovalutare il cambiamento.** L'AI cambia il lavoro: se le persone non sono accompagnate, l'adozione si ferma anche con la tecnologia giusta. **Governance solo di rischio.** Una governance che dice solo "no" blocca l'adozione. Serve una governance che abilita: casi d'uso a basso rischio approvati per default, controlli proporzionati, percorsi rapidi per l'innovazione. ## Come funziona in pratica I programmi di AI adoption che generano valore reale hanno tre caratteristiche. Sono **guidati dal business**, non dall'IT: i casi d'uso nascono dai problemi operativi, non dalle capacità tecniche. Sono **incrementali**: si costruisce sul funzionante, si evita il big bang. Sono **misurati con onestà**: si celebra ciò che funziona, si chiude ciò che non funziona, si condivide ciò che si impara. L'AI adoption non è un progetto: è una **capacità organizzativa** che si costruisce nel tempo. Chi la costruisce ora avrà un vantaggio strutturale nei prossimi cinque anni. ## Come possiamo aiutarti In ZeroFive accompagniamo le aziende dall'AI Rating al portfolio dei casi d'uso, dai piloti allo scale-up. Il metodo è modulare: iniziamo dal punto in cui sei e costruiamo la capacità di adozione sul tuo contesto, senza framework calati dall'alto. --- # Framework di AI governance: guida pratica per le imprese (ISO 42001 e EU AI Act) URL: https://zerofive.ai/blog/ai-governance/guida-framework-ai-governance-iso-42001-eu-ai-act Data: 2026-07-23 Abstract: Guida operativa per costruire un framework di AI governance: 7 componenti, allineamento a ISO 42001, EU AI Act, NIST AI RMF e roadmap in 90 giorni. ## Perché un framework di AI governance, adesso L'AI in azienda non fallisce quasi mai per la tecnologia: fallisce per assenza di governance. Chi decide quali casi d'uso vanno in produzione, chi risponde di un output sbagliato, dove vivono i dati, quali modelli sono ammessi, come si misurano rischio e valore: se non c'è una risposta scritta, la risposta la darà l'incidente. Un framework di AI governance è l'insieme di **politiche, ruoli, processi e controlli** che permette a un'organizzazione di adottare l'AI in modo sicuro, conforme e allineato alla strategia. Non è un documento: è un'infrastruttura decisionale. Nel 2026 il tema è passato da opzionale a obbligatorio. L'**EU AI Act** impone requisiti vincolanti per i sistemi ad alto rischio, la **ISO/IEC 42001** offre lo standard certificabile per un AI Management System, il **NIST AI Risk Management Framework** è diventato lo standard de facto negli Stati Uniti e nelle multinazionali. Chi non ha un framework oggi, domani non passa una due diligence. ## I sette componenti di un framework di AI governance Un framework operativo, non teorico, si articola su sette componenti. ### 1. Principi e policy Il punto di partenza è una **AI Policy** aziendale che stabilisce cosa è permesso, cosa è vietato, cosa richiede approvazione. Non un manifesto etico: regole applicabili. Copre uso di modelli generativi, trattamento di dati sensibili, casi d'uso proibiti (sorveglianza dei dipendenti, scoring sociale, decisioni completamente automatizzate su persone), obblighi di trasparenza verso clienti e dipendenti. ### 2. Inventario dei sistemi AI Non si governa ciò che non si conosce. Serve un **AI inventory** vivo: ogni sistema AI in uso o in sviluppo, con owner, finalità, dati trattati, modelli utilizzati, classificazione di rischio secondo EU AI Act (proibito, alto rischio, rischio limitato, rischio minimo), stato di conformità. È il primo artefatto che chiederà un auditor. ### 3. Risk management Per ogni sistema serve una **valutazione del rischio** strutturata: rischi tecnici (bias, allucinazioni, drift), rischi di sicurezza (prompt injection, data leakage), rischi legali (privacy, IP, responsabilità), rischi reputazionali. Il NIST AI RMF fornisce la tassonomia più utilizzata: Govern, Map, Measure, Manage. ### 4. Ruoli e responsabilità Un framework senza owner è carta. Ruoli minimi: **AI Governance Lead** (spesso il Chief AI Officer o il Chief Data Officer), **AI Ethics Committee** multidisciplinare, **AI Product Owner** per ciascun sistema, **Model Risk Officer** per i sistemi ad alto rischio. Il consiglio di amministrazione ha responsabilità di supervisione: in Italia la Legge 132/2025 la codifica esplicitamente. ### 5. Ciclo di vita dei modelli Governance significa controlli lungo tutto il **ciclo di vita**: approvazione dei casi d'uso, review del design, testing pre-deployment (bias, robustezza, sicurezza), monitoraggio in produzione (performance, drift, incidenti), retraining, dismissione. Ogni fase con evidenze documentate. ### 6. Gestione dei fornitori La maggior parte dei modelli è di terzi. Serve una **vendor governance** che copra: valutazione dei fornitori di modelli e piattaforme, clausole contrattuali (data usage, IP, indemnity), verifiche di conformità (SOC 2, ISO 27001, ISO 42001), gestione della supply chain AI. ### 7. Monitoraggio, audit e miglioramento continuo KPI di governance (copertura dell'inventario, tempo medio di approvazione, incidenti, findings di audit), **audit periodici**, reporting al board, aggiornamento delle policy in risposta a nuovi rischi e nuove regolamentazioni. ## Come si allineano gli standard I framework di riferimento non sono alternativi: sono complementari. **EU AI Act**: cosa devi fare per legge in Europa. Definisce le categorie di rischio, i requisiti per i sistemi ad alto rischio (gestione del rischio, qualità dei dati, documentazione, trasparenza, sorveglianza umana, accuratezza e robustezza), gli obblighi per i modelli GPAI, le sanzioni. **ISO/IEC 42001**: come lo dimostri. È il primo standard internazionale certificabile per un AI Management System. Fornisce la struttura organizzativa (contesto, leadership, pianificazione, supporto, operatività, valutazione, miglioramento) e i controlli specifici per l'AI. La certificazione è l'evidenza esterna che il framework funziona. **NIST AI RMF**: come lo operi. Framework volontario ma diffuso, particolarmente utile per la parte di risk management. Le quattro funzioni (Govern, Map, Measure, Manage) mappano bene sui processi operativi. **ISO/IEC 23894** (AI risk management) e **ISO/IEC 27001** (sicurezza delle informazioni) completano il quadro tecnico. L'approccio pragmatico: **ISO 42001 come architettura** del sistema di gestione, **EU AI Act come requisito** vincolante da incorporare nei controlli, **NIST AI RMF come metodologia** operativa per il risk management. ## Roadmap di implementazione in 90 giorni Un framework di AI governance non si costruisce in un anno. Le fondamenta si posano in un trimestre. **Giorni 1 - 30: Assessment e fondamenta** - AI inventory iniziale (workshop con IT, business, legal, security) - Gap analysis su ISO 42001 e EU AI Act - Bozza di AI Policy - Nomina dell'AI Governance Lead e composizione dell'Ethics Committee **Giorni 31 - 60: Framework e controlli** - AI Policy approvata dal board - Processo di classificazione dei casi d'uso (basso, medio, alto rischio) - Template di risk assessment e Data Protection Impact Assessment - Vendor governance: clausole standard e checklist di valutazione **Giorni 61 - 90: Operatività e reporting** - Primo ciclo di review dei sistemi ad alto rischio - Formazione obbligatoria per team AI e management - Dashboard di governance (KPI, incidenti, findings) - Piano di certificazione ISO 42001 (se rilevante) e roadmap di conformità EU AI Act ## Errori comuni da evitare **Confondere etica e governance.** L'AI Ethics Committee produce principi; la governance produce controlli. Servono entrambi, ma sono cose diverse. **Governance solo IT o solo Legal.** L'AI governance è multidisciplinare per definizione: business, IT, legal, security, HR, compliance. Un framework guidato da una sola funzione fallisce. **Documenti senza processi.** Una policy che nessuno legge e nessuno applica è peggio di nessuna policy: crea falsa sicurezza. **Sottovalutare i modelli GPAI.** ChatGPT, Claude, Copilot in azienda sono sistemi AI. Vanno inventariati, valutati, governati. La shadow AI è già dentro. **Rinviare aspettando chiarimenti normativi.** Il framework serve prima delle scadenze, non dopo. Chi arriva ad agosto 2026 senza fondamenta non recupera in tempo. ## Cosa fa la differenza I framework che funzionano hanno tre caratteristiche. Sono **proporzionati** al rischio effettivo: controlli pesanti sui sistemi ad alto impatto, snelli su quelli a basso impatto. Sono **integrati** nei processi esistenti (project management, procurement, security, risk) invece di essere una burocrazia parallela. Sono **misurati** con KPI che il board capisce: quanti sistemi in produzione, quanti incidenti, quanto valore generato, quanto rischio residuo. L'AI governance non rallenta l'innovazione: la rende possibile su scala. Senza framework, l'unica AI che entra in produzione è quella che nessuno vede, e quella è la più rischiosa. ## Come possiamo aiutarti In ZeroFive costruiamo framework di AI governance operativi, non documentali. Partiamo dall'AI Rating per fotografare la maturità attuale, disegniamo il framework su misura del contesto (settore, dimensione, rischio), lo implementiamo con il tuo team e lo colleghiamo agli obblighi di EU AI Act, ISO 42001 e Legge 132/2025. --- # AI Adoption: cosa è, come funziona e da dove si comincia URL: https://zerofive.ai/blog/strategia/ai-adoption-cosa-come-dove-cominciare Data: 2026-07-23 Abstract: Guida operativa all'AI adoption per le imprese: quattro capacità, i passi nell'ordine giusto e cosa fa la differenza tra chi governa l'AI e chi la subisce. Un'azienda attiva le licenze, forma qualche team, avvia due progetti pilota. Dopo un anno gli strumenti sono in uso, i pilota sono ancora pilota e nessuno sa dire quanto valore è entrato nei conti. È l'esito più frequente dei percorsi di adozione dell'AI, e nasce quasi sempre dallo stesso equivoco: si tratta l'adozione come un acquisto, mentre è un cambiamento nel modo in cui l'organizzazione decide. ## Cosa significa adottare l'AI Adottare l'AI significa portarla dentro i processi con cui l'azienda produce valore, e assumersi la responsabilità di ciò che produce. Non coincide con l'accesso agli strumenti: quello è disponibile a chiunque in un pomeriggio. Il confine è netto e si verifica con tre domande. L'azienda sa misurare cosa l'AI produce? Sa decidere dove quel contributo entra nei processi ufficiali? Sa dire chi risponde delle decisioni che ne derivano? Finché una di queste risposte manca, l'AI resta uno strumento in mano ai singoli, e i benefici restano personali invece di diventare aziendali. ## Come funziona il meccanismo L'adozione poggia su quattro capacità che vanno costruite insieme, ed è la stessa struttura su cui lavoriamo negli assessment. La readiness riguarda le fondamenta: dati utilizzabili, competenze reali, processi capaci di assorbire l'AI, una cultura che non la respinge. La delivery riguarda la capacità di portare un'iniziativa dal pilota alla produzione e di scalarla, ed è lo scoglio su cui si ferma la maggioranza dei progetti. La governance del rischio definisce chi decide, chi supervisiona e come si tiene traccia, in allineamento con Legge 132/2025 e AI Act. La confidence riguarda il commitment del vertice e la fiducia di chi lavora, perché un sistema che le persone non usano vale zero anche quando funziona. Queste quattro capacità si tengono a vicenda. Una readiness alta con una delivery debole produce sperimentazione infinita. Una delivery efficace senza governance produce sistemi in produzione di cui nessuno risponde, che è la posizione peggiore davanti a un'autorità o a un incidente. ## Lo squilibrio tra progetti e governance I numeri italiani descrivono uno squilibrio preciso. Il 71% delle grandi imprese ha avviato almeno un progetto di AI, in salita dal 59% del 2024, e appena il 9% dichiara una governance dell'AI pienamente integrata, secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano, che ha presentato la ricerca il 5 febbraio 2026. Otto lavoratori su dieci usano strumenti di AI non forniti dall'azienda: buona parte dell'adozione reale avviene già fuori dal perimetro aziendale, su dati che nessuno ha classificato. Sul fronte normativo il tempo si è ristretto. La Legge 132/2025 è in vigore dal 10 ottobre 2025 e rafforza il legame tra uso dell'AI e responsabilità d'impresa, mentre l'AI Act rende operativi obblighi di trasparenza e regime sanzionatorio dal 2 agosto 2026. Un'adozione non governata smette di essere un'occasione mancata e diventa esposizione. ## I passi, nell'ordine giusto Ogni fase abilita la successiva, e saltarne una si paga più avanti. Si parte dalla misura della maturità, l'AI Rating, che dice a che punto è davvero l'organizzazione sulle quattro capacità e dove sono i divari. Segue la mappatura delle opportunità, con i casi d'uso valutati per impatto, fattibilità e rischio, per capire dove l'AI conviene e dove no. Da lì si costruisce la strategia: priorità, roadmap e criteri chiari di go e no-go. Poi vengono le persone, con formazione per ruolo e un linguaggio comune tra business, IT e funzioni di controllo, perché l'adozione senza competenze diffuse si ferma al reparto che l'ha spinta. Prima di impegnare budget importanti si valida con un prototipo, per verificare valore e fattibilità sul campo. Solo alla fine si porta in produzione e si automatizza, su fondamenta che reggono. ## Come dovrebbero muoversi le aziende Servono uno sponsor esecutivo e un team operativo che lavorano insieme, perché l'AI è una decisione di business prima che una scelta tecnologica. Conviene partire da poche decisioni ad alto valore invece che da molti pilota scollegati, e definire fin dall'inizio come si misura il risultato, altrimenti a fine anno resta l'impressione al posto dell'evidenza. Serve un presidio esplicito degli strumenti già in uso in azienda, quelli che nessuno ha autorizzato. E serve accettare che alcune iniziative vadano fermate: dire di no a un progetto senza fondamenta protegge il budget e la credibilità di tutti gli altri. Il 9% che oggi ha una governance integrata parte dalla stessa tecnologia degli altri, ha deciso prima e su basi misurabili. La distanza tra i due gruppi si allarga con il tempo, perché l'integrazione nei processi non si copia in fretta. Se volete capire a che punto siete, il primo passo è una conversazione di trenta minuti: quanto è matura la vostra adozione, dove intervenire con maggiore impatto e con quale priorità. --- # Migliori tool di AI governance 2026: confronto tra Credo AI, OneTrust e IBM watsonx.governance URL: https://zerofive.ai/blog/ai-governance/migliori-tool-ai-governance-2026 Data: 2026-07-22 Abstract: Confronto tra Credo AI, OneTrust e IBM watsonx.governance: funzioni, punti di forza, costi indicativi e come scegliere il tool giusto dopo l'AI Rating. ## Perché scegliere un tool di AI governance nel 2026 Con l'entrata in vigore dell'EU AI Act e della Legge italiana 132/2025, la governance dell'AI non è più un esercizio da slide: serve un sistema operativo che tenga insieme inventario dei modelli, valutazione dei rischi, controlli sui fornitori, evidenze di conformità e monitoraggio in produzione. I tool di AI governance nascono proprio per questo: sostituire fogli di calcolo e wiki con una piattaforma unica di record. La scelta non è banale: le suite si somigliano nel marketing, ma differiscono molto per profondità tecnica, integrazione con l'MLOps, copertura normativa e modello di prezzo. Questa guida confronta tre piattaforme di riferimento (Credo AI, OneTrust AI Governance, IBM watsonx.governance) e le colloca dentro il framework strategico ZeroFive.AI, così da capire quando ha senso adottarle e quale scegliere dopo un AI Rating. ## Cosa fa (davvero) un tool di AI governance Una piattaforma di AI governance matura copre almeno cinque aree: 1. **Model & use case inventory**: registro centralizzato di sistemi AI, modelli, dataset, proprietari, versioni e stato del ciclo di vita. 2. **Risk assessment**: classificazione del rischio (EU AI Act, NIST AI RMF, ISO/IEC 42001) con questionari, workflow di approvazione e audit trail. 3. **Policy & controls**: catalogo di policy interne (bias, privacy, sicurezza, uso accettabile) collegate a controlli tecnici e organizzativi. 4. **Evidence & reporting**: raccolta automatica di evidenze (test di bias, robustezza, drift, spiegabilità) e generazione di report per audit, CdA e autorità. 5. **Monitoring in produzione**: osservabilità di modelli e agenti (performance, drift, incidenti, feedback umano) con alert e log immutabili. Un tool che copre solo l'inventario o solo il monitoring non è una piattaforma di governance: è un pezzo. Il valore nasce dall'integrazione. ## Il confronto: Credo AI vs OneTrust vs IBM watsonx.governance ### Credo AI **Focus**: governance responsabile end-to-end, con forte accento su policy packs pronti (EU AI Act, NIST, NYC Local Law 144) e workflow multi-stakeholder. **Punti di forza** - Libreria estesa di policy e assessment mappati ai principali standard. - Buona esperienza per team legal, risk e compliance grazie a UI orientate a workflow. - Integrazioni native con Hugging Face, Databricks, AWS SageMaker, Azure ML. - Reporting maturo per audit e board. **Limiti** - Copertura tecnica su MLOps più profonda sui vendor cloud principali; ambienti on-premise custom richiedono lavoro di integrazione. - Prezzo enterprise: adatto a organizzazioni con portafoglio AI già consistente. **Quando ha senso**: aziende con molteplici casi d'uso in produzione, obbligo di rendicontazione verso board o autorità, esigenza di allineamento a EU AI Act e ISO 42001. ### OneTrust AI Governance **Focus**: estensione del modulo AI dentro la suite più ampia OneTrust (Privacy, GRC, Third-Party Risk). **Punti di forza** - Integrazione nativa con privacy, DPIA, third-party risk e ROPA: ideale per chi già usa OneTrust. - Assessment AI collegati al registro dei trattamenti e alle valutazioni di impatto privacy. - Copertura di rischi lungo la supply chain di fornitori AI. - Modello di dati e workflow familiari a team DPO e legal. **Limiti** - Profondità tecnica su MLOps inferiore rispetto a Credo AI o watsonx.governance. - Il valore massimo si ottiene dentro l'ecosistema OneTrust: standalone è meno competitivo. **Quando ha senso**: organizzazioni che già hanno OneTrust per GDPR o GRC e vogliono aggiungere l'AI al perimetro esistente senza introdurre un nuovo silos. ### IBM watsonx.governance **Focus**: governance tecnica dei modelli integrata nella piattaforma dati/AI di IBM, con lineage e monitoring nativi. **Punti di forza** - Fact sheets automatiche generate dal ciclo di vita del modello (training, validazione, deploy). - Monitoraggio in produzione (drift, bias, qualità) integrato con watsonx.ai e OpenPages. - Forte su settori regolati (banking, insurance, healthcare) grazie all'ecosistema IBM. - Buona copertura di modelli open-source e proprietari, inclusi LLM. **Limiti** - Massima efficacia dentro lo stack IBM (watsonx.ai, OpenPages, Cloud Pak for Data). - Curva di adozione più ripida per team non IBM-centrici. **Quando ha senso**: aziende con stack dati/AI IBM, forte esigenza di lineage tecnico, settori altamente regolati che devono dimostrare governance auditable a livello di modello. ## Tabella di sintesi | Criterio | Credo AI | OneTrust AI Governance | IBM watsonx.governance | |---|---|---|---| | Approccio prevalente | Policy & workflow | GRC & privacy | MLOps & lineage | | Copertura EU AI Act | Alta | Alta | Alta | | Integrazione MLOps | Buona (multi-cloud) | Media | Alta (stack IBM) | | Ideale per | Risk, compliance, board | DPO, legal, GRC | Data & AI platform team | | Time-to-value tipico | 2, 4 mesi | 1, 3 mesi (se OneTrust già in casa) | 3, 6 mesi | | Modello di prezzo | Enterprise, per use case | Modulare, per suite | Enterprise, per piattaforma | *I tempi sono indicativi e dipendono da maturità AI, numero di casi d'uso e livello di integrazione richiesto.* ## Come scegliere: la logica ZeroFive.AI Un tool di AI governance non è una scelta di prodotto: è una decisione strategica che va fatta dopo aver capito **dove sei** e **dove vuoi arrivare**. Il framework ZeroFive.AI parte da qui: 1. **AI Rating**: assessment di maturità 1, 5 su strategia, governance, dati, tecnologia e persone. Restituisce il punto di partenza reale e i gap prioritari. 2. **Definizione del target operating model**: chi fa cosa tra business, IT, data, legal e risk; quali comitati, quali policy, quali KPI. 3. **Selezione del tool**: solo a questo punto ha senso valutare le piattaforme, perché conosci portafoglio casi d'uso, standard di riferimento, stack tecnologico e vincoli di budget. 4. **Adozione guidata**: implementazione incrementale (prima l'inventario, poi assessment, poi monitoring), con quick win misurabili. Senza questi passaggi, anche il miglior tool diventa un altro sistema sotto-utilizzato. Con questi passaggi, il tool diventa il sistema nervoso della tua AI governance. ## Domande frequenti **Serve un tool anche per PMI?** Non subito. Sotto i 3, 5 casi d'uso in produzione, un registro strutturato e policy scritte bene bastano. Il tool diventa necessario quando la complessità supera la capacità di gestione manuale. **Un tool sostituisce il framework?** No. Il tool esegue il framework: se il framework non c'è, la piattaforma amplifica il caos invece di risolverlo. **Meglio best-of-breed o suite integrata?** Dipende dallo stack esistente. Se hai già OneTrust o watsonx, l'estensione naturale vince. Se parti da zero e l'AI è centrale, best-of-breed come Credo AI dà più profondità. ## Prossimo passo Prima di scegliere un tool, misura la tua maturità con l'**AI Rating** di ZeroFive.AI: in due settimane ottieni una fotografia oggettiva e una roadmap di governance su misura, che diventa il capitolato per la selezione della piattaforma. --- # Articolo 50 AI Act: trasparenza obbligatoria dal 2 agosto URL: https://zerofive.ai/blog/compliance/articolo-50-ai-act-trasparenza Data: 2026-07-21 Abstract: Art. 50 AI Act: chi deve dichiarare cosa, quando e come, dal 2 agosto 2026. Obblighi per chatbot, deepfake e contenuti generati, con checklist operativa. Il 20 luglio 2026 la Commissione europea ha pubblicato le linee guida sull'articolo 50 dell'AI Act, la norma che disciplina la trasparenza dei sistemi di intelligenza artificiale. Meno di due settimane dopo, il 2 agosto, quegli obblighi diventano applicabili a chiunque immetta sul mercato o metta in servizio nell'Unione un sistema che interagisce con le persone o genera contenuti sintetici. Le linee guida sono un documento non vincolante, l'interpretazione autentica resterà alla Corte di giustizia, eppure fissano una direzione difficile da equivocare. La trasparenza appartiene all'architettura del sistema e all'intera catena che produce e distribuisce il contenuto. Un'etichetta aggiunta a fine corsa arriva tardi. Nascondere nei termini d'uso che «il servizio utilizza l'AI» non basta, e le linee guida lo precisano: una dichiarazione contenuta solo nelle condizioni contrattuali, in un URL o nella documentazione tecnica non soddisfa l'obbligo. ## Chi marca e chi dichiara L'articolo 50 distribuisce quattro obblighi tra due figure. Il provider, chi sviluppa il sistema e lo immette sul mercato con il proprio nome, deve progettare i sistemi interattivi in modo che la persona sappia di parlare con un'AI (paragrafo 1) e marcare in formato leggibile dalle macchine i contenuti sintetici che il sistema genera o manipola (paragrafo 2). Il deployer, chi usa il sistema sotto la propria autorità per fini professionali, deve informare chi è esposto a sistemi di riconoscimento delle emozioni o di categorizzazione biometrica (paragrafo 3) e dichiarare in modo percepibile i deep fake e i testi di interesse pubblico prodotti o manipolati dall'AI (paragrafo 4). La distinzione ha una conseguenza pratica che molte organizzazioni sottovalutano. La marcatura tecnica del provider, un watermark o un metadato, non arriva all'occhio di chi guarda il contenuto, e la Commissione chiarisce che il deployer non può appoggiarsi a quella marcatura per assolvere l'etichettatura del paragrafo 4. Servono due livelli separati: il segnale machine-readable a monte e la disclosure leggibile dalla persona a valle, e rispondono ad attori diversi. ## Gli agenti AI dichiarano anche per conto di chi agiscono Fra i punti più densi c'è la disciplina degli agenti. Un agente AI che prenota, gestisce la corrispondenza o conclude contratti per conto di qualcuno rientra nel paragrafo 1, e deve dichiarare due cose insieme: la propria natura artificiale e la persona per conto della quale agisce. Alla trasparenza dell'identità si aggiunge quella della delega, e con essa la questione di chi risponde delle conseguenze. Quando il provider non può sapere in anticipo se e con chi l'agente interagirà una volta rilasciato, le linee guida chiedono di progettare la dichiarazione a livello di architettura, così che l'agente si riveli ogni volta che è ragionevolmente probabile un contatto con una persona. E deve dichiararsi anche verso chi lo istruisce, nei passaggi chiave in cui autorizza un'azione o la valida, e a ogni nuova interazione. È una lettura che guarda avanti, alle architetture multi-agente dove un agente parla con un altro agente prima di arrivare all'essere umano. ## Il controllo editoriale che vale e quello che non basta Il testo pubblicato per informare il pubblico su questioni di interesse pubblico, quando è generato o manipolato dall'AI, va etichettato come artificiale. Esiste un'eccezione, e qui la Commissione alza l'asticella. L'esenzione vale solo se il testo ha attraversato una revisione umana o un controllo editoriale che entra nel merito, e solo se una persona, fisica o giuridica, ne assume la responsabilità editoriale. Sostanziale è la parola che pesa. La correzione ortografica, un controllo di sola forma o l'esistenza sulla carta di una policy editoriale non attivano l'esenzione. La revisione deve toccare il contenuto, con il fact-checking come requisito minimo, e chi la esercita deve poter approvare, modificare o respingere nel merito. C'è di più: se l'AI interviene in modo sostanziale dopo il via libera editoriale, l'eccezione decade e il testo torna etichettabile. Per le redazioni e per chi produce contenuti a scala, questa è una disciplina operativa prima che una regola giuridica. ## La finestra si chiude il 2 agosto Dal 2 agosto 2026 ogni sistema nel perimetro dell'articolo 50 immesso sul mercato nell'Unione deve essere conforme, a prescindere dalla data in cui è stato messo in servizio. L'AI Omnibus, appena adottato dal legislatore europeo, apre una sola finestra di tolleranza: i sistemi generativi già sul mercato prima del 2 agosto hanno tempo fino al 2 dicembre 2026 per adeguare la marcatura e la rilevabilità del paragrafo 2. La dichiarazione di interazione del paragrafo 1 e l'etichettatura del deployer del paragrafo 4 valgono invece dal 2 agosto, senza proroghe. La sanzione fissa la posta. Chi viola gli obblighi di trasparenza rischia fino a 15 milioni di euro o, se è un'impresa, fino al 3% del fatturato mondiale annuo, la cifra più alta tra le due. Per PMI e startup si applica il tetto più basso. La Commissione indica anche una strada per dimostrare la conformità: aderire al Codice di condotta sulla trasparenza dei contenuti generati dall'AI, pubblicato il 10 giugno 2026, che per i firmatari concentra la vigilanza sulla verifica dell'adesione. I numeri dicono quanto sia reale il problema. In Italia il 71% delle grandi imprese ha almeno un progetto AI attivo, mentre solo il 9% ha una governance strutturata (Osservatorio Artificial Intelligence del Politecnico di Milano, febbraio 2026). Gli obblighi dell'articolo 50 impongono di sapere, per ogni sistema, se genera contenuti, se interagisce con le persone e chi risponde della disclosure. È una domanda di governance prima che di compliance. ## Sapere quando dietro un testo non c'è una persona Lo scopo di questi obblighi è scritto nei considerando 132 e seguenti: ridurre i rischi di impersonificazione e di manipolazione su larga scala, e proteggere la fiducia nell'ecosistema informativo. Le linee guida provano a preservare, nello spazio comunicativo mediato dall'AI, le condizioni minime perché una persona possa scegliere se e quanto fidarsi di una voce, di un volto, di un testo. Sapere quando dietro un contenuto non c'è un essere umano diventa una precondizione dell'autonomia, non un dettaglio di conformità. Per un'azienda che progetta o adotta sistemi di AI, il baricentro si sposta. La trasparenza smette di essere una casella da spuntare a ridosso del lancio e diventa un vincolo di progettazione, da decidere prima di costruire. Chi arriva al 2 agosto avendo già mappato i propri sistemi e le relative responsabilità di disclosure non dovrà rincorrere. Restano poche settimane per capire, sistema per sistema, da che parte del confine ci si trova. ## Checklist: cosa mettere a posto prima del 2 agosto - [ ] **Inventario e classificazione.** Mappa ogni sistema di AI in uso o in arrivo e classificalo: interagisce con persone, genera o manipola contenuti (immagine, audio, video, testo), riconosce emozioni, categorizza dati biometrici. - [ ] **Ruolo per sistema.** Stabilisci se sei provider, deployer o entrambi. Gli obblighi cambiano: la marcatura tecnica spetta al provider, l'etichettatura percepibile al deployer. - [ ] **Sistemi interattivi.** Verifica che chatbot, voice assistant e agenti dichiarino la natura artificiale al primo contatto, in modo chiaro e distinguibile, non solo nei termini d'uso o nella documentazione. - [ ] **Agenti AI.** Assicura che dichiarino sia la natura artificiale sia per conto di chi agiscono, a livello di architettura, e verso chi li istruisce nei passaggi in cui autorizzano o validano un'azione. - [ ] **Contenuti sintetici (provider).** Implementa marcatura machine-readable e rilevabilità effettive e interoperabili. I generativi già sul mercato prima del 2 agosto hanno tempo fino al 2 dicembre 2026 solo per questo obbligo. - [ ] **Deep fake e testi di interesse pubblico (deployer).** Applica un'etichetta percepibile all'occhio umano. La marcatura tecnica del provider non copre questo obbligo. - [ ] **Riconoscimento emozioni e categorizzazione biometrica (deployer).** Informa le persone esposte al sistema. - [ ] **Eccezione editoriale.** Se pubblichi testi di interesse pubblico senza etichetta, documenta una revisione umana sostanziale (con fact-checking) e rendi pubblica la responsabilità editoriale. - [ ] **Accessibilità e vulnerabili.** Rendi la disclosure accessibile e adatta a minori e persone vulnerabili quando è ragionevole che siano tra il pubblico. - [ ] **Prova di conformità e responsabilità interna.** Valuta l'adesione al Codice di condotta sulla trasparenza dei contenuti generati dall'AI, coordina la disclosure con GDPR e DSA dove si applicano, e assegna per ogni sistema chi risponde della disclosure. --- *In ZeroFive lavoriamo con CEO e board per mappare i sistemi di AI in uso e decidere dove la trasparenza va progettata, prima che diventi un problema di conformità. Il punto di partenza è l'AI Rating. Per parlarne: [calendly.com/fabiolalli/zerofive](https://calendly.com/fabiolalli/zerofive).* ## Dove si colloca l'art. 50 nel quadro di governance La trasparenza dell'articolo 50 non è un adempimento isolato: è un controllo dentro un sistema più ampio. Chi ha già impostato una [consulenza di AI Governance](/ai-governance) la gestisce come un requisito di progettazione, chi non l'ha fatto la scopre come emergenza. Per l'allineamento completo alle scadenze normative il percorso è la [consulenza AI Act](/compliance-ai), mentre il quadro dei servizi è su [consulenza AI per aziende](/servizi). --- # Adozione dell'AI: dove finisce l'uso e comincia l'integrazione URL: https://zerofive.ai/blog/approfondimenti/adozione-ai-italia-dove-finisce-uso-comincia-integrazione Data: 2026-07-18 Abstract: Il 71% delle grandi imprese italiane ha un progetto AI, solo il 9% una governance integrata. Come misurare la maturità AI prima di scalarla. Chiedete in una grande azienda italiana chi usa l'intelligenza artificiale e alzeranno la mano in molti, il marketing per i testi, l'IT per il codice, qualcuno in finance per le analisi. Chiedete poi chi decide quali di questi usi entrano nei processi ufficiali, con quali dati e sotto la responsabilità di chi, e la stanza si svuota. In quella distanza, tra chi usa l'AI e chi la governa, si gioca tutto il tema dell'adozione. L'adozione dell'AI viene spesso confusa con la sua diffusione, e sono due cose lontane. La diffusione si misura in licenze attivate e persone che aprono un modello ogni mattina. L'adozione si misura in quanto quel modello ha cambiato il modo in cui l'azienda produce valore e risponde di quello che produce. ## La differenza tra usare l'AI e averla adottata Un'organizzazione ha adottato l'AI quando sa fare tre cose: misurare cosa l'AI produce, decidere dove quel contributo entra nei processi, rispondere delle decisioni che ne derivano. Finché queste tre cose mancano, l'AI resta uno strumento in mano ai singoli, senza diventare una capacità dell'organizzazione. Un'azienda dove duecento persone usano ogni giorno un assistente generativo, ma nessuno sa dire cosa sia cambiato nei conti né chi abbia autorizzato quali usi, ha la diffusione al massimo e l'adozione a zero. È la situazione più comune, ed è anche la più costosa, perché somiglia al progresso senza esserlo. ## Le quattro capacità che reggono l'adozione Adottare l'AI è una capacità organizzativa che poggia su quattro basi, da costruire insieme. La readiness viene per prima: dati utilizzabili, competenze reali, processi capaci di assorbire l'AI, una cultura che non la respinge. Poi conta la delivery, la capacità di portare un progetto dal pilota alla produzione e di scalarlo, ed è lì che muore la maggioranza delle iniziative. Sul rischio si gioca la governance, con una linea chiara di responsabilità su chi decide e chi supervisiona e l'allineamento a Legge 132/2025 e AI Act. Resta la confidence, il commitment del vertice e la fiducia di chi lavora, senza cui anche un sistema che funziona finisce inutilizzato. Sono le quattro dimensioni su cui si misura l'AI Rating, e trovarle mature tutte insieme, nella stessa azienda, è raro. ## Il 71% ha un progetto, il 9% ha una governance I numeri italiani raccontano esattamente questo squilibrio. Nel 2025 il mercato dell'AI in Italia ha raggiunto 1,8 miliardi di euro, in crescita del 50% sull'anno prima, e il 71% delle grandi imprese ha avviato almeno un progetto, in salita dal 59% del 2024, secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano, che ha presentato la ricerca il 5 febbraio 2026. L'84% usa strumenti di Generative AI pronti all'uso. Sotto quei numeri la fotografia cambia: solo una grande impresa su cinque impiega l'AI in modo pervasivo su più funzioni, e appena il 9% dichiara una governance dell'AI pienamente integrata. Tra le PMI la quota che ha avviato progetti scende all'8%. Lo stesso Osservatorio segnala che otto lavoratori su dieci usano strumenti di AI non forniti dall'azienda, e buona parte dell'adozione reale accade così fuori da ogni perimetro e da ogni decisione. L'Italia ha diffuso l'AI in larghezza e l'ha integrata in profondità solo in una minoranza di casi. ## Il costo di restare in superficie Fermarsi alla diffusione ha un prezzo, e si paga su più fronti. Il primo è economico: la spesa in accessi che non entrano nei processi resta un guadagno di produttività individuale e non diventa vantaggio dell'organizzazione. Poi c'è la difendibilità, perché l'uso individuale si replica in fretta mentre l'integrazione nei processi no, e la distanza tra chi ha governato l'adozione e chi no si allarga nel tempo. Sul piano normativo, con la Legge 132/2025 in vigore e l'AI Act che entra nel vivo, l'adozione non governata diventa esposizione, perché lega l'azienda a decisioni prese da modelli di cui non tiene traccia. Sopra tutto pesa una dipendenza di sequenza: automazione e agenti si costruiscono su un'adozione governata, e chi non ha attraversato questa fase non ha fondamenta per quelle successive. ## Misurare la maturità prima di scalarla Si comincia dal sapere a che punto si è davvero. Prima di scegliere dove investire, un'azienda ha bisogno di una misura oggettiva della propria capacità di adottare l'AI lungo le quattro dimensioni, dalla readiness alla confidence. È la logica dell'AI Rating, la valutazione con cui ZeroFive.AI fotografa la maturità AI di un'impresa su criteri oggettivi e restituisce i divari prima che diventino costi. Da quella misura discendono le scelte concrete: dove ha senso investire e cosa conviene validare prima di portarlo in produzione. Misurare, decidere, validare, in quest'ordine. Il 9% che oggi ha una governance integrata parte dalla stessa tecnologia di tutti gli altri, ha deciso prima e su basi misurabili. La domanda da portare in consiglio non è quanto stiamo spendendo in AI, ma quanto di quella spesa sappiamo davvero governare. Se la risposta non è chiara, il primo passo è misurarla. Parte da una conversazione: hello@zerofive.ai --- # Ontologie: l'infrastruttura che decide se l'AI ragiona o indovina URL: https://zerofive.ai/blog/approfondimenti/ontologie-infrastruttura-ai-ragiona-o-indovina Data: 2026-07-18 Abstract: Un'azienda può avere il modello migliore e ricevere risposte plausibili invece che vere. Perché senza ontologia governata l'AI non ragiona, indovina. Nelle riunioni sull'AI l'ontologia compare spesso come parola, quasi mai come responsabilità. Se ne parla, la si mette in una slide accanto a knowledge graph e dati, e poi si torna a discutere di modelli e casi d'uso. Eppure è lo strato che stabilisce una cosa sola: se il sistema che avete messo in produzione ragiona sui vostri dati o produce risposte che suonano bene. Un'azienda può avere il modello migliore sul mercato e continuare a ricevere risposte plausibili invece che vere, perché nessuno ha governato il significato su cui quel modello lavora. ## L'ontologia è la mappa condivisa del significato Sotto le buzzword c'è un'idea semplice. Un'ontologia è la mappa esplicita e condivisa delle entità che contano per il business, cliente, prodotto, contratto, rischio, e delle relazioni tra queste entità. È l'accordo su cosa significano le parole con cui l'azienda descrive sé stessa. In gran parte delle organizzazioni quell'accordo non esiste: "cliente" vuol dire una cosa nel CRM, un'altra nella fatturazione, una terza nel supporto, e ogni sistema ha ragione dal proprio punto di vista. Il knowledge graph è quella mappa resa interrogabile, la forma in cui il significato diventa qualcosa su cui una macchina può ragionare. ## Ragionare o indovinare Un modello linguistico, da solo, è fluente e senza terra sotto i piedi: genera testo probabile a partire da ciò che ha visto durante l'addestramento, senza contatto con i fatti della vostra azienda. Ancorato a un'ontologia e a un knowledge graph, lo stesso modello smette di completare frasi e inizia a percorrere entità e relazioni reali, e le sue risposte diventano verificabili, tracciabili fino alla fonte. La differenza conta poco quando l'AI scrive una email, pesa tutto quando decide un affidamento o classifica un rischio. Con la Legge 132/2025 in vigore e l'AI Act che entra nel vivo, una risposta difendibile davanti a un'autorità chiede di poggiare su un significato governato, l'unica base che regge a un controllo. ## Costruirla senza reinventarla L'errore più comune è trattare l'ontologia come un grande progetto da completare prima di partire, e infatti quei progetti non partono. Si comincia dal lato opposto, dalle decisioni che l'azienda deve poter difendere e dalle poche entità che quelle decisioni toccano, mappando prima ciò che genera valore o rischio e lasciando fuori il resto. Dove esistono standard di settore si riusano, invece di ridisegnare da zero categorie che qualcuno ha già formalizzato. L'ontologia cresce per strati, seguendo l'uso reale, e resta piccola abbastanza da poter essere mantenuta. ## Il significato si sposta, e nessuno se ne accorge Un'ontologia non si rompe con un errore visibile, si degrada in silenzio. Il business cambia, nasce una linea di prodotto, una categoria assume un senso diverso, e la mappa resta ferma a un mondo che non esiste più. Le risposte continuano ad arrivare, sembrano corrette, e intanto poggiano su definizioni scadute. Il significato va governato come si governa il codice: qualcuno lo possiede, le modifiche sono versionate, chi cambia la definizione di un termine sa cosa sta muovendo a valle. Senza questa manutenzione l'infrastruttura invisibile diventa un rischio invisibile, e il problema si scopre quando una decisione sbagliata è già stata presa. Governare le ontologie è un tema di responsabilità prima che di tecnologia, ed è uno dei punti dove l'AI aziendale si vince o si perde. È anche il primo dei nostri AI Strategy Papers, "Govern Meaning": trenta pagine su cosa è davvero un'ontologia, perché serve adesso, come costruirla e come impedirle di degradare in silenzio fino a diventare pericolosa. Si scarica qui, in italiano e in inglese: [AI Strategy Papers](https://zerofive.ai/papers). --- # Legge 132/2025 e AI Act: perché la governance conta più delle regole URL: https://zerofive.ai/blog/compliance/legge-132-2025-ai-act-governance-imprese Data: 2026-07-17 Abstract: Dal 10 ottobre 2025 la Legge 132/2025 è in vigore e dal 2 agosto 2026 scattano gli obblighi dell'AI Act. Perché serve una governance AI, non solo la compliance. Il quadro normativo sull'AI è cambiato, e non riguarda solo gli avvocati. Dal **10 ottobre 2025** è in vigore la **Legge 132/2025**, primo quadro nazionale italiano sull'intelligenza artificiale. Si affianca all'**AI Act europeo**, che dal **2 agosto 2026** rende operativi gli obblighi di trasparenza e il regime sanzionatorio. Insieme valgono per le imprese di qualsiasi settore e dimensione. ## Il passaggio che i board sottovalutano C'è un punto che i consigli di amministrazione tendono a leggere in ritardo: la 132 rafforza il legame tra AI e **Modello 231**. L'uso di sistemi AI entra nel perimetro della responsabilità penale d'impresa. Diventa un tema da consiglio di amministrazione, oltre che da IT. Le domande cambiano di natura: - chi risponde delle decisioni prese o suggerite da un sistema AI? - con quali dati sono state addestrate e alimentate? - quale tracciabilità esiste, oggi, in caso di contestazione? ## Le regole sono la parte facile La reazione tipica è correre a leggere le regole. Le regole però sono la parte facile. Difficile è sapere se l'organizzazione sa rispettarle: chi risponde di cosa, con quali dati, con quale tracciabilità delle decisioni. È la distanza tra conoscere una norma e avere la governance per applicarla. > Il **9% delle grandi imprese italiane** ha una governance AI strutturata. > *Osservatorio Artificial Intelligence, Politecnico di Milano, 2025* Sono le stesse che oggi si ritrovano già pronte alla compliance. ## Misura prima di adeguarti Prima di adeguarti, misura dove sei. L'**AI Rating** valuta la tua AI Risk su criteri oggettivi e ti dice cosa manca prima che scatti una scadenza. Il primo passo è una conversazione: [hello@zerofive.ai](mailto:hello@zerofive.ai) --- # AI Rating nello sport: il gate cambia tra club e federazioni URL: https://zerofive.ai/blog/strategia/ai-rating-club-sportivi-proprieta-dati Data: 2026-07-16 Abstract: Confidence alta e Readiness bassa. Perché il vincolo è contrattuale, cosa cambia classificando gli atleti come lavoratori e quando misurare. **In sintesi.** Nelle società sportive il profilo di maturità AI ha una forma caratteristica: Confidence molto alta, perché la dirigenza è convinta del valore, e Readiness bassa, perché i dati sono nei sistemi dei fornitori e non della società. Il gate che blocca la classe riguarda la proprietà dei dati più che la governance: un club che non può esportare quello su cui lavora non controlla i propri sistemi, per quanto li usi bene. Nelle federazioni e negli enti di promozione il quadro si ribalta: il dato è in casa, e il peso si sposta sul trattamento dei tesserati e sui sistemi che valutano ammissioni ed esami. Una società che si misura sulla maturità AI ottiene spesso un risultato più basso di quanto si aspetti, e la ragione è che il modello guarda al controllo mentre la percezione interna guarda all'uso. Le due cose divergono in modo netto nello sport. ## Le quattro dimensioni in una società sportiva **Readiness** misura preparazione, dati, competenze, infrastrutture. È la dimensione più bassa nei club, non per arretratezza tecnologica ma perché i dati sono distribuiti tra fornitori e la società raramente ha accesso diretto. Un club può usare quotidianamente tre piattaforme di analisi e non possedere nessuno dei dati che le alimentano. Lo stesso vale sul lato del pubblico: l'anagrafica dei tifosi è divisa tra biglietteria, e-commerce, app e canali social, e una vista unica del singolo tifoso quasi mai esiste. **Delivery** misura la capacità di portare in produzione e mantenere. Nei club è strutturalmente limitata dalla dimensione degli organici: non esiste un ciclo di rilascio perché non esiste un team che lo governi, e i sistemi arrivano già pronti dai fornitori. **Risk** misura governance, compliance ed etica. È scoperta quasi ovunque, e l'area più esposta riguarda i dati degli atleti, che sono dati sanitari, e i sistemi biometrici negli impianti. **Confidence** misura commitment della dirigenza e fiducia degli utenti. È tipicamente alta, a volte più alta di quanto i risultati giustifichino, perché nello sport l'innovazione ha valore anche comunicativo. La fiducia degli utenti, qui, è quella del pubblico, e si misura sulle reazioni ai prezzi dei biglietti e ai controlli agli ingressi più che su un questionario interno. ## Il gate: chi possiede i dati Il vincolo ricorrente è questo. Un club usa sistemi che funzionano, su dati che non può esportare, forniti da aziende che aggiornano i modelli senza preavviso. Questo produce tre conseguenze sul rating. L'inventario resta incompleto, perché di alcuni sistemi non si conosce il funzionamento. La sorveglianza umana non è dimostrabile, perché mancano i log. Cambiare fornitore comporta la perdita dello storico, il che rende la società dipendente da scelte che non controlla. Il nodo si presenta due volte, sul dato tecnico e su quello del pubblico. Nel secondo caso il fornitore è la piattaforma di ticketing o il social network, e la quota di tifosi raggiungibili in modo diretto è la misura pratica di quanto la società controlla la propria base. Finché questo nodo resta aperto, la dimensione Readiness non sale e la classe resta bassa per quanto la governance sia ordinata. ## Gli atleti sono lavoratori, e questo cambia tutto È la classificazione che nei club emerge tardi e cambia il quadro. I sistemi usati per valutare, selezionare o gestire atleti sotto contratto rientrano tra i sistemi di gestione dei lavoratori dell'Allegato III quando incidono su decisioni contrattuali. Molte società non hanno mai fatto quella classificazione, e di conseguenza non hanno né valutazione dei rischi né documentazione su quei sistemi. Il rilievo non riguarda l'uso, riguarda l'assenza di una decisione documentata su come quei sistemi vanno trattati. ## Il profilo di una federazione Nelle federazioni e negli enti di promozione il profilo si ribalta rispetto al club su due dimensioni. Readiness è più alta sul dato, perché il tesseramento è gestito internamente e l'anagrafica esiste, spesso con uno storico lungo. Risk è più esposta, perché quello stesso dato riguarda in prevalenza minori e include certificati di idoneità. C'è poi un elemento che nei club non compare. Se l'ente usa sistemi che decidono ammissioni a corsi o valutano esami per tecnici e ufficiali di gara, quei sistemi rientrano in Allegato III, e la classificazione va fatta a prescindere da quanto il processo sembri di routine. Dove l'ente ricade tra gli organismi di diritto pubblico si aggiungono obblighi di valutazione e trasparenza che conviene verificare in anticipo. ## Cosa significa una classe, in pratica | Classe | Situazione tipica in un club | Cosa è ragionevole fare | |---|---|---| | D | Sistemi dei fornitori usati senza mappatura, nessuna classificazione | Mappare fornitori e dati prima di adottare altro | | C | Mappa dei sistemi presente, nessun controllo sui dati | Rinegoziare i contratti su accesso ed esportazione, sul lato tecnico e su quello del pubblico | | B | Accesso ai dati garantito, classificazione fatta, presidio parziale | Completare la documentazione sui sistemi che toccano gli atleti | | A | Sistema maturo verificato su tutte le dimensioni | Riservata alle valutazioni verificate, non alle autovalutazioni | Il passaggio da C a B in una società sportiva è quasi sempre un lavoro contrattuale prima che tecnico, e questo sorprende chi si aspettava un intervento sui sistemi. ## Perché misurare prima di firmare Nello sport il momento utile per il rating non è l'inizio dell'anno fiscale, è il momento in cui scade un contratto con un fornitore di dati. È lì che la società ha la leva per ottenere accesso, esportazione e documentazione, e senza una valutazione fatta prima quella leva viene usata solo sul prezzo. Un club che rinnova per tre anni senza aver chiarito cosa può esportare si blocca la crescita sulla dimensione Readiness per l'intera durata del contratto. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), che in una società sportiva va costruito partendo dall'elenco dei fornitori e dei flussi di dati in uscita. Il modello completo, con le quattro dimensioni e la logica dei gate, è nella pagina [AI Rating](/servizi/ai-rating). Il quadro normativo del settore è nella pagina [AI governance per club e organizzazioni sportive](/settori/sport). Per una valutazione della posizione della tua società puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # EU AI Act per imprese italiane: guida operativa alla compliance URL: https://zerofive.ai/blog/compliance/guida-eu-ai-act-imprese-italiane Data: 2026-07-15 Abstract: EU AI Act e L. 132/2025 per le imprese italiane: rischi sui processi, calendario post Digital Omnibus, autorità AgID e ACN, sanzioni e sei passi operativi. Questa pagina approfondisce un aspetto specifico. Il quadro completo degli obblighi, dei ruoli e delle scadenze è in [AI Act: guida completa a obblighi, responsabilità e dati](/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati). L'EU AI Act (Regolamento UE 2024/1689) è la prima normativa organica al mondo sull'intelligenza artificiale. Per le imprese italiane la partita è di governance, responsabilità e mercato, prima ancora che tecnica. Chi si presenta pronto entra nei tender pubblici e nelle supply chain europee con un vantaggio strutturale, perché i clienti enterprise chiedono già attestazioni AI Act nei bandi. Chi arriva in ritardo rischia sanzioni fino a 35 milioni di euro o al 7% del fatturato globale. Il calendario è cambiato nel 2026: il Digital Omnibus on AI, approvato in via definitiva dal Consiglio UE il 29 giugno 2026, ha rinviato gli obblighi più pesanti sui sistemi ad alto rischio. Restano fermi i divieti, la trasparenza e i poteri sanzionatori; slitta la parte più onerosa. Questa guida è pensata per CEO, board, responsabili compliance e IT delle aziende italiane che devono passare dai principi alle azioni concrete, e integra il quadro nazionale della L. 132/2025. ## Il quadro italiano: AI Act più L. 132/2025 L'AI Act è direttamente applicabile in Italia senza recepimento, ma il legislatore nazionale ha aggiunto un ulteriore strato con la Legge 23 settembre 2025, n. 132 ("Disposizioni e deleghe in materia di intelligenza artificiale"), in vigore dal 10 ottobre 2025. È una legge quadro: diversi aspetti operativi, inclusi i poteri sanzionatori delle autorità, arrivano con i decreti attuativi attesi entro dodici mesi. Le imprese italiane devono quindi leggere insieme: - Il Regolamento UE 2024/1689 (AI Act) per obblighi, divieti e sanzioni. - La L. 132/2025 per il quadro nazionale: principi, autorità competenti, uso dell'AI nella PA, in sanità, nel lavoro e nella giustizia. - AgID (Agenzia per l'Italia Digitale) come autorità di notifica e ACN (Agenzia per la Cybersicurezza Nazionale) come autorità di vigilanza del mercato, con poteri ispettivi e sanzionatori. - Il Garante Privacy per tutto ciò che tocca dati personali, profilazione e decisioni automatizzate ai sensi del GDPR. Per i sistemi AI di banche, assicurazioni e mercati finanziari la vigilanza del mercato resta a Banca d'Italia, CONSOB e IVASS. Per un'impresa italiana la compliance AI non è mai solo AI Act: è la combinazione di AI Act, GDPR, NIS2 e DORA per il finance, oltre alle norme di settore. ## Le quattro categorie di rischio applicate ai processi di business L'AI Act classifica i sistemi in base al rischio. La chiave operativa è ragionare per caso d'uso e processo aziendale, non per tecnologia. ### 1. Rischio inaccettabile: vietato dal 2 febbraio 2025 Sono vietati, tra gli altri: - Social scoring generalizzato su cittadini o dipendenti. - Riconoscimento delle emozioni sul luogo di lavoro e nelle scuole (con eccezioni mediche o di sicurezza molto strette). - Categorizzazione biometrica per dedurre etnia, opinioni politiche, orientamento sessuale o religione. - Tecniche subliminali o manipolative che alterano il comportamento in modo dannoso. - Predictive policing basato solo su profilazione. Impatti tipici per le aziende italiane: HR analytics aggressivi, sistemi di sentiment analysis sui dipendenti, tool di sorveglianza comportamentale in call center o retail. Vanno rivisti o dismessi subito. Con il Digital Omnibus si aggiunge dal 2 dicembre 2026 un divieto sui sistemi AI che generano immagini intime non consensuali o materiale pedopornografico. Sul piano nazionale la L. 132/2025 ha inoltre introdotto un reato per la diffusione di deepfake dannosi (art. 612-quater c.p.). ### 2. Alto rischio: il cuore della compliance È qui che si gioca la maggior parte del lavoro. Un sistema è ad alto rischio se rientra nei casi dell'Allegato III o se è componente di sicurezza di un prodotto già regolato (come i dispositivi medici, i macchinari, l'automotive, i giocattoli o gli ascensori). Casi ad alto rischio ricorrenti nelle imprese italiane: - HR e recruiting: screening CV, ranking candidati, valutazione performance, decisioni su promozioni e licenziamenti. - Credito e assicurazioni: scoring creditizio persone fisiche, pricing assicurativo life & health, antifrode con impatto sull'accesso a servizi. - Formazione e istruzione: sistemi che valutano studenti, ammettono a percorsi o assegnano punteggi. - Infrastrutture critiche: reti di traffico, energia e acqua, telecomunicazioni. - Servizi pubblici essenziali: eleggibilità a benefici, triage sanitario, priorità nell'accesso ai servizi. - Law enforcement e migrazione: valutazione affidabilità testimonianze, verifica documenti. - Amministrazione della giustizia: supporto interpretativo, ricerca giurisprudenziale con impatto decisionale. Per ciascun sistema ad alto rischio l'AI Act impone un pacchetto di obblighi: - Sistema di gestione del rischio documentato lungo tutto il ciclo di vita. - Data governance: qualità, rappresentatività e tracciabilità dei dataset di training, validation e test. - Documentazione tecnica conforme all'Allegato IV, aggiornata a ogni release rilevante. - Logging automatico degli eventi rilevanti (input, output e override umano). - Trasparenza verso il deployer: istruzioni d'uso, limiti e condizioni operative attese. - Sorveglianza umana effettiva, non teorica: chi controlla, con quali competenze, con quale potere di intervento. - Accuratezza, robustezza e cybersecurity proporzionate al rischio. - Sistema di gestione qualità (SGQ) che tenga insieme i punti precedenti. - Valutazione di conformità prima dell'immissione sul mercato, marcatura CE e registrazione nella banca dati UE. - Monitoraggio post-market e reporting degli incidenti gravi entro i termini previsti, di norma 15 giorni. ### 3. Rischio limitato: obblighi di trasparenza Chatbot, assistenti virtuali, generatori di contenuti sintetici (testo e immagini, audio e video). L'utente deve sapere che sta interagendo con un'AI o che il contenuto è generato o alterato artificialmente. Deepfake e contenuti sintetici vanno etichettati in modo leggibile a macchina (watermarking, provenance metadata). ### 4. Rischio minimo: nessun obbligo specifico Filtri antispam, motori di raccomandazione a basso impatto, videogiochi. Non ci sono obblighi vincolanti, ma è consigliato adottare comunque i codici di condotta volontari previsti dall'AI Act. ## Modelli GPAI: l'obbligo trasversale I fornitori di General Purpose AI models (LLM di frontiera e non) devono pubblicare la documentazione tecnica, le informazioni per gli integratori, una policy di rispetto del copyright UE e un riassunto pubblico dei dati di training. I modelli con rischio sistemico (soglia indicativa 10^25 FLOPs di training) hanno obblighi aggiuntivi di valutazione, mitigazione del rischio sistemico, cybersecurity e reporting. Per le imprese italiane che integrano GPAI di terze parti in prodotti o processi, l'obbligo si sposta: si diventa deployer o provider a valle e occorre valutare se l'uso configura un sistema ad alto rischio ai sensi dell'Allegato III. ## Il Digital Omnibus: cosa è cambiato nel 2026 Entro l'estate 2026 è diventato chiaro che gli standard tecnici e le autorità competenti non sarebbero stati pronti in tempo per l'applicazione degli obblighi ad alto rischio. La Commissione europea ha proposto il Digital Omnibus on AI il 19 novembre 2025; il Parlamento europeo lo ha approvato il 16 giugno 2026 e il Consiglio UE ha dato il via libera definitivo il 29 giugno 2026. Il pacchetto non tocca l'architettura dell'Act, resta l'approccio per rischio. Sposta le scadenze più impegnative e introduce alcune modifiche mirate: - **Obblighi ad alto rischio rinviati.** I sistemi stand-alone dell'Allegato III passano dal 2 agosto 2026 al 2 dicembre 2027. I sistemi integrati in prodotti regolati dell'Allegato I passano dal 2 agosto 2027 al 2 agosto 2028. - **Nuovo divieto.** Dal 2 dicembre 2026 sono vietati i sistemi AI che generano immagini intime non consensuali o materiale pedopornografico. - **Watermarking rinviato.** L'obbligo per i provider di marcare in modo leggibile dalle macchine i contenuti generati (Articolo 50, comma 2) si applica dal 2 dicembre 2026 per i sistemi già sul mercato al 2 agosto 2026. Gli altri obblighi di trasparenza restano al 2 agosto 2026. - **Sandbox rinviate.** Il termine per gli Stati membri per istituire almeno una sandbox regolatoria nazionale slitta al 2 agosto 2027. - **Meno oneri per le piccole realtà.** Le esenzioni previste per le PMI vengono estese alle small mid-cap. ## La roadmap aggiornata per le imprese italiane - **2 febbraio 2025**: divieti sulle pratiche vietate e obbligo di AI literacy per il personale che usa o gestisce AI, a qualsiasi livello di rischio. - **2 agosto 2025**: governance UE operativa, obblighi per i modelli GPAI, regime sanzionatorio applicabile. - **2 agosto 2026**: si applica la maggior parte delle disposizioni, inclusi gli obblighi di trasparenza dell'Articolo 50 e i poteri sanzionatori. Non è più la data dell'alto rischio. - **2 dicembre 2026**: watermarking dei contenuti generati per i sistemi già sul mercato, ed entra in vigore il nuovo divieto su immagini intime non consensuali e materiale pedopornografico. - **2 agosto 2027**: termine per gli Stati membri per istituire le sandbox regolatorie nazionali. - **2 dicembre 2027**: piena applicazione per i sistemi ad alto rischio stand-alone dell'Allegato III. - **2 agosto 2028**: applicazione ai sistemi ad alto rischio integrati in prodotti già coperti da normativa di sicurezza UE. Le sanzioni sono strutturate su tre livelli: - Fino a 35 milioni di euro o 7% del fatturato globale per pratiche vietate. - Fino a 15 milioni di euro o 3% del fatturato globale per violazioni degli obblighi ad alto rischio. - Fino a 7,5 milioni di euro o 1% del fatturato globale per informazioni scorrette alle autorità. Per PMI e startup gli importi sono ridotti ma non nulli. ## Sei passi operativi per iniziare oggi - **Inventario AI aziendale**: mappa ogni sistema AI, interno o SaaS, con owner di business, dati trattati e decisioni influenzate. Nessuna compliance è possibile senza inventario. - **Classificazione del rischio per caso d'uso**: applica la logica dell'AI Act e documenta le motivazioni della classificazione. - **Gap assessment**: per ogni sistema ad alto rischio verifica la presenza di risk management, data governance, logging e sorveglianza umana, oltre alla documentazione tecnica. - **Governance interna**: nomina un AI Officer o rafforza un comitato AI cross-funzionale (Legal, IT, Security, HR, Business). Definisci le deleghe verso il board. - **Integrazione con framework esistenti**: allinea l'AI Act a ISO/IEC 42001, NIST AI RMF e agli obblighi di GDPR, NIS2 e DORA. Riusa i controlli già in essere. - **AI literacy diffusa**: forma tutto il personale che interagisce con l'AI, non solo i tecnici. È un obbligo dal 2 febbraio 2025. ## Come integrare AI Act, ISO 42001 e L. 132/2025 Le imprese più mature stanno costruendo un modello unico di governance AI che tiene insieme: - L'AI Act come base di conformità obbligatoria. - La ISO/IEC 42001 come standard certificabile per il sistema di gestione AI, utile in gara e nei rapporti con i clienti enterprise. - La L. 132/2025 per gli aspetti nazionali (uso nella PA, nel lavoro, in sanità, nella giustizia). - Il NIST AI RMF come framework operativo per gestire il rischio, misurarlo e migliorarlo. - GDPR, NIS2 e DORA per i domini connessi come dati, cybersecurity e finance. Il vantaggio è duplice: si riduce la duplicazione dei controlli e si costruisce un unico corpo di evidenze utilizzabile in audit, gare e trattative commerciali. ## Le priorità per il board Se sei nel board o nella direzione di un'azienda italiana, tre priorità: - Fai partire l'inventario AI questa settimana. Non serve un tool: serve un foglio di lavoro condiviso con i proprietari di processo. - Chiedi una classificazione del rischio per i primi cinque casi d'uso. Documenta chi ha deciso e con quali motivazioni. - Metti la governance AI all'ordine del giorno del board almeno ogni trimestre, con KPI di compliance e di adozione. L'AI Act è anche un'occasione: costruire un vantaggio competitivo strutturale mentre altri rimandano. Il rinvio degli obblighi ad alto rischio al 2 dicembre 2027 apre una finestra utile, a patto di usarla per prepararsi invece di fermarsi. Se vuoi capire dove sei nel percorso di compliance, valuta il nostro AI Rating: un assessment che misura la maturità AI su quattro dimensioni, con un report utilizzabile in board e con i clienti enterprise. --- # EU AI Act: guida pratica alla compliance per aziende e board URL: https://zerofive.ai/blog/compliance/guida-eu-ai-act-compliance-aziende Data: 2026-07-15 Abstract: L'EU AI Act per le aziende: obblighi risk-based, timeline aggiornata dopo il Digital Omnibus, sanzioni fino a 35M EUR e roadmap 90 giorni per CEO e board. Questa pagina approfondisce un aspetto specifico. Il quadro completo degli obblighi, dei ruoli e delle scadenze è in [AI Act: guida completa a obblighi, responsabilità e dati](/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati). L'EU AI Act è la prima regolamentazione organica al mondo sull'intelligenza artificiale. È in vigore dal 1° agosto 2024 e le sue disposizioni si applicano su una timeline scaglionata tra il 2025 e il 2028. Nel 2026 quella timeline è stata rivista: il Digital Omnibus on AI, approvato in via definitiva dal Consiglio dell'UE il 29 giugno 2026, ha spostato in avanti gli obblighi più pesanti, quelli sui sistemi ad alto rischio. Per un CEO o un board italiano la domanda resta operativa: cosa dobbiamo fare, entro quando, e chi risponde se non lo facciamo. Questa guida sintetizza gli obblighi reali per le aziende che usano, integrano o sviluppano AI, la timeline aggiornata dopo l'Omnibus e una roadmap operativa a 90 giorni pensata per organizzazioni medio-grandi. ## Chi è coinvolto: provider, deployer, importatore, distributore Il regolamento definisce quattro ruoli, e una stessa azienda può ricoprirne più di uno su sistemi diversi. **Provider**: chi sviluppa o immette sul mercato un sistema di AI a proprio nome, anche quando all'interno di un prodotto viene usato un modello open source. È il ruolo con il maggior numero di obblighi. **Deployer**: chi utilizza un sistema di AI nell'ambito della propria attività (una banca che adotta un modello di scoring, una funzione HR che introduce lo screening dei CV, un'organizzazione sanitaria che integra un supporto diagnostico). È il ruolo più diffuso. **Importatore e distributore**: chi porta sul mercato UE sistemi di AI di terzi extra-UE o li rivende. Un errore ricorrente è pensare "compriamo software, quindi non siamo provider". Se una banca personalizza un modello di credit scoring integrandolo nei propri processi con dati proprietari, in molti scenari il ruolo cambia e le responsabilità crescono. La prima azione di compliance è quindi classificare correttamente il proprio ruolo per ogni sistema AI in uso. ## Le quattro categorie di rischio L'AI Act non regola l'AI in astratto: regola i casi d'uso in base al rischio. **Rischio inaccettabile: vietato.** Social scoring pubblico, manipolazione subliminale, riconoscimento delle emozioni sul lavoro e a scuola, categorizzazione biometrica per dedurre dati sensibili come etnia, opinioni politiche o orientamento sessuale. Questi divieti si applicano dal 2 febbraio 2025. Il Digital Omnibus aggiunge un nuovo divieto, applicabile dal 2 dicembre 2026, sui sistemi AI che generano immagini intime non consensuali di persone reali o materiale pedopornografico. **Alto rischio.** Sistemi usati nelle aree sensibili elencate nell'Allegato III: HR (screening, valutazione e decisioni sul rapporto di lavoro), credito e assicurazioni per persone fisiche, istruzione, infrastrutture critiche, giustizia e migrazione, componenti di sicurezza di prodotti già regolamentati come i dispositivi medici. È qui che si concentra la maggior parte dello sforzo di compliance. **Rischio limitato: obblighi di trasparenza.** Chatbot, generazione di contenuti sintetici e deepfake: l'utente deve sapere che sta interagendo con un'AI o che il contenuto è generato. **Rischio minimo.** Filtri antispam, videogiochi e ottimizzazioni interne. Nessun obbligo formale, anche se applicare un livello minimo di governance ha comunque senso. ## Obblighi concreti per i sistemi ad alto rischio Per un sistema classificato ad alto rischio, il provider deve avere in essere, prima dell'immissione sul mercato: - Un sistema di risk management documentato lungo l'intero ciclo di vita. - Data governance: qualità, rappresentatività e bias dei dataset di training, validazione e test. - Documentazione tecnica conforme all'Allegato IV e istruzioni per il deployer. - Logging automatico degli eventi rilevanti per la tracciabilità. - Sorveglianza umana progettata "by design", non aggiunta a posteriori. - Accuratezza, robustezza e cybersecurity proporzionate al rischio. - Valutazione di conformità (autovalutazione in molti casi, con organismo notificato in altri) e marcatura CE. - Registrazione nella banca dati UE dei sistemi ad alto rischio. - Un sistema qualità e un monitoraggio post-market. Il deployer ha obblighi più leggeri ma non nulli: usare il sistema secondo le istruzioni, garantire la sorveglianza umana da parte di personale competente, conservare i log, segnalare incidenti gravi, informare i lavoratori quando l'AI incide sul rapporto di lavoro e, per il settore pubblico e alcuni privati come banche e assicurazioni, condurre la Fundamental Rights Impact Assessment prima dell'uso. ## Modelli GPAI: cosa cambia dal 2 agosto 2025 I provider di modelli General Purpose AI (LLM di frontiera e oltre) devono pubblicare documentazione tecnica, informazioni per gli integratori, una policy UE di conformità al copyright e una sintesi pubblica dei dati di addestramento. I modelli con rischio sistemico (soglia indicativa di 10^25 FLOPs di training) portano obblighi aggiuntivi di valutazione, mitigazione del rischio sistemico, cybersecurity e segnalazione degli incidenti gravi all'AI Office. Per chi costruisce prodotti sopra un LLM di terzi, questa documentazione più strutturata dei provider va comunque integrata nella propria, in qualità di deployer o provider a valle. ## Il Digital Omnibus: cosa è cambiato nel 2026 Nell'estate del 2026 era ormai chiaro che gli standard tecnici e le autorità competenti non sarebbero stati pronti in tempo per l'applicazione degli obblighi sull'alto rischio. La Commissione europea ha proposto il Digital Omnibus on AI il 19 novembre 2025; il Parlamento europeo lo ha approvato il 16 giugno 2026 e il Consiglio dell'UE ha dato il via libera definitivo il 29 giugno 2026, con pubblicazione in Gazzetta Ufficiale prevista a luglio. Il pacchetto non tocca l'architettura dell'Act, l'approccio risk-based resta. Sposta le scadenze più impegnative e introduce alcuni interventi mirati. - **Obblighi alto rischio posticipati.** I sistemi stand-alone dell'Allegato III (HR, credito, istruzione e simili) passano dal 2 agosto 2026 al 2 dicembre 2027. I sistemi integrati in prodotti regolamentati dall'Allegato I passano dal 2 agosto 2027 al 2 agosto 2028. - **Nuovo divieto.** Dal 2 dicembre 2026 sono vietati i sistemi AI che generano immagini intime non consensuali o materiale pedopornografico. - **Watermarking posticipato.** L'obbligo per il provider di marcare in modo machine-readable i contenuti generati (articolo 50(2)) si applica dal 2 dicembre 2026 per i sistemi già sul mercato al 2 agosto 2026. Gli altri obblighi di trasparenza restano al 2 agosto 2026. - **Sandbox posticipate.** La scadenza per gli Stati membri per istituire almeno una sandbox regolatoria nazionale scivola al 2 agosto 2027. - **Carico più leggero per i player più piccoli.** Le esenzioni per le PMI si estendono alle small mid-cap, e la base giuridica per il trattamento di dati sensibili al solo fine di correzione dei bias viene ampliata, con un requisito stretto di necessità. I mesi guadagnati vanno spesi su valutazione di conformità, documentazione tecnica e disegno della sorveglianza umana, non archiviati come tempo libero. ## La timeline aggiornata da mettere in agenda - **2 febbraio 2025**: divieti sulle pratiche vietate e obblighi di AI literacy per il personale che usa o gestisce AI. - **2 agosto 2025**: governance UE operativa, obblighi per i modelli GPAI, regime sanzionatorio applicabile. - **2 agosto 2026**: si applica la maggior parte delle disposizioni, inclusi gli obblighi di trasparenza dell'articolo 50 e i poteri di enforcement. Non è più la data per l'alto rischio. - **2 dicembre 2026**: watermarking dei contenuti generati per i sistemi già sul mercato, ed entrata in vigore del nuovo divieto sulle immagini intime non consensuali e sul materiale pedopornografico. - **2 agosto 2027**: scadenza per gli Stati membri per istituire le sandbox regolatorie nazionali. - **2 dicembre 2027**: piena applicazione per i sistemi stand-alone ad alto rischio dell'Allegato III. - **2 agosto 2028**: applicazione ai sistemi ad alto rischio integrati in prodotti già coperti dalla legislazione UE di sicurezza, come dispositivi medici, macchinari e giocattoli. ## Sanzioni: perché il board deve prenderne carico Il regime sanzionatorio è più duro del GDPR: - Pratiche vietate: fino a 35 milioni di euro o al 7% del fatturato mondiale. - Violazioni degli obblighi sui sistemi ad alto rischio o sui GPAI: fino a 15 milioni o al 3%. - Informazioni scorrette alle autorità: fino a 7,5 milioni o all'1%. A questo si aggiungono il rischio reputazionale, quello contrattuale verso clienti enterprise che già chiedono attestazioni AI Act nei bandi, e il rischio di responsabilità civile in caso di danno. ## Roadmap a 90 giorni per un'azienda medio-grande **Giorni 0-30, snapshot.** Inventario dei sistemi AI in uso e in pipeline, con il business owner, il vendor e i dati trattati, oltre al ruolo AI Act (provider o deployer). Classificazione preliminare del rischio. Nomina di un AI compliance owner e coinvolgimento formale del board. **Giorni 30-60, gap analysis.** Per ogni sistema ad alto rischio o borderline: revisione della documentazione tecnica del vendor, valutazione della data governance, definizione di una sorveglianza umana efficace, mappatura di log e incidenti. Preparazione della Fundamental Rights Impact Assessment dove richiesta. **Giorni 60-90, piano operativo.** Policy AI aziendale, aggiornamento dei contratti con i vendor (SLA di compliance, diritti di audit, notifica incidenti), piano di AI literacy per il personale, integrazione con i sistemi di gestione esistenti come ISO 27001 e ISO 9001 e, dove ha senso, roadmap verso l'ISO/IEC 42001 come sistema di gestione AI certificabile. ## Come si integra con ISO/IEC 42001 e NIST AI RMF L'AI Act è prescrittivo e giuridicamente vincolante nell'UE. L'ISO/IEC 42001 è un sistema di gestione volontario e certificabile che fornisce l'impianto organizzativo fatto di policy, ruoli e controlli con audit interni, per rispondere agli obblighi gestionali richiesti dall'Act. Il NIST AI RMF è il framework operativo per mappare, misurare e gestire il rischio a livello di singolo sistema. Per un'azienda europea con esposizione internazionale, la combinazione più efficace tiene insieme tre livelli: l'AI Act come vincolo regolatorio, l'ISO 42001 come impianto di governance, il NIST AI RMF come metodo tecnico per gestire il rischio a livello di sistema. Il confronto puntuale dei tre framework è nel nostro approfondimento sull'AI Governance. ## Da dove partire Se il board non ha ancora una vista formale sull'AI Act, il primo passo non è comprare uno strumento: è capire dove ci si trova oggi e quali sistemi affrontare per primi. Il rinvio degli obblighi sull'alto rischio al 2027 apre una finestra utile, a patto di usarla per misurare la propria maturità e non per rinviare. La dimensione AI Risk del nostro AI Rating misura già gran parte di ciò che l'Act chiede di governare: governance, qualità dei dati, gestione del rischio e sicurezza. Un AI Rating o un assessment mirato fornisce lo snapshot iniziale e le priorità di intervento, così la compliance diventa un percorso governabile e non un'emergenza. --- # NIST AI RMF, ISO/IEC 42001 e EU AI Act: guida al confronto dei framework di AI Governance URL: https://zerofive.ai/blog/ai-governance/confronto-framework-ai-governance Data: 2026-07-15 Abstract: Confronta NIST AI RMF, ISO 42001 e EU AI Act: obblighi, certificazione e priorità. Tabella, matrice decisionale e 7 artefatti comuni per la governance AI. **In breve.** Se vendi o usi AI nella UE, l'EU AI Act non è opzionale e viene per primo: è legge. NIST AI RMF è il metodo più rapido per organizzare il rischio senza certificazione, utile nei primi mesi. ISO/IEC 42001 serve quando ti chiedono una prova esterna (gare, clienti enterprise, audit) e richiede più tempo e budget. I tre si sovrappongono su inventario dei sistemi, valutazione del rischio, controlli e documentazione: costruisci quegli artefatti una volta sola e riusali. Sotto trovi il confronto per natura, ambito, effort e certificabilità, la matrice di scelta e i 7 artefatti comuni. Adottare l'AI in azienda senza un framework di governance è come lanciare un prodotto senza QA: prima o poi paghi il conto in incidenti, sanzioni o perdita di fiducia. Nel 2025 tre riferimenti globali dominano il tema: **NIST AI RMF** (USA, volontario), **ISO/IEC 42001** (internazionale, certificabile) ed **EU AI Act** (Europa, vincolante). Non sono alternative, sono livelli complementari. Questa guida spiega cosa fa ciascuno, dove si sovrappongono e come combinarli senza duplicare lavoro. ## Le differenze in 3 righe - **EU AI Act**: legge vincolante nella UE. Se vendi o usi AI in Europa, parte da qui. - **NIST AI RMF**: metodo volontario, il più rapido da adottare. Nessuna certificazione. - **ISO/IEC 42001**: unico dei tre certificabile. Serve quando ti chiedono una prova esterna. ## I tre framework in una riga | Framework | Obbligatorio? | Natura | Effort tipico | Certificabile | Chi lo usa | |---|---|---|---|---|---| | **NIST AI RMF 1.0** | No | Linee guida volontarie | Basso (settimane) | No | Aziende che vogliono un metodo, non un certificato | | **ISO/IEC 42001:2023** | No | Standard certificabile (AIMS) | Alto (6-12 mesi) | Sì, audit di terza parte | Aziende che devono dimostrare la governance a clienti e gare | | **EU AI Act (Reg. UE 2024/1689)** | Sì, se operi in UE | Regolamento vincolante | Variabile per classe di rischio | No, ma con obblighi di conformità | Chiunque venda o usi AI in UE, a qualsiasi titolo | ## NIST AI Risk Management Framework Pubblicato dal National Institute of Standards and Technology a gennaio 2023, il **NIST AI RMF** è un framework volontario costruito attorno a quattro funzioni: **Govern, Map, Measure, Manage**. È il più agile dei tre: nessuna certificazione, nessun obbligo, ma un vocabolario condiviso per parlare di rischio AI in modo strutturato. - **Govern**: definire ruoli, policy, accountability sull'AI. - **Map**: identificare contesto, stakeholder e rischi potenziali di ciascun sistema. - **Measure**: misurare performance, bias, robustezza, spiegabilità. - **Manage**: prioritizzare, mitigare, monitorare i rischi nel tempo. È la scelta naturale come **punto di partenza**: nessuna barriera d'ingresso, si integra con qualsiasi metodologia interna, e crea la base concettuale su cui poi costruire ISO 42001 o la compliance all'AI Act. ## ISO/IEC 42001 **ISO/IEC 42001:2023** è il primo standard internazionale per un **Artificial Intelligence Management System (AIMS)**. Segue la stessa logica di ISO 27001 (sicurezza delle informazioni) o ISO 9001 (qualità): definisce requisiti verificabili per un sistema di gestione, ed è **certificabile** da enti terzi accreditati. Cosa richiede in pratica: - Policy AI approvata dal top management. - Analisi del contesto e degli stakeholder. - Valutazione d'impatto dei sistemi AI (AIIA). - Gestione del ciclo di vita: dati, sviluppo, deployment, monitoraggio, dismissione. - Audit interni e riesame della direzione (ciclo PDCA). È la scelta giusta quando serve **dimostrare** la governance a clienti, board o autorità, un certificato ISO 42001 è un asset commerciale, non solo di conformità. ## EU AI Act Il **Regolamento UE 2024/1689** è la prima legge orizzontale al mondo sull'AI. È entrato in vigore il 1° agosto 2024 con applicazione graduale: divieti dal 2 febbraio 2025, obblighi sui modelli GPAI dal 2 agosto 2025, obblighi sui sistemi ad alto rischio dal 2 agosto 2026. L'AI Act classifica i sistemi in quattro categorie di rischio: 1. **Rischio inaccettabile**, vietati (social scoring, manipolazione cognitiva, riconoscimento emotivo sul posto di lavoro, ecc.). 2. **Alto rischio**, soggetti a requisiti stringenti (risk management, data governance, documentazione tecnica, trasparenza, human oversight, accuratezza e cybersecurity). Include HR, credito, istruzione, giustizia, dispositivi medici, infrastrutture critiche. 3. **Rischio limitato**, obblighi di trasparenza (es. chatbot, deepfake). 4. **Rischio minimo**, nessun obbligo specifico. Separati, i **modelli GPAI** (General-Purpose AI) hanno un regime dedicato, con obblighi rafforzati per quelli a "rischio sistemico". Le sanzioni arrivano fino a **35 milioni di euro o al 7% del fatturato mondiale annuo**, il tetto più alto di qualsiasi regolamento digitale europeo, GDPR incluso. ## Confronto side-by-side | Dimensione | NIST AI RMF | ISO/IEC 42001 | EU AI Act | |---|---|---|---| | **Obbligatorio?** | No | No (ma certificabile) | Sì, se operi in UE | | **Certificabile?** | No | Sì, da enti accreditati | Marcatura CE per alto rischio | | **Focus** | Gestione del rischio | Sistema di gestione | Immissione sul mercato | | **Sanzioni** | Nessuna | Nessuna (perdita del certificato) | Fino a 35M€ o 7% fatturato | | **Costo di adozione** | Basso | Medio-alto | Variabile per categoria di rischio | | **Riconoscimento** | USA e globale | Internazionale | UE (extraterritoriale) | | **Aggiornamenti** | Rilasci NIST | Revisione ISO ~5 anni | Atti delegati Commissione | ## Obblighi dell'EU AI Act: cosa coprono davvero NIST e ISO L'EU AI Act è l'unico livello obbligatorio, quindi la domanda pratica è quanta parte di quegli obblighi si soddisfa già adottando NIST AI RMF o ISO/IEC 42001. | Obbligo EU AI Act (alto rischio) | NIST AI RMF | ISO/IEC 42001 | Cosa manca comunque | |---|---|---|---| | Sistema di gestione del rischio (art. 9) | Coperto (Map, Measure, Manage) | Coperto (clausola 6, valutazione del rischio AI) | Aggancio formale alle classi di rischio previste dalla legge | | Dati e governance dei dati (art. 10) | Parzialmente coperto (Map) | Coperto (controlli Annex A sui dati) | Evidenze dei test sui bias e tracciabilità della provenienza dei dataset | | Documentazione tecnica (art. 11, Allegato IV) | Non prescrittivo | Parzialmente coperto (informazioni documentate) | La struttura dell'Allegato IV, da produrre esplicitamente | | Registrazione e log (art. 12) | Parzialmente coperto (Measure) | Coperto (controllo operativo) | Periodo di conservazione e tracciabilità dei log automatici | | Trasparenza verso i deployer (art. 13) | Parzialmente coperto | Parzialmente coperto | Istruzioni per l'uso con i contenuti richiesti dalla norma | | Sorveglianza umana (art. 14) | Coperto (Govern) | Coperto (ruoli e competenze) | Ruoli di sorveglianza nominati per sistema, con potere di fermarlo | | Accuratezza, robustezza, cybersecurity (art. 15) | Coperto (Measure) | Parzialmente coperto | Metriche e soglie dichiarate per finalità d'uso | | Sistema di gestione della qualità (art. 17) | Non coperto | Coperto (è il cuore dello standard) | Nulla, se l'AIMS è in piedi | | Valutazione di conformità e marcatura CE (art. 43) | Non coperto | Non coperto | Procedura legale specifica, non sostituibile da alcun framework | | Monitoraggio post-mercato (art. 72) | Parzialmente coperto (Manage) | Coperto (monitoraggio e miglioramento) | Segnalazione degli incidenti gravi alle autorità | La lettura è questa: NIST porta il metodo, ISO porta il sistema di gestione e la prova esterna, ma nessuno dei due produce valutazione di conformità, documentazione Allegato IV e segnalazione degli incidenti. Restano lavoro legale da fare a parte. ## Dove si sovrappongono (e come sfruttarlo) I tre framework non sono in competizione: **condividono il 60-70% dei controlli**. Chi implementa uno solido ha già fatto metà del lavoro sugli altri due. Sovrapposizioni chiave: - **Risk assessment**: NIST "Map/Measure", ISO clausola 6, AI Act art. 9. - **Data governance**: NIST "Measure", ISO Allegato B, AI Act art. 10. - **Documentazione tecnica**: ISO clausola 7, AI Act art. 11 e Allegato IV. - **Human oversight**: NIST "Govern/Manage", ISO Allegato B, AI Act art. 14. - **Monitoraggio post-deployment**: NIST "Manage", ISO clausola 9, AI Act art. 72. ## Quale scegliere? Uno scenario per profilo **Startup o scale-up, prodotto AI B2B in UE.** Parti da NIST per costruire il metodo, valuta ISO 42001 quando i clienti enterprise inizieranno a chiederlo, verifica l'esposizione all'AI Act (specie se HR, healthtech, fintech, edtech). **Grande azienda regolata (banca, assicurazione, sanità, PA).** L'AI Act è il vincolo. ISO 42001 dà struttura auditabile e integra bene con ISO 27001 già in casa. NIST come vocabolario interno per il risk team. **Vendor di modelli o piattaforme AI.** L'AI Act (regime GPAI) è obbligatorio. ISO 42001 è la leva commerciale verso i clienti enterprise. NIST come baseline per il red-teaming. **PMI che integra AI di terzi.** Il rischio principale è la scelta dei fornitori. NIST come checklist di due diligence, contratti allineati agli obblighi dell'AI Act, ISO 42001 solo se e quando serve. ## Come partire senza sprecare risorse 1. **Inventario dei sistemi AI**: cosa avete, chi lo usa, che dati elabora, che decisioni prende. 2. **Classificazione rischio AI Act**: quali sistemi sono vietati, ad alto rischio, a rischio limitato. 3. **Gap analysis su NIST AI RMF**: dove siete oggi rispetto a Govern/Map/Measure/Manage. 4. **Roadmap ISO 42001** se la certificazione ha valore commerciale. 5. **Governance operativa**: policy, ruoli, comitato AI, KPI di monitoraggio. È esattamente il percorso che seguiamo in ZeroFive con l'**AI Rating** e i servizi di **AI Governance**: partiamo dalla misurazione (dove siete oggi), definiamo priorità basate sul rischio reale, e costruiamo la governance su misura, non un copia-incolla di uno standard. ## Matrice di decisione: da dove partire, per profilo aziendale | Profilo | Si parte da | Da aggiungere entro 12 mesi | Evento scatenante | Effort primi 90 giorni | |---|---|---|---|---| | Startup o scale-up con prodotto AI venduto nella UE | NIST AI RMF | Classificazione EU AI Act | Primo questionario di sicurezza enterprise | 10-15 giorni persona | | Banca, assicurazione, sanità, PA | Classificazione EU AI Act | ISO/IEC 42001 sopra ISO 27001 | Sistema ad alto rischio identificato a inventario | 30-45 giorni persona | | Vendor di modelli o piattaforme (GPAI) | Obblighi GPAI dell'AI Act | ISO/IEC 42001 | Modello immesso sul mercato UE | 25-40 giorni persona | | PMI che integra AI di terzi | NIST AI RMF come due diligence fornitori | Clausole contrattuali allineate all'art. 25 AI Act | Rinnovo fornitore o nuovo tool AI | 5-8 giorni persona | L'errore più frequente è partire dalla certificazione. La certificazione è un output, non una strategia: senza inventario e classificazione del rischio, un progetto ISO 42001 viene quotato due o tre volte tanto, perché il perimetro non è definito. ## Quanto costa davvero ciascun framework | Voce | NIST AI RMF | ISO/IEC 42001 | EU AI Act (alto rischio) | |---|---|---|---| | Effort interno, primo ciclo | 15-30 giorni persona | 60-120 giorni persona | 80-200 giorni persona per sistema | | Costo esterno | Advisory opzionale | Audit e certificazione, più advisory | Conformity assessment, organismo notificato dove richiesto | | Tempo alla prima evidenza utilizzabile | 4-6 settimane | 6-9 mesi | Legato alla scadenza del 2 agosto 2026 | | Costo ricorrente | Revisione interna | Audit di sorveglianza, ciclo triennale | Monitoraggio post-market, segnalazione incidenti | Gli intervalli valgono per un'organizzazione media con 5-15 sistemi AI in perimetro. La variabile che sposta di più il numero non è il framework: è quanti sistemi avete e quanto sono già documentati. ## Fai una volta, usa tre volte: la mappa di riuso | Artefatto prodotto | NIST AI RMF | ISO/IEC 42001 | EU AI Act | Riuso | |---|---|---|---|---| | Inventario dei sistemi AI | Map | Clausola 4, contesto | Art. 9, art. 11 | Alto | | Risk assessment per sistema | Map, Measure | Clausola 6 | Art. 9 | Alto | | Documento di data governance | Measure | Annex B | Art. 10 | Alto | | Documentazione tecnica | Manage | Clausola 7 | Art. 11, Allegato IV | Medio, l'AI Act è più stringente | | Disegno della supervisione umana | Govern, Manage | Annex B | Art. 14 | Alto | | Logging e monitoraggio | Manage | Clausola 9 | Art. 12, art. 72 | Medio, cambiano le regole di conservazione | | Procedura incidenti | Manage | Clausola 10 | Art. 73 | Medio, i 15 giorni di notifica sono specifici AI Act | Trattate questi sette artefatti come un unico corpo documentale con tre destinatari. Chi mantiene tre raccoglitori paralleli spende circa il doppio e non supera comunque gli audit, perché le versioni divergono. ## Tre domande che un board dovrebbe fare prima di approvare il budget 1. **Quanti sistemi AI usiamo davvero, compresi quelli dentro i SaaS acquistati?** Se nessuno risponde in una settimana, il progetto è l'inventario, non il framework. 2. **Quali di questi prendono o influenzano in modo rilevante decisioni sulle persone?** Sono quelli che vi portano nell'area alto rischio dell'AI Act e nell'esposizione reputazionale. 3. **Quali evidenze potremmo produrre domani se ce le chiedesse un cliente o un'autorità?** La distanza tra quello che credete e quello che potete mostrare è il vero indice di maturità. ## In sintesi - **NIST AI RMF** è il vocabolario e il metodo. - **ISO/IEC 42001** è il sistema di gestione certificabile. - **EU AI Act** è la legge che devi rispettare se operi in UE. Non sono alternative: sono livelli. Chi li tratta come opzioni mutualmente esclusive rifà tre volte lo stesso lavoro. Chi li integra costruisce una governance AI difendibile davanti a board, clienti e autorità, e ci arriva in mesi, non anni. ## Come lo affrontiamo con le aziende Tradurre questi tre livelli in un sistema che regge davanti a board, clienti e autorità è esattamente il lavoro della nostra [consulenza di AI Governance](/ai-governance). Se il tema urgente è la scadenza normativa, il percorso specifico è la [consulenza AI Act e conformità](/compliance-ai). Per capire da dove partire in concreto, l'[AI Rating](/servizi/ai-rating) misura la maturità attuale e restituisce le priorità dei primi mesi. Il quadro completo dei servizi è su [consulenza AI per aziende](/servizi). Per discutere il vostro caso: [prima call di 30 minuti](https://calendly.com/fabiolalli/zerofive). --- # "Il board ci chiede una strategia AI": da dove iniziare in 90 giorni URL: https://zerofive.ai/blog/strategia/strategia-ai-90-giorni Data: 2026-07-14 Abstract: Quando il board chiede una strategia AI, la tentazione è partire dai tool. La sequenza dei 90 giorni: misurare, scegliere, avviare la prima validazione, con i deliverable per il consiglio. La telefonata con cui si apre questa storia la riceviamo ormai ogni mese, con variazioni minime: il consiglio ha chiesto una strategia AI entro il prossimo trimestre, l'incarico è atterrato su un dirigente capace e improvvisamente solo, e la prima mossa istintiva, già in agenda, è un giro di demo con i fornitori. È la mossa che questa serie ha passato sei mesi a sconsigliare, e il pezzo che la chiude vuole offrire l'alternativa in forma eseguibile: la sequenza dei novanta giorni, con le settimane contate e i deliverable che il board si aspetta di vedere. La premessa che ordina tutto sta in una distinzione: il board non sta chiedendo un elenco di tecnologie, sta chiedendo dove l'AI serve al business, quanto costa, cosa rischia e chi risponde. A quella domanda non si risponde partendo dai tool, si risponde partendo da una fotografia. ## Settimane 1-4: la fotografia Il primo mese produce la base fattuale che rende oneste tutte le decisioni successive, e ha due cantieri paralleli. Il primo è la misurazione della maturità sulle quattro dimensioni che i lettori conoscono, Readiness, Delivery, Risk e Confidence: dove siamo pronti, dove sappiamo eseguire, cosa ci è permesso fare, chi ci crede. Il secondo è il censimento di ciò che esiste già, i progetti in corso con il loro stato vero, i sistemi in uso compresi quelli mai autorizzati, perché in oltre il 90% delle aziende, contava il MIT (2025), la shadow AI è la strategia di fatto in attesa di quella ufficiale. Il deliverable di fine mese è il punto di partenza dichiarato: il rating con i gap nominati, l'inventario, e la prima verità scomoda da portare al vertice, che quasi sempre riguarda i dati o la governance, non i modelli. ## Settimane 5-8: le scelte Il secondo mese trasforma la fotografia in un portafoglio. La discovery degli use case raccoglie i candidati da tutte le funzioni, la griglia di prioritizzazione li ordina con pesi decisi prima, il Canvas costringe i primi tre-cinque a rispondere alle sei domande su una pagina, opportunità e rischi, priorità e stakeholder, capability e dipendenze, e i criteri di go/no-go fissano le soglie che decideranno al posto delle opinioni. In parallelo parte la governance minima che non può aspettare il piano perfetto: il registro dei sistemi, le responsabilità nominate, la policy sull'uso quotidiano che trasforma la shadow AI in adozione governata. Il deliverable di fine secondo mese è il portafoglio motivato: cosa facciamo, cosa non facciamo e perché, con i no scritti accanto ai sì, perché la strategia che non scarta niente non è una strategia, è una lista dei desideri. ## Settimane 9-13: la prova e il piano Il terzo mese fa la cosa che distingue una strategia da un documento: inizia a verificarla. Il caso d'uso in cima al portafoglio entra in validazione con il protocollo che conosciamo, golden set, soglie firmate, condizioni di arresto, tre settimane; l'esito, qualunque sia, è il primo dato reale della strategia, e un no a questo stadio vale quanto un sì, perché costa settimane invece di trimestri. Intorno alla prova si chiude il resto: la roadmap a dodici-diciotto mesi con i cantieri sequenziati, il modello di misurazione che dirà ogni trimestre se il piano sta funzionando, il capitolo compliance con le scadenze vere, quelle di agosto e quelle del 2027, dentro il piano invece che accanto. Al giorno novanta, davanti al consiglio, i deliverable sono quattro: la fotografia con il rating, il portafoglio con i suoi no, l'esito della prima validazione, la roadmap con governance e misure. Nessuna promessa di trasformazione, nessun tool consigliato per fede: una posizione misurata e un piano verificabile, che è esattamente ciò che un organo di governo può approvare senza fingere di capire ciò che non gli è stato spiegato. ## La chiusura del cerchio Chi ha letto questa serie dall'inizio riconoscerà nei novanta giorni la miniatura dell'intero percorso: misurare prima, decidere poi, validare sempre, governare mentre si fa. L'abbiamo aperta a gennaio con i pilot bloccati e la chiudiamo con il loro antidoto, e con l'unico numero dell'Osservatorio del Politecnico (febbraio 2026) che vale la pena ripetere un'ultima volta: il 71% delle grandi imprese ha progetti AI, il 9% ha una governance strutturata. La strategia dei novanta giorni è, in fondo, il ponte tra quei due numeri. È anche, senza giri di parole, il lavoro che facciamo: l'intera sequenza, dal rating alla roadmap approvata, è il percorso ZeroFive, e la prima conversazione costa mezz'ora di calendario, calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Se la telefonata con cui abbiamo aperto è arrivata anche a voi, la domanda giusta per iniziare non è quale tool scegliere. È: cosa sappiamo, oggi, di dove siamo davvero? --- # AI adoption nello sport: club e federazioni partono da punti diversi URL: https://zerofive.ai/blog/strategia/ai-adoption-club-sportivi-primo-caso-uso Data: 2026-07-13 Abstract: Scouting e fan engagement hanno cicli di verifica diversi. La mappa dei casi, il costo contrattuale dei dati e l'ownership in strutture piccole. **In sintesi.** In un club sportivo le due aree con più valore atteso sono lo scouting e la relazione con il pubblico, e hanno profili di rischio opposti: lo scouting su atleti professionisti ricade tra i sistemi di gestione dei lavoratori, il fan engagement resta a rischio basso. Il primo caso d'uso conviene prenderlo dal secondo gruppo, anche quando il primo sembra più strategico. La ragione non è prudenza, è che i ricavi commerciali sono misurabili in una stagione mentre l'impatto tecnico richiede anni. Nelle società sportive la conversazione sull'AI parte quasi sempre dal campo, perché è lì che si misura il successo del club. È anche l'area dove è più difficile dimostrare che un modello ha aggiunto qualcosa al giudizio di chi guarda le partite da vent'anni. ## Perché il campo è difficile da misurare Un modello di scouting produce una raccomandazione, la società compra un giocatore, e il risultato si vede in due o tre stagioni, influenzato da infortuni, allenatore, spogliatoio e mercato. Attribuire quel risultato al modello è quasi impossibile, e questo rende fragile qualunque business case costruito su quel terreno. Il fan engagement funziona al contrario. Una campagna di rinnovo abbonamenti con segmentazione assistita produce un numero confrontabile con quello della stagione precedente, dentro la stagione stessa. Questo non significa che lo scouting non valga. Significa che come primo caso d'uso non permette di imparare, perché il ciclo di verifica è più lungo del ciclo di attenzione della dirigenza. ## La mappa dei casi candidati | Caso d'uso | Valore | Attrito regolamentare | Adatto come primo | |---|---|---|---| | Segmentazione per campagne su abbonati | Alto e misurabile in stagione | Basso, profilazione GDPR | Sì | | Produzione di contenuti per i canali | Medio, in tempo risparmiato | Basso, obbligo di dichiarazione | Sì | | Assistente per il servizio tifosi | Medio | Basso, articolo 50 | Sì | | Analisi video per lo staff tecnico | Medio, in ore di lavoro | Medio, dipende dall'uso | Come secondo passo | | Prezzi dinamici sui biglietti | Alto | Basso, obblighi informativi | Sì, con attenzione alla reputazione | | Raccomandazione di contenuti e prodotti sui canali diretti | Medio | Basso, profilazione GDPR | Sì | | Assistenza alle affiliate su tesseramenti e regolamenti | Alto in ore liberate | Basso, dati dei tesserati | Sì, per federazioni ed enti | | Scouting e valutazione atleti | Alto ma lento da verificare | Alto, Allegato III | No, non come primo | Sulla quinta riga vale una nota che non è normativa. I prezzi dinamici funzionano e generano reazioni nel pubblico, e nello sport la reazione del pubblico è un costo reale. La decisione va presa sapendolo. ## Il vincolo che nessuno mette a budget In un club i dati sono sparsi tra fornitori diversi: il tracking è di un fornitore, il video di un altro, il CRM di un terzo, la biglietteria di un quarto. Nessuno di questi parla con gli altri, e i contratti raramente prevedono l'esportazione. Questo è il vero costo di ingresso, e quasi mai compare nel preventivo di un progetto AI. Prima di qualunque caso d'uso interessante serve sapere quali dati la società può effettivamente usare, e questo è un lavoro contrattuale prima che tecnico. Chi parte senza averlo fatto costruisce un pilota su un'esportazione manuale che non sarà replicabile in produzione. ## Quanti tifosi conosce davvero la società La segmentazione assistita produce risultati sulla quota di pubblico che la società ha in anagrafica, e in quasi tutti i club quella quota è più piccola di quanto la dirigenza stimi. Gli abbonati sono identificati, i biglietti singoli passano spesso da rivenditori che restituiscono dati aggregati, il pubblico dei canali social appartiene alla piattaforma, gli spettatori televisivi appartengono al broadcaster. Il numero da avere prima di impostare qualunque caso d'uso commerciale è uno: quanti tifosi la società può contattare direttamente, con un consenso valido e un'anagrafica che tiene insieme biglietteria, e-commerce, app e newsletter. Se quel numero è basso conviene spendere il primo budget sulla raccolta e l'unificazione del dato, prima di qualunque modello. Vale anche il contrario. Una società con una base identificata ampia ha già in casa la condizione che rende misurabile il primo caso d'uso, e spesso non lo sa, perché quel dato vive dentro quattro sistemi che nessuno ha mai messo in fila. ## Nelle federazioni si parte dall'amministrazione Una federazione ha una struttura di ricavi diversa da quella di un club e un carico amministrativo molto più pesante, quindi il primo caso d'uso cambia. Il valore misurabile sta nelle richieste che arrivano dalle società affiliate: tesseramenti da controllare, documenti da leggere, regolamenti da interpretare, scadenze da far rispettare. Il vantaggio di questo terreno è che il volume è noto e stagionale. Una federazione sa quante pratiche arrivano tra luglio e settembre e quante ore servono per smaltirle, e questo rende la baseline facile da costruire. Resta un limite da mettere a bilancio. Il dato amministrativo contiene informazioni su minori e certificati medici, e questo alza i requisiti sul trattamento anche quando il caso d'uso sembra innocuo. Un assistente che legge pratiche di tesseramento lavora su dati particolari ai sensi del GDPR, con quello che ne consegue su base giuridica, accessi e tempi di conservazione. ## Cosa serve perché sia un pilota Tre elementi, definiti prima. La baseline misurata, che nello sport significa il dato della stagione precedente sullo stesso perimetro. I criteri di accettazione fissati prima di vedere i risultati. Il piano di uscita, cioè cosa succede se funziona, che in un club significa anche chi lo gestirà quando il consulente non c'è più. Su quest'ultimo punto le società sportive hanno una fragilità strutturale: gli organici sono piccoli e le competenze sono concentrate su poche persone. Un sistema che richiede presidio continuo senza qualcuno che lo faccia è un sistema che tra sei mesi non verrà usato. ## Il proprietario in una struttura piccola Il principio è lo stesso di altri settori, con una complicazione: in un club l'ownership non può stare su una persona già satura. Il direttore sportivo non ha tempo per governare una piattaforma, e l'IT spesso è una persona sola o un fornitore esterno. La soluzione praticabile è assegnare la responsabilità a chi usa il sistema ogni giorno, tipicamente il match analyst per l'area tecnica e il responsabile CRM per l'area commerciale, con un riferimento in dirigenza che risponde delle decisioni di adozione. ## Da dove partire La sequenza parte dalla mappa dei fornitori e dei dati, prima ancora che dall'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), perché in un club le due cose quasi coincidono. I criteri generali di selezione sono in [AI adoption: come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso), il modello di costo in [budget di un progetto AI](/blog/strategia/budget-progetto-ai-pilota-produzione). Il quadro normativo del settore è nella pagina [AI governance per club e organizzazioni sportive](/settori/sport). Per valutare quali casi d'uso hanno senso nella tua società puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # AI literacy nello sport: due popolazioni nei club, tre nelle federazioni URL: https://zerofive.ai/blog/compliance/ai-literacy-club-sportivi-formazione Data: 2026-07-10 Abstract: Staff tecnico e commerciale ricadono in regimi diversi. Il match analyst come ruolo critico e il nodo dei dati che appartengono ai fornitori. **In sintesi.** Un club sportivo ha due popolazioni che usano AI per scopi opposti: lo staff tecnico, che lavora su dati di atleti sotto contratto e quindi su sistemi classificati ad alto rischio, e lo staff commerciale, che lavora su contenuti e pubblico. La formazione va separata, perché gli obblighi sono diversi. Il ruolo critico è il match analyst, che nei club raramente ha una posizione formalizzata nell'organigramma e quasi mai compare in un piano formativo. Nelle federazioni e negli enti di promozione le popolazioni diventano tre, perché si aggiunge quella amministrativa, che è anche la più numerosa e la più esposta sul trattamento dei dati dei tesserati. Nelle società sportive la formazione obbligatoria esiste su sicurezza, antidoping e talvolta su integrità sportiva, e non esiste come impianto strutturato. È la differenza principale rispetto a banche e compagnie assicurative, e cambia il punto di partenza: qui non si tratta di estendere un sistema, si tratta di costruirne uno minimo. ## Due popolazioni, due regimi Lo staff tecnico lavora su sistemi che toccano atleti sotto contratto. Scouting, valutazione delle prestazioni, gestione dei carichi di lavoro: quando quei sistemi incidono su decisioni contrattuali ricadono tra i sistemi di gestione dei lavoratori dell'Allegato III, perché un atleta professionista è un lavoratore. Lo staff commerciale lavora su contenuti, ticketing e relazione con il pubblico, e su un patrimonio che nei club viene trattato come materia di marketing invece che come dato personale: l'anagrafica dei tifosi. Segmentare gli abbonati, personalizzare un'offerta, scegliere a chi mandare una campagna sono trattamenti soggetti al GDPR, con basi giuridiche da dichiarare e una questione aggiuntiva sui minori, che nel pubblico sportivo sono una quota rilevante. Sul fronte AI Act gli obblighi restano di trasparenza, principalmente l'articolo 50, e il livello di rischio è basso. Trattare le due popolazioni con lo stesso modulo produce un piano che non serve a nessuna delle due. Chi analizza le prestazioni ha bisogno di sapere quando un modello è fuori dal suo perimetro; chi gestisce i canali del club ha bisogno di sapere cosa va dichiarato come generato artificialmente. ## Nelle federazioni le popolazioni diventano tre In una federazione o in un ente di promozione sportiva alle due popolazioni se ne aggiunge una terza, ed è la più numerosa: chi lavora su tesseramenti, affiliazioni, corsi e procedimenti. Sono processi amministrativi che toccano decine di migliaia di persone, in larga parte minori, e che includono i certificati di idoneità, cioè dati sanitari. Due aree meritano attenzione specifica. La prima è la formazione dei tecnici e degli ufficiali di gara: i sistemi che determinano l'ammissione a un corso, valutano un esame o sorvegliano una prova rientrano nell'area istruzione e formazione professionale dell'Allegato III, dove la classificazione è ad alto rischio. Diverse federazioni hanno digitalizzato quei corsi senza sapere di aver toccato quel perimetro. La seconda riguarda il ruolo dell'ente. Dove la federazione agisce come organismo di diritto pubblico, sui sistemi ad alto rischio si aggiungono obblighi ulteriori, a partire dalla valutazione d'impatto sui diritti fondamentali. È una verifica giuridica da fare in anticipo, perché cambia la quantità di documentazione richiesta. ## Il match analyst e la sua assenza dai piani È la figura che sta al centro della questione e che quasi nessun club ha formalizzato. Riceve dati da fornitori esterni di analytics, li interpreta, e le sue letture entrano in decisioni su formazione, minutaggio e mercato. Su questo ruolo l'evidenza di competenza deve essere individuale, perché è la persona che esercita di fatto la sorveglianza umana sul sistema. Serve che sappia riconoscere quando il dato di un fornitore è inaffidabile, come si comporta il modello su campioni piccoli, e quando il giudizio tecnico deve prevalere sul numero. Gli altri due ruoli con evidenza individuale sono il responsabile dell'area performance, che risponde dell'uso dei dati sanitari, e chi in dirigenza approva l'adozione di una piattaforma. ## Quando i dati non sono della società Nei club quasi tutti i sistemi arrivano da fornitori: piattaforme di scouting, wearable, sistemi di tracking, strumenti di analisi video. Il club è deployer e raramente ha visibilità su come il modello è costruito o quando viene aggiornato. Questo ha una conseguenza diretta sulla formazione: non si può insegnare alle persone come funziona un sistema di cui non si conosce il funzionamento. Quello che si può e si deve fare è formarle su cosa il sistema dichiara di fare, su quali sono i suoi limiti noti, e su cosa fare quando l'output non torna. La richiesta di documentazione al fornitore diventa quindi anche un requisito formativo, non solo contrattuale. ## Cosa costruire e con quali tempi | Destinatari | Contenuto | Frequenza | |---|---|---| | Staff tecnico e match analyst | Sistemi in uso, limiti noti, quando il dato non regge, come si documenta uno scostamento | All'ingresso e a ogni cambio di piattaforma | | Area performance e medica | Trattamento dei dati sanitari, base giuridica, chi accede a cosa | Annuale | | Staff commerciale e comunicazione | Obblighi di dichiarazione sui contenuti generati, limiti sull'uso dell'immagine | Annuale | | Marketing, CRM e biglietteria | Base giuridica del trattamento dei dati dei tifosi, profilazione, consenso, trattamento dei minori | Annuale | | Tesseramento, affiliazioni e amministrazione | Dati dei tesserati, minori, certificati di idoneità, cosa può decidere un sistema automatico | Annuale | | Area formazione e qualifiche | Sistemi che valutano ammissioni ed esami per tecnici e ufficiali di gara, obblighi dell'Allegato III | All'ingresso e a ogni cambio di piattaforma | | Dirigenza | Cosa si approva quando si firma l'adozione di una piattaforma | All'ingresso e prima di ogni nuova adozione | | Operatori di stadio | Cosa è consentito sui sistemi di controllo accessi | Prima di ogni stagione | L'ultima riga è quella che i club sottovalutano di più. I sistemi di riconoscimento negli impianti sono l'area con i vincoli più forti, e chi li opera deve sapere cosa può e cosa non può fare. ## Quando formare, dentro una stagione La formazione in un club non può seguire un calendario aziendale, perché la stagione detta i tempi. Le finestre utili sono due: il ritiro precampionato, quando lo staff è concentrato e le partite non sono ancora iniziate, e la pausa invernale. Fuori da quelle finestre la formazione strutturata compete con il calendario delle partite e perde. È un vincolo pratico che conviene accettare in fase di pianificazione invece di scoprirlo a ottobre. ## Da dove partire Il prerequisito è l'inventario dei sistemi, che in un club significa soprattutto mappare i fornitori e capire quali dati escono dalla società. La guida è in [l'inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001). Da lì si separano le due popolazioni e si costruisce la matrice, descritta in [la matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai). I requisiti completi sono in [la clausola 7 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze). Il quadro normativo del settore è nella pagina [AI governance per club e organizzazioni sportive](/settori/sport). L'approccio ai percorsi per ruolo è nella pagina [AI Training](/servizi/ai-training). Per valutare la situazione della tua società puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # Checklist AI Act: l'audit interno in 10 verifiche URL: https://zerofive.ai/blog/compliance/checklist-ai-act-audit-interno Data: 2026-07-09 Abstract: Dieci verifiche con evidenze per l'audit interno AI Act prima del 2 agosto 2026: registro, classificazione, trasparenza, literacy, fornitori, log. Una settimana di lavoro. Martedì abbiamo messo in fila cosa scatta il 2 agosto e cosa slitta; oggi manteniamo la promessa del pezzo operativo. Quella che segue è la checklist che usiamo per l'audit interno rapido, dieci verifiche eseguibili in una settimana da un piccolo gruppo, compliance, IT e un process owner, con una regola che vale per tutte: la risposta non è mai "sì", è un documento. Ogni verifica indica l'evidenza che la chiude, perché un audit senza evidenze è un sondaggio, e i sondaggi il 2 agosto non difendono nessuno. ## Le fondamenta: sapere cosa avete **Verifica 1, l'inventario.** Esiste un registro dei sistemi AI, completo di quelli incorporati nei prodotti dei fornitori e di quelli entrati dal basso senza approvazione? Evidenza: il registro con data di ultimo aggiornamento e owner. Il test di completezza più rapido resta il confronto con la realtà: un giro con IT sui log di rete e sulle spese in nota trova quasi sempre sistemi che il registro ignora. **Verifica 2, la classificazione.** Ogni sistema del registro ha una classificazione di rischio con motivazione scritta, non solo un'etichetta? Evidenza: la scheda di classificazione per sistema. La motivazione è ciò che trasforma un'opinione in una posizione difendibile, ed è anche ciò che vi dice a quali sistemi si applica il rinvio al 2027. **Verifica 3, le pratiche vietate.** Qualcuno ha verificato formalmente che nessun sistema ricada nelle pratiche proibite, dal social scoring al riconoscimento delle emozioni sul lavoro? Evidenza: il verbale della verifica, con perimetro e data. È l'unico punto della lista dove il massimale sanzionatorio è il più alto e la tolleranza è zero. ## Gli obblighi che scattano adesso **Verifica 4, la trasparenza verso le persone.** I sistemi che interagiscono con clienti o dipendenti si dichiarano come AI? Evidenza: gli screenshot delle interfacce, raccolti sistema per sistema. **Verifica 5, i contenuti generati.** I contenuti prodotti o manipolati dall'AI che pubblicate sono riconoscibili come tali, con un piano per la marcatura machine-readable esigibile da dicembre? Evidenza: la policy sui contenuti e gli esempi marcati. **Verifica 6, l'alfabetizzazione.** L'obbligo dell'articolo 4 ha evidenze: chi è stato formato, su cosa, quando, con quale copertura rispetto a chi opera i sistemi? Evidenza: il piano formativo e i registri di partecipazione. Sono le tre verifiche più visibili dall'esterno, e per questo le prime che un'autorità o un segnalante possono testare senza nemmeno entrare in azienda. ## La filiera e la tenuta nel tempo **Verifica 7, i ruoli.** Per ogni sistema è scritto chi ne risponde, e la catena arriva a un punto unico che risponde al vertice? Evidenza: la matrice delle responsabilità. **Verifica 8, i fornitori.** Per i sistemi acquistati, avete la documentazione del provider, la sua classificazione, le clausole che vi servono per i vostri adempimenti di deployer? Evidenza: il fascicolo fornitore per i sistemi principali; le domande da cui partire le abbiamo pubblicate parlando di valutazione dei vendor. **Verifica 9, i dati.** Gli usi AI dei dati personali hanno base giuridica documentata e, dove serve, DPIA? Evidenza: il registro trattamenti aggiornato con gli usi AI, perché il GDPR non ha aspettato l'AI Act e la multa da 15 milioni al provider di ChatGPT (Garante, dicembre 2024) lo ha ricordato a tutti. **Verifica 10, i log e il piano.** I sistemi rilevanti conservano tracce delle proprie operazioni, e per quelli da Allegato III esiste la roadmap scritta verso dicembre 2027? Evidenza: la policy di logging e il piano con date e owner. ## Come leggere il punteggio Dieci verifiche, dieci evidenze: il conteggio di quelle che avete è la vostra fotografia, e la scala di lettura che usiamo è schietta. Sotto quattro, il problema precede l'AI Act: l'organizzazione non sa cosa possiede, e si riparte dall'inventario. Tra quattro e sette, la governance esiste a chiazze, e le settimane fino al 2 agosto bastano per chiudere le verifiche 4, 5 e 6, quelle esposte al pubblico. Da otto in su, siete nella minoranza attrezzata, e il lavoro vero è il piano della verifica 10, perché il rischio, per voi, si chiama coda del 2027 più che scadenza di agosto. L'onestà impone di dire cosa questa checklist non è: una certificazione di conformità, che nessuna lista da dieci punti può dare, e che noi per primi non promettiamo mai. È lo strumento per sapere dove siete, che è la condizione per decidere dove investire, ed è la stessa logica con cui il nostro AI Rating estende queste dieci verifiche a una gap analysis completa sulla dimensione Risk, con roadmap e priorità: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La settimana per eseguirla, da qui al 2 agosto, c'è ancora. Quante delle dieci evidenze potreste mettere sul tavolo stamattina? --- # AI Act, 2 agosto 2026: cosa scatta davvero e le azioni da fare adesso URL: https://zerofive.ai/blog/compliance/ai-act-2-agosto-2026-azioni Data: 2026-07-07 Abstract: Il 2 agosto 2026 l'AI Act diventa applicabile in via generale, con sanzioni operative e obblighi di trasparenza. Cosa resta fermo dopo l'Omnibus, cosa slitta e le azioni per le prossime quattro settimane. Mancano meno di quattro settimane al 2 agosto 2026, e intorno alla data si sono formate due narrazioni opposte, entrambe sbagliate. La prima, alimentata dai titoli sul pacchetto Omnibus digitale adottato in via definitiva a fine giugno, racconta un AI Act svuotato, con gli obblighi rinviati e la pressione rientrata. La seconda, alimentata dall'ansia da scadenza, racconta un 2 agosto in cui tutto diventa esigibile per tutti. La realtà, come spesso con questo regolamento, sta nel calendario letto riga per riga, e il calendario dice una cosa precisa: ciò che slitta riguarda una categoria, ciò che scatta riguarda tutti. ## Cosa scatta il 2 agosto, per tutti La data segna l'applicabilità generale del regolamento e la piena operatività dell'impianto sanzionatorio, con le autorità nazionali di vigilanza a regime e massimali che arrivano al 7% del fatturato globale per le pratiche vietate. Diventano esigibili gli obblighi di trasparenza dell'articolo 50, quelli che toccano il numero più grande di aziende: i sistemi che interagiscono con persone, i chatbot verso clienti in testa, devono dichiararsi; i contenuti generati o manipolati dall'AI, deepfake inclusi, vanno resi riconoscibili, con la marcatura in formato leggibile dalle macchine che diventerà esigibile dal 2 dicembre 2026. Restano naturalmente in vigore gli strati già applicabili da tempo: i divieti e l'obbligo di alfabetizzazione dal febbraio 2025, le regole sui modelli di uso generale dall'agosto 2025. Cosa slitta, invece: gli obblighi per i sistemi ad alto rischio dell'Allegato III, credit scoring, HR, accessi a servizi essenziali, si spostano al 2 dicembre 2027, e quelli per i prodotti regolamentati dell'Allegato I al 2 agosto 2028. È il cuore della revisione Omnibus, e per chi ha sistemi in quelle categorie compra tempo di adeguamento reale su documentazione tecnica, sorveglianza umana e sistemi di gestione della qualità. La lettura corretta del rinvio, però, chiede una franchezza che i sospiri di sollievo evitano: il tempo comprato serve a chi lo usa. La classificazione dei sistemi resta il prerequisito di tutto, perché senza sapere cosa cade nell'Allegato III non si sa nemmeno a cosa si applica il rinvio; i settori regolati, come abbiamo scritto per il finance, restano dentro obblighi di vigilanza che non slittano di un giorno; e le scadenze del 2027 hanno la proprietà di tutte le scadenze lontane, sembrano lontane finché non lo sono più. ## Le azioni per le prossime quattro settimane La lista per arrivare al 2 agosto in ordine è corta e verificabile. Primo: il censimento dei sistemi che interagiscono con persone o generano contenuti, dal chatbot del sito agli strumenti di marketing, con la verifica che ciascuno dichiari la propria natura dove la norma lo chiede; è l'adempimento con la superficie di esposizione più ampia, perché è visibile a chiunque, concorrenti e segnalanti inclusi. Secondo: la verifica formale, messa a verbale, dell'assenza di pratiche vietate, che sono esigibili da un anno e mezzo ma dal 2 agosto incontrano il massimale sanzionatorio pieno. Terzo: l'evidenza documentale dell'alfabetizzazione richiesta dall'articolo 4, i programmi svolti, per chi, con quali contenuti, perché è la domanda più semplice che un'autorità può fare e la più imbarazzante a cui non saper rispondere. Quarto: il registro dei sistemi aggiornato con la classificazione motivata di ciascuno, che è insieme la difesa di oggi e il piano di lavoro verso il 2027. Quinto, per chi ha sistemi da Allegato III: la roadmap verso dicembre 2027 scritta adesso, con i cantieri lunghi, dati, log, sorveglianza umana, avviati prima che la coda di consulenti e certificatori del 2027 assomigli a quella del GDPR nel 2018. Chi ha seguito questa serie riconoscerà che le cinque azioni non sono adempimenti inventati per la scadenza: sono i pezzi di governance di cui abbiamo scritto per mesi, il registro, la classificazione, la fluency, arrivati al loro appuntamento con il calendario. È la tesi con cui abbiamo aperto l'anno e che la scadenza rende verificabile: la conformità non si produce sotto deadline, si raccoglie, se la governance l'ha seminata. Il nostro AI Rating include la gap analysis su questi adempimenti nella dimensione Risk, con la roadmap dei novanta giorni che per una volta ha una data di riferimento scritta nella Gazzetta ufficiale: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E giovedì pubblichiamo il complemento operativo di questo pezzo, la checklist per l'audit interno in dieci verifiche, pensata per essere eseguita in una settimana. Il tempo, fino al 2 agosto, basta esattamente per questo. --- # AI Rating in compagnia assicurativa: il gate è il perimetro, non il processo URL: https://zerofive.ai/blog/strategia/ai-rating-assicurazioni-perimetro-gate Data: 2026-07-06 Abstract: Processi di validazione solidi su un perimetro troppo stretto. Le tre categorie di sistemi che restano fuori e cosa significa ogni classe. **In sintesi.** Nelle compagnie assicurative l'AI Rating misura le quattro dimensioni di sempre, e il profilo che emerge è diverso da quello bancario: Delivery tende a essere alta grazie alla model governance esistente, mentre Risk resta scoperta su un punto preciso, cioè i sistemi arrivati da fuori l'area attuariale che non sono mai passati dalla validazione. Il gate che blocca la classe non è la mancanza di processi, è il perimetro a cui quei processi si applicano. Il comparto arriva alla misurazione della maturità AI con un impianto di controllo più maturo di quasi tutti gli altri settori. Il risultato spesso le sorprende, perché il punteggio non riflette quella maturità. ## Le quattro dimensioni in chiave assicurativa **Readiness** misura preparazione, dati, competenze, infrastrutture. Nelle compagnie assicurative è generalmente buona sui dati di portafoglio e più debole sui dati non strutturati dei sinistri, che sono proprio quelli su cui si concentrano i casi d'uso più immediati. **Delivery** misura la capacità di portare in produzione e mantenere. È la dimensione dove il settore assicurativo sta meglio della media, perché il ciclo di vita dei modelli esiste e funziona. Il limite è che si applica ai modelli riconosciuti come tali. **Risk** misura governance, compliance ed etica. Qui si concentra lo scarto. L'Allegato III tocca il cuore del mestiere, la vigilanza IVASS è già presente, e i dati trattati sono spesso sanitari ai sensi dell'articolo 9 del GDPR. **Confidence** misura commitment della direzione, fiducia degli utenti, robustezza percepita. Nelle compagnie assicurative è spesso alta nella funzione tecnica e bassa nella rete, che usa strumenti senza sapere cosa facciano. ## Il gate che si chiude: il perimetro, non il processo Il profilo ricorrente è questo: processi di validazione solidi, applicati a un insieme di modelli più stretto di quello che il regolamento considera sistemi AI. Restano fuori tre categorie. I modelli acquistati da fornitori, dove la compagnia assicurativa è deployer e spesso non ha né documentazione tecnica né visibilità sugli aggiornamenti. Le funzionalità AI attivate dentro software gestionali già in uso, che nessuno ha mai classificato. Gli strumenti adottati da singole funzioni senza passare da un processo di adozione. Finché l'inventario non copre queste tre categorie, la dimensione Risk resta sotto soglia per quanto sia buona la validazione sui modelli interni. E poiché i gate non sono compensabili, la classe finale scende al livello del vincolo. ## Quali modelli attuariali rientrano nella definizione Il punto più discusso negli assessment assicurativi riguarda quali modelli attuariali rientrino nella definizione di sistema AI del regolamento. La definizione è più ampia di quella che le compagnie assicurative usano internamente, e la conseguenza pratica è che alcuni modelli trattati da sempre come strumenti attuariali possono ricadere nel perimetro. Rinviare quella classificazione non riduce il rischio, lo sposta: se la valutazione viene fatta da un'autorità invece che dalla compagnia assicurativa, arriva senza margine di preparazione. La risposta ragionevole è classificare per iscritto, con la motivazione, anche i casi in cui si conclude che un modello resta fuori. Quella motivazione documentata vale più della conclusione. ## Cosa significa una classe, in pratica | Classe | Situazione tipica in compagnia assicurativa | Cosa è ragionevole fare | |---|---|---| | D | Sistemi fuori dall'area attuariale non mappati, nessun presidio esteso | Costruire l'inventario completo prima di nuove adozioni | | C | Validazione solida sui modelli interni, perimetro incompleto | Estendere la model governance ai sistemi di terzi | | B | Perimetro completo, evidenze presenti, qualche area scoperta | Preparare l'audit e presidiare i sistemi in Allegato III | | A | Sistema maturo verificato su tutte le dimensioni | Riservata alle valutazioni verificate, non alle autovalutazioni | Su quest'ultima riga conviene essere espliciti: un'autovalutazione non produce una classe A, perché quella classe presuppone una verifica strutturata con evidenze controllate. ## Perché misurare prima di stanziare Una compagnia assicurativa in classe C che stanzia budget per portare l'AI sul pricing paga due volte: la prima per il progetto che non supera i presidi, la seconda per rifarlo a gate chiusi. La stessa cifra, spesa prima sull'estensione del perimetro, produce un'organizzazione in grado di assorbire i progetti successivi. È il motivo per cui il rating ha senso all'inizio del ciclo di pianificazione, non come verifica finale di quello che è già stato deciso. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), costruito sulle tre categorie che di solito restano fuori. Da lì si verifica il ruolo per ciascun sistema e si estende la valutazione dei rischi. Il modello completo, con le quattro dimensioni e la logica dei gate, è descritto nella pagina [AI Rating](/servizi/ai-rating). Il quadro normativo del settore è nella pagina [AI governance per compagnie assicurative](/settori/insurance). Per una valutazione della posizione della tua compagnia assicurativa puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # AI adoption in compagnia assicurativa: da quale caso d'uso partire URL: https://zerofive.ai/blog/strategia/ai-adoption-assicurazioni-primo-caso-uso Data: 2026-07-02 Abstract: Il caso più prezioso è anche quello in Allegato III. La mappa dei candidati, il vantaggio di model governance non sfruttato e il peso del proprietario. **In sintesi.** In una compagnia assicurativa la scelta del primo caso d'uso ha un vincolo che altrove non esiste: il processo con il valore più alto, la tariffazione vita e salute, è anche quello classificato ad alto rischio dall'Allegato III. I casi che si possono portare in produzione subito stanno sui sinistri, sul supporto alla rete e sul back office. La differenza tra chi arriva in produzione e chi resta al pilota si decide sul proprietario del sistema, non sulla tecnologia. Nelle compagnie assicurative la conversazione sull'AI parte quasi sempre dal pricing, perché è lì che si misura il risultato. È anche il punto da cui conviene non partire, per ragioni che hanno a che fare con la sequenza e non con il merito. ## Le due misure da tenere separate Valutare un caso d'uso assicurativo richiede due misure distinte, e sovrapporle è quello che allunga i progetti di mesi. La prima è il valore economico, concentrato su tariffazione, gestione dei sinistri e antifrode. La seconda è l'attrito regolamentare, cioè il lavoro di governance necessario prima della produzione. Il pricing vita e salute sta in alto su entrambe. La gestione documentale dei sinistri sta in mezzo sul valore e in basso sull'attrito, ed è il motivo per cui quasi tutti i percorsi riusciti iniziano da lì. ## La mappa dei casi candidati | Caso d'uso | Valore | Attrito regolamentare | Adatto come primo | |---|---|---|---| | Lettura e classificazione documenti di sinistro | Alto in efficienza | Basso | Sì | | Supporto alla rete su prodotti e condizioni | Medio | Basso, articolo 50 | Sì | | Ricerca su normativa e circolari interne | Medio, in tempo | Basso | Sì | | Antifrode sui sinistri | Alto | Medio, dipende dall'effetto sulla persona | Come secondo passo | | Liquidazione automatizzata di sinistri semplici | Alto | Medio-alto, incide sul diritto alla prestazione | Solo con presidi maturi | | Tariffazione vita e salute | Il più alto | Il più alto, Allegato III | No, non come primo | La riga che merita attenzione è la quinta. La liquidazione automatica di sinistri di importo contenuto sembra a basso rischio perché gli importi sono piccoli, e il criterio non è l'importo: è se il sistema incide sul riconoscimento del diritto alla prestazione. ## Il vantaggio che le compagnie assicurative non sfruttano In assicurazione esiste un impianto di model governance che poche altre organizzazioni possiedono: validazione indipendente, documentazione dei modelli, controlli di secondo livello, funzione attuariale che valida. Quell'impianto copre buona parte di quello che l'AI Act chiede sui sistemi ad alto rischio, e nella maggior parte dei casi non viene usato. Il motivo è organizzativo: i nuovi sistemi AI arrivano da funzioni diverse, spesso digital o operations, e non passano dal processo di validazione perché nessuno li ha classificati come modelli. Estendere il perimetro della model governance esistente ai sistemi AI costa meno che costruire un impianto parallelo, e produce un risultato più solido, perché quel processo è già stato messo alla prova da un'autorità di vigilanza. ## Cosa deve esistere prima di chiamarlo pilota Tre elementi vanno definiti per iscritto prima di cominciare, e il primo è la baseline del processo attuale, misurata: quante pratiche al giorno, con quale tempo medio, con quanti rilavori. Senza quel numero la valutazione finale diventa un'impressione. I criteri di accettazione, fissati prima di vedere i risultati, perché scritti dopo si adattano a qualunque esito. Il piano di uscita, cioè cosa succede se funziona. In una compagnia assicurativa il passaggio in produzione richiede integrazioni con sistemi di portafoglio e liquidazione che raramente sono stati stimati in fase di pilota. ## Il proprietario, non la tecnologia L'errore che blocca più progetti non riguarda la scelta del caso, riguarda chi ne risponde. Un sistema AI in produzione ha bisogno di una persona con nome e cognome che risponda degli esiti, e in una compagnia assicurativa quella persona sta nella funzione tecnica o nei sinistri, non nell'IT. Quando l'ownership resta all'IT il sistema viene mantenuto e non governato: nessuno decide quando è fuori perimetro, nessuno rileva una deriva, e il presidio esiste solo nelle procedure. È anche la condizione che rende debole la posizione della compagnia assicurativa se quel sistema finisce in una contestazione. ## Da dove partire La sequenza parte dall'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), costruito guardando anche ai modelli già validati, perché la definizione del regolamento è più ampia di quella che le compagnie assicurative usano internamente. Le regole di selezione sono in [AI adoption: come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso), il modello di costo dal pilota alla produzione in [budget di un progetto AI](/blog/strategia/budget-progetto-ai-pilota-produzione). Il quadro normativo del settore è nella pagina [AI governance per compagnie assicurative](/settori/insurance). Per valutare quali casi d'uso hanno senso nella tua compagnia assicurativa puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Agenti AI in azienda: cosa sono, dove funzionano, dove no URL: https://zerofive.ai/blog/approfondimenti/agenti-ai-azienda Data: 2026-07-01 Abstract: Gli agenti AI pianificano ed eseguono azioni, non solo risposte: i criteri per capire dove hanno senso, dove no, e cosa cambia per la governance quando il sistema agisce. La parola dell'anno nei board che frequentiamo è "agenti", e come ogni parola dell'anno arriva avvolta in una nebbia che conviene diradare prima di firmare budget. Un agente AI, spogliato del marketing, è un sistema che riceve un obiettivo invece di una domanda, scompone il lavoro in passi, usa strumenti, l'accesso ai sistemi, la ricerca, l'esecuzione di codice, le API aziendali, e porta avanti la sequenza correggendosi lungo la strada, con gradi variabili di autonomia dall'intervento umano. La differenza con il chatbot che tutti conoscono sta in un verbo: non risponde soltanto, agisce. Ed è quel verbo, non la tecnologia in sé, a cambiare i termini della valutazione. ## Il criterio che separa i casi buoni Chiunque venda agenti mostrerà demo impressionanti, e le demo saranno vere: la tecnologia ha fatto passi reali, e i casi in produzione esistono. La domanda utile per un decision maker non è se gli agenti funzionino, è dove le loro proprietà incontrano le proprietà del processo, e l'incontro felice ha quattro condizioni riconoscibili. Perimetro delimitato: l'agente rende bene dove il dominio è circoscritto, gli strumenti sono pochi e noti, le eccezioni hanno una via d'uscita definita, e rende male negli spazi aperti dove il buon senso deve supplire alle regole. Esito verificabile: il lavoro dell'agente deve poter essere controllato a costo basso, da una macchina o da un umano, perché un output che costa più verificarlo che produrlo azzera il guadagno. Errore reversibile: la domanda decisiva è cosa succede quando sbaglia, e la risposta deve essere "poco", perché l'agente che classifica ticket produce al peggio uno smistamento da rifare, quello che tocca pagamenti o comunicazioni verso clienti produce danni con la stessa autonomia con cui produce valore. Checkpoint umani nei punti irreversibili: i disegni che funzionano mettono l'approvazione dove l'azione smette di essere annullabile, non ovunque per ansia né in nessun posto per fede. La mappa che ne esce assomiglia poco ai proclami: i primi ritorni solidi stanno nel back office e nelle operations, triage e arricchimento di ticket, riconciliazioni, preparazione di pratiche, manutenzione di dati e documentazione, gli stessi territori dove la ricerca MIT (2025) trovava il ROI migliore e i budget minori. All'estremo opposto, l'agente con mandato ampio su processi ad alta posta e azioni irreversibili è, allo stato dell'arte, una scommessa che nessun caso in produzione serio giustifica ancora. ## Quando il sistema agisce, la governance cambia grado C'è un punto che i piani entusiasti saltano, ed è quello da cui dipende la sopravvivenza del progetto: un sistema che agisce non si governa come un sistema che risponde. Le identità e i permessi diventano il cuore del disegno, perché l'agente opera sui sistemi con credenziali proprie, e il principio del minimo privilegio smette di essere igiene informatica per diventare la differenza tra un incidente contenuto e uno strutturale. Il log delle azioni, non solo delle risposte, diventa l'evidenza che audit e regolatori chiederanno, e le condizioni di arresto, care ai lettori di questa serie, qui si fanno letterali: soglie che fermano l'agente da sole, budget di azioni per sessione, interruttori che qualcuno sa dove trovare. Anche la classificazione normativa va rifatta con occhi nuovi, perché l'autonomia sposta il profilo di rischio: lo stesso compito che da assistito era innocuo può, reso autonomo, toccare categorie e obblighi diversi, e il registro dei sistemi deve dire chi risponde delle azioni dell'agente con la stessa chiarezza con cui lo dice per un dipendente. ## La sequenza resta quella, con una prova in più Per il resto, gli agenti non meritano un metodo speciale: meritano il metodo di sempre applicato senza sconti. Il caso d'uso passa dalla prioritizzazione come gli altri, il PoC risponde alla fattibilità sul golden set, l'MVP verifica l'uso reale, con una prova aggiuntiva che per gli agenti è obbligatoria, il red teaming del perimetro: cosa fa il sistema davanti a input ostili, strumenti che falliscono, istruzioni ambigue, e quanto ci mette un umano ad accorgersene. Nella nostra catena questo vive tra PROTOT.AI per la validazione e AI Shift per la messa in produzione controllata, con i perimetri e i checkpoint firmati prima del primo giorno di autonomia: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il test per le proposte che avete sul tavolo sta in tre domande al proponente: qual è l'azione più dannosa che l'agente può compiere da solo, chi se ne accorgerebbe e in quanto tempo, come si annulla. Se le risposte arrivano precise, state parlando con qualcuno che ha progettato un agente. Se arrivano vaghe, state parlando con qualcuno che ha visto una demo. --- # AI literacy in assicurazione: perché la competenza attuariale non basta URL: https://zerofive.ai/blog/compliance/ai-literacy-assicurazioni-formazione-compagnie Data: 2026-06-30 Abstract: I tre ruoli con evidenza individuale, la rete agenziale come perimetro dimenticato e cosa si riusa dall'aggiornamento professionale già obbligatorio. **In sintesi.** In una compagnia assicurativa la formazione AI incontra una popolazione che già lavora con i modelli, e questo crea un falso senso di copertura: gli attuari sanno di modelli, ma la competenza richiesta dalla clausola 7 riguarda sistemi AI specifici e il modo in cui incidono sulle persone. I tre ruoli su cui l'evidenza deve essere individuale sono chi tariffa vita e salute, chi esercita la sorveglianza umana e chi approva l'adozione. La rete agenziale è il perimetro che quasi sempre viene dimenticato. Le compagnie assicurative partono avanti rispetto ad altri settori, perché la cultura del modello esiste da sempre. È anche il motivo per cui la formazione AI viene sottodimensionata: se in azienda ci sono attuari, sembra che la competenza ci sia già. ## Perché la competenza attuariale non copre il requisito Un attuario conosce i modelli meglio di chiunque altro in azienda, e questo non risponde a quello che la norma chiede. La clausola 7 di ISO/IEC 42001 e l'articolo 4 dell'AI Act guardano a una competenza diversa: sapere cosa fa un sistema AI specifico, riconoscere quando il suo esito va verificato, sapere a chi segnalarlo. La distanza si vede su tre punti. Il primo è il perimetro dei modelli: molti sistemi in uso oggi non nascono in area attuariale, arrivano dentro software acquistati o da fornitori esterni. Il secondo è l'effetto sulla persona, che è la lente dell'AI Act e non quella della tecnica attuariale. Il terzo è la documentazione, perché la competenza va dimostrata con evidenze collegate ai ruoli, e l'esperienza professionale non è di per sé un'evidenza ai sensi della clausola 7. ## I tre ruoli su cui l'evidenza deve essere individuale Per la maggior parte del personale serve consapevolezza. Su tre ruoli l'evidenza deve essere nominale e collegata al sistema specifico. **Chi lavora sulla tariffazione vita e salute.** L'Allegato III dell'AI Act classifica ad alto rischio la valutazione del rischio e la tariffazione in questi rami. Chi opera su quei processi deve saper riconoscere quando il modello è fuori dal suo perimetro di validità e come si documenta uno scostamento. **Chi esercita la sorveglianza umana.** L'alleggerimento dell'articolo 4 introdotto dal Digital Omnibus riguarda il livello generale di alfabetizzazione e non tocca gli obblighi di competenza per questi ruoli. La loro evidenza deve mostrare capacità di intervenire su quel sistema, non partecipazione a un corso generico. **Chi approva l'adozione.** Direzione, comitato rischi, funzione attuariale che valida. Una firma senza comprensione sposta il rilievo dalla clausola 7 alla clausola 5 sulla leadership. ## La rete agenziale, il perimetro dimenticato La clausola 7.3 parla di persone che lavorano sotto il controllo dell'organizzazione, e in assicurazione quel perimetro è più largo del libro paga. Agenti, subagenti, collaboratori di agenzia e broker convenzionati usano strumenti di preventivazione e assistenza che incorporano AI, spesso forniti dalla compagnia assicurativa stessa. Quasi nessun piano formativo li copre, perché il sistema di gestione del personale da cui il piano nasce si ferma ai dipendenti. L'auditor se ne accorge in modo indiretto, notando che una persona incontrata durante la visita non compare in nessun registro. Gli strumenti che funzionano sono due: i requisiti di competenza nelle convenzioni con la rete, e l'inclusione della rete nei percorsi già previsti dalla normativa IVASS sull'aggiornamento professionale degli intermediari, dove un modulo AI si innesta senza creare un impianto nuovo. ## Cosa si riusa e cosa va costruito | Elemento | Esiste già in compagnia assicurativa | Cosa manca per l'AI | |---|---|---| | Cultura del modello | Sì, in area attuariale | Estensione oltre l'area attuariale | | Aggiornamento professionale della rete | Sì, per obbligo IVASS | Modulo specifico sui sistemi in uso | | Governance dei modelli | Sì, per i modelli interni | Estensione ai modelli di terzi | | Formazione su dati sanitari | Sì, via GDPR | Collegamento ai sistemi AI che li trattano | | Verifica di efficacia | Test a quiz | Casi pratici sui sistemi reali | La riga che pesa di più è la terza. Molti modelli di pricing e antifrode arrivano da fornitori, e su quelli la compagnia assicurativa è deployer con obblighi propri, tra cui assicurarsi che chi li usa abbia la competenza per farlo. ## Il modulo che nessun fornitore può scrivere La parte utile della formazione richiede informazioni che ha solo la compagnia assicurativa: quali sistemi sono in produzione, su quali decisioni incidono, quali casi limite sono emersi, chi è il referente per le anomalie, cosa succede dopo una segnalazione. Sono trenta o quaranta minuti per sistema, preparati da chi quel sistema lo conosce. È anche il materiale che dimostra, in un'ispezione o in un contenzioso, che la sorveglianza umana esisteva davvero e non solo nelle procedure. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), che in una compagnia assicurativa va costruito guardando anche ai modelli attuariali già in uso, perché la definizione di sistema AI del regolamento è più ampia di quanto si assuma. Da lì si costruisce la matrice ruoli-competenze, descritta in [la matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai), e si separa la consapevolezza dalla competenza verificabile. I requisiti completi della clausola sono in [la clausola 7 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze). Il quadro normativo del settore è nella pagina [AI governance per compagnie assicurative](/settori/insurance). L'approccio con cui costruiamo i percorsi per ruolo è nella pagina [AI Training](/servizi/ai-training). Per valutare il piano della tua compagnia assicurativa puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Change management per l'AI: perché i tool non bastano URL: https://zerofive.ai/blog/approfondimenti/change-management-ai Data: 2026-06-23 Abstract: I sistemi AI installati non sono sistemi adottati: cosa distingue il change management che funziona, dove si gioca la partita dei middle manager e cosa misurare. C'è una scena che si ripete nelle aziende che visitiamo: le licenze comprate per tutti, il tool presentato al town hall con l'entusiasmo del caso, e sei mesi dopo le dashboard di utilizzo che raccontano un'altra storia, una minoranza che usa lo strumento davvero, una maggioranza che l'ha aperto due volte, e nel frattempo, sui telefoni personali, gli strumenti non autorizzati che prosperano. La ricerca del MIT Project NANDA (luglio 2025) ha fotografato il paradosso su scala: il 95% dei pilot GenAI senza impatto sul conto economico dentro le aziende, e una shadow AI fiorente in oltre il 90% delle stesse. Le persone non rifiutano l'AI, rifiutano l'AI di come gliela stiamo portando. ## Il malinteso sul cambiamento Il change management dell'AI fallisce quasi sempre per lo stesso equivoco: viene trattato come comunicazione, quando è ridisegno. La sequenza classica, annuncio, formazione a catalogo, campagna di adozione con i poster e gli ambassador, opera sulla consapevolezza e lascia intatto tutto ciò che determina il comportamento: il processo che non prevede lo strumento, gli obiettivi che premiano il vecchio modo di lavorare, il tempo che nessuno ha liberato per imparare. McKinsey, nella ricerca sullo stato dell'AI (2025), indica nel ridisegno dei flussi di lavoro il fattore con il maggiore impatto sui ritorni della GenAI, e il dato si lascia leggere anche al contrario: dove il flusso resta quello di prima con un tool appoggiato accanto, il ritorno non arriva, e l'adozione nemmeno. La seconda gamba del malinteso riguarda gli incentivi, che parlano più forte di qualunque campagna. Se la produttività guadagnata con l'AI si traduce, agli occhi delle persone, in organici a rischio o in obiettivi alzati senza contropartita, la resistenza non è irrazionale, è una lettura corretta del contratto implicito, e nessun corso di prompting la scioglie. Le organizzazioni dove l'adozione attecchisce hanno risposto prima alla domanda che tutti fanno in silenzio, cosa succede a me se questo funziona, e l'hanno fatto con impegni verificabili, non con rassicurazioni. ## Dove si gioca la partita Il punto del sistema dove il cambiamento vive o muore è il middle management, ed è anche il punto che i programmi trascurano di più, stretti come sono tra la formazione al vertice e quella operativa. I capi intermedi decidono, con cento micro-scelte al giorno, se il nuovo modo di lavorare è ammesso davvero: se il tempo per imparare è tempo legittimo o tempo rubato, se l'errore fatto con lo strumento nuovo si perdona come quello fatto col vecchio, se l'output assistito dall'AI vale in riunione. Un programma che non dà a questo strato strumenti, tempo e un motivo proprio per volere il cambiamento sta chiedendo alle persone di attraversare un ponte che i loro capi non hanno approvato. Intorno a questo centro, le pratiche che vediamo funzionare hanno poco di spettacolare: partire dai flussi dove il dolore è sentito e il beneficio è personale, non da quelli strategici sulla carta; usare i primi utenti veri come progettisti del rollout invece che come testimonial; misurare l'adozione con i numeri d'uso e di esito, non con i sondaggi di gradimento, e pubblicare quei numeri con la stessa serietà dei KPI di business. E accettare un tempo fisiologico: la curva dell'adozione reale si misura in trimestri, e i programmi dichiarati vittoriosi al mese due stanno quasi sempre misurando la curiosità, non il cambiamento. ## Il collegamento che chiude il cerchio Il lettore affezionato riconoscerà i pezzi che si incastrano qui: la fluency del vertice che sostiene il programma nei trimestri difficili, il linguaggio comune che evita che business, IT e risk si perdano per strada, la shadow AI come sintomo da leggere invece che reprimere, perché indica esattamente dove la domanda di strumenti è più forte dell'offerta ufficiale. Il change management, più che un cantiere accanto agli altri, è il tessuto connettivo, e nel nostro modello di rating vive dentro Readiness e Confidence, le due dimensioni dove i punteggi bassi predicono meglio i pilot che non scaleranno. Nella catena ZeroFive questo lavoro si chiama AI Culture, e arriva tipicamente dopo assessment e strategia per una ragione pratica: il cambiamento ha bisogno di sapere verso cosa si cambia. Per costruire il programma sulla vostra mappa reale: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il test da fare intanto costa un'ora e vale un audit: prendete il tool AI più sponsorizzato dell'ultimo anno e guardate tre numeri, gli utenti attivi settimanali contro le licenze, l'uso a novanta giorni contro l'uso al lancio, e quanti processi ufficiali lo prevedono per iscritto. Il terzo numero, quasi sempre, spiega i primi due. --- # AI Rating in banca: quale gate blocca la classe e perché URL: https://zerofive.ai/blog/strategia/ai-rating-banche-quattro-dimensioni-gate Data: 2026-06-16 Abstract: Le quattro dimensioni in chiave bancaria, il profilo tipico con Risk sotto soglia, i due gate ricorrenti e cosa significa ogni classe in termini di decisioni. **In sintesi.** In banca l'AI Rating misura le stesse quattro dimensioni di sempre, Readiness, Delivery, Risk e Confidence, e le pesa in modo diverso. Dove altrove una carenza su Risk è un'area da migliorare, qui è un gate che blocca: un'organizzazione con sistemi in Allegato III e senza inventario non può stare sopra la classe C, per quanto sia avanzata sul resto. Il risultato utile non è il punteggio, è capire quale gate è chiuso e perché. Le banche arrivano alla misurazione della maturità AI con un vantaggio e uno svantaggio. Il vantaggio è la familiarità con i sistemi di rating: nessuno deve spiegare cosa sia una classe o un gate non compensabile. Lo svantaggio è la tentazione di leggere il risultato come un voto, quando serve invece a decidere dove intervenire. ## Le quattro dimensioni, lette in chiave bancaria **Readiness** misura la preparazione: strategia, dati, competenze, infrastrutture. In banca tende a essere la dimensione più alta, perché l'impianto di data governance esiste già per ragioni prudenziali. Il punto debole ricorrente è la distanza tra la qualità dei dati nei sistemi di rischio e quella nei processi commerciali, dove nascono molti dei casi d'uso proposti. **Delivery** misura la capacità di portare in produzione e mantenere: processi di rilascio, monitoraggio, integrazione. Qui le banche si dividono nettamente. Chi ha già un ciclo di vita dei modelli strutturato per il rischio di credito parte avanti, chi ha sperimentato l'AI generativa fuori da quel perimetro scopre che il pilota non ha nessuno dei presidi che servono al passaggio in produzione. **Risk** misura governance, compliance ed etica. È la dimensione che in banca determina la classe più di tutte le altre, perché i sistemi in Allegato III alzano l'asticella e perché le autorità di vigilanza sono già presenti. **Confidence** misura commitment del board, fiducia degli utenti e robustezza percepita. Spesso è alta nelle dichiarazioni e bassa nei comportamenti, e lo scarto si vede quando si chiede chi ha firmato l'ultima decisione di adozione e su quali elementi. ## Il gate che ferma quasi tutti Nei nostri assessment il profilo bancario tipico è uno: Readiness e Confidence buone, Delivery accettabile, Risk sotto soglia. E poiché i gate non sono compensabili, la classe finale scende al livello del vincolo, non alla media. Il gate che si chiude più spesso è l'inventario dei sistemi. Non perché manchi la volontà, ma perché in una banca i sistemi AI sono arrivati per tre strade diverse, e nessuna delle tre passa da un punto unico: i modelli sviluppati internamente nell'area rischi, le funzionalità AI attivate dentro software già acquistati, e gli strumenti adottati dalle singole funzioni. Il secondo gate riguarda il ruolo assunto. Quasi tutte le banche si dichiarano deployer, e alcune non lo sono più: il fine-tuning su dati proprietari o la modifica di una soglia decisionale possono far scattare l'articolo 25 dell'AI Act, con gli obblighi dell'articolo 16. Finché quel campo non è verificato sistema per sistema, la dimensione Risk resta scoperta. ## Cosa significa una classe, in pratica | Classe | Situazione tipica in banca | Cosa è ragionevole fare | |---|---|---| | D | Sistemi in uso non mappati, nessun presidio formale | Fermare le nuove adozioni e costruire l'inventario | | C | Inventario parziale, governance dichiarata ma non attuata | Chiudere i gate prima di scalare su processi core | | B | Impianto funzionante, evidenze presenti, qualche area scoperta | Estendere ai processi ad alto rischio e preparare l'audit | | A | Sistema maturo e verificato su tutte le dimensioni | Riservata alle valutazioni verificate, non alle autovalutazioni | Su quest'ultima riga vale la pena essere espliciti: un'autovalutazione non produce una classe A, perché quella classe presuppone una verifica strutturata con evidenze controllate. Uno strumento che restituisse A in autonomia svaluterebbe il risultato di chiunque. ## Perché misurare prima di decidere il budget Il collegamento tra rating e budget è diretto. Una banca in classe C che stanzia budget per scalare l'AI sul credito sta pagando due volte: la prima per il progetto che non supererà i presidi, la seconda per rifarlo quando i gate saranno chiusi. La stessa cifra, spesa prima sulla chiusura dei gate, produce un'organizzazione che può assorbire i progetti successivi senza rifarli. È il motivo per cui il rating ha senso all'inizio del ciclo di pianificazione, non alla fine come verifica di quello che si è già deciso. ## Cosa serve per farlo sul serio Una valutazione utile richiede materiale che in banca esiste quasi sempre, sparso in funzioni diverse: l'elenco dei sistemi AI in uso o in valutazione, le procedure di validazione dei modelli già attive in area rischi, le evidenze di formazione collegate ai ruoli, i contratti con i fornitori di modelli, e i verbali delle decisioni di adozione. Raccogliere quel materiale è già metà del lavoro, e produce da solo la fotografia che molte banche non hanno mai avuto in un unico punto. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), perché senza quello il rating misura percezioni. Da lì si passa alla verifica del ruolo per ciascun sistema e alla valutazione dei rischi. Il modello completo, con le quattro dimensioni e la logica dei gate, è descritto nella pagina [AI Rating](/servizi/ai-rating). Il contesto normativo del settore, con le norme che si sovrappongono all'AI Act, è nella pagina [AI governance per banche e servizi finanziari](/settori/finance). Per una valutazione della posizione della tua banca puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # AI adoption in banca: da quale caso d'uso partire davvero URL: https://zerofive.ai/blog/strategia/ai-adoption-banche-primo-caso-uso Data: 2026-06-11 Abstract: Valore e attrito regolamentare non coincidono. La mappa dei casi d'uso bancari, il criterio che distingue un pilota da un progetto e perché il credito arriva dopo. **In sintesi.** In banca la scelta del primo caso d'uso AI viene quasi sempre fatta al contrario, partendo dal processo più visibile invece che da quello con il rapporto migliore tra valore e attrito regolamentare. I casi che generano valore rapido sono quelli interni, dove il rischio resta basso e nessuna autorità chiede conto del modello. I casi che cambiano il conto economico stanno sul credito, e lì il percorso è lungo perché passa dall'Allegato III. La domanda che arriva più spesso riguarda dove iniziare, più che se usare l'AI, e in una banca quella domanda ha un vincolo in più rispetto ad altri settori: alcuni processi sono già presidiati da modelli validati, con un impianto di governance che l'AI deve rispettare invece di scavalcare. ## Due curve che non coincidono Nel valutare un caso d'uso bancario servono due misure separate, e confonderle è l'errore che allunga i progetti. La prima è il valore economico atteso, che nella maggior parte delle banche è concentrato sul credito, sull'antifrode e sull'efficienza operativa di back office. La seconda è l'attrito regolamentare, cioè quanto lavoro di governance serve prima di poter mettere il sistema in produzione. Le due curve non coincidono. Il caso d'uso con il valore più alto, il credit scoring, ha anche l'attrito più alto, perché ricade in Allegato III con obblighi su dati, documentazione tecnica e sorveglianza umana. Il caso d'uso con l'attrito più basso, la ricerca interna su documentazione e normativa, ha un valore reale ma difficile da portare a bilancio. ## Dove parte chi arriva in produzione Nei percorsi che funzionano il primo caso d'uso quasi mai è quello strategico. È un caso interno, scelto perché permette di costruire il metodo mentre il rischio resta contenuto. | Caso d'uso | Valore | Attrito regolamentare | Adatto come primo | |---|---|---|---| | Ricerca su normativa e procedure interne | Medio, in tempo risparmiato | Basso | Sì | | Sintesi di pratiche e documentazione istruttoria | Alto in efficienza | Medio, dati dei clienti | Sì, con attenzione ai dati | | Assistenza alla rete commerciale | Medio | Basso, articolo 50 | Sì | | Antifrode e antiriciclaggio | Alto | Medio, dipende dall'effetto sulla persona | Come secondo passo | | Credit scoring | Il più alto | Il più alto, Allegato III | No, non come primo | | Chatbot verso la clientela | Medio | Basso, obblighi di trasparenza | Sì, se il perimetro è chiuso | La colonna che sorprende è la terza. Molte banche scelgono di partire dal chatbot verso la clientela perché sembra il più visibile, e scoprono che il perimetro di quello che l'assistente può dire è la parte difficile, non il modello. ## Il criterio che distingue un pilota da un progetto Un pilota vale se produce una decisione, non se produce una demo. La differenza si stabilisce prima di cominciare, definendo tre elementi che devono esistere per iscritto. Il primo è la baseline misurata del processo attuale: quanto tempo richiede, quanti errori produce, quanto costa. Senza quel numero il pilota non è confrontabile con nulla e si chiude con un giudizio di impressione. Il secondo sono i criteri di accettazione, stabiliti prima di vedere i risultati. Se vengono scritti dopo, si adattano a qualunque esito. Il terzo è il percorso di uscita, cioè cosa succede se il pilota funziona. Un pilota senza un piano di industrializzazione resta un pilota, e in banca resta tale anche per anni, perché il passaggio in produzione richiede integrazioni, presidi e documentazione che nessuno aveva messo a budget. ## Perché il credito arriva dopo, non è una rinuncia Rimandare il credit scoring non significa rinunciare al valore, significa ordinare il lavoro. Gli obblighi dell'Allegato III per i sistemi ad alto rischio si applicano dal 2 dicembre 2027 dopo il rinvio del Digital Omnibus, e quella finestra serve a costruire quello che poi verrà chiesto: tracciabilità dei dati, documentazione tecnica, sorveglianza umana progettata e non aggiunta. C'è anche una ragione pratica. Chi tocca il credit scoring con un fine-tuning su dati proprietari può ricadere tra i fornitori ai sensi dell'articolo 25 dell'AI Act, assumendo gli obblighi dell'articolo 16. È una decisione che conviene prendere sapendo cosa comporta, e non scoprirla a progetto avviato. Nel frattempo, i casi interni costruiscono esattamente le capacità che serviranno: inventario, valutazione dei rischi, competenze verificate, processo di rilascio. ## L'errore che costa di più Il più frequente non è scegliere il caso sbagliato, è scegliere il caso giusto senza un proprietario. Un sistema AI in produzione ha bisogno di una persona con nome e cognome che risponda delle decisioni che produce, e in banca quella persona sta nella funzione di business, non nell'IT. Quando l'ownership resta all'IT, il sistema viene mantenuto ma non governato: nessuno decide quando è fuori dal suo perimetro di validità, nessuno si accorge di una deriva, e il presidio esiste sulla carta. ## Da dove partire La sequenza che funziona parte dall'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), perché in quasi tutte le banche qualcosa è già in uso, spesso dentro software acquistati anni fa. Da lì si costruisce la mappa dei casi candidati con le due curve, valore e attrito, e si sceglie il primo in basso a sinistra invece che in alto a destra. I criteri di selezione in dettaglio sono in [AI adoption: come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso), il modello di costo dal pilota alla produzione in [budget di un progetto AI](/blog/strategia/budget-progetto-ai-pilota-produzione). Il quadro normativo completo del settore è nella pagina [AI governance per banche e servizi finanziari](/settori/finance). Per capire quali casi d'uso hanno senso nella tua banca puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in banca: chi formare, su cosa e con quali evidenze URL: https://zerofive.ai/blog/compliance/ai-literacy-banche-formazione-settore-finanziario Data: 2026-06-09 Abstract: Formazione AI per banche: i tre ruoli con evidenza individuale, cosa si riusa dai percorsi esistenti e perché il modello antiriciclaggio non basta. **In sintesi.** In una banca l'obbligo di alfabetizzazione AI dell'articolo 4 e i requisiti di competenza della clausola 7 di ISO/IEC 42001 incontrano una popolazione già formata su altri fronti, dall'antiriciclaggio alla MiFID II. La formazione AI che funziona non parte da zero, si innesta su quei percorsi. I ruoli critici sono tre, chi valuta il merito creditizio, chi esercita la sorveglianza umana sui modelli e chi approva le decisioni di adozione, e per loro l'evidenza deve essere individuale. Nel settore finanziario la formazione obbligatoria è una routine consolidata, con calendari, piattaforme e tracciature che esistono da anni. Questo è un vantaggio e allo stesso tempo la ragione per cui la formazione AI viene spesso impostata male, aggiunta come modulo generico dentro un impianto pensato per altro. ## Perché il modello dell'antiriciclaggio non funziona qui La formazione antiriciclaggio ha una struttura che le banche conoscono bene: contenuto uguale per fasce di ruolo, erogazione periodica, test finale, tracciatura. Trasferire quello schema sull'AI produce un piano che regge la forma e manca il sostanziale. La differenza è che le norme antiriciclaggio descrivono comportamenti da tenere, mentre i requisiti sull'AI chiedono di riconoscere quando un sistema specifico sta producendo un esito anomalo. Il primo si insegna in astratto, il secondo no. Un modulo che spiega cos'è un modello di machine learning non mette un analista in condizione di accorgersi che lo scoring sta trattando diversamente due pratiche equivalenti. C'è poi una differenza di perimetro. L'antiriciclaggio riguarda chi opera su determinati processi, mentre l'alfabetizzazione AI riguarda chiunque usi un sistema, inclusi i consulenti della rete e il personale delle società di servizi che lavorano sui vostri processi. ## I tre ruoli su cui l'evidenza deve essere individuale Per la maggior parte del personale è sufficiente la consapevolezza, cioè sapere cosa fa lo strumento che si usa e a chi segnalare un'anomalia. Tre ruoli fanno eccezione, e su quelli la documentazione deve essere nominale e collegata al sistema specifico. **Chi valuta il merito creditizio con il supporto di un modello.** Il credit scoring su persone fisiche è classificato ad alto rischio dall'Allegato III dell'AI Act, e chi lavora su quel processo deve saper leggere l'output, riconoscere i casi in cui il modello è fuori dal suo perimetro di validità e sapere come si discosta dal suggerimento. **Chi esercita la sorveglianza umana.** L'obbligo di competenza per queste persone non è stato toccato dall'alleggerimento dell'articolo 4 operato dal Digital Omnibus. Restano pieni, e la loro evidenza deve mostrare che quella persona era in grado di intervenire su quel sistema, non che ha seguito un corso sull'AI in generale. **Chi approva l'adozione di un sistema.** Direzione, comitato rischi, chi firma la messa in produzione. Una firma priva di comprensione mette in discussione il processo decisionale, e in audit il rilievo risale dalla clausola 7 alla clausola 5 sulla leadership. ## Cosa si riusa e cosa va costruito L'impianto formativo esistente copre già una parte del lavoro, e conviene mapparlo prima di comprare qualcosa di nuovo. | Elemento | Esiste già in banca | Cosa manca per l'AI | |---|---|---| | Piattaforma e tracciatura | Sì, consolidata | Collegamento tra evidenza e sistema specifico | | Formazione su decisioni automatizzate | In parte, via GDPR | Estensione ai requisiti dell'AI Act | | Cultura del model risk | Sì, in area rischi | Allargamento oltre l'area rischi | | Verifica di efficacia | Test a quiz | Casi pratici sui modelli in uso | | Perimetro esteso ai fornitori | Parziale | Requisiti nei contratti di outsourcing | La riga che costa di più è l'ultima. Molte banche esternalizzano il servizio clienti, il recupero crediti o parti dell'istruttoria, e quelle persone usano sistemi AI sui vostri processi senza rientrare nei vostri piani formativi. L'unico strumento è il contratto. ## Il modulo che nessun fornitore può scrivere La parte più utile della formazione AI in banca non si compra, perché richiede informazioni che avete solo voi: quali modelli sono in produzione, su quali decisioni incidono, quali casi limite sono già stati osservati, a chi si segnala un comportamento anomalo e cosa succede dopo. Sono trenta o quaranta minuti per sistema, preparati da chi quel sistema lo conosce, e valgono più di quattro ore di corso sulla struttura del regolamento. È anche il materiale che, in un'ispezione o in un contenzioso, dimostra che la sorveglianza umana esisteva davvero. ## Le domande dell'auditor a un analista Durante una verifica il campione segue criteri precisi: si parte dalla matrice dei ruoli e si scelgono persone che lavorano sui sistemi più esposti, chi è entrato da poco e chi ha firmato approvazioni. Le domande sono semplici e quasi sempre le stesse. Cosa fa il sistema che usi ogni giorno. Come ti accorgeresti che sta sbagliando. Cosa fai se succede. A chi lo segnali. Quando la risposta non arriva, il rilievo riguarda il sistema di gestione che ha erogato formazione senza verificarne l'efficacia, non la persona. ## Da dove partire Il punto di partenza non è il catalogo dei corsi, è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), perché senza sapere quali sistemi sono in uso e su quali processi, la formazione calibrata sul contesto resta calibrata su un'idea del contesto. Da lì si costruisce la matrice che collega ruoli e competenze, si separa quello che serve come consapevolezza da quello che serve come competenza verificabile, e si decide per quali ruoli l'evidenza deve essere individuale. Il quadro completo dei requisiti è in [la clausola 7 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze), e il rapporto tra i due obblighi in [AI literacy e competenze ISO 42001](/blog/compliance/ai-literacy-competenze-iso-42001). Il contesto normativo del settore, con la mappa completa delle norme che si sovrappongono, è nella pagina [AI governance per banche e servizi finanziari](/settori/finance). L'approccio con cui costruiamo i percorsi per ruolo è descritto nella pagina [AI Training](/servizi/ai-training). Per valutare cosa manca al piano della tua banca puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive). --- # Il linguaggio comune tra business, IT e risk: il vero collo di bottiglia URL: https://zerofive.ai/blog/approfondimenti/linguaggio-comune-business-it-risk Data: 2026-06-04 Abstract: I progetti AI rallentano dove business, IT e risk usano le stesse parole con significati diversi: i malintesi tipici, i costi e come si costruisce un glossario che funziona. Provate ad ascoltare una riunione di steering AI con l'orecchio del linguista invece che del manager, e sentirete tre lingue che si scambiano le stesse parole. Il business dice "il modello funziona" e intende che il processo migliora; l'IT dice "il modello funziona" e intende che le metriche tecniche tengono; il risk sente "funziona" e chiede rispetto a quale perimetro approvato, ricevendo in cambio sguardi. Nessuno mente, nessuno sbaglia, eppure la riunione produce un accordo apparente che si scioglierà alla prima verifica, perché le tre funzioni hanno firmato tre frasi diverse credendole una. Nei nostri assessment questo attrito linguistico compare con tale regolarità che abbiamo smesso di trattarlo come un dettaglio di comunicazione: è un collo di bottiglia operativo, con costi misurabili, e nella dimensione Readiness del rating pesa dentro la voce cultura più di quanto i piani di trasformazione gli riconoscano. ## Le parole che dividono di più Vale la pena nominare i malintesi ricorrenti, perché riconoscerli è metà del rimedio. "Validato" è il campione: per l'IT significa che i test tecnici passano, per il business che il process owner ha visto risultati accettabili, per il risk che esiste una valutazione formale con evidenze conservate, e un sistema può essere validato in due lingue su tre mentre viaggia verso un blocco. "Dato pronto" segue a ruota, con il business che intende disponibile in un report, l'IT che intende accessibile via pipeline, il risk che intende utilizzabile per quella finalità con base giuridica scritta. "Rischio" merita un capitolo suo, perché il business lo usa per la probabilità che il progetto fallisca, il risk per l'esposizione che il progetto crea anche riuscendo, e la conversazione tra i due significati è quella che decide se la compliance entra in progettazione o arriva come sorpresa finale. Perfino "pilot" divide: esperimento con condizioni di arresto per alcuni, prima release da difendere per altri, e abbiamo visto la differenza tra le due letture consumare interi trimestri. Il costo di questa Babele si presenta in forme note: riunioni che si ripetono perché l'accordo precedente non era un accordo, requisiti riscritti a metà sviluppo, la scena classica del progetto fermato dal risk "all'ultimo momento", dove l'ultimo momento è semplicemente il primo in cui qualcuno ha tradotto. ## Il glossario che funziona (e quello che no) Il rimedio ovvio, il glossario aziendale, esiste in molte organizzazioni e non funziona quasi mai, perché nasce come documento e i documenti non cambiano il parlato. Il glossario che funziona ha tre proprietà diverse. È corto, venti voci scelte tra quelle che hanno già prodotto malintesi in casa, non duecento importate da un framework. È operativo, nel senso che ogni voce definisce la parola attraverso l'evidenza che la dimostra: "validato" non ha una definizione filosofica, ha una lista di che cosa deve esistere perché la parola si possa usare. E soprattutto è incorporato negli artefatti che le tre funzioni compilano insieme, perché la lingua si impara usandola dove conta. È qui che gli strumenti di cui abbiamo scritto mostrano il loro secondo mestiere. L'AI Canvas è, tra le altre cose, un traduttore: le sei caselle costringono business, IT e risk a scrivere sulla stessa pagina con parole che tutti sottoscrivono, e la sessione di compilazione è il luogo dove i tre significati di "validato" si incontrano prima di costare. I criteri di go/no-go fanno lo stesso lavoro sulle soglie, e il registro dei sistemi sulle classificazioni. La lingua comune si costruisce meno con i corsi e più con i moduli condivisi. ## Da dove si comincia La sequenza che vediamo funzionare parte da un inventario dei malintesi già pagati: mezza giornata con le tre funzioni a ricostruire gli ultimi attriti, estraendo le parole che li hanno generati, produce il glossario grezzo e, insieme, il consenso sul fatto che serva. Seguono le venti definizioni operative, l'innesto negli artefatti, e un rituale leggero di manutenzione, perché le parole nuove arriveranno con le tecnologie nuove. È il cuore del lavoro che nella nostra catena si chiama AI Culture, il cambio di passo che separa le organizzazioni dove le funzioni si sorvegliano da quelle dove si capiscono: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. L'esperimento da fare già alla prossima riunione, intanto, costa trenta secondi e un po' di faccia: quando qualcuno dice "validato", chiedete cosa dovrebbe esistere, concretamente, perché la parola sia vera. Le tre risposte che riceverete sono la fotografia del vostro collo di bottiglia. --- # AI Rating nel retail: il gate sono i sistemi sul personale URL: https://zerofive.ai/blog/strategia/ai-rating-retail-sistemi-personale Data: 2026-05-27 Abstract: Punteggi discreti su Readiness e Delivery, Risk che cade sui sistemi di workforce management mai classificati. Quando conviene misurare. **In sintesi.** Nel retail il profilo di maturità AI presenta un'anomalia rispetto agli altri settori: le aziende ottengono punteggi discreti su Readiness e Delivery, e crollano su Risk per una ragione sola, i sistemi che gestiscono il personale. Sono arrivati dentro software di workforce management, nessuno li ha classificati, e ricadono in Allegato III. È il gate più sottovalutato di tutti quelli che incontriamo. Le insegne arrivano al rating convinte che l'AI Act le riguardi poco, perché pochi casi d'uso commerciali ricadono ad alto rischio e la narrativa di settore ha insistito su quel punto per mesi. La valutazione sposta l'attenzione dove non se l'aspettavano, sui dipendenti invece che sui clienti. Cambia la conversazione. ## Le quattro dimensioni nel retail **Readiness** misura preparazione, dati, competenze, infrastrutture. È generalmente discreta, perché i dati di vendita esistono, sono strutturati e vengono già usati. Il punto debole riguarda i dati di negozio non digitalizzati e la frammentazione tra canale fisico e online, che nella pratica significa che il dato di uno stesso cliente vive in almeno tre sistemi diversi, la cassa, l'e-commerce e il programma fedeltà, senza che esista una vista unica su cui un modello possa lavorare senza riconciliazioni manuali. **Delivery** misura la capacità di portare in produzione e mantenere. Nel retail è limitata dalla distanza tra la sede, dove i sistemi vengono scelti, e la rete, dove vengono usati. Un sistema rilasciato senza accompagnamento in negozio viene aggirato entro poche settimane, perché il personale trova una scorciatoia che funziona meglio del processo previsto e nessuno in sede se ne accorge finché i numeri non smettono di tornare. **Risk** misura governance, compliance ed etica. È la dimensione che determina la classe, e cade quasi sempre sullo stesso punto. **Confidence** misura commitment della direzione e fiducia degli utenti. Alta in sede, bassa in negozio, con uno scarto che nel retail è più ampio che altrove perché le due popolazioni si parlano poco. ## Il gate: i sistemi sul personale Il vincolo ricorrente riguarda i sistemi di pianificazione turni, assegnazione dei compiti e valutazione delle prestazioni. Sono sistemi che nel retail esistono da anni, sono stati comprati come moduli gestionali, e negli ultimi anni hanno acquisito funzionalità predittive senza che l'acquisto venisse rivalutato. Ricadono in Allegato III, perché riguardano la gestione dei lavoratori. Finché non vengono classificati come tali, mancano valutazione dei rischi, documentazione e presidio, e la dimensione Risk resta sotto soglia indipendentemente dalla qualità della governance sul resto. C'è un aggravante italiana. Su quei sistemi si sommano i vincoli del diritto del lavoro e il confronto con le rappresentanze, e un'azienda che li ha introdotti senza quel passaggio ha un problema che non si risolve con la documentazione. ## La videoanalisi, il punto che emerge tardi Molte insegne hanno impianti di videosorveglianza che nel tempo hanno acquisito funzioni di analisi: conteggio presenze, mappe di calore, in alcuni casi riconoscimento. La linea tra analisi aggregata e trattamento biometrico è più sottile di quanto si pensi, e attraversarla comporta vincoli molto forti. Nelle valutazioni questo emerge tardi, perché l'impianto è gestito dalla sicurezza fisica e non entra nei perimetri IT. ## Cosa significa una classe, in pratica | Classe | Situazione tipica nel retail | Cosa è ragionevole fare | |---|---|---| | D | Moduli AI attivi in gestionali, nessuna mappatura, personale non classificato | Mappare i sistemi partendo da quelli che toccano i dipendenti | | C | Inventario commerciale presente, sistemi HR non classificati | Classificare i sistemi sul personale e aprire il confronto interno | | B | Classificazione completa, presidio sui sistemi in Allegato III | Estendere la documentazione e verificare la videoanalisi | | A | Sistema maturo verificato su tutte le dimensioni | Riservata alle valutazioni verificate, non alle autovalutazioni | Il passaggio da C a B nel retail è insieme tecnico e relazionale, perché tocca l'organizzazione del lavoro. È anche il motivo per cui richiede tempi più lunghi di quanto la direzione si aspetti. ## Perché misurare prima del prossimo rinnovo gestionale Nel retail il momento utile coincide con il rinnovo o la sostituzione del software di gestione del personale o del gestionale di magazzino. È in quel momento che si possono chiedere al fornitore la documentazione sui moduli predittivi, la descrizione dei parametri modificabili e l'accesso ai log. Dopo la firma quelle richieste diventano rinegoziazioni, e spesso il fornitore risponde che quelle informazioni non le produce. Un'insegna che rinnova senza aver fatto la valutazione si porta dietro un sistema non classificato per tutta la durata del contratto. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), costruito partendo dai sistemi che toccano i dipendenti invece che da quelli commerciali. Il modello completo, con le quattro dimensioni e la logica dei gate, è nella pagina [AI Rating](/servizi/ai-rating). Il quadro normativo del settore è nella pagina [AI governance per il retail](/settori/retail). Per una valutazione della posizione della tua insegna puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive) oppure [avviare l'autovalutazione](/avvia-ai-rating). --- # AI fluency: perché la formazione al board viene prima di quella operativa URL: https://zerofive.ai/blog/approfondimenti/ai-fluency-formazione-board Data: 2026-05-26 Abstract: L'AI literacy è un obbligo dell'AI Act e una necessità di governo: cosa deve sapere un board, perché la sua formazione precede quella operativa e come si fa. Nei piani di formazione AI che rivediamo c'è una piramide rovesciata: corsi di prompting per centinaia di operativi, workshop per i middle manager, e per il vertice, quando va bene, un keynote ispirazionale di un'ora con le slide sul futuro. La logica implicita è che l'AI si impara usandola, quindi la formazione va a chi la usa. La logica dimenticata è che le decisioni che determinano il successo dell'adozione, quanto investire, dove, con quali rischi accettabili, quando fermarsi, si prendono tutte al vertice, e si prendono male quando chi le prende non possiede gli strumenti per interrogare ciò che gli viene proposto. Il mercato del lavoro, intanto, corre nella direzione opposta alla piramide rovesciata: l'Osservatorio Artificial Intelligence del Politecnico di Milano (ricerca 2025, febbraio 2026) registra un +93% di richieste di competenze AI negli annunci e un 41% di lavoratori che grazie all'AI svolge attività prima fuori portata. Le competenze diffuse crescono da sole, spinte dalla domanda; quelle di governo no, e sono le più scarse proprio dove servono di più. ## Un obbligo, prima ancora che una scelta C'è poi un dato normativo che molti piani di formazione ignorano: dall'articolo 4 dell'EU AI Act, in applicazione dal febbraio 2025, discende per le organizzazioni il compito di garantire un livello adeguato di alfabetizzazione all'AI per il personale che opera con questi sistemi, commisurato al contesto e al ruolo. La formula "commisurato al ruolo" è il punto che ci interessa: per chi delibera strategie, alloca capitale e risponde della governance, l'alfabetizzazione adeguata non è saper scrivere un prompt, è saper esercitare il proprio mestiere su questa materia. Un board che approva un investimento AI senza gli strumenti per valutarlo ha un problema di adempimento oltre che di qualità decisionale. ## Cosa deve sapere un board (e cosa no) L'equivoco da sciogliere è sul contenuto, perché la fluency del vertice non è una versione ridotta della formazione tecnica. Un consiglio non deve saper costruire, deve saper interrogare, e il curriculum che funziona si organizza intorno a quattro capacità. La prima è capire la natura probabilistica di questi sistemi, quanto basta per porre le domande giuste sull'errore: con quale frequenza sbaglia, su cosa, chi se ne accorge, cosa costa. La seconda è l'economia dell'AI, le cinque famiglie di costo di cui abbiamo scritto, la differenza tra un pilot e un sistema in produzione, il perché i ritorni arrivano dal ridisegno dei processi più che dallo strumento. La terza è il perimetro normativo nelle sue conseguenze gestionali, cosa comporta avere sistemi ad alto rischio, quali domande fare su dati e fornitori, quando pretendere che risk e DPO siano al tavolo. La quarta, la più preziosa, è il repertorio di domande: le dieci domande che un consigliere fa davanti a qualunque proposta AI, dal "chi ha firmato il valore atteso" al "qual è la condizione di arresto". Tutto il resto, i dettagli architetturali, le tassonomie dei modelli, le demo degli strumenti, è zavorra a questo livello, e i programmi che lo includono comprano ore di attenzione del vertice per spenderle male. ## La sequenza giusta, e cosa sblocca La formazione del vertice prima di quella operativa ha una giustificazione di sequenza, oltre che di gerarchia: sblocca tutto il resto. Un board fluente approva piani di formazione diffusa con criterio invece che a catalogo, distingue i fornitori dalle brochure, sostiene i progetti giusti nei trimestri difficili (la Confidence di cui parliamo nel rating si costruisce anche così) e smette di oscillare tra l'entusiasmo del keynote e il panico dell'articolo di giornale. Nei percorsi che seguiamo, la mezza giornata ben fatta con il consiglio vale mesi di attrito risparmiato a valle. Il formato conta quanto il contenuto: sessioni brevi e ricorrenti battono la giornata monstre, i casi dell'azienda battono gli esempi di scuola, e l'esercizio più efficace che conosciamo è la simulazione di delibera, una proposta AI vera portata in aula e smontata con il repertorio di domande. Nella nostra AI Academy i percorsi sono costruiti per livello, board, management, operativi, con questo principio di sequenza incorporato: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai per il programma. Il test per capire se il vostro vertice è già fluente, intanto, è gratuito e un po' crudele: alla prossima proposta AI in consiglio, contate le domande che vengono fatte prima dell'approvazione. Se la più tecnica riguarda il costo della licenza, la piramide è ancora rovesciata. --- # AI adoption nel retail: il caso d'uso che rende e quello che espone URL: https://zerofive.ai/blog/strategia/ai-adoption-retail-primo-caso-uso Data: 2026-05-22 Abstract: Previsione della domanda come primo caso, pricing personalizzato da valutare, sistemi sul personale da trattare come progetto a sé. **In sintesi.** Nel retail il caso d'uso con il rapporto migliore tra valore e attrito è la previsione della domanda, perché produce effetti misurabili in poche settimane e resta a rischio minimo. Il caso che attira di più è il pricing personalizzato, che tecnicamente funziona e porta con sé obblighi informativi verso il consumatore e un rischio reputazionale che raramente entra nel business case. I sistemi sul personale, quelli a rischio più alto, vengono adottati senza che nessuno li tratti come tali. Nel retail la pressione sui margini rende ogni punto percentuale interessante, e questo porta a valutare l'AI come leva di ottimizzazione più che come sistema da governare. La conseguenza è che si adotta in fretta e si classifica dopo, o mai. ## Dove il risultato si vede subito Il retail ha un vantaggio che altri settori non hanno: i cicli sono brevi. Un modello di previsione della domanda si valuta su quattro settimane di vendite, non su tre anni di sinistri o due stagioni sportive. Questo cambia la logica di adozione. Si può permettere di sbagliare il primo caso d'uso, purché si sia misurato prima, perché il costo dell'errore si recupera in fretta. È il contrario di quello che accade in manifattura o in assicurazione. La condizione è che esista una baseline. Senza il dato di partenza su rotture di stock, invenduto e margine, la valutazione a quattro settimane produce un'impressione e non un numero. ## La mappa dei casi candidati | Caso d'uso | Valore | Attrito regolamentare | Adatto come primo | |---|---|---|---| | Previsione della domanda e riassortimento | Alto e rapido da misurare | Basso | Sì | | Ottimizzazione degli spazi e assortimento | Medio-alto | Basso | Sì | | Assistente per il servizio clienti | Medio | Basso, articolo 50 | Sì | | Raccomandazione prodotti online | Medio-alto | Basso, profilazione GDPR | Sì | | Prezzi personalizzati sul singolo cliente | Alto | Medio, obblighi informativi e reputazione | Da valutare con attenzione | | Analisi video in negozio con riconoscimento | Medio | Alto, area biometrica | No | | Pianificazione turni e valutazione del personale | Medio | Alto, Allegato III | Da trattare come progetto a sé | L'ultima riga è quella che nel retail viene adottata con meno cautela di tutte, perché arriva dentro un software di workforce management e sembra una funzionalità gestionale. ## Il caso del prezzo personalizzato Vale la pena isolarlo perché genera confusione. Un sistema che adatta il prezzo al singolo cliente sulla base di dati comportamentali non è vietato, e comporta un obbligo informativo verso il consumatore: la personalizzazione basata su decisioni automatizzate va comunicata. Il punto delicato non è normativo. Nel retail la percezione di trattamento diverso tra clienti produce reazioni sproporzionate rispetto all'entità della differenza, e quelle reazioni diventano un costo commerciale reale. La decisione va presa in modo esplicito, valutando insieme il margine atteso e l'esposizione, invece di scoprire il problema quando qualcuno confronta due schermate. ## Quanti clienti riconosce davvero l'insegna La personalizzazione, in qualunque forma, produce effetti solo sulla quota di clienti che l'insegna riconosce, e nel retail fisico quella quota è quasi sempre una minoranza dello scontrinato, perché fuori dal programma fedeltà la transazione resta anonima e il modello lavora su un campione che nessuno ha scelto. Un'insegna con il trenta per cento di scontrini identificati costruisce previsioni su un terzo dei propri clienti. Prima di finanziare un caso d'uso di personalizzazione conviene misurare due numeri: la percentuale di transazioni collegate a un cliente identificato e la percentuale di quei clienti raggiungibile con un consenso valido. Il secondo è quasi sempre più basso del primo. Se entrambi sono bassi il primo budget rende di più speso sulle ragioni per cui un cliente dovrebbe farsi riconoscere in cassa, perché senza quella base ogni modello di personalizzazione lavora su una porzione troppo piccola per spostare il margine. ## Quando il pilota non si trasferisce alla rete Il perimetro giusto nel retail è un gruppo di punti vendita o una categoria merceologica, con baseline misurata sullo stesso perimetro. C'è però una cautela specifica. I negozi differiscono per bacino, superficie, assortimento e composizione della clientela, e un risultato ottenuto su dieci punti vendita selezionati non si trasferisce automaticamente su cinquecento. La selezione del campione conta quanto il modello, e un campione scelto tra i negozi che funzionano meglio produce un risultato che non si ripeterà. Il piano di uscita riguarda l'integrazione con i sistemi di cassa e con i gestionali di magazzino, che è la parte più lunga e quella che raramente entra nella stima iniziale. ## Chi risponde del sistema Nel retail l'ownership tende a finire nella funzione che ha comprato lo strumento, che spesso è marketing o IT. Per i sistemi che toccano l'assortimento il punto giusto è il category manager, per quelli che toccano il personale è la direzione risorse umane, e in quel secondo caso la responsabilità non è delegabile a un fornitore. Su questo vale una precisazione. Un sistema che assegna turni incide su condizioni di lavoro, e la persona che risponde deve poter modificare i parametri e fermare il sistema, non solo riceverne i risultati. ## Da dove partire La sequenza parte dall'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), che nel retail deve includere i moduli AI attivati dentro gestionali già in uso, a partire da quelli di workforce management. I criteri generali di selezione sono in [AI adoption: come scegliere il primo caso d'uso](/blog/strategia/ai-adoption-scegliere-primo-caso-uso), il modello di costo in [budget di un progetto AI](/blog/strategia/budget-progetto-ai-pilota-produzione). Il quadro normativo del settore è nella pagina [AI governance per il retail](/settori/retail). Per valutare quali casi d'uso hanno senso nella tua insegna puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # AI literacy nel retail: il turnover rende inutile il piano annuale URL: https://zerofive.ai/blog/compliance/ai-literacy-retail-formazione-negozi Data: 2026-05-20 Abstract: Turnover alto e piano formativo annuale non stanno insieme. L'innesco sull'onboarding, i ruoli critici in sede e la rete in franchising. **In sintesi.** Nel retail la formazione AI si scontra con il turnover, che in molte insegne supera il cinquanta per cento annuo sul personale di negozio. Un piano con cadenza annuale copre una popolazione che nel frattempo è cambiata, e questo rende inutile la struttura classica. Serve un innesco legato all'ingresso della persona e contenuti brevissimi. I ruoli con evidenza individuale stanno tutti in sede. Nel retail la formazione esiste su sicurezza, prodotto e procedure di cassa, ed è costruita per essere rapida e ripetibile, perché deve raggiungere migliaia di persone distribuite su centinaia di punti vendita e con un ricambio continuo. L'AI ci entra bene come formato e male come contenuto, perché quello che serve sapere cambia da sistema a sistema. Il formato aiuta, il contenuto no. ## Il turnover cambia il progetto Un piano formativo annuale presuppone che chi è stato formato a gennaio sia ancora lì a dicembre. Nel retail di negozio questa assunzione è falsa per una parte consistente della popolazione, e la conseguenza è che l'evidenza raccolta descrive persone che non ci sono più. L'unico meccanismo che funziona è l'innesco sull'ingresso: il modulo AI entra nell'onboarding, insieme a cassa e sicurezza, e viene erogato nei primi giorni. Dura dieci minuti, copre i sistemi che quella persona userà davvero, e viene registrato con nome e data. La revisione annuale resta, e serve per chi rimane e per aggiornare i contenuti quando i sistemi cambiano. ## I ruoli con evidenza individuale Qui il retail differisce dagli altri settori, perché i ruoli critici stanno in sede, dentro funzioni che raramente vengono considerate quando si parla di formazione AI su una rete di negozi. **Chi configura i sistemi di pianificazione del personale.** Turni, assegnazione dei compiti, valutazione delle prestazioni sono sistemi che ricadono in Allegato III, e chi li configura decide parametri che incidono su condizioni di lavoro reali. In Italia si sommano i vincoli del diritto del lavoro e il confronto con le rappresentanze. **Chi imposta le regole di personalizzazione dei prezzi.** Non per l'AI Act in senso stretto, dove il caso resta a rischio limitato, ma perché esistono obblighi informativi verso il consumatore quando il prezzo è personalizzato tramite decisione automatizzata. Chi imposta quelle regole deve sapere cosa va comunicato. **Chi gestisce il programma fedeltà e la profilazione della clientela.** Costruire i cluster di comportamento, decidere chi riceve un'offerta e scegliere quali dati alimentano quei cluster sono trattamenti soggetti al GDPR, e quando la decisione produce effetti significativi sul cliente entra in gioco anche l'articolo 22. Chi imposta quelle regole deve sapere su quale base giuridica si appoggia e cosa rispondere a un cliente che chiede perché ha ricevuto un'offerta diversa da quella del vicino di casa. Per tutto il resto della popolazione, compreso il personale di negozio, serve consapevolezza: cosa fa lo strumento, quando non fidarsi, a chi segnalare. ## Cosa deve sapere chi sta in negozio | Sistema | Cosa serve sapere | Durata | |---|---|---| | Suggerimenti di riassortimento | Che è una previsione e non un ordine, quando segnalare un'anomalia | 5 minuti | | Assistente per la clientela | Che va dichiarato come sistema automatico, cosa non può promettere | 5 minuti | | Pianificazione turni assistita | Come funziona, a chi rivolgersi per una contestazione | 10 minuti | | Analisi video in negozio | Cosa il sistema registra e cosa no, cosa dire a un cliente che chiede | 10 minuti | L'ultima riga è quella che più spesso manca del tutto, ed è quella che espone di più. Un addetto che non sa rispondere a un cliente che chiede cosa fa quella telecamera crea un problema che nessun modulo sulla privacy risolve dopo. ## La rete in franchising La clausola 7.3 copre chi usa i sistemi, e nel retail questo include le reti indirette, dove il personale del punto vendita non compare nel libro paga dell'insegna e lavora comunque tutti i giorni su strumenti che l'insegna ha scelto, configurato e distribuito. Lo strumento è il contratto di affiliazione, dove i requisiti di competenza possono essere previsti insieme all'obbligo di fornire evidenza. Molte insegne già distribuiscono formazione agli affiliati su prodotto e visual merchandising, e quel canale è lo stesso. ## Da dove partire Il prerequisito è l'[inventario dei sistemi AI](/blog/compliance/inventario-sistemi-ai-iso-42001), che nel retail deve includere i sistemi di gestione del personale, spesso classificati come strumenti HR e mai valutati come sistemi AI. Da lì si costruisce la matrice, descritta in [la matrice ruoli-competenze per l'AI](/blog/compliance/matrice-ruoli-competenze-ai), separando i pochi ruoli in sede dalla popolazione di negozio. I requisiti completi sono in [la clausola 7 spiegata senza gergo](/blog/compliance/clausola-7-iso-42001-competenze). Il quadro normativo del settore è nella pagina [AI governance per il retail](/settori/retail). L'approccio ai percorsi per ruolo è nella pagina [AI Training](/servizi/ai-training). Per valutare il piano della tua insegna puoi [fissare un incontro](https://calendly.com/fabiolalli/zerofive). --- # Quanto costa davvero un progetto AI: il TCO oltre la licenza URL: https://zerofive.ai/blog/strategia/quanto-costa-davvero-progetto-ai Data: 2026-05-19 Abstract: Il costo totale di un progetto AI va molto oltre licenze e token: prerequisiti, integrazione, compliance, persone e run. Come si costruisce un conto onesto. I business case AI che riceviamo in revisione condividono una geometria: la voce visibile, licenze o consumo di token più le giornate del fornitore, occupa il centro del foglio, e intorno c'è il bianco. Poi il progetto parte, e il bianco si popola: il dataset da bonificare che nessuno aveva prezzato, l'integrazione con il gestionale stimata in due settimane e durata quattro mesi, la valutazione privacy arrivata a sviluppo inoltrato, la formazione ridotta a un webinar e ripagata con l'inutilizzo. A consuntivo, nei progetti che analizziamo, la voce iniziale copre di rado più di un terzo del totale, e la sorpresa non sta nei numeri, sta nel fatto che continuiamo a chiamarla sorpresa. Il costo totale di possesso di un'iniziativa AI si lascia scomporre in cinque famiglie, e conoscerle prima trasforma il business case da esercizio di ottimismo a strumento di decisione. ## Prerequisiti e integrazione: il costo di arrivare al via La prima famiglia sono i prerequisiti, dominati dai dati. Rendere le fonti accessibili, misurarne la qualità, bonificare ciò che il caso d'uso richiede, costruire le pipeline che tengano pulito ciò che si è pulito: è il cantiere di cui abbiamo scritto più volte, e nei progetti su processi core capita che valga da solo quanto tutto il resto. La contabilità onesta lo mette nel conto, con un'avvertenza che lo alleggerisce: è l'unica voce che si ammortizza sui casi d'uso successivi, e un business case fatto bene lo ripartisce invece di caricarlo tutto sul primo progetto, che altrimenti non parte mai. La seconda famiglia è l'integrazione, il costo di far vivere il sistema dentro i flussi reali invece che accanto: connettori verso i sistemi esistenti, ridisegno dei passaggi di processo, gestione delle eccezioni che il flusso felice della demo non contemplava. La ricerca McKinsey sullo stato dell'AI (2025) indica nel ridisegno dei flussi di lavoro il fattore con il maggiore impatto sui ritorni della GenAI, il che rende questa voce doppiamente interessante: è tra le più sottostimate nei preventivi ed è quella più correlata al valore. ## Compliance, persone, esercizio: il costo di restare in piedi La terza famiglia è il presidio normativo, che per i sistemi in ambito AI Act ad alto rischio ha voci nominabili, documentazione tecnica, valutazioni d'impatto, disegno della sorveglianza umana, registrazioni, e per tutti gli altri comprende comunque la classificazione, l'aggiornamento del registro, l'eventuale lavoro su basi giuridiche e DPIA. Metterlo nel conto all'inizio costa ore di legale e risk; scoprirlo alla fine costa mesi di fermo, ed è una delle asimmetrie più documentate del mestiere. La quarta famiglia sono le persone: la formazione di chi userà il sistema, il tempo degli esperti di dominio per costruire golden set e validare gli output, il change management che separa un sistema installato da un sistema adottato. È la voce che i business case tagliano per prima perché è la più facile da rimandare, ed è quella la cui assenza produce il fallimento più beffardo, il sistema perfetto che nessuno usa. La quinta famiglia è l'esercizio, il costo ricorrente che inizia quando il progetto "finisce": monitoraggio di qualità e derive, aggiornamenti dei modelli con le ritarature che ne seguono, costi di inferenza che crescono con l'adozione (il paradosso del successo: più il sistema piace, più consuma), manutenzione delle integrazioni. La regola empirica che usiamo nelle revisioni: se il run annuale stimato è sotto il 20-30% del costo di costruzione, qualche voce manca. ## Il conto onesto come strumento, non come freno L'obiezione prevedibile a un TCO così composto è che gonfia i numeri e ammazza le iniziative. L'esperienza dice il contrario su entrambi i punti. I numeri non si gonfiano, si anticipano: le voci ci sono comunque, e l'unica scelta disponibile è tra vederle nel business case o nel consuntivo. E le iniziative che un conto onesto ferma sono esattamente quelle che andavano fermate, mentre quelle giuste ne escono rafforzate, con un budget difendibile davanti al board e senza la stagione delle richieste integrative che consuma più credibilità dei soldi. C'è anche un uso strategico del TCO pieno che vale la pena nominare: confrontato tra le opzioni build, buy e wait, con le cinque famiglie compilate per ciascuna, cambia spesso l'esito del bivio, perché il buy che sembrava caro smette di sembrarlo quando il build mostra il suo run perpetuo, e viceversa. Nel nostro AI Assessment i business case degli use case prioritari escono con questa struttura, cinque famiglie compilate, prerequisiti ripartiti, run stimato, ed è uno dei punti dove i clienti misurano la differenza tra un piano e una speranza: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. L'esercizio da fare intanto sull'iniziativa che avete in approvazione richiede dieci minuti: accanto alla voce visibile, scrivete le altre quattro famiglie, anche solo con un ordine di grandezza. Quale delle quattro, nel vostro foglio, era rimasta bianca? --- # Lock-in tecnologico nell'AI: exit strategy e indipendenza dai fornitori URL: https://zerofive.ai/blog/strategia/lock-in-tecnologico-ai Data: 2026-05-14 Abstract: Le quattro forme di lock-in nei progetti AI, cosa costano davvero e come progettare l'exit strategy all'ingresso: astrazione, clausole, dati portabili. C'è un momento preciso in cui il lock-in si decide, e non è quando ci si accorge di essere prigionieri: è alla firma, quando il fornitore corteggia, gli sconti fioccano e la clausola di uscita sembra un dettaglio pessimista da rimandare. Nell'AI questo vecchio meccanismo del software enterprise si è fatto più rapido e più sottile, perché le dipendenze si formano in settimane invece che in anni, e alcune non passano nemmeno dal contratto. Da posizione vendor-agnostic, il tema ci sta a cuore per una ragione di mestiere: l'indipendenza del cliente è la condizione perché le nostre raccomandazioni valgano qualcosa. ## Le quattro forme della cattività La prima forma è il lock-in comportamentale, la più nuova e la più sottovalutata. Prompt, flussi e valutazioni si tarano sul comportamento di un modello specifico, e dopo mesi di raffinamenti il sistema funziona perché quel modello risponde in quel modo: cambiare provider significa rifare la taratura, e il costo non sta in nessuna fattura, sta nei mesi di lavoro accumulato. La seconda forma è il lock-in sui dati e sugli artefatti derivati: embedding calcolati in un formato proprietario, fine-tuning che vivono solo sull'infrastruttura del provider, storici di conversazioni e feedback che escono, quando escono, in formati inservibili. La terza forma è il lock-in di piattaforma, quello classico: più il caso d'uso si integra con i servizi accessori di un ecosistema (orchestrazione, vector store, strumenti di valutazione, connettori), più l'uscita smette di essere una migrazione di modello e diventa un trasloco di architettura. La quarta è contrattuale, e vive nelle clausole che nessuno ha negoziato: prezzi rivedibili unilateralmente, preavvisi di deprecazione brevi, diritti ambigui sulle personalizzazioni costruite sopra il prodotto. Il costo della cattività, in tutte e quattro le forme, si presenta allo stesso modo: al rinnovo, quando il fornitore sa che andarsene vi costerebbe più dell'aumento, e la trattativa si fa con una parte sola che ha alternative. ## L'assicurazione si compra all'ingresso L'exit strategy efficace ha la proprietà scomoda di dover essere progettata quando nessuno ne sente il bisogno, e le sue componenti sono note. Sul piano tecnico, lo strato di astrazione di cui abbiamo scritto a proposito di infrastruttura: le applicazioni parlano con un'interfaccia interna e mai direttamente con il singolo provider, così che la sostituzione sia una configurazione. Accanto, il golden set di valutazione tenuto in casa, che trasforma la domanda "il modello alternativo funzionerebbe?" da dibattito a pomeriggio di test, e la disciplina di conservare dati, feedback e artefatti in formati portabili, con l'export provato davvero almeno una volta, perché la clausola di portabilità mai esercitata è una speranza scritta. Sul piano contrattuale, le clausole che contano si negoziano quando il fornitore vi vuole: formati e tempi di export garantiti, preavvisi minimi su deprecazioni e cambi di prezzo, proprietà chiara delle personalizzazioni, e per i carichi critici la possibilità di un secondo fornitore qualificato, anche solo tenuto caldo su una frazione del traffico, che è la forma più concreta di potere negoziale che esista. ## Quanto vale l'indipendenza, in numeri L'assicurazione ha un premio, ed è giusto dirlo: lo strato di astrazione costa ingegneria, il secondo fornitore costa gestione, i formati portabili costano disciplina. La domanda corretta riguarda meno l'azzeramento del premio e più il suo confronto con il danno atteso, e il confronto si fa con un esercizio che consigliamo di mettere in agenda una volta l'anno: per ogni dipendenza critica, stimare tempo e costo di un'uscita forzata entro novanta giorni, come si fa con i piani di continuità. Le cifre che escono, di solito, chiudono la discussione sul premio. C'è infine un equilibrio da dichiarare, perché l'indipendenza portata all'estremo diventa un costo essa stessa: costruire ogni componente in casa per non dipendere da nessuno è la forma più cara di lock-in, quella verso il proprio passato. L'obiettivo sensato non è dipendere da nessuno, è che ogni dipendenza sia scelta, misurata e reversibile a un costo noto. È il criterio con cui, nel lavoro di AI Strategy, disegniamo architetture e contratti insieme ai clienti, con l'exit strategy come requisito di progettazione e non come rimedio: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il test da fare questa settimana costa una domanda al vostro team: se il fornitore principale raddoppiasse i prezzi al prossimo rinnovo, quanto ci costerebbe davvero dirgli di no? --- # Build, buy o wait: la decisione che i CIO sbagliano più spesso URL: https://zerofive.ai/blog/strategia/build-buy-wait-decisione-ai Data: 2026-05-12 Abstract: Costruire, comprare o aspettare: i criteri per la decisione più ricorrente dell'AI aziendale, i bias che la deformano e perché il wait va scritto con una data. Ogni caso d'uso AI approvato arriva presto a un bivio a tre uscite: costruire in casa, comprare sul mercato, o aspettare. Le prime due uscite hanno lobby interne agguerrite, l'ingegneria che vuole costruire e il procurement assediato dai fornitori, mentre la terza non ha nessuno che la difenda, e questo squilibrio di rappresentanza è la prima causa degli errori che poi si contano nei portafogli. La decisione, presa bene, è un esercizio di criteri; presa come si prende di solito, è un braccio di ferro tra bias. ## Il criterio che ordina tutti gli altri La domanda che dovrebbe aprire ogni discussione build-or-buy è se la capacità in questione differenzia l'azienda sul mercato o la mantiene semplicemente operativa. La distinzione tra core e context, che Geoffrey Moore ha reso canonica, applicata all'AI produce una regola con poche eccezioni: si costruisce solo ciò che tocca il cuore del vantaggio competitivo, dove i propri dati e la propria conoscenza di dominio creano qualcosa che il mercato non può offrire a nessun altro, e si compra tutto il resto, perché nel resto il prodotto di mercato incorpora l'apprendimento di centinaia di clienti e migliora a spese loro. L'errore di classificazione più frequente pende dal lato del core: quasi ogni funzione considera differenziante il proprio processo, e il test per sgonfiare l'illusione è chiedere se un concorrente, usando lo stesso prodotto di mercato, otterrebbe lo stesso risultato. Se sì, il vantaggio non stava nel software, e costruirlo in casa produce solo un costo di manutenzione perpetuo travestito da asset. Sotto il criterio del core, gli altri fanno da tribunale di appello: la maturità dell'offerta di mercato (comprare un prodotto acerbo è un build con il fornitore sbagliato), le competenze interne reali con la loro prospettiva di ritenzione, il costo totale su tre anni dove il build paga la manutenzione per sempre e il buy paga il canone per sempre, la velocità richiesta dal business. ## Il wait, l'opzione senza lobby L'AI aggiunge al bivio classico una terza uscita che merita più rispetto di quanto riceve, perché la tecnologia sottostante ha una proprietà rara: migliora e si deprezza a velocità visibile. Capacità che dodici mesi fa richiedevano progetti su misura oggi stanno in un prodotto o dentro un modello di base, e i costi per token della stessa capacità sono scesi di multipli anno su anno. In un contesto così, aspettare sei mesi può essere la decisione con il ritorno più alto delle tre, perché il problema che oggi richiede un build domani si compra, e dopodomani è una funzione inclusa in qualcosa che avete già. Il wait legittimo, però, ha una forma precisa che lo distingue dalla procrastinazione: è una decisione scritta, con la data di riesame, le condizioni che lo farebbero terminare prima (un concorrente che si muove, un prodotto che matura, una scadenza normativa) e un owner che presidia il calendario. Ha anche un costo, che va guardato in faccia: i mesi di apprendimento organizzativo a cui si rinuncia, il vantaggio che un competitor più impaziente può accumulare. Il wait senza data e senza costo dichiarato non è un'opzione strategica, è il no-go che nessuno ha avuto il coraggio di firmare. ## I bias in azione, e la contromisura Vale la pena nominare i bias per come si presentano in comitato. Il build bias parla la lingua dell'unicità ("le nostre esigenze sono particolari") e della prudenza ("così manteniamo il controllo"), e prospera dove l'ingegneria è forte e sottoccupata. Il buy bias parla la lingua della velocità e del de-risking ("ci pensa il fornitore"), e prospera sotto pressione di budget e di trimestre. Il bias contro il wait li accomuna: in una stagione in cui "fare qualcosa con l'AI" è un imperativo reputazionale, la pazienza sembra inerzia, e nessun manager viene promosso per aver aspettato bene. La contromisura è procedurale più che psicologica: le tre opzioni si valutano sempre tutte e tre, per iscritto, sugli stessi criteri, con il costo del wait quantificato accanto agli altri due, e la decisione la firma chi possiede il conto economico del processo, non chi possiede la tecnologia o il contratto. Dove il metodo esiste, i bias non spariscono, ma smettono di decidere da soli. Nel nostro lavoro di AI Strategy il bivio a tre uscite si attraversa dentro il Canvas e il backlog, con i criteri di questo articolo resi espliciti caso per caso: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il test retrospettivo, per chi vuole misurare la propria esposizione ai bias, è guardare le ultime cinque decisioni build-or-buy prese in azienda e chiedersi quante volte il wait è stato valutato per iscritto. Se la risposta è zero, difficilmente è perché aspettare non convenisse mai. --- # Come valutare un prodotto AI prima di adottarlo: le domande da fare al vendor URL: https://zerofive.ai/blog/strategia/come-valutare-vendor-ai Data: 2026-05-05 Abstract: Le domande che separano i prodotti AI solidi dal marketing: modelli sottostanti, trattamento dei dati, evidenze di performance, AI Act e condizioni di uscita. Il procurement aziendale ha decenni di esperienza nel comprare software, e quasi nessuna nel comprare software che si comporta in modo probabilistico, cambia con gli aggiornamenti del fornitore e trascina con sé un corredo normativo in evoluzione. Il risultato si vede nelle demo: presentazioni impeccabili, sempre sugli stessi esempi, davanti a compratori che non hanno ancora un questionario all'altezza dell'oggetto. Da posizione vendor-agnostic, senza prodotti da difendere né da attaccare, abbiamo distillato le domande che nei progetti dei clienti separano i fornitori solidi da quelli che vendono una roadmap, e conviene organizzarle in cinque aree. ## Cosa c'è dentro, davvero La prima area apre la scatola. Quale parte del prodotto è AI e quale è logica tradizionale? La domanda sembra ingenua e non lo è, perché la risposta rivela subito i casi di AI washing da fornitore, il prodotto storico ribattezzato per una funzione marginale. Su quali modelli poggia, propri o di terzi, e in questo secondo caso di chi? Il fornitore controlla le versioni o eredita gli aggiornamenti del provider a monte, con i cambi di comportamento che ne seguono? Con quale preavviso comunica modifiche che toccano gli output? Un fornitore serio risponde senza reticenze, al netto dei dettagli protetti da proprietà intellettuale; uno che oppone il segreto industriale alla domanda "chi produce il modello che elaborerà i miei dati" sta chiedendo un atto di fede, e gli atti di fede nel procurement hanno un altro nome. ## Dove vanno i dati, e cosa impara il sistema La seconda area è quella dove gli errori costano di più. I vostri dati vengono usati per addestrare o migliorare modelli, del fornitore o di terzi? La risposta va pretesa per iscritto nel contratto, con la distinzione tra dati di configurazione, dati operativi e feedback degli utenti, perché le policy spesso divergono tra i tre. Dove risiedono fisicamente i dati, con quali sub-fornitori, con quali tempi di conservazione e cancellazione? Come si concilia tutto questo con GDPR e, per i casi d'uso che lo richiedono, con i vincoli di settore? Su quest'area la documentazione batte la conversazione: DPA, elenco dei sub-processori, certificazioni di sicurezza con il loro perimetro reale. Il commerciale rassicura, il contratto vincola. ## Le prove, il regolamento, l'uscita La terza area riguarda le evidenze di performance, e la regola discende da ciò che abbiamo scritto sui benchmark: le metriche del fornitore, ottenute sui casi del fornitore, contano come le brochure. La richiesta giusta è una proof of value sui vostri casi reali, con il vostro golden set, i vostri criteri di successo e una durata definita, e la disponibilità del fornitore a sostenerla è essa stessa un dato: chi ha un buon prodotto di solito non teme il banco di prova. La quarta area è normativa. Come classifica il fornitore il proprio sistema rispetto all'AI Act, con quale motivazione scritta? Quale documentazione fornisce per gli adempimenti che restano a carico vostro come deployer, dalla trasparenza verso gli utenti alla sorveglianza umana? La domanda va fatta oggi anche ai fornitori di sistemi non ad alto rischio, perché la capacità di rispondere misura la maturità della loro governance, e perché il vostro registro dei sistemi ha bisogno di quelle informazioni comunque. La quinta area guarda alla fine fin dall'inizio: in quali formati escono i vostri dati e le vostre configurazioni se il rapporto si chiude, in quanto tempo, a quale costo? Le personalizzazioni costruite sopra il prodotto restano vostre? È il tema del lock-in, che merita l'articolo a sé che gli dedicheremo, e che in fase di acquisto si riassume in un principio: le condizioni di uscita si negoziano quando il fornitore vi vuole, non quando volete andarvene. ## Il metodo oltre le domande Le domande funzionano dentro un processo, e il processo minimo ha tre proprietà. Le stesse domande a tutti i candidati, con le risposte scritte e conservate, perché la memoria delle demo è generosa con chi ha presentato meglio. Un punteggio con pesi decisi prima, per gli stessi motivi visti nella prioritizzazione degli use case. E la presenza al tavolo, fin dal primo giro, di chi userà il prodotto e di chi ne presidia i rischi, perché il costo di coinvolgerli dopo lo conoscete già. Nella nostra catena questo lavoro vive dentro l'AI Assessment e la selezione che ne segue, dove i fornitori si valutano con la stessa disciplina degli use case: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E se una trattativa è già in corso, il test più economico del mese sta in una richiesta sola: chiedete al fornitore la proof of value sui vostri dati, e guardate cosa succede alla conversazione. --- # Benchmark e valutazione dei modelli: cosa dicono davvero i numeri URL: https://zerofive.ai/blog/approfondimenti/benchmark-valutazione-modelli-ai Data: 2026-04-28 Abstract: Perché i benchmark pubblici non bastano per scegliere un modello AI in azienda, e come costruire una valutazione sui propri casi reali che regga nel tempo. Ogni rilascio di un nuovo modello segue ormai una liturgia: la tabella dei benchmark con i punteggi in grassetto dove si vince, i grafici che sorpassano il concorrente, e nei giorni successivi i comitati aziendali che chiedono se non sia il caso di migrare. La liturgia funziona perché i numeri sembrano oggettivi, e in parte lo sono; il problema è cosa misurano, e la distanza tra quel cosa e il lavoro che il modello dovrà fare nella vostra azienda. Distanza che nessuna classifica pubblica colma, e che si può colmare solo in un modo, misurando in casa. ## Cosa misurano davvero le classifiche I benchmark accademici e industriali valutano capacità generali su prove standardizzate: domande di conoscenza e ragionamento, problemi matematici, esercizi di programmazione, prove di comprensione. Sono strumenti preziosi per chi sviluppa modelli e per seguire la traiettoria del settore, e soffrono di tre limiti strutturali quando diventano criteri d'acquisto. Il primo è la contaminazione: le prove pubbliche finiscono, direttamente o per parafrasi, nei dati di addestramento, e un punteggio alto può misurare la memoria più della capacità. Il secondo è la saturazione, perché sui benchmark storici i modelli di punta si affollano ormai in pochi punti percentuali, una zona dove le differenze dicono poco e il rumore molto. Il terzo, il più importante per chi compra, è lo scarto di dominio: nessuna prova standard contiene i vostri documenti, il vostro gergo di settore, i vostri formati, le vostre soglie di errore accettabile, e la correlazione tra l'eccellenza generale e la prestazione sul vostro compito specifico esiste, ma è troppo lasca per firmarci un contratto sopra. A questi si aggiunge il limite che i numeri non catturano per costruzione: la classifica non dice nulla di latenza ai vostri volumi, costi al vostro traffico, stabilità del comportamento tra una versione e l'altra, qualità nella vostra lingua di lavoro, tutte variabili che in produzione pesano quanto la capacità. ## La valutazione che vale: il golden set L'alternativa ha un costo iniziale sorprendentemente basso e un nome preso in prestito dall'ingegneria: il golden set, un insieme curato di casi reali del vostro compito, con l'output atteso definito da chi il lavoro lo fa davvero. Per un caso d'uso tipico bastano da cinquanta a duecento esempi scelti bene, che coprano la routine, i casi limite che vi fanno male e gli errori che non potete permettervi, ciascuno con la risposta di riferimento e i criteri per giudicare le varianti accettabili. Su quel set si valuta ogni candidato nelle stesse condizioni, con metriche decise prima e tarate sul compito: dove l'output è verificabile si automatizza, dove è testo aperto si combinano revisione umana a campione e valutazione assistita, con la cautela di verificare periodicamente che il giudice automatico giudichi come giudichereste voi. Il risultato è una tabella che nessuna classifica pubblica può darvi, i modelli in gara ordinati per qualità sul vostro lavoro, con accanto costo e latenza misurati sul vostro traffico: le tre colonne su cui una decisione si firma. Il golden set, una volta costruito, continua a rendere: è il banco su cui si prova ogni nuovo modello che la liturgia dei rilasci vi metterà davanti (la migrazione diventa un pomeriggio di test invece di un dibattito), è la rete di sicurezza per verificare che un aggiornamento del provider non abbia cambiato comportamenti su cui avete costruito, ed è l'embrione del monitoraggio di qualità in produzione, dove i casi nuovi e difficili incontrati dal vivo tornano ad arricchirlo. ## La disciplina che ne discende La regola operativa che consegniamo ai clienti sta in una riga: nessuna scelta o migrazione di modello si decide su una classifica pubblica, tutte si decidono sul golden set. La classifica resta utile per un solo scopo, costruire la lista dei candidati da portare al banco di prova, e per quello basta e avanza. C'è un ostacolo pratico, ed è la fatica iniziale di costruire il set, che richiede il tempo delle persone che conoscono il compito, le più occupate per definizione. È esattamente il tipo di lavoro che nella nostra catena copre il prototyping: in poche settimane si costruiscono golden set e banco di valutazione insieme al primo prototipo, così che la scelta del modello nasca già misurata e resti misurabile: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Nel frattempo, se in azienda si sta discutendo una migrazione sull'onda dell'ultimo rilascio, una domanda riporta la conversazione a terra: su quanti dei nostri casi reali lo abbiamo provato, e chi ha giudicato le risposte? --- # Criteri go/no-go: quando dire stop a un progetto AI è un valore URL: https://zerofive.ai/blog/strategia/criteri-go-no-go-progetti-ai Data: 2026-04-21 Abstract: Come si scrivono criteri go/no-go per i progetti AI: soglie, date, decisori, e perché la capacità di fermarsi è il segno delle organizzazioni mature. Delle decine di post-mortem di progetti AI a cui abbiamo assistito, la frase che ricorre più spesso arriva sempre da qualcuno del team, mai dal verbale: "lo sapevamo da mesi". I progetti che falliscono male, quelli che bruciano diciotto mesi e la credibilità delle iniziative successive, raramente muoiono per una sorpresa; muoiono per l'assenza di un meccanismo che trasformi ciò che il team sa in una decisione che l'organizzazione prende. Quel meccanismo ha un nome poco poetico, criteri di go/no-go, e la sua assenza è tra le cause di fallimento più curabili dell'intero repertorio. C'è una ragione strutturale per cui i progetti AI ne hanno più bisogno di altri: sono esperimenti per natura, con esiti incerti che nessuna pianificazione elimina, e un esperimento senza condizioni di arresto scritte non è un esperimento, è un impegno a oltranza con un altro nome. La proposta di valore di chi fa consulenza seria, lo diciamo spesso ai clienti, include il no: un advisor che sa dire solo go è un venditore con un altro biglietto da visita. ## L'anatomia di un criterio che funziona Un criterio di go/no-go degno del nome ha quattro componenti, e ognuna mancante lo trasforma in un auspicio. La metrica, che deve essere di business o direttamente collegata (il tempo di gestione del reclamo, il tasso di adozione degli utenti, il costo per pratica), mai solo di modello, perché un'accuratezza brillante su un processo che nessuno usa supera ogni soglia tecnica e fallisce lo stesso. La soglia, con il numero scritto prima di partire, quando nessuno ha ancora interessi da difendere: sopra si prosegue, sotto si applica la conseguenza. La data, perché una soglia senza scadenza è un traguardo mobile, e "ancora un mese e ci siamo" è la lingua ufficiale dei progetti zombie. E il decisore, una persona con nome e potere di firma, perché le decisioni assegnate a un comitato hanno la proprietà di non venire mai prese da nessuno. La quinta componente, implicita ma decisiva, è il momento della scrittura: i criteri si fissano al kickoff, dentro il Canvas dell'iniziativa, insieme a sponsor e process owner. Scriverli a metà progetto è già negoziare. ## Fermare, correggere, proseguire: tre esiti, non due Il nome tradisce una semplificazione, perché gli esiti utili sono tre. Il go conferma e sblocca la fase successiva con il suo budget. Il no-go chiude, e la chiusura fatta bene ha un rito: si documenta cosa si è appreso, si archiviano dati e codice riusabili, si comunica l'esito con la stessa visibilità del lancio, perché un esperimento ben chiuso è un'informazione pagata che deve rendere. In mezzo sta il pivot, la correzione di rotta con criteri nuovi e una nuova data, che è legittima una volta e diventa accanimento alla seconda: la regola pratica che suggeriamo è un solo pivot per iniziativa, deliberato dal decisore, mai auto-concesso dal team. I criteri, poi, non vivono solo alla fine del pilot: le organizzazioni mature li mettono a ogni passaggio di fase, dall'idea al pilot, dal pilot all'MVP, dall'MVP alla produzione, con soglie via via più esigenti. È lo stesso principio dei gate critici applicato al singolo progetto, e produce lo stesso effetto: sposta le risorse da ciò che promette a ciò che dimostra. ## Rendere lo stop socialmente possibile La parte difficile dei no-go, più che tecnica, è antropologica. Il costo affondato pesa ("abbiamo già speso troppo per fermarci adesso", che è esattamente il ragionamento che moltiplica la spesa), lo sponsor ha esposto la faccia, il team teme che la chiusura del progetto significhi un giudizio sulle persone. Un'organizzazione che vuole criteri funzionanti deve disinnescare questa meccanica, e gli strumenti sono noti: separare esplicitamente la valutazione dell'esperimento da quella delle persone, celebrare pubblicamente le chiusure ben fatte quanto i lanci, misurare chi guida i progetti anche sulla velocità con cui libera risorse da ciò che non rende. Nel portafoglio, il segnale di salute è contro-intuitivo: una quota fisiologica di no-go dice che le soglie erano vere, mentre un portafoglio dove tutto supera sempre ogni gate racconta criteri scritti per essere superati. La domanda giusta a fine anno riguarda meno i progetti andati avanti e più quelli fermati: sono stati fermati al momento giusto? I criteri di decisione sono tra i deliverable del nostro lavoro di AI Strategy, scritti iniziativa per iniziativa dentro backlog e roadmap, con soglie, date e decisori: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il test da fare oggi, intanto, richiede cinque minuti e un progetto in corso: esiste, scritta da qualche parte, la condizione alla quale lo fermereste? E se domani si verificasse, chi firmerebbe? --- # On-premise, cloud o API: dove far girare l'AI aziendale URL: https://zerofive.ai/blog/approfondimenti/on-premise-cloud-api-dove-ai Data: 2026-04-16 Abstract: Le tre architetture per l'AI aziendale, API gestita, cloud dedicato, on-premise: criteri di scelta, vincoli sui dati, costi reali e assetti ibridi. Dopo la scelta del modello arriva la domanda gemella, dove farlo girare, e la risposta disegna l'assetto con cui l'azienda conviverà per anni: i costi che diventeranno struttura, le competenze da assumere, i vincoli che ogni nuovo caso d'uso erediterà. Le opzioni sul tavolo sono tre, e prima dei criteri conviene chiamarle con precisione, perché nei comitati si confondono spesso. L'API gestita: il modello vive dal provider, l'azienda consuma capacità a richiesta. Il cloud dedicato: il modello, aperto o licenziato, gira su infrastruttura noleggiata dall'azienda presso un hyperscaler, dentro un perimetro che l'azienda controlla. L'on-premise: hardware proprio, nel proprio data center, sotto la propria responsabilità fisica. La tentazione di trattarla come scelta di campo va disinnescata subito, come per i modelli: la domanda giusta è per caso d'uso, e l'assetto di arrivo delle organizzazioni mature è quasi sempre ibrido. ## Il vincolo comanda, il resto negozia Il criterio che decide per primo, quando c'è, è il vincolo non negoziabile sui dati. Esistono informazioni che per norma di settore, per clausola di committenza o per natura (si pensi a certi dati sanitari, giudiziari, di difesa) non possono attraversare confini definiti, e lì la discussione si accorcia: si sceglie tra cloud dedicato con garanzie di residenza contrattualmente solide, formule di cloud sovrano dove il settore le richiede, oppure on-premise quando nemmeno il perimetro noleggiato basta. Il lavoro serio, in questi casi, sta nel distinguere i vincoli veri da quelli presunti, perché "i nostri dati non possono stare nel cloud" è una frase che negli assessment si rivela, una volta su due, una policy mai scritta che qualcuno ricorda male. Dove il vincolo assoluto non c'è, entrano i criteri negoziabili, e il primo è il profilo di carico. L'API brilla con volumi variabili o imprevedibili, perché trasforma tutto in costo marginale; l'infrastruttura propria, noleggiata o comprata, inizia a ripagarsi con carichi alti e costanti, quando le GPU lavorano invece di aspettare. La latenza aggiunge il suo peso nei casi d'uso in linea con l'operatività (un sistema che risponde all'operatore in tempo reale tollera male i viaggi di rete), la personalizzazione profonda il suo, perché fine-tuning estesi e controllo di versione totale chiedono un'infrastruttura che si comanda. ## I costi che le slide non mostrano Il confronto economico tra le tre vie soffre di una distorsione sistematica: si confrontano i prezzi visibili, il costo per token contro il canone delle GPU, e si omettono le voci che decidono il totale. Per il cloud dedicato e l'on-premise le voci omesse sono le persone (ingegneri capaci di servire modelli con affidabilità di produzione, la figura più contesa del mercato), l'utilizzo reale dell'hardware (una GPU pagata e ferma è il costo più puro che esista), l'aggiornamento (i modelli migliorano a ritmo tale che l'infrastruttura dimensionata oggi può servire un modello obsoleto tra diciotto mesi). Per l'API la voce omessa è speculare, la crescita: il costo marginale che rendeva facile partire scala linearmente con il successo, e i casi d'uso ad alto volume vanno rifatti di conto ogni pochi mesi. La conseguenza pratica è che il punto di pareggio esiste, si sposta nel tempo, e va calcolato sui volumi propri con tutte le voci dentro. Nei conti che rivediamo, l'errore più frequente resta sottostimare le persone e sovrastimare l'utilizzo. ## L'ibrido come punto di arrivo, l'astrazione come premessa Messi in fila i criteri, l'architettura verso cui convergono le organizzazioni mature è a strati: API gestite per la lunga coda di casi d'uso a volume contenuto e per ciò che chiede capacità di frontiera, un perimetro dedicato (cloud o, più di rado, on-premise) per i carichi costanti e per i dati che non viaggiano, e una regola scritta che assegna ogni nuovo caso d'uso allo strato giusto in base a vincoli, volumi e latenza, invece che alle preferenze del team che lo propone. La premessa tecnica che rende l'ibrido governabile, e che va decisa all'inizio quando costa poco, è lo strato di astrazione: le applicazioni parlano con un'interfaccia interna, mai direttamente con il singolo provider o il singolo cluster, così che spostare un carico da uno strato all'altro sia una configurazione e non una riscrittura. È la stessa assicurazione contro il lock-in di cui parliamo a proposito dei modelli, applicata all'infrastruttura, e vale anche come posizione negoziale: si ottengono condizioni migliori da chiunque quando andarsene è tecnicamente facile. La scelta dell'assetto, in sintesi, è un esercizio di vincoli prima che di preferenze, e il modo più rapido per sbagliarla è farla per imitazione, copiando l'architettura di un'azienda con vincoli diversi dai propri. Se state disegnando la vostra, o ridiscutendo quella ereditata, il punto di partenza è l'inventario di vincoli, volumi e competenze reali: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E per il prossimo comitato, una domanda di controllo che non richiede slide: dei vincoli che oggi vi tengono lontani dal cloud, o dentro, quanti esistono per iscritto? --- # AI Canvas: strutturare una decisione AI su sei dimensioni URL: https://zerofive.ai/blog/strategia/ai-canvas-decisione-sei-dimensioni Data: 2026-04-14 Abstract: Cos'è l'AI Canvas, come funzionano le sei dimensioni (opportunità, rischi, priorità, stakeholder, capability, dipendenze) e perché una pagina batte un deck. I business case delle iniziative AI che arrivano sui tavoli di approvazione soffrono di una malattia formale: sono documenti costruiti per convincere, non per decidere. Trenta pagine dove il valore atteso occupa la copertina, i rischi stanno in un'appendice, le dipendenze non compaiono perché nessuno le ha cercate, e il comitato che li riceve può solo scegliere tra fidarsi e rinviare. L'AI Canvas nasce come contromisura a questa forma: una pagina, sei dimensioni obbligatorie, e la regola che una dimensione lasciata vuota vale come un allarme, mai come un dettaglio da completare dopo. L'idea di fondo è che la qualità di una decisione dipende dalla struttura con cui viene istruita, e che per le iniziative AI le domande giuste sono note e sono sei. Vediamole nell'ordine in cui si compilano, che ha una sua logica. ## Le prime tre: cosa, cosa può andare storto, quanto conta L'opportunità apre il Canvas e pretende una disciplina precisa: il problema di business prima della soluzione tecnica, con la metrica che migliorerebbe e la firma di chi possiede quella metrica. "Ridurre del 30% il tempo di gestione dei reclami, misurato dal responsabile operations" è un'opportunità; "usare l'AI generativa sul customer service" è una tecnologia in cerca di impiego, e il Canvas la respinge per costruzione. I rischi occupano la seconda casella con lo stesso rigore, e in quattro famiglie: l'errore del sistema e il suo impatto su clienti o persone, il profilo normativo (la classificazione AI Act del caso d'uso, i dati personali coinvolti con la loro base giuridica), la dipendenza da fornitori, il rischio di adozione, cioè la possibilità concreta che il sistema funzioni e nessuno lo usi. La priorità, terza dimensione, posiziona l'iniziativa dentro il portafoglio di cui abbiamo scritto: il punteggio sui tre assi, l'orizzonte temporale, cosa spodesta o rimanda nel backlog, perché ogni sì detto a un'iniziativa è un no detto a un'altra e il Canvas costringe a scrivere quale. ## Le seconde tre: chi, con quali mezzi, dopo cosa Gli stakeholder sono la dimensione che i business case tradizionali danno per scontata e i fallimenti no: lo sponsor esecutivo con potere di firma, il process owner che cede il processo, gli utenti che dovranno cambiare abitudini, le funzioni di controllo (risk, legale, DPO quando i dati personali entrano in gioco) che vanno coinvolte all'inizio, quando costano ore, invece che alla fine, quando costano mesi. Le capability censiscono il divario tra ciò che serve e ciò che c'è, su dati, competenze e infrastruttura, con la scelta esplicita per ogni divario: si costruisce, si compra, ci si allea. Le dipendenze chiudono il giro e sono la dimensione che più spesso ribalta le decisioni: cosa deve essere vero perché l'iniziativa parta (quel dataset pulito, quella integrazione, quella policy approvata) e cosa questa iniziativa rende possibile dopo, perché un caso d'uso mediocre che sblocca una fondazione riusabile può valere più di uno brillante che non lascia nulla. È la casella dove il portafoglio smette di essere una classifica e diventa una sequenza. ## Come si usa, e cosa produce Il Canvas dà il meglio compilato in sessione, due o tre ore con sponsor, process owner, referente tecnico e una funzione di controllo nella stanza, perché il valore sta tanto nel foglio finale quanto nei disaccordi che emergono compilandolo: la sessione in cui si scopre che il valore stimato non ha un firmatario, o che la dipendenza dai dati era nota a tutti tranne che allo sponsor, ha già ripagato il metodo. L'output alimenta direttamente i criteri di go/no-go: da opportunità e rischi escono le soglie di successo e di arresto, dalle capability il budget vero comprensivo dei prerequisiti, dalle dipendenze la sequenza. E il confronto tra Canvas diversi, tutti sulla stessa struttura, è ciò che permette a un comitato di decidere tra iniziative invece che tra retoriche. Nel nostro lavoro di AI Strategy il Canvas è lo strumento con cui ogni iniziativa del backlog viene istruita prima di chiedere capitale, e la versione compilata entra nei deliverable insieme a roadmap e criteri di decisione: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Se volete testare il metodo senza aspettare, prendete l'iniziativa AI più promettente che avete in casa e provate a compilare le sei caselle in un'ora, con le persone giuste nella stanza: la casella che resta vuota vi sta dicendo qualcosa, e ve lo sta dicendo adesso, che costa poco, invece che a progetto avviato. Quale delle sei, scommettiamo, sarà? --- # LLM proprietari o open source: i criteri di scelta per l'azienda URL: https://zerofive.ai/blog/approfondimenti/llm-proprietari-open-source-criteri Data: 2026-04-07 Abstract: Modelli proprietari via API o open source in casa: i sei criteri che contano davvero per un'azienda, i falsi miti sui costi e la logica del portafoglio. La domanda arriva in ogni percorso di adozione, di solito posta come scelta di campo: meglio i modelli proprietari dei grandi provider, consumati via API, o i modelli open source (più precisamente open weight, visto che di aperto ci sono i pesi e di rado tutto il resto) da far girare sotto il proprio controllo? La forma della domanda è la prima cosa da correggere, perché presuppone una risposta unica per l'azienda, mentre la risposta seria si dà per caso d'uso, e quasi sempre al plurale. Da posizione vendor-agnostic quale la nostra, senza modelli da vendere né alleanze da onorare, i criteri che vediamo decidere davvero sono sei, e conviene passarli in ordine di peso. ## Capacità richiesta e sensibilità dei dati Il primo criterio è la distanza tra ciò che il caso d'uso richiede e ciò che le due famiglie offrono. Sui compiti di frontiera, ragionamento complesso e affidabilità su domini difficili, i modelli proprietari di punta mantengono un vantaggio, mentre su una quota crescente di compiti aziendali, classificazione, estrazione, sintesi su domini circoscritti, i modelli aperti di taglia media raggiungono risultati indistinguibili a una frazione del costo per token. La conseguenza pratica è che pagare capacità di frontiera per compiti di routine è lo spreco più comune che incontriamo nei conti dei clienti. Il secondo criterio sono i dati che il modello vedrà. Per informazioni ordinarie, i contratti enterprise dei provider seri offrono oggi garanzie contrattuali robuste su non-addestramento e residenza dei dati, e vanno lette invece che presunte. Restano i casi in cui il dato non può uscire per vincolo normativo, di segreto industriale o di committenza, ed è lì che il modello aperto in infrastruttura propria smette di essere una preferenza ideologica e diventa l'unica opzione sul tavolo. ## Il costo totale, con le voci nascoste Il terzo criterio è il TCO, e il confronto onesto guarda oltre il prezzo per token. La via proprietaria fa pagare l'uso e regala tutto il resto: aggiornamenti, infrastruttura, sicurezza del serving, scalabilità. La via aperta azzera il costo di licenza e apre le voci che nei business case entusiasti mancano sempre, le GPU o il cloud per l'inferenza, l'ingegneria per servire il modello con latenze accettabili, il monitoraggio, e soprattutto le persone capaci di fare tutto questo, che sono la voce più scarsa e più cara del listino. La regola empirica che ne esce: sotto una certa scala di utilizzo l'API vince quasi sempre sul costo pieno, e il punto di pareggio va calcolato sul proprio traffico reale, non sulle slide del fornitore di GPU. Il quarto criterio è il controllo, nelle sue forme concrete: la possibilità di fissare una versione del modello e deciderne il ciclo di vita (con le API, il provider può deprecare ciò su cui avete costruito), di specializzarlo in profondità con fine-tuning sui propri dati, di ispezionarne il comportamento per esigenze di audit. Dove queste esigenze pesano, i pesi aperti pesano con loro. ## Compliance, competenze e la logica del portafoglio Il quinto criterio è il profilo normativo. L'AI Act assegna obblighi specifici a chi fornisce modelli per finalità generali, e consumare via API lascia quegli obblighi al provider, mentre chi prende un modello aperto e lo modifica o lo mette in servizio deve capire quale parte della catena di responsabilità sta assumendo, una valutazione da fare con il legale prima e con evidenze scritte, non dopo. Il sesto criterio, le competenze, è il più semplice da enunciare: la via aperta è una scelta di build, e le scelte di build si fanno con le persone che si hanno o che si è certi di poter assumere e trattenere. Messi in fila, i sei criteri portano quasi sempre alla stessa architettura di arrivo, il portafoglio: modelli proprietari di punta dove la capacità di frontiera paga, modelli aperti o proprietari minori dove il compito è di routine e i volumi mordono, un livello di astrazione tecnico che permetta di instradare e sostituire senza riscrivere le applicazioni. Il portafoglio, oltre a ottimizzare i costi, è la migliore assicurazione contro il lock-in, tema che merita un articolo a sé e che qui lasciamo come promemoria contrattuale: la clausola di uscita si negozia all'ingresso. La scelta dei modelli, vista da questa distanza, è una decisione di business travestita da decisione tecnica, e come tale entra nel lavoro di AI Strategy che facciamo con i clienti, dentro criteri espliciti invece che dentro preferenze di reparto: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il test rapido per capire se la vostra scelta attuale è stata una decisione o un'abitudine sta in una domanda: sapreste dire, caso d'uso per caso d'uso, perché gira sul modello su cui gira? --- # Come prioritizzare gli use case AI: valore, fattibilità e rischio URL: https://zerofive.ai/blog/strategia/prioritizzare-use-case-ai Data: 2026-04-02 Abstract: Un metodo per prioritizzare gli use case AI: i tre assi di valutazione, gli errori più comuni e come costruire un backlog che il board può approvare. C'è un momento ricorrente nei percorsi di adozione, e arriva subito dopo i workshop di ideazione: l'azienda si ritrova con una lista di trenta, cinquanta, a volte cento idee di use case AI, tutte plausibili, tutte sponsorizzate da qualcuno, e un budget che ne finanzia cinque. Quello che succede dopo decide più del successo dell'intero programma che qualunque scelta tecnologica, eppure è il passaggio trattato con meno metodo: nella maggior parte dei casi vince chi urla di più in comitato, o l'idea più simile alla demo vista all'ultimo evento. I dati suggeriscono quanto costi questa selezione per acclamazione. Il MIT Project NANDA (The GenAI Divide, luglio 2025) ha osservato che oltre metà dei budget GenAI si concentra su vendite e marketing, dove i risultati sono i più visibili da raccontare, mentre i ritorni migliori si registrano nell'automazione di back office e funzioni operative, dove nessuno fa comunicati stampa. Il capitale, lasciato all'istinto, va dove luccica. ## I tre assi, e come misurarli senza barare La prioritizzazione seria valuta ogni use case su tre assi, e la disciplina sta nel modo, prima ancora che nei criteri. Il valore va espresso in una metrica di business che qualcuno firma: ore recuperate su un processo con il loro costo pieno, punti di marginalità, riduzione di un rischio quantificato, ricavo incrementale con le sue ipotesi esplicite. La firma è la parte importante, perché un valore stimato dal team AI vale la metà di uno stimato dal process owner che poi dovrà risponderne. La fattibilità misura la distanza tra il caso d'uso e le condizioni per realizzarlo, e la componente che domina quasi sempre sono i dati, con le cinque domande di readiness che abbiamo trattato altrove: accesso, qualità misurata, ownership, tempo, legittimità. Accanto ai dati pesano l'integrazione richiesta nei sistemi esistenti e le competenze disponibili, interne o acquistabili. Il rischio, terzo asse, incrocia la classificazione AI Act (un caso d'uso in ambito Allegato III porta con sé un corredo di obblighi che ne cambia tempi e costi), l'esposizione sui dati personali e l'impatto di un errore del sistema sul cliente o sulla persona. Il rischio alto non squalifica, informa: sposta il caso d'uso più avanti nella sequenza, quando la governance sarà pronta a reggerlo. ## Gli errori che deformano la classifica Quattro distorsioni ricorrono in quasi tutti i portafogli che rivediamo. La prima è il punteggio senza pesi dichiarati, dove ogni funzione compila la matrice gonfiando il proprio asse preferito: i pesi vanno decisi prima, insieme, e poi applicati a tutti. La seconda è l'orizzonte unico, che mette in gara i quick win a tre mesi con le scommesse a due anni sulla stessa scala: un portafoglio sano li separa per costruzione, tipicamente con una quota maggioritaria di iniziative a ritorno rapido che finanziano e legittimano le poche scommesse strutturali. La terza distorsione è ignorare le dipendenze: tre use case che condividono la stessa fondazione dati valgono, insieme, più della loro somma, e sequenziarli bene abbatte il costo marginale del secondo e del terzo. La quarta è la classifica scolpita nella pietra, mentre i punteggi invecchiano in fretta, perché i dati migliorano, i costi dei modelli scendono, le norme avanzano: il backlog è un artefatto vivo, da rivedere a cadenza fissa, con la stessa serietà della prima stesura. ## Dal punteggio alla delibera La classifica, da sola, resta un esercizio finché non si traduce in un formato su cui il vertice può decidere. La traduzione che funziona ha tre componenti: i primi casi d'uso con il loro valore firmato e i prerequisiti da chiudere, i criteri di go/no-go che ciascuno dovrà superare per passare di fase, e la lista di ciò che è stato deliberatamente escluso con il perché, che è la parte più sottovalutata e quella che protegge il programma dalle riaperture continue. Un backlog senza esclusioni esplicite è una lista dei desideri con i numeri accanto. È il lavoro che nel nostro modello copre l'AI Assessment, il secondo anello della catena dopo la misurazione della maturità: mappa degli use case, scoring sui tre assi con pesi condivisi, quick win identificati e un backlog che il board può approvare sapendo cosa sta scegliendo e cosa sta rinunciando a scegliere. Se la vostra lista dei trenta è già sul tavolo e il budget dei cinque pure, il metodo per passare dall'una all'altro si costruisce in poche settimane: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E se la classifica l'avete già fatta, il test di tenuta è uno solo: chi ha firmato i numeri nella colonna del valore? --- # Gate critici: quando un punteggio alto non basta URL: https://zerofive.ai/blog/ai-governance/gate-critici-maturita-ai Data: 2026-03-24 Abstract: Cosa sono i gate critici in un modello di maturità AI, perché certe carenze non si compensano con la media e come usarli nella propria governance. Immaginate due aziende con lo stesso punteggio di maturità AI, un dignitoso 3.2 su 5. La prima è solida ovunque e brillante da nessuna parte. La seconda eccelle in strategia e delivery, ma non ha un inventario dei propri sistemi e tratta dati personali dentro modelli senza che nessuno abbia mai valutato la base giuridica. Un modello fatto solo di medie le dichiarerebbe gemelle, e consiglierebbe a entrambe la stessa strada, mentre la seconda sta camminando spedita verso un muro che la prima non ha. I gate critici esistono per impedire al modello di raccontare questa bugia statistica. ## La logica del non compensabile Il principio arriva da mondi che con il rischio convivono da più tempo dell'AI. Nei rating di credito, un covenant violato pesa più di dieci indicatori in ordine. Nelle certificazioni di sicurezza, una non conformità maggiore blocca l'esito a prescindere dall'eleganza del resto. Nell'aviazione, la checklist pre-volo non fa la media: un item fallito tiene l'aereo a terra anche se gli altri quaranta sono perfetti. In tutti questi domini la lezione è identica, esistono condizioni la cui assenza cambia la natura del rischio invece di abbassare un punteggio, e la matematica giusta per trattarle è il vincolo, non la ponderazione. Il nostro AI Rating incorpora questa logica: accanto ai punteggi 0-5 sulle quattro dimensioni vive un insieme ristretto di gate, condizioni verificate in modo binario, e una classe di merito alta richiede sia lo score sia i gate soddisfatti. La classe A, per dire, chiede score sopra 4.0, nessuna area sotto 3.5 e tutti i gate a posto: la terza condizione non è ridondante rispetto alle prime due, è quella che le rende credibili. ## Quali condizioni meritano un gate Non ogni carenza merita il trattamento, altrimenti il modello degenera in una lista di veti e perde capacità di distinguere. I criteri che usiamo per promuovere una condizione a gate sono tre, e devono valere insieme. La carenza deve poter revocare il permesso di operare, per via normativa (un trattamento di dati personali illecito, l'assenza della classificazione per rischio che l'AI Act presuppone) o per via sostanziale (nessuna sorveglianza umana su decisioni che incidono su persone). Deve essere non delegabile, cioè irrisolvibile comprando qualcosa da un fornitore, perché ciò che si compra si può anche pesare. E deve essere fondativa, nel senso che la sua assenza rende inaffidabili gli altri punteggi: il registro dei sistemi è l'esempio perfetto, perché senza censimento ogni altra valutazione descrive un perimetro immaginario. Applicati con questa disciplina, i gate restano pochi, tipicamente tra i cinque e gli otto, e ciascuno con una definizione verificabile: non "buona gestione dei dati" ma condizioni accertabili con evidenze, che un secondo valutatore riprodurrebbe. ## Cosa cambiano nei comportamenti L'effetto più interessante dei gate si vede dopo l'assessment, nelle scelte di allocazione. Senza gate, la roadmap tende a inseguire i punti dove il miglioramento è più facile o più visibile, perché ogni decimo di punto vale uguale. Con i gate, la sequenza si inverte da sola: prima si chiudono le condizioni bloccanti, che di solito sono anche le meno glamour (il registro, le basi giuridiche, la sorveglianza umana), e solo dopo si ottimizza il resto. Nei progetti che seguiamo questa inversione è spesso il contributo singolo più prezioso dell'intera misurazione, perché sposta budget da ciò che luccica a ciò che regge. C'è poi un effetto sulla conversazione con il vertice che vale la pena nominare. Dire a un board "siamo a 3.2" invita al confronto con il benchmark; dire "siamo a 3.2 con due gate aperti, ed ecco quali" invita a una delibera. Il gate trasforma la maturità da fotografia a lista di decisioni, che è la forma in cui un consiglio può effettivamente usarla. ## Costruirsi i propri La logica è replicabile in casa, anche senza un modello esterno, e l'esercizio vale la mezza giornata che costa: riunite chi possiede rischio, dati e AI, e chiedete quali condizioni, se assenti, dovrebbero fermare un progetto a prescindere da quanto promette. La lista che esce, depurata con i tre criteri di sopra, è la vostra prima versione dei gate, e il test di onestà arriva subito dopo, verificandola sui progetti in corso. Se qualche iniziativa attiva non passerebbe i vostri stessi gate, avete appena scoperto la cosa più utile del trimestre. Noi lo facciamo con il rigore di un modello calibrato su decine di assessment, dentro l'AI Rating, dove punteggi e gate escono insieme e la roadmap ne eredita le priorità: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La domanda con cui lasciarvi è la versione personale di quella iniziale: nella vostra organizzazione, oggi, esiste una condizione che fermerebbe tutto, e qualcuno la sta guardando? --- # Registro dei sistemi AI: perché serve e come costruirlo URL: https://zerofive.ai/blog/compliance/registro-sistemi-ai-come-costruirlo Data: 2026-03-19 Abstract: Il registro dei sistemi AI è il primo strumento di governance e la base di ogni adeguamento all'AI Act: cosa contiene, come costruirlo e come tenerlo vivo. Tra tutti i deliverable di un programma di AI governance, il registro dei sistemi è quello con il rapporto più sbilanciato tra quanto è umile e quanto è decisivo. Umile perché nella sua prima versione è, letteralmente, una tabella. Decisivo perché ogni altra attività di governo dipende da lui: non si classifica per rischio ciò che non è censito, non si valuta l'impatto privacy di un trattamento ignoto, non si presenta al board lo stato di un perimetro che nessuno ha mai delimitato. Nei nostri assessment la sua assenza è uno dei gate critici che bloccano la classe di merito a prescindere dagli altri punteggi, e la scelta è deliberata: un'organizzazione che non sa cosa usa non può, per definizione, governarlo. ## A cosa serve, oltre all'ovvio La funzione normativa è quella che spinge la maggior parte delle aziende a partire. L'AI Act ragiona per sistemi, e ogni obbligo, dalla classificazione agli adempimenti per l'alto rischio fino alla trasparenza, presuppone di sapere quali sistemi esistono e con quale ruolo l'azienda li tocca; per i deployer di sistemi ad alto rischio, poi, valutazioni e documentazione richiedono esattamente le informazioni che un buon registro contiene già. Chi conosce il GDPR riconoscerà la logica del registro dei trattamenti dell'articolo 30, e la parentela non è solo concettuale: molte righe dei due registri si sovrappongono, e costruirli in dialogo evita di censire due volte lo stesso mondo. La funzione gestionale, meno citata, vale però di più nel quotidiano. Il registro è il posto dove il CFO scopre quanto l'azienda spende davvero in AI sommando licenze sparse nei budget di funzione, dove il CISO vede la superficie di attacco che i singoli acquisti hanno composto, dove chi valuta un nuovo caso d'uso controlla se uno strumento adatto esiste già, evitando il terzo abbonamento allo stesso servizio. È anche l'antidoto strutturale alla shadow AI di cui abbiamo scritto: il fenomeno prospera nell'assenza di un luogo ufficiale dove gli strumenti possano essere dichiarati. ## Cosa scrivere in ogni riga Un registro utile tiene insieme poche informazioni scelte bene, e l'esperienza suggerisce una dozzina di campi. L'identità del sistema: nome, fornitore o sviluppo interno, descrizione della finalità in linguaggio di business. La responsabilità: l'owner interno con nome e cognome, la funzione che lo usa. Il profilo normativo: il ruolo dell'azienda (fornitore o deployer), la categoria di rischio AI Act con la motivazione scritta, la presenza di dati personali con relativa base giuridica e il rimando alla DPIA quando esiste. L'operatività: i dati che il sistema consuma e produce, i sistemi con cui si integra, lo stato (sperimentazione, produzione, dismesso) e la data dell'ultima revisione della riga. Due avvertenze salvano mesi. La prima riguarda la granularità: la voce giusta è il sistema nel suo contesto d'uso, non il prodotto, perché lo stesso strumento usato dal marketing per le bozze e dall'HR per lo screening è una riga sola per il procurement e due righe molto diverse per il rischio. La seconda riguarda l'ambizione iniziale: la prima versione perfetta è nemica della prima versione esistente, e un foglio condiviso con venti righe oneste batte il progetto di piattaforma che parte tra sei mesi. Gli strumenti dedicati arrivano quando il registro ha dimostrato di vivere. ## Tenerlo vivo, che è la parte difficile Ogni organizzazione che ha costruito un registro ha poi scoperto la seconda metà del lavoro: i registri muoiono di obsolescenza in silenzio, e un registro vecchio di un anno è quasi peggio di nessun registro, perché produce falsa sicurezza. La sopravvivenza si progetta agganciando l'aggiornamento ai flussi dove i sistemi nascono e cambiano. Il procurement è il gancio principale: nessun acquisto con componenti AI si perfeziona senza la riga di registro compilata, e la domanda "contiene AI?" entra nella checklist fornitori. Il secondo gancio è il rilascio: nessun caso d'uso passa in produzione senza registrazione. Il terzo è la finestra di emersione periodica per ciò che sfugge ai primi due, erede diretta del censimento iniziale. Serve infine un custode, tipicamente dentro la funzione che presiede la governance AI, con il mandato esplicito di inseguire le righe incomplete: i registri non si aggiornano per gentilezza. Costruito così, il registro smette di essere un adempimento e diventa la mappa su cui si prendono le decisioni, dalla priorità degli interventi alla risposta rapida quando un'autorità, un cliente o il consiglio chiede "quali sistemi AI usate e come li governate?". Se oggi quella domanda vi troverebbe a improvvisare, il primo passo costa poco e lo si può fare con metodo dentro una misurazione completa: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La versione minima dell'esercizio, intanto, sta in una riga vuota e una domanda: quale sarebbe il primo sistema che scrivereste, e chi mettereste nella colonna dell'owner? --- # Pulizia e organizzazione dei dati: da dove iniziare, in pratica URL: https://zerofive.ai/blog/approfondimenti/pulizia-organizzazione-dati Data: 2026-03-17 Abstract: Come pulire e organizzare i dati aziendali in vista di progetti AI: priorità, problemi ricorrenti, pipeline ripetibili e gli errori che sprecano mesi. Il momento in cui un'azienda decide di "mettere a posto i dati" è quasi sempre un buon momento arrivato nel modo sbagliato: un progetto AI si è incagliato, qualcuno ha aperto le tabelle vere, e la scoperta di anagrafiche triplicate e campi compilati a fantasia ha generato la richiesta più pericolosa del repertorio, puliamo tutto. Pericolosa perché "tutto" non è un perimetro, e i programmi di pulizia senza perimetro condividono il destino delle diete da lunedì: partenza solenne, tre settimane di rigore, abbandono silenzioso. Il lavoro sui dati si può invece impostare in modo che produca valore visibile in settimane e fondamenta riusabili negli anni, e la differenza sta quasi tutta nelle prime decisioni. ## Il perimetro lo detta il caso d'uso La prima decisione è cosa non pulire. I dati aziendali sono un continente, e la parte che serve ai primi casi d'uso AI è tipicamente una provincia: le entità che alimentano quel processo, le tabelle da cui il modello berrà, gli storici che servono ad addestrare. Partire da lì ha due vantaggi che il programma universale non avrà mai, un committente che aspetta il risultato (il progetto AI stesso, che finanzia e giustifica lo sforzo) e un criterio di completamento verificabile, perché "dati pronti per il caso d'uso X" è una condizione che si misura, "dati a posto" no. Dentro il perimetro, la seconda decisione è l'ordine dei lavori, e conviene seguire la gerarchia del danno. Prima le entità chiave, clienti, prodotti, fornitori, perché ogni difetto lì si propaga ovunque: deduplicare un'anagrafica clienti e stabilire una chiave univoca condivisa tra CRM e gestionale vale, da solo, più di mesi di ritocchi sui campi secondari. Poi le relazioni tra sistemi, cioè le riconciliazioni che oggi qualcuno fa a mano in un foglio di calcolo. Solo alla fine la cosmesi dei campi descrittivi, che è la parte visivamente gratificante e economicamente meno urgente. ## I quattro difetti che si incontrano sempre Le patologie dei dati aziendali sono sorprendentemente ripetitive, e riconoscerle accelera la diagnosi. I duplicati sono la prima: la stessa entità registrata più volte con varianti minime, "Rossi S.p.A.", "ROSSI SPA", "Rossi Spa (nuova)", che per un modello sono tre clienti diversi. Il rimedio ha una parte tecnica (matching e merge) e una parte organizzativa che la sopravvive, la regola su chi può creare nuove anagrafiche e con quali controlli, perché deduplicare senza chiudere il rubinetto è svuotare il mare con il secchio. Il secondo difetto sono i campi liberi usati come discarica: note che contengono informazioni strutturali (scadenze, importi e stati) perché il campo giusto non esisteva o nessuno lo compilava. Qui l'AI moderna offre paradossalmente un aiuto, perché l'estrazione di struttura da testo libero è uno dei suoi mestieri migliori, purché l'output torni in campi governati e non in altre note. Il terzo difetto sono i valori mancanti non casuali, i buchi che si concentrano in certi periodi o certe filiali e che, dati in pasto a un modello, diventano bias appresi. Il quarto sono le convenzioni divergenti, date in tre formati, unità di misura implicite, codifiche che ogni reparto ha piegato ai suoi usi: il rimedio si chiama standard dichiarato, e vale solo se qualcuno ne risponde. ## La pulizia che resta pulita L'errore tecnico più costoso dell'intero cantiere è pulire i dati invece di costruire la pulizia, cioè produrre un dataset sistemato una tantum che ricomincia a sporcarsi il giorno dopo. La forma giusta del lavoro è la pipeline: regole di validazione, deduplica e standardizzazione scritte come codice, versionate, eseguite a ogni aggiornamento, con metriche di qualità che escono a ogni esecuzione e un punto dove le eccezioni finiscono davanti a un occhio umano. La pipeline cambia anche l'economia del progetto, perché trasforma un costo ricorrente e invisibile (le ore che analisti e team spendono ogni mese a sistemare a mano) in un investimento una tantum con manutenzione, e quel risparmio ricorrente è spesso il business case più solido dell'intero programma dati, più solido persino del progetto AI che l'ha innescato. Resta la parte organizzativa, che decide la tenuta nel tempo: ogni regola di pulizia incorpora una scelta di business (quale dei due indirizzi è quello buono? sotto quale soglia un record si scarta?), e quelle scelte spettano agli owner dei dati, non a chi scrive la pipeline. Dove la data governance di cui abbiamo scritto esiste, questo passaggio è un flusso; dove non esiste, la pulizia la fa nascere per necessità, un dominio alla volta. Se state per aprire un cantiere dati in vista di progetti AI, il modo per non sprecare il primo mese è sapere in anticipo quali dati contano, in quale ordine e con quali soglie, che è esattamente la fotografia che l'AI Rating produce sulla dimensione Readiness: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E se il cantiere è già aperto, una domanda di controllo vale l'intera retrospettiva: quello che state pulendo oggi, tra sei mesi sarà ancora pulito da solo? --- # Data governance per l'AI: ruoli, policy e qualità misurabile URL: https://zerofive.ai/blog/approfondimenti/data-governance-per-ai Data: 2026-03-10 Abstract: Cosa cambia nella data governance quando arriva l'AI: ruoli e responsabilità, policy sui dati, qualità misurabile con ISO 8000 e requisiti dell'AI Act. La data governance ha vissuto per anni la vita ingrata delle assicurazioni: tutti concordano che serva, pochi la comprano finché il danno non arriva. L'AI le ha cambiato lo statuto in un paio d'anni, per una ragione strutturale: un errore nei dati, dentro un processo tradizionale, produce un errore, mentre dentro un sistema che apprende produce un comportamento, che si replica su ogni decisione successiva e si scopre tardi. Il regolatore europeo ha tratto la conseguenza, e l'articolo 10 dell'AI Act dedica ai dati dei sistemi ad alto rischio requisiti espliciti su governance, pertinenza, rappresentatività e gestione dei bias, trasformando in obbligo ciò che era buona pratica. La domanda operativa, per chi deve costruirla o adeguarla, è cosa contenga una data governance all'altezza dell'AI. La risposta sta in tre componenti, e in un errore di impostazione da evitare. ## Nomi e cognomi prima dei comitati La prima componente sono le responsabilità, e la regola pratica è che la governance esiste quando ogni asset di dati rilevante ha due nomi accanto. Il data owner risponde del dato sul piano del business: ne autorizza gli usi, ne definisce le regole, risponde della sua correttezza verso l'organizzazione. Il data steward lo presidia sul piano operativo: monitora la qualità, gestisce le anomalie, mantiene la documentazione. Senza questi due ruoli assegnati per iscritto, ogni progetto AI ricomincia il negoziato daccapo, e la scena che vediamo più spesso negli assessment, il team che per settimane cerca "chi può dirci se questi dati si possono usare", è il sintomo esatto della loro assenza. Il comitato data governance, tanto amato dai framework, viene dopo e serve ad arbitrare i conflitti tra owner, non a sostituirli. Un comitato senza owner sottostanti è una riunione periodica su dati di nessuno. ## Policy scritte per chi costruisce La seconda componente sono le regole, e il criterio di qualità è che devono essere consultabili da chi sviluppa nel momento in cui sviluppa, non solo dall'audit a cose fatte. Le policy che contano per l'AI rispondono a domande da progetto: quali categorie di dati possono alimentare quali categorie di sistemi, con quali approvazioni; come si documenta la provenienza (il lineage) di un dataset di addestramento, così che tra un anno si possa ricostruire su cosa un modello ha imparato; quali soglie di qualità un dataset deve superare prima di entrare in una pipeline; come si gestiscono conservazione e cancellazione quando i dati vivono dentro modelli e non solo dentro tabelle. Su quest'ultimo punto, la coppia GDPR e AI Act che abbiamo trattato altrove entra nella governance dei dati come requisito di progettazione, perché una cancellazione richiesta da un interessato è gestibile se il lineage esiste, quasi impossibile se nessuno sa quali addestramenti quel dato ha attraversato. ## Qualità che si misura, con uno standard La terza componente è la qualità resa misurabile, ed è quella che separa la governance vera dal documento di intenti. Lo standard ISO 8000 offre il vocabolario: completezza e accuratezza, coerenza e tempestività, unicità e validità, ognuna misurabile con metriche concrete sulle tabelle che contano. Il salto di maturità sta nel passare dal giudizio ("i dati del CRM sono buoni") al numero ("completezza dell'anagrafica al 94%, duplicati al 3%, aggiornamento medio 36 ore"), perché solo il numero permette soglie, trend e accountability degli owner. Per l'AI la misurazione va tarata sul caso d'uso, con una soglia dichiarata sotto la quale il dataset non entra in pipeline, e un monitoraggio che continua in produzione, dato che i dati si degradano e i modelli con loro. È lo stesso principio dei gate critici che applichiamo nell'AI Rating: sotto certe condizioni non si compensa, ci si ferma. ## L'errore dell'impianto totale L'errore di impostazione più diffuso è progettare la governance come un impianto totale da costruire prima di qualunque AI, con anni di cataloghi, comitati e policy universali. Il progetto totale fallisce quasi sempre per la stessa ragione dei grandi programmi di data quality, nessun ritorno visibile lo tiene in vita, e nel frattempo blocca tutto il resto. L'impostazione che vediamo funzionare procede per perimetri: si parte dai domini di dati che i primi casi d'uso AI toccano, lì si assegnano owner e steward, si scrivono le policy che servono davvero, si misurano le sei dimensioni di qualità, e si lascia che la roadmap AI estenda il perimetro governato un dominio alla volta. La governance cresce così alla velocità del valore che abilita, che è anche il modo migliore per difenderne il budget. Nel nostro AI Rating la data governance attraversa Readiness e Risk, con evidenze puntuali: ruoli assegnati o vacanti, policy esistenti o presunte, qualità misurata o percepita, e ogni gap entra nella roadmap con priorità e owner. Se voleste applicare il test minimo già oggi, prendete le tre fonti di dati più critiche per il vostro prossimo progetto AI e scrivete accanto a ciascuna il nome dell'owner: se una delle tre righe resta vuota, sapete da dove iniziare. Per la versione completa: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La governance dei dati, alla prova dell'AI, si riduce a una domanda quasi anagrafica: di chi sono, con nome e cognome, i dati su cui state per costruire? --- # AI e GDPR: dove si sovrappongono e dove entrano in tensione URL: https://zerofive.ai/blog/compliance/ai-gdpr-sovrapposizioni-tensioni Data: 2026-03-05 Abstract: AI Act e GDPR si applicano insieme: basi giuridiche, decisioni automatizzate, DPIA e FRIA. Dove le due norme si rafforzano e dove creano tensioni operative. Una convinzione pericolosa circola nei progetti AI, e cioè che l'AI Act abbia in qualche modo sostituito o assorbito il GDPR sul terreno dell'intelligenza artificiale. Le due norme, in realtà, si applicano in parallelo e per intero: il regolamento AI disciplina i sistemi in funzione del loro rischio, il GDPR disciplina i trattamenti di dati personali ovunque avvengano, e un sistema AI che tocca dati personali risponde a entrambi, con autorità di vigilanza, sanzioni e logiche differenti. Il Garante italiano lo ha ricordato nel modo più concreto, con la sanzione da 15 milioni di euro a OpenAI (dicembre 2024) fondata interamente su violazioni GDPR, basi giuridiche e trasparenza in testa, senza attendere alcuna scadenza dell'AI Act. Per chi guida progetti AI in azienda, la mappa delle sovrapposizioni e delle tensioni tra le due norme vale più di molte ore di formazione generica, perché è lì che si annidano sia i rischi sia le scorciatoie che poi si pagano. ## Dove le due norme remano insieme Su tre fronti AI Act e GDPR chiedono cose convergenti, e chi ha lavorato bene sulla privacy parte avvantaggiato. Il primo fronte è la conoscenza di sé: il registro dei trattamenti ex articolo 30 GDPR e il censimento dei sistemi AI sono esercizi cugini, e un'azienda con il primo in ordine costruisce il secondo in metà tempo, spesso scoprendo che molte righe coincidono. Il secondo fronte sono le valutazioni d'impatto. La DPIA del GDPR e la valutazione d'impatto sui diritti fondamentali che l'AI Act introduce per certi deployer di sistemi ad alto rischio condividono struttura logica e buona parte delle evidenze: descrizione del trattamento, rischi per le persone, misure di mitigazione. Farle dialogare in un processo unico evita duplicazioni e incoerenze tra documenti che un'autorità leggerebbe insieme. Il terzo fronte è la sorveglianza umana sulle decisioni. L'articolo 22 GDPR limita da anni le decisioni basate unicamente su trattamenti automatizzati con effetti giuridici o significativi sulle persone, e l'AI Act rafforza il principio con i requisiti di oversight per l'alto rischio: chi ha già progettato processi con un intervento umano significativo, non un timbro di ratifica, ha già la spina dorsale di entrambe le compliance. ## Dove nasce la tensione Le frizioni vere stanno nei principi di fondo, perché il GDPR è nato per limitare i trattamenti e l'AI contemporanea prospera sull'abbondanza. La minimizzazione dei dati chiede di trattare solo il necessario, mentre lo sviluppo dei modelli spinge a raccogliere tutto ciò che potrebbe servire. La limitazione delle finalità vincola i dati allo scopo dichiarato alla raccolta, mentre il riuso per addestrare o alimentare sistemi AI è quasi sempre una finalità nuova, che chiede una valutazione di compatibilità o una base giuridica propria. La trasparenza esige spiegazioni comprensibili, e i modelli più potenti restano i meno spiegabili. Su questo terreno le risposte facili sono quasi sempre sbagliate. "I dati sono anonimi" regge di rado a un'analisi seria, perché la soglia dell'anonimizzazione vera è alta e la pseudonimizzazione lascia i dati nel perimetro GDPR. "C'è il legittimo interesse" richiede il bilanciamento documentato, che per l'addestramento su larga scala è tutto meno che scontato, come i procedimenti delle autorità europee hanno mostrato. "Il fornitore è compliant" trascura che l'azienda resta titolare dei propri trattamenti, con responsabilità che nessun contratto trasferisce per intero. ## Il metodo per tenerle insieme Il modo operativo per governare la coppia parte da una mossa organizzativa prima che giuridica: DPO e owner dell'AI devono lavorare sullo stesso tavolo, con un processo che intercetti ogni nuovo caso d'uso AI prima del kickoff e gli faccia tre domande in sequenza. Ci sono dati personali, anche indirettamente? Se sì, con quale base giuridica e per quale finalità, ed è la stessa della raccolta originaria? La decisione che il sistema supporta produce effetti significativi su persone, e in tal caso come è disegnato l'intervento umano? Le risposte alimentano una scheda unica per sistema, quella stessa scheda che serve alla classificazione di rischio AI Act, e la coppia di norme smette di essere due cantieri per diventare un solo processo con due liste di controllo. Nel nostro AI Rating questo intreccio vive nella dimensione Risk, dove privacy e AI Act si valutano insieme e i gap sui dati personali contano tra i gate critici, perché un trattamento illecito non è una debolezza da media ponderata, è una condizione che può fermare il sistema. La tensione tra protezione dei dati e ambizione dell'AI non si scioglie una volta per tutte, si amministra caso per caso, e le aziende che la amministrano con metodo scoprono un effetto collaterale prezioso: i vincoli, presi sul serio in progettazione, producono sistemi più sobri nei dati e più solidi nel tempo. Se volete capire dove sta la vostra organizzazione su questo intreccio, la misurazione è il punto d'ingresso: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E la domanda da portare al prossimo comitato è precisa: dei sistemi AI attivi oggi, quanti hanno una base giuridica scritta per i dati che consumano? --- # Data readiness: perché i progetti AI muoiono sui dati URL: https://zerofive.ai/blog/approfondimenti/data-readiness-progetti-ai Data: 2026-03-03 Abstract: La causa più citata di fallimento dei progetti AI sono i dati. Cos'è la data readiness, come si verifica prima di investire e cosa fare quando manca. Nelle autopsie dei progetti AI falliti la tecnologia compare di rado tra le cause, i dati quasi sempre. RAND Corporation (2024) mette le fondamenta dati inadeguate tra le ragioni primarie di quel oltre 80% di progetti che manca il valore atteso, il MIT Project NANDA (The GenAI Divide, luglio 2025) individua nella scarsa prontezza dei dati e nella mancata integrazione nei flussi la radice del 95% di pilot GenAI senza impatto sul conto economico, e Gartner (2025) ha formulato la previsione più netta: entro il 2026 le organizzazioni abbandoneranno il 60% dei progetti AI non supportati da dati AI-ready. Il paradosso è che i dati sono anche la causa di fallimento più prevedibile in assoluto, perché a differenza dello sponsor che cambia ruolo o del mercato che si muove, la loro condizione si può verificare per intero prima di spendere il primo euro. Basta volerlo fare, e sapere cosa guardare. ## L'illusione del dataset da demo Il meccanismo con cui i dati uccidono i progetti ha una dinamica ricorrente che abbiamo descritto parlando di pilot bloccati, e che merita di essere vista dal lato dei dati. Il pilot gira su un estratto curato: qualcuno che conosce bene un sistema ha esportato una tabella, l'ha pulita a mano, ha risolto i duplicati e riempito i buchi. Su quel materiale il modello funziona, la demo convince, il progetto accelera verso la produzione. In produzione, però, il modello deve bere dalla fonte vera, e la fonte vera è un'altra cosa: anagrafiche clienti duplicate tra CRM e gestionale con chiavi che non si parlano, campi liberi compilati in dieci modi diversi in dieci anni, storici interrotti da migrazioni, dati freschi che arrivano con giorni di ritardo rispetto a quando servirebbero. Il lavoro manuale che aveva reso possibile la demo non è ripetibile ogni notte, e il progetto entra nella fase che consuma budget e pazienza, quella in cui si scopre che il vero cantiere non era il modello, era tutto ciò che sta prima. ## Le domande che misurano la prontezza La data readiness si lascia interrogare con domande concrete, e conviene farle per il caso d'uso specifico, perché dati ottimi per un'applicazione possono essere inservibili per un'altra. La prima riguarda l'accesso: i dati necessari sono raggiungibili in modo programmatico e ricorrente, o vivono dietro estrazioni manuali, fogli di calcolo personali, fornitori da pregare? La seconda riguarda la qualità misurata, che è cosa diversa dalla qualità percepita: esistono metriche di completezza, accuratezza e coerenza su quelle tabelle, o il giudizio si basa sul fatto che "il gestionale funziona"? La terza domanda riguarda la ownership: per ogni fonte, c'è una persona che risponde della sua qualità e che può autorizzarne l'uso, o l'unico esperto è un collega che "quel sistema lo conosce"? La quarta riguarda il tempo, nelle sue due forme, la profondità storica sufficiente ad addestrare e la freschezza sufficiente a servire il processo. La quinta, spesso dimenticata, riguarda la legittimità: quei dati possono essere usati per quello scopo, con quella base giuridica, o il progetto sta costruendo su un trattamento mai valutato? Un caso d'uso che risponde bene a tutte e cinque è raro, e va benissimo così: la readiness non chiede perfezione, chiede di conoscere i gap prima di partire e di metterli nel budget e nel piano, invece di scoprirli al momento peggiore. ## Sistemare i dati senza l'alibi del progetto infinito Davanti a un quadro dati mediocre, le organizzazioni oscillano tra due errori speculari. Il primo è partire lo stesso, confidando che "i dati li sistemiamo strada facendo", che è il copione esatto dei fallimenti censiti dalle ricerche citate. Il secondo è il rinvio a tempo indeterminato, il grande programma di data quality triennale che deve completarsi prima di qualunque AI, e che di solito muore di inedia perché nessun business case lo tiene in vita. La via che vediamo funzionare è chirurgica: si sistemano i dati che servono al caso d'uso scelto, in profondità e con criteri di riuso, lasciando che sia la sequenza dei casi d'uso a estendere progressivamente il perimetro dei dati in ordine. Ogni progetto AI diventa così anche un investimento incrementale in fondamenta, con un ritorno visibile che finanzia il successivo, e la data readiness smette di essere un prerequisito astratto per diventare un sottoprodotto misurabile della roadmap. ## La misura prima della scommessa Nel nostro AI Rating la condizione dei dati attraversa la valutazione da parte a parte: pesa sulla Readiness (qualità, accessibilità e ownership delle fonti), condiziona la Delivery (pipeline e integrazione) e tocca il Risk, dove il presidio sui dati è uno dei gate critici non compensabili, in coerenza con quanto l'EU AI Act chiede sui dati dei sistemi ad alto rischio e con gli standard di qualità come ISO 8000. Il punteggio dice, prima dell'investimento, se il prossimo pilot poggia su roccia o su sabbia, e quanto costa consolidare. Se avete un progetto AI in partenza nel 2026, l'esercizio più redditizio della settimana costa un'ora: prendete il caso d'uso e fategli le cinque domande di sopra, per iscritto, con i nomi delle fonti accanto. Se preferite farlo con metodo e con un punteggio confrontabile, ci trovate su calendly.com/fabiolalli/zerofive o a hello@zerofive.ai. La versione scomoda della domanda, quella che vale il budget intero, resta comunque una: il vostro prossimo modello, da dove berrà ogni notte? --- # Come presentare lo stato dell'AI al consiglio di amministrazione URL: https://zerofive.ai/blog/ai-governance/come-presentare-ai-al-cda Data: 2026-02-24 Abstract: Cosa deve contenere una presentazione sull'AI al consiglio di amministrazione: il numero di sintesi, i gap, la roadmap e gli errori che fanno perdere il board. Le presentazioni sull'AI che arrivano nei consigli di amministrazione italiani appartengono, con poche eccezioni, a due generi. Il primo è il tour tecnologico: venti slide su cosa sono i modelli generativi, una demo, un elenco di iniziative in corso, applausi e nessuna decisione. Il secondo è il genere ansiogeno: rassegna di rischi, sanzioni dell'AI Act, casi di cronaca, con l'effetto di congelare qualunque iniziativa. Entrambi falliscono per la stessa ragione, non danno al board ciò di cui un board vive: numeri confrontabili, opzioni con trade-off, una richiesta precisa su cui deliberare. Il tema è meno di nicchia di quanto sembri, perché la platea di consigli che dovranno affrontarlo è enorme: secondo l'Osservatorio Artificial Intelligence del Politecnico di Milano (ricerca 2025, febbraio 2026), il 71% delle grandi imprese ha progetti AI attivi e solo il 9% ha una gestione strutturata. Nella distanza tra quei due numeri ci sono migliaia di CdA che prima o poi chiederanno "a che punto siamo?", e qualcuno dovrà rispondere in venti minuti. ## Il numero di apertura La presentazione che funziona apre con una misura, non con un contesto. Un rating di maturità su scala nota (nel nostro modello, 0-5 con classi da A a D) dà al consiglio in trenta secondi ciò che le rassegne di iniziative non danno in un'ora: una posizione. "Siamo una classe C, con Readiness a 3.1, Delivery a 2.8, Risk a 1.9 e Confidence a 2.5" è una frase che ogni consigliere può interrogare, confrontare con il prossimo trimestre, usare per chiedere conto. Il numero funziona a due condizioni. La prima è la trasparenza sul metodo: da dove viene, su quali evidenze, con quale ripetibilità, perché un board esperto diffida giustamente dei punteggi autoprodotti. La seconda è l'onestà sulla parte scomoda, e qui i gate critici aiutano: dire che la classe resta bloccata finché manca il registro dei sistemi richiesto dal quadro normativo trasmette più credibilità di dieci slide di successi. ## I tre blocchi che seguono Dopo la posizione, la presentazione efficace si regge su tre blocchi, ciascuno con la sua funzione deliberativa. Il primo blocco traduce i gap in esposizione: cosa rischia concretamente l'azienda restando dov'è, in termini che il consiglio già maneggia. Il gap normativo diventa esposizione a sanzioni e a esclusione dai capitolati che chiedono evidenze di governance; il gap sui dati diventa capitale investito in pilot con alta probabilità di fallimento; il gap di competenze diventa dipendenza da fornitori. Ogni esposizione va quantificata dove possibile e datata sempre, perché il costo dell'inazione ha un profilo temporale e il consiglio deve vederlo. Il secondo blocco è la roadmap con i suoi trade-off, presentata come scelta e mai come piano unico da ratificare. Due o tre scenari con intensità di investimento diverse, ciascuno con cosa chiude, cosa rimanda e cosa rischia, danno al board il materiale per esercitare il suo mestiere, che è allocare capitale tra alternative. Il piano unico chiede fiducia, gli scenari chiedono una decisione, e i consigli decidono più volentieri di quanto si fidino. Il terzo blocco è la richiesta, una e precisa: approvare il budget della fase uno, nominare l'owner con mandato, fissare il re-assessment a dodici mesi in agenda. Le presentazioni senza richiesta producono il verbale più frequente d'Italia, "il consiglio prende atto", che è il modo formale di non decidere. ## Gli errori che fanno perdere la sala Tre pratiche affossano anche le presentazioni ben costruite. La prima è il gergo: parlare di RAG, fine-tuning e agenti a una platea che alloca capitale sposta la conversazione dal terreno del board a quello del relatore, e il board, quando non capisce, rinvia. La traduzione in linguaggio di business non è una semplificazione, è il lavoro. La seconda è la demo dal vivo, che ruba minuti alla deliberazione e sposta l'attenzione dallo stato dell'organizzazione alle capacità dello strumento, che non era la domanda. La terza è presentare solo successi: un consiglio che scopre i problemi da altre fonti, un audit, un articolo, un whistleblower, smette di usare le presentazioni del management come fonte, ed è una fiducia che non si ricostruisce in una riunione. ## Da evento a routine La presentazione singola, per quanto riuscita, risolve poco se resta un evento. L'obiettivo di fondo è portare l'AI nel ciclo di reporting ordinario del consiglio, con il rating in dashboard accanto ai KPI finanziari, aggiornato a ogni misurazione, e una cadenza definita per le eccezioni. È il criterio con cui costruiamo l'Executive Presentation dentro l'AI Rating, il deliverable pensato per il board: sintesi strategica, posizionamento, raccomandazioni, nel formato che un consiglio può assorbire e riusare. Se avete un CdA in calendario nei prossimi mesi e la voce AI in agenda, prepararla partendo da una misurazione vera cambia la qualità della discussione: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E se l'ultima presentazione sull'AI l'avete già fatta, il test retrospettivo è impietoso ma utile: cosa ha deliberato il consiglio, esattamente? --- # ISO/IEC 42001: cos'è un AI Management System e a chi serve davvero URL: https://zerofive.ai/blog/compliance/iso-42001-ai-management-system Data: 2026-02-19 Abstract: ISO/IEC 42001 è il primo standard certificabile per la gestione dell'AI: come è fatto, cosa dimostra, il rapporto con l'AI Act e per chi la certificazione ha senso adesso. Nelle conversazioni sulla governance AI degli ultimi mesi una sigla ha iniziato a circolare con insistenza crescente, spinta dai consulenti che la vendono e dai clienti enterprise che cominciano a chiederla ai fornitori: ISO/IEC 42001. Come accade a ogni standard giovane, intorno le si sono formate aspettative sproporzionate in entrambe le direzioni, chi la tratta come il lasciapassare che risolve l'AI Act e chi la liquida come l'ennesimo bollino. Vale la pena guardarla per quello che è, perché a certe organizzazioni serve davvero, ad altre non ancora, e la differenza si può dire con precisione. ## Un sistema di gestione, non un esame sui modelli ISO/IEC 42001:2023, pubblicata a fine 2023, è il primo standard internazionale certificabile per un sistema di gestione dell'intelligenza artificiale, un AI Management System. La parola che pesa è "gestione": lo standard non valuta i vostri modelli, non misura l'accuratezza degli output, non promuove o boccia algoritmi. Certifica che l'organizzazione ha costruito la macchina per governarli: politiche e obiettivi, ruoli e responsabilità, valutazione dei rischi e degli impatti dei sistemi AI lungo il ciclo di vita, controlli operativi, monitoraggio, miglioramento continuo, il tutto nella struttura armonizzata che chi conosce ISO 9001 o ISO/IEC 27001 riconoscerà al primo sguardo, con un annesso di controlli specifici per l'AI che copre dal ciclo di vita dei sistemi ai dati, dalla trasparenza verso gli stakeholder all'uso responsabile. La parentela con la 27001 non è un dettaglio tecnico, è la notizia buona per molte aziende: chi ha già un sistema di gestione della sicurezza delle informazioni possiede l'impalcatura, i processi di audit interno, la cultura documentale, e l'estensione all'AI è un cantiere incrementale invece che una fondazione da zero. Nei percorsi che osserviamo, questa è la variabile che più di ogni altra separa i progetti da sei mesi da quelli da diciotto. ## Il rapporto onesto con l'AI Act La domanda che tutti fanno è se la certificazione metta al riparo dal regolamento europeo, e la risposta onesta ha due metà. La prima: no, ISO 42001 non equivale alla conformità all'AI Act, perché lo standard è volontario e organizzativo mentre il regolamento impone obblighi puntuali per sistema e per categoria di rischio, e nessun certificato sostituisce la classificazione dei vostri use case, la documentazione tecnica dove richiesta, gli obblighi di trasparenza. Chi vi vende la certificazione come "conformità AI Act garantita" sta vendendo una parola che noi, per policy, non usiamo mai. La seconda metà, però, pesa nella direzione opposta: il regolamento chiede alle organizzazioni esattamente il tipo di evidenze che un AIMS produce per costruzione, ruoli assegnati, rischi valutati e registrati, processi documentati, riesami periodici. Lo standard è la macchina organizzativa che genera il materiale probatorio, e arrivare alle scadenze del regolamento con quella macchina in funzione cambia la natura del lavoro: si compila ciò che esiste invece di ricostruire ciò che manca. È lo stesso principio che vale per la 27001 rispetto al GDPR, mai equivalenza, sempre attrezzatura. ## A chi serve adesso, a chi non ancora Il profilo a cui la certificazione serve oggi è riconoscibile. Fornitori di soluzioni e servizi AI a clienti enterprise, per i quali il certificato sta diventando una richiesta nei procurement, come accadde alla 27001 dieci anni fa. Organizzazioni in settori regolati o esposti, dove board, audit e vigilanza chiedono garanzie dimostrabili e un certificato accreditato parla la loro lingua. Gruppi internazionali che vogliono un impianto unico spendibile su più giurisdizioni, dato che lo standard viaggia dove i regolamenti nazionali divergono. Il profilo opposto è altrettanto riconoscibile: l'organizzazione con pochi strumenti in uso e una governance ancora da fondare, per la quale partire dalla certificazione significa comprare l'impalcatura prima della casa. Il dato dell'Osservatorio del Politecnico di Milano presentato a febbraio, il 9% di grandi imprese con governance AI strutturata, dice che la maggioranza sta in questo secondo profilo, e per la maggioranza la sequenza sensata resta quella di cui scriviamo da settimane: prima l'inventario e la classificazione, poi le responsabilità e infine, quando la governance esiste e va dimostrata, lo standard che la certifica. La certificazione è la fotografia di una maturità, e fotografare una stanza vuota produce solo un certificato vuoto. Per chi è nel primo profilo, il percorso realistico va messo in agenda con i suoi tempi: gap analysis rispetto allo standard, implementazione dei controlli mancanti, audit di certificazione in due stadi, sorveglianze annuali, con orizzonti che nella pratica si misurano in due o tre semestri più che in mesi. Il nostro mestiere sta nel gradino prima: l'AI Rating misura dove siete rispetto a ciò che lo standard chiederebbe, la dimensione Risk produce la gap analysis, e la roadmap dice se e quando la certificazione entra sensatamente nel piano, perché anche questa, come tutto in questa serie, è una decisione da prendere con evidenze: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il test preliminare costa intanto una domanda in comitato: se l'audit di certificazione fosse fra sei mesi, quale capitolo del vostro sistema di gestione oggi non esiste nemmeno come bozza? --- # AI washing: come distinguere l'adozione reale dalla comunicazione URL: https://zerofive.ai/blog/approfondimenti/ai-washing-adozione-reale-comunicazione Data: 2026-02-17 Abstract: Cos'è l'AI washing, perché è un rischio legale oltre che reputazionale, e i test concreti per distinguere l'adozione AI reale dalla comunicazione. I dati presentati dall'Osservatorio Artificial Intelligence del Politecnico di Milano (ricerca 2025, febbraio 2026) contengono una coppia di numeri che, letti insieme, descrivono un fenomeno di cui si parla poco: l'84% delle grandi imprese italiane ha licenze di Generative AI, e solo una su cinque usa l'AI in modo pervasivo su più funzioni. Tra le due percentuali abita la versione aziendale di quello che i mercati chiamano AI washing, la distanza tra ciò che si racconta di fare con l'intelligenza artificiale e ciò che accade davvero nei processi. Il termine è nato per i casi estremi, e almeno lì la giurisprudenza si è già mossa: la SEC americana ha sanzionato nel marzo 2024 due società di investimento per dichiarazioni ingannevoli sull'uso dell'AI nei propri prodotti, aprendo un filone che chi comunica con investitori e clienti farebbe bene a conoscere. La versione che incontriamo più spesso nei nostri assessment, però, è meno dolosa e più insidiosa: aziende che raccontano a se stesse, in buona fede, un'adozione che i numeri interni non confermano. ## Dalla comunicazione esterna al teatro interno La prima forma guarda all'esterno ed è la più nota: comunicati, bilanci e pitch che descrivono capacità AI sovradimensionate rispetto al reale, per attrarre capitali, clienti o talenti. Qui il rischio ha smesso di essere solo reputazionale, perché tra enforcement dei regolatori finanziari, obblighi di trasparenza dell'AI Act in arrivo e due diligence sempre più tecniche nelle operazioni M&A, la distanza tra dichiarato e verificabile è diventata una passività misurabile. La seconda forma guarda all'interno, ed è quella che costa di più senza finire mai su un giornale: il teatro dell'attività. Task force, hackathon, licenze distribuite a pioggia, un "responsabile AI" nominato senza mandato né budget, decine di PoC celebrati e mai portati in produzione. Ogni elemento, preso da solo, è legittimo, ma l'insieme produce l'illusione del movimento, e l'illusione è più pericolosa dell'immobilità dichiarata perché disattiva l'urgenza di fare sul serio. La terza forma è la più recente e arriva dai fornitori: prodotti tradizionali ribattezzati "AI-powered" per una funzione marginale, roadmap che promettono capacità future come se fossero presenti. Per chi compra, saperla riconoscere è diventata una competenza di procurement. ## I test che non mentono Distinguere l'adozione reale dalla sua rappresentazione richiede domande a cui la comunicazione non può rispondere al posto dei sistemi. Il primo test è contabile: esiste una riga di conto economico, un KPI operativo o una metrica di processo che sia cambiata in modo attribuibile a un sistema AI? L'adozione reale lascia tracce nei numeri che l'azienda già misura, quella raccontata vive solo in numeri creati apposta per raccontarla (persone formate, prompt scritti, workshop tenuti). Il secondo test riguarda la produzione: quanti sistemi AI sono integrati nei processi core, con utenti che li usano perché il flusso di lavoro passa da lì, e non perché è stato chiesto di provarli? Le licenze misurano la spesa, l'integrazione misura l'adozione, e i due numeri dell'Osservatorio citati in apertura mostrano quanto possano divergere. Il terzo test riguarda la governance, ed è il più rapido da somministrare: esiste un registro dei sistemi, una classificazione per rischio, un owner con mandato, un processo per decidere cosa parte e cosa si ferma? Nella stessa ricerca del Politecnico, solo il 9% delle grandi imprese dichiara una gestione strutturata dell'AI. Un'organizzazione che comunica leadership nell'AI e non supera questo terzo test sta descrivendo un'aspirazione, il che è legittimo purché lo sappia lei per prima. ## Smontarlo da soli costa meno L'AI washing interno ha una proprietà scomoda: prima o poi lo smonta qualcuno, e conviene molto che sia l'azienda stessa a farlo. Se lo smonta un investitore in due diligence, il conto si paga in valutazione. Se lo smonta un cliente enterprise con un capitolato che chiede evidenze di governance, si paga in commesse. Se lo smonta un'autorità, si paga in sanzioni e tempo del vertice. Se lo smontano i dipendenti, che sono sempre i primi ad accorgersi della distanza tra i comunicati e i loro strumenti di lavoro, si paga nella valuta più difficile da riacquistare, la credibilità delle prossime iniziative. L'auto-smontaggio ha un nome meno drammatico, si chiama misurazione. Un rating di maturità condotto con metodo, su evidenze e interviste a più livelli, produce esattamente la fotografia che separa il reale dal raccontato, e la produce in un contesto dove la scoperta dei gap è l'inizio di una roadmap invece che di una crisi. È il lavoro che facciamo con l'AI Rating, e l'effetto più frequente sui clienti non è la delusione, è il sollievo: sapere dove si è davvero libera energie che il mantenimento della narrazione consumava. La comunicazione, sia chiaro, resta legittima e persino doverosa, a una condizione: che insegua i fatti invece di precederli di troppo. Se voleste verificare oggi da che parte sta la vostra organizzazione, i tre test di sopra si somministrano in una riunione, e la versione completa in quattro-sei settimane: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La domanda scomoda con cui chiudere ve la suggeriamo noi: se domani doveste dimostrare, evidenze alla mano, l'ultima affermazione pubblica della vostra azienda sull'AI, con cosa lo fareste? --- # Il 71% delle grandi imprese ha progetti AI. Solo il 9% li governa URL: https://zerofive.ai/blog/approfondimenti/71-percento-progetti-ai-9-percento-governance Data: 2026-02-12 Abstract: I dati dell'Osservatorio AI del Politecnico di Milano: il 71% delle grandi imprese ha progetti AI, solo il 9% una governance strutturata. Cosa significa il divario. I numeri presentati la scorsa settimana dall'Osservatorio Artificial Intelligence del Politecnico di Milano (ricerca 2025, febbraio 2026) raccontano due storie contemporaneamente, e vale la pena leggerle insieme. La prima è una storia di corsa: il mercato italiano dell'AI ha toccato 1,8 miliardi di euro, in crescita del 50% in un anno, il 71% delle grandi imprese ha avviato almeno un progetto, l'84% ha licenze di Generative AI attive. La seconda è una storia di vuoto: solo il 9% delle grandi imprese ha una gestione strutturata dell'AI, e appena il 15% ha avviato progetti organici di adeguamento all'AI Act. Sessantadue punti percentuali separano chi fa da chi governa ciò che fa. Nei tavoli dove lavoriamo questo divario ha una faccia precisa, ed è quella del CFO o del risk manager che scopre in comitato quanti sistemi AI girano davvero in azienda, e da quanto tempo, senza che nessuno li abbia mai censiti. ## Cosa contiene davvero quel 71% Il dato di adozione, preso da solo, dice meno di quanto sembri. La stessa ricerca precisa che solo un'impresa su cinque usa l'AI in modo pervasivo su più funzioni: per la maggioranza, "avere progetti" significa sperimentazioni localizzate, licenze distribuite, singoli casi d'uso partiti dal basso. L'adozione è larga e sottile, come una vernice. C'è poi il dato che dovrebbe togliere il sonno a chi presidia sicurezza e compliance: otto lavoratori su dieci utilizzano strumenti AI non aziendali (stessa fonte). Documenti caricati su servizi consumer, dati di clienti dentro prompt, output non verificati che rientrano nei processi. La shadow AI non compare in nessun inventario ufficiale, eppure è, con ogni probabilità, il perimetro AI più esteso della maggior parte delle organizzazioni italiane in questo momento. Il quadro, messo in fila, è quello di un'adozione che è avvenuta comunque, con o senza il permesso dell'organizzazione, mentre la capacità di governarla è rimasta ferma al punto di partenza. ## Perché la governance arriva sempre dopo (e perché è un errore di sequenza) La spiegazione benevola del 9% è che la governance segue fisiologicamente l'innovazione: prima si sperimenta, poi si regola. È una spiegazione che regge per le tecnologie a basso impatto, e l'AI non lo è, per due ragioni che i numeri stessi suggeriscono. La prima è che l'AI tocca decisioni, non solo processi. Un sistema che seleziona candidati, valuta pratiche di credito o suggerisce priorità cliniche produce effetti su persone, e il legislatore europeo lo ha già codificato: l'EU AI Act è in vigore dall'agosto 2024, i divieti sulle pratiche a rischio inaccettabile e l'obbligo di alfabetizzazione all'AI si applicano dal febbraio 2025, e il calendario delle prossime scadenze applicative è pubblico. Chi oggi è nel 91% senza governance strutturata non sta rimandando un adempimento futuro, sta accumulando un arretrato su obblighi in parte già vigenti. La seconda ragione è economica. La ricerca dell'Osservatorio registra un +93% di richieste di competenze AI negli annunci di lavoro e un 41% di lavoratori che grazie all'AI svolge attività prima fuori portata: il valore c'è, ed è proprio questo a rendere costoso il disordine. Senza criteri di prioritizzazione, ogni funzione compra il suo strumento, i dati restano nei silos, i pilot si moltiplicano senza mai consolidarsi, e la spesa cresce più in fretta del ritorno. La governance, vista da qui, ha poco a che fare con il freno che molti immaginano: è il meccanismo che decide dove concentrare un capitale che altrimenti si disperde. ## Entrare nel 9%, con metodo La buona notizia è che il passaggio dal 91% al 9% è un percorso noto, e non parte da un comitato etico o da un documento di principi. Parte da una misurazione. Nei nostri assessment (34+ progetti condotti, dati ZeroFive.AI al 2026) la sequenza che funziona ha tre tappe, e la prima è un censimento onesto: quali sistemi AI esistono in azienda, inclusi quelli ombra, chi li usa, su quali dati, con quale classificazione di rischio ai sensi dell'AI Act. È il registro dei sistemi, ed è insieme il primo obbligo sensato e il primo strumento di gestione. La seconda tappa è il rating di maturità: misurare su una scala oggettiva la capacità dell'organizzazione su preparazione, esecuzione, rischio e adozione, per sapere quali gap bloccano il resto. La terza è la roadmap con responsabilità assegnate, quick win a 30 giorni e un re-assessment a dodici mesi, perché una fotografia isolata invecchia in fretta e il valore sta nel confronto tra due misurazioni. Il nostro AI Rating copre esattamente queste tre tappe in quattro-sei settimane. Chi lo ha fatto racconta un effetto collaterale prezioso: per la prima volta board, IT e risk guardano lo stesso numero, e la conversazione sull'AI smette di essere una collezione di aneddoti. I dati dell'Osservatorio verranno aggiornati tra un anno, e la previsione facile è che il 71% salirà ancora. La domanda aperta riguarda l'altro numero: se anche il 9% resterà fermo, il divario smetterà di essere una statistica di settore e comincerà a decidere, azienda per azienda, chi ha trasformato la spesa in vantaggio e chi ha solo partecipato alla corsa. Se volete sapere da che parte del divario siete, mezz'ora su calendly.com/fabiolalli/zerofive basta per capirlo, oppure scrivete a hello@zerofive.ai. --- # Classificazione dei sistemi AI per rischio: come mappare i propri use case URL: https://zerofive.ai/blog/compliance/classificazione-sistemi-ai-rischio Data: 2026-02-10 Abstract: Le quattro categorie di rischio dell'AI Act e un metodo pratico per mappare e classificare i sistemi AI aziendali, con gli errori più comuni da evitare. L'intero impianto dell'EU AI Act poggia su un'idea semplice da enunciare e laboriosa da applicare: gli obblighi dipendono dal rischio del sistema, quindi finché un'azienda non ha classificato i propri sistemi non sa nemmeno quali articoli la riguardano. La classificazione è il passaggio dal regolamento letto al regolamento applicato, ed è anche il punto dove i progetti di adeguamento incontrano il primo ostacolo concreto, perché prima di classificare bisogna sapere cosa classificare, e quasi nessuno lo sa davvero. ## Le quattro categorie, in breve Il regolamento (UE) 2024/1689 organizza i sistemi in una piramide. Al vertice le pratiche a rischio inaccettabile, vietate dal 2 febbraio 2025: manipolazione subliminale dannosa, social scoring da parte di autorità pubbliche, riconoscimento delle emozioni sul luogo di lavoro e nell'istruzione (con eccezioni strette), scraping indiscriminato di immagini facciali. Qui l'unica classificazione utile è accertarsi di non esserci dentro, anche indirettamente attraverso un fornitore. Sotto stanno i sistemi ad alto rischio, il cuore operativo del regolamento. L'Allegato III elenca gli ambiti: biometria e identificazione, infrastrutture critiche, istruzione e formazione, occupazione e gestione dei lavoratori (dallo screening dei CV alle decisioni su promozioni e licenziamenti), accesso a servizi essenziali pubblici e privati (incluso il credit scoring), attività di contrasto, migrazione e giustizia. A questi si sommano i sistemi che fungono da componenti di sicurezza in prodotti già regolati (Allegato I). Per l'alto rischio scattano gli obblighi pesanti, dalla gestione dei rischi alla documentazione tecnica, dalla sorveglianza umana alla registrazione, con un calendario applicativo che la proposta di Digital Omnibus presentata dalla Commissione a novembre 2025 propone di ricalibrare, senza toccarne la sostanza. Il terzo livello è il rischio limitato, dove l'obbligo principale è la trasparenza: chi interagisce con un chatbot deve saperlo, i contenuti generati vanno resi riconoscibili. Alla base, il rischio minimo, che copre la grande maggioranza dei sistemi e non comporta obblighi specifici oltre alle norme generali già esistenti. ## Il metodo: dal censimento alla scheda La classificazione fatta bene è un processo in quattro mosse, e la prima non è giuridica: è un censimento completo di ciò che l'organizzazione usa. Completo significa includere i sistemi comprati come tali, le funzioni AI attivate dentro software già in licenza (il modulo di screening del gestionale HR, il motore di raccomandazione dell'e-commerce), gli sviluppi interni, e gli strumenti usati informalmente dai team, perché la shadow AI non è esente dal regolamento solo perché nessuno l'ha autorizzata. La seconda mossa assegna a ogni sistema il ruolo dell'azienda, che determina il pacchetto di obblighi: fornitore se lo sviluppate o lo mettete sul mercato a vostro nome, deployer se lo utilizzate sotto la vostra autorità, con casi intermedi (personalizzazioni sostanziali possono trasformare un deployer in fornitore, ed è una delle trappole più sottovalutate nei contratti). La terza mossa è la classificazione vera e propria, sistema per sistema, con una scheda che documenti la finalità, l'ambito Allegato III eventualmente toccato, i dati trattati, le persone impattate e la categoria assegnata con la sua motivazione. La motivazione scritta conta quanto l'esito, perché in caso di verifica dimostra che la valutazione è stata fatta con metodo e non a posteriori. La quarta mossa collega ogni classificazione agli obblighi conseguenti e a un owner, trasformando la mappa in un piano. ## Gli errori che vediamo più spesso Tre errori ricorrono con una frequenza che li rende prevedibili. Il primo è delegare la classificazione al fornitore, accettando la sua autovalutazione come definitiva: il vendor ha un incentivo evidente a classificare basso, e la responsabilità del deployer resta comunque in capo al deployer. Le dichiarazioni del fornitore vanno acquisite, verificate e integrate nella propria analisi, con clausole contrattuali che coprano aggiornamenti e cambi di finalità. Il secondo errore è classificare per tecnologia invece che per uso. Lo stesso modello linguistico può essere rischio minimo quando riassume documenti interni e alto rischio quando entra in un processo di selezione del personale: la categoria segue la finalità e il contesto, il che significa che ogni nuovo caso d'uso di uno strumento già censito richiede una nuova valutazione, non un rinvio alla precedente. Il terzo errore è trattare la classificazione come un esercizio una tantum. I sistemi evolvono, i fornitori aggiornano, i team trovano usi nuovi, e una mappa ferma a sei mesi fa descrive un'azienda che non esiste più. La classificazione vive dentro il registro dei sistemi AI e si aggiorna con un processo, tipicamente agganciato al procurement e al rilascio di nuovi casi d'uso. ## Da adempimento a strumento di priorità C'è un beneficio collaterale che rende questo lavoro meno ingrato di quanto sembri: la mappa dei sistemi classificati per rischio è anche una mappa di dove l'AI tocca le decisioni che contano, e quindi un ottimo punto di partenza per prioritizzare investimenti e presidi. Nel nostro AI Rating il censimento e la classificazione alimentano la dimensione Risk, e i gap emersi (sistemi non censiti, categorie non motivate, ruoli contrattuali ambigui) entrano nella roadmap con la loro priorità. Se la vostra mappa oggi è una lista parziale in un foglio di calcolo, siete in compagnia numerosa, e il passo successivo è più breve di quanto si tema: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La domanda con cui iniziare ve la lasciamo: dei sistemi AI che la vostra azienda usa questa settimana, quanti hanno una categoria di rischio scritta da qualche parte? --- # Le quattro dimensioni della maturità AI: Readiness, Delivery, Risk e Confidence URL: https://zerofive.ai/blog/ai-governance/quattro-dimensioni-maturita-ai Data: 2026-02-05 Abstract: Readiness, Delivery, Risk e Confidence: cosa misura ciascuna dimensione della maturità AI, perché servono tutte e quattro e come si leggono insieme. Quando un cliente ci chiede perché il nostro modello di rating misuri quattro dimensioni invece di produrre un unico indice di "prontezza AI", la risposta più onesta viene dai casi che abbiamo visto fallire. Un'azienda con dati eccellenti e zero capacità di portare modelli in produzione fallisce in un modo. Una con una delivery brillante e nessun presidio dei rischi fallisce in un altro, più costoso. Una tecnicamente impeccabile che il board non difende al primo trimestre difficile fallisce in un terzo modo ancora, il più silenzioso. Un indice unico farebbe la media di questi profili e li renderebbe indistinguibili, mentre le decisioni che contano si prendono proprio sulle differenze. Le quattro dimensioni del modello AI Rating nascono da qui, e conviene guardarle una per una prima di capire come si leggono insieme. ## Readiness, ovvero le fondamenta La prima dimensione fotografa la preparazione dell'organizzazione: esiste una strategia AI deliberata o una collezione di iniziative? Chi governa le priorità? I dati sono accessibili, di qualità nota, con una ownership chiara, o vivono in silos che ogni progetto deve riconquistare da capo? Le infrastrutture reggono carichi di lavoro AI? Le competenze sono diffuse o concentrate in due persone che, se domani se ne andassero, porterebbero via la capacità dell'azienda? La Readiness è la dimensione dove le aziende italiane si sopravvalutano più spesso, per una ragione precisa: strategia e governance si possono raccontare bene nelle slide, mentre la qualità dei dati si scopre solo andando a vedere. Nei nostri assessment il divario tra la Readiness dichiarata nelle interviste al vertice e quella misurata sulle evidenze è, in media, il più ampio delle quattro dimensioni. ## Delivery, ovvero la fabbrica La seconda dimensione risponde a una domanda diversa: ammesso che l'organizzazione sia pronta, sa costruire? Qui si misurano i processi di sviluppo, la presenza di pratiche MLOps (versionamento dei modelli, pipeline riproducibili, retraining), la capacità di integrare l'AI nei sistemi esistenti invece di lasciarla in applicazioni parallele, il monitoraggio di ciò che gira in produzione, la scalabilità oltre il singolo caso d'uso. La Delivery è la dimensione preferita dei team tecnici e quella che i vendor promettono di risolvere, ed è anche la meno decisiva da sola: una fabbrica eccellente che riceve priorità sbagliate produce, con grande efficienza, cose che non servono. Il pattern che incontriamo di frequente nelle scale-up è proprio questo, Delivery a 3.5 e Readiness a 2, con il risultato di prototipi rapidissimi che non trovano mai né i dati né lo sponsor per diventare altro. ## Risk misura il permesso di operare La terza dimensione misura il presidio: la compliance verso l'EU AI Act (dai divieti già in vigore dal febbraio 2025 alla classificazione dei sistemi per rischio), l'allineamento a ISO/IEC 42001 come standard di gestione, il controllo su bias e correttezza dei modelli, la sicurezza e la protezione dei dati personali, l'esistenza di processi per gestire gli incidenti. Sul Risk vale una regola che abbiamo incorporato nel modello sotto forma di gate critici: certe carenze bloccano la classe di merito a prescindere dalla media delle altre dimensioni, perché un registro dei sistemi mancante o dati personali fuori controllo non sono debolezze compensabili, sono condizioni che possono revocare il permesso di operare. È la dimensione dove il costo dell'inazione cresce nel tempo per costruzione, visto che il calendario normativo europeo avanza a prescindere dai piani aziendali. ## Confidence chiede se qualcuno ci crede La quarta dimensione è quella che sembra soft finché non si guardano i dati di adozione. Misura il commitment reale del board (budget pluriennale o esperimenti a rate?), la fiducia degli utenti interni nei sistemi che dovrebbero usare, la robustezza percepita delle soluzioni, l'adozione effettiva contro quella dichiarata. L'abbiamo vista decidere la sorte di progetti tecnicamente perfetti. Un sistema di supporto alle decisioni che gli utenti aggirano perché non si fidano dei suggerimenti vale zero, qualunque sia la sua accuratezza, e un board che al primo intoppo taglia il budget trasforma retroattivamente in spreco tutto l'investimento fatto. La Confidence si costruisce con trasparenza sui limiti dei sistemi, formazione e coinvolgimento precoce di chi li userà, e si misura con i comportamenti, mai con i sondaggi di gradimento. ## Il profilo conta più della media Il punteggio complessivo su scala 0-5 serve alla comparabilità nel tempo, ma il valore diagnostico sta nel profilo, cioè nella forma che le quattro dimensioni disegnano insieme. Readiness alta con Delivery bassa suggerisce di comprare capacità di esecuzione o allearsi con chi la possiede. Delivery alta con Risk basso chiede di fermarsi a mettere in sicurezza prima che la velocità diventi esposizione. Tutto alto con Confidence bassa indica un problema di leadership e cultura che nessun investimento tecnologico risolverà, e che anzi l'investimento tecnologico di solito peggiora. Ogni profilo prescrive una sequenza di intervento diversa, e sbagliare sequenza costa più che sbagliare intensità: rafforzare la fabbrica quando mancano le fondamenta produce solo macerie più veloci. Se doveste disegnare a mano, ora, il profilo della vostra organizzazione sulle quattro dimensioni, quale sarebbe la più debole? La risposta istintiva è già un'informazione, e verificarla con una misurazione vera richiede quattro-sei settimane: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. La domanda successiva, quella su cosa fare del profilo, è dove il lavoro diventa interessante. --- # EU AI Act: guida operativa per le aziende italiane, tra obblighi vigenti e scadenze in movimento URL: https://zerofive.ai/blog/compliance/eu-ai-act-guida-operativa-aziende Data: 2026-02-03 Abstract: Cosa prevede l'EU AI Act per le aziende: obblighi già in vigore, calendario delle scadenze, proposta Digital Omnibus e i primi passi operativi da fare. Questa pagina approfondisce un aspetto specifico. Il quadro completo degli obblighi, dei ruoli e delle scadenze è in [AI Act: guida completa a obblighi, responsabilità e dati](/blog/compliance/ai-act-guida-completa-obblighi-responsabilita-dati). # EU AI Act: guida operativa per le aziende italiane, tra obblighi vigenti e scadenze in movimento C'è un equivoco che incontriamo in quasi tutti i comitati dove si parla di AI Act, e conviene scioglierlo in apertura: il Regolamento (UE) 2024/1689 riguarda anche, e soprattutto, chi i sistemi di intelligenza artificiale li usa, non solo chi li sviluppa. L'azienda che adotta un software di screening dei candidati, la banca che impiega modelli nella valutazione del credito, l'impresa che integra AI generativa nei processi verso i clienti: tutte rientrano nel perimetro, con ruoli e obblighi definiti. Il secondo equivoco, speculare, è pensare che ci sia tempo. Una parte del regolamento è già in vigore e già sanzionabile. ## Cosa è già legge, oggi Il regolamento è entrato in vigore il 1° agosto 2024, con un'applicazione a scaglioni. Dal 2 febbraio 2025 si applicano due blocchi che riguardano tutti. Il primo sono i divieti dell'articolo 5 sulle pratiche a rischio inaccettabile, dal social scoring alla manipolazione subliminale fino al riconoscimento delle emozioni sul luogo di lavoro, con eccezioni strette. Il secondo, molto più trasversale di quanto il suo profilo mediatico suggerisca, è l'articolo 4 sull'alfabetizzazione: le organizzazioni devono garantire un livello adeguato di AI literacy al personale che opera con questi sistemi, il che rende la formazione un obbligo normativo oltre che una buona pratica. Dal 2 agosto 2025 si sono aggiunti gli obblighi per i fornitori di modelli di AI per finalità generali, l'architettura di governance europea e l'impianto sanzionatorio, che nella fascia più alta arriva fino al 7% del fatturato mondiale annuo. Chi oggi tratta l'AI Act come un tema del futuro sta, in concreto, accumulando arretrato su norme già applicabili. ## Il calendario che verrà, e la variabile Omnibus La prossima tappa fissata dal testo è il 2 agosto 2026, data di applicazione generale del regolamento, che include gli obblighi di trasparenza dell'articolo 50 (informare le persone quando interagiscono con un'AI, marcare i contenuti generati) e, nel calendario originario, i requisiti per i sistemi ad alto rischio dell'Allegato III: gestione dei rischi, qualità dei dati, documentazione tecnica, sorveglianza umana, registrazione. Qui entra la variabile che chi pianifica il 2026 deve conoscere. Il 19 novembre 2025 la Commissione ha presentato il pacchetto di semplificazione noto come Digital Omnibus, che propone tra le altre cose di legare l'applicazione degli obblighi sull'alto rischio alla disponibilità effettiva di standard armonizzati e strumenti di supporto, con date limite spostate in avanti rispetto all'agosto 2026. L'iter legislativo è in corso mentre scriviamo, e fino all'eventuale pubblicazione in Gazzetta Ufficiale restano formalmente valide le date originarie. La lettura operativa che diamo ai clienti è prudente su entrambi i fronti: pianificare come se l'agosto 2026 valesse, accogliere un eventuale rinvio come tempo guadagnato per fare le cose bene invece che come un liberi tutti, anche perché la sostanza degli obblighi non è in discussione, si discute solo del quando. ## I quattro passi da fare adesso L'esperienza sui progetti di adeguamento suggerisce una sequenza che vale a prescindere dall'esito dell'Omnibus, perché costruisce capacità che servono comunque. Il primo passo è il censimento: un inventario dei sistemi AI in uso o in sviluppo, inclusi quelli acquistati dentro altri software e quelli usati informalmente dai team, perché non si classifica ciò che non si vede. Il secondo è la classificazione per rischio di ciascun sistema secondo le categorie del regolamento, che determina quali obblighi si applicano e con quale ruolo (fornitore, deployer, importatore). Il terzo è la verifica di conformità sugli obblighi già vigenti, divieti e alfabetizzazione in testa, con un piano di formazione documentato. Il quarto è l'assegnazione delle responsabilità, perché l'adeguamento all'AI Act attraversa legale, IT, risk, HR e business, e senza un owner con mandato esplicito si dissolve in riunioni. Su questo percorso vale la nostra avvertenza di sempre: si parla di gap analysis e di preparazione, mai di conformità garantita, che nessun consulente serio può promettere e che il regolamento stesso costruisce come processo continuo, non come bollino. ## La compliance come sottoprodotto della governance L'errore strategico da evitare è trattare l'AI Act come un progetto di compliance isolato, un cantiere legale da chiudere e archiviare. Le cose che il regolamento chiede, sapere quali sistemi si usano, valutarne i rischi, documentare le decisioni, formare le persone, presidiare i dati, sono esattamente le componenti di una governance AI fatta bene, quella che serve per generare valore prima ancora che per evitare sanzioni. Nel nostro AI Rating la dimensione Risk misura proprio questa distanza, con riferimenti puntuali agli articoli del regolamento per ogni gap rilevato, dentro una valutazione complessiva della maturità. Se il vostro consiglio o il vostro comitato rischi ha messo l'AI Act in agenda per quest'anno, il modo più rapido per trasformare l'agenda in un piano è misurare il punto di partenza: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Le scadenze possono ancora muoversi, la direzione no, e la distanza da colmare è la stessa in entrambi i casi: meglio conoscerla con un numero. --- # Il costo reale dei progetti AI falliti: sprechi, tempo e credibilità URL: https://zerofive.ai/blog/approfondimenti/costo-reale-progetti-ai-falliti Data: 2026-01-29 Abstract: Il 95% dei pilot GenAI non produce ritorni misurabili secondo il MIT. Quanto costa davvero un progetto AI fallito, tra spesa diretta, tempo e credibilità. I numeri sul fallimento dei progetti AI sono usciti tutti nel giro di pochi mesi, e messi in fila compongono un quadro che nessun comitato investimenti accetterebbe per qualunque altra classe di spesa. Il MIT Project NANDA (The GenAI Divide, luglio 2025) ha analizzato oltre trecento implementazioni enterprise: il 95% dei pilot di AI generativa non produce alcun impatto misurabile sul conto economico, a fronte di 30-40 miliardi di dollari investiti. RAND Corporation stimava già nel 2024 che oltre l'80% dei progetti AI manca il valore atteso, circa il doppio dei progetti IT tradizionali comparabili. S&P Global Market Intelligence (Voice of the Enterprise, 2025) ha registrato il dato più brusco: il 42% delle aziende ha abbandonato la maggior parte delle proprie iniziative AI, dal 17% dell'anno precedente. La reazione più diffusa a questi numeri è archiviare il pilot fallito come "apprendimento" e ripartire con il successivo. La contabilità vera del fallimento, quella che vediamo emergere negli assessment, è molto più larga della voce di budget cancellata, e vale la pena scomporla, perché ogni componente ha un rimedio diverso. ## La spesa diretta è la parte piccola Il costo visibile, licenze, consulenze, giornate del vendor, infrastruttura di test, è quello che finisce nel post-mortem, quando un post-mortem si fa. Nella nostra esperienza rappresenta di rado più di un terzo del conto totale, ed è anche l'unica componente che l'organizzazione percepisce come persa. Sopra ci sta il tempo delle persone migliori. Un pilot AI serio assorbe per mesi i data engineer più capaci, i process owner più esperti, ore di comitati e steering. Se il progetto muore, quel tempo qualificato non torna, e il suo costo opportunità raramente viene calcolato: cosa avrebbero prodotto quelle stesse persone su un'iniziativa con prerequisiti solidi? La ricerca RAND indica tra le cause primarie proprio gli obiettivi disallineati e le fondamenta dati inadeguate, cioè condizioni note prima di partire, il che rende il tempo bruciato un costo evitabile e non un incidente. ## Il danno che si vede dopo: la credibilità interna La componente più costosa è anche la meno contabilizzata. Ogni pilot fallito alza il prezzo del successivo, perché consuma la risorsa più scarsa di qualunque trasformazione: la disponibilità delle persone a crederci ancora. Il terzo progetto AI presentato a un management che ha visto affondare i primi due parte con uno sconto di fiducia che nessuna demo recupera, e lo stesso vale per i team operativi, che imparano in fretta a trattare l'ennesima iniziativa come una moda passeggera da lasciar sfogare. Il report del MIT descrive questo effetto da un'angolatura rivelatrice: mentre i pilot ufficiali si fermano, in oltre il 90% delle aziende i dipendenti usano strumenti AI personali che funzionano. La domanda di AI resta alta, la fiducia nella capacità dell'organizzazione di soddisfarla crolla, e il divario tra le due curve è il costo reputazionale interno del fallimento, quello che trasforma i progetti futuri in salite. ## Fallire bene, fallire male Un chiarimento, prima delle conclusioni sbagliate: una quota di fallimenti è fisiologica e persino desiderabile, perché l'AI resta un territorio in cui si valida sperimentando. Il problema del 95% non sta nel fatto che i pilot chiudano, sta nel come. Un esperimento con ipotesi chiara, soglia di successo scritta e budget contenuto che chiude a un no ha prodotto un'informazione a basso costo, e quella è ricerca ben spesa. Un progetto partito senza criteri, cresciuto per inerzia e abbandonato per sfinimento dopo diciotto mesi ha prodotto solo il conto di cui sopra. La differenza tra i due esiti si decide quasi interamente prima del kickoff, ed è una questione di prerequisiti misurabili: dati pronti a reggere la scala, uno sponsor con potere di firma, metriche di business definite da chi possiede il processo, un perimetro di rischio e compliance mappato. Le cause di fallimento censite da RAND e dal MIT sono in larga parte diagnosi che un assessment serio formula in poche settimane, a un costo che è una frazione di un singolo pilot. ## La due diligence che manca Se il 95% dei pilot non produce ritorno, la leva con il rendimento più alto non è migliorare l'esecuzione del prossimo, è selezionare meglio a monte. Il nostro AI Rating fa esattamente questo lavoro di due diligence interna: misura su scala 0-5 la capacità dell'organizzazione lungo quattro dimensioni e dice, prima dell'investimento, quali gap condannerebbero il progetto e quanto costa chiuderli. Chi arriva da una serie di fallimenti di solito scopre che i pilot non erano sbagliati nell'idea, erano prematuri nei prerequisiti. Il conto dei progetti falliti, alla fine, lo si può leggere in due modi: come il prezzo pagato per imparare, o come la misura di quanto valga iniziare a misurare. Se nel vostro 2025 c'è almeno un pilot archiviato senza un perché scritto, mezz'ora su calendly.com/fabiolalli/zerofive serve a evitare che il 2026 lo replichi, oppure scrivete a hello@zerofive.ai. Quanto è costato davvero l'ultimo progetto AI che avete chiuso, contando tutto? --- # AI Rating: perché serve un punteggio oggettivo prima di investire URL: https://zerofive.ai/blog/ai-governance/ai-rating-punteggio-oggettivo Data: 2026-01-27 Abstract: Cos'è l'AI Rating, come funziona una valutazione su scala 0-5 con classi di merito, e perché il punteggio dovrebbe precedere ogni investimento in AI. Nessun CFO approverebbe un'acquisizione senza due diligence, nessuna banca concederebbe credito senza un rating, nessun CISO comprerebbe una piattaforma di sicurezza senza un assessment del proprio perimetro. Poi arriva il budget AI, spesso il capitolo di spesa tecnologica che cresce più in fretta, e la disciplina evapora: si parte dal fornitore, dal caso d'uso di moda, dalla demo vista a un evento, senza che nessuno abbia misurato se l'organizzazione è in grado di trasformare quell'investimento in valore. L'AI Rating nasce per riportare sull'AI la stessa disciplina che le aziende applicano a ogni altra allocazione di capitale rilevante. L'analogia con il rating di credito è voluta e va presa sul serio, perché ne eredita tre proprietà: un punteggio sintetico e confrontabile, una metodologia trasparente e ripetibile, regole di gating per cui certe carenze non sono compensabili da altri punti di forza. ## Come si arriva al punteggio La valutazione attraversa quattro dimensioni, ognuna con un punteggio da 0 a 5. AI Readiness fotografa la preparazione, dalla strategia alla qualità dei dati, dalle infrastrutture alle competenze diffuse. AI Delivery guarda alla capacità di esecuzione, cioè processi di sviluppo, MLOps, integrazione con i sistemi esistenti, monitoraggio di ciò che va in produzione. AI Risk presidia la governance, con la compliance verso l'EU AI Act e ISO/IEC 42001, la gestione di bias, sicurezza e privacy. AI Confidence misura l'adozione reale, dal commitment del board alla fiducia di chi i sistemi li usa ogni giorno. Il metodo conta quanto il modello. Ogni punteggio nasce dall'incrocio tra evidenze documentali (architetture, policy e metriche di progetto) e interviste condotte a più livelli, dal board ai team operativi, perché la distanza tra il dichiarato e il vissuto è essa stessa un dato, spesso il più eloquente. Il risultato si sintetizza in quattro classi di merito, dalla A dei leader (score sopra 4.0, nessuna area sotto 3.5, gate soddisfatti) alla D di chi è allo stadio iniziale, con la C nel mezzo a raccogliere il caso più frequente in Italia: capacità presenti, pilot mai scalati, maturità in costruzione. I gate critici meritano una parola in più, perché sono ciò che distingue un rating da un sondaggio. Un'azienda può eccellere in strategia e delivery, ma se manca un registro dei sistemi AI, se i dati personali circolano senza presidio o se nessuno ha classificato i sistemi per rischio come chiede il quadro europeo, la classe di merito resta bloccata. Il messaggio incorporato nel meccanismo è che su certe fondamenta non si negozia. ## Cosa cambia nelle decisioni, concretamente Il valore del punteggio si vede in tre momenti decisionali precisi. Il primo è l'allocazione del budget: sapere di essere una classe C con Risk a 1.8 sposta la spesa dal terzo pilot alla chiusura dei gap che hanno affossato i primi due, e nella nostra esperienza (34+ assessment condotti, dati ZeroFive.AI al 2026) questa singola correzione di rotta vale più di qualunque quick win tecnologico. Il secondo momento è la conversazione con il board. Un consiglio di amministrazione non può governare ciò che non riesce a confrontare, e il rating gli consegna esattamente questo: un numero da mettere in dashboard accanto ai KPI finanziari, da rimisurare a dodici mesi, su cui chiedere conto al management con la stessa naturalezza con cui si discute di marginalità. La fotografia isolata invecchia, il confronto tra due misurazioni governa. Il terzo momento è il dialogo con l'esterno, auditor, regolatori, clienti enterprise che nei capitolati iniziano a chiedere evidenze di governance AI. Un rating documentato, con riferimenti normativi puntuali per ogni raccomandazione, dimostra di aver affrontato il tema con metodo, che è cosa diversa dal dichiararsi conformi (la conformità certificata è un percorso a sé, e diffidiamo di chi la promette in un assessment). ## Quando farlo, e quando rifarlo Il momento giusto per la prima misurazione è prima di un ciclo di investimento, non dopo. Le occasioni tipiche che vediamo: un piano industriale che include l'AI, un board che chiede una strategia, una serie di pilot dagli esiti deludenti, una scadenza normativa all'orizzonte. La baseline richiede quattro-sei settimane e produce deliverable calibrati per ciascun livello, la sintesi strategica per il board, il report analitico dei gap per i team, la roadmap con quick win a 30 giorni, i dati grezzi per audit e governance. La singola misurazione, però, è solo l'inizio del meccanismo. Il modello prevede un ciclo, baseline, esecuzione delle azioni correttive, re-assessment a dodici mesi, perché l'obiettivo dichiarato è trasformare il rating in un KPI strutturale dell'organizzazione, monitorato nel tempo come qualunque altro indicatore direzionale. Se state per approvare un budget AI per il 2026, la domanda da farvi prima della firma è semplice: su quali evidenze si fonda? Se la risposta è una lista di progetti proposti e nessuna misura della capacità di realizzarli, mezz'ora di conversazione può farvi risparmiare mesi: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. Il capitale paziente non è quello che aspetta, è quello che misura prima di muoversi. --- # Shadow AI: cosa succede quando i dipendenti usano l'AI senza policy URL: https://zerofive.ai/blog/approfondimenti/shadow-ai-azienda-rischi-policy Data: 2026-01-20 Abstract: In oltre il 90% delle aziende i dipendenti usano strumenti AI personali. Cos'è la shadow AI, quali rischi crea e perché vietarla è la risposta sbagliata. Fate un esercizio la prossima volta che attraversate l'open space: contate quante finestre di ChatGPT, Gemini o Copilot sono aperte su account personali. Nei progetti che seguiamo la risposta sorprende sempre il management, mai i team. Il report del MIT Project NANDA (The GenAI Divide, luglio 2025) ha dato una misura al fenomeno: in oltre il 90% delle aziende analizzate i dipendenti usano strumenti AI personali per lavorare, spesso proprio dove i pilot ufficiali si sono fermati. I ricercatori la chiamano shadow AI economy, un'economia parallela che non compare in nessun inventario, in nessun budget e in nessuna valutazione dei rischi. La lettura istintiva è quella della violazione da reprimere. La nostra, dopo averla incontrata in quasi tutti gli assessment condotti, è diversa: la shadow AI è il segnale più affidabile che esista sulla domanda reale di AI dentro l'organizzazione, e insieme il rischio operativo più sottovalutato del momento. ## L'inventario che nessuno ha Il problema di governance comincia da una domanda a cui pochissime aziende sanno rispondere: quali sistemi AI vengono usati oggi, da chi, su quali dati. La versione ufficiale della risposta elenca i progetti approvati. La versione reale include decine di strumenti consumer, plugin installati in autonomia, funzioni AI attivate silenziosamente dentro software già in licenza, automazioni costruite da singoli team con account gratuiti. La distanza tra le due versioni ha conseguenze concrete. Un documento con dati di clienti caricato su un servizio consumer è un trattamento di dati personali che nessuno ha valutato, con tutto ciò che ne segue sul piano GDPR. Un output non verificato che rientra in un processo decisionale è un errore che non ha un responsabile. E dal 2 febbraio 2025 c'è un livello in più: l'EU AI Act, con l'articolo 4, chiede alle organizzazioni di garantire un livello adeguato di alfabetizzazione all'AI per il personale che la utilizza, e la norma non distingue tra strumenti approvati e strumenti portati da casa. ## Perché il divieto non funziona Alcune aziende hanno risposto bloccando i domini dei principali servizi AI. Nella nostra esperienza il risultato è prevedibile: l'uso si sposta sullo smartphone personale, esce completamente dal perimetro osservabile e diventa impossibile perfino da stimare. Il divieto trasforma un fenomeno visibile e gestibile in uno invisibile, che è la peggiore delle configurazioni possibili per chi deve presidiare i rischi. C'è anche una ragione più profonda per cui la repressione fallisce. Le persone usano questi strumenti perché funzionano, perché tolgono attrito da compiti che il flusso ufficiale rende lenti, e questa informazione vale oro: ogni uso ombra è una segnalazione gratuita su dove l'AI produrrebbe valore se fosse adottata sul serio. Un'organizzazione che spegne il segnale rinuncia alla migliore mappa dei propri use case, quella disegnata dai comportamenti invece che dai workshop. ## Dal fenomeno al perimetro governato Il percorso che proponiamo ai clienti ha una sequenza precisa, e il primo passo è un censimento senza intenti punitivi: una finestra di emersione in cui team e persone dichiarano quali strumenti usano e per cosa, con la garanzia esplicita che l'obiettivo è capire, e semmai dotare tutti di alternative sicure. Il censimento alimenta il registro dei sistemi AI, che serve sia alla gestione quotidiana sia alla classificazione per rischio richiesta dal quadro normativo europeo. Il secondo passo è una policy scritta per essere usata, con tre categorie chiare (consentito, consentito con cautele, vietato), esempi concreti per ciascuna e una regola semplicissima sui dati: cosa può uscire dal perimetro aziendale e cosa no. Le policy di venti pagine che nessuno legge producono lo stesso effetto del divieto, cioè nessuno. Il terzo passo è la parte che quasi tutti saltano, e cioè dare alle persone uno strumento ufficiale almeno altrettanto buono di quello che usavano di nascosto, accompagnato dalla formazione che l'articolo 4 dell'AI Act comunque richiede. La shadow AI non si estingue per decreto, si prosciuga per convenienza: quando l'alternativa interna è comoda, sicura e disponibile, il canale ombra perde la sua ragione d'essere. ## La misura prima della policy Resta la domanda di priorità: da dove iniziare, con quale urgenza, con quali risorse. La risposta dipende da quanto è esteso il fenomeno e da quanto è matura l'organizzazione nel gestirlo, due cose che si possono misurare invece di supporre. Nel nostro AI Rating la shadow AI attraversa tre delle quattro dimensioni che valutiamo, la readiness (cultura e competenze), il rischio (dati e compliance) e la confidence (fiducia e comportamenti reali), e il punteggio dice subito se siete davanti a un fenomeno marginale o a un perimetro parallelo più grande di quello ufficiale. Se il dubbio vi è venuto leggendo, vale la pena scioglierlo con dei numeri: mezz'ora su calendly.com/fabiolalli/zerofive, o una mail a hello@zerofive.ai. Nel frattempo l'esercizio dell'open space resta gratuito, e la domanda che apre è quella giusta: se l'AI in azienda la stanno già adottando le persone, chi sta decidendo come? --- # AI maturity model: cos'è, come si misura e a cosa serve al board URL: https://zerofive.ai/blog/ai-governance/ai-maturity-model-come-si-misura Data: 2026-01-15 Abstract: Cos'è un AI maturity model, quali dimensioni misura, come funzionano scale e classi di merito e perché il board dovrebbe pretenderne uno. Provate a fare questa domanda al prossimo comitato di direzione: su una scala da 0 a 5, quanto è matura la nostra azienda nell'adozione dell'AI? Nella nostra esperienza le risposte si dividono in tre famiglie, chi cita i progetti in corso (che misurano l'attività, non la capacità), chi cita il budget speso (che misura l'intenzione), e chi ammette che una misura condivisa non esiste. La terza risposta è la più utile, perché è il punto di partenza per costruirla. Un AI maturity model serve esattamente a questo: trasformare una percezione ("siamo indietro", "stiamo andando bene") in un numero confrontabile nel tempo, tra funzioni e con il mercato. Le aziende misurano da decenni la solidità finanziaria con i rating di credito e la sicurezza informatica con framework di maturità, mentre sull'AI, dove gli investimenti crescono a doppia cifra, la maggior parte decide ancora a sensazione. ## Cosa misura davvero un modello di maturità La parola maturità inganna, perché suggerisce una classifica tecnologica, quanti modelli abbiamo, quanto sono sofisticati. Un modello serio misura una cosa diversa: la capacità dell'organizzazione di trasformare l'AI in valore in modo ripetibile e governato. Un'azienda può avere il modello linguistico più avanzato sul mercato e una maturità bassa, perché i dati sono frammentati, nessuno presidia i rischi e il board non ha mai deliberato una strategia. Il nostro AI Rating, il framework proprietario che usiamo negli assessment ZeroFive, scompone questa capacità in quattro dimensioni. AI Readiness misura la preparazione: strategia, governance, qualità dei dati, infrastrutture, competenze e cultura. AI Delivery misura l'esecuzione: processi di sviluppo, MLOps, integrazione con i sistemi, scalabilità e monitoraggio. AI Risk misura il presidio: compliance con l'EU AI Act e con ISO/IEC 42001, etica, bias, sicurezza, privacy. AI Confidence misura l'adozione: commitment del board, fiducia degli utenti, robustezza percepita delle soluzioni. La quarta dimensione è quella che sorprende di più i clienti, perché sembra soft e invece è predittiva: un sistema tecnicamente eccellente che gli utenti non usano, o che il board non difende al primo intoppo, ha lo stesso valore di un sistema che non esiste. ## Scale, classi e la logica dei gate critici La misurazione produce un punteggio da 0 a 5 per ciascuna dimensione e un rating globale, sintetizzato in quattro classi di merito, dalla A (leader, score sopra 4.0 con nessuna area sotto 3.5) alla D (stadio iniziale, score sotto 2.0, approccio opportunistico, prerequisiti mancanti). In mezzo, la classe B degli avanzati e la classe C di chi ha capacità presenti ma debolezze significative, tipicamente pilot mai scalati. Il meccanismo che rende il modello credibile, e che manca in molti self-assessment scaricabili online, è quello dei gate critici non compensabili. Un punteggio alto su strategia e delivery non può compensare l'assenza di un registro dei sistemi AI o una gestione dei dati personali fuori controllo: certe carenze bloccano la classe di merito a prescindere dalla media, esattamente come nei rating di credito un covenant violato pesa più di dieci indicatori in ordine. Senza gating, il modello premia chi è bravo a raccontarsi. C'è poi un requisito di metodo che vale per qualunque framework scegliate: la valutazione deve combinare evidenze quantitative (documenti, architetture e metriche reali) con interviste qualitative a più livelli dell'organizzazione, perché il divario tra ciò che il management dichiara e ciò che i team operativi vivono è, quasi sempre, il dato più informativo dell'intero assessment. ## Il numero che il board dovrebbe pretendere Per un consiglio di amministrazione il rating di maturità AI risolve tre problemi concreti. Il primo è la comparabilità nel tempo: ripetere la misurazione a dodici mesi trasforma una fotografia in un filmato, e permette di chiedere conto dei progressi con la stessa disciplina con cui si seguono i KPI finanziari. Il nostro obiettivo dichiarato, nei progetti che seguiamo, è portare il rating AI nella dashboard direzionale come indicatore strutturale monitorato dal board. Il secondo è la difendibilità verso l'esterno. Con l'EU AI Act in vigore dall'agosto 2024 e le sue scadenze applicative in arrivo, con ISO/IEC 42001:2023 che definisce lo standard per i sistemi di gestione dell'AI, board, comitati rischi e auditor hanno bisogno di dimostrare di aver valutato lo stato dell'arte con metodo. Un rating documentato, con evidenze e riferimenti normativi puntuali per ogni area, è la base di quella dimostrazione (parliamo di preparazione e gap analysis, non di conformità certificata, che è un percorso diverso). Il terzo problema è l'allocazione del capitale. Sapere che l'azienda è una classe C con Readiness a 3.1 e Risk a 1.8 cambia la conversazione sul budget: prima di finanziare il terzo pilot si finanzia la chiusura dei gap che hanno bloccato i primi due. La maturità bassa non è una condanna, è un'informazione, e chi la possiede spreca meno. ## Da dove iniziare, in pratica Il primo assessment richiede tipicamente da quattro a sei settimane e produce deliverable per ogni livello: una sintesi strategica per il board, un report analitico dei gap per i team, una roadmap con quick win a 30 giorni e progetti prioritizzati, i dati grezzi per governance e audit. Il costo è una frazione di un pilot medio, e nella nostra esperienza ne evita almeno uno sbagliato. Se volete capire come funzionerebbe sulla vostra organizzazione, trovate il tempo per una call su calendly.com/fabiolalli/zerofive o scrivete a hello@zerofive.ai. Prima però vale la pena rifare al vostro comitato la domanda dell'inizio, quella sulla scala da 0 a 5, e osservare non tanto le risposte quanto quanto divergono tra loro: quella distanza è la prima misura della vostra maturità. --- # Pilot AI bloccati: le cinque cause ricorrenti e come riconoscerle URL: https://zerofive.ai/blog/approfondimenti/pilot-ai-bloccati-cause-ricorrenti Data: 2026-01-07 Abstract: Perché i pilot AI non arrivano in produzione: le cinque cause ricorrenti, i segnali per riconoscerle in anticipo e il percorso per sbloccarle. C'è una scena che nei tavoli dove lavoriamo si ripete con una regolarità quasi imbarazzante: il pilot è tecnicamente riuscito, la demo ha convinto tutti, il vendor ha fatturato la sua fase uno, e poi niente. Sei mesi dopo il progetto è ancora lì, in quella terra di mezzo tra "funziona" e "lo usiamo davvero", con un budget consumato e nessuno che sappia dire con precisione perché non si va avanti. Il fenomeno ha un nome nella letteratura di settore, pilot purgatory, e riguarda la maggioranza delle sperimentazioni AI nelle imprese europee. La cosa che ci colpisce, dopo oltre trenta assessment condotti (dati ZeroFive.AI al 2026), è che le cause quasi mai sono tecnologiche. Sono cinque, si ripetono, e si possono riconoscere prima ancora di avviare il pilot. ## Un pilot nato senza una decisione La prima causa sta a monte, nel momento in cui il pilot viene approvato. In molte organizzazioni la sperimentazione parte per entusiasmo, per pressione competitiva, perché "dobbiamo fare qualcosa con l'AI", e nessuno definisce cosa dovrebbe succedere se il pilot funziona: quale budget scatta, quale processo cambia, chi firma il passaggio in produzione. Un pilot senza criteri di go/no-go definiti in partenza non è un esperimento, è un rinvio travestito da azione. L'esperimento vero ha un'ipotesi, una soglia di successo e una conseguenza già deliberata per entrambi gli esiti. Quando manca questo, il pilot riuscito finisce in una presentazione e la decisione resta esattamente dove stava. ## Dati che non reggono il passaggio di scala La seconda causa emerge quasi sempre tra la demo e la produzione. Il pilot gira su un dataset curato a mano, pulito per l'occasione, spesso estratto una tantum da qualcuno che conosceva bene quel sistema, e tutto funziona. Poi si prova a collegare i dati veri, quelli che vivono in tre gestionali diversi con anagrafiche disallineate e campi compilati in modo incoerente da anni, e il modello che in demo faceva il 92% di accuratezza smette di essere affidabile. Il segnale per riconoscere questa causa in anticipo è semplice: chiedere, prima del pilot, quanto tempo servirebbe per ricostruire il dataset di test in modo automatico e ricorrente. Se la risposta è vaga, il problema non è il modello. ## Uno sponsor che non c'è, o sono troppi Terza causa, la più politica. I pilot bloccati hanno quasi sempre una ownership ambigua: il progetto è partito dall'IT ma tocca un processo del commerciale, oppure l'ha voluto un direttore che nel frattempo ha cambiato ruolo, oppure lo sponsor formale è il CEO ma il CEO lo ha delegato a qualcuno che non ha potere di spesa. Il passaggio in produzione richiede sempre di togliere qualcosa a qualcuno, un processo, un'abitudine, a volte una responsabilità, e questo scatto avviene solo con uno sponsor esecutivo che ci mette la faccia e un team operativo che possiede il processo. Quando nei nostri assessment misuriamo la dimensione che chiamiamo AI Confidence, il commitment del board pesa quanto la robustezza tecnica, una scelta che deriva da quello che vediamo determinare, caso dopo caso, chi scala e chi resta fermo. ## Metriche di successo mai scritte La quarta causa si scopre facendo una domanda sola: come misuriamo se ha funzionato? Nei pilot bloccati la risposta arriva dopo una pausa, e di solito riguarda metriche di modello (accuratezza, precisione, latenza) e mai metriche di business (ore risparmiate, errori evitati, margine recuperato, rischio ridotto). Le due famiglie di metriche non sono intercambiabili, perché un modello accurato applicato a un processo marginale produce un pilot perfetto e irrilevante. La metrica di business va scritta prima, con il valore atteso e la soglia sotto la quale si chiude, e va scritta da chi possiede il conto economico di quel processo, non dal team tecnico. ## Il salto in produzione non era stato progettato L'ultima causa è quella che i team tecnici conoscono meglio e che il management scopre per ultima. Portare un modello in produzione significa integrazione con i sistemi esistenti, monitoraggio continuo delle performance, gestione delle derive, un presidio di sicurezza e privacy, e da quest'anno anche un perimetro normativo esplicito, con l'EU AI Act che chiede di classificare i sistemi per rischio e documentarli. Tutto questo ha un costo che spesso supera quello del pilot stesso, e se non era stato stimato all'inizio arriva come una brutta sorpresa che congela il progetto. Il pilot andava progettato con la produzione in mente fin dal primo giorno, con l'architettura di integrazione almeno abbozzata e i requisiti di compliance mappati, perché la validazione riguarda anche la sostenibilità del dopo. ## Da dove si riparte Le cinque cause hanno una radice comune: si è iniziato a costruire prima di aver misurato e deciso. La sequenza sana è inversa, prima si valuta la maturità dell'organizzazione (dati, competenze, governance, commitment), poi si sceglie dove sperimentare con criteri espliciti, poi si valida, e solo dopo si automatizza. Il nostro AI Rating nasce esattamente per questo passaggio: misura su una scala 0-5 la capacità reale dell'azienda di portare l'AI in produzione, su quattro dimensioni (Readiness, Delivery, Risk, Confidence), e restituisce una roadmap a 90 giorni con i gap da chiudere prima di investire ancora. Chi ha pilot fermi da mesi di solito scopre che il blocco era scritto nei prerequisiti, e che sbloccarlo costa meno di quanto temeva. Se avete uno o più pilot in questa condizione, il primo passo utile è capire quale delle cinque cause vi riguarda, perché la terapia è diversa per ciascuna. Trenta minuti di conversazione bastano per una prima diagnosi: potete prenotarle su calendly.com/fabiolalli/zerofive, oppure scriverci a hello@zerofive.ai. La domanda con cui vale la pena arrivare è una sola: se il pilot funzionasse domani, chi firmerebbe il passaggio in produzione? --- # No agent goes to production without a named owner URL: https://zerofive.ai/en/blog/ai-governance/ai-agents-named-owner-production Data: 2026-10-09 Abstract: Agent inventory, real owner powers, dedicated identities and least privilege. When an agent falls under Annex III. **In short.** The most effective rule on AI agents is also the easiest to check: no agent goes to production without a named person answering for it. It is an organisational rule, it costs little, and it separates companies that know what runs in house from those that will find out when something goes wrong. Nearly three quarters of organisations expect to adopt agents within two years, and around one in five reports a mature governance model for managing them. An agent differs from a model answering a question, because it plans, uses tools, writes to company systems and produces effects outside the conversation, from opening a ticket to changing a record. Risk moves from the output to the action, and a wrong action isn't fixed by rereading the answer. ## Why ownership gets skipped Agents almost always appear outside formal processes. Somebody switches on a feature inside a platform already in use, a team builds an internal automation, a supplier offers a module that performs operations in place of an operator. None of these looks like buying software, so nobody triggers the process that assigns a responsible person. The result is that in many organisations the active agents outnumber the recorded ones, the question of who authorised them has no answer, and when something goes wrong the reconstruction starts from people instead of logs. The same dynamic we described for [shadow AI](/en/blog/insights/shadow-ai-company-risks-policy) applies, with one difference: here the system acts. ## What being an owner means A name on a document means little without concrete powers. An owner who cannot stop the agent is a signature of convenience. | Power | Why it matters | |---|---| | Stop the agent without going through anyone else | Anomalous behaviour has to be interrupted in minutes, not days | | Change the autonomy limits | Thresholds get tuned through use, not decided once | | Access the action logs | Without tracing, what happened cannot be reconstructed | | Approve extension to new systems | An agent gaining access changes its risk profile | | Answer for the outcome to management | This is what makes responsibility real | The owner is a business figure. Whoever answers for an agent handling payment reminders sits in the finance function, with IT support on the technical side, because the consequences of a wrong reminder land on the customer relationship rather than on the infrastructure. ## The agent inventory It needs to be separate from the general AI system inventory, because the information to keep is different. For each agent, record purpose, owner, systems it can write to, data it accesses, autonomy limits, how it is stopped, and the environment it runs in. The part forgotten most often is the list of systems the agent can act on, which is also what separates the risk profiles: an assistant reading documents exposes information, while an agent changing an order or sending a message to a customer produces operational and contractual effects that are hard to undo. ## Identity and permissions An agent using a person's credentials makes it impossible to tell one's actions from the other's. It is the underlying problem that renders much of the logging useless: the records exist and attribute everything to a human account whose owner was doing something else at the time. The right direction is a dedicated identity per agent, with least privilege and separation by environment, and it takes work on the identity infrastructure that belongs in the project budget rather than surfacing halfway through. It rarely appears in the initial estimate. ## When an agent falls under Annex III If an agent operates inside a high-risk use case, the high-risk obligations apply to that use case. An agent sorting applications sits in workforce management, and the classification doesn't change because the system is called an assistant. There is a second step worth knowing. A deployer using an agent differently from what the provider intended can become the provider of a high-risk system, with the obligations that follow. The distinction between intended use and actual use has to be documented, and the place for it is the [AI systems register](/en/blog/compliance/ai-systems-register-how-to-build). ## Where to start The entry point is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), extended to agents with the extra fields described above. The criteria for judging whether an agentic project makes sense are in [AI agent PoCs](/en/blog/strategy/ai-agent-pocs-how-to-make-them-work), while the general framing is in [AI agents in the enterprise](/en/blog/insights/ai-agents-enterprise). To find out which agents are live in your organisation and who answers for them you can [book an assessment session](https://calendly.com/fabiolalli/zerofive). --- # AI Act: what actually happens on 2 December 2027 URL: https://zerofive.ai/en/blog/compliance/ai-act-december-2-2027-fourteen-months Data: 2026-10-07 Abstract: The delay on high-risk obligations is not a pause. The updated calendar and the work that really fits in the fourteen months left. **In short.** The Digital Omnibus moved the obligations on high-risk systems under Annex III from 2 August 2026 to 2 December 2027, and those on systems embedded in regulated products to 2 August 2028. The common reading is that there is time. Counting the actual work it takes to arrive ready, fourteen months is a tight deadline for an organisation that today doesn't know which AI systems it has in production. Regulation (EU) 2026/1744 entered into force on 27 July 2026, days before the deadline that would have made high-risk obligations applicable. The practical result is that many companies stopped work they had just started, reading the delay as permission to postpone. That is the reading that costs most. ## What was delayed and what wasn't The delay covers a precise perimeter. Prohibited practices and the AI literacy obligation under Article 4 remain applicable, in force since February 2025, as do obligations for providers of general-purpose AI models since August 2025, and from 2 August 2026 the general application of the regulation with the transparency obligations of Article 50, national authorities and the penalty regime. | What | From when | |---|---| | Prohibited practices and the AI literacy obligation | 2 February 2025 | | Obligations for providers of general-purpose AI models | 2 August 2025 | | General application, Article 50 transparency, penalties | 2 August 2026 | | Standalone high-risk systems under Annex III | 2 December 2027 | | High-risk systems embedded in regulated products | 2 August 2028 | | High-risk systems intended for public authorities | 2 August 2030 | A chatbot that doesn't declare itself an automated system is out of line today, and recruitment software remains subject to the GDPR and labour law, with every obligation that follows, whatever the date the AI Act ones start to bite. ## Fourteen months, counted properly The distance between today and December 2027 looks generous until the work is laid out. This is the sequence we see in real projects, with the durations we observe in mid-sized organisations. | Phase | Typical duration | |---|---| | AI system inventory, including modules inside software already in use | 6-10 weeks | | Risk classification and role identification, provider or deployer | 4-6 weeks | | Gap analysis on systems that turn out to be high risk | 4-8 weeks | | Contract renegotiation with suppliers on documentation and logs | 3-6 months | | Documentation, risk assessment, human oversight | 4-6 months | | Role-based training with individual evidence | continuous | | Internal verification ahead of the deadline | 2 months | The phases don't all run in sequence, but two of them depend on third parties and won't compress. Renegotiating with a supplier who has never produced the required documentation takes the time of their release cycle, not yours. ## The work that doesn't start with legal The recurring mistake is handing preparation to legal or compliance and waiting for the result. Those functions can read the regulation, they don't know which systems are switched on across the company, and they can't know, because the information sits split between whoever signed the contracts, whoever activated the modules and whoever uses them daily. The first step is technical and organisational at once. It takes a survey starting from active software contracts and systems in use, asking each function which predictive modules have been switched on over the last two years. In the projects we have run, between a third and half of the relevant systems were unknown to whoever handled compliance. The second step concerns the role. A company using a supplier's model is a deployer, with its own obligations, and can become a provider if it substantially modifies the system, rebrands it or uses it for a purpose other than the one the supplier declared, and in that case the volume of work changes by an order of magnitude. That distinction belongs before any plan is built. ## Who arrives late, and how to spot them Organisations arrive late when they wait for harmonised technical standards before starting, because those standards serve to demonstrate conformity by presumption, while knowing which systems you have, who authorised them and what they actually do is work that depends on no standard and can be done now. Whoever treats the deadline as a one-off project also arrives late. High-risk systems require post-market monitoring, documentation upkeep and incident recording, so an organisation building everything in the three months before the deadline reaches the line with its paperwork in order and without the oversight it needs from the next day. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), followed by [risk classification](/en/blog/compliance/ai-systems-risk-classification) and the [AI systems register](/en/blog/compliance/ai-systems-register-how-to-build). The detail of what has been binding since 2 August 2026 is in [AI Act: what is binding](/en/blog/compliance/ai-act-august-2-2026-what-is-binding), while the content of the package that moved the dates is in [Digital Omnibus](/en/blog/compliance/digital-omnibus-regulation-2026-1744). To measure the distance between where you stand and what December 2027 will require, see the [AI Rating](/en/services/ai-rating) page. For an assessment you can [book a session](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # Connecting AI to company data: why you need an AI Company OS URL: https://zerofive.ai/en/blog/strategy/connect-ai-to-company-data-ai-company-os Data: 2026-10-03 Abstract: How to connect ChatGPT, Claude or Copilot to company data safely: MCP, ontology, data classification and human approval in an AI Company OS. **In short.** Connecting ChatGPT, Claude or Copilot to email, Drive and the CRM now takes a few minutes, and almost every company is trying it. The result, however, depends on how the knowledge the model reads is organised: without types and approval rules the assistant produces plausible answers whose origin nobody knows. An AI Company OS is the layer that brings order before the model, and decides which data goes to which AI and with which permissions. Over the last year connectors have changed the way companies use generative AI. With the Model Context Protocol (MCP), the open standard Anthropic published in November 2024 and that OpenAI, Google and Microsoft adopted in the following months, an assistant can read an inbox, open a document, check a calendar or query a business application without anyone copying and pasting anything. The technical part, which until recently required an integration project, has become a setting to switch on. This has moved the problem elsewhere, and many companies notice it after a few weeks of use. ## Company knowledge is scattered across too many places In almost every organisation a project's knowledge lives in seven or eight different places: meeting recordings, email, a folder on Drive and another on Dropbox, the calendar, the CRM, Slack or Teams channels, Jira or Asana tickets, personal notes. Each works well on its own, and none knows the others exist. ![The knowledge lost today across company sources](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/03-sources-en.webp) A new source has joined them that did not exist two years ago: the conversations each person has with their AI assistant while preparing a proposal or analysing a problem. That is often where the most useful reasoning of the day ends up, and it disappears when the window is closed, because no company system collects it. ## What happens when an LLM reads everything The most common reaction is to connect the model to every source and expect an overall view to emerge from the connection. Almost always the opposite happens. The model reconstructs the meaning of information on its own, slightly differently each time, and two answers to the same question a week apart do not match. The typical cases are three. A client appears in the CRM with one decision maker and in meeting minutes with another, and the assistant picks one at random. A decision made in a call contradicts a document from a few days earlier, and the summary merges them as if they said the same thing. Confidential information, such as a margin or personal data, ends up in an answer read by someone who should not have seen it, because the connector used an account with access to everything. None of these errors depends on the quality of the model. A more capable model produces more convincing answers from the same fragments, and makes the error harder to see. ## What an AI Company OS is We call AI Company OS the workspace where company knowledge becomes readable by models and governed by people. Every piece of information, a meeting note, a task, a document, a contact, becomes an object with a type, an author, a date and a place in the project. Models read it with the real permissions of whoever uses them, and nothing enters the shared memory unless a person has approved it. The system is designed in six layers: centralisation, ontology, graph, connectors and models, skills, governance. The detail of the method and of the platform we use to build it is on the [AI Company OS](/en/services/ai-company-os) service page; here it is worth focusing on the three points that change the way people work the most. ![The Workspace dashboard, the platform we use on our own projects and make available to companies](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/12-workspace-dashboard.webp) ## Meaning comes before data Ontology is where a company decides what its information means, before a model decides for it. It establishes that a note does not weigh as much as a decision, that a risk calls for attention, that tags have a controlled vocabulary and three variants of the same name do not get created. The most delicate part concerns contradictions. When two sources state different things on the same point, a naive system keeps the latest or merges them into a summary. In an AI Company OS the conflict becomes an explicit link, opens a verification assigned to a person and is closed with a note stating which source was confirmed and which superseded, leaving the originals intact. ![When two sources disagree: conflict, verification and knowledge note](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/05-conflicts-en.webp) ## Which AI for which data If knowledge is structured, choosing the model becomes a decision about cost and confidentiality. The core of the system is an access server, today almost always an MCP server, independent of the model: the same server serves Claude, ChatGPT or an open model installed on a company machine, and always operates with the permissions of the person using it, never with an all-powerful technical account. ![Which model for which data: three classes of information](https://xioqqrwigutxqfzdortp.supabase.co/storage/v1/object/public/site-assets/ai-company-os/07-models-and-data-en.webp) A practical way to decide is to classify information on three levels. What can leave, such as public research and drafts, goes to the most capable commercial model. Internal information goes only to vendors with adequate contractual guarantees. What must not leave, such as confidential financial data or personal data, stays on a local model or is anonymised before sending. Changing vendor, or using two side by side, requires no migration. ## People's work changes With an AI Company OS people enter less data and approve far more information prepared by the model. Meeting minutes arrive already written, with tasks extracted and linked to the right people, and the job of whoever receives them is to say whether they are correct. The model prepares proposals with the source, an excerpt and a confidence level, and when confidence is low it does not choose: the decision goes back to a person. This rule also produces traceability, because every object has an origin and an owner. If six months from now someone asks why a decision was taken, the answer leads to a meeting, a person, a date, and it is the same kind of evidence an AI management system under ISO/IEC 42001 asks to be able to show. ## Where to start Anyone starting from scratch should begin on paper and leave the tools for later: an inventory of the information the team produces in a normal week, including what gets lost today in chats and AI conversations, and of the system that owns it. The technical part is often the fastest, because the sources already have their connectors. The long work is agreeing on what counts as a decision and on who can close a conflict. We do it starting from a single team, with a method and a platform we built for ourselves first. If you want to understand how to apply it in your company, you can [book a 30-minute inventory session](https://calendly.com/fabiolalli/zerofive) or read how the [AI Company OS](/en/services/ai-company-os) service works. --- # AI across industries: the sector decides where risk comes from URL: https://zerofive.ai/en/blog/strategy/ai-across-industries-sector-map Data: 2026-10-02 Abstract: Finance, insurance, telecom, sport, manufacturing and retail: where high risk comes from and which gate blocks the rating in each sector. **In short.** The question of what the AI Act means for a company has no single answer, because the sector decides where high risk comes from and which gate blocks the rating. In banking it comes from credit, in insurance from suppliers' models, in sport from athletes as workers, in retail from the systems managing shifts, in manufacturing from the product sold, in telecom from commercial systems. The rest of the method stays the same everywhere. We have worked across six sectors with the same sequence, system inventory, classification, measurement of the four dimensions, and each time the point blocking the organisation came from a direction management didn't expect. Below is the map, with pointers to the detailed pieces. ## The sector decides where risk comes from | Sector | Where high risk comes from | The recurring gate | |---|---|---| | [Finance](/en/sectors/finance) | Creditworthiness assessment, Annex III | No inventory covering systems already in production | | [Insurance](/en/sectors/insurance) | Pricing and risk selection on third-party models | Perimeter: the insurance company deploys models it didn't build | | [Telecom](/en/sectors/telco) | Commercial systems, starting with customer credit assessment | Classification never done on systems born as administrative tools | | [Sport](/en/sectors/sport) | Athletes as workers, biometrics in stadiums, training of coaches and match officials | Data ownership, almost always with suppliers | | [Manufacturing](/en/sectors/manufacturing) | Products with embedded AI, Annex I | Missing separation between plant systems and systems bound for the product | | [Retail](/en/sectors/retail) | Shift planning and staff evaluation, Annex III | Predictive modules inside workforce management software | ## In finance and insurance the perimeter matters more than the machinery These two sectors arrive best prepared, because independent model validation predates the AI Act and documentation is an established habit. What is missing is the boundary: which systems are in scope, who built them, which obligations stay with whoever uses them. In banking, training grafts onto paths that are already mandatory and the critical roles are three, as [AI literacy in banking](/en/blog/compliance/ai-literacy-banks-financial-sector-training) explains. The first use case is almost always chosen the wrong way round, and the reason is in [AI adoption in banking](/en/blog/strategy/ai-adoption-banking-first-use-case). How the rating weighs the four dimensions is in [AI Rating in banking](/en/blog/strategy/ai-rating-banking-four-dimensions-gates). On the insurance side a modelling culture helps and the forgotten perimeter is the agency network, as [AI literacy in insurance](/en/blog/compliance/ai-literacy-insurance-companies-training) sets out. The most valuable use case is also the one falling under Annex III, and the reasoning is in [AI adoption in insurance](/en/blog/strategy/ai-adoption-insurance-first-use-case). The gate that sets the class is described in [AI Rating in insurance](/en/blog/strategy/ai-rating-insurance-perimeter-gate). ## Telecom and manufacturing: where technology isn't the problem Here companies own their data, run solid infrastructure and have mature release cycles, and precisely for that reason they arrive at the measurement convinced they are ahead. The score falls elsewhere. For telecom operators the training difficulty is scale, with thousands of people who are not on the operator's payroll, and the answer is in [AI literacy in telecom](/en/blog/compliance/ai-literacy-telecom-operators-scale). The area with most value is also the one with least friction, a rare case explained in [AI adoption in telecom](/en/blog/strategy/ai-adoption-telecom-network-commercial), while the gate sits on commercial systems, as [AI Rating in telecom](/en/blog/strategy/ai-rating-telecom-commercial-systems) shows. In manufacturing everything turns on a separation that precedes every other assessment, between a system that stays in the plant and one that ends up inside a product sold to customers. Training grafts onto workplace safety, with the risk described in [AI literacy in manufacturing](/en/blog/compliance/ai-literacy-manufacturing-factory-training). The choice of the first case is in [AI adoption in manufacturing](/en/blog/strategy/ai-adoption-manufacturing-plant-or-product), and the data weakness that surprises technologically advanced companies is in [AI Rating in manufacturing](/en/blog/strategy/ai-rating-manufacturing-data-and-product). ## Retail and sport, risk where nobody looks These two sectors share a trait: management attention sits on the customer and the supporter, while the real exposure concerns the people who work. In retail, turnover makes the annual training plan useless, and the alternative is in [AI literacy in retail](/en/blog/compliance/ai-literacy-retail-store-training). The use case that pays and the one that exposes are separated in [AI adoption in retail](/en/blog/strategy/ai-adoption-retail-first-use-case), while the gate on predictive modules inside workforce software is in [AI Rating in retail](/en/blog/strategy/ai-rating-retail-workforce-systems). In sport the populations to train are two in clubs and three in federations, as [AI literacy in sport](/en/blog/compliance/ai-literacy-sports-clubs-training) explains. The starting point differs between clubs and federations, and the difference is in [AI adoption in sport](/en/blog/strategy/ai-adoption-sports-clubs-first-use-case). The gate on data ownership, which in clubs almost always sits with suppliers, is in [AI Rating in sport](/en/blog/strategy/ai-rating-sports-clubs-data-ownership). ## The constants that cut across sectors Three things recur everywhere, whatever the sector. The first is that the most exposed systems arrive inside software bought for something else, predictive modules switched on within tools nobody reassessed after purchase. The second is that role-based training already exists on other fronts, from workplace safety to anti-money laundering, and grafting onto those paths costs far less than building new ones. The third concerns data, which in almost every sector belongs contractually to a supplier, and a company unable to export what it works on doesn't control its own systems. How these three weigh on the score is described in [the four dimensions of AI maturity](/en/blog/ai-governance/four-dimensions-ai-maturity) and in [the critical gates](/en/blog/ai-governance/critical-gates-ai-maturity). ## Where to start The prerequisite is the same in every sector, and it doesn't depend on company size: the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), built by looking inside software already in use as well. From there comes [risk classification](/en/blog/compliance/ai-systems-risk-classification) and the measurement described on the [AI Rating](/en/services/ai-rating) page. The full sector map is on the [Sectors](/en/sectors) page. To understand where the exposure sits in your organisation you can [book an assessment session](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # From Today, AI Documentation Is Also Evidence URL: https://zerofive.ai/en/blog/compliance/ai-documentation-as-evidence-decree-160-2026 Data: 2026-09-30 Abstract: With Legislative Decree 160/2026 in force, logs, technical documentation and human oversight become evidence. How to reread inventory, design and competence. **In short.** Legislative Decree 160/2026 is in force in Italy from today, and in a damages claim involving an AI system a court can order disclosure of logs, risk management documentation, technical documentation and human oversight arrangements. The same documents a month-long series described as requirements of a voluntary standard become, in that forum, the material a company uses to support its position. This article revisits the series from that angle. For a month we wrote about inventories, impact assessments, logging, human oversight, competence and certification, with the argument compliance usually makes: it's needed for the audit, better done early, more expensive to reconstruct later. From today that argument has a second dimension, worth setting out now that the decree is operative. ## What changes today Legislative Decree of 9 September 2026, No. 160, published in the Official Gazette on 15 September, enters into force on the 30th. Articles 16 to 20 govern civil damages claims for harm caused through the use of an AI system, described in detail in our article on [evidence and causation](/en/blog/compliance/ai-damages-evidence-causation-italy-decree-160-2026). Three mechanisms work together. A court can order disclosure of evidence about how the system operated, and a party failing to comply without justified reason risks having the facts alleged against it treated as established. Where the harm stems from a breach of AI Act obligations, causation is presumed, subject to proof to the contrary. Conformity with the regulation, even when certified, does not in itself exclude liability. Two limits are worth keeping in mind, because the effective perimeter is narrower than headlines suggest. The causation presumption operates only where harm follows from an AI Act breach, and several high-risk obligations apply from December 2027 for Annex III and August 2028 for Annex I. Access to evidence, by contrast, applies immediately to any damages claim tied to the use of an AI system, whatever its risk class. ## The same documents, two readers The four document types Article 17 lists as disclosable are those the AI Act already requires: automatic logs, the risk management system, technical documentation, and human oversight parameters and arrangements. They are also, almost one for one, what a management system aligned with ISO/IEC 42001 produces across the life cycle. The difference lies in who reads them and with what question. An auditor checks that the management system works and samples to establish it, working from conformity to a model. A court looks at a single episode and asks what happened that day, on that input, with what human intervention. The first can accept that a procedure describes a control; the second wants the trace of that control in the specific case. This distance explains why some documents entirely adequate for an audit turn weak in litigation. An approved and current human oversight procedure passes an audit; if nobody records the actual interventions, though, it doesn't show that anyone looked that day. ## Where the series shifts weight The [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001) served to know what needed governing. From today it also serves, when a challenge lands on one specific system, to know who owns it, what data it handles and where its logs sit. A company unable to answer those questions within a reasonable time starts at a disadvantage. The choices described in [designing an ISO-ready AI system](/en/blog/compliance/designing-iso-ready-ai-system) matter more than they appeared to. A log recording only the output won't let anyone reconstruct a decision, and that moves from technical limitation to evidentiary difficulty. The same applies to oversight designed without traceable means of intervention. On competence, [clause 7](/en/blog/compliance/clause-7-iso-42001-explained) and the [roles-competence matrix](/en/blog/compliance/roles-competence-matrix-ai) connect to human oversight. Demonstrating that oversight existed also means showing that whoever exercised it had the means to, which leads back to the individual evidence for critical roles covered in [AI literacy and ISO 42001 competence](/en/blog/compliance/ai-literacy-iso-42001-competence). On certification, Article 19 settles the question explicitly. The articles on the [map of accredited bodies](/en/blog/compliance/iso-42001-certification-italy-accredia) and the [three certification paths](/en/blog/compliance/lead-implementer-auditor-organizational-certification) remain valid for what they say, and should be read knowing that a certificate attests a system existed on a given date, while the defence in a specific case is built from operational evidence. ## The question that shifts the perspective Anyone wanting to gauge their exposure in half an hour can try a simple exercise. Pick one AI system in use, pick any date in recent weeks, then try to reconstruct a single decision taken that day: what input the system received, which model version was live, what outcome it produced, whether anyone intervened and who. If the reconstruction requires requesting files from a vendor, if the logs have been rotated, if the human intervention appears nowhere, that is the position the company would be in facing a disclosure order. The difference is that today the exercise can be done calmly, and the result doesn't go on the record. ## Three checks worth running now The three most pressing checks concern contracts, retention periods and the traceability of interventions. On vendor contracts, verify whether a clause guarantees access to logs and technical documentation in the event of litigation, within timeframes compatible with a court order. A vendor keeping logs for thirty days with no release obligation leaves the company without its principal material. On retention, Article 26 of the AI Act sets at least six months for high-risk systems, which is a floor rather than necessarily the right duration relative to how long it takes for harm to surface and be contested. On traceability of human interventions, check whether the act of oversight leaves a trace, or whether it remains a practice described in procedures and invisible in the data. ## Why the method stays the same Anyone who built a management system in order to certify already holds most of what's needed, and mainly has to verify that the evidence can be reconstructed case by case rather than only by sample. Anyone not certifying carries no equivalent documentary obligations, and still has an interest in producing the same material, because a disclosure order doesn't distinguish between certified and uncertified companies. The inversion sits there: governance documentation stops being a cost borne to obtain a title and becomes how a company accounts, with verifiable elements, for what its system did. Which is why it's worth building when it isn't needed, because by the time it is needed it can no longer be built. ## Next step This article closes the ISO/IEC 42001 series that began on 1 September. The full index sits at the end of the article on the [three certification paths](/en/blog/compliance/lead-implementer-auditor-organizational-certification), and the wider regulatory picture is in the [complete guide to the AI Act](/en/blog/compliance/eu-ai-act-complete-guide-obligations-liability-data). Through [AI Rating](/en/services/ai-rating) we measure a company's maturity across the AI Risk dimension too, covering risk governance, compliance and traceability. To discuss your position you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive) or write to hello@zerofive.ai. *This article describes the legislative text and its organizational implications, and does not constitute legal advice.* **Sources.** Legislative Decree of 9 September 2026, No. 160, Official Gazette, General Series, No. 214 of 15 September 2026, Articles 16-20; Regulation (EU) 2024/1689 (AI Act) as amended by Regulation (EU) 2026/1744, Articles 9, 11, 12, 14 and 26; ISO/IEC 42001:2023, clauses 7 and 9, Annex A. --- # High-risk AI systems: how to read Article 6 of the AI Act URL: https://zerofive.ai/en/blog/compliance/high-risk-ai-systems-article-6-ai-act Data: 2026-09-28 Abstract: Annex I, Annex III, Article 6(3) exceptions and obligations for providers and deployers: how to classify AI systems before 2 December 2027. **In short.** An AI system becomes high-risk through one of two routes: as a safety component of a product regulated under Annex I, or because its intended purpose falls within one of the eight areas listed in Annex III. The Digital Omnibus has moved the obligations to 2 December 2027 and 2 August 2028, but classification has to happen now, because it determines the cost, contracts and architecture of projects already under way. On 19 May 2026 the European Commission published its draft guidelines on the classification of high-risk artificial intelligence systems, required by Article 6(5) of Regulation (EU) 2024/1689. They were due by 2 February, arrived more than three months late, the stakeholder consultation closed over the summer and the final version is expected by the end of 2026. In the meantime the Digital Omnibus, published as Regulation (EU) 2026/1744 on 24 July, has reshaped the timeline: obligations for the systems listed in Annex III apply from 2 December 2027, those for AI embedded in the regulated products of Annex I from 2 August 2028. These weeks the topic is everywhere, in webinars, posts and checklists, and the reaction we see most often in companies is a kind of relief, because fourteen months feel like a lot. In my view that reading is dangerous. The classification of an AI system decides how much it costs to build, how the contract with the vendor has to be written, which documentation must be produced while the project takes shape, and who in the company has to sign off. The Artificial Intelligence Observatory of Politecnico di Milano, in research presented in February 2026, found that 71% of large Italian companies have active AI projects and only 9% have structured governance: that gap is full of systems nobody has classified yet, and that someone will have to classify in a hurry a year from now. ## The two routes of Article 6 Article 6 opens two separate doors into high-risk status, and mixing them up is the most common mistake. The first, in paragraph 1, covers AI systems that are themselves a product, or a safety component of a product, covered by the EU harmonisation legislation listed in Annex I, provided that product has to undergo a third-party conformity assessment. The second, in paragraph 2, covers systems whose intended purpose falls within one of the use cases in Annex III, regardless of the product they run in. These are two different logics. The first reasons about the product and physical safety, inherits the language of the New Legislative Framework and plugs into certification processes that makers of machinery or medical devices have known for years. The second reasons about use and fundamental rights, and reaches companies that have never thought of themselves as "regulated", such as those hiring staff or assessing creditworthiness. In both cases the decisive variable is the intended purpose, meaning the use the provider declares in its documentation, instructions and commercial material. The draft guidelines insist on this point: the purpose must be described consistently across all documents, and a system presented as general-purpose in the technical sheet but sold for candidate screening on the website will be judged by what it does. ## The regulated products of Annex I For AI embedded in products, the first question is technical before it is legal. Annex I lists the relevant product legislation: machinery, toys, radio equipment, medical and in vitro diagnostic devices, lifts, pressure equipment, vehicles, civil aviation and more. If the product falls under one of these regimes and requires a notified body, the next step is to establish whether the AI system performs a safety function or whether its failure could endanger the health or safety of people, following the definition of safety component in Article 3(14). The guidelines make clear that what counts is the function, not the way the AI is delivered: a vision module that stops a press when it detects a hand in the working area is a safety component whether it runs on the machine or arrives as a cloud service. For manufacturers, and Italian industry is full of increasingly intelligent machines, this means classification belongs inside the product's technical file, handled by the same people who manage CE marking today. ## The eight areas of Annex III Annex III is the list that matters to most service companies. There are eight areas: - biometrics, including remote identification and emotion recognition where permitted; - critical infrastructure, such as the management of water, gas, electricity and traffic networks; - education and vocational training, from admission to the assessment of learning outcomes; - employment and workers management, from recruitment to decisions on promotion, termination and task allocation; - access to essential public and private services, including creditworthiness assessment and pricing in life and health insurance; - law enforcement; - migration, asylum and border control; - administration of justice and democratic processes. Anyone working in a bank, an insurer or an HR department sits inside this list even without building anything in-house, because obligations follow the system along the value chain and fall partly on whoever uses it. The Commission's draft adds a clarification many companies had not anticipated: a system that materially shapes an employment decision stays high-risk even if a person has the final word, because human oversight is an Article 14 obligation and not an exit from classification. ## The exceptions of Article 6(3) This is where the most heated discussions with market surveillance authorities will concentrate. A system that falls within Annex III may not be considered high-risk if it does not materially influence the outcome of decisions, and Article 6(3) sets out four alternative conditions, so meeting one is enough: - the system performs a narrow procedural task, such as sorting incoming documents; - it improves the result of a previously completed human activity, for example by polishing the wording of a text written by a person; - it detects decision-making patterns or deviations from prior decisions, without replacing human assessment; - it performs a preparatory task for an assessment that remains human. With one limit that leaves no room for interpretation: if the system profiles natural persons, none of the four conditions can save it. Anyone relying on the exception must document the assessment before placing the system on the market and make it available to authorities on request, so the derogation is an active, signed choice that someone must be able to defend. The guidelines also close the architectural shortcut: when several components, possibly separate agents, jointly contribute to a decision within Annex III, the overall configuration is treated as a single system, and splitting the workflow into pieces that look harmless on their own does not change the outcome. ## Obligations for providers and deployers Once a system is classified as high-risk, the provider carries most of the load. It must set up a risk management system across the whole lifecycle, govern the quality of training, validation and test data, produce technical documentation, ensure automatic event logging, supply understandable instructions for use, design human oversight, and guarantee appropriate levels of accuracy, robustness and cybersecurity. On top of that come a quality management system, conformity assessment with CE marking, registration in the EU database, post-market monitoring and the reporting of serious incidents. The deployer, meaning the company that uses the system in its own activity, has lighter obligations that are anything but formal. Article 26 requires it to use the system according to the instructions, to assign oversight to people with adequate competence and authority, to check the relevance of the input data under its control, to monitor operation, to keep automatically generated logs for at least six months and to inform workers when the system is used in the workplace. For public bodies, private entities providing public services, and those using creditworthiness assessment or life and health insurance pricing systems, Article 27 adds the fundamental rights impact assessment. Article 25 provides that a deployer becomes a provider, with all the related obligations, if it substantially modifies a high-risk system, changes its intended purpose so that it becomes high-risk, or places it on the market under its own name. A company that takes a general model and configures it to screen CVs for its clients is crossing that line, often without noticing. ## Classification as a governance decision Faced with this list, many companies are tempted to treat the whole thing as a legal problem to delegate. That is understandable, and a legal opinion on a borderline case is genuinely useful, but classification starts earlier, at the moment someone in the company defines a system's purpose, chooses a vendor, designs a workflow. Whoever goes to their lawyer with an empty inventory will get an opinion on a hypothesis. The work we see missing almost everywhere sits upstream: a register of the AI systems in use and in development, recording for each one the declared intended purpose, the company's role (provider, deployer, or both), the Article 6 route that might apply and, where an exception is invoked, the written rationale and the name of whoever approved it. It is the same kind of discipline ISO/IEC 42001 requires for an AI management system, and it is what our AI Rating measures in the Risk dimension, with a gate that cannot be offset by high scores elsewhere: a company that does not know which systems it has cannot be mature on AI, whatever the quality of its models. The Digital Omnibus timeline leaves time to build documentation, testing, contracts and oversight processes, provided classification is done now. Those who postpone it to 2027 will be classifying systems already in production, with contracts already signed and architectures already fixed, and at that point every uncomfortable answer costs twice as much. The Commission's draft will be revised, examples will change, some interpretations will shift. A register started today will be ready to absorb the final version, and it will tell the company how many of its "support tools" are in fact systems that steer decisions about people. --- # The mandatory AI course: what it covers after the Omnibus and what ISO 42001 still needs URL: https://zerofive.ai/en/blog/compliance/mandatory-ai-course-not-enough Data: 2026-09-23 Abstract: The standard AI course after the Digital Omnibus: what it covers of AI Act Article 4, what ISO/IEC 42001 clause 7 still requires, and how to extend it. **In short.** A standard AI course bought to answer Article 4 of the AI Act covers a useful base, and stays far from what clause 7 of ISO/IEC 42001 requires. After the Digital Omnibus, the AI literacy obligation consists of adopting measures that support literacy, and a general course can count among them. Clause 7 instead asks for competence determined by role, documented evidence, and updates tied to the systems in use. Below: what a standard course cannot contain by construction, what it costs to add, and what to ask a vendor before signing. With a large part of the AI Act applicable from 2 August 2026, many companies are asking whether the mandatory course they bought months ago is enough to consider themselves in order. For Article 4, after the Digital Omnibus amendments, the answer depends on how the course fits into the measures the company adopted. For anyone heading toward ISO/IEC 42001 certification, the answer is almost always no. ## The market for standard courses Since the AI literacy obligation became applicable on 2 February 2025, a wide offering of standard courses has grown, short and identical for every client, often presented as a complete answer to Article 4. The course itself is a legitimate instrument. The problem starts when it gets treated as the last step rather than the first. Three sales formulations deserve attention because they promise more than a course can deliver. The first is guaranteed AI Act compliance, which no training vendor can provide, because compliance depends on the systems you run and how you govern them. The second is a course valid for ISO/IEC 42001 certification, a formula confusing training content with the evidence a certification body will assess. The third is the recognised certificate, where the recognition often comes from the same entity delivering the course. None of the three makes the course useless. All three signal that the vendor is selling reassurance rather than competence, and it's worth knowing that before treating the matter as closed. ## Article 4 after the Digital Omnibus The amendment to the regulation, in force since 27 July 2026, made the obligation less rigid than many vendors continue to suggest: organisations must adopt measures supporting staff literacy, without guaranteeing any specific demonstrated level for each person. For anyone organising training at scale that's a concrete simplification, and a well-chosen general course can form part of those measures, especially when paired with guidance on the systems present in the company. The criteria for calibrating those measures stand, among them the context in which systems are used, and that criterion is precisely what a one-size-fits-all course doesn't satisfy on its own. One limit the relief doesn't touch is worth adding. Competence obligations for those exercising human oversight over high-risk systems remain in full, and for those roles attending a general course isn't sufficient even against the AI Act. ## What a standard course covers | Content | Standard course | ISO/IEC 42001 clause 7 | |---|---|---| | Basic concepts on models and risks | Covered | Useful as a base | | Principles of responsible use | Covered | Useful as a base | | Role-specific competence | Usually absent | Required (7.2) | | Reference to inventoried systems | Absent | Required for roles affecting the AIMS | | Awareness of the AI policy and one's contribution | Partial | Required (7.3) | | Evidence tied to the person and the role | Generic certificate | Documented information (7.5) | | Effectiveness evaluation | Satisfaction survey | Required (7.2) | | Refresh when systems change | Absent | Expected by the management system | ## The five elements no vendor can write One point gets lost in the discussion and is worth stating plainly: some things are missing from standard courses not through vendor laziness, but because content identical for every client cannot contain them by construction. Your AI policy, which is your document and which clause 7.3 requires people to know. The list of systems actually in use at your company, with what they do and which decisions they support. The name of the person to flag anomalous behaviour to. The internal procedure describing what happens after that report. The edge cases observed on your systems, which is the single most useful piece of information for whoever uses them daily. Five elements no external vendor can write on your behalf, and also the ones turning generic training into training that changes how people behave. The good news is they're cheap: thirty or forty minutes per system, prepared by whoever already knows it. ## Where clause 7 goes further The standard course covers models, risks in the abstract and general principles, and rarely enters the role of whoever attends. A risk owner and a warehouse operator walk out with the same certificate, with no connection to the systems they'll use, and in an audit that certificate demonstrates attendance more than competence. Even an organisation in order with Article 4 therefore stays distant from clause 7, which asks for competence determined by role, evidence retained, and a plan refreshing itself when systems change, as described in the [roles-competence matrix](/en/blog/compliance/roles-competence-matrix-ai). There's also a requirement standard courses almost never address, the effectiveness evaluation required by clause 7.2. The satisfaction survey handed out at the end measures how much people enjoyed it, not how much stayed, and doesn't cover that obligation. ## What the certificate actually says The typical certificate carries the person's name, the course title, its duration and the date. Useful information for showing something was delivered, insufficient for showing a competence was acquired. To work as evidence, a certificate should let someone answer three questions without opening other documents: which competence from the matrix that person covered, against which role, and with what verification of learning. Almost no standard certificate answers all three. The fix doesn't require redoing the course. It takes an internally produced document linking the certificate to the role and the competence, kept alongside the certificate itself, which is exactly what the documented information in clause 7.5 asks for. ## A hypothetical example A distribution company bought an online AI course for all employees and is preparing for ISO/IEC 42001 certification. During gap analysis it emerges that the course covers the general part well but touches neither of the two inventoried systems, and that certificates don't state people's roles. The company keeps the course as an introductory module, adds a workshop for risk owners and short modules for operators of the two systems, and links every certificate to the role matrix. The example is illustrative and does not describe a real case. ## The course and the evidence There is a further reason, outside the technical standard, why a standard course doesn't settle the matter. Since 30 September 2026, Legislative Decree 160/2026 allows a court to order disclosure of the human oversight arrangements adopted, and in that forum a certificate of attendance at a generic course says little about what competence the person who should have caught the error actually had. The relief the Omnibus brought to Article 4 concerns the level of literacy required in general, and leaves untouched the competence obligations for those exercising human oversight over high-risk systems. For those roles the evidence has to stay individual and tied to the specific system, which is what clause 7 asks for as well. The procedural picture is set out in the article on [evidence and causation under Legislative Decree 160/2026](/en/blog/compliance/ai-damages-evidence-causation-italy-decree-160-2026). ## How to extend the course you already bought Starting over is the most common waste when the gap appears, and it's hardly ever needed. The course you paid for remains valid for what it covers, and works as the first of three layers in a plan. - Record the course as the plan's introductory module, listing the content it genuinely covers. - Link every certificate to the person's role in the matrix, through an internal document acting as the bridge. - Add a short module for each inventoried system, aimed at whoever uses it and whoever owns its risk. Half an hour per system, prepared internally, covers what the course couldn't contain. - Plan a session for top management, centred on the decisions they have to take rather than on technical concepts. - Define the effectiveness check, at least for critical roles, through a practical case or a review of real work. - Set the refresh trigger, typically a new system being adopted or a person changing role. The additional cost concentrates in the internal hours of whoever prepares the specific modules, who are also the people who know the systems. Buying those externally rarely pays, because the vendor would first have to learn from you what it's meant to teach your people. ## Questions to ask before buying Anyone still choosing a course can avoid much of the later work with five questions during selection. - Can the program be extended with content on our systems, and on what terms? - Can certificates state the role and the competences covered, or are they standard? - Is there a learning check distinct from the satisfaction survey? - Is the content current with the AI Act as amended by the Digital Omnibus of July 2026? - Who updates the program when the rules change, and how often? A vendor answering vaguely on the first and the third is offering a product rather than a path, and should be assessed as such. ## Next step The course already paid for is a base to extend. The coordination between the two obligations is described in [AI literacy and ISO 42001 competence](/en/blog/compliance/ai-literacy-iso-42001-competence), the construction of the levels in the [roles-competence matrix](/en/blog/compliance/roles-competence-matrix-ai), and the most frequent audit findings in [the mistakes that make an AI training plan fail an audit](/en/blog/compliance/training-plan-mistakes-ai-audit). Our approach to building role-based tracks is described on the [AI Training](/en/services/ai-training) page. To assess what your plan is missing, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # The mistakes that make an AI training plan fail an audit URL: https://zerofive.ai/en/blog/compliance/training-plan-mistakes-ai-audit Data: 2026-09-22 Abstract: Four mistakes that get an AI training plan flagged in an ISO/IEC 42001 audit, how they surface, and which evidence prevents them. **In short.** An AI training plan gets challenged in an ISO/IEC 42001 audit for six recurring reasons: delivery doesn't match what was declared, evidence isn't tied to roles, effectiveness was never evaluated, the plan doesn't update when systems and people change, whoever approves hasn't understood what they're approving, and the perimeter stops at employees. All six share one origin, training treated as a box to tick and disconnected from the system inventory. Below: how each surfaces, what evidence prevents it, and when a finding becomes a major nonconformity. During a certification audit the auditor compares the plan against attendance records, samples a few people, and asks direct questions about what they learned and how they apply it. That comparison between paper and reality produces almost every clause 7 nonconformity, including at companies that spent serious budget on training. ## Where the plan breaks between stage 1 and stage 2 Certification runs in two stages, and training behaves differently across them. In stage 1 the auditor verifies the documents exist and hang together: there's a plan, there's a role matrix, there's a procedure describing how competence gets determined. Passing it is relatively easy, because the paperwork only has to be in order. In stage 2 the verification changes nature. The auditor checks that the plan was implemented and produced the stated effect, and does so by talking to people. This is where most clause 7 findings appear, and the gap between the two explains why companies confident after stage 1 end up with a list of observations in stage 2. Preparing for certification by looking only at documentary completeness means preparing for half the audit. ## The plan that doesn't match delivery The plan exists, perhaps with a tidy calendar and recognised vendors, but what actually got delivered is different. This happens when a course is bought for a wider group than the one that eventually attends, or when the vendor changes the program mid-stream and the internal documentation stays on the original version. The three most frequent discrepancies all show up in the records: people listed in the plan who don't appear among attendees, modules delivered with content different from what was described, sessions postponed and never rescheduled that the plan marks as complete. None is serious on its own, but together they describe a process nobody governs, and that's the conclusion the auditor writes down. Prevention is cheap: a plan revision at every program change, with date and reason, turning a discrepancy into a tracked decision. ## Generic evidence Even where training took place, the proof that matters is often missing: a record with a verifiable date, the link between who attended and the role they hold, a certificate describing content in more detail than "AI basics course". Generic vendor certificates, with no reference to the competence required for the role, don't demonstrate that the competence was covered. The practical test is simple. Take a certificate at random and ask whether, reading it with no other information, you can tell which competence from the matrix that person acquired. If answering requires opening three more documents and reasoning through them, the auditor will hit the same difficulty and note it. ## The effectiveness evaluation that doesn't exist This is the most expensive finding, and often the most unexpected, because it lands at companies that got everything else right. Clause 7.2 requires taking action to acquire the necessary competence and evaluating the effectiveness of those actions, which are two distinct obligations. An attendance register documents delivery. It says nothing about effectiveness, and when the auditor asks how that was verified, the most common answer is the satisfaction survey, which measures how much attendees enjoyed the course rather than what competence they gained. The forms of evaluation that hold up are different: a practical case completed and marked, real work reviewed by someone more experienced, a field check weeks later, a structured interview with a recorded outcome. None needs special tooling, all need planning in advance rather than reconstruction afterwards. ## A plan frozen in time A plan written a year ago and never revised loses validity even if it was correct when drafted. New AI systems have arrived since, associated risks have shifted, and people have joined who never saw that plan. The check the auditor runs is mechanical: compare the date of the plan's last revision against the entry date of the newest system in the inventory and against recent hires. If the inventory moved and the plan didn't, the update mechanism isn't working, however complete the plan is for everyone who was already there. Training, like the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), needs a trigger that refreshes it when something relevant changes. Two triggers work in practice, a new system entering and a person changing role, both attached to processes that already exist and that nobody can skip. ## Approval without understanding This is the most delicate one: a person with approval authority signs off without having understood what they're approving. It happens more often at management level than in operational teams, because training for those who govern gets treated as less urgent than technical training. A few auditor questions bring it out, and the consequence reaches beyond training. An approval without understanding puts the AI decision-making process itself in question, which is the heart of what the standard asks of top management. The finding therefore tends to travel from clause 7 up to clause 5 on leadership, which is why it weighs more than it appears to. ## The perimeter that stops at employees Clause 7.3 speaks of people working under the organisation's control, a formula covering temporary staff, consultants, contractors and personnel of suppliers operating inside your processes. Almost every plan stops at the payroll, because that's where the HR system the plan was built from ends. The auditor notices indirectly, spotting that someone met during the visit appears in no record. The typical case is the external agency running customer service with an AI-assisted tool, where the people using the system daily aren't yours and no training plan covers them. The only instrument that works here is the contract, which needs to set competence requirements and an obligation to supply evidence they're met. ## How they surface in audit | Mistake | How it surfaces | Evidence that prevents it | |---|---|---| | Plan differs from delivery | Comparison of plan against attendance records | Updated records and a plan revised at every program change | | Generic evidence | Request to link certificates to roles | Certificates with detailed content, tied to the role matrix | | Effectiveness not evaluated | Question on how acquired competence was verified | Marked practical cases, reviewed work, field checks with recorded outcomes | | Plan frozen in time | Comparison of plan date, inventory and org chart | Documented triggers for new systems and new joiners | | Approval without understanding | Direct questions to whoever signed | Minutes of management training and of subsequent decisions | | Perimeter limited to employees | People met on site and absent from the records | Competence requirements in supplier and agency contracts | ## The auditor's sample Sampling isn't random, and knowing how it's built allows you to simulate it beforehand. The auditor starts from the role matrix and picks three to five people across different profiles, favouring three categories: whoever exercises human oversight over a significant system, whoever joined recently, whoever signed an approval. The questions are simple and nearly always the same. What's the company's AI policy and where is it. What does the system you use every day do. What would you do if you noticed it getting something wrong. Who would you report that to. When the sampled person can't answer, the nonconformity isn't theirs. It belongs to the management system, which planned a training action without verifying its effectiveness, which loops back to the third mistake on this list. ## When a finding blocks the certificate Findings don't carry equal weight, and the difference decides whether certification arrives or slips. A minor nonconformity is partial implementation of a requirement, an isolated case, missing evidence on one person. It's handled with a corrective action plan, normally due within three months, and doesn't block issuance of the certificate. It rises to major when a requirement is systematically absent, or when a failure compromises the system's ability to achieve its objectives. A complete absence of effectiveness evaluation, repeated across every module, has the characteristics to qualify, and in that case the certificate isn't issued until the finding is closed and verified, often through an additional visit. The practical distinction is between a repeated error and an isolated one. A generic certificate for one person is an instance. Generic certificates for everyone are a process that doesn't work. ## A hypothetical example A department head signed off his team's training on an AI sales-support system as complete. During the audit the auditor asks which risks of the system the course covered, how staff recognise an output that needs checking, and who they report an anomaly to. By the third question the head admits he doesn't know the course content, and the nonconformity covers both the competence evidence and the approval process. The example is illustrative and does not describe a real case. ## The same gap, in a different forum A training plan that fails an audit has, since the end of September, a second place where it can come due. Legislative Decree 160/2026, in force in Italy from 30 September, allows a court to order disclosure of the human oversight parameters and arrangements required by Article 14 of the AI Act, and provides that failing to disclose without justified reason leads the facts alleged by the claimant to be treated as established. Demonstrating human oversight also means demonstrating that whoever exercised it was able to. The generic evidence described above, the attendance register without an effectiveness check, the approval without understanding, is precisely what fails to support the claim that oversight genuinely existed. The defect is the same one that triggers an audit finding, with consequences of a different nature. Anyone preparing the plan for an audit is therefore preparing, without realising it, material that may be needed elsewhere. The context is set out in the article on [evidence and causation under Legislative Decree 160/2026](/en/blog/compliance/ai-damages-evidence-causation-italy-decree-160-2026). ## Before the audit, a simulated sample The most useful check consists of doing what the auditor will do, a few weeks earlier and on a sample built with the same criteria. - Does the plan match, module by module, what the records show? - Is every piece of evidence tied to the person's role in the matrix? - For each module, is there an effectiveness evaluation distinct from a satisfaction score? - Is there a mechanism that updates the plan when a new system or a new person arrives? - Has whoever approves the training followed the path set for their level? - Do contractors with system access appear in the plan or in the contracts? - Picking three people by the auditor's criteria, can they answer the four standard questions? That last point yields the most reliable information and takes half an hour. If two out of three hesitate, the problem isn't theirs, and better to find out now. ## Next step Preventing every mistake on this list runs through training tied to roles and systems. The levels are described in [a roles-competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai), the coordination with the AI Act in [AI literacy and ISO 42001 competence](/en/blog/compliance/ai-literacy-iso-42001-competence), and the full clause requirements in [clause 7 explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained). If you want your plan checked before the audit, [AI Rating](/en/services/ai-rating) is the starting point, or you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # Lead Implementer vs Lead Auditor vs organizational certification URL: https://zerofive.ai/en/blog/compliance/lead-implementer-auditor-organizational-certification Data: 2026-09-22 Abstract: Lead Implementer, Lead Auditor, and organizational ISO/IEC 42001 certification: who is certified, who issues it, what it attests, and in what order. **In short.** Behind the phrase "ISO 42001 certification" sit three distinct paths: Lead Implementer and Lead Auditor are personal credentials, attesting respectively the competence to build an AI management system and the competence to audit one. Organizational certification instead concerns the company and is issued by an accredited body after an audit of the management system. The paths are independent: a company can be certified with nobody holding these credentials, and a person can hold them inside an uncertified company. Below: who is actually needed for internal audits, how to answer a tender without getting it wrong, and what can be written in commercial material. The question "are you ISO 42001 certified?" appears more and more often in customer questionnaires and tender specifications, and whoever asks doesn't always know which of the three paths they have in mind. Whoever answers, in turn, risks confusing a personal credential with organizational certification, with consequences ranging from exclusion from a tender to a challenge during verification. ## Three paths with the same name | Path | Who gets certified | Who issues it | What it attests | How it's obtained | |---|---|---|---|---| | Lead Implementer | A person | Personnel certification body | Competence to design, implement and manage an AIMS | Multi-day course and exam | | Lead Auditor | A person | Personnel certification body | Competence to plan and conduct audits on an AIMS | Multi-day course, exam and audit experience | | Organizational certification | The organization, for a defined scope | Accredited certification body | Conformity of the management system with ISO/IEC 42001 | Two-stage audit, periodic surveillance, renewal | The difference that matters most sits in the second column. The first two rows certify what a person can do, the third certifies what an organization has actually built, and those are claims of different natures that the market treats differently. ## The Lead Implementer credential The credential certifies a person and is obtained through multi-day training with a final exam, delivered by personnel certification bodies, among which PECB, Exemplar Global and various national bodies are the most widespread. Whoever holds it has demonstrated knowledge of the standard's requirements and of how to translate them into a working management system, from the AI policy to risk assessment to the Annex A controls. It's the most coherent path for whoever has to lead an organization through building the system in practice. Two practical aspects often get discovered after enrolment. The first is that many credentials carry maintenance, with periodic renewal and continuing education credits to accumulate, and should be treated as a recurring cost. The second is that the credential's value depends on the issuing body: before enrolling it's worth verifying the body is itself accredited against ISO/IEC 17024, the standard on requirements for those certifying persons. ## What a Lead Auditor actually does The training path has a similar structure but builds a different competence, namely conducting internal audits or audits on behalf of a certification body, verifying the conformity of a system built by others. Working as an auditor for an accredited body takes more than the credential: you have to be selected, qualified and appointed by that body, which also assesses audit experience gained in the field and in many cases requires initial shadowing. That's why the title is rarely put to use independently, while it stays useful to whoever applies it inside their own organization. ## Certifying the organization A company obtains certification of its management system through an audit by an accredited body, along the path described in [ISO/IEC 42001 certification in Italy](/en/blog/compliance/iso-42001-certification-italy-accredia). The certificate covers a precise scope, meaning the systems, processes and sites declared, and doesn't automatically extend to the rest of the business. Having a Lead Implementer on staff helps with preparation, but the body assesses the system regardless of people's credentials. The reverse holds too: a company that built a solid system with the support of an external consultant can certify without holding any personal credential in house. ## Who conducts internal audits The costliest misunderstanding concentrates here, because it concerns a mandatory requirement rather than a choice. Clause 9.2 requires internal audits at planned intervals, and asks two things of whoever conducts them: adequate competence and impartiality with respect to the area being audited. It doesn't ask for a Lead Auditor credential. A competent, independent internal auditor satisfies the requirement without formal titles, provided the competence is demonstrable through evidence, which is the clause 7 principle applied to one specific role. The real constraint is impartiality. Whoever built the management system can't audit their own work, which means a second internal person is needed, or an external auditor appointed for that activity. This is why many organizations train two people with separate roles, one implementing and one verifying, and it's an organizational choice before a training one. ## A hypothetical example A digital services supplier bids for a tender awarding additional points to holders of "ISO/IEC 42001 certification". The team includes someone with a Lead Implementer credential, the commercial office declares the requirement as met and, during verification, the contracting authority asks for the organization's certificate issued by an accredited body, which the company doesn't have, and the points are withdrawn. The example is illustrative and does not describe a real case. ## How to answer a tender Before completing the response it's worth working out what the requester is actually asking, because tender wording is often as imprecise as the answers it receives. If the document speaks of organizational certification, of a management system, or asks for a certificate number, the reference is organizational certification, and the only correct answer is holding it or stating that you don't. If it speaks of qualified personnel, team competences or certified individuals, then personal credentials are relevant and should be listed with the exact name of the credential and of the issuing body. Where the requirement is ambiguous, a clarification request during the tender costs far less than a challenge afterwards. And where organizational certification is missing but the path has started, saying so precisely, naming the chosen body and the stage reached, is a defensible position, while a generic claim isn't. ## What can be written in materials Correct wording costs the same as imprecise wording and survives a check. About a person: certified ISO/IEC 42001 Lead Implementer, naming the body. About a team: team with certified competences on ISO/IEC 42001. About a company holding the certificate: AI management system certified to ISO/IEC 42001 by an accredited body, with the scope and the certificate number. The wording to avoid is equally clear. We are ISO 42001 certified, said without the organizational certificate. ISO 42001 company, which means nothing verifiable. Compliant with ISO 42001, which is a self-declaration and needs distinguishing from certification, even where it's true. The difference surfaces exactly when somebody asks for the document, which is also the worst moment to discover it. ## The order of choices For anyone building a management system, the first sensible investment is Lead Implementer training for one or two key people, who will lead the work on documentation, inventory and controls. Organizational certification arrives once the scope is mature and the system has produced evidence for some months, while the Lead Auditor credential makes sense for whoever will run internal audits or intends to work with a certification body. Organizational size shifts the calculation. In a small company it often pays to have one person trained as Implementer and an external internal auditor appointed as needed, because maintaining two in-house competences costs more than it returns. In a structure spread across several functions, separating implementation from verification becomes natural instead, and training both roles internally pays for itself from the first surveillance cycle. Before answering a questionnaire or a tender, it's worth checking which of the three paths is being asked for and stating precisely what you hold. ## Every piece in the series This article is part of the September series on documentation, training and certification: - [The minimum documentation of an AIMS](/en/blog/compliance/aims-minimum-documentation-iso-42001) - [AI system impact assessment: DPIA, the AI Act and ISO/IEC 42001 compared](/en/blog/compliance/impact-assessment-dpia-ai-act-iso-42001) - [The AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001) - [Designing an ISO-ready AI system](/en/blog/compliance/designing-iso-ready-ai-system) - [ISO/IEC 42001 clause 7, explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained) - [A roles-competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai) - [AI literacy and ISO 42001 competence](/en/blog/compliance/ai-literacy-iso-42001-competence) - [The mistakes that make an AI training plan fail an audit](/en/blog/compliance/training-plan-mistakes-ai-audit) - [The mandatory AI course and clause 7](/en/blog/compliance/mandatory-ai-course-not-enough) - [ISO/IEC 42001 certification in Italy](/en/blog/compliance/iso-42001-certification-italy-accredia) - [From today, AI documentation is also evidence](/en/blog/compliance/ai-documentation-as-evidence-decree-160-2026), out on 30 September ## Next step ZeroFive doesn't issue certifications: we support companies in building the system and preparing for the audit, as described on the [AI Compliance](/en/ai-compliance) page. To work out which path to start from, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive) or write to hello@zerofive.ai. --- # ISO/IEC 42001 certification in Italy: the map of Accredia-accredited bodies URL: https://zerofive.ai/en/blog/compliance/iso-42001-certification-italy-accredia Data: 2026-09-21 Abstract: ISO/IEC 42001 certification in Italy: why Accredia accreditation matters, circular DC 08/2026, the accredited bodies, and the audit stages. **In short.** An ISO/IEC 42001 certificate carries weight in a due diligence, a public tender or before a regulator when it comes from an accredited body, which in Italy means accredited by Accredia. Accreditation specific to this standard was made possible by Accredia technical circular DC No. 08/2026, integrating ISO/IEC 17021-1 with ISO/IEC 42006. Below: who can certify today, how to verify somebody else's certificate, what drives time and cost, and why the scope is the decision that matters most. Anyone, in principle, can issue a document attesting conformity with an ISO standard, and what changes that document's value is the accreditation of the body issuing it. For ISO/IEC 42001 in Italy, specific accreditation only arrived in 2026. Before then, certificates existed from serious bodies lacking that formal recognition. ZeroFive is not a certification body and issues no certificates: we support companies in preparing for the path, and knowing who can certify is the first filter in the choice. ## Why accreditation matters Accreditation guarantees that the certification body has itself been verified against shared international rules, with competence, impartiality and procedures under control. In Italy the single accreditation body is Accredia, and an accredited certificate is recognised in tenders, in customer checks and in dealings with authorities, while a non-accredited certificate remains a private attestation. Recognition doesn't stop at national borders. International mutual recognition arrangements mean a certificate issued by a body accredited by a foreign signatory carries the same value as one accredited by Accredia, which matters when assessing an overseas supplier. What needs verifying in that case is that the accreditation body is genuinely a signatory and that the accreditation covers ISO/IEC 42001 rather than management systems generally. ## Technical circular DC No. 08/2026 Accredia technical circular DC No. 08/2026, which opened the way to accrediting bodies for ISO/IEC 42001, integrates the general requirements of UNI CEI EN ISO/IEC 17021-1, applying to all bodies certifying management systems, with those of ISO/IEC 42006, the standard setting requirements for those auditing and certifying AI management systems, including reference to the Annex A controls and Annex B guidance of ISO/IEC 42001. From that point bodies could apply for specific accreditation. There's a practical consequence for certificates issued earlier too. A company certified by a body that couldn't be accredited for this standard at the time doesn't hold a worthless document, it holds one worth bringing under accreditation at the first renewal, because that's what customers will start asking for. ## The accredited bodies | Body | Note | |---|---| | CSQA | First body accredited in Italy for ISO/IEC 42001 | | Bureau Veritas | Accredited | | DNV | Accredited | | TÜV Italia | Accredited | | ACM CERT | Accredited | The list reflects the position at the date of publication and is set to grow, so the source to consult remains the Accredia database. ## How to verify a certificate Anyone receiving a supplier's certificate and wanting to know what it's worth has a check available that takes a few minutes, and that's worth making a standard part of supplier qualification. The first check is against the Accredia database, looking up the body that issued the document and verifying the accreditation covers ISO/IEC 42001 specifically. The second is on the scope stated on the certificate, compared against the activity you're assessing that supplier for: a certificate valid for the Milan site doesn't cover a plant in another country, and one covering software development doesn't necessarily cover the AI system the supplier uses to run your service. The third is on validity dates and status, because a certificate may have been suspended or withdrawn in the meantime, and that information doesn't appear on the paper document. The fourth, where needed, is a direct enquiry to the body, which confirms the certificate's existence and status. ## Scope, the decision that matters most Scope is the part of the certificate almost nobody discusses enough during preparation, and it's what determines the certificate's usefulness. Setting it too wide lengthens the audit, increases audit days and therefore cost, and above all exposes areas that weren't ready to findings. Setting it too narrow produces a certificate that is technically valid and commercially of little use, because the customer reading it looks for coverage of the system that concerns them and doesn't find it. The practical criterion is to start from the inventoried systems and from whoever will ask for the certificate. If the request comes from customers buying a specific service, the scope has to cover the AI systems feeding that service, with the relevant organisational structure. Widening later is possible, done at a surveillance visit or a renewal, and costs less than narrowing. ## The audit stages | Stage | What it verifies | Typical evidence | |---|---|---| | Stage 1 | Existence and adequacy of the AIMS documentary structure | AI policy, scope, risk assessment, statement of applicability | | Stage 2 | Actual implementation of the system | Staff interviews, record samples, control evidence on inventoried systems | | Surveillance | Maintenance over time, normally annual | Internal audits, management review, corrective actions | | Recertification | Overall conformity at the end of the three-year cycle | The system's history across the cycle | The structure mirrors other management systems such as ISO/IEC 27001 and ISO 9001, and anyone who has been through those finds a familiar logic with different technical content. Some weeks normally pass between stage 1 and stage 2, used to close the observations raised in the first phase. It's a window worth using, because stage 1 findings almost always anticipate where stage 2 will look. ## What drives time and cost A body's quotation is built on audit days, and audit days depend on four variables: the number of people inside the scope, the number of sites to visit, the quantity and criticality of AI systems in the inventory, and the existence of other certified management systems the audit can be integrated with. That last point saves the most. A company already certified to ISO/IEC 27001 can request an integrated audit, where the parts common to both standards, from documentation to nonconformity management to management review, get verified once. The saving is real and extends to internal people's time, which is the least visible cost and often the highest. On the calendar, the dominant variable isn't the audit but the preparation. The typical distance between deciding to certify and stage 2 is measured in months, and depends almost entirely on how much of the management system already exists and genuinely works. ## The distance from 27001 and 9001 Anyone arriving from other certifications finds the structure familiar and three substantive differences. The first is the object. An AI system changes behaviour over time, with the model updated by the vendor or retrained internally, while an information asset or a production process stays more stable. That makes the system inventory a document that moves, rather than an annex refreshed once a year. The second is the impact assessment on people and groups, which has no direct equivalent in 27001, where the analysis looks at assets and information security. The third is a body of legislation running in parallel. An ISO 9001 auditor doesn't have to account for an evolving European regulation, while for ISO/IEC 42001 the relationship with the AI Act is part of the context, which is also why auditors with specific experience are worth more than generalists. ## A hypothetical example A software company receives a copy of a supplier's ISO/IEC 42001 certificate and attaches it to tender documentation. During verification the contracting authority asks whether the body is accredited for that standard, and a check against the Accredia database comes back negative: the certificate is genuine, but doesn't carry the value the tender required. The example is illustrative and does not describe a real case. ## What the certificate does not cover Legislative Decree 160/2026 has been in force in Italy since 30 September 2026, and its Article 19 establishes that conformity with AI Act obligations, even when certified through the conformity assessment procedures the regulation provides for, does not in itself exclude liability in a damages claim. The provision addresses AI Act certification, and the same logic reaches any voluntary attestation, including one against ISO/IEC 42001. The distinction is sharp. A certificate attests that on a given date, across a given scope, a body verified that a management system existed. Litigation instead turns on how one specific system behaved in one specific case, and that reconstruction comes from logs, human oversight evidence and documented decisions rather than from the certificate on the wall. Anyone entering certification knowing this sets it up differently, holding the certificate and the operational evidence the same system produces daily side by side, because the two serve different forums. The full picture is in the article on [evidence and causation under Legislative Decree 160/2026](/en/blog/compliance/ai-damages-evidence-causation-italy-decree-160-2026). ## When to wait Certification certifies a system that works, it doesn't create one. An organisation without a current system inventory, or with policies written and never applied, facing the audit now risks the most expensive path of all: stage 2 findings, corrective actions under pressure, an additional visit, and a system built in haste to pass the check rather than to govern the risks. The signal that the moment has arrived is easy to recognise. There's an inventory updated in recent months, there are risk assessments signed by named people, there's a training plan with evidence tied to roles, and there's at least one documented management review. With those four in place, the audit verifies something that already exists. Without them, the months spent building them first are worth more than the months spent chasing findings afterwards. ## Questions to ask a certification body - Is the body accredited by Accredia, or by a signatory to the mutual recognition arrangements, specifically for ISO/IEC 42001? - Does the proposed scope match the systems the company intends to certify? - Do the assigned auditors have experience with comparable AI systems? - How are time and cost structured across stage 1, stage 2 and surveillance? - Can the audit be integrated with certifications already held, and with what saving in days? - What happens if major nonconformities arise in stage 2, and within what closure timeframes? - How much notice is needed to schedule stage 1, given your calendar? ## Next step Reaching the audit with a system that works requires coherent documentation, inventory and training. The starting point is [the minimum documentation of an AIMS](/en/blog/compliance/aims-minimum-documentation-iso-42001), followed by the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), while the most frequent training findings are in [the mistakes that make an AI training plan fail an audit](/en/blog/compliance/training-plan-mistakes-ai-audit). Our approach to preparation is described on the [AI Compliance](/en/ai-compliance) page. To understand how far you are from the audit, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # AI literacy and ISO 42001 competence: one training plan, two obligations URL: https://zerofive.ai/en/blog/compliance/ai-literacy-iso-42001-competence Data: 2026-09-18 Abstract: AI Act Article 4 after Regulation (EU) 2026/1744 and ISO/IEC 42001 clause 7 compared: one training plan answering both obligations. **In short.** The AI literacy obligation in Article 4 of the AI Act and the competence requirements in clause 7 of ISO/IEC 42001 largely reach the same people, and running them as two separate projects means paying twice for the same training base. The Digital Omnibus rewrote Article 4, turning it from an obligation of result into one of effort, while leaving untouched the competence requirements covering anyone exercising human oversight over high-risk systems. A single role-based plan, stating which obligation each module covers, answers both. In companies dealing with the AI Act and ISO/IEC 42001 certification at the same time, training often starts from two different offices: the legal team works from Article 4, the quality manager from clause 7. The two tracks end up with separate vendors, budgets, and calendars, and nobody checks how much they overlap until someone compares the programs. ## Two obligations with different origins Article 4 of the AI Act has applied since 2 February 2025 to providers and deployers alike. It is a legal provision, enforced by national market surveillance authorities, and it binds organizations that pursue no certification at all. Clause 7 of ISO/IEC 42001 comes from a voluntary standard instead, and asks organizations to determine the competence needed for each role within a documented management system, ensure it, evaluate the effectiveness of the actions taken, and keep evidence of all of it. Those who apply it do so because they chose to certify, or because they want a method that holds up in a due diligence. ## What changed on 27 July Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and has been in force since 27 July. Article 1, point 5, replaces Article 4 of the AI Act in full. The original wording required providers and deployers to take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff. The new wording requires measures supporting the development of AI literacy, and adds an explicit clarification: the provision does not require guaranteeing any specific level of AI literacy for any individual. The technical shift is from an obligation of result to an obligation of effort. The criteria for calibrating those measures are unchanged: technical knowledge, experience, education, and the context in which the systems are used. ## The relief that doesn't apply to everyone Read quickly, the new Article 4 looks like it takes pressure off everyone. It moves the plane on which measures get judged rather than removing it, and for some organizations it changes almost nothing. The obligations covering people assigned to human oversight of high-risk systems were not touched. An organization assigning someone to oversee a system of that kind must ensure they have adequate competence, training and authority, and that requirement is not an obligation of effort. A company with systems falling under Annex III therefore faces a lightened general duty alongside an intact specific one, precisely for its most exposed staff. The practical consequence is that the relief mainly concerns the wide perimeter, meaning the base of staff using lower-risk tools. On critical roles, the distance between Article 4 and clause 7 narrows rather than widens. ## The comparison | Aspect | AI literacy (AI Act, Art. 4) | Competence (ISO/IEC 42001, cl. 7.2 and 7.3) | |---|---|---| | Nature | Legal obligation, of effort after the Digital Omnibus | Requirement of a voluntary standard | | Who it covers | Staff of providers and deployers and others using the systems on their behalf | People working under the organization's control who affect AIMS performance | | Content | Support measures calibrated to skills, experience, education, and context of use | Competence determined by role, acquired and verified | | Individual level | Need not be guaranteed for any one person | Determined for each role | | Evidence | Not prescribed in detail | Documented information required by the standard | | Effectiveness | Not explicitly required | Effectiveness evaluation mandatory | | Who checks | National market surveillance authorities | Internal audits and the certification body | | Refresh | Tied to the context of use | Tied to changes in the AIMS and the systems | ## Who falls inside the perimeter Both provisions look beyond the payroll, and in similar terms. Article 4 covers staff and other persons dealing with the operation and use of the systems on the provider's or deployer's behalf. Clause 7.3 speaks of people working under the organization's control. In both cases that takes in consultants, temporary staff, contractors and personnel of suppliers operating inside your processes. The external agency running customer service with an AI-assisted tool sits inside both perimeters, and in both cases the only instrument for governing it is the contract, because you have no training plan covering those people. This is also where the two obligations align best: an organization that has already mapped its perimeter for clause 7 knows its extended perimeter already, and doesn't need to redo the exercise for Article 4. ## Why "contextual" changes what to buy The rewriting of Article 4 leaves the reference to context of use standing, and removing the individual level effectively shifts the centre of gravity onto it. Measures get judged against the systems actually in use, the roles working around them, and the risks they carry. That makes the best-selling training product of the moment, the generic AI Act course, of limited use. Knowing how the regulation is structured doesn't help an operator recognise when the tool they use every day is getting something wrong. One hour on the system that person has in front of them is worth more than four hours on the regulation, and answers both obligations better. ## Where they meet Both ask for training calibrated to role and context of use, and both end up reaching the people who decide on adoption, use the tools, or assess their risks. A plan built on the [roles-competence matrix](/en/blog/compliance/roles-competence-matrix-ai) already covers much of what Article 4 requires. ## The differences that remain AI literacy is a floor, which applies even to organizations that have no management system and do not plan one, while ISO 42001 competence requires verifiable evidence linked to the risks of inventoried systems. An organization can meet Article 4 while staying far from clause 7; the reverse is hard, because meeting clause 7 in practice already covers the literacy of the staff involved. Two clause 7 requirements have no equivalent in Article 4. The first is evaluating the effectiveness of training actions, which forces measurement of the outcome and not just of delivery. The second is the update mechanism triggered by changes to the management system or to the systems in use. Anyone building a plan for Article 4 alone tends to skip both, and those are exactly what make a plan useful beyond the audit date. ## Mapping modules to obligations The method is to map each module of the plan to the obligations it satisfies. In practice the structure that works has three layers. A base layer for everyone touched by an AI system, short, centred on what the system they use does, where the system's responsibility ends and theirs begins, and who to flag an anomaly to. It answers Article 4 and, for non-critical roles, the awareness requirement in clause 7.3. A role layer, built on the matrix, answering the competence requirement in 7.2 and covering Article 4 for operational roles in more depth than strictly needed. A specialist layer for those running risk assessments, exercising human oversight over high-risk systems, and accountable for decisions. Evidence here has to be individual and verifiable, because this is where the specific human oversight obligations and the clause 7 requirements ask for the same thing. Keep the mapping, because during an audit or an inspection it shows quickly how the company addressed each requirement. ## What to keep if you're not certifying An organization not pursuing ISO/IEC 42001 has no detailed documentary obligations under Article 4, which is not the same as having nothing to show. An authority asking about the measures adopted expects more than an assertion. The reasonable minimum is a document describing which measures were adopted and for which groups of staff, the list of AI systems in use those measures relate to, a record of when they were delivered and to whom, and a review date. Four items an HR function produces in a week, and which turn a statement into a defensible position. ## A hypothetical example An industrial group runs two AI training projects with different vendors and separate budgets, one launched by the legal team for Article 4 and the other by the quality function for ISO 42001 certification. Mapping the modules to roles shows that much of the content overlaps and that the two vendors use different definitions of a high-risk system. The group merges the plan, keeps one vendor for the general part, and gives the other the specialist modules. The example is illustrative and does not describe a real case. ## Questions before signing with a vendor - Which modules address Article 4 and which address clause 7? - Is the evidence produced linked to each person's role? - Does the content use the AI Act definitions as amended by the Digital Omnibus? - How much of the program covers the systems actually in use here, and how much covers the regulation in general? - How is effectiveness measured, beyond a satisfaction survey? - Who updates the content when the systems in use change? - Does the new plan account for what the company has already delivered? ## The most frequent mistakes The first is reading the Article 4 amendment as a postponement. The obligation has applied since February 2025, national supervision is operational, and an organization that has adopted no measures at all is in no better position after the Digital Omnibus. The second is buying the course on the regulation rather than on the system, which produces staff able to cite Article 6 and unable to notice that a tool is returning anomalous outputs. The third is treating Article 4 and clause 7 as though the former were a subset of the latter at every point. For the wide perimeter that's nearly true; for oversight roles it's less true than it looks, because the AI Act's specific obligations on those people remain in full. The last is building the plan without knowing which AI systems are actually in use. Without the [system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), context of use is a hypothesis, and training calibrated to context becomes training calibrated to an idea of the context. ## Next step Before splitting the budget, compare existing programs against the role matrix. The full requirements are in [ISO/IEC 42001 clause 7, explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained), and the levels are built in [a roles-competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai). Our approach to training tracks is described on the [AI Training](/en/services/ai-training) page. To check the overlaps in your plan, [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # Who needs training and on what: a roles-competence matrix for AI URL: https://zerofive.ai/en/blog/compliance/roles-competence-matrix-ai Data: 2026-09-17 Abstract: A roles-competence matrix for AI training under ISO/IEC 42001: board, risk owners, operational users, formats, audit evidence, and refresh cycles. **In short.** An AI training plan built by department trains some people twice and leaves others uncovered. Clause 7 of ISO/IEC 42001 asks for competence tied to roles, and for most organizations three levels are enough: those who govern and approve, those who own the risk of a specific system, and those who use the tools in daily work. A roles-competence matrix links each role to what it must be able to do, the training format, the evidence to keep for audit, and how often it is refreshed. Once they realize clause 7 asks for more than one course for everyone, many companies move to different tracks but keep deciding content by department. A process owner and a clerk in the same office then end up in the same course, even though one decides and the other executes, while people in other departments who sign risk assessments miss the track they need. The criterion that works looks at what the person must decide or do with respect to a specific system, and the org chart becomes a starting point to cross-check against the inventory. ## The competence levels The board and senior management approve system adoption, accept residual risks, and answer for those choices to shareholders and authorities. Risk owners are the people assigned the risk of a given system; they keep the assessment current and escalate when something changes. Operational users work with the tools every day, and they are where a system error becomes a process error. Each level needs a different depth, and a single course bores the first group and leaves the third unprepared, with neither problem surfacing until an auditor starts asking questions. ## The matrix | Role | What they must be able to do | Format | Audit evidence | Refresh | |---|---|---|---|---| | Board and senior management | Read an AI rating, ask why a risk was accepted, understand the accountability attached to approval | A few hours on company cases | Minutes with questions asked and decisions taken | Yearly and for every new high-risk system | | Risk owners | Run and update the risk assessment, recognize a substantial change, trigger escalation | Hands-on workshop on inventoried systems | Signed, current assessments and logged escalations | At every system change and at least yearly | | Operational users | Recognize when an output needs checking, know whom to report an anomaly to | Short modules in the context of the tool | Attendance record linked to role, practical check | At adoption and at every version change | | Control functions | Check consistency between inventory, risks, and controls | Technical and regulatory track | Internal audit plan and reports | Yearly | | Contractors with system access | Follow defined procedures and usage limits | Contract clauses and briefings | Documented acceptance | At every contract renewal | ## The board Board members don't need to read a model; they need to read an AI rating report and ask why a given risk was accepted rather than mitigated, knowing what it means to sign an approval without asking that question. Training at this level takes hours, and it is measured by the quality of the questions the board asks in later meetings more than by course minutes completed. ## Risk owners A risk owner cannot just sign an assessment prepared by an outside consultant. They must recognize when the system they own has changed enough to need a fresh analysis, for example after a model update or an extension to a new category of users, and know how to escalate before the problem surfaces on its own. Training here works on the systems in the company's inventory, because generic examples do not prepare people to spot the signals of their own context. ## Operational users An operator using an AI-assisted tool needs to know when an output requires human verification before moving on and whom to report odd behavior to, with examples taken from their own work. This is the largest group and often the most neglected, even though it is the one in daily contact with real errors. ## A hypothetical example An insurer with four AI systems in its inventory, including one that supports claims assessment, builds the matrix by cross-checking the org chart with the list of systems. The claims manager, who under a department-based plan would have taken the users' course, turns out to be the risk owner of the claims system and joins the risk assessment workshop, while the adjusters on the team get short modules on verifying outputs and reporting anomalies. The example is illustrative and does not describe a real case. ## Mistakes to avoid - Assigning content by department without looking at the role relative to the system. - Treating the board as a secondary audience because its training is short. - Forgetting contractors who work on the systems. - Recording attendance without linking it to the role held. - Building the matrix once and not updating it when people or systems change. ## Next step The matrix starts from the list of systems and the roles that touch them, and the method for building it is in our guide to the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001). The full requirements of clause 7 are described in [ISO/IEC 42001 clause 7, explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained). Our approach to role-based training is described on the [AI Training](/en/services/ai-training) page. To build the matrix for your organization, [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # AI damage claims in Italy: evidence and causation under Legislative Decree 160/2026 URL: https://zerofive.ai/en/blog/compliance/ai-damages-evidence-causation-italy-decree-160-2026 Data: 2026-09-16 Abstract: Italy's Decree 160/2026 on AI damage claims: disclosure of logs and records, presumed causation, limits of compliance, direct action against insurers. **In short.** Italy's Legislative Decree 160/2026, in force from September 30, changes how courts handle claims for damage caused by an artificial intelligence system. A judge can order the disclosure of logs, technical documentation, risk management records, and human oversight parameters, and if those documents are withheld without a justified reason, the facts alleged by the claimant are deemed admitted. When the damage results from a breach of the AI Act, the causal link is presumed, while compliance, even when certified, does not by itself rule out liability. For a company using AI, governance documentation becomes evidence. On September 15, 2026, Italy's Official Gazette No. 214 published Legislative Decree No. 160 of September 9, 2026, another piece of the national adaptation to Regulation (EU) 2024/1689. The text combines two distant subjects: the use of AI by police forces, which fills the first half, and civil and criminal liability tied to AI systems, which directly concerns businesses. We cover the criminal side, with the new Article 437-bis of the Criminal Code and Article 25-vicies of Decree 231, in our [updated article on Legislative Decree 231/2001](/en/blog/compliance/italy-decree-231-article-25-vicies-ai). Here we look at Articles 16 to 20, the civil procedure tools available to anyone seeking compensation: five short articles that matter to whoever signs vendor contracts, approves insurance policies, and reports to the board, lawyer or not. ZeroFive is not a law firm, so we describe the text and its organizational consequences and leave interpretation to the courts and legal scholars. ## The scope of the new rules Article 16 sets two levels. The rules on access to evidence apply to every damages claim, contractual or non-contractual, for harm caused through the use of an AI system, whatever its risk class. The presumption of causation and the rule on compliance apply only when the damage results from a breach of one or more AI Act obligations. Two parallel regimes remain untouched: compensation under Article 82 of the GDPR, and the upcoming Italian law transposing Directive (EU) 2024/2853 on liability for defective products, which covers software and must be transposed by December 9, 2026. For individuals acting outside their business or profession, the decree adds jurisdiction for the court of their place of residence or domicile, so a consumer can sue close to home, even against a company based elsewhere. ## Disclosure of evidence Article 17 allows the judge, at the request of the party claiming to have suffered damage, to order the other party or a third party to disclose evidence relating to how the system works. The condition is that the claimant presents facts and elements making the claim plausible, including the link between the system's output and the damage. The text names four categories of documents, all already required by the AI Act. | Document | AI Act reference | What it lets you reconstruct | Who usually holds it | |---|---|---|---| | Automatic logs | Art. 12 | What the system did, when, and on which inputs | Provider; the deployer keeps those under its control (Art. 26) | | Risk management system | Art. 9 | Which risks were known and how they were addressed | Provider | | Technical documentation | Art. 11 | How the system was designed, trained, and tested | Provider | | Human oversight parameters and arrangements | Art. 14 | Who could intervene, with which tools, and in which cases | Provider for the design, deployer for the implementation | The order must be limited to what is necessary and proportionate, and the judge protects trade secrets and confidential information under Article 121-ter of the Italian Industrial Property Code. A party that fails to disclose without a justified reason faces two consequences of different weight: the judge may draw evidentiary inferences under Article 116 of the Code of Civil Procedure, and when the failure concerns the documents in the table, having weighed all other evidence, the judge treats the facts alleged by the claimant as admitted. A third party that fails to disclose, for instance a vendor holding logs its client cannot access, faces a fine of 1,500 to 10,000 euros. For a company, this is the provision with the most immediate effect. A log register that does not exist, or that sits with a vendor without access clauses, stops being a gap to fix before the next audit and becomes a fact the court can hold against whoever should have kept it. ## The presumed causal link Article 18 is a single sentence: when the damage results from the breach of one or more AI Act obligations, the causal link between breach and damage is presumed, unless proven otherwise. The wording is plainly circular, since it already assumes that the damage results from the breach, and courts will decide how much the claimant must prove before the presumption applies. The expected effect is a shift of the burden toward the defendant, who will have to prove a different origin for the damage. Which AI Act obligations already apply therefore matters. The prohibited practices of Article 5 and the AI literacy duty of Article 4 have applied since February 2, 2025, the obligations on general-purpose AI models since August 2, 2025, and the transparency duties of Article 50 since August 2, 2026. After the Digital Omnibus (Regulation (EU) 2026/1744), the obligations for Annex III high-risk systems apply from December 2, 2027, and those for Annex I from August 2, 2028: from September 30 the presumption works on a narrow perimeter, which widens as the high-risk obligations come into application. ## Compliance as a partial defense Article 19 states that the system's compliance with AI Act obligations, even when certified through the regulation's conformity assessment procedures, does not in itself exclude the defendant's liability, without prejudice to what the law transposing the defective products directive will provide. The rule refers to certification under the AI Act, and its logic extends to any voluntary attestation, including an ISO/IEC 42001 certification of the management system. A certificate shows that a set of controls existed on a given date, while a court case turns on how the system behaved in that specific situation, and that proof comes from logs, oversight records, and documented decisions. ## Insurance and direct action Article 20 concerns the CFO even before the legal department. Anyone planning to sue can ask the allegedly liable party whether it holds a liability insurance policy covering that damage, and the recipient must answer within thirty days, giving the policy details and the insurer's name. The request is not a precondition for suing, but a missing or incomplete answer can be used by the judge as an evidentiary inference. The injured party then has a direct action against the insurer, within the policy limits, with the liable party joined as a necessary party to the proceedings. The insurer can raise contractual defenses that predate the incident and, after paying, recover from the insured to the extent it could have refused or reduced the payment. A policy that excludes damage caused by automated systems, or ties coverage to controls never put in place, leaves the company uncovered exactly when the claim arrives. ## A hypothetical example A services company uses a third-party AI system to triage support requests and decide which cases reach a human agent. A customer whose request was closed automatically suffers a financial loss and sues, submitting the messages received and the timeline of events, so the judge orders disclosure of the decision logs and the human oversight arrangements. Only then does the company discover that the logs stay on the vendor's servers for thirty days, that the contract does not provide for their release in litigation, and that the agents' supervision was never written down. The vendor can be ordered to disclose as a third party, but the company has nothing to produce on human oversight, and on that point the customer's allegations risk being treated as admitted. The example is illustrative, shows the mechanism, and does not describe a real case. ## Checks to run now - Is there a register of the AI systems in use, with an owner for each and a risk classification under the AI Act? - For each system, who keeps the logs, for how long, and in what exportable format? - Do vendor contracts provide access to logs, technical documentation, and risk management records in case of litigation, on timelines compatible with a court order? - Is human oversight written down, stating who intervenes, on which signals, and with what record of the intervention? - Do liability policies cover damage caused by AI systems, and with which exclusions or conditions? - Who in the company answers, within thirty days, a request about the existence of coverage? - Does the 231 compliance model account for the new Article 25-vicies? ## Next step Most of the questions above can only be answered after an inventory of systems and a clear picture of the evidence the company actually produces. For the method, start with our guide to the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001) and the one on the [minimum documentation of an AIMS](/en/blog/compliance/aims-minimum-documentation-iso-42001); obligations by role are covered in the [complete EU AI Act guide](/en/blog/compliance/eu-ai-act-complete-guide-obligations-liability-data). With the [AI Rating](/en/services/ai-rating) we also measure maturity on the AI Risk dimension, which covers compliance, security, and risk governance. To discuss your case, [book an assessment meeting](https://calendly.com/fabiolalli/zerofive) or write to hello@zerofive.ai. *This article describes the legislative text and its organizational implications and does not constitute legal advice.* **Sources.** Legislative Decree No. 160 of September 9, 2026, Official Gazette, General Series, No. 214 of September 15, 2026, Articles 16-20; Regulation (EU) 2024/1689 (AI Act) as amended by Regulation (EU) 2026/1744, Articles 4, 5, 9, 11, 12, 14, 26, and 50; Regulation (EU) 2016/679, Article 82; Directive (EU) 2024/2853; Italian Code of Civil Procedure, Article 116; Legislative Decree No. 30 of February 10, 2005, Article 121-ter. --- # ISO/IEC 42001 clause 7, explained without jargon: competence and awareness URL: https://zerofive.ai/en/blog/compliance/clause-7-iso-42001-explained Data: 2026-09-15 Abstract: The whole of ISO/IEC 42001 clause 7: 7.1 resources, 7.2 competence, 7.3 awareness, 7.4 communication, 7.5 documented information. Evidence and audit sampling. "We've already done the AI training" usually means a two-hour online course, identical for everyone from the warehouse to risk management, with no verifiable record of who finished it and no check on what stayed useful to any particular role. In an audit that sentence doesn't hold up, and the reason has nothing to do with the length of the course. ## Clause 7 has five parts, not two Most people know it as "the training clause". Within the harmonised structure ISO/IEC 42001 shares with ISO 27001 and ISO 9001, clause 7 is called Support and contains five sub-clauses: resources (7.1), competence (7.2), awareness (7.3), communication (7.4) and documented information (7.5). Anyone preparing for certification by working only on 7.2 and 7.3 covers two fifths of the requirement and meets the other three during the audit, when there's no time left to build them. The three that get ignored are also the easiest to evidence, because much of what they ask for already exists in the organisation's other management systems. ## Resources come before people Sub-clause 7.1 requires the organisation to determine and provide the resources needed to establish, implement, maintain and continually improve the management system. The verb that matters is determine: the organisation has to be able to show how it concluded those resources were the right ones, not merely that something was allocated. In an AI context, resources aren't only people. Area A.4 of Annex A deals specifically with resources for AI systems and distinguishes data, tooling, computing resources and human resources, requiring each to be identified and documented. A management system declared without anyone having time allocated to maintain it, or without access to the data needed to assess what you intend to assess, is a statement of intent. The question an auditor asks here is direct: how many hours a week are assigned to whoever keeps the system register current and runs the assessments, and which decision produced that number. ## What determining a competence actually means Sub-clause 7.2 breaks into four steps, and the third is the one that dismantles the equivalence between a course and a competence. The organisation must determine the competence required for people whose work affects the management system's performance, ensure they are competent, where applicable take action to acquire the missing competence and evaluate the effectiveness of those actions, and retain documented evidence. Evaluating effectiveness is an obligation separate from delivery. An attendance record shows someone was connected, not that the training produced the intended effect. What's needed is something that measures the outcome: a practical case completed, real work reviewed by someone more experienced, a field check weeks later. There's a second element almost everyone overlooks. The standard recognises competence acquired through education, training or experience. That conjunction is alternative, meaning prior experience counts as evidence, provided it's documented rather than assumed. ## Demonstrating competence without a course For several roles, formal training is the least efficient route, and the standard doesn't mandate it. Other forms of evidence hold up in an audit. Documented experience, where a person is paired with a description of what they actually did rather than just a professional profile. A work sample, meaning a risk assessment or impact assessment genuinely carried out by that person, dated and signed, which counts for more than any certificate. Peer review, with a recorded outcome. Structured shadowing, with a start date, an end date and a closing assessment from whoever supervised. External certifications sit among the options rather than exhausting them, and on their own they don't show the person can apply that knowledge to the organisation's specific systems. ## The perimeter of awareness Under 7.3, people working under the organisation's control need to know the AI policy, understand how they contribute to the management system's effectiveness, and know what follows from not meeting its requirements. The phrase "under the organisation's control" reaches wider than "employees". It takes in temporary staff, consultants operating inside your processes, contractors, and in many cases personnel of suppliers carrying out work on your behalf. The external agency running your customer service with an AI-assisted tool falls inside the perimeter, and the only way to govern it is the contract, because you have no training plan covering that agency's people. For most roles the content of awareness comes down to three things: what the system they use does, where the system's responsibility ends and theirs begins, and who to flag anomalous behaviour to. None of them needs to know how to build a model. ## The communication almost nobody plans Determining what to communicate about the management system, when, to whom, how and who does it: that's what 7.4 sets out. It's a short sub-clause, skipped almost universally, with concrete consequences when it's needed. The questions it answers are operational. Who responds to a customer asking whether the decision affecting them was made or suggested by an automated system, and in what words. Who communicates internally that a system has been suspended, and how quickly. Who speaks to an authority if a request arrives. This intersects directly with the transparency obligations under Article 50 of the AI Act, binding since August, which in several cases require informing people that they're interacting with an AI system. Without a plan, the answer gets improvised by whoever receives the question first, who is usually the person least equipped to give it. ## Maintain and retain are different verbs Two obligations that get confused routinely are separated under 7.5. Some documented information must be maintained, meaning kept current because it describes a present state: the management system's scope, the AI policy, the procedures. Other documented information must be retained, meaning kept as proof that something happened: completed risk assessments, impact assessments, training records, results of effectiveness checks. Sub-clause 7.5.2 adds how documents get created and updated: identification, appropriate format, review and approval before use. Sub-clause 7.5.3 adds control: availability where and when needed, protection against loss or improper use, version management and access control. The practical consequence is sharp. A document with no version, no date and no evidence of approval isn't documented information for the purposes of the standard, it's a file. The distinction surfaces at the first sampling, when an auditor asks which version of a procedure is in force and two slightly different ones are circulating in two folders. ## What actually happens during the audit An auditor doesn't check everyone. They sample three or five people across different roles and ask simple questions, usually the same ones: what's the company's AI policy and where is it, what does the system you use every day do, what would you do if you noticed it getting something wrong, who would you report that to. When the sampled person can't answer, the nonconformity isn't about that person. It's about the management system, which planned a training action without verifying its effectiveness. Which is why the effectiveness check is worth running beforehand, against a sample resembling the one the auditor will use. A second recurring check concerns recent joiners. If someone has been with the company three months, working on a process touched by an AI system, and has received nothing, the update mechanism required by 7.2 isn't working, however complete the plan is for everyone who was already there. ## The most frequent mistakes The one-size-fits-all course is the most visible, though not the most expensive. The most expensive is treating an attendance register as evidence of competence, because it produces the feeling of being covered right up until the auditor asks for the effectiveness assessment and none exists. Next comes awareness confined to people who write code, which leaves exposed exactly the roles where system-assisted decisions touch real people. Then the contractor perimeter, forgotten because it doesn't appear in HR systems. Then sub-clauses 7.4 and 7.5, never addressed because nobody associates them with the word training. The last one is the absence of a trigger: no mechanism firing an update when someone changes role or when the system they use changes. A plan built once and never revisited stops being valid the moment the organisation moves, and organisations move. ## The next step Separating competence from awareness, assigning each to the right roles and deciding how both get verified is the work missing from most companies that say the training is done. The next piece goes into operational detail with the matrix connecting each role to what it needs to be able to do, and how to keep that matrix aligned as the organisation changes. --- # AI project budgeting: costs from pilot to production URL: https://zerofive.ai/en/blog/strategy/ai-project-budget-pilot-production Data: 2026-09-12 Abstract: Estimate total AI project cost across data, licences, integration, oversight and maintenance, with scenarios and practical vendor questions. **An AI project budget must cover the complete process, not just the model.** Licences and usage are only part of the cost. Data, integration, evaluation, oversight, training and maintenance determine whether production is sustainable. A pilot should measure these items before a larger commitment is approved. ## Pilot cost is not production cost A demonstration may use prepared data, a few users and manual checks. Production brings incomplete cases, different permissions, demand peaks and support requests. The operating task changes: availability, monitoring, exception handling and source maintenance become necessary. There is no universal multiplier between pilot and production. A narrow project can remain simple; integration into critical processes requires different controls. Build estimates around actual conditions and separate known information from assumptions. ## Total-cost table | Item | Initial costs | Recurring costs | Question to resolve | |---|---|---|---| | Data | Cleaning, permissions, preparation | Updates and quality checks | Who maintains sources? | | Integration | Connections and access | Compatibility and changes | Which systems may change? | | Models and tools | Configuration | Licences, usage, storage | What contractual limits apply? | | Evaluation | Sample and criteria | Tests after changes | Who accepts continuing quality? | | Oversight | Control design | Review and exceptions | How much human work remains? | | Training | Exercises and materials | New users and updates | Can people handle uncertain cases? | | Operations | Monitoring and recovery | Support and incidents | Who responds and with what priority? | Internal work is not free. Record hours and skills even when they do not create an external invoice: they consume capacity that could support other work. ## A calculable model For a defined period, total cost adds setup, fixed costs, variable costs, human work and maintenance. Compare alternatives over the same period and scope. Make exclusions such as integration or oversight visible before comparing proposals. Cost per accepted outcome divides process cost by the number of genuinely usable results. Counting every generation as a useful outcome hides attempts, mistakes and revisions. Systems that call tools or repeat steps also require an estimate of operations per case. ## Three scenarios rather than one number Build a contained, expected and pressure scenario. Vary volumes, document length, retries, review rate and frequency of change. Explain each variation using historical data, pilot measurements or an explicitly labelled assumption. | Variable | Budget effect | Useful evidence | |---|---|---| | Volume | More usage and work | Historical demand and seasonality | | Complexity | More processing and checks | Distribution of case types | | Rework | Fewer usable outcomes | Observed corrections | | Updates | Maintenance and testing | Source change frequency | | Adoption | Actual usage and support | Active users in the process | ## Hypothetical example: document assistant A company considers an assistant for internal procedures. Initial spending covers source selection, permissions, configuration and testing. Operating spending covers document updates, usage, answer review, support and access reviews. Frequently changing procedures can make reliable source maintenance more significant than a single model request. If many answers need checking, human review belongs in the calculation. This example illustrates estimation structure, not a quote or measured customer result. ## Connect cost and benefit Define the baseline before testing. Measure complete process time, including review, and distinguish released capacity from financial savings. Name an owner who can explain how the benefit will be used. Better quality can justify investment without reducing time, provided it is measured and tied to an objective. Risk assessment remains part of the decision. The [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) structures governing, mapping, measuring and managing risk; it does not provide standard prices or returns. An attractive projected return cannot remove a data constraint or a necessary control. ## Questions before signing - Which activities are included and which remain internal? - Which usage estimates have been measured? - What changes with higher volume or complexity? - Who funds and performs tests after updates? - How are data, configuration and documentation exported? - Which terms allow termination or reduced scope? - What threshold requires renewed spending approval? ## Fund successive decisions Separate exploration, validation and production budgets. Each step needs expected evidence, spending limits and a decision owner. [PROTOT.AI](/en/protot-ai) validates before production commitment; [AI Strategy](/en/services/ai-strategy) connects initiatives with priorities. Read [what AI consulting should deliver](/en/blog/strategy/ai-consulting-what-a-project-delivers) and [how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case). To discuss your project’s constraints and assumptions, [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # AI transformation: processes, accountability and outcome metrics URL: https://zerofive.ai/en/blog/strategy/ai-transformation-processes-accountability-metrics Data: 2026-09-12 Abstract: Measure AI transformation with baselines, accountable owners, quality, costs and exceptions. A practical guide from tools to business outcomes. **AI transformation changes how an organisation produces outcomes, makes decisions and remains accountable.** Distributing tools enables change; transformation becomes visible when processes, responsibilities and measures change. Start with a baseline of current work, not a count of activated licences. ## Three levels of change | Level | What changes | Useful evidence | |---|---|---| | Individual use | Preparation of one activity | Task quality and time | | Automation | Execution of one step | Step time, errors and rework | | Transformation | Complete process and decisions | Overall outcome, cost and accountability | These levels can coexist. A personal assistant can be the right answer. It becomes part of transformation when its use changes handovers, approval criteria or service delivery. ## Design the process before the organisation chart Map inputs, activities, decisions, checks and outputs. Ask which information each step needs, who owns it and how exceptions are handled. Final quality also depends on waiting times, authorisations and missing data. Faster drafting offers limited value if approval still takes days. The redesigned process needs an accountable outcome owner. A system can suggest, classify or perform bounded actions; the organisation still determines purpose, limits and controls. The [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) helps connect governance, context, measurement and risk management. ## Accountability matrix | Role | Accountable decision | Evidence to maintain | |---|---|---| | Sponsor | Priority and investment | Approved goals and constraints | | Process owner | Operational outcome | Baseline, indicators and exceptions | | Data owner | Source use and quality | Access, provenance and update rules | | Technical owner | Availability and changes | Versions, tests and monitoring | | Control functions | Reviews within their remit | Risks, checks and agreed actions | | Users | Use within agreed rules | Reports and corrections | These are roles to assign, not necessarily new hires. In smaller organisations one person may cover several roles, provided conflicts and required controls are addressed. Verify skills transfer through independently completed activities, not attendance alone. ## Measure outcomes rather than activity A baseline describes a period and sample: volumes, case mix, time, errors and resources. Compare reasonably equivalent conditions after introducing AI. A month of easier requests does not establish system improvement. | Indicator | Interpretation | Limitation | |---|---|---| | End-to-end time | Arrival to completion | Includes delays unrelated to AI | | First-pass quality | Cases completed without correction | Needs a shared error definition | | Cost per completed case | Process costs divided by accepted outcomes | Must include oversight and maintenance | | Exceptions | Cases requiring intervention | An increase may mean better detection | | Effective adoption | Use in the intended process | Logins do not establish value | Released time is not automatically financial savings. Explain whether it creates capacity, quality, backlog reduction or a reduction in actual expenditure. Avoid counting the same benefit twice. ## Hypothetical example: request handling A service introduces AI extraction and draft preparation. Drafting time falls, but checking time grows because sources are invisible. The process outcome may remain unchanged. The useful decision is to improve traceability and exception handling before extending use. In the revised setup, operators see sources, correct extraction and flag uncertain cases. Repeat the comparison including review time and errors. This scenario illustrates evaluation, not a result achieved by ZeroFive. ## Managing continuous change Models, instructions and sources change. Relevant changes need proportionate assessment: affected cases, tests to repeat and release approval. Maintain control examples, version history and a recovery procedure. People also change roles. Training should use realistic exercises and escalation criteria. Select tools according to organisational needs and existing licences rather than prescribing one platform for everyone. ## The periodic review document Bring a concise document containing the objective, baseline, observed outcomes, costs, incidents, limitations and requested decision. Separate facts, estimates and hypotheses. Assign an owner and date to each corrective action. Review frequency depends on criticality and change rate, not a universal schedule. Decisions include extend, maintain, revise and suspend. A justified suspension protects resources and preserves learning from the experiment. Explore [AI Strategy](/en/services/ai-strategy), [AI Shift](/en/services/ai-shift) and our [papers](/en/papers). To identify a starting point, read [how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case). [Book an assessment meeting](https://calendly.com/fabiolalli/zerofive) or start a [company self-assessment](/en/start-ai-rating). --- # AI adoption: how to choose your first use case URL: https://zerofive.ai/en/blog/strategy/ai-adoption-choose-first-use-case Data: 2026-09-11 Abstract: Choose your first AI use case using value, data, feasibility and risk. A practical worksheet and acceptance criteria for a measurable pilot. **Choose your first AI use case for its testability, not the impact of its demo.** It needs an accountable owner, an observable process, usable data and an outcome that can be compared with current work. Assess value, feasibility and risk together: a large potential benefit cannot compensate for missing controls. ## From ideas to a decision A document assistant, request classification and quotation drafting are candidates, not projects. To become projects, they must specify who uses the output, which activity changes and which decision remains human. Start by asking which process step should improve and how the organisation will recognise that improvement. The [AI adoption guide](/en/ai-adoption) explains the broader journey. This article addresses a narrower decision: selecting an experiment that produces useful investment evidence. ## The selection worksheet | Dimension | Evidence required | Decision question | |---|---|---| | Value | Volumes, current time, rework | Which cost or outcome could change? | | Feasibility | System access and skills | Can we test without rebuilding the process? | | Data | Representative sample and permissions | May these data be used for this purpose? | | Risk | Impact, reversibility, controls | Can we detect and correct an error? | | Adoption | Named owner and involved users | Who will use the output in actual work? | Rate each dimension with a reason: evidence available, partial or absent. A summary score supports discussion but must not hide a blocking constraint. Missing rights to data require a data decision before an experiment. ## Constraints before ranking The [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) distinguishes Govern, Map, Measure and Manage. It is a voluntary reference for organising risk management and measurement, not a certification. Before ranking ideas, define context, affected people and responsibilities. A decision affecting people calls for different attention from an internal draft. Check applicable law with the relevant functions: a prioritisation matrix does not replace legal classification. For personal data, purpose, minimisation and security remain separate from model quality. ## Hypothetical example: incoming request classification A company considers a system that suggests a request category. Operators can change the suggestion, and it is not sent to the customer. The service owner gathers ordinary, ambiguous and rare requests, defines categories and compares automated assignments with reviewed labels. The hypothesis is not merely that the model classifies accurately. It is that the complete process takes less time while maintaining an error level agreed beforehand. Review time and corrections therefore matter too. This is an illustrative example, not a customer result. | Worksheet item | Example to complete before testing | |---|---| | Owner | Person accountable for request handling | | Baseline | Time and quality measured in the current process | | Sample | Representative requests, separate from development examples | | Measures | Errors by category, total time, corrections | | Oversight | Operator confirmation before routing | | Stop condition | Agreed threshold for critical errors or unavailability | ## Writing acceptance criteria A complete criterion names a measure, sample, threshold, verifier and consequence. Thresholds depend on the cost of error and current quality, not another company’s pilot. Distinguish recoverable errors from mistakes with hard-to-reverse consequences. Keep improvement data separate from final evaluation data. Record model version, instructions and sources so that later changes can be compared. Include inexperienced users and incomplete inputs rather than only well-written requests. ## Moving into real work A successful experiment supports a decision, not automatic rollout. Production requires access controls, incident handling, cost monitoring and an alternative process when the system is unavailable. The owner must be able to suspend use without blocking essential work. Training should explain when to accept a suggestion, when to inspect sources and when to involve a qualified person. Tool logins alone do not show whether the work improved. ## Selection meeting checklist - A specific process and named owner. - An observed baseline rather than an impression. - Accessible data usable for the intended purpose. - An evaluation sample containing difficult cases. - Thresholds agreed before seeing results. - Human oversight and a recovery path. - An explicit decision: proceed, revise or stop. Where these are missing, complete the worksheet before buying more licences. [AI Assessment](/en/services/ai-assessment) connects processes and opportunities; [PROTOT.AI](/en/protot-ai) provides the validation gate before production. Read [budgeting from pilot to production](/en/blog/strategy/ai-project-budget-pilot-production) for the wider commitment. Start with a [company self-assessment](/en/start-ai-rating) or [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # AI consultant, vendor or internal team: how to choose URL: https://zerofive.ai/en/blog/strategy/ai-consultant-vendor-or-internal-team Data: 2026-09-11 Abstract: When to build in house, when to buy and when an independent advisor helps: a decision matrix and the questions to ask during vendor selection. **In short.** Choosing between an internal team, a solution vendor and an independent consultant does not depend on company size. It depends on three variables: how distinctive the AI capability is for your business, how sensitive the data involved is, and how governable the result must stay over time. Distinctive capabilities are built in house. Standard functions are bought. When the real problem is deciding what to do, in which order and under which controls, you need someone independent from the sale. Many companies take this decision backwards: they pick the vendor first and then look for a problem to solve. The outcome is predictable: tools switched on, licences paid, real usage limited to a handful of enthusiasts. ## The three models compared | Aspect | Internal team | Solution vendor | Independent consultant | |---|---|---|---| | Fits when | The capability is distinctive and recurring | The need is standard and widespread | Priorities, criteria and governance are missing | | Time to first result | Longer, hiring dependent | Short, the solution already exists | Medium, depends on data quality | | Dominant cost | People and maintenance | Licences and integration | Working days and skills transfer | | Main risk | Under-resourcing and turnover | Vendor lock-in | Theoretical deliverables with no application | | What stays in the company | Knowledge and code | Configuration and data in the system | Documents, criteria and skills | | Conflict of interest | None | Present, sells what it recommends | None if no licences are resold | None of the three is better in absolute terms. Most organisations end up with a combination: an advisor to set priorities and controls, vendors for standard functions, and a small internal core for what should not be delegated. ## The question that comes first Before choosing a model, decide whether the capability is distinctive. The test is simple: a capability is distinctive if a competitor copying it would erode your advantage. Drafting internal communications rarely qualifies. A prioritisation model built on your historical data, your operating rules and your sector language often does. Distinctive capabilities should be built or at least controlled internally, because they live on continuous iteration and tacit knowledge. Standard capabilities should be bought, because building them internally means paying twice for the same work. ## Decision matrix Score each initiative from 1 to 5 on four dimensions: 1. **Distinctiveness**: how much the capability affects competitive advantage. 2. **Data sensitivity**: how confidential or personal the data involved is. 3. **Usage frequency**: how often the activity repeats. 4. **Available skills**: how capable the internal team is of maintaining it. Typical readings: - High distinctiveness, strong skills: build internally, with external support only in early phases. - High distinctiveness, weak skills: build with hands-on support and an explicit skills transfer plan. - Low distinctiveness, high frequency: buy, negotiating data portability and exit terms. - High sensitivity in any scenario: the model choice follows the definition of controls, not the other way round. The matrix does not produce an automatic answer. It makes the reasoning explicit and lets different functions argue from the same basis. ## How to evaluate a vendor A solution vendor is the right choice in many cases, provided you examine what surfaces after signature: - Where the data sits and who can access it. - Whether data is used to train models, and how to opt out. - Which technical documentation is supplied to satisfy internal and external obligations. - What happens to data and configuration if the contract ends. - How much notice applies to changes in underlying models, pricing and usage limits. - Which quality metrics are measured and shared. Those answers, in writing, are worth more than a demo. ## How to evaluate a consultant The decisive criterion is independence from the sale: whoever recommends a technology and earns a margin on it is not in a position to advise against it. Few questions are needed: 1. Do you resell licences or hold channel agreements with vendors? 2. Which documents stay in the company at the end, and who maintains them? 3. How do you measure skills transfer to internal people? 4. What do you do if the analysis shows the project is not worth running? 5. Who actually works on the project, and how present are they? Question four is the most revealing. An engagement that cannot end with "this is not worth doing" is not assessing anything: it is selling. ## When to build an internal team An internal core becomes sustainable when three conditions hold: a continuous flow of use cases, accessible data of reasonable quality, and a function that answers for outcomes. Without the third condition the team produces prototypes nobody adopts. Start small, with two or three people combining process knowledge and technical skill, and grow on the basis of completed use cases rather than growth forecasts. ## A hypothetical example A manufacturer is weighing three initiatives: assistance in drafting internal documents, complaint analysis, and maintenance prediction. The first has low distinctiveness and high frequency: buy. The second touches customer data and needs internal rules: buy with additional controls, or build, depending on sensitivity. The third depends on proprietary historical data and affects cost directly: build, with initial support. This example is illustrative and shows the reasoning; it is not a measured result. ## Next step The choice becomes straightforward once priorities are clear and internal skills are honestly mapped. You can read our approach on the [How we work](/en/how-we-work) page, see [what an AI consulting project should deliver](/en/blog/strategy/ai-consulting-what-a-project-delivers), or start with a [self-assessment of your company](/en/start-ai-rating). For a direct discussion of your case, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # AI consulting for businesses: what a project should deliver URL: https://zerofive.ai/en/blog/strategy/ai-consulting-what-a-project-delivers Data: 2026-09-11 Abstract: The documents an AI consulting engagement must leave behind: inventory, risk assessment, acceptance criteria and accountability, phase by phase. **In short.** Useful AI consulting does not deliver a deck: it delivers decisions taken and documents that stay inside the company after the consultant leaves. Four artefacts separate a solid engagement from a theoretical exercise: an inventory of systems and use cases, a risk assessment for each one, measurable acceptance criteria, and an accountability model naming who decides and who answers for outcomes. Below is the phase by phase table, with the expected artefact, its approver and the criterion that lets the phase close. Anyone comparing AI consulting proposals runs into the same problem: they all look alike. Every one of them mentions assessment, roadmap, use cases and change management. The difference is not in the wording, it is in what remains in the company at the end. An engagement should be judged by the verifiable objects it produces, because those are the only things that survive a change of vendor, of sponsor or of priorities. ## The test that separates a project from a presentation An artefact is useful when someone can use it to decide without asking its author for an explanation. A prioritisation matrix without explicit criteria is not an artefact: it is a formatted opinion. A risk register with no named owner becomes obsolete within weeks. Three questions are enough to evaluate any deliverable: - Who will use it after the engagement ends, and for which decision? - How is it updated, how often, and by whom? - What breaks if the answer never arrives: which decision stays blocked? If a deliverable fails these three questions, its value ends with the final meeting. ## Phases and what each must produce | Phase | Decision to enable | Expected artefact | Approver | Closing criterion | |---|---|---|---|---| | Framing | Where it makes sense to intervene | Map of candidate processes with measurable objectives | Executive sponsor | Scope written down, including what is out | | Assessment | How ready the organisation is | Picture of data, skills, processes and governance | Sponsor and function leads | Each dimension backed by evidence, not perception | | Portfolio | Which use cases to fund | Use cases scored on value, feasibility, risk and data availability | Steering committee | Priorities ordered against written criteria | | Validation | Whether the hypothesis holds | Prototype with acceptance criteria defined up front | Process owner | The result states pass or fail | | Production | Whether the system can enter official processes | Technical documentation, controls, monitoring plan | Process owner and risk function | Controls live, not planned | | Continuity | Who maintains the system over time | Accountability model and review schedule | Executive leadership | Names, frequencies and thresholds assigned | Sequence matters more than duration. Skipping the assessment funds use cases the organisation cannot absorb. Skipping acceptance criteria produces pilots that never close, because nobody defined success before starting. ## The four documents that must remain ### Inventory of systems and use cases This is the foundation for everything else. For each system or use case it should record purpose, data used, who uses it, who is accountable, which process it enters and which decision it influences. Without this list you cannot assess risk, and you cannot answer an internal or external clarification request. The same structure later feeds risk management and documentation obligations, so it is worth building once and reusing. ### Risk assessment per use case Risk is not a property of the technology: it depends on use. The same model can be irrelevant in an internal draft and sensitive in a decision affecting people. The assessment should state the type of impact, who can be affected, which controls exist and who supervises. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organises this work into four functions, govern, map, measure and manage, and is a practical reference because it requires no certification to adopt. ### Acceptance criteria These are the strongest defence against endless pilots. They must be written before work begins and must include the current baseline, the expected result, the measurement method, the sample, the verifier and what happens if the result does not materialise. A workable criterion can be checked by someone other than the person who built the system. ### Accountability model Every production system needs three names: who uses it in the process, who answers for outcomes, and who verifies that it keeps behaving as expected. Without those roles, human oversight remains a stated principle rather than a real control. ## How to read a proposal Concrete questions serve better than price comparison: 1. Which documents will remain in the company, and in what editable format? 2. Who maintains them after the engagement closes? 3. Which criteria decide whether a use case moves into production? 4. What happens if the assessment shows the initial scope is not the best one? 5. Which skills transfer to internal people, and how is that transfer verified? 6. Which part of the work depends on specific tools or licences, and what survives if those change? The last question deserves particular attention. Consulting tied rigidly to one platform produces results that travel badly when conditions change, and in AI conditions change often. ## A hypothetical example A services company wants to reduce response time to customer requests. A properly framed project does not start from the tool: it starts from the current measurement, for example average response time and the share of requests needing rework. It then defines what improvement means, which error margin is tolerable, who reviews answers before they are sent during the first months, and when that review can be reduced. At the end the company owns a measurement, a criterion, a control and an owner. This example is illustrative and shows the structure; it does not describe an achieved result. ## What to avoid - Detailed twelve month roadmaps drawn before anyone has checked data quality. - Lists of forty use cases with no selection criteria. - Benefit estimates without the matching baseline. - Deliverables provided only as presentations, with no updatable version. - Governance described as a principle, with no names and no frequencies. ## Next step If you are evaluating AI consulting, start from an honest picture of where you are: what is already in use, on which data, with which responsibilities assigned. You can read our approach on the [Services](/en/services) page and in the [practical AI adoption framework guide](/en/blog/strategy/ai-adoption-framework-practical-guide-enterprises), or begin with a [self-assessment of your company](/en/start-ai-rating). If you would rather discuss it directly, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive): in thirty minutes we clarify scope, constraints and which documents would genuinely help in your case. --- # Designing an ISO-ready AI system: what to prepare before development starts URL: https://zerofive.ai/en/blog/compliance/designing-iso-ready-ai-system Data: 2026-09-10 Abstract: Designing an ISO-ready AI system: what can't be recovered later, logging and oversight as design choices, gates with exit criteria, and what to ask a vendor during selection. The moment an AI project discovers it has to answer to ISO/IEC 42001 almost always arrives too late, usually once the system is already in staging and somebody asks whether a risk assessment was ever done. What follows is two or three weeks of retroactive reconstruction, with a team trying to document decisions made months earlier and a launch date slipping. The awkward part is that some of that work cannot be recovered at all, however long anyone spends on it. ## What cannot be reconstructed after the fact Policies, procedures and user manuals can be written at the end of a project. They describe a state, and a state is verifiable at any point. Four things, by contrast, exist only if they were produced while the system was being built. The first is the provenance of the data used to train or tune the model. If nobody tracked where each dataset came from, on what basis and with what usage rights, six months later that chain cannot be reconstructed, only asserted. An auditor knows the difference. The second is the alternatives that were rejected. The question of why this architecture, this model, this vendor was chosen has a credible answer only if the options were on the table at the same time. Reconstructing it later produces a justification, which is a different thing. The third is the baseline of the process before the system was introduced. How long it took, how many errors it produced, what it cost. Without that number measured up front, later monitoring has nothing to compare against and nobody can say whether the system is improving the situation or degrading it. It's also why so many AI projects can't demonstrate their own return: nobody recorded the starting point. The fourth is the acceptance criteria. Deciding what has to be true for the system to count as successful, before seeing the results, is one thing. Deciding it afterwards, looking at the metrics that came out, is an exercise that accommodates any outcome. ## Technical decisions with compliance consequences Some choices that look purely architectural in a project plan determine whether the system can be governed at all. Changing them later means going back into the code, not into the documentation. **Logging.** Article 12 of the AI Act requires high-risk systems to technically allow the automatic recording of events over the lifetime of the system, and Article 26(6) requires the deployer to retain those logs for at least six months. The operational question, though, isn't switching logging on, it's deciding what gets recorded. A log holding only the output won't let anyone reconstruct a single decision months later. That needs the input received, the model version live at that moment, the outcome produced, and any human intervention along with who made it. Adding those fields afterwards touches the data schema, often latency, sometimes the whole pipeline. **Human oversight.** Article 14 requires high-risk systems to be designed so people can effectively oversee them. In practice that comes down to three design questions: who can stop the system, how quickly, and with what information in front of them at the moment they have to decide. An operator who sees only the outcome, without the elements that produced it, is in no position to challenge it, and Article 13 on transparency toward those using the system exists precisely because oversight without understanding stays formal. **The level of explainability.** How well the system has to justify its outputs depends on what it decides and who it affects. This constrains the architecture: choosing a non-interpretable model for a use case that requires a reason is a decision no amount of later documentation undoes. **The fallback path.** What happens when the system is unavailable, or produces an outcome the operator rejects. If no workable manual path exists, the system effectively cannot be switched off, and a system that cannot be switched off is a risk no control compensates for. ## When a technical choice changes your legal role In the piece on the inventory we covered how Article 25 of the AI Act sets out three situations where an entity using a system becomes its provider, taking on the obligations under Article 16. Two of those three arise from decisions made at design time. Fine-tuning on proprietary data and changing a decision threshold can both fall within the notion of substantial modification. Changing the purpose of a system not classified as high-risk so that it becomes high-risk has the same effect. The reclassification requires no notification or registration, it happens when the conditions are met. The practical consequence is that "let's start from the vendor's model and adapt it to our data" isn't only an implementation choice. It needs making with an understanding of what follows, and the phase to raise the question is design, when changing course costs one meeting. ## The questions to ask, and what to do with a vague answer A list of questions is worth little without a way to recognise an insufficient answer. These six each carry an exit criterion. - **Is there a non-AI alternative, and why was it rejected?** If nobody considered the alternative, the project doesn't have a case yet, it has a hypothesis. This question stops more projects than all the others combined, which is why it goes first. - **What decision does the system produce, and who does it affect?** The answer drives the risk classification and therefore everything downstream. If the answer is "it supports the operator", ask how often the operator departs from the suggestion: below a certain rate, the system is the one deciding. - **Who owns it in production?** A name is needed, not a department. If nobody accepts the role before release, nobody will accept it afterwards. - **What is the current baseline, measured?** Without a number collected beforehand, later monitoring has nothing to compare against. - **What has to be true for the system to count as successful?** Written down in advance, with numeric thresholds, otherwise a metric confirming the decision already taken will always be found downstream. - **What happens when it gets something wrong?** Who notices, how quickly, and what they do. If the answer is that the end customer will notice, the project has a design problem, not a documentation problem. ## The gates, and what clears them Few checkpoints are needed, but each needs explicit exit criteria, otherwise they turn into meetings that acknowledge decisions already made. At **kickoff**, the first two questions above get answered and a position is taken on the expected risk classification and on the role the organisation will assume. It's the cheapest gate and the one skipped most often. At **design review**, the choices with compliance consequences get checked: what the logs record, how oversight is designed, what level of explainability is required, what fallback path exists. Leaving this gate with any of those open means it will be closed badly and in a hurry later on. **Before production**, what gets checked is evidence rather than intent: the measured baseline, logs active and verified against one real case reconstructed end to end, a named owner, an open row in the AI system inventory, and a monitoring plan with its thresholds. **Thirty or ninety days after launch**, actual behaviour gets compared against the baseline and the acceptance criteria set at the start. This is the gate almost nobody puts in the calendar, and it's the one that says whether the system is doing what it was built for. ## If you're not the one building it Most organisations don't develop from scratch, they buy or integrate. The same questions apply, but they need putting to the vendor during selection, because once the contract is signed the negotiating leverage is gone. Five things are worth asking for in a tender: the system's technical documentation, the role the vendor states it takes on under the AI Act, which logs the system produces and in what format they're accessible, what validation testing was carried out and with what results, and how much notice is given before the underlying model changes. A vendor that won't answer these during a tender won't answer afterwards either, and that silence is itself useful input to the decision. ## Why a policy isn't enough here Across much of ISO/IEC 42001's Annex A, a written and approved procedure counts as sufficient evidence. Across area A.6, the one covering the AI system life cycle, it doesn't. The controls in that area deal with documenting design choices, verification and validation, deployment, operational monitoring and event logging. For each, an auditor asks for the record the system produced while running, not the document describing how it ought to run. A test plan counts if the test results exist. A release procedure counts if there's a trace of the checks performed before the last release. That distinction changes what has to be built, and above all when. Evidence in this area is only produced while the system is being developed and used, which brings the argument back to where it started. ## The most frequent mistakes The most common of all is the proof of concept that slides into production without passing any gate, because it worked and there was pressure. It begins life as an experiment, therefore without documentation, and ends up handling real cases with a level of control designed for a demo. The second is nominal human oversight, the operator approving three hundred cases a day who in practice is rubber-stamping. Formally the control exists, substantively the system decides on its own, and the gap surfaces at the first incident. The third is documentation written for the auditor rather than for whoever will maintain the system. It's recognisable because nobody on the team ever opens it, and because it goes stale without anyone noticing. ## How this connects to the rest of the series Designing with the knowledge that the system will have to answer these questions isn't extra work, it's the same work in a different and cheaper order. The information is needed either way: gathered during, it costs hours; reconstructed afterwards, it costs weeks; and in four cases it can't be gathered at all. The next piece in this series leaves technical documentation behind and turns to people, with what the standard requires on competence and why it's as auditable a requirement as any risk register. --- # The AI system inventory: what it must contain and how to keep it current URL: https://zerofive.ai/en/blog/compliance/ai-system-inventory-iso-42001 Data: 2026-09-08 Abstract: How to build an AI system inventory that survives an audit: scoping the definition, required fields, AI Act Article 25, shadow AI discovery and a 90-day plan. If you look at most companies' AI system registers right now, assuming one even exists, you'd find pretty much the same scene: a handful of rows untouched for months, systems long decommissioned still marked active, two or three tools the sales team uses every day that nobody ever logged because they didn't look like "real AI". It happened to us too, before we cleaned it up. The inventory is the document everything else in an AI management system rests on. Risk assessment needs to know what to assess, the impact assessment needs a perimeter, the training plan needs to know who uses what. When the inventory is wrong, every document built on top of it inherits the same error without anyone noticing until the audit. ## The definition comes before the fields The question that stalls most inventory projects in week one isn't which column to add. It's what counts as an AI system. ISO/IEC 42001 and the AI Act both start from a broad definition aligned with the OECD one: a system that, from a set of inputs, generates outputs such as predictions, content, recommendations or decisions, with some degree of autonomy. Applied to the reality of an operating company, that definition takes in quite a few things nobody would spontaneously call artificial intelligence. The four cases that generate the most debate in our assessments are always the same. The spreadsheet with a scoring model built in-house by someone who no longer works there. The AI feature switched on inside software you already owned, added by the vendor in an update nobody chose. The chatbot on the website, usually treated as marketing and therefore never reviewed by IT. And the model bought through an API, wired into an internal workflow by a product team, appearing nowhere on any org chart. The working rule we suggest: if an output from that system influences a decision affecting a person, a customer or a supplier, it goes in the inventory. Risk classification comes afterwards, and exists precisely to separate the trivial cases from the serious ones. Excluding something before registering it means deciding without the information needed to decide. ## One row per tool or one row per use This choice determines whether the inventory stays useful or becomes unmanageable, and it needs making early because redoing it later is expensive. The same generative assistant used by marketing to draft copy and by HR to do a first pass on job applications is, technically, the same tool. From a risk standpoint they are two different worlds: the first is a low-impact use, the second falls into the category of cases Annex III of the AI Act treats as high-risk. An inventory organised by tool flattens that difference and produces rows that say nothing useful. An inventory organised by system-plus-purpose pairs makes it visible: two rows, two owners, two risk classifications, two review paths. It costs a few extra rows and saves months when the time comes to show that critical purposes were treated as such. ## Provider or deployer, the field almost nobody fills in Most companies assume they are deployers of somebody else's systems, and therefore subject to lighter obligations. That assumption holds until it meets Article 25 of the AI Act, which sets out three situations where an entity using a system becomes its provider outright, taking on the obligations under Article 16. The first is putting your own name or trademark on a high-risk system already placed on the market, typically in white-label or resale arrangements, absent a different contractual allocation. The second is making a substantial modification to a high-risk system that remains high-risk: Article 3(23) defines this as a change not foreseen in the initial conformity assessment that affects compliance or the intended purpose. The third is changing the purpose of a system not classified as high-risk in a way that makes it high-risk. The second one catches the most companies off guard, because the boundary of "substantial modification" is wider than it looks: fine-tuning on proprietary data, changing a decision threshold in a classifier, restructuring a retrieval pipeline can all fall inside it. The reclassification doesn't run through a notification or a registration, it happens by the conditions being met. This is why the inventory needs to carry the role assumed for each row, and the date that role was last assessed. It's the field that turns the register from a descriptive list into something that flags an exposure before it becomes a problem. ## What an auditor looks for in each field - **Name and purpose**, described in language someone who didn't build the system can follow. If the purpose is lifted from the vendor's marketing material, an auditor spots it on first reading and treats it as a signal about the quality of the whole register. - **Owner**, a named person accountable for the decisions the system makes. A department is not an owner: when responsibility belongs to everyone, in an audit it belongs to no one. - **Data processed and its source**, which doubles as the direct link to the mapping a DPIA already requires and to the data requirements in Annex A of ISO/IEC 42001. Filling in the same information twice in separate documents is the most common reason they drift apart. - **Lifecycle status**: development, pilot, production, decommissioned. Status is what makes the inventory readable at a glance, and the move from pilot to production is where the update most often gets skipped. - **Role assumed**, provider or deployer, with the date of last assessment. - **Risk level**, aligned with AI Act classification where it applies, with the reasoning behind the classification, not just the outcome. Auditors rarely challenge the level chosen, they challenge the absence of reasoning behind it. - **Origin**: built in-house, purchased, or built on an external foundation model. It determines which information you can produce yourself and which you have to request from someone else, which translates directly into contract clauses. - **Vendor and model version**, where the system rests on third-party components. - **Date of last review**, the field most often missing and the first one anyone checks. On that last point it's worth being explicit about what it signals. If every row carries the same review date, the register describes an exercise done in bulk to prepare for something, not a living process. Dates that differ and spread across time say the opposite. ## Finding what you don't know you have Asking department heads which AI systems they use produces incomplete lists, and not out of reticence. Someone using a tool to work faster doesn't mentally file it as an AI system, they file it as how they do their job. Which is why five different sources beat a questionnaire. Expense reports and corporate card statements, searched against known vendor names, surface the individual subscriptions that never went through procurement. Identity provider logs show which applications people actually authenticated into, which is a fact rather than a self-declaration. A browser extension inventory across managed devices catches a category that almost always slips through. Re-reading SaaS contracts already in place surfaces the AI features a vendor switched on inside products you have had for years, often without any explicit decision on your side. And asking teams directly, framed as "what do you use to move faster" rather than "do you use AI tools", gets far more accurate answers. ## The vendor that changes the model without telling you A SaaS product can swap the underlying model between releases. The stated purpose stays the same, so does the interface, and the system's behaviour changes without anything in the inventory recording it. This is a risk you govern where it originates, which is the contract. The clauses we see working ask for three things: notice when the model changes or the system's behaviour is materially altered, access to the technical documentation needed to keep your own assessment current, and an explicit statement of the role the vendor takes on under the AI Act. Without those clauses the inventory stays accurate only until the first silent update. ## When a new row is needed A change of purpose always opens a new row, because it changes the risk classification and potentially the role assumed. A change of model version for the same purpose updates the existing row and triggers a review. A new department adopting the same system for the same purpose gets added to the existing row. A new department adopting it for a different purpose opens a new one. Decommissioned rows stay, with a date and a reason. A register with no history is a register someone rewrites each time instead of maintaining, and the difference shows immediately. ## Who keeps it current, and what triggers the update An inventory that depends on someone remembering to update it doesn't survive one quarter. The triggers that hold over time are the ones attached to processes that already exist and that nobody can skip. The first is procurement: every software purchase runs through a question checking for AI components, and a positive answer generates a row. The second is go-live: the release procedure updates the status of the matching system before deployment, not after. The third is a periodic review, quarterly for the most exposed organisations and half-yearly for everyone else, catching whatever slipped past the first two. Above those three triggers you need someone accountable for the register as a whole, separate from the owners of individual systems. Their job isn't filling in rows, it's noticing when rows stop being updated. ## Spreadsheet or platform Below twenty or thirty rows, a spreadsheet with version control and restricted write access works well and takes an afternoon to build. The point where a dedicated tool starts paying for itself is when you need change traceability, automatic links between the inventory, the risk register and the impact assessment, or when the number of owners involved makes manual coordination more expensive than the licence. Starting from the tool is the mistake we see most often at this stage. A platform populated with badly collected data produces the same problems a spreadsheet does, plus the cost of the licence and the false comfort of having solved something. ## Before building the next document Without a current inventory, the impact assessment covered in the previous piece ends up evaluating systems that may no longer exist, or missing others that have since gone live. The next piece in this series starts exactly here, with what changes when a system is designed knowing from day one that it will end up in this register, instead of discovering that fact after launch. --- # Vibecoding in production: regulatory scope, real risks and the checks to run before deploy URL: https://zerofive.ai/en/blog/compliance/vibecoding-production-cra-ai-act-controls Data: 2026-09-07 Abstract: CRA and AI Act scope for AI-generated apps, the structural problems of the method, and the eight checks to run before going to production. A young entrepreneur showed us his application in June, built in eleven days with a code generator and already used by four paying customers. It worked well. Asked which npm packages were inside it, he said he did not know, because the model had picked them. Asked who could read the users table, he opened the database console and found a permissive policy across every row, written by the generator on day two and never looked at again. Vibecoding has moved the bottleneck in software development from writing code to verifying it, and the jump from prototype to production, which used to take weeks of visible work, now happens without anyone noticing. This article sets out where applications generated with these tools actually sit inside the European regulatory perimeter, which structural problems the method introduces regardless of regulation, and which concrete checks belong on suppliers and on the team before anything goes in front of a real user. A glossary of the terms used follows at the end. ![Vibecoding Production Gate: Cyber Resilience Act scope triage and the eight checks before releasing to production](/vibecoding-production-gate-en.png) ## The scope of the Cyber Resilience Act The common assumption is that the Cyber Resilience Act catches any software. On the point that matters for most applications generated with these tools, the Commission's guidance says the opposite. On July 27, 2026 the Commission approved the application guidance required by Article 26 of the regulation, document reference C(2026) 5252, with the stated aim of making compliance easier for small and medium-sized enterprises. Its largest section deals precisely with scope. The criterion is where the software runs. Software that executes on the user's device, meaning a downloaded app, a browser extension, a locally installed client, is a product with digital elements. Software merely accessed remotely through a browser is not, on that basis alone, and web applications used only through a browser together with websites that merely present information are generally not products with digital elements. They fall in scope only where they qualify as remote data processing supporting a product's function. The draft guidance of March 3, 2026 had already confirmed explicitly that standalone SaaS falls outside scope. Cloud and SaaS come within scope only where the component qualifies as a remote data processing solution, which requires three conditions at once: that it processes data at a distance, that the product is unable to fulfil a core function without it, and that it was designed by or under the responsibility of the same manufacturer that designed the supported product. Only components satisfying all three legs fall within scope as remote data processing. Even where SaaS stays outside the Cyber Resilience Act, providing it in the Union can trigger the NIS2 Directive for the organisation. One further clarification matters to anyone working with public repositories: the regulation's definition of software covers both machine code and source code, but simply sharing open-source code on a public repository is generally not placing on the market. Translated into a triage table you can complete in half an hour: | What you put into production | Cyber Resilience Act | What applies anyway | |---|---|---| | Web app used through a browser only | out of scope | AI Act, GDPR, NIS2 if you are in scope | | Mobile app downloadable from a store | in scope, together with the backend that makes it work | everything else | | Desktop application, Electron, browser extension, CLI | in scope | everything else | | SaaS with an installable agent or distributed SDK | in scope, and the backend comes with the product | everything else | | Backend powering a customer's device | in scope as remote data processing | everything else | | Progressive web app installable on the device | grey area, document case by case | everything else | For the typical portfolio built with these tools most applications stay outside the Cyber Resilience Act, and the real exposure comes from other directions. The recurring exceptions are installable progressive web apps, applications published on app stores and any browser extension, categories these environments produce as easily as a web page. It is worth writing down the triage result and filing it with the reasoning, because the question will come from an enterprise customer long before it comes from an authority, and a documented answer is worth more than a correct answer improvised on the spot. ## Obligations that apply anyway Outside the Cyber Resilience Act does not mean outside everything. The four exposures below apply to an application generated in three days exactly as they apply to a product developed over three years. **AI Act transparency, applicable since August 2, 2026.** If the application exposes a chatbot, an assistant, a text or image generator, there is already an obligation to inform users that they are interacting with an artificial intelligence system, and to mark synthetic content in machine-readable form. It is the most likely exposure and the cheapest to fix, and almost no application built over a weekend covers it. **Literacy, applicable since February 2, 2025.** The obligation covers both those who develop and those who use artificial intelligence systems, and it is demonstrated through documented evidence. A team generating code with a model without being able to read what the model produces is exactly the case the provision means to cover, and training here is the condition for noticing an error rather than a formality. **High risk, applicable from December 2, 2027.** An application built in three days can be high-risk without anyone having decided so. Candidate screening, evaluation or task allocation for employees, scoring for access to credit or essential services, assessment in education. These are all Annex III cases and they are all among the first problems a young entrepreneur tries to solve with a generator, because they look like interface and database problems. Anyone in scope will need a risk management system, data governance, technical documentation, automatic event logging, human oversight and conformity assessment. **NIS2 and data protection.** Providing a service in the Union can bring the organisation into NIS2 scope based on sector and size, independently of the Cyber Resilience Act. Data protection law applies always, with one particularity: a database generated from prompts almost always carries a minimisation nobody designed, because the model adds columns when it needs them and never removes them. ## Where the method is weak These hold regardless of regulatory scope, because they are engineering problems before they are compliance problems. They are listed in the order we have met them in the field. **Nobody knows what is inside.** A software bill of materials presupposes that somebody chose the dependencies. In vibecoding the model chooses them, often reaching for packages by plausible name, and the transitive chain stays invisible to anyone who only wrote prompts. The risk of abandoned packages or of names built to resemble known libraries is not theoretical, and it is compounded by the fact that the generator has no way of knowing whether a package was compromised last week. Even staying outside the Cyber Resilience Act, the component list is the first thing a structured procurement function asks for during supplier qualification. **The generator's security default.** The most frequent class of error concerns row-level authorisation rules on managed databases, service keys ending up inside the bundle delivered to the browser, and serverless functions exposed without authentication. The generator produces code that works, and working is not the same as being protected. Anyone who does not know what a row-level security policy is cannot review one written by a model, and the model writes it permissive because that way the application starts on the first attempt. **The line between prototype and production evaporates.** This is the central point. In these environments the prototype is deployed to a public domain from the first minute, so the moment when somebody consciously decides to go to production is missing. The decision happens by accumulation, when the first real user arrives and nobody notices. Every control that follows depends on restoring that decision point. **There is no change traceability.** Without code review and without a change log nobody can answer the question of when a substantial modification was introduced, which is the test capable of reopening conformity assessment under the Cyber Resilience Act and technical documentation under the AI Act. Nobody can reconstruct which version was running when an incident occurred either, which is the first question in any post-event analysis. **Event logging and retention.** For high-risk systems the AI Act requires automatic logging and retention for a defined period. Generated applications almost always carry development-grade logging, verbose where it is not needed and absent where it would matter, with personal data landing in logs without anyone having decided so. **Regressions without a safety net.** A single prompt can rewrite a function nobody was watching. Without automated tests verification is visual, and visual verification does not cover authorisation, edge cases and error conditions. The speed of change that makes the method attractive is the same thing that makes silent regression likely. **The support period.** Anyone within Cyber Resilience Act scope must declare how long they will maintain the product, on a horizon that in principle does not fall below five years. An application generated by a single startup founder, on a platform that may change its underlying model twice a year, has a problem sustaining that promise before it has a compliance problem. **Who the manufacturer is.** If you place a product on the market under your own brand, the provider under the AI Act and the manufacturer under the Cyber Resilience Act is you. The platform on which you generated the code appears nowhere in that accountability chain. It works in the opposite direction too, and it bears directly on consulting work: if a prototyping unit delivers a prototype and the client puts it into production unchanged, the boundary of responsibility belongs in the contract before delivery. ## Reliance on three suppliers A typical vibecoded application rests simultaneously on three suppliers: the generation and hosting platform, the managed database, the model provider. Each with its own jurisdiction of corporate control, its own deprecation calendar and its own incident policy. The due diligence question asked about these three suppliers today is almost always about price and speed. The questions the European framework makes relevant are of a different nature, and the cybersecurity package presented by the Commission on January 20, 2026 makes them current even for very small projects, because it introduces the possibility of designating suppliers as high-risk with progressive phase-out obligations. The cost of exiting these three dependencies grows faster than a startup founder estimates, because the database schema, the serverless functions written for that platform, the prompts tuned to that model and the team's habits accumulate on top of the contract. Verifying real code portability before the third customer costs an afternoon, verifying it after the thirtieth costs a quarter. ## Supplier checks On the generation platform and the infrastructure, eight points to close in writing: - Real code portability and repository ownership, proven with an actual export rather than a documentation entry - Treatment of prompts and code, with explicit confirmation on use or non-use for training purposes - List of sub-processors and data residency, current rather than generically declared - Available certifications and independent assessments, with the date of the last offensive security test - Vulnerability disclosure channel and timelines, checking compatibility with a twenty-four hour window where the reporting obligation sits with you - Corporate control and jurisdiction, with future supply chain designation in mind - The supplier's position relative to NIS2, because a supplier already in scope has processes you can inherit rather than build - Incident and outage history, reconstructed independently rather than requested from the supplier For the model provider, add four specific checks: versioning policy and deprecation notice period, behaviour when the model is updated under the same commercial name, location of data processing, and contractual clauses on the use of inputs sent for inference. On each of these points the acceptable answer is a document or a clause. An answer given verbally on a sales call is worth nothing when it is actually needed. ## Skills and accountability in the team Team checks are fewer and harder to pass, because they touch competence and accountability instead of documents. **Named ownership.** You need one person, with a name, accountable for the application, who answers for reporting and documentation. Without this every other control stays theoretical, because what goes missing at the moment of an incident is somebody who decides. **Who can ship to production.** A second pair of eyes on release, even in a two person team. Vibecoding makes release so cheap that the barrier has to be reintroduced by hand. **Reading competence.** At least one person able to read generated code across three dimensions: authorisation, secret handling, input validation. If that competence does not exist internally it should be bought by the hour, and it costs less than one incident involving customer data. **Documented literacy.** The AI Act obligation is demonstrated through training records and content, not through the sense that the team is good. It needs a trail with dates, content and participants. **Owning the clock.** Who receives the security report on a Friday evening, through which channel, with which escalation procedure and which stand-in during holidays. Twenty-four hours does not allow the process to be built while the incident is unfolding. **Knowing the perimeter.** The team has to know whether the application it is building falls under Annex III, and that question belongs before the first prompt. Discovering it once the product is live means rebuilding the data architecture and the human oversight design. ## The pre-production gate Eight checks, all answerable in half a day, none of which requires a consultant to set up the first time. 1. **Written and filed scope triage.** Cyber Resilience Act yes or no, AI Act yes or no, Annex III yes or no, each answer with its reasoning and its date. 2. **Bill of materials generated and filed**, with a scan for known vulnerabilities in the components and a scheduled rescan date. 3. **Manual review of database authorisation rules**, table by table, with a negative test proving that an unauthorised user receives a refusal. 4. **No secrets in the client bundle**, verified by searching the production package rather than the source code. 5. **Transparency implemented** wherever a generative component is exposed to users, with marking of synthetic content. 6. **Structured event logging** with a defined retention period, an aligned privacy notice and a check that logs do not contain data they should not contain. 7. **Published security contact** and a written reporting procedure, with internal timings set backwards from twenty-four hours. 8. **Named owner** and boundary of responsibility with the client set out in writing, including the case of a delivered prototype. Anyone failing these eight points has a prototype. The distinction between prototype and product is a decision somebody has to take consciously, and in these environments it has to be reintroduced as a formal artefact because the technology removed it. ## The checklist The gate, the scope triage and the questions to put to suppliers and teams are collected in a three page document built to be completed rather than read. **What it is for.** Turning an implicit decision into a recorded one, with a date and a name next to it. Today the move into production happens by accumulation and nobody writes it down anywhere, so when the question arrives, from a customer running supplier qualification or from someone investigating an incident, there is nothing to show. The checklist produces that trail in half a day, and it is the same trail you need six months later, when nobody remembers why a choice was made that way. **How to use it.** The first page is completed once per application and revisited at every substantial modification: the scope triage establishes which regimes apply and why. The second page is used when selecting or renewing suppliers, and its rows work well as an attachment to a request for proposal. The eight point gate is walked at every release, and after the first time it takes an hour. **Who completes it.** The named owner of the application for the scope and ownership parts, whoever runs the release for the gate, whoever handles procurement for the supplier checks. In a two person team the three roles coincide, and that is fine, provided the name written down belongs to a person and not to a department. **What it is not.** It is not an attestation of conformity, it does not replace legal advice and it certifies nothing, because no document completed by the people who built the thing can do that job. It is a decision tool, and it serves to establish where you stand before opening a programme and spending a budget. **Licence and credits.** The document is released under a Creative Commons Attribution NonCommercial 4.0 licence. You may use, print, complete and adapt it inside your own organisation, including as a commercial company, and share it with colleagues, suppliers and clients. You may not resell it or include it in paid consulting, audit or training services delivered to third parties. Every reproduction or citation must carry the source, ZeroFive.AI, with a link to zerofive.ai where the format allows. For commercial use write to hello@zerofive.ai. [**Download the checklist as a three page PDF**](/vibecoding-production-checklist-zerofive.pdf) and keep it next to the repository, because the moment it is needed is the release, not the reading. ## Running the checks The gate checks become manageable once they translate into concrete operations. Those below can be run by anyone with access to the repository and the infrastructure console. **Bill of materials.** Generate it from the package manager in a standard format, file it with the date and the reference commit, and pass it to a scanner for known vulnerabilities. The first pass almost always produces a long list, and the useful work is separating findings on code that actually executes from findings on development dependencies. Pin versions instead of leaving open ranges, because an open range means the product in production changes without anyone releasing it. **Database authorisation.** List the tables, verify that row-level security is enabled on each, and read the condition of every policy. Any always-true condition needs rewriting. The check that counts comes afterwards: open a session as an ordinary user and try to read a row belonging to another user. Until you have seen a refusal with your own eyes, the policy is a hypothesis. **Secrets.** Search for your key strings inside the production package served to the browser, not inside the source code, because the build process can include variables you do not expect. Repeat the search across repository history, where a key removed three weeks ago remains readable. Keys that turn up must be rotated, and removal from the code does not substitute for rotation. **Exposed surface.** List the serverless functions and published endpoints, and for each verify which authentication control applies. The generator tends to create helper endpoints during development and not remove them, and those stay reachable. **Application logs.** Read one day of records and look for what should not be there: email addresses, user-submitted content, tokens. Define a retention period and enforce it, because indefinite retention is a difficult position to defend. **Regression.** Before a full test suite, write the three tests covering the most sensitive data operations in the application and run them at every release. Three tests that run beat thirty tests that are planned. ## The contractual boundary The accountability question deserves separate treatment, because it produces the most expensive damage and the most awkward conversations. Whoever places a product on the market under their own brand is the manufacturer for the Cyber Resilience Act and the provider for the AI Act, regardless of who physically produced the code. A generation platform does not enter that chain, and neither does the consultant who built the prototype, unless the contract says otherwise. When a prototype changes hands the contract should say at least four things. That the artefact is a prototype intended for validation rather than for serving real users. Which checks were performed and which were explicitly excluded, with the list. That moving to production requires further work, defined in scope and price. Who takes ownership from the moment of delivery, and from what date. This is not legal caution for its own sake. A prototype delivered without those four lines ends up in production in the large majority of cases, because it works and because putting it online costs nothing, and the first incident reopens the discussion about who said what months earlier. ## Glossary **Annex III to the AI Act.** The list of use cases that qualify a system as high-risk, including recruitment, worker management, access to essential services, biometrics and education. **Client bundle.** The code package the user's browser downloads and executes. Everything inside it is readable by anyone, including the keys that should not be there. **Transitive dependency chain.** The set of packages your project installs indirectly, because they are required by the packages you chose. In a modern project it easily exceeds a thousand items. **Software bill of materials, or SBOM.** A structured list of the software components in a product, including third party and open source dependencies. **Remote data processing.** The Cyber Resilience Act category that brings a cloud service into scope when it processes data at a distance, when the product does not work without it, and when it is designed by the same manufacturer as the product. **Manufacturer.** The party placing a product on the European market under its own name or brand and assuming commercial responsibility for it. It does not necessarily coincide with whoever wrote the code, nor with the platform that generated it. **Serverless function.** A fragment of code executed on managed infrastructure, typically exposed at a public address. Without authentication controls, anyone who knows the address can invoke it. **Substantial modification.** A change to a product already on the market sufficient to reopen conformity assessment. The Commission's July 2026 guidance devotes a section to defining its boundaries. **Support period.** The span during which the manufacturer commits to handling product vulnerabilities, declared to the user and in principle not shorter than five years. **Row-level security policy.** A rule determining which rows of a table a given user may read or write. A permissive policy makes the entire table accessible to anyone able to query the database. **Product with digital elements.** The Cyber Resilience Act category covering hardware and software with a direct or indirect connection to devices or networks, together with the associated remote data processing. **Progressive web app.** A web application that can be installed on a device and work partly offline. It is the most frequent grey area in scope triage. **Negative test.** A check confirming that a forbidden operation is actually refused. It is the test that is almost always missing, because nobody thinks to try what is not supposed to work. **Typosquatting.** Publishing packages with names similar to known libraries, so that they get installed by mistake or by automated suggestion. **Vibecoding.** Software development carried out by describing the desired outcome in natural language to a generative model, with verification based mainly on observed behaviour rather than on the code produced. ## In summary The speed these tools introduced is real and worth keeping. What disappeared is the moment when somebody decided a thing was ready, and that moment has to be rebuilt by hand, because no platform will hand it back. The eight gate checks cost half a day the first time and an hour at every subsequent release. An incident involving customer data costs the relationship with those customers, and that cost is not recovered through development speed. Anyone wanting to understand where their organisation stands on these controls before opening a compliance programme can write to hello@zerofive.ai or book a conversation at calendly.com/fabiolalli/zerofive. **Sources.** European Commission, guidance on the application of Regulation (EU) 2024/2847 approved on July 27, 2026, document C(2026) 5252, and draft interpretative guidance of March 3, 2026. Legislative texts cited: Cyber Resilience Act, Regulation (EU) 2024/2847; AI Act, Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744; NIS2, Directive (EU) 2022/2555. European Commission, cybersecurity package of January 20, 2026, proposals COM(2026) 11 and COM(2026) 13. --- # Cybersecurity Act 2, Cyber Resilience Act and AI Act: why December 2027 is a single deadline URL: https://zerofive.ai/en/blog/compliance/cybersecurity-act-2-cra-ai-act-december-2027 Data: 2026-09-06 Abstract: CRA reporting from September 11, 2026, AI Act high-risk from December 2, 2027, full CRA from December 11. Scope, impacts and operational sequence. A client wrote to us in August asking whether the Cyber Resilience Act applied to them, given that their product is a cloud management platform rather than a connected device. The answer took a forty minute phone call, because the question itself was the wrong one. That platform embeds a conversational assistant supplied by a third party, it ships under the company's own brand, and it serves a recruitment process. Three separate pieces of legislation touch it, and two of them come due nine days apart. Between September 11, 2026 and December 2027 the European framework on digital product security and artificial intelligence closes in on itself. Companies that build, integrate or purchase software with AI components face obligations that appear to belong to separate worlds and that in fact share documentation, evidence and accountability. This article sets out what was proposed on January 20, 2026, what becomes applicable now, who genuinely falls within scope, and which decisions are worth taking before signing the next supplier contract. At the end you will find a glossary of every acronym and technical term used, because in this field the barrier to entry is almost always a vocabulary problem. ![December 2027 convergence: CRA and AI Act calendar, the Article 12 bridge and the Cybersecurity Act 2 supply chain](/csa2-cra-ai-act-dicembre-2027-en.png) ## September 11, December 2, December 11 The first deadline has already arrived. From September 11, 2026 Article 14 of the Cyber Resilience Act becomes applicable, and manufacturers of products with digital elements placed on the European market must report actively exploited vulnerabilities and severe incidents within very tight windows. The second falls on December 2, 2027, when the AI Act obligations for Annex III high-risk systems apply, following the calendar rewritten by Regulation (EU) 2026/1744, published in the Official Journal on July 24, 2026 and in force from the third day after publication. The third comes on December 11, 2027, with the full application of the Cyber Resilience Act and of the essential cybersecurity requirements in its Annex I. Nine days separate the two full deadlines. For a company that develops or integrates software with artificial intelligence components aimed at the European market, this means one preparation window and one budget, even where internal governance currently treats the two subjects as separate tracks with two owners who never speak to each other. ## What happened on January 20, 2026 That day the European Commission presented a cybersecurity package made up of two connected legislative proposals. The first replaces the 2019 Cybersecurity Act with a new Cybersecurity Act 2, the second amends the NIS2 Directive in targeted fashion and aligns it with the first. The reference text for the first proposal is COM(2026) 11, covering the European Union Agency for Cybersecurity, the European cybersecurity certification framework and ICT supply chain security, and repealing Regulation (EU) 2019/881. The second text is COM(2026) 13, a proposed directive on simplification measures and alignment with the Cybersecurity Act. The Commission describes the main proposal through four building blocks: a horizontal framework for ICT supply chain security that also addresses strategic dependency and foreign interference risks, a simplified and strengthened European certification framework, simplification measures connected to the implementation of NIS2, and a reinforced mandate for the agency. On the agency's role the proposal goes well beyond fine tuning. ENISA would be empowered to issue early alerts on threats and incidents, to manage EU level threat and incident repositories, to operate a unified incident notification platform, to support organisations in responding to and recovering from ransomware attacks, and to contribute to the development of certification schemes. This is the shift from a coordination body to Europe's operational cybersecurity centre, with everything that implies for expectations around response speed. ## The part that changes procurement The supply chain block deserves attention from anyone who buys technology, not only from those who build it, and this is precisely why the subject belongs inside artificial intelligence governance. The proposal moves outside cybersecurity as traditionally understood in EU law. It would have significant consequences for eighteen critical sectors and their ICT suppliers, with broad implications for international trade and for relationships with trading partners. This is the first time the Union has used a binding instrument to impose trade restrictions grounded in geopolitical and national security concerns, with effects on the technology supply chains of critical sectors. The mechanism works as follows. The Commission would be empowered to designate third countries as raising cybersecurity concerns and to classify suppliers controlled by those countries as high-risk. Such a designation would trigger automatic exclusion from EU funding, standardisation and public procurement, and could impose phase-out obligations requiring entities across all critical sectors to remove equipment that was acquired entirely lawfully. The Commission would be able to specify the phase-out periods for each type of component: for mobile networks, by way of example, those periods shall not exceed thirty-six months from publication of the high-risk supplier list, under Article 110(3) of the proposal. On penalties the proposed structure is tiered, with a ceiling of 1 per cent of total worldwide annual turnover for certain disclosure-related violations, 2 per cent for other instances of non-compliance, and 7 per cent for the most serious infringements. One clarification is missing from most commentary and is worth holding firmly in board discussions. Cybersecurity Act 2 is a proposal under negotiation, not law in force. The text is moving through the ordinary legislative procedure, with negotiations in Parliament and Council expected throughout 2026, and once adopted it will apply directly in every Member State, while for the supply chain rules it will be the Commission's implementing acts that set sector specific transition periods. The path has already met resistance. In its Progress Report of May 22, 2026 the Council of the European Union flagged concerns about the proposed framework and asked for greater clarity on the methodology and procedures for identifying high-risk suppliers, as well as on the scope and likely impact of the measures. Anyone planning today should therefore treat this part as a directional signal rather than an imminent obligation, while keeping in mind that purchasing decisions taken over the next eighteen months will produce their effects inside that framework. ## The obligation that starts on September 11 Unlike the January package, the Cyber Resilience Act is already law in force. The regulation entered into force on December 10, 2024 and follows a staggered application calendar. A first section has been operational since June 11, 2026, namely Chapter IV with Articles 35 to 51, governing the authorities and bodies responsible for conformity control. The second section arrives now. The reporting cascade is the part that changes daily work for engineering teams. For an actively exploited vulnerability the manufacturer must send an early warning within twenty-four hours of becoming aware of it, followed by a full notification within seventy-two hours containing the available information on the vulnerability and on corrective measures, and by a final report within fourteen days of a corrective or mitigating measure becoming available. For a severe incident affecting product security the opening sequence is identical, while the final report is due within one month of the seventy-two hour notification. The channel is single and centralised. Communications pass through the Single Reporting Platform operated by ENISA, with one submission from the manufacturer addressed to the CSIRT designated as coordinator and, save in exceptional circumstances, made simultaneously available to the European agency. In Italy the competent national CSIRT operates within the National Cybersecurity Agency. The reporting obligation also applies to products made available on the market before December 11, 2027, and this provision widens the scope of a great many product portfolios. The installed base is not excluded, so the notification process must also cover versions the company considered to be in maintenance or even at end of commercial life. On July 27, 2026 the Commission published implementing guidance annexed to Communication C(2026) 5252, a non-binding document organised in nine sections with practical examples and use cases, clarifying scope of application, treatment of free and open source software, the definition of substantial modification and the reporting obligations. The guidance devotes explicit attention to micro and small enterprises, suggesting simplified self-assessment routes without reducing the substance of the obligations, because anyone selling a connected product on the European market has to comply regardless of company size. It is worth recalling how broad the objective scope is, because the word product leads people astray. The regulation applies to a very wide range of internet connected devices and software, including routers, modems, smart home products, connected toys, watches and other wearables, operating systems, firewalls, VPNs, browsers and antivirus software. Commercially distributed software falls within scope with no associated hardware at all, and a language model packaged inside a software product placed on the European market falls within scope together with the product containing it. ## Who is actually in scope The first question companies ask is almost always about scope, and the answer depends on how the product reaches the market far more than on how much code was written in-house. The first profile is the company that places a product on the market under its own brand, which makes it the manufacturer for the purposes of the regulation. It needs a working detection and notification process from September 2026, a software bill of materials, an assessment of the distance from the essential requirements in Annex I and, by December 2027, completed technical documentation and conformity assessment. Accountability does not transfer upstream by contract, however much the contract is the instrument through which necessary information is obtained in time. The second profile covers companies that integrate third party components. A company embedding a model, a library or an external service inside its own product and placing it on the market takes on manufacturer responsibility for that product. The critical contractual point becomes upstream notification, because if the component supplier discovers an actively exploited vulnerability and informs the customer five days later, the twenty-four hour window burned out long ago. Accelerated notification clauses in software supply contracts therefore move from legal refinement to operational requirement. The third profile is the company that buys and uses, formally outside manufacturer obligations and substantially exposed on three different fronts. As a deployer under the AI Act, where it uses high-risk systems. As a NIS2 entity, where it operates in a sector within the directive's scope. As a purchaser, in the event that one of its suppliers were designated high-risk under the future Cybersecurity Act 2 framework. This third profile covers the majority of European mid-market companies and is today the one that perceives itself as least involved. ## Where artificial intelligence enters So far the discussion belongs to product security. The next step turns the subject into a matter of artificial intelligence governance, and it runs through a bridging provision that almost nobody is using. Article 12 of the Cyber Resilience Act provides that, without prejudice to the accuracy and robustness requirements in Article 15 of the AI Act, products with digital elements falling within the scope of the regulation and classified as high-risk AI systems under Article 6 of the AI Act shall be deemed to comply with the cybersecurity requirements of Article 15 of the AI Act where they fulfil the essential requirements set out in Part I of Annex I, where the processes put in place by the manufacturer comply with the essential requirements in Part II of Annex I, and where the achievement of the required level of protection is demonstrated in the declaration of conformity issued under the regulation itself. The same provision also simplifies matters on the bodies side, because notified bodies competent to control the conformity of high-risk systems under the AI Act are also competent to control the conformity of those same systems with the requirements of Annex I to the Cyber Resilience Act, provided their compliance with the requirements of Article 39 has been assessed within the notification procedure under the AI Act. A second bridge runs through the certification framework. Article 42 of the AI Act provides that an artificial intelligence system which has obtained a relevant cybersecurity certification under the Cybersecurity Act may be presumed to comply with certain cybersecurity requirements of the AI Act, which opens a route to reusing evidence already produced. The operational meaning of these two provisions is straightforward and widely underused. Evidence produced for the cyber regime counts as evidence for the artificial intelligence regime, provided the documentation perimeter is designed with that goal from the outset. Building two separate dossiers means paying twice for the same work, obtaining the same result twice, and additionally risking technical statements that diverge between one file and the other, with everything that follows when an auditor arrives. ## Article 15 of the AI Act, read in full The text is technical but worth quoting, because it defines the playing field for anyone building systems intended for high-risk uses. High-risk systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness and cybersecurity, and perform consistently in those respects throughout their lifecycle. They shall also be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities. The vulnerabilities contemplated are specific to artificial intelligence, and this is the point at which the subject departs from traditional information security. Technical solutions shall include, where appropriate, measures to prevent, detect, respond to, resolve and control attacks attempting to manipulate the training data set, the pre-trained components used in training, inputs designed to cause the model to make a mistake, alongside confidentiality attacks and model flaws. In technical shorthand this covers data poisoning, model poisoning, adversarial examples and model evasion, and these are categories that traditional corporate security teams almost never own. For teams working on agent architectures the perimeter widens further. A system that plans, invokes external tools and takes actions brings inside the compliance boundary the authentication between agents, the permissions attached to each tool call, and the logging that allows anyone to reconstruct after the fact what happened and on what basis. In a multi-agent architecture every component performing a high-risk function in the chain is within scope, not only the one producing the final decision. ## The AI Act calendar after the Digital Omnibus The deferral of summer 2026 moved the deadlines without cancelling the obligations, and the distinction is anything but formal. Regulation (EU) 2026/1744 deferred the application of the high-risk provisions. Standalone systems falling under Annex III must meet the requirements from December 2, 2027, while high-risk systems embedded in products already subject to the Union harmonisation legislation listed in Annex I, Section A, have until August 2, 2028. Everything the deferral does not touch remains fully applicable from August 2, 2026, including the Article 5 prohibitions and the Article 50 transparency obligations. The deferral should be read for what it is. The dates are fixed and are not conditional on the availability of harmonised standards, because the conditional mechanism initially proposed by the Commission was dropped during negotiations. Anyone who had planned compliance around August 2, 2026 therefore has additional time rather than an open-ended suspension. There is also a change of counterpart that almost always goes unnoticed and is worth checking inside corporate groups. A deployer belonging to the same undertaking as the provider comes under the exclusive supervision of the AI Office from August 2, 2026. For a group that develops internally and distributes to its own subsidiaries the competent authority changes, and with it the counterparts, the timelines and the form of documentation to be kept ready. ## The supply chain as an artificial intelligence risk In our AI Rating model the risk dimension covers compliance, ethics, bias, security and privacy. The 2026 package introduces a variable we have so far weighted lightly, namely supplier sustainability over time. Almost no European company trains models, they buy them, and the due diligence questions asked today about a supplier concern accuracy, cost per token, latency and data residency. The questions the proposed framework makes relevant are of a different nature: who controls the supplier at corporate level, from which jurisdiction, with which upstream infrastructure dependencies, and what would happen to the service if that supplier ended up on a high-risk list with a phase-out obligation running to a defined number of months. For a company that has just built a core process on a third party conversational assistant this becomes a question of operational continuity before it becomes one of formal compliance. The cost of exiting an artificial intelligence dependency grows with adoption time, and it grows faster than procurement plans tend to assume, because prompts, integrations, historical data and working habits accumulate on top of the contract. Three indicators therefore enter the risk assessment naturally, with no need to change the four dimension structure of the model: demonstrated ability to notify within twenty-four hours, existence and maintenance of a software bill of materials, and mapping of exposure to suppliers that could be designated. ## NIS2 and the rest of the picture The proposed amendment to the NIS2 Directive works on simplification rather than expansion, which makes it less visible than it deserves. The targeted amendments proposed on January 20, 2026 aim to increase legal clarity, simplifying compliance with EU rules and risk management requirements for companies operating in the Union, with a benefit the Commission estimates across 28,700 companies, including 6,200 micro and small enterprises. The package promises clearer scope boundaries, simplified jurisdictional rules, more effective cross-border supervisory tools and a unified approach to collecting data on ransomware attacks, while encouraging the use of European certification schemes as a fast route to demonstrating compliance. On timing it is best not to be optimistic. Adoption is expected in late 2026 or, more realistically, in 2027, after which Member States will have twelve months to transpose, and only then will the Commission set out the detailed technical and sector specific requirements. The subjective scope widens at specific points, because the proposal extends the digital infrastructure sector to include providers of European Digital Identity Wallets and European Business Wallets, alongside operators of submarine data transmission infrastructure. A new intermediate size category also appears, that of small mid-caps, designated as important rather than essential entities and therefore subject to a lighter supervisory and penalty regime. One element passed almost unnoticed and deserves a permanent place in the multi-year plan of anyone running infrastructure. The new Article 7(2)(k) would require every Member State to adopt, within its national cybersecurity strategy, policies for the transition to post-quantum cryptography, aligned with timelines and requirements already set out in EU legal acts and policy documents. This is the moment quantum risk stops being a conference topic and becomes a budget line. ## Impacts, area by area On product and engineering the software bill of materials stops being good practice and becomes expected documentation. Substantial modifications to a product already on the market reopen conformity assessment, and the July guidance devotes space precisely to defining when a modification should be considered substantial. The release cycle therefore has to be designed around the support window declared to users. For procurement and legal, existing software contracts need rereading on at least two points: the supplier's obligation to notify within timeframes compatible with twenty-four hours, and the right to obtain the bill of materials for supplied components. Neither is standard in contracts signed before 2025, and realistic renegotiation happens at renewal. On security and operations you need an identified and genuinely reachable point of contact, a triage procedure that distinguishes an actively exploited vulnerability from a merely known one, and registration on the reporting platform. Twenty-four hours does not allow the process to be built while the incident is unfolding, all the more so if the event lands on a Friday evening or during a company shutdown. For the board and the risk committee, exposure has to be represented on a single map with a single deadline. Taking two separate roadmaps to the board, one for cyber and one for artificial intelligence, produces two uncoordinated budget decisions on a problem that requires one. On the financial side, compliance cost should be estimated net of overlaps. The presumptions of conformity in Article 12 of the Cyber Resilience Act and Article 42 of the AI Act represent, in practical terms, a concrete saving, provided documentation is set up once and with both regimes in mind. ## The operational sequence The first move concerns the notification process and its deadline has already passed. It requires a named owner, an internal assessment flow for reports, and access to the European platform. It is the one obligation whose date went by while you were reading. The second move, to be closed by the end of 2026, is the inventory. It requires two lists that almost no company holds in current form: products with digital elements placed on the market, including those predating full application, and artificial intelligence systems in use or in development, each with supplier, jurisdiction of corporate control and criticality of the process served. The third move, which fits in the first quarter of 2027, is the joint gap assessment. A single analysis covering the essential requirements of Annex I to the Cyber Resilience Act and the requirements of Chapter III of the AI Act, with explicit mapping of the evidence reusable across both regimes. Two separate exercises cost more and produce documentary contradictions that are hard to explain. The fourth move occupies 2027 and concerns conformity proper: product classification, choice of the applicable procedure, involvement of a notified body where required, technical documentation and declaration of conformity. Running alongside all of this is the contractual review, with the right clauses from first signature on new suppliers and progressive renegotiation on existing ones. ## Three recurring mistakes The first is looking only at 2027. The September 2026 deadline does not require product conformity but a working process, and companies that skip it reach 2027 without the organisational precondition everything else rests on. The second is separating information security from artificial intelligence governance. These are two regulatory directions with an explicit legal bridge, and treating them as independent projects means producing the same evidence twice while giving up the presumptions of conformity the legislator created precisely to avoid that. The third is delegating to the supplier. Accountability for placing a product on the market under your own brand does not shift upstream by contract, and the contract serves to obtain information in useful time rather than to transfer the obligation. ## Glossary of terms used **ACN, National Cybersecurity Agency.** The Italian authority competent for cybersecurity. It hosts CSIRT Italia, the recipient of Cyber Resilience Act notifications for Italian entities. **AI Act.** Regulation (EU) 2024/1689 on artificial intelligence. It classifies systems by risk level and imposes differentiated obligations on providers and deployers. **AI Office.** The European AI Office, a Commission body with supervisory and coordination tasks over the application of the AI Act, particularly for general purpose models. **Annex I to the Cyber Resilience Act.** The list of essential cybersecurity requirements, split into Part I on product requirements and Part II on the manufacturer's vulnerability handling processes. **Annex III to the AI Act.** The list of use cases that qualify a system as high-risk, including recruitment, worker management, access to essential services, biometrics and education. **Annexes III and IV to the Cyber Resilience Act.** Lists of products defined as important and critical, subject to stricter conformity assessment procedures than the ordinary regime. **COM followed by year and number.** The identifier of a European Commission document. COM(2026) 11 is the Cybersecurity Act 2 proposal, COM(2026) 13 the proposed NIS2 amendment. **CER.** Directive (EU) 2022/2557 on the resilience of critical entities, complementary to NIS2 on the physical security side. **CRA, Cyber Resilience Act.** Regulation (EU) 2024/2847 on cybersecurity requirements for products with digital elements. **CSA, Cybersecurity Act.** Regulation (EU) 2019/881, establishing the ENISA mandate and the European certification framework. Cybersecurity Act 2 is the proposal intended to replace it. **CSIRT.** The national computer security incident response team, designated to receive and handle reports of incidents and vulnerabilities. **Data poisoning.** Deliberate manipulation of training data in order to alter a model's behaviour. It is among the vulnerabilities cited in Article 15 of the AI Act. **Declaration of conformity.** The document by which a manufacturer attests under its own responsibility that a product meets the applicable requirements. It is where the bridge between the Cyber Resilience Act and the AI Act becomes concrete. **Deployer.** In AI Act language, the party using an artificial intelligence system under its own authority in a professional capacity. Distinct from the provider, which develops and places on the market. **Digital Omnibus.** The European digital law simplification package. On the artificial intelligence side it produced Regulation (EU) 2026/1744, which amended the AI Act calendar. **DORA.** Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. **ECCF.** The European Cybersecurity Certification Framework established by the Cybersecurity Act, currently based on voluntary participation. **ENISA.** The European Union Agency for Cybersecurity. It operates the single reporting platform and the European vulnerability database. **Implementing act and delegated act.** Instruments through which the Commission specifies the technical detail of a regulation after adoption. Many operational aspects of Cybersecurity Act 2 are deferred to these acts. **ISO/IEC 42001.** The international standard for artificial intelligence management systems, certifiable by accredited bodies. Useful as a documentation structure, though distinct from statutory obligations. **Manufacturer.** The party placing a product on the European market under its own name or brand and assuming commercial responsibility for it. It does not necessarily coincide with whoever wrote the code. **NIS2.** Directive (EU) 2022/2555 on the security of network and information systems. It imposes risk management measures and reporting obligations on essential and important entities in designated sectors. **Notified body.** A third party authorised by a Member State to carry out conformity assessments. Chapter IV of the Cyber Resilience Act governs their notification and has applied since June 11, 2026. **Ordinary legislative procedure.** The process through which the European Parliament and Council jointly adopt an act proposed by the Commission. It includes the informal negotiation phase known as trilogue. **PQC, post-quantum cryptography.** Cryptographic algorithms designed to withstand attacks carried out with quantum computers. The proposed NIS2 amendment names them expressly. **Presumption of conformity.** The mechanism by which meeting a requirement in one regulatory regime causes the corresponding requirement in another regime to be considered satisfied. It is the core of Article 12 of the Cyber Resilience Act. **Product with digital elements.** The Cyber Resilience Act category covering hardware and software with a direct or indirect connection to devices or networks. **SBOM, software bill of materials.** A structured list of the software components in a product, including third party and open source dependencies. **Small mid-cap.** An intermediate size category between SME and large enterprise, introduced in the proposed NIS2 amendment with a lighter regime. **SRP, Single Reporting Platform.** The single platform operated by ENISA to receive the reports required by the Cyber Resilience Act, with automatic forwarding to the CSIRTs concerned. **Actively exploited vulnerability.** A security flaw for which there is evidence of ongoing exploitation by a malicious actor. It is the condition that triggers the twenty-four hour alert obligation. ## The decision point The December 2027 convergence makes visible something that has been true for a while. Artificial intelligence governance in a company runs through the technology supply chain at least as much as it runs through models, and an organisation that does not know which systems it uses, who supplies them and from which jurisdiction holds none of the minimum inputs needed to estimate its exposure on either side. Measurement precedes decision. Before opening a compliance programme it is worth knowing where the organisation actually stands: which systems are in use, which documentation already exists, which evidence is reusable across the two regimes, which suppliers represent a critical dependency and what exiting them would cost. For a structured assessment of maturity and regulatory exposure write to hello@zerofive.ai or book a conversation at calendly.com/fabiolalli/zerofive. **Sources.** European Commission, proposals COM(2026) 11 and COM(2026) 13 of January 20, 2026, and Communication C(2026) 5252 of July 27, 2026. Legislative texts cited: Cyber Resilience Act, Regulation (EU) 2024/2847; AI Act, Regulation (EU) 2024/1689; Digital Omnibus on artificial intelligence, Regulation (EU) 2026/1744 published in the Official Journal on July 24, 2026. Council of the European Union, Progress Report of May 22, 2026. Italian National Cybersecurity Agency, September 2026 communication. --- # AI system impact assessment: DPIA, the AI Act, and ISO/IEC 42001 compared URL: https://zerofive.ai/en/blog/compliance/ai-impact-assessment-dpia-ai-act-iso-42001 Data: 2026-09-03 Abstract: DPIA, AI Act conformity assessment, and ISO 42001 impact assessment: what each actually evaluates, and how to avoid running three separate ones. In a recent assessment we ran into three different documents, produced by three different consultants, all answering the same question: is this AI system risky? None of the three knew the other two existed, and none of them actually covered the full risk perimeter. ## Three assessments, three different purposes The DPIA comes from the GDPR and looks at personal data: what gets collected, on what legal basis, with what impact on the individual. The AI Act conformity assessment looks at classifying the system by risk tier, and the obligations that follow if it lands in Annex III. The AI system impact assessment required by ISO/IEC 42001 covers an even wider perimeter: not just data, not just regulatory classification, but the overall impact on people, the organization, and society, including impact that never touches privacy and never falls into the AI Act's high-risk categories. An internal recommendation system that processes no sensitive personal data might not need a DPIA, might sit outside the AI Act's critical categories, and can still need an ISO 42001 impact assessment, because it shapes decisions affecting real people. ## Where they overlap (and where they don't) - **Data perimeter**: covered by all three, but the DPIA goes deep on it while the other two treat it as just one risk dimension among several - **Risk classification**: almost exclusively an AI Act concern, ISO 42001 references it as an input without replacing it - **Impact on groups that can't be individually identified**: bias across categories of people, systemic effects, ground the DPIA doesn't cover and ISO 42001 addresses explicitly - **Governance and accountability**: who approved it, who answers for it, present in all three but often with different owners, a privacy officer for the DPIA, a risk owner for the AI Act, a process owner for ISO 42001 The overlap itself matters less than the real risk it creates: three different offices producing three parallel assessments that never talk to each other, each one convinced it has covered the whole problem. ## One process, three lenses Organizations that handle this well don't write three separate documents, they build a single assessment process with modular sections: a shared part that gathers the facts about the system, what data it uses, what decisions it automates, who's involved, then three lenses applied to those same facts. A company with a mature DPIA practice has already done eighty percent of the work, it just needs to add the missing questions. ## Who talks to whom, before the system ships A unified process on its own isn't enough if privacy, risk, and AI governance keep working in separate rooms: more than shared templates, what matters is who talks to whom before the system goes into production, not after someone has already signed off on the launch. This, not the mechanics of the assessment itself, is usually where organizations lose weeks to avoidable rework. ## Before writing the first assessment Anyone starting this work does well to begin with one shared document rather than three separate modules, and to bring in whoever already runs the DPIAs instead of starting from zero. The next piece in this series covers the natural next step: the AI system inventory, the foundation without which no impact assessment really knows what it's evaluating. --- # EU AI Act: a complete guide to obligations, liability and data URL: https://zerofive.ai/en/blog/compliance/eu-ai-act-complete-guide-obligations-liability-data Data: 2026-09-02 Abstract: EU AI Act compliance explained: risk classes, provider and deployer duties, data rights, penalties and a phased plan for enterprises. The EU AI Act is not a technical standard for specialists. It is the framework that decides which artificial intelligence systems a company can place on the market or use in Europe, under which controls, and with which chain of accountability. This guide brings together in one place the definitions, the risk classification, the obligations by role, the treatment of data and people's rights, the application calendar and the penalties. It is written for the people who make decisions: executive management, legal, compliance, data protection, IT and the business owners of AI projects. ## 1. What the AI Act is and who it applies to Regulation (EU) 2024/1689 is the world's first horizontal legal framework on artificial intelligence. It does not regulate one specific technology: it regulates how AI systems are placed on the market, put into service and used, applying obligations proportionate to the risk they create for health, safety and fundamental rights. **Definition of an AI system.** A machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. Inference is the discriminating element: software applying deterministic rules written by a person falls outside the scope, a model that learns relationships from data does not. **General purpose AI models (GPAI).** Large generative models have their own chapter, with obligations covering technical documentation, information provided downstream, a copyright compliance policy and a public summary of training data. Models presenting systemic risk add adversarial evaluation, risk mitigation, serious incident tracking and reinforced cybersecurity. **Extraterritorial scope.** The regulation applies to providers established outside the Union when the output of the system is used within the Union. An Italian or UK-based company integrating a model developed in the United States does not transfer the risk to the provider: it takes on its own obligations as a deployer and, in certain cases, becomes a provider itself. **What stays outside.** Systems used exclusively for military, defence or national security purposes; research and development activity before market placement; strictly personal non-professional use; components released under free and open source licences, unless they fall into prohibited or high-risk categories. **Relationship with the Digital Omnibus.** The simplification package recalibrated timing and some requirements, but it did not change the architecture: prohibitions, risk classification, high-risk obligations and the GPAI regime remain the core of the law. We covered the detail in our analysis of the [Digital Omnibus](/en/blog/compliance/digital-omnibus-regulation-2026-1744) and in the note on [what became binding on 2 August 2026](/en/blog/compliance/ai-act-august-2-2026-what-is-binding). ## 2. The four risk classes Classification is the first operational exercise. Without it, every subsequent assessment is arbitrary. | Class | Business examples | Consequence | |---|---|---| | Unacceptable risk | Social scoring, emotion recognition in the workplace, manipulative techniques, untargeted scraping of facial images to build biometric databases | Outright prohibition, already applicable | | High risk | Candidate screening and selection, performance evaluation and promotion, credit scoring, life and health insurance pricing and underwriting, safety components of regulated products, systems used in education, essential services and justice | Full conformity regime, conformity assessment, CE marking, registration | | Limited risk | Customer-facing chatbots, synthetic content generation, deepfakes, systems interacting with natural persons | Transparency and content marking obligations | | Minimal risk | Spam filters, internal logistics optimisation, non-determinative product suggestions | No specific obligations, voluntary codes of conduct | Two clarifications account for most classification errors. First: a system listed as high risk can be derogated if it performs a narrow procedural task, improves the result of a human activity already completed, only detects deviations from decision patterns without replacing human assessment, or performs a preparatory task. The derogation must be documented, not presumed, and it falls away whenever the system performs profiling of natural persons. Second: the class depends on the intended purpose, not on the technology. The same language model is limited risk in an informational chatbot and high risk when it filters CVs. Classification belongs in an AI system inventory, with owner, purpose, data processed, company role and risk class. It is the starting point of our [AI Assessment](/en/servizi/ai-assessment) and the base on which we build the [AI Rating](/en/servizi/ai-rating). ## 3. Roles and accountability along the chain The AI Act distributes obligations across five roles. A company can hold more than one at the same time, for different systems or even for the same system in different markets. | Role | Who it is | Main obligations | |---|---|---| | Provider | Develops the system, or has it developed, and places it on the market under its own name or trademark | Quality and risk management system, technical documentation, conformity assessment, CE marking, registration in the EU database, post-market monitoring, serious incident reporting | | Deployer | Uses the system under its own authority in a professional activity | Use in line with instructions, human oversight by competent staff, control over input data quality where applicable, log retention, information to workers and affected persons, fundamental rights impact assessment where required | | Importer | Places on the EU market a system from a non-EU provider | Conformity verification, documentation, traceability, cooperation with authorities | | Distributor | Makes the system available on the market without being provider or importer | Verification of marking and documentation, suspension of distribution when non-conformity is found | | Authorised representative | Entity in the Union appointed by a non-EU provider | Custody of documentation, interface with authorities | **When a deployer becomes a provider.** This is the most underestimated scenario and the most frequent in companies that adopt AI without developing it. You become a provider when you put your own name or trademark on a high-risk system already placed on the market, when you substantially modify a high-risk system already in use, or when you change the purpose of a system so that it becomes high risk. A concrete example: a general purpose model embedded in a candidate evaluation flow and re-exposed internally as the company's HR tool turns the deployer into a provider, with the full obligation set that follows. On this point governance matters more than technology: you need an internal rule stating who authorises integrations and modifications, and on the basis of what review. That is the work we do in the [AI Governance](/en/ai-governance) track and in defining the [AI Strategy](/en/servizi/ai-strategy). ## 4. Operational obligations for high-risk systems For systems in the high class, the regulation requires a permanent compliance system, not a one-off exercise. **Risk management system.** An iterative process covering the entire lifecycle: identification of reasonably foreseeable risks to health, safety and fundamental rights, estimation of risks under intended use and foreseeable misuse, adoption of mitigation measures, testing against metrics and thresholds defined in advance. **Data governance.** Training, validation and testing datasets must be relevant, sufficiently representative and, to the extent possible, free of errors and complete for their purpose. Possible biases affecting health, safety and rights must be examined, with detection and correction measures. This is the chapter that connects the AI Act directly to the data work covered in [AI Data](/en/servizi/ai-data). **Technical documentation and automatic logging.** Documentation must demonstrate conformity before market placement and stay current. Systems must automatically record events across the lifecycle, with logs kept for a period appropriate to the purpose and in any case no shorter than six months unless otherwise provided. **Transparency towards the deployer.** Clear instructions for use, covering characteristics, capabilities, performance limitations, expected accuracy levels, conditions that may create risk, the human oversight measures foreseen and the expected lifetime. **Human oversight.** The system must be designed so that a person can understand its capabilities and limits, correctly interpret its output, decide not to use it, disregard the result or interrupt operation. Human oversight is not a signature at the end of an already formed output: if the person supervising lacks the time, the information and the authority to disagree, the obligation is not met. **Accuracy, robustness and cybersecurity.** Adequate and consistent levels across the lifecycle, with resilience against errors, faults, inconsistencies and attempts to manipulate data or the model, including data poisoning and adversarial attacks. **Conformity assessment and CE marking.** Depending on the case, internal control or the involvement of a notified body, followed by the EU declaration of conformity, CE marking and registration in the European database. **Post-market monitoring.** Systematic collection and analysis of real-world performance data, with an obligation to report serious incidents to the authorities within tight deadlines. ## 5. Data and people's rights The AI Act does not replace the GDPR: it overlaps with it. Every system processing personal data must satisfy both regimes, and in practice this is where disputes and internal challenges concentrate. **Legal basis and minimisation.** Before any technical assessment you need a valid legal basis for training, for fine tuning and for inference, with distinct and documented purposes. Reusing data collected to deliver a service in order to train a model is a change of purpose that must be justified, not a natural continuation. **Automated decisions.** Article 22 GDPR restricts solely automated decisions producing legal effects or similarly significantly affecting a person. Adding a formal reviewer is not enough: meaningful human involvement is required. We examined this in the article on [GDPR Article 22 and automated decisions inside the enterprise](/en/blog/compliance/gdpr-article-22-automated-decisions-enterprise). **DPIA and fundamental rights impact assessment.** The DPIA remains a GDPR obligation when processing presents high risk. The FRIA is the AI Act obligation for certain deployers of high-risk systems, in particular public bodies and entities providing essential public services, plus specific cases in credit and insurance. They are distinct instruments with largely shared evidence: design them as one file with two views, not as two parallel exercises. **Transparency towards people.** People interacting with an AI system must be told, unless it is obvious from the context. Synthetic content must be marked in a machine-readable format. Deepfakes and text published to inform the public on matters of public interest require explicit disclosure. In the workplace, workers and their representatives must be informed before a high-risk system is put into service. **Right to explanation.** A person subject to a decision taken by a high-risk system producing legal effects or significantly affecting them has the right to obtain from the deployer clear and meaningful explanations of the role of the system in the decision and of the main elements behind it. Translated into a technical requirement: you need decision-level logs, versioning of the model and rules, and an explanation understandable without statistical jargon. **Data inside models and data subject rights.** Erasure, rectification and objection must be handled even when the data has flowed into training. The workable routes are upstream filtering, separation between a retrievable knowledge base and model weights, and the architectural choice of document retrieval over fine tuning when personal data is involved. ## 6. AI literacy and cross-cutting obligations The literacy obligation applies to all providers and deployers, regardless of the risk class of the systems in use: staff dealing with the operation and use of AI systems must have a sufficient level of competence, taking into account the context and the people affected. It is not a one-off course but a programme proportionate to the role: those who select vendors, those who supervise outputs and those who design processes have different training needs. That is exactly the logic of our [AI Training](/en/servizi/ai-training) tracks and of the [corporate courses and workshops](/en/corsi). ## 7. Penalties and calendar | Infringement | Cap | |---|---| | Prohibited practices | EUR 35 million or 7% of total worldwide annual turnover | | Breach of high-risk, transparency or GPAI obligations | EUR 15 million or 3% of turnover | | Incorrect, incomplete or misleading information to authorities | EUR 7.5 million or 1% of turnover | The higher of fixed amount and percentage applies, with reduced thresholds for SMEs. The calendar is staggered: prohibitions and literacy obligations already apply, the GPAI regime entered into force in the second phase, high-risk obligations follow on differentiated timelines between systems listed in the annexes and those that are safety components of already regulated products. In Italy there is an additional national layer, with Law 132/2025 and the extension of corporate administrative liability through [the new Article 25-vicies of Legislative Decree 231/2001](/en/blog/compliance/italy-decree-231-article-25-vicies-ai): a profile that moves the topic from the compliance budget to the board agenda. ## 8. From the law to internal governance Compliance is not achieved with a document: it is achieved with a management system that produces evidence repeatably. ISO/IEC 42001 is today the most effective instrument for that, because it provides the organisational structure (policy, roles, objectives, controls, internal audits, management review) on which the AI Act requirements can rest. The detailed comparison between the two is in our [guide to AI governance frameworks](/en/blog/ai-governance/ai-governance-framework-guide-iso-42001-eu-ai-act). The minimum elements of a governance setup that survives an inspection are five: an AI policy approved at the top, a system inventory with reasoned classification, an authorisation process for new use cases with explicit gates, logs and documentation retained per system, and a periodic review cycle with named owners. Everything else is implementation detail. If you want to measure the distance from that point, start with our [AI compliance](/en/compliance-ai) track. ## 9. A phased operating plan **First phase, inventory and classification.** A census of every AI system in use, including those bought as features inside third-party software and those introduced by individual teams without authorisation. For each: purpose, company role, data processed, risk class, owner. The output is the AI system inventory and a priority list. **Second phase, gap analysis and decisions.** Comparison between applicable obligations and existing evidence, system by system. Explicit decisions on what to retire, what to bring into conformity, what to renegotiate with vendors. This is where the AI policy is written and the authorisation process is defined. **Third phase, remediation and proof.** Closing priority gaps, activating logging, formalising human oversight, launching the AI literacy programme, testing the process on a real case. How long each phase takes depends on the number of systems in use, the maturity of existing processes and the availability of evidence: what matters is the sequence, not the calendar. By the end you must be able to answer three questions with documents in hand: which systems we use, who is accountable for them, how we demonstrate they are under control. On the adoption side the principle is symmetrical: no system reaches production without validation. That is the logic of the [AI Adoption](/en/ai-adoption) path, of fast validation with [PROTOT.AI](/en/protot-ai) and of running [AI agents](/en/servizi/ai-agents) in production. ## 10. Frequently asked questions **Does the AI Act apply if we only use third-party tools?** Yes. Anyone using an AI system in a professional activity is a deployer and has their own obligations, which cannot be contracted away to the provider. **Is an internal chatbot high risk?** Usually not, if it answers questions and does not contribute to decisions about people. It becomes high risk when it enters recruitment, evaluation, access to essential services or credit processes. **Is adding a human reviewer enough to leave the high-risk class?** No. Human oversight is a requirement for high-risk systems, not an exit from the classification. Derogation is possible only in the typified cases and must be documented. **What is the difference between a DPIA and a FRIA?** The DPIA covers data protection risks and is a GDPR obligation. The FRIA covers the impact on fundamental rights and is an AI Act obligation for certain deployers of high-risk systems. They share most of the underlying evidence. **If we modify a purchased model, do we become providers?** If the modification is substantial on a high-risk system, or if it changes the purpose so that the system becomes high risk, yes. Applying your own trademark has the same effect. **How long does it take to become compliant?** For a company with a few non-critical systems, a structured quarter is enough to close the framework. For portfolios with high-risk systems, timing depends on the conformity assessment and on the documentation already available. **Do SMEs get a lighter regime?** They are not exempt, but they benefit from reduced penalty caps, simplified documentation in some cases and priority access to national regulatory sandboxes. ## The next step The organisations that handle the AI Act well are not the ones that read more articles of the regulation: they are the ones that turn the text into an inventory, an authorisation process and a set of maintained evidence. It is a governance job, not a paperwork job. If you want to understand where your company stands against this picture, the fastest route is a thirty-minute conversation or an [AI Rating](/en/servizi/ai-rating), our structured assessment of maturity and regulatory exposure. From there you build a plan that holds compliance and the ability to put AI into production together. --- # The minimum documentation of an AIMS: what ISO/IEC 42001 actually requires URL: https://zerofive.ai/en/blog/compliance/aims-minimum-documentation-iso-42001 Data: 2026-09-01 Abstract: The documents ISO/IEC 42001 actually requires for an AI Management System: what's needed, what isn't, and the right order to build them. In the AI maturity assessments we run, the scene repeats itself almost identically: a shared folder full of PDFs, a policy written a year ago and never opened again, a few presentation slides passed off as a procedure. The company believes it already has the documentation for an AI management system. What it actually has is scattered fragments of one. ## The starting misconception The first misunderstanding about [ISO/IEC 42001](/en/blog/compliance/iso-42001-ai-management-system) concerns what an audit actually looks for: the volume of pages produced matters less than people assume, what an auditor checks is whether those documents are actually used to decide something. A risk register last updated before the project even launched is useless to anyone, least of all to someone asking to see the latest revision and its date. Documentation, inside an AI Management System, works more as decision infrastructure than as proof of compliance: it lets an organization choose with solid grounds, and account for that choice when someone questions it later, why that model was picked, who assessed the risk, what happens if the system stops behaving as expected. ## The documents the standard actually requires Strip away the noise and the minimum core comes down to a handful of connected families, more than a flat list. - **AI policy and objectives**, the starting point that fixes what the organization means by responsible AI use and against which measurable targets - **Roles and responsibilities**, who owns each AI system, who answers for it, who approves exceptions - **Risk assessment and treatment**, the procedure that classifies every system before it goes into production - **AI risk register**, kept alive, not a document closed at project sign-off - **AI system inventory**, an updated list of what the organization uses, builds, or buys, with its lifecycle status - **Operating procedures**, how a live system is monitored, how an incident is handled, how a model gets updated - **Training plan**, ground worth its own piece, since people's competence is itself an auditable requirement - **Management review records**, proof that the system gets reviewed periodically by whoever has the authority to decide, not just maintained by whoever wrote it Eight families of connected documents, not eighty scattered files in a shared drive. ## The treatise nobody needs to write Many companies start out convinced they need to produce a treatise, and stall before they begin. What's needed is a system sized to the actual scale and risk of the AI systems in use, not an encyclopedic manual built for a multinational running a hundred use cases in production when the real count is three. Organizations that already run a certified management system, ISO 27001 for information security or ISO 9001 for quality, start ahead. The harmonized structure ISO/IEC 42001 shares with those standards lets a company reuse context analysis, document control, and management review instead of duplicating everything from zero. The risk register can become an extension of the one that already exists, not a parallel system nobody looks at after the first month. ## Sequence matters more than content The most common mistake is about order rather than technique: procedures get written before context and objectives are defined, or an AI system inventory gets built months after those systems are already in production, documenting after the fact what should have been decided beforehand. An AIMS assembled this way looks more like a retroactive justification than a management system. The right sequence starts with context, who the interested parties are and what they expect from how the organization uses AI, then moves to policy, risk assessment, inventory, and finally operating controls. Each step leans on the one before it. Skipping one to reach the certificate faster produces a fragile system, one that holds up on paper and gives way at the first real check. ## Before starting Anyone tasked with putting order into this starting point does well to pause before writing the first document, and ask what the organization actually knows about itself: how many AI systems it really runs, at what risk, at what maturity. That's the same ground covered by AI Assessment, mapping before formalizing, because a document written without that map stays paper with a date on it, not a management system under ISO/IEC 42001. The question we'll pick up in the next piece of this series is the AI system inventory itself: how it's built, what it actually needs to contain, and why almost no company has one that's actually current when it says it does. --- # Where to Restart With AI in September 2026 URL: https://zerofive.ai/en/blog/strategy/where-to-restart-ai-september-2026 Data: 2026-08-31 Abstract: Digital Omnibus settled, Italy's 231 decree incoming. Three questions to answer before the year-end AI budget, and why measuring comes before spending. Every September, Italian boards return to the same ritual: review what's been spent in the first eight months, discuss what's left of the budget, set priorities for the last four. For AI, this year, that ritual lands at a particular moment. The 2026 regulatory calendar has just stopped moving, after months of delays and corrections, and for the first time in a while companies have a window stable enough to plan properly, instead of chasing the latest amendment. Worth being precise about what's actually settled, because more than one shortcut is circulating in conversations this week. Since August 2nd, the AI Act's Article 50 transparency obligations are binding, penalties are enforceable, and national supervision sits with ACN and AgID under Law 132/2025. The high-risk obligations for Annex III systems, on the other hand, have been pushed by the Digital Omnibus to December 2, 2027, and those for Annex I product-embedded systems to August 2028. The new prohibitions on non-consensual intimate imagery and AI-generated child sexual abuse material take effect December 2, 2026. In Italy, completing the picture, there is the decree given final approval on August 4th that adds artificial intelligence to the predicate offenses under Legislative Decree 231/2001, still awaiting publication in the Official Gazette. ## Sixteen months is not an excuse to wait The temptation, faced with deadlines pushed out to 2027, is to read them as time gained and not to be used yet. That's the wrong read. Sixteen months is exactly the amount of time it takes to build calmly what, done under pressure right before a deadline, always ends up worse and always costs more: a register of AI systems in use, a risk assessment process for every new use case, governance that doesn't depend on one person's memory but on a written, repeatable method. The companies that arrive at December 2027 ready won't be the ones who waited until November 2027 to start. They'll be the ones who used the remaining months of 2026 to measure where they actually stand, before deciding where to invest in 2027. ## Measure before you allocate, not after This is where it connects to what we've written over the past few weeks on cost and adoption: companies that blow past their AI budget almost always do it because they scaled a project without first checking whether the organization could sustain it, and the 71% who started without reaching structured governance shares the same root cause, the absence of an honest starting picture. Our AI Rating exists to answer exactly this, before any decision on budget or roadmap. It measures maturity across four dimensions, readiness, how prepared the organization is on data, skills and strategy, delivery, whether technical processes hold up in production and not just in a prototype, risk, how well governance covers compliance and ethics, confidence, how much the board and users actually trust what's been built. The result is a score from zero to five and a class from A to D, with critical gates that can't be compensated for: excellence in three areas out of four isn't enough to cover a serious gap in the fourth. ## Three questions before closing the September budget Before allocating the AI budget for the last quarter, three questions separate decisions made on evidence from decisions made out of habit. Which AI systems are already in use across the company, mapped with an owner and a risk level, not just the ones formally approved. Which use case, among those underway or proposed, has a success criterion written down before it started, rather than estimated after the fact once it's too late to stop. And if a regulator or a board asked today for an account of the company's AI governance, would the answer come from a verifiable document or from a shared feeling in a meeting room. Whoever answers all three with confidence has likely already done the work described in this article, and is ready to talk about scale rather than foundations. Whoever hesitates on even one has just found the place to restart in September, before looking at the rest of the budget. ## The advantage of measuring before everyone else A structured rating also produces a ninety-day roadmap, with priorities ordered by impact and risk, not a generic list of recommendations. It's what lets a board arrive at December with a concrete plan for 2027, instead of the feeling of having chased the previous year one month at a time. Organizations that choose to measure before investing in September arrive at the new year with an advantage that isn't visible right away but matters a great deal over time: they know where the money is going, and why. --- # 71% Started, 9% Arrived: What Happens in Between URL: https://zerofive.ai/en/blog/ai-governance/adoption-gap-71-9-percent Data: 2026-08-28 Abstract: 71% of large enterprises have active AI projects, only 9% have structured governance. Shadow AI, risk gates, and what separates companies that close the gap. 71% of large Italian companies have active AI projects, only 9% have reached structured governance (Osservatorio Artificial Intelligence, Politecnico di Milano, February 2026). The gap between those two numbers doesn't describe companies running late. It describes companies that started, in many cases started well, and stalled somewhere in the middle, where AI produces activity without yet producing a system. Italy's national statistics office tells the same story from another angle: in 2024, 8.2% of Italian enterprises had adopted AI technologies, against a European average of 13.5%. This isn't a problem of curiosity or available budget, Italy invests, experiments, launches pilots across every sector. It's a problem of what happens after the first project, when the enthusiasm of getting started meets the absence of a method for governing what comes next. ## Employee AI arrives before the policies meant to cover it An analysis published in May describes a pattern we see with striking regularity in our own assessments: the AI tools employees use every day move faster than the policies meant to govern them. People looking for a faster way to write a report, summarize a contract, or prepare a deck find it in a tool the company has never evaluated, often without the company even knowing. The case cited most often is still Samsung in 2023: employees, trying to speed up their own work, uploaded proprietary source code into a public chatbot, with no intention of causing harm, simply because the tool worked and nobody had said no. Three years later the scenario has multiplied rather than shrunk, more tools available, more employees used to working outside the corporate perimeter, and a gap between informal adoption and formal governance that in many organizations looks exactly the same as before. ## The 71% measures initiative, the 9% measures control The two Osservatorio numbers aren't in tension, they measure different things. The 71% counts anyone who has started something, a pilot, a project in one department, an agreement with a vendor. The 9% counts those who know, with verifiable evidence rather than the feeling of having done it, where those systems are in use, who owns them, what risks they carry and how often they get checked. In our AI Rating this distance almost always maps to a precise pattern: strong scores on Readiness and Confidence, because the company is eager to innovate and management believes in it, and a weak score on Risk, the dimension that measures compliance, risk management, and the existence of a register of AI systems in use. It's a critical gate, non-compensable, technical excellence elsewhere doesn't offset it. A company that innovates with enthusiasm but can't list its own AI systems stays stuck in class C, regardless of how advanced it looks on paper. ## What separates the companies that close the gap Organizations that move from the 71% to the 9%, that turn scattered initiative into real governance, share one specific move: they stop treating every AI project as a case of its own and build a single register, one place where every system in use gets mapped with the same level of detail, who activated it, what data it touches, what risk level it carries under the AI Act's classification, who is accountable if something goes wrong. This step doesn't necessarily require more budget. It requires an organizational decision, often taken at board level, that AI stops being managed department by department and becomes a single chapter of corporate governance, with a named owner and a periodic review process. Companies that get there earlier do so because they measured their actual situation instead of assuming it, and measurement, almost always, is the first step that's missing. ## The risk of staying in the middle Staying in the 71% without moving toward the 9% isn't a neutral position, it's a risk that compounds over time. Every month that passes without a register of AI systems in use adds to the number of unmapped tools, and with Italy's decree adding artificial intelligence to the predicate offenses under Legislative Decree 231/2001 nearing final publication, the distance between informal adoption and an adequate organizational model stops being a matter of efficiency and becomes a matter of legal exposure for the company itself. The question worth asking before the gap widens further is easy to phrase and uncomfortable to answer honestly: if a regulator, a board, or a court asked today for the complete list of AI systems in use, with risk level and owner attached, would that list already exist, or would it have to be built from scratch in a hurry. --- # Why AI Budgets Blow Up (And It's Not the Tokens) URL: https://zerofive.ai/en/blog/strategy/ai-cost-nobody-budgeted-for Data: 2026-08-27 Abstract: Usage-based billing, headcount traded for tokens, PoCs scaled without measuring first. Why AI costs escape the budget, and how to see them coming with an AI Rating. In mid-July, a Forrester report picked up by The Register put in writing something several companies already suspected: software bills are set to grow next year, and AI will be the main reason why. Anthropic, OpenAI and GitHub have already moved to usage-based billing, Microsoft has launched a premium license, and the implicit message to enterprise customers is the same everywhere, the infrastructure that runs the models has a cost, and that cost has to land somewhere. The report adds a line that reads almost like an aside, and it matters more than the rest: success on an AI investment depends on how well a company has built the right foundations, more than on how much it has spent on AI narrowly defined. Those foundations are, in a company that has never measured its own maturity, exactly what tends to be missing. ## Usage-based billing changes who controls the budget As long as AI was bought on a license, cost was predictable: one number a year, negotiated once, revisited at renewal. Consumption billing works differently. It grows with usage, with context length, with the number of calls a process generates without anyone counting them one by one. An agent running around the clock, calling a model at every step of a workflow, repeating a search because the first attempt missed the answer, produces a spend curve the CFO only sees once the invoice arrives. This is not a technical problem to leave to IT. It is a governance problem around consumption, one that needs thresholds, alerts and clear ownership of who authorizes what, the same way a company treats any other variable cost line. The optimization techniques exist and are well documented, from prompt caching to right-sizing the model for each task, to targeted retrieval that avoids reloading unnecessary context on every call. They remain optimization techniques, not decisions: they tell you how to spend less on a use case already chosen, not whether that use case made sense in the first place. ## The trade of people for tokens that isn't paying off A second thread of news, from the same weeks, tells another side of the same problem. Several companies, including well-known names like Klarna, Uber and Walmart, have shifted budget from headcount to tokens, cutting roles to fund AI adoption. The early data coming out of those choices, though, doesn't show the expected return: customer satisfaction down in some cases, processes that still require human oversight, savings on paper that get consumed by rework and correction. The problem isn't AI itself, it's the sequence. Cutting first and measuring later reverses the order that makes an investment defensible. Our AI Rating measures maturity across four dimensions, Readiness, Delivery, Risk, Confidence, precisely because a company can have a technically sound use case and still lose money, if it lacks the organizational capacity to run it at scale. A model that performs well in the lab and poorly in production is almost always telling you a skipped assessment, more than a technology limit. ## Where the cost actually originates In our assessments, the question "how much does AI cost" almost always arrives too late, once the project has already been decided and the cost to justify is the one already incurred, not the one still avoidable. The question that actually saves money comes earlier: this use case, with this data, in this organization, where will it generate value and where will it just generate consumption. A recurring pattern: a company automates a customer service process with a conversational agent, measures a drop in first-response time and presents it as a success. Six months later, operating costs have doubled because of repeated calls on ambiguous cases the agent can't close on its own, and the staff meant to be freed up gets reassigned to checking responses before they reach the customer. The cost didn't appear out of nowhere. It was predictable from month one, if someone had measured the escalation rate before scaling the project across every channel. ## What changes when you measure first Companies that come to us already at AI Rating class B or above have these conversations differently. They know which processes have data clean enough to support an autonomous agent, which still need oversight, which risk gates block scaling regardless of how promising the use case looks. Cost, at that point, gets discussed by component, build cost, run cost, governance cost, and each one is estimated up front, not reconstructed later from the invoice. The reverse holds too. A company in class D or C that invests at scale anyway risks paying twice, once for the project that doesn't hold up, and again to rebuild it properly once the failure mode is understood. It's the pattern we see most often in projects that end up with us after starting somewhere else: the budget wasn't the problem, the sequence was. With 2027 budgets under discussion over the coming months, the useful question isn't how much to allocate to AI. It's whether the organization already knows, with evidence rather than impressions, where that budget will produce measurable value and where it will just produce a bigger bill in December. --- # AI Rating in manufacturing: high automation, unusable data URL: https://zerofive.ai/en/blog/strategy/ai-rating-manufacturing-data-and-product Data: 2026-08-26 Abstract: Sensors everywhere and unusable data. The plant-product separation gate and why 2028 already shapes today's designs. **In short.** In manufacturing the AI maturity profile carries a weakness that surprises technologically advanced companies: low Readiness through data quality, not infrastructure. A plant full of sensors can hold unusable data, because it was collected for process control rather than analysis. The recurring gate, though, is another one, and concerns the missing separation between plant systems and product-bound systems. Manufacturers come to the rating expecting a high score on the technical dimension, because they have invested in automation for years. The result surprises them, because the model measures the governability of AI systems rather than the level of automation. ## The four dimensions in manufacturing **Readiness** measures preparation, data, skills, infrastructure. It is the dimension with the widest gap between perception and reality. The data exists in enormous quantities, and is often unusable for AI because it was collected with process control logic, at inadequate granularity and retention. **Delivery** measures the ability to reach production and maintain. In a factory it is limited by the fact that systems arrive inside machines, and the software lifecycle follows the machine's, which runs in years. **Risk** measures governance, compliance and ethics. It is exposed on two separate fronts: systems that measure people, almost never classified, and product-bound systems, where the distant deadline has produced deferral. **Confidence** measures management commitment and user trust. In manufacturing it is often high in management and low on the shop floor, and that gap matters, because a system operators don't trust gets worked around. ## The gate: plant and product mixed together The recurring constraint is the absence of a formal separation between systems that stay inside the company and those that end up in products sold. While that separation is missing, the inventory can't determine the role, and without the role the obligations can't be assigned. A company can have orderly governance over plant systems and no awareness that on one product line it is already a provider under the regulation. The finding isn't about missing controls. It's about the impossibility of knowing which controls are needed, which is a different and prior problem. ## When the data seems to be there and isn't enough In manufacturing assessments the Readiness dimension falls on one specific point. A company states it holds ten years of maintenance history, and verification reveals that failure causes are free-text fields filled in differently from shift to shift, or that process data is retained in aggregate form because the control system never historised it. The problem concerns structure more than volume, and technology doesn't solve it. It has to be tackled first, because it conditions every subsequent project. ## What a class means in practice | Class | Typical situation in manufacturing | What's reasonable to do | |---|---|---| | D | AI systems inside machines, no mapping, unstructured data | Map the systems and verify the quality of historical data | | C | Inventory in place, no separation of product and plant | Separate the two paths and assign the roles | | B | Separation done, plant systems governed | Start the conformity path for products embedding AI | | A | Mature system verified across all dimensions | Reserved for verified assessments, not self-assessments | The jump from C to B is the one manufacturers defer most often, because the Annex I deadline is distant. It's also the one shaping products already in design today. ## Why measure before designing the next product The useful moment for an assessment in manufacturing isn't the start of the financial year, it's the start of the development cycle for a new product line. An AI system embedded in a product subject to harmonisation legislation requires technical documentation, risk management and conformity assessment, and all of that is designed alongside the product. Adding it afterwards means reopening architectural choices already made, at a cost nobody planned for. A company starting development today on a product aimed at 2028 is already deciding, without knowing it, what conformity will cost. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), built separating plant systems from product-bound ones from the very first entry. The full model, with the four dimensions and the gate logic, is on the [AI Rating](/en/services/ai-rating) page. The sector's regulatory picture is on the [AI governance for manufacturing](/en/sectors/manufacturing) page. For an assessment of your company's position you can [book a meeting](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # AI, Regulation, and Certification: 11 Articles on ISO/IEC 42001 URL: https://zerofive.ai/en/blog/insights/editorial-plan-september-iso-42001 Data: 2026-08-25 Abstract: From August 27 to September 30, two more pieces on cost and adoption, then the full ISO/IEC 42001 series. Full calendar and newsletter signup. Over the next few days we're publishing three articles on cost, on adoption, and on where to restart with AI in September. The thread connecting them leads straight to a very practical question, one we hear in almost every assessment: once you've decided to close the gap between initiative and governance, what do you actually do with it, on a Monday morning. The answer we give most often is ISO/IEC 42001, the international standard for AI management systems. It isn't a document to read once and file away, it's an operating method, with precise clauses on documentation, competence, risk assessment, audit. Starting Tuesday, September 1st, we're publishing eleven articles that walk through it one piece at a time, from the first document you need to write to the certification itself. ## The sequence isn't arbitrary The first block covers the foundations: what documents an AI management system actually requires, how to build an inventory of the systems in use, how to run an impact assessment that ties DPIA and the AI Act together instead of duplicating the work twice, what to prepare before writing a single line of code if the goal is an ISO-ready system from the design stage onward. The second block moves to people. Clause 7 on competence, explained without the standard's jargon, a matrix that says who needs training and on what, where the AI literacy required by the AI Act ends and the competence required by ISO 42001 begins, the mistakes that make a training plan fail an audit, why the mandatory course alone isn't enough. The third block closes on certification: the map of Accredia-accredited bodies in Italy, and the real difference between becoming a Lead Implementer, a Lead Auditor, or getting the whole organization certified. ## Why now The regulatory calendar just settled, we wrote about that last week, and boards are closing out the budget for the last quarter. This is the moment when the question shifts from whether to invest in AI governance to which method to use, and ISO 42001 remains the most concrete reference available today, because unlike the AI Act it doesn't just describe what to avoid, it describes what to build. ## The full calendar One article every two or three days, through September 30th. Each piece is meant to stand on its own, useful even if you only read the one you need right now. | Date | Article | |---|---| | Aug 27 | Why AI Budgets Blow Up (And It's Not the Tokens) | | Aug 28 | 71% Started, 9% Arrived: What Happens in Between | | Aug 31 | Where to Restart With AI in September 2026 | | Sep 1 | The Minimum Documentation of an AIMS | | Sep 3 | Impact Assessment: DPIA, the AI Act, and ISO/IEC 42001 Compared | | Sep 8 | The AI System Inventory | | Sep 10 | Designing an ISO-Ready AI System | | Sep 15 | ISO/IEC 42001 Clause 7, Explained Without Jargon | | Sep 17 | Who Needs Training and on What: A Roles-Competence Matrix | | Sep 18 | AI Literacy and ISO 42001 Competence | | Sep 22 | The Mistakes That Make an AI Training Plan Fail an Audit | | Sep 23 | The Mandatory AI Course Isn't Enough | | Sep 24 | ISO/IEC 42001 Certification in Italy: the Accredia Map | | Sep 29 | Lead Implementer vs Lead Auditor vs Organizational Certification | If you'd rather not check the blog every couple of days, you can subscribe to the newsletter. --- **Don't miss the next release.** [Subscribe to the ZeroFive newsletter](https://zerofive.ai/en/papers): one email per article published, nothing else in between. --- # GDPR Article 22 and automated decisions inside the enterprise URL: https://zerofive.ai/en/blog/compliance/gdpr-article-22-automated-decisions-enterprise Data: 2026-08-24 Abstract: Uber's EUR 825m fine shows what Article 22 requires. How to inventory automated flows and where the upstream stop point belongs. On 21 August 2026 the Autoriteit Persoonsgegevens, the Dutch data protection authority, fined Uber EUR 824,990,000. It is the second largest fine ever issued under the GDPR. The case concerns a system that deactivated driver accounts through a fully automated process, with no person reviewing the case before the block took effect. The conduct under scrutiny spans 2018 to 2022. Uber has appealed, arguing that most suspensions are short, that no permanent deactivation happens without human review, and that drivers can appeal. Uber's defence is the most useful part of the case for anyone assessing their own exposure. A human review and an appeal channel existed, and they were not enough. ## What the regulator found The legal basis is Article 22 of the GDPR, which prohibits subjecting a person to a decision based solely on automated processing where that decision produces legal effects or similarly significantly affects them. On top of this sit the information and transparency duties of Articles 12 to 15, for failing to adequately explain how the decision-making process worked. Monique Verdier, deputy chair of the authority, summarised the principle by saying that a computer should not make decisions on its own that carry major consequences for a person, and that those decisions should have been reviewed by a human being first. The two words that matter are "on its own" and "first". Whether the algorithm performs well is not the question. Whether a remedy exists after the fact is not the question either. What the regulator measures is whether, at the moment the decision takes effect, a person with the power to stop it was involved. ## The actual scope of the problem The case comes from ride hailing, which leads many companies to file it away as a platform and gig-work matter. That reading is expensive, because the sanctioned pattern is among the most common in the operational systems of entirely conventional businesses. Examples we encounter regularly in our assessments: - **Automatic supplier suspension** from a procurement portal once a scoring, delay or documentation-compliance threshold is crossed - **Automatic credit blocking** for a customer when a system-calculated risk parameter is reached - **Automatic rejection of applications** at the screening stage, with filters or scores applied before any human reading - **Automatic downgrading** of a reseller or agent from one commercial tier to another, affecting commissions and terms - **Automatic revocation of access or permissions** for a worker based on usage metrics or system flags - **Automatic denial of claims or requests** in insurance, healthcare and warranty workflows In nearly every case we have seen, these flows were never designed as automated decisions. They started as efficiency rules inside an ERP, a CRM or a portal, they were configured years ago by a vendor who is no longer around, and no one ever recorded them as processing relevant under Article 22. ## How this interlocks with the AI Act Since 2 August 2026 the European Commission, through the AI Office and together with national authorities, has begun enforcing the AI Act ([what is actually binding from that date](/en/blog/compliance/ai-act-august-2-2026-what-is-binding)), and the transparency obligations of Article 50 became applicable, carrying fines of up to EUR 15 million or 3% of total worldwide annual turnover. Nineteen days later, the first substantial European penalty over an algorithmic decision affecting work did not come from the AI Act. It came from the GDPR. That tells two things to anyone allocating a compliance budget over the next six months. First, the apparatus with immediate operational capacity is the data protection one, with staffed authorities, eight years of practice and settled case law behind it. Second, there is the question of sequence. Annex III of the AI Act classifies as high risk the systems used for recruitment, selection, promotion, termination and task allocation, but those obligations are not applicable yet: the Digital Omnibus moved them to 2 December 2027. Reading that as a reprieve is a mistake. Article 22 already covers much of the same ground today, with an authority that enforces and a ceiling the Uber case has just demonstrated. A company that inventories its automated flows now for the GDPR is building the register it will need in 2027 for the AI Act, with seventeen months of headroom rather than against a deadline. Doing the same work twice, with two separate working groups and two separate vendors, is the most expensive sequencing error we are seeing right now. ## The automated decision inventory In the 05 Framework this activity belongs to the ASSESS phase, before any use case is selected. The reason is practical: a company that does not know which automated decisions it already runs in production cannot assess the risk of the ones it is about to add. The inventory starts from five questions, applied to every flow where a system produces an outcome affecting a natural person. 1. **What outcome does the system produce, and for whom.** An employee, a contractor, a candidate, an individual customer, a sole trader. Legal entities fall outside Article 22, but the same flow often hits both and no one has separated the two cases. 2. **Does the outcome have significant effects.** Loss of income, exclusion from an opportunity, termination of a relationship, restriction of access, worsening of commercial terms. 3. **Is there a stop point upstream.** Not a complaints channel, not a later review: a person with the authority and the actual time to block the outcome before it takes effect. 4. **Does that person have what they need to decide.** An operator who sees only a score and a confirm button is not human oversight, it is a signature. The Dutch authority assessed the substance of the involvement, not its formal existence. 5. **Does the affected person know the decision is automated**, and have they been given an understandable explanation of the logic applied. Anyone answering no to the third or fourth question on a flow that cleared the first two has found an exposure, whether or not an AI model sits anywhere in that flow. ## Human in the loop as an architecture requirement The most common outcome of this inventory is a decision to write a policy. It is the wrong answer, and the Uber case shows why: a procedure that calls for human review offers no protection if the system can still produce the outcome without waiting for it. The control belongs in the flow, not in the document. Concretely, this means the system must not be able to close the operation until an authorisation has been recorded, that the authorisation must be logged with identity and timestamp, and that whoever authorises must see the case and not only the score. This is an architecture decision, and it belongs in the ARCHITECT phase alongside the rest of the design, not bolted on during ACTIVATE once the system is already live. In our experience, adding an authorisation point to a flow already in production costs three to six times what it costs to design it in from the start. ## Where to start A structured Italian company typically has between fifteen and forty flows worth checking, spread across ERP, CRM, supplier portals, HR systems and customer service platforms. The inventory takes two to four weeks of work and produces three outputs: the map of the flows, a risk classification for each, and a prioritised list of the authorisation points to introduce. The same inventory then serves as the basis for classification under Annex III of the AI Act once those obligations apply in December 2027, with no need to rebuild it from scratch. --- **Sources** - [Autoriteit Persoonsgegevens, press release of 21 August 2026](https://autoriteitpersoonsgegevens.nl/en/current/uber-fined-nearly-825-million-euros-for-automated-driver-blocking) - [European Commission, start of AI Act enforcement, 2 August 2026](https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1714) - [Cooley, Article 50 transparency obligations in force from 2 August 2026](https://www.cooley.com/news/insight/2026/2026-08-03-eu-ai-act-transparency-obligations-take-effect-2-august-2026) - [TechCrunch, Uber's position and appeal, 23 August 2026](https://techcrunch.com/2026/08/23/uber-faces-fine-of-nearly-1b-over-automated-driver-suspensions/) --- # AI adoption in manufacturing: plant or product, the choice that comes first URL: https://zerofive.ai/en/blog/strategy/ai-adoption-manufacturing-plant-or-product Data: 2026-08-21 Abstract: The same model changes regime by destination. The candidate map, the data history check, and why a pilot doesn't replicate itself. **In short.** In manufacturing the choice of a first use case turns on a separation that precedes every other assessment: whether the system stays in the plant or ends up inside a product that gets sold. In the first case the company is a deployer and the path is short; in the second it becomes a provider under the regulation and the path runs through product conformity assessment. Starting from the plant lets you learn before taking on product obligations, which is why it pays, beyond caution. In a factory the AI conversation almost always starts from predictive maintenance and quality control, and this time the instinct is right. The problem comes later, when the same technology gets proposed for the product without anyone noticing the change of regime. ## A separation that comes before everything A computer vision model checking parts on the line is a system the company uses for itself. The same model, embedded in a machine the company sells to a customer, becomes a system the company places on the market, with everything that follows in documentation and liability. Everything changes. The first carries user obligations. The second carries provider obligations, with technical documentation, conformity assessment and liability towards the buyer. The technology is identical, the regime isn't. This separation has to happen before building the portfolio, because it determines timing, cost and the competence required. A company discovering it mid-project ends up with a product in development and no preparation on the conformity path. ## The map of candidate use cases | Use case | Value | Regulatory friction | Suitable as first | |---|---|---|---| | Predictive maintenance on plant | High, in downtime avoided | Low | Yes | | Visual quality control, not safety-related | High, in scrap reduction | Low | Yes | | Scheduling and energy optimisation | Medium-high | Low | Yes | | Documentation assistant for maintenance staff | Medium, in time | Low | Yes | | Control with a safety function | High | High, changes class | No, not as a first | | AI embedded in products sold | Strategically the highest | High, Annex I | No, needs a dedicated path | | Worker productivity monitoring | Medium, contested | High, Annex III and employment law | Assess with worker representatives | The last row deserves a note that isn't regulatory. These systems often get introduced as efficiency tools, and they produce internal conflict once people understand what they measure. The cost of that conflict rarely enters the business case. ## The constraint sits in the data, not the model In manufacturing the factor determining the result is almost always the quality of historical data. Predictive maintenance works when correctly labelled failure data exists, and in many plants that data sits in a maintenance system filled in inconsistently. The check to run before any pilot is trivial and many skip it: take a year of history, count how many failure events carry a reliable cause and date, and see whether there are enough to train anything. When the answer is no, the first sensible project concerns data collection rather than a model. Management doesn't want to hear it, and hearing it avoids spending on a pilot that cannot succeed. ## A pilot on one line doesn't replicate itself The right perimeter in a factory is a line, a cell or a plant. The baseline is measured on that line, not on the plant average, and acceptance criteria get set beforehand. There is a specificity, though: what works on one line doesn't automatically work on another, because machines, materials and operators differ. Extension has to be treated as a new project with its own verification rather than as a copy. Many companies discover this after buying licences for the whole plant. ## Who has to be able to stop the system Accountability for an AI system in a factory can't sit with IT, which doesn't know the process, nor with the production manager, who is measured on output and has no time. The balance point is usually the maintenance manager or the quality manager, depending on the use case, with a contact in operations management. The person must have the authority to stop the system when needed. An owner who can't switch it off remains one on paper only. ## Where to start The sequence begins with the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), separating plant and product from the very first row. The general selection criteria are in [AI adoption: how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case), and the cost model in [AI project budgeting](/en/blog/strategy/ai-project-budget-pilot-production). The sector's regulatory picture is on the [AI governance for manufacturing](/en/sectors/manufacturing) page. To assess which use cases make sense in your company, you can [book a meeting](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in manufacturing: where to graft without distorting URL: https://zerofive.ai/en/blog/compliance/ai-literacy-manufacturing-factory-training Data: 2026-08-19 Abstract: OT and IT don't talk. The three roles needing individual evidence and the natural window when a new production line starts. **In short.** In manufacturing, AI training meets a training framework that already exists and is required by law, the one for workplace safety. It is the most efficient graft point and at the same time the risk, because discussing AI inside the safety module leads to treating it as a hazard rather than as a tool to govern. Three roles need individual evidence, and one of them, the product designer, doesn't yet know it at many companies. In a factory, training has a long tradition and a defined structure, with supervisors, operators and managers, roles the law names and assigns specific duties to. Whoever comes to build the AI plan finds language, calendar and tracking already in place, and the temptation to lean entirely on that framework is strong. It's worth partly resisting. ## Two worlds that don't talk Manufacturing houses two populations with different skills and cultures. The OT world, which governs machines and lines, with a culture of reliability and safety built over decades. The IT world, which governs management systems and data, with a culture of process and project. AI systems fall between them, and that creates a specific training problem: whoever knows the machine doesn't know the model, whoever knows the model doesn't know the production process. A plan that trains the two populations separately leaves precisely the contact point exposed, which is where problems start. The workable answer isn't training everyone on everything. It's building one short shared module on the contact points, then separate tracks on the specifics. ## The three roles needing individual evidence **Those designing products that will embed AI.** This is the role many companies don't yet recognise as critical. An AI system embedded in a product subject to harmonisation legislation falls under Annex I, and conformity assessment is designed alongside the product. Whoever shapes those choices needs to know their consequences, and the 2028 deadline doesn't make the training deferrable, because products in design today reach the market then. **Those introducing systems that measure people.** Productivity monitoring, task allocation, performance evaluation: these are Annex III systems, and in Italy employment law constraints stack on top. Whoever proposes or configures them needs to know what that entails. **Those exercising human oversight over systems with a safety function.** Here the competence adds to what accident prevention legislation already requires, and the documentation has to hold both together. ## Where it grafts, without distorting | Existing framework | What it already covers | What to add for AI | |---|---|---| | Safety training for operators | Correct machine use, hazards | Behaviour of adaptive systems and when to stop | | Supervisor training | Oversight and accountability | What to report on a system that decides | | Designer training | Product conformity and marking | Requirements arriving from the AI Act on embedded systems | | Training on a new line | Operational use | Known system limits and cases where the data doesn't hold | | Quality training | Controls and nonconformities | Difference between a deterministic and a probabilistic control | The last row produces the most immediate value. Quality people think in thresholds and tolerances, and a model-based visual control system works differently: it errs in a different way, and how it errs has to be taught. ## When to train, inside a production cycle In a factory, training has a natural window other sectors lack, coinciding with the introduction of a new line or machine, when training is already budgeted, people have been released from production and the supplier's engineer is physically present on the floor. It is the best possible condition. Grafting AI content there costs almost nothing extra and produces competence tied to the specific system, which is exactly what clause 7 asks for. Outside that window, structured training competes with production and loses. ## The machine supplier isn't the model supplier A complication typical of manufacturing concerns the chain. The machine builder integrates third-party components, which in turn embed models developed by others. When something goes wrong, working out who answers requires tracing a chain nobody has mapped. On the training side the company therefore has to require known-limit information from the builder rather than settling for the user manual. Without that information the training stays generic, and in the event of an incident it demonstrates nothing. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), which in manufacturing must separate plant systems from product-bound ones, because the two groups carry different regimes and deadlines. From there the matrix gets built, described in [a roles-competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai). The full requirements are in [clause 7 explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained). The sector's regulatory picture is on the [AI governance for manufacturing](/en/sectors/manufacturing) page. Our approach to role-based tracks is on the [AI Training](/en/services/ai-training) page. To review your company's plan, you can [book a meeting](https://calendly.com/fabiolalli/zerofive). --- # AI Enters Italy's Corporate Liability Law: What the New Article 25-vicies Actually Covers URL: https://zerofive.ai/en/blog/compliance/italy-decree-231-article-25-vicies-ai Data: 2026-08-18 Abstract: Article 25-vicies of Italy's Decree 231/2001 after Decree 160/2026: offenses 437-bis and 612-quater, sanctions, timing, and compliance model updates. > **Update, September 16, 2026.** The decree was published in Italy's Official Gazette No. 214 of September 15, 2026 as Legislative Decree No. 160 of September 9, 2026, and enters into force on September 30. This article has been reviewed against the official text: numbering and penalties are confirmed, while the description of Article 437-bis has been corrected compared with the August 18 version, which was based on the text approved by the Council of Ministers. **In short.** The new Article 25-vicies of Legislative Decree 231/2001 makes companies liable for two AI-related offenses: failing to adopt safety and human oversight measures in high-risk AI systems, together with unlawfully altering those systems (Article 437-bis of the Criminal Code), and the unlawful dissemination of deepfakes (Article 612-quater). Monetary sanctions range from 600 to 1,000 quote for the first offense and from 200 to 700 quote for the second, alongside a selection of disqualifying sanctions. For those who use a high-risk system without having developed it, the offense requires that human oversight be omitted intentionally. Updating the 231 compliance model starts from the inventory of AI systems. ## Where the new liability comes from The extension of corporate liability comes from a choice by the Italian legislature, exercised through the delegation in Article 24 of Law 132/2025, which asked the government to specify how administrative liability applies to entities for offenses tied to AI systems; the European regulation, on its own, does not provide for it. Decree 160/2026, whose first part governs the use of AI by police forces, carries out that delegation in Article 15, which inserts Article 25-vicies into Decree 231 under the heading "Offenses committed through the use of artificial intelligence systems". The new article follows Article 25-undevicies in a catalog of predicate offenses that has grown almost every six months in recent years, and it brings into the 231 perimeter a risk that many companies had treated only as a technical or data protection issue. ## Two predicate offenses | Offense | Monetary sanction for the entity | Disqualifying sanctions | |---|---|---| | Art. 437-bis Criminal Code, failure to adopt safety measures in AI systems and unlawful alteration of systems | 600 to 1,000 quote | Art. 9(2)(b), (c), (d), (e) | | Art. 612-quater Criminal Code, unlawful dissemination of content generated or altered with AI systems | 200 to 700 quote | Art. 9(2)(b), (c), (d), (e) | A quota is the unit Italian law uses to scale corporate fines to the offense and to the company's financial capacity. The disqualifying sanctions referenced are the suspension or revocation of authorizations, licenses, or concessions, a ban on contracting with public administration, exclusion from grants, financing, and subsidies, and a ban on advertising goods or services. Letter (a), the ban on carrying out the business activity, is left out, and it is the harshest sanction in the 231 system. Article 612-quater, the deepfake provision, has existed since 2025, when Law 132 introduced it, and punishes anyone who distributes falsified images, videos, or voices without consent, capable of deceiving about their authenticity and causing unjust harm. Through Article 25-vicies it also becomes a predicate offense, when committed in the entity's interest or to its advantage. ## The structure of Article 437-bis Article 437-bis, introduced by Article 12 of the decree, has four paragraphs with different addressees and conducts. | Paragraph | Who | Conduct | Penalty | |---|---|---|---| | First | Anyone, in the design, training, production, and placing on the market of high-risk systems | Fails to adopt the required technical safety measures capable of preventing malfunctions or alterations, or fails to adopt human oversight measures | Imprisonment from 1 to 5 years if danger to life or to public or individual safety results; from 2 to 8 years if the danger concerns state security | | Second | Anyone, outside the cases of the first paragraph | Alters high-risk AI systems | Imprisonment from 2 to 6 years; from 3 to 10 years if the danger concerns state security, unless the act constitutes a more serious offense | | Third | Perpetrators of the first paragraph's acts | Same acts committed with gross negligence | Penalty reduced by one third to one sixth | | Fourth | Professional user of high-risk systems | Intentionally fails to adopt human oversight measures | The penalties of the first paragraph, depending on the type of danger | The first paragraph targets the chain that builds and markets the system, meaning the position the AI Act assigns to the provider and to upstream actors. The professional user, a figure close to the AI Act's deployer, has a dedicated rule in the fourth paragraph, which requires intentional omission: the gross negligence reduction in the third paragraph refers only to the first paragraph's acts, so no negligent form is provided for someone who uses a system without having developed it. As drafted, every case requires that the conduct creates a danger to life, to public or individual safety, or to state security. A missing formal step does not, on its own, amount to the offense, which moves attention to human oversight as actually exercised, day by day, more than to its description in documents. ## When the rules bite The decree is in force from September 30, 2026, yet Article 437-bis refers to the measures "required" for high-risk systems, and under the AI Act, after the Digital Omnibus (Regulation (EU) 2026/1744), those obligations apply from December 2, 2027 for Annex III systems and from August 2, 2028 for Annex I systems. How the two dates interact is a question criminal lawyers and the courts will settle. For corporate organization the conclusion hardly changes. A 231 model describes safeguards that must exist before the risk materializes, and building them across a portfolio of AI systems takes months of work on inventory, contracts, and procedures. ## The mechanism that triggers corporate liability For a company's liability to arise, the two conditions that apply across the whole 231 catalog must be met: the offense is committed in the entity's interest or to its advantage by a senior manager or a subordinate, and the entity fails to prove it adopted and effectively implemented a model suited to preventing it. Organizational fault is a standard as old as the decree itself. What changes is its object, which now includes the upstream choices on AI systems, such as how they were selected, on what criteria they were configured, how continuously they were monitored, and how rigorously they were documented. The exemption remains available through the usual safeguards, a model adopted before the fact, a supervisory body with autonomous powers, and a disciplinary system, provided the model addresses algorithmic risk specifically rather than as a variant of generic IT risk. ## Updating the 231 model | Activity | Output | Led by | |---|---|---| | AI system inventory | List with purpose, AI Act risk class, and the company's role in the value chain | Compliance with IT and process owners | | Cross-check with 231 sensitive processes | Map of the points where a high-risk system touches an already exposed process | Compliance and supervisory body | | Assignment of responsibilities | Names for adoption, configuration, oversight, and incident handling | Senior management | | Human oversight procedures | Written rules on who intervenes, on which signals, and with what record | Process owner | | Evidence retention | Logs, human interventions, and anomalies, with defined retention periods | IT and vendors, through contract clauses | | Targeted training | Content differentiated by role | HR and compliance | The evidence in the table also matters outside the criminal perimeter. In Articles 16 to 20, the same decree makes logs and oversight records subject to disclosure orders in civil claims for AI-related damage, with heavy consequences for those who fail to produce them, as we explain in our article on [evidence and causation](/en/blog/compliance/ai-damages-evidence-causation-italy-decree-160-2026). ## A parallel reform of Decree 231 At the same August 4, 2026 meeting, the Council of Ministers also approved a bill for a broader reform of Decree 231, covering among other things the statute of limitations for the administrative offense and the burden of proof in negligence-based offenses. That bill still has to go through the full parliamentary process, on a longer timeline than an implementing decree, and regulatory monitoring should keep the two reforms apart: Article 25-vicies is law from September 30, while the bill is still a proposal. ## Next step Updating the 231 model starts from the inventory, because without knowing which systems are in use and in what role, none of the activities in the table has an object. The method is in our guide to the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), and the AI Act obligations already binding are mapped in [AI Act August 2, 2026: what is actually binding](/en/blog/compliance/ai-act-august-2-2026-what-is-binding). With the [AI Rating](/en/services/ai-rating) we also measure maturity on the AI Risk dimension, which covers compliance, security, and risk governance. To discuss your compliance model, [book an assessment meeting](https://calendly.com/fabiolalli/zerofive) or write to hello@zerofive.ai. *This article describes the legislative text and its organizational implications and does not constitute legal advice.* **Sources.** Legislative Decree No. 160 of September 9, 2026, Official Gazette, General Series, No. 214 of September 15, 2026, Articles 12 and 15; Legislative Decree No. 231 of June 8, 2001, Articles 9 and 25-vicies; Law No. 132 of September 23, 2025, Article 24; Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744; Council of Ministers, press release of August 4, 2026. --- # AI Act August 2, 2026: What Is Actually Binding URL: https://zerofive.ai/en/blog/compliance/ai-act-august-2-2026-what-is-binding Data: 2026-08-06 Abstract: What really applies on August 2, 2026: Article 50, sanctions and Italian supervision. Annex III moves to December 2, 2027 under the Digital Omnibus. In the days around August 2nd we read dozens of headlines about the AI Act, and they do not all say the same thing. Some talk about transparency and fines, others add high-risk systems as if those kicked in too, others blend deadlines from different years into a single paragraph. For a board that needs to decide what to do on Monday morning, the nuance matters: it separates a real obligation from an alarm that has already expired. Let's sort it out, source by source. ## Three Obligations Become Operative Today Three things go live on August 2nd, 2026, and they are real. The first is transparency under Article 50: providers of chatbots, voice assistants or systems that interact with people must make their artificial nature recognisable, and the same applies to text, images, audio and video generated or altered by AI, marked in a readable way within the limits of available technology. The Digital Omnibus grants a window until December 2nd, 2026 for systems already on the market before today: a tool launched in June still has four months, one launched tomorrow does not. The second is the sanctions regime, fully enforceable from today for violations of these transparency obligations and for the prohibited practices of Article 5, in force since February 2025. The figures are precise: up to fifteen million euros or 3% of global turnover for transparency, up to thirty five million or 7% for prohibited practices. These are not theoretical ceilings, the Commission published operational guidelines in the days before the deadline specifically to make them enforceable from day one. The third is less visible but weighs heavily for companies operating in Italy: national supervision becomes fully operational today. Law 132/2025 designated the National Cybersecurity Agency as the authority with inspection and sanctioning powers, and the Agency for Digital Italy for notification and accreditation, while Banca d'Italia, CONSOB and IVASS retain competence over systems used in banking, financial and insurance services. An inspection, from now on, has a specific counterpart with a name and a phone number. ## The Confusion Around Annex III Here lies the misunderstanding circulating most. Several articles published before July 24th, when the Digital Omnibus was still a draft, listed August 2nd, 2026 as the date when obligations for high-risk systems under Annex III would also become applicable: recruitment, credit, education, essential services. That was accurate when it was written. Regulation (EU) 2026/1744, published in the Official Journal on July 24th and in force since the 27th, moved that deadline to December 2nd, 2027. Those articles remained online, indexed, and are circulating today as if they described the current situation. The practical consequence: if a company system falls under Annex III, nothing is being violated this morning. An obligation that is not yet applicable cannot be sanctioned, and this is precisely the point the noise of these past days has failed to clarify enough. For high-risk systems embedded in already regulated products, Annex I, the deadline is further out still: August 2nd, 2028. ## Two Obligations Stay Where They Were Two requirements are not news from August, they simply remain where they already stood. The prohibitions of Article 5, covering manipulative practices, social scoring, emotion recognition at work, have been in force since February 2nd, 2025. The obligations on general-purpose AI models, GPAI, have been operative since August 2nd, 2025, together with European governance and the designation of national authorities. Companies that had not yet addressed these two fronts do not have a new August deadline, they have an overdue one. ## The Map Matters More Than the Date The right question for a company is not which exact date applies, it is what the company actually has running. Mapping the AI systems in use or in procurement, with a first classification against Annexes I and III, is worth as much today as it will be worth in December 2027: without that map, every regulatory deadline arrives as a surprise, regardless of when it falls. According to the Artificial Intelligence Observatory of Politecnico di Milano, 71% of large Italian companies have active AI projects, yet only 9% have structured governance. That gap widens precisely in moments like this one, when deadlines multiply and contradictory news makes it hard to know what to act on first. A company that already has a map of its own systems reads August 2nd as one deadline among others. A company without that map risks reacting to the wrong headline, or ignoring the right one. The reference remains the consolidated text: Regulation (EU) 2024/1689 (the AI Act) as amended by Regulation (EU) 2026/1744, published in the Official Journal of the European Union on July 24th, 2026, together with Law 132/2025 for the Italian authority framework. Every other source, including the most recent ones, should be checked against its publication date before being taken at face value. Regulatory deadlines are meant to be managed, not read twice with two different meanings. --- # AI Rating in a telco: the gate sits on the commercial side URL: https://zerofive.ai/en/blog/strategy/ai-rating-telecom-commercial-systems Data: 2026-08-04 Abstract: High Readiness and Delivery, exposed Risk. Classifying sales systems and the cost of separate AI Act and NIS2 frameworks. **In short.** In telecom operators the AI maturity profile skews high on Readiness and Delivery, because these are technology companies with their own data and mature release cycles. The gate blocking the class sits on Risk, and more precisely on one point: the commercial systems nobody has classified, starting with customer credit assessment. It is the one sector where the technical dimension isn't the problem. An operator running the assessment expects a high result, and often gets one across three dimensions out of four, with scores that in other sectors would be out of reach. The jump in class, though, is decided entirely on the fourth, and no technical advantage compensates for it. ## The four dimensions in a telco **Readiness** measures preparation, data, skills, infrastructure. It is high: operators own their data, run their own infrastructure and hold technical competence in house. This is the opposite condition to sports clubs and many insurers. **Delivery** measures the ability to reach production and maintain. This is high too, because the software release cycle exists and works at scale. The limit is that the cycle covers systems developed in house and not those switched on inside vendor platforms. **Risk** measures governance, compliance and ethics. Everything concentrates here. The NIS2 framework exists, is mature and covers operational resilience well, while governance of AI systems read through the lens of impact on the individual is almost always exposed, because nobody asked for it before and the function that should own it isn't the same one. **Confidence** measures management commitment and user trust. It is generally good inside the company and weaker across the indirect network, which uses tools without knowing what they do. ## The gate: commercial systems never classified The recurring constraint isn't where you would expect. Operators govern network systems well, because they consider them critical, and govern commercial systems poorly, because they consider them sales tools. The emblematic case is the creditworthiness assessment attached to device instalment plans. It originates as a commercial rule, often implemented inside a CRM, and falls under Annex III. Until it gets classified as a high-risk system, the Risk dimension stays below threshold, and since the gates are non-compensable the class drops to the level of the constraint even with excellent Readiness and Delivery. The second exposed point concerns AI features switched on inside platforms already in use, where the operator is a deployer without having decided to be and often without knowing. ## When the two frameworks diverge There's a finding that only surfaces at mature operators, and it is expensive. A company that built NIS2 documentation and then separately built AI Act documentation on the same systems ends up with two frameworks that diverge. For the rating this doesn't help as much as it might seem, because the evidence that counts is the consistent kind. Two documents describing the same system differently weaken each other, and in a review the question becomes which of the two reflects reality. The class improves when the frameworks coordinate, not when they multiply. ## What a class means in practice | Class | Typical situation in a telco | What's reasonable to do | |---|---|---| | D | AI systems live in vendor platforms, no mapping | Build the inventory including activated features | | C | Network governed, commercial unclassified | Classify commercial processes, starting with credit | | B | Classification complete, NIS2 coordination underway | Complete the evidence on Annex III systems | | A | Mature system verified across all dimensions | Reserved for verified assessments, not self-assessments | Moving from C to B at an operator is almost always classification and documentary coordination work rather than technology. It's also why it gets deferred: it produces nothing visible. ## Why measure before the next investment cycle Operators plan investment on long cycles and significant budgets. An assessment made before that cycle allows documentation and log access requirements to be written into vendor tenders, which is the moment the leverage exists. After signing, everything changes. Obtaining a model's technical documentation, its logs or a guarantee of notice on updates costs far more, requires a renegotiation nobody wants to open, and in several cases simply isn't possible because the supplier doesn't produce them. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), built to include features activated inside existing platforms and commercial processes with effects on customers. The full model, with the four dimensions and the gate logic, is on the [AI Rating](/en/services/ai-rating) page. The sector's regulatory picture is on the [AI governance for telecom operators](/en/sectors/telco) page. For an assessment of your operator's position you can [book a meeting](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # AI agent PoCs: how to set them up so they reach production URL: https://zerofive.ai/en/blog/strategy/ai-agent-pocs-how-to-make-them-work Data: 2026-08-02 Abstract: 40% of agentic projects will be cancelled by 2027. How to frame an AI agent PoC with success criteria, realistic costs and AI Act compliance built in. An agent that books appointments, an agent that answers customers, an agent that reconciles invoices. In the boards I sit on the question is always the same: should we run a PoC? The right answer exists, but it depends on how the PoC is framed, on what it has to prove, and on who decides what happens next. Because the problem is rarely getting started. 71% of large Italian companies have active AI projects, only 9% have structured governance (Osservatorio Artificial Intelligence, Politecnico di Milano, February 2026). PoCs get done, plenty of them. Then they sit there, in that limbo we call pilot purgatory: demonstrations that worked once, in front of the right people, and that nobody ever carried further. ## 40% of agentic projects will be cancelled by 2027 The estimate comes from Gartner, June 2025: over 40% of agentic AI projects will be cancelled by the end of 2027 due to escalating costs, unclear business value or inadequate risk controls. Anushree Verma, an analyst at Gartner, states that most agentic projects today are experiments or proofs of concept driven by hype, and often misapplied. MIT, through the NANDA project, reached an even harsher conclusion in the summer of 2025: 95% of generative AI pilots produce no measurable impact on the P&L. Well, these numbers describe something precise, something we see every week in our assessments: PoCs fail when they are born to impress someone instead of informing a decision. And a PoC that serves no decision is a cost dressed up as innovation. ## A PoC without upfront criteria is a demo The difference between a demo and a proof of concept lives entirely in a document almost nobody writes: the success criteria, fixed before a single line of code. For an AI agent those criteria cannot stop at "it works". An agent makes decisions autonomously, touches real systems, produces output someone will use, so it has to be measured on dimensions a demo never shows: task completion rate on real cases rather than hand-picked examples, behaviour on edge cases, cost per run (tokens, API calls, human supervision time), how often a person has to step in, what happens when the agent gets it wrong. In our model we formalise it this way: the PoC starts with real data and real context, with success criteria defined upfront, and it produces three possible outputs, scale, fix, stop. The prototype is not a goal, it is a decision-making tool. If at the end of the PoC you cannot say what production would cost and under which conditions it would be sustainable, the PoC gave you applause and no answers. There is also a preliminary test we always recommend, because it filters out half of the requests: does this use case actually need an agent? Many processes are solved with traditional automation or with a well-integrated assistant, at far lower cost and risk. Gartner notes that a large share of use cases positioned as agentic do not require agentic implementations at all. Choosing an agent where a workflow would do is the first economic mistake, and it gets made before anything starts. ## The economic mistake: the PoC that drifts into production The typical scene: the PoC lands well, the sponsor wants speed, and the team ships the same architecture the PoC ran on. Nobody has estimated steady-state costs, nobody has verified the integration with ERP and CRM, nobody has planned the monitoring. Six months later operating costs sit at two or three times the estimates, because a PoC optimises for speed of demonstration rather than efficiency of operation. An agent that costs a few cents per run in a demo changes order of magnitude in production, once you add retries, wide context windows, multi-model orchestration and human supervision. A well-built PoC already carries the antidote: among its success criteria sits a realistic estimate of production cost and complexity. If the PoC proves the use case works but would cost more than the process it replaces, that is a successful PoC with a negative outcome. It prevented a bad investment, which is exactly its job. Our value proposition includes saying "stop", whenever the numbers say so. ## The regulatory mistake: treating the PoC as a free zone Here we see the most widespread naivety. "It's just a PoC" gets used as an implicit exemption: real customer data inside a prototype, no register, no risk assessment, vendors picked without checks. A PoC using real personal data is data processing in every legal sense, and the GDPR grants no discount for experiments. And under the AI Act risk classification belongs at the beginning, at the end it is too late: if the use case you are prototyping falls among high-risk systems (recruitment, credit, access to essential services), the choices made during the PoC, from datasets to human oversight, determine what compliance will cost afterwards. The updated calendar set by Regulation 2026/1744 moves the obligations for Annex III high-risk systems to 2 December 2027, with the new prohibitions applying from 2 December 2026: decision windows, for anyone prototyping right now, far more than administrative deadlines. For agents the issue amplifies, because an agent acts: it writes to real systems and makes micro-decisions on your behalf. The human oversight the regulation requires for relevant cases has to be designed into the prototype, together with action logs and the ability to intervene, because adding it later means redesigning. In our AI Rating this is the Risk dimension, and it contains what we call critical gates: non-compensable parameters, where technical excellence elsewhere never offsets a gap in compliance or ethics. A company with class-A delivery and no AI system register stays in class C, and the same logic applies, identically, to PoCs. ## Rating first, prototype second All of this explains the sequence of our method, which at first looks slow to some and then turns out to be the fastest route to actual production. First you measure: the AI Rating captures maturity across four dimensions (Readiness, Delivery, Risk, Confidence) and tells you whether the organisation has the conditions to carry an agent beyond the prototype. An agent PoC inside a company with inaccessible data, unclear ownership and no monitoring practice will produce a nice demo and nothing else, and knowing that beforehand costs a fraction of discovering it afterwards. Then you decide: which use case, with which success criteria, with which stop threshold. Then you validate, and that is the job of protot.ai, our fast prototyping unit: prototypes in one to three weeks, MVPs in four to eight, on real data, with the explicit mandate of putting the hypothesis to the test before production. protot.ai tests, ZeroFive builds in production and governs: the separation is deliberate, because whoever validates must have no interest in selling the implementation, otherwise every PoC miraculously ends up "working". Across the 34-plus assessments and projects we have run, the sharpest correlation is this one: the PoCs that reach production are the ones born inside a decision path, with an executive sponsor who has already established what to do with the outcome, whatever it turns out to be. The question to ask, before funding your next agent PoC, comes well before choosing a model or a vendor: if the prototype worked, would you be able to take it to production and govern it? If the answer is uncertain, the first PoC to run is the one on your own organisation. --- # The Digital Omnibus Is Law: The Compliance Clock Restarts URL: https://zerofive.ai/en/blog/compliance/digital-omnibus-regulation-2026-1744 Data: 2026-07-31 Abstract: Regulation (EU) 2026/1744 defers high-risk AI Act obligations to 2027 and 2028, expands prohibitions and centralises supervision. How to use the window. Across the board tables we work with, spring 2026 was dominated by a single date: August 2nd. Compressed remediation plans, vendors questioned about system classification, compliance budgets approved in a hurry, with a widespread feeling that time was running out. On July 24th, the Official Journal of the European Union changed that calendar. Regulation (EU) 2026/1744, the AI Digital Omnibus, entered into force on July 27th, 2026. It amends the AI Act (Regulation 2024/1689), the Machinery Regulation and the civil aviation framework, while leaving the risk-based architecture untouched. Deadlines move, prohibitions expand, supervision becomes more centralised. Reading this as a simple postponement means grasping half of the news. ## The Dates Move, the Framework Does Not The core of the amendment is the rewriting of Article 113 of the AI Act. Obligations for high-risk systems under Annex III, the standalone ones used in areas such as recruitment, credit, education and essential services, shift from August 2nd, 2026 to December 2nd, 2027. For high-risk systems embedded in already regulated products, Annex I, the new deadline is August 2nd, 2028. What stays in place: the prohibitions applicable since February 2025, the regime for general-purpose AI models, the sanctions framework and the general application date of August 2nd, 2026. The transparency obligations of Article 50, the ones covering the marking of AI-generated content, gain a grace period until December 2nd, 2026 for systems already on the market. And something new comes in, largely overlooked in this week's commentary: from December 2nd, 2026, systems designed to generate non-consensual intimate material or child sexual abuse material, including so-called nudification apps, will be prohibited. The legislator loosens the calendar and, in the same act, raises the bar on what it considers unacceptable. ## Sixteen Extra Months, to Do What The most comfortable reading of the deferral is also the most dangerous one: we have time, let's revisit this in 2027. That is the same logic that produced the numbers we already know. According to the Artificial Intelligence Observatory of Politecnico di Milano (February 2026), 71% of large Italian companies have active AI projects, yet only 9% have structured governance in place. The gap between those two figures does not come from a lack of time, it comes from a lack of decisions. A company that would have arrived unprepared in August 2026 will arrive just as unprepared in December 2027, if it uses the extension to freeze the topic. A company that treats the sixteen months as a working window can do what the tight deadline made nearly impossible: map the systems in use, understand which ones will fall under Annex III, measure its actual maturity on data and capabilities, and only then build the remediation plan. Compliance done under deadline produces documents, governance built with method produces capability. ## AI Literacy, From Obligation to Choice There is a second passage in the Regulation that deserves more attention than it is getting. The AI literacy obligation of Article 4 is softened: the prescriptive wording gives way to measures necessary to develop AI literacy, leaving organisations a wider margin of interpretation. In our experience the need stays intact, what changes is who carries the responsibility for it. When training was a formal requirement, many companies treated it exactly as such: a recorded course, a certificate, a box ticked. Now that the formal constraint loosens, the difference will be made by those who train their people because they need to, because without a shared language between business, IT and risk, projects stall at the pilot stage, and stalled pilots are precisely what 71% of companies already have in house. Training chosen out of conviction is worth more than training endured out of obligation, and from September onwards it will become visible who belongs to which group. ## Supervision Moves to the Centre The Regulation gives the AI Office clearer and more centralised oversight powers over systems integrating general-purpose models and over those connected to very large online platforms. At the same time, the deadline for national regulatory sandboxes slips to August 2nd, 2027, and simplification measures are introduced for SMEs and small mid-caps. Read as a whole, the design describes enforcement shifting towards Brussels while the national level buys time. For a European company this means something concrete: the authority scrutinising the most relevant systems will be a central one, with extended powers, and the quality of internal documentation, registers, impact assessments, decision logs, will weigh more than local interpretations. Preparing for a centralised supervisor requires traceability, and traceability cannot be improvised on the eve of a deadline. ## From Here to December 2027 The reasonable calendar for a board, seen from the tables where we operate, has three stages. By the end of 2026: a census of AI systems in use and in procurement, with a first classification against Annexes I and III, because the extension only helps those who know what they have. Through 2027: measurement of organisational maturity, gap analysis on governance and processes, explicit decisions on what to scale and what to stop, and on what deserves a prototype before full investment. Close to the deadline: formal remediation, which by then is the easy part. The reference remains the published text: Regulation (EU) 2026/1744, Official Journal of the European Union, L series, July 24th, 2026, together with the consolidated AI Act and ISO/IEC 42001 for those who want a structured management system. Everything else, commentary included, should be checked against the source. The Union has reset the compliance clock without switching it off. The question that matters now is not about Brussels, it is about companies: how many will use these sixteen months to decide, and how many will use them merely to wait? --- # AI adoption in a telco: the network is easy, the commercial side isn't URL: https://zerofive.ai/en/blog/strategy/ai-adoption-telecom-network-commercial Data: 2026-07-30 Abstract: The highest-value area carries the least friction. NIS2 coordination, the hidden credit assessment, and pilots at large volumes. **In short.** Telecom operators enjoy a rare condition: the area with the most value, network optimisation, is also the one with the least regulatory friction, because it stays minimal risk under the AI Act. That is the opposite of banking and insurance. The constraint here concerns the overlap with NIS2, which needs coordinating rather than duplicating, more than the rules themselves. The use case to treat with most care is the commercial one, where a credit assessment hides. In operators, technical maturity is high, and the question concerns impact rather than feasibility. That shifts the problem onto different ground from other sectors, where the discussion stops earlier, at what can be built with the available data. ## Two areas, two logics On the network, value is measured in operating costs, faults avoided and capacity recovered. These are numbers the operator already collects daily for its own reasons, which makes the business case verifiable in months rather than years and removes the argument about how to measure. That matters. On the commercial side, value is measured in churn avoided, conversion and margin per customer. Those numbers are available too, with one complication: attributing a churn change to a model requires a control group, and in a telco keeping one means declining to treat part of the customer base. The practical difference is that on the network you can start without regulatory discussion, while on the commercial side you first need to know which risk class you are working in. ## The map of candidate use cases | Use case | Value | Regulatory friction | Suitable as first | |---|---|---|---| | Predictive maintenance on the network | High and measurable | Low, NIS2 obligations remain | Yes | | Capacity optimisation | High | Low | Yes | | Customer service assistance | Medium-high, at volume | Low, Article 50 | Yes | | Churn and propensity models | High | Medium, GDPR profiling | As a second step | | Traffic fraud detection | High | Medium, depends on customer impact | As a second step | | Credit assessment for instalment plans | High | High, Annex III | No, not as a first | The last row stays invisible longest in operators, because that process originates in the commercial function and gets treated as a sales rule rather than a scoring system. ## Coordinating with NIS2 instead of duplicating A telecom operator already produces documentation on risk management, resilience and critical suppliers. Many of the requirements the AI Act sets for relevant systems overlap with that work. Building a second separate framework means paying twice for the same system, with the result that the two sets of documentation diverge over time and neither is reliable. Coordination is a requirements mapping exercise rather than a rewrite: you establish which evidence satisfies both sets of rules, which serves only one, and who maintains it. It is also how to avoid loading everything onto the security function, which in many operators is already the bottleneck. ## The pilot when volumes are enormous The recurring temptation is to skip the pilot, because volumes are such that a test on a narrow perimeter looks insignificant, and the pressure to scale immediately is strong. It's worth resisting for a practical reason: at large volumes a systematic error causes damage for weeks before anyone notices, and the cost of recovery exceeds that of the test avoided. The right perimeter for a telco pilot is a region, a customer segment or a type of installation, with a baseline measured on that same perimeter and acceptance criteria set beforehand. The exit plan here mostly concerns integration with billing and network management systems, the part that stretches timelines more than any modelling question. ## When the model comes from the vendor Most AI systems in a telco arrive inside vendor platforms rather than being developed in house. That changes the question: it isn't what we want to build, it's what we are already using and who answers for what. Defining the contractual role has to happen system by system, before extending usage rather than after, because the choice between provider and deployer determines which obligations fall on the operator and which stay with the supplier that built the model. This isn't a formality. An operator switching on an AI feature inside an existing platform takes on obligations nobody assessed at activation. ## Where to start The sequence begins with the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), which in a telco must also cover features switched on inside vendor platforms. The general selection criteria are in [AI adoption: how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case), and the cost model in [AI project budgeting](/en/blog/strategy/ai-project-budget-pilot-production). The sector's regulatory picture is on the [AI governance for telecom operators](/en/sectors/telco) page. To assess which use cases make sense for your operator, you can [book a meeting](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in a telco: the problem is scale URL: https://zerofive.ai/en/blog/compliance/ai-literacy-telecom-operators-scale Data: 2026-07-28 Abstract: Thousands of people, many not employees. The few roles needing individual evidence and what to reuse from the existing NIS2 framework. **In short.** In a telco the problem with AI training is scale: thousands of people across call centres, stores and the sales network, most of whom are not employed by the operator. The uniform training that works at those numbers covers the literacy obligation and doesn't cover clause 7, which asks for competence by role. The answer isn't training everyone the same way, it's separating the few roles needing individual evidence from the mass that needs awareness. Telecom operators have vast, well-run training frameworks built on compliance, safety and product. AI slots in easily as a module, and that is both the advantage and the risk: a module added to a system designed for scale produces no specific competence on any system. ## The perimeter is wider than the payroll Clause 7.3 speaks of people working under the organisation's control, and in a telco that perimeter includes the outsourced call centre, franchised stores, agents and installation technicians. These are people using assistance, quotation and diagnostic tools daily, and who in most cases appear in no operator training plan. This is the first gap to close, and it is contractual work. Competence requirements belong in service contracts with partners, alongside an obligation to supply evidence. The second gap concerns turnover. In a call centre annual churn is high, and an annual training plan covers a population that has half changed in the meantime. What's needed is a trigger tied to a person joining, not to the calendar. ## The roles needing individual evidence For the vast majority, awareness is enough: what the tool does, when it needs checking, who to report to. For three groups the evidence has to be named. **Those working on credit assessment.** This is the surprise in a telco. Device instalment plans involve an assessment of the customer's creditworthiness, which falls under Annex III, and anyone working on that process carries full competence obligations. **Those exercising human oversight over critical network systems.** Not under the AI Act, where those systems stay low risk, but under NIS2, which requires demonstrable competence on resilience. **Those approving platform adoption.** In a telco adoptions often run through procurement, and whoever signs needs to know what they are approving in terms of role and obligations. ## What to reuse from NIS2 The framework built for NIS2 already covers part of the work, and mapping it is worth doing before building. | Element | Exists for NIS2 | What's missing for AI | |---|---|---| | Security and resilience training | Yes, structured | Extension to AI systems | | Evidence tracking | Yes, by obligation | Link to role and system | | Critical supplier management | Yes | AI competence requirements in contracts | | Operational risk culture | Yes | Translation to risk for the individual | | Effectiveness verification | Exercises | Practical cases on AI systems in use | The last row is the easiest to close and the most often ignored. Telcos run exercises on security incidents, and the same format applied to an anomalous AI output produces effectiveness evidence that a questionnaire doesn't give. ## The module no vendor can write As in every sector, the useful part requires information only the operator holds: which systems are live on which processes, which edge cases have already surfaced in support, who to report anomalous behaviour to and what happens next. In a telco this translates into short, repeatable content, because it has to reach thousands of people with high turnover. Thirty minutes per system, refreshed when the system changes, distributed through the same channels already used for product. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), built in the knowledge that many systems arrived inside network vendor platforms and were never classified. From there the matrix gets built, described in [a roles-competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai), separating the few roles needing individual evidence from the wider population. The full requirements are in [clause 7 explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained). The sector's regulatory picture is on the [AI governance for telecom operators](/en/sectors/telco) page. Our approach to role-based tracks is on the [AI Training](/en/services/ai-training) page. To review your operator's plan, you can [book a meeting](https://calendly.com/fabiolalli/zerofive). --- # Best AI governance tools 2026: comparing Credo AI, OneTrust and IBM watsonx.governance URL: https://zerofive.ai/en/blog/ai-governance/best-ai-governance-tools-2026 Data: 2026-07-24 Abstract: Compare Credo AI, OneTrust and IBM watsonx.governance: features, strengths, indicative pricing and how to choose the right AI governance tool after an AI Rating. ## Why AI governance tools matter in 2026 With the EU AI Act and Italy's Law 132/2025 in force, AI governance is no longer a slideware exercise: enterprises need an operating system that ties together model inventory, risk assessment, vendor controls, evidence of compliance and production monitoring. AI governance tools exist to replace spreadsheets and wikis with a single system of record. The choice is not trivial. Vendors sound alike in marketing but differ significantly in technical depth, MLOps integration, regulatory coverage and pricing. This guide compares three reference platforms (Credo AI, OneTrust AI Governance, IBM watsonx.governance) and places them inside the ZeroFive.AI strategic framework, so you can decide when a tool makes sense and which one to pick after an AI Rating. ## What an AI governance tool actually does A mature AI governance platform covers at least five capabilities: 1. **Model and use case inventory**: a central registry of AI systems, models, datasets, owners, versions and lifecycle status. 2. **Risk assessment**: risk classification (EU AI Act, NIST AI RMF, ISO/IEC 42001) with questionnaires, approval workflows and audit trails. 3. **Policy and controls**: a catalog of internal policies (bias, privacy, security, acceptable use) linked to technical and organizational controls. 4. **Evidence and reporting**: automated evidence collection (bias, robustness, drift, explainability tests) and reports for auditors, boards and regulators. 5. **Production monitoring**: observability for models and agents (performance, drift, incidents, human feedback) with alerts and immutable logs. A tool that only covers inventory or only monitoring is not a governance platform: it is a piece of one. The value comes from integration. ## The comparison: Credo AI vs OneTrust vs IBM watsonx.governance ### Credo AI **Focus**: end-to-end responsible AI governance with a strong emphasis on ready-made policy packs (EU AI Act, NIST, NYC Local Law 144) and multi-stakeholder workflows. **Strengths** - Extensive library of policies and assessments mapped to the main standards. - Solid experience for legal, risk and compliance teams thanks to workflow-oriented UIs. - Native integrations with Hugging Face, Databricks, AWS SageMaker, Azure ML. - Mature reporting for audit and board. **Limitations** - MLOps coverage is deeper on major cloud vendors; custom on-prem environments require integration work. - Enterprise pricing: best suited to organizations with a sizable AI portfolio. **Best fit**: companies with multiple use cases in production, reporting obligations to board or regulators, and a need to align with EU AI Act and ISO 42001. ### OneTrust AI Governance **Focus**: extension of the AI module inside the wider OneTrust suite (Privacy, GRC, Third-Party Risk). **Strengths** - Native integration with privacy, DPIA, third-party risk and ROPA: ideal for existing OneTrust customers. - AI assessments linked to records of processing and privacy impact assessments. - Coverage of risks along the AI vendor supply chain. - Data model and workflows familiar to DPO and legal teams. **Limitations** - Technical depth on MLOps is lower than Credo AI or watsonx.governance. - The strongest value is inside the OneTrust ecosystem; standalone it is less competitive. **Best fit**: organizations already running OneTrust for GDPR or GRC that want to bring AI inside the same perimeter without adding another silo. ### IBM watsonx.governance **Focus**: technical model governance embedded in IBM's data and AI platform, with native lineage and monitoring. **Strengths** - Automated fact sheets generated across the model lifecycle (training, validation, deployment). - Production monitoring (drift, bias, quality) integrated with watsonx.ai and OpenPages. - Strong in regulated sectors (banking, insurance, healthcare) thanks to the IBM ecosystem. - Broad coverage of open-source and proprietary models, including LLMs. **Limitations** - Maximum effectiveness inside the IBM stack (watsonx.ai, OpenPages, Cloud Pak for Data). - Steeper adoption curve for non IBM-centric teams. **Best fit**: enterprises with an IBM data and AI stack, strong need for technical lineage, and highly regulated sectors that must demonstrate auditable model-level governance. ## Summary table | Criterion | Credo AI | OneTrust AI Governance | IBM watsonx.governance | |---|---|---|---| | Primary approach | Policy and workflow | GRC and privacy | MLOps and lineage | | EU AI Act coverage | High | High | High | | MLOps integration | Good (multi-cloud) | Medium | High (IBM stack) | | Ideal for | Risk, compliance, board | DPO, legal, GRC | Data and AI platform teams | | Typical time-to-value | 2, 4 months | 1, 3 months (if OneTrust already in place) | 3, 6 months | | Pricing model | Enterprise, per use case | Modular, per suite | Enterprise, per platform | *Timelines are indicative and depend on AI maturity, number of use cases and required integration depth.* ## How to choose: the ZeroFive.AI logic An AI governance tool is not a product decision: it is a strategic choice that should be made after you understand **where you are** and **where you want to go**. The ZeroFive.AI framework starts there: 1. **AI Rating**: a 1, 5 maturity assessment across strategy, governance, data, technology and people. It gives you a real baseline and prioritized gaps. 2. **Target operating model**: who does what across business, IT, data, legal and risk; which committees, which policies, which KPIs. 3. **Tool selection**: only now does it make sense to evaluate platforms, because you know your use case portfolio, reference standards, technology stack and budget constraints. 4. **Guided adoption**: incremental rollout (inventory first, then assessments, then monitoring) with measurable quick wins. Without these steps, even the best tool becomes another under-used system. With them, the tool becomes the nervous system of your AI governance. ## FAQ **Do SMEs need a tool too?** Not immediately. Below 3, 5 use cases in production, a structured registry and well-written policies are enough. A tool becomes necessary when complexity exceeds manual capacity. **Does a tool replace the framework?** No. The tool executes the framework: without one, the platform amplifies chaos instead of solving it. **Best-of-breed or integrated suite?** It depends on your existing stack. If you already run OneTrust or watsonx, the natural extension wins. If you start from scratch and AI is central, best-of-breed like Credo AI offers more depth. ## Next step Before picking a tool, measure your maturity with the ZeroFive.AI **AI Rating**: in two weeks you get an objective snapshot and a tailored governance roadmap that becomes the brief for platform selection. --- # AI adoption framework: a practical guide to move AI into production URL: https://zerofive.ai/en/blog/strategy/ai-adoption-framework-practical-guide-enterprises Data: 2026-07-23 Abstract: 5-stage AI adoption framework: assessment, use cases, pilots, scale-up, change. With KPIs, roles and a 90-180 day roadmap to move AI into production. ## Why you need an AI adoption framework Most enterprise AI projects do not fail on the model: they fail on adoption. The pilot works in the lab, then stops. No one uses it, no one maintains it, no one measures impact. Six months later there is a demo and a line on the balance sheet. An **AI adoption framework** is the structured method to move from proofs of concept to production systems that generate measurable value. It is not a software development method: it is an **operational transformation** method, in which technology is the easiest part. In 2026 the gap between organisations that adopt well and those still stuck at pilots has become strategic. It is no longer about "doing AI": it is about **how many core processes** are actually augmented by AI, with what ROI, at what level of residual risk. ## The five stages of an AI adoption framework An operational framework has five sequential stages, each with clear exit criteria. ### Stage 1: Maturity and ambition assessment Before adopting, understand the starting point. A structured assessment covers five dimensions: **strategy** (AI vision, alignment with the business plan), **data** (quality, accessibility, governance), **technology** (platforms, MLOps, integrations), **people** (skills, culture, leadership) and **governance** (policy, risk, compliance). The output is a picture of current maturity (typically on a 1-5 scale) and a realistic target ambition. Skipping this stage is the first mistake: pilots get funded that the rest of the organisation cannot absorb. ### Stage 2: Use case portfolio You do not adopt "AI": you adopt specific use cases. You need a **structured portfolio** built from a double movement: top-down (strategic objectives translated into application areas) and bottom-up (ideas from operational teams). Each use case is evaluated on three axes: **expected value** (revenue, cost, risk, experience), **feasibility** (data, technology, change required), **risk** (compliance, security, reputation). The value/feasibility matrix produces the prioritised pilot list, not a wish list of 40 ideas. ### Stage 3: Pilots with explicit success criteria An AI pilot is not "let's try and see". It is an experiment with **hypothesis, KPIs, success threshold and kill criteria** defined before it starts. Typical duration: 8-12 weeks. Small but multidisciplinary team (business owner, data, engineering, change). At the end, three possible outcomes: **scale** (the pilot exceeds thresholds and becomes a scale-up project), **iterate** (results are promising but adjustments are needed), **stop** (the use case does not work: close it, no blame). The ability to stop failing pilots is a maturity indicator. ### Stage 4: Scale-up and industrialisation Moving from pilot to production is where most programmes get stuck. You need elements the pilot did not have: **integration** into core systems, **MLOps** for the model lifecycle, **observability** (performance, drift, incidents), **support** (SLA, runbook, escalation), **end-user training**, structured **change management**. Rule of thumb: scale-up typically costs **3-5 times** the pilot. Underestimating this creates the "almost in production" projects that stay that way for years. ### Stage 5: Organisational change and culture AI changes roles, processes, and the way decisions are made. If organisational change is not planned, adoption does not happen. Key components: transparent internal **communication** about what changes and what does not, differentiated **training** by level (executive, manager, operational), aligned **incentives** (those who use AI are recognised), internal **communities** of practice, **governance** of prompts and approved tools. Cultural change is not a training module: it is a continuous 12-24 month effort. ## Roles and governance structure An AI adoption programme needs clear roles, not necessarily new functions. **Executive sponsor**: a member of the executive committee is accountable for the programme. Without visible sponsorship, pilots do not cross functional boundaries. **AI Adoption Lead**: coordinates the portfolio, the pilots and the scale-up. Often inside the Innovation or Digital function, with enough seniority to interact with business directors. **Business Owner** for each use case: the person who lives with the outcome of the use case, not a consultant. Without a business owner, the pilot has no demand. **Technical team**: data engineering, ML engineering, prompt engineering, integration. Internal, external or hybrid depending on maturity. **Center of Excellence (CoE)**: a common model for companies with multiple business units. The CoE provides methodology, platforms, standards and support; business units own adoption. ## KPIs for an AI adoption programme Measure adoption, not just development. Useful KPIs: - **Coverage**: number of core processes with at least one AI use case in production - **Adoption**: percentage of target users actively using each system (weekly active users) - **Time-to-production**: average weeks between use case approval and go-live - **ROI per use case**: realised benefits vs investment - **Pilot-to-production rate**: percentage of pilots that reach production (realistic benchmark: 20-35%) - **Incidents** and residual risk level - **AI maturity** reassessed annually on the five dimensions The most underrated KPI is **weekly active users** of production systems: without real usage, ROI is theoretical. ## 90-180 day roadmap An AI adoption framework becomes operational in two quarters. **Days 1 - 30: Foundations** - Initial AI Rating (maturity and ambition) - Appointment of sponsor and AI Adoption Lead - Use case portfolio kickoff **Days 31 - 90: First pilots** - Selection of 3-5 priority pilots with explicit success criteria - Lightweight governance setup (pilot committee, templates, review cadence) - First training wave for managers and power users **Days 91 - 180: Scale-up and institutionalisation** - Scale-up plan for pilots that exceed thresholds - Target operating model definition (CoE, business owners, roles) - Programme dashboard (coverage, adoption, ROI, risk) - 12-month roadmap shared with the executive committee ## Common mistakes to avoid **Starting from technology.** Choosing the platform before the use cases produces poorly calibrated investments. **Pilots without a business owner.** An "IT pilot" does not generate adoption: it generates a demo. **Confusing speed with maturity.** Running twenty pilots in a year without moving any into production is worse than running three and industrialising two. **Ignoring the cost of scale-up.** The pilot is the cheap part; industrialisation is where the real budget lives. **Underestimating change.** AI changes work: if people are not supported, adoption stalls even with the right technology. **Governance only about risk.** A governance function that only says "no" blocks adoption. You need a governance that enables: low-risk use cases pre-approved, proportionate controls, fast lanes for innovation. ## How it works in practice AI adoption programmes that generate real value share three traits. They are **business-led**, not IT-led: use cases come from operational problems, not from technical capabilities. They are **incremental**: build on what works, avoid the big bang. They are **honestly measured**: celebrate what works, close what does not, share what you learn. AI adoption is not a project: it is an **organisational capability** built over time. Those who build it now will have a structural advantage over the next five years. ## How we can help At ZeroFive we support enterprises from AI Rating to use case portfolio, from pilots to scale-up. The method is modular: we start from where you are and build adoption capability on your context, without top-down frameworks. --- # AI governance framework: a practical guide for enterprises (ISO 42001 and EU AI Act) URL: https://zerofive.ai/en/blog/ai-governance/ai-governance-framework-guide-iso-42001-eu-ai-act Data: 2026-07-23 Abstract: Practical guide to building an AI governance framework: 7 components, alignment with ISO 42001, EU AI Act, NIST AI RMF and a 90-day roadmap. ## Why an AI governance framework, now Enterprise AI rarely fails because of technology: it fails because of missing governance. Who decides which use cases go to production, who is accountable for a wrong output, where the data lives, which models are allowed, how risk and value are measured: if there is no written answer, the incident will provide one. An AI governance framework is the set of **policies, roles, processes and controls** that lets an organisation adopt AI safely, in compliance, and aligned with strategy. It is not a document: it is a decision-making infrastructure. In 2026 the topic moved from optional to mandatory. The **EU AI Act** sets binding requirements for high-risk systems, **ISO/IEC 42001** provides the certifiable standard for an AI Management System, and the **NIST AI Risk Management Framework** has become the de facto standard in the United States and in multinationals. Without a framework today, you will not pass tomorrow's due diligence. ## The seven components of an AI governance framework An operational, non-theoretical framework rests on seven components. ### 1. Principles and policies The starting point is a corporate **AI Policy** that states what is allowed, what is forbidden, what requires approval. Not an ethical manifesto: enforceable rules. It covers use of generative models, handling of sensitive data, prohibited use cases (employee surveillance, social scoring, fully automated decisions on individuals), transparency obligations toward customers and employees. ### 2. AI systems inventory You cannot govern what you do not know. You need a living **AI inventory**: every AI system in use or in development, with owner, purpose, data processed, models used, EU AI Act risk classification (prohibited, high-risk, limited risk, minimal risk), compliance status. It is the first artefact any auditor will ask for. ### 3. Risk management Every system needs a structured **risk assessment**: technical risks (bias, hallucinations, drift), security risks (prompt injection, data leakage), legal risks (privacy, IP, liability), reputational risks. The NIST AI RMF provides the most used taxonomy: Govern, Map, Measure, Manage. ### 4. Roles and accountability A framework without owners is paper. Minimum roles: **AI Governance Lead** (often the Chief AI Officer or Chief Data Officer), **AI Ethics Committee** (multidisciplinary), **AI Product Owner** for each system, **Model Risk Officer** for high-risk systems. The board holds oversight responsibility: in Italy, Law 132/2025 codifies this explicitly. ### 5. Model lifecycle Governance means controls across the full **lifecycle**: use case approval, design review, pre-deployment testing (bias, robustness, security), production monitoring (performance, drift, incidents), retraining, decommissioning. Each stage with documented evidence. ### 6. Vendor management Most models are third-party. You need **vendor governance** covering: assessment of model and platform providers, contractual clauses (data usage, IP, indemnity), compliance checks (SOC 2, ISO 27001, ISO 42001), AI supply chain management. ### 7. Monitoring, audit and continuous improvement Governance KPIs (inventory coverage, average approval time, incidents, audit findings), **periodic audits**, board reporting, policy updates in response to new risks and regulations. ## How the standards align The reference frameworks are not alternatives: they are complementary. **EU AI Act**: what you must do by law in Europe. Defines risk categories, requirements for high-risk systems (risk management, data quality, documentation, transparency, human oversight, accuracy and robustness), obligations for GPAI models, sanctions. **ISO/IEC 42001**: how you prove it. The first international certifiable standard for an AI Management System. Provides the organisational structure (context, leadership, planning, support, operations, evaluation, improvement) and AI-specific controls. Certification is the external evidence that the framework works. **NIST AI RMF**: how you operate it. Voluntary but widely adopted, particularly useful for the risk management side. The four functions (Govern, Map, Measure, Manage) map well to operational processes. **ISO/IEC 23894** (AI risk management) and **ISO/IEC 27001** (information security) complete the technical picture. The pragmatic approach: **ISO 42001 as the architecture** of the management system, **EU AI Act as the binding requirement** to be embedded in controls, **NIST AI RMF as the operational methodology** for risk management. ## A 90-day implementation roadmap An AI governance framework is not built in a year. The foundations are laid in a quarter. **Days 1 - 30: Assessment and foundations** - Initial AI inventory (workshop with IT, business, legal, security) - Gap analysis against ISO 42001 and EU AI Act - Draft AI Policy - Appointment of the AI Governance Lead and formation of the Ethics Committee **Days 31 - 60: Framework and controls** - AI Policy approved by the board - Use case classification process (low, medium, high risk) - Risk assessment and Data Protection Impact Assessment templates - Vendor governance: standard clauses and evaluation checklist **Days 61 - 90: Operations and reporting** - First review cycle for high-risk systems - Mandatory training for AI teams and management - Governance dashboard (KPIs, incidents, findings) - ISO 42001 certification plan (if relevant) and EU AI Act compliance roadmap ## Common mistakes to avoid **Confusing ethics with governance.** The AI Ethics Committee produces principles; governance produces controls. You need both, but they are different things. **Governance owned only by IT or only by Legal.** AI governance is multidisciplinary by definition: business, IT, legal, security, HR, compliance. A framework driven by one function fails. **Documents without processes.** A policy no one reads and no one enforces is worse than no policy: it creates false confidence. **Underestimating GPAI models.** ChatGPT, Claude, Copilot in the enterprise are AI systems. They must be inventoried, assessed, governed. Shadow AI is already inside. **Postponing while waiting for regulatory clarifications.** The framework is needed before the deadlines, not after. Those who arrive in August 2026 without foundations will not recover in time. ## What makes the difference Frameworks that work share three traits. They are **proportionate** to actual risk: heavy controls on high-impact systems, light controls on low-impact ones. They are **integrated** into existing processes (project management, procurement, security, risk) instead of being a parallel bureaucracy. They are **measured** with KPIs the board understands: how many systems in production, how many incidents, how much value generated, how much residual risk. AI governance does not slow innovation: it makes it possible at scale. Without a framework, the only AI that reaches production is the one no one sees, and that is the riskiest kind. ## How we can help At ZeroFive we build operational, not documental, AI governance frameworks. We start with the AI Rating to photograph current maturity, we design the framework tailored to your context (sector, size, risk), we implement it with your team, and we connect it to EU AI Act, ISO 42001 and (for Italy) Law 132/2025 obligations. --- # AI Adoption: what it is, how it works, and where to start URL: https://zerofive.ai/en/blog/strategy/ai-adoption-what-how-where-start Data: 2026-07-23 Abstract: Practical guide to AI adoption for enterprises: four capabilities, the steps in the right order, and what separates governed AI from ungoverned AI. A company activates the licences, trains a few teams, launches two pilots. A year later the tools are in use, the pilots are still pilots, and nobody can say how much value has reached the accounts. It is the most frequent outcome of AI adoption programmes, and it almost always comes from the same misunderstanding: adoption gets treated as a purchase, when it is a change in the way the organisation decides. ## What adopting AI actually means Adopting AI means bringing it inside the processes through which a company creates value, and taking responsibility for what it produces. It does not coincide with access to tools, which anyone can arrange in an afternoon. The boundary is sharp, and three questions test it. Can the company measure what AI produces? Can it decide where that contribution enters official processes? Can it say who answers for the decisions that follow? While any one of those answers is missing, AI stays a tool in the hands of individuals, and the benefits stay personal instead of becoming organisational. ## How the mechanism works Adoption rests on four capabilities that have to be built together, and it is the same structure we work with in our assessments. Readiness covers the foundations: usable data, real skills, processes able to absorb AI, a culture that does not push it away. Delivery covers the ability to take an initiative from pilot to production and to scale it, and this is the obstacle where most projects stop. Risk governance defines who decides, who supervises and how things are traced, in alignment with Italy's Law 132/2025 and the EU AI Act. Confidence covers leadership commitment and the trust of the people doing the work, because a system nobody uses is worth zero even when it functions. These four capabilities hold each other up. High readiness with weak delivery produces endless experimentation. Effective delivery without governance produces systems in production that nobody answers for, which is the worst position to be in before a regulator or after an incident. ## The imbalance between projects and governance The Italian numbers describe a precise imbalance. 71% of large companies have launched at least one AI project, up from 59% in 2024, while just 9% report fully integrated AI governance, according to the Artificial Intelligence Observatory of the Politecnico di Milano, which presented its research on 5 February 2026. Eight workers in ten use AI tools their employer does not provide: much of real adoption is already happening outside the corporate perimeter, on data nobody has classified. On the regulatory side the runway has shortened. Law 132/2025 has been in force since 10 October 2025 and strengthens the link between the use of AI and corporate liability, while the AI Act makes transparency obligations and its penalty regime operative from 2 August 2026. Ungoverned adoption stops being a missed opportunity and becomes exposure. ## The steps, in the right order Each stage enables the next, and skipping one is paid for later. It starts with measuring maturity, the AI Rating, which shows where the organisation actually stands across the four capabilities and where the gaps are. Mapping opportunities follows, with use cases assessed for impact, feasibility and risk, to establish where AI is worth it and where it is not. From there comes strategy: priorities, a roadmap, and clear go and no-go criteria. Then come the people, with role-based training and a shared language across business, IT and control functions, because adoption without widespread skills stops at the department that pushed for it. Before committing serious budget, a prototype validates value and feasibility in the field. Only at the end does the work move into production and automation, on foundations that hold. ## How companies should move An executive sponsor and an operating team have to work together, because AI is a business decision before it is a technology choice. It pays to start from a few high-value decisions rather than many disconnected pilots, and to define how the result will be measured from the outset, or the year ends with impressions instead of evidence. The tools already circulating inside the company, the ones nobody authorised, need explicit oversight. And some initiatives have to be stopped: saying no to a project without foundations protects the budget and the credibility of every other one. The 9% that hold integrated governance today start from the same technology as everyone else; they decided earlier, and on measurable ground. The distance between the two groups widens over time, because integration into processes is not quick to copy. If you want to know where you stand, the first step is a thirty-minute conversation: how mature your adoption is, where to act for the greatest impact, and in what order. --- # Article 50 AI Act: Transparency Rules Apply 2 August 2026 URL: https://zerofive.ai/en/blog/compliance/article-50-ai-act-transparency Data: 2026-07-21 Abstract: Art. 50 EU AI Act: who must disclose what, when and how, from 2 August 2026. Duties for chatbots, deepfakes and generated content, with an operational checklist. On 20 July 2026 the European Commission published its guidelines on Article 50 of the AI Act, the provision that governs transparency for AI systems. Less than two weeks later, on 2 August, those obligations become applicable to anyone who places on the market or puts into service in the Union a system that interacts with people or generates synthetic content. The guidelines are non-binding, and any authoritative interpretation will ultimately rest with the Court of Justice, yet they set a direction that is hard to misread. Transparency belongs to the architecture of the system and to the entire chain that produces and distributes the content. A label added at the end of the line arrives too late. Hiding in the terms of use that "the service uses AI" is not enough, and the guidelines say so plainly: a disclosure contained only in contractual terms, a URL, or technical documentation does not satisfy the obligation. ## Who marks and who discloses Article 50 splits four obligations between two figures. The provider, whoever develops the system and places it on the market under their own name, must design interactive systems so that a person knows they are talking to an AI (paragraph 1) and mark in a machine-readable format the synthetic content the system generates or manipulates (paragraph 2). The deployer, whoever uses the system under their own authority for professional purposes, must inform those exposed to emotion recognition or biometric categorisation systems (paragraph 3) and visibly disclose deep fakes and public-interest text produced or manipulated by AI (paragraph 4). The distinction carries a practical consequence many organisations underestimate. The provider's technical marking, a watermark or a piece of metadata, never reaches the eye of the person looking at the content, and the Commission clarifies that the deployer cannot lean on that marking to satisfy the labelling duty under paragraph 4. Two separate layers are needed: the machine-readable signal upstream and the human-readable disclosure downstream, and they answer to different actors. ## AI agents disclose on whose behalf they act Among the densest passages is the treatment of agents. An AI agent that books, handles correspondence, or concludes contracts on someone's behalf falls under paragraph 1, and must disclose two things at once: its artificial nature and the person on whose behalf it is acting. To transparency of identity the guidelines add transparency of delegation, and with it the question of who answers for the consequences. When the provider cannot know in advance whether and with whom the agent will interact once released, the guidelines ask for the disclosure to be designed at the architecture level, so that the agent reveals itself whenever an encounter with a person is reasonably likely. It must also identify itself to the person instructing it, at key moments such as authorising or validating an action, and at every new interaction. This is a reading that looks ahead, to the multi-agent architectures where one agent talks to another before reaching the human being. ## Editorial control that counts, and the kind that does not AI-generated or manipulated text published to inform the public on matters of public interest must be labelled as artificial. There is an exception, and here the Commission raises the bar. The exemption applies only if the text has undergone human review or editorial control that engages with the substance, and only if a person, natural or legal, holds editorial responsibility for it. Substantive is the word that carries the weight. Spell-checking, a purely formal review, or the mere existence on paper of an editorial policy does not trigger the exemption. The review has to reach the content, with fact-checking as the minimum, and whoever performs it must have the authority to approve, alter, or reject on the merits. There is more: if AI intervenes substantively after editorial sign-off, the exception falls away and the text becomes labellable again. For newsrooms and for anyone producing content at scale, this is an operational discipline before it is a legal rule. ## The window closes on 2 August From 2 August 2026 every system within the scope of Article 50 placed on the Union market must be compliant, regardless of when it was put into service. The AI Omnibus, recently adopted by the Union legislature, opens a single window of tolerance: generative systems already on the market before 2 August have until 2 December 2026 to bring their marking and detectability under paragraph 2 into conformity. The interaction disclosure of paragraph 1 and the deployer's labelling under paragraph 4 apply from 2 August instead, with no extension. The penalty sets the stakes. Anyone breaching the transparency obligations risks up to 15 million euro or, for an undertaking, up to 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups the lower ceiling applies. The Commission also points to a route for demonstrating compliance: adhering to the Code of Practice on Transparency of AI-Generated Content, published on 10 June 2026, which for signatories focuses supervision on verifying adherence. The numbers show how real the problem is. In Italy 71% of large companies run at least one active AI project, while only 9% have structured governance (Osservatorio Artificial Intelligence, Politecnico di Milano, February 2026). Article 50 requires knowing, for each system, whether it generates content, whether it interacts with people, and who answers for disclosure. That is a governance question before it is a compliance one. ## Knowing when there is no person behind a text The purpose of these obligations is set out in Recitals 132 and following: to reduce the risks of impersonation and manipulation at scale, and to protect trust in the information ecosystem. The guidelines try to preserve, in a communication space mediated by AI, the minimum conditions for a person to choose whether and how much to trust a voice, a face, a text. Knowing when there is no human being behind a piece of content becomes a precondition of autonomy, not a compliance detail. For a company that designs or adopts AI systems, the centre of gravity shifts. Transparency stops being a box to tick just before launch and becomes a design constraint, to be decided before building. Whoever reaches 2 August having already mapped their systems and the related disclosure responsibilities will not be playing catch-up. A few weeks remain to work out, system by system, which side of the line they fall on. ## Checklist: what to put in order before 2 August - [ ] **Inventory and classification.** Map every AI system in use or coming, and classify it: does it interact with people, generate or manipulate content (image, audio, video, text), recognise emotions, categorise biometric data. - [ ] **Role per system.** Establish whether you are the provider, the deployer, or both. Obligations differ: technical marking sits with the provider, perceivable labelling with the deployer. - [ ] **Interactive systems.** Check that chatbots, voice assistants, and agents disclose their artificial nature at first contact, clearly and distinguishably, not only in the terms of use or documentation. - [ ] **AI agents.** Make sure they disclose both their artificial nature and on whose behalf they act, at the architecture level, and to whoever instructs them at the points where they authorise or validate an action. - [ ] **Synthetic content (provider).** Implement machine-readable marking and detection that are effective and interoperable. Generative systems already on the market before 2 August have until 2 December 2026 for this obligation only. - [ ] **Deep fakes and public-interest text (deployer).** Apply a label perceivable to the human eye. The provider's technical marking does not cover this obligation. - [ ] **Emotion recognition and biometric categorisation (deployer).** Inform the people exposed to the system. - [ ] **Editorial exception.** If you publish public-interest text without a label, document substantive human review (with fact-checking) and make editorial responsibility publicly identifiable. - [ ] **Accessibility and vulnerable groups.** Make the disclosure accessible and suitable for minors and vulnerable people when they are reasonably part of the audience. - [ ] **Proof of compliance and internal ownership.** Consider adhering to the Code of Practice on Transparency of AI-Generated Content, coordinate disclosure with GDPR and the DSA where they apply, and assign who answers for disclosure on each system. --- *At ZeroFive we work with CEOs and boards to map the AI systems in use and decide where transparency has to be designed in, before it becomes a compliance problem. The starting point is the AI Rating. To talk it through: [calendly.com/fabiolalli/zerofive](https://calendly.com/fabiolalli/zerofive).* ## Where Art. 50 sits in the governance picture Article 50 transparency is not an isolated task: it is one control inside a wider system. Companies that already run [AI governance consulting](/en/ai-governance) handle it as a design requirement, the others meet it as an emergency. For full alignment with the regulatory deadlines the track is [EU AI Act compliance consulting](/en/compliance-ai), and the service overview is on [AI consulting for enterprises](/en/servizi). --- # AI adoption: where use ends and integration begins URL: https://zerofive.ai/en/blog/insights/ai-adoption-italy-use-integration Data: 2026-07-18 Abstract: 71% of large Italian companies have an AI project, only 9% have integrated governance. How to measure AI maturity before scaling it. Walk into a large Italian company and ask who uses artificial intelligence, and plenty of hands go up: marketing for copy, IT for code, someone in finance for analysis. Ask instead who decides which of those uses enter official processes, on what data and under whose responsibility, and the room empties. That gap, between who uses AI and who governs it, is where the whole question of adoption sits. AI adoption is often confused with its diffusion, and the two are far apart. Diffusion is measured in licences activated and people who open a model every morning. Adoption is measured in how much that model has changed the way a company produces value and answers for what it produces. ## The difference between using AI and adopting it An organisation has adopted AI when it can do three things: measure what AI produces, decide where that contribution enters its processes, and answer for the decisions that follow. Until those three are in place, AI stays a tool in the hands of individuals and never becomes an organisational capability. A company where two hundred people use a generative assistant every day, yet nobody can say what changed in the accounts or who approved which uses, has diffusion at its peak and adoption at zero. It is the most common situation, and also the most expensive, because it looks like progress without being it. ## The four capabilities that hold adoption up Adopting AI is an organisational capability that rests on four foundations, built together. Readiness comes first: usable data, real skills, processes able to absorb AI, a culture that does not push it away. Delivery comes next, the ability to take a project from pilot to production and to scale it, and this is where most initiatives die. On risk sits governance, with a clear line of accountability over who decides and who supervises, and alignment with Italy's Law 132/2025 and the EU AI Act. Confidence remains, the commitment of leadership and the trust of the people who do the work, without which even a system that works goes unused. These are the four dimensions the AI Rating measures, and finding all four mature in the same company is rare. ## 71% have a project, 9% have governance The Italian numbers describe exactly this imbalance. In 2025 the Italian AI market reached 1.8 billion euro, up 50% on the year before, and 71% of large companies had launched at least one AI project, rising from 59% in 2024, according to the Artificial Intelligence Observatory of the Politecnico di Milano, which presented its research on 5 February 2026. 84% use ready-to-use Generative AI tools. Beneath those figures the picture shifts: only one large company in five uses AI pervasively across several functions, and just 9% report fully integrated AI governance. Among small and medium enterprises the share that has launched projects drops to 8%. The same Observatory notes that eight workers in ten use AI tools their employer does not provide, so much of real adoption happens outside any perimeter and any decision. Italy has spread AI wide and integrated it deep in only a minority of cases. ## The cost of staying on the surface Stopping at diffusion has a price, paid on several fronts. The first is economic: money spent on access that never enters processes stays an individual productivity gain and never becomes an advantage for the organisation. Then there is defensibility, because individual use is quick to copy while integration into processes is not, and the distance between those who have governed adoption and those who have not widens over time. On the regulatory front, with Law 132/2025 in force and the AI Act coming into effect, ungoverned adoption becomes exposure, because it ties the company to decisions taken by models it has no record of. Above all sits a dependency of sequence: automation and agents are built on governed adoption, and a company that has not been through this stage has no foundation for the ones that follow. ## Measure maturity before scaling it It starts with knowing where you actually stand. Before choosing where to invest, a company needs an objective measure of its capacity to adopt AI across the four dimensions, from readiness to confidence. This is the logic of the AI Rating, the assessment with which ZeroFive.AI captures a company's AI maturity on objective criteria and returns the gaps before they turn into costs. From that measure the concrete choices follow: where it makes sense to invest, and what to validate before putting it into production. Measure, decide, validate, in that order. The 9% that hold integrated governance today start from the same technology as everyone else; they decided earlier, and on measurable ground. The question to bring to the board is not how much we are spending on AI, but how much of that spend we can actually govern. If the answer is not clear, the first step is to measure it. It starts with a conversation: hello@zerofive.ai --- # Ontologies: the infrastructure that decides whether your AI reasons or guesses URL: https://zerofive.ai/en/blog/insights/ontologies-infrastructure-ai-reasons-or-guesses Data: 2026-07-18 Abstract: A company can run the best model and still get plausible answers instead of true ones. Without a governed ontology, AI does not reason, it guesses. In AI meetings ontology tends to appear as a word, rarely as a responsibility. It gets mentioned, placed on a slide next to knowledge graphs and data, and then the conversation moves back to models and use cases. Yet it is the layer that settles one thing: whether the system you have put into production reasons over your data or produces answers that merely sound right. A company can run the best model on the market and keep getting plausible answers instead of true ones, because nobody has governed the meaning that model works on. ## An ontology is the shared map of meaning Beneath the buzzwords sits a simple idea. An ontology is the explicit, shared map of the entities a business cares about, customer, product, contract, risk, and of the relations between them. It is the agreement on what the words a company uses to describe itself actually mean. In most organisations that agreement does not exist: "customer" means one thing in the CRM, another in billing, a third in support, and every system is right from its own point of view. The knowledge graph is that map made queryable, the form in which meaning becomes something a machine can reason over. ## Reason or guess A language model on its own is fluent and has no ground under its feet: it generates probable text from what it saw in training, with no contact with the facts of your company. Anchored to an ontology and a knowledge graph, the same model stops completing sentences and starts walking real entities and relations, and its answers become verifiable, traceable back to the source. The difference barely matters when AI writes an email, it weighs everything when it decides a credit line or classifies a risk. With Italy's Law 132/2025 in force and the EU AI Act coming into effect, an answer that is defensible before a regulator needs to rest on governed meaning, the only ground that holds up under scrutiny. ## Build it without reinventing it The most common mistake is to treat the ontology as a large project to complete before starting, and those projects never start. You begin from the opposite end, from the decisions the company has to be able to defend and the few entities those decisions touch, mapping what generates value or risk first and leaving the rest out. Where industry standards exist they are reused, rather than redrawing from scratch categories someone has already formalised. The ontology grows in layers, following real use, and stays small enough to be maintained. ## Meaning drifts, and nobody notices An ontology does not break with a visible error, it degrades in silence. The business changes, a new product line appears, a category takes on a different sense, and the map stays fixed to a world that no longer exists. Answers keep coming, they look correct, and all the while they rest on expired definitions. Meaning has to be governed the way code is governed: someone owns it, changes are versioned, whoever alters the definition of a term knows what they are moving downstream. Without that maintenance the invisible infrastructure becomes an invisible risk, and the problem surfaces once a wrong decision has already been made. Governing ontologies is a question of accountability before it is one of technology, and it is one of the points where enterprise AI is won or lost. It is also the first of our AI Strategy Papers, "Govern Meaning": thirty pages on what an ontology really is, why it matters now, how to build it, and how to keep it from degrading in silence until it turns dangerous. Download it here, in English and Italian: [AI Strategy Papers](https://zerofive.ai/papers). --- # Italy's Law 132/2025 and the EU AI Act: governance matters more than rules URL: https://zerofive.ai/en/blog/compliance/italy-law-132-2025-eu-ai-act-corporate-governance Data: 2026-07-17 Abstract: Since 10 October 2025 Italy's Law 132/2025 is in force; from 2 August 2026 the EU AI Act becomes operative. Why AI governance matters more than the rules themselves. The AI regulatory landscape has changed, and it isn't only a matter for lawyers. Since **10 October 2025**, Italy's **Law 132/2025** has been in force, the country's first national framework on artificial intelligence. It sits alongside the **EU AI Act**, whose transparency obligations and penalty regime become operative on **2 August 2026**. Together they apply to companies of any sector and size. ## What boards underestimate Here is what boards underestimate: Law 132/2025 strengthens the link between AI and **corporate criminal liability** (Italy's "231" model). Using AI systems now falls inside that perimeter. It becomes a boardroom topic, not just an IT one. The questions change in nature: - who is accountable for decisions taken or suggested by an AI system? - on which data was it trained and fed? - what traceability exists today, in case of dispute? ## The rules are the easy part The usual reaction is to rush and read the rules. The rules are the easy part. The hard part is knowing whether the organisation can actually meet them: who answers for what, on which data, with what traceability of decisions. That is the gap between knowing a rule and having the governance to apply it. > Only **9% of large Italian companies** have structured AI governance. > *Osservatorio Artificial Intelligence, Politecnico di Milano, 2025* They are the ones already prepared for compliance. ## Measure before you adapt Before you adapt, measure where you stand. **AI Rating** assesses your AI Risk against objective criteria and shows the gaps while there is still time to close them. The first step is a conversation: [hello@zerofive.ai](mailto:hello@zerofive.ai) --- # AI Rating in sport: the gate differs for clubs and federations URL: https://zerofive.ai/en/blog/strategy/ai-rating-sports-clubs-data-ownership Data: 2026-07-16 Abstract: High Confidence and low Readiness. Why the constraint is contractual, what changes when athletes count as workers, and when to measure. **In short.** In sports organisations the AI maturity profile has a characteristic shape: very high Confidence, because management is convinced of the value, and low Readiness, because the data sits in suppliers' systems rather than the club's. The gate blocking the class concerns data ownership more than governance: a club unable to export what it works on doesn't control its own systems, however well it uses them. In federations and sports promotion bodies the picture flips: the data sits in house, and the weight moves onto the handling of member data and onto systems assessing admissions and exams. A club measuring its AI maturity often gets a lower result than expected, because the model looks at control while internal perception looks at usage. Those two diverge sharply in sport. ## The four dimensions in a sports organisation **Readiness** measures preparation, data, skills, infrastructure. It is the lowest dimension in clubs, not through technological backwardness but because data is spread across suppliers and the organisation rarely has direct access. A club can use three analysis platforms daily and own none of the data feeding them. The same holds on the public side: the supporter database is split across ticketing, e-commerce, app and social channels, and a single view of the individual supporter rarely exists. **Delivery** measures the ability to reach production and maintain. In clubs it is structurally limited by headcount: no release cycle exists because no team governs one, and systems arrive ready-made from suppliers. **Risk** measures governance, compliance and ethics. It is exposed almost everywhere, and the most exposed area concerns athlete data, which is health data, and biometric systems in venues. **Confidence** measures management commitment and user trust. It is typically high, sometimes higher than results justify, because in sport innovation also carries communication value. User trust, here, is the public's trust, and it shows in reactions to ticket prices and entry controls rather than in an internal survey. ## The gate: who owns the data The recurring constraint is this. A club uses systems that work, on data it cannot export, supplied by companies that update their models without notice. That produces three consequences for the rating. The inventory stays incomplete, because how some systems work is unknown. Human oversight isn't demonstrable, because the logs are missing. Changing supplier means losing the history, which leaves the club dependent on choices it doesn't control. The knot appears twice, on technical data and on public data. In the second case the supplier is the ticketing platform or the social network, and the share of supporters reachable directly is the practical measure of how much the club controls its own base. While that knot stays tied, the Readiness dimension doesn't rise and the class stays low however orderly the governance is. ## Athletes are workers, and that changes everything This is the classification that surfaces late in clubs and reframes the picture. Systems used to evaluate, select or manage contracted athletes fall among the worker management systems of Annex III when they affect contractual decisions. Many organisations have never made that classification, and consequently hold neither a risk assessment nor documentation on those systems. The finding isn't about the usage, it's about the absence of a documented decision on how those systems should be treated. ## The profile of a federation In federations and sports promotion bodies the profile flips against the club on two dimensions. Readiness is higher on data, because registration is managed internally and the database exists, often with a long history. Risk is more exposed, because that same data concerns mostly minors and includes medical fitness certificates. There is also an element clubs never see. If the body runs systems deciding admission to courses or assessing exams for coaches and match officials, those systems fall under Annex III, and the classification has to be made however routine the process looks. Where the body counts as a public-law body, further assessment and transparency obligations apply, worth checking in advance. ## What a class means in practice | Class | Typical situation in a club | What's reasonable to do | |---|---|---| | D | Supplier systems used without mapping, no classification | Map suppliers and data before adopting anything else | | C | System map in place, no control over the data | Renegotiate contracts on access and export, on the technical side and the public side | | B | Data access secured, classification done, partial oversight | Complete documentation on systems touching athletes | | A | Mature system verified across all dimensions | Reserved for verified assessments, not self-assessments | Moving from C to B in a sports organisation is almost always contractual work before technical work, which surprises anyone expecting an intervention on the systems. ## Why measure before signing In sport the useful moment for a rating isn't the start of the financial year, it's when a data supplier contract comes up for renewal. That's when the club holds leverage to obtain access, export rights and documentation, and without an assessment done beforehand that leverage gets spent on price alone. A club renewing for three years without clarifying what it can export locks its Readiness growth for the full contract term. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), which in a sports organisation should be built from the list of suppliers and outbound data flows. The full model, with the four dimensions and the gate logic, is on the [AI Rating](/en/services/ai-rating) page. The sector's regulatory picture is on the [AI governance for clubs and sports organisations](/en/sectors/sport) page. For an assessment of your club's position you can [book a meeting](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # The EU AI Act for Italian companies: an operational compliance guide URL: https://zerofive.ai/en/blog/compliance/eu-ai-act-guide-italian-companies Data: 2026-07-15 Abstract: The EU AI Act and Italy's Law 132/2025 for companies: risk on business processes, timeline after the Digital Omnibus, AgID and ACN authorities, penalties and six steps. The EU AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive regulation on artificial intelligence. For Italian companies the stakes are about governance, accountability and market access before they are technical. Whoever shows up prepared enters public tenders and European supply chains with a structural advantage, because enterprise clients already ask for AI Act attestations in their calls. Whoever arrives late risks fines of up to €35 million or 7% of global turnover. The timeline changed in 2026: the Digital Omnibus on AI, given final approval by the Council of the EU on 29 June 2026, deferred the heaviest obligations on high-risk systems. The prohibitions, the transparency duties and the enforcement powers stay firm; the most demanding part slips. This guide is for CEOs, boards, compliance and IT leaders in Italian companies that need to move from principles to concrete actions, and it folds in the national framework of Law 132/2025. ## The Italian picture: the AI Act plus Law 132/2025 The AI Act applies directly in Italy without transposition, but the national legislator added a further layer with Law No. 132 of 23 September 2025 ("Provisions and delegations on artificial intelligence"), in force since 10 October 2025. It is a framework law: several operational aspects, including the authorities' sanctioning powers, arrive through the implementing decrees expected within twelve months. Italian companies therefore have to read together: - Regulation (EU) 2024/1689 (the AI Act) for obligations, prohibitions and penalties. - Law 132/2025 for the national framework: principles, competent authorities, use of AI in public administration, healthcare, employment and justice. - AgID (the Agency for Digital Italy) as the notifying authority and ACN (the National Cybersecurity Agency) as the market surveillance authority, with inspection and sanctioning powers. - The Italian Data Protection Authority (Garante Privacy) for anything touching personal data, profiling and automated decisions under the GDPR. For AI systems used by banks, insurers and financial markets, market surveillance stays with Banca d'Italia, CONSOB and IVASS. For an Italian company, AI compliance is never only the AI Act: it is the combination of the AI Act, the GDPR, NIS2 and DORA for finance, plus sector-specific rules. ## The four risk categories applied to business processes The AI Act classifies systems by risk. The operational key is to reason by use case and business process, not by technology. ### 1. Unacceptable risk: prohibited since 2 February 2025 Prohibited practices include: - Generalised social scoring of citizens or employees. - Emotion recognition in the workplace and in schools (with very narrow medical or safety exceptions). - Biometric categorisation used to infer ethnicity, political opinions, sexual orientation or religion. - Subliminal or manipulative techniques that alter behaviour in harmful ways. - Predictive policing based solely on profiling. Typical impact for Italian companies: aggressive HR analytics, employee sentiment-analysis systems, behavioural surveillance tools in call centres or retail. These must be reviewed or dismissed immediately. The Digital Omnibus adds, from 2 December 2026, a prohibition on AI systems that generate non-consensual intimate imagery or child sexual abuse material. At national level, Law 132/2025 also introduced a criminal offence for the distribution of harmful deepfakes (Article 612-quater of the Criminal Code). ### 2. High risk: the core of compliance This is where most of the work sits. A system is high-risk if it falls under Annex III or if it is a safety component of an already-regulated product (such as medical devices, machinery, automotive, toys or lifts). High-risk cases that recur in Italian companies: - HR and recruiting: CV screening, candidate ranking, performance evaluation, decisions on promotions and dismissals. - Credit and insurance: credit scoring of individuals, life and health insurance pricing, anti-fraud with an impact on access to services. - Training and education: systems that assess students, admit them to programmes or assign scores. - Critical infrastructure: traffic, energy and water networks, telecommunications. - Essential public services: eligibility for benefits, medical triage, prioritisation of access to services. - Law enforcement and migration: assessing the reliability of testimony, document verification. - Administration of justice: interpretive support, case-law research with a bearing on decisions. For each high-risk system the AI Act imposes a package of obligations: - A risk-management system documented across the entire lifecycle. - Data governance: quality, representativeness and traceability of the training, validation and test datasets. - Technical documentation compliant with Annex IV, updated at every relevant release. - Automatic logging of relevant events (input, output and human override). - Transparency toward the deployer: instructions for use, limits and expected operating conditions. - Effective, not theoretical, human oversight: who controls it, with what competence, with what power to intervene. - Accuracy, robustness and cybersecurity proportionate to the risk. - A quality management system that holds the previous points together. - A conformity assessment before placing on the market, CE marking and registration in the EU database. - Post-market monitoring and reporting of serious incidents within the required deadlines, typically 15 days. ### 3. Limited risk: transparency obligations Chatbots, virtual assistants, generators of synthetic content (text and images, audio and video). The user must know they are interacting with an AI or that the content is generated or artificially altered. Deepfakes and synthetic content must be labelled in a machine-readable way (watermarking, provenance metadata). ### 4. Minimal risk: no specific obligation Spam filters, low-impact recommendation engines, video games. There are no binding obligations, though adopting the voluntary codes of conduct provided by the AI Act is still advisable. ## GPAI models: the cross-cutting obligation Providers of General Purpose AI models (frontier LLMs and beyond) must publish technical documentation, information for integrators, an EU copyright-compliance policy and a public summary of the training data. Models with systemic risk (indicative threshold of 10^25 training FLOPs) carry additional obligations for evaluation, systemic-risk mitigation, cybersecurity and reporting. For Italian companies that integrate third-party GPAI into products or processes, the obligation shifts: you become a downstream deployer or provider, and you have to assess whether the use configures a high-risk system under Annex III. ## The Digital Omnibus: what changed in 2026 By the summer of 2026 it had become clear that the technical standards and the competent authorities would not be ready in time for the high-risk obligations to apply. The European Commission proposed the Digital Omnibus on AI on 19 November 2025; the European Parliament approved it on 16 June 2026 and the Council of the EU gave its final green light on 29 June 2026. The package does not touch the architecture of the Act, the risk-based approach stays. It moves the most demanding deadlines and introduces a few targeted changes: - **High-risk obligations deferred.** Stand-alone Annex III systems move from 2 August 2026 to 2 December 2027. Systems embedded in regulated products under Annex I move from 2 August 2027 to 2 August 2028. - **New prohibition.** From 2 December 2026, AI systems that generate non-consensual intimate imagery or child sexual abuse material are banned. - **Watermarking deferred.** The provider obligation to machine-readably mark generated content (Article 50(2)) applies from 2 December 2026 for systems already on the market at 2 August 2026. The other transparency obligations remain at 2 August 2026. - **Sandboxes deferred.** The deadline for Member States to establish at least one national regulatory sandbox slips to 2 August 2027. - **Lighter load for smaller players.** The exemptions available to SMEs are extended to small mid-caps. ## The updated roadmap for Italian companies - **2 February 2025**: prohibitions on banned practices and an AI literacy obligation for staff who use or manage AI, at any risk level. - **2 August 2025**: EU governance operational, obligations for GPAI models, penalty regime applicable. - **2 August 2026**: most provisions apply, including the Article 50 transparency obligations and enforcement powers. This is no longer the high-risk date. - **2 December 2026**: watermarking of generated content for systems already on the market, and the new prohibition on non-consensual intimate imagery and child sexual abuse material takes effect. - **2 August 2027**: deadline for Member States to establish national regulatory sandboxes. - **2 December 2027**: full application for stand-alone high-risk systems under Annex III. - **2 August 2028**: application to high-risk systems embedded in products already covered by EU safety legislation. Penalties are structured on three levels: - Up to €35 million or 7% of global turnover for prohibited practices. - Up to €15 million or 3% of global turnover for breaches of high-risk obligations. - Up to €7.5 million or 1% of global turnover for incorrect information to authorities. For SMEs and startups the amounts are reduced but not zero. ## Six operational steps to start today - **Company AI inventory**: map every AI system, in-house or SaaS, with its business owner, the data processed and the decisions it influences. No compliance is possible without an inventory. - **Risk classification by use case**: apply the logic of the AI Act and document the reasons for the classification. - **Gap assessment**: for each high-risk system, check the presence of risk management, data governance, logging and human oversight, alongside the technical documentation. - **Internal governance**: appoint an AI Officer or strengthen a cross-functional AI committee (Legal, IT, Security, HR, Business). Define the delegations toward the board. - **Integration with existing frameworks**: align the AI Act with ISO/IEC 42001, the NIST AI RMF and the obligations of the GDPR, NIS2 and DORA. Reuse the controls already in place. - **Widespread AI literacy**: train everyone who interacts with AI, not just the technical staff. It has been an obligation since 2 February 2025. ## How to integrate the AI Act, ISO 42001 and Law 132/2025 The more mature companies are building a single AI governance model that holds together: - The AI Act as the mandatory compliance baseline. - ISO/IEC 42001 as the certifiable standard for the AI management system, useful in tenders and in relationships with enterprise clients. - Law 132/2025 for the national aspects (use in public administration, employment, healthcare, justice). - The NIST AI RMF as the operational framework to manage risk, measure it and improve it. - The GDPR, NIS2 and DORA for the connected domains such as data, cybersecurity and finance. The advantage is twofold: you reduce duplication of controls and you build a single body of evidence usable in audits, tenders and commercial negotiations. ## Priorities for the board If you sit on the board or in the leadership of an Italian company, three priorities: - Start the AI inventory this week. You do not need a tool: you need a shared worksheet with the process owners. - Ask for a risk classification of the first five use cases. Document who decided and on what grounds. - Put AI governance on the board agenda at least every quarter, with compliance and adoption KPIs. The AI Act is also an opportunity: to build a structural competitive advantage while others postpone. Deferring the high-risk obligations to 2 December 2027 opens a useful window, provided it is used to prepare rather than to stop. If you want to understand where you stand on the compliance path, consider our AI Rating: an assessment that measures AI maturity across four dimensions, with a report you can use in the boardroom and with enterprise clients. --- # EU AI Act: a practical compliance guide for companies and boards URL: https://zerofive.ai/en/blog/compliance/eu-ai-act-compliance-guide-businesses Data: 2026-07-15 Abstract: The EU AI Act for companies: risk-based obligations, timeline updated after the Digital Omnibus, fines up to 35M EUR and a 90-day roadmap for CEOs and boards. The EU AI Act is the world's first comprehensive regulation on artificial intelligence. It has been in force since 1 August 2024 and its provisions apply on a staggered timeline between 2025 and 2028. In 2026 that timeline was revised: the Digital Omnibus on AI, given final approval by the Council of the EU on 29 June 2026, pushed back the heaviest obligations, the ones covering high-risk systems. For an Italian CEO or board the question stays operational: what do we have to do, by when, and who is accountable if we don't. This guide summarises the real obligations for companies that use, integrate or develop AI, the timeline updated after the Omnibus, and a 90-day operational roadmap designed for mid-to-large organisations. ## Who is in scope: provider, deployer, importer, distributor The regulation defines four roles, and the same company can hold more than one across different systems. **Provider**: whoever develops or places an AI system on the market under its own name, including when an open-source model is used inside a product. This is the role with the most obligations. **Deployer**: whoever uses an AI system in the course of its own activity (a bank adopting a scoring model, an HR function introducing CV screening, a healthcare organisation integrating diagnostic support). This is the most common role. **Importer and distributor**: whoever brings third-party non-EU AI systems onto the EU market or resells them. A common mistake is to think "we buy software, so we are not the provider". If a bank customises a credit-scoring model, integrating it into its own processes with proprietary data, in many scenarios the role shifts and responsibilities grow. The first compliance action is therefore to correctly classify your role for every AI system in use. ## The four risk categories The AI Act does not regulate AI in the abstract: it regulates use cases based on risk. **Unacceptable risk: prohibited.** Public social scoring, subliminal manipulation, emotion recognition in the workplace and at school, biometric categorisation used to infer sensitive data such as race, political opinions or sexual orientation. These prohibitions have applied since 2 February 2025. The Digital Omnibus adds a new prohibition, applicable from 2 December 2026, on AI systems that generate non-consensual intimate imagery of real people or child sexual abuse material. **High risk.** Systems used in the sensitive areas listed in Annex III: HR (screening, evaluation and employment decisions), credit and insurance for individuals, education, critical infrastructure, justice and migration, safety components of already-regulated products such as medical devices. This is where most of the compliance effort sits. **Limited risk: transparency obligations.** Chatbots, synthetic content generation and deepfakes: the user must know they are interacting with an AI or that the content is generated. **Minimal risk.** Spam filters, video games and internal optimisations. No formal obligation, though applying a minimum level of governance still makes sense. ## Concrete obligations for high-risk systems For a system classified as high-risk, the provider must have in place, before placing it on the market: - A risk-management system documented across the entire lifecycle. - Data governance: quality, representativeness and bias of the training, validation and test datasets. - Technical documentation compliant with Annex IV and instructions for the deployer. - Automatic logging of relevant events for traceability. - Human oversight designed "by design", not bolted on afterwards. - Accuracy, robustness and cybersecurity proportionate to the risk. - A conformity assessment (self-assessment in many cases, with a notified body in others) and CE marking. - Registration in the EU database of high-risk systems. - A quality system and post-market monitoring. The deployer has lighter but not zero obligations: use the system according to the instructions, ensure human oversight by competent staff, retain the logs, report serious incidents, inform workers when AI affects the employment relationship and, for the public sector and some private ones such as banks and insurers, carry out the Fundamental Rights Impact Assessment before use. ## GPAI models: what changes from 2 August 2025 Providers of General Purpose AI models (frontier LLMs and beyond) must publish technical documentation, information for integrators, an EU copyright-compliance policy and a public summary of the training data. Models with systemic risk (indicative threshold of 10^25 training FLOPs) carry additional obligations for evaluation, systemic-risk mitigation, cybersecurity and reporting of serious incidents to the AI Office. For anyone building products on top of a third-party LLM, this more structured documentation from providers still has to be integrated into their own, as a downstream deployer or provider. ## The Digital Omnibus: what changed in 2026 By the summer of 2026 it had become clear that the technical standards and the competent authorities would not be ready in time for the high-risk obligations to apply. The European Commission proposed the Digital Omnibus on AI on 19 November 2025; the European Parliament approved it on 16 June 2026 and the Council of the EU gave its final green light on 29 June 2026, with publication in the Official Journal expected in July. The package does not touch the architecture of the Act, the risk-based approach stays. It moves the most demanding deadlines and introduces a few targeted changes. - **High-risk obligations deferred.** Stand-alone Annex III systems (HR, credit, education and similar) move from 2 August 2026 to 2 December 2027. Systems embedded in regulated products under Annex I move from 2 August 2027 to 2 August 2028. - **New prohibition.** From 2 December 2026, AI systems that generate non-consensual intimate imagery or child sexual abuse material are banned. - **Watermarking deferred.** The provider obligation to machine-readably mark generated content (Article 50(2)) applies from 2 December 2026 for systems already on the market at 2 August 2026. The other transparency obligations remain at 2 August 2026. - **Sandboxes deferred.** The deadline for Member States to establish at least one national regulatory sandbox slips to 2 August 2027. - **Lighter load for smaller players.** The exemptions available to SMEs are extended to small mid-caps, and the legal basis for processing sensitive data solely for bias correction is broadened, subject to a strict necessity requirement. The months gained should be spent on conformity assessment, technical documentation and human-oversight design, not filed away as free time. ## The updated timeline to put on the agenda - **2 February 2025**: prohibitions on banned practices and AI literacy obligations for staff who use or manage AI. - **2 August 2025**: EU governance operational, obligations for GPAI models, penalty regime applicable. - **2 August 2026**: most provisions apply, including the Article 50 transparency obligations and enforcement powers. This is no longer the high-risk date. - **2 December 2026**: watermarking of generated content for systems already on the market, and the new prohibition on non-consensual intimate imagery and child sexual abuse material takes effect. - **2 August 2027**: deadline for Member States to establish national regulatory sandboxes. - **2 December 2027**: full application for stand-alone high-risk systems under Annex III. - **2 August 2028**: application to high-risk systems embedded in products already covered by EU safety legislation, such as medical devices, machinery and toys. ## Penalties: why the board must own this The penalty regime is tougher than the GDPR: - Prohibited practices: up to €35 million or 7% of worldwide turnover. - Breaches of obligations for high-risk systems or GPAI: up to €15 million or 3%. - Incorrect information to authorities: up to €7.5 million or 1%. On top of this sit reputational risk, contractual risk toward enterprise clients that already ask for AI Act attestations in tenders, and civil-liability risk in case of harm. ## 90-day roadmap for a mid-to-large company **Days 0-30, snapshot.** Inventory of AI systems in use and in the pipeline, with the business owner, the vendor and the data processed, plus the AI Act role (provider or deployer). Preliminary risk classification. Appointment of an AI compliance owner and formal involvement of the board. **Days 30-60, gap analysis.** For each high-risk or borderline system: review of the vendor's technical documentation, assessment of data governance, definition of effective human oversight, mapping of logs and incidents. Preparation of the Fundamental Rights Impact Assessment where required. **Days 60-90, operational plan.** Corporate AI policy, updates to vendor contracts (compliance SLAs, audit rights, incident notifications), an AI literacy plan for staff, integration with existing management systems such as ISO 27001 and ISO 9001 and, where it makes sense, a roadmap toward ISO/IEC 42001 as a certifiable AI management system. ## How it fits with ISO/IEC 42001 and the NIST AI RMF The AI Act is prescriptive and legally binding in the EU. ISO/IEC 42001 is a voluntary, certifiable management system that provides the organisational structure made of policies, roles and controls with internal audits, to meet the management obligations the Act requires. The NIST AI RMF is the operational framework for mapping, measuring and managing risk at the level of individual systems. For a European company with international exposure, the most effective combination holds three layers together: the AI Act as the regulatory constraint, ISO 42001 as the governance scaffolding, the NIST AI RMF as the technical method for managing risk at system level. The detailed comparison of the three frameworks is in our AI Governance deep dive. ## Where to start If the board does not yet have a formal view on the AI Act, the first step is not to buy a tool: it is to understand where you stand today and which systems to tackle first. Deferring the high-risk obligations to 2027 opens a useful window, provided it is used to measure your own maturity rather than to postpone. The AI Risk dimension of our AI Rating already measures much of what the Act requires you to govern: governance, data quality, risk management and security. An AI Rating or a targeted assessment gives the initial snapshot and the intervention priorities, so compliance becomes a manageable path and not an emergency. --- # NIST AI RMF, ISO/IEC 42001 and the EU AI Act: comparing AI governance frameworks URL: https://zerofive.ai/en/blog/ai-governance/comparing-ai-governance-frameworks Data: 2026-07-15 Abstract: Compare NIST AI RMF, ISO 42001 and the EU AI Act: obligations, certification and priorities. Comparison table, decision matrix and 7 shared AI governance artefacts. **In short.** If you sell or use AI in the EU, the EU AI Act comes first: it is law, not a choice. NIST AI RMF is the fastest way to organise AI risk without certification, useful in the first months. ISO/IEC 42001 matters when someone asks for external proof (tenders, enterprise buyers, audits) and costs more time and budget. All three overlap on system inventory, risk assessment, controls and documentation: build those artefacts once and reuse them. Below: the comparison by nature, scope, effort and certifiability, the decision matrix and the 7 shared artefacts. Deploying AI without a governance framework is like shipping a product without QA: sooner or later you pay the bill in incidents, fines or lost trust. Three global references dominate the space in 2025: **NIST AI RMF** (US, voluntary), **ISO/IEC 42001** (international, certifiable) and the **EU AI Act** (Europe, mandatory). They are not alternatives, they are complementary layers. This guide explains what each one does, where they overlap and how to combine them without duplicating work. ## The differences in 3 lines - **EU AI Act**: binding law in the EU. If you sell or use AI in Europe, start here. - **NIST AI RMF**: voluntary method, the fastest to adopt. No certification. - **ISO/IEC 42001**: the only certifiable one. Needed when someone asks for external proof. ## The three frameworks in one line | Framework | Mandatory? | Nature | Typical effort | Certifiable | Who uses it | |---|---|---|---|---|---| | **NIST AI RMF 1.0** | No | Voluntary guidance | Low (weeks) | No | Companies that want a method, not a certificate | | **ISO/IEC 42001:2023** | No | Certifiable standard (AIMS) | High (6-12 months) | Yes, third-party audit | Companies that must prove governance to buyers and tenders | | **EU AI Act (Reg. EU 2024/1689)** | Yes, if you operate in the EU | Binding regulation | Varies by risk class | No, but conformity duties apply | Anyone selling or using AI in the EU, in any capacity | ## NIST AI Risk Management Framework Published by the National Institute of Standards and Technology in January 2023, the **NIST AI RMF** is a voluntary framework built around four functions: **Govern, Map, Measure, Manage**. It is the most agile of the three: no certification, no obligations, but a shared vocabulary to talk about AI risk in a structured way. - **Govern**: define roles, policies and AI accountability. - **Map**: identify context, stakeholders and potential risks of each system. - **Measure**: measure performance, bias, robustness and explainability. - **Manage**: prioritise, mitigate and monitor risks over time. It is the natural **starting point**: no barrier to entry, it plugs into any internal methodology and lays the conceptual foundation for ISO 42001 or AI Act compliance later on. ## ISO/IEC 42001 **ISO/IEC 42001:2023** is the first international standard for an **Artificial Intelligence Management System (AIMS)**. It follows the same logic as ISO 27001 (information security) or ISO 9001 (quality): it defines verifiable requirements for a management system and is **certifiable** by accredited third parties. In practice it requires: - A top-management-approved AI policy. - Context and stakeholder analysis. - AI impact assessment (AIIA) of systems. - Lifecycle management: data, development, deployment, monitoring, decommissioning. - Internal audits and management review (PDCA cycle). It is the right choice when you need to **demonstrate** governance to customers, boards or regulators, an ISO 42001 certificate is a commercial asset, not just a compliance one. ## EU AI Act **EU Regulation 2024/1689** is the first horizontal AI law in the world. It entered into force on 1 August 2024 with staggered application: prohibitions from 2 February 2025, GPAI model obligations from 2 August 2025, high-risk system obligations from 2 August 2026. The AI Act classifies systems into four risk categories: 1. **Unacceptable risk**, banned (social scoring, cognitive manipulation, workplace emotion recognition, etc.). 2. **High risk**, subject to strict requirements (risk management, data governance, technical documentation, transparency, human oversight, accuracy and cybersecurity). Covers HR, credit, education, justice, medical devices, critical infrastructure. 3. **Limited risk**, transparency obligations (e.g. chatbots, deepfakes). 4. **Minimal risk**, no specific obligations. Separately, **GPAI models** (General-Purpose AI) have a dedicated regime with reinforced obligations for those with "systemic risk". Fines reach up to **EUR 35 million or 7% of annual worldwide turnover**, the highest ceiling of any European digital regulation, GDPR included. ## Side-by-side comparison | Dimension | NIST AI RMF | ISO/IEC 42001 | EU AI Act | |---|---|---|---| | **Mandatory?** | No | No (but certifiable) | Yes, if you operate in the EU | | **Certifiable?** | No | Yes, by accredited bodies | CE marking for high-risk | | **Focus** | Risk management | Management system | Placing on the market | | **Fines** | None | None (loss of certificate) | Up to EUR 35M or 7% revenue | | **Adoption cost** | Low | Medium-high | Variable by risk category | | **Recognition** | US and global | International | EU (extraterritorial) | | **Updates** | NIST releases | ISO review ~5 years | Commission delegated acts | ## EU AI Act obligations: what NIST and ISO actually cover The EU AI Act is the only mandatory layer, so the practical question is how much of it you already satisfy by running NIST AI RMF or ISO/IEC 42001. | EU AI Act obligation (high-risk) | NIST AI RMF | ISO/IEC 42001 | What is still missing | |---|---|---|---| | Risk management system (Art. 9) | Covered (Map, Measure, Manage) | Covered (clause 6, AI risk assessment) | Formal link to the specific legal risk classes | | Data and data governance (Art. 10) | Partially covered (Map) | Covered (Annex A controls on data) | Bias testing evidence and dataset provenance records | | Technical documentation (Art. 11, Annex IV) | Not prescriptive | Partially covered (documented information) | The Annex IV structure itself, to be produced explicitly | | Record keeping and logging (Art. 12) | Partially covered (Measure) | Covered (operational control) | Retention period and traceability of automated logs | | Transparency to deployers (Art. 13) | Partially covered | Partially covered | Instructions for use with the legally required content | | Human oversight (Art. 14) | Covered (Govern) | Covered (roles and competences) | Named oversight roles per system, with authority to stop it | | Accuracy, robustness, cybersecurity (Art. 15) | Covered (Measure) | Partially covered | Declared metrics and thresholds per intended purpose | | Quality management system (Art. 17) | Not covered | Covered (this is the core of the standard) | Nothing, if the AIMS is in place | | Conformity assessment and CE marking (Art. 43) | Not covered | Not covered | Specific legal procedure, not replaceable by any framework | | Post-market monitoring (Art. 72) | Partially covered (Manage) | Covered (monitoring and improvement) | Serious-incident reporting to authorities | Read it this way: NIST gets you the method, ISO gets you the management system and the external proof, but neither one delivers conformity assessment, Annex IV documentation or incident reporting. Those remain legal work you have to do on top. ## Where they overlap (and how to exploit it) The three frameworks are not competing: they **share 60-70% of controls**. Companies that implement one solidly have already done half of the work on the other two. Key overlaps: - **Risk assessment**: NIST "Map/Measure", ISO clause 6, AI Act art. 9. - **Data governance**: NIST "Measure", ISO Annex B, AI Act art. 10. - **Technical documentation**: ISO clause 7, AI Act art. 11 and Annex IV. - **Human oversight**: NIST "Govern/Manage", ISO Annex B, AI Act art. 14. - **Post-deployment monitoring**: NIST "Manage", ISO clause 9, AI Act art. 72. ## Which one should you pick? A scenario per profile **Startup or scale-up, B2B AI product in the EU.** Start from NIST to build the method, evaluate ISO 42001 when enterprise customers begin asking for it, check AI Act exposure (especially in HR, healthtech, fintech, edtech). **Large regulated company (bank, insurance, healthcare, public sector).** The AI Act is the binding constraint. ISO 42001 provides an auditable structure and integrates well with existing ISO 27001. NIST as the internal vocabulary for the risk team. **AI model or platform vendor.** The AI Act (GPAI regime) is mandatory. ISO 42001 is the commercial lever for enterprise clients. NIST as a baseline for red-teaming. **SME integrating third-party AI.** The main risk is vendor selection. NIST as a due-diligence checklist, contracts aligned with AI Act obligations, ISO 42001 only if and when it becomes necessary. ## How to start without wasting resources 1. **AI system inventory**: what you have, who uses it, what data it processes, what decisions it makes. 2. **AI Act risk classification**: which systems are banned, high-risk or limited-risk. 3. **Gap analysis against NIST AI RMF**: where you are today across Govern/Map/Measure/Manage. 4. **ISO 42001 roadmap** if certification has commercial value. 5. **Operational governance**: policies, roles, AI committee, monitoring KPIs. This is exactly the path we follow at ZeroFive with **AI Rating** and our **AI Governance** services: we start from measurement (where you are today), define priorities based on real risk, and build tailored governance, not a copy-paste of a standard. ## Decision matrix: what to do first, by company profile | Your profile | Start with | Add within 12 months | Trigger to move | First 90 days of effort | |---|---|---|---|---| | Startup or scale-up, AI product sold in the EU | NIST AI RMF | AI Act classification | First enterprise security questionnaire | 10 to 15 person-days | | Bank, insurer, healthcare, public sector | EU AI Act classification | ISO/IEC 42001 on top of ISO 27001 | High-risk system identified in the inventory | 30 to 45 person-days | | Model or platform vendor (GPAI) | EU AI Act GPAI obligations | ISO/IEC 42001 | Model placed on the EU market | 25 to 40 person-days | | SME integrating third-party AI | NIST AI RMF as vendor due diligence | Contract clauses aligned to AI Act art. 25 | Vendor renewal or new AI tool | 5 to 8 person-days | The mistake we see most often is starting from certification. Certification is an output, not a strategy: without an inventory and a risk classification, an ISO 42001 project prices itself two to three times higher, because the scope is undefined. ## What each framework actually costs | Item | NIST AI RMF | ISO/IEC 42001 | EU AI Act (high-risk) | |---|---|---|---| | Internal effort, first cycle | 15 to 30 person-days | 60 to 120 person-days | 80 to 200 person-days per system | | External cost | Optional advisory | Audit and certification fees, plus advisory | Conformity assessment, notified body where required | | Time to first usable evidence | 4 to 6 weeks | 6 to 9 months | Tied to the 2 August 2026 deadline | | Recurring cost | Internal review | Surveillance audits, 3 year cycle | Post-market monitoring, incident reporting | Ranges assume a mid-sized organisation with 5 to 15 AI systems in scope. The variable that moves the number most is not the framework, it is how many systems you run and how well documented they already are. ## Build once, use three times: the reuse map | Artefact you produce | NIST AI RMF | ISO/IEC 42001 | EU AI Act | Reuse | |---|---|---|---|---| | AI system inventory | Map | Clause 4, context | Art. 9, art. 11 | High | | Risk assessment per system | Map, Measure | Clause 6 | Art. 9 | High | | Data governance record | Measure | Annex B | Art. 10 | High | | Technical documentation | Manage | Clause 7 | Art. 11, Annex IV | Medium, the AI Act is stricter | | Human oversight design | Govern, Manage | Annex B | Art. 14 | High | | Logging and monitoring | Manage | Clause 9 | Art. 12, art. 72 | Medium, retention rules differ | | Incident procedure | Manage | Clause 10 | Art. 73 | Medium, 15 day reporting is AI Act specific | Treat these seven artefacts as a single documentation set with three audiences. Organisations that keep three parallel binders spend roughly double and still fail audits, because the versions drift. ## Three questions a board should ask before approving budget 1. **How many AI systems do we actually run, including the ones bought inside SaaS tools?** If nobody can answer within a week, the inventory is the project, not the framework. 2. **Which of them make or materially influence decisions about people?** Those are the ones that pull you into AI Act high-risk territory and into reputational exposure. 3. **What evidence could we produce tomorrow if a customer or a regulator asked?** The gap between what you believe and what you can show is the real maturity score. ## In summary - **NIST AI RMF** is the vocabulary and the method. - **ISO/IEC 42001** is the certifiable management system. - **EU AI Act** is the law you must comply with if you operate in the EU. They are not alternatives: they are layers. Companies that treat them as mutually exclusive options end up doing the same work three times. Companies that integrate them build AI governance that is defensible in front of boards, customers and regulators, and they get there in months, not years. ## How we do this with companies Turning these three layers into a system that holds up in front of boards, customers and regulators is exactly what our [AI governance consulting](/en/ai-governance) does. When the pressing issue is the regulatory deadline, the specific track is [EU AI Act compliance consulting](/en/compliance-ai). To find the concrete starting point, the [AI Rating](/en/servizi/ai-rating) measures current maturity and returns the priorities for the first months. The full picture is on [AI consulting for enterprises](/en/servizi). To discuss your case: [book a 30 minute call](https://calendly.com/fabiolalli/zerofive). --- # "The board wants an AI strategy": where to start in 90 days URL: https://zerofive.ai/en/blog/strategy/ai-strategy-90-days Data: 2026-07-14 Abstract: When the board asks for an AI strategy, the temptation is starting from tools. The 90-day sequence: measure, choose, launch the first validation, with the board deliverables. The phone call this story opens with now reaches us every month, with minimal variations: the board has asked for an AI strategy by next quarter, the assignment has landed on a capable and suddenly lonely executive, and the instinctive first move, already on the agenda, is a round of vendor demos. It is the move this series has spent six months advising against, and the piece that closes it wants to offer the alternative in executable form: the ninety-day sequence, with the weeks counted and the deliverables the board expects to see. The premise that orders everything sits in a distinction: the board is not asking for a list of technologies, it is asking where AI serves the business, what it costs, what it risks and who answers for it. That question is not answered by starting from tools, it is answered by starting from a photograph. ## Weeks 1-4: the photograph The first month produces the factual base that makes every subsequent decision honest, and it runs two parallel workstreams. The first is the maturity measurement on the four dimensions readers know, Readiness, Delivery, Risk and Confidence: where we are prepared, where we know how to execute, what we are permitted to do, who believes in it. The second is the census of what already exists, the ongoing projects with their true status, the systems in use including the never-authorised ones, because in over 90% of companies, MIT counted (2025), shadow AI is the de facto strategy awaiting the official one. The end-of-month deliverable is the declared starting point: the rating with the gaps named, the inventory, and the first uncomfortable truth to bring to the top, which almost always concerns data or governance, not models. ## Weeks 5-8: the choices The second month turns the photograph into a portfolio. The use case discovery collects candidates from every function, the prioritisation grid orders them with weights decided beforehand, the Canvas forces the top three to five to answer the six questions on one page, opportunity, risks, priority, stakeholders, capability, dependencies, and the go/no-go criteria fix the thresholds that will decide in place of opinions. In parallel starts the minimal governance that cannot wait for the perfect plan: the systems register, the named responsibilities, the everyday-usage policy that turns shadow AI into governed adoption. The deliverable at the end of month two is the motivated portfolio: what we do, what we do not do and why, with the nos written next to the yeses, because a strategy that discards nothing is not a strategy, it is a wish list. ## Weeks 9-13: the test and the plan The third month does the thing that separates a strategy from a document: it starts verifying it. The use case at the top of the portfolio enters validation with the protocol we know, golden set, signed thresholds, stopping conditions, three weeks; the outcome, whatever it is, becomes the strategy's first real data point, and a no at this stage is worth as much as a yes, because it costs weeks instead of quarters. Around the test the rest closes: the twelve-to-eighteen-month roadmap with the workstreams sequenced, the measurement model that will say every quarter whether the plan is working, the compliance chapter with the real deadlines, August's and 2027's, inside the plan instead of beside it. On day ninety, in front of the board, the deliverables are four: the photograph with the rating, the portfolio with its nos, the outcome of the first validation, the roadmap with governance and measures. No transformation promises, no tools recommended on faith: a measured position and a verifiable plan, which is exactly what a governing body can approve without pretending to understand what was never explained to it. ## Closing the circle Whoever has read this series from the beginning will recognise in the ninety days the miniature of the whole journey: measure first, decide next, always validate, govern while doing. We opened it in January with the stuck pilots and we close it with their antidote, and with the one number from the Politecnico Observatory (February 2026) worth repeating a final time: 71% of large companies have AI projects, 9% have structured governance. The ninety-day strategy is, at bottom, the bridge between those two numbers. It is also, plainly said, the work we do: the whole sequence, from the rating to the approved roadmap, is the ZeroFive journey, and the first conversation costs half an hour of calendar, calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. If the phone call we opened with has reached you too, the right question to start with is not which tool to choose. It is: what do we know, today, about where we really are? --- # AI adoption in sport: clubs and federations start from different points URL: https://zerofive.ai/en/blog/strategy/ai-adoption-sports-clubs-first-use-case Data: 2026-07-13 Abstract: Scouting and fan engagement have different verification cycles. The candidate map, the contractual cost of data, and ownership in small organisations. **In short.** In a sports club the two areas with the most expected value are scouting and the relationship with the public, and they carry opposite risk profiles: scouting on professional athletes falls among worker management systems, while fan engagement stays low risk. The first use case is better taken from the second group, even when the first looks more strategic. The reason isn't caution, it's that commercial revenue is measurable within a season while technical impact takes years. In a federation or a sports promotion body the starting point shifts again, towards the administrative load around registrations. In sports organisations the AI conversation almost always starts on the pitch, because that's where the club's success is measured. It's also the area where it's hardest to show that a model added anything to the judgement of someone who has watched matches for twenty years. ## Why the pitch is hard to measure A scouting model produces a recommendation, the club signs a player, and the result shows over two or three seasons, shaped by injuries, the coach, the dressing room and the transfer market. Attributing that result to the model is nearly impossible, and it makes any business case built on that ground fragile. Fan engagement works the other way. A season-ticket renewal campaign with assisted segmentation produces a number comparable with the previous season, within the season itself. This doesn't mean scouting has no value. It means that as a first use case it doesn't allow learning, because the verification cycle is longer than management's attention cycle. ## The map of candidate use cases | Use case | Value | Regulatory friction | Suitable as first | |---|---|---|---| | Segmentation for season-ticket campaigns | High and measurable within a season | Low, GDPR profiling | Yes | | Content production for club channels | Medium, in time saved | Low, disclosure obligation | Yes | | Assistant for supporter services | Medium | Low, Article 50 | Yes | | Video analysis for technical staff | Medium, in working hours | Medium, depends on use | As a second step | | Dynamic ticket pricing | High | Low, disclosure obligations | Yes, with attention to reputation | | Content and product recommendation on owned channels | Medium | Low, GDPR profiling | Yes | | Support to affiliated clubs on registrations and rules | High in hours freed | Low, member data | Yes, for federations and bodies | | Scouting and athlete evaluation | High but slow to verify | High, Annex III | No, not as a first | The fifth row carries a note that isn't regulatory. Dynamic pricing works and generates reactions among supporters, and in sport the public's reaction is a real cost. The decision should be made knowing that. ## The constraint nobody budgets for In a club the data sits across different suppliers: tracking with one, video with another, CRM with a third, ticketing with a fourth. None of them talks to the others, and contracts rarely provide for export. This is the real cost of entry, and it almost never appears in an AI project quote. Before any interesting use case you need to know which data the club can actually use, and that is contractual work before it is technical. Anyone starting without doing it builds a pilot on a manual export that won't be repeatable in production. ## How many supporters the club actually knows Assisted segmentation produces results on the share of the public the club holds in its database, and in almost every club that share is smaller than management assumes. Season-ticket holders are identified, single tickets often pass through resellers that return aggregated data, the audience on social channels belongs to the platform, television viewers belong to the broadcaster. The number to have before framing any commercial use case is one: how many supporters the club can contact directly, with valid consent and a database that holds ticketing, e-commerce, app and newsletter together. If that number is low, the first budget is better spent on collecting and unifying the data, ahead of any model. The reverse also holds. A club with a broad identified base already has in house the condition that makes the first use case measurable, and often doesn't know it, because that data lives inside four systems nobody has ever lined up. ## In federations the starting point is administration A federation has a different revenue structure from a club and a far heavier administrative load, so the first use case changes. The measurable value sits in the requests coming from affiliated clubs: registrations to check, documents to read, rules to interpret, deadlines to enforce. The advantage of this ground is that the volume is known and seasonal. A federation knows how many files arrive between July and September and how many hours it takes to clear them, which makes the baseline easy to build. One limit belongs in the plan. Administrative data holds information on minors and medical certificates, which raises processing requirements even when the use case looks harmless. An assistant reading registration files works on special category data under the GDPR, with everything that follows on legal basis, access and retention. ## What it takes to call it a pilot Three elements, defined beforehand. The measured baseline, which in sport means the previous season's figure on the same perimeter. Acceptance criteria set before seeing results. The exit plan, meaning what happens if it works, which in a club also means who will run it once the consultant has gone. On that last point sports organisations carry a structural fragility: headcounts are small and competence concentrates in few people. A system requiring continuous oversight without anyone to provide it is a system that won't be used in six months. ## Ownership in a small organisation The principle matches other sectors, with one complication: in a club ownership can't sit with someone already at capacity. The sporting director has no time to govern a platform, and IT is often one person or an external supplier. The workable answer is assigning responsibility to whoever uses the system daily, typically the match analyst for the technical side and the CRM manager for the commercial side, with a management contact accountable for adoption decisions. ## Where to start The sequence begins with the map of suppliers and data, even before the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), because in a club the two nearly coincide. The general selection criteria are in [AI adoption: how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case), and the cost model in [AI project budgeting](/en/blog/strategy/ai-project-budget-pilot-production). The sector's regulatory picture is on the [AI governance for clubs and sports organisations](/en/sectors/sport) page. To assess which use cases make sense in your club, you can [book a meeting](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in sport: two populations in clubs, three in federations URL: https://zerofive.ai/en/blog/compliance/ai-literacy-sports-clubs-training Data: 2026-07-10 Abstract: Technical and commercial staff fall under different regimes. The match analyst as critical role and the problem of supplier-owned data. **In short.** A sports club has two populations using AI for opposite purposes: technical staff, working on data from contracted athletes and therefore on systems classified as high risk, and commercial staff, working on content and the public. Training has to be separated, because the obligations differ. The critical role is the match analyst, who in most clubs has no formalised position on the org chart and almost never appears in a training plan. In federations and sports promotion bodies the populations become three, because the administrative one joins in, the largest of the three and the most exposed on the handling of member data. In sports organisations, mandatory training exists for safety, anti-doping and sometimes sporting integrity, and doesn't exist as a structured framework. That is the main difference from banks and insurers, and it changes the starting point: here it isn't about extending a system, it's about building a minimal one. ## Two populations, two regimes Technical staff work on systems touching contracted athletes. Scouting, performance evaluation, workload management: when those systems affect contractual decisions they fall among the worker management systems of Annex III, because a professional athlete is a worker. Commercial staff work on content, ticketing and the relationship with the public, and on an asset clubs treat as marketing material rather than personal data: the supporter database. Segmenting season-ticket holders, personalising an offer, choosing who receives a campaign are processing activities under the GDPR, with legal bases to be stated and an additional question about minors, who make up a significant share of a sporting audience. On the AI Act side the obligations concern transparency, mainly Article 50, and the risk level is low. Treating both populations with the same module produces a plan that serves neither. Whoever analyses performance needs to know when a model is outside its range; whoever runs the club's channels needs to know what must be declared as artificially generated. ## In federations the populations become three In a federation or a sports promotion body a third population joins the other two, and it is the largest: the people working on registrations, affiliations, courses and administrative procedures. These are processes touching tens of thousands of people, largely minors, and they include medical fitness certificates, which are health data. Two areas deserve specific attention. The first is the training of coaches and match officials: systems that determine admission to a course, evaluate an exam or monitor a test fall within the education and vocational training area of Annex III, where the classification is high risk. Several federations have digitised those courses without realising they had entered that perimeter. The second concerns the role of the body itself. Where a federation acts as a public-law body, high-risk systems carry further obligations, starting with the fundamental rights impact assessment. It is a legal check worth doing in advance, because it changes how much documentation is required. ## The match analyst and their absence from training plans This is the figure at the centre of the question and the one almost no club has formalised. They receive data from external analytics suppliers, interpret it, and their readings feed decisions on line-ups, playing time and transfers. For this role the competence evidence has to be individual, because this is the person effectively exercising human oversight over the system. They need to recognise when a supplier's data is unreliable, how the model behaves on small samples, and when technical judgement should override the number. The other two roles needing individual evidence are the head of performance, accountable for the use of health data, and whoever in management approves the adoption of a platform. ## When the data doesn't belong to the club In clubs almost every system comes from suppliers: scouting platforms, wearables, tracking systems, video analysis tools. The club is a deployer and rarely has visibility on how the model is built or when it gets updated. This has a direct consequence for training: you cannot teach people how a system works when its workings are unknown. What can and must be done is to train them on what the system claims to do, what its known limits are, and what to do when the output doesn't add up. Requesting documentation from the supplier therefore becomes a training requirement as well as a contractual one. ## What to build and on what timeline | Audience | Content | Frequency | |---|---|---| | Technical staff and match analysts | Systems in use, known limits, when the data doesn't hold, how a departure is documented | On joining and at every platform change | | Performance and medical staff | Handling of health data, legal basis, who accesses what | Annual | | Commercial and communications staff | Disclosure obligations for generated content, limits on image use | Annual | | Marketing, CRM and ticketing | Legal basis for processing supporter data, profiling, consent, handling of minors | Annual | | Registrations, affiliations and administration | Member data, minors, fitness certificates, what an automated system may decide | Annual | | Training and qualifications | Systems assessing admissions and exams for coaches and match officials, Annex III obligations | On joining and at every platform change | | Management | What gets approved when signing off a platform adoption | On joining and before each new adoption | | Stadium operators | What is permitted on access control systems | Before each season | The last row is the one clubs underestimate most. Recognition systems in venues are the area with the strongest constraints, and whoever operates them needs to know what is and isn't allowed. ## When to train, inside a season Training in a club can't follow a corporate calendar, because the season sets the pace. Two windows work: pre-season training camp, when staff are together and matches haven't started, and the winter break. Outside those windows structured training competes with the fixture list and loses. It's a practical constraint worth accepting during planning rather than discovering in October. ## Where to start The prerequisite is the system inventory, which in a club mostly means mapping suppliers and understanding which data leaves the organisation. The guide is in [the AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001). From there the two populations get separated and the matrix built, described in [a roles-competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai). The full requirements are in [clause 7 explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained). The sector's regulatory picture is on the [AI governance for clubs and sports organisations](/en/sectors/sport) page. Our approach to role-based tracks is on the [AI Training](/en/services/ai-training) page. To review your club's situation, you can [book a meeting](https://calendly.com/fabiolalli/zerofive). --- # AI Act checklist: the internal audit in 10 verifications URL: https://zerofive.ai/en/blog/compliance/ai-act-checklist-internal-audit Data: 2026-07-09 Abstract: Ten evidence-based verifications for the internal AI Act audit before 2 August 2026: register, classification, transparency, literacy, suppliers, logs. One week of work. On Tuesday we lined up what kicks in on 2 August and what slips; today we keep the promise of the operational piece. What follows is the checklist we use for the rapid internal audit, ten verifications executable in one week by a small group, compliance, IT and one process owner, with a rule that applies to all of them: the answer is never "yes", it is a document. Each verification names the evidence that closes it, because an audit without evidence is a survey, and surveys defend nobody on 2 August. ## The foundations: knowing what you have **Verification 1, the inventory.** Does a register of AI systems exist, complete with those embedded in supplier products and those that entered from below without approval? Evidence: the register with its last-update date and owner. The fastest completeness test remains the comparison with reality: a tour with IT through network logs and expense reports almost always finds systems the register ignores. **Verification 2, the classification.** Does every system in the register carry a risk classification with a written rationale, not just a label? Evidence: the classification sheet per system. The rationale is what turns an opinion into a defensible position, and it is also what tells you which systems the postponement to 2027 applies to. **Verification 3, the prohibited practices.** Has somebody formally verified that no system falls into the prohibited practices, from social scoring to emotion recognition at work? Evidence: the minutes of the verification, with scope and date. It is the one point of the list where the sanction ceiling is the highest and tolerance is zero. ## The obligations kicking in now **Verification 4, transparency towards people.** Do the systems interacting with customers or employees disclose themselves as AI? Evidence: interface screenshots, collected system by system. **Verification 5, generated content.** Is the AI-produced or AI-manipulated content you publish recognisable as such, with a plan for the machine-readable marking enforceable from December? Evidence: the content policy and marked examples. **Verification 6, literacy.** Does the Article 4 obligation have evidence: who was trained, on what, when, with what coverage of the people operating the systems? Evidence: the training plan and attendance records. These are the three verifications most visible from outside, and therefore the first ones an authority or a complainant can test without even entering the company. ## The supply chain and endurance over time **Verification 7, the roles.** For every system, is it written who answers for it, and does the chain reach a single point accountable to the top? Evidence: the responsibility matrix. **Verification 8, the suppliers.** For purchased systems, do you have the provider's documentation, its classification, the clauses you need for your own deployer obligations? Evidence: the supplier file for the main systems; the questions to start from are the ones we published on vendor evaluation. **Verification 9, the data.** Do the AI uses of personal data have a documented legal basis and, where needed, a DPIA? Evidence: the processing register updated with AI uses, because GDPR never waited for the AI Act and the 15 million euro fine to ChatGPT's provider (Italian DPA, December 2024) reminded everyone. **Verification 10, the logs and the plan.** Do the relevant systems keep traces of their operations, and for the Annex III ones does a written roadmap to December 2027 exist? Evidence: the logging policy and the plan with dates and owners. ## How to read the score Ten verifications, ten pieces of evidence: the count of the ones you hold is your photograph, and the reading scale we use is blunt. Below four, the problem is not the AI Act, it is that the organisation does not know what it owns, and you restart from the inventory. Between four and seven, governance exists in patches, and the weeks until 2 August suffice to close verifications 4, 5 and 6, the publicly exposed ones. From eight up, you are in the equipped minority, and the real work is verification 10's plan, because your risk is not the August deadline, it is the 2027 queue. Honesty requires saying what this checklist is not: a certification of conformity, which no ten-point list can grant, and which we ourselves never promise. It is the instrument for knowing where you stand, which is the condition for deciding where to invest, and it is the same logic with which our AI Rating extends these ten verifications into a full gap analysis on the Risk dimension, with roadmap and priorities: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The week to execute it, between now and 2 August, is still there. How many of the ten pieces of evidence could you put on the table this morning? --- # AI Act, 2 August 2026: what actually kicks in and the actions to take now URL: https://zerofive.ai/en/blog/compliance/ai-act-august-2026-actions Data: 2026-07-07 Abstract: On 2 August 2026 the AI Act becomes generally applicable, with operational sanctions and transparency obligations. What stands after the Omnibus, what slips, and the actions for the next four weeks. Less than four weeks remain until 2 August 2026, and around the date two opposite narratives have formed, both wrong. The first, fed by the headlines on the Digital Omnibus package definitively adopted at the end of June, tells of a hollowed-out AI Act, obligations postponed and pressure gone. The second, fed by deadline anxiety, tells of a 2 August on which everything becomes enforceable for everyone. Reality, as often with this regulation, sits in the calendar read line by line, and the calendar says something precise: what slips concerns one category, what kicks in concerns everyone. ## What kicks in on 2 August, for everyone The date marks the regulation's general applicability and the full operability of the sanctions apparatus, with national supervisory authorities at full capacity and ceilings reaching 7% of global turnover for prohibited practices. The transparency obligations of Article 50 become enforceable, the ones touching the largest number of companies: systems interacting with people, customer-facing chatbots first among them, must disclose themselves; content generated or manipulated by AI, deepfakes included, must be made recognisable, with machine-readable marking becoming enforceable from 2 December 2026. The layers applicable for some time naturally remain in force: the prohibitions and the literacy obligation since February 2025, the rules on general-purpose models since August 2025. What slips, instead: the obligations for Annex III high-risk systems, credit scoring, HR, access to essential services, move to 2 December 2027, and those for Annex I regulated products to 2 August 2028. It is the heart of the Omnibus revision, and for those with systems in those categories it buys real adaptation time on technical documentation, human oversight and quality management systems. The correct reading of the postponement, though, requires a candour the sighs of relief avoid: bought time serves those who use it. Classifying the systems remains the prerequisite of everything, because without knowing what falls into Annex III you do not even know what the postponement applies to; regulated sectors, as we wrote for finance, remain inside supervisory obligations that slip by not a single day; and the 2027 deadlines have the property of all distant deadlines, they look distant until they no longer are. ## The actions for the next four weeks The list for reaching 2 August in order is short and verifiable. First: the census of systems that interact with people or generate content, from the website chatbot to the marketing tools, verifying that each discloses its nature where the norm requires it; it is the obligation with the widest exposure surface, because it is visible to anyone, competitors and complainants included. Second: the formal verification, put on record, of the absence of prohibited practices, which have been enforceable for a year and a half but from 2 August meet the full sanction ceiling. Third: the documentary evidence of the literacy required by Article 4, the programmes delivered, for whom, with what content, because it is the simplest question an authority can ask and the most embarrassing not to answer. Fourth: the systems register updated with each system's motivated classification, which is today's defence and the work plan towards 2027 at once. Fifth, for those with Annex III systems: the roadmap to December 2027 written now, with the long workstreams, data, logs, human oversight, started before the 2027 queue of consultants and certifiers resembles the GDPR one of 2018. Readers of this series will recognise that the five actions are not obligations invented for the deadline: they are the governance pieces we have written about for months, the register, the classification, the fluency, arrived at their appointment with the calendar. It is the thesis we opened the year with, and the deadline makes it verifiable: compliance is not produced under deadline, it is harvested, if governance has sown it. Our AI Rating includes the gap analysis on these obligations in the Risk dimension, with a ninety-day roadmap that for once has a reference date written in the Official Journal: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. And on Thursday we publish this piece's operational complement, the internal audit checklist in ten verifications, designed to be executed in one week. The time until 2 August is enough for exactly that. --- # AI Rating in insurance: the gate is the perimeter, not the process URL: https://zerofive.ai/en/blog/strategy/ai-rating-insurance-perimeter-gate Data: 2026-07-06 Abstract: Solid validation processes on too narrow a perimeter. The three categories of systems left outside and what each class means. **In short.** In insurance, AI Rating measures the same four dimensions as always, and the profile that emerges differs from banking: Delivery tends to be high thanks to existing model governance, while Risk stays exposed on one specific point, the systems that arrived from outside the actuarial function and never passed through validation. The gate blocking the class isn't a lack of processes, it's the perimeter those processes apply to. Insurers come to AI maturity measurement with a control framework more mature than almost any other sector. The result often surprises them, because the score doesn't reflect that maturity. ## The four dimensions through an insurance lens **Readiness** measures preparation, data, skills, infrastructure. In an insurer it is generally good on portfolio data and weaker on unstructured claims data, which is exactly where the most immediate use cases concentrate. **Delivery** measures the ability to reach production and maintain. It is the dimension where insurers sit above average, because the model lifecycle exists and works. The limit is that it applies to models recognised as such. **Risk** measures governance, compliance and ethics. The gap concentrates here. Annex III touches the core of the business, IVASS supervision is already present, and the data processed is often health data under Article 9 of the GDPR. **Confidence** measures management commitment, user trust and perceived robustness. In insurers it is often high within the technical function and low across the network, which uses tools without knowing what they do. ## The gate that closes: the perimeter, not the process The recurring profile is this: solid validation processes, applied to a narrower set of models than the regulation counts as AI systems. Three categories fall outside. Models bought from suppliers, where the company is a deployer and often has neither technical documentation nor visibility on updates. AI features switched on inside management software already in use, which nobody ever classified. Tools adopted by individual functions without passing through an adoption process. Until the inventory covers those three categories, the Risk dimension stays below threshold however good the validation of internal models is. And since the gates are non-compensable, the final class drops to the level of the constraint. ## Which actuarial models fall within the definition The most debated point in insurance assessments concerns which actuarial models fall within the regulation's definition of an AI system. The definition is broader than the one insurers use internally, and the practical consequence is that some models long treated as actuarial tools may fall inside the perimeter. Deferring that classification doesn't reduce the risk, it moves it: if the assessment gets made by an authority rather than by the company, it arrives with no room to prepare. The reasonable answer is to classify in writing, with the reasoning, including the cases where the conclusion is that a model stays outside. That documented reasoning is worth more than the conclusion. ## What a class means in practice | Class | Typical situation in an insurer | What's reasonable to do | |---|---|---| | D | Systems outside the actuarial function unmapped, no extended controls | Build the complete inventory before new adoptions | | C | Solid validation of internal models, incomplete perimeter | Extend model governance to third-party systems | | B | Complete perimeter, evidence in place, some areas exposed | Prepare for audit and control Annex III systems | | A | Mature system verified across all dimensions | Reserved for verified assessments, not self-assessments | On that last row it's worth being explicit: a self-assessment does not produce a class A, because that class presupposes a structured verification with checked evidence. ## Why measure before allocating An insurer in class C allocating budget to bring AI onto pricing pays twice: once for the project that won't clear the controls, and again to redo it once the gates are closed. The same money, spent first on extending the perimeter, produces an organisation able to absorb subsequent projects. This is why rating belongs at the start of the planning cycle rather than as a final check on decisions already taken. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), built around the three categories usually left outside. From there you verify the role for each system and extend the risk assessment. The full model, with the four dimensions and the gate logic, is described on the [AI Rating](/en/services/ai-rating) page. The sector's regulatory picture is on the [AI governance for insurance companies](/en/sectors/insurance) page. For an assessment of your company's position you can [book a meeting](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # AI adoption in insurance: which use case to start from URL: https://zerofive.ai/en/blog/strategy/ai-adoption-insurance-first-use-case Data: 2026-07-02 Abstract: The most valuable case is also the Annex III one. The candidate map, the unused model governance advantage, and the weight of ownership. **In short.** In an insurance company the choice of a first use case carries a constraint that doesn't exist elsewhere: the highest-value process, life and health pricing, is also the one classified as high risk under Annex III. The cases that can reach production immediately sit in claims, network support and back office. What separates those who reach production from those stuck at pilot is the system's owner, not the technology. In insurers, the AI conversation almost always starts from pricing, because that's where results are measured. It's also the point not to start from, for reasons about sequencing rather than merit. ## Two measures to keep apart Assessing an insurance use case takes two distinct measures, and overlapping them is what stretches projects by months. The first is economic value, concentrated in pricing, claims handling and fraud detection. The second is regulatory friction, meaning the governance work required before production. Life and health pricing sits high on both. Claims document handling sits mid-range on value and low on friction, which is why almost every successful path starts there. ## The map of candidate use cases | Use case | Value | Regulatory friction | Suitable as first | |---|---|---|---| | Reading and classifying claims documents | High in efficiency | Low | Yes | | Network support on products and terms | Medium | Low, Article 50 | Yes | | Search across regulation and internal circulars | Medium, in time saved | Low | Yes | | Claims fraud detection | High | Medium, depends on effect on the individual | As a second step | | Automated settlement of simple claims | High | Medium-high, affects entitlement to a benefit | Only with mature controls | | Life and health pricing | The highest | The highest, Annex III | No, not as a first | The row worth attention is the fifth. Automated settlement of low-value claims looks low risk because the amounts are small, and the criterion isn't the amount: it's whether the system affects recognition of entitlement to a benefit. ## The advantage insurers don't use Insurers hold a model governance framework few other organisations possess: independent validation, model documentation, second-line controls, an actuarial function that validates. That framework covers much of what the AI Act asks for high-risk systems, and in most cases it goes unused. The reason is organisational: new AI systems arrive from different functions, often digital or operations, and never pass through the validation process because nobody classified them as models. Extending the perimeter of existing model governance to AI systems costs less than building a parallel framework, and produces a more solid result, because that process has already been tested by a supervisory authority. ## What must exist before calling it a pilot Three elements need defining in writing before starting, and the first is the measured baseline of the current process: how many files per day, at what average time, with how much rework. Without that number the final assessment becomes an impression. The acceptance criteria, set before seeing results, because written afterwards they accommodate any outcome. The exit plan, meaning what happens if it works. In an insurer, moving to production requires integrations with policy and claims systems that were rarely estimated at pilot stage. ## The owner, not the technology The error blocking most projects isn't the choice of case, it's who answers for it. An AI system in production needs a named person accountable for its outcomes, and in an insurer that person sits in the technical function or in claims, not in IT. When ownership stays with IT the system gets maintained rather than governed: nobody decides when it's out of scope, nobody detects drift, and the control exists only in procedures. It's also the condition that weakens the company's position if that system ends up in a dispute. ## Where to start The sequence begins with the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), built while also looking at models already validated, because the regulation's definition is broader than the one insurers use internally. The selection rules are in [AI adoption: how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case), and the cost model from pilot to production in [AI project budgeting](/en/blog/strategy/ai-project-budget-pilot-production). The sector's regulatory picture is on the [AI governance for insurance companies](/en/sectors/insurance) page. To assess which use cases make sense in your company, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # AI agents in the enterprise: what they are, where they work, where they don't URL: https://zerofive.ai/en/blog/insights/ai-agents-enterprise Data: 2026-07-01 Abstract: AI agents plan and execute actions, not just answers: the criteria for seeing where they make sense, where they don't, and what changes for governance when systems act. The word of the year in the boardrooms we frequent is "agents", and like every word of the year it arrives wrapped in a fog worth clearing before signing budgets. An AI agent, stripped of the marketing, is a system that receives an objective instead of a question, decomposes the work into steps, uses tools, access to systems, search, code execution, corporate APIs, and carries the sequence forward correcting itself along the way, with variable degrees of autonomy from human intervention. The difference from the chatbot everyone knows lies in one verb: it does not merely answer, it acts. And it is that verb, not the technology itself, that changes the terms of the evaluation. ## The criterion separating the good cases Anyone selling agents will show impressive demos, and the demos will be real: the technology has made genuine strides, and production cases exist. The useful question for a decision maker is not whether agents work, it is where their properties meet the properties of the process, and the happy encounter has four recognisable conditions. Bounded perimeter: the agent performs well where the domain is circumscribed, the tools are few and known, the exceptions have a defined way out, and it performs badly in the open spaces where common sense must substitute for rules. Verifiable outcome: the agent's work must be checkable at low cost, by a machine or a human, because an output that costs more to verify than to produce erases the gain. Reversible error: the decisive question is what happens when it fails, and the answer must be "little", because the agent classifying tickets produces at worst a re-sort, while the one touching payments or customer communications produces damage with the same autonomy with which it produces value. Human checkpoints at the irreversible points: the designs that work place approval where the action stops being cancellable, not everywhere out of anxiety nor nowhere out of faith. The resulting map bears little resemblance to the proclamations: the first solid returns sit in the back office and operations, ticket triage and enrichment, reconciliations, case-file preparation, data and documentation maintenance, the same territories where the MIT research (2025) found the best ROI and the smallest budgets. At the opposite extreme, the agent with a broad mandate over high-stakes processes and irreversible actions is, at the state of the art, a bet no serious production case yet justifies. ## When the system acts, governance changes grade There is a point the enthusiastic plans skip, and it is the one the project's survival depends on: a system that acts is not governed like a system that answers. Identities and permissions become the heart of the design, because the agent operates on systems with credentials of its own, and the least-privilege principle stops being IT hygiene to become the difference between a contained incident and a structural one. The log of actions, not just of answers, becomes the evidence audit and regulators will ask for, and the stopping conditions, dear to readers of this series, here turn literal: thresholds that halt the agent on their own, action budgets per session, switches somebody knows where to find. The regulatory classification also needs redoing with fresh eyes, because autonomy shifts the risk profile: the same task that was harmless when assisted can, made autonomous, touch different categories and obligations, and the systems register must say who answers for the agent's actions with the same clarity it does for an employee. ## The sequence stays the same, with one extra test For the rest, agents deserve no special method: they deserve the usual method applied without discounts. The use case goes through prioritisation like the others, the PoC answers feasibility on the golden set, the MVP verifies real usage, with one additional test that for agents is mandatory, the red teaming of the perimeter: what the system does when facing hostile inputs, failing tools, ambiguous instructions, and how long a human takes to notice. In our chain this lives between PROTOT.AI for validation and AI Shift for controlled production, with perimeters and checkpoints signed before the first day of autonomy: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The test for the proposals on your table fits in three questions to the proposer: what is the most damaging action the agent can take on its own, who would notice and how fast, how is it undone. If the answers come back precise, you are talking to someone who has designed an agent. If they come back vague, you are talking to someone who has seen a demo. --- # AI literacy in insurance: why actuarial competence isn't enough URL: https://zerofive.ai/en/blog/compliance/ai-literacy-insurance-companies-training Data: 2026-06-30 Abstract: The three roles needing individual evidence, the agency network as forgotten perimeter, and what to reuse from mandatory professional development. **In short.** In an insurance company, AI training meets a workforce that already works with models, and that creates a false sense of coverage: actuaries know models, but the competence clause 7 requires concerns specific AI systems and how they affect people. The three roles needing individual evidence are those pricing life and health, those exercising human oversight, and those approving adoption. The agency network is the perimeter almost everyone forgets. Insurance companies start ahead of other sectors, because a culture of modelling has always existed. That's also why AI training gets undersized: if there are actuaries in the building, the competence seems to be there already. ## Why actuarial competence doesn't cover the requirement An actuary knows models better than anyone else in the company, and that doesn't answer what the standard asks. Clause 7 of ISO/IEC 42001 and Article 4 of the AI Act look at a different competence: knowing what a specific AI system does, recognising when its output needs checking, knowing who to report it to. The gap shows on three points. The first is the perimeter of models: many systems in use today don't originate in the actuarial function, they arrive inside purchased software or from external suppliers. The second is the effect on the individual, which is the AI Act's lens rather than that of actuarial technique. The third is documentation, because competence has to be demonstrated with evidence tied to roles, and professional experience is not in itself evidence under clause 7. ## The three roles needing individual evidence For most staff, awareness is enough. For three roles the evidence has to be named and tied to the specific system. **Those working on life and health pricing.** Annex III of the AI Act classifies risk assessment and pricing in these lines as high risk. Anyone operating on those processes must recognise when the model sits outside its validity range and how a departure gets documented. **Those exercising human oversight.** The Article 4 relief introduced by the Digital Omnibus concerns the general literacy level and doesn't touch competence obligations for these roles. Their evidence has to show the ability to intervene on that system, not attendance at a generic course. **Those approving adoption.** Management, the risk committee, the actuarial function that validates. A signature without understanding moves the finding from clause 7 to clause 5 on leadership. ## The agency network, the forgotten perimeter Clause 7.3 speaks of people working under the organisation's control, and in insurance that perimeter is wider than the payroll. Agents, sub-agents, agency staff and contracted brokers use quotation and support tools that embed AI, often supplied by the company itself. Almost no training plan covers them, because the HR system the plan is built from stops at employees. The auditor notices indirectly, spotting that someone met during the visit appears in no record. Two instruments work here: competence requirements in network agreements, and including the network in the professional development paths already required by IVASS rules for intermediaries, where an AI module can be grafted on without creating a new framework. ## What to reuse and what to build | Element | Already present in an insurer | What's missing for AI | |---|---|---| | Modelling culture | Yes, in the actuarial function | Extension beyond the actuarial function | | Professional development for the network | Yes, under IVASS requirements | A specific module on systems in use | | Model governance | Yes, for internal models | Extension to third-party models | | Training on health data | Yes, through GDPR | Link to the AI systems processing it | | Effectiveness verification | Quiz-based tests | Practical cases on real systems | The heaviest row is the third. Many pricing and fraud models come from suppliers, and on those the company is a deployer with its own obligations, including ensuring whoever uses them has the competence to do so. ## The module no vendor can write The useful part of the training requires information only the company holds: which systems are in production, which decisions they affect, which edge cases have emerged, who the contact is for anomalies, what happens after a report. Thirty or forty minutes per system, prepared by whoever knows that system. It's also the material that shows, in an inspection or in litigation, that human oversight genuinely existed rather than living in procedures. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), which in an insurer has to be built looking at actuarial models already in use too, because the regulation's definition of an AI system is broader than commonly assumed. From there you build the roles-competence matrix, described in [a roles-competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai), and separate awareness from verifiable competence. The full clause requirements are in [clause 7 explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained). The sector's regulatory picture is on the [AI governance for insurance companies](/en/sectors/insurance) page. Our approach to building role-based tracks is on the [AI Training](/en/services/ai-training) page. To review your company's plan, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # Change management for AI: why the tools are not enough URL: https://zerofive.ai/en/blog/insights/change-management-ai Data: 2026-06-23 Abstract: Installed AI systems are not adopted systems: what distinguishes change management that works, why middle managers decide the game and what to measure. There is a scene that repeats in the companies we visit: licences bought for everyone, the tool presented at the town hall with the customary enthusiasm, and six months later the usage dashboards telling another story, a minority using the instrument for real, a majority that opened it twice, and meanwhile, on personal phones, the unauthorised tools thriving. The MIT Project NANDA research (July 2025) photographed the paradox at scale: 95% of GenAI pilots with no P&L impact inside companies, and a flourishing shadow AI in over 90% of the same ones. People are not rejecting AI, they are rejecting AI the way we are bringing it to them. ## The misunderstanding about change AI change management fails almost always through the same misconception: it gets treated as communication, when it is redesign. The classic sequence, announcement, catalogue training, adoption campaign with posters and ambassadors, operates on awareness and leaves intact everything that determines behaviour: the process that never includes the instrument, the objectives rewarding the old way of working, the time nobody has freed for learning. McKinsey, in its State of AI research (2025), identifies workflow redesign as the factor with the largest impact on GenAI returns, and the finding also reads in reverse: where the workflow stays as before with a tool resting beside it, the return never arrives, and neither does adoption. The second leg of the misunderstanding concerns incentives, which speak louder than any campaign. If AI-gained productivity translates, in people's eyes, into headcount at risk or targets raised without counterpart, resistance is not irrational, it is a correct reading of the implicit contract, and no prompting course dissolves it. Organisations where adoption takes root have answered first the question everyone asks in silence, what happens to me if this works, and they answered it with verifiable commitments, not reassurances. ## Where the game is decided The point of the system where change lives or dies is middle management, and it is also the point programmes neglect most, squeezed as they are between top-level and operational training. Middle managers decide, through a hundred micro-choices a day, whether the new way of working is truly permitted: whether learning time is legitimate time or stolen time, whether the mistake made with the new instrument is forgiven like the one made with the old, whether AI-assisted output counts in the meeting. A programme that gives this layer no instruments, no time and no reason of its own to want the change is asking people to cross a bridge their managers never approved. Around this centre, the practices we see working have little spectacle about them: starting from the workflows where the pain is felt and the benefit is personal, not from the strategic-on-paper ones; using the first real users as designers of the rollout instead of testimonials; measuring adoption with usage and outcome numbers, not satisfaction surveys, and publishing those numbers with the same seriousness as business KPIs. And accepting a physiological timeline: the real adoption curve is measured in quarters, and the programmes declared victorious at month two are almost always measuring curiosity, not change. ## The link that closes the circle The regular reader will recognise the pieces interlocking here: the top's fluency sustaining the programme through difficult quarters, the common language keeping business, IT and risk from losing each other along the way, shadow AI as a symptom to read rather than repress, because it indicates exactly where the demand for instruments exceeds the official supply. Change management is not a workstream next to the others, it is the connective tissue, and in our rating model it lives inside Readiness and Confidence, the two dimensions where low scores best predict the pilots that will never scale. In the ZeroFive chain this work is called AI Culture, and it typically comes after assessment and strategy for a practical reason: change needs to know what it is changing towards. To build the programme on your real map: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The test to run meanwhile costs an hour and is worth an audit: take the most sponsored AI tool of the past year and look at three numbers, weekly active users against licences, usage at ninety days against usage at launch, and how many official processes include it in writing. The third number, almost always, explains the first two. --- # AI Rating in banking: which gate blocks the class, and why URL: https://zerofive.ai/en/blog/strategy/ai-rating-banking-four-dimensions-gates Data: 2026-06-16 Abstract: The four dimensions through a banking lens, the typical profile with Risk below threshold, the recurring gates and what each class means. **In short.** In banking, AI Rating measures the same four dimensions as anywhere else, Readiness, Delivery, Risk and Confidence, and weighs them differently. Where elsewhere a weakness on Risk is an area to improve, here it is a gate that blocks: an organisation with Annex III systems and no inventory cannot rise above class C, however advanced it is on everything else. The useful output isn't the score, it's knowing which gate is closed and why. Banks come to AI maturity measurement with one advantage and one disadvantage. The advantage is familiarity with rating systems: nobody needs an explanation of what a class or a non-compensable gate is. The disadvantage is the temptation to read the result as a grade, when it exists to decide where to intervene. ## The four dimensions through a banking lens **Readiness** measures preparation: strategy, data, skills, infrastructure. In banks it tends to be the highest dimension, because the data governance framework already exists for prudential reasons. The recurring weak point is the distance between data quality in risk systems and data quality in commercial processes, where many of the proposed use cases originate. **Delivery** measures the ability to reach production and maintain: release processes, monitoring, integration. Banks divide sharply here. Those with a structured model lifecycle for credit risk start ahead; those who experimented with generative AI outside that perimeter find the pilot has none of the controls needed to go live. **Risk** measures governance, compliance and ethics. It is the dimension that determines the class in banking more than any other, because Annex III systems raise the bar and because supervisory authorities are already present. **Confidence** measures board commitment, user trust and perceived robustness. It is often high in statements and low in behaviour, and the gap shows when you ask who signed the last adoption decision and on what basis. ## The gate that stops nearly everyone In our assessments the typical banking profile is one: good Readiness and Confidence, acceptable Delivery, Risk below threshold. And since the gates are non-compensable, the final class falls to the level of the constraint rather than the average. The gate that closes most often is the system inventory. Not for lack of will, but because in a bank AI systems arrived through three separate routes, none of which passes through a single point: models developed internally within risk functions, AI features switched on inside software already purchased, and tools adopted by individual departments. The second gate concerns the role assumed. Almost every bank declares itself a deployer, and some no longer are: fine-tuning on proprietary data or changing a decision threshold can trigger Article 25 of the AI Act, with the obligations in Article 16. Until that field is verified system by system, the Risk dimension stays exposed. ## What a class means in practice | Class | Typical situation in a bank | What's reasonable to do | |---|---|---| | D | Systems in use unmapped, no formal controls | Pause new adoptions and build the inventory | | C | Partial inventory, governance stated but not implemented | Close the gates before scaling onto core processes | | B | Working framework, evidence in place, some areas exposed | Extend to high-risk processes and prepare for audit | | A | Mature system verified across all dimensions | Reserved for verified assessments, not self-assessments | On that last row it's worth being explicit: a self-assessment does not produce a class A, because that class presupposes a structured verification with checked evidence. A tool returning A on its own would devalue everyone else's result. ## Why measure before setting the budget The link between rating and budget is direct. A bank in class C allocating budget to scale AI onto credit is paying twice: once for the project that won't clear the controls, and again to redo it once the gates are closed. The same money, spent first on closing the gates, produces an organisation able to absorb subsequent projects without redoing them. This is why rating belongs at the start of the planning cycle rather than at the end, as a check on decisions already made. ## What it takes to do properly A useful assessment requires material that almost always exists in a bank, scattered across different functions: the list of AI systems in use or under evaluation, the model validation procedures already running in risk functions, training evidence linked to roles, contracts with model suppliers, and minutes of adoption decisions. Gathering that material is half the work already, and on its own produces the picture many banks have never had in one place. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), because without it the rating measures perceptions. From there you move to verifying the role for each system and to risk assessment. The full model, with the four dimensions and the gate logic, is described on the [AI Rating](/en/services/ai-rating) page. The sector's regulatory context, with the rules overlapping the AI Act, is on the [AI governance for banks and financial services](/en/sectors/finance) page. For an assessment of your bank's position you can [book a meeting](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # AI adoption in banking: which use case to actually start from URL: https://zerofive.ai/en/blog/strategy/ai-adoption-banking-first-use-case Data: 2026-06-11 Abstract: Value and regulatory friction don't align. The map of banking use cases, what separates a pilot from a project, and why credit comes later. **In short.** In banking, the choice of a first AI use case is almost always made backwards, starting from the most visible process rather than the one with the best ratio of value to regulatory friction. The cases generating quick value are internal ones, where risk stays low and no authority asks about the model. The cases that move the P&L sit in credit, and that path is long because it runs through Annex III. The question that comes up most often is where to start rather than whether to use AI, and in a bank that question carries an extra constraint: some processes are already covered by validated models, within a governance framework AI has to respect rather than bypass. ## Two curves that don't line up Assessing a banking use case takes two separate measures, and conflating them is the error that stretches projects out. The first is expected economic value, which in most banks concentrates in credit, fraud prevention and back-office efficiency. The second is regulatory friction, meaning how much governance work is needed before the system can go into production. The two curves don't line up. The highest-value use case, credit scoring, also carries the highest friction, because it falls under Annex III with obligations on data, technical documentation and human oversight. The lowest-friction case, internal search across documentation and regulation, has real value that is hard to put on the balance sheet. ## Where those who reach production actually start In the paths that work, the first use case is rarely the strategic one. It's an internal case, chosen because it lets the method get built while risk stays contained. | Use case | Value | Regulatory friction | Suitable as first | |---|---|---|---| | Search across regulation and internal procedures | Medium, in time saved | Low | Yes | | Summarising files and loan documentation | High in efficiency | Medium, customer data | Yes, with attention to data | | Support for the commercial network | Medium | Low, Article 50 | Yes | | Fraud and anti-money laundering | High | Medium, depends on effect on the individual | As a second step | | Credit scoring | The highest | The highest, Annex III | No, not as a first | | Customer-facing chatbot | Medium | Low, transparency obligations | Yes, if the scope is closed | The surprising column is the third. Many banks choose to start from the customer-facing chatbot because it looks most visible, then discover that the hard part is the boundary of what the assistant may say, not the model. ## What separates a pilot from a project A pilot is worth running if it produces a decision rather than a demo. That difference gets established before starting, by defining three elements that must exist in writing. The first is the measured baseline of the current process: how long it takes, how many errors it produces, what it costs. Without that number the pilot is comparable to nothing and closes on an impression. The second is the acceptance criteria, set before seeing any results. Written afterwards, they accommodate any outcome. The third is the exit path, meaning what happens if the pilot works. A pilot without an industrialisation plan stays a pilot, and in a bank it can stay one for years, because moving to production requires integrations, controls and documentation nobody budgeted for. ## Why credit comes later, and that isn't a retreat Deferring credit scoring doesn't mean giving up the value, it means sequencing the work. Annex III obligations for high-risk systems apply from 2 December 2027 following the Digital Omnibus postponement, and that window exists to build what will then be required: data traceability, technical documentation, human oversight designed in rather than added on. There's a practical reason too. Anyone touching credit scoring with fine-tuning on proprietary data may fall among providers under Article 25 of the AI Act, taking on the obligations in Article 16. That decision is better made knowingly than discovered mid-project. In the meantime, internal cases build exactly the capabilities that will be needed: inventory, risk assessment, verified competence, a release process. ## The most expensive mistake The most frequent one isn't picking the wrong case, it's picking the right case with no owner. An AI system in production needs a named person accountable for the decisions it produces, and in a bank that person sits in the business function, not in IT. When ownership stays with IT, the system gets maintained but not governed: nobody decides when it's outside its validity range, nobody notices drift, and the control exists on paper. ## Where to start The sequence that works begins with the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), because in almost every bank something is already in use, often inside software bought years ago. From there you build the map of candidate cases across the two curves, value and friction, and pick the first from the bottom left rather than the top right. The selection criteria in detail are in [AI adoption: how to choose your first use case](/en/blog/strategy/ai-adoption-choose-first-use-case), and the cost model from pilot to production in [AI project budgeting](/en/blog/strategy/ai-project-budget-pilot-production). The sector's full regulatory picture is on the [AI governance for banks and financial services](/en/sectors/finance) page. To work out which use cases make sense in your bank, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in banking: who to train, on what, and with what evidence URL: https://zerofive.ai/en/blog/compliance/ai-literacy-banks-financial-sector-training Data: 2026-06-09 Abstract: AI training for banks: the three roles needing individual evidence, what to reuse from existing programs, and why the AML model falls short. **In short.** In a bank, the AI literacy obligation under Article 4 and the competence requirements of ISO/IEC 42001 clause 7 meet a workforce already trained on other fronts, from anti-money laundering to MiFID II. AI training that works doesn't start from scratch, it builds onto those programs. Three roles are critical, those assessing creditworthiness, those exercising human oversight over models, and those approving adoption decisions, and for them the evidence has to be individual. In financial services, mandatory training is a settled routine, with calendars, platforms and tracking that have existed for years. That's an advantage and at the same time the reason AI training often gets set up badly, added as a generic module inside a framework designed for something else. ## Why the anti-money laundering model doesn't work here AML training has a structure banks know well: content identical across role bands, periodic delivery, final test, tracking. Transferring that scheme onto AI produces a plan that holds the form and misses the substance. The difference is that AML rules describe behaviours to follow, while AI requirements ask people to recognise when one specific system is producing an anomalous outcome. The first can be taught in the abstract, the second cannot. A module explaining what a machine learning model is doesn't put an analyst in a position to notice that a scoring system is treating two equivalent applications differently. There's also a difference in perimeter. AML concerns whoever works on certain processes, while AI literacy concerns anyone using a system, including network advisors and staff at service companies working on your processes. ## The three roles needing individual evidence For most staff, awareness is enough: knowing what the tool they use does and who to report an anomaly to. Three roles are the exception, and for those the documentation has to be named and tied to the specific system. **Those assessing creditworthiness with model support.** Credit scoring of natural persons is classified as high risk under Annex III of the AI Act, and anyone working on that process needs to read the output, recognise cases where the model sits outside its validity range, and know how to depart from the suggestion. **Those exercising human oversight.** The competence obligation for these people was not touched by the Article 4 relief introduced by the Digital Omnibus. It remains in full, and their evidence has to show that the person was able to intervene on that system, not that they attended a course on AI in general. **Those approving a system's adoption.** Management, the risk committee, whoever signs off on going live. A signature without understanding puts the decision-making process in question, and in an audit the finding travels from clause 7 up to clause 5 on leadership. ## What to reuse and what to build The existing training framework already covers part of the work, and mapping it is worth doing before buying anything new. | Element | Already present in a bank | What's missing for AI | |---|---|---| | Platform and tracking | Yes, well established | Link between evidence and specific system | | Training on automated decisions | Partly, through GDPR | Extension to AI Act requirements | | Model risk culture | Yes, within risk functions | Extension beyond risk functions | | Effectiveness verification | Quiz-based tests | Practical cases on models in use | | Perimeter extended to suppliers | Partial | Requirements in outsourcing contracts | The costliest row is the last one. Many banks outsource customer service, debt collection or parts of loan processing, and those people use AI systems on your processes without falling inside your training plans. The only instrument is the contract. ## The module no vendor can write The most useful part of AI training in a bank cannot be bought, because it requires information only you hold: which models are in production, which decisions they affect, which edge cases have already been observed, who to report anomalous behaviour to and what happens next. Thirty or forty minutes per system, prepared by whoever knows that system, worth more than four hours on the structure of the regulation. It's also the material that, in an inspection or in litigation, shows human oversight genuinely existed. ## What an auditor asks an analyst During a verification the sample follows precise criteria: it starts from the role matrix and picks people working on the most exposed systems, recent joiners, and whoever signed approvals. The questions are simple and nearly always the same. What does the system you use every day do. How would you notice it getting something wrong. What do you do if it happens. Who do you report it to. When no answer comes, the finding concerns the management system that delivered training without verifying its effectiveness, not the person. ## Where to start The starting point isn't the course catalogue, it's the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), because without knowing which systems are in use and on which processes, training calibrated to context stays calibrated to an idea of the context. From there you build the matrix linking roles to competences, separate what's needed as awareness from what's needed as verifiable competence, and decide for which roles the evidence has to be individual. The full requirements are in [clause 7 explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained), and the relationship between the two obligations in [AI literacy and ISO 42001 competence](/en/blog/compliance/ai-literacy-iso-42001-competence). The sector's regulatory context, with the full map of overlapping rules, is on the [AI governance for banks and financial services](/en/sectors/finance) page. Our approach to building role-based tracks is described on the [AI Training](/en/services/ai-training) page. To assess what your bank's plan is missing, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive). --- # The common language between business, IT and risk: the real bottleneck URL: https://zerofive.ai/en/blog/insights/common-language-business-it-risk Data: 2026-06-04 Abstract: AI projects slow down where business, IT and risk use the same words with different meanings: the typical misunderstandings, their costs and how to build a glossary that works. Try listening to an AI steering meeting with a linguist's ear instead of a manager's, and you will hear three languages exchanging the same words. The business says "the model works" and means the process improves; IT says "the model works" and means the technical metrics hold; risk hears "works" and asks against which approved perimeter, receiving stares in return. Nobody lies, nobody is wrong, yet the meeting produces an apparent agreement that will dissolve at the first verification, because the three functions have signed three different sentences believing them to be one. In our assessments this linguistic friction appears with such regularity that we have stopped treating it as a communication detail: it is an operational bottleneck, with measurable costs, and in the rating's Readiness dimension it weighs inside the culture item more than transformation plans give it credit for. ## The words that divide the most The recurring misunderstandings deserve to be named, because recognising them is half the remedy. "Validated" is the champion: for IT it means the technical tests pass, for the business it means the process owner has seen acceptable results, for risk it means a formal evaluation with preserved evidence exists, and a system can be validated in two languages out of three while travelling towards a blockage. "Data ready" follows closely, with the business meaning available in a report, IT meaning accessible via pipeline, risk meaning usable for that purpose with a written legal basis. "Risk" deserves its own chapter, because the business uses it for the probability the project fails, the risk function for the exposure the project creates even by succeeding, and the conversation between the two meanings is the one deciding whether compliance enters at design time or arrives as a final surprise. Even "pilot" divides: an experiment with stopping conditions for some, a first release to be defended for others, and we have watched the difference between the two readings consume entire quarters. The cost of this Babel presents itself in familiar forms: meetings that repeat because the previous agreement was not an agreement, requirements rewritten mid-development, the classic scene of the project stopped by risk "at the last moment", where the last moment is simply the first one in which somebody translated. ## The glossary that works (and the one that does not) The obvious remedy, the corporate glossary, exists in many organisations and almost never works, because it is born as a document and documents do not change speech. The glossary that works has three different properties. It is short, twenty entries chosen among those that have already produced misunderstandings in-house, not two hundred imported from a framework. It is operational, meaning each entry defines the word through the evidence that proves it: "validated" gets no philosophical definition, it gets a list of what must exist for the word to be usable. And above all it is embedded in the artefacts the three functions fill in together, because a language is learned by using it where it counts. This is where the instruments we have written about show their second trade. The AI Canvas is, among other things, a translator: the six boxes force business, IT and risk to write on the same page with words everyone endorses, and the drafting session is the place where the three meanings of "validated" meet before they cost anything. The go/no-go criteria do the same work on thresholds, and the systems register on classifications. The common language, in other words, is built less through courses and more through shared forms. ## Where to start The sequence we see working starts from an inventory of the misunderstandings already paid for: half a day with the three functions reconstructing the latest frictions, extracting the words that generated them, produces the raw glossary and, with it, the consensus that one is needed. Then come the twenty operational definitions, the grafting into the artefacts, and a light maintenance ritual, because new words will arrive with new technologies. It is the heart of the work that in our chain is called AI Culture, the gear change separating organisations where functions watch each other from those where they understand each other: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The experiment to run at your very next meeting, meanwhile, costs thirty seconds and a little face: when somebody says "validated", ask what would need to exist, concretely, for the word to be true. The three answers you receive are the photograph of your bottleneck. --- # AI Rating in retail: the gate is workforce systems URL: https://zerofive.ai/en/blog/strategy/ai-rating-retail-workforce-systems Data: 2026-05-27 Abstract: Decent Readiness and Delivery, Risk falling on workforce management systems never classified. When it pays to measure. **In short.** In retail the AI maturity profile carries an anomaly compared to other sectors: organisations score decently on Readiness and Delivery, and collapse on Risk for one reason alone, the systems managing staff. They arrived inside workforce management software, nobody classified them, and they fall under Annex III. It is the most underestimated gate we come across. Chains arrive at the rating convinced the AI Act barely concerns them, because few commercial use cases land in the high-risk bracket and the sector narrative has pushed that point for months. The assessment moves attention somewhere they didn't expect, onto employees rather than customers. It changes the conversation. ## The four dimensions in retail **Readiness** measures preparation, data, skills, infrastructure. It is generally decent, because sales data exists, is structured and already in use. The weak point concerns undigitised store data and the split between physical and online channels, which in practice means the data on a single customer lives in at least three different systems, the till, e-commerce and the loyalty programme, without a single view a model could work on without manual reconciliation. **Delivery** measures the ability to reach production and maintain it. In retail it is limited by the distance between head office, where systems are chosen, and the network, where they are used. A system released without support in store gets worked around within weeks, because staff find a shortcut that works better than the intended process and nobody at head office notices until the numbers stop adding up. **Risk** measures governance, compliance and ethics. It is the dimension that sets the class, and it falls almost always on the same point. **Confidence** measures management commitment and user trust. High at head office, low in store, with a gap wider in retail than elsewhere because the two populations rarely talk to each other. ## The gate: workforce systems The recurring constraint concerns shift planning, task allocation and performance evaluation systems. These have existed in retail for years, were bought as administrative modules, and in recent years acquired predictive features without the purchase being reassessed. They fall under Annex III, because they concern the management of workers. Until they are classified as such, risk assessment, documentation and oversight are missing, and the Risk dimension stays below threshold whatever the quality of governance elsewhere. There is an Italian aggravating factor. Labour law constraints and consultation with worker representatives sit on top of those systems, and a company that introduced them without that step has a problem documentation alone won't solve. ## Video analytics, the point that surfaces late Many chains run video surveillance installations that over time acquired analytical functions: footfall counting, heat maps, in some cases recognition. The line between aggregate analysis and biometric processing is thinner than people assume, and crossing it brings heavy constraints. In assessments this surfaces late, because the installation is managed by physical security and never enters the IT perimeter. ## What a class means in practice | Class | Typical situation in retail | What is reasonable to do | |---|---|---| | D | AI modules live inside software, no mapping, staff systems unclassified | Map the systems starting from those touching employees | | C | Commercial inventory in place, HR systems unclassified | Classify workforce systems and open the internal conversation | | B | Classification complete, oversight on Annex III systems | Extend documentation and review video analytics | | A | Mature system verified across all dimensions | Reserved for verified assessments, not self-assessments | Moving from C to B in retail is technical and relational at once, because it touches the organisation of work. It is also why it takes longer than management expects. ## Why measure before the next software renewal In retail the useful moment coincides with the renewal or replacement of workforce management or warehouse software. That is when the supplier can be asked for documentation on predictive modules, a description of adjustable parameters and access to logs. After signature those requests become renegotiations, and the supplier often replies that it doesn't produce that information. A chain renewing without having run the assessment carries an unclassified system for the whole term of the contract. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), built starting from the systems touching employees rather than commercial ones. The full model, with the four dimensions and the gate logic, is on the [AI Rating](/en/services/ai-rating) page. The sector's regulatory picture is on the [AI governance for retail](/en/sectors/retail) page. For an assessment of your chain's position you can [book a session](https://calendly.com/fabiolalli/zerofive) or [start the self-assessment](/en/start-ai-rating). --- # AI fluency: why board training comes before operational training URL: https://zerofive.ai/en/blog/insights/ai-fluency-board-training Data: 2026-05-26 Abstract: AI literacy is an AI Act obligation and a governance necessity: what a board must know, why its training precedes the operational one and how it is done. In the AI training plans we review there is an inverted pyramid: prompting courses for hundreds of operational staff, workshops for middle managers, and for the top, when things go well, a one-hour inspirational keynote with slides about the future. The implicit logic is that AI is learned by using it, so training goes to those who use it. The forgotten logic is that the decisions determining adoption's success, how much to invest, where, with which acceptable risks, when to stop, are all taken at the top, and they are taken badly when the people taking them lack the instruments to interrogate what is being proposed. The labour market, meanwhile, runs in the opposite direction to the inverted pyramid: the Artificial Intelligence Observatory of Politecnico di Milano (2025 research, February 2026) records a 93% increase in AI skills requested in job postings and 41% of workers performing, thanks to AI, activities previously out of reach. Widespread skills grow on their own, pushed by demand; governing skills do not, and they are scarcest exactly where they matter most. ## An obligation, even before a choice There is also a regulatory fact many training plans ignore: from Article 4 of the EU AI Act, applicable since February 2025, organisations carry the task of ensuring an adequate level of AI literacy for the staff operating these systems, commensurate with context and role. The phrase "commensurate with role" is the point that interests us: for those who resolve strategies, allocate capital and answer for governance, adequate literacy is not knowing how to write a prompt, it is knowing how to exercise one's own trade on this matter. A board approving an AI investment without the instruments to evaluate it has a compliance problem on top of a decision-quality one. ## What a board must know (and what it must not) The misunderstanding to dissolve concerns the content, because top-level fluency is not a reduced version of technical training. A board does not need to know how to build, it needs to know how to interrogate, and the curriculum that works organises itself around four capabilities. The first is understanding the probabilistic nature of these systems, just enough to ask the right questions about error: how often it fails, on what, who notices, what it costs. The second is the economics of AI, the five cost families we have written about, the difference between a pilot and a production system, why returns come from process redesign more than from the tool. The third is the regulatory perimeter in its managerial consequences, what having high-risk systems entails, which questions to ask about data and suppliers, when to demand that risk and the DPO be at the table. The fourth, the most precious, is the repertoire of questions: the ten questions a director asks in front of any AI proposal, from "who signed the expected value" to "what is the stopping condition". Everything else, architectural details, model taxonomies, tool demos, is ballast at this level, and the programmes that include it buy hours of the top's attention only to spend them badly. ## The right sequence, and what it unlocks Training the top before the operations has a sequencing justification, beyond a hierarchical one: it unlocks everything else. A fluent board approves widespread training plans with criteria instead of by catalogue, tells suppliers apart from brochures, sustains the right projects through difficult quarters (the Confidence we discuss in the rating is built this way too) and stops oscillating between keynote enthusiasm and newspaper-article panic. In the journeys we run, a well-executed half day with the board is worth months of friction saved downstream. The format counts as much as the content: short recurring sessions beat the marathon day, the company's own cases beat textbook examples, and the most effective exercise we know is the resolution simulation, a real AI proposal brought into the room and dismantled with the repertoire of questions. In our AI Academy the tracks are built by level, board, management, operations, with this sequencing principle embedded: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai for the programme. The test to see whether your top is already fluent, meanwhile, is free and slightly cruel: at the next AI proposal in the boardroom, count the questions asked before approval. If the most technical one concerns the licence cost, the pyramid is still inverted. --- # AI adoption in retail: the use case that pays and the one that exposes URL: https://zerofive.ai/en/blog/strategy/ai-adoption-retail-first-use-case Data: 2026-05-22 Abstract: Demand forecasting as the first case, personalised pricing to weigh carefully, workforce systems as a project of their own. **In short.** In retail the use case with the best ratio of value to friction is demand forecasting, because it produces measurable effects within weeks and stays at minimal risk. The case that attracts most attention is personalised pricing, which works technically and carries disclosure obligations towards the consumer plus a reputational risk that rarely enters the business case. Workforce systems, the highest-risk ones, get adopted without anyone treating them as such. Margin pressure in retail makes every percentage point interesting, and that pushes organisations to see AI as an optimisation lever rather than a system to govern. The consequence is that adoption comes first and classification later, or never. ## Where results show immediately Retail has an advantage other sectors lack: the cycles are short. A demand forecasting model is judged on four weeks of sales, not on three years of claims or two sporting seasons. That changes the logic of adoption. A chain can afford to get the first use case wrong, as long as it measured beforehand, because the cost of the error is recovered quickly. It is the opposite of what happens in manufacturing or insurance. The condition is that a baseline exists. Without the starting figures on stockouts, unsold inventory and margin, a four-week assessment produces an impression rather than a number. ## The map of candidate cases | Use case | Value | Regulatory friction | Suitable as a first | |---|---|---|---| | Demand forecasting and replenishment | High and quick to measure | Low | Yes | | Space and assortment optimisation | Medium-high | Low | Yes | | Customer service assistant | Medium | Low, Article 50 | Yes | | Online product recommendation | Medium-high | Low, GDPR profiling | Yes | | Personalised pricing per customer | High | Medium, disclosure and reputation | Assess carefully | | In-store video analytics with recognition | Medium | High, biometric area | No | | Shift planning and staff evaluation | Medium | High, Annex III | Treat as a project of its own | The last row is the one adopted with the least caution in retail, because it arrives inside workforce management software and looks like an administrative feature. ## The personalised price case It deserves isolating because it generates confusion. A system adapting the price to an individual customer on behavioural data is not prohibited, and it carries a disclosure obligation towards the consumer: personalisation based on automated decisions has to be communicated. The delicate part isn't regulatory. In retail the perception of different treatment between customers produces reactions out of proportion to the size of the difference, and those reactions become a real commercial cost. The decision belongs in the open, weighing expected margin against exposure, rather than surfacing when somebody compares two screens. ## How many customers the chain actually recognises Personalisation, in any form, only produces effects on the share of customers the chain recognises, and in physical retail that share is almost always a minority of receipts, because outside the loyalty programme the transaction stays anonymous and the model works on a sample nobody chose. A chain with thirty per cent of receipts identified is building predictions on a third of its customers. Before funding a personalisation use case it is worth measuring two numbers: the percentage of transactions linked to an identified customer, and the percentage of those customers reachable with valid consent. The second is almost always lower than the first. If both are low, the first budget pays off better spent on the reasons a customer should identify themselves at the till, because without that base any personalisation model works on a share too small to move the margin. ## When the pilot doesn't transfer to the network The right perimeter in retail is a group of stores or a product category, with the baseline measured on that same perimeter. One caution is specific here. Stores differ by catchment, floor space, assortment and customer mix, and a result obtained on ten selected stores does not transfer automatically onto five hundred. Sample selection counts as much as the model, and a sample drawn from the best-performing stores produces a result that won't repeat. The exit plan concerns integration with till systems and warehouse management software, which is the longest part and the one rarely included in the initial estimate. ## Who answers for the system In retail, ownership tends to land in whichever function bought the tool, often marketing or IT. For systems touching assortment the right point is the category manager, for those touching staff it is the HR director, and in that second case responsibility cannot be delegated to a supplier. One clarification belongs here. A system assigning shifts affects working conditions, and the person answering for it has to be able to change the parameters and stop the system, not merely receive its output. ## Where to start The sequence starts from the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), which in retail has to include AI modules switched on inside software already in use, starting with workforce management. The general selection criteria are in [AI adoption: how to choose the first use case](/en/blog/strategy/ai-adoption-choose-first-use-case), the cost model in [the budget of an AI project](/en/blog/strategy/ai-project-budget-pilot-production). The sector's regulatory picture is on the [AI governance for retail](/en/sectors/retail) page. To assess which use cases make sense in your chain you can [book a session](https://calendly.com/fabiolalli/zerofive). --- # AI literacy in retail: turnover makes the annual plan useless URL: https://zerofive.ai/en/blog/compliance/ai-literacy-retail-store-training Data: 2026-05-20 Abstract: High turnover and an annual training plan don't mix. The onboarding trigger, the critical roles at head office and the franchise network. **In short.** In retail, AI training runs into turnover, which in many chains exceeds fifty per cent a year among store staff. A plan on an annual cycle covers a population that has changed in the meantime, and that makes the classic structure useless. What works is a trigger tied to the person joining, and very short content. The roles carrying individual evidence all sit at head office. Retail already trains on safety, product and till procedures, and that training is built to be fast and repeatable, because it has to reach thousands of people spread across hundreds of stores with continuous churn. AI fits that format well and fits the content badly, because what people need to know changes from system to system. The format helps, the content doesn't. ## Turnover changes the project An annual training plan assumes whoever was trained in January is still there in December. In store retail that assumption is false for a large part of the population, and the consequence is that the evidence collected describes people who have left. The only mechanism that works is the joining trigger: the AI module goes into onboarding, alongside till and safety, and is delivered in the first days. It runs ten minutes, covers the systems that person will actually use, and is recorded with a name and a date. The annual review stays, and serves the people who remain and the content that needs updating when systems change. ## The roles carrying individual evidence Here retail differs from other sectors, because the critical roles sit at head office, inside functions rarely considered when the conversation turns to AI training across a store network. **Whoever configures workforce planning systems.** Shifts, task allocation and performance evaluation fall under Annex III, and whoever configures them sets parameters affecting real working conditions. In Italy, labour law constraints and consultation with worker representatives sit on top. **Whoever sets personalised pricing rules.** Not under the AI Act in the strict sense, where the case stays at limited risk, but because disclosure obligations towards the consumer apply when a price is personalised through an automated decision. Whoever sets those rules needs to know what must be disclosed. **Whoever runs the loyalty programme and customer profiling.** Building behavioural clusters, deciding who receives an offer and choosing which data feeds those clusters are processing activities under the GDPR, and when the decision produces significant effects on the customer, Article 22 comes into play as well. Whoever sets those rules needs to know which legal basis they rest on and what to answer a customer asking why they received a different offer from their neighbour. For the rest of the population, store staff included, awareness is enough: what the tool does, when not to trust it, who to flag it to. ## What store staff need to know | System | What they need to know | Duration | |---|---|---| | Replenishment suggestions | That it is a forecast and not an order, when to flag an anomaly | 5 minutes | | Customer service assistant | That it must be declared as an automated system, what it cannot promise | 5 minutes | | Assisted shift planning | How it works, who to approach to contest a result | 10 minutes | | In-store video analytics | What the system records and what it doesn't, what to tell a customer who asks | 10 minutes | The last row is the one most often missing entirely, and the one carrying the most exposure. An assistant who can't answer a customer asking what that camera does creates a problem no privacy module solves afterwards. ## The franchise network Clause 7.3 covers whoever uses the systems, and in retail that includes indirect networks, where store staff never appear on the chain's payroll and still work every day on tools the chain has chosen, configured and distributed. The instrument is the franchise agreement, where competence requirements can be set alongside the obligation to provide evidence. Many chains already push training to franchisees on product and visual merchandising, and that channel is the same one. ## Where to start The prerequisite is the [AI system inventory](/en/blog/compliance/ai-system-inventory-iso-42001), which in retail has to include workforce management systems, often classified as HR tools and never assessed as AI systems. From there comes the matrix, described in [the roles and competence matrix for AI](/en/blog/compliance/roles-competence-matrix-ai), separating the few head-office roles from the store population. The full requirements are in [clause 7 explained without jargon](/en/blog/compliance/clause-7-iso-42001-explained). The sector's regulatory picture is on the [AI governance for retail](/en/sectors/retail) page. The approach to role-based paths is on the [AI Training](/en/services/ai-training) page. To assess your chain's plan you can [book a session](https://calendly.com/fabiolalli/zerofive). --- # What an AI project really costs: TCO beyond the licence URL: https://zerofive.ai/en/blog/strategy/what-ai-projects-really-cost Data: 2026-05-19 Abstract: The total cost of an AI project goes far beyond licences and tokens: prerequisites, integration, compliance, people and run. How to build an honest account. The AI business cases we receive for review share a geometry: the visible line, licences or token consumption plus the supplier's days, occupies the centre of the sheet, and around it there is white space. Then the project starts, and the white space fills up: the dataset to remediate that nobody had priced, the ERP integration estimated at two weeks and lasting four months, the privacy assessment arriving mid-development, the training reduced to a webinar and repaid with non-usage. At final count, in the projects we analyse, the initial line rarely covers more than a third of the total, and the surprise is not in the numbers, it is in the fact that we keep calling it a surprise. The total cost of ownership of an AI initiative can be broken into five families, and knowing them beforehand turns the business case from an exercise in optimism into a decision instrument. ## Prerequisites and integration: the cost of reaching the start line The first family is the prerequisites, dominated by data. Making sources accessible, measuring their quality, remediating what the use case requires, building the pipelines that keep clean what was cleaned: it is the workstream we have written about repeatedly, and in projects on core processes it can be worth as much as everything else combined. Honest accounting puts it in the bill, with one alleviating note: it is the only line that amortises across subsequent use cases, and a well-made business case spreads it instead of loading it all onto the first project, which otherwise never starts. The second family is integration, the cost of making the system live inside real workflows rather than next to them: connectors to existing systems, redesign of process steps, handling of the exceptions the demo's happy path never contemplated. McKinsey's State of AI research (2025) identifies workflow redesign as the factor with the largest impact on GenAI returns, which makes this line doubly interesting: it is among the most underestimated in quotes and the most correlated with value. ## Compliance, people, operations: the cost of staying up The third family is regulatory oversight, which for systems in AI Act high-risk territory has nameable items, technical documentation, impact assessments, human oversight design, registrations, and for all the others still includes classification, register updates, possible work on legal bases and DPIAs. Putting it in the bill at the start costs hours of legal and risk time; discovering it at the end costs months of standstill, and it is one of the trade's best-documented asymmetries. The fourth family is people: training for those who will use the system, the time of domain experts to build golden sets and validate outputs, the change management separating an installed system from an adopted one. It is the line business cases cut first because it is the easiest to postpone, and the one whose absence produces the most mocking failure, the perfect system nobody uses. The fifth family is operations, the recurring cost starting when the project "ends": quality and drift monitoring, model updates with the retuning that follows, inference costs growing with adoption (the paradox of success: the more people like the system, the more it consumes), maintenance of integrations. The rule of thumb we use in reviews: if the estimated annual run is below 20-30% of the build cost, some line is missing. ## The honest account as an instrument, not a brake The predictable objection to a TCO composed this way is that it inflates the numbers and kills initiatives. Experience says the opposite on both counts. The numbers are not inflated, they are anticipated: the lines exist regardless, and the only available choice is between seeing them in the business case or in the final statement. And the initiatives an honest account stops are exactly the ones that needed stopping, while the right ones come out reinforced, with a budget defensible in front of the board and without the season of supplementary requests that consumes more credibility than money. There is also a strategic use of the full TCO worth naming: compared across the build, buy and wait options, with the five families filled in for each, it often changes the outcome of the fork, because the buy that looked expensive stops looking so once the build shows its perpetual run, and vice versa. In our AI Assessment the business cases of the priority use cases come out with this structure, five families filled in, prerequisites spread, run estimated, and it is one of the points where clients measure the difference between a plan and a hope: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The exercise to run meanwhile on the initiative you have in approval takes ten minutes: next to the visible line, write the other four families, even just as orders of magnitude. Which of the four, on your sheet, had stayed white? --- # AI vendor lock-in: exit strategy and independence from suppliers URL: https://zerofive.ai/en/blog/strategy/ai-vendor-lock-in Data: 2026-05-14 Abstract: The four forms of lock-in in AI projects, what they really cost and how to design the exit strategy at the entrance: abstraction, clauses, portable data. There is a precise moment when lock-in gets decided, and it is not when you realise you are captive: it is at signature, when the supplier is courting, discounts rain down and the exit clause looks like a pessimistic detail to postpone. In AI this old enterprise software mechanism has become faster and subtler, because dependencies form in weeks instead of years, and some never pass through the contract at all. From a vendor-agnostic position, the topic matters to us for a professional reason: the client's independence is the condition under which our recommendations are worth anything. ## The four forms of captivity The first form is behavioural lock-in, the newest and the most underestimated. Prompts, workflows and evaluations get tuned to the behaviour of a specific model, and after months of refinement the system works because that model answers that way: changing provider means redoing the tuning, and the cost appears on no invoice, it sits in the months of accumulated work. The second form is lock-in on data and derived artefacts: embeddings computed in a proprietary format, fine-tunes living only on the provider's infrastructure, histories of conversations and feedback that come out, when they come out, in unusable formats. The third form is platform lock-in, the classic one: the more a use case integrates with an ecosystem's accessory services (orchestration, vector stores, evaluation tools, connectors), the more the exit stops being a model migration and becomes an architecture relocation. The fourth is contractual, and it lives in the clauses nobody negotiated: prices revisable unilaterally, short deprecation notices, ambiguous rights over the customisations built on top of the product. The cost of captivity, in all four forms, presents itself the same way: at renewal, when the supplier knows leaving would cost you more than the increase, and the negotiation happens with only one side holding alternatives. ## The insurance is bought at the entrance The effective exit strategy has the uncomfortable property of needing to be designed when nobody feels the need, and its components are known. On the technical side, the abstraction layer we wrote about regarding infrastructure: applications talk to an internal interface and never directly to the single provider, so that substitution is a configuration change. Alongside it, the evaluation golden set kept in-house, which turns the question "would the alternative model work?" from a debate into an afternoon of tests, and the discipline of keeping data, feedback and artefacts in portable formats, with the export actually tested at least once, because a portability clause never exercised is a written hope. On the contractual side, the clauses that matter get negotiated when the supplier wants you: guaranteed export formats and timelines, minimum notice on deprecations and price changes, clear ownership of customisations, and for critical workloads the option of a second qualified supplier, even just kept warm on a fraction of the traffic, which is the most concrete form of negotiating power in existence. ## What independence is worth, in numbers The insurance has a premium, and it is fair to say so: the abstraction layer costs engineering, the second supplier costs management, portable formats cost discipline. The correct question is not whether the premium is zero, it is how it compares with the expected damage, and the comparison is made through an exercise we recommend putting on the agenda once a year: for every critical dependency, estimate the time and cost of a forced exit within ninety days, as one does with continuity plans. The figures that come out usually close the discussion about the premium. Finally there is a balance to declare, because independence taken to the extreme becomes a cost itself: building every component in-house so as to depend on nobody is the most expensive form of lock-in, the one towards your own past. The sensible goal is not depending on nobody, it is that every dependency be chosen, measured and reversible at a known cost. It is the criterion with which, in our AI Strategy work, we design architectures and contracts together with clients, with the exit strategy as a design requirement and never as a remedy: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The test to run this week costs one question to your team: if the main supplier doubled its prices at the next renewal, what would saying no actually cost us? --- # Build, buy or wait: the decision CIOs get wrong most often URL: https://zerofive.ai/en/blog/strategy/build-buy-wait-ai-decision Data: 2026-05-12 Abstract: Build, buy or wait: the criteria for enterprise AI's most recurrent decision, the biases that warp it, and why the wait must be written with a date. Every approved AI use case soon reaches a fork with three exits: build in-house, buy on the market, or wait. The first two exits have fierce internal lobbies, the engineering team that wants to build and the procurement team besieged by vendors, while the third has nobody defending it, and this imbalance of representation is the first cause of the errors later counted in the portfolios. The decision, taken well, is an exercise in criteria; taken as it usually is, it is an arm-wrestle between biases. ## The criterion that orders all the others The question that should open every build-or-buy discussion is whether the capability in question differentiates the company on the market or merely keeps it operational. The distinction between core and context, which Geoffrey Moore made canonical, applied to AI produces a rule with few exceptions: you build only what touches the heart of the competitive advantage, where your data and your domain knowledge create something the market cannot offer anyone else, and you buy everything else, because in everything else the market product embeds the learning of hundreds of customers and improves at their expense. The most frequent classification error leans towards the core side: almost every function considers its own process differentiating, and the test to deflate the illusion is asking whether a competitor, using the same market product, would obtain the same result. If yes, the advantage never lived in the software, and building it in-house produces only a perpetual maintenance cost dressed up as an asset. Beneath the core criterion, the others act as a court of appeal: the maturity of the market offering (buying an immature product is a build with the wrong supplier), the real internal skills with their retention outlook, the three-year total cost where the build pays maintenance forever and the buy pays the fee forever, the speed the business requires. ## The wait, the option without a lobby AI adds to the classic fork a third exit that deserves more respect than it receives, because the underlying technology has a rare property: it improves and depreciates at visible speed. Capabilities that twelve months ago required bespoke projects now sit inside a product or a base model, and the per-token costs of the same capability have fallen by multiples year over year. In such a context, waiting six months can be the highest-return decision of the three, because the problem that requires a build today can be bought tomorrow, and the day after it is a feature included in something you already own. The legitimate wait, though, has a precise shape distinguishing it from procrastination: it is a written decision, with a review date, the conditions that would end it early (a competitor moving, a product maturing, a regulatory deadline) and an owner watching the calendar. It also has a cost, to be looked at squarely: the months of organisational learning forgone, the head start a more impatient competitor can accumulate. A wait without a date and a declared cost is not a strategic option, it is the no-go nobody had the courage to sign. ## The biases in action, and the countermeasure It is worth naming the biases as they present themselves in committee. The build bias speaks the language of uniqueness ("our needs are special") and of prudence ("this way we keep control"), and thrives where engineering is strong and under-utilised. The buy bias speaks the language of speed and de-risking ("the supplier will handle it"), and thrives under budget and quarterly pressure. The bias against the wait unites them: in a season where "doing something with AI" is a reputational imperative, patience looks like inertia, and no manager gets promoted for having waited well. The countermeasure is procedural more than psychological: the three options always get evaluated, all three, in writing, on the same criteria, with the cost of the wait quantified next to the other two, and the decision is signed by whoever owns the P&L of the process, never by whoever owns the technology or the contract. Where the method exists, the biases do not disappear, but they stop deciding on their own. In our AI Strategy work the three-exit fork is crossed inside the Canvas and the backlog, with this article's criteria made explicit case by case: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The retrospective test, for anyone wanting to measure their exposure to the biases, is looking at the last five build-or-buy decisions taken in the company and asking how many times the wait was evaluated in writing. If the answer is zero, it is not because waiting was never the better deal. --- # How to evaluate an AI product before adopting it: the questions to ask the vendor URL: https://zerofive.ai/en/blog/strategy/how-to-evaluate-ai-vendor Data: 2026-05-05 Abstract: The questions separating solid AI products from marketing: underlying models, data handling, performance evidence, AI Act posture and exit conditions. Corporate procurement has decades of experience buying software, and almost none buying software that behaves probabilistically, changes with the supplier's updates and drags along an evolving regulatory apparatus. The result shows in the demos: impeccable presentations, always on the same examples, in front of buyers who do not yet have a questionnaire worthy of the object. From a vendor-agnostic position, with no products to defend or attack, we have distilled the questions that in our clients' projects separate solid suppliers from those selling a roadmap, and it helps to organise them into five areas. ## What is inside, really The first area opens the box. Which part of the product is AI and which is traditional logic? The question sounds naive and is not, because the answer immediately reveals supplier-side AI washing, the legacy product rebranded for one marginal feature. Which models does it rest on, its own or third parties', and in the latter case whose? Does the supplier control versions or inherit the upstream provider's updates, with the behavioural shifts that follow? With what notice does it communicate changes affecting outputs? A serious supplier answers without reticence, net of details protected by intellectual property; one who opposes trade secrecy to the question "who produces the model that will process my data" is asking for an act of faith, and acts of faith in procurement go by another name. ## Where the data goes, and what the system learns The second area is where mistakes cost most. Is your data used to train or improve models, the supplier's or third parties'? The answer must be demanded in writing in the contract, distinguishing between configuration data, operational data and user feedback, because policies often diverge across the three. Where does the data physically reside, with which sub-processors, with which retention and deletion timelines? How does all this reconcile with GDPR and, for the use cases that require it, with sector constraints? In this area documentation beats conversation: the DPA, the list of sub-processors, security certifications with their real scope. The salesperson reassures, the contract binds. ## The evidence, the regulation, the exit The third area concerns performance evidence, and the rule descends from what we wrote about benchmarks: the supplier's metrics, obtained on the supplier's cases, count as much as the brochures. The right request is a proof of value on your real cases, with your golden set, your success criteria and a defined duration, and the supplier's willingness to sustain it is itself a data point: whoever has a good product rarely fears the test bench. The fourth area is regulatory. How does the supplier classify its own system under the AI Act, with what written rationale? What documentation does it provide for the obligations that stay with you as deployer, from user-facing transparency to human oversight? The question should be asked today even of suppliers of non-high-risk systems, because the ability to answer measures the maturity of their governance, and because your systems register needs that information anyway. The fifth area looks at the end from the beginning: in which formats do your data and configurations come out if the relationship closes, in how much time, at what cost? Do the customisations built on top of the product remain yours? It is the lock-in theme, which deserves the dedicated article we will give it, and which at purchase time boils down to one principle: exit conditions are negotiated when the supplier wants you, never when you want to leave. ## The method beyond the questions The questions work inside a process, and the minimal process has three properties. The same questions to every candidate, with answers written down and kept, because the memory of demos is generous with whoever presented best. A score with weights decided beforehand, for the same reasons seen in use case prioritisation. And the presence at the table, from the first round, of the people who will use the product and the people who oversee its risks, because you already know the cost of involving them later. In our chain this work lives inside the AI Assessment and the selection that follows, where suppliers get evaluated with the same discipline as use cases: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. And if a negotiation is already underway, the cheapest test of the month fits in a single request: ask the supplier for a proof of value on your data, and watch what happens to the conversation. --- # Benchmarks and model evaluation: what the numbers really say URL: https://zerofive.ai/en/blog/insights/ai-model-benchmarks-evaluation Data: 2026-04-28 Abstract: Why public benchmarks are not enough to choose an AI model for your company, and how to build an evaluation on your real cases that lasts over time. Every new model release now follows a liturgy: the benchmark table with the winning scores in bold, the charts overtaking the competitor, and in the following days the corporate committees asking whether it is time to migrate. The liturgy works because the numbers look objective, and in part they are; the problem is what they measure, and the distance between that what and the work the model will have to do in your company. A distance no public leaderboard bridges, and that can be bridged in only one way, by measuring at home. ## What the leaderboards actually measure Academic and industry benchmarks evaluate general capabilities on standardised tests: knowledge and reasoning questions, mathematical problems, programming exercises, comprehension tasks. They are precious instruments for model developers and for tracking the sector's trajectory, and they suffer from three structural limits when they become purchasing criteria. The first is contamination: public tests end up, directly or through paraphrase, in training data, and a high score may measure memory more than capability. The second is saturation, because on the historical benchmarks the leading models now crowd within a few percentage points, a zone where differences say little and noise says a lot. The third, the most important for buyers, is domain gap: no standard test contains your documents, your industry jargon, your formats, your thresholds of acceptable error, and the correlation between general excellence and performance on your specific task exists, but it is too loose to sign a contract on. To these adds the limit numbers cannot capture by construction: the leaderboard says nothing about latency at your volumes, cost at your traffic, behavioural stability between versions, quality in your working language, all variables that in production weigh as much as capability. ## The evaluation that counts: the golden set The alternative has a surprisingly low initial cost and a name borrowed from engineering: the golden set, a curated collection of real cases of your task, with the expected output defined by the people who actually do the work. For a typical use case, fifty to two hundred well-chosen examples suffice, covering the routine, the edge cases that hurt you and the errors you cannot afford, each with its reference answer and the criteria for judging acceptable variants. On that set every candidate is evaluated under identical conditions, with metrics decided beforehand and tuned to the task: where the output is verifiable you automate, where it is open text you combine sampled human review with assisted evaluation, taking care to check periodically that the automatic judge judges the way you would. The result is a table no public leaderboard can give you, the competing models ranked by quality on your work, with cost and latency measured on your traffic next to them: the three columns a decision gets signed on. The golden set, once built, keeps yielding: it is the bench on which every new model the release liturgy puts in front of you gets tested (migration becomes an afternoon of tests instead of a debate), it is the safety net for verifying that a provider update has not changed behaviours you built upon, and it is the embryo of quality monitoring in production, where the new and difficult cases met in the wild flow back to enrich it. ## The discipline that follows The operational rule we hand to clients fits in one line: no model choice or migration is decided on a public leaderboard, all are decided on the golden set. The leaderboard stays useful for one purpose only, building the list of candidates to bring to the test bench, and for that it is more than enough. There is one practical obstacle, the initial effort of building the set, which requires time from the people who know the task, by definition the busiest ones. It is exactly the kind of work our chain covers with prototyping: in a few weeks golden set and evaluation bench get built together with the first prototype, so that the model choice is born measured and stays measurable: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. In the meantime, if a migration is being discussed in your company on the wave of the latest release, one question brings the conversation back to earth: on how many of our real cases have we tried it, and who judged the answers? --- # Go/no-go criteria: when stopping an AI project is a value URL: https://zerofive.ai/en/blog/strategy/go-no-go-criteria-ai-projects Data: 2026-04-21 Abstract: How to write go/no-go criteria for AI projects: thresholds, dates, decision-makers, and why the ability to stop marks mature organisations. Of the dozens of AI project post-mortems we have witnessed, the most recurrent sentence always comes from someone on the team, never from the minutes: "we knew for months". Projects that fail badly, the ones burning eighteen months and the credibility of every subsequent initiative, rarely die of a surprise; they die from the absence of a mechanism turning what the team knows into a decision the organisation takes. That mechanism has an unpoetic name, go/no-go criteria, and its absence is among the most curable failure causes in the whole repertoire. There is a structural reason why AI projects need it more than others: they are experiments by nature, with uncertain outcomes no planning removes, and an experiment without written stopping conditions is not an experiment, it is an open-ended commitment under another name. The value proposition of serious advisory, we often tell clients, includes the no: an advisor who can only say go is a salesperson with a different business card. ## The anatomy of a criterion that works A go/no-go criterion worthy of the name has four components, and each missing one turns it into a wish. The metric, which must be a business metric or directly linked to one (complaint handling time, user adoption rate, cost per file), never a model metric alone, because brilliant accuracy on a process nobody uses passes every technical threshold and fails anyway. The threshold, with the number written before the start, when nobody yet has interests to defend: above it you proceed, below it the consequence applies. The date, because a threshold without a deadline is a moving finish line, and "one more month and we are there" is the official language of zombie projects. And the decision-maker, one person with a name and signing power, because decisions assigned to a committee have the property of never being taken by anyone. The fifth component, implicit but decisive, is the moment of writing: criteria are fixed at kickoff, inside the initiative's Canvas, together with sponsor and process owner. Writing them mid-project is already negotiating. ## Stop, correct, proceed: three outcomes, not two The name hides a simplification, because the useful outcomes are three. The go confirms and unlocks the next phase with its budget. The no-go closes, and a closure done well has its ritual: the learnings get documented, reusable data and code get archived, the outcome gets communicated with the same visibility as the launch, because a well-closed experiment is paid-for information that must yield. In between sits the pivot, the course correction with new criteria and a new date, which is legitimate once and becomes obstinacy the second time: the practical rule we suggest is a single pivot per initiative, resolved by the decision-maker, never self-granted by the team. Criteria, moreover, do not live only at the pilot's end: mature organisations place them at every phase transition, from idea to pilot, from pilot to MVP, from MVP to production, with progressively more demanding thresholds. It is the same principle as critical gates applied to the single project, and it produces the same effect: it moves resources from what promises to what demonstrates. ## Making the stop socially possible The hard part of no-gos is not technical, it is anthropological. Sunk cost weighs ("we have already spent too much to stop now", which is exactly the reasoning that multiplies the spending), the sponsor has exposed their face, the team fears that closing the project means a judgement on the people. An organisation that wants working criteria must defuse this mechanism, and the tools are known: explicitly separating the evaluation of the experiment from the evaluation of the people, publicly celebrating well-executed closures as much as launches, measuring project leaders also on the speed with which they free resources from what does not yield. In the portfolio, the health signal is counter-intuitive: a physiological share of no-gos says the thresholds were real, while a portfolio where everything always clears every gate tells of criteria written to be cleared. The right question at year end is not how many projects moved forward, it is whether the ones stopped were stopped at the right time. Decision criteria are among the deliverables of our AI Strategy work, written initiative by initiative inside backlog and roadmap, with thresholds, dates and decision-makers: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The test to run today, meanwhile, takes five minutes and one ongoing project: does the condition under which you would stop it exist, written anywhere? And if it materialised tomorrow, who would sign? --- # On-premise, cloud or API: where to run enterprise AI URL: https://zerofive.ai/en/blog/insights/on-premise-cloud-api-where-ai Data: 2026-04-16 Abstract: The three architectures for enterprise AI, managed API, dedicated cloud, on-premise: selection criteria, data constraints, real costs and hybrid setups. After the model choice comes the twin question, where to run it, and the answer draws the setup the company will live with for years: the costs that will become structure, the skills to hire, the constraints every new use case will inherit. The options on the table are three, and before the criteria it pays to name them precisely, because committees often blur them. The managed API: the model lives at the provider, the company consumes capacity on demand. The dedicated cloud: the model, open or licensed, runs on infrastructure the company rents from a hyperscaler, inside a perimeter the company controls. On-premise: own hardware, in one's own data centre, under one's own physical responsibility. The temptation to treat it as a matter of allegiance should be defused immediately, as with models: the right question is per use case, and the target setup of mature organisations is almost always hybrid. ## The constraint commands, the rest negotiates The criterion that decides first, when it exists, is the non-negotiable constraint on data. Some information, by sector regulation, by client clause or by nature (think of certain health, judicial or defence data), cannot cross defined borders, and there the discussion shortens: the choice is between dedicated cloud with contractually solid residency guarantees, sovereign cloud formulas where the sector demands them, or on-premise when even the rented perimeter is not enough. The serious work, in these cases, lies in separating real constraints from presumed ones, because "our data cannot live in the cloud" is a sentence that in assessments turns out, every other time, to be a policy nobody ever wrote that someone remembers badly. Where the absolute constraint is absent, the negotiable criteria come in, and the first is the load profile. The API shines with variable or unpredictable volumes, because it turns everything into marginal cost; owned or rented infrastructure starts paying for itself with high and constant loads, when GPUs work instead of waiting. Latency adds its weight in use cases inline with operations (a system answering an operator in real time tolerates network round-trips badly), and deep customisation adds its own, because extensive fine-tuning and total version control demand infrastructure you command. ## The costs the slides never show The economic comparison between the three routes suffers from a systematic distortion: visible prices get compared, cost per token against GPU rental fees, and the lines that decide the total get omitted. For dedicated cloud and on-premise, the omitted lines are people (engineers able to serve models with production-grade reliability, the most contested profile on the market), actual hardware utilisation (a GPU paid for and idle is the purest cost in existence), and refresh (models improve at such a pace that infrastructure sized today may be serving an obsolete model in eighteen months). For the API the omitted line is the mirror image, growth: the marginal cost that made starting easy scales linearly with success, and high-volume use cases need their maths redone every few months. The practical consequence is that the break-even point exists, moves over time, and must be computed on one's own volumes with every line included. In the accounts we review, the most frequent error remains underestimating the people and overestimating the utilisation. ## Hybrid as the destination, abstraction as the premise With the criteria lined up, the architecture mature organisations converge on is layered: managed APIs for the long tail of low-volume use cases and for whatever demands frontier capability, a dedicated perimeter (cloud or, more rarely, on-premise) for constant loads and for data that does not travel, and a written rule assigning every new use case to the right layer based on constraints, volumes and latency, rather than on the preferences of the proposing team. The technical premise that makes the hybrid governable, and that should be decided at the start when it costs little, is the abstraction layer: applications talk to an internal interface, never directly to the single provider or the single cluster, so that moving a workload from one layer to another is a configuration change and not a rewrite. It is the same insurance against lock-in we discuss for models, applied to infrastructure, and it doubles as a negotiating position: better terms are obtained from anyone when leaving is technically easy. The setup choice, in short, is an exercise in constraints before preferences, and the fastest way to get it wrong is by imitation, copying the architecture of a company whose constraints differ from yours. If you are drawing yours, or renegotiating an inherited one, the starting point is the inventory of real constraints, volumes and skills: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. And for the next committee, a control question that requires no slides: of the constraints keeping you out of the cloud today, or inside it, how many exist in writing? --- # AI Canvas: structuring an AI decision across six dimensions URL: https://zerofive.ai/en/blog/strategy/ai-canvas-decision-six-dimensions Data: 2026-04-14 Abstract: What the AI Canvas is, how the six dimensions work (opportunity, risks, priority, stakeholders, capabilities, dependencies) and why one page beats a deck. The business cases for AI initiatives that reach approval tables suffer from a formal disease: they are documents built to convince, never to decide. Thirty pages where the expected value occupies the cover, the risks sit in an appendix, the dependencies do not appear because nobody looked for them, and the committee receiving them can only choose between trusting and postponing. The AI Canvas was born as a countermeasure to this form: one page, six mandatory dimensions, and the rule that a dimension left blank counts as an alarm, never as a detail to fill in later. The underlying idea is that the quality of a decision depends on the structure with which it is prepared, and that for AI initiatives the right questions are known and number six. Let us walk through them in filling order, which has a logic of its own. ## The first three: what, what can go wrong, how much it matters The opportunity opens the Canvas and demands a precise discipline: the business problem before the technical solution, with the metric that would improve and the signature of whoever owns that metric. "Reduce complaint handling time by 30%, measured by the head of operations" is an opportunity; "use generative AI on customer service" is a technology in search of employment, and the Canvas rejects it by construction. Risks occupy the second box with the same rigour, in four families: system error and its impact on customers or people, the regulatory profile (the use case's AI Act classification, the personal data involved with its legal basis), supplier dependence, and adoption risk, meaning the concrete possibility that the system works and nobody uses it. Priority, the third dimension, positions the initiative inside the portfolio we wrote about: the score on the three axes, the time horizon, what it displaces or postpones in the backlog, because every yes said to one initiative is a no said to another and the Canvas forces you to write down which. ## The second three: who, with which means, after what Stakeholders are the dimension traditional business cases take for granted and failures do not: the executive sponsor with signing power, the process owner ceding the process, the users who will have to change habits, the control functions (risk, legal, the DPO whenever personal data enters the picture) to be involved at the beginning, when they cost hours, rather than at the end, when they cost months. Capabilities census the gap between what is needed and what exists, across data, skills and infrastructure, with an explicit choice for each gap: build, buy, or ally. Dependencies close the loop and are the dimension that most often overturns decisions: what must be true for the initiative to start (that cleaned dataset, that integration, that approved policy) and what this initiative makes possible afterwards, because a mediocre use case that unlocks a reusable foundation can be worth more than a brilliant one that leaves nothing behind. It is the box where the portfolio stops being a ranking and becomes a sequence. ## How it is used, and what it produces The Canvas performs best filled in session, two or three hours with sponsor, process owner, technical lead and one control function in the room, because the value lies as much in the final sheet as in the disagreements that surface while filling it: the session in which it emerges that the estimated value has no signatory, or that the data dependency was known to everyone except the sponsor, has already paid for the method. The output feeds directly into the go/no-go criteria: from opportunity and risks come the success and stop thresholds, from capabilities the true budget inclusive of prerequisites, from dependencies the sequence. And the comparison between different Canvases, all on the same structure, is what allows a committee to decide between initiatives instead of between rhetorics. In our AI Strategy work the Canvas is the instrument through which every backlog initiative is prepared before asking for capital, and the completed version enters the deliverables together with roadmap and decision criteria: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. If you want to test the method without waiting, take the most promising AI initiative in the house and try filling the six boxes in an hour, with the right people in the room: the box that stays blank is telling you something, and it is telling you now, when it costs little, instead of mid-project. Which of the six, shall we bet, will it be? --- # Proprietary or open source LLMs: the selection criteria for companies URL: https://zerofive.ai/en/blog/insights/proprietary-open-source-llm-criteria Data: 2026-04-07 Abstract: Proprietary models via API or open source in-house: the six criteria that truly matter for a company, the cost myths and the portfolio logic. The question arrives in every adoption journey, usually framed as a matter of allegiance: better the proprietary models of the large providers, consumed via API, or the open source models (more precisely open weight, since what is open are the weights and rarely everything else) run under one's own control? The shape of the question is the first thing to correct, because it presupposes a single answer for the company, while the serious answer is given per use case, and almost always in the plural. From a vendor-agnostic position like ours, with no models to sell and no alliances to honour, the criteria we see actually deciding are six, and it pays to walk through them in order of weight. ## Required capability and data sensitivity The first criterion is the distance between what the use case requires and what the two families offer. On frontier tasks, complex reasoning and reliability across difficult domains, the leading proprietary models keep an edge, while on a growing share of corporate tasks, classification, extraction, summarisation on bounded domains, mid-sized open models reach indistinguishable results at a fraction of the cost per token. The practical consequence is that paying frontier capability for routine tasks is the most common waste we find in clients' bills. The second criterion is the data the model will see. For ordinary information, the enterprise contracts of serious providers today offer robust contractual guarantees on non-training and data residency, and they should be read rather than presumed. There remain the cases where data cannot leave, by regulatory constraint, industrial secrecy or client mandate, and that is where the open model on one's own infrastructure stops being an ideological preference and becomes the only option on the table. ## Total cost, with the hidden lines The third criterion is TCO, and the honest comparison looks beyond the price per token. The proprietary route charges for usage and gives everything else away: updates, infrastructure, serving security, scalability. The open route zeroes the licence cost and opens the lines that enthusiastic business cases always miss, the GPUs or cloud for inference, the engineering to serve the model at acceptable latency, the monitoring, and above all the people able to do all this, who are the scarcest and most expensive item on the list. The rule of thumb that emerges: below a certain usage scale the API almost always wins on full cost, and the break-even point should be computed on your real traffic, never on the GPU supplier's slides. The fourth criterion is control, in its concrete forms: the ability to pin a model version and decide its lifecycle (with APIs, the provider can deprecate what you built on), to specialise it in depth through fine-tuning on your own data, to inspect its behaviour for audit needs. Where these needs weigh, open weights weigh with them. ## Compliance, skills and the portfolio logic The fifth criterion is the regulatory profile. The AI Act assigns specific obligations to whoever provides general-purpose models, and consuming via API leaves those obligations with the provider, while whoever takes an open model and modifies it or puts it into service must understand which part of the responsibility chain it is assuming, an evaluation to run with legal counsel beforehand and with written evidence, never after. The sixth criterion, skills, is the simplest to state: the open route is a build choice, and build choices are made with the people you have or are certain you can hire and retain. Lined up, the six criteria almost always lead to the same target architecture, the portfolio: leading proprietary models where frontier capability pays for itself, open or smaller proprietary models where the task is routine and volumes bite, and a technical abstraction layer that allows routing and swapping without rewriting the applications. The portfolio, besides optimising costs, is the best insurance against lock-in, a topic deserving its own article and left here as a contractual reminder: the exit clause is negotiated at the entrance. Model choice, seen from this distance, is a business decision disguised as a technical one, and as such it enters the AI Strategy work we do with clients, inside explicit criteria rather than departmental preferences: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The quick test to see whether your current choice was a decision or a habit fits in one question: could you say, use case by use case, why it runs on the model it runs on? --- # How to prioritise AI use cases: value, feasibility and risk URL: https://zerofive.ai/en/blog/strategy/prioritising-ai-use-cases Data: 2026-04-02 Abstract: A method for prioritising AI use cases: the three evaluation axes, the most common mistakes and how to build a backlog a board can approve. There is a recurring moment in adoption journeys, and it arrives right after the ideation workshops: the company finds itself with a list of thirty, fifty, sometimes a hundred AI use case ideas, all plausible, all sponsored by someone, and a budget that funds five. What happens next decides more of the whole programme's success than any technology choice, and yet it is the step treated with the least method: in most cases the winner is whoever shouts loudest in committee, or the idea most similar to the demo seen at the last event. The data suggests what this selection by acclamation costs. MIT Project NANDA (The GenAI Divide, July 2025) observed that over half of GenAI budgets concentrate on sales and marketing, where results are the most visible to narrate, while the best returns show up in the automation of back office and operational functions, where nobody issues press releases. Capital, left to instinct, goes where things glitter. ## The three axes, and how to measure them without cheating Serious prioritisation evaluates every use case on three axes, and the discipline lies in the how, even before the criteria. Value must be expressed in a business metric someone signs: hours recovered on a process at their full cost, margin points, reduction of a quantified risk, incremental revenue with its assumptions made explicit. The signature is the important part, because a value estimated by the AI team is worth half of one estimated by the process owner who will later answer for it. Feasibility measures the distance between the use case and the conditions for delivering it, and the component that almost always dominates is data, with the five readiness questions we covered elsewhere: access, measured quality, ownership, time, legitimacy. Alongside data weigh the integration required into existing systems and the skills available, in-house or purchasable. Risk, the third axis, crosses the AI Act classification (a use case in Annex III territory carries a set of obligations that changes its timeline and cost), the exposure on personal data and the impact of a system error on the customer or the person. High risk does not disqualify, it informs: it moves the use case later in the sequence, to when governance will be ready to carry it. ## The mistakes that warp the ranking Four distortions recur in almost every portfolio we review. The first is scoring without declared weights, where every function fills the matrix inflating its favourite axis: weights must be decided beforehand, together, and then applied to everyone. The second is the single horizon, which races three-month quick wins against two-year bets on the same scale: a healthy portfolio separates them by construction, typically with a majority share of fast-return initiatives that fund and legitimise the few structural bets. The third distortion is ignoring dependencies: three use cases sharing the same data foundation are worth, together, more than their sum, and sequencing them well collapses the marginal cost of the second and the third. The fourth is the ranking carved in stone, while scores age quickly, because data improves, model costs fall, regulation advances: the backlog is a living artefact, to be revisited at a fixed cadence, with the same seriousness as the first draft. ## From score to resolution The ranking, alone, remains an exercise until it is translated into a format the top can decide upon. The translation that works has three components: the first use cases with their signed value and the prerequisites to close, the go/no-go criteria each will have to pass to move phase, and the list of what was deliberately excluded with the reasons why, which is the most underrated part and the one protecting the programme from endless reopenings. A backlog without explicit exclusions is a wish list with numbers next to it. It is the work our AI Assessment covers, the second link of the chain after the maturity measurement: use case map, scoring on the three axes with shared weights, quick wins identified and a backlog the board can approve knowing what it is choosing and what it is choosing to forgo. If your list of thirty is already on the table and the budget for five too, the method to get from one to the other takes a few weeks to build: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. And if you have already made your ranking, the stress test is a single one: who signed the numbers in the value column? --- # Critical gates: when a high score is not enough URL: https://zerofive.ai/en/blog/ai-governance/critical-gates-ai-maturity Data: 2026-03-24 Abstract: What critical gates are in an AI maturity model, why certain gaps cannot be offset by averages and how to use gates in your own governance. Picture two companies with the same AI maturity score, a dignified 3.2 out of 5. The first is solid everywhere and brilliant nowhere. The second excels at strategy and delivery, but has no inventory of its own systems and processes personal data inside models without anyone ever having assessed the legal basis. A model made only of averages would declare them twins, and would recommend the same road to both, while the second is walking briskly towards a wall the first does not have. Critical gates exist to prevent the model from telling this statistical lie. ## The logic of the non-compensable The principle comes from worlds that have lived with risk longer than AI. In credit ratings, one breached covenant outweighs ten healthy indicators. In security certifications, a major non-conformity blocks the outcome regardless of the elegance of the rest. In aviation, the pre-flight checklist does not compute averages: one failed item keeps the aircraft on the ground even if the other forty are perfect. Across all these domains the lesson is identical, certain conditions change the nature of the risk by their absence rather than lowering a score, and the right mathematics for treating them is the constraint, never the weighting. Our AI Rating embeds this logic: alongside the 0-5 scores on the four dimensions lives a restricted set of gates, conditions verified in binary fashion, and a high merit class requires both the score and the gates satisfied. Class A, for instance, demands a score above 4.0, no area below 3.5 and all gates in order: the third condition is not redundant with the first two, it is what makes them credible. ## Which conditions deserve a gate Not every gap deserves the treatment, otherwise the model degenerates into a list of vetoes and loses its ability to discriminate. The criteria we use to promote a condition to gate status are three, and they must hold together. The gap must be able to revoke the licence to operate, on regulatory grounds (unlawful personal data processing, the absence of the risk classification the AI Act presupposes) or on substantive grounds (no human oversight on decisions affecting people). It must be non-delegable, meaning unsolvable by buying something from a supplier, because whatever can be bought can also be weighted. And it must be foundational, in the sense that its absence makes the other scores unreliable: the systems register is the perfect example, because without a census every other evaluation describes an imaginary perimeter. Applied with this discipline, gates stay few, typically between five and eight, each with a verifiable definition: not "good data management" but conditions ascertainable through evidence, ones a second evaluator would reproduce. ## What they change in behaviour The most interesting effect of gates appears after the assessment, in allocation choices. Without gates, the roadmap tends to chase the points where improvement is easiest or most visible, because every decimal is worth the same. With gates, the sequence inverts on its own: the blocking conditions get closed first, and they are usually the least glamorous ones (the register, the legal bases, human oversight), and only afterwards does the rest get optimised. In the engagements we run this inversion is often the single most valuable contribution of the whole measurement, because it moves budget from what glitters to what holds. There is also an effect on the conversation with the top that deserves naming. Telling a board "we are at 3.2" invites a benchmark comparison; telling it "we are at 3.2 with two gates open, and here they are" invites a resolution. The gate turns maturity from a photograph into a list of decisions, which is the form in which a board can actually use it. ## Building your own The logic is replicable in-house, even without an external model, and the exercise is worth the half day it costs: gather whoever owns risk, data and AI, and ask which conditions, if absent, should stop a project regardless of what it promises. The list that emerges, filtered through the three criteria above, is your first version of the gates, and the honesty test comes right after, checking it against the projects currently running. If some active initiative would not pass your own gates, you have just discovered the most useful thing of the quarter. We do it with the rigour of a model calibrated on dozens of assessments, inside the AI Rating, where scores and gates come out together and the roadmap inherits their priorities: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The question to leave you with is the personal version of the opening one: in your organisation, today, does a condition exist that would stop everything, and is anyone watching it? --- # The AI systems register: why it matters and how to build it URL: https://zerofive.ai/en/blog/compliance/ai-systems-register-how-to-build Data: 2026-03-19 Abstract: The AI systems register is the first governance tool and the base of any AI Act programme: what it contains, how to build it and how to keep it alive. Among all the deliverables of an AI governance programme, the systems register is the one with the most unbalanced ratio between how humble it is and how decisive. Humble because in its first version it is, literally, a table. Decisive because every other governing activity depends on it: you cannot risk-classify what was never censused, you cannot assess the privacy impact of an unknown processing operation, you cannot present to the board the state of a perimeter nobody ever delimited. In our assessments its absence is one of the critical gates that cap the merit class regardless of the other scores, and the choice is deliberate: an organisation that does not know what it uses cannot, by definition, govern it. ## What it is for, beyond the obvious The regulatory function is what pushes most companies to start. The AI Act reasons by systems, and every obligation, from classification to high-risk requirements to transparency, presupposes knowing which systems exist and in which role the company touches them; for deployers of high-risk systems, assessments and documentation require exactly the information a good register already contains. Anyone who knows the GDPR will recognise the logic of the Article 30 record of processing activities, and the kinship is not merely conceptual: many rows of the two registers overlap, and building them in dialogue avoids censusing the same world twice. The managerial function, less quoted, is worth more in daily life. The register is the place where the CFO discovers how much the company truly spends on AI by adding up licences scattered across functional budgets, where the CISO sees the attack surface individual purchases have composed, where whoever evaluates a new use case checks whether a suitable tool already exists, avoiding the third subscription to the same service. It is also the structural antidote to the shadow AI we wrote about: the phenomenon thrives in the absence of an official place where tools can be declared. ## What to write in each row A useful register holds together a few well-chosen pieces of information, and experience suggests about a dozen fields. The system's identity: name, supplier or internal development, description of purpose in business language. The responsibility: the internal owner with first and last name, the function using it. The regulatory profile: the company's role (provider or deployer), the AI Act risk category with its written rationale, the presence of personal data with the related legal basis and the reference to the DPIA where one exists. The operations: the data the system consumes and produces, the systems it integrates with, the status (experimentation, production, retired) and the date of the row's last review. Two warnings save months. The first concerns granularity: the right entry is the system in its context of use, not the product, because the same tool used by marketing for drafts and by HR for screening is one row for procurement and two very different rows for risk. The second concerns initial ambition: the perfect first version is the enemy of the existing first version, and a shared sheet with twenty honest rows beats the platform project starting in six months. Dedicated tools arrive once the register has proven it can live. ## Keeping it alive, which is the hard part Every organisation that built a register then discovered the second half of the job: registers die of obsolescence in silence, and a year-old register is almost worse than none, because it produces false confidence. Survival is designed by hooking updates to the flows where systems are born and change. Procurement is the main hook: no purchase with AI components completes without its register row filled, and the question "does it contain AI?" enters the supplier checklist. The second hook is release: no use case reaches production without registration. The third is the periodic amnesty window for whatever escapes the first two, direct heir of the initial census. Finally a custodian is needed, typically inside the function chairing AI governance, with the explicit mandate to chase incomplete rows: registers do not update themselves out of kindness. Built this way, the register stops being a formality and becomes the map on which decisions are taken, from intervention priorities to the fast answer when an authority, a client or the board asks "which AI systems do you use and how do you govern them?". If that question would catch you improvising today, the first step costs little and can be taken with method inside a full measurement: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The minimal version of the exercise, meanwhile, fits in one empty row and one question: which system would you write down first, and whose name would you put in the owner column? --- # Cleaning and organising data: where to start, in practice URL: https://zerofive.ai/en/blog/insights/data-cleaning-organisation Data: 2026-03-17 Abstract: How to clean and organise company data ahead of AI projects: priorities, recurring defects, repeatable pipelines and the mistakes that waste months. The moment a company decides to "get the data in order" is almost always a good moment arrived at in the wrong way: an AI project has run aground, someone opened the real tables, and the discovery of triplicated master records and fields filled with creativity generated the most dangerous request in the repertoire, let's clean everything. Dangerous because "everything" is not a perimeter, and cleaning programmes without a perimeter share the destiny of Monday diets: solemn start, three weeks of rigour, silent abandonment. Work on data can instead be set up so that it produces visible value in weeks and reusable foundations over years, and the difference sits almost entirely in the first decisions. ## The use case dictates the perimeter The first decision is what not to clean. Company data is a continent, and the part the first AI use cases need is typically a province: the entities feeding that process, the tables the model will drink from, the histories needed for training. Starting there carries two advantages the universal programme will never have, a client waiting for the result (the AI project itself, which funds and justifies the effort) and a verifiable completion criterion, because "data ready for use case X" is a measurable condition, "data in order" is not. Inside the perimeter, the second decision is the order of works, and it pays to follow the hierarchy of damage. First the key entities, customers, products, suppliers, because every defect there propagates everywhere: deduplicating a customer master and establishing a unique key shared between CRM and ERP is worth, alone, more than months of touch-ups on secondary fields. Then the relationships between systems, meaning the reconciliations somebody performs today by hand in a spreadsheet. Only at the end the cosmetics of descriptive fields, which is the visually gratifying and economically least urgent part. ## The four defects you always meet The pathologies of corporate data are surprisingly repetitive, and recognising them speeds up the diagnosis. Duplicates come first: the same entity recorded several times with minimal variants, "Rossi S.p.A.", "ROSSI SPA", "Rossi Spa (new)", which for a model are three different customers. The remedy has a technical part (matching and merging) and an organisational part that outlives it, the rule on who can create new master records and under which controls, because deduplicating without closing the tap is emptying the sea with a bucket. The second defect is free-text fields used as a landfill: notes containing structural information (deadlines, amounts, statuses) because the right field did not exist or nobody filled it. Here modern AI paradoxically offers help, since extracting structure from free text is one of its best trades, provided the output lands in governed fields and not in more notes. The third defect is non-random missing values, the holes concentrating in certain periods or certain branches which, fed to a model, become learned bias. The fourth is diverging conventions, dates in three formats, implicit units of measure, encodings every department bent to its habits: the remedy is called a declared standard, and it holds only if someone answers for it. ## Cleaning that stays clean The most expensive technical mistake of the whole endeavour is cleaning the data instead of building the cleaning, meaning producing a one-off tidied dataset that starts getting dirty again the next day. The right shape of the work is the pipeline: validation, deduplication and standardisation rules written as code, versioned, executed at every refresh, with quality metrics coming out at every run and a place where exceptions land in front of a human eye. The pipeline also changes the economics of the project, because it converts a recurring, invisible cost (the hours analysts and teams spend every month fixing things by hand) into a one-off investment with maintenance, and that recurring saving is often the most solid business case of the whole data programme, more solid even than the AI project that triggered it. The organisational part remains, and it decides durability: every cleaning rule embeds a business choice (which of the two addresses is the good one? below which threshold is a record discarded?), and those choices belong to the data owners, never to whoever writes the pipeline. Where the data governance we wrote about exists, this handover is a flow; where it does not, cleaning gives birth to it out of necessity, one domain at a time. If you are about to open a data workstream ahead of AI projects, the way not to waste the first month is knowing in advance which data matters, in which order and with which thresholds, which is exactly the photograph the AI Rating produces on the Readiness dimension: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. And if the workstream is already open, one control question is worth the entire retrospective: what you are cleaning today, will it still be clean on its own in six months? --- # Data governance for AI: roles, policies and measurable quality URL: https://zerofive.ai/en/blog/insights/data-governance-for-ai Data: 2026-03-10 Abstract: What changes in data governance when AI arrives: roles and responsibilities, data policies, measurable quality with ISO 8000 and AI Act requirements. Data governance lived for years the thankless life of insurance: everyone agrees it is needed, few buy it until the damage arrives. AI changed its status in a couple of years, for a structural reason: a data error inside a traditional process produces an error, while inside a learning system it produces a behaviour, which replicates across every subsequent decision and is discovered late. The European legislator drew the consequence, and Article 10 of the AI Act dedicates explicit requirements to the data of high-risk systems, covering governance, relevance, representativeness and bias management, turning into obligation what used to be good practice. The operational question, for anyone who must build or upgrade it, is what a data governance worthy of AI actually contains. The answer sits in three components, and in one design mistake to avoid. ## Names before committees The first component is responsibility, and the practical rule is that governance exists when every relevant data asset has two names next to it. The data owner answers for the data on the business side: authorises its uses, defines its rules, is accountable for its correctness towards the organisation. The data steward oversees it operationally: monitors quality, handles anomalies, maintains documentation. Without these two roles assigned in writing, every AI project restarts the negotiation from scratch, and the scene we see most often in assessments, a team spending weeks searching for "someone who can tell us whether this data can be used", is the exact symptom of their absence. The data governance committee, so beloved by frameworks, comes afterwards and exists to arbitrate conflicts between owners, never to replace them. A committee without underlying owners is a recurring meeting about nobody's data. ## Policies written for builders The second component is the rules, and the quality criterion is that they must be consultable by whoever is building at the moment of building, not only by audit after the fact. The policies that matter for AI answer project-shaped questions: which categories of data may feed which categories of systems, under which approvals; how the provenance (the lineage) of a training dataset is documented, so that a year later it is possible to reconstruct what a model learned from; which quality thresholds a dataset must pass before entering a pipeline; how retention and deletion are handled when data lives inside models and not only inside tables. On this last point, the GDPR and AI Act pair we covered elsewhere enters data governance as a design requirement, because a deletion requested by a data subject is manageable if lineage exists, nearly impossible if nobody knows which trainings that data passed through. ## Quality that gets measured, against a standard The third component is quality made measurable, and it is the one separating real governance from a statement of intent. The ISO 8000 standard offers the vocabulary: completeness, accuracy, consistency, timeliness, uniqueness, validity, each measurable with concrete metrics on the tables that matter. The maturity leap lies in moving from judgement ("the CRM data is good") to a number ("customer master completeness at 94%, duplicates at 3%, average refresh 36 hours"), because only the number allows thresholds, trends and owner accountability. For AI, measurement must be tuned to the use case, with a declared threshold below which the dataset does not enter the pipeline, and monitoring that continues in production, since data degrades and models degrade with it. It is the same principle as the critical gates we apply in the AI Rating: below certain conditions you do not compensate, you stop. ## The mistake of the total build The most widespread design mistake is conceiving governance as a total installation to complete before any AI, with years of catalogues, committees and universal policies. The total project almost always fails for the same reason as the grand data quality programmes, no visible return keeps it alive, and in the meantime it blocks everything else. The approach we see working proceeds by perimeters: start from the data domains the first AI use cases touch, assign owners and stewards there, write the policies that are genuinely needed, measure the six quality dimensions, and let the AI roadmap extend the governed perimeter one domain at a time. Governance thus grows at the speed of the value it enables, which is also the best way to defend its budget. In our AI Rating, data governance runs through Readiness and Risk, with precise evidence: roles assigned or vacant, policies existing or presumed, quality measured or perceived, and every gap enters the roadmap with a priority and an owner. If you wanted to apply the minimal test today, take the three data sources most critical to your next AI project and write the owner's name next to each: if one of the three lines stays blank, you know where to start. For the full version: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. Data governance, tested against AI, boils down to an almost civil-registry question: whose data, first and last name, are you about to build on? --- # AI and GDPR: where they overlap and where they pull apart URL: https://zerofive.ai/en/blog/compliance/ai-gdpr-overlaps-tensions Data: 2026-03-05 Abstract: The AI Act and GDPR apply together: legal bases, automated decisions, DPIA and FRIA. Where the two rules reinforce each other and where they create friction. A dangerous belief circulates in AI projects, namely that the AI Act has somehow replaced or absorbed the GDPR on the terrain of artificial intelligence. The two rules, in reality, apply in parallel and in full: the AI regulation disciplines systems according to their risk, the GDPR disciplines personal data processing wherever it happens, and an AI system touching personal data answers to both, with different supervisory authorities, sanctions and logics. The Italian data protection authority made the point in the most concrete way, with the 15 million euro fine imposed on OpenAI (December 2024) grounded entirely in GDPR violations, legal bases and transparency first, without waiting for any AI Act deadline. For anyone leading AI projects inside a company, the map of overlaps and tensions between the two rules is worth more than many hours of generic training, because that is where both the risks and the shortcuts that later present their bill are hiding. ## Where the two rules row together On three fronts the AI Act and the GDPR ask for converging things, and whoever has worked well on privacy starts with an advantage. The first front is self-knowledge: the record of processing activities under Article 30 GDPR and the AI systems census are cousin exercises, and a company with the first in order builds the second in half the time, often discovering that many rows coincide. The second front is impact assessments. The GDPR's DPIA and the fundamental rights impact assessment the AI Act introduces for certain deployers of high-risk systems share their logical structure and a good part of the evidence: description of the processing, risks for people, mitigation measures. Making them talk inside a single process avoids duplications and inconsistencies between documents an authority would read side by side. The third front is human oversight of decisions. Article 22 GDPR has limited for years decisions based solely on automated processing with legal or similarly significant effects on people, and the AI Act reinforces the principle with its oversight requirements for high risk: whoever has already designed processes with meaningful human intervention, not a rubber stamp, already owns the backbone of both compliances. ## Where the tension comes from The real friction sits in the underlying principles, because the GDPR was born to limit processing and contemporary AI thrives on abundance. Data minimisation asks to process only what is necessary, while model development pushes to collect everything that might serve. Purpose limitation binds data to the purpose declared at collection, while reuse to train or feed AI systems is almost always a new purpose, requiring a compatibility assessment or a legal basis of its own. Transparency demands understandable explanations, and the most powerful models remain the least explainable. On this terrain the easy answers are almost always wrong. "The data is anonymous" rarely survives serious analysis, because the threshold of true anonymisation is high and pseudonymisation leaves data inside the GDPR perimeter. "We rely on legitimate interest" requires the documented balancing test, which for large-scale training is anything but a given, as the proceedings of European authorities have shown. "The supplier is compliant" overlooks that the company remains controller of its own processing, with responsibilities no contract transfers in full. ## The method for holding them together The operational way to govern the pair starts with an organisational move before a legal one: the DPO and the AI owner must work at the same table, with a process that intercepts every new AI use case before kickoff and asks it three questions in sequence. Is personal data involved, even indirectly? If so, on which legal basis and for which purpose, and is it the same purpose as the original collection? Does the decision the system supports produce significant effects on people, and if so how is human intervention designed? The answers feed a single card per system, the same card used for the AI Act risk classification, and the pair of rules stops being two separate workstreams to become one process with two checklists. In our AI Rating this weave lives inside the Risk dimension, where privacy and AI Act are evaluated together and personal data gaps count among the critical gates, because unlawful processing is not a weakness for a weighted average, it is a condition that can stop the system. The tension between data protection and AI ambition is never dissolved once and for all, it is administered case by case, and companies that administer it with method discover a precious side effect: constraints, taken seriously at design time, produce systems that are leaner on data and sturdier over time. If you want to understand where your organisation stands on this weave, measurement is the entry point: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. And the question to bring to the next committee is precise: of the AI systems active today, how many have a written legal basis for the data they consume? --- # Data readiness: why AI projects die on data URL: https://zerofive.ai/en/blog/insights/data-readiness-ai-projects Data: 2026-03-03 Abstract: The most cited cause of AI project failure is data. What data readiness is, how to verify it before investing, and what to do when it is missing. In the autopsies of failed AI projects, technology rarely appears among the causes, data almost always does. RAND Corporation (2024) places inadequate data foundations among the primary reasons behind the more than 80% of projects missing their intended value, MIT Project NANDA (The GenAI Divide, July 2025) identifies poor data readiness and broken workflow integration as the root of the 95% of GenAI pilots with no P&L impact, and Gartner (2025) formulated the sharpest prediction: through 2026, organisations will abandon 60% of AI projects not supported by AI-ready data. The paradox is that data is also the most predictable failure cause of all, because unlike the sponsor who changes roles or the market that moves, its condition can be verified in full before spending the first euro. It takes wanting to do it, and knowing what to look at. ## The illusion of the demo dataset The mechanism by which data kills projects follows a recurring dynamic we described when writing about stalled pilots, and it deserves to be seen from the data side. The pilot runs on a curated extract: someone who knows a system well exported a table, cleaned it by hand, resolved the duplicates and filled the holes. On that material the model works, the demo convinces, the project accelerates towards production. In production, though, the model must drink from the real source, and the real source is another matter: customer master records duplicated between CRM and ERP with keys that do not talk to each other, free-text fields filled ten different ways over ten years, histories interrupted by migrations, fresh data arriving days later than the process needs it. The manual work that made the demo possible cannot be repeated every night, and the project enters the phase that consumes budget and patience, the one where everyone discovers that the real construction site was never the model, it was everything upstream of it. ## The questions that measure readiness Data readiness lets itself be interrogated with concrete questions, and they should be asked for the specific use case, because data that is excellent for one application can be useless for another. The first concerns access: is the necessary data reachable programmatically and repeatedly, or does it live behind manual extractions, personal spreadsheets, suppliers to be begged? The second concerns measured quality, which is a different thing from perceived quality: do completeness, accuracy and consistency metrics exist on those tables, or does the judgement rest on the fact that "the ERP works"? The third question concerns ownership: for every source, is there a person accountable for its quality who can authorise its use, or is the only expert a colleague who "knows that system"? The fourth concerns time, in its two forms, enough historical depth to train and enough freshness to serve the process. The fifth, often forgotten, concerns legitimacy: can that data be used for that purpose, on that legal basis, or is the project building on a processing operation nobody ever assessed? A use case that answers all five well is rare, and that is fine: readiness does not demand perfection, it demands knowing the gaps before starting and putting them into the budget and the plan, instead of discovering them at the worst possible moment. ## Fixing data without the alibi of the endless programme Faced with a mediocre data landscape, organisations swing between two mirror-image mistakes. The first is starting anyway, trusting that "we will fix the data along the way", which is the exact script of the failures catalogued by the research above. The second is indefinite postponement, the great three-year data quality programme that must complete before any AI, and that usually starves to death because no business case keeps it alive. The path we see working is surgical: you fix the data the chosen use case needs, in depth and with reuse criteria, and let the sequence of use cases progressively extend the perimeter of data in good order. Every AI project thus becomes an incremental investment in foundations too, with a visible return financing the next one, and data readiness stops being an abstract prerequisite to become a measurable by-product of the roadmap. ## Measuring before betting In our AI Rating the condition of data runs through the whole evaluation: it weighs on Readiness (quality, accessibility and ownership of sources), conditions Delivery (pipelines and integration) and touches Risk, where data oversight is one of the non-compensable critical gates, consistent with what the EU AI Act asks on data for high-risk systems and with quality standards such as ISO 8000. The score says, before the investment, whether the next pilot rests on rock or sand, and what consolidating costs. If you have an AI project starting in 2026, the most profitable exercise of the week costs one hour: take the use case and ask it the five questions above, in writing, with source names next to each answer. If you prefer doing it with method and a comparable score, you will find us at calendly.com/fabiolalli/zerofive or hello@zerofive.ai. The uncomfortable version of the question, the one worth the entire budget, remains a single one: your next model, where will it drink from every night? --- # How to present the state of AI to the board of directors URL: https://zerofive.ai/en/blog/ai-governance/presenting-ai-to-the-board Data: 2026-02-24 Abstract: What a board presentation on AI must contain: the headline number, the gaps, the roadmap with trade-offs, and the mistakes that lose the room. The AI presentations reaching boards of directors belong, with few exceptions, to two genres. The first is the technology tour: twenty slides on what generative models are, a demo, a list of ongoing initiatives, applause and no decision. The second is the anxiety genre: a review of risks, AI Act sanctions, news stories, with the effect of freezing every initiative. Both fail for the same reason, they do not give the board what a board lives on: comparable numbers, options with trade-offs, a precise request to deliberate upon. The topic is less niche than it sounds, because the audience of boards that will have to face it is enormous: according to the Artificial Intelligence Observatory of Politecnico di Milano (2025 research, February 2026), 71% of large companies run active AI projects and only 9% have structured management. In the distance between those two numbers sit thousands of boards that sooner or later will ask "where do we stand?", and someone will have to answer in twenty minutes. ## The opening number The presentation that works opens with a measure, never with context. A maturity rating on a known scale (in our model, 0-5 with classes from A to D) gives the board in thirty seconds what reviews of initiatives fail to give in an hour: a position. "We are a class C, with Readiness at 3.1, Delivery at 2.8, Risk at 1.9 and Confidence at 2.5" is a sentence every director can interrogate, compare with next quarter, use to hold management accountable. The number works under two conditions. The first is transparency about the method: where it comes from, on what evidence, with what repeatability, because an experienced board rightly distrusts self-produced scores. The second is honesty about the uncomfortable part, and here critical gates help: saying that the class stays capped until the systems register required by the regulatory framework exists conveys more credibility than ten slides of successes. ## The three blocks that follow After the position, the effective presentation stands on three blocks, each with its own deliberative function. The first block translates gaps into exposure: what the company concretely risks by staying where it is, in terms the board already handles. The regulatory gap becomes exposure to sanctions and exclusion from tenders demanding governance evidence; the data gap becomes capital invested in pilots with a high probability of failure; the skills gap becomes dependence on suppliers. Each exposure should be quantified where possible and dated always, because the cost of inaction has a time profile and the board must see it. The second block is the roadmap with its trade-offs, presented as a choice and never as a single plan to ratify. Two or three scenarios with different investment intensities, each with what it closes, what it postpones and what it risks, give the board the material to practise its trade, which is allocating capital across alternatives. The single plan asks for trust, the scenarios ask for a decision, and boards decide more willingly than they trust. The third block is the ask, one and precise: approve the phase-one budget, appoint the owner with a mandate, put the twelve-month re-assessment on the agenda. Presentations without an ask produce the most frequent board minute in existence, "the board takes note", which is the formal way of not deciding. ## The mistakes that lose the room Three practices sink even well-built presentations. The first is jargon: talking about RAG, fine-tuning and agents to an audience that allocates capital moves the conversation from the board's terrain to the presenter's, and a board that does not understand postpones. Translating into business language is not a simplification, it is the job. The second is the live demo, which steals minutes from deliberation and shifts attention from the state of the organisation to the capabilities of the tool, which was not the question. The third is presenting only successes: a board that discovers problems from other sources, an audit, an article, a whistleblower, stops using management presentations as a source, and that trust is not rebuilt in one meeting. ## From event to routine The single presentation, however successful, solves little if it stays an event. The underlying goal is bringing AI into the board's ordinary reporting cycle, with the rating on the dashboard next to financial KPIs, updated at every measurement, and a defined cadence for exceptions. It is the criterion behind the Executive Presentation we build inside the AI Rating, the deliverable designed for the board: strategic summary, positioning, recommendations, in a format a board can absorb and reuse. If you have a board meeting scheduled in the coming months with AI on the agenda, preparing it from a real measurement changes the quality of the discussion: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. And if you have already given your last AI presentation, the retrospective test is merciless but useful: what did the board actually resolve? --- # ISO/IEC 42001: what an AI Management System is and who really needs it URL: https://zerofive.ai/en/blog/compliance/iso-42001-ai-management-system Data: 2026-02-19 Abstract: ISO/IEC 42001 is the first certifiable standard for AI management: how it is built, what it demonstrates, its relationship with the AI Act and who certification makes sense for now. In the AI governance conversations of recent months one acronym has started circulating with growing insistence, pushed by the consultants selling it and by the enterprise clients beginning to demand it from suppliers: ISO/IEC 42001. As happens to every young standard, disproportionate expectations have formed around it in both directions, those treating it as the pass that solves the AI Act and those dismissing it as yet another badge. It is worth looking at it for what it is, because certain organisations really need it, others do not yet, and the difference can be stated with precision. ## A management system, not an exam on models ISO/IEC 42001:2023, published at the end of 2023, is the first certifiable international standard for an artificial intelligence management system, an AI Management System. The word that carries weight is "management": the standard does not evaluate your models, does not measure output accuracy, does not pass or fail algorithms. It certifies that the organisation has built the machine to govern them: policies and objectives, roles and responsibilities, assessment of AI systems' risks and impacts across the lifecycle, operational controls, monitoring, continuous improvement, all within the harmonised structure that anyone familiar with ISO 9001 or ISO/IEC 27001 will recognise at first glance, plus an annex of AI-specific controls covering everything from system lifecycles to data, from stakeholder transparency to responsible use. The kinship with 27001 is not a technical detail, it is the good news for many companies: whoever already runs an information security management system owns the scaffolding, the internal audit processes, the documentary culture, and the extension to AI is an incremental workstream instead of a foundation from scratch. In the journeys we observe, this is the variable that more than any other separates the six-month projects from the eighteen-month ones. ## The relationship with the AI Act, said without shortcuts The question everyone asks is whether certification shelters you from the European regulation, and the honest answer has two halves. The first: no, ISO 42001 does not equal AI Act conformity, because the standard is voluntary and organisational while the regulation imposes specific obligations per system and per risk category, and no certificate replaces the classification of your use cases, the technical documentation where required, the transparency obligations. Whoever sells you the certification as "guaranteed AI Act compliance" is selling a phrase that we, as a matter of policy, never use. The second half, though, weighs in the opposite direction: the regulation asks organisations for exactly the kind of evidence an AIMS produces by construction, assigned roles, risks assessed and recorded, documented processes, periodic reviews. The standard is the organisational machine that generates the evidentiary material, and reaching the regulation's deadlines with that machine running changes the nature of the work: you compile what exists instead of reconstructing what is missing. It is the same principle that holds for 27001 with respect to GDPR, never equivalence, always equipment. ## Who needs it now, who does not yet The profile that needs certification today is recognisable. Suppliers of AI solutions and services to enterprise clients, for whom the certificate is becoming a procurement requirement, as happened with 27001 a decade ago. Organisations in regulated or exposed sectors, where board, audit and supervisors ask for demonstrable guarantees and an accredited certificate speaks their language. International groups wanting a single apparatus spendable across jurisdictions, since the standard travels where national regulations diverge. The opposite profile is just as recognisable: the organisation with few tools in use and a governance still to be founded, for which starting from certification means buying the scaffolding before the house. The figure from the Politecnico di Milano Observatory presented in February, 9% of large companies with structured AI governance, says the majority sits in this second profile, and for the majority the sensible sequence remains the one we have been writing about for weeks: first the inventory, the classification, the responsibilities, then, once governance exists and needs demonstrating, the standard that certifies it. Certification is the photograph of a maturity, and photographing an empty room produces only an empty certificate. For those in the first profile, the realistic path deserves its true timeline on the agenda: gap analysis against the standard, implementation of the missing controls, two-stage certification audit, annual surveillance, with horizons that in practice are measured in two or three semesters rather than months. Our trade sits on the step before: the AI Rating measures where you stand against what the standard would ask, the Risk dimension produces the gap analysis, and the roadmap says whether and when certification sensibly enters the plan, because this too, like everything in this series, is a decision to be taken with evidence: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The preliminary test, meanwhile, costs one question in committee: if the certification audit were six months away, which chapter of your management system today does not exist even as a draft? --- # AI washing: how to tell real adoption from communication URL: https://zerofive.ai/en/blog/insights/ai-washing-real-adoption-communication Data: 2026-02-17 Abstract: What AI washing is, why it has become a legal risk beyond a reputational one, and the concrete tests to tell real AI adoption from communication. The data presented by the Artificial Intelligence Observatory of Politecnico di Milano (2025 research, February 2026) contains a pair of numbers that, read together, describe a phenomenon rarely discussed: 84% of large Italian companies hold Generative AI licences, and only one in five uses AI pervasively across multiple functions. Between those two percentages lives the corporate version of what markets call AI washing, the distance between what a company says it does with artificial intelligence and what actually happens in its processes. The term was born for the extreme cases, and there at least case law has already moved: in March 2024 the US SEC sanctioned two investment firms for misleading statements about the use of AI in their products, opening a line of enforcement that anyone communicating with investors and clients would do well to know. The version we meet most often in our assessments, though, is less malicious and more insidious: companies telling themselves, in good faith, a story of adoption their internal numbers do not confirm. ## The three forms of the phenomenon The first form faces outward and is the best known: press releases, annual reports and pitches describing AI capabilities oversized relative to reality, to attract capital, clients or talent. Here the risk has stopped being merely reputational, because between financial regulators' enforcement, the AI Act's incoming transparency obligations and increasingly technical due diligence in M&A deals, the distance between declared and verifiable has become a measurable liability. The second form faces inward, and it is the one that costs most without ever making a newspaper: activity theatre. Task forces, hackathons, licences distributed like confetti, a "head of AI" appointed without mandate or budget, dozens of PoCs celebrated and never taken to production. Each element, taken alone, is legitimate, but the whole produces the illusion of movement, and the illusion is more dangerous than declared immobility because it switches off the urgency to get serious. The third form is the most recent and comes from suppliers: traditional products rebranded "AI-powered" for one marginal feature, roadmaps promising future capabilities as if they were present. For buyers, recognising it has become a procurement skill. ## The tests that do not lie Telling real adoption from its representation requires questions communication cannot answer on behalf of the systems. The first test is an accounting one: does a P&L line, an operational KPI or a process metric exist that has changed in a way attributable to an AI system? Real adoption leaves traces in the numbers the company already measures, narrated adoption lives only in numbers created to narrate it (people trained, prompts written, workshops held). The second test concerns production: how many AI systems are integrated into core processes, with users who use them because the workflow runs through them, and not because they were asked to try them? Licences measure spending, integration measures adoption, and the two Observatory figures quoted at the opening show how far apart they can drift. The third test concerns governance, and it is the fastest to administer: does a systems register exist, a risk classification, an owner with a mandate, a process for deciding what starts and what stops? In the same Politecnico research, only 9% of large companies report structured AI management. An organisation that communicates AI leadership and fails this third test is describing an aspiration, which is legitimate provided it is the first to know. ## Why it pays to dismantle it yourself Internal AI washing has an uncomfortable property: sooner or later somebody dismantles it, and it pays greatly for the company to be the one. If an investor dismantles it in due diligence, the bill is paid in valuation. If an enterprise client dismantles it with a tender demanding governance evidence, it is paid in contracts. If an authority dismantles it, it is paid in sanctions and executive time. If employees dismantle it, and they are always the first to notice the distance between the press releases and their work tools, it is paid in the hardest currency to buy back, the credibility of the next initiatives. Self-dismantling has a less dramatic name, it is called measurement. A maturity rating run with method, on evidence and multi-level interviews, produces exactly the photograph separating the real from the narrated, and produces it in a context where discovering gaps opens a roadmap instead of a crisis. It is the work we do with the AI Rating, and the most frequent effect on clients is not disappointment, it is relief: knowing where you truly stand frees the energy that maintaining the narrative was consuming. Communication, to be clear, remains legitimate and even necessary, on one condition: that it chases the facts instead of running too far ahead of them. If you wanted to check today which side your organisation is on, the three tests above can be administered in one meeting, and the full version in four to six weeks: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. We will suggest the uncomfortable closing question ourselves: if tomorrow you had to prove, evidence in hand, your company's latest public statement about AI, what would you prove it with? --- # 71% of large companies run AI projects. Only 9% govern them URL: https://zerofive.ai/en/blog/insights/71-percent-ai-projects-9-percent-governance Data: 2026-02-12 Abstract: Data from Politecnico di Milano's AI Observatory: 71% of large Italian companies run AI projects, only 9% have structured governance. What the gap means. The figures presented last week by the Artificial Intelligence Observatory of Politecnico di Milano (2025 research, February 2026) tell two stories at once, and they are worth reading together. The first is a story of speed: the Italian AI market reached 1.8 billion euros, up 50% in a year, 71% of large companies have started at least one AI project, 84% hold active Generative AI licences. The second is a story of emptiness: only 9% of large companies have structured AI management, and just 15% have launched organic EU AI Act compliance programmes. Sixty-two percentage points separate those who do from those who govern what they do. At the tables where we work this gap has a precise face, and it is that of the CFO or the risk manager discovering in a committee meeting how many AI systems actually run inside the company, and for how long, without anyone ever having taken inventory. ## What that 71% actually contains The adoption figure, taken alone, says less than it seems to. The same research specifies that only one company in five uses AI pervasively across multiple functions: for the majority, "having projects" means localised experiments, distributed licences, individual use cases started from below. Adoption is wide and thin, like a coat of paint. Then there is the number that should keep security and compliance leaders awake: eight workers out of ten use AI tools their company never sanctioned (same source). Documents uploaded to consumer services, customer data inside prompts, unverified outputs flowing back into processes. Shadow AI appears in no official inventory, and yet it is, in all likelihood, the largest AI perimeter of most Italian organisations right now. Lined up, the picture is that of an adoption that happened anyway, with or without the organisation's permission, while the capacity to govern it stayed at the starting line. ## Why governance always comes later (and why the sequence is wrong) The charitable explanation for the 9% is that governance physiologically follows innovation: first you experiment, then you regulate. The explanation holds for low-impact technologies, and AI is not one, for two reasons the numbers themselves suggest. The first is that AI touches decisions, not just processes. A system that screens candidates, evaluates credit files or suggests clinical priorities produces effects on people, and the European legislator has already codified this: the EU AI Act has been in force since August 2024, the bans on unacceptable-risk practices and the AI literacy obligation have applied since February 2025, and the calendar of upcoming application deadlines is public. Companies sitting today in the 91% without structured governance are not postponing a future obligation, they are accumulating a backlog on duties that are partly already in force. The second reason is economic. The Observatory's research records a 93% increase in AI skills requested in job postings and 41% of workers performing, thanks to AI, activities that were previously out of reach: the value is there, and this is exactly what makes disorder expensive. Without prioritisation criteria, every function buys its own tool, data stays in silos, pilots multiply without ever consolidating, and spending grows faster than returns. Governance, seen from here, has little to do with the brake many imagine: it is the mechanism that decides where to concentrate capital that would otherwise disperse. ## Joining the 9%, with method The good news is that moving from the 91% to the 9% is a known journey, and it does not start with an ethics committee or a statement of principles. It starts with a measurement. In our assessments (34+ projects delivered, ZeroFive.AI data, 2026) the sequence that works has three stages, and the first is an honest census: which AI systems exist in the company, shadow ones included, who uses them, on which data, with which risk classification under the AI Act. This is the AI systems register, and it is at once the first sensible obligation and the first management tool. The second stage is the maturity rating: measuring on an objective scale the organisation's capacity across preparation, execution, risk and adoption, to know which gaps are blocking everything else. The third is the roadmap with assigned responsibilities, 30-day quick wins and a re-assessment after twelve months, because an isolated snapshot ages quickly and the value lies in comparing two measurements. Our AI Rating covers exactly these three stages in four to six weeks. Companies that have done it report a precious side effect: for the first time board, IT and risk look at the same number, and the AI conversation stops being a collection of anecdotes. The Observatory's data will be updated in a year, and the easy prediction is that the 71% will climb further. The open question concerns the other number: if the 9% stays where it is, the gap will stop being an industry statistic and start deciding, company by company, who turned spending into advantage and who merely joined the race. If you want to know which side of the gap you are on, half an hour at calendly.com/fabiolalli/zerofive is enough to find out, or write to hello@zerofive.ai. --- # AI risk classification: how to map your use cases under the AI Act URL: https://zerofive.ai/en/blog/compliance/ai-systems-risk-classification Data: 2026-02-10 Abstract: The four risk categories of the EU AI Act and a practical method to map and classify corporate AI systems, with the most common mistakes to avoid. The entire architecture of the EU AI Act rests on an idea that is simple to state and laborious to apply: obligations depend on the system's risk, so until a company has classified its systems it does not even know which articles apply to it. Classification is the passage from the regulation as read to the regulation as applied, and it is also the point where compliance programmes meet their first concrete obstacle, because before classifying you need to know what to classify, and almost nobody truly does. ## The four categories, briefly Regulation (EU) 2024/1689 organises systems into a pyramid. At the top, unacceptable-risk practices, banned since 2 February 2025: harmful subliminal manipulation, social scoring by public authorities, emotion recognition in the workplace and in education (with narrow exceptions), indiscriminate scraping of facial images. Here the only useful classification exercise is making sure you are not inside, even indirectly through a supplier. Below sit the high-risk systems, the operational heart of the regulation. Annex III lists the domains: biometrics and identification, critical infrastructure, education and training, employment and worker management (from CV screening to decisions on promotions and dismissals), access to essential public and private services (credit scoring included), law enforcement, migration and justice. To these are added systems acting as safety components in already-regulated products (Annex I). For high risk the heavy obligations kick in, from risk management to technical documentation, from human oversight to registration, on an application calendar that the Digital Omnibus proposal presented by the Commission in November 2025 seeks to recalibrate, without touching its substance. The third level is limited risk, where the main obligation is transparency: whoever interacts with a chatbot must know it, generated content must be recognisable. At the base, minimal risk, which covers the large majority of systems and carries no specific obligations beyond existing general law. ## The method: from census to system card Classification done properly is a four-move process, and the first move is not legal: it is a complete census of what the organisation uses. Complete means including systems bought as such, AI features activated inside software already under licence (the screening module of the HR suite, the recommendation engine of the e-commerce platform), internal developments, and tools used informally by teams, because shadow AI is not exempt from the regulation just because nobody authorised it. The second move assigns each system the company's role, which determines the package of obligations: provider if you develop it or place it on the market under your name, deployer if you use it under your authority, with intermediate cases (substantial customisations can turn a deployer into a provider, one of the most underestimated traps in contracts). The third move is the classification itself, system by system, with a card documenting the purpose, the Annex III domain possibly touched, the data processed, the people impacted and the assigned category with its rationale. The written rationale counts as much as the outcome, because in the event of an inspection it demonstrates that the evaluation was done with method rather than reconstructed after the fact. The fourth move links each classification to its consequent obligations and to an owner, turning the map into a plan. ## The mistakes we see most often Three mistakes recur with a frequency that makes them predictable. The first is delegating classification to the supplier, accepting their self-assessment as final: the vendor has an obvious incentive to classify low, and the deployer's responsibility remains with the deployer. Supplier declarations should be obtained, verified and integrated into your own analysis, with contractual clauses covering updates and changes of purpose. The second mistake is classifying by technology instead of by use. The same language model can be minimal risk when it summarises internal documents and high risk when it enters a personnel selection process: the category follows purpose and context, which means every new use case of an already-censused tool requires a new evaluation, not a reference to the previous one. The third mistake is treating classification as a one-off exercise. Systems evolve, suppliers update, teams find new uses, and a map frozen six months ago describes a company that no longer exists. Classification lives inside the AI systems register and gets updated through a process, typically hooked to procurement and to the release of new use cases. ## From obligation to prioritisation tool There is a side benefit that makes this work less thankless than it seems: the map of systems classified by risk is also a map of where AI touches the decisions that matter, and therefore an excellent starting point for prioritising investments and controls. In our AI Rating the census and the classification feed the Risk dimension, and the gaps that emerge (uncensused systems, unmotivated categories, ambiguous contractual roles) enter the roadmap with their priority. If your map today is a partial list in a spreadsheet, you are in large company, and the next step is shorter than feared: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. We leave you the question to start from: of the AI systems your company is using this week, how many have a risk category written down anywhere? --- # The four dimensions of AI maturity: Readiness, Delivery, Risk and Confidence URL: https://zerofive.ai/en/blog/ai-governance/four-dimensions-ai-maturity Data: 2026-02-05 Abstract: Readiness, Delivery, Risk and Confidence: what each AI maturity dimension measures, why all four are needed and how to read them together. When a client asks us why our rating model measures four dimensions instead of producing a single "AI readiness" index, the most honest answer comes from the cases we have watched fail. A company with excellent data and zero capacity to take models into production fails in one way. One with brilliant delivery and no risk oversight fails in another, more expensive way. One that is technically impeccable but that the board abandons at the first difficult quarter fails in a third way still, the quietest one. A single index would average these profiles and make them indistinguishable, while the decisions that matter are taken precisely on the differences. The four dimensions of the AI Rating model come from here, and it is worth looking at them one by one before understanding how they read together. ## Readiness, or the foundations The first dimension photographs the organisation's preparation: does a deliberate AI strategy exist, or a collection of initiatives? Who governs priorities? Is the data accessible, of known quality, with clear ownership, or does it live in silos every project must reconquer from scratch? Can the infrastructure carry AI workloads? Are the skills widespread, or concentrated in two people who, if they left tomorrow, would take the company's capability with them? Readiness is the dimension where companies overrate themselves most often, for a precise reason: strategy and governance can be told well in slides, while data quality is only discovered by going to look. In our assessments the gap between the Readiness declared in executive interviews and the one measured on evidence is, on average, the widest of the four dimensions. ## Delivery, or the factory The second dimension answers a different question: assuming the organisation is ready, can it build? Here we measure development processes, the presence of MLOps practices (model versioning, reproducible pipelines, retraining), the ability to integrate AI into existing systems rather than leaving it in parallel applications, the monitoring of what runs in production, scalability beyond the single use case. Delivery is the favourite dimension of technical teams and the one vendors promise to solve, and it is also the least decisive on its own: an excellent factory receiving the wrong priorities produces, with great efficiency, things nobody needs. The pattern we meet frequently in scale-ups is exactly this, Delivery at 3.5 and Readiness at 2, with the result of lightning-fast prototypes that never find the data or the sponsor to become anything more. ## Risk, or the licence to operate The third dimension measures oversight: compliance with the EU AI Act (from the bans already in force since February 2025 to the risk classification of systems), alignment with ISO/IEC 42001 as a management standard, control over model bias and fairness, security and personal data protection, the existence of processes for handling incidents. On Risk a rule applies that we have built into the model as critical gates: certain gaps cap the merit class regardless of the average of the other dimensions, because a missing systems register or personal data out of control are not weaknesses to offset, they are conditions that can revoke the licence to operate. It is the dimension where the cost of inaction grows over time by construction, since the European regulatory calendar advances regardless of corporate plans. ## Confidence, or whether anyone believes in it The fourth dimension is the one that sounds soft until you look at adoption data. It measures the board's real commitment (multi-year budget or instalment experiments?), internal users' trust in the systems they are supposed to use, the perceived robustness of the solutions, actual adoption against declared adoption. We have watched it decide the fate of technically perfect projects. A decision-support system users work around because they distrust its suggestions is worth zero, whatever its accuracy, and a board that cuts the budget at the first setback retroactively turns the entire investment into waste. Confidence is built with transparency about system limits, training and early involvement of the people who will use them, and it is measured through behaviour, never through satisfaction surveys. ## The profile matters more than the average The overall 0-5 score serves comparability over time, but the diagnostic value lies in the profile, meaning the shape the four dimensions draw together. High Readiness with low Delivery suggests buying execution capacity or partnering with someone who has it. High Delivery with low Risk demands a pause to secure the perimeter before speed becomes exposure. Everything high with low Confidence points to a leadership and culture problem no technology investment will solve, and that technology investment usually worsens. Each profile prescribes a different intervention sequence, and getting the sequence wrong costs more than getting the intensity wrong: reinforcing the factory when the foundations are missing only produces faster rubble. If you had to sketch, right now, your organisation's profile across the four dimensions, which one would be the weakest? The instinctive answer is already information, and verifying it with a real measurement takes four to six weeks: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The next question, what to do with the profile, is where the work gets interesting. --- # EU AI Act: an operational guide for companies, between obligations in force and moving deadlines URL: https://zerofive.ai/en/blog/compliance/eu-ai-act-operational-guide-companies Data: 2026-02-03 Abstract: What the EU AI Act requires of companies: obligations already in force, the deadline calendar, the Digital Omnibus proposal and the first operational steps. There is a misunderstanding we meet in almost every committee where the AI Act comes up, and it is worth clearing at the start: Regulation (EU) 2024/1689 also concerns, and above all, those who use artificial intelligence systems, not only those who develop them. The company adopting candidate-screening software, the bank employing models in credit evaluation, the business integrating generative AI into customer-facing processes: all fall within the perimeter, with defined roles and obligations. The second misunderstanding, its mirror image, is thinking there is time. Part of the regulation is already in force and already sanctionable. ## What is already law, today The regulation entered into force on 1 August 2024, with staggered application. Since 2 February 2025 two blocks apply to everyone. The first is the Article 5 bans on unacceptable-risk practices, from social scoring to subliminal manipulation to emotion recognition in the workplace, with narrow exceptions. The second, far more cross-cutting than its media profile suggests, is Article 4 on literacy: organisations must ensure an adequate level of AI literacy for staff operating these systems, which makes training a regulatory obligation as well as good practice. Since 2 August 2025 the obligations for providers of general-purpose AI models have been added, together with the European governance architecture and the sanctions framework, which in its highest band reaches 7% of annual worldwide turnover. Anyone treating the AI Act as a topic for the future is, in practice, accumulating a backlog on rules that already apply. ## The calendar ahead, and the Omnibus variable The next milestone set by the text is 2 August 2026, the date of general application of the regulation, which includes the transparency obligations of Article 50 (informing people when they interact with an AI, marking generated content) and, in the original calendar, the requirements for high-risk systems under Annex III: risk management, data quality, technical documentation, human oversight, registration. Here enters the variable anyone planning 2026 needs to know. On 19 November 2025 the Commission presented the simplification package known as the Digital Omnibus, which proposes, among other things, to tie the application of high-risk obligations to the actual availability of harmonised standards and support tools, with backstop dates pushed beyond August 2026. The legislative process is ongoing as we write, and until any publication in the Official Journal the original dates remain formally valid. The operational reading we give clients is prudent on both fronts: plan as if August 2026 holds, and welcome a possible postponement as time gained to do things properly rather than as a free pass, not least because the substance of the obligations is not under discussion, only the when is. ## The four steps to take now Experience on compliance programmes suggests a sequence that holds regardless of the Omnibus outcome, because it builds capacity that is needed anyway. The first step is the census: an inventory of AI systems in use or under development, including those purchased inside other software and those used informally by teams, because you cannot classify what you cannot see. The second is the risk classification of each system according to the regulation's categories, which determines which obligations apply and in which role (provider, deployer, importer). The third is the compliance check on obligations already in force, bans and literacy first, with a documented training plan. The fourth is the assignment of responsibilities, because AI Act readiness cuts across legal, IT, risk, HR and business, and without an owner holding an explicit mandate it dissolves into meetings. On this journey our usual warning applies: we talk about gap analysis and preparation, never about guaranteed compliance, which no serious advisor can promise and which the regulation itself frames as a continuous process, never a stamp. ## Compliance as a by-product of governance The strategic mistake to avoid is treating the AI Act as an isolated compliance project, a legal workstream to close and archive. The things the regulation asks for, knowing which systems you use, assessing their risks, documenting decisions, training people, overseeing data, are exactly the components of AI governance done well, the kind needed to generate value even before avoiding sanctions. In our AI Rating the Risk dimension measures precisely this distance, with precise references to the regulation's articles for every gap found, inside an overall maturity evaluation. If your board or risk committee has put the AI Act on this year's agenda, the fastest way to turn the agenda into a plan is measuring the starting point: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The deadlines may still move, the direction will not, and the distance to cover is the same either way: better to know it as a number. --- # The real cost of failed AI projects: waste, time, credibility URL: https://zerofive.ai/en/blog/insights/real-cost-failed-ai-projects Data: 2026-01-29 Abstract: 95% of GenAI pilots deliver no measurable return, says MIT. What a failed AI project really costs, between direct spend, time and credibility. The numbers on AI project failure all came out within a few months of each other, and lined up they compose a picture no investment committee would accept for any other class of spending. MIT Project NANDA (The GenAI Divide, July 2025) analysed over three hundred enterprise deployments: 95% of generative AI pilots produce no measurable impact on the P&L, against 30-40 billion dollars invested. RAND Corporation estimated back in 2024 that over 80% of AI projects miss their intended value, roughly double the rate of comparable traditional IT projects. S&P Global Market Intelligence (Voice of the Enterprise, 2025) recorded the sharpest figure: 42% of companies abandoned most of their AI initiatives, up from 17% the year before. The most common reaction to these numbers is to file the failed pilot under "learning" and restart with the next one. The true accounting of failure, the one we see surface in our assessments, is much broader than the cancelled budget line, and it is worth breaking down, because each component has a different remedy. ## Direct spend is the small part The visible cost, licences, consulting fees, vendor days, test infrastructure, is what ends up in the post-mortem, when a post-mortem happens at all. In our experience it rarely represents more than a third of the total bill, and it is also the only component the organisation perceives as lost. Above it sits the time of your best people. A serious AI pilot absorbs for months the most capable data engineers, the most experienced process owners, hours of committees and steering meetings. If the project dies, that qualified time does not come back, and its opportunity cost is rarely calculated: what would those same people have produced on an initiative with solid prerequisites? RAND's research lists misaligned objectives and inadequate data foundations among the primary causes, conditions knowable before starting, which makes the burned time an avoidable cost rather than an accident. ## The damage that shows later: internal credibility The most expensive component is also the least accounted for. Every failed pilot raises the price of the next one, because it consumes the scarcest resource of any transformation: people's willingness to believe once more. The third AI project presented to a management team that watched the first two sink starts with a trust discount no demo can recover, and the same goes for operational teams, who quickly learn to treat the latest initiative as a passing fashion to wait out. The MIT report describes this effect from a revealing angle: while official pilots stall, in over 90% of companies employees use personal AI tools that work. Demand for AI stays high, trust in the organisation's ability to meet it collapses, and the gap between the two curves is the internal reputational cost of failure, the one that turns future projects into uphill climbs. ## Failing well, failing badly One clarification, before the wrong conclusions: a share of failures is physiological and even desirable, because AI remains a territory where validation happens by experimenting. The problem with the 95% is not that pilots close, it is how. An experiment with a clear hypothesis, a written success threshold and a contained budget that ends in a no has produced information at low cost, and that is research well spent. A project started without criteria, grown by inertia and abandoned out of exhaustion after eighteen months has produced only the bill above. The difference between the two outcomes is decided almost entirely before kickoff, and it is a matter of measurable prerequisites: data ready to survive scale, a sponsor with signing power, business metrics defined by whoever owns the process, a mapped risk and compliance perimeter. The failure causes catalogued by RAND and MIT are largely diagnoses a serious assessment can formulate in a few weeks, at a cost that is a fraction of a single pilot. ## The missing due diligence If 95% of pilots deliver no return, the highest-yield lever is not improving the execution of the next one, it is selecting better upstream. Our AI Rating does exactly this internal due diligence work: it measures on a 0-5 scale the organisation's capacity across four dimensions and says, before the investment, which gaps would doom the project and what closing them costs. Companies arriving from a string of failures usually discover that their pilots were not wrong in the idea, they were premature in the prerequisites. The bill for failed projects, in the end, can be read two ways: as the price paid for learning, or as the measure of how much starting to measure is worth. If your 2025 contains at least one pilot archived without a written why, half an hour at calendly.com/fabiolalli/zerofive helps keep 2026 from repeating it, or write to hello@zerofive.ai. What did the last AI project you closed really cost, counting everything? --- # AI Rating: why you need an objective score before investing URL: https://zerofive.ai/en/blog/ai-governance/ai-rating-objective-score Data: 2026-01-27 Abstract: What an AI Rating is, how a 0-5 evaluation with merit classes works, and why the score should come before any AI investment. No CFO would approve an acquisition without due diligence, no bank would extend credit without a rating, no CISO would buy a security platform without an assessment of their own perimeter. Then the AI budget arrives, often the fastest-growing line of technology spending, and the discipline evaporates: companies start from the vendor, from the fashionable use case, from the demo seen at an event, without anyone having measured whether the organisation can turn that investment into value. The AI Rating exists to bring back to AI the same discipline companies apply to every other significant capital allocation. The analogy with credit ratings is deliberate and worth taking seriously, because it inherits three properties: a synthetic, comparable score, a transparent and repeatable methodology, and gating rules whereby certain gaps cannot be offset by other strengths. ## How the score is built The evaluation crosses four dimensions, each scored from 0 to 5. AI Readiness photographs preparation, from strategy to data quality, from infrastructure to widespread skills. AI Delivery looks at execution capacity, meaning development processes, MLOps, integration with existing systems, monitoring of whatever reaches production. AI Risk covers governance, with compliance towards the EU AI Act and ISO/IEC 42001, plus the management of bias, security and privacy. AI Confidence measures actual adoption, from board commitment to the trust of the people who use the systems every day. The method matters as much as the model. Every score comes from crossing documentary evidence (architectures, policies, real project metrics) with interviews run at several levels, from the board to operational teams, because the distance between what is declared and what is experienced is itself a data point, often the most eloquent one. The result is summarised in four merit classes, from A for leaders (score above 4.0, no area below 3.5, gates satisfied) to D for those at the initial stage, with C in the middle collecting the most frequent case in Italy: real capabilities, pilots that never scaled, maturity under construction. Critical gates deserve an extra word, because they are what separates a rating from a survey. A company can excel at strategy and delivery, but if an AI systems register is missing, if personal data circulates unsupervised or if nobody has classified systems by risk as the European framework requires, the merit class stays capped. The message built into the mechanism is that certain foundations are non-negotiable. ## What changes in decisions, concretely The value of the score shows up at three precise decision points. The first is budget allocation: knowing you are a class C with Risk at 1.8 shifts spending from the third pilot to closing the gaps that sank the first two, and in our experience (34+ assessments delivered, ZeroFive.AI data, 2026) this single course correction is worth more than any technological quick win. The second moment is the conversation with the board. A board of directors cannot govern what it cannot compare, and the rating hands it exactly that: a number to place on the dashboard next to financial KPIs, to re-measure after twelve months, on which to hold management accountable with the same ease with which margins are discussed. An isolated snapshot ages, the comparison between two measurements governs. The third moment is the dialogue with the outside world, auditors, regulators, enterprise clients whose tenders are starting to require evidence of AI governance. A documented rating, with precise regulatory references for every recommendation, demonstrates that the topic was addressed with method, which is different from declaring compliance (certified compliance is a journey of its own, and we distrust anyone who promises it inside an assessment). ## When to do it, and when to do it again The right moment for the first measurement is before an investment cycle, never after. The typical occasions we see: an industrial plan that includes AI, a board demanding a strategy, a series of pilots with disappointing outcomes, a regulatory deadline on the horizon. The baseline takes four to six weeks and produces deliverables calibrated for each level, the strategic summary for the board, the analytical gap report for the teams, the roadmap with 30-day quick wins, the raw data for audit and governance. The single measurement, though, is only the start of the mechanism. The model works as a cycle, baseline, execution of corrective actions, re-assessment after twelve months, because the declared goal is to turn the rating into a structural KPI of the organisation, monitored over time like any other executive indicator. If you are about to approve an AI budget for 2026, the question to ask before signing is simple: what evidence is it based on? If the answer is a list of proposed projects and no measure of the capacity to deliver them, half an hour of conversation can save you months: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. Patient capital is not the capital that waits, it is the capital that measures before it moves. --- # Shadow AI: what happens when employees use AI without a policy URL: https://zerofive.ai/en/blog/insights/shadow-ai-company-risks-policy Data: 2026-01-20 Abstract: In over 90% of companies employees use personal AI tools. What shadow AI is, which risks it creates and why banning it is the wrong answer. Try an exercise next time you walk across the open space: count how many ChatGPT, Gemini or Copilot windows are open on personal accounts. In the engagements we run, the answer always surprises management, never the teams. The MIT Project NANDA report (The GenAI Divide, July 2025) put a number on the phenomenon: in over 90% of the companies analysed, employees use personal AI tools for work, often exactly where the official pilots stalled. The researchers call it the shadow AI economy, a parallel economy that appears in no inventory, no budget and no risk assessment. The instinctive reading is that of a violation to repress. Ours, after meeting it in almost every assessment we have delivered, is different: shadow AI is the most reliable signal in existence of the real demand for AI inside the organisation, and at the same time the most underestimated operational risk of the moment. ## The inventory nobody has The governance problem starts with a question very few companies can answer: which AI systems are being used today, by whom, on which data. The official version of the answer lists the approved projects. The real version includes dozens of consumer tools, plugins installed autonomously, AI features silently activated inside software already under licence, automations built by individual teams on free accounts. The distance between the two versions has concrete consequences. A document with customer data uploaded to a consumer service is a personal data processing operation nobody ever assessed, with everything that follows under GDPR. An unverified output flowing back into a decision process is an error with no owner. And since 2 February 2025 there is one more layer: the EU AI Act, through Article 4, asks organisations to ensure an adequate level of AI literacy for the staff using it, and the rule does not distinguish between approved tools and tools brought from home. ## Why the ban does not work Some companies responded by blocking the domains of the main AI services. In our experience the outcome is predictable: usage moves to personal smartphones, exits the observable perimeter entirely and becomes impossible even to estimate. The ban turns a visible, manageable phenomenon into an invisible one, which is the worst possible configuration for anyone in charge of risk. There is also a deeper reason why repression fails. People use these tools because they work, because they remove friction from tasks the official workflow makes slow, and this information is gold: every shadow use is a free signal about where AI would produce value if adopted seriously. An organisation that switches off the signal gives up the best map of its own use cases, the one drawn by behaviour rather than by workshops. ## From phenomenon to governed perimeter The path we propose to clients follows a precise sequence, and the first step is a census with no punitive intent: an amnesty window in which teams and individuals declare which tools they use and for what, with the explicit guarantee that the goal is to understand, and if anything to equip everyone with safe alternatives. The census feeds the AI systems register, which serves both day-to-day management and the risk classification required by the European regulatory framework. The second step is a policy written to be used, with three clear categories (allowed, allowed with precautions, forbidden), concrete examples for each and one very simple rule about data: what may leave the company perimeter and what may not. Twenty-page policies nobody reads produce the same effect as a ban, which is none. The third step is the part almost everyone skips, namely giving people an official tool at least as good as the one they were using in secret, together with the training Article 4 of the AI Act requires anyway. Shadow AI is not extinguished by decree, it dries up through convenience: when the internal alternative is comfortable, safe and available, the shadow channel loses its reason to exist. ## Measurement before policy The priority question remains: where to start, with what urgency, with which resources. The answer depends on how widespread the phenomenon is and how mature the organisation is at handling it, two things that can be measured rather than assumed. In our AI Rating, shadow AI cuts across three of the four dimensions we evaluate, readiness (culture and skills), risk (data and compliance) and confidence (trust and actual behaviour), and the score tells you immediately whether you are facing a marginal phenomenon or a parallel perimeter larger than the official one. If the doubt crept in while reading, it is worth resolving it with numbers: half an hour at calendly.com/fabiolalli/zerofive, or an email to hello@zerofive.ai. In the meantime the open space exercise remains free, and the question it opens is the right one: if AI in your company is already being adopted by the people, who is deciding how? --- # AI maturity model: what it is, how it is measured, and why the board should demand one URL: https://zerofive.ai/en/blog/ai-governance/ai-maturity-model-how-to-measure Data: 2026-01-15 Abstract: What an AI maturity model is, which dimensions it measures, how scales and rating classes work, and why the board should demand one. Try asking this question at your next executive committee: on a scale from 0 to 5, how mature is our company in AI adoption? In our experience the answers fall into three families, those who cite ongoing projects (which measure activity, not capability), those who cite budget spent (which measures intention), and those who admit that a shared measure does not exist. The third answer is the most useful, because it is the starting point for building one. An AI maturity model exists precisely for this: turning a perception ("we are behind", "we are doing fine") into a number that can be compared over time, across functions and against the market. Companies have measured financial solidity with credit ratings for decades, and cybersecurity with maturity frameworks, while on AI, where investments grow at double digits, most still decide by gut feeling. ## What a maturity model actually measures The word maturity is misleading, because it suggests a technology ranking, how many models we have, how sophisticated they are. A serious model measures something different: the organisation's capacity to turn AI into value in a repeatable, governed way. A company can run the most advanced language model on the market and still score low on maturity, because its data is fragmented, nobody owns the risks and the board has never approved a strategy. Our AI Rating, the proprietary framework we use in ZeroFive assessments, breaks this capacity down into four dimensions. AI Readiness measures preparation: strategy, governance, data quality, infrastructure, skills and culture. AI Delivery measures execution: development processes, MLOps, systems integration, scalability and monitoring. AI Risk measures oversight: compliance with the EU AI Act and ISO/IEC 42001, ethics, bias, security, privacy. AI Confidence measures adoption: board commitment, user trust, perceived robustness of the solutions. The fourth dimension is the one that surprises clients most, because it sounds soft and turns out to be predictive: a technically excellent system that users avoid, or that the board abandons at the first setback, has the same value as a system that does not exist. ## Scales, classes and the logic of critical gates The measurement produces a 0-5 score for each dimension and a global rating, summarised in four merit classes, from A (leader, score above 4.0 with no area below 3.5) to D (initial stage, score below 2.0, opportunistic approach, missing prerequisites). In between, class B for advanced organisations and class C for those with real capabilities but significant weaknesses, typically pilots that never scaled. The mechanism that makes the model credible, and that most downloadable self-assessments lack, is the non-compensable critical gate. A high score on strategy and delivery cannot offset the absence of an AI systems register or personal data management that is out of control: certain gaps cap the merit class regardless of the average, exactly as in credit ratings a breached covenant outweighs ten healthy indicators. Without gating, the model rewards whoever tells the best story. There is also a methodological requirement that applies to any framework you choose: the evaluation must combine quantitative evidence (documents, architectures, real metrics) with qualitative interviews across several levels of the organisation, because the gap between what management declares and what operational teams experience is, almost always, the single most informative data point of the entire assessment. ## The number the board should demand For a board of directors, an AI maturity rating solves three concrete problems. The first is comparability over time: repeating the measurement after twelve months turns a snapshot into a film, and allows the board to hold management accountable for progress with the same discipline applied to financial KPIs. Our declared goal, in the engagements we run, is to bring the AI rating into the executive dashboard as a structural indicator monitored by the board. The second is external defensibility. With the EU AI Act in force since August 2024 and its application deadlines approaching, and with ISO/IEC 42001:2023 defining the standard for AI management systems, boards, risk committees and auditors need to demonstrate that they assessed the state of play with method. A documented rating, with evidence and precise regulatory references for each area, is the foundation of that demonstration (we are talking about preparation and gap analysis, not certified compliance, which is a different journey). The third problem is capital allocation. Knowing that the company is a class C with Readiness at 3.1 and Risk at 1.8 changes the budget conversation: before funding a third pilot, you fund the closure of the gaps that blocked the first two. Low maturity is not a verdict, it is information, and whoever holds it wastes less. ## Where to start, in practice A first assessment typically takes four to six weeks and produces deliverables for every level: a strategic summary for the board, an analytical gap report for the teams, a roadmap with 30-day quick wins and prioritised projects, and the raw data for governance and audit. The cost is a fraction of an average pilot, and in our experience it prevents at least one wrong one. If you want to understand how it would work on your organisation, book a call at calendly.com/fabiolalli/zerofive or write to hello@zerofive.ai. First, though, it is worth asking your committee the opening question again, the one about the 0-5 scale, and observing not so much the answers as how far they diverge from one another: that distance is the first measure of your maturity. --- # Stalled AI pilots: the five recurring causes and how to spot them URL: https://zerofive.ai/en/blog/insights/stalled-ai-pilots-recurring-causes Data: 2026-01-07 Abstract: Why AI pilots never reach production: the five recurring causes, the early warning signs, and the path to unblocking them. There is a scene that repeats itself, with almost embarrassing regularity, at the tables where we work: the pilot succeeded technically, the demo convinced everyone, the vendor invoiced its phase one, and then nothing. Six months later the project still sits in that no man's land between "it works" and "we actually use it", with a budget consumed and nobody able to say precisely why it isn't moving forward. The phenomenon has a name in the industry literature, pilot purgatory, and it affects the majority of AI experiments in European companies. What strikes us, after more than thirty assessments delivered (ZeroFive.AI data, 2026), is that the causes are almost never technological. There are five of them, they repeat, and they can be recognised before the pilot even starts. ## A pilot born without a decision The first cause sits upstream, at the moment the pilot gets approved. In many organisations the experiment starts out of enthusiasm, out of competitive pressure, because "we have to do something with AI", and nobody defines what should happen if the pilot works: which budget gets unlocked, which process changes, who signs off the move to production. A pilot without go/no-go criteria defined at the outset is not an experiment, it is a postponement dressed up as action. A real experiment has a hypothesis, a success threshold and a consequence already agreed for both outcomes. When this is missing, a successful pilot does not produce a decision, it produces a slide deck. ## Data that cannot survive the jump to scale The second cause almost always surfaces between the demo and production. The pilot runs on a hand-curated dataset, cleaned for the occasion, often extracted once by someone who knew that particular system inside out, and everything works. Then you try to connect the real data, the data that lives across three different systems with misaligned master records and fields filled inconsistently for years, and the model that scored 92% accuracy in the demo stops being reliable. The early warning sign is simple: before the pilot, ask how long it would take to rebuild the test dataset automatically and repeatedly. If the answer is vague, the problem is not the model. ## A sponsor who is missing, or too many of them Third cause, the most political one. Stalled pilots almost always have ambiguous ownership: the project started in IT but touches a sales process, or it was championed by a director who has since changed roles, or the formal sponsor is the CEO but the CEO delegated it to someone with no spending authority. Moving to production always means taking something away from someone, a process, a habit, sometimes a responsibility, and that shift only happens with an executive sponsor who puts their name on it and an operational team that owns the process. When our assessments measure the dimension we call AI Confidence, board commitment weighs as much as technical robustness, and this is not an academic choice: it is what we see determining, case after case, who scales and who stays stuck. ## Success metrics that were never written down The fourth cause reveals itself with a single question: how do we measure whether it worked? In stalled pilots the answer comes after a pause, and it usually involves model metrics (accuracy, precision, latency) and never business metrics (hours saved, errors avoided, margin recovered, risk reduced). The two families of metrics are not interchangeable, because an accurate model applied to a marginal process produces a pilot that is perfect and irrelevant. The business metric must be written before the pilot starts, with the expected value and the threshold below which the project closes, and it must be written by whoever owns the P&L of that process, not by the technical team. ## The jump to production was never designed The last cause is the one technical teams know best and management discovers last. Taking a model to production means integration with existing systems, continuous performance monitoring, drift management, a security and privacy function watching over it, and now an explicit regulatory perimeter too, with the EU AI Act requiring companies to classify systems by risk and document them. All of this carries a cost that often exceeds the pilot itself, and if it was not estimated at the start it arrives as an unpleasant surprise that freezes the project. The pilot should have been designed with production in mind from day one, with the integration architecture at least sketched and the compliance requirements mapped, because validation also concerns the sustainability of what comes after. ## Where to restart from The five causes share a common root: building started before measuring and deciding. The healthy sequence is the reverse, first you assess the organisation's maturity (data, skills, governance, commitment), then you choose where to experiment with explicit criteria, then you validate, and only then do you automate. Our AI Rating was built exactly for this step: it measures, on a 0-5 scale, the company's real capacity to take AI to production across four dimensions (Readiness, Delivery, Risk, Confidence), and returns a 90-day roadmap with the gaps to close before investing further. Companies with pilots stuck for months usually discover that the blockage was written into the prerequisites, and that removing it costs less than they feared. If you have one or more pilots in this condition, the first useful step is understanding which of the five causes applies to you, because the remedy is different for each. Thirty minutes of conversation are enough for a first diagnosis: you can book them at calendly.com/fabiolalli/zerofive, or write to us at hello@zerofive.ai. The question worth arriving with is just one: if the pilot worked tomorrow, who would sign off the move to production?