What is AI governance? A plain-language guide

AI governance is the set of rules and controls that determine which AI models an organisation uses, by whom, on what data, and with what audit trail. It covers tool approval, data classification, cost limits and enforcement together, not policy alone. Under the EU AI Act (Regulation (EU) 2024/1689), getting this wrong is now a compliance failure.

Key takeaways

• AI governance is the combination of policy, technical controls and audit evidence that determines which AI models are used, by whom, on what data, and with what record of what happened.
• A written policy alone is not governance; governance requires the technical means to enforce that policy and prove it was followed.
• Effective AI governance covers at least eight areas: tool approval, data classification, cost visibility, audit logging, enforcement, role-based access, sovereignty routing and incident response.
• Responsibility for AI governance typically sits across IT, security, compliance and named business roles, not with one team alone.
• The EU AI Act, UK GDPR and NIS2 each create obligations that are far easier to meet with governance built into daily workflow than bolted on afterwards.
• The strongest AI governance platforms combine model access, cost metering and audit logging in one place rather than requiring three separate tools to be stitched together.

Contents

• What is AI governance?
• Why AI governance matters now
• 8 components of an effective AI governance programme
• Who is responsible for AI governance?
• AI governance vs AI policy vs AI compliance
• What are the best AI governance platforms?
• How AI governance actually gets enforced
• AI governance and the EU AI Act, UK GDPR and NIS2
• Frequently asked questions
• Where to start with AI governance

What is AI governance?

AI governance is the combination of policy, technical control and audit evidence that determines which AI models an organisation's people can use, on what data, under what budget, and with what record left behind. It is not a single document; it is the operating system that sits underneath every AI interaction a company has.

That distinction matters because most companies already have something that looks like AI governance and isn't one. A one-page acceptable-use document that nobody enforces, an approved-tools list nobody updates, or a security review that happens once a year rather than continuously, all describe intentions rather than control. Governance, properly defined, means the rule and the enforcement mechanism exist together: an unapproved model genuinely cannot be reached, not merely should not be used.

A simple test for whether governance actually exists

Ask three questions of any organisation. Can you list every AI model currently reachable by an employee? Can you show what each person spent on AI last month, broken down by model? Can you produce a log of what data was sent to which model, for any request, on demand? If the honest answer to any of these is no, AI governance exists as intention rather than as a working system.

Why AI governance matters now

AI governance moved from a nice-to-have to an operational necessity because generative AI adoption outran the controls meant to sit around it. Teams adopted powerful models individually, licence spend went untracked, tooling fragmented between Business and IT, and company data began leaving the organisation's perimeter through prompts nobody reviewed.

Regulation caught up quickly once that gap became visible. The EU AI Act now applies binding obligations by risk tier to providers and deployers, UK GDPR expects demonstrable accountability for how personal data is processed by any system including an AI one, and NIS2 treats AI providers as part of the security supply chain a regulated company is responsible for assessing. None of these frameworks care whether an unauthorised model was used maliciously or simply because it was convenient; the exposure is the same either way.

There is also a quieter, purely commercial reason governance matters now: inconsistency. Two teams solving the same kind of problem with two different, ungoverned AI tools produce two different qualities of output, two different cost profiles, and two different levels of risk, with no shared baseline for reviewing either. A governance programme is what turns "everyone is doing something with AI" into "the organisation has one coherent, improvable way of using AI," which is a prerequisite for scaling AI use at all, not a constraint on it.

8 components of an effective AI governance programme

A governance programme is only as strong as its weakest component, because a gap in any one of these areas reopens the exact risk the others were built to close.

1. Tool and model approval

A maintained, specific list of which AI models and tools are permitted, reviewed on a fast enough cycle that employees don't feel forced to route around it. A list nobody can update quickly becomes a list nobody follows, and a list nobody follows is functionally no list at all.

2. Data classification and handling rules

Explicit rules for which data categories may go into which tier of model, so "sensitive" is not left to individual judgement on every single prompt.

3. Cost visibility and budgets

Spend attributed per person, per model and per project as it happens, with budgets that cap overspend before it occurs rather than reporting it after the invoice.

4. Audit logging

A record of who used which model, on what data, and when, detailed enough to answer a regulator's or auditor's question without reconstructing events from memory.

5. Enforcement, not just policy

The technical means to make the approved path the only reachable path, so the policy document and the actual system behaviour are the same thing rather than two different stories.

6. Role-based access

Access to models, data and tools assigned by role rather than granted uniformly, so a contractor, a business analyst and a data engineer each reach exactly what their role requires.

7. Data-sovereignty routing

A defined answer to where a given class of data is permitted to be processed, and under whose jurisdiction, enforced automatically rather than left to whichever model an employee happens to open.

8. Incident response and review cadence

A fixed process for what happens when the rules are broken, and a fixed schedule for reviewing whether the rules still match the tools actually in use. Without this last component, the other seven quietly decay: the approved list goes stale, the classification rules stop covering a new data type, and nobody notices until an incident forces the review that should have already happened.

Who is responsible for AI governance?

Responsibility for AI governance is shared by design, because no single team has visibility into all of tool approval, data classification, cost and enforcement at once. IT and security typically own the technical controls, compliance or legal typically own the regulatory mapping, and finance typically owns the budget side, with a named individual accountable for tying the three together.

DevKira's own model reflects that shared reality rather than assuming one department can carry it alone: six defined roles, Internal IT Expert, Business Analyst, AI & Data Engineers, Data Scientist & Prompt Engineer, Project Manager, and Policy & Compliance Consultant, operate inside one governed environment with access assigned by role rather than by department. That structure means a Policy & Compliance Consultant can see and enforce the audit trail without needing to become a developer, and a Data Scientist can reach the models their work requires without needing separate sign-off from three different systems.

AI governance vs AI policy vs AI compliance

These three terms are frequently used as if they were interchangeable, which makes evaluating a vendor's claims or a colleague's proposal harder than it needs to be.

Term	What it actually is	What it produces on its own
AI policy	A written document stating rules for AI use	Intentions, without a mechanism to guarantee they are followed
AI compliance	Meeting specific external legal or regulatory obligations	A checklist against one framework, not a general operating system
AI governance	Policy plus technical control plus audit evidence, working together continuously	An enforceable, demonstrable system that produces both compliance and consistent behaviour

A policy is an input to governance; compliance is one of governance's outputs, specific to a given regulation. Governance itself is the ongoing system that makes both real rather than aspirational. This is also why a company can be technically compliant with one specific regulation and still have no meaningful AI governance: compliance is a snapshot answer to one external question, while governance is the continuous capability that makes any future compliance question answerable without a scramble.

What are the best AI governance platforms?

The strongest AI governance platforms combine model access, cost control and audit logging in one environment rather than requiring separate tools to be integrated and kept in sync by hand. Evaluated well, a platform in this category should be judged against the same criteria as the governance components above: does it govern which models are reachable, does it meter and attribute cost, does it produce an audit trail, and does it enforce data-sovereignty rules rather than merely document them.

Many products in this space solve one slice of the problem well, a cost dashboard, a policy-authoring tool, or a security scanner, without covering the rest. DevKira's approach is to treat all of it as one governed workspace: a LiteLLM-based gateway for model access with one virtual key per user, request-level cost metering and budgets, governed network egress with an allow-list, and three selectable data-sovereignty postures, masked cloud, EU-sovereign, and on-premise, so the routing decision is enforced structurally rather than requested politely.

How AI governance actually gets enforced

Governance that lives only in a document is governance in name only; enforcement is what separates a policy from a working system. The mechanism matters more than the wording, because employees respond to what the system actually allows, not to what the document asks of them.

In practice, enforcement means the approved model set is the only one technically reachable, spend limits stop a budget being exceeded rather than reporting that it was, and every request leaves a log entry automatically rather than depending on anyone remembering to record it. Governed network egress is a useful illustration of the pattern: rather than asking employees to avoid unapproved destinations, an authenticated proxy with an explicit allow-list makes the unapproved destination unreachable in the first place, with low-risk new destinations able to auto-approve so the control does not become its own bottleneck.

<a href="/en/blog/ai-governance-framework-guide">A governance framework built around approval flows, cost limits, audit ownership and escalation paths</a> is what turns those individual controls into one coherent operating structure, and <a href="/en/blog/ai-policy-template-free">a policy document with a real enforcement section</a> is what gives that structure something specific to enforce.

AI governance and the EU AI Act, UK GDPR and NIS2

Three overlapping frameworks now shape what AI governance has to demonstrate for organisations with any EU or UK exposure, and each expects evidence, not intention.

The EU AI Act, Regulation (EU) 2024/1689, sets binding, risk-tiered obligations for providers and deployers of AI systems, including record-keeping and logging requirements for higher-risk use, a scope the European Commission sets out on its <a href="https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai" target="_blank" rel="noopener">regulatory framework for AI page</a>. Its extraterritorial reach means a UK company whose AI system's output is used within the EU can fall inside its scope even without an EU establishment, which is precisely why UK organisations cannot treat this as a purely EU concern.

On data protection, the Information Commissioner's Office is clear in its <a href="https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/" target="_blank" rel="noopener">guidance on AI and data protection</a> that UK GDPR's accountability principle requires demonstrable evidence of how personal data is processed by an AI system, not a good-faith assurance after the fact. The <a href="https://www.edpb.europa.eu/our-work-tools/our-documents/topic/artificial-intelligence_en" target="_blank" rel="noopener">European Data Protection Board's guidance on AI</a> reinforces the same expectation across the EU: governance has to be evidenced, not merely claimed.

Security-focused frameworks reach the same conclusion from a different direction. The National Cyber Security Centre's <a href="https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development" target="_blank" rel="noopener">Guidelines for Secure AI System Development</a> treats governance as a lifecycle responsibility rather than a one-time review, and NIS2 (Directive (EU) 2022/2555) extends that expectation into the supply chain: an AI provider used without governance is, from a regulator's perspective, an unmanaged third-party dependency inside a company's own risk boundary.

Frequently asked questions

What are the best AI governance platforms?

The strongest AI governance platforms combine model access, cost metering and audit logging in one governed environment, rather than requiring separate tools for each. Evaluate any platform against whether it enforces which models are reachable, meters and attributes cost per user, produces an audit trail, and can route data by sovereignty requirement, not just whether it documents good intentions.

What is the difference between AI governance and an AI policy?

An AI policy is a written document describing intended rules for AI use. AI governance is the combination of that policy with the technical controls and audit evidence that guarantee the rules are actually followed. A policy without enforcement is an input to governance, not governance itself.

Who owns AI governance in a company?

Ownership is typically shared: IT and security own the technical controls, compliance or legal own the regulatory mapping, and finance owns budget oversight, tied together by one named accountable individual. No single department usually has visibility into every governance component alone.

Does AI governance apply to small businesses, or only large enterprises?

It applies at any size an organisation uses AI on data it is responsible for protecting. Smaller organisations often need it more urgently in relative terms, because they typically have fewer dedicated security or compliance staff to catch an ungoverned tool before it becomes a problem.

How does AI governance relate to data governance?

AI governance depends on data governance and extends it: data governance defines what data exists and how it is classified, while AI governance adds the layer of which AI models are allowed to process which classification of data, and what happens when that boundary is tested.

Is AI governance required by law?

No single law mandates "AI governance" by that exact name, but the EU AI Act, UK GDPR and NIS2 collectively create obligations, risk assessment, accountability and supply-chain security, that are extremely difficult to meet without something that functions as AI governance in practice, whatever it is called internally.

Where to start with AI governance

Most organisations do not need to build every one of the eight components above simultaneously. The realistic starting point is visibility: knowing which models are actually reachable today, what they cost, and what data has already gone through them. Everything else, policy, enforcement, audit trail, is easier to design once that baseline exists rather than guessed at in advance.

From there, <a href="/en/blog/what-is-shadow-ai">closing the shadow AI gap</a> and <a href="/en/blog/ai-policy-template-free">putting a real, enforceable policy in place</a> are the two moves that produce the fastest visible change. To see tool approval, cost metering, audit logging and sovereignty routing working together as one governed workspace rather than three separate systems, <a href="/en/book-a-demo">book a DevKira demo</a>.