The Seven Phases: Discovery Through Continuous Compliance

Phase 1 spans Weeks 1 to 3 and determines whether the system falls within the AI Act's scope, classifies its risk tier, and produces the Classification Decision Record. The AI System Assessor examines the system against the Article 3(1) definition of an AI system. If the system meets the definition, the Assessor classifies it against the risk tiers: prohibited under Article 5, high-risk under Articles 6 to 7 and Annex III, limited risk under Article 50, or minimal risk.

For systems falling within Annex III categories, the Assessor evaluates the Article 6(3) exception by testing the functional criterion and the risk criterion separately. The functional criterion covers whether the system performs narrow procedural tasks, improves the results of previously completed human activities, or detects decision-making patterns without replacing human assessment. The risk criterion covers whether the system poses a significant risk of harm to health, safety, or fundamental rights. Both criteria must be satisfied for the exception to apply.

The Classification Reviewer independently reviews the Assessor's determination, providing a separate assessment that either confirms or challenges the classification. Disagreements between the Assessor and the Reviewer are escalated to the AI Governance Lead for resolution.

Phase 1 produces three artefacts: the Classification Decision Record including the system's description, the classification determination with rationale, the Article 6(3) assessment where applicable, and the evidence supporting the classification; the initial risk profile identifying the regulatory obligations triggered by the classification; and the evidence pack containing the source materials that informed the classification decision. The phase gate requires the AI Governance Lead to approve the CDR before Phase 2 begins, ensuring that the classification has governance-level endorsement before resources are committed to the system's development.

Phase 2 spans Weeks 2 to 6 and conducts the comprehensive risk assessment that informs all subsequent design and development decisions. The Technical SME and AI System Assessor conduct the five-method risk identification covering FMEA, stakeholder consultation, regulatory gap analysis, adversarial red-teaming, and horizon scanning. The risk register is established, with each risk scored across four dimensions: health and safety, fundamental rights, operational integrity, and reputational exposure. Residual risk acceptability is assessed against Article 9(4)'s standard of reduction as far as possible.

For deployers of high-risk systems, the Fundamental Rights Impact Assessment required by Article 27 is conducted in parallel. The fria examines the impact on all potentially affected EU Charter rights, with particular attention to intersectional effects. The reputational risk framework assesses customer, market, regulatory, shareholder, and employee dimensions for each technical risk.

Phase 2 produces four key artefacts: the risk register populating aisdp Module 6 with each risk scored and its mitigation documented; the FRIA report populating Module 11 with the fundamental rights assessment for deployer contexts; the reputational risk assessment covering five dimensions of reputational exposure; and the risk mitigation plan with assigned owners and timelines for each mitigation action. The phase gate requires the AI Governance Lead to review the risk register, assess whether the residual risk profile after mitigation falls within the organisation's risk appetite, and accept the profile before development resources are committed.

Phase 3 spans Weeks 4 to 8 and designs the system architecture informed by the risk assessment, selects the model approach, and establishes the data governance framework. The Statement of Business Intent is drafted and approved. The ethical foundation and transparency commitment are documented.

Model selection is conducted using the compliance criteria: documentability, testability, auditability, bias detectability, maintainability, and determinism. The full spectrum of decisioning approaches is evaluated covering heuristic systems, statistical models, neural networks, and LLMs. Model origin risk, copyright risk, and nation-alignment risk are assessed.

The layered architecture is designed with per-layer compensating controls against intent and outcome drift. The data governance framework is established including dataset documentation requirements, data lineage infrastructure, fairness assessment methodology, and special category data handling procedures. Version control strategy, CI/CD pipeline design, and infrastructure-as-code approach are defined. The cybersecurity threat model is developed using STRIDE/PASTA.

Phase 3 produces the Statement of Business Intent approved by the AI Governance Lead and Business Owner, the model selection rationale document populating AISDP Module 3, the system architecture document with dependency maps also populating Module 3, the data governance plan populating Module 4, the version control and CI/CD design populating Module 2, and the cybersecurity threat model populating Module 9.

Phase 4 spans Weeks 6 to 18 and is the longest phase, building the system in accordance with the approved architecture with compliance evidence generated as a natural byproduct of the engineering workflow. Development follows the approved architecture using version-controlled code, model, and data artefacts. The CI/CD pipeline enforces quality gates at every commit: static analysis including AI-specific rules, unit testing, contract testing between services, dependency and licence scanning, and secret detection.

Data engineering follows the pre-step/post-step capture methodology with each transformation documented before execution and verified after execution. Dataset documentation is maintained continuously. Model training, validation, and testing follow the documented methodology. Performance, fairness, robustness, and calibration metrics are computed and recorded. The model validation gate blocks promotion of any model failing to meet AISDP-declared thresholds.

The human oversight interface is developed with automation bias countermeasures, mandatory review workflows, and override capability. The explainability layer is implemented with fidelity validation. Cybersecurity testing is integrated throughout: SAST and DAST in the CI pipeline, dependency scanning, container image scanning, and infrastructure-as-code scanning. Adversarial ML testing covers adversarial examples, data poisoning simulations, and prompt injection testing where applicable.

Phase 4 continuously produces version-controlled code, model artefacts, and dataset versions alongside automated test reports covering unit, integration, regression, fairness, and robustness testing. Model cards are auto-generated from the CI pipeline's evaluation results. Data quality reports are produced at each data transformation stage. Training pipeline logs and metadata provide the reproducibility evidence for AISDP Module 2. Cybersecurity scan results and remediation records are retained for Module 9. The feature registry with proxy variable assessments documents each feature's correlation with protected characteristics.

Phase 5 spans Weeks 16 to 20 and validates the complete system in a production-representative environment while compiling the AISDP. The system is deployed to staging. End-to-end inference tests, regression tests, and chaos/fault injection tests are executed against production-representative data. Performance, fairness, and robustness metrics are compared against declared thresholds.

The AISDP is compiled from the artefacts produced during development, with each module populated from the corresponding engineering artefacts rather than written from scratch. The Conformity Assessment Coordinator reviews each module for completeness and consistency against the Annex IV requirements.

The internal conformity assessment under Annex VI is conducted in three workstreams. First, a QMS assessment verifies that all Article 17 elements are operational, documented, and evidenced. Second, a technical documentation assessment examines each AISDP module against Articles 8 through 15 for content completeness, evidence sufficiency, consistency, and currency. Third, a consistency assessment traces from the AISDP to the source artefacts, verifying that the documentation accurately describes the system as built. Non-conformities are recorded in the Non-Conformity Register and remediated.

The operational oversight framework from the oversight pyramid is established: monitoring infrastructure is configured, alerting thresholds are set, escalation procedures are documented, break-glass procedures are tested, and operator training is completed. Phase 5 produces the complete AISDP, the internal conformity assessment report, the Non-Conformity Register with all items resolved or accepted with documented rationale, the assessment evidence register, operational oversight readiness confirmation, and operator training records. The AI Governance Lead reviews the assessment report and signs the Declaration of Conformity.

Phase 7 is ongoing and maintains the system's compliance posture throughout its operational lifetime through continuous monitoring, periodic review, and responsive action. The PMM system operates continuously, collecting performance, fairness, data drift, operational, and human oversight metrics. Alerts are generated and triaged according to the severity framework.

The AI Governance Lead convenes quarterly PMM review meetings examining monitoring trends, operator escalation patterns, deployer feedback, complaint volumes, and the non-conformity register. The Internal Audit Assurance Lead conducts an annual oversight audit testing monitoring infrastructure, escalation pathways, break-glass procedures, training currency, and non-retaliation commitments.

Serious incidents are detected, triaged, reported, investigated, and remediated in accordance with the Article 73 process. Evidence is preserved and systems are not altered prior to authority notification. System changes are managed through the version control and CI/CD framework, with each change assessed against the substantial modification thresholds. Changes crossing the threshold trigger a new conformity assessment cycle returning to Phase 5. Changes below the threshold are documented in Module 12.

Regulatory developments are monitored by the Legal and Regulatory Advisor: new guidance from the AI Office, enforcement actions taken by competent authorities against comparable systems, harmonised standards publications that may change the compliance baseline, and amendments to the Act's Annexes that could affect the system's classification or obligations. Each development is assessed for its impact on the system's compliance posture and, where relevant, triggers AISDP updates, reclassification reviews, or operational changes.