Articles

EU AI Act Compliance Checklist for DPOs in 2026

EU AI Act compliance checklist and application timeline for DPOs

Last reviewed: 07 August 2026.

The EU AI Act is now applying in stages, which makes 2026 a slightly confusing year for compliance teams. Some duties already apply, the main transparency rules start on 2 August 2026, and the detailed requirements for high-risk AI systems have moved to later dates.

For DPOs, the immediate job is not to create a second compliance programme beside GDPR. It is to make AI use visible, identify which rules apply, and connect AI governance to the records and assessment processes the organisation already has.

This EU AI Act Compliance Checklist sets out the practical work to prioritise in 2026, including AI inventories, role and risk classification, transparency, DPIAs, FRIAs, vendor oversight and preparation for the high-risk rules.

The dates that matter

EU AI Act timeline for 2026 and beyond

The schedule is no longer a single 2026 deadline. The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the detailed high-risk rules to later dates while keeping the transparency duties on track.

1 August 2024 In force

The EU AI Act entered into force.

2 February 2025 Applying

Prohibited AI practices and AI literacy obligations started to apply.

2 August 2025 Applying

Governance rules and obligations for general-purpose AI models started to apply.

2 August 2026 Applies now

Most remaining provisions apply, including the Article 50 transparency obligations.

2 December 2027 Upcoming

High-risk requirements apply to the Annex III use cases, including certain systems in employment, education, essential services, biometrics and law enforcement.

2 August 2028 Upcoming

High-risk requirements apply to AI systems that are safety components of regulated products listed in Annex I.

The later high-risk deadlines create more preparation time, not a reason to postpone governance. An inventory, clear ownership, vendor evidence and connected records take time to build.

The DPO’s role in AI Act compliance

The AI Act does not make the DPO legally responsible for the organisation’s AI compliance. The DPO is, however, well placed to advise on personal data, DPIAs, transparency, data subject rights and the connection between AI systems and existing GDPR records.

Operational ownership should remain cross-functional. Legal, compliance, risk, IT, security, procurement, HR and product teams may all need to contribute. This distinction matters because the DPO must remain independent and avoid conflicting operational responsibilities, including becoming the person who decides the purposes and means of personal data processing.

Step 1: Build a complete AI system inventory

You cannot classify or govern AI systems that are not visible. Start by mapping both formally procured systems and tools adopted informally by individual teams. Pay particular attention to ordinary SaaS products that have added AI features after the original purchase.

For each system, record:

  • System and product name
  • Vendor, developer and internal business owner
  • Intended purpose and actual use case
  • Teams, processes and countries where it is used
  • People who may be affected by its outputs
  • Whether personal data or special category data is processed
  • Whether the organisation acts as provider, deployer, importer or distributor
  • AI Act risk classification and the reasoning behind it
  • Relevant contracts, DPAs, security reviews and vendor evidence
  • Linked RoPA, DPIA, LIA, FRIA or other assessment records
  • Deployment date, model or product version and latest review date

Use procurement records, IT asset lists, browser and application management data, vendor questionnaires and short interviews with department heads. The first inventory will not be perfect. It should be treated as a living register with a clear process for adding new systems before they are deployed.

Step 2: Confirm your role for each AI system

The obligations depend heavily on whether the organisation is a provider or a deployer.

  • Provider: develops an AI system or has it developed, then places it on the market or puts it into service under its own name or trademark.
  • Deployer: uses an AI system under its authority in a professional context.

An organisation can hold different roles for different systems, and sometimes more than one role for the same system. A company using a third-party recruitment tool is normally a deployer. A company building an internal recruitment system and putting it into service under its own name may be a provider as well.

Do not rely on the vendor label alone. Record the role analysis and revisit it when the system is substantially modified, rebranded or used for a new purpose.

Step 3: Classify each system under the AI Act

Classify each system

Four categories for the initial screening

Screen every system into one of four practical categories, then document the legal reasoning behind the result.

ProhibitedBanned

Certain manipulative or exploitative practices, some social scoring and biometric categorisation, untargeted facial-image scraping, and workplace or education emotion recognition. Two further prohibitions apply from 2 December 2026.

High-riskStrict requirements

Certain AI in biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and justice, plus regulated product safety components. The function and intended purpose decide the result, not the sector alone.

TransparencyDisclosure duties

Systems that interact directly with people, certain emotion recognition and biometric categorisation, deepfakes, and certain AI-generated text on matters of public interest. These duties apply even when the system is not high-risk.

OtherBaseline good practice

Many lower-risk systems do not trigger detailed mandatory requirements. Keep them in the inventory with proportionate controls for privacy, security, accuracy, procurement and responsible use.

Top penalty tier. The two new prohibitions added by the Digital Omnibus, non-consensual intimate imagery and AI-generated CSAM, carry fines up to 35 million euros or 7 percent of total worldwide annual turnover, whichever is higher. Any generative or image-editing capability that could foreseeably produce this output should be screened, and vendor assessments should confirm what the provider prevents at source.

Step 4: Address the obligations that apply in 2026

Do not wait for the high-risk rules

What applies in 2026

Several obligations are already relevant. Treating all AI Act work as a future high-risk project is the common mistake.

AI literacyApplies since Feb 2025
Ensure an appropriate level of AI literacy among staff operating AI systems. A generic annual slide is unlikely to be enough. Document the training, target groups, attendance and role-specific instructions.
Prohibited-practice controlsApplies since Feb 2025
Confirm a process to identify and stop prohibited AI uses. Procurement, HR, security and product approval workflows should all include a prohibited-use check.
Article 50 transparencyApplies 2 August 2026
Inform people interacting with AI, disclose deepfakes and certain AI-generated text, and check for machine-readable marking. Review chatbots, recruitment communications and public channels.

Step 5: Prepare for the high-risk requirements

The detailed high-risk rules now apply from 2 December 2027 for Annex III systems and 2 August 2028 for regulated product systems. The required preparation depends on the organisation’s role.

If your organisation is a provider

Prepare a workstream covering the provider requirements, including:

  • Risk management throughout the system lifecycle
  • Data and data governance requirements
  • Technical documentation and record-keeping
  • Instructions for deployers and system transparency
  • Human oversight measures built into the system
  • Accuracy, robustness and cybersecurity
  • Quality management, conformity assessment and EU declaration of conformity
  • Registration, post-market monitoring and incident reporting

The DPO should be involved where personal data, training data, monitoring, transparency or data subject rights are affected, but the technical and product evidence must come from the teams that design and operate the system.

If your organisation is a deployer

Prepare controls to:

  • Use the system in line with the provider’s instructions
  • Assign human oversight to people with suitable competence, training, authority and support
  • Assess whether input data under your control is relevant and sufficiently representative for the intended purpose
  • Monitor the system in use and escalate risks, incidents or unexpected performance
  • Retain and review logs where they are under your control
  • Inform workers and their representatives before using high-risk AI in the workplace, where required
  • Use provider information when completing a DPIA
  • Complete a FRIA and EU database registration where the specific legal conditions apply

Vendor due diligence should test whether the provider can supply the information and contractual support needed for these duties. A generic security questionnaire is not enough for a high-risk AI system.

Step 6: Connect AI Act records to the GDPR programme

AI Act and GDPR records should not sit in separate folders with different owners and review dates. Where an AI system processes personal data, connect the records so the compliance chain is visible.

  • Link the AI system to the relevant RoPA entries
  • Link the vendor to the vendor register, DPA and transfer assessment
  • Record the GDPR purpose, legal basis, categories of data and retention period
  • Connect the DPIA to the AI risk classification and provider documentation
  • Review transparency notices and data subject rights procedures
  • Document human review, automated decision-making and escalation routes
  • Align security, incident and breach response records

This creates a more credible audit trail. A reviewer should be able to move from the AI inventory to the processing activity, assessment, vendor evidence, controls, decisions and current owner without reconstructing the story from email.

Step 7: Decide whether a DPIA, FRIA or both are required

A DPIA and a FRIA are related, but they are not interchangeable.

  • DPIA: required under GDPR when personal data processing is likely to result in a high risk to individuals’ rights and freedoms.
  • FRIA: required under Article 27 of the AI Act only for specified deployers and specified Annex III high-risk systems.

A FRIA is not mandatory for every high-risk AI deployer. The duty applies in particular to public-law bodies, private entities providing public services, and deployers using certain high-risk systems for creditworthiness or credit scoring and life or health insurance risk assessment and pricing.

Where both assessments are required, manage them in a connected workflow and reuse factual information where appropriate. Keep the legal tests, conclusions, approvals and review triggers clearly identifiable for each assessment.

Step 8: Record EU database registration duties

Registration duties are role-specific. Providers of relevant Annex III high-risk systems must register the system in the EU database. Public authorities and EU institutions deploying those systems also have deployer registration duties. Private deployers do not have a general obligation to register every high-risk system they use.

For each potentially high-risk system, record:

  • Whether registration is required
  • Which party is responsible
  • The registration reference and date
  • Any exemption or non-high-risk assessment relied on
  • The evidence obtained from the provider

Even where the organisation is not the registering party, the registration status can be a useful vendor due diligence and deployment control.

Step 9: Assign ownership and review triggers

Each AI system should have a named business owner and a compliance owner. Set both a periodic review date and event-based triggers.

Trigger a review when:

  • A new system or AI feature is introduced
  • The intended purpose or affected group changes
  • The provider changes the model, data or material functionality
  • The system is used in a new country or business process
  • An incident, complaint, bias concern or unexpected output occurs
  • New guidance, standards or legal deadlines affect the classification

Annual review can be a useful minimum for stable systems, but it should not replace change-based review.

Work through it

EU AI Act compliance checklist for DPOs

Tick each item as you complete it. Progress is tracked as you go, and saved in your browser so you can return to it.

DPO checklist

0 of 21 complete

Turn the checklist into a working process

GDPR Register helps teams maintain an AI system inventory, classify AI systems, assign ownership, document decisions and connect AI governance to RoPAs, DPIAs, vendor oversight and risk management.

Explore the AI Act software
Primary sources

Official sources

  1. European Union, Regulation (EU) 2024/1689 (the EU AI Act)
  2. European Union, Regulation (EU) 2026/1744 (the Digital Omnibus on AI)
  3. European Commission, Regulatory framework for AI and implementation timeline
  4. European Commission, Guidelines on Article 50 transparency obligations
  5. European Data Protection Board, Data Protection Officer independence and role

This article provides general information and is not legal advice. The applicability of the EU AI Act depends on the system, role, use case and applicable sector rules.

Questions we hear

Frequently asked questions

Is the DPO responsible for EU AI Act compliance?+
No. The AI Act does not assign overall AI compliance responsibility to the DPO. The DPO should advise and monitor on data protection issues, while the organisation assigns operational ownership across the relevant business, legal, risk and technical teams.
Do the high-risk AI rules apply from August 2026?+
Not under the current timeline. The detailed high-risk requirements apply from 2 December 2027 for Annex III systems and 2 August 2028 for high-risk AI embedded in regulated products. Other parts of the AI Act, including Article 50 transparency duties, apply earlier.
Does every high-risk AI system require a FRIA?+
No. Article 27 applies to specified deployers and specified Annex III high-risk systems. A separate DPIA may still be required under GDPR where the personal data processing is likely to create a high risk.
Can existing GDPR documentation be reused?+
Yes, but only partly. RoPAs, DPIAs, vendor records, security assessments and transparency notices provide a strong foundation. AI Act role classification, prohibited-use checks, AI-specific transparency, human oversight, provider evidence and registration analysis still need to be addressed.
How often should the AI system inventory be reviewed?+
Review it whenever systems, purposes, vendors, affected groups or material functionality change. A periodic review, such as annually for stable systems, is useful as a backstop but should not be the only control.
Tags:
case study
data privacy framework
gdpr
gutenberg
interesting
international transfers
scc
schrems ii
Transfer impact assessment steps for GDPR international transfers
PREVIOUS
Transfer Impact Assessment: A Step-by-Step GDPR Guide for 2026
GDPR data breach 72-hour response timeline and notification checklist
NEXT
How to Handle a GDPR Data Breach: A 72-Hour Response Checklist