Model Cards and System Cards 2026: What Regulators Now Expect by Default

From Research Norm to Regulatory Expectation

Model cards started in 2018 as a researcher-led transparency norm (Mitchell et al.). By 2026 they are an explicit or implicit regulatory expectation under the EU AI Act, NIST AI RMF, ISO 42001, and many sectoral regulations. The frontier providers all publish them; the question is what to put in yours.

This piece covers the 2026 standard for model cards and the rising "system card" — a related artifact for deployed AI applications.

Model Card vs System Card

flowchart LR
    Model[Model Card<br/>describes the model] --> System[System Card<br/>describes the application]
    Model --> Use[Used by deployers and<br/>research community]
    System --> Reg[Used by regulators and<br/>end users]

A model card describes a single model — capabilities, training data summary, evaluations, limitations. A system card describes a deployed AI system that uses one or more models — overall flow, additional safeguards, deployer-side evaluations, intended use.

Frontier providers publish model cards. Deployers publish system cards (or should).

The 2026 Model Card Schema

The de facto schema in 2026 includes:

• Identification: name, version, provider, license
• Architecture: family, parameter count (or range), context length, modalities
• Training data: high-level summary, sources, size, deduplication, filtering
• Training compute: rough FLOPs and dates
• Evaluation results: standard benchmarks, safety evaluations, capability evaluations
• Intended use: supported tasks, deployment contexts
• Known limitations: domains of unreliability, languages with weaker performance
• Safety properties: refusal behaviors, hallucination characterization, jailbreak resistance
• Data privacy: whether/how user data is used in training
• Environmental impact: training and per-inference energy estimates
• Update history: changes from prior versions
• Contact: support and incident channels

A frontier-provider model card runs 30-100 pages in 2026. A fine-tune model card may be 5-20.

The System Card Schema

System cards are newer. The pattern emerging in 2026:

• System purpose: business problem solved, intended users
• Architecture: data flow diagram, models invoked, tools, retrieval sources
• Inputs and outputs: what users provide, what the system returns
• Safeguards: prompt guards, output guards, rate limits, escalation
• Deployer evaluations: outcome metrics, bias evaluation, red-team results
• Human oversight: review processes, escalation triggers, training of operators
• Operating context: regulatory regime, sector, sensitive populations
• Known failure modes: with examples
• Update and deprecation policy: how versions are managed and retired

What Should Be Disclosed (and What Shouldn't)

flowchart TD
    Q1{Information about<br/>safety properties?} -->|Yes| Disc[Disclose]
    Q2{Information about<br/>training data sources?} -->|Yes| Sum[Summarize, not list]
    Q3{Specific weights<br/>or training tricks?} -->|No| Hold[Hold proprietary]
    Q4{Information about<br/>evaluation methodology?} -->|Yes| Disc2[Disclose]

The 2026 norm: disclose anything safety-relevant, summarize anything competitively sensitive but expected (training data sources, evaluation results), hold proprietary the specific implementation details (training tricks, exact weights, secret datasets).

EU AI Act training-data summaries are now standardized to a Commission-provided template. NIST RMF and ISO 42001 do not require specific format but expect coverage.

A Sample Provider's 2026 Approach

Frontier provider model cards in 2026 typically cover:

• 5-10 page executive summary
• 10-30 page evaluation appendix
• 5-10 page safety appendix
• 5-10 page training-data summary
• 2-5 page environmental footprint
• Update and deprecation history

Anthropic, OpenAI, Google, and Meta all publish on this template, with provider-specific extensions.

Open-Weights Model Cards

For open-weights releases (Llama 4, Mistral, Qwen3, DeepSeek V4) the model card is the primary user-facing artifact. The 2026 norm includes:

• Reproducibility information (training-config snippets)
• Recommended use cases
• Recommended deployment safeguards
• License terms front and center
• Intended-use guardrails for downstream fine-tuners

How Often to Update

Model cards should be updated for:

• New version releases (always)
• Major safety regressions or improvements (within reasonable time after detection)
• Significant evaluation method changes
• Material changes in known limitations

System cards should be updated for:

• Major architecture changes (always)
• New tools or new safeguards
• New jurisdictions or user populations
• Discovery of new failure modes

What Regulators Actually Look At

In practice, regulators reading these documents focus on three things:

• Whether intended use matches actual deployment
• Whether the safety evaluations cover the relevant risks
• Whether the operator has a path to fix problems they discover

A clean, well-reasoned model+system card pair satisfies most regulator inquiries before they become formal investigations.

Sources

• "Model cards for model reporting" Mitchell et al. — https://arxiv.org/abs/1810.03993
• OpenAI system cards — https://openai.com/safety
• Anthropic model cards — https://www.anthropic.com
• EU AI Office training-data template — https://digital-strategy.ec.europa.eu
• ISO/IEC 42001 — https://www.iso.org