Category Archives: Management

Your AI Risk Register Does Not Reflect Your Actual Risk

Posted on by

 

On 22 June 2026, the intelligence agencies of the United States, United Kingdom, Australia, Canada, and New Zealand spoke in a single voice about enterprise AI risk, and what they said demands attention.

The Five Eyes cybersecurity agencies issued a joint statement warning that frontier AI models are improving at a pace that will allow them to bypass prevailing enterprise cybersecurity defences within months. Not within years. Not in the next planning cycle. Within months. The statement’s own language: “The timeline is not years, it is months.”

 

This Is Not an Abstract Warning

Joint statements from the Five Eyes agencies carry a different category of authority than vendor advisories or consultancy threat reports. These are national intelligence services with access to classified threat intelligence, speaking to government and enterprise leaders simultaneously. When they frame a risk as both imminent and enterprise-specific, take it at face value.

What sets this advisory apart from every AI security conversation most enterprises have been having is one thing: specificity. The Five Eyes statement does not describe abstract AI risks. It specifically names the enterprise AI tools deployed at scale in the last 18 months: copilots, AI assistants, browser-connected agents, and systems with access to operational and customer data. The primary attack mechanism, developed across Five Eyes guidance published earlier this year, is prompt injection: an adversary embeds hidden instructions in content the AI system processes, causing it to act outside its intended scope.

That specificity matters. It means the tools that most large enterprises have already deployed are the attack surface being described.

 

The Threat Moved Faster Than Your Review

Most organisations that have rolled out AI copilots, enterprise agents, or browser-integrated assistants have conducted security reviews of those deployments. The Five Eyes advisory is not questioning whether those reviews happened. It is saying that the threat has moved faster than the defences, and that a review conducted six months ago may no longer accurately reflect the risk profile today. The gap is not in intent. It is in elapsed time against a threat that has not stood still.

The advisory is explicit that this is not solely a security-team problem. The statement directs its recommendations at leadership, framing AI-driven cyber risk as a governance and board-level accountability question. The statement’s own title: “The AI shift in cyber risk: why leaders must act now.” That framing has direct implications for how risk registers are built and how AI deployment decisions are reported to boards.

 

Three Things Worth Doing Before Your Next Board Meeting

The advisory points to three things transformation leaders should act on before their next board meeting.

The first is a current security review. Every AI deployment connected to operational data, whether customer records, financial systems, or internal communications, needs a review that specifically addresses prompt injection risk. Not the review conducted at go-live. A current one, calibrated to the threat capability the Five Eyes describe as arriving within months.

The second is an updated risk register. Most enterprise risk frameworks assessed AI security risk at the point of initial deployment. The Five Eyes advisory says the threat environment has changed materially in the months since, and the assessment needs to reflect current threat capability rather than historical assumptions. An outdated risk assessment is not a minor administrative gap at this point. It is a governance exposure.

The third is using the advisory to reframe the conversation at board level. Six cybersecurity agencies from five countries issued this statement with an explicit focus on business leadership. That gives transformation leaders the instrument they need to move boards that have been treating AI security as an implementation detail. The Five Eyes advisory makes it a governance question. Use it as one.

The AI deployment decisions taken in the last 18 months created an attack surface. Most enterprise risk registers have not yet priced what that surface is worth to an adversary with AI-powered attack tools that are months from bypassing prevailing defences. That gap needs to close, and it closes with a current assessment, not one accurate at the time of go-live.

The EU AI Deadline Your Compliance Team Probably Missed

Posted on by

The EU AI Act enforcement date most organisations have been tracking is not 2 August 2026. They have been watching the high-risk provisions, the conformity assessments, the prohibited applications. Those timelines stretch into 2027 and beyond, and enterprise compliance teams have planned accordingly.

Article 50 has a different clock. It takes effect in 31 days, it applies to a far wider population of organisations than most realise, and for most of its obligations there is no grace period.

 

Not the Regulation You Were Watching

For the past two years, enterprise AI governance conversations have centred on the Act’s high-risk classifications. Which systems require conformity assessments? Which use cases are prohibited outright? The questions were legitimate, and the extended timelines attached to those provisions created a reasonable sense of runway.

That runway does not apply to Article 50.

Article 50 covers transparency obligations, and it lands on 2 August 2026. It requires any organisation deploying customer-facing AI systems to disclose to users that they are interacting with an AI. It requires providers of generative content tools to implement machine-readable marking on AI-generated outputs. Operators running emotion recognition or biometric categorisation systems must notify the individuals affected. And for any new system entering the EU market on or after 2 August, compliance is required from day one.

One aspect of the regulation that most compliance programmes have not fully processed: Article 50 is not jurisdictional. Article 50 follows the user, not the provider. That is how the Act defines its own scope. A company headquartered in Dubai, Singapore, or New York that deploys AI-generated content visible to EU users is in scope. Where the output lands determines the obligation. The practical consequence is that Article 50 applies to any organisation with a customer base that includes EU residents, regardless of where that organisation is incorporated or where its AI systems are built and operated.

The organisations that will be caught short are not the ones building prohibited systems. They are the ones that assumed the regulation was still in the planning stage, or that it would only apply to organisations based in Europe.

 

The GDPR Comparison That Matters

GDPR was announced in 2016 and took effect in 2018. Two years of awareness campaigns, legal seminars, board-level briefings, and vendor remediation work. The compliance industry built an entire ecosystem around it. Privacy officers were hired. Data mapping exercises ran for months. By the time enforcement began, organisations at least understood what was expected of them, even if some were still catching up.

GDPR also reached beyond EU borders from the start. Any organisation processing the personal data of EU residents was in scope, regardless of where it was based. Article 50 operates on the same principle: it reaches wherever EU residents are on the receiving end of AI-generated content or AI-driven interactions.

Article 50 does not have that context. Most enterprise compliance functions have been tracking the Act’s overall timeline without separating out which provisions take effect when. The transparency obligations were not deferred. They were always scheduled for August 2026. But because the high-risk provisions dominated the conversation, the transparency rules arrived quietly, and they arrive soon.

Thirty-one days is not a planning horizon. It is an implementation sprint, or it is already a compliance gap.

 

What Article 50 Actually Requires

The obligations are more specific than the general framing of “AI transparency” suggests, and that specificity matters for scoping the work.

The most broadly applicable obligation is disclosure. If a user is interacting with a chatbot, a virtual assistant, or any automated system capable of conversation or personalised response generation, they must be told. The requirement is not a buried terms-and-conditions clause. It is a functional disclosure at the point of interaction. This applies from 2 August, to all systems, with no transitional provisions.

Generative content carries a second obligation. Organisations using generative AI to produce content distributed in EU-market contexts must ensure outputs carry machine-readable markers indicating AI generation. This applies to text, images, audio, and video. The AI Omnibus agreement provisionally agreed in May 2026 and expected to be formally adopted before 2 August extends this specific requirement to 2 December 2026 for systems already on the market before 2 August. For any new system entering the market from that date, the obligation is immediate. The extension is not a signal to deprioritise: December 2026 is not far away, and the technical implementation is not trivial.

Emotion recognition and biometric categorisation carry a third obligation, active from 2 August with no transitional period. Individuals must be informed when these systems are operating on them.

None of these obligations are complex in isolation. The difficulty is that most organisations have not mapped which of their current systems fall within scope, and that mapping exercise takes longer than 31 days when it is starting from scratch.

 

What to Do in the Next 31 Days

Non-compliance carries fines of up to €15 million or 3% of global annual turnover, whichever is higher. This is not a planning conversation. It is a board conversation.

Article 50 requires operational change: disclosure mechanisms built into interfaces, technical markers implemented in content pipelines, notification processes embedded in operational workflows. A policy document does not close this gap.

The practical starting point is a scoping exercise, and it needs to happen this week, not at the end of July. Three questions define the scope: Which customer-facing systems use AI in any form of interaction or response generation? Which content production workflows use generative AI to produce material distributed in EU-market contexts? Are any systems using emotion recognition or biometric categorisation?

If the answer to any of those questions is yes and the disclosure or notification mechanism is not already live, that is an Article 50 compliance gap.

Once the scope is clear, triage by exposure. Not every system carries the same risk. Externally facing consumer products in regulated sectors carry a different risk profile than internal productivity tools. Sequence the remediation by audience, jurisdiction, and volume of interaction.

Confirming the mechanisms actually work is where most programmes get caught. A disclosure notice that technically exists but is not surfaced at the point of interaction does not satisfy the requirement. The same applies to machine-readable markers that are added to some content outputs but not systematically applied across all generative workflows. Implementation is not the same as compliance.

 

31 Days Is Not a Problem. 32 Days Is.

There is still time to close this gap for organisations that act now. August 2026 is not GDPR day one, when regulators were finding their feet. It is an enforcement event in a regulatory framework that has had two years of published timelines. Regulators will not be looking the other way.

The organisations that treated the high-risk provisions as the whole story now have 31 days to correct that assumption. Wherever they are based.

Your AI Initiative Isn’t Failing Because of the Technology

Posted on by

The technology works. That is almost never the problem.

Across most large organisations right now, AI pilots are running. Proof-of-concepts are producing results that make it into board presentations. Vendor demos are impressive. The innovation team is energised. And then, somewhere between the pilot environment and actual production, the whole thing quietly stops.

According to Deloitte’s 2026 State of AI report, drawn from more than 3,200 business leaders, only 25% of organisations have moved 40% or more of their AI experiments into live production. That number deserves to sit with you for a moment. Three in four organisations are running AI experiments that have not become operational capability. The technology is not the constraint. Something else is.

You Have Seen This Before

If you have been in transformation long enough, this pattern is not new. It is the same pattern from every large ERP programme that never fully went live. Every data platform that became a reporting tool rather than a decision-making engine. Every digital transformation that delivered a new front end while leaving the back-office processes unchanged.

The technology becomes the story because it is visible, measurable, and exciting to talk about. The execution conditions that determine whether the technology actually delivers are harder to photograph and harder to put in a slide: ownership, integration, adoption. So they get managed as a substream, treated as implementation detail, and quietly become the reason the initiative stalls.

This is not an AI problem. It is an execution problem that has found a new context.

Ownership Is Not a Committee

The single most common structural failure in AI deployments is diffuse accountability. Someone owns the technology. Someone owns the data. Someone owns the security review. Someone owns the business case. Nobody owns the outcome.

Committees do not drive production deployments. They review them, adjust them, query them, and occasionally approve them. The organisations that close the gap from pilot to production consistently have a single named individual who is accountable for whether the capability lands in the hands of users, works as intended, and is actually being used. Not a steering group. Not a centre of excellence. One person with the authority and the obligation to make it happen.

This is not a preference for a particular organisational design. It is what the evidence shows, consistently, across every transformation context where the accountability question has been seriously investigated. Singular ownership is not sufficient on its own. But its absence is almost always present when a deployment fails.

The Metric You Are Probably Not Tracking

Most AI initiatives are measured on model accuracy, inference speed, and technical performance. These are valid measures of whether the technology works. They are not measures of whether the initiative is delivering value.

The question that actually determines success is adoption. Is the tool being used? By how many people? How often? Has it changed the decision they were making, or is it an additional step they complete before making the same decision they always made?

Deloitte’s 2026 data found that despite AI tools being available to approximately 60% of the workforce in organisations surveyed, fewer than 60% of those workers actually use them regularly. Access is not adoption. Availability is not value. If you do not have an adoption metric from day one, not a plan to measure adoption eventually but an actual metric that someone is accountable for, you are measuring the wrong thing and you will find out too late.

Scope Is Your Production Variable

There is a reason pilots succeed and production deployments struggle. A pilot can be run by a small team, in a controlled environment, with curated data, limited integrations, and a sponsor who is personally invested in making it work. Production is fundamentally different. It requires integration with existing systems that were not designed for this. It requires security and compliance review. It requires monitoring, maintenance, and the ability to handle the variability of real-world use at scale.

The organisations that consistently move from pilot to production do one thing differently: they scope production more narrowly than they scoped the pilot. Not because they are being unambitious, but because a narrow, fully integrated, fully adopted capability that actually works is worth ten pilots that demonstrated potential and then stalled in the transition.

Start smaller in production than you think you need to. Prove the integration. Prove the adoption. Then expand. The ambition for scale is valid. The timing of it is where most programmes get it wrong.

The Pattern Closes the Same Way Every Time

The 54% of organisations that Deloitte found expecting to move the majority of their AI experiments to production within three to six months are not describing a plan. They are describing an aspiration. The organisations that will actually close that gap are the ones that address the execution conditions, not the technology stack.

Singular accountability. Adoption as the primary metric. Scope narrowed deliberately in production. None of these are technology decisions. They are leadership decisions, and they can be made before the next pilot is commissioned.

The technology is ready. The question is whether the organisation is.

 

The Dashboard Won’t Save Your Project. Your People Will

Posted on by

We have built an entire industry around the wrong obsession.

Walk into any project or programme environment today and tell me what you see. Dashboards. RAG statuses. KPI scorecards. Burndown charts. Milestone trackers. Automated reports that nobody reads in full but everyone references in meetings as though they tell the complete story.

We have convinced ourselves that if we can measure it, visualise it, and put it on a screen, we are in control.

We are not in control. We are comfortable. And those are not the same thing.

Because the thing that actually determines whether your project succeeds or fails, the thing that has always determined it, is not sitting in any dashboard. It is sitting at a desk, joining a call, navigating a problem at 4pm on a Friday when the system throws an error nobody anticipated and the go-live is Monday morning.

It is your people.

And most leaders have quietly forgotten that.

How We Got Here

The shift happened gradually, and it happened with good intentions.

Technology gave us visibility we never had before. We could track progress in real time, surface risks earlier, and report upward with confidence. That was genuinely valuable. Nobody is arguing for less information.

But somewhere along the way, the tool became the answer. The dashboard became the proxy for understanding. The metric became the substitute for the conversation. And the leader who once walked the floor, read the room, and sensed the real mood of a programme started trusting the green status on a screen instead.

The result is a generation of project environments where the reporting is polished and the delivery is fragile. Where everything looks healthy until it suddenly is not. Where nobody saw it coming, except the people closest to the work, who saw it coming for weeks and had nowhere safe to say so.

That is not a data problem. That is a leadership problem.

 

What the Software Cannot Tell You

Your project management software does not know that your lead developer has been quietly updating her CV for three weeks because she feels invisible on this programme.

Your dashboard does not know that the business analyst who owns the most critical workstream is running on empty and has been covering for a colleague who disengaged two months ago.

Your RAG status does not know that the reason everything is green is because the project manager is too afraid to report amber. Because the last time someone reported amber, the steering committee treated it as a personal failure rather than useful information.

Your metrics do not know that the vendor’s implementation team has internally deprioritised your programme because a larger client demanded more of their attention, and your account manager has been managing that fact rather than disclosing it.

None of this shows up in the data. All of it will show up in the outcome.

Professor Bent Flyvbjerg’s research on major project delivery, one of the most comprehensive analyses of project outcomes conducted, found that 91.5% of major projects experience cost overruns, schedule delays, or both. The primary driver is not technical failure. It is optimism bias: the structural human tendency to underestimate problems, which reporting cultures then amplify. A team that does not feel safe surfacing bad news will report optimistically. And the gap between what is reported and what is real compounds week by week until it cannot be managed.

This is the gap that leaders who have outsourced their judgement to software cannot see. The human information. The signals that travel through relationships, not reporting lines. The early warnings that only surface when people feel safe enough, and trusted enough, to tell you the truth.

People Deliver. Not Platforms

Let me be direct about something that gets lost in every technology conversation.

The software does not write the requirements. A person does. The platform does not manage the stakeholder who keeps changing scope. A person does. The dashboard does not have the difficult conversation with the supplier who is underperforming. A person does. The metric does not hold the team together at the point when the pressure peaks and the temptation to cut corners becomes real.

A person does.

Every single meaningful act in the delivery of a project or programme is a human act. The technology supports it, documents it, and reports on it. But it does not do it.

This sounds obvious. And yet the way most organisations invest their leadership attention, their development budget, and their improvement energy tells a completely different story. They upgrade the tools before they develop the people. They add another dashboard before they ask whether their team leaders have the skills to have honest conversations. They buy new software to solve problems that are fundamentally about trust, capability, and culture.

And they wonder why the new system does not fix the delivery problem.

The People Who Confirm Success

Here is the other half of the equation that rarely gets enough attention.

It is not just the people who deliver the project that matter. It is the people who decide whether it worked.

The clinician who was supposed to use the new system and quietly reverted to the old one because nobody involved her in the design. The frontline manager who was presented with a new process in a one-hour training session and had nowhere to raise the fact that it does not reflect how the work actually happens. The customer who was told the transformation would make their experience better and is still waiting.

These people are the real success criteria. Not the go-live date. Not the project closure report. Not the benefits case that was written eighteen months before anyone understood what was actually being built.

Transformation succeeds when the people it was designed for adopt it, use it, and tell you it made a difference. And they will only do that if they were treated as participants in the process, not recipients of its output.

What Recalibration Actually Looks Like

Leaders who get this right do not look fundamentally different from the outside. They attend the same meetings. They review the same reports. But they do something that most of their peers have quietly stopped doing.

They go to where the work is.

Not to check on it. Not to apply pressure. To understand it. To ask the questions that the dashboard cannot answer. How are you actually finding this? What is slowing you down that is not on the risk register? What do you know that I should know?

Google’s Project Aristotle, an internal study of more than 180 Google teams, found that psychological safety was the single strongest predictor of team effectiveness, above individual talent, structure, and every other measurable factor. Amy Edmondson’s research at Harvard Business School reinforces this from a delivery perspective: teams where people feel safe to raise problems surface them earlier, when they are still recoverable. When people do not feel safe, the information gets filtered. And filtered information is what produces the green dashboard above the failing project.

They treat their team’s energy as a delivery asset, because it is. They notice when someone has gone quiet. They notice when the language in status reports starts becoming defensive rather than informative. They notice when the optimism of the first month has been replaced by the grinding compliance of a team that no longer believes the work matters.

And they act on what they notice. Not with a new metric. With a conversation.

They invest in the human layer of delivery the way that most organisations invest in the technical layer. Deliberately. Consistently. Not as a soft add-on to the real work, but as the foundation of it.

The Investment Gap

The question is not whether your tools are good enough.

For most organisations, the tools are fine. In many cases, the tools are excellent. The dashboards are sophisticated. The reporting is comprehensive. The project management frameworks are mature.

And yet the delivery outcomes have not improved at the rate the technology investment suggested they should. PMI’s research, tracking project performance across thousands of organisations globally, found that communication failure contributes to one in three project failures. The gap between organisations that invest seriously in the human and communication layer of delivery and those that do not is measurable, consistent, and significantly larger than most leaders assume.

The gap is not in the software. It is in the leadership attention.

What would change if you spent the same energy on understanding your people that you currently spend on reviewing your reports? What would surface if your team genuinely believed that telling you the truth was safer than protecting the status? What decisions would you make differently if you had the human information as clearly as you have the data?

Those are not rhetorical questions. They are the questions that separate the programmes that deliver from the ones that drift.

The Skill No Platform Replaces

Every programme failure I have ever been close to had warning signs that the data did not capture. The signs were there in the people. In the energy levels. In the conversations that stopped happening. In the problems that got managed rather than solved.

And in almost every case, the leaders were looking at a screen when they should have been reading a room.

The software is not the problem. The hardware is not the problem. The metrics and the dashboards are not the problem.

The problem is that we have allowed them to replace the most important leadership skill there is.

The ability to understand people. To create the conditions where they do their best work. To recognise when they are struggling before it shows up in a project status. To build the kind of trust that means the real information travels fast enough to matter.

No platform does that. No tool does that.

Only you do that.

And the projects that remember it are the ones worth talking about.

What Regulated Industries Know About Speed That Everyone Else Is Learning the Hard Way

Posted on by

 

There is a common assumption in business that regulation slows you down. That the organisations operating fastest are the ones least constrained by oversight. That compliance is a tax on progress.

The organisations now paying the heaviest price for AI governance failures are the ones that operated for years on exactly that assumption.

IBM’s 2025 Cost of a Data Breach Report found that 63% of organisations experiencing a material breach either had no AI governance policy or were still developing one. Shadow AI alone added an average of $670,000 to individual breach costs. The Stanford HAI AI Index recorded 233 documented harmful AI incidents in 2024, a 56% year-on-year increase. These are not primarily failures in regulated sectors. They are failures concentrated in organisations that never had to build governance infrastructure because, until recently, they never had to.

Financial services, healthcare, and government have something that fast-moving technology companies are now being forced to acquire under duress: the institutional knowledge of how to move at pace while the governance is on.

The Misconception About Constraint

Leaders who have spent most of their careers in lightly regulated environments tend to read compliance as friction. Something that adds time to a decision, introduces review cycles, and requires additional sign-off. In that framing, less compliance means faster execution.

What this framing misses is the distinction between compliance as architecture and compliance as checkpoint. A checkpoint is friction. It exists at the end of a process, adds a review stage, and slows the pipeline. Architecture is different. When governance is built into how a system is designed and how decisions are made, it does not add a stage to the process. It is the process.

The organisations in financial services and healthcare that move fastest on AI deployment are not the ones that find clever ways around their regulatory obligations. They are the ones that have built governance into their operating model, their system design, their approval authorities, and their risk frameworks so thoroughly that compliance is not a separate consideration. It is already done by the time a decision reaches an approval point.

Thirty Years of Governance Muscle

This is not an accident. Regulated industries have had decades of pressure to solve exactly this problem. A bank that cannot move fast cannot compete. A hospital that cannot adopt new clinical technology falls behind in patient outcomes and staff capability. A government department that does not modernise its systems loses efficiency and public confidence.

The answer these sectors arrived at, not by choice but by necessity, is embedded governance. Named senior owners for material deployments. Cross-functional oversight bodies with actual authority to pause or redirect, not just to advise. Pre-approved frameworks that allow decisions to be made quickly within defined boundaries, rather than requiring full escalation every time.

The results are measurable. Healthcare AI adoption in outpatient and ambulatory care doubled in two years, from 4.6% of firms in 2023 to 8.7% in 2025, within one of the most tightly regulated environments in the world, according to research published in PMC drawing on US Census Bureau Business Trends and Outlook Survey data. That pace of change did not happen despite the regulation. It happened because enough organisations in that sector had built the infrastructure to move quickly and safely at the same time. Overall healthcare AI adoption still lags sectors such as information services and professional services, where adoption exceeds 20%. The doubling reflects a strong rate of growth, not yet sector leadership in absolute terms.

What the Unregulated Sector Is Now Facing

The regulatory picture for AI is more complex than it appeared eighteen months ago, and understanding that complexity matters.

The EU AI Act has been materially reshaped. Prohibitions on unacceptable AI practices came into force in February 2025. Obligations for general-purpose AI models followed in August 2025. But an AI Omnibus legislative package, agreed in May 2026, delayed the Act’s most commercially significant provisions, those covering employment, biometrics, critical infrastructure, and education, until December 2027 at the earliest. The timeline has extended. The direction has not changed.

In the United States, the trajectory is different. The current federal administration has moved toward a consolidated national framework, explicitly designed to preempt the patchwork of state-level regulation that was developing. Colorado’s original AI Act, among the most comprehensive state-level frameworks, was replaced in May 2026 by a narrower successor focused on disclosure obligations rather than risk management requirements. The patchwork has changed shape. Any organisation planning its governance around a specific jurisdiction’s requirements may be planning around a moving target.

AuditBoard’s 2025 research found that only one in four organisations has a fully implemented AI governance programme. Among organisations with only partial AI governance guidelines, just 25% feel confident in their AI posture. Among those with mature, embedded governance frameworks, that figure rises to 48%, according to research from the Cloud Security Alliance and Google Cloud. Governance maturity is the strongest predictor of AI readiness, above deployment volume, tool selection, or the pace of regulatory change in any given jurisdiction.

The leaders with an advantage right now are not necessarily the ones tracking the latest regulatory guidance. They are the ones who understand that IBM’s breach cost data is accumulating well ahead of any enforcement regime. The external pressure may have shifted its timeline. The operational risk has not.

Governance as Competitive Advantage

The organisations that will move fastest through the current period of regulatory evolution are not the ones trying to stay ahead of each new requirement as it emerges. They are the ones building governance architecture now that will not need to be retrofitted later, whatever form external pressure eventually takes.

That means a named owner for every material AI deployment, not a committee, a person. It means oversight that has genuine authority to pause a deployment, not just to note concerns. It means pre-approved tooling and decision boundaries that allow teams to move without full escalation while still operating within defined risk tolerances.

This is not new governance theory. It is the operating model that financial services and healthcare organisations were forced to develop, iteration by iteration, under regulatory pressure. The knowledge exists. The question is whether leadership teams outside those sectors are willing to learn from it before the external pressure forces the same hard lessons.

The evidence that governance accelerates rather than inhibits deployment is not theoretical. Databricks’ State of AI Enterprise Adoption report found that financial services leads across industries in moving AI from experimental to production, reducing its ratio of experiments per production deployment from 29:1 to 10:1, the sharpest improvement of any sector measured. That is not a coincidence of timing. It is the measurable output of thirty years of building the infrastructure that makes fast deployment safe.

Speed and compliance are not opposites. In the organisations that have figured this out, they are not even in tension. Governance is the infrastructure that makes speed sustainable.

The industries that built that infrastructure under duress are now, inadvertently, the ones best positioned to show everyone else how it works.

The mechanics of building that architecture, including the five characteristics that separate real governance from the committee-and-checkpoint version most organisations have built, are covered in the companion piece Governance Is Not a Committee. It Is a Decision Architecture.

Healthcare’s Algorithm Is Working. That Is the Problem

Posted on by

Somewhere in American hospital records, there is a pattern that should not exist.

Diagnoses of acute posthemorrhagic anaemia, a serious blood-loss condition that requires transfusion, have risen sharply at facilities that adopted AI billing tools. Blood transfusions have not. A condition is being recorded. The standard treatment for that condition is not being given. According to a Blue Cross Blue Shield Association analysis, the discrepancy is not a rounding error. It is a signature.

This is not a story about a medical error. No patient was misdiagnosed. No physician made a wrong call. What happened is more systemic and more troubling. An AI system trained to identify billable conditions found one. It coded it. The hospital billed for it. Nobody questioned whether the diagnosis reflected care that was actually delivered.

This is what AI looks like when there is no governance around it.

What the Bill Says About the Chart

The Blue Cross Blue Shield analysis examined what happened to hospital billing after AI coding tools arrived at scale. The numbers are not ambiguous. Inpatient spending attributable to AI coding practices reached an estimated $663 million. Outpatient spending tied to the same pattern reached $1.67 billion. One facility’s case complexity rating, the metric that determines how much a hospital can charge, rose 6.7 per cent in the year after adopting an AI billing tool. The average rise at comparable facilities in the same state was 0.9 per cent.

The practice is called upcoding: coding a patient as sicker, or their treatment as more complex, than the clinical record supports. It has existed in healthcare administration for decades. What AI has done is industrialise it. According to a federal data brief from the Office of the National Coordinator for Health Information Technology, 71 per cent of US hospitals were using predictive AI by 2024. AI use for billing specifically rose 25 percentage points in a single year, from 36 per cent of hospitals in 2023 to 61 per cent in 2024. The speed of that adoption has outrun every oversight mechanism that existed to check it.

The tool is not complicated. What was built around it is the problem. AI coding tools scan patient records and flag conditions that could legitimately be billed. In the right environment, with clinical oversight and audit processes, that is a useful capability. In the environment most hospitals actually built, which is one without meaningful governance, they become a revenue maximisation engine. The algorithm does what it was trained to do. Nobody verifies whether the conditions it codes for were actually treated. The bills go out.

The Insurer’s Algorithm Has a Different Objective

At the same time hospitals are using AI to add conditions to bills, health insurers are using AI to remove approvals from treatment requests.

Prior authorisation, the process by which insurers must approve procedures before they happen, has become a primary deployment zone for AI-driven decision-making. The American Medical Association surveyed physicians and found that 61 per cent reported health plan use of AI is increasing prior authorisation denials. A US Senate Permanent Subcommittee on Investigations report found that denial rates at UnitedHealthcare, CVS, and Humana’s Medicare Advantage plans rose as each insurer increased AI deployment in its review process.

The governance picture on the insurer side is no better than on the hospital side. A January 2026 study in Health Affairs by researchers at Stanford Health Care, drawing on a survey of 93 large health insurers, found that more than one-quarter of insurers do not document the accuracy of their AI models or test them for bias, around 40 per cent have no accountability practices in place for AI tools used in prior authorisation and claims decisions, and fewer than one-quarter even tell providers when AI was involved in a determination.

The result is a healthcare system in which AI is simultaneously inflating what hospitals charge and compressing what insurers approve. Patients sit between the two. The treatment they need may be denied before it is given and billed for a complication they were never treated for.

Arizona, Maryland, Nebraska, and Texas all passed legislation in 2025 requiring human oversight before AI can be used to deny a prior authorisation request, prohibiting it as the sole basis for medical necessity determinations. From 2026, the Centers for Medicare and Medicaid Services (CMS) will require payers to provide a specific reason for every AI-assisted denial and to publish aggregate approval data. That regulatory response confirms the scale of what is happening. Legislators do not write laws against things that are not happening.

Nobody Has Had to Answer for This

The question that neither the hospital nor the insurer has been required to answer is a straightforward one: who is responsible for what the algorithm decides?

A 2025 survey of 182 US hospital leaders by Black Book Research found that only 22 per cent are confident they could produce a complete AI audit trail within 30 days if asked. Only 29 per cent have implemented and enforced policies covering AI model inventory and accountability sign-offs. Forty-one per cent identified limited vendor documentation, the model cards and drift reports that explain how a system behaves over time, as their top barrier to audit readiness. The median share of IT and quality budgets allocated to AI governance is 4.2 per cent.

These are not numbers that describe an industry taking AI risk seriously. They describe an industry that deployed the technology and deferred the governance question for later.

The procurement happened fast. The governance never followed. Across billing departments and claims operations, AI has been handed consequential authority over patient finances and care access by organisations that did not build the structures that authority demands. The tools were procured. The governance was not.

The Wrong Diagnosis

Every time this gets written about as an AI problem, the real fix gets deferred.

If the algorithm is the villain, the solution is a better algorithm. A more accurate one. A less biased one. Another procurement cycle, another vendor, another pilot. That framing lets every decision-maker who signed the purchase order, approved the deployment, and chose not to build the oversight infrastructure step back from the frame. The machine did it. The machine was wrong.

In healthcare, the machine is doing exactly what it was built to do. It finds billable codes and it finds reasons to deny claims. It operates at the scale and speed that human reviewers cannot match. And it does all of this inside organisations that did not build the governance structures, the audit processes, the accountability frameworks, or the appeals mechanisms that consequential decisions at that scale require.

The United States is where this data exists. It is not where the problem stops.

That is not an AI failure. It is an organisational one. And unlike a broken algorithm, it cannot be fixed with a software update.

 

Governance Is Not a Committee. It Is a Decision Architecture

Posted on by

A technology programme was delivered on time. The steering committee signed it off. The system went live on schedule and within budget. Twelve months later, usage across the organisation sat at eleven percent. The project had been a success by every measure the governance structure tracked. It had failed by the only measure that mattered.

Nobody was accountable for the eleven percent. The named owner had moved to a different role. The steering committee was dissolved at go-live. The vendor had fulfilled its contract. The organisation had built something that worked perfectly and was used by almost nobody, and no single person in the building could explain why.

That is not a delivery failure. It is a governance failure. And it is far more common than any organisation publicly admits.

 

What Governance Actually Is

Governance is one of those words that everyone uses and nobody defines. In most organisations, it has come to mean a structure: a committee, a framework document, an approval process, a risk register. Something you have rather than something you do. You have a governance framework. The governance is in place. The committee meets quarterly.

This version of governance is useless.

Governance is not a structure. It is a decision architecture. It is the infrastructure that determines how decisions are made, who makes them, what they are accountable for, and how fast the organisation can act when circumstances change.

Every organisation has a governance architecture, whether it has designed one or not. The informal version is still a governance architecture: decisions made by whoever is most senior in the room, accountability absorbed by whoever is most junior when something goes wrong, escalation triggered whenever someone is uncomfortable. It is simply a poor one. The difference between organisations that move well and organisations that stall is rarely capability. It is usually the quality of the decision infrastructure underneath the capability.

 

Governance Theatre

The most dangerous governance is the kind that looks correct from the outside.

Most large organisations have built governance that performs the appearance of oversight without the function. The risk register is meticulously maintained and never acted upon. The steering committee meets monthly and has not once paused a programme. The policy required six weeks of approval and is read by nobody after signing. The assurance review always concludes the project is on track.

This is more harmful than no governance, for one reason: it generates confidence without protection. The board believes the oversight is in place. The programme team believes the risks are managed. The organisation proceeds as if the architecture exists, while operating without it. When the failure arrives, it arrives at scale, having been invisible to every structure designed to catch it.

The question is not whether your organisation has governance. The question is whether your governance is real.

 

What Good Governance Looks Like

Good governance has five characteristics that distinguish it from the committee-and-checkpoint version most organisations have built.

The first is named ownership. Every material decision, every significant deployment, every consequential process has a single individual accountable for the outcome. Not a committee. Not a function. A person. The committee can advise. The function can review. One name sits against each thing that matters, and that person knows it and accepts it.

The second is authority that matches accountability. The most common governance failure is asking someone to be accountable for an outcome they cannot influence. If the named owner cannot pause a deployment, redirect a budget, or override a recommendation, their accountability is nominal. If you cannot identify what the accountable person can stop, you have not given them accountability. You have given them exposure.

The third is pre-agreed frameworks. Good governance does not require full escalation for every decision. It requires that boundaries are agreed in advance, so decisions within those boundaries can be made quickly, and decisions outside them trigger a defined path. The approval gate model creates queues. The framework model reserves escalation for the decisions that genuinely need it. Speed and governance are not a trade-off. They are a design choice.

The fourth is transparency of reasoning. Material decisions need a record. Not for audit purposes, but because the organisations that navigate change well are the ones where future leaders can understand not just what was decided, but why, what alternatives were considered, and what conditions would prompt a different outcome. This is not bureaucracy. It is institutional memory, and its absence is one of the most expensive losses any organisation experiences.

The fifth is a culture that supports use. The best governance architecture fails if the organisation punishes the people who use it correctly. The programme manager who escalates a risk that delays a milestone. The engineer who flags a model limitation that complicates a launch. The analyst who says the data is not fit for purpose. If those people are sidelined or not listened to, the framework is decorative. Governance is architecture and behaviour. Building the architecture without addressing the behaviour is half the work.

 

Governance Debt

There is a cost to governance failure that does not appear on any balance sheet until it is too late to address cheaply.

Every decision made without proper governance accumulates what might be called governance debt. The decision is made, the programme moves forward, the system is deployed. The cost is not visible immediately. It appears two years later, when the person who made the original choice has moved on, when nobody can explain why the architecture was designed the way it was, when the organisation needs to change a system it no longer fully understands and cannot safely modify.

Like financial debt, governance debt compounds. Small omissions early in a programme create disproportionately large costs at the point of change. The organisations that experience the most expensive transformations are rarely those that started with the hardest problems. They are those that accumulated governance debt in the early stages and discovered the interest charge when conditions changed.

 

The Speed Paradox

The dominant assumption about governance is that it slows things down. The evidence says otherwise.

Financial services is among the most heavily governed sectors in the world. It is also, by measurable data, among the fastest at moving AI from experimentation to production. Databricks’ analysis of enterprise AI adoption found that financial services improved its experimental-to-production ratio from 29:1 to 10:1 in under eighteen months, the sharpest improvement of any sector measured. The governance culture that financial services built under regulatory compulsion became, in practice, a deployment accelerant.

The reason is straightforward. When governance is architecture rather than checkpoint, when boundaries are pre-agreed and ownership is named, decisions within the framework do not require escalation. The work that in a poorly governed organisation requires a committee review happens at team level, within agreed parameters, without delay. The governance does not add a stage to the process. It is the process.

The organisations that move slowly under governance are the ones with checkpoints. The ones that move fast under governance are the ones with architecture.

 

Why AI Makes This Urgent

AI does not create governance problems. It amplifies the ones that already exist.

Every organisation deploying AI is making decisions at scale and at speed in ways that are not always visible to the people accountable for outcomes. When a model influences hiring, lending, clinical treatment, or procurement, the decision architecture governing that model matters as much as the architecture governing any senior leader. In some respects more.

Three risks are specific to AI. The first is accountability diffusion. When a decision is made by a model, who is accountable is rarely defined in practice. The model carries no accountability. The vendor carries it within narrow contractual limits. The organisation must deliberately assign it or it defaults to nobody, which is where most organisations currently sit.

The second is scale of error. A human decision-maker with a blind spot makes that error incrementally. A model with the same blind spot can make it thousands of times before the pattern is identified. The governance that catches a human error at ten instances must catch a model error at ten thousand. Most governance frameworks were not designed for that volume.

The third is the deployment and use gap. AI systems are deployed for a defined purpose in a defined context. They are then used in contexts their designers did not anticipate, by people not trained on their limitations, for decisions the governance framework never considered. Governance must follow the system into use, not stop at the deployment gate.

One additional risk is specific to the current moment. In most organisations, AI governance covers the official deployments. It has no visibility of, and no authority over, the AI already in use through personal accounts, consumer tools, and unapproved models. The governance gap that will produce the first visible failures is not in the formal AI programme. It is in the tools already running beneath the governance architecture’s line of sight.

For boards, this is a specific accountability question. Most are receiving AI updates without the frameworks to evaluate them. The question is not whether the organisation has an AI strategy. It is whether the board can answer four things: who is accountable for each material AI deployment, what authority they hold, what the escalation path looks like when something goes wrong, and whether the governance covers the AI that is actually in use rather than only the AI that was formally approved.

 

Three Questions That Will Tell You More Than Any Framework Audit

Name the person accountable for your most significant AI deployment. Not the team. Not the function. One person. If you cannot name them in under ten seconds, you do not have governance. You have the appearance of it.

When did your governance last stop something? Not delay it, not document a risk against it. Stop it. If the answer is never, your governance is not functioning as risk infrastructure. It is functioning as a record-keeping exercise.

If the three people who made your most significant programme decisions in the last two years left tomorrow, what would the organisation know about why those decisions were made? If the answer is not much, you are accumulating governance debt at a rate your future leaders will pay.

Governance is not a committee. It is not a document. It is the infrastructure through which an organisation makes consequential decisions, learns from them, and remains able to change course when it needs to.

Most organisations have not built that infrastructure. AI has not created that problem. It has simply made the cost of not solving it impossible to ignore.

Tokens Don’t Run Transformation Programmes

Posted on by

Somewhere right now, a CFO is presenting a slide that frames it as: tokens or headcount. Allocate to AI infrastructure, reduce salary costs, reinvest in capability. The maths is clean. The logic looks compelling. The slide is wrong.

The phrase “tokens or humans” has entered the corporate vocabulary fast. CNBC ran it as a headline in May 2026 and they were right to, because it captures something real: organisations are now making explicit choices between paying for people and paying for AI. But the framing treats it as a resource allocation problem. It isn’t. It’s a transformation governance problem, and most organisations are making the call before they understand what they are trading away.

 

The Numbers Look Better Than They Are

More than 142,000 tech jobs have been cut in 2026 already. Amazon, Meta, Salesforce, Block, Cloudflare. Executives are public about the logic: AI agents handle what humans used to, smaller teams move faster, capital gets redirected to infrastructure. The numbers are real.

So are these: over 80% of companies using AI showed no productivity benefit in a February 2026 study. Uber burned through its entire annual AI coding budget in four months. Microsoft cancelled a large tranche of Claude Code licences after six months. Productivity gains in controlled studies can be significant. In most real-world settings, the gains are a fraction of what those studies suggest, if they materialise at all.

Token prices are falling, yes. Gartner projects a 90% reduction by 2030. But Goldman Sachs projects a 24-fold increase in enterprise token consumption over the same period. The unit cost goes down; the total bill goes up. Companies reporting their AI budgets exhausted in one or two months are not outliers. They are the pattern.

The trade-off that looks like a saving is, in many cases, a substitution of one cost for a more volatile, harder-to-govern one.

 

You’re Cutting the Wrong People

Here is the part executives are not discussing on those slides.

When organisations reduce headcount to fund AI infrastructure, they do not cut at random. They cut operational staff, programme delivery roles, change management functions, middle management layers. These are the roles that look like friction. In a spreadsheet, they are the easiest cost to justify removing.

In a transformation, they are the load-bearing walls.

The tacit knowledge that keeps a complex programme on track does not live in a document or a prompt. It lives in the people who have navigated the politics three times before, who know which stakeholders will quietly block a decision, who understand why the last attempt failed. AI does not have that context. More importantly, it cannot build it. It can only work with what you give it.

When transformation programmes stall, which they do with regularity, the most common cause is not a lack of technology. It is a lack of people who know how to move organisations through change. Cutting those people to fund AI tools that have not yet delivered consistent productivity returns is not a strategy. It is a bet. And it is a bet being made with institutional knowledge that cannot be easily rebuilt.

 

The Governance Question Nobody Is Asking

Most boardroom conversations about tokens versus humans are efficiency conversations. They should be risk conversations.

Specifically: what is the reversibility of this decision? Hiring back experienced programme delivery professionals, change managers, and technology integrators in a tighter labour market is slow and expensive. The talent you let go walks straight into competitor organisations or into consulting. You do not get it back on demand.

Meanwhile, the AI infrastructure you are funding with those savings is subject to vendor pricing changes, model deprecation cycles, and adoption curves that are far less predictable than a salary line. The White House’s own March 2026 AI governance framework acknowledged the workforce transition risk. State lawmakers introduced hundreds of AI-related bills in 2025. Political and regulatory pressure is accelerating.

Boards approving headcount reductions to fund AI should be asking: what is our recovery plan if the productivity gains do not arrive on the timeline assumed? Few are.

 

What Good Decision-Making Looks Like Here

The organisations getting this right are not choosing between tokens and humans. They are sequencing the decisions differently.

They are deploying AI where the productivity case is proven and measurable: customer-facing automation, code assistance, data analysis, routine administrative work. And they are preserving the human capability needed to execute the transformation that makes AI integration actually work.

They are building governance frameworks around AI spend with the same discipline applied to capital programmes: defined outcomes, stage gates, budget controls, and exit criteria if results do not materialise. They are not treating AI infrastructure as a guaranteed return.

They are also being honest internally about what is driving the headcount decisions. If cost pressure is the real driver and AI adoption is the justification, that is worth naming clearly. Obscuring the actual motivation behind a technology narrative creates cultural damage that outlasts the short-term saving.

 

The Slide Does Not Run the Programme

The “tokens or humans” framing will stick around because it captures something real about the economics of 2026. But it is a simplification that is costing organisations more than they realise.

The numbers are not the decision. The decision is how you get from where you are to where you need to be. That still requires people who know what they are doing.

Your AI Isn’t the Problem. Your Organisation Is.

Posted on by

The technology isn’t the problem. It never was.

CEOs have finally said what transformation leaders have known for years. According to CIO.com‘s 2026 digital transformation analysis, a growing view at board level is this: AI adoption is failing because of workforce dysfunction and management failure, not because the tools aren’t good enough. The tools are excellent. The organisations deploying them are not ready.

That sounds like progress. It is not, entirely. Because the honest follow-on question, the one almost nobody is asking out loud, is this: what does it actually cost to fix an organisation that isn’t ready? And more to the point, who is being straight about that number?

 

The Comfortable Diagnosis

Acknowledging a workforce problem is easier than solving one. I have seen this pattern many times. The conversation shifts, the language changes, and suddenly the organisation is talking about upskilling programmes, change management workshops, and appointing a Chief AI Officer. Comfortable. Budgeted. Deliverable. Launch event confirmed.

Also insufficient.

What CEOs are actually describing is a change architecture challenge. Not a training programme. Not a comms plan. How do you get a workforce to reconfigure around fundamentally different ways of working, without losing the institutional knowledge and relationships that make the business worth anything? That takes years. In my experience, the failure rate is high, and rarely discussed honestly before the programme starts. And it requires a very different kind of leadership than deploying technology does.

 

What Boards Have Not Priced In

Technology investment decisions follow a familiar pattern. The vendor presents the business case. The pilots show strong results. The board approves the budget. The programme launches.

What nobody puts on that slide is the organisational cost of change. Not the cost of the technology. The cost of the human system that has to absorb it. The management bandwidth consumed. The productivity drop during transition. The cultural resistance that does not show up in workshops but absolutely shows up in usage data six months after go-live. The governance rework needed before AI-assisted decisions can actually be trusted.

Boards have been pricing in technology risk. They have not been pricing in change architecture risk. Those are different categories, and conflating them is precisely how organisations end up with expensive tools and thin results. The numbers bear it out. CIO.com‘s analysis of AI misconceptions found that 42% of companies abandoned most AI initiatives in the past year, up from 17% the year before. That is not a technology failure rate. That is an organisational one.

 

The Consultancy Pivot Is Real, and Worth Watching

The market is starting to notice. As Florian Douetteau, CEO of Dataiku, put it: “Instead of selling cloud migrations and data platforms, consultants will start selling organisational rewiring to prepare for AI-run operations.”

He is right. And executives need to tell the difference between genuine expertise and repackaged change management with AI branding.

The signal is specificity. Anyone selling organisational rewiring should be able to answer three questions: What does the post-rewired organisation look like, and how is it materially different from today? How do you measure progress at the midpoint, not just the end? And what happens when it does not go to plan?

Vague answers are a warning sign. If the firm cannot describe the failure modes honestly, they are probably not equipped to help you navigate them.

 

The Transformation Leader’s New Mandate

The transformation leader’s remit has shifted. It is no longer primarily about technology deployment. It is about change architecture: the sequencing, the governance, the capability-building, the stakeholder management that lets an organisation absorb new ways of working without destabilising what already works.

Harder to sell on a slide. Harder to put an end date on. Harder to celebrate in a press release. But it is the actual work, and anyone who has run a transformation programme at scale knows it.

The practical implication: if you are accountable for AI adoption and spending more time managing technology vendors than managing your leadership team’s readiness to change, you are working on the wrong problem.

 

Three Things Worth Doing Now

Start with an honest capability audit, not of your technology stack, but of your management layer. Which leaders have the resilience to sustain adoption pressure? Which ones will quietly resist in ways that never surface in a steering group but absolutely show up in usage data? You need to know before you scale.

Re-examine your success metrics. If the primary measures are deployment milestones and licence utilisation, you are measuring the technology, not the adoption. Add behavioural indicators: how are decisions being made differently, how has workflow changed, what are managers doing that they were not doing before?

And build the longer timeline into the plan, not as a caveat but as a structural reality. If your board believes this is an eighteen-month programme and you privately know it is a four-year change effort, that gap will surface. Better now, through a direct conversation, than in a programme review where the numbers no longer make sense.

 

The Gap Is the Risk

The AI is ready. Most organisations are not. The risk is not the gap. The risk is the pretence that it is smaller than it is, approving investment on that basis, and finding out the real cost when there is no runway left to correct it.

Honesty about the gap is not pessimism. It is the foundation of a credible plan.

AI Deployment Without Governance Is Not Transformation

Posted on by

AI deployment without governance is not transformation. It is expensive experimentation.

Most organisations know this. And most organisations are doing it anyway.

The pressure to deploy is real. Boards are asking about it. Competitors are announcing it. Technology vendors are selling it with a conviction that borders on evangelical. And so CIOs, CTOs, and transformation directors are buying, piloting, integrating, and announcing. The pace of activity is impressive. The demonstrable results, when you look past the press releases and the internal communications, are considerably less so.

The problem is not the technology. The tools are genuinely capable, some remarkably so. The problem is what has been skipped in the rush to deploy: the governance infrastructure that determines whether AI investment creates accountable, measurable, sustainable value, or simply generates activity that resembles transformation while the underlying risks accumulate, unmanaged and unmeasured.

 

What Ungoverned AI Actually Looks Like

Every organisation that has rushed deployment without the infrastructure to support it shows the same patterns.

Proliferation without accountability. AI tools appear across departments, purchased by individual teams, integrated into workflows, processing sensitive data, producing outputs that influence decisions. Nobody owns it. Nobody monitors it. Nobody is accountable when something goes wrong. And something will go wrong.

Measurement without meaning. Leaders can tell you how many tools have been deployed, how many users are active, how many hours have been saved. What they cannot tell you is whether those savings translate to outcomes that matter, or whether the metrics being tracked were chosen because they were easy to collect rather than because they were meaningful. The reporting looks credible. The underlying picture is opaque.

Risk without recognition. AI systems inherit the biases in the data they are trained on. They produce errors in ways that are not always visible. They embed themselves in decision-making processes in ways that are difficult to unpick. Without governance structures that surface and manage these risks, organisations are running exposures they have not modelled and cannot quantify. This matters in every sector. In healthcare and financial services, it is potentially catastrophic.

Adoption without sustainability. Most AI deployments stall not because the technology fails, but because the human system around it was never properly designed. People use the tool when it is mandated. They stop when the mandate loosens. The promised transformation does not materialise because the operational disciplines required to embed new ways of working were never built. The pilot looked like a success. The programme was not.

 

Why Governance Gets Skipped

Because it is slower than deployment. Because it requires difficult conversations about accountability that nobody wants to have in a climate of enthusiasm and competitive anxiety. Because governance sounds like bureaucracy to people who have come to associate progress with pace.

The irony is that skipping governance does not make things faster. It makes the eventual reckoning slower, more expensive, and considerably more painful. An AI system embedded across an organisation’s core processes without proper oversight is not an asset. It is a liability with a very good PR strategy.

The organisations that have moved most decisively into AI without governance infrastructure are not ahead. They are exposed. They have made commitments they cannot sustain, taken risks they cannot quantify, and created dependencies they cannot easily exit. That is not a position of strength. It is a position of fragility that has not yet been tested.

 

What AI Governance Actually Means

Not a committee. Not a policy document on an intranet page that nobody reads. Not a risk register reviewed quarterly and then filed. Those are the bureaucratic imitations of governance. The real thing is different.

Real AI governance means someone is accountable for every deployed AI system, with a clear mandate, clear authority, and clear consequences when standards are not met. It means data quality is a precondition for deployment, not an afterthought. It means risk frameworks are designed before tools go live, not retrofitted after something fails. It means adoption is planned around outcomes, not headcount or activity metrics.

It also means the organisation has an honest view of its own readiness. Not every process is ready for AI. Not every dataset is clean enough. Not every team has the change capability to absorb a significant operational shift. Good governance makes that assessment before investment is committed. Not after.

There is also a strategic dimension that is frequently missed. AI governance is not just a risk management function. It is a value protection function. Organisations that govern well can identify what is working, scale it deliberately, and stop what is not working before it becomes costly. Organisations that do not govern well discover problems at the worst possible time: through failures that are visible, expensive, and in the current regulatory environment, increasingly public.

 

Three Questions Worth Asking Before the Next Deployment

Who is accountable for the outcomes of this AI system, defined by the results it produces, not the tool it deploys?

How will we know if this is working, measured by the things that actually matter, not the metrics that are easy to count?

What are the risks we have not fully modelled, and who owns them?

If the answers are unclear, the organisation is not ready to deploy. It is ready to experiment. And experimentation, at the scale and pace of current AI investment, is not a cost most organisations have properly accounted for.

The organisations that will extract durable value from AI are not the ones moving fastest. They are the ones that have built the infrastructure to know what is working, why it is working, what the risks are, and what to do when things go wrong.

That infrastructure is governance. And without it, transformation is not what you are doing.