BOARD BRIEFING REPORTBanche & mercati finanziari europeiDomanda al Management Board · Per discussione

Abbiamo una policy, uno standard e un certificato — che cosa dimostrano?

TopicArchitettura di governance dell'AI
AudienceManagement Board · CIO · CRO · CDO · Compliance
Read Time11 minuti
Target StatusGREEN — quando legge, sistema di gestione, metodo di rischio e test si collegano in un modello operativo tracciabile

In sintesi

Ciascuno di questi elementi viene descritto come il framework di governance dell'IA dell'istituzione.

<strong>Nessuno risponde alla stessa domanda.</strong>

Domanda al consiglioIl management può dimostrare come obblighi giuridici, governance organizzativa, decisioni di rischio e test dei sistemi si colleghino in un unico modello operativo tracciabile?

Situazione

Il management presenta al consiglio una policy sull'IA allineata all'EU AI Act, un programma di certificazione ISO/IEC 42001, una metodologia di rischio basata sul NIST AI Risk Management Framework e un processo di test tecnici.

Ciascuno di questi elementi viene descritto come il framework di governance dell'IA dell'istituzione.

Nessuno risponde alla stessa domanda.

Le singole componenti possono essere ben progettate. La domanda per il consiglio è se formino un sistema integrato. Un quadro giuridico definisce gli obblighi. Un sistema di gestione determina come opera la governance. Una metodologia di rischio struttura il giudizio. Test e assurance forniscono evidenza che risultati attesi e controlli siano stati effettivamente raggiunti.

  • Un certificato non sostituisce una matrice di corrispondenza normativa.
  • Una valutazione del rischio non dimostra che un controllo funzioni.
  • Un risultato di test non prova che siano stati identificati gli obblighi giuridici corretti.

Management Summary

Un framework completo di governance dell'IA comprende quattro livelli collegati:

  1. Il diritto determina ciò che è vietato, obbligatorio o condizionato.
  2. Il sistema di gestione assegna le responsabilità e rende la governance ripetibile.
  3. La metodologia di rischio determina come i rischi vengono classificati, valutati, accettati e trattati.
  4. Test ed evidenze dimostrano come sistemi e controlli operano nella pratica.

Questi livelli sono complementari, non intercambiabili.

ISO/IEC 42001 può fornire un sistema di gestione dell'IA strutturato e certificabile. Non dimostra automaticamente la conformità all'EU AI Act per ogni sistema o caso d'uso. Il programma europeo di normazione ha sviluppato EN 18286 specificamente per i requisiti di gestione della qualità collegati all'AI Act, perché ISO/IEC 42001 non è stata ritenuta pienamente allineata agli obiettivi e alle definizioni di tale requisito normativo.

Il consiglio dovrebbe quindi aspettarsi un Framework Stack, non una singola etichetta di framework.

Un'istituzione può acquistare un certificato. Non può acquistare la > matrice di corrispondenza.

Management Report Panel

Domanda del consiglio
Come si collegano i nostri framework giuridici, di gestione, di rischio e di test?
Distinzione centrale
Ogni livello risponde a una domanda di governance diversa.
Rischio principale
Il nome di un framework o un certificato viene usato come evidenza per aspetti al di fuori del suo perimetro.
Prova richiesta
Una linea tracciabile dall'obbligo al controllo, al test, al responsabile e all'evidenza conservata.
Condizione obiettivo
Un'unica architettura governata che copra l'intera popolazione IA e il relativo ciclo di vita.

Calibrazione della qualità della risposta

GREENRisposta di qualità decisionale
AMBERRisposta parzialmente comprovata
REDNon di qualità decisionale
InventarioUn'unica popolazione IA governata e riconciliata
InventarioEsiste un inventario, ma alcune IA di terzi o integrate restano fuori dal perimetro
Inventario“Sappiamo dove si trova la nostra IA.”
Mappatura giuridicaMatrice di corrispondenza tra requisiti e controlli per caso d'uso
Mappatura giuridicaEsiste una mappa giuridica, ma non è collegata ai controlli
Mappatura giuridica“Siamo allineati all'EU AI Act.”
Perimetro di certificazionePerimetro, esclusioni e confini organizzativi sono espliciti
Perimetro di certificazioneEsiste un certificato, ma il suo perimetro non è riconciliato con l'inventario IA
Perimetro di certificazione“Stiamo perseguendo una certificazione ISO.”
Metodologia di rischioLa classificazione determina il percorso di governance
Metodologia di rischioEsistono punteggi di rischio, ma non modificano requisiti o approvazioni
Metodologia di rischio“Seguiamo il framework NIST.”
TestLe soglie di accettazione sono collegate all'uso previsto
TestI test vengono eseguiti ma sono scollegati dal caso d'uso o dalla decisione
Test“Il fornitore ha testato il modello.”
ResponsabilitàUn responsabile nominato ha l'autorità di approvare, fermare ed effettuare escalation
ResponsabilitàI comitati sono coinvolti, ma l'autorità personale non è chiara
Responsabilità“Passa attraverso il comitato IA.”
Terze partiEvidenze, obblighi di notifica delle modifiche e diritti di assurance sono definiti
Terze partiEsistono clausole contrattuali, ma le evidenze operative sono incomplete
Terze parti“È responsabilità del fornitore.”
Reporting al consiglioEfficacia, eccezioni e decisioni vengono riportate
Reporting al consiglioViene riportato lo stato di avanzamento, ma l'efficacia dei controlli non è visibile
Reporting al consiglio“Il programma è in linea con il piano.”

Lo stato RAG calibra la qualità della risposta. Non giudica l'istituzione.

The Framework Stack

01
Quadro giuridico
Che cosa deve fare l'istituzione?
02
Sistema di gestione
Chi governa l'IA e attraverso quali responsabilità e processi?
03
Metodologia di rischio
Come vengono identificati, valutati, accettati e trattati i rischi dell'IA?
04
Test ed evidenze
Che cosa dimostra che il sistema e i suoi controlli funzionano come dichiarato?

Ogni livello risponde a una domanda diversa. Nessuno risponde a quella successiva.

Chi dovrebbe rispondere

Responsabilità di businessLegaleComplianceRischiModel RiskTecnologiaDatiCybersecurityProtezione dei datiRischio terze partiProcurementInternal Audit
Nota di responsabilità:
  • L'appartenenza a un comitato non equivale alla responsabilità personale.
  • Il responsabile nominato deve detenere l'autorità necessaria per approvare, limitare, sospendere o effettuare escalation sull'uso dell'IA interessato.

Prove che il consiglio dovrebbe richiedere

  1. 01Inventario IA aziendale
  2. 02Mappa dell'architettura dei framework
  3. 03Matrice di corrispondenza normativa
  4. 04Responsabilità e diritti decisionali
  5. 05Metodologia di classificazione
  6. 06Mappa dei controlli del ciclo di vita
  7. 07Valutazione d'impatto e del rischio
  8. 08Registro di test e validazione
  9. 09Dichiarazione del perimetro di certificazione
  10. 10Pacchetto di reporting al consiglio

Segnali di allarme

  • “Seguiamo il framework NIST.”
  • “Siamo allineati all'EU AI Act.”
  • “Stiamo perseguendo una certificazione ISO.”
  • “Il fornitore ha testato il modello.”
  • “Un essere umano approva l'output.”
  • “È coperto dalla policy sull'IA.”
  • “È solo uno strumento interno.”
  • “Il framework è in fase di implementazione.”

Nessuna di queste affermazioni è necessariamente errata. Semplicemente, non costituisce evidenza sufficiente per una decisione affidabile del consiglio.

Percorso verso il verde

  • Architettura nominata
  • Matrice di corrispondenza costruita
  • La classificazione determina il percorso
  • Standard di evidenza definito
  • Terze parti incluse
  • Efficacia monitorata

Un inventario giuridico non collegato ai controlli resta > un'interpretazione. Una libreria di controlli non collegata al diritto > resta una scelta interna di progettazione.

Il consiglio non dovrebbe chiedere quale framework segue > l'istituzione. Dovrebbe chiedere se un uso dell'IA ad alto impatto > possa essere tracciato dall'obbligo fino all'evidenza operativa.

Prossima domanda suggerita

Prendete un sistema di IA che possa incidere in modo rilevante su un cliente, un dipendente, una transazione o un processo critico. Il management può mostrare, in un'unica catena di evidenze, il diritto applicabile, il responsabile accountable, la decisione di rischio approvata, i controlli operativi, i risultati dei test, il percorso di intervento umano, le dipendenze da terze parti e lo stato attuale in produzione?

Commento dell'esperto — 6 min di lettura

01

Il quadro giuridico definisce l'obbligo

Il livello giuridico determina quali obblighi si applicano a un sistema di IA, il ruolo regolamentare dell'istituzione e le evidenze richieste per dimostrare la conformità.

Nell'Unione europea, l'AI Act si affianca a GDPR, DORA e ai requisiti settoriali esistenti. Gli obblighi rilevanti dipendono, tra l'altro, dalla finalità prevista, dalla classificazione del sistema, dalle persone interessate, dal ruolo dell'organizzazione e dall'uso in un processo regolamentato.

Per i sistemi di IA ad alto rischio, l'AI Act affronta aree quali gestione del rischio, data governance, documentazione tecnica, registrazione, sorveglianza umana, accuratezza, robustezza, cybersecurity e gestione della qualità. L'articolo 17 impone ai provider di mantenere un sistema di gestione della qualità documentato che assicuri la conformità al regolamento.

Ciò non significa che una banca debba costruire una struttura di controlli isolata per l'AI Act. I requisiti di governance esistenti restano rilevanti. DORA disciplina ICT e resilienza operativa. Il GDPR impone accountability nel trattamento dei dati personali e limita determinate decisioni automatizzate. I requisiti del settore finanziario in materia di governance, outsourcing, condotta e model risk possono continuare ad applicarsi allo stesso sistema.

Il livello giuridico deve quindi rispondere a tre domande:

  • Quali obblighi si applicano?
  • A quale entità, ruolo e caso d'uso si applicano?
  • Attraverso quali controlli ed evidenze saranno dimostrati?

Un inventario giuridico non collegato ai controlli resta un'interpretazione. Una libreria di controlli non collegata al diritto resta una scelta interna di progettazione.

02

Il sistema di gestione rende la governance ripetibile

ISO/IEC 42001 definisce i requisiti di un sistema di gestione dell'IA. Riguarda i processi organizzativi utilizzati per istituire, implementare, mantenere e migliorare continuamente la governance dell'IA.

Il suo valore è la ripetibilità. Può fornire una struttura per perimetro, policy, obiettivi, responsabilità, processi di rischio, competenze, comunicazione, monitoraggio, internal audit e miglioramento continuo.

Una certificazione ISO/IEC 42001 costituisce quindi un'evidenza significativa relativa a un perimetro definito del sistema di gestione. Non dimostra automaticamente che ogni caso d'uso IA rientri in tale perimetro o che ogni sistema sia conforme all'EU AI Act.

Questa distinzione è rafforzata da EN 18286:2026, il primo standard europeo pubblicato a supporto dell'attuazione dell'AI Act. Riguarda il sistema di gestione della qualità richiesto per finalità regolamentari, in particolare ai sensi dell'articolo 17.

CEN-CENELEC JTC 21 ha valutato se ISO/IEC 42001 potesse essere adottata per il requisito di gestione della qualità previsto dall'articolo 17 dell'AI Act. Poiché obiettivi e definizioni non sono stati ritenuti pienamente allineati a tale requisito regolamentare, è stato sviluppato uno standard europeo separato: EN 18286, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*.

Il punto non è che ISO/IEC 42001 sia inadeguata. Il punto è che uno standard organizzativo di sistema di gestione e un requisito regolamentare di gestione della qualità non dimostrano la stessa cosa.

EN 18286 definisce la qualità in relazione alla conformità ai requisiti applicabili dell'AI Act, non come qualità del prodotto nel senso tradizionale di ISO 9001. La sua struttura consente inoltre di integrare i requisiti specifici dell'IA in un sistema settoriale esistente di gestione della qualità, invece di costringere le organizzazioni a creare un secondo sistema parallelo.

Per le banche, il principio pratico è l'integrazione. La governance dell'IA dovrebbe estendere i framework esistenti di enterprise governance, tecnologia, dati, rischio e resilienza operativa quando tali strutture restano appropriate.

L'articolo 40 dell'AI Act attribuisce una presunzione di conformità solo quando il riferimento a uno standard armonizzato è stato pubblicato nella Gazzetta ufficiale dell'Unione europea, e solo per i requisiti coperti da tale standard. Alla fine di luglio 2026, il riferimento a EN 18286 non era ancora stato pubblicato nella Gazzetta ufficiale.

Un'istituzione può acquistare un certificato. Non può acquistare la matrice di corrispondenza.

Il consiglio dovrebbe quindi richiedere il perimetro preciso della certificazione, le esclusioni, le attività coperte e il rapporto con l'inventario IA e gli obblighi regolamentari.

03

La metodologia di rischio struttura il giudizio

Il NIST AI Risk Management Framework organizza le attività di gestione del rischio IA attraverso quattro funzioni:

  • Govern
  • Map
  • Measure
  • Manage

Govern è trasversale. Map stabilisce il contesto e identifica soggetti interessati e rischi. Measure valuta e monitora comportamento del sistema e rischio. Manage assegna priorità e tratta i rischi in base a obiettivi e tolleranze dell'organizzazione.

Questo crea un linguaggio comune per il rischio IA senza prescrivere un unico esito regolamentare o set di controlli.

Il framework può supportare:

  • tassonomia dei rischi,
  • classificazione dei casi d'uso,
  • valutazione di impatto e materialità,
  • misurazione del rischio,
  • criteri di accettazione,
  • soglie di escalation,
  • e decisioni di trattamento.

Ma il framework non determina quali obblighi giuridici si applichino. Né il completamento di una valutazione del rischio dimostra che la mitigazione operi efficacemente.

La classificazione dovrebbe determinare il percorso di governance. Non dovrebbe limitarsi a compilare un campo di reporting.

Una decisione cliente ad alto impatto, uno strumento interno di produttività a basso rischio e un agente autonomo con accesso alla produzione non dovrebbero seguire lo stesso percorso di approvazione, test e monitoraggio. Ciascuno dovrebbe tuttavia seguire un percorso definito, spiegabile e dimostrabile.

Il consiglio dovrebbe aspettarsi che ogni decisione di rischio rilevante sia collegata a:

  • un responsabile accountable,
  • una tolleranza approvata,
  • un obiettivo di controllo,
  • un controllo implementato,
  • un test,
  • e uno stato operativo attuale.
04

Test e assurance producono evidenze

I test trasformano le affermazioni di governance in evidenze esaminabili.

AI Verify illustra questo livello attraverso undici principi di governance. Ogni principio è collegato a risultati attesi, processi ed evidenze documentali. Il framework combina valutazioni tecniche e non tecniche, invece di trattare l'IA affidabile soltanto come una questione di performance del modello.

Test e assurance possono includere:

  • valutazioni di accuratezza e performance,
  • test di robustezza e cybersecurity,
  • valutazioni di bias ed equità,
  • valutazioni di explainability,
  • evidenze di data lineage e qualità dei dati,
  • valutazioni d'impatto,
  • esercitazioni di sorveglianza umana,
  • red teaming e test di uso improprio,
  • verifiche di riproducibilità,
  • test dei controlli,
  • e assurance indipendente.

Il test rilevante dipende dall'uso previsto. Un modello può ottenere buoni risultati su un benchmark generale e risultare comunque inadatto a una specifica decisione, popolazione di clienti, ambiente operativo o tolleranza al rischio.

Affermare che un essere umano resta "in the loop" non è una descrizione di controllo. Il record di governance dovrebbe identificare che cosa decide la persona, quali informazioni sono disponibili, quanto tempo ha per intervenire e se dispone dell'autorità per modificare il risultato.

La stessa disciplina si applica alla certificazione esterna. ISO/IEC 42006 stabilisce i requisiti per gli organismi che auditano e certificano i sistemi di gestione dell'IA. Rafforza la fiducia nel processo di certificazione; non amplia il perimetro di ciò che ISO/IEC 42001 certifica.

Il consiglio non deve approvare ogni singolo script di test. Dovrebbe richiedere al management di spiegare:

1. il risultato oggetto di test, 2. perché il metodo è appropriato, 3. la soglia di accettazione applicabile, 4. chi può approvare un'eccezione, 5. per quanto tempo l'evidenza resta valida, 6. e quali modifiche richiedono una nuova valutazione.

Lo scopo del reporting al consiglio non è riprodurre l'inventario IA. È mostrare se il sistema di governance resta efficace e dove è necessaria una decisione.

Base di fonti selezionata

  1. Regolamento (UE) 2024/1689 — Artificial Intelligence Act
  2. Regolamento (UE) 2026/1744 — Digital Omnibus on AI
  3. CEN-CENELEC — Artificial Intelligence and JTC 21
  4. CEN-CENELEC — EN 18286 in the Spotlight: Supporting Compliance with the AI Act
  5. ISO/IEC 42001:2023 — AI Management Systems
  6. ISO/IEC 42006:2025 — Certification of AI Management Systems
  7. NIST AI Risk Management Framework
  8. NIST Generative AI Profile — AI 600-1
  9. AI Verify Foundation — Testing Framework
  10. European Banking Authority — AI Act Implications for Banking and Payments
  11. IOSCO — Supervisory Toolkit for AI Use in Capital Markets
  12. Principi OCSE sull'IA

← Tutti i briefing