Approbation humaine et traçabilité d’exécution
L’approbation humaine fait partie d’un enregistrement d’exécution. Ce playbook explique ce qu’il faut capturer avant une action, au moment de la décision du réviseur et après l’exécution.
Exécution du paiement
Soumission acceptée
Paiement demandé
Soumettre un paiement fournisseur · €420,000
Agent de paiements de trésorerieApprobation requise
Le montant dépasse le seuil de €250,000
Limites de paiement · version 3Approuvé par la trésorerie
Détails de la facture et périmètre de l’approbation confirmés
Réviseur trésorerieL’outil a accepté la soumission
Soumission acceptée ; règlement du paiement non affiché
Outil de paiement
Que capturer à chaque étape
Un agent demande un paiement supérieur au seuil de revue. La politique exige une approbation. Les preuves doivent relier cette demande à la revue et au résultat final de l’exécution.
- 1
Capturer la demande
Enregistrez l’agent, l’action proposée, les entrées pertinentes et l’identifiant de la demande.
- 2
Conserver la décision de politique
Enregistrez la version de la politique, le contexte évalué, le résultat et le motif.
- 3
Joindre la décision humaine
Conservez l’identité du réviseur, la décision, la justification, l’heure et le lien avec la demande d’origine.
- 4
Enregistrer ce qui a été exécuté
Reliez l’action autorisée à son résultat dans la même demande. Une demande rejetée doit rester distinguable d’une action terminée.
- 5
Préparer l’artefact de revue
Rassemblez les enregistrements et éléments justificatifs avec un manifeste et des informations d’intégrité.
L’unité utile est la décision complète : demande, règle, réviseur, résultat et preuves justificatives. Lineage Explorer et Evidence Room fournissent les surfaces d’investigation et de revue pour ce travail.
Contrôles et limites de vérification
Un Sealed Evidence Bundle fournit au réviseur un artefact à examiner. La vérification contrôle sa structure cryptographique par rapport au matériel fourni et à la configuration de confiance.
L’authenticité nécessite une vérification de clé hors bande. Les signatures SEK, TEK et du reçu sont toutes contrôlées par rapport aux clés intégrées par le paquet dans keys/jwks.json ; hors ligne, le paquet prouve uniquement sa cohérence interne. Pour démontrer qu’il provient de KLA, épinglez ces clés à un JWKS publié par KLA ou à une empreinte de clé.
L’ancrage Bitcoin OpenTimestamps est fiable hors ligne. La confirmation de sa hauteur de bloc compare la preuve avec la blockchain Bitcoin en direct, et un reçu de calendrier en attente reste en attente jusqu’à une mise à niveau du calendrier.
La preuve de l’ancrage du registre immudb est présente et peut être analysée hors ligne. Vérifier son inclusion par rapport à l’état signé du registre nécessite un contrôle connecté au réseau.
- Signature du manifeste
- Le manifeste est canonisé (RFC 8785 / JCS) et son condensat est recalculé. Le JWS détaché porte des signatures ES256 SEK et TEK valides sur ce condensat, vérifiées avec les clés publiques intégrées au pack dans keys/jwks.json.
- Inclusion de Merkle
- Chaque artefact est re-haché (SHA-256) pour obtenir le digest déclaré par le manifeste, la preuve d’inclusion de chaque artefact atteint la racine scellée et la racine de Merkle recalculée est égale à la valeur du manifeste.
- Signatures de réception
- Chaque chaîne de reçus de gouvernance est vérifiée : la signature ed25519 de chaque reçu est contrôlée avec une clé intégrée au bundle et chaque étape est reliée à la précédente via prevReceiptHash, de la genèse à la dernière.
- Chaîne de hachage du registre
- Chaque enregistrement de registre exporté est re-haché pour obtenir le hachage indiqué et les enregistrements consécutifs sont reliés de bout en bout via previousHash.
- Ancrage OpenTimestamps
- timestamp.ots est analysé selon les règles strictes d’OpenTimestamps et engage le condensat recalculé du manifeste. Lorsque le reçu est attesté par Bitcoin, le vérificateur indique sa hauteur de bloc ; un reçu de calendrier en attente est accepté comme confirmation Bitcoin en attente.
Précédents réglementaires
Ces références décrivent différents contextes de tenue des registres. Utilisez-les pour examiner la question des preuves dans chaque régime et suivez la source pour en comprendre le périmètre.
SOX
Pratiques de tenue des registres
Framework COSO : 17 principes, 87 points d’attention, taux de déficience d’audit de 40% chez les Big 4
MiFID II
Pratiques de tenue des registres
Divergence UTC de 100 microsecondes (HFT), stockage WORM, conservation de 5-7 ans, reconstitution en 72 heures
GDPR
Pratiques de tenue des registres
2FA désormais attendue (amende infligée à l’hôpital Haga), procédures d’accès documentées requises
MDR
Pratiques de tenue des registres
Pistes d’audit IEC 62304, contrôle complet des versions, traçabilité des exigences jusqu’aux tests
Source: Règlement (UE) 2024/1689. Examinez les exigences applicables à votre système avec les personnes responsables de son évaluation juridique et opérationnelle.
Questions et détails
L’Article 12 exige-t-il explicitement l’intégrité cryptographique ?
Non, mais la tendance issue de MiFID II, SOX, GDPR et MDR est sans ambiguïté : un texte fondé sur des principes devient une pratique prescriptive en 2-4 ans. Les auditeurs et les organismes notifiés interpréteront l’« enregistrement automatique » comme une journalisation à preuve de falsification.
Quelles périodes de conservation s’appliquent aux journaux IA ?
Article 12 fixe un minimum de 6 mois pour les journaux automatisés, mais les exigences sectorielles prévalent souvent. Les établissements financiers devraient s’attendre à 5-7 ans. La documentation technique doit être conservée pendant 10 ans après la mise sur le marché du système.
Quand les normes harmonisées seront-elles publiées ?
prEN ISO/IEC 24970 (norme de journalisation) est soumis au vote en tant que projet de norme internationale. prEN 18286 (norme de système de management de la qualité) est entré en enquête publique en octobre 2025. Les normes définitives sont attendues au Q4 2026, mais les attentes des auditeurs se forment déjà.
À quels accès les organismes notifiés auront-ils droit ?
Au titre de l’Annex VII, les organismes notifiés peuvent exiger un accès API complet aux jeux de données d’entraînement, de validation et de test. Ils peuvent effectuer des tests directs si les preuves du fournisseur ne les satisfont pas. Les journaux d’accès aux jeux de données deviendront eux-mêmes des cibles d’audit.
Comment devons-nous rendre un modèle ML auditable ?
Les seuils applicables à une journalisation étendue restent incertains, mais les auditeurs s’attendront probablement au suivi de la version du modèle, aux changements d’hyperparamètres, aux métadonnées des entraînements et à la traçabilité des décisions pour les sorties à haut risque.