Tag: AI Governance

There is a meaningful difference between saying "we are using AI" and being able to say "our business can use AI safely, consistently, and profitably." Most organisations are somewhere in the first camp. Fewer are genuinely in the second. That gap is where the real risk sits.

AI readiness and AI adoption are not the same thing, and conflating them is one of the more expensive mistakes a leadership team can make. Adoption is specific: it means AI is running in real workflows, improving real outcomes, and being measured against real targets. Readiness is the underlying organisational capability that makes adoption stable, scalable, and not quietly catastrophic. You need both. But the order matters, and so does understanding what each actually requires.

What adoption looks like, and what it does not

Adoption, properly defined, is an AI use case in production. It is a customer service process that routes queries more intelligently, a finance team using AI to accelerate period close, a sales function with AI-assisted next-best-action prompts embedded in its CRM. The use case is live. It is integrated into a system of record. There is a defined handoff between the AI output and a human decision. Someone is measuring whether it is working.

What adoption is not: a ChatGPT subscription used sporadically by three people in marketing. A Copilot licence issued to the whole organisation with no change to how work is structured. A pilot that ran six months ago and produced a slide deck that no one has acted on.

That last one is common enough to have become a genre.

The DSIT AI Adoption Research for 2025/26 puts formal AI deployment at around 16% of UK businesses. The British Chambers of Commerce and Atos, using a broader definition that includes AI features embedded in existing tools, put active AI use at 54% of UK firms. Both figures can be true simultaneously. The gap between them is largely the gap between adoption and the appearance of adoption.

What readiness actually requires

Readiness is not a checklist item. It is the set of foundations that determine whether an AI use case, once deployed, will deliver consistent value or unravel inside six months.

There are eight things that matter here, and I would resist the urge to treat any of them as optional.

Strategy alignment

The AI initiative can be tied to a specific business outcome: revenue, cost, risk reduction, or customer experience. If someone in the meeting cannot articulate that connection clearly, the initiative is probably theatre.

Data quality and access

This is where most organisations discover how unprepared they actually are. AI systems are not intelligent about bad inputs. They process what you give them, at scale, with confidence. A governance structure for data, including lineage, retention standards, and documented ownership, is not a technical nicety. It is the load-bearing wall.

Architecture and tooling

This covers the question of whether your infrastructure can actually support what you are trying to do: secure data platforms, the ability to manage model versions over time, sensible integration patterns, and a vendor strategy that does not accidentally concentrate all your risk in one provider who changes their pricing in eighteen months.

Governance and risk

This is the policy layer. Who has approved this use case? How is the model tested before it goes live? Where does a human sit in the loop, and when can they override? How is the output auditable? These are not regulatory box-ticking questions. They are the questions a board should be asking before something goes wrong rather than after.

Security and privacy

This deserves its own line because it is frequently underweighted. Prompts are data. Fine-tuning datasets are data. Outputs can contain data. The question of what you are feeding into a model, where that model runs, who can access the outputs, and what your exposure is to third-party model risk is not a question to defer to the IT team and forget about.

Employee capability

This is role-specific. General AI awareness training is useful. What is more useful is training designed around how a particular role will interact with AI in practice, who is responsible for reviewing outputs, and what the escalation path looks like when something does not look right. Change leadership matters here too. Someone needs to own the human side of the transition, and it is rarely the same person who owns the technology.

Operating model

This means cross-functional ownership, a clear intake and prioritisation process for AI initiatives, and a funding model that does not require a new business case every time someone wants to run an experiment.

Measurement

This is the last pillar and probably the most neglected. You need a baseline before deployment, a clear target outcome, and a way to track whether the use case is performing, drifting, or creating unintended consequences over time.

How to move from pilots to something that actually scales

The failure mode most organisations hit after a successful pilot is assuming the pilot's success means the organisation is ready to scale. It usually does not.

Scaling requires three things that pilots rarely test. First, workflow redesign: the process around the AI needs to be rebuilt, not just augmented. Embedding AI into an existing broken process produces a faster broken process. Second, a reusable component and playbook approach, so that the second and third use cases do not require a full rebuild from scratch. Third, a measurement framework that tracks not just whether the model is producing outputs, but whether those outputs are being used, trusted, and acted on correctly by the people whose jobs now depend on them.

The cycle time reduction, conversion rate improvement, or cost per unit change you are targeting needs to be connected to an actual decision cycle. If the AI is generating a recommendation that no one acts on for three weeks, the efficiency gain exists only in a presentation.

Where your business should actually use AI

Prioritise at the intersection of three things: value potential, technical and data feasibility, and risk level. High-value, low-risk, and data-ready is where to start. Obvious enough in principle, but harder in practice because most organisations do not have a clear view of all three simultaneously.

The domains where AI tends to generate genuine, measurable returns for mid-sized organisations are worth naming directly:

• Customer experience and sales: personalisation, assisted service, and next-best-action recommendations where the data to drive them already exists.
• Operations: intelligent routing, forecasting, document processing, and quality control where repetitive structured tasks are consuming skilled time.
• Back office: finance close processes, procurement insight, and IT service management where volume and repetition are the enemy of human attention.
• Knowledge management and internal search, which is unglamorous but often where the first real productivity gains appear, because it does not require complex model development and the latent value in trapped institutional knowledge is usually significant.

What to avoid in the short term: use cases where the decision stakes are high, the data is thin, and the regulatory exposure is unclear. Not because AI cannot eventually help there, but because getting it wrong in that territory is more expensive than waiting six months.

The hidden cost of adopting without a strategy

Ad hoc AI adoption has a bill that arrives later. It arrives in several currencies.

Model and vendor sprawl is the first one. Uncoordinated adoption across teams produces a fragmented landscape of overlapping tools, duplicative spend, and integration debt that someone will eventually have to untangle. Vendor lock-in tends to arrive before anyone noticed they were being locked in.

Data leakage and intellectual property exposure is the second. If your team is pasting client information, commercially sensitive analysis, or proprietary process documentation into a general-purpose AI tool with no clear understanding of how that data is handled, that is not a theoretical risk. It is a live one. Regulatory penalties, depending on the data involved and the jurisdictions your business operates in, are a realistic downstream consequence.

Shadow IT and brittle integrations. When teams adopt AI tools independently because the official route is too slow, those integrations tend to be fragile, undocumented, and invisible to anyone responsible for security or continuity. The first you may know about them is when one breaks.

User distrust is less obvious but genuinely costly. Poorly designed AI workflows create friction, generate outputs that confuse rather than assist, and produce the peculiarly demoralising experience of having a tool that is supposed to help make your working day harder. Once a team has decided an AI tool does not work, rebuilding that trust is slow.

And the inability to audit or explain outcomes. In regulated environments, or in any client-facing context where someone asks "how did you arrive at this," a model that cannot be explained is a liability, not an asset.

The questions a board should be asking

I am not suggesting this list as a performance exercise or a slide to circulate. These are genuinely the questions that separate organisations building durable AI capability from those accumulating expensive technical debt with a good narrative attached.

• What are our top three AI value pools this year, and how are they measured? How do our current AI initiatives connect to core strategy and to the budget that funds them? What is our readiness baseline across data, technology, people, and governance, and has anyone actually assessed it rather than assumed it?
• What is our policy for responsible AI, and is that policy enforced in tooling and process, or does it exist only in a document? How are we protecting sensitive data and intellectual property across prompts, fine-tuning inputs, and model outputs? What controls exist for third-party model risk, and does our vendor strategy address concentration and lock-in?
• How do we validate model performance, fairness, and security before a use case goes live, and how do we monitor it after? Where are humans in the loop, and when can they override? What is the training plan by role, not by organisation?
• How do we track return on investment, adoption rates, and risk incidents at portfolio level, not just use case by use case? What is the escalation path if an AI-dependent workflow fails or a breach occurs? What does our 90, 180, and 365-day roadmap from pilots to scaled platforms actually say, and does it have an owner?
• Which capabilities should we build internally and which should we buy, and has anyone made that argument with evidence rather than preference? How are we engaging with regulators and auditors proactively, particularly for businesses with EU exposure now that AI Act transparency obligations are operational? And perhaps most practically: if our most AI-dependent workflow failed tomorrow, what is the recovery plan?

These are not trick questions. They are the basic governance questions that any responsible board should be able to answer. If several of them produce a pause or a redirect to someone who is not in the room, that tells you something about where the readiness work actually is.

Treat AI as an organisational capability, not a tool. Build readiness to de-risk and scale. Drive focused adoption to capture value you can actually measure.

The two are not in tension. They are sequential. Getting the order right is most of the job.

The temptation, when everyone around you seems to be adopting AI, is to start with a product. Pick a tool, book a demonstration, run a pilot, announce progress. It feels like momentum. It usually isn't.

Most AI projects that disappoint do not fail because the technology was wrong. They fail because the conditions needed to make any technology work were never in place to begin with. The tool arrives into an organisation that was not ready for it, and no amount of capability in the software compensates for that.

What follows is a list of the most common reasons AI initiatives stall before they have properly started. None of these are exotic failure modes. Most of them come up in the first conversation.

Starting with a tool rather than a business problem

This is the most common mistake, and it sets everything else in motion. A leader attends a demonstration, sees something impressive, and the question becomes: "Where could we use this?" That is the wrong question, and it produces the wrong answer almost every time.

The right starting point is a specific business problem with a measurable cost. Not "we could automate some of our admin" but "our finance team spends roughly two days a week manually consolidating data from three systems, and errors from that process caused three client billing disputes last quarter." From that description, you can evaluate whether AI is the right solution, what it would actually need to do, and how you would know whether it had worked.

Starting with the tool reverses this logic. You end up asking whether the tool fits the organisation rather than whether the organisation has a problem the tool can solve. Those are very different questions, and only one of them leads anywhere useful.

The business question always comes before the technology question. If you cannot name the problem, the cost of the problem, and the measurable outcome you want, you are not ready to evaluate a tool.

Underestimating data quality

AI systems are, at their core, pattern recognition engines. They find structure in data and use that structure to produce outputs: summaries, predictions, recommendations, classifications, drafts. The quality of the output is directly constrained by the quality of the data going in.

This is where a lot of organisations get an unpleasant surprise. They assume their data is broadly usable because it exists in a system. In practice, data that has been entered inconsistently over several years, across multiple people, with varying conventions and occasional gaps, is not clean enough to support reliable AI outputs.

Consider a business trying to use AI to predict which customers are most likely to churn. If the customer records in their CRM contain duplicate entries, missing contract dates, inconsistent industry classifications and a mixture of active and lapsed accounts that have never been properly separated, the prediction the AI produces will reflect all of that. It will not warn you that the inputs were unreliable. It will produce a confident-looking output regardless.

Fixing data quality is unglamorous work. It involves auditing what you have, identifying what is missing or inconsistent, deciding on standards, and cleaning or remapping records. That process takes time and usually surfaces uncomfortable truths about how data has been managed historically. Most organisations skip it because they are eager to get to the interesting part. The interesting part then does not work, and no one is quite sure why.

Sort the data before selecting the model. That order is not optional.

Having no clear owner for the AI initiative

Successful AI adoption requires someone with accountability, authority, and enough understanding of both the business and the technology to hold the two together. In many organisations attempting AI projects, that person does not exist.

What typically happens instead is that the initiative sits somewhere between IT and operations, with each assuming the other is leading. Decisions about data access, process change, user training and governance get deferred because no one has been given authority to make them. The project moves slowly or not at all, and when it stalls, there is genuine confusion about whose problem that is.

An AI initiative needs an owner who can answer three questions without escalating: what are we trying to achieve, what would need to change across people, processes and systems to achieve it, and how will we know it has worked? That person does not need to be an AI specialist. They need to understand the business problem and be trusted to make decisions. The technical knowledge can be sourced. The authority and accountability cannot.

Skipping governance until something goes wrong

Governance is the part of an AI project that feels like administration until it suddenly feels like a crisis.

The governance questions are not abstract. Who has approved what this system can do? What happens when it produces an output that is wrong, harmful or that a customer disputes? Who reviews edge cases? Where is the human in the loop, and at what point? How will the organisation know if the system's behaviour drifts over time?

These are not questions for the technology team alone. They are business decisions with legal, operational and reputational implications. Leaving them until something goes wrong means making them under pressure, without a framework, and probably in public.

This matters more now that UK businesses deploying AI into customer-facing services are operating under increasing scrutiny, even without a standalone UK AI Act. And businesses whose AI systems affect EU customers are already subject to transparency requirements under the EU AI Act that came into force in August 2026. Neither of those facts changes what good governance looks like, but they do raise the cost of not having it.

Governance is not a compliance checkbox. It is the thing that stops a useful tool from becoming a liability.

Confusing a demonstration with a viable use case

Vendor demonstrations are, almost by design, best-case scenarios. The data is clean, the use case has been selected because it showcases the product well, and the person running the session knows exactly which buttons to press and which ones to avoid.

Watching a demonstration and concluding that the tool will work in your organisation is like watching a professional chef make pasta in twenty minutes on television and assuming you can replicate it in your kitchen the first time. You probably can, eventually. But there is a lot between the demonstration and the result that the programme does not show you.

A demonstration tells you what the technology is theoretically capable of. It does not tell you whether your data is compatible, whether your processes are structured in a way the tool can support, whether your team will actually use it, or whether the licensing and integration costs make it commercially viable at your scale.

Before moving from demonstration to decision, it is worth asking the vendor to show the tool working on a sample of your actual data, in something closer to your actual workflow. The response to that request is usually informative.

Expecting AI to fix a broken process

If a process is producing bad outcomes because it is poorly designed, AI applied to that process will produce bad outcomes faster and at greater scale.

This is perhaps the most expensive misunderstanding in AI adoption. The logic runs something like: "This process is slow and error-prone. AI could automate it." That is sometimes true. But the speed and the errors are often symptoms of a process that was not well designed in the first place, built incrementally around workarounds, exceptions and institutional knowledge that was never properly documented.

Automating a broken process does not fix it. It embeds the dysfunction, removes the human intervention points that were catching errors before they became serious, and makes the problems harder to see because they are now happening inside a system rather than between people.

The right sequence is: understand the process, identify where it fails and why, redesign it, then ask whether automation adds value to the redesigned version. Skipping the first three steps and going straight to automation is a route to a faster, more expensive version of the original problem.

A business I am aware of went through exactly this when attempting to automate a customer onboarding process that had been generating complaints. The automation was technically functional. The complaints continued, because the underlying issue was in how requirements were captured from customers at the start of the process, not in the manual steps the AI replaced. The lesson cost more than the original complaints.

Automation accelerates whatever it touches. Make sure what it is touching is worth accelerating.

What actually works

The businesses that get genuine value from AI are not necessarily the ones that move fastest. They are the ones that start with a real problem, check whether their data can support a solution, put someone accountable in charge, build governance before they need it, test assumptions against reality rather than demonstrations, and fix the process before they automate it.

None of that is technically demanding. Most of it is just disciplined thinking applied before money is spent.

If you are feeling pressure to adopt AI and are not yet clear on which of these conditions you have in place, that is probably the more useful question to start with.

There comes a point in August when even the most committed executive should be allowed to stop thinking about artificial intelligence, cyber risk, geopolitical volatility, agent orchestration and whether the latest enterprise software subscription really needs another £37 per user per month.

Unfortunately, we are not quite there yet.

Before switching on the out-of-office message, there is value in taking stock of where AI and business actually stand in mid-2026. Not where the conference keynote says we are going. Not where the vendor demonstration suggests we will be by next Thursday. And certainly not where somebody's suspiciously enthusiastic LinkedIn carousel says we already are.

The picture emerging from recent research is considerably more interesting. AI is becoming more capable, cheaper to deploy in some areas and increasingly autonomous. At the same time, its costs are becoming harder to predict, its cyberattack surface is expanding, boards are demanding clearer returns, and the competitive advantage is moving away from simply possessing AI towards integrating it intelligently into the organisation. The technology is advancing. The harder question is whether the business around it is advancing at the same speed. That is the subject worth considering before we all disappear somewhere sunny.

We have moved beyond “Do we need AI?”

One of the clearest signals comes from Gartner's 2026 CEO research.

Growth remains the dominant strategic priority, cited among the top three priorities by 52% of surveyed CEOs, while technology has risen to 36%. Gartner notes that the increase in technology prioritisation is being driven overwhelmingly by AI. More strikingly, 39% of CEOs surveyed in one wave already said they regard AI agents as employees. Respondents estimated that by 2030 an average of 19.9% of revenue could originate from AI agents or machine customers rather than human customers.

That is quite a leap from asking ChatGPT to improve an email.

Gartner describes the transition as the emergence of the “autonomous business”: an organisation in which AI does not merely assist employees but increasingly participates in operational processes, decisions, transactions and value creation. Importantly, Gartner argues that this transformation requires balance between machine autonomy and human autonomy rather than replacing one with the other. The important threshold then is not when AI becomes clever enough to write something useful. It is when AI gains permission to do something consequential.

Drafting a payment instruction is assistance. Sending the payment is agency.

Recommending a customer discount is assistance. Changing the price in the CRM is agency.

Finding a vulnerability is assistance. Deploying a remediation into production is agency.

Once you cross that boundary, governance is no longer an optional policy document lurking somewhere in SharePoint. It becomes architecture.

Agentic systems can continuously maintain information baselines, monitor indicators, test scenarios and challenge assumptions, while human practitioners retain responsibility for framing, interpretation and decision ownership. That is an excellent model for commercial organisations too. The objective should not be “maximum autonomy.”

It should be maximum useful autonomy within deliberate authority boundaries.

There is a difference.

And then there is cybersecurity

This is where the summer reading becomes noticeably less relaxing.

The 2026 Verizon Data Breach Investigations Report says ransomware featured in 48% of breaches in its dataset, up from 44%. Use of stolen credentials appeared in 36%, while exploitation of vulnerabilities doubled from 18% to 32%. Third-party involvement also reached 48% of breaches, representing a 60% increase over the previous dataset.

For smaller companies the picture deserves particular attention.

Verizon's analysis found that, among ransomware cases where company size was known, around 96% of victims were SMBs. Compromised credentials and exposed vulnerabilities were major contributors. Its separate 2026 Breach Impact Study suggests extreme cyber losses for SMBs can exceed 7% of annual revenue. Ransomware represented 39% of SMB claims in the dataset and business email compromise another 19%.

That is not an “IT issue”.

Seven percent of revenue has a habit of getting the CFO's attention.

CrowdStrike's ransomware survey adds another uncomfortable finding. Of 1,100 IT and cyber decision-makers surveyed, 78% said their organisation had experienced ransomware during the preceding year. Half of those attacked had considered themselves “very well prepared,” yet only 22% recovered within 24 hours.

This is a useful reminder of the difference between having controls and having resilience.

CrowdStrike also reports that 82% of respondents believe generative AI makes phishing harder to identify even for well-trained employees.

Attackers are gaining automation too.

CrowdStrike reports an 89% year-on-year increase in attacks by AI-enabled adversaries observed during 2025 and a 42% increase in zero-day vulnerabilities exploited before public disclosure. The report argues that AI is compressing the interval between vulnerability discovery and exploitation, which makes slow, periodic remediation increasingly inadequate.

The point is not that your encryption will be broken by lunchtime. It is that AI is beginning to accelerate highly specialised technical work.

That applies to defenders. It also applies to attackers.

Welcome to the productivity revolution.

AI agents also create their own attack surface

Traditional cyber controls were designed around users, applications, networks and endpoints. Now add autonomous software capable of accessing files, invoking tools, calling APIs, running commands, generating code and communicating with external systems. What could possibly go wrong?

Organisations first need visibility into which agents, LLM runtimes, development tools and AI applications are actually operating across the estate. Then you could start by controlling permissions, monitoring runtime activity, inspecting prompt interactions and extending protection across endpoint, browser, SaaS and cloud environments.

Whatever vendor technology you use, the architectural principle is sound. An AI inventory is becoming as necessary as a software or asset inventory. For each important agent, businesses should know:

• who owns it;
• which models it calls;
• which data it can read;
• what it can write or change;
• which systems and APIs it can invoke;
• what credentials it holds;
• which decisions require approval;
• where its activity is logged;
• what happens when it behaves unexpectedly;
• and how quickly it can be disabled.

If nobody can answer those questions, you do not have an AI agent.

You have an intern with the master password.

Humans are not the legacy component

AI's “two cost curves” provide an important warning against reducing AI strategy to technology economics.

One cost curve is obvious: licences, models, infrastructure, security, compute and integration. The second cost curve is human capability.

A company may automate work and reduce headcount, only to discover that it has also removed product knowledge, relationships, judgement, leadership capability and institutional memory. Gartner identifies precisely the same tension. CEOs want automation while simultaneously describing people as essential to resilience. Its research warns that enterprises cannot simply cut their way towards autonomous business and will need to preserve high-value human roles while automating transactional work. People frequently disengage because of poor management long before they formally leave a company. If businesses introduce AI badly, i.e. without context, development, psychological safety or clarity about changing roles. Then they may create the very capability loss they are hoping technology will solve.

There is an organisational-design lesson here.

Use AI to remove work that makes good people able to do the valuable things better or more of it.

Do not use AI in ways that make good people feel less valued.

Those are very different strategies.

And there is a marketing lesson too.

AI makes competent marketing content increasingly cheap, generic corporate communication becomes easier for everyone to produce. Human credibility, distinctive expertise, personality and trust therefore become more valuable. In other words, the same technology that lets you automate more of your communications may make it more important that customers occasionally encounter an actual human being.

That is wonderfully inconvenient.

So what should your AI stack look like when you return from holiday?

For most SMEs and mid-sized organisations, I would resist the urge to build a sprawling “AI ecosystem”.

Instead, build a controlled stack around seven layers:

1. Business outcomes. Choose a small number of growth, margin, customer or resilience problems worth solving.
2. Trusted data. Improve the quality, ownership and accessibility of the information AI needs.
3. Model choice and routing. Avoid unnecessary dependence on one model. Match capability and cost to the task.
4. Workflow and agents. Integrate AI into processes rather than leaving it as an isolated chat window.
5. Authority and governance. Separate recommendation from execution. Define where humans remain accountable.
6. Security and observability. Inventory AI, restrict permissions, monitor activity and assume agents can become attack paths.
7. Value measurement. Measure revenue, cost, cycle time, quality, conversion, customer experience or risk reduction—not merely prompts generated or hours “saved”.

Then add an eighth layer that is easy to forget:

People.

Someone still needs to decide what success means. AI is not a substitute for strategic thinkers but as a mechanism for keeping evidence, scenarios and indicators continuously updated so that humans can spend more time interpreting them. That is an attractive model for almost any leadership team. AI should reduce the amount of organisational energy spent gathering information and increase the amount available for making good decisions.

A final thought before the airport lounge

KPMG's recent analysis of the new UK government places AI alongside economic growth, energy security, geopolitics and cybersecurity. That framing feels right. Artificial intelligence is no longer an isolated technology trend. It intersects with productivity, energy, workforce design, supply chains, security, investment, customer experience and competitiveness. The businesses that gain most from it are unlikely to be those that accumulate the largest collection of AI licences. They will be the organisations that understand where AI belongs in the operating model; maintain trustworthy data; choose models intelligently; govern agents proportionately; protect the systems around them; measure financial value realistically; and retain the human judgement, leadership and authenticity that technology cannot conveniently manufacture.

So perhaps the useful question for the summer is not:

“What else can we do with AI?”

It is:

“Where can AI create measurable advantage in our business and what needs to be true for us to trust it there?”

Answer that well, and your AI stack becomes a growth capability.

Ignore it, and by Christmas you may simply have more licences, more agents, more dashboards, more cyber exposure and a finance team asking awkward questions.

On that cheerful note, enjoy the holiday.

Just remember to disable the agent that has permission to move money before boarding the plane.