Knowledge base / regulation10.com product guide (EU AI Act)

What the EU AI Act regime is on this platform

Your workspace runs in the EU AI Act regime. In practice this means the platform serves EU AI Act corpus, modules, and terminology throughout, rather than the DIFC Regulation 10 set that other deployments use. Everything you register, assess, and export is framed against the obligations of Regulation (EU) 2024/1689, the EU's cross-sector law on artificial intelligence.

Concretely, the regime shapes four things you will notice. The assessment modules offered for a system follow the EU AI Act's structure, covering areas such as risk management, data governance, technical documentation, record-keeping, transparency, human oversight, and accuracy. The risk language matches the Act's own categories, including the Annex III high-risk list. The reference content the assistant cites is the EU corpus. And evidence exports are shaped for the EU's reviewers, meaning notified bodies and market surveillance authorities rather than DIFC institutions.

The regime also has a data consequence: your workspace data resides in the EU region tied to this deployment. Where your compliance record is stored is itself a question European buyers and reviewers ask, so the answer is fixed at the platform level rather than left to configuration.

Why does the platform bind a workspace to one regime instead of letting you toggle between frameworks? Because the two regimes disagree in ways that matter. Risk categories, documentation expectations, reviewer institutions, and timelines all differ between the EU AI Act and DIFC Regulation 10. A workspace that blended them could produce records that satisfy neither, and worse, could let guidance from one regime leak into an assessment made under the other. Fixing the regime at provisioning removes a whole class of cross-contamination errors, and it means every entry in your audit trail was made under a known framework.

You therefore do not switch regimes inside the product. The regime is set when the workspace is provisioned and stays fixed for its life. If your organisation also needs the DIFC regime, for example because you operate in both jurisdictions, the platform team sets that up as a separate deployment with its own workspace, its own data residency, and its own record. Two clean records beat one mixed one, and reviewers on each side only ever see the record built for their framework.

What this asks of you is small: work in the regime your workspace was built for, and read the platform's terminology as EU AI Act terminology. When you see a reference to a high-risk classification, an obligation, or an evidence export, it carries the EU meaning. If you are ever unsure whether a concept you have met elsewhere applies here, ask the assistant, which will answer from the EU corpus and cite its source.

The regime binding is one of the quiet features you stop noticing quickly, and that is the intended outcome. The framework is fixed so your attention can go to the systems being assessed rather than to which rulebook applies.

If you inherit a workspace and are unsure which regime it runs, the answer is visible in the product itself: the corpus the assistant cites, the module names, and the reviewer institutions named in the evidence flow all identify the framework. You never have to guess, and nothing you do inside the workspace can change it by accident. This is informational only and not legal advice: the platform's regulatory content is a scaffold pending qualified-professional review, so confirm any obligation with a qualified adviser before you rely on it.