A model card is a short, structured record of a machine learning model: what it is, what it may and may not be used for, how it was tested, how it performs across groups and conditions, and its known limits. The template below follows Mitchell et al. (2019), adds enterprise and LLM sections, includes a filled example, and maps each section to EU AI Act Annex IV.
Where the format comes from
Margaret Mitchell and eight co-authors proposed model cards at the FAT* conference in January 2019. Their nine sections ask a developer to state the intended use, report results broken down by the factors that matter for that use, such as demographic groups or environmental conditions, and say plainly where the model should not be used. Hugging Face later made model cards the README of every model repository, published an annotated template and a guidebook by Ezi Ozoani, Marissa Gerchick and Margaret Mitchell (2022), and added a YAML metadata header for licence, base model, datasets and evaluation results.
Enterprises need a bit more than a public card. Inside an organisation the card is also the record that a reviewer approved this version, for this purpose, with these tests, and it is the first thing an incident responder opens. ISO/IEC 42001:2023 asks for documentation of AI system design, development and technical details in Annex A.6, and NIST AI RMF MAP 2.1 asks for the tasks the system supports, and the methods used, to be defined. A model card answers both for the model layer.
The model card template
Write one card per model version that reaches users. Sections 1 to 9 follow the original paper; sections 10 to 12 are the enterprise additions. Fields in brackets are placeholders.
Metadata header
---
model_id: [internal ID]
version: [x.y.z]
license: [licence identifier or "proprietary"]
base_model: [identifier, if fine-tuned, adapted or quantised]
datasets: [training and evaluation dataset IDs]
language: [ISO 639-1 codes]
risk_tier: [from the AI governance policy]
inventory_id: [AI inventory reference]
card_owner: [name, role]
last_reviewed: [YYYY-MM-DD]
---Sections 1 to 9: the model
1. MODEL DETAILS
Developed by / supplied by: [team or vendor]
Model date and version: [date] / [x.y.z]; previous: [x.y]
Model type: [classifier, regressor, LLM, embedding model]
Architecture and training approach: [one paragraph]
Base model and licence: [if any]
Paper or design document: [link]
Contact for questions: [name, channel]
2. INTENDED USE
Primary intended uses: [tasks]
Primary intended users: [roles]
Out-of-scope uses: [uses the model must not be relied on for]
3. FACTORS
Relevant factors: [groups, languages, channels, document
types, devices or conditions that change performance]
Evaluation factors: [which of these the tests break out]
4. METRICS
Performance measures: [e.g. precision, recall, F1,
calibration, groundedness]
Decision thresholds: [value and why]
How uncertainty was estimated: [e.g. bootstrap intervals]
5. EVALUATION DATA
Datasets: [name, size, period]
Why chosen: [how they represent production]
Preprocessing: [steps]
6. TRAINING DATA
[Sources, period, size, labelling, known gaps. For a
third-party model, what the supplier discloses.]
7. QUANTITATIVE ANALYSES
Results overall and per evaluation factor, including
intersections where sample sizes allow. [table]
8. ETHICAL CONSIDERATIONS AND RISKS
[Sensitive data used, risks to people, mitigations,
links to risk register IDs]
9. CAVEATS AND RECOMMENDATIONS
[Known failure modes, conditions not tested, advice
for users and integrators]Sections 10 to 12: the deployment
10. DEPLOYMENT AND OVERSIGHT
Where it runs: [environment, region, on-premises or vendor]
Systems it feeds: [applications, decisions, agents]
Human oversight: [who reviews which outputs, and how
they can override or stop the model]
Logging: [what is recorded, retention period]
11. MONITORING AND CHANGE HISTORY
Production metrics and alert thresholds: [ ]
Re-test triggers: [new data, new version, drift alert]
Change log: [date, version, change, test result, approver]
12. APPROVAL
Risk assessment: [reference] Gate passed: [ ] on [date]
Approved by: [system owner], [risk], [security]
Next review: [date]LLM model card: fields to add
A large language model is rarely used bare. What users experience is the model plus a system prompt, retrieval, tools and filters, so an LLM card needs fields that a classifier card does not.
| Field | What to record |
|---|---|
| Base model and revision | Exact identifier and revision or file hash, licence, publisher’s card link |
| Quantisation and serving | Precision (for example 4-bit), runtime, context length actually configured |
| System prompt | Version ID and where the text is stored; never only “latest” |
| Retrieval | Indexes connected, how permissions are applied, refresh schedule |
| Tools | Each tool or connector, its permission, and which actions need approval |
| Generative risk tests | Results against the NIST AI 600-1 risks that apply, such as confabulation, data privacy, information security and harmful bias |
| Security tests | Prompt injection, data leakage and excessive agency, following the OWASP Top 10 for LLM Applications 2025 |
| Refusal and escalation | What the model declines and where it hands over to a person |
| Disclosure | How users are told they are dealing with AI, if Article 50 applies |
Where you deploy someone else’s open-weight model, copy the facts from the publisher’s card and test the claims that matter for your use rather than restating them.
Model card example
Fictional example. The organisation, model and every figure below are invented to show how a completed card reads. They describe no real system or result.
MODEL CARD: Claims email triage classifier (fictional)
Organisation: Example Mutual, a fictional insurer
1. MODEL DETAILS
Developed by: Claims analytics team. Version 2.1.0,
approved 2026-09-14; previous 2.0.3.
Type: multi-class text classifier, gradient-boosted trees
on word and character features; trained in-house.
Contact: claims-models@[internal]
2. INTENDED USE
Routes incoming claims emails to one of 9 queues
(new claim, document upload, complaint, fraud tip, ...).
Users: claims intake staff, who see the suggested queue.
Out of scope: deciding cover, liability or payment;
assessing fraud; any message not written by a customer.
3. FACTORS
Language (English, German, Turkish), channel (web form,
email, broker portal), message length.
4. METRICS
Macro F1 per queue and per factor; complaint recall
reported separately because a missed complaint has a
regulatory deadline. Threshold: suggestions below 0.70
confidence go to the manual queue.
5. EVALUATION DATA
6,000 messages from Jan-Jun 2026, held out by month,
labelled twice by senior handlers.
6. TRAINING DATA
48,000 messages from 2023-2025, names and policy numbers
masked before training. Turkish messages are 4% of data.
7. QUANTITATIVE ANALYSES
Overall macro F1 0.91. English 0.93, German 0.90,
Turkish 0.82. Complaint recall 0.96 overall, 0.88 for
Turkish. Broker portal 0.94, email 0.89.
8. ETHICAL CONSIDERATIONS AND RISKS
Lower accuracy for Turkish-language customers could delay
their complaints (register R-31). Mitigation: all Turkish
messages flagged as possible complaints go to a person.
9. CAVEATS AND RECOMMENDATIONS
Not tested on messages longer than 2,000 words or on
attachments. Re-test if queue definitions change.
10. DEPLOYMENT AND OVERSIGHT
Runs in the insurer's data centre; output is a suggestion
only. Intake staff can reassign any message; reassignment
rate is logged per queue. Logs kept 12 months.
11. MONITORING AND CHANGE HISTORY
Weekly F1 on a 300-message sample; alert below 0.87.
2.1.0: added German training data; German F1 0.84 -> 0.90.
12. APPROVAL
Risk assessment RA-2026-022, Tier 2. Approved by claims
operations director, model risk, security. Review 2027-03.The card shows the point of disaggregation: an overall score of 0.91 hides the lower result for Turkish, which the card turns into a register entry and a control.
EU AI Act Annex IV cross-walk
Article 11 requires providers of high-risk AI systems to draw up technical documentation containing at least the elements in Annex IV before the system is placed on the market or put into service. The Digital Omnibus on AI, Regulation (EU) 2026/1744, kept Annex IV and let SMEs and small mid-cap enterprises supply its elements in a simplified form that the Commission is to publish. It also made the post-market monitoring plan part of the Annex IV documentation and asked the Commission for guidance and a template on that plan by 2 September 2027. For Annex III systems these duties apply from 2 December 2027.
| Annex IV point | What it asks for | Model card section | Still needed elsewhere |
|---|---|---|---|
| 1(a) to 1(h) | General description: purpose, provider, version, interactions, hardware, forms of release, user interface, instructions for use | 1, 2, 10 | Instructions for use for deployers; product photos where relevant |
| 2(a) | Development methods, use of pre-trained systems or third-party tools | 1, 6 | Supplier documentation |
| 2(b) | Design specifications, logic, key choices, what it optimises for, expected output quality, trade-offs | 1, 4, 9 | Design document |
| 2(c) | System architecture; compute used to develop, train, test and validate | 1, 10 | Architecture diagram |
| 2(d) | Data requirements, datasheets, provenance, selection, labelling, cleaning | 5, 6 | Datasheets for each dataset |
| 2(e) | Assessment of human oversight measures under Article 14 | 10 | Oversight design and training records |
| 2(f) | Pre-determined changes and how compliance continues | 11 | Change control procedure |
| 2(g) | Validation and testing procedures, metrics, discriminatory impacts, dated and signed test logs | 4, 5, 7 | Signed test reports |
| 2(h) | Cybersecurity measures | LLM security fields | Security test reports |
| 3 | Capabilities, limitations, accuracy for specific groups, foreseeable risks, input specifications | 3, 7, 8, 9 | None if the card is complete |
| 4 | Why the performance metrics are appropriate | 4 | None |
| 5 | Risk management system under Article 9 | 8 (links) | Risk management file and register |
| 6 | Relevant changes over the lifecycle | 11 | None |
| 7 | Harmonised standards or other solutions applied | None | Standards list |
| 8 | Copy of the EU declaration of conformity | None | Declaration under Article 47 |
| 9 | Post-market performance evaluation and monitoring plan | 11 | Post-market monitoring plan |
Not sure whether a system is high-risk at all? Run it through the EU AI Act compliance checker first; most internal models are not, and for them the card is good practice rather than a legal document.
How to fill it in, and who owns it
Start the card at Gate 1 with sections 1 and 2, before anyone trains or buys anything, and finish it at Gate 2 with the test results. The technical owner keeps it current, the system owner approves it, and the risk function checks sections 7 and 8 against the risk assessment for the system. Every risk named in section 8 should have an ID in the AI risk register, so the two documents never disagree.
Store cards next to the model artefacts, in version control, and treat a model release without an updated card as incomplete. Production metrics in section 11 can come straight from your model monitoring and drift detection setup. The template pack contains an editable DOCX of this card, with the LLM fields and the Annex IV table, next to the other five governance templates.
The AI model documentation agent drafts model cards and Annex IV technical documentation from a structured intake, so the team reviews a draft instead of starting from an empty page. Teams that have never documented a model can check where they stand on evaluation, versioning and human review with the AI readiness assessment.
How VDF AI fits
Several LLM fields are easier to fill truthfully when the platform records them. VDF AI runs on servers you control and logs, for each execution, the model and version used, the retrieved sources, tool calls and the response, which gives sections 10 and 11 real data rather than intentions.
VDF AI Router keeps a model registry and an approved-model list per workload, so the base model named on the card is the one actually serving requests, and agent configurations are versioned with rollback. Agents and networks can be evaluated against golden datasets before release, which supplies the test results for sections 4 and 7. Writing and approving the card remains your team’s job.
Sources
- Mitchell et al., Model Cards for Model Reporting, FAT* 2019
- Hugging Face, Model Cards documentation
- Hugging Face, Annotated Model Card Template
- AI Act, Regulation (EU) 2024/1689, on EUR-Lex
- Digital Omnibus on AI, Regulation (EU) 2026/1744
- NIST AI 600-1, Generative AI Profile
- NIST AI 100-1, AI RMF 1.0
- ISO/IEC 42001:2023, AI management systems
- OWASP Top 10 for LLM Applications 2025