The AI Act for compliance leads: fitting it to systems you already run
Updated: 2026-09
If you already run data protection or an information security management system, the AI Act does not start from zero. Registers, risk assessment and evidence trails already exist. What is new is the classification logic under Article 6, the provider–deployer distinction, and standalone transparency obligations.
For compliance leads the AI Act poses a mapping problem, not a knowledge problem. Much of it sounds familiar: risk assessment, documentation, technical and organisational measures. That invites one of two wrong conclusions — either that the existing GDPR structure already covers it, or that an entirely new system has to be built.
Both are inaccurate and both cost. The first leaves gaps in classification and transparency; the second creates parallel structures nobody maintains in daily practice. The actual work is separating cleanly: what can be attached to what exists, and what is genuinely new.
How it works
- 01
Determine the role for each system
Provider or deployer — different obligations follow from each. With bought-in software containing AI functions the answer is less obvious than it first appears, for instance after substantial modification or own branding.
- 02
Attach to the existing register
A record of processing activities is the natural home for the AI system list. Two separate registers mean duplicate maintenance and guarantee that one of them goes stale.
- 03
Classify under Article 6
The AI Act risk tier is not the GDPR risk assessment. It asks about intended purpose and Annex III areas, not about risk to the rights of data subjects. Both assessments are needed.
- 04
Check transparency duties separately
Disclosure obligations under Article 50 apply regardless of risk tier. A system outside the high-risk category can still trigger one — a point that is frequently missed.
- 05
Fold the AI literacy duty into existing training cycles
Article 4 can be integrated into training structures you already run. What matters is the link to roles: the evidence has to show that the depth matches the task.
Why it fits here
The course addresses people with existing compliance experience, so it does not start from what an AI system is but from where it differs from what you already operate.
The DACH focus matters here: Swiss leads face the additional question of how the revised Swiss data protection act, the GDPR and the AI Act interact — a combination internationally framed courses rarely address.
FAQ
Does our existing ISMS cover the AI Act?
Partly. An ISMS supplies structure for evidence, ownership and tracking measures — all of it connectable. What it does not supply is the Article 6 classification logic and the provider–deployer distinction.
Do we need a dedicated AI governance role?
Not necessarily. In smaller organisations the task sits well with the data protection or quality lead. What matters is that it is explicitly assigned rather than implicitly resting with everyone and therefore with nobody.
How do we handle bought-in software?
As a deployer you carry your own obligations regardless of what the vendor asserts. Ask for the classification and conformity statements in writing and file them with your documentation.
What if a system is hard to classify?
Document the reasoning together with the alternatives you considered. A well-reasoned classification is worth considerably more under scrutiny than an unexplained correct one.
Innopulse Academy
The course addresses people with existing compliance experience, so it does not start from what an AI system is but from where it differs from what you already operate.
The DACH focus matters here: Swiss leads face the additional question of how the revised Swiss data protection act, the GDPR and the AI Act interact — a combination internationally framed courses rarely address.