AI / AI-03
Permission-aware RAG document assistant
Connect an assistant to enterprise documents without granting more access than the user has. RAG retrieves material before generating an answer; permissions must be enforced before prohibited data enters the model’s context.
WHEN IT HELPS
A focused response
to a defined need.
Internal search project, assistant connected to SharePoint, Drive or files, separated customer data or concern about users querying confidential documents outside their scope.
SCOPE & OUTCOMES
What the engagement covers.
Scope
- Corpus
- owners
- source permissions
- indexing and access metadata
- retrieval filtering
- identity
- revocation
- deletion
- citations
- caches and histories
- cross-role tests
Deliverables
- RAG architecture
- access matrix
- indexing rules
- separation tests
- resynchronisation procedure
- measured propagation delays
- operations and failure handling
Acceptance evidence
Approved users receive access and unauthorised users are denied; removed documents cannot be retrieved after the validated delay; tests show no leakage; group changes and synchronisation failures are handled.
DELIVERY
How the work is structured.
Approach
Choose a use case; classify data and access; design and pilot; test privacy, actions and cost; decide rollout and monitoring.
Prerequisites & responsibilities
Customer: business sponsor, data owners, identity team, DPO/legal where needed and budget. Provider: architecture and tests; customer retains approval of sensitive use.
Scope factors
Uses, users, models, data, connectors, permissions, actions, volumes and hosting. Separate project, licenses, tokens, search, storage and operations; no claimed savings without measurement.
Questions to clarify
Are current document permissions reliable? How will revocation or deletion propagate? Do caches, citations and histories respect the same restrictions?
IMPORTANT BOUNDARIES
Access is enforced before restricted material enters the model’s context. Connector permissions, revocation, caches and feature availability are part of the design and acceptance tests.
Permissions, provider data use, retention, residency and cost enforcement are assessed separately. Technical features and applicable obligations are checked for the chosen offering and use case.
IN PRACTICE
Illustrative situations.
These examples describe possible engagements and target outcomes. They are not customer references or achieved results.
Scenario 01
A firm wants AI to search all customer files. Project: separate indexes or filter documents by effective permissions. Target outcome: test responses reveal no other customer’s data, including through citations or shared history.
Scenario 02
A company removes an employee from an HR group. Project: test permission propagation, caches and existing conversations. Target outcome: known, controlled revocation delay; a connector that cannot preserve permissions is replaced or excluded.
Technology and reference context
Examples: document retrieval with security filters, permission-preserving connectors and suitable indexes; validate Azure AI Search or equivalent features by version.
The final technology set is agreed during scoping, based on interoperability, licensing, access rights and operating requirements.
CONNECTED SERVICES
Build the next step.
These services can complement the engagement. They are not automatically included.
START A CONVERSATION
Make the scope clear.
We will clarify the objective, dependencies and responsibilities of this service before proposing delivery.