COMPEL Certification Body of Knowledge — Module 1.2: The COMPEL Six-Stage Lifecycle
Article 22 of 22
Every AI system deployment is a governance decision, not merely an engineering event. The decision to move a system from development into production use — where it will affect real people, generate real consequences, and carry real accountability — is one of the most consequential decisions in the AI governance lifecycle. It deserves the rigor that consequential decisions deserve.
The Deployment Readiness Checklist is the instrument through which that rigor is applied. It aggregates the verification work done across the entire COMPEL lifecycle into a single, structured go/no-go decision gate. Before any AI system governed under the COMPEL framework is deployed into production, the Checklist must be completed, reviewed, and approved by the designated deployment authority. A system that cannot satisfy the Checklist's criteria is not ready for deployment — regardless of schedule pressure, stakeholder enthusiasm, or competitive urgency.
This article provides a complete guide to the Deployment Readiness Checklist: its structure, the three readiness domains it covers, the stakeholder sign-off requirements, and the go/no-go decision framework that translates Checklist results into deployment decisions.
Purpose and Governance Context
The Deployment Readiness Checklist (TMPL-P-004) is a mandatory Produce-stage artifact. It is owned by the CoE Lead and must be completed in collaboration with the Business Unit AI Lead, the Model Risk Manager, and representatives from Legal, IT Security, and Operations. Formal sign-off is required from each of these parties before the Checklist can be submitted to the deployment authority.
The Checklist does not duplicate the detailed verification work done in the governance artifacts that precede it. It does not re-perform the validation assessments documented in the Validation Report or re-examine the risk findings in the Risk Register. It verifies that that work was done, that it met the required standards, and that any issues it identified have been resolved or formally accepted. The Checklist is a verification-of-completeness instrument, not a first-pass review instrument.
This distinction matters operationally. Practitioners who treat the Checklist as a substitute for the upstream governance work — checking boxes without the underlying artifacts to support them — are committing a governance failure that may not become visible until an incident occurs. The Checklist's value depends entirely on the integrity of the evidence it references.
Domain 1: Technical Readiness
Technical readiness verifies that the AI system functions as intended and that the technical infrastructure for its production operation is in place.
Model performance verification. The system's performance metrics on the validation dataset must meet all thresholds specified in the system's performance requirements. The Validation Report (TMPL-M-004) must be complete, signed by the Model Risk Manager, and reflect the current model version — not a previous version that has been subsequently modified. Any performance threshold exceptions that were granted during validation must be recorded with their rationale and approval authority.
Infrastructure readiness. The production infrastructure — compute, storage, network, monitoring, logging — must be deployed, tested, and verified to meet the system's operational requirements. Load testing results must confirm that the infrastructure can sustain peak demand. Failover and disaster recovery configurations must be tested. The infrastructure team must have provided written confirmation of production readiness.
Security assessment completion. A security assessment of the deployed system must be complete. For systems processing personal data or operating in sensitive contexts, a penetration test is required. Findings from the security assessment must be remediated or formally accepted with risk acceptance documentation signed by the appropriate risk authority. Open critical or high findings that are not formally accepted are a hard stop — they must be remediated before deployment.
Integration testing completion. All integrations between the AI system and the systems it interacts with in production — data sources, downstream systems, monitoring infrastructure, logging pipelines — must have passed integration testing. Test results must be documented and available for review.
Monitoring and alerting configuration. The monitoring infrastructure defined in the Monitoring Plan must be deployed and verified. All alerts must be configured and routed to the correct recipients. A test alert must have been fired and confirmed received by the designated operations team. Monitoring dashboards must be accessible to all parties specified in the Monitoring Plan.
Domain 2: Governance Readiness
Governance readiness verifies that all required governance artifacts are complete, approved, and current, and that all governance bodies have discharged their responsibilities in relation to this deployment.
Mandatory artifact completion checklist. Every governance artifact required for this system's risk tier and autonomy classification must be present in the governance repository, in its final approved version, and current as of the current model version. The artifact checklist includes: AI Ambition Statement (if this is the first system deployed), System Classification Record, Privacy Impact Assessment (if applicable), Algorithmic Impact Assessment (if applicable), Risk Register, Validation Report, Control Requirements Matrix cross-reference, Agent Autonomy Classification (if applicable), and Workflow Redesign Documentation.
Any mandatory artifact that is missing, in draft, or based on a prior model version is a hard stop. Draft artifacts do not satisfy governance requirements.
Risk acceptance documentation. Every identified risk that is accepted rather than remediated must have formal risk acceptance documentation: the risk description, the risk rating, the rationale for acceptance rather than remediation, the conditions or controls that make acceptance appropriate, and the signature of the risk authority at the level required for risks of this severity. Open risks without acceptance documentation are a hard stop.
Ethics review completion. The Ethics Review Board must have reviewed the system and issued its finding. If the Ethics Review Board identified concerns requiring mitigation, evidence that the mitigations have been implemented must be present in the governance repository. A finding that recommends against deployment — a formal ethics objection — is a hard stop that requires escalation to the AI Governance Committee before deployment can proceed.
Regulatory compliance confirmation. Legal counsel must have confirmed in writing that the system's deployment complies with all applicable regulations, including data protection law, sector-specific AI regulations, and employment law (for systems affecting employment decisions). Any regulatory open items must be documented with their resolution plan and timeline.
Governance body approvals. The deployment authority for this system's risk tier must have reviewed and approved the deployment. For Tier 1 systems, the Business Unit AI Lead may serve as deployment authority. For Tier 2 systems, the CoE Lead must approve. For Tier 3 systems, the AI Risk Committee must approve. For Level 4 autonomous systems, the AI Governance Committee must approve regardless of tier.
Domain 3: Operational Readiness
Operational readiness verifies that the people and processes required to operate the AI system in production are in place and prepared.
Operations team readiness. The team responsible for monitoring and maintaining the system in production must have received all required training. Training completion must be documented. The team must have access to the run book — the operational documentation specifying procedures for routine operation, issue investigation, escalation, and rollback. The run book must be complete, tested for accuracy, and stored in a location accessible to all operations team members.
User readiness. The employees who will interact with the AI system as part of their work — reviewing its outputs, acting on its recommendations, or operating alongside it — must have received training appropriate to the system's autonomy level and their role. For Advisory-level systems, training should cover how to critically evaluate AI recommendations and avoid automation bias. For Delegated-level systems, training should cover the scope boundaries, escalation triggers, and intervention procedures. Training completion rates must meet the threshold specified in the deployment plan (typically 100% for roles with direct AI interaction responsibilities, 80% for roles with indirect interaction).
Incident response readiness. The incident response procedure for this system must be documented, communicated to all relevant parties, and tested through at least a tabletop exercise. The incident response team must know their roles. Escalation contacts must be confirmed current. Communication templates for internal escalation, external disclosure (if required), and regulatory notification (if required) must be prepared and reviewed by Legal.
Rollback procedure readiness. As specified in the Workflow Redesign Documentation, rollback procedures must be tested and the operations team must have confirmed readiness to execute them. The interim manual process that would operate during a rollback period must be staffed and ready. Any additional resources required during a rollback — temporary staff, manual processing capacity, external support — must be identified and contracted or pre-arranged.
Stakeholder communication. All stakeholders who need to know about the deployment — internal stakeholders affected by the workflow change, external stakeholders whose experience will change, regulators who require notification — must have been notified or must be scheduled for notification consistent with the deployment plan. Post-deployment communication plans must be prepared and ready to execute.
Stakeholder Sign-Off
The Deployment Readiness Checklist requires explicit sign-off from each of the following parties before it can be submitted to the deployment authority:
- CoE Lead — confirms governance artifact completeness and overall governance readiness
- Business Unit AI Lead — confirms operational readiness and workflow integration
- Model Risk Manager — confirms technical readiness and validation completion
- Legal Counsel — confirms regulatory compliance and risk acceptance documentation adequacy
- IT Security Lead — confirms security assessment completion and infrastructure security
- Operations Lead — confirms monitoring, alerting, run book, and incident response readiness
Sign-off is not a formality. Each signing party is attesting, personally and professionally, that they have reviewed the evidence in their domain and that it is sufficient to support deployment. Organizations should ensure that signing parties understand this accountability and have adequate time to conduct genuine reviews before signing.
The Go/No-Go Decision Framework
When the completed Checklist and all sign-offs are assembled, the deployment authority makes the go/no-go decision. This decision framework provides structure for that decision.
Go: All Checklist items are verified complete, all hard stops are resolved, and all sign-offs are obtained. Deployment may proceed on the scheduled date.
Conditional Go: All hard stops are resolved and all sign-offs are obtained, but one or more non-critical items are incomplete. The deployment authority may approve deployment with conditions — specific items that must be completed within a defined post-deployment period, with a commitment from the responsible owner and a verification date. Conditional approvals must be documented with the specific conditions and their resolution timeline.
No-Go: One or more hard stops remain unresolved, or one or more sign-offs are withheld. Deployment must not proceed. The deployment authority must convene a resolution meeting within 48 hours to identify the steps required to resolve the hard stops and reschedule the deployment gate review. Schedule pressure does not override a No-Go decision. An organization that deploys a system despite an unresolved hard stop has made a governance decision — it has accepted the risk of deploying an inadequately governed system — and that decision must be made explicitly, documented, and escalated to the AI Governance Committee.
Abort: The deployment authority determines, based on the Checklist review, that the system is not fit for production deployment and that the issues identified cannot be resolved through a focused remediation effort. The system is returned to the Model stage for fundamental rework. This is a rare outcome but must be treated as a legitimate governance option — not a failure but a success of the governance process.
Relationship to the COMPEL Lifecycle
The Deployment Readiness Checklist is the final artifact of the Produce stage and the entry point to the Evaluate stage. A system that passes the Checklist gate enters production and begins the Evaluate-stage monitoring and measurement processes. The monitoring plan activated at deployment is the same monitoring plan that was specified in the Control Requirements Matrix and verified in the Checklist.
The Checklist also creates a documented baseline for future governance reviews. When an AI system undergoes significant modification — a model update, an extension of its deployment scope, or an upgrade of its autonomy level — the Checklist must be re-executed for the modified system. The prior Checklist serves as the baseline against which the new Checklist is compared, enabling reviewers to confirm that no governance capabilities have regressed.
Cross-References
- Article 5: Produce — Deploying AI Responsibly — Produce stage governance objectives
- Article 14: Mandatory Artifacts and Evidence Management — artifact lifecycle and evidence chain requirements
- M1.2-Art19: Building the Control Requirements Matrix — the control framework verified at deployment
- M1.2-Art20: Agent Autonomy Classification Framework — autonomy levels that determine deployment authority and Checklist items
- M1.2-Art21: Workflow Redesign Documentation — the rollback procedures and operational readiness work verified in this Checklist
- Article 6: Evaluate — Measuring Transformation Progress — the Evaluate stage that begins when this Checklist is passed