The Regulatory Context You're Operating In
The AI Act's staggered timeline was designed to give organisations time to prepare. That transition period is now functionally over for the most consequential provisions. From 2 August 2026, organisations deploying high-risk AI systems in the Annex III categories — hiring and recruitment algorithms, credit scoring, biometric identification, critical infrastructure management, educational assessment, law enforcement tools, migration and border control, and AI affecting access to essential services — must demonstrate full compliance with Articles 9 through 49.
This means documented, ongoing risk management systems under Article 9. Training data governance under Article 10. Complete technical documentation under Article 11 and Annex IV. Automatic logging of system events under Article 12. Transparency obligations to deployers and affected persons under Articles 13 and 14. Human oversight mechanisms under Article 14. Accuracy, robustness, and cybersecurity controls under Article 15. A quality management system under Article 17. Conformity assessment before market entry. EU database registration under Article 49.
The regulation applies extraterritorially, mirroring the GDPR's scope. Any organisation providing or deploying AI systems that produce outputs affecting EU residents must comply, regardless of where it is headquartered. Finland became the first member state with fully operational AI Act enforcement powers in January 2026; other national competent authorities are activating throughout the first half of the year.
One additional complication for organisations already managing GDPR obligations: the two frameworks overlap substantially. High-risk AI systems processing personal data trigger both a Fundamental Rights Impact Assessment under AI Act Article 27 and a data protection impact assessment under GDPR Article 35. The most efficient compliance path integrates these into a unified assessment process rather than running parallel exercises.
Step 1: Build Your AI System Inventory
You cannot classify, assess, or govern what you cannot find. The most common structural failure in enterprise AI compliance is not poor documentation — it is that significant AI deployments are entirely invisible to the compliance function.
The inventory problem takes three forms. First, internal models developed by product or data science teams that were shipped without any compliance review process. Second, third-party AI tools and APIs integrated as software dependencies — hiring platforms with algorithmic screening, credit tools with embedded scoring models, analytics platforms with automated segmentation — that are treated as vendor services rather than AI systems requiring classification. Third, shadow AI: employees using external generative AI tools that interact with production data, customer data, or sensitive business processes, creating compliance exposure that no engineering team is currently measuring.
A complete AI system registry must document every AI system across all three categories. For each system, you need to capture the use case and intended purpose, the data types and personal data categories it processes, the system owner and accountable executive, the vendor or provider if third-party, the deployment context and affected population, and a preliminary risk classification. The registry is not a one-time project. The Annex III list of high-risk applications is not static — the European Commission has authority to update it based on technological developments — so the inventory process must be embedded as an ongoing operational practice rather than a sprint deliverable.
Step 2: Classify Your AI Systems Under the Risk Tiers
The AI Act's four-tier risk structure determines the entire scope of your compliance obligations. Getting classification wrong in either direction creates exposure: over-classifying wastes compliance resource on unnecessary controls; under-classifying creates the legal and reputational exposure of deploying a regulated system without the required safeguards.
Prohibited systems are those the regulation bans outright. Since February 2025, AI systems that use subliminal or manipulative techniques to distort behaviour, exploit vulnerabilities of specific groups, perform real-time remote biometric identification in public spaces outside the narrow law enforcement exceptions, conduct untargeted scraping of facial images for recognition databases, infer emotions in workplace or educational settings without safety justification, and perform social scoring of individuals by public or private actors are all prohibited. Penalties reach €35 million or 7% of global turnover. If your AI inventory surfaces systems in these categories, discontinuation is the only compliant path.
High-risk systems under Annex III carry the full burden of Articles 9 through 49. The categories include AI used in the management and operation of critical infrastructure; AI systems deployed as safety components in road traffic, water, gas, electricity, or digital infrastructure management; educational and vocational training assessment; employment, workforce management, and access to self-employment; access to essential private and public services including credit scoring, insurance risk assessment, and emergency services dispatch; law enforcement purposes including risk assessment of individuals and crime analytics; migration, asylum, and border control; and administration of justice and democratic processes. If your organisation operates hiring algorithms, credit scoring models, biometric verification, or content moderation systems affecting access to services, there is a high probability you have Annex III systems in your portfolio.
Limited-risk systems — chatbots, recommendation engines, generative AI with no significant rights impacts — face primarily transparency obligations under Article 50. Users interacting with chatbots must be informed they are dealing with an AI system. AI-generated content, particularly deepfakes, must carry machine-readable watermarks. These requirements take effect 2 August 2026. Minimal-risk systems — spam filters, inventory management tools, AI-enabled games — face no specific obligations, though voluntary codes of conduct are encouraged.
The practical classification challenge is the middle ground. The appliedAI study found 18% of enterprise systems were clearly high-risk, but 40% had ambiguous classifications — primarily in critical infrastructure, employment, law enforcement, and product safety areas. For borderline cases, the European Commission published implementation guidelines in February 2026, and organisations should document their classification rationale thoroughly regardless of the conclusion reached. Ambiguity about classification is not a defence against enforcement; undocumented classification decisions are.
Step 3: Conduct an AI DPIA for Each High-Risk System
An AI Data Protection Impact Assessment combines the familiar structure of a GDPR DPIA with the expanded scope that AI systems demand. The GDPR DPIA addresses risks to personal data subjects. The AI Act's Fundamental Rights Impact Assessment under Article 27 addresses broader systemic risks: algorithmic bias and discrimination, impacts on groups that may not be individually identifiable as data subjects, explainability and transparency of automated decisions, safety and reliability of outputs, and whether human oversight mechanisms can actually intercept harmful decisions before they take effect.
Where a high-risk AI system processes personal data — which in practice is almost always — organisations should conduct a unified assessment addressing both frameworks simultaneously. The AI Act explicitly anticipates this, stating that a FRIA may complement a DPIA. The recommended sequencing is DPIA first, then extended to cover the broader FRIA dimensions: algorithmic risk, bias testing results, explainability documentation, human override mechanisms, and the system's post-market monitoring plan.
The core components of an AI DPIA are as follows. The system description section documents the AI system's purpose, intended use case, affected population, data inputs and outputs, decision logic at a functional level, and how its outputs feed into consequential decisions. The data governance section documents training, validation, and testing dataset provenance — sources, collection methodology, labelling procedures, data augmentation — and records bias assessment results showing statistical model performance across demographic segments. The risk assessment section identifies foreseeable risks to individual rights (including discrimination, privacy violation, and denial of services), estimates their severity and likelihood, and documents the mitigation measures applied. The human oversight section describes the mechanism by which a human can review, override, or halt the system's decisions, who has authority to exercise it, and under what conditions it is triggered. The residual risk section documents what risks remain after controls are applied and why they are acceptable. The review schedule sets out when the assessment will be updated, particularly after any significant modification to the system.
This documentation is not produced once and filed. Article 9's risk management obligation is explicitly continuous — the system must be reviewed and updated throughout its lifecycle. For organisations running continuous training pipelines, where model versions in production may differ materially from the version that was originally assessed, governance hooks in the ML pipeline that trigger documentation updates on retraining are a technical necessity, not an optional enhancement. The intersection of AI systems and GDPR compliance creates particular complications here: if personal data was used in training and a data subject exercises their erasure right, the model's statistical patterns cannot be surgically removed after the fact — prevention through automated DPIA processes before training data enters the pipeline is the only viable approach.
Step 4: Implement Technical and Governance Controls
For high-risk systems, the AI Act's technical requirements are specific and demanding. The risk management system under Article 9 must be a continuous process identifying and evaluating known and foreseeable risks to health, safety, and fundamental rights throughout the system's lifecycle. It must document residual risks, specify testing procedures, and be updated when material changes occur. This is not a risk register in a spreadsheet — it is a governed, documented, continuously maintained process.
Data governance under Article 10 requires that training, validation, and testing datasets undergo quality management ensuring they are relevant, sufficiently representative, and as free as possible of errors and biases. Where sensitive personal data must be processed to detect and correct bias — a tension the Act explicitly acknowledges with the GDPR's data minimisation principle — the regulation provides a specific legal basis for doing so. Dataset documentation must record sources, collection methodologies, labelling procedures, and the results of bias assessments across the demographic dimensions relevant to the system's use case.
Technical documentation under Article 11 and Annex IV is one of the most underestimated compliance burdens. It requires the system's general description, intended purpose, and interaction with hardware; a detailed description of the development process including design specifications and data requirements; performance metrics, accuracy benchmarking, and known limitations; a description of the risk management system; a lifecycle change log; a list of harmonised standards applied; the EU declaration of conformity; and the post-market monitoring plan. Organisations that practice agile development without structured documentation find this requirement particularly difficult to satisfy retroactively for systems already in production.
Automatic logging under Article 12 requires that high-risk AI systems technically allow recording of events over the system's lifetime sufficient to trace operation, identify situations presenting risk, and support post-market monitoring. The logging capability is not optional and cannot be added later as a documentation layer — it must be built into the system's architecture. Human oversight under Article 14 requires that systems be designed to allow natural persons to understand their capabilities and limitations, monitor operation, override or halt outputs, and intervene when the system fails to perform as intended. This is a design requirement, not a policy statement — the override mechanism must actually exist and be exercised.
Conformity assessment before market entry varies by system type. Most Annex III high-risk systems allow internal self-assessment under Annex VI, meaning the provider themselves conducts and documents the conformity assessment against the Act's requirements. Certain categories — biometric identification, emotion recognition systems, remote biometric categorisation — require third-party assessment by a notified body. The assessment must be completed, the EU declaration of conformity signed, CE marking affixed, and the system registered in the EU database under Article 49 before the system can be placed on the market or put into service.
