Compliance and Data Handling: What the Architecture Must Provide

The bookshop platform handles customer PII: names, addresses, order histories, payment references, and every support conversation a customer ever had. The moment a system holds data like that, it inherits obligations, and those obligations shape the architecture as firmly as any latency SLA. This chapter is about designing for them. One thing up front, and the series intro said it too: this is architecture guidance, not legal advice. Your compliance and legal teams own what the law requires in your jurisdiction for your data. What an architect owns is making sure the system can provide what those teams ask for. That distinction is the whole chapter, and it’s also exactly how the exam frames it.

What compliance means for an architecture

It’s tempting to treat compliance as a document problem: a policy PDF, a checkbox, an audit once a year. For an architect it’s the opposite. Compliance is a set of properties the system must have, designed in from the start, because most of them cannot be bolted on afterward. You don’t add data residency to a system that already scattered data across three regions. You don’t add “prove who accessed this customer’s record” to a system that logged nothing. The architect’s job is to translate obligations into properties, and to build the system so those properties hold by construction.

The reframe that makes this tractable: stop reading regulations as rules to obey and start reading them as requirements to satisfy. A regulation says “data subjects can request deletion.” As an architect you don’t argue with that; you ask what capability the system needs to provide deletion, and you build it. This is why the same handful of capabilities show up under wildly different legal regimes. The laws differ; the architectural provisions they demand rhyme.

The data-handling properties you design for

Nearly every data-protection obligation reduces to a small set of properties. Master these and you can meet requirements you haven’t read yet, because you’ll recognize which property a new obligation is really asking for.

Data residency. Where data physically lives, and where it’s processed, must be controllable. Some obligations require certain data to stay within a region or country. Architecturally this constrains your model provider, your storage, your vector index, and your logs. Make the decision at design time: migrating a live system’s data geography later is brutal. Know where each byte lands, including the copies that hide in prompt logs and traces.
Retention limits. Data should not live forever. You design for a defined lifetime per data class, plus a mechanism that actually deletes the data when the clock runs out. The alternative is accumulating everything indefinitely because storage is cheap. Retention is a property of the design, not a cleanup job someone remembers to run.
Encryption in transit and at rest. Data moving between services is encrypted on the wire; data sitting in storage is encrypted on disk. This is table stakes, and it’s non-negotiable for regulated data. The architectural work is ensuring there are no plaintext gaps, including the easily-forgotten ones: a debug log, a cache, a message queue, an analytics export.
Audit trails. You must be able to answer, later and credibly, who did what to which data, and when. Every access to sensitive data and every consequential action leaves an immutable record. This is where the PreToolUse/PostToolUse hook from Foundations earns its keep beyond guardrailing. The same interception point that can deny a call can log every tool invocation and its arguments. That gives you a tamper-resistant trail of exactly what the agent did. Audit logging that runs in your code, outside the model, is a provision the model cannot skip.
Least privilege. Every component gets exactly the access it needs and no more. The refund tool can process refunds and cannot read the full customer table; the retrieval layer can read the corpus and cannot write to it. This is the least-privilege discipline from Foundations applied to data. Scope each tool, each service account, and each subagent, so a compromise or a mistake is contained to a small blast radius.

These five are the vocabulary. When an obligation lands on your desk, ask which of these it’s requesting, and you’ll usually find it’s one or two of them wearing a legal label.

PII minimization: the cheapest compliance is data you never held

The single most effective data-protection decision an architect makes is also the simplest to state: don’t put data into the system that the task doesn’t need. Every field of PII you place in a context window, a log, a trace, or a cache is a field you now have to secure, encrypt, govern residency for, retain within limits, and delete on request. The data you never collected costs you none of that, and it can’t leak.

In a Claude system this discipline has a specific target: the context window. The model only needs what the task requires, so the retrieval and tool layers should hand it the minimum. Answering “where’s my order” needs an order status and maybe a shipping city; it does not need the customer’s full payment history, their address, or their entire support transcript. Design your tools to return scoped fields, not whole records. Redact or tokenize identifiers the model doesn’t need to reason over, so a customer reference rather than a raw card number reaches the context. Whatever enters the context tends to propagate into logs and traces downstream, so minimizing at the source minimizes everywhere at once.

Minimization is the property that makes every other property cheaper. A system that holds less sensitive data has a smaller residency problem, a smaller retention problem, a smaller audit surface, and a smaller breach. It’s the first design move, not the last.

Access control and vendor considerations

Two more architectural provisions round out the picture. Access control is least privilege made concrete across the whole system. That means authenticated callers, scoped permissions per tool and service, and the assumption that a component you didn’t explicitly grant access has none. In an agentic system this includes the agent’s own reach, which is why tool scoping and hook-based denial are compliance controls and not merely safety ones. The subagent isolation rule helps here too: a subagent that never receives PII in its prompt can never leak it.

Vendor and data-processing considerations are the part architects most often forget. When your system sends customer data to a model provider, that provider is now processing your data, and the obligations follow the data across that boundary. The architectural questions are concrete. What does the provider do with the data? Is it retained or used for training? What regions is it processed in? And is there a data-processing agreement that binds the provider to the handling your obligations require? For regulated health data specifically, a Business Associate Agreement (BAA) is the vendor arrangement that lets a covered entity share protected health data with a processor at all. These are contract-and-configuration decisions the architecture depends on, and they belong in your design review, not discovered in an audit.

Three regimes as classes of requirement

The exam won’t ask you to recite regulation clauses, and neither will this chapter, because that’s legal territory and it drifts. What an architect carries is a map from each major regime to the class of requirement it represents, so you know which architectural properties a scenario is pointing at. Again: architecture guidance, not legal advice.

GDPR is fundamentally about data-subject rights and minimization. It’s the regime behind “collect only what you need” and “keep it only as long as you need it.” Sharpest for a data architect is the right to deletion: a person can ask you to erase their data, and you must be able to actually do it. That’s a design requirement, not a policy sentence. You can only honor deletion if you know every place a customer’s data lives and can remove it from all of them, including the copies in logs, caches, backups, and vector indexes.
HIPAA is about protected health information (PHI) and the arrangements around it. Its architectural signature is stringent access control and audit on health data, plus the BAA with any vendor that touches PHI. If a scenario involves health data and a model provider, the vendor-agreement question is in the frame.
FedRAMP is about authorization to operate in US government cloud environments. Its architectural signature is a specific set of authorized, boundary-controlled infrastructure and continuous monitoring. For an architect the practical consequence is that your provider, your regions, and your services must be within an authorized boundary, which is a residency-and-vendor decision made very early.

The point of the map is not the acronyms. It’s that each regime, read as an architect, reduces to properties you already know how to build: residency, retention, encryption, audit, least privilege, minimization, and a vendor agreement. Learn the properties, and the regimes become recognizable rather than intimidating.

Make it concrete with the obligation the intro flagged: a bookshop customer invokes their right to deletion. A system that took minimization and residency seriously can honor it; a system that didn’t, can’t, and that’s the whole lesson. Honoring it means the architecture already knows every place that customer’s data lives: the primary store, the support-conversation history, the vector index of past interactions, the prompt and trace logs, and any cache. It can remove the data from each, then produce an audit record proving the deletion happened. The systems that fail this request fail it for three reasons. They scattered PII into logs and embeddings nobody tracked. They discovered mid-request that “delete the customer” doesn’t reach half their copies. And they had no trail to prove what they did. Deletion is designed in at the moment you decide where data lives, which is why residency, minimization, and audit are the same conversation. Build for deletion from the first schema, and the data-subject request is a routine operation instead of an incident.

What the exam is really testing

The compliance items reward an architect’s altitude, not a lawyer’s memory. They describe a system handling regulated data and ask which architectural provision meets the obligation. The right answer is one of the properties above: residency, retention, encryption, audit, least privilege, minimization, or a vendor agreement. The traps are two. One is reaching for a legal citation where a design decision is called for, because the exam tests what the architecture provides, not what a statute says. The other is over-collection, the plausible-looking answer that puts more data in the system than the task needs, when minimization was the cleaner move all along. Read every scenario as “which property does this obligation demand,” and design for the property. Keep the line the intro drew: you architect the capability to comply, and you leave the legal judgment to the people whose job it is.

Next: ethical AI — bias, fairness, and transparency as concrete design concerns, and the honest limits of what you can engineer away.