Phase 5: Pre-Deployment Validation — Owner & Outputs
Phase 5 runs during Weeks 16 to 20. The Conformity Assessment Coordinator owns this phase, with support from the AI System Assessor and Technical SME.
The objective is to validate the complete system in a production-representative environment and compile the AISDP. The system is deployed to staging, where end-to-end inference tests, regression tests, and chaos/fault injection tests are executed against production-representative data. Performance, fairness, and robustness metrics are computed and compared against AISDP-declared thresholds.
The AISDP is compiled from the artefacts produced during development. Each module is populated from corresponding engineering artefacts rather than written from scratch. The Conformity Assessment Coordinator reviews each module for completeness and consistency. The internal conformity assessment (Annex VI) is then conducted in three workstreams : a QMS assessment verifying compliance with Article 17 per Annex VI(a), a technical documentation assessment examining the AISDP to assess whether the system complies with Articles 8 through 15 per Annex VI(b), and a consistency assessment tracing from the AISDP to source artefacts. Non-conformities are recorded and remediated.
The operational oversight framework is also established during this phase. Monitoring infrastructure is configured, alerting thresholds are set, escalation procedures are documented, break-glass procedures are tested, and operator training is completed.
Key outputs
- Complete AISDP (all twelve modules)
- Internal conformity assessment report
- Non-Conformity Register (all items resolved or accepted with rationale)
- Assessment evidence register
- Operational oversight readiness confirmation
- Operator training and certification records
Phase 5: Governance Gate (Critical NC Resolution)
Phase 5 concludes with a governance gate: the AI Governance Lead reviews the assessment report and non-conformity register before signing the Declaration of Conformity.
Non-conformities are classified by severity. A critical non-conformity means the system cannot be placed on the market until it is resolved. A major non-conformity allows continued operation under a defined remediation timeline; the Technical SME must resolve it or secure an approved remediation plan with a timeline that does not extend beyond deployment. A minor non-conformity is an improvement opportunity that does not block deployment.
Each non-conformity carries a root cause analysis, a corrective action plan, an assigned owner, a deadline, and a verification step confirming that the corrective action was effective. The AI Governance Lead must confirm that all critical non-conformities have been resolved and that major non-conformities have approved remediation plans before signing the Declaration of Conformity.
The Declaration is a legally binding statement issued under Article 47, containing the eight elements specified in Annex V: provider identity, system identification, a statement of sole responsibility, a conformity statement citing the AI Act and any other applicable Union law, a statement of GDPR and data protection compliance where personal data is processed, references to relevant harmonised standards or common specifications used, notified body details where applicable, and the signatory’s name, function, date, and signature. Where harmonised standards under Article 40 have not yet been published for a given requirement, common specifications adopted under Article 41 may be applied instead; the Declaration should reference whichever instruments were used. Signing carries material legal consequences. The Declaration must be retained for ten years after the system is placed on the market.
Key outputs
- Signed Declaration of Conformity
- Fully resolved Non-Conformity Register
Phase 5: Three Assessment Workstreams
The internal conformity assessment under Annex VI proceeds through three workstreams, typically sequenced across five execution phases.
Workstream 1: QMS Assessment. Verifies that all Article 17 elements are operational. The assessor examines document control, change management, non-conformity management, and continual improvement mechanisms. The QMS is the organisational framework that ties all technical controls into a governed, auditable process. ISO/IEC 42001:2023 (AI Management System) provides the most directly relevant framework, with a control set that aligns with the EU AI Act’s requirements.
Workstream 2: Technical Documentation Assessment. Examines the AISDP against Articles 8 through 15 and Annex IV. For each requirement, the assessor records the evidence demonstrating compliance, the determination (conformant, non-conformant, or partially conformant), and any conditions or recommendations. The assessment checklist should be granular; each sub-requirement of each Article should be a separate item with its own evidence requirement.
Workstream 3: Consistency Assessment. Traces from the AISDP to source artefacts. The assessor verifies that each referenced artefact exists, is accessible, is the correct version, and supports the claim it is cited for. Live system verification examines whether the deployed system’s behaviour matches the documentation. Stakeholder interviews with the Technical SME, Business Owner, and Operators verify architecture, testing, deployment, intended purpose, and override capability.
Assessment documentation is distinct from the AISDP itself. It comprises the assessment plan, the structured assessment checklist, the evidence register, the Non-Conformity Register, and the formal assessment report. A pre-assessment readiness review determines whether the system is mature enough to undergo assessment, avoiding the demoralising cycle of premature assessment, mass non-conformity, and re-assessment. provide detailed guidance on readiness criteria and the pre-assessment review process.
Key outputs
- QMS assessment findings
- Technical documentation assessment findings
- Consistency assessment findings
- Assessment report with overall determination