Checklist: AI Pilot-to-Production Stage-Gate Review (G0 to G5)

This is a ready-to-use stage-gate checklist for scaling a GxP AI system. Replace every <<FILL: ...>> placeholder with your own specifics and route each gate review through your normal quality and project governance. A worked filled specimen of one gate follows the blank checklists. Adapt the gate names and approvers to your own quality system; the point is that nothing advances until the prior gate is genuinely cleared.

The stage-gate structure prevents two opposite failures: rushing an unready system into production, and letting a promising pilot drift because no one defined what ready means. Each gate is a decision with explicit entry criteria and a named approver. The most damaging abuse is starting a build before the performance specification is locked, which leads to writing acceptance criteria after seeing the result. Locking the spec at G1, before the production model is trained at G2, structurally prevents that.

Document control header

How to use: at each gate, mark every item Pass, Fail, or N/A with evidence, then the named approver signs the gate decision. A single Fail on a required item holds the gate. Record the decision and date in the gate summary line.

G0 Feasibility (pilot)

Goal: prove the idea works on representative data. Approver: <<FILL: Sponsor / System Owner>>.

• Documented pilot result exists (metric, data used, method).
• Candidate intended-use statement drafted.
• Rough risk class proposed (advisory, human-confirmed, or automated-acting).
• A real business need and owner identified.
• Gate decision: <<FILL: Advance / Hold>>, approver, date.

G1 Definition

Goal: lock what will be built and to what bar. Approver: <<FILL: System Owner + QA>>.

• Intended-use statement finalized and approved.
• Risk class determined with a documented ICH Q9(R1) based rationale.
• Performance specification written into requirements, with the threshold and its justification, before any production model is trained.
• Data sources identified and their integrity and access assessed.
• Metric choice matches the risk (for example recall prioritized where a miss is the dangerous failure).
• Gate decision: <<FILL>>, approver, date.

G2 Build

Goal: build the validated pipeline and the production model. Approver: <<FILL: Validation lead + QA>>.

• Data pipeline built and qualified: extraction, transformation, training, and deployment steps tested and reproducible.
• Training-serving preprocessing is a single shared implementation (no skew).
• Model trained and meets the G1 performance spec on a locked, held-out, time-split test set touched once.
• Model registry populated with lineage (code commit, dataset version, parameters, metrics, approval status).
• The spec was not changed to match the result.
• Gate decision: <<FILL>>, approver, date.

G3 Validation

Goal: assemble and verify the evidence. Approver: <<FILL: QA>>.

• Validation executed and documented against the approved protocol.
• Monitoring built and configured (drift, override rate, output mix, plus a labeled-sample cadence) with predefined triggers and responses.
• Predetermined change control plan approved, classifying anticipated changes and their testing.
• Human-review step defined, with reviewers trained on the model’s known weaknesses.
• Traceability complete from intended use to requirements to the deployed model version to test evidence.
• Defined fallback for model unavailability or failure, considered in the risk assessment.
• Gate decision: <<FILL>>, approver, date.

G4 Release

Goal: go live under control. Approver: <<FILL: QA release decision>>.

• Acceptance checklist fully evidenced from the file, not from memory.
• Monitoring is live before the model serves a single real decision.
• Deployment path is controlled and reversible (shadow or canary with a rollback to the last validated version).
• Owners, support and on-call model, and fallback all named.
• Training complete for reviewers and operations.
• Documented QA release approval recorded (not an automatic metric trigger).
• Gate decision: <<FILL>>, approver, date.

G5 Operate

Goal: keep it in a validated state. Approver: <<FILL: System Owner + QA, ongoing>>.

• Monitoring running and reviewed on cadence; alerts actioned per the defined response.
• Periodic review performed on schedule.
• All model changes routed through the predetermined change control plan or full change control.
• Drift responses and retraining events recorded as GxP records.
• Vendor base-model or dependency changes detected and handled as changes not initiated by the team.
• Gate decision (periodic): <<FILL: remains in validated state / action required>>, approver, date.

Acceptance criteria

• No stage started before the prior gate was cleared with evidence.
• The performance spec was locked at G1 and unchanged through G2.
• Monitoring was live before first real use at G4.
• Every gate decision has a named approver and a date.
• G5 is treated as an ongoing stage with its own criteria, not a finish line.

References

21 CFR Part 11 and EU GMP Annex 11 for the electronic records and controls the system produces. ICH Q9(R1), Quality Risk Management, for the risk classification. GAMP 5 Second Edition, ISPE, for the risk-based validation approach (referenced by title). FDA guidance on predetermined change control plans for AI-enabled device software functions, as a source concept for the change plan; document your own controlled approach for manufacturing and quality AI.

Confirm the current version of each reference before issue.

Revision history

Approvals

Filled specimen: G1 Definition gate for a deviation-triage model

The following shows a completed G1 review, so you can see the level of evidence expected at a gate. The use case and details are illustrative; replace them with your own.

Use case: a text classifier that assigns a preliminary criticality tier to each new deviation; the tier sets the investigation timeline and a QA reviewer confirms or overrides it within one business day.

In this example the performance specification, including the 0.90 recall threshold and its justification, was written and approved before any production model was trained, so the team cannot later fit the acceptance criteria to whatever the model happened to achieve. That single control is the main reason the gate exists.

Common failures this checklist prevents

• The build starts before the performance spec is locked, so the acceptance criteria end up fitted to the result.
• A pilot metric is treated as the finish line and the system is promoted with no pipeline, monitoring, or change control.
• Monitoring is switched on after go-live rather than before first real use.
• The Operate stage is abandoned, and the system drifts out of its validated state unnoticed.
• Gate decisions have no named approver, so no one actually owned the go or no-go.

How to adapt this checklist

1. Align the gate names and approvers to your own project and quality governance.
2. Add use-case-specific entry criteria where your risk assessment demands them.
3. Keep the completed gate reviews as controlled records in the validation file.
4. For a generative or LLM system, add G2 and G3 items for prompt and retrieval version control and an evaluation harness, per your AI validation approach.