AI governance is the operating system that makes AI Act compliance repeatable: roles, inventory, risk classification, oversight, documentation and evidence.

What AI Governance Means in Practice

AI governance is the layer between a regulation and the people who have to comply with it. The EU AI Act never uses the phrase as a defined term, yet almost everything it requires assumes one exists: a risk management system that runs across the lifecycle (Article 9), a quality management system for providers of high-risk systems (Article 17), competent human oversight assigned by name (Article 26), logs kept and retrievable (Article 12), post-market monitoring that feeds back into the design (Article 72), and staff who understand what they are operating (Article 4).

None of that is a document. All of it is a routine somebody owns.

The practical test is simple. If a supervisory authority asked today which AI systems your organisation uses, which risk tier each falls into, who approved them and on what evidence — could you answer in a week? Organisations that can have AI governance. Organisations that cannot have an AI policy.

The Nine Components, and the Articles That Require Them

# Component What it produces AI Act basis
1 Inventory A list of every AI system in use or development, with owner and vendor Precondition for Art. 6 classification
2 Role determination Provider / deployer / importer / distributor, per system Art. 3, Art. 25
3 Risk classification Prohibited, Annex I, Annex III, GPAI, transparency-only, minimal Art. 5, Art. 6, Annex I, Annex III
4 Risk management system Identified risks, mitigations, residual risk accepted by a named person Art. 9
5 Data governance Provenance, representativeness, bias examination for training data Art. 10
6 Technical documentation The Annex IV file, kept current for ten years after placing on the market Art. 11, Annex IV
7 Human oversight design Who can intervene, how, and with what authority to stop the system Art. 14, Art. 26
8 Transparency and disclosure Where users are told they are dealing with AI or synthetic content Art. 50
9 Monitoring and incident reporting Post-market plan, logs, serious-incident route to the authority Art. 72, Art. 73

Read in order, those nine are a build sequence rather than a checklist. Each one depends on the one above it: you cannot design oversight for a system you have not classified, and you cannot classify a system that is not on a list.

Our AI risk classifier does step 3 in three or four questions, and the compliance checklist walks the rest.

What an AI Policy Has to Say

A policy is component zero: the written statement that the other nine exist and who owns them. The ones that survive contact with a regulator share a shape.

Scope. Which entities, which systems, which geographies. State explicitly whether tools bought as part of a SaaS product count — they do, and omitting them is how shadow AI gets written out of the inventory.

Roles. Name the accountable executive. Name the approver for new systems. Name who may declare a system out of scope, and require them to record why.

Prohibited uses. Not a general exhortation but the eight practices of Article 5, written as rules your staff can apply: no emotion inference in the workplace, no social scoring of customers, no scraping faces to build a recognition database.

Disclosure. Where Article 50 bites — chatbots, synthetic media, deepfakes, emotion recognition — and who writes the wording.

Procurement. What a vendor must hand over before a system is approved: intended purpose, instructions for use, accuracy metrics, the logging interface, and the contractual commitment to support your Article 26 duties.

Training. Which measure you rely on for Article 4, and how you record who completed it. Since the Digital Omnibus rewrote Article 4 in July 2026 this is an obligation of means — take measures — rather than a guarantee that every person reached a level. Measures still have to be evidenced.

Incidents. Who decides that something is a serious incident under Article 73, and the clock that starts when they do.

AI Governance Certification: What Actually Exists

This is where the market is noisiest, so it is worth being precise. Three different things are sold under the word certification, and they certify three different objects.

A system can be certified. High-risk AI systems go through conformity assessment under Article 43, which for most Annex III systems is an internal control procedure and for some is third-party assessment by a notified body. The output is a CE marking and an EU declaration of conformity. This certifies a product, not a person and not a company.

An organisation can be certified. ISO/IEC 42001 is the AI management system standard, and accredited certification bodies audit against it. It is voluntary, it is genuinely useful as the scaffold for the nine components above, and it is evidence of diligence. It is not a presumption of conformity with the AI Act: only harmonised standards published in the Official Journal under Article 40 carry that effect, and the first of those appeared in October 2026.

A person can hold a training certificate. No EU body certifies individuals for the AI Act, and none has been designated to. What a training certificate can honestly evidence is that a named person completed structured training and passed an assessment on it — which is exactly the kind of record Article 4 expects you to keep.

That last one is what we issue. The AI Act Fundamentals course is free, the exam is graded on our server rather than in your browser, and the certificate carries a public id anyone can check. It is evidence for your governance file, not a licence from an authority — and we say so on the certificate itself.

Where Governance Meets the Other Regimes

Most organisations building AI governance in 2026 already run a GDPR programme, and financial institutions also run DORA and often NIS2. The controls overlap more than the regulations do.

A data protection impact assessment under GDPR Article 35 and a fundamental rights impact assessment under AI Act Article 27 ask overlapping questions about the same system, and the AI Act explicitly allows the FRIA to build on an existing DPIA rather than duplicate it. Incident reporting under DORA and serious-incident reporting under AI Act Article 73 run on different clocks to different authorities but start from the same detection. Third-party risk management under DORA covers the vendor whose model you deploy.

The practical move is to write each control once and file it against every regime it satisfies. AI Act vs DORA vs NIS2 maps the overlaps for financial institutions; AI Act vs GDPR does the same for data protection.

A Realistic First Ninety Days

Weeks 1–3 — Inventory. Ask every function what they use, then check the expense ledger and the SSO logs against the answer. The gap between the two is the real scope.

Weeks 4–6 — Classify. Run each system through Articles 5 and 6. Most will come out minimal-risk; the point of the exercise is the handful that do not, and the written record showing you checked.

Weeks 7–9 — Close the Article 50 gaps. Disclosure is already in force and is the cheapest obligation to meet. Chatbots say they are AI, synthetic media is marked.

Weeks 10–12 — Design oversight and write the policy. For each high-risk or near-high-risk system, name who can stop it and give them the authority to. Then write the policy that records all of the above, and set the review date.

Annex III obligations bite on 2 December 2027. A first pass at this takes a quarter; doing it twice because the first inventory was wrong takes two.

Official AI Act Compliance Deadline Calendar

Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.

Obligation Applies to Original date New date Status Countdown Legal basis
Prohibited Practices (Art. 5) All providers and deployers active — AI Act Art. 5
GPAI Rules (Chapter 5) GPAI model providers active — AI Act Art. 51-56
Commission Enforcement Powers over GPAI GPAI model providers active — AI Act Art. 88-94, 101
Transparency Obligations (Art. 50) Providers and deployers of chatbots, generative, emotion recognition systems active — AI Act Art. 50
New Art. 5 Prohibition (CSAM / non-consensual intimate imagery) Providers and deployers of generative AI systems active — AI Omnibus 2026 Art. 5
AI-Generated Content Marking (pre-existing systems) Providers of generative AI systems on the market before 2 Aug 2026 active — AI Act Art. 50(2) — transitional
Regulatory Sandboxes National competent authorities deferred — AI Omnibus 2026 Art. 57
High-risk AI — Annex III (standalone) Providers of standalone Annex III systems deferred — AI Omnibus 2026 Art. 6(2)
High-risk AI — Annex I (embedded) AI embedded in Annex I regulated products deferred — AI Omnibus 2026 Art. 6(1)

⬇ Download JSON · CC BY 4.0

Frequently Asked Questions

AI governance is the set of roles, policies, controls and records an organisation puts in place so that decisions about AI systems are made deliberately, documented, and repeatable. Under the EU AI Act it is not optional dressing: Article 9 requires a risk management system that runs across the whole lifecycle, Article 17 requires providers of high-risk systems to operate a quality management system, Article 26 requires deployers to assign competent human oversight, and Article 4 requires measures supporting AI literacy. Governance is what connects those obligations to the people who actually have to meet them.

There is no EU-issued AI Act certification for individuals, and no certification body has been designated by the Commission for that purpose. What exists is threefold: the CE marking and conformity assessment route for high-risk AI systems, which certifies a system and not a person (Articles 43 and 47); management-system certification against ISO/IEC 42001, which certifies an organisation's AI management system and is issued by accredited certification bodies; and training certificates issued by private providers, which evidence that a named person completed and passed structured training. Anyone selling you an official EU AI Act certification for a person is describing something that does not exist.

ISO/IEC 42001 is a voluntary management-system standard: it tells you how to run an AI management system and can be certified by an accredited body. The EU AI Act is binding law with fines up to €35 million or 7% of worldwide turnover. Certification to 42001 is not a presumption of conformity with the AI Act — only harmonised standards published in the Official Journal under Article 40 carry that effect. In practice 42001 is a good scaffold for the governance work the Act assumes you have done, and it is evidence of diligence, but it is not a substitute for conformity assessment.

At minimum: scope and definitions tied to Article 3; the roles your organisation holds for each system (provider, deployer, importer, distributor) and who owns them; an approval gate before any AI system goes live; rules on prohibited uses mapped to Article 5; disclosure rules mapped to Article 50; data governance and retention; human oversight expectations for high-risk use; incident reporting routes mapped to Article 73; vendor and procurement requirements; and the training measures you rely on for Article 4. A policy that does not name an owner for each item is a statement of intent, not a control.

The Act does not mandate an officer the way the GDPR mandates a DPO, so the choice is yours — but the choice has to be made explicitly. The common patterns are an AI governance committee chaired by legal or risk with product and engineering represented, or an existing second line (compliance, operational risk, security) extended to cover AI with a named accountable executive. What fails consistently is leaving it with a single enthusiastic engineer, because the obligations are organisational and the evidence has to survive that person leaving.

Data governance answers what data you hold, where it came from, who may use it and for how long. AI governance adds the model and the decision: how the system was trained and validated, what it is allowed to decide, who can override it, how its behaviour is monitored after release, and how you prove any of that later. Article 10 of the AI Act sits in the overlap — training, validation and testing data for high-risk systems — which is why organisations with mature GDPR programmes usually start from there and find the model lifecycle is the genuinely new part.

Proportionate governance, yes. Most SMEs are deployers rather than providers, which means a smaller set of obligations: use the system as instructed, assign competent oversight, keep the logs, disclose where Article 50 requires it, and train the people who touch it. The AI Act explicitly allows simplified documentation for small providers and gives SMEs priority access to regulatory sandboxes. What does not scale down is the inventory: you still have to know which AI systems you use, because you cannot classify what you have not listed.

Parts of it are already overdue. The Article 5 prohibitions have applied since 2 February 2025 and the GPAI obligations since 2 August 2025; the Article 50 transparency duties and the general application of the Regulation both landed on 2 August 2026. The Digital Omnibus moved the standalone high-risk obligations of Annex III to 2 December 2027 and the embedded Annex I systems to 2 August 2028. That gives most organisations about a year to build the governance that Annex III will test — which is roughly how long a first inventory, classification and oversight design actually takes.

Stay ahead of AI Act changes

Get compliance alerts when deadlines or obligations change.

No spam. One-click unsubscribe.

Take compliance further with the AI Act Academy

A free course, a server-graded exam, a verifiable certificate — and the working templates.