Model Cards for GxP AI: The One-Page Record That Answers an Inspector’s First Questions

Where Model Cards Came From and What They Were Built to Do

Model cards started in research, not in regulation. In a paper presented at the 2019 Conference on Fairness, Accountability, and Transparency, Margaret Mitchell and eight co-authors proposed that released machine learning models should come with a standard piece of documentation describing how they perform. In their words, “Model cards are short documents accompanying trained machine learning models” that report evaluation results across relevant conditions and groups, and that disclose the context in which the model is meant to be used.¹

The paper laid out nine sections: model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats and recommendations. The intended use section asked for primary intended uses, primary intended users, and out-of-scope use cases. The authors worked through two examples, a card for a smiling-face detector and a card for a text toxicity classifier. The toxicity card is a good illustration of the format’s value: it states plainly that the classifier is not intended for fully automated moderation.¹

A companion proposal from the same period did the same thing for data. “Datasheets for Datasets,” by Timnit Gebru and colleagues, argued that every dataset should come with a document recording why it was created, what it contains, how it was collected, and what it is recommended for. It was later published in Communications of the ACM in December 2021.² For GxP teams, the datasheet idea matters because the training and test data fields on a model card are only as good as the records behind them.

How the Format Spread

Model cards became the default documentation format on public model hubs. On Hugging Face, the model card is the README file in each model repository, written in Markdown with a block of structured metadata at the top. Hugging Face’s guidance says the card should describe the model, its intended uses and potential limitations, its training parameters, the datasets used to train it, and its evaluation results, and it links back to the Mitchell paper.³

Wide use did not mean complete use. A study by Weixin Liang, James Zou, and colleagues examined 32,111 model cards on Hugging Face and found uneven content. Across all cards, the limitations section was filled out in 17.4% of cases and the evaluation section in 15.4%, while the training section was filled out in 74.3%.⁴ The study was later published in Nature Machine Intelligence. Put simply, the public cards most often describe how a model was built and least often say how well it works or where it breaks. Those are the two things a GxP reviewer most needs.

Regulators and Health Bodies Have Picked It Up

The format has also reached regulatory guidance, though so far as an option rather than a requirement. FDA’s January 2025 draft guidance on AI-enabled device software functions includes an example model card in Appendix E, with sections for device information, regulatory status, description, performance and limitations, risk management, and development data. FDA is careful about its status: it says it “does not require the inclusion of a model card or a specific model card format, and this example should not be considered a template.”⁵ That guidance is written for medical devices and remains a draft. It is useful context for drug and biologic teams because it shows that FDA has already set out views on what belongs in one.

In health care delivery, the Coalition for Health AI published a draft Applied Model Card in November 2024 for public comment. It describes the card as covering a full AI system in its workflow, not a bare model, and recommends that the developer issue a revised card tied to the software revision number when the uses, risks, key metrics, or training approach change. It also recommends that users ask for updated cards every year.⁶ Both ideas carry over well to GxP work, as later sections show.

Why a GxP Model Card Is a Different Document

A research model card is written by the people who built the model, for anyone who might download it. A GxP model card is written by the regulated company, for the people who must decide whether the model’s use is under control: the quality unit, internal auditors, and inspectors. That change of reader changes almost everything about the document.

It Is a Controlled Record, Not a README

A README can be edited by anyone with access to the repository. A GxP model card describes the configuration of a computerized system used in regulated work, so it falls under the same document controls as any other system documentation. In the United States, 21 CFR 11.10(k) asks for controls over systems documentation, including “Revision and change control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation.”⁷ In practice that means the card has a document number, a revision, an effective date, named approvers, and a home in your document management system. A card that lives only as a wiki page or a slide is not a record anyone can rely on in an inspection.

It Points to Evidence Rather Than Repeating It

The research cards in the Mitchell paper carry their own results. A GxP card should carry only results that already exist in approved records, and it should cite those records by ID. The test report is the evidence. The card is the index to it. This rule keeps the card short, and it removes the most common failure we see: a performance number on a slide or summary that does not match the number in the signed test report.

It Fits on One Page

One page is a discipline, not a formatting choice. If the intended use cannot be stated in a short paragraph, the use is probably not well defined. If the limitations run to two pages, the model is probably being used outside the conditions it was tested for. The one-page limit forces the team to decide what matters. Revision history, signatures, and the full context of use statement can be kept behind the front page in the document system, but the front page has to stand on its own.

What the Card Is Not

Three other documents overlap with the card, and teams often try to merge them. It is better to keep them separate and link them.

The Inspector’s First Questions, Mapped to the Card

No regulator publishes a list of opening questions for AI models. What we can do is read the texts that set expectations and work out what a careful inspector will need to know first. For EU manufacturing, the clearest source is draft Annex 22 to the EU GMP Guide, published for a joint EU and PIC/S consultation that ran from July 7 to October 7, 2025.⁸⁹ It is still a draft. The EMA GMP/GDP Inspectors Working Group’s work plan gives Q4 2026 as the target for providing the European Commission with a final text, which is a handoff, not a publication or an effective date.¹⁰ Even so, its sections on intended use, acceptance criteria, test data, and operation describe the evidence any careful reviewer will look for, and they map closely to card fields.

On the US side, FDA’s January 2025 draft guidance on AI to support regulatory decision-making for drugs and biologics is also still a draft. It notes that a credibility assessment report may be held and made available to FDA on request, giving an inspection as the example, and that detailed plans for life cycle maintenance (such as performance metrics, monitoring frequency, and triggers for retesting) should be available for review as part of a manufacturing site’s pharmaceutical quality system.¹¹ In other words, the reader of your AI documentation may be standing in your facility.

Here are the questions we expect in the first few minutes, the card field that answers each one, and where the proof is kept.

The Fields of a One-Page GxP Model Card

The fields below follow the questions in the previous section. Each one is short. Most are one to three sentences plus a document reference.

1. Identification and Version

Give the model a stable ID and name, the exact version deployed, and a way to prove that the file running in production is the file that was tested. For a supplier model, the version number alone is often not enough. Record a checksum of the model file or the supplier’s build identifier in the configuration record, and put a short form of it on the card. Draft Annex 22 asks for a tested model to be put under configuration control before it is deployed and for effective measures to detect unauthorized change.⁸ The card should also name the host system and its inventory ID, because the model does not run on its own.

2. Supplier

Name the supplier, the product, and the date and ID of your supplier assessment. Draft Annex 22 says documentation for training, validation, and testing should be available and reviewed by the regulated user whether the model was built in-house or provided by a supplier.⁸ Current Annex 11 already asks that documentation supplied with commercial products be reviewed to check that user requirements are met.¹² If the model was built in-house, this field names the team and the development records instead.

3. Intended Use and Context of Use

This is the field most teams want to write at length. Resist that on the card. Write two or three sentences: what the model does, the decision it supports, who acts on its output, and whether it assists or replaces a human step. Then list the out-of-scope uses, which the Mitchell paper made a standard part of the intended use section.¹ Close with the document ID of the full context of use statement. The detailed statement, built from the five parts covered in our earlier article on context of use statements, does the explaining. The card only needs to be accurate and short.

Draft Annex 22 makes a process subject matter expert responsible for the intended use description and asks for it to be documented and approved before acceptance testing starts.⁸ That gives you the approver for this field.

4. Training Data Provenance

State where the training data came from, who labeled it, the time period it covers, and where the record of it is kept. For a supplier model you will often not have the data itself. You can still record what the supplier told you, when, and in which document, and whether you checked it at audit. If the supplier will not describe its training data at all, write that on the card. A missing answer recorded honestly is better than a vague one that falls apart when questioned.

5. Test Data Provenance

Training data tells an inspector how the model learned. Test data tells them whether your claims about its performance are believable, so this field matters more. Record the test data set ID, when and where it was collected, how it was selected, how it was labeled, and how it was kept away from the people and processes that trained the model. Draft Annex 22 is detailed here: test data should be representative of the full sample space of the intended use, stratified to include all subgroups, labeled through a process that ensures a very high degree of correctness, and kept independent of training. It also asks that you record which data was used for testing, when, and how many times.⁸ The card summarizes this in a few lines and cites the records.

6. Performance Metrics and Acceptance Criteria

List each metric, the acceptance criterion set before testing, and the result, with the test report ID. Show the criterion and the result side by side, because an inspector will look first at whether the criterion was fixed before the test was run. Draft Annex 22 asks a process subject matter expert to define acceptance criteria and have them approved before acceptance testing, allows criteria to differ for subgroups, and says criteria should be at least as high as the performance of the process the model replaces.⁸ That last point means the card should also show the baseline: how well the manual process performed, and where that figure came from.

7. Known Limitations

This is the field that public model cards most often leave empty,⁴ and the one inspectors trust most when it is filled in well. List the specific conditions where the model performed worse in testing, the input types it has not been tested on, and the behavior you have seen when it fails. Be concrete: “undercounts merged colonies” is useful, while “performance may vary” tells the reader nothing. Each limitation should link to a control, either a human check or a rule that keeps that input away from the model.

8. Human Oversight

Say who reviews the model’s output, which outputs they review (all, a defined subset, or a sample), what they do when they disagree, and which SOP and training curriculum apply. Draft Annex 22 asks that, where a model gives input to a decision made by a human operator, the intended use include the operator’s responsibility, and that the operator’s training and consistent performance be monitored like any other manual process.⁸ FDA’s draft credibility guidance also links human checks to model risk. Its fill-volume example rates model influence as low because release testing measures fill volume independently, which brings the overall model risk down to medium even though the decision consequence is high.¹¹ The oversight field is where you show that kind of reasoning in one or two lines.

9. Change Control Link

Give the change record that approved the model’s introduction and the change record behind the current card revision. Draft Annex 22 puts the tested model, the system it runs in, and the whole process it supports under change control, and asks that any decision not to retest after a change be fully justified.⁸ Annex 11 already requires changes to computerized systems, including configuration, to follow a defined procedure.¹² Linking the card to change records shows the reader that the card and the system have moved together.

10. Periodic Review Date

Give the date of the last review and the date the next one is due, with the review report ID. Annex 11 asks for periodic evaluation of computerized systems to confirm they remain valid, covering items such as deviations, incidents, upgrade history, and performance.¹² For an AI model, the review should also look at the monitoring data described in draft Annex 22: performance against the defined metrics and whether input data are still within the sample space the model was tested on.⁸

The Header and Footer

Above the fields, put the card ID, revision, effective date, and status. Below them, put the owner roles and approvals: the process subject matter expert, the system owner, and the quality unit. Approvals can be recorded electronically in the document system rather than printed on the page, but the roles should be visible on the card.

A Completed Example: Colony Counting on Environmental Monitoring Plates

The example below is fictional. The company, supplier, product, document numbers, data set sizes, and performance figures were all made up for this article to show the format. They are not drawn from any real system or study, and they should not be used as benchmarks.

The Use Case

A sterile injectables site runs an environmental monitoring program, which FDA’s aseptic processing guidance describes as one of the most important laboratory controls in aseptic processing.¹³ After incubation, plates from the cleanrooms are read and colonies counted. The site has bought an automated plate imaging workstation with a built-in machine learning model that counts colony-forming units (CFU) and classifies each plate as growth, no growth, or undecided.

The grade of the area shapes the oversight design. EU GMP Annex 1 sets “No growth” as the limit for grade A settle and contact plates and notes that “for grade A, any growth should result in an investigation.” It also asks that microorganisms detected in grade A and B areas be identified to species level.¹⁴ So in this fictional design, the model is a second reader for grade A and B plates, and a microbiologist reads every plate. For grade C and D plates, the model’s count is the recorded result, with targeted human review. The model is static (its parameters are fixed) and gives the same output for the same image, which places it within the scope of draft Annex 22.⁸

The Card

What the Example Shows

Look at what the card does not contain. There is no confusion matrix, no image, no explanation of how the model works inside. An inspector who wants those goes to TR-QC-007 or the supplier documentation. What the card does contain is every answer an inspector needs to decide where to look next, and it shows the reasoning in a few lines: the grade A and B design follows from Annex 1’s rule that any growth is investigated, the acceptance criteria are set against a measured manual baseline, and each limitation is tied to a control.

Notice too that the threshold change in Revision 2 is visible on the card. A reader can see that the system changed after first approval, which change record covers it, and that the card was revised at the same time. Hiding that kind of change is what makes inspectors suspicious. Showing it on the front page tells them the company tracks its own changes.

Connecting the Card to the Inventory and the Validation File

A model card on its own is a summary. Its value comes from the links in both directions: up to the computerized system inventory, which tells an inspector the model exists, and down to the validation file, which proves what the card says.

The Inventory Points to the Card

Annex 11 asks that “An up to date listing of all relevant systems and their GMP functionality (inventory) should be available.”¹² When a system contains an AI model, the GMP functionality column should say so. We recommend adding two fields to each inventory entry: a yes or no flag for “contains an AI or machine learning model,” and the card ID or IDs. A system with three models has three card IDs. This keeps the inventory focused on systems, as it should be, while making every model visible from the list an inspector asks for first.

The reverse link matters as much. The card names the host system’s inventory ID, so a reader who starts from the card can find the system’s validation status, owner, and periodic review history. If the two disagree (for example, the inventory shows the host system at software version 5.3 while the card says 5.4), you have found a gap before the inspector does.

The Card Points to the Validation File

Every document ID on the card should resolve to an approved document in the validation file or the quality system. In our example, that is the context of use statement, the test plan, the test data record, the test report, the baseline study, the SOP, the training curriculum, the supplier audit, the change records, and the monitoring report. Draft Annex 22 asks that test documentation be retained along with the intended use description, the characterization of the test data, and the test data itself.⁸ The card is the map to those records.

The Registry, If You Have One

Companies running several models often keep a model registry in their machine learning platform. The registry and the card should share the model ID and version, and the registry entry should hold the card ID. The registry can store far more data than the card. The card’s job is different: it is the version of that data that a process expert and the quality unit have read, agreed with, and approved.

A Simple Reconciliation Check

Once a quarter, or before any planned inspection, run a check that takes less than an hour per model. Confirm that the version and checksum on the card match the configuration record and the running system. Confirm that every document ID on the card resolves to an approved, current document. Confirm that the inventory entry lists the card. Confirm that every change record raised against the host system since the last card revision has been assessed for its effect on the card. Most problems we find in AI documentation reviews would have been caught by this check.

Who Owns Which Field

The card works best when ownership follows knowledge. The process subject matter expert owns intended use, acceptance criteria, known limitations, and human oversight, because draft Annex 22 assigns the intended use description and the acceptance criteria to that role.⁸ The system owner owns identification, version, and the links to the inventory and change records. Whoever ran the testing (a data science team, a validation group, or the supplier under your oversight) drafts the test data and performance fields. The quality unit approves the whole card and owns the reconciliation check.

Supplier Model Cards: What to Accept and What to Rewrite

More suppliers now provide their own model cards, and that is a good development. A supplier’s card is a useful input to your assessment. It is not your card, and it cannot be filed as one, for three reasons.

Why the Supplier’s Card Is Not Enough

First, it describes the model in general, not your use of it. The supplier does not know your process, your subgroups, your baseline, or your human review design. Second, the supplier’s performance figures come from the supplier’s test data. Draft Annex 22 expects test data that represent the full sample space of your intended use, and the regulated user remains responsible for reviewing the documentation whether or not the model came from a supplier.⁸ Third, a supplier’s card is under the supplier’s change control, not yours. It can be updated on the supplier’s website without anyone at your site knowing.

What to Take From It

Use the supplier’s card to fill gaps you cannot fill yourself: training data sources, model architecture, the supplier’s own known limitations, and how the supplier manages versions. Record which supplier card revision you used and when you received it, and keep a copy in your supplier file. Annex 11 says that quality system and audit information about suppliers should be available to inspectors on request.¹² A dated copy of the supplier’s card is part of that.

What to Ask For

The public evidence from Liang and colleagues suggests where supplier cards are likely to be thin: limitations and evaluation.⁴ Ask about those sections directly in your supplier assessment. Ask how the supplier tested the model, on what data, with what labeling process, and what failure patterns it saw. Ask how and when it will tell you about a new model version. The CHAI draft recommends that a revised card be issued, tied to the software revision number, when uses, risks, key metrics, or the training approach change, and that users ask for updated cards every year.⁶ Those are reasonable terms to write into a quality agreement with a GxP supplier.

Keeping the Card True After Go-Live

A model card is accurate on the day it is approved. Whether it stays accurate depends on defining, in advance, which events require a new revision, and connecting those events to processes that already run.

Events That Should Force a New Revision

Draft Annex 22 says any change to the model, the system it runs in, or the process it supports, including changes to physical objects the model uses as input, should be documented and evaluated to decide whether the model needs retesting.⁸ Each of those evaluations should also ask whether the card needs to change. In our experience, these events almost always do:

• A new model version, whether retrained in-house or released by the supplier. The version, checksum, test results, and possibly limitations all change.
• A configuration change that alters behavior, such as a confidence threshold, a decision cutoff, or a preprocessing step.
• A change to inputs: new media, a new camera, a new instrument, a new site, a new product, or a new document type. Each may move inputs outside the tested sample space.
• A change to the human review design, such as reducing the sampling rate after a period of stable performance. This changes model influence and therefore risk.
• A new known limitation found through monitoring, a deviation, or a supplier notice.
• A change of owner for any of the roles named on the card.

Tie the Card to Processes That Already Run

Do not create a separate process for card maintenance. Add one question to your change control impact assessment form: “Does this change affect a model card? If yes, list the card IDs.” Add one item to your periodic review template: “Confirm the model card is current.” Add one line to your deviation and CAPA forms for AI-related events: “Does this event reveal a limitation that should be on the model card?” FDA’s draft credibility guidance describes life cycle maintenance as a set of planned activities, including performance metrics, monitoring frequency, and retesting triggers, kept within the pharmaceutical quality system.¹¹ The card is one of the outputs those planned activities should keep current.

Use Monitoring to Test the Card’s Claims

The card makes claims: the model meets its criteria, inputs stay within the tested range, the limitations are known and controlled. Monitoring is how you check those claims over time. Draft Annex 22 asks for regular monitoring of model performance against its defined metrics and of whether input data stay within the model’s sample space, with metrics defined for input drift.⁸ FDA’s aseptic processing guidance makes a related point about environmental monitoring itself: because false negatives can occur, an increased incidence of contamination over time is as important a trend to track as consecutive growth results.¹³ In our fictional example, the 5% weekly sample of grade C and D plates is the monitoring that tests the card’s claim about missed growth. If the disagreement rate in that sample rises, the card’s performance field is no longer a fair description, and the card needs to change along with the system.

Five Ways a Card Fails in the Room

From reviews of AI documentation, these are the patterns that cause the most trouble when an inspector reads a card:

1. The version on the card is not the version running. Usually the result of a supplier update applied through an IT patch process that never touched quality change control.
2. The acceptance criteria were set after the results came in. The approval date of the test plan is later than the test execution date, or the criteria were edited during testing without a recorded deviation.
3. The limitations field says “none known.” No model tested on realistic data has no limitations. An empty field suggests the testing did not look for them.
4. Human oversight is described as “user review” with no detail. The inspector cannot tell who reviews what, how often, or what happens when the reviewer disagrees.
5. The card cites documents that are drafts, superseded, or missing. Each broken link turns a two-minute read into an hour of searching, and it raises doubts about the rest of the file.

All five can be found by the reconciliation check described above. None needs new technology to fix. They need a process owner who treats the card as a record that must stay true.

Starting Without Waiting for Final Rules

Draft Annex 22 and FDA’s AI guidances are still drafts, and some teams wait for final text before documenting their models. For the card, waiting gains little. The fields come from requirements already in force (Annex 11’s inventory, supplier, change, and periodic evaluation clauses, and Part 11’s controls over system documentation) together with the evidence any reviewer will ask for under any final text. If you have AI models in GxP use today, start with the one that has the highest decision consequence, write its card, and run the two-minute test with someone from quality. The gaps you find will show you what the rest of your documentation needs.

Conclusion

The model card started as a way for researchers to be open about what their models could and could not do. In GxP work, the same idea solves a practical problem: the answers an inspector needs first are already in your records, but they are spread across hundreds of pages and several systems. A one-page card, under document control, with every number traced to an approved record, puts those answers in one place. It also forces discipline on the team writing it. You cannot fill in the limitations field honestly without having looked for limitations, and you cannot fill in the human oversight field without having decided who checks what. Linked up to the computerized system inventory and down to the validation file, the card turns AI documentation from something a team assembles under pressure into something it can hand over in the first minute.

Sakara Digital works with pharma and biotech organizations putting AI models into GxP processes, including the documentation that has to stand up when an inspector asks about them. If you are deciding how to document the models you already have, or want an independent read of a card before an inspection, we are happy to have that conversation.

For Further Reading