Enterprise AI requires rules for handling documents, source code and other information. These rules define which data an application may access, where it may be processed and which actions the application may perform.
This architecture analysis considers a system in which the request route and permitted actions depend on the user, data-processing policies and the use case.
Data classification and processing policies
The following working policy scheme can support design:
- public material approved for the selected external service;
- internal material with defined processing conditions;
- confidential information restricted to approved applications and groups;
- information excluded from the AI use case under consideration.
This is an example, not a universal classification. The organisation defines its categories and restrictions. Permission to send data for processing and permission to use it for model training are recorded separately.
In the proposed design, labels and policies may come from document catalogues, business applications and connected protection tools. Each data flow needs a defined classification source and handling rules for missing labels.
AI gateway and request routing
Cloud and local models are easier to govern through a shared gateway. It performs several functions:
- Authenticates the user and obtains their roles.
- Determines the class of the request and attached data.
- Selects an approved model and processing route.
- Applies masking, filtering and tool restrictions.
- Creates a technical audit trail without unnecessarily copying sensitive content.
The gateway does not replace DLP, IAM or SIEM. It turns their decisions into AI-application behaviour.
Access control in RAG
An enterprise knowledge base should not become a single corpus available to every agent. Indexing must preserve the source, owner, information class and access policy. Retrieval filters should run before passages are provided to the model, not after an answer has already been generated.
This matters when documents look similar but belong to different projects, legal entities or confidentiality domains.
Agent permissions and permitted operations
An AI agent that can act as well as read introduces a new category of risk. Access to ERP, CRM, file stores and service systems should be exposed through narrowly scoped tools.
Critical actions require human confirmation. Every invocation should record the initiator, objective, input parameters, outcome and policy decision.
Model placement and protection requirements
Running an LLM inside the perimeter reduces third-party data exposure, but it does not remove excessive permissions, cross-department leakage, prompt injection or uncontrolled agent actions.
The choice between a cloud and local model is therefore only one architecture decision. The maturity of the environment depends on policy, observability, data quality and the ability to investigate an incident.
Pilot scope and validation
A pilot can focus on one bounded use case and a selected set of models. Data classes, users and failure cases are chosen to exercise the policies relevant to that use case. The test plan can include:
- correct request routing;
- access enforcement during RAG retrieval;
- masking of sensitive data;
- completeness of the audit trail;
- clear refusals and warnings for users;
- cost and latency for each route.
The test report records the scenarios exercised, policy decisions, answer quality, limitations and required changes. These results inform any expansion of the use case.
Related reading: Secure AI platforms and agents. Discuss enterprise AI.