Glossary
158 key terms, pulled from the reference notes. Grows as each competency is built out.
- Acceptable use policy (AUP) I.C
- Rules defining permitted and prohibited uses of AI tools by employees (e.g., what data may be entered into public generative-AI tools), a core control against shadow AI.
- Accountable vs. responsible I.B
- Accountable = the single owner who answers for the outcome and cannot delegate the answerability. Responsible = those who do the work. The exam relies on this distinction.
- Agentic AI I.A
- AI systems that plan and take sequences of actions toward a goal with limited human intervention, often invoking tools or other systems.
- Agentic architecture IV.A
- A system in which the model plans and executes multi-step actions, invoking tools or other systems with limited human intervention. Highest capability and highest risk (autonomy, tool misuse, cascading errors).
- AI audit III.C
- A systematic, often independent evaluation of whether the system conforms to defined criteria (policies, standards, law) — assurance, distinct from adversarial red teaming.
- AI deployer I.B
- Under the EU AI Act, the actor that uses an AI system under its own authority in a professional capacity (not as an end consumer). Responsible for proper use, human oversight and monitoring in context.
- AI developer I.B
- The actor that designs, codes and trains an AI model/system. Bears responsibility for how the model is built — data, training, documentation, intended purpose.
- AI governance committee I.B
- A standing cross-functional body (often a council or board) that sets AI policy, reviews high-risk use cases, and provides oversight and accountability across the organization. The central coordinating structure recommended by the NIST AI RMF Govern function and ISO/IEC 42001.
- AI impact assessment (AIA) IV.B
- A structured evaluation of an AI system's potential effects on individuals, groups and society — risks, benefits, affected stakeholders and mitigations — documented across the life cycle. ISO/IEC 42005 gives guidance; the EU AI Act mandates a related FRIA for some deployers.
- AI incident III.C
- An event where an AI system causes or nearly causes harm, fails, or behaves outside intended bounds. Serious incidents may trigger reporting duties (EU AI Act Art. 73).
- AI life cycle I.C
- The stages an AI system passes through — use-case assessment, design, data acquisition, model/system development, training and testing, deployment, monitoring, and retirement. Policies must give oversight at every stage.
- AI provider I.B
- Under the EU AI Act, the actor that develops an AI system (or has it developed) and places it on the market or puts it into service under its own name or trademark. Carries the heaviest obligations.
- AI system I.A
- A machine-based system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. (OECD 2024 / EU AI Act Art. 3(1))
- AI user I.B
- The end user or affected person who interacts with or is subject to the AI system’s outputs. Needs transparency, notice and avenues for redress.
- Algorithmic disgorgement II.B
- An FTC remedy requiring a company to delete models and algorithms built on illegally obtained data — destroying the ill-gotten asset, not just fining it.
- Architecture & model selection III.A
- Choosing the system design and model type (e.g., classic vs. generative, build vs. buy, interpretable vs. black-box) to fit the requirements and risk profile.
- Audit / transparency rights IV.B
- The deployer's contractual right to obtain information about, test, or audit the vendor's model, data and security — needed to meet the deployer's own regulatory and due-diligence duties.
- Automated decision-making (GDPR Art. 22) II.A
- A right not to be subject to a solely automated decision producing legal or similarly significant effects, with exceptions and safeguards (human intervention, contestation, explanation).
- Benchmarking III.A
- Comparing a model or design against established baselines, standard datasets or competing approaches to judge whether performance is adequate for the use case.
- Bias (harmful) I.A
- Systematic error that produces unfair outcomes. NIST groups it into systemic, statistical/computational and human-cognitive bias.
- Bias testing III.B
- Measuring performance disparities across groups (e.g., demographic parity, equalised odds) to detect harmful bias before deployment.
- Biometric data II.A
- Personal data resulting from specific technical processing of physical, physiological or behavioural characteristics (e.g., face, fingerprint) that allows unique identification. Special-category when used to identify a person.
- Brittleness / lack of robustness III.C
- A model that performs well on expected inputs but fails badly on edge cases, noisy data or out-of-distribution inputs — a common incident root cause.
- Business context / use case III.A
- The problem the AI is meant to solve, who it affects, the decisions it informs, success criteria and constraints — the framing that NIST AI RMF captures in its MAP function before any building begins.
- Classic (discriminative) AI IV.A
- Models that predict or classify a defined target (fraud score, churn, image label). Narrow, often cheaper and more interpretable, with well-bounded behaviour.
- Cloud vs. on-premise vs. edge IV.A
- The three deployment locations. Cloud = scalable, managed, lower control; on-premise = maximum control/privacy, higher cost and ops burden; edge = on-device, lowest latency and best data locality, but constrained compute.
- Colorado AI Act (SB 24-205) II.C
- Leading U.S. state AI law: a duty of reasonable care on developers and deployers of high-risk AI to avoid algorithmic discrimination — a risk-of-harm model, narrower than the EU AI Act.
- Concept drift III.C
- The relationship between inputs and the target itself changes (what a "good" answer is shifts), so a once-accurate model becomes wrong.
- Conformity assessment II.C
- The pre-market process by which a high-risk system's compliance is verified (often self-assessment), followed by a CE marking and EU database registration.
- Conformity assessment III.C
- The EU AI Act process (Art. 43) by which a provider demonstrates a high-risk system meets the Act's requirements before market placement, evidenced by the CE marking and an EU declaration of conformity.
- Continuous monitoring III.C
- Ongoing observation of a deployed model's performance, inputs and outputs to detect degradation, drift, errors or misuse in production.
- Continuous monitoring IV.C
- Ongoing observation of a deployed AI system's inputs, outputs and performance to detect drift, degradation, bias, misuse or failure in production — not a one-time pre-deployment check.
- Cross-border transfer II.A
- Movement of personal data outside the EEA, lawful only with an adequacy decision or appropriate safeguards (e.g., Standard Contractual Clauses). Relevant where AI training or inference happens abroad.
- Cross-functional collaboration I.B
- Bringing legal, privacy, security, data science, product, HR, compliance, ethics and business units together so AI risk is seen from multiple expert perspectives, not just one function.
- Data controller II.A
- The party that determines the purposes and means of processing. Bears the primary accountability for GDPR compliance when deploying or training AI.
- Data drift III.C
- The input data distribution shifts away from the training distribution over time (covariate shift), degrading performance even though the relationship being modelled is unchanged.
- Data governance I.C
- The framework of policies and controls governing how data is acquired, quality-checked, used, retained and protected — a frequent existing policy that AI forces organizations to extend.
- Data governance III.B
- The policies, roles and controls ensuring data used to train and test AI is lawfully obtained, high-quality, well-managed and fit for purpose. A core EU AI Act high-risk requirement (Art. 10).
- Data lineage III.B
- The end-to-end record of where data came from and every transformation it underwent (collection → cleaning → labelling → feature engineering → training set).
- Data minimization (GDPR Art. 5(1)(c)) II.A
- Personal data must be adequate, relevant and limited to what is necessary for the purpose — in tension with AI's appetite for large training datasets.
- Data poisoning III.B
- An attack that corrupts training data to degrade the model or implant a backdoor — a security risk that must be tested for during the training pipeline.
- Data processor II.A
- A party that processes personal data on the controller's behalf (e.g., a cloud AI vendor). Must be bound by an Art. 28 contract and act only on documented instructions.
- Data provenance III.B
- The documented origin and ownership history of a dataset — source, collection method, rights and chain of custody. Underpins trust, reproducibility and IP/legal defensibility.
- Data subject rights (DSRs) II.A
- Individual rights under the GDPR: access, rectification, erasure, restriction, portability, objection, and rights around automated decisions — all of which AI systems must be able to honour.
- Data-use / training rights IV.B
- Contract terms governing whether the vendor may use the deployer's inputs, prompts or data to train or improve its models. Critical for confidentiality, IP and privacy compliance.
- Deployer II.C
- A party using an AI system under its own authority (other than personal, non-professional use). Lighter but real obligations: oversight, monitoring, input data, notice.
- Deployer IV.A
- Under the EU AI Act, any person or organization using an AI system under its own authority (not for personal, non-professional use). The deployer is the perspective of all of Domain IV — distinct from the provider/developer.
- Disparate impact II.B
- A facially neutral practice (including an algorithm) that disproportionately harms a protected group, without sufficient justification. Does not require intent — central to AI bias liability.
- Disparate treatment II.B
- Intentional discrimination — treating someone worse because of a protected characteristic. One of two theories of discrimination liability.
- Downstream harm IV.C
- Negative effects that surface beyond the immediate output — on third parties, society, or via misuse of the outputs. Forecasting these is an explicit deployer duty.
- DPIA (GDPR Art. 35) II.A
- Data Protection Impact Assessment — a mandatory prior assessment when processing is likely to result in a high risk to individuals, including most large-scale or novel AI processing.
- ECOA II.B
- Equal Credit Opportunity Act — prohibits discrimination in any aspect of a credit transaction; requires adverse-action notices, which strain opaque AI models.
- Ethics by design I.C
- Embedding ethical and responsible-AI considerations into the system from the outset of design rather than bolting them on afterward (cf. privacy by design).
- EU AI Act II.C
- Regulation (EU) 2024/1689 — the first comprehensive horizontal AI law. Classifies AI systems by risk and imposes obligations by tier and by role, with phased application from 2025–2027.
- EU Product Liability Directive (revised) II.B
- Updated EU regime (2024) extending strict product-liability rules to software and AI systems, easing the burden of proof for claimants harmed by AI.
- Explainability I.A
- The ability to describe, in human terms, the mechanism by which an AI system produced an output (how it works). Distinct from interpretability and transparency.
- External communication plan IV.C
- A pre-agreed plan for what is disclosed to users, affected people, regulators and the public — including AI-use transparency notices and incident communications.
- FHA II.B
- Fair Housing Act — bars discrimination in housing and related services, including by algorithmic tenant-screening and targeted-advertising tools.
- Fine-tuning IV.A
- Further training a base model on task- or domain-specific data so the weights themselves change. Best for steady style/format/domain adaptation; costs data, compute and re-validation.
- Fit-for-purpose III.B
- Whether the data is relevant, representative and appropriate for the specific intended use — not just abundant. Wrong-population data is unfit even if plentiful and clean.
- Foundation model I.A
- A large model trained on broad data at scale that can be adapted (e.g., fine-tuned, prompted) to many downstream tasks. Large language models (LLMs) are a subset.
- FTC Act §5 (UDAP) II.B
- Bars "unfair or deceptive acts or practices" in commerce. The FTC's main tool against deceptive AI claims and unfair AI uses.
- Fundamental Rights Impact Assessment (FRIA) II.C
- An assessment certain deployers of high-risk AI (e.g., public bodies) must perform on impacts to fundamental rights before use (AI Act Art. 27).
- Fundamental Rights Impact Assessment (FRIA) III.A
- EU AI Act Art. 27 obligation on certain deployers of high-risk AI (public bodies and some private actors) to assess impacts on fundamental rights before first use.
- Fundamental Rights Impact Assessment (FRIA) IV.B
- A deployer-side assessment required by the EU AI Act (Art. 27) for certain high-risk systems used by public bodies and some private deployers, focused on impacts to fundamental rights of affected persons.
- Generative AI I.A
- AI that creates new content (text, images, audio, code) by modelling the distribution of its training data; typically built on foundation models.
- Generative AI IV.A
- Foundation-model-based systems that produce new content (text, image, code, audio). More flexible but prone to hallucination, harder to evaluate, and raises IP/data questions.
- Govern (NIST) II.D
- The cross-cutting NIST function: a culture of risk management — policies, roles, accountability and processes that span the other three functions.
- Governance maturity I.B
- How developed an organization’s AI governance is. Programs are right-sized to company size, maturity, industry, products, objectives and risk tolerance rather than copied wholesale.
- GPAI model II.C
- General-purpose AI model — trained on broad data, displaying significant generality, usable across many tasks. Subject to dedicated transparency and copyright obligations.
- Ground truth III.B
- The trusted, correct labels/answers a model is trained against and evaluated on; its quality caps the quality of everything learned from it.
- High-risk AI system II.C
- Systems posing significant risk to health, safety or fundamental rights (Annex III areas + safety components of regulated products). Subject to the heaviest obligations short of prohibition.
- Human oversight III.A
- Designing the system so a person can understand, monitor, intervene in or override it. EU AI Act Art. 14 mandates effective oversight measures for high-risk AI ("human in / on / over the loop").
- Human-authorship requirement II.B
- U.S. copyright protects only works of human authorship; purely AI-generated output with no human creative control is not copyrightable (U.S. Copyright Office guidance).
- Impact assessment (AIA) III.A
- A structured, documented evaluation of an AI system's potential effects on people, groups and society across the life cycle. ISO/IEC 42005 gives the method; the EU AI Act requires a Fundamental Rights Impact Assessment (FRIA) for certain high-risk deployers.
- Incident management I.C
- Policies and procedures to detect, escalate, respond to, document and learn from AI failures, harms and near-misses.
- Indemnification IV.B
- A contractual promise by one party to cover specified losses of the other (e.g., a vendor indemnifying the deployer against third-party IP-infringement claims arising from model output). A key term to negotiate in AI vendor agreements.
- Instructions for use III.C
- Provider-supplied documentation telling deployers how to operate the system safely and within its limits — required for high-risk AI (EU AI Act Art. 13).
- Intellectual property (IP) risk I.C
- Risk around rights to training data, ownership/authorship of AI outputs, and confidentiality — an existing-policy area AI reshapes.
- Interpretability testing III.B
- Evaluating whether the model's behaviour can be explained/understood (e.g., feature importance, SHAP/LIME), so reviewers can trust and audit it.
- IP ownership IV.B
- Who owns the inputs, the fine-tuned model, and the generated outputs. Must be explicit, especially given uncertainty over copyright in AI-generated content.
- ISO/IEC 22989 II.D
- The foundational ISO/IEC standard for AI concepts and terminology — standard definitions of AI system, ML, life-cycle stages, etc.
- ISO/IEC 42001 II.D
- The certifiable AI management system (AIMS) standard — a Plan-Do-Check-Act management system for AI, analogous to ISO 27001 for security.
- ISO/IEC 42005 II.D
- Guidance for conducting and documenting AI system impact assessments across the life cycle.
- Kill switch / deactivation control IV.C
- A policy and technical capability to rapidly disable, roll back or contain a system that is malfunctioning, causing harm, or out of compliance.
- Lawful basis (GDPR Art. 6) II.A
- Processing of personal data is only lawful if it rests on one of six bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests. AI training and inference each need their own valid basis.
- Lawful rights to use data III.B
- Confirmed legal basis to collect and use the data — consent or other GDPR lawful basis, licensing, IP/copyright clearance and contractual permission — assessed and documented before training.
- Liability cap IV.B
- A contractual ceiling on how much a party can be required to pay for damages. Vendors often cap liability low (e.g., to fees paid); a red flag when the deployment risk is high.
- Localization IV.C
- Restricting or adapting a system's availability or behaviour by jurisdiction (e.g., disabling a feature where it is non-compliant, or keeping data in-region) to meet regulatory requirements.
- Machine learning (ML) I.A
- An approach in which a system learns patterns from data rather than being explicitly programmed with rules. The dominant technique behind modern AI.
- Manage (NIST) II.D
- NIST function to prioritise, respond to and treat risks (mitigate, transfer, avoid, accept) on an ongoing basis.
- Map (NIST) II.D
- NIST function to establish context and frame risks — identify the use case, stakeholders, and where harms could arise.
- Measure (NIST) II.D
- NIST function to analyse, assess, benchmark and monitor AI risks using quantitative and qualitative methods.
- Metric and threshold evaluation III.A
- Defining the metrics that measure success (accuracy, precision/recall, fairness gaps) and the acceptance thresholds a system must meet to proceed.
- Model / data drift IV.C
- Degradation of model performance over time as real-world data diverges from the training distribution (data drift) or the relationship being modelled changes (concept drift). The main reason monitoring and retraining are needed.
- Model card III.C
- A standardised summary of a model — intended use, training data, performance across conditions/groups, limitations and ethical considerations — published for transparency to downstream users.
- Model-change notice IV.B
- A vendor's obligation to notify the deployer before materially changing, deprecating or retiring a model — without it, behaviour can silently drift and break the deployer's validation.
- Multimodal model IV.A
- A model that processes and/or generates more than one modality (e.g., text + image + audio). Expands use cases but widens the attack and risk surface.
- Narrow AI (ANI) I.A
- AI designed for a specific task or narrow set of tasks. All AI in production today is narrow AI.
- NIST AI RMF II.D
- A voluntary U.S. framework (AI RMF 1.0, 2023) to manage AI risks, organised around four functions — Govern, Map, Measure, Manage.
- NIST AI RMF — Manage IV.C
- The RMF function covering prioritizing, responding to, and monitoring AI risks of deployed systems over time — the framework anchor for IV.C.
- NIST AI RMF Playbook II.D
- A companion resource giving suggested, voluntary actions, references and documentation for each function's categories and subcategories.
- OECD AI Principles II.D
- The most widely adopted values-based, non-binding AI principles (2019, updated 2024): inclusive growth/well-being, human-centred values & fairness, transparency & explainability, robustness/security/safety, and accountability.
- OECD AI-system definition II.D
- The internationally referenced definition of an AI system adopted (almost verbatim) by the EU AI Act — a machine-based system that infers from input how to generate outputs, with varying autonomy and adaptiveness.
- Opacity / black box I.A
- The difficulty of understanding how an AI system reached a particular output, especially with deep neural networks.
- Open-source / open-weight model IV.A
- A model whose weights (and sometimes code/data) are released for self-hosting and modification. More control, customizability and on-prem privacy, but you own the safety, security and maintenance burden.
- Operational controls III.A
- Guardrails built into how the system runs — access controls, rate limits, input/output filtering, fallback behaviours, logging and kill-switches.
- Overfitting III.B
- When a model memorises training data (including noise) and fails to generalise — high training accuracy, poor test accuracy. Detected by comparing train vs. validation/test performance.
- Policy I.C
- A high-level statement of intent and rules that sets the organization’s expectations (the "what" and "why"). Procedures and standards operationalize it (the "how").
- Post-market monitoring III.C
- The provider's systematic, documented collection and review of a high-risk system's performance in the field after deployment (EU AI Act Art. 72), feeding corrective action.
- Post-market monitoring IV.C
- The EU AI Act provider duty (and good deployer practice) to collect and review data on a system's performance and incidents after it is in use, feeding fixes and reporting.
- Pre-deployment pilot III.A
- A limited, controlled rollout (shadow mode, A/B, sandbox) used to test the system on real or representative conditions before full deployment.
- Privacy by design and by default (GDPR Art. 25) II.A
- Data-protection safeguards must be built into systems from the outset and the most privacy-protective settings applied by default — not bolted on later.
- Probabilistic output I.A
- AI outputs are statistical likelihoods, not fixed rule-based results — the same input can yield different outputs, unlike deterministic software.
- Probability/severity harms matrix III.A
- A risk-rating grid that scores each potential harm by how likely it is (probability) against how bad it would be (severity) to prioritise mitigation.
- Procurement I.C
- The buying process for AI systems and components; a key control point for embedding governance requirements (assessments, contract clauses) before adoption.
- Product liability II.B
- Legal responsibility of makers/sellers for harm caused by defective products, via design defects, manufacturing defects, or failure-to-warn (inadequate instructions/warnings).
- Prohibited AI practices (Art. 5) II.C
- Unacceptable-risk uses banned outright, e.g. social scoring by public authorities, manipulative/exploitative systems, untargeted facial-image scraping, and (mostly) real-time remote biometric ID in public by law enforcement.
- Prompt engineering IV.A
- Adapting model behaviour purely through instructions/examples in the prompt, leaving weights and data unchanged. The cheapest, fastest, lowest-governance adaptation technique.
- Proprietary (closed) model IV.A
- A model accessed as a service (e.g., via API) whose weights are not released. Lower setup effort and managed safety, but vendor lock-in, less control and data-residency concerns.
- Proprietary-model deployer IV.B
- An organization deploying a model it developed itself. It carries both provider and deployer obligations, more direct liability, and the full burden of safety, documentation and maintenance — with no vendor to indemnify it.
- Provider II.C
- The party that develops an AI system/model (or has it developed) and places it on the market or puts it into service under its own name. Bears the heaviest AI Act obligations.
- Provider vs. deployer IV.B
- EU AI Act roles: the provider develops/places the system on the market; the deployer uses it under its own authority. Building your own model collapses both roles onto one organization.
- Purpose limitation (GDPR Art. 5(1)(b)) II.A
- Personal data collected for one specified purpose may not be further processed in a way incompatible with that purpose. Re-using data to train AI can be an incompatible secondary use.
- RACI I.B
- A responsibility-assignment matrix mapping who is Responsible, Accountable, Consulted and Informed for each governance task. Used to remove ambiguity about AI roles. Exactly one party is Accountable per task.
- Red teaming III.C
- Adversarial testing in which a team deliberately tries to make the system fail, produce harmful output or be misused — to surface weaknesses before attackers or reality do.
- Red teaming IV.C
- Structured adversarial testing in which testers deliberately try to make the system fail, produce harmful output, or be misused — to find weaknesses before adversaries or users do.
- Release readiness III.C
- A go/no-go gate confirming the system meets its acceptance thresholds, has its documentation and model card, and satisfies any conformity requirements before entering production.
- Requirements gathering III.A
- Eliciting and documenting functional, performance, legal, ethical and data requirements the system must meet — the basis for architecture and model selection.
- Responsible AI I.A
- The practice of designing, building and using AI in line with shared principles — fairness, safety, privacy/security, transparency/explainability, accountability and human-centricity.
- Retraining schedule IV.C
- A planned cadence (and triggers) for refreshing or retraining the model to counter drift — balanced against the re-validation, testing and approval each retrain requires.
- Retrieval-augmented generation (RAG) IV.A
- Supplying the model with relevant external documents at inference time so answers are grounded in current, controllable data. Best for freshness, citations and reducing hallucination — without retraining.
- Risk mitigation hierarchy III.A
- An ordered preference for handling risk: first avoid/eliminate, then reduce/mitigate, then transfer (e.g., insurance, contracts), then accept residual risk with sign-off.
- Risk tolerance I.B
- The level and type of AI risk an organization is willing to accept in pursuit of its objectives. Drives how strict controls and approval gates are.
- Risk-tier framework II.C
- The AI Act sorts systems into four tiers — prohibited (unacceptable), high, limited (transparency), and minimal risk — with obligations scaling to risk.
- Secondary / unintended use IV.C
- Using a system for a purpose it wasn't designed or validated for (function creep). A leading source of downstream harm; must be forecast and constrained.
- Serious-incident reporting IV.C
- The EU AI Act obligation (Art. 73) to report serious incidents and malfunctions of high-risk AI to authorities within set timeframes; deployers must inform providers/authorities of incidents they observe.
- Service-level agreement (SLA) IV.B
- Committed performance/availability metrics (uptime, latency, support response) and remedies for failing them. For AI, should also address accuracy/quality and model-change behaviour.
- Shadow AI I.C
- Unsanctioned use of AI tools by employees outside governance — a primary risk an acceptable-use policy is designed to address.
- Shared responsibility IV.B
- The division of governance duties between vendor and deployer. Buying a model does not outsource accountability — the deployer remains responsible for how it is used.
- South Korean AI Basic Act II.C
- Asia's first comprehensive AI law (effective Jan 2026): high-impact AI duties, generative-AI transparency, and a domestic-representative requirement for large foreign providers.
- Special-category data (GDPR Art. 9) II.A
- Sensitive data (race, health, biometrics used for ID, sexual orientation, religion, political opinion, etc.) whose processing is prohibited unless a specific exception applies.
- Stakeholder mapping III.A
- Identifying everyone who affects or is affected by the system — users, subjects, operators, affected non-users, regulators — to surface impacts and assign engagement.
- Systemic-risk GPAI II.C
- A GPAI model with high-impact capabilities — presumed where training compute exceeds 10^25 FLOPs — triggering extra obligations (evaluation, adversarial testing, incident reporting, cybersecurity).
- Third-party / vendor risk I.C
- Risk introduced by external AI models, components, data or services. Managed through due-diligence assessments, contractual terms and ongoing oversight.
- Threat modeling III.C
- A structured analysis of how a system could be attacked or abused (assets, attackers, attack surfaces) to prioritise defences.
- Threat modeling IV.C
- Systematically identifying how a system could be attacked or abused (e.g., data poisoning, prompt injection, model extraction) so defenses can be prioritized.
- Three lines model I.B
- A governance structure: first line (business/operational owners who own the risk), second line (risk, compliance, legal who set policy and oversee), third line (internal audit who provides independent assurance).
- Title VII II.B
- U.S. Civil Rights Act provision barring employment discrimination based on race, color, religion, sex or national origin — reaches AI hiring and HR tools.
- Tone at the top I.B
- Visible senior-leadership and board commitment to responsible AI; sets culture and signals that governance is a priority, not an afterthought.
- Train/validation/test split III.B
- Partitioning data so the model learns on the training set, is tuned on the validation set, and is evaluated once on a held-out test set to estimate real-world performance.
- Training-data infringement II.B
- The unresolved question of whether copying copyrighted works to train an AI model is infringement or a permitted use (e.g., fair use in the U.S.). A central live IP dispute.
- Transparency I.A
- Disclosing meaningful information about an AI system — that it exists, how it is used, its data and its limitations — to relevant stakeholders.
- Trustworthy AI characteristics (NIST) II.D
- Valid & reliable (foundational); safe; secure & resilient; accountable & transparent; explainable & interpretable; privacy-enhanced; and fair with harmful bias managed.
- Use-case assessment I.C
- An early gate that evaluates whether a proposed AI use is appropriate, lawful, valuable and within risk tolerance before resources are committed.
- Use-case context IV.A
- The full picture a deployer must understand before deploying: business objectives, performance requirements, data availability and quality, ethical considerations, and workforce readiness.
- Validation vs. verification III.B
- Verification = "did we build the system right?" (meets spec). Validation = "did we build the right system?" (meets the real-world need). A validation dataset also tunes a model during training, separate from the held-out test set.
- Workforce readiness IV.A
- Whether the people who will operate, oversee and rely on the system have the skills, training and literacy to use it safely — a precondition the EU AI Act makes explicit (AI literacy, Art. 4).