Anteprima del template (estratto)
Scorrete per vedere tutte le colonne
Sezione 4: Metriche delle prestazioni
4.1 Metriche delle prestazioni tecniche
| Metrica | Definizione | Soglia | Livello di alert |
|---|---|---|---|
| [Accuratezza] | [% di previsioni corrette] | [>95%] | [Critico se <90%] |
4.2 Metriche di deriva
| Metrica | Metodo di calcolo | Soglia | Frequenza di verifica |
|---|---|---|---|
| [Deriva delle caratteristiche] | [PSI o divergenza KL] | [PSI <0.1] | [Giornaliera] |
Sezione 5: Alert ed escalation
5.1 Livelli di gravità degli alert
| Livello | Criteri | Tempo di risposta |
|---|---|---|
| Critico | [Rischio immediato, violazione di conformità] | [15 minuti] |
| Alto | [Degrado significativo] | [4 ore] |
Visualizzate l'esempio compilato
Livelli di gravità degli alert:
| Livello | Criteri | Tempo di risposta |
|---|---|---|
| Critico | Sistema non disponibile, accuratezza <90%, esito discriminatorio | 15 minuti |
| Alto | Accuratezza <95%, soglia di deriva superata | 4 ore |
| Medio | Soglia in avvicinamento, pattern insolito | 24 ore |
| Basso | Variazione metrica minore, informativo | Giorno lavorativo successivo |
Prima di iniziare
Per i team di compliance, risk, prodotto e ML ops che portano Processes agentici in ambienti regolamentati.
L'Articolo 72 dell'EU AI Act richiede ai provider di sistemi IA ad alto rischio di istituire e documentare un sistema di monitoraggio post-market. Il sistema è obbligatorio: si tratta di un requisito di conformità con prescrizioni specifiche su come monitorare i sistemi IA dopo il deployment.
Questo modello offre un approccio strutturato in 8 sezioni che copre identificazione del sistema, obiettivi di monitoraggio, raccolta dei dati, metriche delle prestazioni, alert, procedure di revisione, risposta agli incidenti e documentazione.
Quando utilizzare questa risorsa
- State implementando un agente in un Process regolamentato (credito, sinistri, KYC/AML, HR).
- Avete bisogno di dimostrare qualità, sicurezza e conformità alle policy continuative dopo il go-live.
- State preparando un dossier Annex IV o una revisione della preparazione all'audit.
Informazioni da raccogliere
- Identificazione del sistema con classificazione normativa e riferimenti all'Annex IV.
- Obiettivi di monitoraggio collegati al registro dei rischi con criteri di successo.
- Fonti dei dati, frequenza di raccolta, requisiti di qualità e considerazioni sulla privacy.
- Soglie delle prestazioni (tecniche, di deriva, di equità) con livelli di gravità.
- Configurazione degli alert con matrice di escalation e copertura fuori orario.
- Procedure di revisione (continue, a campione, periodiche) con integrazione nella governance.
- Procedure di risposta agli incidenti, inclusa la segnalazione normativa ai sensi dell'Articolo 73.
Checklist di revisione
Utilizzate queste verifiche nella revisione insieme al responsabile del sistema. Confermate i requisiti applicabili e allegate le evidenze per le decisioni prese dal vostro team.
- L'identificazione del sistema collega la classificazione normativa alla documentazione dell'Annex IV.
- Gli obiettivi di monitoraggio sono collegati ai rischi identificati con criteri di successo chiari.
- La raccolta dei dati copre tutte le fonti con requisiti di qualità e considerazioni sulla privacy.
- Le metriche delle prestazioni includono soglie tecniche, di deriva e di equità con livelli di gravità.
- Gli alert definiscono livelli di gravità, matrice di notifica e procedure di escalation.
- Le procedure di revisione includono monitoraggio continuo, campionamento e revisioni periodiche della governance.
- La risposta agli incidenti copre definizione, risposta immediata, indagine e segnalazione ai sensi dell'Articolo 73.
- La documentazione e l'archiviazione delle evidenze assicurano una conservazione a prova di manomissione e la preparazione all'audit.
Controlli operativi ed evidenze
- Govern
Checkpoint policy-as-code che bloccano o richiedono una revisione per le azioni ad alto rischio.
Controllo di versione delle modifiche per aggiornamenti di modello/prompt/policy/Process.
- Assurance
Revisioni di campionamento per livello di rischio (baseline + incremento durante gli incidenti o dopo le modifiche).
Monitoraggio dei near-miss (passaggi bloccati/quasi bloccati) come segnale di controllo misurabile.
- Dimostrare
Calendari di conservazione configurabili, verifica dell'integrità e Audit Trail append-only.
Bundle di esportazione di Evidence Room (manifest + checksum) per consentire agli auditor una verifica indipendente.
Domande su questa risorsa
Che cos'è il "monitoraggio post-market" in parole semplici?
È il modo per dimostrare che il sistema resta sicuro e adeguato allo scopo dopo il go-live: cosa misurate, come esaminate i campioni e come rispondete a incidenti e modifiche.
Cosa richiede l'Articolo 72?
L'Articolo 72 richiede la raccolta attiva dei dati sulle prestazioni del sistema, l'identificazione delle necessità di azioni correttive e la documentazione delle attività di monitoraggio. Questo modello copre tutti e tre i requisiti.
Qual è la differenza tra alert e risposta agli incidenti?
Gli alert rilevano i problemi e informano le persone giuste. La risposta agli incidenti definisce cosa accade dopo il rilevamento: valutazione, contenimento, indagine, risoluzione e documentazione.
Cosa attiva la segnalazione normativa ai sensi dell'Articolo 73?
Gli incidenti gravi che coinvolgono sistemi IA ad alto rischio devono essere segnalati immediatamente alle autorità di vigilanza del mercato non appena se ne viene a conoscenza. Il modello include una sezione per la segnalazione normativa.
Come garantiamo l'integrità delle evidenze?
Utilizzate archiviazione che rende rilevabili le manomissioni (registro append-only con integrità crittografica), raccolta completa nei punti decisionali, logging degli accessi e audit periodici dell'integrità.
Cosa rifiutano più spesso gli auditor?
Piani generici. Gli auditor vogliono responsabili designati, soglie specifiche, procedure chiare di escalation ed evidenze esportabili e verificabili in modo indipendente.
Lingua del file scaricato: inglese