IP Anonymisation on Google Analytics
Many companies use Google Analytics as their assistive tool in order to collect valuable information about customer behaviour on websites, […]
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 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.
The EU AI Act entered into force.
Prohibited AI practices and AI literacy obligations started to apply.
Governance rules and obligations for general-purpose AI models started to apply.
Most remaining provisions apply, including the Article 50 transparency obligations.
Two new Article 5 prohibitions apply (AI-generated non-consensual intimate imagery and AI-generated CSAM), in the top penalty tier. Machine-readable marking of synthetic content becomes mandatory for generative systems placed on the market before 2 August 2026.
High-risk requirements apply to the Annex III use cases, including certain systems in employment, education, essential services, biometrics and law enforcement.
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 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.
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:
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.
The obligations depend heavily on whether the organisation is a provider or a deployer.
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.
Screen every system into one of four practical categories, then document the legal reasoning behind the result.
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.
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.
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.
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.
Several obligations are already relevant. Treating all AI Act work as a future high-risk project is the common mistake.
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.
Prepare a workstream covering the provider requirements, including:
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.
Prepare controls to:
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.
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.
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.
A DPIA and a FRIA are related, but they are not interchangeable.
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.
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:
Even where the organisation is not the registering party, the registration status can be a useful vendor due diligence and deployment control.
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:
Annual review can be a useful minimum for stable systems, but it should not replace change-based review.
Tick each item as you complete it. Progress is tracked as you go, and saved in your browser so you can return to it.
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.
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.