Dossier technique de l’AI Act : le tenir à jour à chaque version

Une version passe, la suivante est bloquée

EN BREF Le même build livre une version et bloque la suivante, parce qu’une section humaine a dépassé sa date de revue.

Les valeurs ci-dessous sont fictives. La règle vient du manifesteManifeste Un petit fichier de configuration qui énumère les blocs du dossier technique et indique, pour chacun, qui peut l’écrire. Voir le glossaire : un bloc humain qui dépasse sa fenêtre de revue fait échouer la version, comme un test en échec.

OBJET OBTENU

Un contrôle réussi prouve les délais, pas le fond

Le contrôle vérifie que chaque revue a eu lieu à temps, pas que l’argument tient. Quelqu’un doit encore le lire, et un avocat dit si le règlement s’applique.

?Dans la section suivante : Alors, où et quand ce contrôle tourne-t-il ?

EN BREF Placez le générateur à côté des tests : chaque version régénère le dossier et le compare au précédent.

Dans ce modèle, les tests et le générateur tournent dans la CICI Intégration continue : la chaîne automatique qui construit et teste chaque changement. Voir le glossaire à chaque changement, sur le même tag de versionTag de version Une étiquette dans le gestionnaire de versions, comme 1.4.0, qui identifie le code et les réglages versionnés d’une livraison. Voir le glossaire. Une étape de build peut aider à maintenir les faits à jour. Elle ne remplit pas seule l’obligation documentaire : il faut encore vérifier que le dossier est complet et que les sections humaines ont été relues.

EN CLAIR

Le dossier est reconstruit avec le code. Une section humaine que personne n’a reconfirmée arrête la version.

Commencez modestement et suivez le coût d’entretien : extraction, preuves externes et sections relues prennent du temps. Un dossier produit reste une image du système. Il est utile quand ses sources, sa version et son historique de revue sont vérifiables.

Les chiffres d’évals du dossier viennent de la même exécution que la suite d’évals qui décide si un agent part en production. Cette exécution donne à la fois le verdict de lancement et les résultats d’évals du dossier.

# annex-iv.yaml: the technical file as a build artifact (illustrative values)
release_tag: reconciliation-agent@1.4.0
blocks:
  - { id: system_description,        point: 1, source: generated }
  - { id: build_and_architecture,    point: 2, source: generated }
  - { id: design_rationale,          point: 2, source: human, owner: tech-lead,  review_every_days: 90 }
  - { id: monitoring_and_control,    point: 3, source: generated }
  - { id: metrics_rationale,         point: 4, source: human, owner: risk-owner, review_every_days: 90 }
  - { id: risk_management,           point: 5, source: human, owner: risk-owner, review_every_days: 90 }
  - { id: lifecycle_changes,         point: 6, source: generated }
  - { id: standards_applied,         point: 7, source: human, owner: tech-lead,  review_every_days: 180 }
  - { id: declaration_of_conformity, point: 8, source: human, owner: compliance }
  - { id: post_market_evaluation,    point: 9, source: human, owner: risk-owner, review_every_days: 90 }  # incl. Art. 72(3) plan
gate:
  block_release_if:
    - a human block is past its review_every_days
    - a generated block cannot be read at release_tag
    - release_tag is missing