Reference
AI governance glossary
The terms that come up when you govern AI inside a regulated organisation, defined plainly. Written from product work, not from a compliance course.
EU AI Act
AI use-case register
A register of the AI systems an organisation proposes to build or buy. Used well it is a gate at intake rather than an inventory compiled afterwards: each proposal is screened for whether it is genuinely AI, classified by risk, and assessed for human oversight before development starts. A register that records decisions after they are made is documentation; one that gates them is governance. Read more →
High-risk AI system
Under the EU AI Act, an AI system falling either under Annex III (stand-alone uses such as recruitment, credit scoring, education and essential services) or Annex I (AI embedded in already-regulated products). High-risk classification triggers the Act's most demanding obligations: risk management, technical documentation, human oversight, conformity assessment and post-market monitoring. Read more →
Annex III
The EU AI Act annex listing stand-alone high-risk use cases, including biometrics, critical infrastructure, education, employment and worker management, access to essential services, law enforcement, migration, and administration of justice. Following the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026), Annex III obligations apply from 2 December 2027 rather than the original 2 August 2026 — a deferral of sixteen months, now fixed in law. Read more →
Meaningful human oversight
The requirement that a person is genuinely positioned to catch and reverse a wrong AI output before it takes effect. In practice it depends on four conditions: enough time to evaluate, enough information to judge, real authority to override, and no incentive to rubber-stamp. A reviewer approving a hundred decisions an hour satisfies none of them. Read more →
Human in the loop
A design in which a person reviews or approves an AI system's output. The phrase is often used as evidence of control when no real control exists: if disagreement is slow, costly, or the output is simply re-presented unchanged, the human is absorbing liability rather than exercising oversight. Read more →
Transparency obligations (Article 50)
EU AI Act duties to tell people when they are interacting with an AI system and to label AI-generated content. In force since 2 August 2026 and enforceable by national authorities, they were not deferred by the Digital Omnibus, unlike the high-risk obligations. A transition to 2 December 2026 applies only to the Article 50(2) machine-readable marking duty for generative systems already on the market before 2 August 2026. Penalties reach €15 million or 3% of worldwide annual turnover.
Prohibited practices
AI uses banned outright under Article 5 of the EU AI Act, in force since 2 February 2025. These include social scoring, certain biometric categorisation, and manipulative techniques that materially distort behaviour. The Digital Omnibus added two Article 5 prohibitions from 2 December 2026, covering AI-generated non-consensual intimate imagery and child sexual abuse material. Breaches carry the highest penalties: up to 35 million euro or 7% of global annual turnover, whichever is higher.
General-purpose AI model (GPAI)
A model trained on broad data and capable of performing a wide range of distinct tasks, which can be integrated into many downstream systems. GPAI obligations under the EU AI Act have applied since 2 August 2025 and sit separately from the high-risk regime.
Provider and deployer
The two principal roles in the EU AI Act. A provider develops an AI system and places it on the market under its own name. A deployer uses an AI system under its own authority. Most obligations fall on providers, but deployers carry duties of their own, including ensuring human oversight and using the system in line with its instructions. An organisation that fine-tunes or substantially modifies a bought-in system may become a provider.
Conformity assessment
The process of demonstrating that a high-risk AI system meets the EU AI Act's requirements before it is placed on the market. Depending on the system, it may be carried out internally or require a notified body. It is the step most teams underestimate, because it depends on documentation produced throughout development rather than assembled at the end.
Digital Omnibus on AI
An amending regulation — Regulation (EU) 2026/1744 — that postponed the EU AI Act's high-risk obligations. Voted by the European Parliament on 16 June 2026, approved by the Council on 29 June, published in the Official Journal on 24 July and in force since 27 July 2026. Stand-alone high-risk systems under Annex III now apply from 2 December 2027, and AI embedded in regulated products under Annex I from 2 August 2028. It did not amend Article 50, which applied on schedule from 2 August 2026. Read more →
DORA and financial services
DORA
The Digital Operational Resilience Act, Regulation (EU) 2022/2554. It entered into force on 16 January 2023 and has applied since 17 January 2025 to EU financial entities and their ICT third-party service providers. It has five operative blocks: ICT risk management, incident reporting, resilience testing, ICT third-party risk, and direct EU oversight of providers designated as critical. It contains no AI-specific chapter. Read more →
ICT third-party service provider
Under DORA, an undertaking supplying ICT services to a financial entity. The definition of ICT services is deliberately broad, covering digital and data services provided through ICT systems on an ongoing basis. An external model API delivered continuously generally falls within it, which brings an AI vendor into scope of DORA's third-party obligations. Read more →
Register of information
The record DORA requires financial entities to keep of every contractual arrangement for ICT services, reported to the competent authority. AI tools procured quickly by product teams are the entries most often missing from it. Read more →
Concentration risk
The risk arising from dependence on a small number of ICT providers. For AI the useful question is not how many vendors you have but how many rest on the same underlying foundation model or the same cloud. Four vendors sharing one model is a single dependency wearing four coats. Read more →
Exit strategy
DORA requires exit plans for ICT arrangements that are comprehensive, documented, tested and periodically reviewed. For AI this is harder than an ordinary migration: prompts encode assumptions about one model's behaviour, thresholds are tuned to its confidence distribution, and users have formed expectations from its tone and failure modes. A credible AI exit strategy needs a provider abstraction layer, a re-runnable evaluation set, versioned prompts, and a defined standard for equivalent quality. Read more →
Product practice
Evaluation set
A fixed collection of representative cases with known good answers, used to measure whether an AI feature performs acceptably and to detect regression after a change. Its practical importance is that it constrains scope: if you cannot build an evaluation set for the scope you have agreed, the scope is too wide. Read more →
Usage concentration
The observation that real usage is rarely evenly distributed: a small share of cases typically accounts for most of the volume, with a long tail used rarely or never. It is the main argument against building AI features for full coverage, because effort spread across everything is effort mostly spent where it will not be felt. Read more →
Aimed scope
Scoping an AI feature to the cases that carry the volume rather than to the full population, while giving the remainder a defined fallback. The framing matters: the proposal is not to do less work but to concentrate the same effort where it will be felt, which is an argument a sponsor can carry upward. Read more →
Model drift
Degradation in an AI feature's quality over time, often caused by a provider-side model update rather than any change on your side. It is invisible in ordinary product analytics, which measure usage rather than correctness, and it is why AI features need instrumenting for degradation and not just for adoption. Read more →