The KNOW lane
The SharePoint AI Knowledge Mesh
Last updated by Errin O'Connor, Founder & Chief AI Architect, EPC Group
Most organizations have exactly one AI assistant reading their SharePoint content. The Knowledge Mesh is a governed way to put that same estate to work across several models — Microsoft Copilot natively, and Claude, ChatGPT, Gemini and private in-tenant models through a permission-aware integration layer — so the model best suited to a question can answer it without anyone gaining access they did not already have.
Key Facts
- Copilot is the native Microsoft 365 experience; other models participate only through a governed integration layer.
- Permissions are resolved before retrieval, so the mesh can never widen what a user is authorized to see.
- Governed by the K-N-O-W method: Knowledge inventory, Normalize, Orchestrate, Watch.
- Content hygiene is fixed before any model reads the estate, because retrieval quality is decided there.
- Built on 6,500+ SharePoint implementations.
Where our multi-model work on Power BI answers what is happening in our data, the Knowledge Mesh answers a different question entirely: what do we know, where does it live, and who is allowed to see it? Those are not the same problem and they do not have the same solution.
Why a single assistant is not a knowledge strategy
An organization’s knowledge is fragmented by default — across sites, libraries, Teams channels, and a decade of near-duplicate versions nobody has authority to delete. Point one assistant at that estate and it inherits every content-hygiene flaw at once, then repeats them back with the confidence of a direct answer.
The second problem is subtler. Models differ. One is stronger at summarizing a long policy document, another at synthesizing across dozens of sources, another at drafting in a compliance-sensitive register. Committing an entire knowledge estate to a single model means accepting that model’s weakest capability everywhere it is weak — permanently, and invisibly.
The K-N-O-W method
This is a methodology, not a feature list. Each stage gates the next, and skipping the first is the most common reason enterprise AI retrieval disappoints.
K — Knowledge inventory and classification
Audit sites, libraries, metadata and sensitivity labels, and separate authoritative content from stale duplicates — before any model reads a single document. Retrieval quality is decided here, not at the model.
N — Normalize and govern
Permission trimming, sensitivity-label enforcement, retention alignment and content-type discipline. The mesh can only ever surface what governance already approves.
O — Orchestrate model access
Route each question class to the model that handles it best — Copilot in-flow for native Microsoft 365 work, external models through the governed retrieval layer for research, long-context synthesis or drafting.
W — Watch and improve
Query analytics, answer-quality review, drift detection, and reconciliation whenever permissions change. A mesh that is not watched silently decays as the estate moves underneath it.
Security and permission architecture
SharePoint and Microsoft 365 permissions determine which information the authenticated user is authorized to retrieve, while EPC Group’s governed integration architecture controls what approved context is subsequently transmitted to a selected AI model.
Two consequences follow, and both matter more than any model choice. The mesh cannot become a shortcut around permissions — if a user could not open a document yesterday, no model in the mesh will summarize it for them today. And because AI amplifies oversharing rather than creating it, the permission remediation in the Normalize stage is usually the highest-value work in the engagement, whether or not a single model is ever switched on.
Which model answers which question
Routing is a governance decision before it is a technical one. Microsoft Copilot handles in-flow Microsoft 365 work natively. Research and long-context synthesis route to models selected for that strength. Anything touching regulated or highly sensitive material can be pinned to models deployed inside the Microsoft 365 trust boundary through Azure OpenAI or Azure AI Foundry. None of these external models connect to SharePoint directly — every one of them receives only approved context through the integration layer.
Where this sits: KNOW, ACT, ANALYZE
Three lanes, three distinct problems: multi-model architecture for Power BI is the ANALYZE lane; the Decision Fabric for Power Automate and Power Apps is ACT; the Knowledge Mesh is KNOW. They share a governance philosophy and nothing else — different estates, different failure modes, different measures of success.
Getting started
Engagements begin with a knowledge inventory, because the answer to “which models should we use” is unanswerable until the estate is understood. Work is fixed-fee and fixed-scope; pricing is confirmed after a scoping call.
Frequently asked questions
Can ChatGPT or Claude read our SharePoint directly?
No. Microsoft Copilot is the native experience inside Microsoft 365. Other models never connect directly to SharePoint. They participate only through a governed integration layer that resolves the authenticated user’s permissions first and passes forward only approved context.
Does the Knowledge Mesh replace Microsoft Copilot?
No. Copilot remains the native layer and the default for in-flow Microsoft 365 work. The Knowledge Mesh adds governed choice on top, so a question better served by a different model can be routed there without loosening any permission.
How are SharePoint permissions enforced when an external model is used?
SharePoint and Microsoft 365 permissions determine which information the authenticated user is authorized to retrieve, while EPC Group’s governed integration architecture controls what approved context is subsequently transmitted to a selected AI model.
Is our content used to train these models?
The architecture is designed so tenant content is not used for model training, and enterprise API terms are selected on that basis. What any specific vendor agreement guarantees is a contractual question, and we document the applicable terms per engagement rather than making blanket claims.
How long does a Knowledge Mesh implementation take?
It is scoped after the assessment, because duration is driven by estate condition rather than headcount — the number of sites in scope, how much content carries usable metadata, and how much permission remediation the inventory surfaces.
Where to go next if the estate is the problem: SharePoint consulting, Microsoft Purview for the labelling and DLP layer this depends on, or a scoping call if you want the inventory first.
The Knowledge Mesh draws on 6,500+ SharePoint implementations delivered since 1997 — which is the reason the method starts with content hygiene rather than model selection.