Keeping Documentation Updated

An Annex IV file that describes last year's model is worse than none — it's evidence you *stopped* paying attention. The Act expects documentation to track the system through its lifecycle.

The trigger: substantial modification

Re-visit classification and documentation whenever the system changes in a way that affects its risk or behaviour:

• swapping or retraining the model on materially different data,
• new user groups or a new purpose (internal tool → customer-facing),
• new input data sources,
• changed decision thresholds or automation level (human-in-the-loop removed?).

Any of these can change the classification itself — re-run the risk assessment first, then update the affected document sections.

A cadence that works

• On every substantial modification — update immediately, before deployment where feasible.
• Quarterly — a 30-minute review: does the documentation still describe reality? Re-run a bias report on fresh data.
• At the enforcement deadline and annually after — full review of the file per system.

What the platform does to help

• Generated documents record their creation date and version; regenerating a section keeps the rest intact.
• The audit log records compliance activity, so "when did we last review this?" has an answer.
• Monitoring alerts (drift, fairness) tell you *when* reality has moved — treat every acknowledged alert as a documentation-review trigger.