ACE Journal

Model Cards as Governance Artifacts - Gaps and Enforcement

Who this is for: ML engineers and platform teams that build or deploy models and are starting to face documentation requirements from legal, compliance, or customers. You do not need to be a governance specialist. If you are writing model cards by hand, copying a template, and treating the result as a checkbox, this piece is about encoding that process into CI so the checkbox has teeth.

The model nobody documented properly

The scenario is common enough to have a name internally at most organizations that have been deploying models for a few years. A model ships to production. The model card (if one exists at all) is a stub: intended use copied from the training brief, one benchmark number from the framework’s default evaluation, limitations section reading “may produce incorrect results.” Six months later a compliance review arrives, or a customer asks for documentation before signing an enterprise agreement, and someone has to reverse-engineer what the model actually does from the training code and a Slack thread.

This is not a failure of good intentions. It is a structural consequence of voluntary documentation without enforcement at the point of release. The model card format exists. Adoption is widespread in form. In substance, a survey of Hugging Face model cards for widely-downloaded models finds a spectrum from rigorous multi-slice evaluations with stated methodology all the way down to boilerplate that ships with every model by default and is never touched [3]. The goal of this piece is to show what it takes to close that gap mechanically, what the residual hard problems are, and where the regulatory landscape is pushing the format.

What a model card captures: the Mitchell et al. framework

The original Mitchell et al. (2019) paper [1] proposed model cards as the ML equivalent of a nutrition label. The core sections are:

The disaggregated analysis requirement is the operationally important one. A model that performs well overall can systematically underperform for a demographic subgroup, a dialect, an image acquisition context, or a deployment environment. Reporting only aggregate performance hides this. The intended-use / out-of-scope-use distinction is the second critical one: it creates an explicit record of what the releasing organization warranted the model was designed to do.

Hugging Face operationalized this format in its model hub, providing a YAML metadata block at the top of each README.md and a rendered card interface [3]. The metadata schema includes fields for language, license, datasets, metrics, and task type, with the narrative sections in markdown below. As of early 2026, Hugging Face’s model card metadata spec [4] is the most widely deployed instantiation of the format.

Figure 1 shows the lifecycle of a model card from initial creation through deployment and downstream modification, with the points where the card can diverge from reality.

flowchart TD
    A[Training run] --> B[Evaluation\neach slice]
    B --> C[Card authored\nat release]
    C --> D[Model published\nto registry]
    D --> E[Downstream team\nfine-tunes]
    E --> F{Card updated?}
    F -->|Yes| G[Card reflects\nfine-tuned model]
    F -->|No| H[Card describes\nbase model only\nDRIFT]
    D --> I[Deploying team\ncopies model]
    I --> J{Deployment\ndocumented?}
    J -->|No| K[No deployment-level\ncard exists]
    J -->|Yes| G

Figure 1. Model card lifecycle from training through downstream use. The two drift points are fine-tuning without card update (center) and deployment without deployment-level documentation (bottom right). Both are common and neither is addressed by the original voluntary format.

The governance role under emerging regulation

The EU AI Act [2], which completed its legislative process in 2024 and is entering enforcement phase across risk categories, specifies technical documentation requirements for high-risk AI systems. Annex IV lists what that documentation must contain: intended purpose, accuracy and robustness metrics, known risks and risk management measures, training data characteristics, human oversight measures, and more. The overlap with a well-completed model card is substantial.

The operational word is “well-completed.” The Act’s conformity assessment requirements for most high-risk categories (Annex III systems: biometric identification, critical infrastructure, education, employment, access to essential services, law enforcement, migration, administration of justice) allow self-assessment rather than mandatory third-party audit for the majority of cases. This preserves the same structural gap that exists in voluntary frameworks: the party with the most to gain from positive documentation is the same party completing it.

The Act does create a paper trail that can be inspected by market surveillance authorities after the fact, which is a meaningful change from the purely voluntary pre-Act regime. It also creates liability for documentation that is incomplete or inaccurate at the time of market placement. That liability incentive is doing more practical work than any technical specification in the regulation.

For teams operating in US markets, the NIST AI Risk Management Framework [5] (released January 2023) provides a voluntary governance structure that overlaps heavily with model card content, particularly in its “Map” and “Measure” functions. It does not mandate model cards specifically, but its documentation expectations are consistent with the format.

A schema-enforced model card: worked example

The path from “we have a model card template” to “the build fails if the card is incomplete” runs through a machine-readable schema. Here is a minimal YAML schema for a model card that can be validated in CI.

# model-card-schema.yaml
# JSON Schema (YAML form) for a minimal governance-grade model card.
type: object
required:
  - model_name
  - version
  - date
  - intended_use
  - out_of_scope_use
  - training_data
  - evaluation_data
  - metrics
  - eval_slices
  - limitations
properties:
  model_name:    { type: string }
  version:       { type: string }
  date:          { type: string, format: date }
  intended_use:  { type: string, minLength: 50 }
  out_of_scope_use: { type: string, minLength: 30 }
  training_data: { type: string, minLength: 50 }
  evaluation_data: { type: string, minLength: 50 }
  metrics:
    type: array
    minItems: 1
    items: { type: object, required: [name, value, threshold] }
  eval_slices:
    type: array
    minItems: 2
    items: { type: object, required: [factor, metric, value] }
  limitations:   { type: string, minLength: 80 }

The eval_slices requirement with minItems: 2 is the operationally meaningful constraint. It is not possible to satisfy with a single aggregate metric, which forces at minimum two disaggregated evaluation slices into the card. The minLength constraints on free-text fields are crude but effective at preventing one-line boilerplate.

Here is a matching model card YAML file for a hypothetical text classification model:

# model-card.yaml
model_name: "content-moderation-v2"
version: "2.3.1"
date: "2026-03-15"
intended_use: >
  Binary classification of user-submitted text as policy-violating or
  compliant for English-language content moderation on a social platform.
  Designed for use as a first-pass filter with human review for borderline
  cases above a configurable confidence threshold.
out_of_scope_use: >
  Not designed for languages other than English. Not suitable for legal
  determinations or permanent account actions without human review.
training_data: >
  Internal annotation dataset of 2.4M examples, 2021-2023. Annotators
  were recruited via a managed labeling vendor. Label schema and inter-
  annotator agreement protocol documented in training/annotation-guide.md.
evaluation_data: >
  Held-out 15% split from the annotation dataset, stratified by label.
  Separate out-of-domain evaluation set of 50k examples from a partner
  platform, collected 2024-Q1, not used in training.
metrics:
  - name: "F1 (positive class)"
    value: 0.913
    threshold: 0.90
  - name: "False positive rate"
    value: 0.031
    threshold: 0.05
eval_slices:
  - factor: "text_length_bucket"
    metric: "F1"
    value: { short: 0.887, medium: 0.921, long: 0.908 }
  - factor: "dialect_region"
    metric: "F1"
    value: { us: 0.919, uk: 0.911, au: 0.897, other_english: 0.874 }
  - factor: "content_category"
    metric: "false_positive_rate"
    value: { hate_speech: 0.028, spam: 0.011, nsfw: 0.044, political: 0.067 }
limitations: >
  Performance degrades on non-standard spelling, heavy code-switching, and
  emerging slang not represented in the training window. The political
  content false positive rate (0.067) is above the overall threshold and
  reflects genuine ambiguity in annotation; human review is recommended
  for that category. Model has not been evaluated on low-resource dialects.

And the CI check that gates on it. This runs in any Python-based pipeline:

# validate_model_card.py
import sys, yaml
from jsonschema import validate, ValidationError

def main():
    try:
        schema  = yaml.safe_load(open("model-card-schema.yaml"))
        card    = yaml.safe_load(open("model-card.yaml"))
    except FileNotFoundError as e:
        print(f"Model card validation FAILED: file not found - {e.filename}", file=sys.stderr)
        sys.exit(1)
    try:
        validate(instance=card, schema=schema)
        print("Model card validation passed.")
    except ValidationError as e:
        print(f"Model card validation FAILED: {e.message}", file=sys.stderr)
        sys.exit(1)

if __name__ == "__main__":
    main()

In a GitHub Actions workflow, this step runs before the model artifact is pushed to the registry. A failed validation blocks the push. The model does not ship without a card that passes the schema.

Figure 2 shows where this validation step sits in a typical MLOps pipeline.

flowchart LR
    A[Training\ncomplete] --> B[Evaluate\nper slice]
    B --> C[Write\nmodel-card.yaml]
    C --> D{validate_model_card.py}
    D -->|PASS| E[Push to\nmodel registry]
    D -->|FAIL\nmissing sections\nor slices < 2| F[Block release\nCI fails]
    E --> G[Deployment\nconfiguration]
    G --> H[Serve in\nproduction]

Figure 2. Model card validation as a CI gate. The validator runs after evaluation and before the registry push, blocking release on schema failures. The eval_slices minItems: 2 constraint is what prevents aggregate-only cards from passing.

The hard part: drift, voluntary completion, and structural vs. substantive quality

Enforcement at the CI layer solves the “no card” problem. It does not solve the harder problem, which is that a card can satisfy the schema and still be substantively empty.

Minlength is not content quality. A limitations field with 85 characters of “may produce incorrect results in some contexts” passes minLength: 80. It contains no actionable information. Distinguishing informative from boilerplate text requires either human review or a more sophisticated natural-language check; pure schema validation cannot do it.

Evaluation slices can be chosen to look good. The releasing organization selects which factors appear in eval_slices. If performance is poor on a demographic group that the deploying organization would care about, the releasing organization can simply not include that slice. There is no external requirement specifying which slices are relevant for which use cases, except in narrow regulatory contexts (the EU AI Act specifies some requirements for biometric systems, but most categories are underspecified).

Cards drift from the deployed model. A model card written at release time describes that checkpoint. Fine-tuning, quantization, and prompt-wrapping all change the model’s behavior. The Mitchell et al. framework anticipated this with a recommendation that cards be updated for model modifications, but it is a recommendation, not a requirement enforced by any current tooling. Figure 3 shows a state diagram for card validity over a model’s operational life.

stateDiagram-v2
    [*] --> Valid: card authored at release
    Valid --> Stale: fine-tuning applied\nor adapter added
    Stale --> Valid: card updated\nfor new version
    Valid --> Stale: deployment context\nchanges (new domain)
    Stale --> Misrepresenting: time passes\nno update
    Misrepresenting --> Valid: audit forces\ncorrection
    Valid --> Archived: model retired

Figure 3. Card validity states over a model’s operational life. The Stale state is nearly universal for models that stay in production beyond their initial deployment. The Misrepresenting state is where regulatory liability begins to attach.

Voluntary completion rates for optional fields are low. Research into documentation practices for ML systems consistently finds that fields that are not structurally required are frequently omitted. Making sections optional in a schema, even when the guidance says they are important, produces incomplete documentation in practice. The schema above requires everything; the tradeoff is more friction per release.

No audit right for downstream deployers. If an organization deploys a third-party model, the model card is the primary source of information about what they are deploying. They have no right to inspect the evaluation datasets behind the reported numbers, no way to verify that the reported slices reflect actual behavior, and no recourse if the card is inaccurate except the general contract law that applies to any misrepresentation. The EU AI Act creates some obligations on providers toward deployers, but the audit mechanisms are not yet operationally defined.

Integration with an MLOps registry

In practice, the CI gate is one piece. The other is connecting the validated card to the model artifact in whatever registry the organization uses. MLflow [6] supports attaching free-form tags and logged artifacts to model versions; the model card YAML can be logged as an artifact at registration time.

A minimal MLflow pattern:

import mlflow

with mlflow.start_run():
    # ... training and evaluation code ...
    mlflow.log_artifact("model-card.yaml", artifact_path="governance")
    mlflow.log_metrics({
        "eval_f1_overall": 0.913,
        "eval_fpr_political": 0.067,
    })
    mlflow.sklearn.log_model(model, "model")

This ties the card to the registered model version in the experiment tracking system, which means any query against the registry for a model version can retrieve its card. For teams using Hugging Face Hub internally or as a deployment target, the equivalent is the README.md with the metadata YAML block that the Hub renders as the card UI [4]. The schema-validated YAML can be embedded directly.

The goal is that every version in the registry has a card that passed validation, not just the models that someone remembered to document.

Model cards are one point in a constellation of documentation formats for AI systems, and it is worth being clear about what each covers.

Datasheets for datasets (Gebru et al., 2018 [7]) is the upstream analog. It applies the same structured-disclosure logic to training and evaluation datasets: motivation, composition, collection process, preprocessing, uses, distribution, maintenance. A model card’s training-data and evaluation-data sections are downstream consumers of what a datasheet would contain. In practice, few publicly released datasets have formal datasheets, which means model cards often report training-data characteristics that were never formally documented.

System cards (as published by Meta for large language models, building on the model card concept) extend the scope beyond a single model to the full system: the model, the deployment configuration, fine-tuning layers, and the policies applied at inference time [8]. For systems where the model is only one component of a deployed product, the system card is the more complete governance artifact.

IBM’s FactSheets [9] approach the same problem from an enterprise governance direction, emphasizing the supplier-consumer relationship and the audit trail for regulated industries. They map well to ISO 42001 and similar management system standards.

The formats are complementary rather than competing. A rigorous governance setup for a high-risk system would have a datasheet for each training dataset, a model card for the base model, and either a system card or a FactSheet for the deployed system configuration. In practice, the model card is the most commonly required format and the reasonable place to start.

Where it breaks: six failure modes

1. The template-as-compliance trap. Organizations adopt a model card template, require it to be completed before release, and declare the governance problem solved. The template ensures a card exists; it does not ensure the card is accurate, the evaluations were run correctly, or the limitations section reflects genuine analysis. Structural presence without substantive review is theater.

2. Aggregate metrics hiding subgroup failure. A model that performs at 92% F1 overall may perform at 74% F1 for a subgroup that represents a minority of the evaluation set. If the card reports only the aggregate number, the deploying organization has no signal that a subset of their users will have a materially worse experience. This is the original motivation for the disaggregated evaluation requirement, and it is the requirement most commonly omitted.

3. Post-training modifications orphan the card. Fine-tuning, instruction tuning, RLHF, quantization, and distillation all change model behavior. The card describes the checkpoint it was written for. The deployed model may be several modifications downstream of that checkpoint. No current registry system enforces re-evaluation and card update on model modification.

4. Evaluation data contamination is unverifiable. The evaluation dataset is reported in the card, but its contents are usually not released. A deploying organization cannot verify that the reported test set was held out correctly, that it was not contaminated by training data, or that it is representative of their deployment context. The reported metric is a number with no audit trail.

5. Scope mismatch between card and deployment. A model released for English-language content moderation, with a card that only evaluates English-language inputs, gets deployed in a multilingual context by a downstream team. The card’s out-of-scope-use section may say “not designed for non-English” in a way that is technically accurate and practically invisible to the team reading a card for the first time under deadline. The gap between what the card says and how it is read in deployment is a documentation problem that no schema can solve.

6. The CI gate creates false confidence. A passing validation tells you the card exists and has the required fields. It does not tell you the card is accurate. Teams that implement schema validation and then treat it as equivalent to governance review have moved the problem from “no documentation” to “documentation that passed a syntax check.” Both are better than nothing. Only the second creates a false sense that the governance problem is solved.

Further reading

The Mitchell et al. model cards paper [1] is the necessary starting point, and it is short and readable. For the Hugging Face operationalization, the model card metadata specification [4] explains the YAML schema and how the hub renders it. The EU AI Act Annex IV documentation requirements [2] are the specific legal text governing high-risk system documentation. The NIST AI RMF [5] provides the US voluntary framework context. For the upstream dataset documentation problem, the Gebru et al. datasheets paper [7] is the companion piece. The IBM FactSheets paper [9] covers the enterprise governance angle. For implementing the validation layer, the Python jsonschema library documentation [10] covers the validation API used in the worked example above. For MLflow artifact logging [6], the model registry documentation covers attaching cards to registered versions.

Written with AI assistance, editorially reviewed.

References

[1] M. Mitchell et al., “Model Cards for Model Reporting,” in Proc. ACM FAccT, 2019, pp. 220-229. https://dl.acm.org/doi/10.1145/3287560.3287596

[2] European Parliament and Council, “Regulation (EU) 2024/1689 on Artificial Intelligence (EU AI Act),” Official Journal of the European Union, 2024. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689

[3] Hugging Face, “Model Hub - Model Cards,” Hugging Face Documentation, 2024. https://huggingface.co/docs/hub/model-cards

[4] Hugging Face, “Model Card Metadata Specification,” GitHub, 2024. https://github.com/huggingface/hub-docs/blob/main/modelcard.md

[5] National Institute of Standards and Technology, “AI Risk Management Framework (AI RMF 1.0),” NIST AI 100-1, January 2023. https://doi.org/10.6028/NIST.AI.100-1

[6] MLflow, “MLflow Model Registry,” MLflow Documentation, 2024. https://mlflow.org/docs/latest/model-registry.html

[7] T. Gebru et al., “Datasheets for Datasets,” Communications of the ACM, vol. 64, no. 12, pp. 86-92, December 2021. https://dl.acm.org/doi/10.1145/3458723

[8] Meta AI, “System Cards,” Meta AI Research, 2023. https://ai.meta.com/research/publications/llama-2-open-foundation-and-fine-tuned-chat-models/ (system card accompanying Llama 2 release)

[9] M. Arnold et al., “FactSheets: Increasing Trust in AI Services through Supplier’s Declarations of Conformity,” IBM Journal of Research and Development, vol. 63, no. 4/5, pp. 6:1-6:13, 2019. https://doi.org/10.1147/JRD.2019.2942288

[10] Python jsonschema, “jsonschema Documentation,” Read the Docs, 2024. https://python-jsonschema.readthedocs.io/en/stable/

[11] B. Hutchinson et al., “Towards Accountability for Machine Learning Datasets: Practices from Software Engineering and Infrastructure,” in Proc. ACM FAccT, 2021. https://dl.acm.org/doi/10.1145/3442188.3445918