Regulation (EU) 2024/1689 defines 68 Article 3 terms your organization should govern consistently across policies, inventories, technical documentation, disclosures, and quality systems. After the 2026 AI Omnibus political agreement, the useful 2026 work is Article 50, GPAI, inventory, and terminology evidence readiness — not a stale high-risk countdown. Last verified: 2026-06-22; re-check final Official Journal text after AI Omnibus adoption.
Terminology governance is one prerequisite you can build now. Article 3 of Regulation (EU) 2024/1689 defines 68 terms. 2 August 2026 remains relevant for Article 50 transparency and Commission enforcement powers over GPAI model providers. Under the 7 May 2026 AI Omnibus political agreement, stand-alone high-risk rules move to 2 December 2027 and product-integrated high-risk rules move to 2 August 2028 as planning dates pending final legal text.
The EU AI Act entered into force on August 1, 2024. Its obligations roll out in phases:
Article 3 of the AI Act provides the regulatory definitions that should flow consistently through AI governance deliverables. These are legal definitions in a binding EU regulation. Using them inconsistently, or substituting informal alternatives, creates review friction and can weaken the evidence record.
Article 3 establishes 68 definitions. The following 10 definitions surface most often in conformity assessment documentation and are the likeliest candidates for cross-team drift:
| # | Term | Why It Matters |
|---|---|---|
| 1 | ‘AI system’ | The threshold definition. A machine-based system with varying autonomy that infers outputs from inputs — full text at Article 3(1). If your engineering team calls it a “model” while compliance calls it an “AI system,” your documentation is internally inconsistent. |
| 2 | ‘High-risk AI system’ | Triggers the full compliance obligation set: risk management, technical documentation, data governance, human oversight, accuracy, robustness, cybersecurity. Misclassification here cascades through every deliverable. |
| 3 | ‘Provider’ | The entity that develops or has an AI system developed, and places it on the market or puts it into service. Determines who bears primary compliance obligations. |
| 4 | ‘Deployer’ | The entity using an AI system under its authority, except where used for personal non-professional activity. Deployers have their own obligations under Article 26. |
| 5 | ‘Intended purpose’ | The use for which the AI system is intended by the provider, as specified in instructions, technical documentation, and promotional materials. Defines the scope of conformity assessment. |
| 6 | ‘Reasonably foreseeable misuse’ | Use of an AI system in a way not in accordance with its intended purpose but which may result from reasonably foreseeable human behavior. Must be addressed in risk management (Article 9). |
| 7 | ‘Placing on the market’ | The first making available of an AI system on the Union market. Triggers documentation and registration obligations. |
| 8 | ‘Putting into service’ | The supply of an AI system for first use directly to the deployer for its intended purpose. Distinct from placing on the market. |
| 9 | ‘Substantial modification’ | A change not foreseen in the initial conformity assessment that affects compliance or modifies the intended purpose. Triggers re-assessment obligations. |
| 10 | ‘Post-market monitoring’ | All activities by providers to collect and review experience from AI systems in use. Required under Article 72. |
These definitions must be used consistently across every artifact your organization produces: risk assessments (Article 9), technical documentation (Article 11, Annex IV), quality management procedures (Article 17), transparency disclosures (Article 13), and instructions for deployers (Article 13).
Enterprise AI governance platforms exist — Credo AI, Holistic AI, Vanta, and others — covering risk classification, bias testing, model monitoring, and regulatory mapping. Their list pricing is typically enterprise-tier and out of reach for smaller compliance teams.
But terminology governance — the foundational layer that ensures every compliance artifact uses the same definitions — falls through the cracks.
Compliance Glossary is a Confluence app built specifically for terminology governance in regulated environments. For AI Act compliance, it provides the infrastructure layer that GRC platforms skip.
Every AI Act term goes through a formal approval workflow. The person who defines “AI system” cannot approve it — a second authorized reviewer must independently verify the definition matches Article 3 before it becomes the organizational standard. This is enforced in code, not policy. Learn how the four-eyes principle works.
Every change to every definition is recorded: who changed it, when, what the previous version said, who approved the change, and why. When a notified body asks “when was your definition of ‘intended purpose’ last reviewed?” — you have a timestamped, attributed answer. Not an email thread.
Compliance Glossary scans your Confluence pages and identifies where AI Act terms are used. It finds inconsistencies — pages where someone wrote “algorithm” when the governed term is “AI system,” or where “user” appears instead of “deployer.” You see exactly which documentation needs remediation before the auditor does.
One governed glossary. Every team — engineering, legal, risk, product — references the same definitions. When Article 3 terminology is updated through delegated acts or implementing acts, you update one place. The change propagates through your compliance scanning results, showing you every page that needs revision.
Compliance Glossary capabilities mapped to the regulatory requirements they address:
| Capability | AI Act | ISO 27001 | SOC 2 |
|---|---|---|---|
| Governed definitions with approval workflow | Art. 3 (Definitions) — ensures consistent use of regulatory terminology | Clause 7.5 — documented information must be controlled and maintained | CC6.1 — logical access controls over information assets |
| Four-eyes approval | Art. 17(1)(b) — quality management system must include design and development verification procedures | Annex A 5.3 — segregation of duties / dual authorization | CC6.1 — separation of duties in access controls |
| Version history and audit trail | Art. 11 + Annex IV — technical documentation must be kept up to date with traceable changes | Clause 7.5.3 — control of documented information, including changes | CC7.2 — monitoring of system components for anomalies |
| Compliance scanning | Art. 9(2)(a) — risk management must identify and analyze known and reasonably foreseeable risks; consistent terminology is prerequisite | Clause 9.1 — monitoring, measurement, analysis and evaluation | CC4.1 — monitoring of internal controls |
| Single source of truth | Art. 17(1)(a) — quality management system strategy for regulatory compliance | Clause 7.5.1 — the ISMS shall include documented information required by the standard | CC2.1 — information and communication relevant to internal controls |
August 2, 2026 is not a soft deadline. It is the date when the obligations for Annex III high-risk AI systems become enforceable under EU law. National market surveillance authorities and the EU AI Office will oversee compliance. Each Member State must establish at least one AI regulatory sandbox by this date (Article 57(1)). Penalties for non-compliance with Annex III obligations reach up to EUR 15M or 3% of global turnover (Article 99(4)); prohibited-practice violations under Article 5 reach EUR 35M or 7%.
Your definition of “AI system” must come directly from Article 3(1) of Regulation (EU) 2024/1689 and be stored in a controlled location with version history. Compliance Glossary holds it in Confluence as a governed term, approved by two authorized reviewers, with every change timestamped and attributed.
Every governed definition records the author, the independent approver, the approval timestamp, and the review comments. The four-eyes workflow enforces that the person who drafts a definition cannot approve it — a second authorized reviewer must verify it matches the regulation before it becomes the organizational standard.
Compliance Glossary scans all Confluence pages and flags inconsistencies — pages where informal alternatives like “algorithm” or “model” appear instead of the governed term “AI system”. You see exactly which documentation needs remediation before an auditor does.
Every definition carries a full version history: what the previous text said, who changed it, when, and why. When Article 3 terminology is updated through delegated or implementing acts, you update one place and the change propagates through compliance scanning results.
The four-eyes approval record is stored with the definition and cannot be bypassed. The approver’s identity, timestamp, and any review comments are retained as part of the audit trail — satisfying Article 17(1)(b) quality management system verification procedures.
If you cannot answer these questions with documented evidence, you have a conformity gap. The time to close it is now — not after the assessment begins.
Governed definitions. Four-eyes approval. Full audit trail. Compliance scanning. The terminology infrastructure layer your AI Act compliance program is missing.
Evaluate in Confluence View Security WhitepaperCompliance for Confluence — approved terms, page scanning, and audit evidence for regulated teams in Confluence
EU AI Act Compliance Guide — full overview of the AI Act and how terminology governance supports compliance
AI Act: CEO Deadline Playbook — board-level obligations under the August 2026 full-application date
ISO 27001 Terminology Management — 49 terms for information security management systems, Clause 7.5 aligned
SOC 2 Terminology Management — 40 Trust Services Criteria terms for GRC teams
Four-Eyes Principle — how dual-approval workflows prevent self-approval audit findings
Security Whitepaper — architecture, data handling, and compliance controls