AI Act glossary: 14 terms that change company decisions

An AI Act glossary is useful when each definition leads to a decision: what must be checked, who owns the question, and what evidence should be retained. Labels such as “provider”, “deployer” and “high-risk” are not conclusions on their own. Each term needs to be tied to a specific system, intended purpose, organisational role and current legal text.

The controlling source is Regulation (EU) 2024/1689, as amended, among other instruments, by Regulation (EU) 2026/1744, which is in force. Poland published its Act on AI systems on 27 July 2026 as Journal of Laws 2026, item 1003. Dates and scope must be read together: some provisions have applied since 2025, most of the AI Act applies from 2 August 2026, and the full duties for specified high-risk systems were deferred to 2027 or 2028.

This guide is informational. It is not legal advice or a formal conformity assessment of a specific system. The Semitora artifacts below are implementation practices for organising evidence. The AI Act does not prescribe those document names or exact formats.

Table of contents

• How to use this glossary
• 14 AI Act terms: from definition to decision
• System, purpose and roles
• Risk and obligations
• GPAI, control and operation
• Polish market supervision
• FAQ: using AI Act terms in practice
• Sources and next steps

How to use this glossary

Test each definition at three levels: the model, the downstream system, and the business process in which an output affects a person or decision. One organisation may deploy an off-the-shelf tool and also provide a different system under its own name. The same model may support low-impact document summarisation and a separate recruitment process that requires an Annex III analysis.

Do not start with “what risk level does ChatGPT have?”. Start by recording the use case: inputs, outputs, users, affected people, integrations, intended purpose and actual use. The legal vocabulary becomes useful only after the operating facts are visible.

14 AI Act terms: from definition to decision

Term	What it means	Who should review it	Related artifact or page
AI system	The machine-based system defined in Article 3(1), which infers from inputs how to generate outputs that can influence an environment	Technical and business owners	System card and classification method
Intended purpose	The use specified by the provider, including its context and conditions, under Article 3(12)	Product owner and provider	Use-case statement, instructions and excluded uses
Provider	The actor that develops, or has developed, an AI system or GPAI model and places it on the market under its own name or trademark; for an AI system, the definition also covers putting it into service under that name or trademark, Article 3(3)	Legal, product owner and procurement	Role-and-obligation map
Deployer	The actor using an AI system under its authority, except for personal non-professional use, Article 3(4)	Process owner and compliance	Register of use, instructions and controls
Substantial modification	An unforeseen change affecting high-risk compliance or changing the assessed intended purpose, Article 3(23)	Change owner, provider and compliance	Change record and renewed classification
Prohibited practice	A use covered by the prohibitions in Article 5, subject to their conditions and exceptions	Legal, compliance and sponsor	“Stop or redesign” decision record
High-risk system	A system that meets the Article 6 route through Annex I or Annex III	Legal, product compliance and system owner	Requirements-to-evidence matrix
Transparency obligation	An information or labelling duty for cases covered by Article 50	Product and content owners	Notice register and Article 50 test
General-purpose AI model	A model with significant generality that performs many tasks and can be integrated into varied systems, Article 3(63)	Vendor owner and architect	Model and dependency due diligence
GPAI model with systemic risk	A GPAI model meeting the capability or Commission-designation route in Article 51 and Article 3(65)	Model provider and AI Office	Model documentation, evaluations and incident reports
AI literacy	Skills, knowledge and understanding needed for informed AI use, Article 3(56) and amended Article 4	HR, process owner and compliance	Role-based literacy plan
Human oversight	Article 14 measures enabling suitable people to understand, challenge and stop a high-risk system	Operating owner and risk owner	Oversight procedure and effectiveness test
Post-market monitoring	Provider activities for reviewing operational experience and identifying corrective action, Article 3(25) and Article 72	Provider, operations and security	Monitoring plan, metrics and triggers
Serious incident	An incident or malfunction producing the effects listed in Article 3(49)	Incident manager, legal and provider	Incident register and reporting route

System, purpose and roles

AI system

An AI system is a machine-based system that infers from its inputs how to generate outputs capable of influencing physical or virtual environments. Article 3(1) covers varying levels of autonomy and possible adaptiveness after deployment. A product name or marketing claim does not settle the question. The analysis should describe the working arrangement: model, rules, data, integrations and how the output is used.

The system boundary affects every later conclusion. If a recruitment assistant retrieves CVs from an ATS, produces a ranking and presents it to a recruiter, the data sources, ranking rules, integration and reviewer interface all matter. The language model alone is not the complete risk object.

Intended purpose

Intended purpose is the provider-specified use, including the context and conditions recorded in instructions, technical documentation and promotional or sales materials. Article 3(12) means that a purpose change can have legal consequences even when the code and model remain unchanged. A writing assistant does not become a candidate-ranking system merely because it can technically process a CV.

Write the purpose in one sentence in the AI-system register, then add excluded uses. Compare that statement with logs, instructions and actual user behaviour. A gap between declared purpose and real operation is a review trigger.

Provider

A provider develops, or has developed, an AI system or GPAI model and places it on the market under its own name or trademark; for an AI system, the definition also covers putting it into service under that name or trademark. Article 3(3) covers paid and free supply. A company does not always remain a deployer merely because it consumes an external API. Its own branding, a changed intended purpose or a substantial modification may require the role to be reassessed.

The role map should distinguish the model provider, downstream system provider, importer, distributor and deployer. A single “vendor” label hides responsibility. Contract wording can allocate work between parties, but it does not rewrite statutory definitions.

Deployer

A deployer uses an AI system under its authority for an activity other than personal non-professional use. The Article 3(4) definition covers most organisations using ready-made tools. The role is not passive. Depending on the system classification and use, a deployer may need controls around instructions, input data, human oversight, logs, monitoring or information to affected people.

Assign a business-process owner for each use. That owner can confirm where the output goes, who can reject it and what happens after an error. Procurement understands the contract but often does not see the complete operating flow.

Substantial modification

A substantial modification is an unforeseen post-market or post-deployment change that affects high-risk compliance or alters the intended purpose for which the system was assessed. That is the Article 3(23) test. Not every model update crosses this threshold, but every material change needs an impact screen.

Practical triggers include a new purpose, user population, country, data source, decision channel or level of automation. The change record should identify the previous and new versions, classification impact and the person approving continued use.

Risk and obligations

Prohibited practice

A prohibited practice is a use that meets the conditions in Article 5, not any system described as “unethical”. The provision contains specific criteria and exceptions, so keyword screening is insufficient. If a use is prohibited, added monitoring or sponsor approval does not make it lawful. The decision should be “stop”, “redesign”, or “escalate for formal legal analysis”.

The prohibitions have applied since 2 February 2025. That is a different date from the general application of the Regulation and the deferred high-risk timetable. A defensible decision record identifies the practice tested, facts, legal condition, exceptions and reviewer.

High-risk system

A system is high-risk when it reaches that result through Article 6 and Annex I or Annex III. The Annex I route concerns an AI system that is a product or safety component covered by specified harmonisation legislation, subject to the third-party assessment conditions. Annex III lists use cases in areas such as employment, education and access to essential services, with conditions and potential exclusions.

Do not classify a complete supplier or department with one label. Amended Article 113 keeps the general application date of 2 August 2026. Chapter III, Sections 1–3, except Article 6(5), apply from 2 December 2027 to high-risk systems referred to in Article 6(2) and Annex III, and from 2 August 2028 to systems referred to in Article 6(1) and Annex I. Those dates do not switch off the prohibitions, AI literacy, transparency or other provisions already in application.

Transparency obligation

A transparency obligation is a specific notice or marking requirement for a case covered by Article 50. Depending on the paragraph, it may address an AI interaction, machine-readable marking of specified outputs, or disclosure of deepfake content. The responsible actor and exceptions depend on the channel, the content and the relevant paragraph.

A generic “powered by AI” statement in terms and conditions is not an implementation test. Review when the notice appears, whether people can perceive it, accessibility and what happens when the channel changes. Our Article 50 labelling guide provides a practical route through those questions.

GPAI, control and operation

General-purpose AI model

A GPAI model displays significant generality, can competently perform a broad range of distinct tasks and can be integrated into varied downstream systems. Article 3(63) defines the model category. GPAI is not a fifth risk level for the downstream system. It is a separate model regime that can coexist with the classification of the final use case.

An organisation consuming an API should know the model provider, acceptable-use rules, version, available documentation and constraints. It must still classify its downstream system separately. The model dependency list belongs in an Evidence Pack, but it does not replace documentation owed by the GPAI provider.

GPAI model with systemic risk

A GPAI model with systemic risk meets the high-impact capability route or an equivalent Commission designation under Article 51. “Systemic risk” in Article 3(65) concerns effects capable of propagating at scale across the value chain and having significant consequences for the Union market, health, safety, public security, fundamental rights or society.

Do not apply this category to every popular model. It is a formal model-provider classification under the mechanism in the Regulation. A deployer should still understand which model it depends on and how it will learn about material changes to capabilities or limitations.

AI literacy

AI literacy means the skills, knowledge and understanding required for informed AI deployment and use, including awareness of opportunities, risks and possible harm. Article 3(56) supplies the definition. Article 4, as replaced by Regulation 2026/1744, requires providers and deployers to take measures supporting the development of AI literacy among people operating AI on their behalf. It does not require them to guarantee one universal level.

The plan should follow roles. A person reviewing an HR recommendation needs different preparation from an integration administrator or incident responder. Attendance at a generic course is not proof that an operational control works.

Human oversight

Human oversight under Article 14 should enable suitable people to understand a high-risk system’s limits, detect anomalies, challenge outputs and stop operation safely. Placing a person after the model is insufficient if that person lacks time, information, authority or a realistic ability to disregard the result.

Test oversight in a difficult scenario: conflicting data, uncertainty, an integration failure or an output that contradicts procedure. Record the response time, available information, decision and effect of intervention. That turns the legal term into an observable control.

Post-market monitoring

Post-market monitoring covers provider activities for collecting and reviewing experience from operational use and identifying a need for corrective or preventive action. Article 3(25) defines the system, while Article 72 provides the high-risk monitoring requirements. It is not a one-off report written before launch.

Tie each metric to a threshold, owner and response: escalation, feature restriction, correction or suspension. After a model change, measurements must remain traceable to the relevant version, method and sample.

Serious incident

A serious incident is an event or malfunction that directly or indirectly causes one of the effects listed in Article 3(49). These include death or serious harm to health, a serious and irreversible disruption of critical infrastructure, infringement of Union-law obligations protecting fundamental rights, or serious harm to property or the environment.

Incident classification needs facts, actor roles and the applicable reporting route. The operating record should retain discovery time, system version, impact, containment and the reporting decision. Not every quality defect is a serious incident, but every defect needs an escalation path.

Polish market supervision

Poland’s Commission for the Development and Security of Artificial Intelligence is the market-surveillance authority and single point of contact established by the national Act on AI systems. Article 5 of Journal of Laws 2026, item 1003 assigns those roles, while Article 125 creates the Commission. The national provisions have different commencement dates.

Article 125(4) has applied since 28 July 2026. Most remaining provisions entered into force on 11 August 2026. Articles 8–18 and Chapters 3–5, 8 and 9 enter into force on 28 October 2026. Polish shorthand sometimes uses “KRiBSI”; the enacted text uses the full name and the short form “Commission”. The national authority does not change the EU-law definitions of provider and deployer.

FAQ: using AI Act terms in practice

Is a company using an off-the-shelf tool a provider or a deployer?

It will usually be a deployer when it uses the system under its authority. The answer may change if the company supplies a system under its own name, changes the intended purpose or makes a modification that affects compliance. Review the facts and supply chain, not the contract title.

Is every system built on a GPAI model high-risk?

No. GPAI is a model layer. High-risk status for the downstream system follows from Article 6, Annex I or Annex III and the specific use case. The same model can support several systems with different classifications.

Does “human in the loop” prove compliance with human-oversight duties?

Not automatically. The person needs competence, relevant information, time and authority to challenge or stop the system. The interface and process must also avoid routine rubber-stamping of outputs.

When should the classification be repeated?

Repeat it after a change in purpose, function, model, data, integration, user group, market or effect on a decision. Add a periodic review as well. An event trigger is more useful than an arbitrary calendar date on its own.

Can Semitora issue a formal legal classification of a system?

Semitora can prepare the technical system description, role map, criteria test and evidence package. Formal legal interpretation and conformity decisions remain with the appropriate qualified people and, where required, competent authorities or assessment bodies.

Sources and next steps

The definitions and article references come from the current AI Act text in EUR-Lex, read together with amending Regulation 2026/1744. Poland’s supervision model and commencement dates come from the Act on AI systems, Journal of Laws 2026, item 1003. The official sources were checked on 27 August 2026.

Use the AI Act risk-classification method to move from vocabulary to a specific system. The readiness checklist organises the company-level baseline, while the Evidence Pack guide structures the supporting record. Our governance guide for regulated industries explains how decisions remain current. To connect the inventory, classification, testing and remediation plan, see Semitora services.