Model Cards: what are they and why your business should care

Getting your vendor's model card before deployment of a new AI product is an essential part of good AI governance.

This article explains in non-technical terms what model cards are and why they matter.

What Is a Model Card?

When a company releases a new AI model, a responsible developer publishes what is called a model card - a transparency document that explains what the AI can do, what risks it poses, how those risks were tested, and what safeguards have been put in place. Think of it like a product safety data sheet for a chemical, or a clinical trial disclosure for a medication: it tells you what is inside, what it can and cannot do, and under what conditions it is safe to use.

The model card format was introduced by Google researchers in 2018 as a standardised way to document AI systems for the people who deploy and use them. The concept has since been adopted across the industry, though with significant variation in depth, rigour, and honesty. Some model cards run to a few pages of high-level claims. Others, such as Anthropic's system cards for its Claude models, run to over 130 pages of detailed capability testing, safety evaluations, and governance documentation (Claude Sonnet 4.6 System Card, Anthropic). The difference matters enormously when you are trying to make an informed decision about an AI tool.

Why Model Cards Exist

AI models are not neutral tools. They reflect the data they were trained on, the choices their developers made, and the risks those developers did or did not test for. Without documentation, a business deploying an AI tool has no way to know:

What the model was designed to do, and crucially, what it was not designed to do
What kinds of errors or biases have been identified in testing
Whether the model has been tested for the specific use case being considered
What safeguards are in place and how they were validated

Model cards make this information accessible. They are not a guarantee of safety; they are a disclosure of what the developer knows, including what they do not know. A well-written model card is therefore as valuable for what it acknowledges as limitations as for what it claims as strengths.

What a Good Model Card Should Contain

The quality of model cards varies widely across the industry. A useful model card for a business audience should address at least the following:

Intended use and scope: What is the model designed to do? What uses are explicitly out of scope or discouraged? This matters because many AI tools are deployed in contexts their developers never evaluated, with unpredictable results.

Training data: Where did the data used to train the model come from? Was it filtered or cleaned? Was it sourced ethically? Training data is the single biggest determinant of an AI model's behaviour, and undisclosed or poorly documented training data is a significant governance gap.
Capability evaluations: What can the model actually do, and how was that measured? Good model cards include results from standardised benchmarks across a range of tasks, so that capabilities can be compared across models and over time.
Known limitations and failure modes: Where does the model underperform, make errors, or behave unpredictably? A model card that claims no significant limitations should be treated with scepticism.
Bias and fairness testing: Has the model been tested for systematic bias across protected characteristics such as gender, race, age, or disability? What were the results? For any model used in decisions affecting people, this is non-negotiable.
Safety evaluations: For more capable models, what specific safety risks were tested — for example, the ability to assist with harmful activities — and what were the findings?
Safeguards and mitigations: What has the developer done to address the risks identified? What restrictions or content filters are in place, and how were they validated?
Ongoing monitoring: What happens after deployment? Does the developer monitor for misuse, performance drift, or emerging risks? How are updates communicated to users?

How Developers Approach Governance Differently

The industry has not converged on a single approach to AI governance, and the differences between major developers reflect genuinely different philosophies.

Some developers, like Anthropic, take the position that safety must be built into the model itself — trained into how the AI thinks and responds, rather than managed primarily through external controls. Their system cards for Claude models reflect this approach, documenting not just what the model can do but extensive testing of alignment, misuse resistance, and behavioural consistency under adversarial conditions. Anthropic also operates under a self-imposed governance framework called the Responsible Scaling Policy, which commits the company to defined safety standards before releasing each new model.

Other developers take the position that safety is best achieved through layered operational controls, such as monitoring, usage restrictions, and system design, which are applied on top of a capable base model. This approach is not inherently inferior, but it does mean that the safety properties are less visible from the model card alone, since they depend on controls that exist outside the model itself.

Open-source model developers such as Meta publish model cards for their Llama models, but face a structural challenge: once model weights are released publicly, the developer has limited ability to enforce safeguards, monitor misuse, or withdraw a problematic version. Transparency and accountability can diverge sharply in open-source AI.

For a business evaluating an AI tool, the important question is not which philosophy is correct in the abstract; it is whether the vendor can demonstrate, with documentation, that their approach has been tested and that the risks relevant to your use case have been identified and addressed.

The Self-Regulation Problem

A significant limitation of model cards as a governance mechanism is that they are, in virtually every case, self-reported. The developer identifies the risks, conducts the evaluations, reports the results, and determines whether those results are acceptable. There is no independent government regulator verifying these claims for most AI applications, and no mandatory external audit process.

This does not mean model cards are worthless; a detailed, candid model card from a developer with a track record of transparency is genuinely useful. Anthropic's system card for Claude Sonnet 4.6, for example, explicitly acknowledges that "confidently ruling out" the highest risk thresholds "is becoming increasingly difficult" as models become more capable. This kind of candid acknowledgement of uncertainty that is far more valuable than a document presenting only reassuring conclusions.

But it does mean that a model card should be the beginning of your due diligence, not the end of it. A document produced by the same organisation that has a commercial interest in releasing the model cannot be treated as an independent audit.

The regulatory landscape is beginning to address this gap. The EU AI Act, which came into force in stages from 2024, requires developers of high-risk AI systems to produce technical documentation comparable to a model card, and subjects those systems to conformity assessments before deployment. For the most powerful AI systems, independent third-party auditing requirements are emerging. Australia is actively developing its own AI governance framework, and the direction of travel globally is toward greater accountability and independent verification.

Model Cards and the Products Built on Top of Them

One of the most important things to understand about model cards is what they do not cover. The vast majority of AI products available to businesses are not built from scratch, but on top of a foundation model developed by one of the major AI companies, then customised for a specific purpose.

A model card describes the foundation model. It says nothing about what a vendor has done to customise, fine-tune, or configure that model for their specific product. When a hiring tool vendor says their product is "powered by leading AI," they are relying on the safety properties of the underlying model. However, everything they have added on top is a separate question that the foundation model's card does not answer.

This means that for any AI product your business considers adopting, there are two layers of documentation you should request:

The model card for the foundation model to understand the base capabilities and risks of the AI the product is built on
The vendor's own documentation explaining what customisation was applied, what data was used, and what additional testing was conducted on the finished product.

A vendor that can supply the first but not the second has essentially told you that their governance stops at the layer they did not build.

When Should Your Business Ask for a Model Card?

Not every AI tool warrants the same level of scrutiny. A spell-checker or a document formatting tool carries very different risks from an AI system that screens job applicants, assesses creditworthiness, or flags customer transactions.

As a general rule, request model card documentation and apply serious diligence to reviewing it whenever an AI tool will:
Make or influence decisions that affect individuals (hiring, lending, insurance, access to services)
Process sensitive personal information including health data, financial data, or information about protected characteristics
Operate autonomously or semi-autonomously without a human reviewing every output
Be used in a regulated industry or for a regulated purpose

For these use cases, the absence of model card documentation should be treated as a significant red flag. It means either the vendor does not know what their AI tool actually does, or they do not want you to know.

Practical Steps for Small Businesses

You do not need to be a technology expert to use model cards effectively. Start with these straightforward questions when evaluating any AI tool:

Does a model card exist? If not, ask why, and consider whether you are comfortable proceeding without one.
Who produced it? Was it the foundation model developer, the vendor, or an independent party? Understand whose interests the document reflects.
Does it address your specific use case? A model card that describes general capabilities without addressing the domain you are deploying into (e.g. employment screening) is of limited value.
What limitations and risks does it acknowledge? A document that identifies no significant risks or limitations is probably incomplete. Candour about limitations is a positive sign, not a negative one.
Has bias been tested? For any tool used in decisions affecting people, bias testing results should be present, specific, and disaggregated by relevant characteristics.
What happens when it gets it wrong? Who is responsible, and what is the process for identifying and correcting errors?

Asking these questions, and paying attention to the quality of the answers, will tell you considerably more about a vendor's governance maturity than any marketing material.

The Bottom Line

Model cards are an important step toward transparency and accountability in AI. The best examples are detailed, candid, and regularly updated and provide genuine insight into what an AI system can do, what risks it poses, and what a developer has done to address those risks. They represent the current industry standard for responsible AI disclosure.

But model cards are not a guarantee. They are self-reported, they describe the foundation model rather than every product built on top of it, and they are no substitute for your own governance processes once an AI tool is deployed in your business. The responsibility for decisions made using AI, and the accountability for their consequences, ultimately sits with the organisation that chose to deploy it.

Understanding what model cards can and cannot tell you is the first step to making that responsibility a manageable one.