What Annex IV actually asks of your model documentation

First, the uncomfortable part: you are probably in scope

Most teams read the high-risk annexes, decide their assistant is not a credit-scoring engine, and move on. That reading is too narrow. Scope follows the use, not the technology: the same retrieval assistant is out of scope in a marketing team and in scope the moment it drafts a decision that affects access to a service, employment, or credit.

The practical test we apply on day one is simpler than the legal text. If a human downstream would find it difficult to overturn the system output, or if nobody can name the person who owns the decision, treat it as in scope and document accordingly. The cost of over-documenting is a week. The cost of under-documenting is a launch freeze.

The nine artefacts, and who has to write them

Annex IV asks for technical documentation sufficient for an authority to assess conformity. In practice that resolves to nine artefacts. Seven of them are derivable from a well-instrumented platform. Two are genuinely human work, and pretending otherwise is where programmes lose a quarter.

Generate what you can, and generate it from the runtime

The failure mode we see most often is a documentation set maintained beside the system rather than by it. A Confluence page describing the retrieval strategy is accurate on the day it is written and misleading within two sprints. An authority does not want a description of your intent; they want evidence of what actually ran.

Anchor every derivable artefact to the runtime. Policy version, model identifier, evaluation suite version and data classification should be recorded on the call, not asserted in a document. When the record is a projection of production state, drift is impossible by construction, and the quarterly documentation exercise becomes an export.

The two artefacts you cannot automate

The system description and the risk management record are judgement documents. They require someone to state what the system is for, what could go wrong for a real person, and what the organisation has decided is acceptable. No amount of telemetry produces that sentence.

Give both a named owner and a review cadence tied to change, not to the calendar. In our engagements the trigger is any change to purpose, population or authority: if the system starts serving a new group, making a more consequential call, or acting with less human review, the risk record is reopened that week.

The order that stops the work doubling

Sequence matters more than effort. Teams that document in the wrong order write everything twice, because the risk record depends on the design specification and the evaluation evidence depends on both. A workable order looks like this.

What to do this month

Run an inventory before you run a programme. Most organisations cannot yet answer how many AI-assisted workflows are in production, on which models, touching which data classes. Until that list exists, any documentation effort is guesswork about its own scope.

Then pick the single most consequential system on the list and take it all the way through the nine artefacts. One complete example teaches your organisation more than nine partial ones, and it gives your review board something concrete to argue with.

Where this leaves you