Approvazione umana e lineage di esecuzione
L'approvazione umana fa parte di un record di esecuzione. Questo playbook spiega cosa raccogliere prima di un'azione, quando decide un revisore e dopo l'esecuzione.
Esecuzione del pagamento
Invio accettato
Pagamento richiesto
Invia il pagamento al fornitore · €420.000
Agente pagamenti di tesoreriaApprovazione richiesta
L'importo supera la soglia di €250.000
Limiti di pagamento · versione 3Approvato dalla tesoreria
Fattura e ambito dell'approvazione confermati
Revisore di tesoreriaLo strumento ha accettato l'invio
Invio accettato; il regolamento non è mostrato
Strumento di pagamento
Cosa raccogliere in ogni fase
Un agente richiede un pagamento superiore alla soglia di revisione. La policy richiede approvazione. Le evidenze devono collegare la richiesta alla revisione e al risultato finale dell'esecuzione.
- 1
Acquisite la richiesta
Registrate l'agente, l'azione proposta, gli input pertinenti e l'identificativo della richiesta.
- 2
Conservate la decisione della policy
Registrate la versione della policy, il contesto valutato, l'esito e la motivazione.
- 3
Allegate la decisione umana
Conservate l'identità del revisore, la decisione, la motivazione, l'orario e il rapporto con la richiesta originale.
- 4
Registrate ciò che è stato eseguito
Collegate l'azione autorizzata e il relativo risultato alla stessa richiesta. Una richiesta rifiutata deve restare distinguibile da un'azione completata.
- 5
Preparate l'artefatto di revisione
Raccogliete i record e il materiale di supporto con un manifest e informazioni sull'integrità.
L'unità utile è la decisione completa: richiesta, regola, revisore, risultato ed evidenze di supporto. Lineage Explorer ed Evidence Room forniscono le superfici di indagine e revisione per questo lavoro.
Controlli e limiti della verifica
Un Sealed Evidence Bundle fornisce al revisore un artefatto da esaminare. La verifica controlla la sua struttura crittografica rispetto al materiale fornito e alla configurazione di trust.
L'autenticità richiede un controllo della chiave fuori banda. Le firme di SEK, TEK e della ricevuta vengono tutte verificate rispetto alle chiavi incorporate dal bundle in keys/jwks.json; quindi, offline, il bundle dimostra solo la propria coerenza interna. Per dimostrare che proviene da KLA, fissate queste chiavi rispetto a un JWKS pubblicato da KLA o a un'impronta della chiave.
L'ancoraggio OpenTimestamps a Bitcoin è considerato attendibile offline. La conferma dell'altezza del blocco confronta la prova con la blockchain Bitcoin live e una ricevuta di calendario in sospeso resta in sospeso fino a un aggiornamento del calendario.
La prova dell'ancoraggio del registro immudb è presente e viene analizzata offline. La conferma della sua inclusione rispetto allo stato firmato del registro richiede un controllo connesso alla rete.
- Firma del manifest
- Il manifest viene canonizzato (RFC 8785 / JCS) e il relativo digest viene ricalcolato. Il JWS detached contiene firme ES256 valide di SEK e TEK su quel digest, verificate rispetto alle chiavi pubbliche incorporate dal bundle in keys/jwks.json.
- Inclusione Merkle
- Ogni artefatto ricalcola l'hash SHA-256 fino al digest dichiarato dal manifest, la prova di inclusione di ogni artefatto raggiunge la radice sigillata e la radice Merkle ricalcolata corrisponde al valore del manifest.
- Firme della ricevuta
- Ogni catena di ricevute di governance viene verificata: la firma ed25519 di ogni ricevuta viene controllata rispetto a una chiave incorporata nel bundle e il prevReceiptHash di ogni passaggio si collega al passaggio precedente, dalla genesi all'ultimo.
- Catena di hash del registro
- Ogni record del registro esportato ricalcola l'hash dichiarato e i record consecutivi si collegano end-to-end tramite previousHash.
- Ancoraggio OpenTimestamps
- timestamp.ots viene analizzato secondo le regole rigorose di OpenTimestamps e si impegna nel digest del manifest ricalcolato. Quando la ricevuta è attestata da Bitcoin, il verificatore riporta l'altezza del blocco; una ricevuta di calendario in sospeso viene accettata come conferma Bitcoin in sospeso.
Precedenti normativi
Questi riferimenti descrivono diversi contesti di gestione dei record. Utilizzateli per esaminare la questione delle evidenze in ciascun regime e seguite la fonte per il relativo ambito.
SOX
Prassi di gestione dei record
COSO framework: 17 principi, 87 punti di attenzione, tasso di carenze del 40% negli audit Big 4
MiFID II
Prassi di gestione dei record
100 microsecondi di divergenza UTC (HFT), archiviazione WORM, conservazione per 5-7 anni, ricostruzione in 72 ore
GDPR
Prassi di gestione dei record
2FA ora atteso (multa all'Haga Hospital), procedure di accesso documentate richieste
Regolamento MDR
Prassi di gestione dei record
Tracce di audit IEC 62304, controllo completo delle versioni, tracciabilità dai requisiti ai test
Fonte: Regolamento (UE) 2024/1689. Esaminate i requisiti applicabili al vostro sistema con le persone responsabili della relativa valutazione legale e operativa.
Domande e dettagli
L'Articolo 12 richiede esplicitamente l'integrità crittografica?
No, ma il modello derivato da MiFID II, SOX, GDPR e MDR è chiaro: il testo basato sui principi diventa prassi prescrittiva entro 2-4 anni. Gli auditor e gli organismi notificati interpreteranno la "registrazione automatica" come logging a prova di manomissione.
Quali periodi di conservazione si applicano ai log IA?
L'Articolo 12 specifica un minimo di 6 mesi per i log automatizzati, ma spesso i requisiti specifici del settore prevalgono. Le istituzioni finanziarie dovrebbero prevedere 5-7 anni. La documentazione tecnica deve essere conservata per 10 anni dopo l'immissione del sistema sul mercato.
Quando saranno pubblicati gli standard armonizzati?
prEN ISO/IEC 24970 (standard di logging) è in votazione come Draft International Standard. prEN 18286 (standard QMS) è entrata nella consultazione pubblica nell'ottobre 2025. Gli standard definitivi sono attesi nel Q4 2026, ma le aspettative degli auditor si stanno formando già ora.
Quale accesso avranno gli organismi notificati?
Ai sensi dell'Annex VII, gli organismi notificati possono richiedere accesso API completo ai dataset di training, convalida e test. Possono svolgere test diretti se le evidenze del provider non sono soddisfacenti. Gli stessi log di accesso ai dataset diventeranno oggetto di audit.
Come dobbiamo gestire l'auditabilità dei modelli ML?
Le soglie per un logging esteso restano poco chiare, ma gli auditor probabilmente si aspetteranno: tracciamento della versione del modello, modifiche agli iperparametri, metadati delle esecuzioni di training e tracciabilità delle decisioni per output ad alto rischio.