What does practical AI governance look like?

Practical AI governance makes it clear who can use which tools, for what work, with what information and under whose authority. It also defines how outputs are reviewed, how problems are handled and who can change or stop a system. The controls should reflect the consequences of the particular use.

An approved policy is useful when people can apply it to a real decision. Someone preparing an internal draft needs to understand the boundaries. A team introducing an agent that changes records needs a more detailed operating arrangement.

Establish what is being used and why

Start with a straightforward inventory of current and proposed uses. Speak with teams about the work they are trying to improve, including informal experiments. Keep the discussion practical so people can describe what is happening without having to produce a technical specification.

For each use, record:

• The business purpose and accountable owner.
• The product, account or service involved.
• The information it receives and where outputs go.
• Whether it suggests an answer or can take an action.
• Who checks the result and how a problem is reported.

This gives leaders a basis for deciding what can continue, what needs further controls and what should be paused while questions are resolved. It also reveals overlapping purchases and unclear ownership.

Match the controls to the consequences

Assess a use case by considering who could be affected, how an error would be detected and whether an action can be reversed. Include the sensitivity of the information and the scale at which the system will operate.

Consider an illustrative communications process. A person using approved material to prepare an internal draft has a different control need from a service sending personalised messages directly to customers. The latter needs an explicit decision about publishing authority, permitted content, recipient handling and recovery when something fails.

The same tool can be appropriate for one use and unsuitable for another. Product approval should therefore be accompanied by approved uses and limits. Make clear where specialist privacy, security, legal or other review is needed for your circumstances, and who arranges it.

Turn data rules into instructions people can follow

Describe what information can be used in each approved environment. Give recognisable examples and a route for questions. “Use responsibly” does not tell someone whether they can upload a customer spreadsheet or connect a shared document folder.

Review the account, contract, retention arrangements and permissions for the actual implementation. Connecting a tool to company information also requires checking whether existing access is appropriate. A document being accessible today does not establish that everyone with access still needs it.

For a proposed internal assistant, agree the approved source material, the person who maintains it and the groups permitted to use it. Decide how outdated documents are removed and how conflicting guidance is resolved. These are operating responsibilities that continue after launch.

The platform selection guide explains why product editions, data arrangements and connected services need to be assessed separately.

Make human review meaningful

Define what the reviewer is expected to check and give them the information, time and authority to do it. A person approving a draft should be able to inspect its source material, correct it or reject it.

Be precise about when review happens. Reviewing a message before it is sent serves a different purpose from sampling messages afterwards. The appropriate approach depends on the use, the impact of an error and the evidence from testing.

For systems that take actions, establish which actions need approval, what gets recorded and how partial completion is handled. For example, the team needs to know whether retrying a failed step could create a duplicate action. These details belong in the delivery and operating plan.

Give the work clear owners

Identify the business owner who accepts responsibility for the outcome, the person who maintains the workflow and the team responsible for technology access and support. Agree who investigates an incident and who can suspend operation.

One person may hold several responsibilities in a smaller business. The important point is that the responsibilities are understood and someone has the capacity to carry them out. Record decisions about permitted use, remaining limitations and the evidence used to approve introduction.

Staff also need a visible route to raise uncertainty. Include examples in training and make reporting a poor result part of normal operation. A useful report identifies what happened, the task being attempted and what needs attention without spreading sensitive information unnecessarily.

Keep governance connected to change

Set review points around changes that matter: a new information source, a new integration, a different audience or permission to take additional actions. Check whether the original controls still suit the expanded use.

Review observed problems and feedback alongside commercial value and adoption. Where a control creates repeated workarounds, investigate the process and explain any adjustment to the people affected.

My governance and ownership work helps turn these decisions into practical guidance, accountable roles and an operating review process suited to the business.