Glossaries fail at AI governance for a structural reason. The terms that cause real compliance failures are not the obscure ones. Nobody misapplies an AI governance duty because they were unsure what a model card is. AI governance programmes break on the ordinary words, because provider, deployer, operator, high-risk and impact assessment each carry a different meaning in each instrument that uses them, and one lexicon entry per word hides exactly the thing a reader needs.
AI governance vocabulary collides most visibly on one word. Under Article 3(8) of the EU AI Act an operator is an umbrella category that includes the deployer. Under Regulation 10 of the DIFC Data Protection Regulations an operator is the technical party that builds a system on the deployer’s instructions, which makes it the deployer’s counterparty rather than a category containing it. Same word, opposite structural position, two instruments a Gulf-facing team reads in the same week.
AI governance terms are grouped here by collision rather than alphabet, sorted by the kind of error they cause, each entry naming the instrument that defines it and the duty that follows. Anyone needing the jurisdictional picture before the AI governance vocabulary should start with which countries have binding AI law.
Role terms move between instruments, and the duty moves with them
AI governance allocates duties by role, so a misread role misallocates the entire obligation set.
Provider, Article 3(3) of the EU AI Act, is a person or body that develops an AI system or general-purpose model, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether for payment or free. Development alone does not make you a provider. Placing it on the market under your own name does.
Deployer, Article 3(4), is a person or body using an AI system under its authority, excluding personal non-professional use. The term carries the operational duties: monitoring, human oversight, input data quality where applicable.
Operator is the trap. Article 3(8) defines it as a provider, product manufacturer, deployer, authorised representative, importer or distributor, so it is a collective noun rather than a distinct party. DIFC Regulation 10 uses the same word for the party that builds a system on a deployer’s instruction, closer to a processor. A clause saying “the operator shall” means something different depending on which instrument drafted it, which is the clearest argument for a lexicon organised this way.
Importer, Article 3(6), is established in the Union and places on the market a system bearing a third-country person’s name. Distributor, Article 3(7), is anyone in the supply chain other than the provider or importer who makes a system available. Initial provider and new provider come from Article 25: a party that puts its name on a system, substantially modifies it, or changes its intended purpose so it becomes high-risk becomes a new provider, and the initial provider then owes it documentation, known failure modes and targeted technical access.
Covered provider is Californian and unrelated to any of the above. Under the state’s AI Transparency Act it means any person that creates, codes or otherwise produces a generative AI system publicly accessible in California, with no size threshold since September 2026.
Controller and processor come from data protection law and map imperfectly onto provider and deployer. A deployer is usually a controller. A provider frequently is not. Mapping the two sets rather than assuming they align is the AI governance step teams skip, and the role analysis under the EU AI Act is where that work starts.
AI governance gained two role definitions recently. The Digital Omnibus inserted Article 3(14a) for small and medium-sized enterprises and 3(14b) for small mid-cap enterprises, which now gate several proportionality concessions.
Risk tier terms do not line up, and the thresholds differ by design
AI governance classification vocabulary looks interchangeable across instruments and is not.
High-risk under the EU AI Act has two routes. Article 6(1) with Annex I covers AI as a safety component of a regulated product. Article 6(2) with Annex III covers listed standalone uses including employment, credit and education. The routes carry different dates, 2 August 2028 and 2 December 2027 respectively, so an AI governance record naming the tier without the route is incomplete. The classification mechanics deserve their own reading.
High-risk processing in DIFC Regulation 10 is unrelated to either. Commercial use of an autonomous system for high-risk processing is barred until the Commissioner has set audit and certification requirements and the system meets them, which is a prohibition rather than a tier.
Consequential decision is Colorado’s term, spanning education, employment, housing, financial services, insurance, healthcare and essential government services. Significant decision is California’s, covering hiring, compensation, work allocation, promotion, demotion, suspension, termination and independent contracting. Overlapping, not identical, and an AI governance register should name which one it means.
AI governance scoping goes wrong at the involvement thresholds, which diverge further still. New York City asks whether a tool substantially assists or replaces discretionary decision making. Colorado asks whether technology materially influences a decision, excluding incidental, trivial or clerical uses. California asks whether it replaces or substantially replaces human decision making. Materially influence is the widest and substantially replaces the narrowest, so one tool can sit inside one AI governance regime and outside another on identical facts. The practical routing by fact pattern is set out in the jurisdiction selector for hiring tools.
AI system itself is defined in Article 3(1) and deliberately broad, which is why scoping by the definition rarely narrows anything. Scoping by decision type does.
Document terms name at least four different artefacts
Impact assessment is the single most overloaded phrase in this field, and the documents are not interchangeable.
AI system impact assessment is ISO/IEC 42001, Clause 6.1.4. Data protection impact assessment is a data protection instrument, required for example before large-scale or systematic automated processing under Bahrain’s Order No. 43 of 2022. Fundamental rights impact assessment is Article 27 of the EU AI Act. The Digital Omnibus replaced Article 27(4) so that obligations already met through a data protection impact assessment need not be duplicated, and replaced 27(5) to require the AI Office to develop a questionnaire template. Colorado’s annual impact assessment existed until May 2026 and does not now, which is a tense distinction worth writing into any register that still lists it.
Technical documentation means Annex IV of the EU AI Act specifically, and since the omnibus the post-market monitoring plan sits inside it. Statement of Applicability is ISO/IEC 42001 Clause 6.1.3, which requires the organisation to produce a document stating the necessary controls drawn from the 38 reference controls in Annex A, grouped across nine objectives running A.2 to A.10. A walkthrough of those Annex A controls and of what belongs in the Statement covers the mechanics.
Post-market monitoring plan is Article 72(3), now part of the Annex IV file, with Commission guidance and a template due 2 September 2027. The obligation it serves is explained in the post-market monitoring guide.
Latent disclosure and manifest disclosure are Californian. A latent disclosure is embedded in the content and carries the provider name, system name and version, time and date, a unique identifier and whether AI generated or modified the content. A manifest disclosure was the visible version and was deleted by statute on 30 September 2026. Any AI governance register still describing it as required is out of date, as the transparency requirements page sets out.
Measurement terms trace to one legal source, and that source is moving
Only one jurisdiction mandates a bias audit: New York City, annually, by an independent auditor, for automated employment decision tools used to screen candidates or evaluate employees for promotion. Everywhere else the duty is notice, documentation or rights. Treating bias audit as a generic obligation is the most expensive AI governance vocabulary error there is.
Selection rate, scoring rate and impact ratio are the measures that audit uses, and the city’s Final Rule prescribes the arithmetic rather than importing it. An impact ratio is a category’s selection rate divided by the selection rate of the most selected category, or for scoring tools the scoring rate divided by that of the highest scoring category. Categories below 2 per cent of the audit data may be excluded.
Independent auditor is defined by the same rule as a person or group capable of exercising objective and impartial judgment. Independence fails where the auditor used, developed or distributed the tool, has an employment relationship with a user, or holds a financial interest in a user or the vendor.
Adverse impact and the four-fifths rule come from the Uniform Guidelines on Employee Selection Procedures at 29 C.F.R. Part 1607, under which a selection rate below 80 per cent of the highest group’s rate is generally treated as evidence of adverse impact. Federal personnel regulations dropped their references to the Guidelines on 31 July 2026. The EEOC sent a final rule rescinding the interpretive portions of those Guidelines to regulatory review on 16 October 2026 under RIN 3046-AB43, with an effective date projected for January 2027. Statutory disparate impact liability survives in Title VII itself. The city methodology survives because it never depended on the federal Guidelines. Vendor reports citing the Guidelines as their authority will not. How the measurement is actually run is worth understanding independently of which instrument currently blesses it.
Event terms arrive with clocks attached
Serious incident is Article 3(49) of the EU AI Act and has four limbs: death or serious harm to health, serious and irreversible disruption to critical infrastructure, infringement of Union law obligations protecting fundamental rights, and serious harm to property or the environment. Reporting runs to 15 days by default, 10 where a death may have been caused and 2 for a widespread infringement or critical infrastructure disruption, which makes this the most time-sensitive entry in the lexicon. The reporting clocks and where reports go are a subject in themselves.
Adverse outcome is Colorado’s trigger, covering denial, reduced eligibility, lower compensation or worse terms, and it starts a 30 day explanation window from 1 January 2027.
Substantial modification, Article 3(23), is a change after placing on the market that was not foreseen in the initial conformity assessment and that affects compliance with the Chapter III Section 2 requirements or changes the intended purpose. Crossing it can convert a deployer into a provider, which is the most consequential definitional boundary in AI governance.
Deepfake, Article 3(60), needs three cumulative features: resemblance to existing persons, objects, places, entities or events; the existence of what is resembled; and a false appearance of authenticity.
Terms that exist in exactly one instrument
Single-source AI governance vocabulary is safer to use precisely because it cannot collide.
AEDT, automated employment decision tool, is New York City. Autonomous systems officer is DIFC Regulation 10, a role modelled on the data protection officer and required where an autonomous system is used commercially for high-risk processing. AIMS, the AI management system, is ISO/IEC 42001. GPAI, general-purpose AI model, is the EU AI Act. ADMT, automated decision-making technology, belongs to Colorado and California and is defined differently by each.
Govern, map, measure and manage are the four functions of the NIST AI Risk Management Framework, released as version 1.0 on 26 January 2023 and voluntary. NIST does not use provider and deployer, which is precisely why AI governance teams need a crosswalk rather than a translation when mapping it to the Act. The control mapping across frameworks does that work.
| Term | Instrument | What it means there |
| Operator | EU AI Act Article 3(8) | Umbrella for provider, manufacturer, deployer, representative, importer, distributor |
| Operator | DIFC Regulation 10 | The technical party building a system on the deployer’s instruction |
| High-risk | EU AI Act Article 6 | Annex I product route or Annex III listed use route |
| High-risk processing | DIFC Regulation 10 | Commercial use barred until certification requirements are set and met |
| Impact assessment | ISO/IEC 42001 Clause 6.1.4 | AI system impact assessment |
| Impact assessment | EU AI Act Article 27 | Fundamental rights impact assessment |
| Impact assessment | Colorado, until May 2026 | Annual deployer assessment, now repealed |
| Bias audit | NYC Local Law 144 | Annual independent audit, the only such mandate |
| Covered provider | California AI Transparency Act | Anyone producing a publicly accessible generative system |
| Deployer | EU AI Act Article 3(4) | User of a system under its own authority |
| Deployer | DIFC Regulation 10 | Party authorising or benefiting from an autonomous system |
How a lexicon earns its place in a governance programme
An AI governance lexicon changes nothing as a list. What makes the vocabulary operational is binding each term to the register entry it governs.
AI governance records fail audits on definitional drift more often than on missing documents. A system is logged as high-risk without recording whether that means Annex I or Annex III. An impact assessment is attached without recording which of the four it is. A party is described as the operator in a contract drafted against one instrument and read against another. Each of those is a one-line omission at the time and an unanswerable AI governance question two years later.
AI governance registers need three habits to avoid it. Record the instrument alongside the term every time, so high-risk never appears in a register without its article reference. Record the date state, because a term can be accurate and expired at once, as Colorado’s impact assessment and California’s manifest disclosure both demonstrate. Record which lexicon definition was applied when a system was ruled out of scope, since out of scope is a position that has to be defended rather than a gap in the record.
Enforcing those three habits at entry rather than at audit is the job, by attaching the instrument, the article and the decision date to each system record. Teams beginning AI governance work usually find the gap is in the register structure rather than in the knowledge, which is why the inventory question comes before the vocabulary question, and why a single platform view across frameworks tends to beat a document per regime.
Vocabulary discipline is cheap at entry and expensive to retrofit, which is the argument for holding definitions against system records rather than in a separate document. Holding them there is what govern365.ai was built for.
AI governance, AI ethics and responsible AI are not synonyms either, and the distinction between the three is its own discussion.
Questions about AI governance terminology
What is the difference between a provider and a deployer?
A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, under Article 3(3) of the EU AI Act. A deployer uses a system under its own authority, excluding personal non-professional use, under Article 3(4). Providers carry the design and documentation duties, deployers carry the operational ones. Substantially modifying a system or changing its intended purpose can turn a deployer into a provider.
Does operator mean the same thing in every instrument?
No, and the two main uses are structurally opposed. Article 3(8) of the EU AI Act makes operator an umbrella category that includes the deployer. DIFC Regulation 10 uses operator for the technical party building a system on the deployer’s instruction, which places it opposite the deployer rather than above it. Contract drafting that borrows the word without naming the instrument is a common source of confusion.
How many kinds of impact assessment are there?
AI governance has at least four distinct documents sharing the name. ISO/IEC 42001 Clause 6.1.4 requires an AI system impact assessment. Article 27 of the EU AI Act requires a fundamental rights impact assessment. Data protection law requires a data protection impact assessment, which Bahrain’s Order No. 43 of 2022 extends to systematic automated processing. Colorado required an annual impact assessment until its statute was repealed and reenacted in May 2026.
Is a bias audit required outside New York City?
AI governance mandates an independent bias audit in one place only. New York City requires one, and only for automated employment decision tools used to screen candidates or evaluate employees for promotion within the city. Illinois, California, Colorado and the European Union impose notice, documentation, consumer rights or anti-discrimination duties instead.
Is the four-fifths rule still a federal standard?
The four-fifths rule’s federal footing is being removed. The rule comes from the Uniform Guidelines on Employee Selection Procedures at 29 C.F.R. Part 1607, and the EEOC sent a final rule rescinding the interpretive portions to regulatory review on 16 October 2026 with an effective date projected for January 2027. Statutory disparate impact liability under Title VII is unaffected, and New York City’s methodology sits in city rules rather than the federal Guidelines.
What does high-risk mean under the EU AI Act?
Two separate routes. Article 6(1) with Annex I covers AI acting as a safety component of a regulated product, applying from 2 August 2028. Article 6(2) with Annex III covers listed standalone uses such as employment and credit, applying from 2 December 2027. Recording which route applies matters, because the dates and the conformity route differ.
Does NIST use the same vocabulary as the EU AI Act?
No. The NIST AI Risk Management Framework organises around four functions, govern, map, measure and manage, and does not use provider and deployer as defined roles. Mapping between the two requires an AI governance crosswalk that reconciles different actor models, rather than a direct substitution of terms.
Which terms in this field changed during 2026?
AI governance vocabulary moved in several places during 2026. Colorado’s annual impact assessment was repealed in May 2026 and replaced with an automated decision-making technology framework. California deleted the manifest disclosure requirement on 30 September 2026 and removed the user threshold from covered provider. The EU AI Act gained definitions of small and medium-sized enterprise and small mid-cap enterprise, and its post-market monitoring plan moved inside the Annex IV technical documentation. A term can be correct and expired at the same time, which is why registers should carry dates alongside definitions.
