Un framework di AI governance è il piccolo insieme di decisioni, responsabili e registrazioni che permette a un'azienda di dire, in qualsiasi momento, quali sistemi di intelligenza artificiale usa, cosa può fare ciascuno, chi ne risponde e come se ne accorgerebbe se qualcosa andasse storto. Per una media impresa non è un ufficio e non è un acquisto software. Sono sette controlli, ognuno produce un artefatto, ognuno ha un responsabile con nome e cognome — e la maggior parte si mette in piedi in un trimestre.
L'urgenza è normativa e operativa insieme. Divieti e obbligo di alfabetizzazione dell'AI Act si applicano dal 2 febbraio 2025, gli obblighi di trasparenza dal 2 agosto 2026, e il Digital Omnibus ha spostato al 2 dicembre 2027 gli obblighi per i sistemi ad alto rischio dell'Allegato III. Nel frattempo le vostre persone usano già strumenti di AI che nessuno ha approvato. La governance serve a chiudere la distanza tra l'AI che l'azienda crede di usare e quella che usa davvero, prima che la chiuda per voi un'autorità, un auditor o un data breach.
Per chi è questa guida
Guidate operations, tecnologia, rischi o legale in un'azienda tra 100 e 2.000 persone — una banca, un'assicurazione, una struttura sanitaria, un'utility, un'impresa industriale, o una software house che vende a uno di loro. Avete AI in produzione o quasi, nessuno che si occupi a tempo pieno di compliance AI, e un consiglio di amministrazione che ha iniziato a fare domande. Costruisco e porto in produzione sistemi di AI per clienti proprio in questi settori: quello che segue è il framework che uso davvero, non un modello di maturità.
Cos'è Davvero un Framework di AI Governance (e Cosa Non È)
Cercate cos'è l'AI governance e troverete principi: equità, trasparenza, accountability, centralità della persona. Sono tutti giusti e nessuno dice a un direttore operativo cosa fare lunedì mattina. I principi sono il perché. Il framework è il come: il meccanismo operativo che trasforma i principi in decisioni che qualcuno deve prendere ed evidenze che qualcuno deve conservare.
Un test utile: un framework di AI governance che funziona risponde a tre domande in meno di un'ora, con documenti e non con opinioni.
- Quale AI usiamo? Ogni sistema, comprese le funzionalità AI attivate dentro i software che già avete in licenza e gli strumenti che i dipendenti hanno adottato di loro iniziativa.
- Quale conta? Quali sistemi toccano decisioni sulle persone, processi regolamentati o dati riservati — e come li classifica l'AI Act.
- Chi ne risponde? Una persona con nome e cognome per ogni sistema, in grado di spiegare cosa fa, su cosa è stato testato e cosa succede quando sbaglia.
Se oggi non sapete rispondere, non avete ancora un problema di AI governance: avete un problema di visibilità sull'AI, e ogni iniziativa costosa di governance costruita prima di risolverlo sarà costruita su ipotesi. Per questo il framework qui sotto parte da un inventario e non da una carta etica.
Perché è un Problema del 2026, Non del 2028
Il rinvio della scadenza per l'alto rischio ha convinto alcuni vertici aziendali che la governance possa aspettare. I dati di adozione dicono che l'esposizione c'è già, e quasi tutta non ha nulla a che vedere con la classificazione ad alto rischio:
| Indicatore | Dato | Fonte (data) |
|---|---|---|
| Imprese UE (10+ addetti) che usano l'AI | 20,0% nel 2025, dal 13,5% del 2024 | Eurostat (dicembre 2025) |
| Imprese UE grandi / medie / piccole che usano l'AI | 55,0% / 30,4% / 17,0% | Eurostat (dicembre 2025) |
| Knowledge worker che usano l'AI al lavoro | 75% | Microsoft & LinkedIn Work Trend Index (maggio 2024) |
| Utenti AI che portano al lavoro i propri strumenti | 78% | Microsoft & LinkedIn Work Trend Index (maggio 2024) |
| Organizzazioni con violazioni di modelli o applicazioni AI | 13%, di cui il 97% senza adeguati controlli di accesso all'AI | IBM Cost of a Data Breach (2025) |
| Organizzazioni senza policy di AI governance | 63% | IBM Cost of a Data Breach (2025) |
| Costo aggiuntivo di un breach con shadow AI coinvolta | 670.000 USD in più su una media di 4,44 milioni USD | IBM Cost of a Data Breach (2025) |
Leggete le righe in sequenza. L'adozione cresce più in fretta nelle aziende abbastanza grandi da avere processi regolamentati. Gran parte di quell'adozione parte dai dipendenti, quindi non è registrata da nessuna parte. E le organizzazioni già colpite attraverso l'AI, nella quasi totalità, non avevano né controlli di accesso né una policy. Niente di tutto questo aspetta il 2027. Il dato Eurostat dice anche qualcosa di utile in chiave competitiva: in gran parte d'Europa quattro imprese su cinque non usano ancora l'AI, quindi chi costruisce la governance adesso lo fa all'inizio della curva, quando costa poco.
L'AI Act dopo il Digital Omnibus: Cosa Scade e Quando
Il Regolamento (UE) 2026/1744 — il Digital Omnibus sull'AI — è stato pubblicato in Gazzetta ufficiale UE il 24 luglio 2026 ed è entrato in vigore il 27 luglio 2026. Ha rinviato gli obblighi per l'alto rischio, soprattutto perché le norme armonizzate da cui dipendono non erano pronte, e ha lasciato quasi tutto il resto in calendario. In Italia c'è un livello in più: la Legge 132/2025, in vigore dal 10 ottobre 2025, che designa AgID e ACN come autorità nazionali per l'AI. Questo è il calendario che vale oggi:
| Data | Cosa si applica | Chi colpisce in una media impresa |
|---|---|---|
| 2 febbraio 2025 | Pratiche vietate (art. 5); obbligo di alfabetizzazione AI (art. 4) | Chiunque usi l'AI — già in vigore |
| 2 agosto 2025 | Regole sui modelli di AI per finalità generali; autorità nazionali; regime sanzionatorio | Soprattutto i fornitori di modelli; qui partono gli obblighi dei vostri vendor |
| 2 agosto 2026 | Obblighi di trasparenza (art. 50): chatbot dichiarati, deepfake e testi generati di interesse pubblico etichettati | Ogni assistente rivolto ai clienti o contenuto sintetico |
| 2 dicembre 2026 | Fine del periodo di grazia sul watermarking per i sistemi esistenti; nuovo divieto di generare immagini intime non consensuali e CSAM | Fornitori di sistemi generativi |
| 2 dicembre 2027 | Obblighi per i sistemi ad alto rischio dell'Allegato III (credit scoring, pricing assicurativo, HR, infrastrutture critiche, biometria…) | Banche, assicurazioni, ogni datore di lavoro che seleziona candidati con l'AI |
| 2 agosto 2028 | Obblighi per i sistemi ad alto rischio dell'Allegato I (AI dentro prodotti regolamentati come dispositivi medici e macchine) | Medtech, produttori di macchinari |
Due modifiche si leggono facilmente male. Primo, l'obbligo di alfabetizzazione è stato ammorbidito: fornitori e deployer devono ora sostenere lo sviluppo dell'alfabetizzazione AI del personale, invece di garantirne un livello definito. Non è sparito, e si applica già oggi. Secondo, l'Omnibus non ha toccato né le sanzioni dell'articolo 99 né i divieti. L'AI Act è in vigore; si è spostato solo il capitolo sull'alto rischio.
Il rinvio è una finestra, non una proroga
Quattordici mesi sono più o meno il tempo che serve a una media impresa per inventariare la propria AI, rinegoziare tre o quattro contratti con i fornitori, inserire il logging delle decisioni nei sistemi che lo richiedono e fare una revisione interna onesta. Chi parte a fine 2027 farà tutto sotto scadenza, con consulenti prezzati di conseguenza. Chi usa la finestra spenderà una frazione di quella cifra e arriverà con evidenze invece che con promesse.
Fornitore o Deployer: la Domanda che Dimensiona Tutto
L'AI Act assegna quasi tutti gli obblighi pesanti — sistema di gestione dei rischi, documentazione tecnica, valutazione di conformità, marcatura CE, registrazione — al fornitore: chi sviluppa un sistema di AI e lo immette sul mercato o lo mette in servizio con il proprio nome. La maggior parte delle medie imprese non è fornitore. È deployer: usa sistemi costruiti da altri. Per un sistema ad alto rischio, gli obblighi del deployer previsti dall'articolo 26 sono reali ma circoscritti:
- Usare il sistema secondo le istruzioni d'uso del fornitore, con misure tecniche e organizzative adeguate.
- Affidare la sorveglianza umana a persone con competenza, formazione, autorità e supporto necessari.
- Garantire che i dati di input sotto il proprio controllo siano pertinenti e sufficientemente rappresentativi rispetto alla finalità prevista.
- Monitorare il funzionamento del sistema e segnalare senza ritardo gli incidenti gravi al fornitore e all'autorità di vigilanza del mercato.
- Conservare i log generati dal sistema per un periodo adeguato alla finalità, e comunque almeno sei mesi.
- Informare i rappresentanti dei lavoratori e i lavoratori interessati prima di usare un sistema ad alto rischio sul luogo di lavoro.
È un elenco gestibile senza un ufficio compliance. La trappola è scivolare da deployer a fornitore senza accorgersene. L'articolo 25 trasforma un deployer in fornitore di un sistema ad alto rischio — con tutti gli obblighi del fornitore — in tre situazioni, tutte frequenti nelle aziende che costruiscono sopra i modelli di AI:
- Mettete il vostro nome o marchio su un sistema ad alto rischio costruito da altri — per esempio il motore di scoring in white label rivenduto ai vostri clienti.
- Apportate una modifica sostanziale a un sistema ad alto rischio già sul mercato, come riaddestrarlo sui vostri dati per una decisione diversa.
- Cambiate la finalità prevista di un sistema in modo che diventi ad alto rischio — l'assistente generico che l'ufficio HR inizia a usare per fare la classifica dei candidati.
Il Framework di AI Governance in Sette Controlli
Questo è il framework minimo che metto in piedi per i clienti di medie dimensioni. Ogni controllo produce un artefatto da mostrare a un auditor, a un CdA o al team di due diligence di un cliente. Ognuno corrisponde a qualcosa che AI Act, GDPR o il regolatore di settore già si aspettano — e in Italia si integra naturalmente con il Modello 231. La colonna dell'impegno riflette la mia esperienza su aziende tra 200 e 1.000 persone con qualche decina di casi d'uso AI, non un benchmark di settore.
| # | Controllo | Artefatto | Riferimento principale | Responsabile | Impegno tipico |
|---|---|---|---|---|---|
| 1 | Inventario AI | Registro AI (una riga per sistema) | Base per art. 26 e art. 50 | Responsabile AI governance | 2–4 settimane, poi mensile |
| 2 | Classificazione del rischio | Livello per ogni riga, con motivazione | Art. 5, art. 6 e Allegato III, art. 50 | Responsabile + legale | 1–2 settimane |
| 3 | Ownership | Owner di business nominato per sistema; piccolo board AI | Art. 26(2) sorveglianza umana | Sponsor esecutivo | 1 settimana |
| 4 | Uso consentito e regole sui dati | Policy AI di una pagina + classi di dati per strumento | GDPR, art. 4 alfabetizzazione | Responsabile + DPO + security | 2 settimane |
| 5 | Sorveglianza umana e logging | Procedura di sorveglianza + conservazione log per sistema | Art. 26(2), 26(5), 26(6) | Owner del sistema + engineering | 2–6 settimane per sistema ad alto rischio |
| 6 | Due diligence sui fornitori | Questionario AI per i vendor + clausole contrattuali | Art. 26(1), art. 25 | Acquisti + legale | 1–2 settimane, poi a ogni contratto |
| 7 | Monitoraggio, incidenti, alfabetizzazione | Runbook incidenti, revisione trimestrale, registro formazione | Art. 26(5), art. 4, art. 73 | Responsabile + security | Continuo, ~2 giorni a trimestre |
Controllo 1 — L'inventario AI
Tutto il resto dipende da qui, ed è sempre più grande di quanto il vertice si aspetti. Negli inventari che ho condotto, i sistemi noti alla direzione erano di solito ben meno della metà del registro finale. Il resto erano funzionalità AI attivate di default dentro SaaS già in uso — scoring nel CRM, smistamento dei ticket, trascrizione delle riunioni, assistenti di codice — e strumenti adottati dai singoli team con una carta aziendale. Si trovano con i dati di acquisti e note spese, i log SSO, i report sulle estensioni del browser e un breve sondaggio in stile amnistia: le persone dichiarano molto di più se il messaggio è "diteci cosa usate così lo rendiamo sicuro" che se è "chi ha violato le regole".
- Cos'è e chi lo fornisce: prodotto, vendor, fornitore del modello sottostante se noto, versione o riferimento contrattuale.
- Cosa fa da noi: il processo di business, la decisione che informa o prende, e se un essere umano rivede l'output.
- Quali dati entrano: dati personali, categorie particolari, dati riservati dei clienti, codice sorgente.
- Chi ne è toccato: dipendenti, clienti, candidati, pazienti, il pubblico.
- Il vostro ruolo: fornitore o deployer, e perché — per iscritto, perché l'articolo 25 lo rende un bersaglio mobile.
Controllo 2 — Classificazione del rischio
Classificate ogni riga due volte. Prima secondo le categorie dell'AI Act — vietato, alto rischio da Allegato III o Allegato I, obblighi di trasparenza dell'articolo 50, rischio minimo. Poi secondo la vostra criticità di business: cosa succede a clienti, soldi o reputazione se questo sistema sbaglia per una settimana. Il secondo livello conta perché gran parte del vostro rischio sta in sistemi che l'AI Act considera minimi. Un modello di previsione delle vendite non è ad alto rischio per la legge. Può comunque fuorviare un consiglio di amministrazione. I controlli devono seguire il più alto dei due livelli, non solo quello giuridico.
Controllo 3 — Ownership
Ogni sistema ha un solo owner di business responsabile — il capo della funzione le cui decisioni il sistema influenza, non la persona dell'IT che l'ha installato. Sopra c'è un piccolo board AI: uno sponsor esecutivo, il responsabile AI governance, qualcuno del legale o il DPO, la security e un manager di business che usa molto l'AI. Cinque persone, un'ora al mese, con l'autorità di approvare, sospendere o dismettere un sistema. I grandi comitati di AI governance falliscono nelle medie imprese per un motivo semplice: quando quindici persone possiedono una decisione, non la possiede nessuno.
Controllo 4 — Uso consentito e regole sui dati
Scrivete una policy di AI governance che stia in una pagina e che la gente legga davvero: quali strumenti sono approvati, quali classi di dati possono entrare in quale strumento, cosa non va mai incollato da nessuna parte (dati personali dei clienti, credenziali, dati finanziari non pubblicati, codice sotto NDA) e come chiedere un nuovo strumento con una risposta garantita entro cinque giorni lavorativi. È quest'ultima riga a ridurre la shadow AI. I divieti senza una via di approvazione rapida spostano semplicemente l'uso sui dispositivi personali, dove non vedete più nulla.
Controllo 5 — Sorveglianza umana e logging delle decisioni
"Human in the loop" non è un controllo finché non potete dimostrare chi era l'umano, cosa ha visto e cosa ha deciso. Per ogni sistema di livello alto definite il punto di sorveglianza, l'autorità di intervenire e cosa viene registrato: input, output, revisore, decisione finale ed eventuali override. Conservate i log almeno sei mesi, di più dove le norme di settore lo richiedono. È lavoro di ingegneria, ed è la stessa disciplina che descrivo per il codice generato dall'AI nel playbook dei guardrail enterprise per il vibe coding: se l'evidenza non la produce il sistema in automatico, il giorno in cui serve non esisterà.
Controllo 6 — Due diligence sui fornitori
Da deployer, la maggior parte del rischio AI vi arriva attraverso i contratti. Le funzionalità AI rilasciate dai vostri fornitori sono regolate dalla loro documentazione e dal vostro accordo con loro, e quasi tutti i termini SaaS standard sono stati scritti prima che qualcuno facesse queste domande. Aggiungete una sezione AI al questionario fornitori e alla checklist di rinnovo:
- I nostri dati vengono usati per addestrare o migliorare modelli, e possiamo escluderlo per contratto invece che con un'impostazione?
- Quali fornitori di modelli ci sono sotto, in quali regioni vengono trattati i dati, e come veniamo avvisati quando cambiano?
- Per gli usi ad alto rischio: ci fornirete istruzioni d'uso, capacità di logging e informazioni necessarie per i nostri obblighi dell'articolo 26?
- Qual è il vostro tempo di notifica per i guasti legati all'AI, ed è compatibile con le nostre scadenze regolamentari?
- Le funzionalità AI si possono disattivare per tenant, e le nuove nascono spente finché non le approviamo?
Controllo 7 — Monitoraggio, incidenti e alfabetizzazione
La governance si degrada il mese dopo essere stata impostata, a meno che qualcosa non imponga una revisione. Mettete tre cose in calendario: un aggiornamento mensile del registro alimentato da acquisti e dati SSO; una revisione trimestrale del board AI su ogni sistema di livello alto rispetto alle metriche del suo owner; e un runbook per gli incidenti AI che si innesti nel processo di gestione degli incidenti di sicurezza esistente invece di crearne uno parallelo. L'alfabetizzazione è il controllo più economico dei sette: formazione per ruolo di un'ora o due per la maggior parte del personale, più approfondita per owner e revisori, con presenze registrate. È anche l'obbligo che si applica da febbraio 2025.
Punti Caldi per Settore: Dove le Medie Imprese Incontrano l'Allegato III
L'elenco dell'alto rischio è più stretto di quanto suggerisca il marketing dei vendor. Nei settori in cui lavoro, questi sono gli usi che ci rientrano davvero — e quelli che no:
| Settore | Caso d'uso | Classificazione AI Act | Da quando |
|---|---|---|---|
| Banche e credito | Valutazione del merito creditizio o credit scoring di persone fisiche | Alto rischio, Allegato III 5(b); valutazione d'impatto sui diritti fondamentali obbligatoria (esclusa la rilevazione frodi) | 2 dic 2027 |
| Assicurazioni | Valutazione del rischio e pricing per assicurazioni vita e malattia | Alto rischio, Allegato III 5(c); valutazione d'impatto sui diritti fondamentali obbligatoria | 2 dic 2027 |
| Ogni datore di lavoro | Screening dei CV, ranking dei candidati, decisioni su promozioni o licenziamenti, assegnazione dei compiti, monitoraggio delle prestazioni | Alto rischio, Allegato III punto 4; informare i lavoratori prima dell'uso | 2 dic 2027 |
| Energia e utility | Componenti di sicurezza nella gestione e nel funzionamento di fornitura di elettricità, gas, riscaldamento, acqua e infrastrutture digitali critiche | Alto rischio, Allegato III punto 2 | 2 dic 2027 |
| Sanità | AI nel software dei dispositivi medici; triage dei pazienti in emergenza | Alto rischio tramite Allegato I (dispositivi medici) o Allegato III 5(d) | 2 ago 2028 / 2 dic 2027 |
| Tutti i settori | Chatbot e assistenti rivolti ai clienti | Trasparenza: le persone devono sapere che interagiscono con un'AI | In vigore dal 2 ago 2026 |
| Tutti i settori | Copilot interni, sintesi, assistenti di codice, previsioni | Rischio minimo per l'AI Act — governati dalla vostra classificazione e dal GDPR | Obbligo di alfabetizzazione in vigore |
La valutazione d'impatto sui diritti fondamentali dell'articolo 27 merita una nota specifica per banche e assicurazioni, perché è l'unico obbligo di questa tabella che ricade sul deployer e non sul fornitore. Prima del primo utilizzo di un sistema di credit scoring o di pricing vita e malattia, dovete valutare chi potrebbe essere colpito e come, e quali misure di sorveglianza e rimedio avete. Se fate già le DPIA del GDPR, estendete quel modello invece di inventarne uno nuovo. Il lato architetturale — audit trail, controllo degli accessi, residenza dei dati — è trattato nel dettaglio in come costruire software compliance-first per le industrie regolamentate.
Quanto Costa Non Essere Conformi
| Violazione | Sanzione massima (art. 99) | Nota per le PMI |
|---|---|---|
| Pratiche di AI vietate (art. 5) | 35 milioni di euro o 7% del fatturato mondiale annuo, se superiore | Si applica l'importo inferiore |
| Quasi tutti gli altri obblighi, compresi quelli dei deployer (art. 26) e la trasparenza (art. 50) | 15 milioni di euro o 3% del fatturato mondiale annuo, se superiore | Si applica l'importo inferiore |
| Informazioni inesatte, incomplete o fuorvianti fornite alle autorità | 7,5 milioni di euro o 1% del fatturato mondiale annuo, se superiore | Si applica l'importo inferiore |
Non costruirei un programma di governance sulla paura di queste cifre: le autorità nazionali partiranno da linee guida e casi evidenti. Il costo commerciale più immediato è negli acquisti. I grandi clienti di finanza e sanità stanno già aggiungendo domande sull'AI alla due diligence dei fornitori, e un fornitore di medie dimensioni che consegna un registro, una policy e una procedura di sorveglianza vince contratti che un fornitore che promette "prendiamo l'AI sul serio" perde.
Chi Possiede l'AI Governance Se Non Avete un Ufficio Compliance
L'errore più comune che vedo non è la policy mancante. È una policy in mano al legale, un registro in mano all'IT, la formazione in mano alle risorse umane e nessuno che li colleghi. Una media impresa ha bisogno di una persona — di solito il 20–40% di un ruolo senior, non una nuova assunzione — che possieda il framework dall'inizio alla fine. I candidati migliori sono un CTO o un responsabile dati che conosce i sistemi, o un direttore operativo che conosce i processi. Il peggiore è una figura junior con il titolo ma senza l'autorità di fermare un sistema.
- Sponsor esecutivo (CEO, COO o CFO): definisce la propensione al rischio e presiede o partecipa al board AI.
- Responsabile AI governance: possiede registro, classificazione, calendario e fascicolo delle evidenze.
- Owner di sistema: uno per sistema, responsabile di risultati, sorveglianza e metriche.
- Legale / DPO: decisioni di classificazione, valutazioni d'impatto, clausole con i fornitori.
- Security: controlli di accesso, risposta agli incidenti, monitoraggio degli strumenti non autorizzati.
- Engineering: logging, punti di sorveglianza e valutazione costruiti dentro i sistemi stessi.
“Se in azienda nessuno può spegnere un sistema di AI, non avete governance. Avete documentazione.”
— Michele Cimmino · Fractional CTO & Digital Transformation Advisor
I Primi 90 Giorni
- Settimane 1–2 — nominare e annunciare. Nominate sponsor esecutivo e responsabile AI governance, formate il board AI di cinque persone e annunciate un inventario in stile amnistia: dichiarate cosa usate, nessuno viene punito.
- Settimane 2–5 — costruire il registro. Dati di acquisti, note spese, SSO e browser, più il sondaggio. Includete le funzionalità AI dentro i SaaS esistenti. Registrate il ruolo di fornitore o deployer per ogni riga.
- Settimane 5–6 — classificare e fare triage. Classificate ogni sistema secondo l'AI Act e la criticità di business. Dismettete o bloccate subito ciò che è vietato o indifendibile; di solito c'è almeno un caso.
- Settimane 6–8 — pubblicare la policy di una pagina con strumenti approvati, classi di dati e una via di approvazione in cinque giorni per i nuovi strumenti. Avviate la formazione per ruolo e registrate le presenze.
- Settimane 8–10 — sistemare il lato fornitori. Inviate il questionario AI ai vendor dietro i sistemi di livello alto e pianificate le modifiche contrattuali al prossimo rinnovo.
- Settimane 10–12 — strumentare i sistemi di livello alto. Definite punti di sorveglianza e logging delle decisioni per ciascuno, partendo da tutto ciò che rientra nell'Allegato III. Assemblate il fascicolo delle evidenze e tenete la prima revisione trimestrale.
Errori da Evitare
- Comprare una piattaforma di AI governance prima di avere un registro. Gli strumenti automatizzano un processo; non lo inventano. Quasi tutte le medie imprese possono gestire il primo anno con un foglio di calcolo ben strutturato e il loro strumento GRC o di ticketing esistente.
- Scrivere prima una carta etica. Principi senza inventario producono un documento che nessuno sa applicare. Scrivete i principi dopo aver capito cosa governeranno.
- Trattare la governance come un progetto del legale. Metà dei controlli è ingegneria — logging, accessi, punti di sorveglianza — e nessuna policy la consegna.
- Ignorare l'AI dentro i software che già pagate. È la parte più grande e meno visibile del registro, e cambia a ogni rilascio del fornitore. È la stessa dinamica dietro il costo crescente dei SaaS enterprise di cui ho scritto in la fine dell'era SaaS.
- Vietare strumenti senza una via di approvazione. Non ferma l'uso. Vi impedisce di vederlo.
- Leggere l'Omnibus come un permesso di aspettare. Divieti, alfabetizzazione e trasparenza si applicano già, e la due diligence dei vostri clienti non segue il calendario dell'AI Act.
In Sintesi
L'AI governance per una media impresa non è la versione ridotta di quella di una banca globale. È un problema diverso: pochi sistemi costruiti in casa, molti di più presi in affitto, pochissimo personale dedicato, e lo stesso regolatore. La risposta è un framework abbastanza piccolo da gestire con le persone che avete già — un inventario, una classificazione, owner con nome e cognome, una policy di una pagina, logging dove serve, clausole con i fornitori e una revisione trimestrale. Il Digital Omnibus ha dato ai deployer dell'Allegato III tempo fino a dicembre 2027. Usate la finestra per costruire le evidenze, non per rimandare la conversazione. Le aziende che possono mostrare il proprio registro AI in una riunione di due diligence scopriranno che la governance non è solo un costo. È un motivo per essere scelte.
Se vi serve un secondo parere
Aiuto medie imprese di finanza, assicurazioni, sanità ed energia a impostare esattamente questo: il primo inventario, le decisioni fornitore-o-deployer, il design di sorveglianza e logging per i sistemi che lo richiedono, e le domande da fare ai fornitori prima del rinnovo. Con Lasting Dynamics costruiamo anche i sistemi di AI, ed è per questo che tengo a una governance che gli ingegneri possano davvero implementare.