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, adopted by the Council on 29 June 2026, Annex III obligations apply from 2 December 2027 rather than the original 2 August 2026 — a deferral of sixteen months. 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. These apply from 2 August 2026 and were not deferred by the Digital Omnibus, unlike the high-risk obligations. A four-month extension to 2 December 2026 applies only to the Article 50(2) watermarking duty for systems already on the market before 2 August 2026. For most organisations this is the nearest binding AI Act deadline.
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 a prohibition on 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
A package of targeted amendments to the EU AI Act, proposed by the European Commission on 19 November 2025, endorsed by the European Parliament on 16 June 2026 and adopted by the Council on 29 June 2026. Its principal effect was to defer high-risk obligations: Annex III stand-alone systems from 2 August 2026 to 2 December 2027, and Annex I embedded systems to 2 August 2028. Transparency obligations were not deferred. Note that the amendments take legal effect only on publication in the Official Journal; until then the original dates remain binding, so the sensible planning posture is to use the extra runway rather than pause. 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 →