Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics -> Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Plan Plug-and-play starting point AI & Automation

Plan: AI Model Credibility Evidence Plan

A plug-and-play credibility evidence plan for a GxP AI or machine-learning model, written and dated before any evidence is gathered: the context of use, the model-risk sizing, the test population and hold-out method, metrics and thresholds, uncertainty treatment, and human-control design, with a filled specimen and the regulations it satisfies.

Document type: Plan

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use credibility evidence plan. It is the document that separates a genuine credibility assessment from a rationalization written after the fact: it commits, in writing and before any evidence is generated, to the population, metrics, thresholds, and human controls that will justify trust in the model for a specific use. The credibility assessment report is written afterward, against this plan. 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. AI-specific guidance is still evolving; confirm each cited reference against the current source before you rely on it, and treat any draft guidance as draft.

Document control header

FieldEntry
Document titleAI Model Credibility Evidence Plan
Document number<<FILL: e.g. AICP-2026-004>>
Version<<FILL: version>>
Date issued<<FILL: date, must predate evidence generation>>
Model name and version<<FILL>>
Author<<FILL: role>>
Approved by<<FILL: role>>

1. Purpose

This plan states, before any credibility evidence is generated, what evidence will be collected for <<FILL: model name>>, at what depth, and against what pre-set thresholds, so that the later credibility assessment report is a comparison against a committed plan rather than a description written to fit whatever the results turned out to be.

2. Context of use

State in one sentence what the model outputs, the decision it feeds, and the accountable role.

<<FILL: e.g. "The model proposes one of twelve complaint categories for each new complaint; the intake analyst confirms or changes the category before the complaint is routed; the analyst owns the final category.">>

If this sentence cannot be written cleanly, the model is not ready for a credibility plan; scope it first.

3. Model risk sizing

FactorAssessmentRationale
Model influence<<FILL: Low / Moderate / High>><<FILL: how much the output drives the decision relative to other evidence and human judgment>>
Decision consequence<<FILL: Low / Moderate / High>><<FILL: severity if the decision based on the model is wrong>>
Resulting risk level<<FILL: Minimal / Moderate / Maximal evidence tier>><<FILL: from the influence x consequence grid>>

Tie this sizing to the model risk assessment under quality risk management and ICH Q9(R1); reference the underlying risk assessment record here rather than re-deriving it.

4. Test population and hold-out method

  • Test population source: <<FILL: e.g. drawn from a later time period than training data, to mimic deployment>>
  • Hold-out method: <<FILL: how the test set is guaranteed never to have been seen during training, tuning, or model selection>>
  • Representativeness: <<FILL: how the test population is confirmed to represent the production population the model will face, by product, site, instrument, or relevant subgroup>>
  • Sample size and basis: <<FILL: count, and the basis for judging it adequate given the base rate of the outcome of interest>>

5. Metrics, thresholds, and subgroup reporting

MetricJustified thresholdReported by subgroup?Rationale for this metric
<<FILL: e.g. recall on safety-relevant class>><<FILL>><<FILL: Yes, by which subgroup / No>><<FILL: why this metric, not fooled by the base rate, matches the consequence of the error type it is meant to catch>>
<<FILL: e.g. precision>><<FILL>><<FILL>><<FILL>>
<<FILL: calibration>><<FILL>><<FILL>><<FILL>>

State the threshold and the metric before measuring. Setting a threshold after seeing the result is not a credibility plan, it is a rationalization with a plan’s formatting.

6. Uncertainty treatment

<<FILL: how uncertainty will be reported, e.g. confidence intervals on each metric, and how a small positive-class count will be flagged as fragile rather than presented as a settled point estimate>>

7. Explainability evidence (if applicable)

<<FILL: what explainability or attribution evidence will be gathered, for which outputs, and how it will be validated as a faithful account rather than a plausible-looking approximation>>. State “not applicable” with a reason if the context of use does not require it.

8. Human-control design

ElementEntry
What the reviewer sees<<FILL>>
What the reviewer checks the output against<<FILL>>
Where the review decision is recorded<<FILL>>
Reviewer qualification / training required<<FILL>>

9. Monitoring commitment

<<FILL: the metrics that will be watched post-deployment, e.g. override rate, input-distribution drift, periodic re-evaluation on labeled production samples>> and <<FILL: the review cadence and the threshold that triggers re-assessment>>.

10. Deviations from this plan

Any change to the population, metrics, or thresholds after this plan is approved must be documented here with a reason, dated, and re-approved before the evidence affected by the change is generated. A plan quietly edited to match a result is not a plan.

DateChangeReasonRe-approved by
<<FILL>><<FILL>><<FILL>><<FILL>>

11. Approvals

RoleNameSignatureDate
Author<<FILL>>
Model owner<<FILL>>
Quality Assurance<<FILL>>

References

ASME V&V 40, Verification and Validation in Computational Modeling of Medical Devices (credibility framework). FDA draft guidance, Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products (January 2025 draft; treat as draft and confirm current status). FDA and EMA, Guiding Principles of Good AI Practice in Drug Development (14 January 2026). ICH Q9(R1), Quality Risk Management.

Confirm the current status and text of each reference, especially the draft guidance, before you rely on it.


Filled specimen

The following shows the plan completed for a model that screens incoming product complaints and proposes a category for an intake analyst to confirm, written before any test-set evidence was generated. The company and figures are illustrative.

FieldEntry
Document numberAICP-2026-004
Version1.0
Date issued02 September 2026
Model name and versionComplaint Category Assistant, v2.3

Context of use: The model proposes one of twelve complaint categories for each new complaint; the intake analyst confirms or changes the category before the complaint is routed; the analyst owns the final category.

Model risk sizing: Influence: Low to moderate (every output reviewed before it has any effect). Consequence: Moderate (a misroute the analyst fails to catch could delay a safety-relevant complaint). Resulting tier: Moderate evidence, per the model-risk assessment MRA-2026-011.

Test population: Drawn from Q3 2026 complaints, a quarter entirely after the training and tuning data cutoff of Q1 2026; hold-out enforced by a date-based split recorded in the data pipeline log, never touched during model selection.

Metrics and thresholds: Recall on the three safety-relevant categories, target 0.95 minimum, because a missed safety-relevant complaint is the failure that matters; precision on those categories, target 0.75 minimum, accepted lower given the recall priority; overall accuracy reported for context only, not as a release criterion; all metrics reported per category, not only in aggregate.

Uncertainty: 95% confidence intervals reported for every metric; any category with fewer than 30 positive test cases flagged as a fragile estimate rather than a settled figure.

Human-control design: Analyst sees the proposed category and a one-line rationale snippet; checks it against the complaint narrative; confirms or overrides in the complaint-handling system, which timestamps and records the decision; analysts complete a defined training module before first use.

Monitoring commitment: Override rate tracked weekly; input-category-distribution drift tracked monthly; a labeled 200-complaint production sample re-evaluated quarterly against the same thresholds; a sustained override rate above 20% on any safety-relevant category triggers re-assessment.

This plan was approved 02 September 2026, before the Q3 test set was scored. The credibility assessment report written afterward compares the actual results against these pre-set thresholds rather than describing whatever the results happened to be.

Common inspection findings this plan prevents

  • A credibility report with metrics and thresholds that appear chosen to match the result, because no dated plan exists showing they were set first.
  • A test population with no documented hold-out method, so a reviewer cannot confirm the evidence is not measuring memorization.
  • A single aggregate accuracy figure standing in for subgroup performance on a use with meaningful subgroup risk.
  • A human-control design described in the final report for the first time, with no evidence it was designed before deployment.

How to adapt this plan

  1. Set your document number, model identity, and issue date; the issue date must genuinely predate evidence generation.
  2. Pull the risk sizing from your model risk assessment rather than re-deriving it here.
  3. Set metrics and thresholds that match the consequence of each error type, not a single convenient aggregate number.
  4. Route through the same approval chain as your validation plans, and treat any post-approval change per section 10, never silently.
  5. Confirm the AI-specific guidance references against their current status before issue.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.