The question comes up in every team that considers it, usually phrased as a single worry about security. It is actually three separate questions wearing one coat: who can see which documents, what the assistant is able to do besides read, and what the vendor does with the content that passes through. They have different answers and very different risk profiles, and conflating them is why the decision often stalls for months on a concern that turns out to be the smallest of the three.
Separate Three Questions People Conflate
The first question is access: can this arrangement show someone a document they were not supposed to see. That is a real risk and the one worth most of your attention, because it is the failure that cannot be undone once it happens.
The second is capability: what can the assistant change. An agent that can only read has a bounded worst case. An agent that can act — modify records, send messages, trigger workflows — has a worst case that extends to everything within its reach, and deserves a completely different level of scrutiny.
The third is vendor handling: where the content goes, whether it is retained, and whether it trains anyone's model. This is the question people lead with and it is usually the most tractable, because it is answered by reading a contract rather than by designing a system.
Read-Only Bounds The Worst Case
Restricting an assistant to reading is the single most effective control available, and it is worth treating as a permanent design decision rather than a cautious first phase. The worst thing a read-only assistant can do is show someone information — a serious failure if the permissions are wrong, but a failure that does not corrupt records, send anything to a customer, or require a restore from backup.
Write access changes the shape of the risk entirely. A misread instruction becomes a modified record, and the blast radius follows whatever the integration was granted. The benefit that justifies that exposure is usually much smaller than it sounds in the proposal.
It also makes the internal conversation easier. Granting an assistant read access to documentation a colleague could already open is a modest decision that a security review can approve quickly. Bundling it with the ability to act turns a modest decision into a large one, and the modest version is where nearly all the value sits anyway.
Permissions Follow The Person, Not The Bot
The most common design mistake is giving the assistant its own account with access to everything, then relying on it to be tactful about what it reveals. That is not a permission model; it is a hope. Anyone who can ask a question can, with enough rephrasing, reach anything that account can read.
The correct model is that a request inherits the permissions of the person making it. If a document is restricted to the leadership group, an engineer asking a question that would be answered by that document gets the same result as if they had searched manually: nothing. The assistant becomes a faster path to what someone already had, never a route around the rules.
This also means the existing access structure is the thing that gets tested. If your documentation is currently a single shared space where sensitive material happens to be filed among ordinary pages, that was already a problem — connecting an assistant just makes it visible faster, which is an argument for fixing it rather than for postponing the project.
Retention, Training And What To Ask Vendors
Four questions settle most of this, and all four should have written answers. Is content used to train any model, by the knowledge base vendor or the model provider behind it. How long are queries and retrieved passages retained, and in what form. Where is the data processed, which matters for teams with residency obligations. And what does the audit trail record — who asked what, and which documents were returned.
The audit question is the one most often forgotten and the most useful in practice. A log of questions and the documents used to answer them is what lets you investigate an incident at all, and it doubles as the clearest signal of which documentation people actually depend on.
Be specific about the model provider as well as the knowledge base vendor, since the content passes through both. A vendor that cannot answer plainly in writing has answered the question anyway.
A Rollout That Does Not Need A Committee
Start with documentation that is already company-wide: onboarding material, published processes, product information, support policies. There is no access question to resolve for content everyone can already read, which removes the hardest part of the decision from the first phase entirely.
Run that for a few weeks with a small group and look at the logs. You will learn which questions people actually bring, how often the answer was present, and whether the citations hold up — all of it evidence you can take into the conversation about extending scope, in place of speculation.
Then add restricted material deliberately, one group at a time, with the permission model tested before anything sensitive is loaded. Staged this way, the project never requires one large approval covering every risk at once, which is usually what stalls it.
Frequently asked questions
Is it safe to connect an AI assistant to internal docs?
It can be, if access follows the person asking rather than a shared service account, the assistant is read-only, and the vendor states in writing that content is not used for training. Those three conditions cover most of the risk.
Why does read-only access matter so much?
It bounds the worst case to showing someone information rather than changing something. A misread instruction with write access becomes a modified record or a sent message, with a blast radius matching whatever the integration was granted.
Will our documents be used to train a model?
That depends entirely on the vendor and the model provider behind it, so ask both and require the answer in writing. It is a contractual question rather than a technical one, and a vague answer is itself informative.
Where should a cautious team start?
With documentation everyone can already read: onboarding material, published processes, support policies. There is no access question to resolve, so the first phase tests answer quality and the permission model before anything sensitive is added.
Top comments (0)