Architecture: where policy becomes technical control and why data residency defines the design

From policy to technical control - Part 4 of "Generative AI in a Regulated Financial Institution".

An AI usage policy without corresponding technical architecture is merely a document; governance exists on paper while risk exists in production. The distance between them is what an incident or regulatory inspection eventually reveals.

In the first three parts of this series, I drew the map, went through the regulations one by one, and translated frameworks into auditable controls. Now the question changes: how do you design an architecture where compliance with policy does not depend solely on the goodwill of the person using the tool?

The answer begins with a provider- and tool-agnostic principle: fail-closed. In the absence or failure of a security control, the system does not silently degrade to a less protected path, open a direct connection to the provider, or trigger a fallback that bypasses inspection. Is the gateway unavailable? The development-assistance tool (whether Claude Code, Codex, or another) stops model calls, with no alternative route bypassing the same controls. This does not mean giving up operational continuity: a contingency route may exist, provided it preserves equivalent inspection, identity, traceability, and residency controls. What must not exist is a fallback that turns control unavailability into a bypass.

CMN Resolution 4.893/2021, amended by CMN Resolution 5.274/2025, does not use the term fail-closed; it establishes requirements for security, traceability, network protection, secure configuration, and controls also applicable to adopting new technologies. In this design, fail-closed is a defensible way of operationalizing these requirements. I am not citing a literal regulatory mandate, but translating regulatory objectives into an architectural decision.

The central thesis of this article follows from that decision: residency, custody, and control over the data path are not hosting details: they are design constraints.

Throughout this article, I use Claude Code as a concrete example to detail the architecture and its control mechanisms. The principle, however, remains the same for any tool: implementation must be adapted to each product's capabilities, but none may operate outside the corporate inspection path.

Each design decision addresses a specific risk#

Not every architectural choice is literally imposed by a regulation. Some are decisions a company may adopt to verifiably meet the objectives established by different regulations. This distinction matters. The regulator establishes the expected result, while architecture defines how to demonstrate it.

The central point is not to assert that only one architecture is possible. It is to require the institution to demonstrate why it chose a particular design and how that design addresses the identified risks.

The same control may address more than one risk#

Endpoint configuration is a good example. In Part 3, ANTHROPIC_BASE_URL appeared from the supply-chain angle. The CVE-2026-21852 vulnerability allowed, in versions before the fix, a malicious repository to influence endpoint configuration and redirect requests before project trust confirmation. The first control for this vulnerability is updating Claude Code to a patched version. Managed settings, network restrictions, and blocking local configurations are additional defense layers, not substitutes for the patch.

Here, the same configuration appears for another reason: governance and traceability. When each developer directly accesses the public endpoint, the institution may identify the key or account used, but loses a central, uniform trail correlating:

corporate identity
device
session
repository
applied policy
model and version
detected content
block or allow decision
provider response

Fixing the destination through corporate policy helps, but does not solve the problem alone. The design must be reinforced by the network, which blocks direct connections to public endpoints and allows only the authorized gateway. Local configuration and network control complement each other: one prevents accidental or malicious changes to the tool, while the other prevents a different tool from bypassing the same path.

Two layers, two roles#

A mistake in this type of architecture is confusing network control with the content gateway. SSE (Security Service Edge) and SASE (Secure Access Service Edge) tools can technically inspect traffic, apply DLP, identify AI applications, and even analyze prompts and responses. The point here is not to deny that capability, but to identify which component will be the canonical decision point for regulated content, and where that inspection will occur?

In this design, responsibilities are separated.

The network layer#

The network layer controls the path:

blocks direct access to unauthorized providers and tools
forces traffic toward a corporate destination
identifies Shadow AI
applies access controls by user, group, and device
may use DLP as a complementary barrier
records bypass attempts

The content gateway#

The gateway applies policy to each call:

authenticates and identifies the user
correlates device, session, and repository
inspects prompts, files, and responses
detects personal data, credentials, secrets, and sensitive code
applies blocking, redaction, tokenization, or human approval
controls models, tools, and usage limits
records the policy and version used
produces evidence under the institution's custody

The complete flow looks like this:

There are two explicit blocking paths:

The network prevents the gateway from being bypassed, and the gateway prevents trust in the destination from being confused with trust in the content.

If the network layer also inspects prompts, that processing must appear in the data inventory, contracts, third-party assessment, and transfer map. It is not automatically prohibited, but changes the architecture's regulatory posture.

The market comparison for the network layer#

The SSE/SASE category is mature and offers relevant capabilities for controlling AI tools. The choice, however, should not be based merely on the existence of a feature called “AI Security” or “GenAI DLP”.

What matters is understanding:

where traffic is processed
where policies are administered
where logs are stored
which content is retained
who has administrative access
which data, control, and management planes remain in the desired jurisdiction
which capabilities depend on additional products or contracts

The comparison above is not intended to choose a winner, but to demonstrate that “the provider has a presence in Brazil” and “all processing and all evidence remain in Brazil” are different statements. A local PoP can improve latency and keep part of the data plane close to the user, but does not automatically establish the location of:

configuration
telemetry
logs
support
threat analysis
additional processing
backups
administration plane

The same applies to expressions such as “Sovereign SASE” (a network-security model where data processing and traffic inspection occur entirely within the company's private or local infrastructure): they may represent relevant controls, but must be broken down into verifiable architectural and contractual commitments.

Why, in this design, the gateway needs to be in Brazil#

Keeping the content gateway in Brazil is not a literal, universal localization obligation imposed by the LGPD. The LGPD allows international transfers when one of the conditions in article 33 is met. Complementary Law 105 establishes the duty to preserve the secrecy of financial operations and services, but also does not require every technical component to be located in national territory.

Why adopt this constraint, then? Because the inspection location changes the data flow: if the gateway is outside Brazil, content must cross the border before it is analyzed. The international transfer has already occurred, even if the system blocks the prompt immediately afterward.

This does not mean the transfer is automatically illegal. It means it must be:

mapped
justified
supported by an applicable legal mechanism
reflected in contracts
included in provider assessment
subject to the corresponding technical controls

When inspection occurs in Brazil, the institution can detect and block certain content before transfer. What leaves can be reduced, redacted, or tokenized. An important point here: we cannot confuse redaction with anonymization; a sanitized prompt may still contain personal data or confidential information, depending on context and the possibility of reidentification. The remaining traffic must also undergo the applicable legal and contractual analysis. The local gateway does not eliminate every risk; it reduces the exposure surface and centralizes a critical stage under the institution's control.

This decision offers four main benefits:

Minimization before transfer: prohibited content can be blocked before leaving the country.
Custody of the decision: the applied policy and its evidence remain under the institution's direct control.
Reduced dependency: producing the audit trail does not depend exclusively on an external provider.
Consistency: different tools pass through the same inspection and policy-enforcement point.

The gateway does not necessarily need to be in a physically owned datacenter either. It can operate on-premises, in a private cloud, or in a dedicated VPC in a Brazilian region, provided the institution controls:

identity and access
keys
configuration
policy
availability
logs
retention
operations
incident response
provider chain

The question is not merely “which cloud does it run in?”, but who controls the component, who sees the content, and who can produce the evidence.

The hooks that defend before the gateway#

Before traffic reaches the network or gateway, there is a defense layer on the developer's machine. In Claude Code, hooks can be associated with execution-lifecycle events. They do not replace the gateway or network control, but allow behavior to be blocked or detected at the point closest to the user.

This detail about is important: a hook executed after a write does not prevent the secret from being written to disk. It must be combined with controls that stop the next cycle, prevent commits and pushes, remove the content, and generate a security event. Leak prevention cannot depend on a single regular expression. The design must combine:

deterministic patterns
secret scanners
contextual classification
per-repository rules
commit and push protection
DLP at the gateway
automated response
human review for ambiguous cases

Hooks can be distributed through managed settings. In Claude Code, the option prevents local user or project hooks from being used outside the managed policy, but there is a nuance: hooks from explicitly approved corporate plugins mandated by administration may also be allowed. Therefore, the correct wording is not simply that only hooks installed by MDM execute, but:

Only hooks defined by managed policy or explicitly approved corporate extensions may execute.

Distribution can occur through MDM, such as Intune or Jamf, administrative policies in the tool itself, or corporate configuration mechanisms. Ansible can participate in this distribution, but it is an automation and configuration-management tool, not an MDM.

Hooks, managed settings, and the gateway are controls built by the institution on top of the surface offered by the provider. They form a corporate layer that does not come ready-made with the product.

Fail-closed also needs to exist in the network#

Configuring the endpoint inside the tool is not enough. Even if points to the corporate gateway, a user, script, or different tool could still try to access the public endpoint directly. Fail-closed must therefore be reinforced through egress controls:

controlled DNS resolution
mandatory proxy
blocking of unapproved public endpoints
mutual authentication or workload identity
credentials available only at the gateway
monitoring of direct-access attempts
specific rules for CI/CD environments
segmentation between development, testing, and production

The workstation should not hold the provider's long-lived credential. Ideally, it authenticates to the gateway with its corporate identity, and the gateway injects or obtains the credential needed for the external call. This improves revocation, reduces key exposure, and allows different policies by user, application, repository, or environment.

The audit trail: what to record#

There is a deliberate decision at the center of the audit model: not recording the full prompt by default. Retaining complete prompts, files, and responses expands the processing surface and creates another repository of:

personal data
information subject to secrecy
source code
credentials
internal documents
business strategies
vulnerabilities

This retention may be necessary in specific situations, but requires a clear justification of purpose, necessity, access, protection, and duration. It should not happen merely because “the log supports it.” The trail must demonstrate what happened without unnecessarily reproducing all content. Elements that may be recorded include:

authenticated corporate identity
device
application and repository
session identifier
tool and version
model and version
request identifier
content HMAC
categories of data detected
redacted preview, when genuinely necessary
policy and version applied
action taken
blocking justification
human approval or intervention
response metadata
latency and cost
timestamp
call outcome

An HMAC with a key controlled by the institution is preferable to a plain hash when the goal is to produce a verifiable identifier without storing the original content. An ordinary hash of predictable text can be tested through guessing and comparison. Even so, HMAC does not address every proof requirement. The institution must define which evidence demonstrates integrity, authorship, temporal sequence, and the policy applied.

Trail sources

The provider's compliance API should not be treated as a substitute for the internal trail. Its scope varies by product, plan, and capability. Furthermore, availability of an administrative event does not mean full content, device, or repository information is available for correlation. The internal gateway is the point where the institution can build a consistent taxonomy across providers and tools.

How long to retain records#

There is no universal five-year period for all AI logs. CMN Resolution 5.274 requires the institution to define retention according to processing type and keep records securely. The five-year period appears specifically in relation to penetration-testing documentation and the corresponding remediation plans. Applying five years indiscriminately to prompts, responses, gateway logs, endpoint telemetry, and administrative events would be an excessive interpretation and could conflict with data minimization.

The right approach is to build a retention matrix.

Retention must also consider the source. Some events may remain available from the provider for limited periods. If needed as institutional evidence, they must be exported to a repository controlled by the institution before they expire. The goal is not to keep everything. It is to preserve sufficient, intact, traceable evidence for as long as necessary, without turning observability into a new liability.

Surfaces from the same provider, different regimes#

The "Product ≠ Provider" principle opened this series in Part 1 (The map of what lies ahead). Here it stops being a slogan and becomes a decision matrix. The data regime is defined by the product, not by who signs it; and the same provider delivers surfaces with mutually incompatible regimes. The same provider may offer:

an API
a local tool
a web interface
an agentic surface
a remote environment
an alpha/beta feature

These surfaces do not necessarily share the same retention, auditing, network, identity, and administration regime. The matrix below represents the state verified on June 29, 2026. As these capabilities change rapidly, they should be reconfirmed in the documentation and contract before a production decision.

The conclusion is not that one surface is “good” and another “bad.” It is that approval granted to one product cannot automatically extend to other products from the same company. ZDR should not be treated as a permanent property of a provider's name either. It depends on:

plan
contract or addendum
organization
workspace
model
feature
execution mode
any legal or security exceptions

An organization can have ZDR in an API workspace while simultaneously using another surface with different retention.

A concrete demonstration of the risk#

In January 2026, PromptArmor researchers published a proof of concept involving Claude Cowork. The demonstration used hidden instructions in a document to induce the agent to locate files and send content to an account controlled by the researchers. The exfiltration used Anthropic's own infrastructure as the destination.

This was not a confirmed incident at a financial institution, but a security demonstration. Even so, it reveals an important weakness: trusting only the destination's name is not enough. If the network considers all traffic to “Anthropic” trustworthy, an agent compromised by prompt injection may try to use that very permitted destination as an exfiltration channel.

This is why network control and the content gateway solve different problems.

While the network answers:

May this tool communicate with this destination?

The gateway answers:

May this user, in this session, send this content to this model for this purpose?

A gateway is not an absolute guarantee against prompt injection. It can, however, impose limits a destination allowlist cannot provide:

block files or data classes
limit volume and frequency
restrict tools
detect credentials and identifiers
prevent uploads
require approval
record the decision
stop anomalous patterns

Trust must reside in the set of controls, not merely in the domain to which the connection is being opened.

What the design demonstrates#

Data residency was treated here as an adopted architectural constraint, not a literal obligation applicable to every scenario. From that constraint came:

a gateway under the institution's control
inspection before transfer
restricted egress
fail-closed
contingency with equivalent controls
managed hooks
central identity
retention based on evidence type
a minimized audit trail
separate assessment by product

None of these pieces guarantees compliance on its own: the gateway may be misconfigured; a hook may fail; classification may produce a false negative; the provider may change a feature; telemetry may be incomplete; a ZDR model may be replaced by another requiring retention. That is why regulated architecture is not a static design. It is a system of controls that needs to be:

versioned
tested
monitored
reviewed
evidenced
adapted when the surface changes

Policy without architecture is a promise, and architecture without operations is only a diagram. Control exists when design, configuration, evidence, and process all point in the same direction.

Part 5 changes the question. Architecture ensures where data passes and which controls are applied, but does not guarantee generated code is correct. “The AI generated it” is not a defense for an invented requirement, omitted validation, or vulnerability introduced into the repository.

That is where specification-driven development comes in. Part 6 closes the concept running through this entire article. Hooks, managed settings, gateways, identity, observability, and policies are the layer built by the institution on top of what the provider delivers.

Policy promises, architecture constrains, operations provide evidence. And before an auditor, showing what should happen is not enough. It is necessary to demonstrate what the system prevented, allowed, and recorded.

Part 3, “Frameworks in practice,” translated NIST AI RMF, ISO/IEC 42001, OWASP, and GAIG into controls and evidence. Part 5 moves into spec-driven development with AI.

Links:

Part 1 - The map of what lies ahead: https://bit.ly/4oXLCsi

Part 2 - The Brazilian regulatory maze: what BACEN, CVM, ANBIMA, and the LGPD require before the first prompt: https://bit.ly/4wfQRG1

Part 3 - Frameworks in practice: NIST AI RMF, ISO 42001, OWASP, and GAIG translated into controls and evidence: https://bit.ly/4vzlXZf

CVE-2026-21852: https://nvd.nist.gov/vuln/detail/CVE-2026-21852