How to Read an AI Model Card (and a System Card)

When a lab releases a model, it usually publishes two documents. A model card, which is a technical description on the model’s hosting page, and increasingly a system card, which is a longer safety and evaluation report. Anthropic published one alongside Claude Opus 5 in July 2026; the practice is now standard across major releases.

Almost nobody reads them, which is a shame, because they are the only place where the vendor commits to specifics in writing. If you are choosing a model for professional work, particularly in a regulated setting, these documents are your due diligence.

The Six Fields That Matter Most

Reading a model card on Hugging Face or a lab’s documentation, these are worth finding first.

License. The single most consequential field, and the one most likely to be glossed over in the announcement. Apache 2.0 or MIT means commercial use with attribution and no user-count ceiling. A community license means usable with conditions, including an acceptable-use policy that is incorporated by reference and can change. A research-only license forbids commercial use entirely, and downloads exactly like everything else. We covered the categories in open-weights model licenses explained.

Parameter count, total and active. For a mixture-of-experts model both numbers appear, as in 295B total with 21B active. Total drives memory; active drives speed. Assuming active parameters determine what you can run is the most common planning error in local deployment.

Context length. A capacity limit, not a quality guarantee. Useful for knowing whether your input will be accepted, not for predicting whether the model attends to all of it.

Intended use and out-of-scope use. Often the most honest section. Labs increasingly state what the model was not built for, and those statements are worth taking seriously rather than treating as legal boilerplate.

Training data description. Usually vague, occasionally informative about language coverage and domain emphasis. If you write in a language other than English, this is where you look for whether it was represented meaningfully.

Evaluation results. Read these with the understanding that they measure what they measure. Coding and mathematics benchmarks predict very little about whether a model rewrites your email well. See what open-weights benchmarks do not tell you.

What The Omissions Tell You

A card that does not state its license is a red flag, not an oversight. Serious releases state terms, and vagueness usually means the terms are either unfavorable or unsettled.

A card with no out-of-scope section suggests the lab has not thought carefully about misuse, or has decided not to say. A card with no evaluation details at all is a marketing page rather than documentation.

Conversely, a card that discloses a limitation without being forced to is a good sign about the team’s engineering culture. Anthropic noting that Opus 5 remained behind another model on cybersecurity tasks while positioning it as state of the art elsewhere is that kind of disclosure: specific, unflattering, and more useful than a table of wins.

System Cards Are A Different Document

A system card goes beyond the model to the deployed system: safety evaluations, red-teaming results, known failure modes, mitigations, and often the reasoning behind deployment decisions.

For most users these are long and skippable. For two audiences they are not.

Regulated deployers. If you must document what you deployed and why it was appropriate, the system card is the source you cite. Under the EU AI Act, general-purpose AI obligations and transparency requirements took effect on 2 August 2026, along with the full penalty regime. Providers of general-purpose models have documentation duties, and deployers benefit from that documentation existing.

Anyone assessing failure modes. The known-limitations section tells you where the model breaks, which is more actionable than knowing where it excels. If it is documented as prone to a specific error, that is a thing to check for in your own output.

The Local Model Version Of Due Diligence

For an open-weights model you run yourself, the card is your only vendor documentation, because there is no vendor relationship. That makes a few checks worth doing once and recording.

1. License name and version, copied into your own records.
2. Exact model identifier and revision, since families contain many variants with different terms.
3. Published checksum, verified against the file you downloaded.
4. Total parameter count and quantization, so you know what you are actually running.
5. Date you checked, because cards get edited.

That takes ten minutes and answers the question an auditor will eventually ask: which model version processed client data in March, and under what license. There is a fuller process in how to document your AI workflow for an auditor.

Wrivio verifies model downloads against a published SHA-256 checksum before use, which covers the integrity half of that list automatically.

Writing The Summary For Your Own Organization

Once you have read a card, somebody usually needs a paragraph rather than the document. The failure mode is a summary so hedged that it communicates nothing.

Before:

I looked at the model and it seems fine, it’s open source and pretty capable, should be OK for our use.

After:

Summary of the model we propose to use. It is a 4-billion-parameter instruction-tuned model licensed Apache 2.0, which permits commercial use with attribution and carries no user-count restriction. It runs locally in a 4-bit quantization at approximately 3GB of memory, so no message content is transmitted externally. The card states English and major European languages are well represented and does not claim specialist domain capability, which matches our intended use for general business correspondence. Checksum verified against the published value on 29 July 2026.

A Wrivio Context for technical summaries could say:

Rewrite this as a factual technical summary for an internal record. Neutral professional register, complete sentences, no contractions. Keep every version number, license name, figure, and date exactly as written. Do not add capabilities, assurances, or conclusions that are not in the original, and do not replace specific claims with general ones.

Press Ctrl+Shift+Space, run it, and read the diff. Specific technical claims becoming reassuring generalities is exactly the failure mode here.

Common Questions

Are model cards legally binding?

They are vendor statements rather than contracts, but the license they reference is binding, and misstatements in published documentation carry regulatory risk for the provider. Treat the license as the operative document.

Do open-weights models have system cards?

Increasingly yes for major releases, though coverage is uneven and typically thinner than for flagship closed models. Smaller community fine-tunes often have minimal documentation, which is itself information.

What if the card contradicts the announcement blog post?

Trust the card, and the license text above all. Announcements are written by marketing; cards are written by the people who trained the thing.

How do I check a model’s license quickly?

The license field on the model’s hosting page, then follow the link to the full text. If the field is missing or says something non-standard, read the full terms before adopting it.

Download Wrivio for Windows to run a checksum-verified Apache 2.0 model with the documentation trail already in place.