There is a pattern that appears consistently across organisations that have invested in AI initiatives over the past two years. It starts with genuine ambition. The board has asked about AI. Leadership has committed to a program. A pilot is commissioned, usually involving a large language model connected to some internal data source. The pilot produces impressive demos.
And then it stalls.
Sometimes the stall is a security review that raises concerns nobody anticipated. Sometimes it is a compliance team that cannot approve deployment because the system cannot explain where its answers came from. Sometimes it is simply that the outputs are unreliable enough that the people who were meant to use the system do not trust it. The project is not cancelled. It is described as being in an extended evaluation phase, or pending a technical review, or waiting for a policy decision. In practice, it has stopped moving.
This pattern is common enough that it is worth examining seriously. Because in almost every case, the stall is not caused by the model. The model is usually fine. The stall is caused by the information underneath it.
What fragmented knowledge actually looks like
Most large organisations have accumulated information across many systems over many years. There is a SharePoint environment, often several, frequently with overlapping structures and unclear ownership. There are document repositories that were implemented by different teams at different times. There are line-of-business systems with their own data stores. There are email archives, project management tools, and file shares.
Each of these systems has its own access model. Each was designed to solve a specific problem for a specific team. None of them were designed with the expectation that an AI system would one day need to retrieve information across all of them simultaneously, respecting each access model, and produce a coherent answer that could be traced back to authoritative sources.
When an AI system is connected to this environment, several things happen. The system retrieves information from whatever it can access, which is usually a subset of what exists. It cannot tell the user what it could not access. It produces answers that appear authoritative but may be based on outdated, incomplete, or incorrectly scoped information. The people responsible for data governance and security, when they understand what the system is actually doing, raise concerns. Those concerns are legitimate.
This is not a model problem. It is a foundation problem.
Why governance is not a constraint on AI. It is what makes AI work.
The instinct in many AI programs is to treat governance as friction. The security team, the compliance function, and the data governance group are perceived as obstacles between the organisation and a working AI system. This perception is understandable and almost always counterproductive.
In practice, the organisations that have successfully deployed AI into regulated environments have done so by treating governance as a design input rather than a deployment hurdle. They started by mapping what information existed, where it lived, and what access model should govern how it was retrieved. They built their retrieval layer on top of that map, with the access controls embedded rather than applied retrospectively.
The result is an AI system that can explain where its answers came from. One that does not retrieve content the user is not authorised to see. One that the security and compliance teams can review and approve because the access model is explicit and auditable. One that people actually trust because the outputs are traceable.
This approach takes longer to establish. It requires conversations with stakeholders who are not in the original project team. It often surfaces problems with content quality, version control, and ownership that the organisation would rather not confront. But it produces systems that stay in production rather than stalling in evaluation.
The question worth asking before the next pilot
Most organisations in 2026 are not short of AI capability. The models are accessible, capable, and increasingly affordable. What determines whether an AI initiative delivers operational value rather than impressive demos is the quality of the information it can access and the governance framework that controls how it does so.
Before commissioning another pilot, it is worth asking a more basic set of questions. Does the organisation have a clear map of where its authoritative information lives? Are the access controls on that information consistent and maintained? If an AI system retrieves content from across the organisation’s knowledge base, can it explain what it accessed, what it could not access, and why? Can the outputs be traced back to a source that a compliance team would find acceptable?
If the answers to those questions are unclear, the next pilot will produce the same result as the last one. The model will perform well in a controlled environment. The real-world deployment will stall.
The foundation work is not glamorous. It does not produce the kind of demos that impress a board. But it is the difference between AI that holds up in production and AI that stays permanently in an extended evaluation phase.
