What the EU AI Act actually asks of your model documentation

The Act is a product safety law

It does not ask whether your model is accurate. It asks whether you can show, in writing, that you understood the risk before deploying, and that a person can intervene afterwards.

That changes who owns the work. This documentation is not a data science deliverable. It is a joint artefact between the team that builds the model and the function that accepts the risk.

Start by tiering, not writing

Most internal analytics is minimal risk and needs nothing beyond your normal standards. The obligations concentrate on a narrow set of uses, and knowing which of yours fall inside that set is most of the work.

• Does the output affect access to a service, employment, credit or care?
• Can a human overrule it in practice, not just on paper?
• Would a reasonable person be surprised a model was involved?

Two yes answers and treat the system as in scope until someone qualified says otherwise.

If a model decides something about a person, assume you will have to explain it to someone who was not in the room.

What a model card has to cover

Section	Usually missing?
Intended purpose and out-of-scope uses	Yes
Training data provenance	Partly
Evaluation method and results	No
Known limitations	Yes
Human oversight arrangements	Yes

The three marked yes are judgement calls rather than measurements, which is exactly why they cannot be generated automatically.

Keep it next to the code

Store the card in the model’s folder so it moves through the same review. A document in a shared drive is out of date within one retraining cycle.

models/churn_propensity/
├── model.py
├── evaluate.py
├── MODEL_CARD.md   # same pull request
└── tests/

Where to start this quarter

Build the inventory. You cannot tier what you have not listed, and almost every organisation we work with finds models in production that the central team did not know about.