Modello di piano di monitoraggio post-commercializzazione (conforme all'Articolo 72)
Scarica un modello di piano di monitoraggio post-commercializzazione conforme all'Articolo 72: identificazione del sistema, obiettivi, raccolta dati, metriche, alert, revisioni, gestione incidenti e documentazione.
Genera un piano di monitoraggio post-commercializzazione sottoponibile a revisione in 30-60 minuti.
Per i team di compliance, rischio, prodotto e ML Ops che distribuiscono Processi agentici in ambienti regolamentati.
Ultimo aggiornamento: 16 dic 2025 · Versione v1.0 · Campione fittizio. Non costituisce consulenza legale.
Segnala un problema: /contact
Cos'è questo artefatto (e quando vi serve)
Spiegazione essenziale minima, scritta per gli audit, non per la teoria.
L'Articolo 72 dell'EU AI Act impone ai fornitori di sistemi di IA ad alto rischio di istituire e documentare un sistema di monitoraggio post-commercializzazione. Non è facoltativo: è un requisito di conformità con prescrizioni specifiche sul monitoraggio dei sistemi di IA dopo la loro implementazione.
Questo modello offre un approccio strutturato in 8 sezioni che copre identificazione del sistema, obiettivi di monitoraggio, raccolta dati, metriche di performance, alert, procedure di revisione, risposta agli incidenti e documentazione.
Vi serve quando
- Stai implementando un agente in un Processo regolamentato (credito, sinistri, KYC/AML, HR).
- Devi dimostrare qualità, sicurezza e conformità alle policy nel tempo dopo il go-live.
- Stai preparando un dossier Allegato IV o una revisione della preparazione a un audit.
Errore comune
Un piano che elenca le metriche ma non definisce soglie, responsabili nominativi, procedure di escalation degli alert o un Processo di risposta agli incidenti collegato a evidenze esportabili.
Com'è fatto un buon risultato
Criteri di accettazione che i revisori verificano effettivamente.
- L'identificazione del sistema è collegata alla classificazione normativa e alla documentazione dell'Allegato IV.
- Gli obiettivi di monitoraggio sono collegati ai rischi identificati con criteri di successo chiari.
- La raccolta dati copre tutte le fonti con requisiti di qualità e considerazioni sulla privacy.
- Le metriche di performance includono soglie tecniche, di drift 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 di governance.
- La risposta agli incidenti copre definizione, risposta immediata, indagine e segnalazione ai sensi dell'Articolo 73.
- La documentazione e la conservazione delle evidenze garantiscono una conservazione a prova di manomissione e la preparazione agli audit.
Anteprima del template
Un estratto reale in HTML così è indicizzabile e revisionabile.
## Sezione 4: Metriche di performance ### 4.1 Metriche di performance tecniche | Metrica | Definizione | Soglia | Livello di alert | |--------|------------|-----------|-------------| | [Accuratezza] | [% di previsioni corrette] | [>95%] | [Critico se <90%] | ### 4.2 Metriche di drift | Metrica | Metodo di calcolo | Soglia | Frequenza di controllo | |--------|-------------------|-----------|-----------------| | [Drift delle feature] | [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 della conformità] | [15 minuti] | | Alto | [Degrado significativo] | [4 ore] |
Come compilarlo (rapidamente)
Input necessari, tempo di completamento e un esempio pratico in miniatura.
Input necessari
- Identificazione del sistema con classificazione normativa e riferimenti all'Allegato IV.
- Obiettivi di monitoraggio collegati al registro dei rischi con criteri di successo.
- Fonti dati, frequenza di raccolta, requisiti di qualità e considerazioni sulla privacy.
- Soglie di performance (tecniche, drift, equità) con livelli di gravità.
- Configurazione degli alert con matrice di escalation e copertura fuori orario.
- Procedure di revisione (continue, a campione, periodiche) integrate nella governance.
- Procedure di risposta agli incidenti, inclusa la segnalazione normativa ai sensi dell'Articolo 73.
Tempo di completamento: 30-60 minuti per una v1 difendibile.
Mini esempio: gravità degli alert
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 drift superata | 4 ore | | Medio | Soglia in avvicinamento, pattern insolito | 24 ore | | Basso | Variazione metrica minore, informativo | Giorno lavorativo successivo |
Come KLA lo trasforma in evidenza governata
Collegate l'artefatto alle primitive di prodotto per favorire la conversione.
Govern
- Checkpoint Policy-as-code che bloccano o richiedono una revisione per le azioni ad alto rischio.
- Controllo delle modifiche con versionamento per gli aggiornamenti di modello/prompt/policy/Processo.
Assure
- Revisioni a campione basate sul livello di rischio (baseline + intensificazione durante gli incidenti o dopo le modifiche).
- Tracciamento dei quasi incidenti (passaggi bloccati o quasi bloccati) come segnale di controllo misurabile.
Prove
- Programmi di conservazione configurabili, verifica dell’integrità e un Audit Trail append-only.
- Pacchetti di esportazione Evidence Room (manifest + checksum) che consentono agli auditor una verifica indipendente.
FAQ
Scritte per ottenere risposte in formato snippet.
Scarica l'artefatto
Markdown editabile. Nessuna email richiesta.
Scarica il modello modificabile