Model Card and System Card Template for AI Assurance

Auditors, customers and regulators increasingly ask for documentation of an AI model and the system built around it, and most teams have only a README and a slide deck. A model card describes one trained model: what it is for, how it was trained and evaluated, and where it fails. A system card describes the deployed AI system: the model plus prompts, tools, data connections, identities, safeguards and human oversight. This template gives you both, as numbered sections you can copy into a repository or GRC tool, with a cross-reference to the EU AI Act Annex IV and Annex XI documentation points and to the machine-readable formats (Hugging Face metadata and CycloneDX modelCard). It is for ML engineers, AI governance leads and security assurance teams.

How to use this template

Pick the card type: complete sections 1 to 7 and 10 for a model card. Complete all sections for a system card. A system that uses a third-party model links to the supplier's model card rather than copying it.
Replace placeholders: text in square brackets, such as [Organisation], [System name] and [AI governance lead], is yours to fill. Write "Not applicable" with a reason rather than deleting a field, so reviewers can see it was considered.
Keep it versioned: store the card alongside the model or system configuration, ideally as Markdown in the same repository, so every release has a matching card.
"Must" and "should": "must" marks fields your assurance process requires; "should" marks recommended fields. Adjust to your policy.
Link, do not duplicate: point to the risk assessment, test reports and AI register entry instead of pasting them. See the AI Register and AI Inventory Template.

1. Document control

Field	Entry
Card type	[Model card / System card]
Name and identifier	[Model or system name], [AI register ID]
Version of model or system described	[Version, commit or release tag]; relation to previous versions
Card version and date	[1.0], [date]
Accountable owner	[Named person and role]
Provider / deployer role	[Organisation] acts as [provider / deployer / both] for this system
Classification and audience	[Internal / Customer-shareable / Public]; redactions applied: [list]
Approvals	[AI governance lead], [Security lead], [Legal / Privacy], dates

2. Overview and intended purpose

Summary: [Two or three sentences on what the model or system does and for whom.]
Intended purpose: [The specific task, the context and conditions of use, and the users or affected persons.]
Risk classification: [Internal risk tier]; EU AI Act category, if applicable: [prohibited check done / high-risk under Annex III point X / transparency obligations / minimal]. See the EU AI Act High-Risk AI Systems Guide.
Form of release: [Internal API / embedded in product / downloadable weights / SaaS feature]; hardware or runtime requirements.

3. Uses and out-of-scope uses

Direct use: [Supported uses without further adaptation.]
Downstream use: [Fine-tuning or integration into other systems that [Organisation] supports.]
Out-of-scope and prohibited use: [Uses that are unsupported or forbidden, including any acceptable use policy terms.] Out-of-scope use must be stated explicitly; silence is read as permission.
User and deployer instructions: [Link to instructions for use, including how outputs should be interpreted.]

4. Model details and provenance

Field	Entry
Developer and supplier	[Organisation or third party]; supplier model card link if third-party
Model type and architecture	[e.g. decoder-only transformer, gradient-boosted trees]; parameter count where known
Base model and relation	[Base model ID]; relation: [fine-tune / adapter / merge / quantised]
Input and output modalities	[Text, image, audio, tabular]; formats and limits
Licence	[SPDX identifier or licence link]
Artefact integrity	[SHA-256 hash or signature of weights]; registry location; signing identity. See the Model Signing Guide
Dependencies	[Frameworks, tokenisers, libraries]; link to AI-BOM. See the AI Supply Chain and AI-BOM Guide
Compute and energy	[Training compute, training time, estimated energy] where known or required

5. Training and evaluation data

Data sources: [Datasets with identifiers, origin, and how they were acquired: licensed, collected, synthetic, scraped.]
Preparation: [Selection, labelling, cleaning and filtering steps, including removal of unsuitable sources.]
Personal and sensitive data: [Categories present, lawful basis reference, minimisation applied, link to DPIA.]
Bias checks: [How representativeness and identifiable biases were examined.]
Data integrity: [Dataset hashes or versions, who can write to training stores, and how poisoning risk is controlled.]
Evaluation data: [Held-out sets, how they differ from training data, and leakage checks.]

6. Evaluation and testing results

Test	Method and dataset	Metric	Result	Threshold	Date and signed off by
Task performance	[Benchmark or internal set]	[Accuracy, F1, error rate]	[ ]	[ ]	[ ]
Performance by group	[Groups or factors tested]	[Metric per group]	[ ]	[Maximum gap]	[ ]
Robustness	[Perturbation or adversarial set]	[Degradation]	[ ]	[ ]	[ ]
Prompt injection and jailbreak (LLM systems)	[Red team or tool, scope]	[Attack success rate]	[ ]	[ ]	[ ]
Data leakage	[Extraction and memorisation probes]	[Leak rate]	[ ]	[ ]	[ ]
Tool and agent misuse (system card)	[Scenarios attempting unauthorised actions]	[Blocked rate]	[ ]	[ ]	[ ]

Record test logs with dates and sign-off; regulators and auditors look for evidence that tests ran on the version described, not an earlier one. See the AI Red Teaming Guide.

7. Risks, limitations and safeguards

Known limitations: [Conditions where performance drops: languages, input types, edge cases.]
Foreseeable misuse and unintended outcomes: [Risks to health, safety, fundamental rights, security and the organisation.]
Security threats considered: [Poisoning, evasion, extraction, prompt injection, supply chain]; link to threat model.
Safeguards: [Filters, guardrails, rate limits, output checks, approval steps], with the residual risk accepted and by whom.
Recommendations for deployers: [What a user of this model or system must do to stay within safe operation.]

8. System architecture, integrations and identities

System cards only. This is the section most often missing, and the one security reviewers need most.

Component	Description	Identity used	Permissions	Owner
Model endpoint	[Provider, model version, region]	[API key / workload identity]	[Scope]	[ ]
System prompt and configuration	[Location, version control]	[Who can change it]	[ ]	[ ]
Retrieval sources	[Indexes, document stores]	[Service account]	[Read scope]	[ ]
Tools, plugins and MCP servers	[Each tool and what it can do]	[OAuth client, token, service account]	[Actions allowed]	[ ]
Memory and logs	[Stores, retention]	[ ]	[ ]	[ ]

Delegation model: [Does the system act with its own identity, on behalf of the user, or both? How is the user context passed?]
Credential handling: [Where secrets are stored, rotation period, whether credentials are short-lived.] See the Agentic AI Identity Guide.
High-impact actions: [Actions requiring human approval.]

9. Human oversight and operation

Oversight measures: [Who reviews outputs or approves actions, how they can override or stop the system, and what training they receive.]
Monitoring: [Metrics, drift checks, logging of prompts, tool calls and decisions, retention period.]
Incident handling: [How issues are reported, the contact, and the link to the AI incident procedure.] See the AI Incident Reporting Guide.
Post-market or post-deployment review: [Review frequency and triggers.]
Decommissioning: [How the system is retired, credentials revoked and data disposed of.]

10. Change log and review

Card version	Date	Model or system version	Change	Re-tested?	Approved by
[1.0]	[ ]	[ ]	[Initial card]	[Yes / No]	[ ]

The card must be reviewed on every release that changes the model, system prompt, tools or data sources, and at least [annually].

Implementation guidance

Model card or system card?

Question	Model card	System card
What it describes	One trained model artefact	The deployed system: model, prompts, tools, data, identities, oversight
Who writes it	Model developer or provider	System owner with security and governance input
Main readers	Integrators, downstream developers, model risk	Auditors, customers, security reviewers, regulators
Changes when	The weights or training data change	Any component, prompt, tool or permission changes
Machine-readable form	Hugging Face YAML metadata; CycloneDX `modelCard`	AI-BOM plus the card in Markdown

Cross-reference to EU AI Act documentation

For high-risk AI systems, Article 11(1) and Annex IV of Regulation (EU) 2024/1689 set the content of technical documentation. For general-purpose AI models, Annex XI sets the content. A well-kept card covers much of it, but it is not the full technical file.

Template section	Annex IV (high-risk systems)	Annex XI (GPAI models)
2. Overview and intended purpose	Point 1(a) intended purpose, provider, version; 1(d) forms of release; 1(e) hardware	Section 1, point 1: intended tasks, release date and distribution
3. Uses	Point 1(h) instructions for use	Section 1, point 1: acceptable use policies
4. Model details	Point 2(a) development methods including third-party pre-trained tools; 2(b) design specifications	Section 1, points 1 and 2: architecture, parameters, modalities, licence, compute, energy
5. Data	Point 2(d) data requirements and datasheets	Section 1, point 2: training, testing and validation data
6. Evaluation	Point 2(g) validation and testing with dated, signed logs; point 4 appropriateness of metrics	Section 2: evaluation strategies, adversarial testing (systemic-risk models)
7. Risks and safeguards	Point 3 capabilities, limitations, foreseeable risks; point 5 risk management system (Article 9); point 2(h) cybersecurity measures	n/a
8. Architecture and identities	Points 1(b) interaction with other systems; 2(c) system architecture	Section 2, point 3: system architecture (systemic-risk models)
9. Oversight and operation	Point 2(e) human oversight (Article 14); point 9 post-market monitoring (Article 72)	n/a
10. Change log	Point 6 lifecycle changes	n/a

Annex IV also requires the list of harmonised standards applied (point 7) and a copy of the EU declaration of conformity (point 8); keep those in the technical file, not the card. See the EU AI Act Provider vs Deployer Obligations Guide and the EU General-Purpose AI (GPAI) Code of Practice Guide.

Rolling it out

Start with the riskiest systems: pick the three highest-tier entries in the AI register and write system cards for them first.
Request supplier model cards: add a model card or equivalent documentation requirement to AI procurement and vendor questionnaires. See the AI Vendor Security Questionnaire Template.
Automate what you can: generate sections 4 and 5 from the training pipeline and registry metadata, and section 8 from infrastructure-as-code and identity inventories, so cards do not drift.
Gate releases: make an up-to-date card a release criterion in the deployment pipeline, starting in warning mode before blocking.
Prepare a shareable version: derive a redacted card for customers that removes internal hostnames, identity names and detailed safeguards an attacker could use.

Measuring it

Card coverage: percentage of AI register entries above the lowest risk tier with a current card.
Freshness: percentage of cards whose model or system version matches production.
Identity completeness: percentage of system cards whose section 8 names every credential and owner.
Supplier documentation rate: percentage of third-party models with a supplier model card on file.

Common mistakes

Cards written once at launch and never updated after prompt, tool or model changes.
Model card used as a system card: the model looks safe, but the risk sits in the tools and permissions the system adds.
Benchmark scores without context: results with no dataset, date or threshold cannot support an assurance decision.
Publishing internal detail: a public card that lists service account names, endpoints or bypassable filters helps attackers.

Model Card and System Card Template: fields for assurance and EU AI Act documentation