How to Actually Implement AI Governance (Without Paralyzing Your Organization)


Introduction

Earlier this week, I wrote about AI capability developing faster than many organisations’ ability to control it. The natural question is: What should organisations actually do about it?

The answer is not to stop AI, but to govern it according to its risk. A writing assistant should not require the same controls as a system that recommends prices, changes business data or acts independently.

From my experience with AI-supported pricing and process automation, building the tool is often the easy part. The real challenge is defining its boundaries, ownership and human oversight.

Practical AI governance starts before deployment—not after something goes wrong.


1. Stop Treating Speed and Safety as Opposites

AI governance is often presented as a choice between innovation and control.

One side wants to move quickly. The other wants more review, documentation and safeguards. The result can become an unproductive debate: either governance slows innovation, or innovation must accept greater risk.

This is the wrong framing.

The real objective is to move at a speed appropriate to the risk.

Using AI to improve the wording of an internal email does not require the same controls as allowing AI to publish customer prices. Analysing an SAP export is different from modifying SAP master data. Preparing a recommendation is different from executing it.

When every AI use is forced through the same heavy approval process, employees may work around governance or abandon useful ideas. When every use is treated as harmless experimentation, the organisation can expose its data, customers and financial results to unnecessary risk.

Good governance creates different lanes. Low-risk uses can move quickly. Higher-risk uses receive stronger controls.

The objective is not maximum control. It is the right level of control for the possible consequence.

2. Start With the Decision, Not the Technology

Before asking what an AI tool can do, leaders should clarify the business decision or action it will support.

For each use case, ask:

  • What task is being performed?

  • Who is affected by the result?

  • What data does the system need?

  • Is the output advice, a recommendation or an action?

  • What could happen if the result is wrong?

  • Can the action be reversed?

This turns a vague discussion about “AI risk” into a practical business assessment.

A useful model is to classify AI use into four levels:

Assist

AI drafts, summarises, reformats or analyses. A person decides whether and how to use the result.

Recommend

AI proposes a business decision and provides supporting evidence. An accountable person approves or rejects it.

Execute With Approval

AI prepares an action, but the action cannot be completed until an authorised person approves it.

Execute Autonomously

AI acts without individual approval, but only within strict permissions, limits and monitoring.

As the system moves from assisting to acting, governance should become stronger.

This simple distinction prevents a common mistake: applying the trust given to a writing assistant to a system capable of changing prices, contacting customers or updating operational data.

3. Define the Boundaries Before Deployment

Once the risk level is clear, the organisation should define the system’s boundaries in plain business language.

What May It Do?

Avoid broad statements such as “optimise pricing.” Be precise.

For example:

The system may analyse approved source data, calculate price scenarios and recommend changes. It may not publish or upload prices independently.

What May It Not Do?

Identify the hard stops.

Can the system override a customer agreement? Can it use unverified market information? Can it change a price beyond an agreed percentage? Can it contact a customer without approval?

Who May Use It?

Access is not the same as authority.

An employee may be allowed to view a recommendation without being authorised to approve or execute it.

What Requires Escalation?

Define the conditions that require specialist review.

These might include large price movements, missing costs, weak market comparisons, strategic customers, unusual margin changes or conflicting source data.

What Happens When Information Is Missing?

The safest response is sometimes to stop.

A system should not invent a confident answer simply because the workflow expects one.

These rules should be agreed before the tool becomes operational. Discovering the boundaries one incident at a time is not governance; it is reaction.

4. Build Governance Into the Workflow

Governance works best when it is part of the process rather than an additional document sitting beside it.

In a pricing workflow, for example, AI might clean data, identify anomalies, organise market evidence and prepare recommendations. Transparent calculations can then apply the agreed cost factors, freight, markup and margin rules.

The workflow can route only the important exceptions to a pricing specialist.

This is more effective than requiring someone to review every line manually.

If an employee receives 1,000 AI-generated recommendations, an approval button does not guarantee meaningful oversight. Under time pressure, the person may check a few examples and accept the rest.

Human involvement then exists in theory but not in practice.

Exception-based review is more realistic. It directs attention towards cases involving:

  • High revenue or margin exposure

  • Large or unusual proposed changes

  • Missing or conflicting data

  • Customer-specific agreements

  • Weak market evidence

  • Low-confidence recommendations

  • Irreversible or customer-facing actions

Routine cases can move within agreed limits. Important exceptions receive real human judgment.

The purpose of oversight is not to place a person in every step. It is to place accountable human attention where a mistake would matter most.

5. Keep Important Calculations Deterministic

Not every part of an AI-supported process should be left to AI.

Where a calculation must be consistent, it should follow a visible and testable business rule.

Purchase cost, internal cost factors, freight, markup, gross margin and rounding logic should not change because a model interprets the prompt differently on another day.

AI is valuable when the work requires interpretation: finding patterns, summarising evidence, identifying exceptions or explaining possible causes.

Controlled formulas are better when the work requires mathematical consistency.

In practice, the strongest design is often a combination:

  1. Verified systems provide the source data.

  2. Deterministic rules perform the financial calculations.

  3. AI organises the evidence and identifies unusual cases.

  4. A person reviews decisions above the agreed threshold.

  5. The approved output moves to the operational system.

This division makes the workflow easier to test, explain and trust.

6. Make Accountability Visible

One of the weakest forms of governance is widely distributed responsibility.

IT implements the tool. The business provides the requirements. Legal reviews the terms. Information security approves access. Employees use the output.

But who owns the result?

Every important AI application needs a named business owner.

That person does not need to build the technology or approve every individual decision. However, they should be accountable for whether the system remains appropriate for its intended use.

The owner should know:

  • What outcome the system is expected to improve

  • Which data and permissions it uses

  • Which decisions require approval

  • How performance and exceptions are monitored

  • Who can pause or disable the process

  • What happens when the system is wrong

  • Whether the benefits still justify the risk and control cost

Technical responsibility can be shared. Accountability for the business outcome cannot disappear into a committee.

AI cannot accept responsibility for lost margin, an incorrect customer price or damage to a commercial relationship. The people who authorise its use remain accountable.

7. Measure Outcomes, Not Just Adoption

Many organisations measure AI progress through licences, active users, prompts or training completion.

These figures show activity. They do not prove value.

A well-governed AI process should be measured against the reason it was introduced.

For a pricing or operational workflow, useful measures might include:

  • Processing time saved

  • Reduction in manual errors and rework

  • Number of meaningful exceptions detected

  • Price and margin consistency

  • Quality of market comparisons

  • Percentage of recommendations changed by specialists

  • Customer or commercial impact after implementation

  • Incidents, near misses and unauthorised actions

  • Time and cost required for governance

Governance itself should also be tested.

Are approval thresholds identifying the right cases? Are employees genuinely reviewing exceptions? Are alerts useful, or are there so many that people ignore them? Are controls preventing problems or simply creating delays?

The goal is not to prove that governance exists. It is to determine whether it works.

8. Review and Adjust the Controls

AI governance should not be designed once and left unchanged.

A new system may begin with narrow permissions and close supervision. If evidence shows that it performs reliably, some controls may be relaxed. If new risks or failure patterns appear, controls may need to become stronger.

A regular review should ask:

  • Is the use case still the same?

  • Has the system gained new capabilities or access?

  • Have the data sources changed?

  • Which recommendations were overridden, and why?

  • Have any incidents or near misses occurred?

  • Are the approval limits still appropriate?

  • Is the process creating measurable value?

  • Are the controls proportionate, or have they become a bottleneck?

This approach avoids two extremes: permanent restrictions based on early uncertainty and permanent trust based on early success.

Governance should learn from operational evidence.

9. What I Do Differently Now

Working with AI on pricing analysis, data preparation and business-process tools has changed how I think about implementation.

I no longer begin only with the question:

“Can AI do this?”

I also ask:

  • What could go wrong?

  • How serious would the consequence be?

  • Which part should use AI, and which part should remain rule-based?

  • What evidence should appear beside the recommendation?

  • Which cases require human judgment?

  • Who owns the final outcome?

  • How will we know whether the process is working?

This does not make AI adoption slower. It makes the purpose clearer.

For example, AI can help identify unusual price movements or prepare a market comparison. But the system should not independently decide whether two materials are technically equivalent, override an agreed customer condition or upload a significant price change without the appropriate review.

The important question is not whether humans or AI should make the decision.

It is how the workflow should combine data, controlled rules, AI capability and human accountability.

10. A Practical Minimum Governance Framework

An organisation does not need to begin with a large committee or a complicated policy manual.

For each meaningful AI use case, start with one page answering eight questions:

  1. What is the intended business outcome?

  2. What level of risk does the use case carry?

  3. Which data may the system access?

  4. What may it recommend or execute?

  5. Which boundaries cannot be crossed?

  6. What triggers human review or escalation?

  7. Who owns the outcome?

  8. How will performance, incidents and value be measured?

That one page will not solve every governance issue. But it creates something many AI projects lack: shared clarity.

More detailed controls can then be added where the level of risk justifies them.

Final Thought

AI governance should not mean stopping AI.

It should create the conditions in which an organisation can use AI with confidence, appropriate speed and clear accountability.

The strongest approach is neither extremely light nor unnecessarily heavy. It is proportional.

Low-risk assistance should remain easy to use. Recommendations affecting important business decisions should include traceable evidence. High-impact actions should require approval. Autonomous activity should operate only within strict permissions, limits and monitoring.

Good governance is not a policy sitting beside the work. It is the way the work is designed.

It defines what the system may do, directs human attention towards meaningful exceptions, preserves accountability and measures whether AI is producing a better outcome.

The time to build these controls is not after something goes wrong.

It is while the organisation can still decide—calmly and deliberately—how much authority it is prepared to give AI.


Add comment

Comments

There are no comments yet.