An internal AI assistant can make policies and project knowledge easier to find. It can also make a badly configured document library easier to search. Before connecting company files, ask a concrete question: can an ordinary employee obtain information that the same employee should not be allowed to open?
This guide is for UAE businesses planning a custom assistant that retrieves information from documents. It concerns access design and acceptance testing, not a claim that a particular product automatically makes every connected source safe. Vendor references were checked on 9 October 2026.
Define the audience for each source first
Start with a small source register: location, owner, intended readers, sensitivity and update process. Separate a general handbook from personnel records, finance files and client-specific material. Ask each owner to approve the audience before the content enters the pilot.
For example, a hypothetical engineering business might allow everybody to read its travel policy, only project members to read a client's working documents, and only authorised HR staff to read employee cases. “All company documents” is therefore not a useful single access rule.
Review the original sharing configuration as well. If a sensitive folder is already available to everyone, an assistant that faithfully follows those permissions may still produce an unacceptable result. The SharePoint sharing review guide can help organise the source-side discussion.
Keep restricted content out of the retrieved context
Document-level access control limits which documents a user can retrieve. Microsoft's Azure AI Search access-control overview describes security filters and native permission approaches. Several native integrations are labelled preview; confirm support for the exact data source, API and deployment before choosing one.
For a custom solution, make authorisation a retrieval requirement. An instruction saying “do not reveal confidential information” is not a substitute for preventing unauthorised text from reaching the answer-generation step. Once restricted passages are in that context, hiding their source links does not remove the exposure.
ITZ's AI integration service can help define a bounded pilot. Plan Your Internal AI Access Review with the intended users, document locations and business questions; share a source inventory rather than confidential files through the form.
Ask who supplies the permission information
Microsoft's security-filter pattern matches user or group identifiers against permission fields in the index. In that design, the application is responsible for constructing the appropriate filter. A login screen by itself does not establish that every search uses the right permissions.
Ask the delivery team to show how the server derives identity from the authenticated session, how each indexed passage inherits its source permissions and what happens when permission data is unavailable. Our recommended pilot rule is to deny access when authorisation cannot be established, rather than silently searching everything.
- Can a caller alter a user identifier or omit an access filter?
- Are cached results separated by the relevant user and permissions?
- Do logs and conversation history expose passages to a wider audience?
- Can a citation, document preview or download route bypass the same checks?
- Who can inspect the index directly, outside the assistant?
These questions should produce a demonstrable design and test evidence, not merely the name of a cloud platform. Where the assistant connects multiple applications, include the boundaries in the software integration review.
Test denial as carefully as a helpful answer
Use synthetic documents and approved test accounts with deliberately different permissions. Place a distinctive fictional phrase in a restricted document so the team can detect accidental retrieval without using genuine confidential information.
- Confirm an authorised account can retrieve the intended document and open its citation.
- Ask an unauthorised account for the same information directly and through a broader summary.
- Check that titles, snippets, citations and suggested follow-up questions do not disclose restricted material.
- Repeat after removing the authorised account from its access group.
- Delete or restrict a source and measure when the assistant stops returning it.
- Simulate a permissions lookup failure and confirm the agreed denial behaviour.
Record results per account, document and route. An empty answer alone is weak evidence: the system may simply have failed to find the file. Pair the denied test with an authorised test of that same content.
Define ownership after launch
Agree how quickly access changes must take effect, who responds to a suspected disclosure and how a document source can be disconnected. Include indexes, cached answers and retained conversations in the review; changing a source permission should not leave an unexamined copy elsewhere.
Keep the first pilot small enough to inspect. Expand only after owners accept the access tests and the team understands remaining limitations. If staff movement changes permissions, link the process to the existing employee offboarding checklist.
Plan your internal AI access review
Discuss a specific assistant use case with ITZ: the questions it should answer, the source owners, the user groups and the information it must withhold. Request a scoped pilot with an access model, synthetic test cases, permission-change checks and a documented launch decision.
