Retrieval
Azure OpenAI production RAG: permissions before the index
Azure OpenAI production RAG only works when retrieval respects the same entitlements as the source system. Pexon builds permission-aware indexes, evaluation before release, and Azure OpenAI inference in your tenant — the pattern behind our engine-manufacturer maintenance assistant, not a demo chat over a flat document dump.
Order of work
The order is not optional
- Entitlements. Whose identity the request carries, and which source-system ACLs already decide what that person may see. If this is vague, stop — the index will only amplify the mistake.
- Index design. Partition or filter so retrieval cannot return a node the caller could not open unaided. Chunking follows the permission boundary, not only the paragraph boundary.
- Azure OpenAI generation. Completions run in your tenant under the identity model from governance. The model never becomes a second permission system.
- Evaluation. A fixed question set with acceptable answers, scored before release and again when the index or deployment changes.
What we assemble
A production stack, not a notebook
Each layer produces an artefact the next layer consumes. Skipping entitlements to 'just try RAG' is how PoCs become incidents.
01
Identity
Entra or the source-system session that already governs the document.
- Entra ID
- Managed identity
02
Retrieval
Permission-aware search over the systems people already trust.
- ACL filter
- Evaluation set
03
Generation
Azure OpenAI in your subscription, with logging your SOC can read.
- Azure OpenAI
- Diagnostics
We have shipped this shape
The anonymised engine-manufacturer maintenance assistant runs permission-aware retrieval with Azure OpenAI in the customer tenant — entitlement per data node, thousands of users, not a pilot chat over public manuals. That is the reference architecture this offer aims at.
If your first use case is a public knowledge base with no ACL story, say so. A simpler stack is then the honest answer, and we will not sell you entitlement engineering you do not need.
Trade-off
Permission-aware RAG costs more engineering than dumping PDFs into a vector store. The cheaper path is fine until the first document a user should not see appears in an answer — at which point the cheap path is a security project. Choose based on whether the corpus has entitlements, not based on demo speed.
Where this connects
- Permission-aware maintenance RAG (case study) — the shipped Azure OpenAI reference
- Enterprise RAG platform — when you need the broader company-brain programme
- Governance and Entra — the identity layer this stack assumes
Questions buyers ask
Why do most Azure OpenAI RAG pilots fail in production?
Because the index ignores entitlements. A shared vector store that returns a contract the caller could not open in SharePoint is a security incident dressed as a demo. Production RAG filters or partitions by permission before generation.
Do we need Azure AI Search?
Sometimes. The decision follows the source systems and the permission model, not the product brochure. We have shipped on Azure AI Search and on other stores when the entitlement story fitted better.
What does evaluation before release mean?
A fixed set of questions with known acceptable answers, scored before users see the system, plus regression when the index or model changes. Without that, 'it feels better' is the only metric and it never survives audit.
How does this relate to the company-brain offer?
Company brain is the broader retrieval platform story. This page is the Azure OpenAI-shaped entry when the buyer already standardised on Azure and needs one production use case, not a platform programme on day one.
Next step
Start with one permission-aware queue
A two-week blueprint at €4,900. We pick one real document or ticket queue, map entitlements, and leave an architecture that can ship on Azure OpenAI without a flat index that ignores who may read what.