Regulated AI Navigator

Turn an AI use case into its EU AI Act risk class, the regulations it triggers, the obligations, the architecture and the evidence you owe — in about two minutes.

Community-curated knowledge graph, peer-reviewed by experts across law, engineering and governance. Every change traceable →

Analyse a use case →Browse 35 profiles

Glossary

Plain-English definitions of the compliance terms used across the Regulated AI Navigator. These are working explanations for orientation, not legal advice — for a concrete deployment, validate the term against the underlying regulation with qualified counsel.

AIMS / ISO 42001 Annex III Annex IV Conformity assessment Contribution credits Deployer FRIA (fundamental rights impact assessment) GPAI (general-purpose AI model) Harmonised standard Notified body OJEU citation Presumption of conformity Provider Risk tiers the Art. 25 role flip Verifiability ladder

AIMS / ISO 42001

ISO/IEC 42001:2023 defines a certifiable AI management system (AIMS), using the same Annex SL harmonized structure and plan-do-check-act logic as other ISO management-system standards, with a synergy discount available where an ISO 27001 information-security management system already exists. It is estimated to cover 40–50% of the AI Act's organizational duties, but certification is an organizational certificate — it does not by itself grant a product-level presumption of conformity under the AI Act.

See the source claim in the knowledge graph

Annex III

Annex III of the AI Act lists the categories of AI system that are high-risk because of the area they are used in — for example employment and worker management, access to essential services such as credit or insurance, education, migration, law enforcement, and critical infrastructure. Falling into an Annex III category triggers the full high-risk obligation set (Art. 8–15), a quality management system, conformity assessment, and CE marking, unless the system genuinely poses no significant risk under the narrow carve-outs the Act allows.

Annex IV

Annex IV sets out the technical file a provider must maintain: system description, architecture, capabilities and limitations, and the risk measures taken. It is meant to be built incrementally during development — reconstructing it retroactively, after the fact, is treated as an audit red flag. Where the notified-body route applies, the file is reviewed as part of that assessment.

See the source claim in the knowledge graph

Conformity assessment

There are two conformity-assessment pathways. Internal control self-assessment (Annex VI) covers most Annex III systems — the provider itself verifies its quality management system, technical file, and design consistency. Notified-body assessment (Annex VII) is mandatory for safety components in already-harmonised products (such as medical devices, aviation or rail) and for remote biometric identification. Harmonised standards cited in the OJEU give a presumption of conformity within either pathway.

See the source claim in the knowledge graph

Contribution credits

Contribution credits are RAIN's contribute-to-participate currency. They are earned by hardening the graph — an accepted verification, an accepted use case, an accepted peer review, or inviting a colleague who gets verified — and are only credited on acceptance, never on submission alone. Credits are spent on member services such as saving an analysis to a portfolio or requesting an expert review. All balance changes are written server-side, so no client action can mint or remove a credit directly.

Deployer

Uses the system under its own authority: instructions-compliant use, oversight staffing, input-data control, log retention of at least six months. Beware the Art. 25 role flip.

See the source claim in the knowledge graph

FRIA (fundamental rights impact assessment)

Fundamental-rights impact assessment (Art. 27, deployer-side), generalized in practice to an AI Impact Assessment: a societal, legal and operational risk evaluation that defines human-oversight intervention parameters and acceptable-use bounds. It is done before deployment and refreshed annually and on major model updates — a stale FRIA is treated as an audit finding, not merely an outdated document.

See the source claim in the knowledge graph

GPAI (general-purpose AI model)

A general-purpose AI (GPAI) model is trained on broad data and capable of a wide range of tasks, regardless of how it is later packaged or deployed. The AI Act imposes model-level obligations on GPAI providers — technical documentation, training-content summaries, and copyright-compliance policies — with an additional systemic-risk tier for the most capable models. These duties sit alongside, not instead of, the obligations that apply to whoever later builds a system on top of the model.

Harmonised standard

A harmonised standard is a technical standard developed by a recognized European standards body (such as CEN-CENELEC) under a mandate from the European Commission to flesh out how a legal obligation should be met in practice. Meeting the standard is voluntary, but a system built to a standard that has been officially cited gets the benefit of a presumption of conformity with the corresponding legal requirement. Until a standard is cited, following it is good practice but does not by itself satisfy the law.

Notified body

A notified body is an independent conformity-assessment organization that a national authority has designated and notified to the European Commission as competent to assess products against a given piece of EU law. For AI systems, notified-body assessment is required only for the narrower set of cases where the Act's Annex VII route applies — most other high-risk systems can rely on the provider's own internal-control self-assessment instead.

OJEU citation

The Official Journal of the European Union (OJEU) is where the Commission formally publishes the reference number of a harmonised standard once it has assessed and accepted it. A standard only unlocks the presumption of conformity from the date its citation is published in the OJEU — publication of the standard itself by the standards body is a necessary but not sufficient earlier step.

Presumption of conformity

Presumption of conformity is a legal shortcut: if a provider builds and documents its system in line with a harmonised standard that has been cited in the OJEU, regulators presume the corresponding legal requirement is met, without the provider having to separately prove it clause by clause. Without a cited standard, the same requirement still has to be satisfied, but the provider carries the full burden of demonstrating it directly against the law's text.

Provider

Develops (or has developed) and places the system on the market under its own name: full Art. 8–17 burden, technical file, conformity assessment, CE marking.

See the source claim in the knowledge graph

Risk tiers

The AI Act sorts AI systems into four risk tiers that set the obligation set that applies. Unacceptable-risk practices (such as social scoring or untargeted facial-image scraping) are banned outright. High-risk systems — safety components in regulated products, and the Annex III use-case list — carry the full obligation set: risk management, technical documentation, a quality management system, conformity assessment and CE marking. Limited-risk systems (chatbots, deepfakes, emotion recognition) carry disclosure and labelling duties. Minimal-risk systems have no AI-Act-specific obligations beyond general AI-literacy duties, though other laws such as the GDPR may still apply.

See the source claim in the knowledge graph

the Art. 25 role flip

A deployer becomes the provider (full Art. 8–17 duties) by re-branding, changing the intended purpose, or making a substantial modification — for example deep fine-tuning or wiring a model into autonomous agent toolchains.

See the source claim in the knowledge graph

Verifiability ladder

The verifiability ladder describes how strongly an evidence artifact can prove it hasn't been tampered with, independent of who vouches for it. Self-asserted means the organization simply states the artifact exists and is accurate. Tamper-evident means manipulation would be detectable after the fact within the organization's own systems (for example hash-chained, append-only logs). Externally-anchored means integrity proofs leave the organization's own trust domain — such as periodic hash anchoring to an external ledger. Independently-attested means an external party has re-performed the verification itself and formally attested the result. Verifiability (what the artifact can prove) and attestation (who vouches for it) are separate, complementary dimensions of evidence strength.