Risk classification, the provider and deployer split, and why AI governance tooling that ignores the GDPR overlay solves half the problem.
EU AI Act compliance software helps you classify AI systems against the risk tiers of Regulation (EU) 2024/1689, work out whether you act as provider or deployer for each one, and meet the duties that follow. The two questions that separate credible tools are whether they maintain a live inventory of the AI systems you actually run — including the ones a team adopted without telling anyone — and whether they model the provider versus deployer distinction properly, because the same system carries different obligations depending on your role. Since most AI systems process personal data, a tool that treats the AI Act in isolation from GDPR obligations leaves the harder half unaddressed.
Classification is meaningless without a complete register. Ask how systems get discovered — from procurement, from code, from cloud usage — rather than only from a form someone fills in when they remember.
The same system carries different duties depending on your role, and many organisations are both across their portfolio. A tool that offers one generic obligation set per system will misstate what you owe.
Article 50 duties apply outside the high-risk tier and are the ones most visible to the outside world: telling people they are interacting with AI, marking generated content, disclosing emotion recognition, labelling deepfakes. Check they are handled as controls with evidence, not as a copy checklist.
An AI system processing personal data engages both instruments at once. Satisfying Article 50 says nothing about lawful basis, DPIA requirements or data subject rights. Look for one programme that carries both rather than two registers describing the same system.
For high-risk systems the obligations are ongoing — risk management, data governance, logging, human oversight, accuracy and robustness. Ask what a tool produces if an authority asks you to demonstrate those were operating six months ago.
Four shapes of vendor, described by category rather than by name. Which one fits depends on how fast your systems change and how much judgement you need to buy in.
Large, modular GRC platforms that cover most regimes through separately licensed modules, usually with a long implementation and a dedicated administrator.
Best fit: Large organisations with a compliance team big enough to own configuration, and budget that tolerates a multi-module licence.
Focused products that do one job well — consent, DSAR intake, cookie scanning, vendor questionnaires — and integrate loosely with whatever else you run.
Best fit: Teams with one acute, well-bounded problem, who accept that the register tying everything together lives somewhere else.
People rather than software: an external DPO or advisory retainer that produces the documentation on your behalf, often in documents you then own.
Best fit: Organisations without in-house expertise who need judgement more than tooling, and who can accept that the output is a snapshot.
Systems that connect to what you already run, derive the records from live signals, and keep them current between audits rather than regenerating them before one.
Best fit: Teams whose systems change faster than documents can be maintained by hand, and who need to evidence a current state on demand.
Noru treats AI systems as part of the same programme as everything else: they enter the register from procurement and from code, carry a risk classification, and inherit the same evidence and review machinery as any other control.
Because the privacy data map already knows what personal data a system processes, the GDPR overlay on an AI system is derived rather than re-documented — the DPIA trigger and the AI classification see the same facts.
Article 50 transparency duties are modelled as controls with evidence and owners, so a disclosure that gets removed in a redesign surfaces as drift instead of going unnoticed.
Providers and deployers of AI systems whose output is used in the EU, along with importers and distributors. It applies extraterritorially: being established outside the Union does not remove the obligation if people in the EU interact with the system or its output.
Practices that are prohibited outright, high-risk systems carrying substantial obligations around risk management, data governance, logging, human oversight and robustness, and — cutting across tiers — the transparency duties in Article 50 that apply to systems interacting with people or generating content.
The provider develops the system or places it on the market under its own name; the deployer uses it under its own authority. Providers of generative systems must ensure output is machine-markable; deployers owe the user-facing disclosure. Building on a third-party model typically makes you a deployer, and can make you a provider if you substantially modify it or put it out under your own name.
No, they stack. The AI Act governs whether the system may be placed on the market and whether people know they are dealing with AI. The GDPR governs whether you may process the personal data involved at all, on what basis, and with what rights attached.
You need an accurate inventory, a defensible classification per system, and evidence that the obligations are operating. Whether that lives in dedicated tooling or in the platform already running your compliance programme matters less than whether it shares facts with your privacy and security records instead of duplicating them.
Regulatory references on this page were last checked on .
A 45-minute walkthrough against your frameworks, your integrations and your evidence.
