Who can see what: document permissions in an AI knowledge base

Your shared drive already hides the salary spreadsheet from sales. An AI assistant built on top of that drive does not know this unless it is told. It reads everything it is given and answers from all of it. Search engines inside companies have always respected folder rights, but a language model that summarises text across files can expose a sentence the folder was meant to hide.

The risk is quiet. Nobody opens the HR folder. They ask what the notice period is for a senior manager, and the answer arrives with a paragraph from someone’s contract.

So the index needs the same fences as the folders, and it needs them to be checked on each question.

When a document is indexed, store its access list beside each chunk of text. That list comes from the source: the drive’s folder groups, the SharePoint site members or the role in your HR system. Inherited rights deserve special care, because a file may be open to a team only through its parent folder, and the index must record that chain.

At question time, the assistant first identifies the person, then searches only chunks whose list includes that person or one of their groups. Filtering must happen before the text reaches the language model, never after.

Sync is just as vital as the first copy. When someone leaves a group, the index must hear about it within hours, not at the next full rebuild.

An answer without a source invites doubt. Show the file name, the page or section and the date for every claim, and link to the original so the reader opens it under their own permissions. A clickable citation also trains staff to trust the original document over the summary, which is the habit you want when a figure or clause really matters.

Citations also catch old material. If the answer points to a 2021 price list and a 2026 one exists, the reader can see the problem and the owner can retire the old file.

When nothing permitted matches the question, the assistant should say so. It should not guess, and it should not hint that a restricted document exists.

Build a test sheet with real roles. Ask the questions a curious salesperson, a branch manager and a new joiner might try. Ask directly, such as who earns the most, and sideways, such as summarise the last disciplinary meeting.

Test the edges too. Move a file from an open folder to a closed one and ask again. Remove a person from a group and confirm answers change the same day. Upload a document with no access list and see that it defaults to closed.

Have the HR head and the IT manager both watch the run. Keep the results, because you will repeat the tests after each change. Repeat the whole run whenever you add a new data source, change the embedding or search settings, or restructure the folder tree.

Permissions drift when nobody owns them. Name one person for the source rules, usually the IT manager, and one for the content, often HR or operations. Agree how new folders get classified.

Set the default as closed. A document enters the index as visible to nobody until someone assigns an audience. This is mildly annoying and far better than the reverse. A default of closed means a missing label costs one support ticket from a puzzled colleague, while a default of open could cost a data breach notice.

Next step: list your ten most sensitive folders this week and write down which roles may read each. That list is the first row of your test sheet.