Who has to build an AI governance framework under the EU AI Act, and what does it have to do?

In most organizations, AI governance starts as a question nobody quite owns. Legal asks whether the AI Act applies. Security asks what data the new tools can see. HR asks whether the screening software is allowed. Somebody is then asked to pull it together into a framework. This guide is about that person: what the EU AI Act actually asks of providers and deployers, which duties already apply after the Digital Omnibus moved the calendar, and what to build first.

Everything here comes from the Official Journal texts of the AI Act, Regulation (EU) 2024/1689, and the Digital Omnibus on AI, Regulation (EU) 2026/1744, with the GDPR where the two meet, and from the pages for ISO/IEC 42001 and the NIST AI Risk Management Framework, all read on 20 October 2026. It is a guide, not legal advice.

What does the AI Act ask an organization to build?

Not one thing, but a set of duties that depend on two questions: what the AI system is, and what your organization is in relation to it. The Act sorts systems into tiers. A small number of practices are prohibited outright under Article 5. Some systems are high-risk under Article 6: those that are safety components of products covered by the EU laws listed in Annex I, and those used in the areas listed in Annex III, such as recruitment and decisions about workers, credit scoring, and risk assessment and pricing for life and health insurance. Some systems carry transparency duties under Article 50, whatever their risk: chatbots that talk to people, systems that generate synthetic content, emotion recognition and deep fakes. General-purpose AI models have their own chapter. Everything else is lightly regulated, but still inside the AI literacy duty in Article 4.

The Act then sorts organizations by role. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, whether it charges for it or not (Article 3(3)). A deployer uses an AI system under its authority, except in a personal non-professional activity (Article 3(4)). Importers, distributors and authorized representatives have shorter lists of duties of their own. Most organizations are deployers of many systems and providers of a few, and the framework has to handle both.

An AI governance framework, in the sense this guide uses, is the set of decisions, owners and records that lets an organization show, for each AI system, which tier it is in, which role the organization holds, which duties follow, and that those duties are being met. It is the same idea as a security or privacy management system, applied to AI, with the law setting much of the content.

When does each part apply?

This is the first thing to get right, because the calendar changed in July 2026. The AI Act was published in the Official Journal on 12 July 2024 and entered into force on 1 August 2024, with its duties phased in by Article 113. The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026, was published on 24 July 2026 and moved several of those dates.

Two things follow for anyone building a framework. First, the high-risk duties moved back by 12 to 16 months, which gives providers of Annex III systems until December 2027, not August 2026. Second, nothing else moved back. The prohibitions, AI literacy and the transparency rules already apply, so a framework that waits for 2027 is already late for the parts that bite now. The Omnibus also added two prohibitions from 2 December 2026, including AI that generates or manipulates sexually explicit images of identifiable people without their explicit consent.

The Omnibus changed the AI literacy duty too. Article 4 now says providers and deployers shall take measures to support the development of AI literacy of their staff and other persons dealing with AI systems on their behalf, taking account of their knowledge, experience and the context of use, and it states that this does not require them to guarantee any specific level of AI literacy for any individual. The duty is softer in wording, but it is still a duty, and it is the one that reaches every organization using AI at work.

Who ends up building the framework?

The Act does not name a job. It assigns duties to organizations, and the organization decides who carries them. In practice the work tends to land on one of a small number of people, and each brings a different strength and a different blind spot.

The common thread is that nobody can build it alone. The inventory needs every business unit to say what AI it uses. Classification needs legal judgment. Human oversight needs managers who will actually do it. The person who builds the framework is the one who can run that process across the organization and keep the records that prove it ran.

When does the work land on your desk?

You sell an AI product into the EU

Picture a software company whose product screens job applications for its customers. Recruitment and selection is an Annex III use, so the product is likely a high-risk system and the company is its provider. From 2 December 2027 it will need a risk management system, data governance, technical documentation, logging, instructions for use, human oversight by design, a quality management system, a conformity assessment, an EU declaration of conformity, CE marking and registration. Somebody has to plan that work now, because the documentation has to describe a product that is being built today.

You buy AI and use it at work

Now picture the customer: an employer that uses the screening tool. It is a deployer of a high-risk system. The vendor's certificate does not cover the employer's own duties, which include assigning trained people to oversee the tool, keeping its logs, informing workers' representatives before using it, and telling applicants that it is used. These are the duties most often missed, because the purchase felt like it settled the question.

Staff are already using AI tools

The most common trigger is the least dramatic. Staff are using AI assistants, writing tools and coding tools, some approved and some not. The AI literacy duty already applies, Article 50 transparency rules now apply to chatbots and synthetic content, and nobody has a list. The framework starts the day somebody is asked to make one.

A regulator, customer or board asks

Customers now ask suppliers about AI in their questionnaires, and boards ask management whether the organization is exposed. When the honest answer is "we are not sure", the framework gets a sponsor and a deadline.

What each role owes, and who usually owns it

This is the table that saves the most time when you split the work. It sets the main duties for a high-risk system side by side for the provider and the deployer, with the article that sets each one, and adds the function inside an organization that usually ends up owning it. The articles come from the Official Journal text as amended; the owner column is our reading of how organizations tend to split the work, not a legal requirement.

Two things stand out. First, the deployer column is not short. Buying a high-risk system leaves the deployer with real duties that no vendor contract can transfer, and most of them are about people: who oversees the system, who is told, and who checks. Second, the owners are spread across the organization. That is why the framework needs a single person who keeps the register and chases the owners, and why the deployer duties are where frameworks most often have gaps. Our guide to AI Act incident reporting deadlines covers the after-launch row in detail. We have turned the table into a register you can copy below.

When does a deployer become a provider?

This is the question that catches organizations out, because it changes the whole duty list. Article 25(1) treats a distributor, importer, deployer or other third party as the provider of a high-risk AI system, with all the provider duties in Article 16, in three situations.

The third trigger is the one to watch. A general AI assistant bought for drafting is not a high-risk system. The same assistant, wired into a workflow that ranks job applicants, may be one, and the organization that did the wiring may be its provider. A framework that screens new uses, not only new purchases, catches this before it becomes a problem.

The transparency duties that already apply

Article 50 is the part of the Act most organizations meet first, because it is not limited to high-risk systems and it has applied since 2 August 2026. It splits the duties between the two roles. Providers must design AI systems that interact directly with people so that the people concerned are told they are dealing with an AI system, unless that is obvious to a reasonably well-informed person in the circumstances (Article 50(1)). Providers of systems that generate synthetic audio, image, video or text must mark the output in a machine-readable format so it can be detected as artificially generated or manipulated (Article 50(2)), and providers whose generative systems were already on the market before 2 August 2026 have until 2 December 2026 to comply.

Deployers carry the other half. A deployer of an emotion recognition or biometric categorization system must inform the people exposed to it and process their personal data under the GDPR (Article 50(3)). A deployer of a system that generates or manipulates image, audio or video content constituting a deep fake must disclose that the content has been artificially generated or manipulated (Article 50(4)). For a framework, that means two checks on every system in the inventory: does it talk to people or produce content, and who is responsible for telling them.

Who owes a fundamental rights impact assessment?

Not every deployer. Article 27 requires one before deploying an Annex III high-risk system, except those used for critical infrastructure under point 2 of Annex III, from three groups: deployers that are bodies governed by public law, private entities providing public services, and deployers of systems that evaluate creditworthiness or set credit scores, or that assess risk and set prices for life and health insurance (Annex III, points 5(b) and (c)). The assessment describes the deployer's process, the period and frequency of use, the people likely to be affected, the specific risks of harm, the human oversight measures and what happens if the risks materialize. Where a GDPR data protection impact assessment already meets some of these obligations, Article 27(4) makes the fundamental rights assessment complement it, and Article 26(9) tells deployers to use the provider's information for that GDPR assessment.

How does it fit with ISO/IEC 42001 and the NIST AI RMF?

Most organizations do not build an AI governance framework from nothing. They take a structure from a standard or a framework and fill it with the legal duties that apply to them. The two most used are ISO/IEC 42001 and the NIST AI Risk Management Framework, and our guide to AI governance frameworks compared goes deeper than this section.

The combination that works for many EU-facing organizations is ISO/IEC 42001 as the structure and the AI Act as the content, with the NIST AI RMF as a source of practices. Our ISO 42001 Lead Implementer Exam Guide covers the management system side, and the UK government's AI Management Essentials guidance is a lighter starting point for smaller organizations.

What to build first

Order matters more than effort. The sequence that tends to work starts with the inventory, before any policy, because a policy written before anyone knows what AI is in use is a policy about imagined systems. Then screen every system: is any use prohibited, is it high-risk, does Article 50 apply, does it rely on a general-purpose model? Then settle the role for each one, provider or deployer, and check the Article 25(1) triggers. Only then split the work into a provider track and a deployer track, and give every duty an owner and a record.

Three things are worth doing in the first month, whatever your role. Put an AI literacy plan in place, because that duty already applies to everyone. Check every chatbot, generator and deep fake against Article 50, because those duties applied from 2 August 2026. And confirm that none of your uses falls under Article 5, including the two prohibitions added from 2 December 2026, because the fines for prohibited practices are the highest in the Act: up to EUR 35mn or 7% of worldwide annual turnover, whichever is higher, under Article 99(3).

The high-risk work comes next, on the longer runway the Omnibus provided. For a provider, the conformity route, the technical documentation and the quality management system take the longest, so choose the route early. For a deployer, the duties are shorter but depend on people: trained overseers, informed workers, logs kept, and a habit of telling the provider when something looks wrong.

How to prepare

If you are the person building the framework, the fastest route is to read the Act itself, article by article, with a guide that keeps you on the text. AI Governance Framework is a practitioner handbook written from the Official Journal text of Regulation (EU) 2024/1689, as amended by the Omnibus, in 22 chapters. It takes the reader from scope and roles through the prohibited practices, each high-risk requirement, everything a provider owes and everything a deployer owes, to a final chapter on building the framework in a sequence that works. AI Governance Worked Scenarios takes 24 situations a governance lead faces, from an importer and a distributor in one supply chain to a regulatory sandbox, works each one to a decision against the articles by number, and lists the records each decision must produce.

If you want a credential to go with the work, the IAPP's AIGP covers AI governance across laws and frameworks, and our guide to the AIGP certification explains it. For the management system side, the PECB ISO/IEC 42001 Lead Implementer is the natural pair. Our guide to which certification suits which role helps you choose.

So, should it be you?

It probably should if you already run a management system, privacy, security or compliance, and AI is the next thing your organization needs to get under control. The skills transfer: inventories, risk methods, owners, records and reviews are the same habits, applied to a new kind of system. It is a particularly good fit if your organization buys more AI than it builds, because the deployer duties reward exactly that operational discipline.

It probably should not, or not alone, if the organization is a provider of a high-risk system and you have no engineering or product partner. The provider duties live inside the product, and they need someone who can change it.

The best AI governance leads share one habit, and it is the habit the Act rewards: they start from a list of real systems, decide in writing what each one is and who owns it, and keep the records that prove the decision was made. Everything else in the framework hangs from that list.

Questions people ask about building an AI governance framework

Who has to comply with the EU AI Act?

Anyone who places AI systems on the EU market or puts them into service, and organizations that use AI systems professionally in the EU, plus importers, distributors and authorized representatives. The Act calls the first group providers and the users deployers, and most of its duties depend on which of those you are for each system.

What is the difference between a provider and a deployer?

A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark (Article 3(3)). A deployer uses an AI system under its own authority, outside personal non-professional use (Article 3(4)). The same organization can be a provider for one system and a deployer for another.

When do the high-risk rules apply after the Digital Omnibus?

Regulation (EU) 2026/1744 moved them. The high-risk rules in Chapter III, Sections 1 to 3, now apply from 2 December 2027 for Annex III systems and from 2 August 2028 for systems that are safety components of Annex I products. Before the Omnibus those dates were 2 August 2026 and 2 August 2027.

What already applies today?

The prohibited practices in Article 5 and the AI literacy duty in Article 4 have applied since 2 February 2025. The rules for general-purpose AI models, governance and penalties have applied since 2 August 2025, and the Act's general application date, which brings in the Article 50 transparency duties, was 2 August 2026. Two further prohibitions added by the Omnibus apply from 2 December 2026.

Did the Omnibus remove the AI literacy duty?

No, it reworded it. Article 4 now says providers and deployers shall take measures to support the development of AI literacy of their staff and others dealing with AI systems on their behalf, and that the duty does not require them to guarantee any specific level of AI literacy for any individual.

Can a deployer become a provider?

Yes. Under Article 25(1), a distributor, importer, deployer or other third party is treated as the provider of a high-risk AI system if it puts its name or trademark on the system, makes a substantial modification to it, or changes the intended purpose of a system so that it becomes high-risk.

What does a deployer of a high-risk system have to do?

Article 26 lists it: use the system according to its instructions, assign human oversight to competent people, keep input data relevant where you control it, monitor operation and report risks and serious incidents, keep the logs under your control for at least six months, inform workers before workplace use, and tell people subject to Annex III decisions that the system is used. Some deployers also owe a fundamental rights impact assessment under Article 27.

Is ISO/IEC 42001 enough to comply with the AI Act?

Not on its own. ISO/IEC 42001 is a management system standard for AI, and it gives a framework a strong structure, but the AI Act sets legal duties of its own, such as conformity assessment and registration for high-risk systems. Many organizations use ISO/IEC 42001 as the operating system and map the Act's duties onto it.

What are the maximum fines?

For prohibited practices, Article 99(3) sets administrative fines of up to EUR 35mn or, for an undertaking, up to 7% of total worldwide annual turnover for the preceding financial year, whichever is higher. Other breaches carry lower maximums.

Where should an AI governance framework start?

With an inventory. You cannot classify, assign roles or plan duties for systems you have not listed, and most organizations find more AI in use than they expected. Screen each system for prohibited practices and high-risk use, settle your role for it, then build the duties that follow.

Which books help you build an AI governance framework?

AI Governance Framework

Building one that survives the EU AI Act. 22 chapters, 416 pages.

What is insideBuy on Amazon

AI Governance Worked Scenarios

24 worked situations under the EU AI Act, decided against the Articles. 81 pages.

What is insideBuy on Amazon