Anteprima del template (estratto)
Scorrete per vedere tutte le colonne
Sezione 2: Uso previsto
2.1 Casi d'uso principali
| Caso d'uso | Descrizione | Tipo di utente |
|---|---|---|
| [Caso d'uso principale 1] | [Descrizione dettagliata] | [Chi lo utilizza] |
2.3 Usi fuori ambito
| Caso d'uso | Motivo per cui non è supportato |
|---|---|
| [Caso d'uso vietato 1] | [Perché è inappropriato: limiti dei dati, considerazioni etiche, ecc.] |
Sezione 7: Limitazioni
7.2 Modalità di errore note
| Modalità di errore | Condizioni di attivazione | Rilevamento | Risposta |
|---|---|---|---|
| [Modalità di errore 1] | [Cosa causa questo errore] | [Come rilevarlo] | [Cosa fare] |
Visualizzate l'esempio compilato
Usi fuori ambito:
| Caso d'uso | Motivo per cui non è supportato |
|---|---|
| Processo decisionale esclusivamente automatizzato per il credito | Modello progettato solo come supporto decisionale; richiede revisione umana |
| Utilizzo su popolazioni non presenti nei dati di training | Prestazioni non convalidate; può produrre risultati inaffidabili |
| Applicazioni critiche per la sicurezza in tempo reale | Requisiti di latenza non convalidati per questo caso d'uso |
Prima di iniziare
Per i team di compliance, risk, prodotto e ML ops che portano Processes agentici in ambienti regolamentati.
Le model card sono documentazione standardizzata per i modelli IA. Proposte originariamente da ricercatori di Google nel 2019, sono diventate una best practice di settore per comunicare cosa fa un modello, come si comporta e quali sono le sue limitazioni.
Per le organizzazioni soggette all'EU AI Act, le model card aiutano a soddisfare i requisiti di trasparenza previsti dall'Articolo 13 e contribuiscono alla documentazione tecnica richiesta dall'Annex IV.
Quando utilizzare questa risorsa
- State implementando modelli ML e avete bisogno di documentazione standardizzata per i revisori tecnici.
- Avete bisogno di soddisfare i requisiti di trasparenza dell'EU AI Act (Articolo 13) o contribuire alla documentazione Annex IV.
- Volete comunicare capacità, limitazioni e considerazioni etiche del modello a deployer e utenti.
Informazioni da raccogliere
- Dettagli su architettura, versione e provenienza del training del modello.
- Casi d'uso previsti e usi espliciti fuori ambito.
- Documentazione dei dati di training e valutazione con problemi noti.
- Metriche delle prestazioni (complessive + disaggregate) con intervalli di confidenza.
- Risultati dell'analisi dell'equità e considerazioni etiche.
- Limitazioni note, modalità di errore e condizioni ai margini.
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 modello include versione, architettura, lineage e provenienza dello sviluppo.
- L'uso previsto definisce i casi d'uso principali, gli utenti previsti e indica esplicitamente gli usi fuori ambito.
- I dati di training sono documentati con fonti, caratteristiche, pre-processing e problemi di qualità noti.
- Le metriche delle prestazioni includono risultati complessivi e disaggregati con intervalli di confidenza.
- Le considerazioni etiche coprono metriche di equità, test del bias e caratteristiche protette.
- Le limitazioni sono documentate in modo completo, incluse le modalità di errore e le condizioni ai margini.
- Le raccomandazioni forniscono indicazioni operative per deployment, monitoraggio e manutenzione.
Controlli operativi ed evidenze
- Govern
Model card con controllo di versione collegate al registro dei modelli e alle pipeline di deployment.
Gate di approvazione che verificano la completezza della model card prima della messa in produzione.
- Assurance
Acquisizione automatica delle metriche delle prestazioni, dei segnali di deriva e degli indicatori di equità.
Monitoraggio disaggregato delle prestazioni tra gruppi protetti e condizioni ai margini.
- Dimostrare
Model card collegate agli artefatti di valutazione, al lineage dei dati di training e ai record di approvazione.
Bundle di evidenze che collegano le asserzioni documentali ai dati delle prestazioni a runtime.
Domande su questa risorsa
Qual è la differenza tra una model card e una system card?
Una model card documenta un singolo modello ML. Una system card documenta un sistema IA completo che può includere più modelli, integrazioni e Processes. Le model card sono elementi costitutivi delle system card.
Le model card sono richieste dall'EU AI Act?
L'EU AI Act non impone esplicitamente le model card, ma le informazioni che contengono sono richieste in varie forme nell'intero framework di conformità, in particolare per la trasparenza dell'Articolo 13 e la documentazione tecnica dell'Annex IV.
Con quale frequenza devono essere aggiornate le model card?
Aggiornate quando il modello viene nuovamente addestrato, le caratteristiche delle prestazioni cambiano in modo sostanziale, vengono scoperte nuove limitazioni o cambiano i casi d'uso previsti.
Cosa devo includere nelle prestazioni disaggregate?
Riportate le prestazioni tra i sottogruppi rilevanti per far emergere le disparità. Ove applicabile, i sottogruppi dovrebbero includere caratteristiche protette e condizioni che influenzano il comportamento del modello.
Come gestisco le limitazioni che scopro dopo il deployment?
Documentate immediatamente le limitazioni appena scoperte, aggiornate la model card e informate i responsabili del deployment. Collegate le limitazioni ai processi di monitoraggio e di risposta agli incidenti.
Cosa cercano i revisori nelle model card?
Limitazioni complete, non solo metriche favorevoli, prestazioni disaggregate, usi previsti e fuori ambito chiari e tracciabilità agli artefatti di valutazione e ai dati di training.
Lingua del file scaricato: inglese