The AI Governance Operating Model: Who Owns What, Who Signs, and How to Build the Machine
You have just been handed the AI governance brief. There is probably a policy document somewhere, a committee that has met twice, and an inventory spreadsheet that was accurate in February. Congratulations - you now own a framework that is almost certainly shelfware.
This post is not about what the EU AI Act requires. We have a 10-step triage guide for that, and a compliance software buyer's guide for tooling. This post is about organisational design: who decides, who signs, what the forum actually does, and how you make the whole thing survive contact with the business. The test for every section is simple - does it tell you who does what, when, and who signs? If not, it belongs in a different post.
Why Most AI Governance Frameworks Are Shelfware
The symptoms are consistent across organisations of every size. A policy that nobody reads because it was written by lawyers for auditors. An AI inventory that was built once for a board presentation and has not been touched since. A governance committee that quorum-fails because the CISO and GC are always double-booked. And a shadow AI estate that nobody sees - Lenovo's April 2026 research found 70% of enterprise AI now operates outside IT oversight, which means the inventory is almost certainly missing the majority of what is actually running.
The root cause is not bad policy. It is diffused accountability. When everyone is responsible, nobody is. Most organisations have only usage policies and mistakenly call it governance - what practitioners call "governance theatre." Static PDF policies reviewed once a year, disconnected from live operations, will not survive an EU AI Act conformity assessment.
The EU AI Act makes this problem structurally visible. Unlike most regulations, it assigns duties to legal roles - provider, deployer, importer, distributor - not to departments. That means the first act of governance is translating a legal role into a named human with a budget. A governance framework that cannot answer "who signs the declaration of conformity" is a document, not a framework.
The Four Decision Rights Every AI Governance Framework Must Allocate
One accountable person per activity is the rule that makes RACI work. Exactly one named person owns each outcome, with experts consulted and stakeholders informed. Here are the four decisions where that rule matters most.
1. Can We Build or Buy This at All? (Intake and Prohibition Screen)
Every new AI system - whether it is being built internally or procured from a vendor - needs a gate before any material investment is made. This gate screens for Article 5 prohibited practices and for obvious misalignment with the organisation's risk appetite.
Accountable owner: Head of AI Governance (or GC if no dedicated role exists yet).
The intake form should be short enough that a product manager fills it in without calling legal. Five questions: What does the system do? Who does it affect? What data does it use? Are we building or buying? What is the intended deployment context? Everything else is downstream.
2. What Is Our Legal Role for This System? (Provider vs. Deployer Determination)
This is the decision most organisations skip, and it is the one that determines the entire obligation stack. See our full guide to provider, deployer, importer, and distributor roles for the definitions. The governance point is that role determination must happen per system, not once for the organisation - you will be a provider for systems you build and a deployer for systems you buy, and those roles can change.
The Article 25 role-flip is the most common trap: if you fine-tune, rebrand, or substantially modify a third-party system, you may convert from deployer to provider, with the far heavier obligation set. That determination needs a named owner.
Accountable owner: Legal/Regulatory Counsel, with the Model Owner responsible for providing the factual inputs.
3. Is This High-Risk, and Do We Accept the Residual Risk? (Classification and Risk Acceptance)
Annex III classification is a legal determination, but the risk acceptance decision is a business one. They should not be conflated. Legal determines whether the system falls within a high-risk category. The AI Governance Committee - or a delegated risk owner - decides whether the organisation accepts the residual risk of deploying it.
Accountable owner for classification: Legal/Regulatory Counsel. Accountable owner for risk acceptance: AI Governance Committee Chair (or CRO for systems above a defined risk threshold).
4. Are We Clear to Ship? (The Release Gate)
This is the decision that most governance frameworks never actually implement. The release gate is the moment at which someone with authority signs off that the system is compliant to deploy. For high-risk systems as provider, that signature is the Declaration of Conformity. For high-risk systems as deployer, it is the documented completion of Article 26 obligations - including, where required, the Article 27 Fundamental Rights Impact Assessment.
Accountable owner: Model or System Owner, countersigned by Legal/Regulatory Counsel for high-risk systems.
If nobody in your organisation can name the person who signs the release gate today, that is the first gap to close.
The RACI That Survives an Audit
The table below is opinionated. It insists on exactly one Accountable per activity because diffused accountability is the single most common failure mode in AI governance programmes. A RACI-based operating model is how organisations convert AI enthusiasm into governed, scalable capability.
Role abbreviations: AGC = AI Governance Committee | MSO = Model/System Owner | PEL = Product/Engineering Lead | DS = Data Steward | LRC = Legal/Regulatory Counsel | SEC = Security (CISO) | PVM = Procurement/Vendor Mgmt | HR = HR/People | IA = Internal Audit
| Activity / Obligation | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| AI intake & triage (new systems) | PEL / PVM | MSO | LRC, SEC | AGC |
| Legal role determination (Art. 25) | LRC | LRC | MSO, PVM | AGC |
| Annex III classification | LRC | LRC | MSO, PEL | AGC, IA |
| Art. 9 risk management system | MSO | MSO | LRC, SEC, DS | AGC |
| Art. 10 data governance | DS | DS | MSO, SEC, LRC | AGC |
| Art. 11 / Annex IV technical file | PEL | MSO | LRC, DS | AGC, IA |
| Art. 14 human oversight design | PEL | MSO | LRC, SEC, HR | AGC |
| Art. 26 deployer duties | MSO | MSO | LRC, PVM | AGC |
| Art. 27 FRIA | LRC | MSO | HR, DS, SEC | AGC, IA |
| Art. 43 conformity assessment | PEL | MSO | LRC | AGC, IA |
| Art. 49 EU database registration | LRC | MSO | PEL | AGC |
| Art. 72 post-market monitoring | MSO | MSO | SEC, DS | AGC, IA |
| Art. 73 incident reporting | SEC | MSO | LRC, AGC | IA |
| Art. 4 AI literacy programme | HR | HR | LRC, AGC | All staff |
A few things worth noting in this table. The Model or System Owner carries Accountable for most operational activities - that is deliberate. They are the person who knows the system, owns the budget, and will be asked to explain decisions to a regulator. Legal is Accountable for legal determinations (role, classification, FRIA drafting) but Consulted on operational ones. Internal Audit is Informed throughout, not Consulted - they should be reviewing the evidence, not generating it.
The most common RACI failure: Listing the AI Governance Committee as Accountable for everything. A committee cannot be accountable — only a named individual can. The committee's job is to set policy, resolve escalations, and review evidence. The moment it becomes the default Accountable owner, it becomes the bottleneck, and the business routes around it.
The AI Inventory as the Load-Bearing Artefact
The inventory is not a spreadsheet you build for an audit. It is the operational register that feeds Article 49 EU database registration, Article 26(5) deployer records, and post-market monitoring. If it is not live, it is not governance.
Every record in the inventory should carry at minimum:
| Field | Why It Matters |
|---|---|
| System name and version | Traceability across lifecycle events |
| Legal role (provider / deployer / both) | Determines the entire obligation stack |
| Annex III classification and reasoning | Audit trail for the classification decision |
| Provider / deployer counterparties | Contractual chain for Article 26 duties |
| Data sources and data governance owner | Feeds Article 10 and FRIA |
| Human oversight design summary | Links to Article 14 implementation |
| Lifecycle status | Distinguishes in-development, deployed, retired |
| EU database registration ID | Required once Article 49 applies |
| Last-reviewed date and reviewer | Proves the register is live, not static |
Accountable owner: a named individual, not the committee. In most organisations this is the Head of AI Governance or a designated AI Compliance Manager. The inventory owner is responsible for ensuring every new system is added at intake, every change is reflected within a defined SLA (30 days is reasonable), and every retired system is marked as such.
Only 25% of organisations report comprehensive visibility into how employees are using AI, while 35% describe shadow AI as pervasive or widespread. That gap is why the inventory must be fed by continuous discovery - SSO logs, CASB signals, procurement workflows - not by self-reporting. Effective shadow AI governance requires connecting discovered tools to remediation workflows: blocking access to prohibited tools, routing newly discovered tools through the intake and approval process, or migrating people to sanctioned alternatives. Treating discovery as a one-time audit misses the point entirely. Shadow AI is a continuous challenge, not a checkbox.
The Governance Forum: What It Does and What It Must Not Do
The one-sentence charter test: If your committee charter does not say what the committee is not allowed to do, it will eventually try to do everything — and then do nothing well.
A well-designed AI Governance Committee has a narrow, powerful mandate. Here is what that looks like in practice.
Membership (7-10 people maximum): Permanent members from IT Security (CISO), Technology/Engineering (CTO or VP Engineering), Legal, Data Privacy, and Compliance/Risk. A senior executive sponsor - CEO, COO, or Board-level Risk Committee Chair - provides escalation authority. Business unit representatives should rotate quarterly to ensure operational perspectives are represented.
Cadence: Monthly is the floor. Quarterly is too slow for an AI portfolio that grows by 30+ systems a year; weekly is unsustainable for a room that includes the CIO, CISO, GC, and CFO.
Quorum: The committee meets monthly. A quorum consists of four voting members, including either the Chair or the Vice Chair. The committee reports to the Audit Committee of the Board at least quarterly, and on demand for material incidents.
A good standing agenda (60-minute hard stop):
- New system approvals requiring committee sign-off (15 min) - pre-read circulated 5 days prior
- Escalated risk decisions from Model Owners (10 min)
- Incident and near-miss review (10 min)
- Policy and regulatory updates (10 min)
- Inventory and monitoring metrics (10 min)
- Actions and owners (5 min)
What the committee is NOT allowed to do:
- Rubber-stamp approvals without reviewing the pre-read
- Become the Accountable owner for individual system compliance (that is the Model Owner's job)
- Review every system - only those that exceed a defined risk threshold or are escalated
- Become the release bottleneck by requiring committee sign-off for low-risk systems
Most committees fail not because they lack a charter, but because they meet without a pre-read, drift into status updates, and never produce a binding decision. Five practices separate working committees from theatre: monthly cadence with quarterly audit-committee reporting, a five-day pre-read window with decisions framed in a three-column format, an explicit decision rights matrix, a standing agenda anchored to new system approvals and incident reviews, and a hard 60-minute time-box.
Making It Survive Contact with the Business
Governance that only activates at launch is governance that arrives too late. By the time a system reaches production, the architecture decisions, the data choices, and the vendor contracts are already locked. The intake gate must be at the point of procurement and at the point of a Jira epic - not at the point of launch.
The two intake triggers:
- Procurement trigger: Any purchase order, contract, or vendor evaluation that includes AI capabilities should route through a lightweight AI intake form before signature. Procurement/Vendor Management owns this gate.
- Engineering trigger: Any new Jira epic, product brief, or design document that involves building or integrating an AI system should trigger the same form. The Product/Engineering Lead owns this gate.
The form itself should take five minutes to complete. Its output is a risk tier (low / medium / high) that determines the subsequent process. Low-risk systems get a fast-track path - documented, inventoried, and approved by the Model Owner without committee involvement. Medium-risk systems get Legal review and a Model Owner sign-off. High-risk systems get the full stack.
An EY survey found 52% of department-level AI initiatives operate without formal approval. The reason is almost always that the governance process is too slow or too heavy for the pace of the business. A tiered path - where the majority of systems get a two-week fast-track - removes the incentive to route around the process.
The Governance Maturity Ladder
Most organisations are on rung 2. Be honest about where you are before you plan where you are going.
The honest observation: A 2026 readiness report found 74% of organisations had no designated internal owner for AI compliance. Most organisations reading this post are on rung 1 or rung 2. The goal for the first 90 days is to reach rung 3 - not rung 5. Rung 5 is a multi-year programme. Rung 3 is achievable in a quarter and is the minimum that will satisfy a regulator asking basic questions.
The Timeline Context: You Have Live Work to Do Today
Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. The deferral pushes compliance for standalone high-risk AI systems (Annex III) from August 2, 2026, to December 2, 2027, and for AI embedded in products already covered by EU product-safety law (Annex I) to August 2, 2028.
The deferral is not a pause. Several obligations remained on the original August 2, 2026, schedule: Article 50 transparency and AI-content-labelling duties, the General-Purpose AI (GPAI) provider obligations that have applied since August 2025, and the Article 5 prohibited-practices regime in force since February 2025. A new prohibition on AI-generated non-consensual intimate imagery and child sexual abuse material was introduced into Article 5 - those two new prohibitions apply from 2 December 2026.
The governance point: the window between now and December 2027 is exactly the window in which the operating model should be built. The machine has live work to do today on Articles 4, 5, and 50. The deferral gives you the runway to build the machine properly rather than in a panic - use it.
The publication of EN 18286:2026, the first standard in support of the AI Act, specifies requirements and provides guidance for the definition, implementation, and maintenance of a quality management system for organisations that provide AI systems - a fundamental step towards regulatory compliance. What EN 18286 describes as a QMS is, in operational terms, exactly what this post describes as a governance operating model. The Article 17 QMS guide covers the standard's requirements in detail. The point here is that the operating model is not a compliance exercise bolted onto the real work - it is the real work.
Your First 90 Days
Find the existing policy, the existing inventory (however incomplete), and the existing committee (however dormant). Interview the CISO, GC, CTO, and one or two business unit heads. Your goal is to understand what is real versus what is documented. Do not build anything yet.
For every system in the existing inventory, assign a Model Owner. If the inventory is empty, start with the five highest-risk systems you can identify. Send a one-page brief to each owner explaining what the role means and what they are accountable for. Get written acknowledgement.
Work with Procurement and Engineering to add a five-question AI intake form to the vendor onboarding process and to the engineering epic template. This does not require a committee decision — it requires two conversations and two Confluence page edits. The gate does not need to be perfect; it needs to exist.
Take the existing inventory and screen every system against the Article 5 prohibited practices list. This is live law. Document the screen, the reasoning, and the sign-off. Any system that raises a question goes to Legal immediately. See our Article 5 guide for the full checklist.
Draft a one-page committee charter: purpose, membership, decision rights, quorum, cadence, escalation path, and — critically — what the committee is not allowed to do. Get it approved by the executive sponsor. Schedule the first 12 monthly meetings before the charter is signed.
Migrate the inventory to a system that can be updated continuously — a GRC tool, a governed spreadsheet with a named owner and a 30-day review SLA, or a dedicated AI governance platform. Run the first shadow AI discovery scan. Report to the committee on inventory coverage, Article 5 screen results, and the intake gate's first month of operation.
At the end of 90 days you should have: a named owner for every known system, a live intake gate, a documented Article 5 screen, a chartered committee with its first meeting behind it, and an inventory that is updated rather than archived. That is rung 3. Everything after that is iteration.
The EU AI Act is unusual in that it hands you the organisational design problem explicitly - it names roles, assigns duties to those roles, and then leaves it to you to translate those roles into named humans with budgets and authority. Most organisations have not done that translation yet. The ones that do it now, in the deferral window, will find the December 2027 deadline manageable. The ones that wait will find themselves building the machine and running it simultaneously - which is how governance frameworks become shelfware.
This post is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for advice specific to your organisation's situation.
Related reading
The Cyber Resilience Act and the EU AI Act: Reporting Went Live on 11 September 2026 - What AI Product Makers Must Do Now
Since 11 September 2026, makers of software and connected products, including most AI products, must report actively exploited vulnerabilities within 24 hours under the Cyber Resilience Act. Here is how CRA reporting works, how CRA Article 12 links to AI Act Article 15, and how to build one incident playbook for both.
EU AI Act News: What the First 60 Days of Enforcement Actually Produced (August-September 2026)
2 August 2026 was supposed to be the day the EU AI Act got teeth. Sixty days later, here is what actually happened: the AI Office's first information requests to GPAI providers, a transparency Code of Practice with 200+ signatories, a new complaints tool, and a string of GDPR decisions that show where AI enforcement is really coming from.
Swiss FADP vs GDPR for AI: How Switzerland Regulates AI Without an AI Act - and When the EU AI Act Still Catches You
Switzerland chose not to copy the EU AI Act. Instead, its revised data protection law applies directly to AI, and a Council of Europe-based bill is due for consultation by the end of 2026. Here is how the Swiss FADP compares with the GDPR for AI use cases, and when Swiss companies are caught by the EU AI Act anyway.