Transparency through model and system cards
By AI Resource Zone Admin · February 7, 2026 · 4 min read
Model cards and system cards promise structured disclosure. They help, but they are not a substitute for accountability.
Model cards were proposed in a 2019 research paper as a way to document machine learning models in a structured format, covering intended use, performance across groups, training data characteristics, and known limitations. System cards extend the idea to the deployed product, since behavior depends on more than the model itself, including retrieval systems, guardrails, and user interface choices. Both formats are now common in industry practice, though their depth varies significantly from release to release.
A good card states what the system is and is not designed to do, lists evaluation results with enough detail to be meaningful, and discusses residual risks rather than hiding them. Recent cards published for frontier models include evaluations in areas such as cybersecurity, biosecurity, persuasion, and autonomous behavior, often with collaboration from external testing organizations. A weak card reads as marketing material, with vague capability claims and no honest discussion of limits.
Regulatory frameworks are starting to lean on card-like artifacts. The EU AI Act requires technical documentation for high-risk systems that overlaps with model card content. The NIST AI Risk Management Framework references documentation practices throughout its functions. National testing institutes also rely on cards to scope their evaluations and to compare notes between jurisdictions. Where multiple regulators accept similar documentation, the compliance burden on providers is lower, which is a positive alignment story.
Editor's note: Cards are necessary but not sufficient. They can create the impression of transparency while leaving the most contested questions, such as training data provenance and post-deployment monitoring, in vague language. Readers should treat a card as a starting point for questions, not a guarantee of safety. Regulators should treat it as evidence to test, not as a substitute for independent review.