AI governance glossary

This AI governance glossary explains, in plain English, the terms that come up most often when a company starts to manage its use of AI, with a link to the library article that covers each one in more detail.

AI agent

An AI agent is an AI system that takes actions rather than only producing text: it can send emails, update records, book appointments or make payments, usually by connecting to other software. A wrong answer from a chatbot is a mistake someone can still catch; a wrong action from an agent may already have happened by the time anyone looks. For a company, the key questions are what each agent is allowed to do and which of its actions wait for a person to confirm them. Agents with more permissions than their task needs are one of the main AI security risks. A practical safeguard is to require human confirmation for anything that cannot easily be undone, such as payments, deletions and external emails.

AI bias

AI bias means that an AI system produces systematically unfair results for some groups of people, for example ranking applicants from one group lower or offering different prices to different customers without a good reason. It can come from the data a system learned from, from its design or from the way it is used. Bias matters most where AI affects decisions about people: hiring, lending, pricing and customer service. It becomes a legal issue through anti-discrimination law and, for high-risk systems, through the data governance requirements in Art. 10 of the AI Act. Comparing results for paired test cases with identical settings is a useful initial screening, not proof of fairness: finding no difference does not show a system is fair, and decisions with serious consequences need proper evaluation (NIST AI RMF). See how AI bias can show up in your business.

AI ethics

AI ethics is the set of principles a company follows when it builds or uses AI, such as fairness, transparency, accountability and respect for people’s privacy. Ethics answers the question of what the company should do, including in situations the law does not cover. It is not the same as compliance, which means meeting specific legal requirements, or governance, which turns principles into roles, processes and decisions. A company needs all three: principles without processes stay on paper, and compliance alone leaves gaps, because no law covers every risk. The difference between the three, and a simple way to tell a legal requirement from a recommendation, is explained in how AI ethics, governance and compliance differ.

AI governance

AI governance is the way a company organises decisions about AI: who owns the AI programme, who approves new tools, who owns each use case, which records are kept and when a use case is reviewed or stopped. It turns ethical principles into everyday practice and gives compliance work a structure. Most entries in this AI governance glossary describe one piece of that structure. A small company can often assign these responsibilities within existing roles, although company size alone does not determine how complex or risky its AI use is. One person owns the programme and has the time and authority to pause a use case, each use case has a named owner, and legal, the data protection officer and security join when needed, as described in who should be responsible for AI in a small company.

AI incident

An AI incident is an event in which an AI system causes harm or comes close to it: a wrong decision about a person, leaked data, false content published in the company’s name, or an agent taking an unapproved action. A company needs to know in advance who can stop a system, how to preserve evidence and which duties apply. For a personal data breach, the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people’s rights and freedoms; a processor must notify the controller without undue delay (GDPR, Art. 33). Telling the affected individuals is a separate assessment under Art. 34: it is required where the risk is high, with exceptions (EDPB guide on data breaches). How to respond to an AI incident sets out six steps.

AI inventory

An AI inventory is a list of the AI a company uses, with one entry per specific use case: the same tool used by marketing and by HR makes two entries. Each entry records the tool, vendor, purpose, owner, data used, markets and the company’s role under the AI Act, with separate fields for prohibited-practice screening, high-risk classification and transparency duties that can say “Not yet determined” until a named classification owner decides. A company cannot assess, approve, monitor or explain AI it does not know about. Much AI never appears in the IT budget, because staff sign up for free tools and familiar software gains AI features through updates. An inventory works best as a way to make useful tools safe, not as a hunt for rule-breakers. How to find all the AI your company uses includes a ready-to-use template.

AI literacy

AI literacy is the skills, knowledge and understanding people need to use AI sensibly: what a tool can and cannot do, what data may go into it, when its output needs checking and whom to ask. Under Art. 4 of the AI Act, which has applied since 2 February 2025, providers and deployers take measures to support the development of AI literacy. Since the amendment by the Digital Omnibus on AI, the law does not require them to guarantee a particular level of literacy for each employee. In practice, a company needs proportionate measures for different roles and a record of what it has done. What AI literacy training staff need includes a role-to-knowledge matrix.

AI management system

An AI management system is the set of policies, roles, processes and records an organisation uses to direct and control its work with AI, in the same way a quality management system does for quality. The best-known framework is ISO/IEC 42001:2023, a voluntary standard that can be certified. For a company, a management system brings order to scattered practices such as the inventory, assessments, approvals and monitoring. Certification can help when customers or tenders ask for it, but a standard is not a law, and certification does not guarantee full compliance with the AI Act. Whether you need ISO 42001 certification explains when it makes sense and when it is too early.

AI risk assessment

An AI risk assessment is a structured look at one use case before it goes live: what the AI does, who it affects, what can go wrong, how likely and how serious that would be, which measures are needed and who decides whether the remaining risk is acceptable. A general assessment of this kind is a recommendation rather than a legal requirement for every use case. It is, however, the basis for the assessments the law does require in some situations, the DPIA and the FRIA, and one form with modules avoids duplicate work. Its screening questions are a preliminary check of whether a full DPIA or FRIA is needed, not a DPIA or FRIA in themselves. A completed assessment is evidence of a decision, not proof of compliance. How to run your first AI risk assessment includes a first assessment form.

AI system

An AI system is defined in Art. 3 of the AI Act. In plain terms, it is a machine-based system that works with some degree of autonomy and infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. Chatbots, writing assistants and tools that rank job applicants are typical examples. The definition matters because most of the AI Act’s obligations attach to AI systems, while general-purpose AI models are a separate category with their own rules. Roles are also decided per AI system: one company can be the provider of one system and the deployer of another. What the EU AI Act requires gives the wider picture.

AI use policy

An AI use policy is a short internal document that tells staff how the company uses AI. At a minimum it covers what is allowed and what is not, rules for data, how new tools are approved, when output needs human review, transparency towards customers, how to report incidents, training, who is responsible and when the policy is reviewed. Its value lies in being followed: a template copied from elsewhere that nobody reads protects no one. A policy is one part of AI governance and does not on its own make a company compliant with the AI Act or data protection law. What an AI use policy should include explains each element and the most common mistake.

Automation bias

Automation bias is the tendency of people to trust automated output too much, especially when they are busy and the system is usually right. It is why a human approval step can turn into a formality: a reviewer who handles hundreds of cases a day and sees only the final result will approve almost everything. The AI Act names this tendency directly: people overseeing a high-risk system must be able to remain aware of the risk of over-relying on its output (Art. 14 of the AI Act, which applies from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I Section A products; Section B products follow the sector route in Art. 2(2)). For a company, an approval step that never rejects anything is a warning sign rather than proof that control works. How human oversight of AI works describes what a reviewer needs.

Data processing agreement

A data processing agreement (DPA) is the contract a company signs with a vendor that processes personal data on its behalf, for example an AI tool that stores and analyses customer messages. In GDPR terms, the company is the controller and the vendor is the processor, and a contract with specific terms is required whenever a processor is used (GDPR, Art. 28). A DPA does not make the processing lawful by itself, and it is not a general trade-secret contract. The company still checks the lawful basis and purpose, minimisation and security, retention, international transfer conditions and, where required, a DPIA; special-category data needs an Art. 9 condition. Where staff use a personal account, ask who is party to the contract and which terms apply to the organisation. See whether it is safe to share data with AI tools.

Data protection impact assessment (DPIA)

A data protection impact assessment (DPIA) is an assessment of how a planned processing of personal data could affect people, and which measures will reduce the risks. Under Art. 35 of the GDPR, which applies now, the controller, meaning the organisation that decides why and how personal data is processed, must carry one out before the processing starts where it is likely to result in a high risk to people’s rights and freedoms. AI use cases that process personal data should therefore be screened against that threshold. A DPIA is separate from a general AI risk assessment and from a FRIA, although one form with modules can cover all three. See how to run your first AI risk assessment.

Deepfake

A deepfake is image, audio or video content generated or manipulated by AI that resembles real people, objects, places or events and could falsely appear authentic. Under Art. 50 of the AI Act, which applies from 2 August 2026, a deployer that uses AI to create a deepfake must disclose that the content was artificially generated or manipulated. Separately, from 2 December 2026 the AI Act prohibits AI systems used to generate non-consensual intimate deepfakes. For a company, the practical point is that AI-generated video, voice or images that could pass as real need a clear label wherever they are published. What AI transparency requires includes sample notices.

Deployer

A deployer is an organisation that uses an AI system under its authority in a professional capacity. It is one of the roles defined in Art. 3 of the AI Act, alongside provider, importer, distributor and authorised representative. Most companies are deployers of the AI tools they buy, such as an HR team using a screening tool. For high-risk systems, Art. 26 requires deployers to use the system according to its instructions, assign competent people to oversee it and, on identifying a serious incident, immediately inform first the provider and then the importer or distributor and the market surveillance authorities. These duties apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I Section A; Section B products follow the sector route in Art. 2(2)). The AI literacy duty and some transparency duties also apply to deployers. See whether you are a provider or deployer.

EU AI Act

The EU AI Act, Regulation (EU) 2024/1689, is the EU’s law on AI. It is usually explained through four risk levels, prohibited practices, high-risk systems, transparency obligations and minimal risk, with general-purpose AI models covered separately (AI Act overview). The levels are a teaching model: a high-risk system can also carry transparency duties (Art. 50(6)). It reaches non-EU providers placing systems on the EU market, and non-EU providers and deployers whose system’s output is used in the EU (Art. 2). The Digital Omnibus on AI postponed only Chapter III, Sections 1–3:

Obligation	Application
High-risk classification, requirements and duties (Art. 6–27, except Art. 6(5), which concerns Commission guidelines)	2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I Section A; Section B: Art. 2(2))
Art. 72, 73, 86	Not expressly postponed; timing depends on classification and Art. 111

See what the EU AI Act requires.

Explainability

Explainability is the ability to say, in understandable terms, how an AI system reached its output and what role it played in a decision. Transparency includes disclosing that AI is involved and, in some contexts, duties to explain decisions. Explainability is good practice more broadly, but specific duties can already arise under the GDPR: for automated decisions within Art. 22, people are entitled to meaningful information about the logic involved (Art. 13–15). The Court of Justice held in C-203/22 that this means explaining the procedure and principles actually applied, intelligibly, not disclosing source code. The AI Act adds a right to an explanation from the deployer for decisions based on certain Annex III systems that have legal or similarly significant adverse effects (Art. 86); it is not expressly postponed, and its timing for a specific system needs a legal assessment. See what AI transparency requires.

Fundamental rights impact assessment (FRIA)

A fundamental rights impact assessment (FRIA) is an assessment of how a high-risk AI system could affect people’s fundamental rights, such as non-discrimination and privacy, before the system is put into use. Under Art. 27 of the AI Act, it is required before deploying a high-risk system under Art. 6(2) (Annex III), except critical infrastructure (Annex III point 2), by bodies governed by public law, private entities providing public services, and deployers of systems for credit scoring of natural persons (except fraud detection) or for risk assessment and pricing in life and health insurance. The duty applies from 2 December 2027. Other companies do not need a FRIA. Screening questions only show whether a full FRIA is needed; answering them is not a FRIA. See how to run your first AI risk assessment.

General Data Protection Regulation (GDPR)

The General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, is the EU law on personal data. It applies to organisations established in the EU, and to organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour there (Art. 3; see the EDPB guidelines on territorial scope). Public data can still be personal data. The GDPR is a separate layer from the AI Act: meeting one does not mean meeting the other. For AI, the provisions that come up most often are the legal basis for processing, Art. 22 on decisions based solely on automated processing, Art. 28 on processor contracts, Art. 30 on records of processing, Art. 32 on security, Art. 33–34 on personal data breaches and Art. 35 on the DPIA. Which other laws apply to your use of AI explains when each one matters.

General-purpose AI model (GPAI model)

A general-purpose AI (GPAI) model is a model that can perform a wide range of tasks and be built into many systems, such as a large language model. The model is not the same as an AI system built on it. Providers of GPAI models have had their own obligations since 2 August 2025, including a policy to comply with EU copyright law (Art. 53 of the AI Act); fines for GPAI providers (Art. 101) apply from 2 August 2026. Providers of GPAI models placed on the market before 2 August 2025 must bring those models into compliance by 2 August 2027. A company that builds a chatbot on such a model through an API is generally not the GPAI model provider, but it may be the provider of the chatbot as an AI system. See whether you are a provider or deployer.

Hallucination

Hallucination is the common name for AI output that states false information with confidence, including facts, sources, quotes or figures that do not exist. It happens because generative AI produces a likely answer based on patterns in the data it learned from rather than checking facts. Hallucinations are hard to spot precisely because they sound plausible, and the same question can produce a correct answer one time and an invented one the next. For a company, the risk depends on where the output goes: an internal draft someone will rewrite is low risk, while a figure in a client report or a statement in a customer reply needs a person to check it first. What AI can do, and what its limits are gives a simple criterion for when a check is needed.

High-risk AI system

A high-risk AI system is one the AI Act subjects to its strictest requirements short of a ban. Art. 6 sets two routes. Annex I: the system is, or is a safety component of, a product covered by Annex I legislation that must undergo third-party conformity assessment. Annex III: the system is used in a listed area, such as recruitment, education or credit scoring, unless it poses no significant risk of harm. Do not remove an Annex III use from the high-risk category merely because you consider its impact small. Check the specific conditions in Article 6(3) and document the provider’s assessment under Article 6(4). Annex III systems that profile people remain high-risk. Requirements apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I Section A); Section B products follow the sector route in Art. 2(2). See what the EU AI Act requires.

Human oversight

Human oversight means that a competent person can follow what an AI system does, understand its output and reject, change or stop it when needed. Clicking “OK” on every recommendation is not oversight: the reviewer needs time, information and the authority to say no, and people affected by a decision need a clear way to challenge it. For high-risk systems, the AI Act requires providers to design systems so that people can oversee them (Art. 14) and deployers to assign competent people to do so (Art. 26), both from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I Section A products (Section B products follow the sector route in Art. 2(2)). Separately, GDPR Art. 22 already gives people rights, including to obtain human intervention, in certain decisions based solely on automated processing. See how human oversight of AI works.

Intended purpose

Intended purpose covers the use, context and conditions specified by the provider across its instructions, technical documents, advertising, sales materials and statements (Art. 3(12) of the AI Act). It matters because many obligations are measured against it: whether a system is high-risk often depends on what it is used for, not on the technology behind it. In practice, how a product is described on a website and in sales can matter for its legal purpose, and the risk for a company is using a tool for something its provider never intended. Under Art. 25, a deployer or other party that changes the intended purpose of a system that was not high-risk, so that it becomes high-risk, becomes the provider of that system and takes on the provider’s obligations. See whether you are a provider or deployer.

Post-market monitoring

Post-market monitoring is the duty of providers of high-risk AI systems to track and document how the system performs once it is in use (Art. 72 of the AI Act). Art. 72 is not expressly postponed by the Omnibus, but it concerns only high-risk systems, so when it applies to a given system depends on its classification and the transitional rules in Art. 111 and needs a legal assessment. Deployers of high-risk systems also monitor operation under Art. 26(5), from 2 December 2027 (Annex III) or 2 August 2028 (Annex I Section A; Section B follows the sector route in Art. 2(2)). Outside the high-risk regime, ongoing monitoring remains good practice and may also be required by other laws or contracts: GDPR Art. 32 requires regularly testing and evaluating security measures. Tracking errors, complaints and quality drift catches problems early. See how to monitor AI after launch.

Prohibited AI practices

Prohibited AI practices are uses of AI that the AI Act bans under Art. 5. The prohibitions have applied since 2 February 2025 and include, in plain terms, harmful manipulation, exploiting people’s vulnerabilities to materially distort their behaviour in a way that causes or is likely to cause significant harm, unfair social scoring, emotion recognition based on biometric data in the workplace or in education except for medical or safety reasons, and untargeted scraping of facial images to build recognition databases (AI Act). From 2 December 2026, AI systems used to generate child sexual abuse material or non-consensual intimate deepfakes are prohibited too. This is a short summary: each prohibition has conditions and exceptions, so it is not a ready-made classifier. No notice or safeguard makes a prohibited use acceptable. When you should stop or avoid using AI covers these red lines and other signals to pause.

Prompt injection

Prompt injection is an attack in which someone writes text that an AI model treats as a new instruction. It works because large language models cannot reliably tell the instructions they were given apart from the content they are processing. Direct injection comes from the person typing into the tool, for example a user trying to make a customer chatbot ignore its rules. Indirect injection is hidden in a document, email or web page the AI reads on someone’s behalf, so the user may never see it. There is no complete technical fix, so companies limit what an injected instruction can achieve: least privilege, human confirmation for irreversible actions and logging. See the main AI security risks.

Provider

In this library, provider refers only to the AI Act role. Under Art. 3 of the AI Act, a provider develops an AI system or a general-purpose AI model, or has it developed, and places it on the market or puts it into service under its own name or trademark. Putting into service includes supply for own use, so a company that builds an AI tool only for internal use can be its provider. A company that developed a GPAI model is its provider when it places the model on the market. Providers of high-risk systems carry the heaviest obligations. A company can also become a provider by putting its name on a high-risk system or substantially modifying one (Art. 25). A vendor is often, but not automatically, the provider. See whether you are a provider or deployer.

Serious incident

A serious incident is an incident or malfunction of an AI system that leads to serious harm, as defined in Art. 3 of the AI Act. For high-risk systems, the provider reports serious incidents to the authorities (Art. 73). A deployer that identifies one must immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities; informing the provider alone is not enough (Art. 26(5)). The deployer duty applies from 2 December 2027 (Annex III) or 2 August 2028 (Annex I Section A; Section B products follow the sector route in Art. 2(2)). Art. 73 is not expressly postponed, and its timing for a specific system needs a legal assessment. In practice, agree incident reporting with the vendor in advance. Where personal data is involved, the GDPR breach notification may apply as well. See how to respond to an AI incident.

Shadow AI

Shadow AI is AI tools used without the company knowing or approving: a free chatbot an employee signs up for with a work email, a browser extension that summarises meetings, or an AI feature switched on by default in software the company already pays for. It is rarely malicious, since people adopt tools because they help them do their job. The risk is that nobody has checked what data goes in, what the vendor’s terms allow or how the output is used. Treating the search for shadow AI as a hunt for rule-breakers makes people hide their tools. A better approach is an inventory that invites people to report what they use, followed by a safer alternative where needed. See how to find all the AI your company uses.

Substantial modification

A substantial modification is a change to an AI system after it has been placed on the market or put into service that the provider did not plan and that affects the system’s compliance or its intended purpose, as defined in Art. 3 of the AI Act. It matters because it can change who is responsible: under Art. 25, a deployer or other party that makes a substantial modification to a high-risk system, so that it remains high-risk, becomes its provider. A substantial modification can build up gradually through retraining, new features or new data, so it is worth checking whenever a system changes. See whether you are a provider or deployer and how to monitor AI after launch.

Vendor

In this library, a vendor is a company selling an AI product or service, such as a chatbot, a writing assistant or an AI feature inside other software. The word describes a commercial relationship, not a legal role. A vendor is often the provider of its AI system under the AI Act, but not automatically, and the term provider is used only for that legal role. For a company buying AI, the vendor’s terms and answers decide much of its position in practice: whether the model trains on company data, how long data is kept, whether a data processing agreement is in place, how model changes and incidents are handled and who holds rights in the output. What to ask an AI vendor includes a questionnaire.

Sources and further reading

• Regulation (EU) 2024/1689 (AI Act) — Articles 2–6, 10–14, 25–27, 50, 53, 72, 73, 86, 101 and 111, and Annexes I and III
• Regulation (EU) 2026/1744 (Digital Omnibus on AI)
• EU AI Act Service Desk — Article 3 (definitions)
• EU AI Act Service Desk — Article 6 (classification)
• EU AI Act Service Desk — Article 26 (deployer obligations)
• EU AI Act Service Desk — Article 27 (FRIA)
• EU AI Act Service Desk — Article 86 (right to explanation)
• Regulation (EU) 2016/679 (GDPR) — Articles 3, 9, 13–15, 22, 28, 30 and 32–35
• EDPB Guidelines 3/2018 on the territorial scope of the GDPR
• EDPB — Data breaches (guide for SMEs)
• Court of Justice of the EU, C-203/22 Dun & Bradstreet Austria (summary)
• NIST AI Risk Management Framework
• European Commission — AI Act overview