Enterprise chatbots: organise knowledge and access

An enterprise chatbot that answers the question "what is our renewal price?" with the wrong version of a document is not an artificial intelligence problem: it is a problem of knowledge organisation and access rights. Semantic search finds relevant text; it does not decide who is allowed to read it. This article describes how to structure a multi-team knowledge base, where to place permission filtering, how to manage versions and validity, and which tests to run before opening the chatbot to your teams.

Why search alone is not enough to authorise

A search engine, semantic or not, answers a question of relevance: does this paragraph look like the query? Authorisation answers a different question: is this user allowed to see this content? The two operations must remain separate, because an answer can be perfectly relevant and strictly forbidden to the person asking for it.

The most common risk arises when the chatbot builds a single index of all documents, then filters "after the fact" in the generated response. If the model has already received the forbidden content in its context, filtering the final text is cosmetic: details can leak out, rephrased differently. Filtering must therefore happen before the context is sent to the model, on the server side, over the list of documents authorised for the identified user.

This has a design consequence: your chatbot must know the user's identity at the moment of the question, not only at login. An anonymous session or a generic team identifier makes filtering impossible. If you connect the chatbot to other tools with their own permissions, our guide on connecting your tools: APIs, MCP and authorisations explains why the transport protocol does not choose the business rules for you.

Three distribution levels: public, internal, individual

Before writing a single line of index, classify your content into three distribution levels, distinct from perceived sensitivity.

• Public: content you can show externally, for example a returns policy published on your website or a product guide intended for customers.
• Internal: content shared company-wide or within a team, such as a recruitment procedure or a margin table by product line.
• Individual: content attached to a person, such as their expense reports, their appraisals or their contract drafts.

The real difficulty lies at the boundaries. A negotiation report with a client is internal for the sales department, but its content may be individually identifiable for the participants. An "internal" document that names an employee changes in nature as soon as an assistant can relay it to someone else. Classification must therefore be done document by document, not by folder, and reviewed whenever a document's content changes.

The fictional case: HR, sales and customers

Let's take an explicitly fictional example. An SME with 80 employees deploys a chatbot over its knowledge base. Three populations use it: HR, the sales team and end customers via a portal.

HR consults internal salary grids and disciplinary procedures. Sales reps consult discount grids and product sheets, but not salaries. Customers consult the general terms and conditions and published product sheets, but neither negotiated discounts nor anything internal.

Without server-side filtering, an innocuous question from a customer — "do you offer discounts for large volumes?" — can surface an extract from the internal discount grid, with percentages that should never have been visible. The answer is factually correct and commercially disastrous. This scenario is hypothetical, but every element of it is plausible: the leak does not come from an exotic flaw, it comes from a single index with no permission boundary at search time.

Server-side filtering: the principle and its implementation

The principle is simple to state: the search query only covers the subset of documents authorised for the current user. Concretely, each document carries distribution metadata (level, owning team, list of exceptions), and each user query is accompanied by the user's resolved identity. The server combines these two pieces of information to build the allow list before any vector or keyword search.

Three design rules reduce errors:

1. Closed by default: a document without distribution metadata is indexed nowhere, or only in a review bin. A forgotten label must never mean broad distribution.
2. Controlled inheritance: if a document inherits rights from its folder, any file move must trigger a review, because silent inheritance is a classic source of divergence between what the team believes and what the index sees.
3. Access log: keeping a record of who asked what, and which documents fed the response, makes it possible to audit a leak or correct a classification. Our checklist on AI agent permissions offers a control structure you can adapt.

An often-overlooked point: the filter must also apply to summaries, titles and excerpts displayed in the interface, not only to the generated text. A document title alone can reveal sensitive information.

Versions and validity: when two sources contradict each other

A living knowledge base almost always contains documents that contradict one another: a 2023 remote-work policy and its 2025 revision, two product sheets one of which was never withdrawn, an internal note contradicting an email from management. A chatbot that does not manage validity will answer with the source that is most "semantically close" to the question, not the most up to date.

Version management requires three minimal pieces of metadata: an effective date, an expiry or withdrawal date, and a link to the document it replaces. At search time, expired documents are excluded from the context — or, if you prefer to keep them consultable, explicitly flagged as outdated in the response.

Example of how to handle a detected contradiction: the chatbot receives two sources with identical distribution levels, one dated March 2025 and the other January 2026, which give different discount rules. The response must not silently pick a side. It must cite both sources with their dates, indicate which is the more recent and whose content it retains, and suggest verifying with the document owner. This behaviour must be specified at design time; it will not appear spontaneously.

The same reasoning applies to extracts from structured documents. Our article on document automation: extraction, evidence and control shows how to keep a trace of the source document for every piece of data returned — a practice that becomes indispensable when several versions coexist.

Decision table: where to classify a document

Situation	Proposed distribution level	Condition for entering the index
Policy published on the website	Public	Marketing and legal review completed
Product sheet intended for customers	Public	Version validated, old versions withdrawn
Team procedure (e.g. HR onboarding)	Internal, owning team	Team label mandatory
Sales discount grid	Internal, sales team	Explicit exclusion of other teams
Individual data (expenses, appraisals)	Individual	Strict filtering by user identifier
Document without a clear label	None	Out of the index until classified
Note containing people's names	Internal or individual	Review before indexing
Old replaced version	Out of the index	Kept in archive, never returned

This table is a decision framework, not an obligation: adapt the levels to your organisation, but keep the closed-by-default rule.

Procedure: opening a new corpus to the chatbot

Here is an actionable procedure for adding a team to the knowledge base, step by step.

1. Inventory: list the team's folders, with approximate volumes and named owners. A document without an owner is a document without a distribution decision.
2. Classify: assign each document a level (public, internal, individual) and, for internal, the team or list of exceptions. Handle duplicates: two copies of the same note with different rights create a guaranteed inconsistency.
3. Date: check effective dates, mark replaced documents, remove anything expired from the index.
4. Index with closed-by-default: index only labelled documents, recording distribution metadata with every indexed fragment.
5. Test access: run the tests from the next section, especially the cross-team tests.
6. Log and review: enable the access log, then schedule a quarterly classification review with the team owner.

The fourth step deserves particular attention: if your indexing tool does not allow attaching permission metadata to each fragment, you will need either to change tools or to index in separate compartments. A fragment without metadata is a fragment that will leak sooner or later.

Access tests: horizontal and cross-client

Content tests verify that the chatbot answers correctly. Access tests verify that it does not answer too much. They are distinct, and the second is more important.

Horizontal test: for each pair of populations (HR/sales, sales/customer, HR/customer), ask the same sensitive question from each profile and compare. For example: "What is the maximum discount grid?" should get a documented answer from a sales rep, a reasoned refusal from a customer, and probably a refusal from HR if the document is compartmentalised by team. The refusal must be explicit ("this content is not accessible with your profile"), not a vague answer that hints at the document's existence.

Cross-client test, if you operate a multi-client chatbot: one client must never see any trace of another. This covers not only documents, but names, case references and wording specific to an account. The safest approach remains physical separation of indexes per client; logical separation by metadata requires systematic testing, because a single badly filtered query is enough. Our grid on evaluating AI chatbot answers can serve as a support for formalising these test scenarios with the business teams.

Add an access-revocation test: remove a right from a test user, then verify that their previous questions no longer return the content. If the chatbot caches responses per session or per team, revocation must invalidate that cache — otherwise the user retains a ghost access after the removal.

The limitations to own up to

Three limitations deserve to be stated clearly.

First, server-side filtering depends on the quality of the initial classification. A badly labelled document is a badly filtered document. No technique compensates for absent classification, and the initial human review remains real work that must be budgeted.

Second, the model's rephrasing can circumvent boundaries that are too fine. If two authorised fragments, placed side by side, make it possible to reconstruct information that neither would have revealed on its own, your per-fragment filtering shows its limits. Genuinely sensitive documents must be compartmentalised at the whole-document level, or even kept out of the chatbot entirely.

Finally, permissions evolve. A person changes teams, a document changes level, a client terminates. The system must treat revocation as a normal case, with non-regression tests, rather than as an exceptional fix. For personal data, the core data protection principles described by the CNIL — minimisation, retention periods, security — provide a useful framework for deciding what should enter the index at all.

Common mistakes and how to handle them

The first mistake is believing that a label or a folder name is enough as a boundary. A folder named "internal" prevents nothing if the index does not read that information. The permission boundary must be structured data that the server enforces, not an implicit convention.

The second mistake is testing only with demo accounts that have all rights. These accounts never reveal leaks. From the start, build test profiles with reduced rights, one per distribution level, and replay the tests at every corpus change.

The third mistake is treating source contradiction as a bug to be silenced. Two dated documents that contradict each other are a document governance signal: the right course of action is to escalate the information to the content owner, not to let the chatbot arbitrarily choose the most recent source without saying so.

Finally, do not confuse the enterprise AI assistant with a storage space. If users start dropping documents into it "so the chatbot can find them", you lose control of classification. Provide a single intake channel, with mandatory classification, even if it is slower than direct upload.

If you would like to structure the knowledge base and access rights of an enterprise chatbot for your organisation, you can define a mission with Edeverse.

Frequently asked questions

Can permissions be filtered in the prompt rather than server-side?

No, not reliably. The prompt is an instruction the model can ignore or circumvent, especially if the context already contains the forbidden text. Filtering must happen beforehand, on the list of documents sent to the model, in server code.

How do you handle a document accessible to several teams with exceptions?

Assign a base level (for example internal, teams A and B) then a list of named exceptions, stored as structured metadata. The server applies the level first, then removes the exceptions. Test each exception explicitly with a dedicated account.

What to do when two up-to-date documents contradict each other?

That is a governance problem, not a technical one. The chatbot's answer must cite both sources with their dates and flag the ambiguity, and the content owner must decide. A persistent contradiction often signals a document validation process that needs revisiting.

Should you have a separate index per client in a multi-client chatbot?

It is the safest choice, because it makes cross-client leaks structurally impossible. Logical separation by metadata is acceptable if accompanied by systematic cross-testing and an access log, but it relies entirely on the correctness of the filter.

How do you verify that an access revocation is effective?

Remove the right from a test account, then replay the questions that previously returned the content, including in an already-open session. If cached answers persist, revocation must explicitly invalidate that cache. This test is one of the controls to replay at every corpus change.