Knowledge management governance is the set of named owners, written policies, access tiers, review cadences and logs that decide what enters your organisation's knowledge base, who may read each part of it, and how you prove that afterwards. Until recently the readers were all people. That is the part that changed.
Our position is that knowledge management governance stopped being a publishing discipline and became an access-control and audit discipline the moment a retrieval system started reading the corpus on an employee's behalf. Document-level permissions written for humans browsing an intranet do not survive a service identity that can search everything indexed, and the two questions nobody used to ask - was this requester entitled to this passage, and what did retrieving it cost - are now the ones you get asked in an audit. On Hacker News in March 2026, a commenter posting as everforward described a corporate assistant wired to the company wiki returning rejected RFCs and abandoned personal runbooks, and concluded that "it just ends up polluting the context with irrelevant, outdated or just wrong information." That is a governance failure wearing a retrieval costume.
The short answer: Govern the retrieval, not just the document. A knowledge management governance programme built for AI needs four things human-era programmes never needed: corpus tiers an agent can be scoped to, a per-retrieval record naming the requester and the principal it acted for, non-human identities in the same ownership register as people, and staleness enforced by expiry rather than encouraged by policy.
Last updated: July 30, 2026.
We have not run a governed enterprise corpus of our own and this article reports no benchmark we measured. Every claim below is either read directly from a primary source and linked, or presented as arithmetic with its assumptions stated so you can substitute your own numbers.
The ungoverned path indexes everything and answers from whatever the vector search returns. The governed path adds four checkpoints and one record.
What Knowledge Management Governance Actually Governs Now
Knowledge management governance is the operating machinery of a knowledge programme: who owns each body of knowledge, what gets captured, who may read which tier, how often it is reviewed, when it expires, and what evidence exists that the rules held. Assemble those decisions into one document and you have a knowledge governance framework, which is the field's usual name for the artefact. Strategy decides what the programme is for. Governance is what makes the strategy survive contact with a Tuesday.
That distinction is old and still correct. What is new is the reader. For thirty years the consumer of an internal knowledge base was a person with a browser, an employment contract, and a manager. Every control in the field was designed around that assumption: a wiki space with a permission group, a review reminder in someone's inbox, a naming convention, an intranet search box that surfaced what the searcher could already open.
There is exactly one international management-system standard for this discipline, and its dates tell the story. ISO 30401:2018, Knowledge management systems - Requirements, was published in November 2018 by ISO/TC 260. It runs to 20 pages, it has picked up two amendments (one in 2022, one in 2024 covering climate-action changes), ISO's own record marks it at stage 90.92, "International Standard to be revised", and the page states it is expected to be replaced by ISO/DIS 30401 within the coming months. A 20-page management-system standard drafted in 2018 could not have anticipated a retrieval pipeline, and it does not describe one.
| Layer | Human-era assumption | What retrieval changed |
|---|---|---|
| Reader | A named employee with a login | A service identity acting on someone's behalf |
| Unit of access | A document or a space | A passage, embedded in a vector index |
| Access decision | Made once, at open time | Made per query, at retrieval time, invisibly |
| Discovery | Search returns what you can open | Search returns what the index holds, filtered late or not at all |
| Evidence of use | Access logs on a file server | A retrieval trace, if anyone built one |
| Cost of a bad document | Someone wastes ten minutes | Every retrieval pays for it in input tokens |
| Failure mode | Nobody finds the answer | The answer is confidently wrong and attributed to you |
The last row is the one that changes the risk calculation. A stale document in a human-era wiki is inert until someone opens it. The same document inside a retrieval corpus is a live participant in every answer that mentions its subject, and the employee reading that answer has no way to know which document it came from unless someone built citations and kept them.
So the working definition we use is narrower and more testable than the field's usual one. Knowledge management governance is the set of decisions and records that let you answer, for any answer your systems produced: which passages fed it, who asked, on whose authority, whether that authority was current, and what it cost. Taxonomy, templates, contribution incentives and the committee's meeting rhythm are instrumentation in service of that.
Why Human-Era Permissions Fail an Agent
Permissions written for humans fail agents for a structural reason: they were enforced at the point of opening a document, and a retrieval pipeline reads the document long before anyone decides whether to show it to you. Knowledge base access control was a door; retrieval turned it into a filter, and the filter sits somewhere nobody was watching. The permission check moved, and in most deployments it did not move with the same fidelity.
The peer-reviewed literature is blunt about how widespread the gap is. In Permission-Aware RAG: Identity and Access Management (IAM)-Based Access Filtering in Multi-Resource Environments, published in IEEE Access in 2025, Jooyoung Jeong and Sang Goo Lee note that "most existing RAG research implicitly assumes that all retrieved content is equally accessible to any user," and that this assumption fails in enterprises where data comes from several independently governed sources. Their proposed architecture puts a permission retriever, a credential manager and an IAM adapter between the vector store and the answer, which is a fair summary of the plumbing most internal deployments skip.
The security community reached the same conclusion from the attack side. OWASP's LLM08:2025 Vector and Embedding Weaknesses entry warns that in multi-tenant environments sharing one vector database "there's a risk of context leakage between users or queries," and that "embeddings from one group might be inadvertently retrieved in response to queries from another group's LLM, potentially leaking sensitive business information." Its remediation list reads like a knowledge base access control policy written by security engineers: implement fine-grained access controls and permission-aware vector and embedding stores, partition datasets logically, "tag and classify data within the knowledge base to control access levels," audit the knowledge base for poisoning, and "maintain detailed immutable logs of retrieval activities."
Note what that list is not: a content strategy. Every item is a governance artefact, and none of it belongs to the security team alone.
Microsoft's own deployment guidance for Microsoft 365 Copilot is the most useful public admission of the problem, because it comes from the vendor with the largest installed base of human-era permissions. The secure and governed data foundation blueprint, dated 6 May 2026, opens by describing Copilot as "grounding responses in the data users already have permission to access" and then organises the entire deployment around three pillars, the first of which is "Remediate oversharing." A product that only reads what the user could already open still needs an oversharing remediation programme in front of it, because "could already open" was never audited when nobody was systematically asking.
The instrument Microsoft ships for the interim is worth studying even if you never touch SharePoint, because it isolates a control surface the field did not previously have a name for. Restricted Content Discovery limits whether a site's content appears in organisation-wide search and Copilot responses, and the documentation is explicit that it "doesn't change existing permissions" and "doesn't remove content from the Microsoft 365 search index." It also removes the AI entry points from those sites, so users no longer see the Copilot button or the agent-creation menus there.
That is retrieval scope as a control separate from access permission, and separating them is the single most useful conceptual move available to a knowledge governance programme in 2026. A document can be legitimately openable by 4,000 people and still be a bad candidate for retrieval, because retrieval surfaces it without the context that made it safe - the folder it sat in, the meeting it came out of, the colleague who would have said "that one's out of date."
The operational cost of that control is a number worth quoting to anyone who thinks corpus hygiene is a two-week project. Microsoft's documentation states that for sites with more than 500,000 items, an update to Restricted Content Discovery "could take more than a week to fully process and reflect in search and Copilot experiences." Index propagation is measured in days, not minutes, which means retrieval governance decisions have latency and you cannot treat them as an emergency valve.
Practitioners report the softer version of the same failure. On Hacker News in February 2026, a commenter posting as carefulfungi was discussing a report that an assistant had summarised email carrying a sensitivity label with a data loss prevention policy configured, and added that "a DLP policy is apparently ineffective at its purpose." We could not independently verify that specific tenant behaviour and we are not asserting it as a product defect; we cite it as evidence of what administrators believe they are seeing, which is its own governance problem. When the people responsible cannot tell whether a control applied, the control has failed as evidence even if it worked as code.
The four questions traditional programmes never had to answer
| Question | Who used to answer it | Who answers it now |
|---|---|---|
| Was the requester entitled to this passage? | The file system, at open time | The retrieval layer, per query, before the model sees it |
| On whose behalf did the reader act? | Nobody asked; the reader was the person | The agent's identity plus the principal it impersonated |
| Which passages produced this answer? | Not applicable | Whatever citation and trace you built, or nothing |
| What did reading it cost? | Nothing measurable | Input tokens, on every single query |
If your governance documentation cannot answer all four for a query made last Tuesday, the programme is a content programme, not a governance programme. That is not a criticism of content programmes. It is a scope statement.
What Knowledge Management Governance Is Not
Knowledge management governance is not four things it gets confused with, and the confusions are expensive because each one sends the budget to a different team.
It is not a knowledge management strategy. Strategy answers "what is this programme for and which decisions should get better." Governance answers "who owns this, what are the rules, and how do we know they held." A strategy with no governance is a slide deck; governance with no strategy is a review queue nobody can justify. Most of the field's writing conflates them, and buyers end up purchasing a tool when they needed an owner.
It is not information governance or records management. Information governance is chiefly concerned with the lifecycle and legal disposition of records: retention schedules, legal hold, defensible deletion, regulatory classification. Knowledge governance is concerned with whether the organisation's working understanding is current, findable and correctly scoped. The two overlap at classification and access, and they answer to different stakeholders. Records management will happily retain a wrong document for seven years because the schedule says so. Knowledge governance needs it out of the retrieval path this week.
It is not data loss prevention. DLP guards the egress path: what leaves. Knowledge governance guards the ingress and retrieval paths: what enters the corpus, what may be pulled from it, and by whom. They are complementary and neither substitutes for the other. We have written separately on the egress half in our earlier analysis of inline AI data loss prevention at the gateway, which is the mirror image of the problem described here: DLP stops the prompt carrying your data out, retrieval governance stops the corpus feeding the wrong data in.
It is not agent memory. This is the newest confusion and the most consequential, because vendors sell "context" and buyers hear "memory." A retrieval corpus is a queryable store your systems read from; agent memory is state carried between turns and sessions. They fail differently, they are governed differently, and the protocol most often credited with providing memory does not. Our earlier analysis of why the Model Context Protocol is not a memory layer works through the specification on that point. For governance purposes the practical consequence is simple: governing your knowledge base does not govern what an agent remembers, and vice versa. You need policies for both and they are not the same policy.
| It is not | Which team owns that | What it protects | Where it overlaps knowledge governance |
|---|---|---|---|
| Knowledge management strategy | Business/ops leadership | The purpose of the programme | Governance implements it |
| Information governance | Legal, records, compliance | Legal disposition of records | Classification and access rights |
| Data loss prevention | Security | The egress path | Sensitivity labels feed both |
| Agent memory | Platform/AI engineering | Session and cross-session state | Both need retention and owner decisions |
| Search relevance tuning | Data/ML engineering | Answer quality | A governed corpus makes tuning honest |
Search relevance deserves the last row and a warning. The substitution runs like this: retrieval returns poor passages, the embeddings or the reranker take the blame, and a quarter goes into retrieval engineering. Sometimes that is right. But an engineering fix to a governance problem produces a system that retrieves stale, duplicated or wrongly-scoped material more precisely.
The Corpus Tier Model: Scoping a Knowledge Base an Agent Can Read
The most useful artefact a knowledge governance programme can produce in its first month is a tier model: a small number of named corpus tiers, each with a stated retrieval rule, so that scoping an agent becomes a one-line decision instead of a negotiation. Four tiers is enough for most organisations, and the discipline is to keep the count small enough that people remember it.
Four corpus tiers, each with one retrieval rule. Agents are scoped by tier, not by folder.
| Tier | Name | Contents | Retrieval rule | Default agent scope |
|---|---|---|---|---|
| T0 | Published | Approved, owned, in-date reference: policies, product facts, how-to guides, approved answers | Retrievable by any authenticated principal; always cited | In scope by default |
| T1 | Working | Live team material: project spaces, runbooks, decision records | Retrievable only for principals already in the owning group; citation mandatory | In scope only when the agent's owner is in that group |
| T2 | Restricted | Regulated or confidential: HR case files, unreleased financials, legal advice, security findings | Not retrievable by general-purpose agents; named agents only, with a human approval gate on the workflow | Out of scope by default; explicit grant required |
| T3 | Excluded | Drafts, rejected proposals, personal scratch space, superseded material, unowned orphans | Never retrievable; indexed for records purposes only if legally required | Never |
Three rules make the model work, and each of them is the answer to a way it normally fails.
Default deny at the tier, not at the document. If the model requires someone to classify 400,000 documents before anything can be governed, nothing will be governed. Assign tiers to containers - spaces, sites, libraries, repositories - then let owners promote documents upward. Promotion is cheap and reviewable; document-by-document classification is neither.
T3 is where the value is, and it is the tier everyone skips. Most organisations hold more excluded-by-rights material than published material, and it is the excluded material that produces the failure the Hacker News commenter described: rejected RFCs, half-built runbooks, an old pricing sheet nobody deleted. Deciding that abandoned drafts are never retrievable takes one meeting and removes a whole class of confident wrong answers.
A tier is not a permission; it is a retrieval eligibility. This is the point where knowledge base access control stops being a copy of the file system's permission model and becomes its own decision. This is the distinction Microsoft's Restricted Content Discovery isolates, and it is what lets you make progress without re-permissioning the estate. You are not telling people they may no longer read something. You are telling the retrieval layer that the passage is not eligible to be pulled into an answer. That is a much cheaper decision to make, and a much cheaper one to reverse.
The prerequisites, honestly stated
Four things need to exist before the tier model is worth drawing. Without them it is a diagram nobody can enforce.
| Prerequisite | Why it is required | Cheapest acceptable version |
|---|---|---|
| A container inventory | You cannot tier what you cannot list | An export of every space, site and repository with its item count and last-modified date |
| A named owner per container | A tier with no owner cannot be promoted, reviewed or retired | A single human name and a single deputy per container; no team aliases |
| An identity for every retrieval caller | Tier rules are meaningless if calls arrive anonymously | Every agent and pipeline holds its own credential, never a shared service account |
| A retrieval log you can query | Otherwise you cannot verify any of it | One append-only table with the five fields in the next section |
The third row is the one that most often blocks a programme, and it blocks it silently. A single shared service account reading the whole corpus on behalf of everyone makes every tier rule unenforceable and every log entry useless, because the log will record the same principal for every query in the company. We have written about the identity half of this problem in our earlier analysis of owner, scope and expiry for non-human identities.
The Five-Field Retrieval Record
A retrieval record is a per-query log entry that makes an answer auditable after the fact. Five fields are enough, and we name it the Five-Field Retrieval Record so that teams have something short to argue about in a design review: requester, principal, passages, entitlement, spend. Anything less and you cannot reconstruct why an answer contained what it contained.
| Field | What it holds | The question it answers | Failure if omitted |
|---|---|---|---|
| Requester | The non-human identity that made the call: agent name, version, owner | Which system asked? | You cannot revoke or scope anything, because you cannot tell callers apart |
| Principal | The human or service on whose behalf it acted, resolved at request time | On whose authority? | Every entry looks identical; entitlement is unprovable |
| Passages | Stable identifiers for the retrieved chunks, plus their tier and document version | Which sources fed this answer? | You cannot answer "where did that come from" or remediate a poisoned document |
| Entitlement | The rule that permitted it, and its evaluation result, including refusals | Was this allowed, and how do we know? | Refusals vanish; you can only prove what happened, never what was prevented |
| Spend | Input tokens attributed to retrieved context, and the cost centre | What did this cost, and who pays? | Corpus bloat is invisible until the invoice |
Most retrieval stacks will not emit all five fields out of the box, and several will not emit entitlement at all. The practical fallback is to log at the layer you control rather than the layer you wish existed: if the orchestration code decides which passages to send, it can write the record itself, even when the vector database has no concept of a principal. Where a field is genuinely unobtainable, write down which one and why, because that gap is the honest description of what your programme can currently prove.
One caution before the fields become a shopping list. A retrieval record naming the human principal behind every query is personal data in most jurisdictions, and a log that records what each named employee asked about is more sensitive than it first looks. Decide the lawful basis, the retention period and the access rules for the log itself, minimise the fields you keep beyond the retention floor, and put the log under the same tier model as everything else. A governance artefact that creates a new surveillance dataset by accident has traded one problem for a worse one.
The entitlement field carries the load that most implementations drop. Logging what was retrieved is comparatively easy. Logging what was refused - the passages the tier rule excluded, and which rule excluded them - is what converts a log into evidence, because a regulator or an internal auditor asking whether a control worked is asking about the refusals. Recording refusals is a design principle we build our own observability and audit layer around, and we have written up the general case in our earlier analysis of proving what an agent actually did.
How the record maps to regulation
If any of your AI systems fall into the EU AI Act's high-risk categories, several of these fields stop being good practice and start being obligations. Two provisions matter most for a knowledge corpus.
Article 12 requires that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system," with logging sufficient to identify risk situations and support post-market monitoring. For the biometric category in Annex III the minimum record explicitly includes "the reference database against which input data has been checked by the system." That phrase is worth sitting with: the regulation already contemplates the corpus as a logged object, not just the query.
Article 26 is the deployer's side, and it contains the provision most directly relevant to a knowledge base. Paragraph 4 states that "to the extent the deployer exercises control over the input data, that deployer shall ensure that input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system." In a retrieval system the corpus is the input data, and you control it entirely. Paragraph 6 requires deployers to keep the automatically generated logs "for a period appropriate to the intended purpose... of at least six months."
Article 10 then sets the quality bar for data sets themselves, requiring that they be "relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose," and that data governance practices cover design choices, collection processes, the origin of data, and preparation operations including "annotation, labelling, cleaning, updating, enrichment and aggregation."
| Provision | What it requires | The governance artefact that satisfies it |
|---|---|---|
| Article 10(2)-(3) | Data governance practices; data sets relevant, representative, error-free as far as possible | Tier model, owner register, review cadence, provenance on ingest |
| Article 12 | Automatic event logging over the system lifetime; reference database recorded for the biometric category | The Five-Field Retrieval Record, retained |
| Article 26(4) | Deployer-controlled input data must be relevant and sufficiently representative | Corpus curation with a documented exclusion policy (T3) |
| Article 26(6) | Deployers keep logs at least six months | A retention decision on the retrieval log, written down |
Two caveats. These obligations bite for high-risk systems as classified by the Act, and an internal search assistant may well not be one; that is a legal question about your use, and this is not legal advice. And the Act phases in, with the record-keeping article's applicability date shown on the reference above as 2 August 2026. Our argument is narrower than compliance: the artefacts that satisfy these provisions are the ones that make a corpus governable at all, so building them is defensible even if you are never in scope.
Frameworks outside Europe point the same way. NIST's AI Risk Management Framework describes its GOVERN function as one that "cultivates and implements a culture of risk management" and that "addresses full product lifecycle and associated processes, including legal and other issues concerning use of third-party software or hardware systems and data." A knowledge corpus assembled from wikis, ticket systems, vendor documentation and email is third-party data at scale. ISO/IEC 42001:2023, described by ISO as "the world's first AI management system standard," provides the management-system scaffolding for the same set of decisions. Neither tells you what your tiers should be. Both expect you to have decided.
Ownership: Humans and Non-Human Identities in One Register
Ownership is where knowledge governance programmes are usually strongest on paper and weakest in practice, because the register they build lists only people. Knowledge assets acquired a second class of reader and the register never noticed. The fix is small and structural: one register, two kinds of entry, the same required fields for both.
The traditional half is a straightforward responsibility assignment, and it is worth writing down even if it feels bureaucratic, because every dispute you will have for the next two years is a dispute about one of these cells.
| Activity | Content owner | Subject matter expert | Knowledge lead | Security / privacy | Steering group |
|---|---|---|---|---|---|
| Assign a container's tier | Recommends | Consulted | Approves | Consulted for T2 | Escalation only |
| Promote a document to T0 | Accountable | Reviews | Audits samples | Not involved | Not involved |
| Grant an agent access to T2 | Recommends | Consulted | Consulted | Approves | Informed |
| Set the review cadence | Consulted | Consulted | Accountable | Consulted | Approves the standard |
| Retire or tombstone a document | Accountable | Consulted | Informed | Informed | Not involved |
| Approve an exception to a tier rule | Requests | Consulted | Recommends | Consulted | Approves |
| Review the retrieval log for refusals | Informed | Not involved | Accountable | Reviews monthly | Sees the summary |
The second half of the register is the one almost nobody has. Every non-human identity that reads the corpus needs the same fields you would demand of a person with equivalent access.
| Field | Human entry | Non-human entry |
|---|---|---|
| Name | The person | The agent, with version |
| Owner | Their manager | A named human, not a team |
| Purpose | Their role | The task it exists to do, one sentence |
| Tiers granted | T0, T1 for their groups | Explicit list; T2 only by exception |
| Expiry | Employment | A date, always; renewal requires the owner to reconfirm |
| Offboarding trigger | Leaver process | Owner departure, project end, or expiry, whichever comes first |
| Log identity | Their account | Its own credential, never shared |
The expiry row is the one that pays for itself. Human access is revoked by an event everyone already has a process for: someone leaves. Agent access has no such event, so unless you attach a date, an agent provisioned for a three-week pilot in 2025 is still reading your restricted tier today, owned by someone who has since moved teams. Attaching an expiry date turns the absence of a leaver event into a scheduled decision. Our own access and identity approach treats non-human identities as first-class for exactly this reason: an agent with an owner, a scope and an expiry can be offboarded in one step, and one without those fields cannot be offboarded at all.
The steering committee question, answered honestly
Most writing on this topic tells you to form a steering committee first. We would put it third, and we would keep it small, because a committee formed before there is anything to decide becomes a status meeting and then becomes nothing. The order that works is: inventory and owners first, tier model second, then a small group with the authority to arbitrate tier disputes and approve exceptions.
Oversight here means something narrower than the word usually carries. What the group must actually have is authority over three specific things: the tier standard, exceptions to it, and the review cadence. If it cannot decide those without escalating, it is a working group and you should call it one. A monthly meeting that reviews the refusal summary from the retrieval log and rules on the exception queue is a real governing body. A quarterly meeting that receives an adoption dashboard is theatre.
Staleness as an Enforced Policy, Not a Good Intention
Every knowledge lifecycle model ends with a review-and-retire stage, and every knowledge programme has a review policy to match. Almost none of them enforce it, because enforcement means something has to happen automatically when a review date passes, and the only options anyone likes are the two that do nothing: an email reminder, or a small "last reviewed" badge nobody reads.
Retrieval changes the economics of that choice. A stale document that nobody opens costs nothing. A stale document in the retrieval corpus is pulled into answers, paid for in tokens, and cited to the reader as though it were current. So the enforcement action does not have to be deletion, which is what makes it politically possible: the enforcement action is demotion out of the retrieval path.
| Content class | Review cadence | Action on expiry | Rationale |
|---|---|---|---|
| Policy, compliance, security guidance | 6 months | Demote T0 to T1; owner notified; retrieval marks it "unreviewed" | Wrong policy guidance is the highest-consequence stale answer |
| Product and pricing facts | 3 months, or on release | Demote to T3 immediately | Ships faster than any review cycle can track |
| Customer-facing approved answers | 3 months | Demote to T1; remove from T0 citation set | The blast radius reaches outside the company |
| Process and runbooks | 12 months | Flag; demote after a second missed review | Slow-changing but high-trust |
| Decision records and post-mortems | Never expire | Never demote; mark superseded when replaced | Historically valuable precisely because they are dated |
| Project and working material | On project close | Auto-demote to T3 at close | The single largest source of confident wrong answers |
| Drafts and personal scratch | Not reviewed | Never eligible for retrieval | Cheapest rule in the whole model |
Three mechanisms make the cadence real, and all three are cheap relative to a re-permissioning project.
Ingest-time metadata, not retro-fitted metadata. Owner, tier, review date and source system get attached when a document enters the corpus. Retro-fitting them across an existing estate is the project that never finishes; requiring them on new ingest is a one-line rule that starts working immediately and makes the backlog a known, shrinking quantity rather than an unbounded one.
Supersession instead of deletion. When a document replaces another, the old one gets a tombstone: it leaves the retrieval path, keeps its identifier, and points at the replacement. Deletion breaks citations and destroys the audit trail; tombstoning keeps both while removing the document from circulation. Decision records are the clearest case - a 2024 architecture decision that was later reversed is genuinely valuable, and genuinely dangerous to retrieve without the reversal.
A human approval gate on promotion to T0. Publishing into the tier every agent can read changes more answers than any other single action in the system, and it is the one action that should require a person. This is the same argument as our earlier analysis of when approval is the control: gate the step where reversal is expensive, and leave the rest alone. Reviewing every edit is unaffordable and does not help. Reviewing every promotion into the corpus every agent reads is affordable and helps enormously.
One thing to resist: making agents responsible for enforcing their own corpus hygiene without a gate. Auto-summarising, auto-tagging and auto-flagging are genuinely useful and we would use them. Auto-publishing into T0 means the corpus that grounds your answers is being written by the same class of system that reads it, with no human in the loop, and the failure compounds quietly.
What an Ungoverned Corpus Costs Per Query
Governance arguments usually stall at budget, because the benefit is a risk reduction and the cost is a headcount. Retrieval gives you a second, harder argument: an ungoverned corpus is a recurring line item, and you can size it with published prices and arithmetic.
The mechanism is simple. Every retrieved passage is placed into the model's input on every query that retrieves it. Input tokens are billed. So a corpus carrying material that should never have been eligible for retrieval is not merely a risk; it is a subscription.
Here is the derivation. The assumptions are ours and they are illustrative, not measured - substitute your own and the shape holds. Take a passage of roughly 700 tokens, a query that retrieves some number of passages, and a fixed overhead of about 1,600 tokens for the system prompt and the question. Prices are per million input tokens from OpenAI's published pricing, fetched 30 July 2026: gpt-5 at $1.25 per million input tokens, and a top-tier model at $5.00.
| Passages retrieved | Input tokens per query | Cost at $1.25/M | Cost at $5.00/M | Annual at 3M queries, $1.25/M | Annual at 3M queries, $5.00/M |
|---|---|---|---|---|---|
| 6 | 5,800 | $0.0073 | $0.029 | $21,750 | $87,000 |
| 12 | 10,000 | $0.0125 | $0.050 | $37,500 | $150,000 |
| 24 | 18,400 | $0.0230 | $0.092 | $69,000 | $276,000 |
Three million queries a year is 2,000 employees asking six retrieval-backed questions each across 250 working days. Change that number first if your population differs.
Now the governance line. Suppose four of the twelve retrieved passages are material a tier model would have excluded: superseded pricing, a rejected proposal, a project space closed eighteen months ago, a personal runbook. Those four passages are 2,800 tokens, or 28% of the input on every query.
| Metric | At $1.25/M input | At $5.00/M input |
|---|---|---|
| Annual input spend, 12 passages, 3M queries | $37,500 | $150,000 |
| Share attributable to excludable passages (4 of 12) | 28% | 28% |
| Annual spend on material that should not be retrievable | $10,500 | $42,000 |
We want to be precise about what this is and is not. The four-in-twelve figure is an assumption we chose to make the arithmetic legible; we have not measured the excludable share of any real corpus and we are not claiming a benchmark. The point is not the total. The point is that the calculation exists, that it is a line on a cloud bill rather than a hypothetical, and that you can compute your own version in an afternoon from your retrieval log if the log records the fifth field. Without the spend field, this whole argument is unavailable to you.
A second cost is harder to bound and probably larger: a wrong retrieved passage produces a wrong answer someone acts on, and the rework lands in a team with no idea the knowledge base was involved. We will not put a number on that, because any number we produced would be invented. The token line is the part you can prove, and it is usually enough to fund the inventory.
Model choice interacts with all of this: retrieval-heavy, low-stakes internal questions do not need your most expensive model, and privacy-sensitive tiers may need one that never leaves your boundary. Our earlier analysis of how model routing cuts LLM costs covers that per-task decision.
The Rollout: Observe, Enforce, Optimise, Applied to a Corpus
The sequencing mistake worth naming first is enforcing before observing: a programme writes a tier standard, applies it to the estate, and discovers in week three that half the retrieval traffic it just blocked was the one legitimate use everybody depended on. Our gateway rollout guidance states the order as "Observe first. Enforce second. Optimize third." and the same three phases transfer cleanly to a knowledge corpus.
Phase 1, Observe - weeks 1 to 3. No rules yet.
- Export the container inventory: every space, site, repository and shared drive that feeds retrieval, with item counts and last-modified dates. The count matters because propagation latency scales with it; recall Microsoft's note that sites over 500,000 items can take more than a week for a discovery change to take effect.
- Turn on retrieval logging with all five fields. If you can only get four, drop passages last and never drop principal.
- Instrument nothing else. Let it run for two weeks and answer three questions from the log: which containers actually get retrieved from, which principals do the retrieving, and what the input-token spend per query looks like.
- Publish the truth before proposing rules. The observation almost always shows that a small number of containers serve most retrievals, which is what makes the next phase affordable.
Phase 2, Enforce - weeks 4 to 8. Smallest enforceable rule set.
- Assign a tier to every container in the inventory. Default everything unowned to T3. Resist per-document classification.
- Name an owner and a deputy for every container above T3. A container that cannot get a named owner in a week is a T3 container; that is the decision, not a failure.
- Turn off retrieval eligibility for T3. This is the first enforcement action and it should be reversible in a day, which is why it is first.
- Put the human approval gate on promotion into T0.
- Set expiry dates on every non-human identity that reads T1 or above. Existing agents without an owner get a 30-day expiry, not an exemption.
- Start the monthly refusal review: the governing group reads what the tier rules blocked and rules on the exception queue.
Phase 3, Optimise - week 9 onward. Now tune.
- Work the review cadence table into the ingest pipeline, so review dates arrive with documents rather than being applied later.
- Attribute retrieval spend to cost centres and give owners their own number.
- Now, and only now, tune retrieval: reranking, chunk sizes, embedding choices. Relevance work on a governed corpus improves answers; the same work on an ungoverned one improves the precision with which you retrieve the wrong thing.
- Revisit the tier model quarterly against the refusal log. Rules that never fire are either perfect or unenforced, and the log tells you which.
Holding enforcement until week 4 is not caution for its own sake. The observation phase generates the evidence you need to survive the first complaint, and the first complaint arrives within days of the first enforcement action.
A Complete Worked Example: One Confluence Space in Two Weeks
Abstract governance models are easy to agree with and hard to start. So here is one filled-in artefact for a single container, at the level of specificity a real programme would need. The organisation, the space and the names below are a worked illustration, not a customer engagement: we are showing the shape of the completed artefact, not reporting something we ran.
Container: ENGDOCS - engineering documentation space, 18,400 items, last bulk edit 14 months ago, currently readable by all employees.
Step 1. Observation, before any rule. Two weeks of retrieval logging produce the following, and this table is the thing that funds the rest of the work.
| Observation | Value | What it implies |
|---|---|---|
| Retrievals from ENGDOCS in 14 days | 4,120 | Genuinely load-bearing; cannot simply be excluded |
| Distinct documents retrieved | 210 of 18,400 | 1.1% of the space serves all of the traffic |
| Retrievals hitting the archive subtree | 38% | More than a third of value delivered from material nobody has reviewed |
| Distinct principals | 6 | Five of six are one shared service account: the log is nearly blind |
| Mean input tokens per query | 9,600 | Baseline for the spend field |
The fourth row is the finding that reorders the plan. With five of six callers sharing one credential, no tier rule can be enforced and no entitlement can be proved, so credential separation moves ahead of classification.
Step 2. The filled-in container record. One record per container; this is the whole artefact, not an excerpt.
| Field | Value |
|---|---|
| Container | ENGDOCS (Confluence space) |
| Tier | T1 Working, with a T0 subtree at ENGDOCS/published |
| Owner | Head of Platform Engineering (named individual) |
| Deputy | Staff engineer, developer experience (named individual) |
| Review cadence | Runbooks 12 months; the published subtree 6 months |
| Expiry action | Demote to T3, tombstone in place, owner notified 14 days ahead |
| Retrieval eligibility | T0 subtree: all authenticated principals. T1 body: principals in eng-all. Archive subtree: excluded |
| Excluded subtrees | /archive, /drafts, /personal, /incident-2024 (superseded by the post-mortem register) |
| Agents granted | support-answer-bot v3 (T0 subtree only, expiry 2027-01-31); oncall-assistant v1 (T0 plus runbooks, expiry 2026-10-31) |
| Approval gate | Promotion into /published requires owner or deputy approval |
| Log retention | 12 months, exceeding the six-month floor in Article 26(6) |
| Cost centre | Platform Engineering |
| Exceptions | One: oncall-assistant may retrieve /incident-2024 during an active incident, approved by the governing group, reviewed quarterly |
Step 3. What actually got done in fourteen days.
| Day | Action | Outcome |
|---|---|---|
| 1-2 | Export inventory; identify the archive, drafts and personal subtrees | 11,900 of 18,400 items are candidates for exclusion |
| 3 | Owner and deputy named and confirmed in writing | Ownership exists for the first time |
| 4-5 | Split the shared service account into per-agent credentials | The log becomes usable; two undocumented callers surface |
| 6 | Exclude /drafts and /personal from retrieval eligibility | 2,300 items out of the retrieval path; no permission changed |
| 7-8 | Create /published; promote the 60 most-retrieved documents after owner review | A T0 set exists and is small enough to review honestly |
| 9 | Exclude /archive; add the one incident exception | 9,600 items out; the 38% archive traffic is reviewed rather than blocked blindly |
| 10 | Set expiry dates on both agents | Neither can outlive its owner's attention |
| 11-12 | Attach review dates to the published set; wire the approval gate | Cadence becomes mechanical |
| 13 | Re-measure input tokens per query | Retrieval now draws from a curated set; the new baseline is recorded |
| 14 | First refusal review with the governing group | Two exception requests, one granted |
Two rows in that table are optimistic and it would be dishonest to leave them unmarked. Splitting a shared service account into per-agent credentials is a two-day job only when the retrieval service already supports on-behalf-of flows and the connectors can broker credentials per caller; where it does not, this is weeks of platform work and it should be scheduled as such. And naming an owner takes a day only when someone senior has already decided that owning a space is part of somebody's role. Where nobody will accept the name, the correct outcome is not a longer search: the container drops to T3 and stops being retrievable, which is usually what converts a refusal into a volunteer.
Two things about this example are deliberate. Nobody's read access was removed - every exclusion is a retrieval-eligibility decision, which is why it fits in two weeks. And the credential split landed before the classification work, because until callers are distinguishable, every other control is unverifiable. If you take one sequencing lesson from the whole article, take that one.
Common Mistakes That Make Retrieval Governance Fail
Each of these either appears in a source cited above or follows directly from one. We are not reporting a survey and we have not counted them in the field; the ordering below is our judgement about which cause the most damage, not a measured frequency.
One shared service account reads everything. The most damaging of the set, because it silently voids every other control. Fixing it is unglamorous credential work with no visible feature at the end, which is why it gets deferred. Defer it and your retrieval log records one principal for the entire company.
Classifying documents instead of containers. A programme that begins by classifying documents produces a spreadsheet, a stalled quarter and no enforcement. Tier the containers, let owners promote upward, accept the imprecision.
Treating relevance engineering as the fix. Better embeddings retrieve the wrong document more accurately. Governance first, tuning third. This is the substitution the phase ordering exists to prevent.
Logging retrievals but not refusals. A log of what happened proves activity. A log that includes what was blocked, and by which rule, proves control. The second is what an auditor is asking for.
Agents publishing into the corpus they read. Auto-capture and auto-tagging are good. Auto-publishing into the tier that grounds every answer removes the last human checkpoint in the loop, and the resulting drift is very hard to detect from inside the system.
No expiry on non-human identities. There is no leaver event for an agent. Without a date, pilot credentials become permanent, and the register that was supposed to describe your access surface describes a snapshot from a project that ended.
Measuring adoption instead of governance. Page views, contribution counts and search volumes tell you the programme is being used. They tell you nothing about whether the corpus is correctly scoped. Adoption metrics are the ones that survive a budget review and the ones that hide a leak.
Where This Is Still Uncertain
Several things in this article are less settled than the confident register of governance writing usually admits, and it is worth naming them rather than letting the tables imply more certainty than exists.
We have no measurement of the excludable share of a real corpus. The four-in-twelve assumption in the cost section is an illustration chosen to make arithmetic legible. We do not know the real distribution, we could not find a credible published measurement of it, and if yours turns out to be one in twelve the cost argument shrinks accordingly. The formula is the deliverable; the number is a placeholder for yours.
Tier counts are a judgement, not a finding. Four tiers is what we would start with because it stays memorable. We have no evidence that four beats three or five, and organisations with strong existing classification schemes should map onto what they have rather than adopt ours.
The legal position is genuinely unsettled for internal tools. Whether an internal knowledge assistant is a high-risk AI system under the EU AI Act depends on its use, and reasonable advisers currently disagree. We cite the Act's provisions because the artefacts they require are useful regardless. Nothing here is legal advice, and the applicability dates for individual articles differ.
Sources a reader would expect are missing, and we would rather say so. ISO 30401 and ISO/IEC 42001 sit behind a paywall - CHF 155 and CHF 225 at the time of writing - so we cite scope, status and publication metadata from ISO's catalogue pages and do not quote clause text we have not purchased. Gartner's material on knowledge management systems is widely cited by vendors here and returned 403 to every fetch we attempted, so it is excluded rather than paraphrased. We also found no verifiable industry benchmark for knowledge decay rates or the cost of duplicated internal documentation; the circulating figures trace back to unsourced vendor posts, and we left them out.
The staleness cadences are conventions, not evidence. Six months for policy and three for pricing reflect how fast those things change in most organisations. They are not derived from a study. Treat the table as a starting proposal for your governing group to argue with.
Enforcement latency may be worse than anyone plans for. The one hard propagation figure we could source - over a week for sites above 500,000 items - comes from one vendor's documentation about one control. Whether your stack behaves similarly is an empirical question to answer in the observe phase rather than assume. We have not run this programme end to end ourselves; where something above is marked illustrative, that marking is doing real work.
Where LeapForce Fits
LeapForce does not sell a knowledge base, a wiki, or a search product, and nothing in this article should be read as suggesting you replace the systems your knowledge already lives in. What we build is the control layer around AI use: one governed endpoint for every model and agent, identity and scope for non-human callers, connectors IT vets once, and a record of what ran and what was refused.
That maps onto three of the artefacts above. Non-human identities with an owner, a scope and an expiry are how the agent half of the ownership register stops being a spreadsheet - our access and identity approach treats them as first-class rather than as service accounts with extra steps. The requester, principal and entitlement fields of the Five-Field Retrieval Record are the kind of thing our observability and audit layer is designed to record, including refusals rather than only successes. And the spend field is a routing and budget question as much as a logging one, which is where our AI gateway and its rollout order - observe first, enforce second, optimise third - sit. LeapForce is in active development and per-capability build status is published honestly on those pages; check them rather than assuming everything described is generally available today.
The tier model, the owner register and the review cadence are yours to run, in whatever tooling you already have. No platform decides that a rejected RFC should never be retrievable. A platform can make that decision enforceable and auditable once you have made it.
Frequently asked questions
Knowledge management governance is the set of owners, policies, access tiers, review cadences and logs that determine what enters an organisation's knowledge base, who or what may retrieve each part of it, and how that is evidenced afterwards. In a pre-AI programme it mostly governed publishing and review. Once a retrieval system reads the corpus on an employee's behalf, it also governs access decisions made per query, which is a different discipline with different artefacts.
Strategy sets the purpose: which decisions should get better, for whom, and how you would know. Governance is the machinery that makes it hold: named owners, written rules, tiers, cadences and evidence. The practical test is that a strategy can be presented and a governance model can be audited. If your document says what good looks like but does not name who decides, who approves exceptions, and where the record lives, it is a strategy that has not yet produced governance.
You need a small group with real authority over three things: the tier standard, exceptions to it, and the review cadence. Form it third, after the container inventory and the owner assignments, because a group formed before there is anything to decide becomes a status meeting. A monthly session that reviews what the retrieval rules refused and rules on the exception queue is a governing body; a quarterly session that receives an adoption dashboard is not.
Information governance manages the legal lifecycle of records: retention schedules, legal hold, defensible deletion, regulatory classification. Knowledge governance manages whether the organisation's working understanding is current, findable and correctly scoped for retrieval. They overlap at classification and access rights and answer to different stakeholders. Records management will retain a wrong document for seven years because the schedule requires it; knowledge governance needs that document out of the retrieval path this week, which is a demotion rather than a deletion.
The structural model shapes how knowledge sharing feels day to day, but it matters less than whether every container has a named human owner and every retrieval caller has its own credential. Centralised models give consistency and become a bottleneck at scale; distributed models move fast and drift; federated models set the standard centrally and delegate execution, which is where most organisations of any size end up. Pick federated as a default, then check the harder question: can you name the owner of any given space in under a minute? If not, the model is not your problem.
For one container, two weeks is realistic if you exclude rather than re-permission: inventory, owners, credential separation, exclusion of drafts and archives, a small published tier, expiry dates on agents. For a whole estate, plan in containers rather than in a single programme, and expect propagation delay in the tooling. Microsoft's documentation notes that for SharePoint sites over 500,000 items, a discovery-scope change can take more than a week to reflect in search and Copilot results, so build latency into the schedule.
Six things, and it can be two pages. Together they are the whole knowledge governance framework; anything else belongs in guidance. A tier definition with a retrieval rule per tier. A statement that unowned containers default to the excluded tier. Required metadata at ingest: owner, tier, review date, source. A review cadence per content class with a stated action on expiry, which should be demotion rather than deletion. The rule that promotion into the tier every agent can read requires human approval. And the retrieval log's field list and retention period. Everything longer than that tends to be aspiration rather than policy.
Adoption metrics - page views, contributions, searches - show the programme is used and hide whether it is governed. Report instead: percentage of retrieved containers with a named owner, percentage of retrievals from documents inside their review window, count and reason of refusals per month, number of non-human identities without an owner or expiry, and input-token spend per retrieval-backed query with its trend. Those five change behaviour because each one names something a specific person can fix.
Possibly, and it depends on classification rather than on the knowledge base itself. The Act's data-governance and logging obligations attach to high-risk AI systems, and whether an internal assistant is one is a legal question about its use. What is worth knowing is that Article 26(4) requires deployers who control the input data to ensure it is "relevant and sufficiently representative," and in a retrieval system the corpus is that input data. Article 26(6) requires deployers to keep automatically generated logs for at least six months. This is not legal advice, and applicability dates differ by article.
Because the committee has nothing enforceable to decide. Without a container inventory it cannot assign tiers; without named owners it cannot approve promotions; without a retrieval log recording distinct principals it cannot verify that any rule worked, so it falls back on adoption reporting. The other common stall is a shared service account: when every retrieval arrives under one credential, no entitlement rule can be enforced and the group's decisions have no mechanism. Separate credentials before writing rules.
Partly, and the boundary matters. Agents are genuinely good at drafting summaries, proposing tags, spotting near-duplicates, flagging documents past their review date and nudging owners. Let them do all of that. What they should not do is publish into the tier that grounds every answer, because then the corpus your systems read is being written by the same class of system with no human checkpoint, and the drift is hard to see from inside. Keep a human approval gate on promotion; automate everything up to it.
The visible cost is people: a part-time knowledge lead, named owners spending an hour a month each, and one engineer for credential separation and logging. The argument that funds it is on the invoice. Every retrieved passage is billed as input tokens on every query, so material that should never have been retrievable is a recurring charge. At three million retrieval-backed queries a year and twelve passages per query, published list prices put annual input spend between roughly $37,500 and $150,000 depending on model tier - and whatever share of those passages a tier model would have excluded is spend on material you did not want retrieved. Compute your own share from the retrieval log's spend field.
Ready to Govern Your AI?
Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.
Comments