Model Card

Basic metadata providing unambiguous identification and versioning of the artifact.

• Model Name & Version: A unique identifier and semantic version string (e.g., v2.1.0).
• Model Type: The architecture class, such as transformer, convolutional neural network, or gradient-boosted tree.
• Developer: The entity that trained and owns the model.
• Release Date: The ISO 8601 timestamp of the initial publication.

A precise definition of the operational domain and valid use cases to prevent off-label application.

• Primary Use Case: The specific task the model was designed to solve (e.g., English-to-French translation).
• Out-of-Scope Applications: Explicitly forbidden high-risk uses (e.g., medical diagnosis or credit scoring).
• Target Domain: The data distribution and environment where the model is expected to perform reliably.
• Intended Users: The required expertise level, such as ML engineers or domain experts.

Quantitative evaluation results across relevant metrics, datasets, and population segments.

• Evaluation Datasets: The specific test corpora used, including their provenance and potential biases.
• Aggregate Metrics: Standard scores like F1, BLEU, ROUGE, or accuracy.
• Disaggregated Performance: Metrics broken down by demographic factors, dialect, or environmental conditions to surface disparate impact.
• Decision Thresholds: The operating points and calibration curves used for classification tasks.

A candid disclosure of known failure modes, biases, and safety vulnerabilities.

• Known Biases: Documented statistical skews against protected groups identified during fairness evaluation.
• Failure Modes: Specific scenarios where the model is brittle, such as out-of-distribution inputs or adversarial perturbations.
• Hallucination Rate: The empirically measured frequency of factually incorrect or nonsensical generation.
• Robustness: Performance degradation under distribution shift, measured via data drift detection benchmarks.

A lineage record of the datasets used to train and fine-tune the model.

• Data Sources: A list of corpora, databases, or synthetic generation engines.
• Preprocessing Steps: Tokenization, filtering, and augmentation pipelines applied.
• Sensitive Data: Disclosure of whether personally identifiable information (PII) or copyrighted material is present.
• Data Splits: The methodology for creating training, validation, and test partitions to prevent leakage.

Documentation of the governance process and alignment with legal frameworks.

• Impact Assessment: A link to the Algorithmic Impact Assessment or Data Protection Impact Assessment.
• Fairness Metrics: The specific definitions of fairness used (e.g., equalized odds, demographic parity).
• Human Oversight: The mechanism for human-in-the-loop or human-on-the-loop intervention.
• Regulatory Status: Classification under the EU AI Act, such as high-risk or general purpose AI.

A transparency artifact that documents the safety evaluation and operational context of an entire AI system, not just the model. While a model card focuses on the mathematical artifact, a system card expands the scope to include the user interface, deployment environment, and human interaction protocols. It captures systemic risks that emerge only when the model is integrated into a software application. A system card typically includes the results of red-teaming exercises and the configuration of guardrails that constrain model behavior in production.

A formal, structured inventory of all software, data, and model components used to construct an AI system. Analogous to a Software Bill of Materials (SBOM) in cybersecurity, an AIBOM provides a machine-readable manifest that enables vulnerability scanning and supply chain risk management. It catalogs every dependency—from the base foundation model and fine-tuning dataset to the inference server and Python library versions—allowing procurement teams to quickly identify exposure when a critical CVE is disclosed.

The documented end-to-end origin, movement, and transformation history of all datasets used to train a model. A model card's data section is a summary; full data lineage provides the granular, auditable provenance trail. It tracks:

• Source: Original data repository or provider
• Transformations: Cleaning, augmentation, and filtering steps
• Splits: How data was partitioned into training, validation, and test sets This lineage is essential for copyright compliance and detecting data poisoning vectors.

The process of verifying that an AI system meets the essential requirements of a specific regulation, such as the EU AI Act. A model card serves as a key input to this assessment, providing the documented evidence of performance characteristics and limitations. The conformity assessment body evaluates whether the model's intended use, as declared in the card, aligns with its risk classification and whether the documented mitigations are sufficient. A successful assessment results in CE marking for the European market.

A document detailing the findings from an adversarial simulation designed to uncover safety and security flaws in an AI system. While a model card discloses known limitations, a red-teaming report provides the empirical evidence of how those limitations were discovered and stress-tested. It documents jailbreak susceptibility, prompt injection vulnerabilities, and alignment faking attempts. This report is increasingly a mandatory supplement to the model card for high-risk and frontier AI systems.

The network of data providers, model developers, and tooling vendors that contribute components to a final AI system. A model card is a transparency artifact that must account for every link in this chain. When a foundation model is fine-tuned by a downstream vendor, the resulting model card must reference the upstream card and document the modifications. This chain of custody enables vendor due diligence and ensures that risk is not obscured by complex subcontracting relationships.