What Is AI Governance? An EU-Native Framework For Security, Compliance, And Product Leaders

TL;DR. AI governance is the operational discipline of knowing which AI systems your organisation uses, classifying each one by risk, applying the controls that risk warrants, and producing the evidence regulators ask for - across the EU AI Act, GDPR, DORA, and NIS2 simultaneously. It begins with discovery, not with policy. Frameworks like NIST AI RMF and ISO 42001 are useful as scaffolding for an AI governance framework; in Europe, they are not the regulation you will be audited against.

AI governance is how your organisation knows what AI it is using, what that AI is doing, and how it will prove that to a regulator. The board says you need AI governance. The vendor brochures say you need AI governance. Five different consultants have given you five different definitions of AI governance.

Here is one that works.

This piece is a joint take from Montro's two founders, written together because the answer requires both halves of the discipline. Namita has spent twelve years inside compliance functions at HSBC, EY, Accenture, and NTT Data, watching teams try to govern data, then vendors, then AI. Ankur has spent the last three years building inventory and discovery systems for European mid-market firms. The definition below is what we have settled on after running enough audits and enough regulatory conversations to know which definitions hold up under pressure.

A Working Definition

AI governance is the operational discipline of knowing which AI systems your organisation uses, classifying each one by risk, applying the controls that risk warrants, and producing the evidence regulators ask for, across four EU regimes simultaneously.

The definition is built to do specific work. Each phrase is load-bearing.

Operational discipline, not policy framework. AI governance is something an organisation does every day, not a document approved at a board meeting and revisited in six months. The work is continuous because the AI footprint changes continuously.

Knowing which AI systems your organisation uses, that is the inventory. We will come back to why this is the foundation rather than an afterthought.

Classifying each one by risk - under the EU AI Act's four-tier system, plus the firm-specific overlays from sector regulation.

Applying the controls that risk warrants, proportionality matters. Minimal-risk AI gets light-touch governance; high-risk AI gets transparency notices, human oversight, logging, and conformity-assessment cooperation.

Producing the evidence regulators ask for, across four EU regimes simultaneously, because the same AI tool typically generates obligations under the EU AI Act, GDPR, DORA where applicable, and NIS2. Treating those as four separate workstreams is how mid-market firms burn through their compliance budget on duplicated work.

Some clarifications, in case the language is doing more work than it should:

AI governance is not AI ethics. AI ethics asks what AI systems should do; AI governance asks what AI systems are doing in your organisation, and whether you can defend the answer to a supervisor. Some of the "what AI is doing" question is the shadow AI and shadow SaaS work that has to happen before governance can.

AI governance is not AI compliance. Compliance is the documentation output, the registers, the DPIAs, the conformity assessment files. Governance is the discipline that produces the documentation. A firm can have impressive compliance documentation and weak governance; the documents go stale within ninety days because the inventory underneath them was incomplete on the day they were signed.

AI governance is not AI risk management in the narrow enterprise-risk sense. AI risk management is one component, the controls layer. Enterprise AI governance encompasses inventory, classification, controls, and evidence as a whole.

AI governance is not AI safety. AI safety, as a field, addresses the risks of advanced AI systems behaving in unintended ways. AI governance, as a discipline, addresses the risks of organisations deploying AI systems they do not have visibility into. The two communities have different concerns and different vocabularies; they get conflated in vendor pitches and should not be.

The board-meeting version of the definition fits in one sentence. AI governance is how we know what AI we are using, what it is doing, and how we will prove it to a regulator.

The Four Pillars

The work splits cleanly into four pillars. Every AI governance programme we have designed has the same architecture, in the same order.

Pillar 1 - Discovery

A complete and current inventory of every AI system in active use across the organisation. Not approved AI; used AI. Not the AI procurement reviewed; all of it.

What sits inside it: sanctioned AI tools the organisation purchased deliberately. Embedded AI features that turned on inside SaaS the organisation already uses - Notion AI, Slack AI, Microsoft Copilot, Salesforce Einstein, the long list. Free-tier AI accessed by individual employees on personal credentials. Evaluation tools that quietly became production tools. AI APIs called by the firm's own software products. AI in third-party services the firm relies on, where the firm is not the direct AI deployer but the AI's outputs feed the firm's processes.

What is not Discovery: surveying department heads and asking what AI they use. People do not know. The answer they give is the visible top of an iceberg whose bulk sits in tools they have forgotten about, AI features they did not notice activate, and personal-credential adoption they do not think to mention.

The standard discovery method we run combines four data layers - identity and SSO, email and calendar metadata, browser and endpoint telemetry, and finance and expense data. Each layer finds tools the others miss. Run together against a SaaS catalogue with AI feature flags, the four-layer method surfaces ninety per cent of the footprint within thirty days at most mid-market firms.

Pillar 2 - Classification

Per-tool risk categorisation against the regulatory schemes that apply.

What sits inside it: the EU AI Act risk-tier mapping (we will cover the four tiers below). The deployer-versus-provider determination, which changes the obligations substantially. The Annex III category assignment for high-risk systems. The GDPR processor mapping. The DORA register assignment for financial services firms. The NIS2 supply-chain category. Industry-specific overlays - the Medical Device Regulation for healthcare, MiFID II / DORA / PSD2 for financial services, sector-specific guidance from national supervisors.

What is not Classification: a binary "high-risk yes/no" tag. The classification work is fine-grained: the same tool can be high-risk under the EU AI Act and a low-criticality ICT third party under DORA, simultaneously. The classification is a set of regulatory positions, not a single status.

The classification problem is more determinate than vendor marketing implies. Most tools resolve cleanly through a structured decision tree, Article 5 prohibited practices first, Article 6(1) safety-component test second, Article 6(2) Annex III categories third, Article 50 transparency obligations fourth, minimal-risk default last. The hard cases are real but a small percentage of the catalogue.

Pillar 3 - Controls

Per-tier control assignments matched to the classification.

What sits inside it: transparency notices to data subjects (Article 50 obligations and the broader GDPR information requirements). Human oversight processes for high-risk systems. Logging and retention configuration. Vendor due-diligence and contract management. Exception registers for AI tools that cannot yet be brought into governance but need to be monitored. Incident response playbooks that include AI-specific failure modes. Where applicable, conformity-assessment cooperation processes.

What is not Controls: a library of policies. A policy that says "AI must be governed responsibly" is not a control. A documented process that says "before any new AI tool is approved, the DPO assesses processor status, the CISO reviews data flows, the AI lead classifies under EU AI Act, and a register entry is created within seven days", that is a control.

The temptation in mid-market firms is to over-invest in this pillar before the prior two are solid. Sophisticated control libraries applied to incomplete inventories are theatre. The control work has to be proportionate to the classification work, which has to be proportionate to the discovery work, and that sequencing is what separates credible enterprise AI governance from compliance theatre.

Pillar 4 - Evidence

Audit-ready documentation of the prior three pillars.

What sits inside it: the AI Use Register, refreshed and version-controlled. The DPIAs and risk assessments per high-risk system. The conformity assessment files where applicable. The vendor questionnaires and DPAs. The training records for AI literacy obligations under Article 4 of the EU AI Act. The incident logs. The reporting cadence to the executive committee and to the board.

What is not Evidence: a SharePoint folder. Evidence is structured, time-stamped, sign-off-verified, and produceable on demand within the windows the regulator expects - typically days, not weeks.

The cross-regulation point matters most here. A firm that has built four parallel evidence pipelines - one for the EU AI Act, one for GDPR, one for DORA, one for NIS2 - has built four times the maintenance burden for one underlying reality. The unified-evidence layer is the leverage point: one source of truth for the inventory and the classifications, with reporting templates that produce framework-specific outputs from the shared substrate.

Why Discovery Comes First

The strongest argument we can make in this piece is that policy without inventory is theoretical, and most mid-market AI governance programmes start with policy.

The starting-with-policy pattern looks like this. The board asks for AI governance. Compliance leads convene a working group. The group spends six to eight weeks producing an AI Use Policy, an AI Risk Framework, an AI Acceptable Use document, perhaps an AI Ethics Charter. The documents are approved by the executive committee. The team feels accomplished. Six months later the supervisor asks for the AI Use Register. The team produces a register that lists the AI tools the policy team knew about, typically nine to fourteen. The supervisor finds, on inspection, dozens of AI tools in active use that are not on the register. The policy was technically correct and operationally meaningless.

In ninety per cent of the audits we have run for European mid-market firms, the AI Use Register the organisation provided was missing more than half of the AI in actual use. The register-versus-reality gap is widest for firms that started with policy.

The discovery-first sequence inverts the order. Find what is there. Classify each item. Apply controls proportionate to the classification. Produce evidence as a continuous output of the prior three. The policy that emerges from this work is not an aspirational document, it is a description of operational practice that already exists. That is what AI compliance looks like when it is built on governance rather than the other way round.

This sequence is also faster, counter-intuitively. A discovery-first programme produces an audit-ready position in roughly ninety days. A policy-first programme produces an audit-ready position when discovery eventually happens, typically six to nine months in, after the policy team realises the documents they wrote cannot actually be operated against the inventory.

Why An EU-Native Approach Matters

Most of the AI governance content available online is American. The frameworks it cites - NIST AI RMF, the White House AI Bill of Rights, the various state-level AI bills, the SOC 2 mappings - are real, useful, and not the basis on which European supervisors will hold European firms accountable.

The European environment is different in three ways that matter operationally.

The regulatory architecture is enacted, not voluntary. NIST AI RMF is a framework organisations adopt voluntarily; ISO 42001 is a standard organisations certify against voluntarily; the OECD AI Principles are policy guidance with no enforcement mechanism. The EU AI Act is a regulation with binding force, enforcement dates, and fines structured in tens of millions of euros. The same is true of GDPR, DORA, and NIS2. A European mid-market firm operating only against voluntary frameworks is preparing for an exam that will not be set.

The supervisory architecture is plural. A European firm engages with the AI Office (within the European Commission's DG CNECT), the national AI competent authorities (still being designated by member states), the data protection authority for the lead establishment (DPC in Ireland, CNIL in France, BfDI for the federal level in Germany, with the Länder DPAs alongside), and where applicable the financial supervisor (Central Bank of Ireland, BaFin, ACPR, and so on). The cross-supervisor coordination problem is real and material.

National supervisors take materially different positions. The German federal data protection authority and the French CNIL have published more detailed AI-specific guidance than several other DPAs. BaFin and ACPR are most active on financial-services AI applications, and have signalled that DORA enforcement will incorporate AI risk explicitly. The Italian Garante took an aggressive position on ChatGPT in 2023 that no other DPA replicated, then reversed it; that history affects how Italian firms approach generative AI tooling. A pan-European firm has to model these differences, not assume the strictest position satisfies all.

The cross-regulation problem is the most operationally consequential difference, and worth a worked example.

A 600-person fintech in Dublin uses Phenom for AI-driven CV screening. One tool. The obligations:

EU AI Act. Phenom-driven CV screening is a high-risk AI system under Annex III, employment category. The fintech is a deployer, not a provider. Deployer obligations include transparency to candidates, human oversight, ensuring relevant input data, monitoring of operation, and cooperation with the provider's conformity assessment. These obligations enforce from 2 August 2026.

GDPR. Phenom is a processor under Article 28; a Data Processing Agreement must be in place. Processing requires an Article 30 RoPA entry. The processing is likely to result in high risk to candidates' rights, requiring an Article 35 DPIA. Article 22 applies because shortlisting is a decision producing significant effects; candidates have a right to human intervention.

DORA. Phenom is an ICT third-party service provider. The fintech, in scope under DORA, must have Phenom in its Article 8 ICT third-party register, with criticality assessed under the relevant Joint Committee Regulatory Technical Standards.

NIS2. Phenom sits in the fintech's supply chain. Article 21(2)(d) requires the fintech, as an essential or important entity, to address supply chain security including the security of Phenom and its sub-processors.

One tool. Four regimes. Four supervisors. Currently, four documents, often produced by four people who do not talk to each other. This is the AI risk management failure that an EU-native AI governance framework is specifically designed to prevent.

The unified-governance approach treats the inventory and the classification as the shared substrate, then produces framework-specific outputs from that substrate. The DPIA, the ICT register entry, the AI Use Register entry, the supply-chain assessment, these are different views on the same underlying record, generated through templates that map the shared fields to the framework's required structure. Done once, served four ways.

This is the EU-native architecture. Voluntary frameworks have their place; they are not the architecture.

The Role of Frameworks

NIST AI RMF, ISO/IEC 42001, the OECD AI Principles, the IEEE Ethically Aligned Design framework, there is a healthy ecosystem of voluntary frameworks for organisations doing AI governance. The question is when they help and when they do not.

Where frameworks help. They provide vocabulary. The "Map / Measure / Manage / Govern" structure of NIST AI RMF gives a working team a shared shorthand. ISO 42001 provides a certifiable management system that demonstrates programme maturity. The OECD AI Principles offer a high-level set of values useful for executive communication.

Where frameworks stop. They do not tell a European firm how to satisfy Article 6 of the EU AI Act. They do not produce a register that the DPC will accept. They do not classify against Annex III. They do not interlock with DORA Article 8. That gap is the difference between a voluntary AI governance framework and AI compliance with binding European law.

The clean way to think about it: frameworks are the scaffolding, regulations are the building. A team that builds a strong scaffolding and never builds the building has produced impressive-looking work that will not survive the supervisor's first inspection.

For mid-market firms, our recommendation is pragmatic. Adopt one framework as the operational vocabulary, NIST AI RMF if your team is technically oriented, ISO 42001 if your team is management-system oriented. Map your regulatory obligations onto the framework's structure rather than the other way round. Do not pursue ISO 42001 certification before you have completed a discovery and classification cycle, because the certification will surface gaps that the discovery would have surfaced more cheaply.

Roles and Responsibilities

The "who owns AI governance" question is the one that most often stalls programmes at week three. Three patterns work; the fourth, which is the most common, does not.

Pattern 1: DPO-led with CISO partnership. The DPO owns the AI governance programme, with the CISO as the security partner. Works well in firms where the regulatory framing dominates - financial services, healthcare, professional services. The DPO carries Article 30 / Article 35 muscle memory and extends it to AI.

Pattern 2: CISO-led with DPO partnership. The CISO owns, with the DPO as the privacy partner. Works well in firms where the security framing dominates - tech scale-ups, fintech, firms with mature security functions and lighter formal compliance. The CISO carries the inventory and risk-management muscle memory.

Pattern 3: Compliance-led with both DPO and CISO as partners. The Head of Compliance owns the programme, coordinating across DPO and CISO. Works well in firms with strong compliance functions and clear regulatory accountabilities, especially in regulated industries. The compliance team treats AI governance as a new regime alongside existing ones, which structurally fits its job.

The pattern that does not work: AI Lead / Chief AI Officer ownership without integration. Some firms hire an AI Lead and assign them governance. The role is real and useful - for product strategy, for AI engineering standards, for vendor selection. It does not work for governance, because governance is a regulatory and operational discipline, not a product discipline. The AI Lead who tries to own governance ends up doing CISO work without CISO authority, DPO work without DPO mandate, and compliance work without compliance training. They burn out at month nine, the programme stalls, and the firm reorganises.

Mid-market firms typically cannot afford a dedicated Chief AI Officer, and we would argue most should not have one even if they can. The right structure is Pattern 1, 2, or 3, chosen based on which function has the strongest existing operational muscle, with a small cross-functional working group that meets fortnightly and reports to the executive committee monthly.

A 90-Day Starter Plan

The structured way to go from "we need AI governance" to "we have AI governance" is a thirteen-week programme. Weeks 1–4 are discovery: connect data sources, run the four-layer discovery method, produce the first complete AI inventory. Weeks 5–8 are classification: each tool through the EU AI Act decision tree, mapped to GDPR processor status, positioned in the DORA register where applicable, assessed for NIS2 supply chain category. Weeks 9–11 are controls: per-tier control assignments, ownership per tool, exception register. Weeks 12–13 are evidence: first audit-ready outputs, reporting cadence, regulatory simulation.

The output at day ninety is an operating enterprise AI governance programme. Not a finished one, governance is continuous, but one that can survive an external inspection.

Frequently Asked Questions

Is AI governance the same as AI compliance?

No. Compliance is the documentation output. Governance is the discipline that produces the documentation and keeps it true. A firm with strong compliance and weak governance has documents that are correct on the day they are signed and wrong six weeks later. A firm with strong governance has compliance as a continuous output of the operating model.

Do we need AI governance if we don't build AI?

Yes. Most mid-market firms do not develop AI; they deploy AI provided by others, embedded in SaaS, accessed via APIs, run as standalone tools. The EU AI Act explicitly addresses both providers and deployers. Deployer obligations are different from provider obligations but they are real, and most mid-market firms are deployers many times over.

How much does AI governance cost to run?

Setup investment varies materially with firm size and existing compliance function maturity. Steady-state cost is typically the equivalent of one to two full-time roles in a 1,000-person firm - distributed across the DPO, the CISO, and one cross-functional coordinator, plus a software platform and the cost of episodic external assurance. Firms that invest below that level produce documentation that does not survive supervisor inspection.

Can we wait until the EU AI Act August 2026 deadline gets closer?

You can; we would not. The August 2026 deadline applies to high-risk systems already in operation. The discovery and classification work to identify which of your systems are high-risk takes thirty to sixty days. The control implementation and evidence work for high-risk systems takes another sixty to ninety days. A firm that starts in July 2026 will not be ready by August. A firm that starts in May 2026 will be.

What happens if we get it wrong?

The fines are sized to be felt. EU AI Act Article 99 sets penalties up to €35 million or 7% of global annual turnover for prohibited-practice violations, and up to €15 million or 3% for most other obligations. GDPR fines are well known. DORA introduces sanctions including, for the most serious breaches, restrictions on operating activities. The fine risk is real, but it is the second-order risk: the first-order risk for most firms is reputational, in the lag between a finding and the public disclosure that follows.

Do voluntary frameworks (NIST, ISO) satisfy the EU AI Act?

No. Adopting NIST AI RMF or certifying against ISO 42001 demonstrates programme maturity. It does not satisfy the EU AI Act. The Act sets specific deployer and provider obligations - register entries, conformity assessment cooperation, transparency to data subjects, human oversight, AI literacy of staff, that are not produced by adopting a voluntary framework.

What is the single most common mistake European mid-market firms make?

Starting with policy. The team produces an AI Use Policy and an AI Risk Framework before they have an AI Use Register. Six months later they have impressive documents and an inventory that is missing half of what is actually in use. The order matters. Discover first, classify second, control third, evidence fourth, policy fifth, the policy is the description of what the prior four pillars produce, not the input to them. That sequence is the foundation of AI compliance that holds up under inspection.