Enterprise AI Knowledge Layer

It is the governed combination of sources, metadata, relationships, retrieval logic and provenance that supplies an AI application with useful context about your organisation. In practice it sits between the systems that hold your information and the assistants, search experiences or agents that need to use it, deciding what gets retrieved for a given question, from which authoritative source, and for which user. The label matters less than the components. What makes it a layer rather than a project is that more than one AI application can rely on it.

Not quite. A knowledge graph can be the right central component, particularly where relationships and multi-step questions matter, and it is where the interesting engineering usually sits. But a complete solution normally also involves search, vector retrieval, structured queries against existing databases and a semantic model over them. We decide during design where a graph genuinely earns its place, because building one for a question that a well-structured query would answer is expensive and slow to maintain.

Standard retrieval-augmented generation, usually shortened to RAG, is a sound technique and often sufficient: it finds passages relevant to a question and gives them to the model as context. It works less well when the answer depends on how things relate to one another rather than on what a document says, when the same entity appears differently across systems, or when the user needs to know which source is authoritative. A richer knowledge layer models the entities, the relationships and the provenance rather than only the text. Where a graph carries those relationships the industry term is GraphRAG; it is one pattern within the layer, not a replacement for it.

No, and we would advise against trying. We start with the sources the agreed questions require, and connect or ingest each one according to its security, performance and governance constraints. Some sources are best queried in place, others need indexing, and a few are not worth including at all. An attempt to consolidate everything first is the most common way these projects stall before producing anything useful.

No, and any supplier promising that is overselling. Better grounding and provenance reduce unsupported answers substantially and make the remaining ones easier to spot, because a user can see which source an answer rests on and whether it is current. What they do not do is remove the need for evaluation, source quality controls and human judgement. We test answer quality against a representative set of real questions and keep monitoring it, rather than treating the problem as solved at go-live.

Through identity mapping between your systems and the retrieval layer, source-level permission checks, least-privilege filtering and audit logging. The principle is that a person sees through an assistant nothing they could not already see, and no more. The implementation detail depends on your identity provider and on how consistently the source systems apply their own access rules, which is one of the things discovery establishes early because it often turns out to be the constraint that shapes the design.

Revocation matters as much as access. When a permission is withdrawn or a record deleted at the source, the change has to reach the index and every derived form of the content within an agreed time, rather than lingering in a copy nobody remembers making. The same mechanism is what makes a deletion request under data protection law answerable, so we design it in from the start.

It can try. Anything the layer retrieves — a document, a ticket, an email, a record — may contain text written to steer the model rather than inform it, and once the layer feeds agents as well as assistants this is a security question rather than a quality one. Retrieved content is treated as evidence for an answer, never as an instruction to the model, and is kept separate from the instructions the assistant operates under. Where the layer feeds an agentic workflow, the controls apply: validated tool inputs, approval gates on consequential actions, and adversarial cases in the evaluation set.

With incremental ingestion rather than periodic full rebuilds, freshness monitoring on each source, versioning so that superseded information can be identified rather than silently overwritten, and a named owner for each source. Currency is an operating question more than a technical one. Part of what we hand over is a stewardship model setting out who is responsible for keeping which source accurate, because a knowledge layer nobody maintains degrades quietly and is trusted long after it should not be.