Model cards: definition, examples, and creation process

A vendor offers an AI demonstration and asks for a signed contract. The model shown in the demonstration has not been examined by anyone beyond the vendor's organisation. Clear information about the training data, the system's limitations, or the party accountable for errors is missing. A model card is the document that supplies these details prior to making a commitment.

A model card is a brief, organised document that describes how a machine learning model functions, its intended purpose, and its shortcomings, resembling a nutrition label more than a sales brochure. It usually includes model details, intended use, training data, performance across groups, ethical considerations, and recommendations for ongoing monitoring.

Shipshape Data constructs data and AI foundations. We often talk about model cards when clients assess vendors or record their own models. This guide describes the contents of a model card and explains why this format has stayed standard since 2018. It provides examples for study and instructions on how to efficiently create a model card.

The definition of a model card

A model card is a brief and organised document. It describes how a machine learning model operates, its intended purpose, and its limitations. This document resembles a nutrition label because it enumerates the model's components, its performance under various conditions, and the particular situations where its results may be unreliable.

Researchers at Google presented this concept in a 2018 paper titled Model Cards for Model Reporting, and the format has become standard because it solves a practical issue. Earlier, most teams either failed to document their models or placed important details in a research paper appendix, where individuals outside the research lab were unlikely to locate them. A model card consolidates essential information: who created the model, the data used for training, how it was tested, and its intended limitations.

Our clients exhibit a consistent pattern whether they build their own models or acquire them from vendors. Teams that record model cards during development make quicker and more informed decisions regarding model reliability. Teams that omit this documentation frequently face issues months later when the model performs poorly on specific data segments that were not previously examined.

Why model cards are necessary for AI projects

Most AI projects fail due to insufficient understanding during deployment rather than flawed model construction. Issues frequently emerge when teams fail to recognise what they are deploying until the system is already live. Even a correctly trained and tuned model may be unsuitable for particular data, users, or regulations. A model card ought to pinpoint these mismatches before they cause an incident.

They lower risk before you commit

A model card details the training data and the model's performance across various groups and conditions. This information enables you to spot common risks early in the process. If a model is trained mainly on a single demographic, language, or image type, it will probably perform poorly when faced with different data. You should examine the performance section relative to your specific population before deploying the model. Doing so helps you prevent issues before they generate complaints.

Model cards also convey information about a model's scope. A fraud-detection model trained on credit card transactions is not intended to score loan applications. Projects frequently fail when users treat these distinct tasks as interchangeable because "it's all classification". The intended-use section is provided to prevent this kind of inappropriate reuse.

They offer a reference point for governance

Compliance and legal teams need visibility into models before they can approve them. Model cards give this visibility by providing structured documentation: they detail who created the model, when it was created, the data used to build it, how it was tested, and its known limitations. When an auditor or regulator inquires about a decision, you want to explain it by referencing specific choices, rather than relying on assurances of careful work.

This becomes increasingly important when an organisation operates multiple models. If a consistent format is absent, each model is evaluated individually by different people using whatever information the original team supplies. A model card turns this process into a repeatable check rather than a new investigation for each case.

A model that works well in one environment may not work well in another. You should use the model card to spot these differences before deploying the model rather than discovering them later.

The components of a model card

The structure that researchers proposed in 2018 remains effective. Most organisations adapt this framework rather than replace it. You do not have to include every section for each model. A functional model card must contain at least some of the following sections. A document that omits all of them serves as promotional material in a technical format.

• Supply the model details. Include the developers' names and the creation date. Specify the version number being documented and the type of architecture the model employs.
• Intended use: the specific applications it was designed for, and the applications that lie outside that scope.
• Training data: its source, the collection method, and the preprocessing steps employed.
• Quantitative performance includes metrics like accuracy, precision, and recall. These data are organised by specific groups or conditions.
• Ethical considerations: concerns about fairness, privacy implications, and the likelihood of misuse.
• Recommendations: the process for monitoring, retesting, and revalidating the model when it encounters new data.

The identification basics

Start with model details covering the basics: who built it, when, what version this document describes, and what type of model it is. Link to a research paper or technical documentation if one exists, and give a contact route for questions, because "figure it out yourself" isn't a governance answer.

Define the intended use clearly. List the specific applications that the model was designed for and state what is outside of that scope. The phrase "A quality-control system" provides very little information to a future team. The description "Detects surface defects on painted metal panels under fixed lighting conditions" explains exactly whether the model is suitable for their specific production line.

Training data and performance

Record the source of the training data, the collection methods used, and the preprocessing steps taken before model training. You are not required to share proprietary pipelines. You must provide enough information for readers to evaluate potential sources of bias.

Performance metrics require honesty. You must report model performance for relevant groups. These groups include demographics, geographies, and device types. You should choose categories based on how the model functions in practice. Include the specific conditions where the model performs poorly. A card that only displays high-performing metrics fails to meet the definition of a model card. This type of document is a highlight reel. Users will face problems because of the missing information.

Ethical considerations and recommendations

Include a section that lists concerns about fairness, privacy risks, and the broader effects of the model during operation. Conclude with specific recommendations for monitoring, retesting, and revalidating the model as it encounters new environments. This section changes the document from a static record into a functional one. Most model cards omit these details because they require analysis instead of simple metadata reporting.

How to build one without losing a week

Creating a model card often seems like a task that should take one afternoon, but it frequently requires three days to complete. This issue is resolved by better scheduling rather than a different template.

Start while you build, not after

Record your decisions as they occur instead of trying to remember them months later. You should document why you selected specific datasets or changed certain thresholds. Write down the training data details, the chosen architecture, and any fairness or performance constraints you established. Save your evaluation results and the specific testing conditions as soon as the tests finish. Teams that follow this documentation process can typically create a complete model card in a few hours after finishing the model. Teams that delay this work must rely on memory, and those guesses are not sufficient for audits.

• At the beginning of a project, record essential information: who is involved, the relevant dates, the problem being addressed, and the version number.
• Record your training data sources and preprocessing decisions on the day you make them. Do not wait until the week before you launch the project.
• Record all evaluation results along with the specific conditions used for each test. You must include the results from runs that did not meet your expectations.
• Finish the ethical considerations and recommendations sections at the end of the process. You will have a better understanding of the model's behaviour at that stage.

Start with a template instead of a blank page

You do not have to create the structure yourself. Google's Model Card Toolkit creates a card using your model's metadata and evaluation results. The template from the original 2018 research paper is a functional starting point. Cloud platforms are also integrating the format into their services. For example, Amazon SageMaker includes model cards so that documentation is a standard part of the development process rather than an extra task at the end. The community model cards on Hugging Face offer a less formal version of this concept. These are effective when your primary audience consists of other engineers instead of a compliance committee.

Pick whichever starting point matches how your organisation works, then adjust the sections to the people who will read it. Legal wants more on data provenance. Product wants performance broken out by user segment. Nobody wants a document written for an audience that doesn't exist.

Examples of effective model cards in practice

You should study several published examples. These documents demonstrate different valid approaches rather than a single correct format.

Meta and Microsoft placed the Llama 2 card in the appendix of the research paper. This document includes specific information on hardware requirements, the carbon footprint, and ethical considerations. It is designed for a technical audience that requires implementation details and governance data. The authors provide a comprehensive amount of information without attempting to shorten the text.

OpenAI's initial GPT-3 documentation uses a different method. It includes brief sections covering model specifics, appropriate applications, data origins, and limitations, along with a straightforward way to submit comments. The design avoids unnecessary elements, and this simplicity may be intentional: the document is likely to be read completely because it requires only five minutes to finish.

Google's face detection model card provides information that the other examples do not. It displays specific failures such as blurry faces and crowded scenes. It shows the actual images where the model has difficulty instead of using an abstract paragraph to describe limitations. A non-technical stakeholder can understand a visual example of a failure more quickly than a sentence about "reduced accuracy under suboptimal conditions".

Hugging Face operates differently. Its community model cards are short documents written by developers. There are hundreds of thousands of these cards because the platform requires one for almost every shared model. Individual cards are sometimes unpolished or contain little information. Taken together, they demonstrate the results of making documentation a standard practice rather than a separate project. The process becomes easier and more consistent over time because users do not have to start from a blank page.

The lesson from these four examples is consistent. You should choose a format that suits your specific reader instead of following a standard template by habit. A document designed for engineers will not be useful to a compliance officer, and a document designed for compliance will not be useful to engineers.

Common mistakes that make a model card useless

We have reviewed many model cards that were created solely for compliance purposes. These documents generally have the same flaws.

• Performance is presented as one overall number. It lacks a breakdown by group, region, or specific condition.
• The intended use was documented after the model had already been deployed for another purpose. As a result, the model card outlines the model's present activities instead of the original design objectives.
• The training data description is overly vague to answer the specific bias questions that this card aims to clarify.
• The model has not been updated since its retraining. Therefore, the card refers to a model version that was replaced eighteen months ago.
• The information resides in a wiki or shared drive that people outside the original team are unaware of how to locate.

Address the final point first, even though it is not interesting. If a model card is high quality yet impossible to locate, it provides no practical value.

Using model cards to evaluate vendors

When a vendor offers an AI product, you should ask for the model card before signing a contract. A complete model card reveals whether the training data is relevant to your specific needs. It also indicates whether the vendor tested the model against groups important to your business and enumerates the known software limitations.

We have attended numerous vendor pitches and understand the implication of vague responses. "We use industry-standard datasets" does not constitute a sufficient answer. A performance figure lacking a supporting breakdown is also insufficient. If a vendor cannot provide a model card, or if the provided card seems to be written by a legal department rather than the developers, treat that as a significant signal.

Comparing vendors side by side becomes more efficient when you use the same document type for each. You can assess training data sources, tested demographics, and known failure modes across three shortlisted tools in a single afternoon. This approach is more reliable than reviewing each vendor's individual claims and hoping the differing information sets are compatible.

Specific questions separate a useful model card from a compliance-only document. You should verify whether the card names the specific datasets or merely describes them as diverse. You should also determine if the performance section provides detailed results beyond the single figure used in sales materials. Check whether the document includes a date and whether that date precedes the model version you are purchasing. If any of these elements are absent, you should request more information before signing a contract.

Making model cards part of how your organisation works

Organisations obtain the greatest value from model cards when they make them a standard requirement. These companies do not wait for an auditor to request documentation. Rather, they require a model card for every model before deployment, irrespective of whether the model was developed internally or purchased from a vendor.

We spend much of our time assisting clients in building the habit of documenting decisions as they happen. This emphasis on process rather than tool selection ensures the organisation maintains an accurate record for future use. Including validation and testing in this record from the start guarantees that the recommendations section is actionable rather than merely a statement of intent. When legal, compliance, and product teams agree on a standard template before shipping the first model, it prevents repeated disputes about documentation quality for each subsequent model.

Get the documentation habit right, then everything downstream is easier

Model cards do not enhance the quality of a model. They help you avoid discovering performance issues after the model is already in production or under regulator review. You should create these cards during the development process instead of treating them as final administrative tasks. This approach makes the rest of your AI governance process easier to manage.

If you want assistance establishing a model card standard across your AI systems, or getting your data into a state where documenting a model does not require contacting multiple teams for unrecorded information, talk to us. We help organisations build the data foundation that makes questions like "what is this model actually doing" easy to answer.

Most AI projects stall because there is a gap between understanding these concepts and applying them effectively. Our AI consultancy helps clients bridge that gap.

Frequently asked questions