Definition: Model Card
A model card is a structured document that discloses an AI model’s intended use, training data, performance metrics, and known limitations, giving downstream users and regulators a standardized basis for evaluating the model before deployment.
Core characteristics of model cards
Model cards follow a consistent template so different models can be compared side by side, regardless of which vendor built them. They typically accompany the model itself, whether published on a hub like Hugging Face or delivered as part of a vendor’s technical documentation package.
- Intended use cases and explicitly out-of-scope uses
- Training data summary and provenance
- Performance metrics across evaluation conditions
- Known limitations, biases, and ethical considerations
Model Card vs. AI Bill of Materials
A model card documents a single model: its behavior, training data, and limitations. An AI Bill of Materials inventories every component, dataset, and third-party dependency inside a full AI system, often spanning several models. A company deploying a customer service agent might reference the model card of the underlying language model while maintaining a separate AI-BOM listing every plugin and data source the whole system depends on. Model cards inform model selection and safe use, AI-BOMs support supply chain security and incident response.
Importance of model cards in enterprise AI
Model cards matter because enterprises increasingly select and combine third-party models rather than training their own, making documented behavior the only practical way to assess fit and risk before integration. Gartner projects spending on AI governance platforms, which rely heavily on structured model documentation, to reach 492 million dollars in 2026 and surpass 1 billion by 2030.
Methods and procedures for model cards
Producing and consuming model cards follows established patterns that vary by regulatory context and deployment stage.
EU AI Act Article 53 documentation
Under the EU AI Act, providers of general-purpose AI models must prepare technical documentation matching Annex XI and share a summary with downstream integrators matching Annex XII. These duties became applicable on August 2, 2025, and the AI Office gained enforcement and fine powers on August 2, 2026.
- Model architecture and training methodology
- Compute usage and training data summary
- Known capabilities, limitations, and evaluation results
Voluntary transparency reporting
Beyond regulatory duty, many providers publish model cards voluntarily in the format popularized by Hugging Face, covering intended use, evaluation results, and ethical considerations. This practice predates the EU AI Act and originated in a 2019 Google research paper proposing standardized reporting to reduce misuse of models in contexts they were never suited for.
Vendor evaluation workflow
Procurement teams request model cards during vendor selection to compare capabilities, licensing terms, and data provenance before signing. Missing or vague documentation is a red flag, particularly for models touching regulated data or feeding into a foundation model-based application stack.
Important KPIs for model cards
Organizations that formalize model documentation track a mix of coverage, quality, and process metrics.
Documentation coverage metrics
- Models with a current model card: 100% target for production systems
- Required fields completed per card: >90% of Annex XI/XII fields
- Time to update after a model change: under 5 business days
- Cards reviewed by legal or compliance before deployment: 100%
Strategic governance metrics
Beyond coverage, mature organizations measure how documentation shortens vendor evaluation time and audit preparation effort. Bitkom’s 2026 AI study found that 85% of German SMEs have no documented AI inventory at all, meaning most Mittelstand companies cannot currently produce a model card on demand.
Quality and accuracy metrics
A well-maintained model card should be revised whenever the underlying model is retrained or fine-tuned, not left as a one-time launch artifact. Reviewers typically check that stated limitations match observed production behavior, since a card that understates known failure modes creates legal exposure rather than reducing it.
Risk factors and controls for model cards
Incomplete or outdated model documentation creates specific risks that compliance and procurement teams must manage.
Incomplete or stale documentation
A model card written at launch and never revised no longer reflects a model’s actual behavior after fine-tuning, retraining, or a provider’s silent version update.
- Undisclosed changes to training data or architecture
- Performance claims that no longer match production behavior
- Missing information on known failure modes
Vendor transparency gaps
Not every AI vendor discloses training data sources, licensing terms, or evaluation methodology in comparable detail, which makes side-by-side comparison hard during procurement. Open-source models carry a partial exemption from EU AI Act documentation duties unless they present systemic risk, so buyers cannot assume every open model discloses as much as a commercial one.
Regulatory non-compliance
Providers of general-purpose AI models that fail to produce Article 53-compliant documentation face fines once the AI Office’s enforcement powers are active. Deployers who integrate an undocumented model into a high-risk AI system inherit part of that exposure, since they cannot demonstrate AI governance over a component nobody can fully describe.
Practical example
A 90-employee industrial automation supplier in Baden-Württemberg was evaluating a third-party AI model to draft quality inspection reports before rolling it out to production. Before signing, the compliance team requested the vendor’s model card and found no error rate disclosed for German technical terminology. The vendor delivered an updated card within two weeks showing a 6% error rate on German text versus 2% on English, prompting a mandatory human review step for non-English outputs. The half-day review prevented an error-prone rollout that would have needed costly rework later.
- Structured comparison of vendor capabilities before signing
- Documented basis for the mandatory human review policy
- Reusable evidence for the company’s own EU AI Act deployer file
- Faster procurement decisions with less back-and-forth over email
Current developments and effects
Model card practices are converging with regulatory requirements as the EU AI Act’s GPAI provisions take full effect.
Regulatory convergence
The AI Office’s guidelines and the GPAI Code of Practice are pushing voluntary templates like Hugging Face’s toward alignment with Annex XI and XII. This reduces the effort of maintaining separate documentation for open releases and EU filings.
- AI Office template for training data summaries
- Growing overlap between voluntary and mandatory disclosure fields
- Downstream deployers increasingly requesting cards as contract exhibits
Automated documentation tooling
Vendors are building tools that auto-generate draft model cards from training logs and evaluation runs, cutting the manual burden that once discouraged smaller AI labs from publishing complete documentation. This lowers the barrier for smaller providers to meet regulatory expectations.
Buyer-side scrutiny increases
As the August 2026 enforcement deadline approaches, German Mittelstand procurement teams are asking for model cards earlier in the sales process rather than after signature. This mirrors how data processing agreements became a standard early request once GDPR enforcement began.
Conclusion
Model cards turn an AI model’s behavior from a black box into a document a compliance officer, developer, or auditor can actually read. As EU AI Act enforcement activates and Mittelstand companies scale their AI vendor relationships, the ability to request, review, and act on this documentation becomes a basic procurement competency rather than a specialist task. Companies that build this habit now avoid scrambling when a customer, auditor, or works council asks for evidence later. The direction is clear: undocumented models will become harder to sell into regulated European markets.
Frequently Asked Questions
What is a model card?
A model card is a structured document that describes an AI model’s intended use, training data, performance across evaluation conditions, and known limitations. It gives anyone integrating or auditing the model a standardized reference instead of relying on marketing claims.
Is a model card legally required?
Yes, for providers of general-purpose AI models under the EU AI Act. Article 53 requires technical documentation matching Annex XI and a downstream summary matching Annex XII, obligations that became applicable on August 2, 2025.
Does a company with 50 employees need to worry about model cards?
If your company only uses AI models built by others, you are a deployer rather than a provider, so the direct documentation duty sits with your vendor. You still benefit from requesting the model card, since it feeds your own EU AI Act deployer file and DSGVO risk assessments.
What does introducing model card review cost?
There is no license fee since it is a documentation practice rather than a tool, just staff time to request, review, and file vendor cards during procurement. Most mid-sized companies fold this into an existing vendor onboarding or AI governance checklist rather than hiring dedicated staff.
How long does it take to add model card checks to procurement?
Adding a request-and-review step to an existing vendor evaluation process typically takes two to four weeks, mainly to agree which fields are mandatory and who signs off. Retrofitting the practice across existing AI vendor contracts takes longer, often two to three months depending on vendor count.
Is there funding available for Mittelstand companies building AI documentation processes?
German digitalization funding programs occasionally cover consulting costs for EU AI Act readiness, including documentation processes, though coverage varies by Bundesland and program. Companies should check current KfW and regional Digitalisierungsförderung programs before assuming self-funding is the only option.
