AI Governance
Glossary

Practitioner note The three definitions converge on machine-based inference generating outputs that influence environments. The EU AI Act version adds "adaptiveness after deployment" and "explicit or implicit objectives" as explicit criteria - both carry direct classification consequences under the Act.

Practitioner note Article 4 creates an obligation - not merely a goal - for providers and deployers to take measures to ensure sufficient AI literacy among staff who operate or oversee AI systems. This definition is the only one currently carrying legal weight in EU law.

Practitioner note The carve-out for systems "ancillary to another commercial service and strictly necessary for objective technical reasons" is narrow. Practitioners deploying systems that incidentally categorise users by protected characteristics need to assess whether the carve-out applies before assuming the system falls outside scope.

Practitioner note Most in-house legal, privacy and compliance teams procuring AI tools from third-party vendors are deployers, not providers, under the EU AI Act. The distinction determines which obligations apply and which can be contractually allocated to the provider.

Practitioner note The research and prototyping carve-out applies only before a model is placed on the market. Once deployed - even as a component in a downstream product - the carve-out no longer applies and GPAI obligations attach to the upstream model provider.

Practitioner note Classification as high-risk triggers the full Chapter III obligation set: risk management system, data governance, technical documentation, logging, transparency, human oversight, accuracy and robustness requirements. The Article 6(3) self-assessment carve-out is narrow and requires a documented rationale retained in the technical file.

Practitioner note Article 25 is the provision most in-house teams overlook: a deployer becomes a provider - and assumes provider obligations - when they place an AI system on the market under their own name, make a substantial modification to a high-risk system, or change the intended purpose of a system in a way that brings it into high-risk scope.

Practitioner note The EU Act's definition is simpler but the practical difference is material: the NIST formulation requires organisations to assess how many people are affected (breadth) and whether the harm can be undone (reversibility). Practitioners using the NIST AI RMF alongside the EU AI Act will need to map between the two frameworks explicitly.

Practitioner note Article 73 sets a tiered timeline, not a flat deadline. Death or serious harm to health: 10 days from provider awareness. All other serious incidents and serious malfunctioning: 15 days from awareness. The clock runs from when the provider becomes aware, not when the incident occurred - making the deployer-to-provider notification chain a contractual dependency that must be in place before deployment. Article 73(3) requires deployers to notify the provider "immediately" on becoming aware of an incident; if that chain is undefined, the provider's reporting window erodes before they know there is one. Note also that Article 73 applies to high-risk AI systems only. GPAI models with systemic risk have separate incident reporting obligations under Article 73(2).

Practitioner note The 10^25 FLOP threshold is a rebuttable presumption, not a hard boundary. Deployers integrating GPAI models should verify whether the underlying model has been designated as systemic risk: this affects the obligations that apply to the upstream provider and, indirectly, the due diligence required of the deployer.

Practitioner note The Act's tripartite distinction between training, validation and testing data is not merely technical - Article 10(2) requires providers to document governance practices for each category separately. Practitioners reviewing AI governance documentation should check that all three are addressed.

Practitioner note The EU Act frames transparency as a design obligation on providers and an operational obligation on deployers. The NIST framework frames it as an organisational accountability obligation that spans the entire AI lifecycle. Practitioners need both framings: the EU Act tells you what must be disclosed; the NIST framework tells you how to govern disclosure internally.