This is a ready-to-use record. It captures, in one controlled document, what an AI or machine learning model is, what it is allowed to decide, the data behind it, how well it performs, where it should not be trusted, and how its continued performance is watched. The model card is the single artifact an inspector, a reviewer, or a future investigator reaches for to understand a model without reading its source code. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it, and note that AI-specific guidance is still evolving, so treat any draft reference as draft.
1. Model identity and version
State whether the model is locked (fixed parameters, same output for the same input) or continuously learning. Almost every defensible GxP model is locked, and a change to the weights is a new version recorded on a new card. If the model calls a vendor base model through an API, pin the version you can and record that the provider may change it under you.
2. Intended use and context of use
Write one plain sentence that names the model output, the action it triggers, and the role accountable for the consequence. If you cannot write that sentence cleanly, the intended use is not yet defined, and nothing downstream can be sized correctly. The use pattern sets the rest of the card: an advisory model that only flags items for a reviewer needs less than a model that drives a manufacturing parameter.
3. Training, validation, and test data
The integrity of the model is bounded by the integrity of the data it learned from. Keep three separate splits: training, validation or tuning, and a locked test set touched once at the end to report the headline number. The test set, ideally drawn from a period after the training data so it mimics real deployment, is the only honest measure. Production data later pulled to retrain the model is itself a GxP record and carries the full ALCOA+ expectations.
State the performance specification that was set before training, then the measured result on the locked test set.
Tie each threshold to the consequence of error. Where a missed positive is the dangerous failure, set a high recall threshold and accept lower precision, then catch the false positives in human review. A single point estimate on a small positive count is fragile, so report a confidence interval or a sensitivity check.
5. Limitations and out-of-scope uses
State, plainly, where the model is not to be trusted. This protects the model from being used outside the conditions it was validated for.
- Known weaknesses:
<<FILL: conditions where performance is lower, e.g. a product line under-represented in training, rare event types>>
- Input boundaries:
<<FILL: data ranges, formats, or languages outside the validated envelope>>
- Out-of-scope uses:
<<FILL: decisions the model must not be used for>>
- Failure mode if used out of scope:
<<FILL: what goes wrong and the safeguard>>
- Dependence on upstream data quality:
<<FILL: what the model assumes about its inputs>>
6. Bias and fairness checks
Even outside a patient-facing setting, a model can systematically underperform on a subpopulation, a site, a product, or an instrument, which is an operational quality risk. Record what was checked.
7. Explainability
Match the level of explanation to the use pattern: a confidence score and top features for an advisory model, a per-decision rationale for an automated classification, a deterministic interlock for process control.
Do not present a post-hoc attribution as a guaranteed causal explanation. Two attribution methods can disagree on the same prediction. State what the explanation does and does not establish; an honest limitation reads better than an overclaim.
8. Monitoring plan
A model with no monitoring is not in a validated state, regardless of how it scored at release, because there is no evidence it still works.
The override or disagreement rate is cheap, continuous, and a strong leading indicator; a rising rate usually shows up before the formal metric review catches it. Define the response in advance, a monitoring system with no defined response is decoration.
9. Acceptance criteria
This model card is acceptable when all of the following are true:
- Model identity, version, and the exact training-data version are recorded and reproducible.
- The intended-use statement names the output, the action, and the accountable role, and the risk class has a documented ICH Q9(R1) based rationale.
- The performance specification was set before training, the headline metric was measured on a locked test set the model never saw, and the spec predates the test report.
- The training-data integrity record is complete: source, lineage, representativeness, labeling, inter-rater agreement, splits, and dataset version.
- Limitations and out-of-scope uses are stated, and bias and fairness across relevant subgroups were checked.
- The explainability entry matches the use pattern and states its own limitations.
- A monitoring plan is live from day one, with triggers and a defined response.
- The card is complete, signed, dated, and approved.
10. References
21 CFR Part 11 (electronic records and signatures) and EU GMP Annex 11 (clauses on risk management, change control, and periodic evaluation).
GAMP 5 Second Edition (ISPE, 2022), including its appendices on AI and machine learning.
FDA “Computer Software Assurance for Production and Quality Management System Software” (draft 2022; final 24 September 2025; current version issued 3 February 2026, which added “Management” to the title; confirm the current version before relying on it).
ICH Q9(R1), Quality Risk Management (2023 revision), for the risk-based sizing.
FDA guidance on a Predetermined Change Control Plan for AI-enabled device software functions (final since December 2024, with the current version issued 18 August 2025), for model-change thinking transferred by analogy. This is a device document, not a manufacturing rule.
The EU AI Act, Regulation (EU) 2024/1689, applies on a phased timeline; confirm whether and when it reaches your use.
Confirm the current version, status, and clause numbers of each reference before issue. Several AI-specific references are evolving or are device documents applied by analogy, so state that in the record rather than presenting them as settled manufacturing law.
11. Approvals
12. Revision history
Filled specimen
The following shows the same record completed for an example deviation-classification model used in a quality system. The company, model, and numbers are illustrative; replace them with your own.
1. Model identity and version
2. Intended use and context of use
Plain-sentence intended use: “The model assigns a preliminary criticality tier to each new deviation, the tier sets the investigation timeline, and the QA reviewer confirms or overrides the tier within one business day and owns the final classification.”
3. Training, validation, and test data
5. Limitations and out-of-scope uses
- Known weaknesses: lower recall on the clinical-only product line, which was under-represented in training.
- Input boundaries: validated on English-language deviation text only.
- Out-of-scope uses: not for adverse-event or complaint classification, not for closing deviations.
- Failure mode if used out of scope: a non-validated population would receive an untrustworthy tier; the QA confirmation step is the safeguard.
- Dependence on upstream data quality: assumes the deviation description field is completed at intake.
6. Bias and fairness checks
7. Explainability
8. Monitoring plan
9. Approvals
In this example the card is dated after the validation report, the performance specification predates the test report, and the test set was held out by time period so it mimics deployment. A reviewer can read the card and know exactly what the model decides, how well, where not to trust it, and how its continued performance is watched, without ever reading the model code.
Common inspection findings this record prevents
- A model is in production but there is no single document an inspector can read to understand what it decides and how well it performs.
- Performance is quoted but the test set was not held out, so the headline metric is inflated by data the model trained on.
- The acceptance criteria are dated after the test report, so the threshold looks fitted to the result.
- The training data has no lineage, labeling SOP, or version, so the model cannot be reproduced or investigated.
- Limitations and out-of-scope uses are not stated, so the model gets used on a population it was never validated for.
- There is no monitoring plan, so the validated state is asserted from release day rather than demonstrated months later.
- A model change happened with no new card and no change control, so the documentation no longer matches the deployed model.
How to adapt this record
- Set your document number, model name and version, and owner in the control header, and confirm the GAMP category against the trained model, not the platform’s marketing category.
- Write the plain-sentence intended use in section 2 first; everything else is sized from it. Set the use pattern (advisory, automated classification, process control) and the matching human control.
- Fill the training-data record in section 3 from your actual extract, labeling SOP, and frozen dataset version, and confirm the test set was held out.
- Enter the performance specification that was approved before training, then the measured result on the locked test set, and keep the dates so the spec visibly predates the test.
- State limitations and out-of-scope uses honestly in section 5; this is what keeps the model from being misused later.
- Match the explainability entry in section 7 to the use pattern, and state the limitations of the explanation method.
- Make the monitoring plan in section 8 live from day one, with triggers and a defined response, and link it to a predetermined change control plan.
- Confirm every regulation in section 10 against its current version and status before issue, and mark any draft or device-applied-by-analogy reference as such.
- Issue a new card version for every model version; the card and the deployed model must always match.
