Why Enterprise AI Fails: The Governance Gap

The failure that is not a technology failure

The 2025 version of this article opened with a statistic about the share of AI projects that never reach production. It was two years old then, so it is gone. You do not need it. Ask anyone running an AI programme how many pilots they have that work and are not live, and the answer is the point.

The pattern is consistent. A team builds an assistant that reaches two or three systems and does something useful: closes tickets, drafts credit memos, answers policy questions from the current policy. It works. It goes to the security review. The review asks five questions. Nobody can answer them, and the pilot stays a pilot.

The five questions

1. Who is allowed to use this? Not "the pilot team". Which people, by what rule, and what happens when one of them leaves?
2. What exactly may it do, on which records? "It can read the CRM" is not an answer. Every record? The ones under legal hold? Can it write?
3. What happens when it tries something it should not? An agent that can issue a refund will, at some point, propose a bad one. Is there a step where a person says no?
4. Where does the data go? Which model, in which region, with what retention, and is anything redacted on the way?
5. Can you prove all of the above afterwards? Not a dashboard. A record an auditor will accept, per call.

These are the same questions the organisation already answers for a person who touches the same systems. The gap is that agents arrived by two routes that do not answer them: the assistant vendors, who govern the model and not the tools, and the protocol, which authenticates a client to a server and describes tools but does not decide which person may use which tool. An authorised client sees everything the server exposes to it.

Why the questions are now mandatory

Until this year the security review was an internal gate and a determined sponsor could sometimes push a pilot past it. The EU AI Act's obligations for general-purpose and high-risk systems took effect on 2 August 2026, and for an organisation deploying AI that touches customer, financial or HR data, the five questions are now the shape of the compliance file. Logging, human oversight, transparency about what the system may do: the regulation asks for evidence of the same things the security team asked for informally. GDPR already required the data-residency answer; DORA asks the operational-resilience version of it for financial services.

The practical effect is that "we will add governance later" stopped being an option. A programme that cannot produce the record cannot go live, and one that goes live without it is now a reportable problem rather than a risk appetite decision. We wrote up the frameworks in more detail in the compliance deep dive.

What the answers look like

• Who: entitlement follows the groups people already hold in the identity provider. A joiner in Finance has Finance tools on day one; a leaver loses them on their last. There is no new list to maintain, and the identity provider stays the authority.
• What: policy is evaluated on the actual arguments of a call, not on the tool name. A read on one record and a bulk export are different decisions.
• When it tries something it should not: the call is held, routed to the right approver, and released or refused. The approval is part of the record.
• Where the data goes: you decide which models and which regions, and what is redacted before a call leaves; the layer runs in your VPC or on-prem if residency requires it.
• Proof: every call logged with who, what, when, why and on whose approval, exportable to the SIEM the auditors already read.

Each person gets one governed connector that carries all of this, together with every tool and Skill they are entitled to, into whichever assistant they already use. That is what Palma provides. The assistant and the systems do not change; the five questions get answers, and the pilot goes live.

The earlier version of this post described Palma as "multi-tenant" and said each team gets "AI assistants tailored to their needs". Neither is right. People keep the assistant they have; the connector is what is theirs.

What to do with the pilots you already have

1. List them. For each, write down which of the five questions blocked it. If the answer is "none, it just never got scheduled", that is a different problem.
2. Pick the one whose owner will defend a number. The value of a pilot is what its owner says it is worth per month, in writing.
3. Put the governance layer in front of it and re-submit to the review with the audit trail from a week of use. That is usually the fastest route from "we have pilots" to "we have one in production".

If you want help with the list, book thirty minutes and bring it.