Construire une matrice AI Act qui résiste à l’examen

La matrice est construite après la qualification du système et du rôle de chaque entité. Une ligne porte sur une seule assertion vérifiable et sur une version identifiée. Elle ne conclut jamais au-delà du périmètre réellement testé.

Applicabilité

Disposition, condition, rôle et date

Contrôle

Objectif, mécanisme, responsable et fréquence

Épreuve

Population, procédure, seuil et résultat

Conclusion

Statut, limite, décision et valideur

Chaque champ répond à une question différente. Les fusionner produit des dossiers impossibles à relire ; les relier permet à un second examinateur de reconstruire la conclusion.

• Source — Article, paragraphe, annexe, texte consolidé et date de consultation.
• Applicabilité — Fait déclencheur, rôle concerné, échéance et justification.
• Résultat attendu — Assertion précise que le dispositif doit satisfaire.
• Contrôle — Mécanisme technique ou organisationnel, propriétaire et fréquence.
• Test — Population, échantillon, procédure, seuil et critère d’échec définis avant l’exécution.
• Preuve — Entrées, résultats bruts, version, provenance, intégrité et limite.
• Décision — Statut de la ligne, action, autorité de décision et condition de réouverture.

Pour un fournisseur, les exigences des articles 8 à 15 et les obligations associées ne se démontrent pas par un document unique. Chaque domaine reçoit ses propres assertions, essais, traces et décisions.

Le déployeur ne reprend pas la matrice du fournisseur. Il doit démontrer ce qu’il maîtrise dans son organisation : configuration, personnes habilitées, données d’entrée, surveillance, suspension, journaux et information lorsque ces obligations s’appliquent.

La preuve n’est pas choisie parce qu’elle est facile à obtenir. Le protocole part de l’assertion et annonce à l’avance ce qui permettra de conclure, d’échouer ou de limiter la portée du résultat.

• Référence — Geler le système, la configuration, les données et la période examinées.
• Assertion — Écrire un résultat observable, sans verbes vagues comme « gérer » ou « assurer » seuls.
• Population — Définir les cas couverts, les exclusions et la stratégie d’échantillonnage.
• Procédure — Décrire les actions, outils, entrées et règles de calcul pour permettre la réexécution.
• Critère — Fixer seuil de réussite, tolérance, criticité et conduite attendue avant le résultat.
• Restitution — Conserver sorties brutes, anomalies, écarts au protocole, conclusion et signataire.

Une capture d’écran ou une politique non exercée peut établir un fait limité ; elle ne démontre pas à elle seule l’efficacité opérationnelle. Le dossier conserve la pièce et le contexte qui autorise — ou interdit — son extrapolation.

Provenance

Auteur, système source et chemin de collecte

Temporalité

Date, période couverte et horodatage

Version

Modèle, code, règles, données et configuration

Intégrité

Original, empreinte ou mécanisme de conservation

Résultat

Données brutes, calcul, exception et observation

Portée

Population couverte, exclusion et limite de conclusion

Le statut qualifie une assertion précise. Il ne transforme pas une ligne réussie en déclaration générale de conformité du système.

Exemple entièrement synthétique : un système à haut risque assiste une décision de recrutement. La documentation affirme que le responsable métier peut ignorer la recommandation et suspendre l’usage.

Le registre reste rattaché à la configuration en service. Il distingue qui opère le contrôle, qui produit la preuve, qui l’examine et qui accepte le risque résiduel.

• Version — Réexaminer après changement de modèle, données, règles, interface ou fournisseur.
• Usage — Réexaminer après changement de finalité, population, décision influencée ou contexte.
• Rôle — Réexaminer après marque, intégration, modification substantielle ou transfert de responsabilité.
• Résultat — Réexaminer après dérive, incident, plainte, dépassement de seuil ou contrôle défaillant.
• Droit — Réexaminer après modification du texte, échéance, ligne directrice ou règle sectorielle.