When a regulator asks how an AI agent reached a decision, the answer needs to be specific. Not a screenshot, not a summary, not a sentence beginning “the model returned…”. The answer needs to identify the user who initiated the action, the data the agent retrieved, the reasoning path it followed, the approval that authorised the output, and the supervisor who reviewed it. That answer comes from the compliance architecture, not from the model.
In regulated environments, the model is the easy part. Anthropic, OpenAI, and the open-weight ecosystem all ship capable models. What separates a production deployment from a proof of concept is the surrounding architecture: the layers that turn an LLM call into an auditable, supervised, regulator-defensible piece of work.
This article is a reference for what those layers look like. It covers the five control planes every compliance architecture for AI agents needs, how they fit together, and how the design maps to the regulatory frameworks that apply in the UK and EU.
What compliance architecture has to do
A compliance architecture for AI agents has to satisfy three things at once.
Outcomes. Every output an agent produces must be traceable to its inputs, its reasoning, its approvers, and its supervisors. When the regulator asks how a specific document was generated or a specific decision was made, the system produces the evidence rather than reconstructing it.
Boundaries. Data that is privileged, confidential, or subject to data protection law must not leave the environment that is permitted to hold it. Cross-border transfers, third-party access, and model training on customer data are blocked by design rather than by policy.
Supervision. Every action an agent takes must be either reviewable in real time or routable to a human for approval before it has effect. The choice between automatic execution and human review is determined by risk, not by convenience.
These are the requirements. The architecture below is how they are implemented.
The five control planes
A compliance architecture for AI agents has five control planes. Each one solves a different category of risk and produces a different category of evidence.
1. Identity
The identity plane answers two questions. Who initiated this action? And what is the agent authorised to do on behalf of that user?
In a regulated deployment, agents do not have their own credentials to backend systems. They act on behalf of the user who initiated the workflow, using that user’s identity and that user’s permissions. If a paralegal who cannot see family law matters initiates a document search agent, the agent cannot see family law matters either. The same access controls that govern human users govern the agent.
In practice this means delegated OAuth, typically through Microsoft Entra ID, Okta, or a similar identity provider. The agent obtains a token scoped to the initiating user’s permissions, with a short expiry, and uses that token for every downstream call. The result is an audit trail in every connected system (iManage, SharePoint, Salesforce, the firm’s data warehouse) that identifies the human user, not the agent.
This is the foundation of every other control. Without per-user identity propagation, supervision is impossible: the audit logs in the document management system, the CRM, and the matter management system all show a service account, not a person.
2. Data boundaries
The data boundary plane answers where information can flow.
For a UK law firm processing privileged client material, the boundary is straightforward: data must not leave UK or EU infrastructure, must not be accessible to non-EU service providers, and must not be used to train any model. Each of these is a structural commitment, not a contractual one.
The architectural implications are specific. The agent runtime, the vector index, the prompt cache, and the model endpoint all run inside the firm’s own cloud tenancy (Azure UK South or AWS eu-west-2 are the most common UK choices) or on-premises. Model providers are accessed through tenancy-scoped endpoints (Azure OpenAI, AWS Bedrock) rather than the public API, so requests and responses stay inside the customer’s tenancy boundary. Encryption keys are held by the customer in Azure Key Vault or AWS KMS, with the platform configured to use envelope encryption that fails closed if the keys are revoked.
For deployments where third-party API access is unavoidable (for example, when using a specific frontier model not available through a tenancy-scoped endpoint), the boundary is enforced through commercial API tiers that exclude customer data from training. Anthropic’s commercial API terms and OpenAI’s data usage policy both make this explicit. The architecture treats these as exceptions that require additional review, not as defaults.
The data boundary plane also covers retention. Logs of agent activity are retained for the period the firm’s regulatory framework requires (seven years is typical for financial services and legal), in storage classes that prevent modification or deletion before the retention period expires. WORM (write-once, read-many) storage in AWS S3 Object Lock or Azure Blob immutable storage is the standard pattern.
3. Action authorisation
The action plane answers what an agent is allowed to do, and what requires human approval first.
In a compliance architecture, every action an agent can take is classified by risk and routed accordingly. Reading a document is low risk and proceeds automatically. Drafting a response is low risk but the output is held in a review queue rather than sent. Sending an email to a client, executing a trade, or filing a regulatory document is high risk and requires explicit human approval before the action takes effect.
The classification is enforced by policy-as-code, not by user discretion. A policy specifies that any external email from a legal agent requires partner approval. Any document generation that touches a matter flagged as litigation requires senior associate review. Any output that contains client identifiers requires the originating user to confirm before it is delivered. These policies are evaluated at the point of action, every time, by a deterministic policy engine (Open Policy Agent is a common choice) that sits between the agent and the world.
This is the layer that maps most directly to the SRA’s supervision requirements under Rule 3.5 and the FCA’s Consumer Duty outcomes-based supervision. The regulator does not require that humans review every action. The regulator requires that the firm demonstrate, for each category of action, that supervision was calibrated to risk and that the system enforced it. The action authorisation plane is how that demonstration becomes evidence.
4. Reasoning and confidence
The reasoning plane answers why the agent did what it did.
Every agent action carries a reasoning trace: the prompt the model received, the context the agent retrieved, the tools it considered, the tools it called, the outputs it generated, and the confidence score it assigned. This is not a debug log. It is the artefact the firm hands to a regulator, a complainant, or a court when asked to explain a specific decision.
The confidence score is doing work here. It is not just a number from the model. It is a derived metric that combines the quality and relevance of the retrieved context, the consistency of the model’s outputs across multiple sampling attempts, and the alignment of the proposed action with the firm’s known precedent. Low confidence outputs are routed to human review regardless of the action category. High confidence outputs on low-risk actions can proceed automatically. The threshold is configurable per workflow and per client.
The reasoning trace also enables a category of post-hoc analysis that compliance teams need: pattern detection across thousands of agent actions to identify drift, bias, or unexpected behaviour. If an agent starts producing outputs that systematically disadvantage a particular client segment, the pattern is visible in the reasoning logs before it becomes a complaint.
5. Immutable audit
The audit plane is the final control. It answers the question “what happened” with evidence that cannot be modified after the fact.
Every event in the system is recorded: the user who initiated the workflow, the agent that executed it, the model and version that produced each output, the documents retrieved, the prompts sent, the responses received, the policies evaluated, the human reviews performed, and the actions that resulted. The records are append-only and tamper-evident. They cannot be modified or deleted by anyone, including the platform’s own administrators.
In a typical deployment, the audit log is duplicated to two destinations: a queryable index for operational use (the compliance team’s day-to-day investigations) and an immutable archive for regulatory retention. The archive uses WORM storage with a retention period that exceeds the longest applicable regulatory requirement.
The audit log is the evidence base for everything else. SRA inquiries, FCA reviews, GDPR data subject access requests, professional indemnity claims, internal complaints, and litigation discovery all start with “what did the system actually do” and end with the audit log producing the answer. An architecture that does not produce immutable, queryable audit data is not a compliance architecture.
How the planes fit together
A request flows through every plane on its way to becoming an action.
A user initiates a workflow. The identity plane verifies the user, obtains a delegated token scoped to their permissions, and issues it to the agent. The agent retrieves context from connected systems using that token, which is recorded in the audit log along with the documents accessed. The model produces a draft output, with a reasoning trace captured by the reasoning plane and a confidence score derived from the retrieval and consistency signals. The action plane evaluates the proposed action against policy: routine, automatic, or requires approval. If approval is required, the request is held and a notification is sent to the responsible reviewer. The reviewer’s decision is recorded. If approved, the action is executed and the result is recorded. The audit plane captures every step.
If a regulator asks six months later why a specific email was sent to a specific client, the answer is reconstructed from the audit log. Who initiated the workflow. What context the agent retrieved. What the reasoning trace shows. What confidence the system assigned. What policy gated the action. Who approved it. When it was sent. The reconstruction is mechanical because the architecture produces it as a byproduct of normal operation.
Mapping to regulatory frameworks
The five control planes were not chosen abstractly. Each maps to specific requirements in the regulatory frameworks that apply to UK and EU regulated industries.
The SRA Standards and Regulations require accountable supervision (Rule 3.5), confidentiality (Principle 6), and the ability to demonstrate that work was performed to professional standards. The identity, action authorisation, and audit planes are the architectural answer.
The FCA Consumer Duty requires firms to demonstrate that the products and outputs delivered to retail customers are fit for purpose, with documented oversight of the systems that produce them. The reasoning and confidence plane provides the documented oversight; the audit plane provides the evidence.
UK GDPR and Article 28 require demonstrable controls on processing, lawful basis, and the rights of data subjects. The data boundary plane addresses processing location and access; the audit plane produces the evidence for data subject access requests.
The EU AI Act, for high-risk AI systems, requires documented risk management, data governance, technical documentation, logging, transparency, human oversight, and post-market monitoring. Every one of these maps to a control plane in the architecture, which is why a compliance-first design from the start is significantly cheaper than retrofitting controls onto an existing system once the Act applies.
The SRA Risk Outlook on AI, the FCA, PRA and Bank of England joint discussion paper DP5/22 on AI and Machine Learning, and the ICO’s guidance on AI and data protection all converge on the same architectural pattern: explicit identity, enforced boundaries, supervised actions, documented reasoning, immutable audit. The phrasing differs by regulator. The architecture does not.
What this means for procurement
For firms evaluating AI platforms against this reference, the test is whether the architecture exposes the five planes as first-class concepts, or whether they are bolted on through policy documents and vendor assurances.
The questions that matter in vendor due diligence are specific. Does the agent act with the user’s identity, or with a service account? Can data leave the firm’s tenancy at any point in the workflow? Is policy enforced by the platform, or by reviewer discipline? Are reasoning traces and confidence scores captured automatically, or constructed when needed? Is the audit log append-only and tamper-evident, or is it an operational log that can be modified or rotated?
A platform that answers “service account, sometimes, by policy, on request, operational” is not a compliance architecture. It is a productivity tool with a compliance overlay. For work in regulated industries, the difference is the difference between something a firm can put into production and something that creates exposure the firm cannot defend.
The architecture above is structural, not optional. The firms that have moved from pilots to production are the ones that designed for it from the start. The firms still in pilots are usually the ones discovering, midway through a security review, that the architecture they chose cannot produce the answers their regulator and their CISO are about to ask for.
Related reading
- Building Compliant AI Agents: Governance Controls and Technical Architecture
- Private AI Deployment for Law Firms: SRA Compliance, Privilege and Practical Architecture
- MCP Servers in Regulated Environments
- Per-User Credentials in AI Integrations
- CompleteFlow Technical Evaluation Guide
- CompleteFlow Security and Compliance