AI governance in practice: moving from policy to live controls

Many organisations now have AI policies and governance frameworks in place. The challenge is to create controls that are clear enough to manage risk, but practical enough not to inhibit innovation or slow AI adoption.

Overly rigid governance can push AI use underground; overly light governance may leave the organisation without a reliable record of how AI systems are being used and managed. 

Start with visibility

AI governance depends on knowing where and how AI is being used. AI may be used in obvious tools, such as generative AI assistants, but also embedded in software products, customer service systems, research platforms, analytics tools, recruitment processes or supplier services.

A useful starting point is a simple inventory of AI use cases. This does not need to be perfect on day one, but it should capture enough information to support meaningful review: what the tool does, who uses it, what data it processes, whether it affects customers or employees, and whether it supports business-critical or regulated activities.

Match governance to how AI is used

Once an organisation has visibility of where AI is being used, the next question is how closely it is integrated into the work¹.

• Where AI is used as a separate assistant - for example to draft, summarise or analyse information for human review - governance may focus on user training, permitted use, data handling and output review.
• Where AI is embedded into live workflows, the system may draw on business data, interact with enterprise systems, support decisions, trigger steps or update records. In those cases, governance needs to address permissions, approval gates, monitoring, logging, escalation and evidence.

The practical point is that governance should follow the operating model. A policy designed for prompt-and-review use will not be enough for AI that is connected to systems and workflows. 

Match controls to the level of risk

Not every AI use case needs the same level of governance. A low-risk internal productivity tool is different from an AI system used in a customer-facing product, a regulated service or a decision-making workflow.

Practical AI governance should therefore be proportionate, and risk based. Relevant factors may include the type of data involved, the level of human oversight, the potential impact on individuals, the degree of autonomy, the importance of the system to the business, and the regulatory context in which it operates.

The EU AI Act, data protection law, sector-specific rules and regulator guidance may all affect what controls are appropriate for a particular use case.

Allow for safe experimentation

Governance should also distinguish between different stages of AI use. A short internal trial using dummy or synthetic data may not need the same approval process as a live deployment using customer data, employee data or business-critical systems.

In many organisations, a lighter process for low-risk trials or proofs of concept can help teams test AI tools safely. The limits that matter most are usually around data use, external sharing, duration, and the path into production.

Be clear about ownership

AI governance can fail where responsibility is too diffuse. Legal, data protection, information security, procurement, product, compliance and business teams may all have a role, but someone needs to own the process.

That does not necessarily mean a single central team approving every AI use case. In many organisations, a more workable approach may be to create a clear allocation of roles: who identifies AI use, who approves it, who monitors it, who reviews supplier terms, who manages incidents and who keeps the governance framework up to date.

Build controls into workflows

The most effective AI governance is not a document sitting on an intranet. It is a practical framework built into the way people procure, develop and deploy technology.

In practice, that may mean AI questions in procurement intake forms, standard contractual positions for AI suppliers, approval routes for higher-risk use cases, user permissions, logging requirements, output review processes, and escalation routes where systems behave unexpectedly.

Keep monitoring after deployment

AI governance does not stop when a tool goes live. AI systems may change over time, whether through model updates, changes in use, new integrations, new data sources or shifts in regulatory expectations.

Ongoing monitoring may involve reviewing performance, tracking incidents, checking whether the system is still being used as approved, monitoring supplier changes, and revisiting whether the original risk assessment remains accurate.

Governance needs to account for the lifecycle of AI use, not just the initial approval decision.

Make escalation easy

A governance framework should make it easy for people to raise concerns. Users may spot inaccurate outputs, unexpected behaviour, bias, data issues, security concerns or customer complaints before central teams do.

Clear escalation routes help organisations respond quickly and consistently. They also support a better audit trail if an AI system, output or decision is later challenged.

For many businesses, the next phase is not writing another AI policy. It is making sure the existing policy is connected to the way AI is actually being used.

Listen further

For more on the identify, design and monitor phases of AI governance, listen to Vik Khurana and Simon McDougall’s AI governance series on The Roadmap. The episodes are available below:

• Identify & Assess
• Design & Implement
• Manage & Monitor
• Top tips from a technology executive

For more on building an AI governance programme, read our companion piece: AI governance: a practical roadmap here.