What are the AI model card requirements in 2027?

What a model card is and why it stopped being optional

A model card is a structured disclosure document that travels with a trained model the way a nutrition label travels with food. The format originated in a 2019 research paper from Google researchers ("Model Cards for Model Reporting," Mitchell et al.), which proposed that every released model ship with a short standardized document covering what it was trained on, what it is meant to do, how well it performs, and where it breaks. For several years that was a courtesy — a nice-to-have README section on Hugging Face that many teams filled out with two sentences and a benchmark screenshot.

What changed is that three separate constituencies started asking for the same artifact, and one of them acquired the power to fine you.

The first is the regulator. The EU AI Act, which entered into force in August 2024 with obligations phasing in over the following years, requires providers of high-risk AI systems to prepare technical documentation and instructions for use that let deployers understand and interpret system output. Article 13 is the transparency provision; Annex IV enumerates the technical documentation contents. General-purpose AI model providers carry their own documentation duties. The penalty structure runs into percentages of global annual turnover, which is what moved this from a documentation backlog item to a board-level line. Whether or not a given US company sells into the EU, the Act functions as the de facto template, because nobody wants to maintain two disclosure regimes.

The second is the buyer. Enterprise procurement teams — the same people who have asked for SOC 2 Type II reports for a decade — added AI-specific questions to their vendor security questionnaires. If you sell software with a model inside it, you now field a request for the model card during the security review, usually somewhere between the penetration test summary and the subprocessor list. This is where the topic becomes a RevOps problem rather than purely an ML engineering one: an incomplete model card stalls deals in legal review, and stalled deals in legal review are indistinguishable from lost deals on a forecast.

The third is the downstream developer. If you fine-tune someone else's base model, you inherit its failure modes. The training cutoff, the language coverage, the known jailbreak surface — those become your problems the moment you ship. Model cards are how that information propagates down the supply chain, and by 2027 the expectation is that a fine-tune's card references the base model's card explicitly rather than restating its claims secondhand.

The practical consequence is that model card work has migrated out of the research team. In most organizations the card is now assembled by whoever owns compliance evidence — often the same function that maintains the trust portal — with ML engineering supplying the numbers and legal reviewing the use-case language. That handoff is where most of the friction lives.

The nine required sections, in detail

Different frameworks number the sections differently, but the union of EU AI Act Annex IV, the NIST AI Risk Management Framework, and the Hugging Face card template converges on the same nine buckets. Treat these as the minimum spine.

Model identification. Name, version string, release date, provider legal entity, and a contact address for reporting problems. Architecture summary at a level a technical reviewer can act on — transformer, mixture-of-experts, parameter count or an honest range if the exact count is confidential. Training data cutoff stated as a month and year. If the model is a fine-tune, name the base model and link its card. Reviewers check version strings against what is actually deployed; a card that describes v2.1 while the API serves v2.3 is a finding.

Intended use and out-of-scope use. The single most-rejected section, because teams write "general-purpose assistant" and stop. What reviewers want is a three-column matrix: permitted uses, conditional uses that require human oversight, and prohibited uses. "Drafts customer support replies for retail inquiries" is permitted. "Summarizes clinical notes for a licensed clinician who reviews before filing" is conditional. "Provides medical diagnosis, legal advice, or credit decisions without human review" is prohibited. Where a prohibition traces to a specific legal provision, cite it. Geographic scope belongs here too, since a model available in the US but not the EU has a different obligation profile.

Training data summary. Source categories with rough proportions — web crawl, licensed corpora, code repositories, dialogue data, synthetic data. Time period covered. Approximate size in tokens. Filtering and preprocessing steps: PII scrubbing, deduplication, toxicity filtering, opt-out honoring. Known exclusions. You are not expected to publish a file manifest, and most providers will not, but "we cannot describe our data" is no longer an acceptable answer. If synthetic data was used for fine-tuning, say which model generated it — that reference matters, because the generator's biases propagate.

Evaluation results. Report on recognized public benchmarks so results are comparable: MMLU and MMLU-Pro for general knowledge, GPQA for hard reasoning, HumanEval and SWE-bench for code, MATH for quantitative work, and long-context retrieval tests such as needle-in-a-haystack variants. Report the evaluation configuration alongside the number — few-shot count, temperature, whether chain-of-thought prompting was used, whether tools were available. A bare "82% on MMLU" is not reproducible and reviewers increasingly say so. Include sample sizes and, where you can, confidence intervals.

Bias and fairness assessment. Performance broken out by demographic slice where the deployment context makes that meaningful, plus results on standard bias probes such as BBQ, BOLD, StereoSet, or CrowS-Pairs. Name the metric you are using — demographic parity, equal opportunity difference, disparate impact ratio — rather than asserting "no significant bias found." Document what you found, not just that you looked. A card that reports a real disparity and an accompanying mitigation reads as more credible than one reporting a clean sweep.

Safety mitigations. Alignment technique used (RLHF, constitutional methods, RLAIF), any classifier or guardrail layers running in front of or behind the model, red-teaming summary including who did it and roughly how much effort, and refusal behavior. If output watermarking or provenance signaling is applied, say so. Note the residual risks that mitigations did not close, because reviewers assume they exist and read their absence as omission rather than achievement.

Compute disclosure. Training compute in FLOPs or accelerator-hours. Inference latency at P50 and P95 on named hardware at a stated prompt and output length. Memory footprint and available quantizations. This section matters for the EU AI Act's compute-threshold provisions for general-purpose models with systemic risk, and separately it is the section enterprise buyers actually read, because it is the one that predicts their bill.

Environmental impact. Training energy in megawatt-hours and estimated CO2 equivalent, with the grid carbon intensity assumption stated. Per-inference energy estimate. Tools like CodeCarbon and the ML CO2 impact calculator produce defensible estimates; the expectation is a transparent estimate with methodology, not a precise figure.

Known limitations and risks. Hallucination patterns you have characterized, reasoning failure modes, languages where quality degrades, the knowledge gap created by the training cutoff, and adversarial vulnerabilities including prompt injection exposure. This section is the credibility test for the whole document. Cards with a thin limitations section get the rest of their claims discounted.

The step-by-step process

Building a card is an assembly job, and the failure mode is treating it as a writing job at the end. The evidence has to be captured while the training and evaluation runs are happening, because reconstructing FLOPs and energy from cloud invoices three months later is miserable.

A workable sequence: freeze the model version and tag it in your registry so every downstream artifact points at one immutable thing. Pull metadata automatically — training configuration, accelerator hours, energy telemetry — from your ML platform rather than transcribing it. Run the benchmark suite and the safety suite as a single scheduled job, capturing raw outputs rather than summary numbers, so a reviewer's follow-up question does not require a re-run. Run the fairness analysis. Compute the environmental figures. Then, and only then, draft the narrative sections — intended use, limitations — because those are the ones requiring human judgment and legal review, and they are the bottleneck.

Tooling helps at the collection end. Hugging Face's model card template and toolkit, Google's Model Card Toolkit, and IBM's AI FactSheets all generate structured cards from metadata; evaluation harnesses such as EleutherAI's lm-evaluation-harness produce comparable benchmark output; CodeCarbon handles emissions. None of them write your intended-use section, and that is deliberate — the judgment calls are the point.

One organizational note that decides whether this works: the card needs a single named owner with authority to block a release. Where the card is everyone's job it is nobody's job, and the version that ships is the one someone assembled the night before launch from a spreadsheet.

Costs, timelines, and typical ranges

For a first card on a model your team trained, budget on the order of 40 to 120 person-hours across ML engineering, compliance, and legal. The spread is wide because it depends almost entirely on whether evaluation infrastructure already exists. If you have a benchmark harness wired into CI, the numbers fall out and the work is mostly writing and review — closer to the low end. If every evaluation has to be stood up from scratch, the benchmark and safety runs alone consume the majority of the budget.

Rough allocation for a first card: a day or two on metadata collection and registry hygiene; several days on benchmark and safety evaluation, most of it compute wall-time rather than human time; a couple of days on fairness analysis; a few hours on environmental calculation; and then a week or so of elapsed calendar time on the narrative sections, dominated by review cycles rather than drafting. The legal review of the prohibited-use matrix is consistently the longest pole, because it is the section that creates contractual exposure.

Subsequent cards are dramatically cheaper — often a small fraction of the first — because the pipeline exists. That asymmetry is the argument for building the evaluation harness properly the first time rather than assembling the card by hand and promising to automate it later.

For teams that consume models rather than train them, the cost profile inverts. You are not producing a card; you are collecting vendor cards, verifying they cover your deployment context, and writing a thin deployment-level card describing your system prompt, your retrieval layer, your guardrails, and your evaluation of the composed system. That last part is the piece teams skip and reviewers ask about, because a well-documented base model wired into a badly-scoped application is still a badly-scoped application. Budget a much smaller effort per application, but multiply by every application, and the aggregate is not trivial.

Refresh cadence is the recurring cost most plans miss. A material change — retraining, a new fine-tune, a significant system prompt change, a new deployment context — requires a new card version rather than an edit in place. Many organizations settle on quarterly review with event-driven updates in between, and maintain a version history table showing what changed and when. Safety evaluations in particular go stale; a common internal policy is that safety results older than roughly a quarter get re-run before the card is presented as current.

Where teams get it wrong

Writing the card after the fact. By far the most expensive error. Training runs finish, the team moves on, and six months later someone tries to reconstruct energy consumption from partial logs and a cloud bill. Instrument during, not after.

Intended-use sections that say nothing. "General-purpose AI assistant" is not a use statement; it is a refusal to make one. It reads to a reviewer as either evasion or an admission that nobody has thought about deployment boundaries. The fix is mechanical — enumerate permitted, conditional, and prohibited uses, and be specific enough that a support engineer could apply the rule.

Cherry-picked benchmarks. Reporting only the evaluations where the model wins is transparent to anyone who has read more than a handful of cards, and it poisons the credibility of everything else in the document. Report the standard suite, including the weak results, with a sentence on why. A model that is strong on code and mediocre on multilingual reasoning is a normal model; a model claiming to be strong on everything is a marketing document.

Bias assessment limited to English. If the product ships in twelve languages, an English-only fairness analysis covers a minority of the risk surface. Culturally-adapted probes exist for major languages, and where they do not, saying "we have not evaluated fairness in these languages" is a legitimate and far more useful disclosure than silence.

Copying the base model's card. Fine-tuning changes behavior, sometimes substantially, and fine-tuning on a narrow domain can undo safety training. A fine-tune inherits the base card as context, not as its own evaluation. Re-run at minimum the safety suite and the evaluations relevant to your domain.

Treating the card as a document rather than a data product. Cards get consumed by procurement portals, ingested into vendor risk platforms, and diffed across versions. Structured fields with a stable schema survive that; a prose PDF does not. Publish machine-readable and render the human version from it.

Ignoring the composed system. The model card describes the model. Your users interact with a system: model plus system prompt plus retrieval plus tools plus guardrails plus your UI's affordances. Regulators and serious buyers care about the system. A deployment-level card that documents the composition is the piece most teams have not built.

No owner. Covered above, worth repeating, because it is the root cause behind several of the others.

Decision framework: how deep to go

Not every model needs the full nine-section treatment with third-party review. The depth should track risk and obligation, and over-documenting a low-stakes internal tool burns credibility you will need later.

The first question is whether the system falls into a regulated high-risk category — employment decisions, credit, education access, essential services, biometric identification, safety components. If yes, the full documentation set is a legal obligation and the question of depth is settled. The second question is whether you are the provider or the deployer, since obligations differ. The third is whether the system is customer-facing at all; purely internal experimental work with no external impact sits at a genuinely lower tier, and a lightweight internal card is a reasonable answer.

A useful heuristic underneath the flowchart: document to the level of the hardest question a skeptical outsider could ask about consequences. If the worst realistic outcome of a wrong output is a slightly awkward internal summary, a short card is honest. If the worst realistic outcome touches someone's job, money, health, or liberty, the full treatment is not bureaucracy — it is the thing that lets you answer for the decision later.

How this lands on the revenue team

There is a commercial dimension that ML teams rarely see and RevOps teams feel immediately. The model card becomes a sales artifact the moment you sell to enterprises, and its quality becomes a cycle-time variable.

Concretely: security review is a stage in your funnel whether or not your CRM models it as one. When the buyer's security team asks for the model card and receives an incomplete one, the deal does not die — it stalls, generates a remediation thread, and slips a quarter. That shows up in your pipeline data as elongated cycle time in late stages, and because it is a documentation gap rather than a competitive loss, it is nearly invisible to standard win/loss analysis. Teams find it by segmenting cycle time by whether the deal triggered a security review, and by tagging the specific evidence request that caused each slip.

The operational fix mirrors what mature companies already do with SOC 2 reports: put the card in a trust portal, keep it current, and pre-empt the question rather than answering it deal by deal. Vendor trust platforms have added AI documentation sections precisely because buyers started asking. Publishing proactively converts a multi-week back-and-forth into a link in the first discovery call.

Two second-order effects are worth planning for. First, the card constrains what sales can claim. If the card says the model is not evaluated for medical use, a rep promising a healthcare use case has created a gap between the marketing claim and the disclosure — which is exactly the kind of inconsistency a regulator or a plaintiff's counsel looks for. Enablement should treat the prohibited-use matrix as source-of-truth for what is sellable. Second, the refresh cadence needs to be a scheduled operational commitment with an owner and a calendar entry, not a task that surfaces when a deal is blocked. A stale card discovered mid-deal costs more than the quarterly maintenance it replaces.

The upstream effect closes the loop: procurement questionnaires are the best available signal for what disclosure requirements are actually hardening in your market. Whatever buyers are asking today that you cannot answer is next year's mandatory section. Logging those gaps and routing them to whoever owns the card turns compliance from a reactive cost into a roadmap input.

Related questions

Does a fine-tuned model need its own card?

Yes. Fine-tuning changes behavior and can weaken safety training, so the base card does not transfer. Publish a card that references the base model, documents your training data and objective, and reports fresh safety and domain-relevant evaluation results.

Who owns the model card internally?

Usually whoever owns compliance evidence, with ML engineering supplying measurements and legal reviewing the use-case language. The essential property is a single named owner with authority to block a release, not which department they sit in.

What if we only use third-party APIs?

You still owe a deployment-level card: system prompt, retrieval sources, guardrails, intended and prohibited uses, and your own evaluation of the composed system. Keep the vendor's card on file as supporting evidence, not as a substitute.

How often must a model card be updated?

On any material change — retraining, new fine-tune, significant prompt or architecture change, new deployment context. Absent changes, a quarterly review keeps safety evaluation results from going stale and catches drift between the card and what is actually deployed.

Is a model card the same as a system card?

Not quite. A model card documents the model; a system card documents the deployed system including guardrails, mitigations, and evaluations of the whole composition. Larger providers publish system cards precisely because the model alone is not what users touch.

FAQ

Does every AI model need a card in 2027?

Every production deployment with external impact should have one, and high-risk systems under applicable regulation must. Purely internal research prototypes with no customer exposure can carry a lightweight internal registry entry instead — but the moment something ships to users, the full treatment applies.

Can we omit training data details for competitive reasons?

You can withhold a file-level manifest, and most providers do. You cannot skip the section. Describe source categories, approximate proportions, time coverage, filtering steps, and exclusions at a level that lets a reviewer assess risk. "Proprietary" as the entire answer gets rejected.

Which benchmarks are actually required?

No single list is universally mandated, but the practical expectation is a recognized general-knowledge benchmark, a reasoning benchmark, task benchmarks relevant to your domain, plus safety and bias evaluations. What matters as much as the choice is reporting the configuration — shot count, prompting method, tool access — so results are reproducible.

What are the penalties for getting this wrong?

Under the EU AI Act, penalties for serious violations are set as a percentage of global annual turnover, with the exact tier depending on the violation. The more common commercial penalty is quieter: stalled enterprise deals, marketplace delisting, and remediation work that consumes engineering time you had budgeted elsewhere.

Do we need a third-party audit of the card?

For high-risk systems under the EU framework, conformity assessment obligations apply and independent review is part of the path. For everything else, self-certification is the norm, though large enterprise buyers increasingly ask who reviewed the document internally and whether that reviewer was independent of the team that built the model.

Where should the card be published?

For open-weight models, the model hub alongside the weights. For commercial products, a public trust page or trust portal that procurement can reach without an NDA, with the deeper technical documentation available under one. Both should render from the same structured source so they cannot drift apart.

Sources

• https://arxiv.org/abs/1810.03993 — Model Cards for Model Reporting (Mitchell et al.)
• https://www.nist.gov/itl/ai-risk-management-framework — NIST AI Risk Management Framework
• https://artificialintelligenceact.eu/ — EU Artificial Intelligence Act text and article browser
• https://huggingface.co/docs/hub/model-cards — Hugging Face model card documentation
• https://www.iso.org/standard/42001 — ISO/IEC 42001 AI Management System standard
• https://oecd.ai/en/ai-principles — OECD AI Principles
• https://codecarbon.io/ — CodeCarbon emissions tracking for ML workloads
• https://github.com/EleutherAI/lm-evaluation-harness — EleutherAI language model evaluation harness
• https://www.gov.uk/government/organisations/ai-safety-institute — UK AI Safety Institute

Related on PULSE

• [How should a 2027 GTM team adjust motion for EU GDPR and AI Act requirements?](/knowledge/q12582)
• [What are the LLM fine-tuning compute requirements in 2027?](/knowledge/q12298)
• [What compensation model prevents revenue churn when sales cycles double due to mandatory AI audit requirements in 2027?](/knowledge/q16406)
• [How should RevOps teams think about governance philosophy as a leading indicator of go-to-market maturity and expansion readiness, separate from operational compliance requirements?](/knowledge/q9549)