The AI Act borrows much of the GDPR’s grammar: a risk-based approach, accountability, documentation, transparency. For a DPO or a CISO already running a compliance programme, that changes how the work should be approached. The real operational risk is duplication: two registers, two impact assessment campaigns, two sets of questionnaires sent to the same business teams a few weeks apart. A workable GDPR and AI Act compliance strategy identifies the overlaps early and handles them once.
The timeline shifted this summer. Prohibited practices have applied since February 2025, general-purpose models since August 2025. The Digital Omnibus package, adopted in late June 2026, has however pushed back the heaviest obligations: 2 December 2027 for high-risk systems under Annex III, 2 August 2028 for AI embedded in products that are already regulated under Annex I. The penalty regime and the transparency obligations did come into application on 2 August 2026. The postponement extends the deadline without reducing the workload: the documentation expected in 2027 is built on the registers and impact assessments you already maintain. The organisational decisions are being made now.
Common foundations: a shared regulatory philosophy
The European legislator kept a familiar structure for the AI Act. It slots into an existing governance framework without pain.
The risk-based approach as common denominator
The GDPR scales its requirements to the sensitivity of the processing. The AI Act classifies systems into four levels: unacceptable, high, limited, minimal. In both cases, the greater the potential harm to rights and freedoms, the tighter the security and transparency obligations become. Your existing risk matrices and rating scales can be reused to qualify your AI projects, provided you add the criteria specific to Annex III.
The accountability principle and organisational responsibility
Both regulations require you to document compliance and to be able to demonstrate it at any time. Internal policies, training, periodic controls, evidence retained: the mechanism is identical. An organisation with a mature GDPR programme already has the backbone needed to carry the AI Act. What changes is the objects being controlled, not the steering logic.
The requirement for technical documentation and traceability
Article 11 of the AI Act requires providers of high-risk systems to maintain detailed technical documentation, complemented by the logging set out in Article 12. The logic of privacy by design and of access traceability is recognisable. Centralise those documents in the same place as your GDPR evidence: a single source of truth, a single collection campaign when the audit comes.
Where the two texts diverge
The similarities stop at the targets and the legal vocabulary. Confusing the two leads to blind spots.
What is protected: personal data on one side, fundamental rights and safety on the other
The GDPR covers personal data and the privacy of natural persons. The AI Act aims at a broader spectrum: health, safety, fundamental rights, non-discrimination. A system trained on anonymised data can be impeccable under the GDPR and still be prohibited under Article 5 of the AI Act, for instance if it amounts to social scoring or prohibited biometric categorisation.
Qualifying the players: controller, provider, deployer
The GDPR thinks in terms of controller and processor. The AI Act introduces the provider, who develops or has developed the system and places it on the market under their own name, and the deployer, who uses it under their authority. The two grids do not overlap: a company is often the deployer of a third-party AI and the controller for the data that system handles. Watch for changes of status: a deployer who substantially modifies a high-risk system or operates it under their own brand becomes a provider, with the obligations that follow. Clarify these roles in contracts, before go-live.
Geographic and material scope
The AI Act applies as soon as the output produced by the system is used in the Union, wherever the provider is established. The extraterritorial reach mirrors that of the GDPR. The penalty ceilings go higher: up to 35 million euros or 7% of worldwide turnover for prohibited practices.
Operational synergies: when one supports the other
Bringing the two texts together opens real simplifications for your teams, provided you design for it from the start.
From the DPIA to the fundamental rights impact assessment
The DPIA is a well-practised exercise for most DPOs. Article 27 of the AI Act adds a fundamental rights impact assessment for certain deployers of high-risk systems, notably public bodies and some private players providing essential services. The text itself provides that elements already covered by a DPIA need not be duplicated. So build the AI questions into your DPIA template: bias, human oversight, explainability, remedies. The business is consulted once, for a single project.
Data governance in the service of AI
Article 10 imposes quality criteria on training, validation and testing datasets: relevance, representativeness, examination of possible bias. That is the direct extension of the GDPR’s minimisation and accuracy principles. An organisation that already controls the provenance, retention period and quality of its data is halfway there.
The right to information and algorithmic transparency
Articles 13, 14 and 22 of the GDPR already govern information about automated decisions. The AI Act adds the obligation to inform people when they are interacting with an AI system and to mark generated content. Your information notices, privacy policies and user journeys must cover both aspects, in plain language.
Towards a single, centralised compliance framework
Running both regulations on parallel spreadsheets always produces the same result: diverging versions, re-entered data and stale information on audit day. To hold your GDPR compliance and the AI Act together, unify the frameworks.
Pooling inventories for a consolidated view
The register of AI systems and the record of processing activities share a large part of their fields: purpose, categories of data, recipients, internal owner, processors. Create a single “application” or “system” object in your GRC platform, then attach the GDPR attributes on one side and the AI Act attributes on the other. One record, two regulatory readings.
Merging security and compliance controls
The cybersecurity, robustness and accuracy requirements of Article 15 overlap with the security obligation of Article 32 of the GDPR, and intersect broadly with both ISO 27001 and ISO 42001. A consolidated action plan makes it possible to prioritise the remediations that serve several frameworks at once. Hardening your logging, for example, feeds both the traceability of data access and that of model decisions.
Automating oversight to avoid duplicate entry
Connect your service catalogue, your CMDB or your development tools to your compliance platform. A new AI project then automatically triggers the qualification questionnaire, with no manual intervention. No more chasing by email and half-completed tracking sheets: the information comes back structured, dated and attached to an owner.
Governance: who owns AI compliance?
The allocation of roles comes up almost every time as the first question, before the subject of the register. It deserves to be settled in writing.
The DPO and CISO pairing at the centre
The DPO brings the legal and ethical reading: purposes, legal bases, data subject rights, proportionality. The CISO assesses technical robustness and the attacks specific to models, from data poisoning to model inversion and prompt injection. Neither covers the subject alone. Formalise the decision path between them, otherwise arbitrations end up being made in project meetings, with no record.
The emergence of the AI compliance officer
In large organisations, an AI Compliance Officer is appearing, often reporting to legal or to IT. They bridge the technical requirements of the AI Act and business needs. Their work must stay coordinated with the DPO’s, failing which two competing interpretations circulate on the use of personal data by models.
Involving the business and the legal department
Marketing, HR and Finance deploy AI tools without always going through IT. Train those teams so they can identify for themselves whether a solution falls under the AI Act, rather than discovering the usage six months later. Legal, for its part, revises supplier clauses: compliance commitments, access to technical documentation, information obligations in the event of a serious incident.
AI system register and record of processing: merge or keep separate?
The question of the register comes up systematically. A new document, or an extension of the existing one?
| Characteristic | Record of processing (GDPR) | AI system inventory (AI Act) | Can they be pooled? |
|---|---|---|---|
| Base unit | Processing activity | Artificial intelligence system | Yes, the AI supports the processing |
| Mandatory nature | Article 30, with exceptions | Documentation and registration for high risk | Yes |
| Purpose of the text | Protection of individuals | Safety, health, fundamental rights | Yes |
| Associated documentation | Flows, retention, recipients | Architecture, datasets, logs, performance | Partial |
Where the two inventories overlap
A well-maintained record of processing activities already contains a good share of what the AI Act asks for. Add the missing fields: risk class, role taken on (provider or deployer), model version, human oversight mechanisms, CE marking status. The register becomes a multi-framework steering tool.
Handling the specifics of high-risk systems
Some fields concern AI only: description of the algorithmic logic, anti-bias measures, performance metrics, emergency stop procedure. Handle them with conditional forms. If the application is flagged as “high-risk AI”, the additional fields become mandatory. The other records stay light.
The structure of a hybrid register
Three layers are enough:
- Identity: tool name, business owner, vendor, version, functional description.
- GDPR: legal basis, categories of data and of individuals, retention periods, transfers, processors.
- AI Act: risk class, role, provider, technical documentation, human oversight, logging.
Transition method: starting from the GDPR to absorb the AI Act
There is no need to start from a blank page. What you have built for the GDPR is the fastest starting point.
Step 1: map AI systems within existing processing
Go back through your current register and spot the processing activities that rely on machine learning, scoring or expert systems. Take the opportunity to hunt down shadow AI: browser extensions, assistants built into SaaS suites, and subscriptions taken out directly by a department. That is often where the most exposed uses are found.
Step 2: update your data governance policies
Your internal policies must absorb the Article 10 requirements on dataset quality. Define who validates a training corpus, against which criteria, and how test results are retained. Without a written procedure, proof of the absence of discriminatory bias gets reconstructed in a hurry, at the worst possible moment.
Step 3: adapt procurement and third-party review
Enrich your supplier questionnaire. “Are you GDPR compliant?” is no longer enough: ask for the EU declaration of conformity, the CE marking where it applies, the instructions for use provided for in Article 13, and access to the technical documentation. Build those elements into your TPRM process rather than opening a parallel assessment channel.
Key takeaways
- One process: pool registers and impact assessments rather than running two compliance chains in parallel.
- Risk as compass: your GDPR risk analysis method serves as the basis for classifying AI systems into the AI Act categories.
- Data as foundation: sound data governance determines compliance with both texts.
- Written roles: DPO, CISO, legal and business must know who decides what, and at which point in the project.
- A centralised tool: maintaining continuous compliance across several frameworks requires a single source of truth, not a collection of spreadsheets.
- Anticipation: qualifying an AI system before go-live costs markedly less than reworking it afterwards.
Frequently asked questions
Can the DPO also be responsible for AI compliance? Yes, and it is common in mid-sized companies. It assumes a ramp-up on the technical aspects of models and access to the data teams. Above all, check the workload: combining both remits without extra resources degrades the core GDPR duties, starting with handling data subject requests.
Do I have to redo all my DPIAs if I use AI? Update them, rather than redo them. Existing processing that incorporates an AI component changes risk profile: opacity of the decision, bias, new attack vectors, dependency on a supplier. An AI section added to your DPIA template covers the essentials in most cases.
What are the penalties for AI Act non-compliance? They are tiered. Up to 35 million euros or 7% of worldwide turnover for the prohibited practices of Article 5. Up to 15 million euros or 3% for breaching other obligations. Up to 7.5 million euros or 1% for supplying inaccurate information to the authorities.
Does an AI system that processes no personal data fall under the GDPR? No. The GDPR applies to the processing of personal data. The AI Act applies independently, as soon as the system falls into a defined risk category, for instance a safety component of critical infrastructure. Qualification is done text by text.
How do you prove the human oversight required by the AI Act? Through documented procedures: who monitors the system, how often, how alerts are escalated, under what conditions an operator can override a recommendation or stop the system. Add records of actual exercises, the associated permissions and test reports. A procedure that has never been tested will not hold up during an inspection.
Going further
Start with a quick inventory of your AI uses, including those that never went through IT. Then take your three most exposed systems and run them through a combined GDPR and AI Act impact assessment: it is the best test of your governance, and it blocks no project. In parallel, update your acceptable use policy to frame employees’ use of generative AI and limit data leakage towards services you do not control.
Make IT Safe centralises your assets, your registers, your risk analyses and your action plans in a single collaborative platform, hosted in France. The record of processing on one side, the register of AI systems on the other, and evidence shared between the two: that is the common foundation described in this article. We can show you it working: request a demonstration.
