Writing a model card an auditor will accept

What a reviewer is actually looking for

Not accuracy. A reviewer wants evidence that someone thought about how this could go wrong, wrote it down before deployment, and arranged for a human to catch it when it does.

The template we use

Intended purpose. One paragraph, in business language, plus the uses explicitly out of scope. The out-of-scope list matters more than the purpose.

Training data. Where it came from, the period it covers, known gaps, and any population the data under-represents.

Evaluation. Method, dataset, results, and how often it is re-run. Include the metric that looked bad, not only the one that looked good.

Limitations. Conditions under which the model is unreliable. Written in sentences someone outside the team can act on.

Human oversight. Who can override, how, and where the override is logged.

The three sections people leave out

Intended purpose, limitations and oversight. All three are judgement calls, which is why they get postponed and why reviewers ask about them first.

Ask whoever signs off on risk to write the limitations section themselves. It takes an hour, and it surfaces disagreements long before an auditor does.

Keep it versioned with the model

models/credit_scoring/
├── model.py
├── evaluate.py
├── MODEL_CARD.md
└── tests/

A card reviewed in the same pull request as the code stays current. One in a shared drive describes a model that no longer exists.

A useful test

Hand the card to a colleague outside the team and ask what the model should not be used for. If they cannot tell you, it is not finished.