A practical starting point for organisations looking to bring more visibility, ownership and control to AI adoption.
AI governance is one of those things that sounds straightforward until you try to put it into practice.
Most organisations understand the principle. AI needs appropriate policies and controls. Data needs to be protected. Risks need to be understood. Roles and responsibilities need to be clear. None of that is particularly controversial.
The harder question is what that means on a Tuesday morning, when someone has found a new AI tool that solves a problem, a software vendor has quietly introduced an AI feature into a platform you already use, or a team wants to move an AI experiment into production.
That’s where governance stops being a policy exercise and becomes an operational one.
So, if your organisation knows it needs to get a better handle on AI governance but isn’t sure where to start, there are some practical questions worth asking first.
Before you can govern AI, you need to understand where it already exists across the organisation. And the answer is likely to be broader than you think.
There are the obvious tools: ChatGPT, Microsoft Copilot, Claude and other generative AI applications being used by employees. But there’s also AI embedded within software you already pay for. Vendors are adding AI capabilities rapidly, sometimes enabling new functionality as part of routine product updates.
Then there are internal AI solutions being developed by technology teams, agents and automation built using platforms such as Azure AI Foundry or Amazon Bedrock, and potentially AI embedded within the products or services you provide to customers.
It’s also worth asking what people are experimenting with, not just what has formally gone live.
The objective at this stage isn’t to shut things down. It’s visibility. Until you know where AI is being used, you can’t make sensible decisions about the risks, controls or opportunities associated with it.
Trying to create a rule for every possible AI scenario is unlikely to work. The technology is moving too quickly and the use cases are too varied. Clear boundaries are far more useful.
What information should never be entered into an unapproved AI service? Are there decisions about people that should always involve meaningful human judgement? Are there particular types of AI use that require additional review before they proceed?
These are partly risk and compliance questions, but they’re also questions about organisational values.
The important thing is to make some of those decisions before a live project forces the issue. Bright lines are much easier to establish when you’re discussing a principle than when a team has already spent three months building something.
One of the easiest traps with AI governance is allowing responsibility to default to the technology team.
Technology absolutely has a role to play. But AI risk can involve privacy, security, customer experience, employment, reputation and commercial decision-making. Those aren’t technology decisions alone.
Each meaningful AI use case should have someone accountable for the business outcome and able to understand the risks associated with it. Ownership also needs to mean more than having a name in a spreadsheet.
Who has the authority to make decisions about the use case? Who decides whether the level of risk is acceptable? Who is accountable if something changes?
Those questions matter much more than which team happens to operate the underlying technology.
If there is one part of AI governance worth getting particularly curious about, it’s data.
What information is going into an AI system? Where does that information go? Where is it stored? Who can access it? Can the provider use it to train or improve its models? How long is it retained? And who within your organisation is responsible for managing that access?
Some of those answers may be straightforward. Others may take more investigation than expected.
AI has made it remarkably easy to move information between systems and services. That convenience is part of its value, but it also makes understanding the movement and ownership of data increasingly important.
Governance doesn’t have to mean turning every AI experiment into a committee meeting. In fact, making the process too cumbersome can have the opposite effect: people simply work around it.
A better approach is to be clear about what requires approval and what doesn’t. Low-risk experimentation with approved tools may need very little oversight. A customer-facing AI solution using sensitive information should attract considerably more scrutiny.
The questions themselves don’t need to be complicated. Who can approve an AI use case? What information do they need before making that decision? What level of risk requires wider review? And does the same thinking apply while something is being developed, not just when it goes into production?
The goal is proportionate governance: enough structure to make good decisions without creating unnecessary friction.
A surprising amount of technology governance focuses on getting something approved and into production. With AI, what happens afterwards can be just as important.
Models change. Data changes. Software vendors change their services. Integrations change. Organisational policies change.
So who keeps the solution operating safely? Who monitors it? Who understands its dependencies? Who knows what data it relies on? And if something changes six months after launch, who decides whether the original risk assessment still holds?
Support and ongoing ownership should be part of the conversation when an AI use case is designed, not something worked out once it’s already live.
For many organisations, much of their AI exposure won’t come from sophisticated internal AI projects. It will arrive through suppliers.
AI is increasingly embedded within CRM platforms, productivity suites, security products, contact centre systems, marketing platforms and countless other SaaS applications.
That introduces another set of questions. What does your agreement with the supplier say about the use and retention of your data? Can your information be used for model training? Where is it processed? What happens when the vendor introduces new AI functionality? Who is responsible for reviewing those changes?
Third-party risk isn’t new. AI simply gives organisations another reason to understand it properly.
AI governance can quickly become a conversation about standards, maturity models, certification and lengthy policy documents. Those things may become relevant as an organisation’s AI capability develops, but they don’t have to be the starting point.
A useful first step is much simpler: know what AI is being used, understand the data involved, agree some clear boundaries, give meaningful use cases an accountable owner, establish how new uses will be assessed, and make sure somebody is responsible for what happens after an AI solution goes live.
Good AI governance shouldn’t exist to stop people using AI. Done well, it creates enough visibility, ownership and clarity for people to explore what AI can do without every decision becoming a leap into the unknown.
You don’t need perfect governance from day one. You need a sensible foundation that can evolve as your organisation’s use of AI does.
If you’re working through what AI governance should look like in practice, our team can help you make sense of the technology, risks and operational considerations involved. Talk to us about where to start >