AI Act Technical File: Keeping It Current at Every Release

One release ships, the next is blocked

IN SHORT The same build ships one release and blocks the next, because one person-owned section went past its review date.

The values below are invented. The rule comes from the manifestManifest A small config file that lists the blocks of the technical file and says, for each one, who may write it. See the glossary: a person-owned block past its review window fails the release, the way a broken test does.

ITEM GET

A passed gate proves timing, not truth

The gate checks that each review happened in time, not that the argument holds. Someone still has to read it, and a lawyer decides whether the Act applies.

?Coming up next: So where and when does this check run?

IN SHORT Put the generator next to the tests, so every release regenerates the file and compares it with the last one.

In this design, the tests and the generator run in CICI Continuous integration: the automated pipeline that builds and tests every change. See the glossary on every change, against the same release tagRelease tag A label in version control, like 1.4.0, that marks the code and versioned settings of one release. See the glossary. A build step can help keep the facts current. It doesn’t meet the documentation duty on its own: you still check that the file is complete and that the human parts were reviewed.

IN PLAIN WORDS

The file is rebuilt with the code. A human section nobody re-confirmed stops the release.

Start small and track the upkeep: pulling facts out, outside evidence and reviewed parts all take time. A rendered file is still only a picture of the system. It helps when you can check its sources, its release and its review history.

The eval numbers in the generated half come from the same run as the eval suite that gates a release: that run gives both the release verdict and the file’s eval results.

# 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