An AI governance framework is the small set of decisions, owners and records that lets a company say, at any moment, which AI systems it uses, what each one is allowed to do, who is accountable for it, and how it would know if something went wrong. For a mid-market company that is not a department and not a software purchase. It is seven controls, each producing one artefact, each with a named owner — and most of them can be in place within a quarter.
The urgency is regulatory and operational at the same time. The EU AI Act's prohibitions and AI literacy duty have applied since 2 February 2025, transparency duties since 2 August 2026, and the Digital Omnibus moved the high-risk obligations for Annex III systems to 2 December 2027. Meanwhile your people are already using AI tools you have never approved. Governance is how you close the distance between what the company believes it uses and what it actually uses, before a regulator, an auditor or a breach closes it for you.
Who this guide is for
You run operations, technology, risk or legal at a company of roughly 100 to 2,000 people — a bank, an insurer, a healthcare provider, an energy or industrial business, or a software company selling into one of them. You have AI in production or about to be, nobody whose full-time job is AI compliance, and a board that has started asking. I build and ship AI systems for clients in exactly these sectors, so what follows is the framework I actually use, not a maturity model.
What an AI Governance Framework Actually Is (and Is Not)
Search for what is AI governance and you will get principles: fairness, transparency, accountability, human-centricity. They are all correct and none of them tells a COO what to do on Monday. Principles are the why. A framework is the how: the operating mechanism that turns principles into decisions somebody has to make and evidence somebody has to keep.
A useful test: a working AI governance framework can answer three questions in under an hour, with documents rather than opinions.
- What AI do we run? Every system, including the AI features switched on inside software you already license and the tools employees adopted on their own.
- Which of it matters? Which systems touch decisions about people, regulated processes or confidential data — and what the EU AI Act calls each of them.
- Who answers for it? One named person per system who can explain what it does, what it was tested against, and what happens when it fails.
If you cannot answer those today, you do not have an AI governance problem yet — you have an AI visibility problem, and every expensive governance initiative built before fixing it will be built on guesses. That is why the framework below starts with an inventory and not with an ethics charter.
Why This Is a 2026 Problem, Not a 2028 One
The delay to the high-risk deadline has persuaded some leadership teams that governance can wait. The adoption data says the exposure is already here, and most of it has nothing to do with high-risk classification:
| Indicator | Figure | Source (date) |
|---|---|---|
| EU enterprises (10+ employees) using AI | 20.0% in 2025, up from 13.5% in 2024 | Eurostat (December 2025) |
| Large / medium / small EU enterprises using AI | 55.0% / 30.4% / 17.0% | Eurostat (December 2025) |
| Knowledge workers using AI at work | 75% | Microsoft & LinkedIn Work Trend Index (May 2024) |
| AI users bringing their own tools to work | 78% | Microsoft & LinkedIn Work Trend Index (May 2024) |
| Organisations reporting breaches of AI models or applications | 13%, of which 97% lacked proper AI access controls | IBM Cost of a Data Breach (2025) |
| Organisations with no AI governance policies | 63% | IBM Cost of a Data Breach (2025) |
| Extra breach cost when shadow AI was involved | USD 670,000 on top of a USD 4.44M average | IBM Cost of a Data Breach (2025) |
Read the rows as a sequence. Adoption is rising fastest in the companies large enough to have regulated processes. Most of that adoption is employee-led, which means unrecorded. And the organisations that have already been breached through AI overwhelmingly had no access controls and no policy. None of this waits for 2027. The Eurostat figure also tells you something useful competitively: in most of Europe, four out of five companies are not using AI at all yet, so the ones building governance now are building it at the start of the curve, when it is cheap.
The EU AI Act After the Digital Omnibus: What Is Due When
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. It postponed the high-risk obligations, mainly because the harmonised standards they depend on were not ready, and left almost everything else on schedule. This is the timeline that now applies:
| Date | What applies | Who it hits in a mid-market company |
|---|---|---|
| 2 February 2025 | Prohibited practices (Article 5); AI literacy duty (Article 4) | Everyone using AI — already in force |
| 2 August 2025 | General-purpose AI model rules; national authorities; penalties regime | Mostly model providers; your vendors' obligations start here |
| 2 August 2026 | Transparency duties (Article 50): chatbots disclosed, deepfakes and AI-generated public-interest text labelled | Any customer-facing assistant or synthetic content |
| 2 December 2026 | Watermarking grace period for existing systems ends; new ban on non-consensual intimate imagery and CSAM generation | Providers of generative systems |
| 2 December 2027 | High-risk obligations for Annex III systems (credit scoring, insurance pricing, HR, critical infrastructure, biometrics…) | Banks, insurers, every employer screening candidates with AI |
| 2 August 2028 | High-risk obligations for Annex I systems (AI inside regulated products such as medical devices and machinery) | Medtech, industrial equipment makers |
Two of the changes are easy to misread. First, the AI literacy duty was softened: providers and deployers must now support the development of AI literacy among their staff rather than ensure a specified level. It did not disappear, and it still applies today. Second, nothing in the Omnibus touched Article 99 penalties or the prohibitions. The Act is in force; only the high-risk chapter moved.
The delay is a window, not a reprieve
Fourteen months is roughly the time it takes a mid-market company to inventory its AI, renegotiate three or four vendor contracts, build decision logging into the systems that need it and run one honest internal review. Companies that start in late 2027 will be doing all of it under deadline, with consultants priced accordingly. The companies that use the window will spend a fraction of that and arrive with evidence instead of promises.
Provider or Deployer: The Question That Sizes Everything
The AI Act assigns most of its heavy obligations — risk management system, technical documentation, conformity assessment, CE marking, registration — to the provider: whoever develops an AI system and places it on the market or puts it into service under its own name. Most mid-market companies are not providers. They are deployers: they use systems built by someone else. For a high-risk system, a deployer's duties under Article 26 are real but bounded:
- Use the system in line with the provider's instructions for use, with appropriate technical and organisational measures.
- Assign human oversight to people with the competence, training, authority and support to exercise it.
- Ensure the input data you control is relevant and sufficiently representative for the intended purpose.
- Monitor the system's operation and report serious incidents to the provider and the market surveillance authority without delay.
- Keep the logs the system generates for a period appropriate to its purpose, and at least six months.
- Inform workers' representatives and affected workers before putting a high-risk system into use at the workplace.
That list is achievable without a compliance department. The trap is drifting from deployer into provider without noticing. Article 25 turns a deployer into a provider of a high-risk system — with every provider obligation attached — in three situations, and all three are common in companies that build on top of AI models:
- You put your name or trademark on a high-risk system that someone else built — the white-labelled scoring engine sold to your own customers, for example.
- You make a substantial modification to a high-risk system already on the market, such as retraining it on your data for a different decision.
- You change the intended purpose of a system so that it becomes high-risk — the general-purpose assistant that your HR team starts using to rank candidates.
The Seven-Control AI Governance Framework
This is the minimum viable framework I put in place for mid-market clients. Each control produces one artefact you can show an auditor, a board or a buyer's due-diligence team. Each maps to something the AI Act, GDPR or your sector regulator already expects. The effort column is my own experience for a company of 200 to 1,000 people with a few dozen AI use cases, not an industry benchmark.
| # | Control | Artefact | Main anchor | Owner | Typical effort |
|---|---|---|---|---|---|
| 1 | AI inventory | AI register (one row per system) | Foundation for Art. 26 and Art. 50 | AI governance lead | 2–4 weeks, then monthly |
| 2 | Risk tiering | Tier per register row, with rationale | Art. 5, Art. 6 and Annex III, Art. 50 | Lead + legal | 1–2 weeks |
| 3 | Ownership | Named business owner per system; small AI board | Art. 26(2) human oversight | Executive sponsor | 1 week |
| 4 | Acceptable use & data rules | One-page AI use policy + data classes per tool | GDPR, Art. 4 literacy | Lead + DPO + security | 2 weeks |
| 5 | Human oversight & logging | Oversight procedure + log retention per system | Art. 26(2), 26(5), 26(6) | System owner + engineering | 2–6 weeks per high-risk system |
| 6 | Vendor due diligence | AI vendor questionnaire + contract clauses | Art. 26(1), Art. 25 | Procurement + legal | 1–2 weeks, then per contract |
| 7 | Monitoring, incidents, literacy | Incident runbook, quarterly review, training record | Art. 26(5), Art. 4, Art. 73 | Lead + security | Ongoing, ~2 days per quarter |
Control 1 — The AI inventory
Everything else depends on this, and it is always larger than leadership expects. In the inventories I have run, the systems leadership knew about were typically well under half of the final register. The rest were AI features enabled by default inside existing SaaS — CRM scoring, ticket triage, meeting transcription, code assistants — and tools individual teams adopted on a card. Find them through procurement and expense data, SSO logs, browser-extension reports and a short, amnesty-style survey: people disclose far more when the message is "tell us so we can make it safe" than when it is "who broke the rules".
- What it is and who provides it: product, vendor, model provider underneath if known, version or contract reference.
- What it does here: the business process, the decision it informs or makes, and whether a human reviews the output.
- What data goes in: personal data, special-category data, confidential client data, source code.
- Who it affects: employees, customers, applicants, patients, the public.
- Your role: provider or deployer, and why — written down, because Article 25 makes it a moving target.
Control 2 — Risk tiering
Tier every row twice. First by the AI Act's categories — prohibited, high-risk under Annex III or Annex I, transparency obligations under Article 50, or minimal risk. Second by your own business criticality: what happens to customers, money or reputation if this system is wrong for a week. The second tier matters because most of your risk sits in systems the Act considers minimal. A sales-forecasting model is not high-risk under the Act. It can still mislead a board. Your controls should follow the higher of the two tiers, not the legal one alone.
Control 3 — Ownership
Every system gets one accountable business owner — the head of the function whose decisions it shapes, not the IT person who installed it. Above them sits a small AI board: an executive sponsor, the AI governance lead, someone from legal or the DPO, security, and one business leader who uses AI heavily. Five people, meeting monthly for an hour, with authority to approve, pause or retire a system. Large AI governance committees fail in the mid-market for a simple reason: when fifteen people own a decision, nobody does.
Control 4 — Acceptable use and data rules
Write an AI governance policy that fits on one page and that people will actually read: which tools are approved, which classes of data may go into which tool, what must never be pasted anywhere (client personal data, credentials, unreleased financials, source code under NDA), and how to request a new tool with a promised answer within five working days. That last line is the one that reduces shadow AI. Bans without a fast approval route simply move usage to personal devices, where you see none of it.
Control 5 — Human oversight and decision logging
"Human in the loop" is not a control unless you can show who the human was, what they saw, and what they decided. For each system tiered high, define the oversight point, the authority to override, and what gets logged: input, output, the reviewer, the final decision and any override. Keep logs at least six months, longer where sector rules require it. This is engineering work, and it is the same discipline I describe for AI-generated code in the enterprise guardrail playbook for vibe coding: if the evidence is not produced by the system automatically, it will not exist on the day you need it.
Control 6 — Vendor due diligence
As a deployer, most of your AI risk arrives through contracts. The AI features your vendors ship are governed by their documentation and your agreement with them, and most standard SaaS terms were written before anyone asked these questions. Add an AI section to your vendor questionnaire and your renewal checklist:
- Is our data used to train or improve models, and can we opt out contractually rather than through a settings toggle?
- Which model providers sit underneath, in which regions is data processed, and how are we told when they change?
- For high-risk uses: will you provide the instructions for use, logging capability and information we need to meet our Article 26 duties?
- What is your incident notification time for AI-related failures, and does it match our own regulatory clocks?
- Can AI features be disabled per tenant, and are new AI features switched off by default until we approve them?
Control 7 — Monitoring, incidents and literacy
Governance decays the month after it is set up unless something forces a review. Put three things on a calendar: a monthly register update fed by procurement and SSO data; a quarterly review by the AI board of every high-tier system against its owner's metrics; and an AI incident runbook that plugs into your existing security incident process rather than creating a parallel one. Literacy is the cheapest control of the seven: role-based training of an hour or two for most staff, deeper for system owners and reviewers, with attendance recorded. It is also the obligation that has applied since February 2025.
Sector Hotspots: Where Mid-Market Companies Meet Annex III
The high-risk list is narrower than vendor marketing suggests. In the sectors I work with, these are the uses that actually land in it — and the ones that do not:
| Sector | Use case | AI Act classification | From |
|---|---|---|---|
| Banking & lending | Creditworthiness assessment or credit scoring of natural persons | High-risk, Annex III 5(b); fundamental rights impact assessment required (fraud detection excluded) | 2 Dec 2027 |
| Insurance | Risk assessment and pricing for life and health insurance | High-risk, Annex III 5(c); fundamental rights impact assessment required | 2 Dec 2027 |
| Any employer | CV screening, candidate ranking, promotion or termination decisions, task allocation, performance monitoring | High-risk, Annex III point 4; inform workers before use | 2 Dec 2027 |
| Energy & utilities | Safety components in the management and operation of electricity, gas, heating or water supply and critical digital infrastructure | High-risk, Annex III point 2 | 2 Dec 2027 |
| Healthcare | AI in medical device software; emergency patient triage | High-risk via Annex I (medical devices) or Annex III 5(d) | 2 Aug 2028 / 2 Dec 2027 |
| All sectors | Customer-facing chatbots and assistants | Transparency: people must know they are dealing with AI | In force since 2 Aug 2026 |
| All sectors | Internal copilots, summarisation, coding assistants, forecasting | Minimal risk under the Act — governed by your own tiering and GDPR | Literacy duty in force |
The fundamental rights impact assessment in Article 27 deserves a specific note for banks and insurers, because it is the one obligation in this table that falls on the deployer rather than the vendor. Before first use of a credit-scoring or life and health pricing system, you must assess who could be affected and how, and what oversight and remediation you have in place. If you already run GDPR data protection impact assessments, extend that template rather than inventing a new one. The architecture side of this — audit trails, access control, data residency — is covered in detail in building compliance-first software in regulated industries.
What Non-Compliance Costs
| Infringement | Maximum fine (Article 99) | Note for SMEs |
|---|---|---|
| Prohibited AI practices (Article 5) | EUR 35 million or 7% of worldwide annual turnover, whichever is higher | Whichever is lower |
| Most other obligations, including deployer duties (Article 26) and transparency (Article 50) | EUR 15 million or 3% of worldwide annual turnover, whichever is higher | Whichever is lower |
| Supplying incorrect, incomplete or misleading information to authorities | EUR 7.5 million or 1% of worldwide annual turnover, whichever is higher | Whichever is lower |
I would not build a governance programme on fear of these numbers; national authorities will start with guidance and the obvious cases. The more immediate commercial cost is in procurement. Large buyers in finance and healthcare are already adding AI questions to vendor due diligence, and a mid-market supplier that can hand over a register, a policy and an oversight procedure wins deals that a supplier promising "we take AI seriously" loses.
Who Owns AI Governance When You Have No Compliance Department
The most common failure I see is not a missing policy. It is a policy owned by legal, a register owned by IT, training owned by HR, and nobody who connects them. Mid-market companies need one person — usually 20 to 40 percent of a senior role, not a new hire — who owns the framework end to end. The best candidates are a CTO or head of data who understands the systems, or a COO who understands the processes. The worst is someone junior given the title without the authority to pause a system.
- Executive sponsor (CEO, COO or CFO): owns the risk appetite and chairs or attends the AI board.
- AI governance lead: owns the register, the tiering, the calendar and the evidence pack.
- System owners: one per system, accountable for its outcomes, its oversight and its metrics.
- Legal / DPO: classification calls, impact assessments, vendor clauses.
- Security: access controls, incident response, monitoring of unsanctioned tools.
- Engineering: logging, oversight hooks and evaluation built into the systems themselves.
“If nobody in the company can switch an AI system off, you do not have governance. You have documentation.”
— Michele Cimmino · Fractional CTO & Digital Transformation Advisor
The First 90 Days
- Weeks 1–2 — appoint and announce. Name the executive sponsor and the AI governance lead, form the five-person AI board, and announce an amnesty-style inventory: disclose what you use, nothing gets punished.
- Weeks 2–5 — build the register. Procurement, expenses, SSO and browser data, plus the survey. Include AI features inside existing SaaS. Record provider or deployer role for every row.
- Weeks 5–6 — tier and triage. Classify each system under the AI Act and by business criticality. Retire or block anything prohibited or indefensible immediately; there is usually at least one.
- Weeks 6–8 — publish the one-page policy with approved tools, data classes and a five-day approval route for new tools. Launch role-based literacy training and record attendance.
- Weeks 8–10 — fix the vendor side. Send the AI questionnaire to the vendors behind your top-tier systems and schedule contract amendments at the next renewal.
- Weeks 10–12 — instrument the high-tier systems. Define oversight points and decision logging for each, starting with anything in Annex III. Assemble the evidence pack and hold the first quarterly review.
Mistakes Worth Avoiding
- Buying an AI governance platform before you have a register. Tools automate a process; they do not invent one. Most mid-market companies can run the first year on a well-structured spreadsheet and their existing GRC or ticketing tool.
- Writing an ethics charter first. Principles without an inventory produce a document nobody can apply. Write principles after you know what they will govern.
- Treating governance as legal's project. Half of the controls are engineering — logging, access, oversight hooks — and cannot be delivered by a policy.
- Ignoring the AI inside software you already pay for. It is the largest and least visible part of the register, and it changes with every vendor release. The same dynamic is behind the rising cost of enterprise SaaS I described in the SaaS reckoning.
- Banning tools without an approval route. It does not stop usage. It stops you from seeing it.
- Reading the Omnibus as permission to wait. Prohibitions, literacy and transparency already apply, and your buyers' due diligence does not follow the AI Act's calendar.
The Bottom Line
AI governance for a mid-market company is not a scaled-down version of what a global bank does. It is a different problem: fewer systems you build, many more you rent, very little dedicated staff, and the same regulator. The answer is a framework small enough to run with the people you already have — an inventory, a tiering, named owners, a one-page policy, logging where it matters, vendor clauses and a quarterly review. The Digital Omnibus gave Annex III deployers until December 2027. Use the window to build the evidence rather than to postpone the conversation. Companies that can show their AI register in a due-diligence meeting will discover that governance is not only a cost. It is a reason to be chosen.
If you want a second pair of eyes
I help mid-market companies in finance, insurance, healthcare and energy set up exactly this: the first inventory, the provider-or-deployer calls, the oversight and logging design for the systems that need it, and the vendor questions to ask before renewal. Through Lasting Dynamics we also build the AI systems themselves, which is why I care about governance that engineers can actually implement.