AI Governance in Practice: One Way to Turn Principles into Control

In an earlier article, I looked at the growing governance challenge created by Artificial Intelligence, and some of the questions Boards and senior leaders should be asking.

Where is AI being used? Who owns it? What risks have been considered? What controls are operating? How are outputs validated? And, if challenged, could the organisation demonstrate that those arrangements actually work?

However, those questions lead to a more practical one:

What does effective AI governance actually look like?

One thing is particularly clear to me: there isn't one universal answer. What works for one organisation may be quite wrong for another. It also depends on the decisions AI is influencing, the risks involved and, ultimately, the consequences if something goes wrong.

Therefore, I do not intend to propose the AI governance model. It is simply one way I would approach the problem, and I would start with visibility.

Start with Visibility

Before an organisation can govern AI, it needs to know where AI is actually being used, what system or technology is involved and, more importantly, what it is being used to do

That sounds obvious. In practice, it may be rather less tidy. AI can arrive through major technology programmes, third-party platforms and software updates, but it can just as easily appear because a useful new feature has been switched on or a team has found a tool that helps them get something done.

A practical inventory is therefore a sensible starting point. But I wouldn't get too hung up on producing the perfect register. What matters is understanding where significant AI use exists, what business process it supports and which decisions or outputs it influences.

Finding it, however, is only the beginning.

There is a more fundamental question to ask: Should AI be used here at all, and if so, what kind of AI use is appropriate?

That decision should begin with the business need. What are we trying to achieve? What information will the AI have access to? What process or decision will it influence? How much reliance are we prepared to place on its output? And does that use call for an open general-purpose tool, an approved enterprise solution, AI embedded within an existing system, or something specifically designed or configured for the purpose?

The business does not need to make those decisions in isolation. Technology, data, security, compliance and other specialists may all have legitimate requirements to bring to the discussion. But the business should be clear about the purpose, the acceptable boundaries and the outcome the AI is expected to support.

Only then does another question become particularly useful: What does this AI influence, and what happens if it gets something wrong?

That changes the exercise from simply identifying AI tools to understanding their significance. An AI tool helping somebody improve an internal document is one thing. A system whose output contributes to a customer decision, sanctions screening, regulatory assessment, financial approval or safety-related process is quite another.

Those distinctions begin to tell us where governance attention is actually needed. The purpose of visibility, then, is not to create another enormous register requiring constant administration. It is to understand where AI is being used, why it is being used, whether that use is appropriate and what matters if we choose to rely upon it.

Not Everything Needs the Same Governance

An AI tool helping someone improve an internal document does not necessarily need the same attention as a system influencing customer acceptance, sanctions screening, regulatory compliance, financial approval or a safety-related decision. Treating them identically would probably create administration rather than control.

I would look first at consequence. What happens if the output is wrong, goes unchallenged or is relied upon when it shouldn't be?

Regulatory significance, customer impact, financial exposure, data sensitivity, degree of automation and the difficulty of detecting an incorrect output may all matter. Different organisations will reasonably reach different conclusions.

The principle is simpler: The level of governance should broadly follow the level of risk and consequence. That allows the greatest attention to be placed where getting it wrong would genuinely matter.

Put Ownership Where Accountability Really Sits

Who owns an AI-enabled process?

It can become an interesting conversation. Is it IT because it manages the technology? Compliance because the AI supports a compliance decision? Procurement because an external provider supplied the system? A data team because organisational data is involved?

All may have legitimate responsibilities. My preference, however, would be to begin with the business process and the decision being influenced, rather than the technology itself.

Somebody needs to be accountable for the outcome the AI is helping to produce.

That person does not need to understand every technical detail. They do need to understand why AI is being used, what it is intended to do, where its important limitations sit, what could go wrong and which controls the organisation is relying upon.

Technology specialists can manage technical matters. Compliance and legal can advise. Risk can challenge. Procurement can manage supplier obligations. All useful. None of them makes business accountability disappear.

A test I would use is: If this produces the wrong result tomorrow, who needs to know and who is expected to act?

If nobody is quite sure, ownership probably deserves another look.

Ownership and Oversight Are Different

Ownership and oversight serve different purposes. The owner is accountable for the process and its outcomes. Oversight provides challenge and asks whether the process continues to behave within acceptable boundaries.

That oversight might come through existing risk committees, compliance functions, technology governance or specialist arrangements. There is no particular virtue in creating another committee simply because AI is involved. Existing structures may be perfectly adequate, provided they have the information, competence and authority to ask awkward questions when necessary.

For me, the test is less about whether the organisation has an AI committee and more about whether somebody with appropriate authority can look at the process and ask: Is this still behaving as we expected, and what gives us confidence that it is?

Build Controls Around the Decision

AI governance can easily become overly technical. Technical performance, cybersecurity, data quality and system integrity matter. But a technically sound system can still contribute to a poor business decision.

From a compliance and risk perspective, I would start with the decision or outcome that AI influences. Think about what could go wrong, what might prevent or detect it, and where somebody needs to step in.

The answers begin to tell you what sensible controls might look like. Depending on the risk, that could include human review, secondary verification, approval requirements, access restrictions, exception reporting or documented override arrangements. The important part is being able to connect a significant risk with a control intended to do something useful about it.

Human Judgement Needs to Be Meaningful

Putting a person somewhere in the workflow does not automatically create effective human oversight. If that person routinely clicks Approve because the "computer says so", the organisation may have human involvement without much human challenge.

I would be more interested in asking: At what point would human judgement actually provide meaningful protection?

For one process, that could mean reviewing every recommendation. For another, people may add far more value by concentrating on exceptions, unusual results or cases above an agreed risk threshold.

The point is not to include a human simply so the governance framework can say somebody was involved. It is to put human experience, judgement and challenge where they genuinely reduce risk.

Escalation follows much the same logic. If the system moves outside expected parameters, produces something unusual or repeatedly requires an override, people should already have a reasonable idea of what happens next. Those decisions are usually easier to make before the problem occurs than in the middle of it.

Evidence Matters

There is a simple question I find useful: If this decision were challenged tomorrow, what would we wish we had kept?

That tends to focus attention rather quickly. Depending on the significance of the process, the answer could include the original assessment, approvals, testing results, significant changes, exceptions, human reviews, overrides, incidents and corrective actions.

The objective is not to preserve everything just in case somebody might want it one day.

It is to retain enough evidence to reconstruct an important decision and demonstrate that the controls we thought were operating actually did.

There is a fundamental difference between saying: “We have a review process.”

and being able to say: “Here is the review that took place.”

That difference tends to become quite important once somebody starts asking questions.

Monitor Exceptions, Not Noise

Controls help manage identified risks.

Monitoring has a different job: it helps us notice when something may be changing.

Depending on the application, that might mean watching unexpected outcomes, increasing exceptions, unusual patterns, repeated human overrides, complaints or changes in performance.

I wouldn't begin by asking what data the system can produce. Most systems can produce plenty of it. I would ask: What would tell us that something important has changed?

That is more likely to produce useful management information than another dashboard full of reassuring green indicators. Monitoring should give people enough visibility to notice when reality is beginning to move away from what they expected. When it does, somebody needs to take a closer look.

Assurance: Test the Confidence

Assurance has a different job again.

Controls manage risk. Monitoring looks for change. Assurance asks whether our confidence in either is justified.

I would look at three things.

First, are the controls actually operating? Is the review, approval or validation activity taking place when it is supposed to?

Then comes the slightly harder question. Are those controls still effective? There is little comfort in performing a control perfectly if it no longer meaningfully reduces the risk it was designed to manage.

And finally, is there sufficient independent challenge?

Management review, compliance monitoring, specialist testing and internal audit may all have a part to play, depending on the significance of the AI use and how the organisation is structured. That does not necessarily mean creating another assurance function.

What matters is maintaining some sensible separation between running the process and deciding that the process is working perfectly. Otherwise, organisations can become very good at assuring themselves.

Give Boards Information They Can Use

Boards do not necessarily need more information about AI. They need better information about the things that matter.

A report showing that thousands of AI-supported activities have been processed successfully may be reassuring. I would be rather more interested in knowing that exceptions have suddenly increased, people are overriding the system more often, an important control has failed, or an unresolved weakness remains from an assurance review.

That is the difference between information about activity and information that helps somebody govern. The Board does not need to understand every algorithm or technical configuration. Nor should we expect it to. It does need enough meaningful information to understand whether significant risks are known, owned, controlled and appropriately challenged.

Bringing It Together

If I were looking for a simple way to think about all of this, I would probably use the following chain:

AI Use → Risk → Owner → Control → Evidence → Oversight → Assurance → Improvement

It is not a regulatory formula, and I certainly wouldn't suggest it is the only way to organise AI governance. It is simply a useful way of following the thinking through.

• AI Use: What are we using and why?

• Risk: What hazards does AI bring, and what are the impacts and likelihoods if realised?

• Owner: Who is accountable for the outcome?

• Control: What are we doing about the risk?

• Evidence: Can we demonstrate that it happened?

• Oversight: Who is watching for change or concern?

• Assurance: How do we know the arrangements work?

• Improvement: What changes when they do not?

None of those is a particularly exotic question, but they are governance questions. AI simply gives us a new context in which we need to answer them.

Try It on One Real Process

There is no need to begin with an organisation-wide transformation programme to find out whether this thinking is useful.

Take one meaningful AI-enabled process. Preferably not the easiest one.

Choose something where an incorrect decision would have consequences that people around the table would genuinely care about. Then follow it through.

Can you see where AI is being used and what it influences? Is the risk reasonably understood? Is there somebody who clearly owns the outcome? Are the controls doing something useful, and can you show that they actually operated? Do you know what is being monitored and what would cause somebody to step in? And is there sufficient challenge to tell you whether the confidence you have in all of this is deserved?

Then ask the slightly uncomfortable final question:

If a regulator, auditor, customer or Board member asked tomorrow, could we put the evidence in front of them with confidence?

If the answer is largely yes, there is probably something worth building upon.

If answering those questions requires several meetings, a hunt through different systems, and somebody eventually saying, “I thought IT dealt with that,” the technology may have matured rather faster than the governance around it.

Ceterus Perspective

There will not be one perfect model for AI governance. The right arrangements will depend on how AI is used, the decisions it influences and the consequences when those decisions are wrong.

Perhaps the encouraging part is that none of this requires us to invent governance again.

We already understand ownership, controls, evidence, escalation, challenge and assurance. We know what good governance is supposed to achieve, even if delivering it consistently is sometimes the more interesting part.

AI changes the technology. It can change the speed, complexity and scale of decision-making, and it may cause us to look again at whether some familiar controls remain fit for purpose. But it does not remove the disciplines upon which good governance has always depended.

AI changes the context. It does not abolish the fundamentals of good governance.