EU AI Act's High-Risk Deadline Just Landed. What DPOs Should Have Shipped

The Deadline That Merged Two Compliance Worlds

2 August 2026 was the day the EU AI Act's high-risk provisions became fully applicable. Providers and deployers of AI systems that fall inside Annex III — biometric identification, safety components in critical infrastructure, education grading, employment screening and workforce management, access to essential public and private services (credit scoring, insurance underwriting), law enforcement, migration and asylum, administration of justice — now sit inside a compliance regime that runs on top of GDPR rather than beside it.

Most privacy teams shipped the AI Act paperwork on time. What they underestimated is how the two frameworks stack. A Fundamental Rights Impact Assessment (FRIA) is not a DPIA with a different cover page. A conformity assessment is not a Legitimate Interest Assessment. The technical documentation under Annex IV overlaps with your RoPA but demands details your RoPA never captured. The teams doing well are the ones who reconciled the two frameworks; the teams scrambling are the ones who ran them as separate programmes.

What Actually Became Enforceable on 2 August

Not every AI Act obligation switched on at the same moment. The applicability timetable was deliberately staggered: prohibited practices in February 2025, GPAI (general-purpose AI) transparency and governance in August 2025, and the high-risk regime in August 2026. Provisions for embedded AI in regulated products (Annex I) run until August 2027. Knowing which slice applies to your systems today is the first step.

As of 2 August 2026, high-risk providers must have registered eligible systems in the EU database, completed conformity assessments (either internal control or notified body depending on the Annex III category), affixed CE marking where the system is a physical product, established a post-market monitoring plan, and set up a serious incident reporting channel to the relevant market surveillance authority. Deployers — the organisations putting a high-risk system to use — must have completed a FRIA before first use, assigned human oversight, monitored operation, and kept operational logs for the periods specified. Providers not established in the EU need an authorised representative on the record.

FRIA vs DPIA: The Overlap Nobody Wanted

Article 27 requires deployers of high-risk AI systems in public services or in categories the Commission adds by delegated act to conduct a FRIA. The scope reads similar to a DPIA but the questions are different: which affected persons or groups, what fundamental rights are implicated (dignity, non-discrimination, effective remedy, private life), what mitigation measures are proportionate, what governance is in place to oversee outcomes.

The honest reconciliation is that a FRIA and a DPIA answer different questions about the same system. The DPIA asks whether processing is lawful, necessary, proportionate, and safeguarded. The FRIA asks whether the system's outputs affect fundamental rights disproportionately across groups, and whether the deployer has the governance to detect and correct that. Teams that tried to shove one into the other's template ended up with a document that satisfied neither regulator. The pragmatic pattern is a single assessment workflow that produces both artefacts from a shared evidence base — the same system inventory, the same data flow, the same stakeholder interviews, but two output documents mapped to two different obligation sets. See our AI privacy impact assessment template for a workable structure and the DPDP AI comparison for cross-jurisdictional context.

Provider vs Deployer: Where Your DPA Obligations Shift

The AI Act splits obligations between providers (the actor placing an AI system on the market or putting it into service under its name) and deployers (the actor using the system under its authority). This split does not align cleanly with GDPR's controller and processor split. A provider can be a processor for the deployer. A deployer can be a joint controller with the provider. Vendors that build features into their SaaS using third-party models are simultaneously deployers of those models and providers of the resulting AI system to their customers.

The operational consequence is that a Data Processing Agreement drafted before August 2026 probably does not carry the right AI-Act allocations of responsibility. Providers must supply technical documentation and instructions for use sufficient for the deployer to comply. Deployers must feed serious incidents back to the provider inside the reporting window. If your DPAs do not name conformity assessment evidence, incident-response cooperation, log retention responsibility, or post-market monitoring input, they need an addendum. The vendor risk management workflow needs a new category for AI-system suppliers — see the vendor risk management guide for privacy teams for the base pattern and layer the AI-specific asks on top.

Human Oversight and the Article 22 Trap

Article 14 of the AI Act requires human oversight of high-risk systems, calibrated to the risks the system poses. Article 22 of the GDPR restricts solely automated decisions with legal or similarly significant effect. These are related but not identical guarantees, and confusing them creates real risk.

An Article 22 defence typically rests on meaningful human intervention — a person who can override the automated decision, has enough information to do so, and is not just rubber-stamping. Article 14 asks for a broader set of measures: the ability to interpret system output, to correctly use the human-machine interface, to intervene or halt operation, to remain aware of automation bias. A deployer who has a human-in-the-loop for GDPR purposes may still fail Article 14 if the oversight is theatrical rather than substantive. Auditors are already probing this distinction. Document the specific oversight mechanisms — not that a human exists, but what evidence they see, what they can do about it, and how you measure whether they actually intervene when they should.

The Documentation Package Auditors Are Asking For

Annex IV lists the technical documentation a provider must maintain. It reads like a superset of a good model card plus a system security assessment plus a data governance register. In practice, auditors focusing on the first wave of high-risk deployments are asking for a specific package: description of the intended purpose and reasonably foreseeable misuse, hardware and software specifications, training and validation datasets with their provenance and preprocessing, evaluation metrics disaggregated by relevant subgroup, human oversight measures, cybersecurity measures, and a plan for changes over the system lifecycle.

Deployers get a lighter documentation load but still need the FRIA, the operational logs (at least six months by default, longer for certain categories), and evidence that the system was operated per the provider's instructions. A recurring auditor question is whether the deployer read the provider's instructions and configured accordingly — a deployment that violates the provider's stated conditions can shift liability onto the deployer even for defects in the underlying system.

Registered Deployers and the EU Database

Providers of Annex III high-risk systems must register those systems in the EU database maintained by the Commission before placing them on the market or putting them into service. Public authorities and EU institutions deploying such systems must also register their use. Private deployers were originally exempt from public registration in most categories, but implementing acts have narrowed that exemption for certain sensitive contexts.

Operationally, the database registration is a hard gate. A system that should be registered but isn't cannot lawfully be operated in the EU, and market surveillance authorities have been checking. The registration workflow needs an owner and a cadence — not a one-time exercise. Every material update to the system, every change in intended purpose, every new deployer for a public-authority instance triggers a registration update.

The Serious Incident Reporting Channel

Article 73 requires providers to report serious incidents to the market surveillance authority of the Member State where the incident occurred within tight windows — 15 days generally, 10 days for incidents involving death or serious harm, and immediately for large-scale infringements or critical infrastructure impact. A serious incident includes any malfunction that directly or indirectly leads to death, serious harm to health, serious and irreversible disruption of critical infrastructure, or infringement of fundamental rights obligations under EU law.

The deployer's role is to detect and escalate to the provider. This is the operational counterpart to GDPR breach notification, but the trigger is different: a system that hallucinates plausibly but wrongly may not be a GDPR breach yet may absolutely be a serious incident. Teams that built a breach-response runbook for GDPR need an AI-incident runbook that overlaps but is distinct — see the GDPR 72-hour breach guide for the base pattern and add AI-incident classifiers to the on-call playbook.

The Reality of Joint EDPB + AI Office Enforcement

The AI Act is enforced by a mix of national market surveillance authorities (typically at national level), the AI Office (at the Commission), and national data protection authorities where AI Act obligations overlap with GDPR. The EDPB and the AI Office are coordinating on the overlap, and the first joint interpretive positions are shaping expectations quickly.

Expect two enforcement lanes in the year ahead: one where regulators pursue high-visibility symbolic cases against the largest providers, and one where DPAs use the AI Act to intensify GDPR enforcement against deployers of solutions like biometric recognition in retail, algorithmic hiring, and credit scoring. The second lane is where most compliance teams should focus energy — the AI Office cannot inspect every deployer, but a DPA that already has a GDPR complaint file can now add AI Act questions to the same investigation.

The August 2026 Audit Checklist

A pragmatic checklist for the first weeks after the deadline: inventory every AI system, classify each against Annex III, identify whether you are provider or deployer or both, confirm registration status for each qualifying system, verify conformity assessment evidence is complete and current, check your FRIA templates cover the Article 27 fields, reconcile your DPIA and FRIA workflows into a single evidence process, add AI-incident classes to your on-call runbook, update DPAs with vendors of high-risk AI systems, and confirm your operational log retention meets the applicable minimum.

Each gap has an owner and a deadline. The AI Office and DPAs are not expecting perfection, but they are expecting to see a programme. A well-run programme with a documented backlog is a better position than a claim of full compliance the first inspection immediately disproves. Vendor selection for AI systems now needs privacy team sign-off on Annex IV documentation and DPA terms — treat this as a hard gate.

What This Means for Your Consent and DSR Programme

The AI Act does not create new individual rights in the same shape as GDPR. It does not add a right to erasure of training data, and its Article 26 duty to inform natural persons subject to a high-risk system does not replace GDPR transparency obligations. But the overlap creates practical work for the consent and DSR programme.

Consent flows for products that include an AI component now need clearer disclosure of that fact — Article 50 requires it for certain categories (chatbots, deepfakes, emotion recognition), and best practice extends it further. DSR responses that touch AI-processed data should note the automated processing, its logic in meaningful terms, and its consequences. The privacy notice needs a purpose entry for AI-model training that is separate from the operational purpose. If your CMP or DSR tooling does not surface these fields, add them — auditors are asking whether the disclosure travels through your public surfaces, not just whether it exists in a policy document. See our consent management vs privacy management piece for how these workflows fit inside a broader operational programme.

Where To Start If You Are Behind

If your 2 August deadline came and went with more open questions than closed, prioritise ruthlessly. Inventory first — you cannot manage what you cannot enumerate. Classify each AI system against Annex III honestly, including systems your team may not have called AI (rules-based scoring engines can qualify if they influence a high-risk outcome). Complete or refresh a FRIA for the top two or three deployer use cases within the next month, and use those artefacts as the template for the rest.

On the provider side, if you place an AI system on the EU market, close the technical documentation gap before you close anything else — an inspection begins with the docs. On the deployer side, close the FRIA gap first and the operational-log retention second. Both sides need updated DPAs, but updated DPAs signed against a coherent internal programme are more defensible than perfect DPAs against a chaotic one. The AI Act is genuinely the most consequential privacy-adjacent regulation of the decade for European operations — programmes that treat it as a natural extension of GDPR rather than a foreign body will get the enforcement conversation over quickly and cheaply.