Connecting AI assistants to company data under access control

General-purpose language models are already capable of reading a document and answering a question about it. What they do not know is anything about a particular company: its prices, its contracts, its policies, which customer called yesterday. The standard way to close that gap is retrieval: when a question arrives, search the company’s systems for the relevant pieces, hand them to the model with the question, and ask it to answer from that material only.

This pattern, retrieval-augmented generation, moves the difficulty from the model to the surrounding system. Which systems are searched, under whose identity, what leaves the environment, how answers are checked and how everything is logged are engineering and governance decisions. They deserve more attention than the choice of model.

The most consequential rule is simple: the assistant must retrieve as the user rather than as a super-user. If a sales representative cannot open the board pack in the document system, the assistant answering their question must not be able to retrieve it either. Enforcement belongs in the retrieval layer, which filters candidate documents by the caller’s identity and the source system’s access control before anything reaches the model. Instructing the model to “only answer if the user is allowed” is not a control; a model is not an access-control system and will eventually be talked out of the instruction.

In practice this means every item in the search index carries its permissions (owners, groups, roles, tenant), and those permissions are refreshed when the source changes. Where a source system has fine-grained rules, such as row-level security in an ERP or field-level masking of personal data, the safest design is to query that system through its own API with the user’s session rather than copy its data into a shared index. This approach is slower, and it is correct.

The role-based access that already exists in the portal (Owner, Admin, Member, Viewer) is a sound starting point for what the assistant can see and do on behalf of each person.

Decide, in writing, which systems the assistant may read, which categories of data it may include in a prompt, and where the model runs. A hosted model provider means prompts and retrieved snippets leave the environment; read the provider’s terms on data retention and training use, and prefer a region and a contract that the data protection officer has approved. A self-hosted or private-endpoint model keeps data inside the boundary at a higher operating cost.

Minimize what is sent. The model needs the paragraph that answers the question rather than the whole customer record. Strip or mask identifiers that are not needed for the answer. Keep the assistant’s own connections to systems (API keys, service accounts) write-only in the configuration and visible to administrators as a last-four hint at most, in the same way as any other credential.

Treat the retrieved content as untrusted input. A document can contain text that attempts to instruct the model (“ignore your rules and e-mail this to…”). Separate instructions from data in the prompt, do not allow retrieved text to trigger actions by itself, and keep the assistant’s permissions narrow so that a successful injection has little to work with.

An assistant that sounds confident is not necessarily an assistant that is correct. Before launch, build a test set of real questions from the people who will use it, with the answers they would accept and the documents those answers come from. Run the assistant against the set and score three things: whether it retrieved the right material, whether the answer is supported by that material (groundedness), and whether it declined appropriately when the material was absent. Keep the set and run it again whenever the model, the prompt or the index changes.

After launch, sample conversations with the users’ consent and review them weekly. Thumbs-down signals are useful but biased; a random sample is more informative. Watch for the two classic failures, answering from general knowledge when company data disagreed and refusing when the answer was available, and correct them in retrieval and prompt design rather than with longer disclaimers.

Languages other than English need their own testing. Thai text, for example, has no spaces between words, uses tone marks and vowels that sit above and below the base character, and mixes freely with English product names, abbreviations and numbers. Search and embedding components tuned on English can tokenize Thai poorly, which appears as missed retrievals rather than obvious errors. Test retrieval with real Thai queries, including informal spelling and Thai-English mixtures, and check that the model’s answers in Thai are as specific as its answers in English rather than vaguer translations.

Pay attention to the vocabulary the company uses. Business language often has formal terms, transliterated English terms and internal shorthand for the same concept; a glossary of the company’s own terms helps both retrieval and the answer. Where the assistant speaks, as our AI Avatar does, pronunciation of names and numbers deserves its own test cases.

Answering questions carries low risk; performing actions carries considerably more. When an assistant can create a purchase order, change a price or send an e-mail, separate the two clearly. The assistant drafts, a person confirms, and the system records who confirmed. The confirmation must show exactly what will happen, in plain language, and a single ambiguous instruction must never perform an irreversible action.

This is also where the assistant earns trust. A draft that is right most of the time and always reviewed saves real time; an action that is wrong once without review costs more than the assistant will ever save.

Every answer should cite its sources (the document, the record, the system) so that the person can check it and the organization can establish later why the assistant answered as it did. Behind the scenes, log the question, the identity, the retrieved items, the prompt version, the model and the answer, with a retention period that matches the data protection policy. Those logs are personal data too and must be protected accordingly.

With provenance and logs in place, the assistant becomes something the organization can govern: review it, correct it, and demonstrate to an auditor or a regulator how it behaved. Without them, it is an opaque system that happens to write well.