Privacy by Design

Overview

This is the topic with a named person who can stop the project.

It is not a legal explainer — the obligations are somebody else’s expertise. It is about the three or four places where those obligations become architectural, and about the artifact that turns a potential blocker into a fast approver.

What the obligations require of the architecture

Four translations, which is the useful altitude for an architect:

Purpose limitation means you must be able to say what each piece of data is used for. Architecturally: the pipeline’s purposes are documented per data flow, and a new use of existing data is a decision rather than a convenience.

Data minimisation means not holding what you do not need. Architecturally: Module 4’s question about whether a corpus earns its place is a compliance control, not only an engineering one. The previous topic reached the same conclusion from the security side, which is worth noticing — minimisation is where privacy and security agree.

The right to erasure means a person can require their data to be removed, and it reaches derived data. This is the one with teeth and the subject of the next section.

Residency means data processed where the contract says. Module 4’s three gates cover it, and the third gate — can you evidence it — is what makes it architectural rather than contractual.

Then there is the audit regime. A SOC 2 engagement is mostly about demonstrating that controls exist, operate and are changed deliberately. Architecturally that means: the audit trail exists, retention is defined, access is controlled, and changes are recorded. Module 5’s observability plan is most of the answer, which is a pleasant surprise rather than a coincidence — the record that lets you explain a bad decision is the record an auditor wants.

Erasure is the hard one

A deletion request satisfied in the primary store and nowhere else has not been satisfied. Personal data in a system of this shape propagates into several derived forms, and each one needs an enumerated path.

graph LR
  S["Source record<br/><i>primary store</i>"] --> E["Embeddings<br/><i>in the index</i>"]
  S --> C["Cached answers<br/><i>derived from the data</i>"]
  S --> T["Traces<br/><i>the full interaction</i>"]
  S --> L["Logs and<br/>backups"]
  S --> W["Trained weights<br/><i>cannot be undone</i>"]

  classDef src fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef reach fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef never fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class S src
  class E,C,T,L reach
  class W never

Five derived forms from one source record. The four amber ones need an erasure path you build. The terracotta one is why Module 4’s rejection of fine-tuning on personal data was a privacy decision as much as a cost one.

The enumeration, which belongs in the design as a table:

Embeddings. Vectors derived from text containing personal data. You cannot search an index for a phone number, so this requires the vector-to-source mapping Module 4 specified. Without it, erasure means rebuilding the index.

Cached answers. A semantic or exact cache holding a generated response derived from someone’s data. This is the one most often missed, because the cache was built as a cost lever by someone thinking about Section 1.

Traces. Module 5’s observability plan captures the conversation, the retrieved chunks and the arguments. That store is comprehensive by design, which is exactly what makes it an erasure obligation.

Logs and backups. Backups are genuinely awkward — the usual resolution is a documented retention window rather than surgical deletion, agreed with your compliance owner rather than invented by you.

Trained weights. A model fine-tuned on personal data cannot be un-trained. Module 4 rejected fine-tuning on cost and freshness grounds; this is the stronger reason, and it is worth recording in that ADR retrospectively.

Designing for approval

The artifact matters as much as the design, and this is the Module 2 elicitation lesson spent where the leverage is highest.

A compliance owner with blocking authority is not an obstacle; they are a stakeholder whose criteria are stable, stated, and discoverable. What they need in order to say yes quickly:

A data-flow description — what enters, where it rests, where it is processed, what leaves.
A purposes list, per flow.
A retention table — what is kept, where, for how long, and why.
The erasure procedure, covering every derived form above.
The residency evidence — not the claim, the mechanism that proves it per request.
The control list with enforcement points, from the previous topic.

Six sections, a handful of pages. A reviewer handed that can assess it in an afternoon. A reviewer handed an architecture diagram and a verbal assurance will, correctly, ask for the above — in month six, when changing it is expensive.

What privacy controls cost, stated so the trade is visible: redaction removes signal, and an over-redacted corpus is compliant and useless. Minimisation removes capability. Residency removes model options and may rule out the strongest candidate. Retention limits shorten the window in which you can investigate an incident. Each is a real cost, and each is worth paying — but naming them is what makes the design credible rather than pious.

The erasure table, and the review packet

A customer exercises their right to erasure. Everything derived from their data must go.

Derived form	Erasure path	Owner
Primary ticket records	Existing deletion flow	Platform team
Vector index entries	Vector-to-source mapping from Module 4, delete by source id	Platform team
Cached answers derived from their tickets	Cache key must carry the source ids, or the cache is flushed per tenant	Gap — needs designing
Traces containing the conversation and retrieved chunks	Trace store deletion by customer id, within the Module 5 retention window	Engineering
Logs and backups	Documented retention window, agreed rather than surgically deleted	Lena Fischer
Trained weights	Not applicable — no fine-tuning on personal data, deliberately	Recorded in the Module 4 ADR

The cache row is the finding. Section 1 made caching the single largest cost lever on the action path, and nobody designing it for cost reasons was thinking about erasure. If the cache key does not carry the source ids, the only compliant erasure is a per-tenant flush — which is correct, and which costs exactly the cache warmth that the cost model depends on.

That is a genuine tension between two pillars of this module, discovered by enumerating derived data. It is resolvable — scope cache entries per tenant so a flush is bounded — but it is a design decision that has to be made in both places at once.

The review packet for Lena Fischer is the six sections above, and it is written before the build rather than after. She fears a breach with her name on it; the packet is what lets her see the controls, their enforcement points, and the residual risks stated plainly — including that injection is mitigated rather than solved. A blocker given criteria and evidence approves; a blocker given reassurance escalates.

Feeds the workbook

This is the privacy design, and two rubric items land here: the design must address erasure from embeddings rather than only the primary store, and it must be written to be reviewable by the person who can block you. Build the erasure table — it is the fastest way to find your own gaps.

→ Cost and safety are specified. Neither tells you whether the system is still any good. — From tests to evals