Enterprise AI needs a knowledge plane, not another vector store.

The first enterprise AI assistant usually starts with a sensible goal. Connect a model to a collection of internal documents, add retrieval, and help one team find answers faster.

Then another team builds one. And another.

Each application creates its own connectors, copies some of the same documents, chooses a different chunking strategy and invents its own metadata. One assistant indexes architecture decisions. Another reads SharePoint. A third searches source code and runbooks. Before long, the company has several AI products, each carrying a partial and slightly different memory of the same organisation.

The models are not necessarily the problem. The organisation has made knowledge an application-level concern.

I have seen this pattern emerge in enterprise modernisation work: the valuable part is rarely getting a model to produce an answer. The difficult part is establishing which evidence it may use, who owns that evidence, where it applies, whether it is still current and what should happen when sources disagree.

That is why enterprise AI needs more than retrieval-augmented generation. It needs a knowledge plane.

By knowledge plane, I mean a shared set of contracts, controls and feedback loops through which AI products can discover and retrieve domain-owned knowledge. It standardises identity, metadata, provenance, permissions, lifecycle and evaluation. It does not require every document to live in one database, and it does not make every piece of knowledge visible to everyone.

The distinction matters. A shared knowledge plane can make many AI products safer and more useful. One giant knowledge base can simply make the same mistakes available at greater scale.

The fragmented-memory problem

When every assistant builds its own memory, duplication is only the visible cost.

The deeper cost is inconsistency. A policy can be current in one index and obsolete in another. A permission change in the source system may not reach every copy. The same service may have different names across a repository, a catalogue and an incident platform. Evaluation results from one assistant teach the others nothing.

Every product team is then forced to solve the same questions independently:

• How do we identify an authoritative source?
• How do we preserve document permissions during retrieval?
• How do we represent effective dates and superseded decisions?
• How do we trace a generated claim back to evidence?
• How do we test retrieval against real business questions?
• How do we remove compromised or obsolete content quickly?

This is not just inefficient. It creates a governance gap between the systems that own enterprise knowledge and the AI products that reuse it.

The important change is not that the second architecture has fewer indexes. It may still use several specialised indexes. The change is that those indexes no longer invent their own rules for authority, access, provenance and quality.

The wrong answer is one giant knowledge base

Centralisation sounds attractive. Put everything in one place, embed it, and call it the enterprise source of truth.

But a retrieval index is not a source of truth. It is a derived projection of source material. Documents have been parsed, split, enriched and transformed into structures optimised for search. The index can be stale, partially synchronised, incorrectly chunked or built with an obsolete model. AWS describes this process explicitly: source material is divided into chunks and embedded while retaining a mapping to the original document.¹

That mapping is essential because authority remains with the source.

Some knowledge belongs in Git. Some belongs in a controlled records system. Some is maintained in service catalogues, data products, policy repositories or collaboration platforms. And some truths should not be documents at all. Inventory, deployment state, account balances and permissions change too quickly; an agent should query them through an authoritative API under transactional controls.

Centralising ownership also creates an organisational bottleneck. The people closest to a business domain are usually best placed to judge its vocabulary, exceptions and lifecycle. The Data Mesh model was developed for analytical data, not enterprise knowledge, but its principles are instructive: domain ownership, products with explicit quality expectations, self-service infrastructure and federated governance.²

Centralise the contract and controls. Federate the content and its accountability.

This also respects a limit that technical architectures often ignore. ISO 30401 treats organisational knowledge as human, codified and embedded.³ A retrieval system can make recorded evidence easier to reuse. It cannot fully encode expert judgement, informal relationships or the practical understanding required for exceptional situations.

A knowledge plane should therefore amplify experts, not pretend to replace them.

What the knowledge plane actually shares

The shared layer is not a universal content store. It is a common way for independent domains and AI products to exchange trustworthy context.

At minimum, it should provide five capabilities.

A knowledge-object contract

Every retrievable object needs a stable identity and enough metadata for a machine to decide whether it is appropriate evidence. Useful fields include:

• canonical identifier and source URI;
• source system and source revision or hash;
• owner and accountable steward;
• lifecycle state such as draft, approved, deprecated or revoked;
• valid-from and valid-until dates;
• domain, audience, geography and environment;
• security classification and policy reference;
• relationships such as supersedes, conflicts with or supports;
• chunk lineage and index or embedding version.

This is not a new universal schema. Dublin Core provides portable metadata terms, DCAT adds catalogue interoperability and versioning, W3C PROV models derivation and responsibility, and SKOS supports shared taxonomies.⁴⁵⁶ An enterprise can borrow from these standards while allowing domains to extend the contract for their own knowledge products.

Provenance that survives generation

Provenance answers where evidence came from, how it changed and which person or process was responsible for it. It does not prove that the evidence is true.

That distinction prevents a common category error. A citation can make an answer inspectable, but it cannot make an obsolete policy correct. Trust requires four separate ideas:

• authority: who is accountable for the source;
• provenance: where the content came from and how it changed;
• validity: when and where it applies;
• confidence: how strongly the retrieved evidence supports the answer.

Permission-aware retrieval

Authorisation must happen before evidence reaches the model.

Microsoft recommends applying security trimming to every retrieval request and preserving the caller's identity through a governed API layer.⁷ Google uses the enterprise identity provider to restrict results to documents the user may access in the original data source.⁸ AWS supports metadata and document-level ACL filtering at retrieval time.⁹

This is consistent with Zero Trust: neither network location nor membership of the company creates implicit permission to access a resource.¹⁰

Post-generation redaction is too late. Once restricted content has entered the model context, the security boundary has already failed.

Retrieval as a governed service

Vector similarity is useful, but it is not a knowledge architecture.

Enterprise retrieval often needs lexical search for exact identifiers, semantic search for conceptual matches, metadata filters for applicability, reranking for relevance and graph traversal for relationship-heavy questions. Long context windows do not remove this need; research has shown that model performance can still degrade depending on where relevant evidence appears in a large context.¹¹

The knowledge plane should route queries to the appropriate mechanism. A source-code question, a policy question and a request for live operational state should not automatically follow the same retrieval path.

Shared evaluation and observability

If multiple products consume the same knowledge, they should not need to rediscover the same failure modes independently.

The platform should maintain reusable evaluation sets drawn from real work. Those sets should include ordinary questions, ambiguous language, obsolete documents, conflicting sources, permission boundaries and deliberately malicious content.

Retrieval metrics such as context relevance and coverage should be separated from answer metrics such as correctness, completeness, faithfulness and citation quality.¹² Security tests should verify cross-domain isolation, prompt-injection resistance and revocation. Business measures should track outcomes such as time to resolution, successful self-service, onboarding time and duplicate work avoided.

Trust is a chain, not a score

Enterprise teams often focus on the final answer quality. But an answer is only as trustworthy as the controls that preceded it.

Every arrow is a possible failure boundary.

A strong model cannot repair an incorrect authorisation decision. Excellent retrieval cannot make an obsolete source current. A citation cannot recover provenance that disappeared during ingestion. A high average evaluation score cannot excuse one route that leaks another department's restricted documents.

This is also why AI governance cannot be added as a final review. ISO/IEC 42001 frames AI management as a continuing organisational system, while the NIST AI Risk Management Framework organises governance around activities to govern, map, measure and manage risk across the lifecycle.¹³¹⁴

The knowledge plane gives those controls somewhere concrete to operate.

The operating model is the real product

Technology can detect stale content, but it cannot decide which policy should replace it. It can find two contradictory architecture decisions, but it cannot assign accountability. A durable knowledge plane therefore needs an operating model.

Each domain needs people who can:

• approve or reject authoritative knowledge;
• define domain vocabulary and applicability;
• resolve conflicts and exceptions;
• respond to freshness or quality alerts;
• revoke unsafe content;
• review questions the system could not answer.

Maintenance must also happen in the flow of work. The Knowledge-Centered Service methodology captures this with a useful principle: knowledge is created and improved through use, rather than maintained only through periodic cleanup.¹⁵

For engineering organisations, that can mean updating a runbook in the same pull request as the operational change, recording architecture decisions when they are made, linking incident learning to the affected services, and routing repeated unanswered questions back to a domain owner.

The feedback loop is what turns a searchable corpus into organisational memory.

Start with one consequential workflow

Building an enterprise-wide ontology before delivering value is a reliable way to create a governance programme that nobody uses.

A better starting point is one workflow with repeated questions, identifiable owners and a measurable cost of poor knowledge. It could be incident response, software modernisation, customer support, policy interpretation or developer onboarding.

For that workflow:

1. Identify the authoritative sources and their owners.
2. Define the minimum metadata and permission contract.
3. Build a representative set of real questions and expected evidence.
4. Connect retrieval through an identity-aware gateway.
5. Require citations and explicit abstention when evidence is insufficient.
6. Measure retrieval, answer quality, security and business outcomes separately.
7. Feed recurring failures back into the domain's knowledge process.

Only then should the organisation generalise the shared capabilities for other domains.

This creates a practical maturity path: from document dumping, to a searchable corpus, to governed knowledge products, to a federated knowledge plane. The final step is not a bigger database. It is a system that learns where organisational knowledge is weak and creates accountable work to improve it.

AI readiness is knowledge readiness

The race to deploy enterprise agents can make knowledge architecture look like supporting infrastructure. I believe it is closer to the foundation.

Models will change. Retrieval products will improve. Context windows will grow. None of those developments answers the organisational questions of authority, permission, validity and accountability.

A company is ready to scale enterprise AI when its agents can retrieve domain-owned evidence through common controls, show where their claims came from, respect the same access boundaries as the underlying sources, and decline to answer when the evidence is not good enough.

That is not one giant knowledge base.

It is a knowledge plane the organisation can trust.

Sources

1. Amazon Web Services, How Amazon Bedrock knowledge bases work.
2. Zhamak Dehghani, Data Mesh Principles and Logical Architecture, 2020.
3. International Organization for Standardization, ISO/DIS 30401: Knowledge management systems - Requirements, draft second edition, 2026; see also ISO 30401:2018.
4. Dublin Core Metadata Initiative, DCMI Metadata Terms.
5. W3C, Data Catalog Vocabulary - Version 3 and PROV-O: The PROV Ontology.
6. W3C, SKOS Simple Knowledge Organization System Reference.
7. Microsoft, Design a secure multitenant RAG inferencing solution.
8. Google Cloud, Set up data source access control.
9. Amazon Web Services, Amazon Bedrock Knowledge Bases.
10. NIST, SP 800-207: Zero Trust Architecture.
11. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, Transactions of the Association for Computational Linguistics, 2024.
12. Amazon Web Services, Review metrics for RAG evaluations that use LLMs; Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, EACL 2024.
13. International Organization for Standardization, ISO/IEC 42001:2023 - AI management systems.
14. NIST, AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 2024.
15. Consortium for Service Innovation, KCS v6 Practices Guide.