Privacy-by-design architecture
Build privacy decisions into the agent architecture
Privacy-by-design architecture becomes relevant when a proposed agent design distributes personal information before privacy requirements have been translated into system boundaries. A focused review would examine a data and control boundary across collection, processing, storage and tool execution. This is most relevant to enterprise architects and privacy engineering leads, especially where teams must distinguish privacy policy and enforced architecture.
Locate the privacy question inside the processing path
- Functional and privacy requirements
- Establish the processing activity and the information boundary.
- Privacy policy
- Identify the condition requiring a separate technical check.
- Access, retention and recovery constraints
- Expose the downstream conditions that qualify the conclusion.
- A privacy validation and implementation backlog
- Route unresolved questions to the appropriate decision owner.
Decision at stake
Build privacy decisions into the agent architecture
Make the decision explicit
- Enterprise architects and privacy engineering leads
- A proposed agent design distributes personal information before privacy requirements have been translated into system boundaries.
- Decision
- Which architectural choices can limit unnecessary exposure while supporting the intended workflow.
- Privacy policy
- Use functional and privacy requirements to establish the relevant starting condition.
For enterprise architects and privacy engineering leads, the immediate question is which architectural choices can limit unnecessary exposure while supporting the intended workflow. This is most useful when there is a real choice between proceeding, changing the design, collecting more evidence or narrowing the intended use. The starting conversation should identify that choice and its consequence before deciding how much work the topic warrants.
A design could rely on a policy instruction while sending full records to every component involved in the task. A useful review follows a data and control boundary across collection, processing, storage and tool execution, rather than stopping at a convenient component metric or document boundary. The evidence should separate observation, interpretation and recommendation so the accountable owner can see what it supports.
Coverage
Privacy policy and enforced architecture need different evidence
Keep the review distinctions visible
- Privacy policy
- Check enforced architecture separately.
- Centralized convenience
- Check exposure boundary separately.
- Data availability
- Check necessary use separately.
Privacy policy versus enforced architecture
Architecture options would examine where information is collected, transformed and sent. A purpose-specific interface that supplies a narrow field set would be compared with unrestricted access to a complete source record.
Centralized convenience versus exposure boundary
Enforcement would be located at relevant retrieval, tool and storage boundaries. The design would ask how a denied or ambiguous request behaves, including whether error handling creates another unnecessary information path.
Data availability versus necessary use
Privacy conditions would become implementation and validation requirements. The architecture proposal would identify what can be observed locally and what depends on provider evidence or qualified legal and privacy decisions.
Illustrative scenario
Order-status request: examine what changes the decision
Examine the constructed decision boundary
Illustrative scenario
- Order-status request
The assistant receives an entire customer profile for a narrow question.
- Reduced exposure
Compare limited retrieval and purpose-specific interfaces against task needs.
- Architecture proposal
Carry untested privacy conditions into the validation plan.
Imagine a fictional account-support agent that needs an order status but receives a complete customer profile. The proposed architecture work would examine narrower retrieval, purpose-specific interfaces and separation of retained state. Candidate designs would be compared against task requirements and validation effort. The result would be an architectural proposal with testable privacy conditions, not a claim of compliant implementation.
The narrower interface might satisfy ordinary status requests but fail on disputed orders. The proposed architecture would identify an approved exception path instead of restoring full-profile access for every request. That tradeoff would be tested with representative cases, allowing privacy and product owners to evaluate the same concrete design. These are hypothetical decision paths, not observed client outcomes.
Prerequisites
Start with functional and privacy requirements
Give each input a specific job
- Functional and privacy requirements
- Defines the operating boundary.
- Architecture and provider options
- Examine centralized convenience.
- Access, retention and recovery constraints
- Shows conditions affecting data availability.
- Privacy and data owner
- Confirm access and a reviewer who can resolve gaps.
For Privacy-by-design architecture, a named data owner should approve the evidence route and handling rules. The work needs clear purposes, relevant system boundaries and suitable specialist participation. Controlled or sanitised examples should be used where possible, with raw sensitive material retained only in approved systems and access limited to the agreed scope.
Useful starting material would include functional and privacy requirements; architecture and provider options; access, retention and recovery constraints. These inputs have different jobs: the first establishes context, the second supplies behaviour or comparison material, and the third exposes operating conditions that may qualify a conclusion. Existing material would be reviewed before requesting new collection, and a missing input would be recorded as an evidence gap rather than treated as a favourable result.
How the work proceeds
Translate approved privacy requirements into observable checks
Follow the evidence through the work
- Functional and privacy requirements
Map the approved processing purpose and scoped information path.
- Architecture and provider options
Examine this material under the data owner’s handling rules.
- Centralized convenience
Challenge this distinction using an authorised, bounded case.
- A privacy validation and implementation backlog
Separate technical findings from questions requiring qualified legal review.
Map the privacy question
Translate privacy objectives into explicit data and control requirements. The opening step turns the operating concern into a question that can be examined. It would identify a data and control boundary across collection, processing, storage and tool execution, the outcome the owner cares about and the conditions that would make an observation decision-relevant. Scope changes would remain explicit if the evidence reveals a different problem.
Define observable criteria
Compare processing locations, interfaces and storage boundaries. The comparison material would include architecture and provider options, with access, retention and recovery constraints available to explain the operating conditions. Differences between privacy policy and enforced architecture would remain visible beside the observation rather than disappear into a pooled result.
Examine the relevant paths
Design minimum necessary access and lifecycle controls for the workflow. The review question would explicitly distinguish centralized convenience from exposure boundary. A material discrepancy would be traced back to functional and privacy requirements and the relevant execution or decision record, so a proposed change addresses the observed cause rather than the most convenient explanation.
Review findings and limits
Define validation evidence and unresolved legal or provider dependencies. The resulting privacy validation and implementation backlog would explain the distinction between data availability and necessary use and identify what further observation would change the recommendation. The privacy and product owner would retain the decision, including whether a narrower scope or a different approach is preferable.
Indicative artefacts
Use a privacy validation and implementation backlog to make the next action explicit
Every artefact needs an operating use
Illustrative working format
- A privacy architecture decision record
- Boundary — functional and privacy requirements.
- A data and enforcement boundary design
- Findings about centralized convenience.
- A privacy validation and implementation backlog
- Action on data availability.
The final artefact set depends on the agreed decision. Useful outputs can include:
- A privacy architecture decision record. The working foundation for the question, including relevant definitions, boundaries and assumptions so another reviewer can understand what was examined.
- A data and enforcement boundary design. The substantive observations and interpretation, preserving adverse results, disagreement and limitations that affect how the evidence may be used.
- A privacy validation and implementation backlog. The connection to action: what the owner could do next, what evidence is still missing and what change would justify revisiting the conclusion.
Scope and authority
Technical findings need separate legal and processing decisions
Keep analytical work separate from decision authority
- Approved processing paths and technical checks
- Can include a privacy architecture decision record.
- Privacy and data owner
- Qualified legal and privacy owners interpret requirements and approve processing.
- Legal determinations or guaranteed privacy
- Cannot be inferred from a data and enforcement boundary design.
This is a proposed technical and operational privacy scope. It does not determine lawful processing, approve transfers, certify compliance or guarantee that information cannot be disclosed. Qualified privacy, legal and security review would be arranged where the actual processing or test methods require it. To discuss privacy-by-design architecture, the first practical step is to identify the relevant owner and bring a sanitised description of the decision, the current alternative and the material uncertainty. That gives scoping a concrete starting point without implying a preapproved package or favourable conclusion.
Ways to engage
Related engagement scopes
AI Agent Component Evaluation
Find where agent behaviour breaks down. Follow memory, retrieval and delegation through your workflow, then isolate the components that need attention.
AI Agent Memory Assurance
Examine what your agent remembers, when it retrieves it and whose information it can expose—in the deployment where it actually works.
AI Privacy Engineering Review
Trace personal data through your agent workflow. Examine collection, memory, retrieval, tool access and retention against your agreed requirements.
Continue exploring
Related insights and resources
Protecting agent data and memory
An agent's information footprint extends beyond the conversation. Map the copies, derived records and retrieval paths that influence future actions, then connect each to purpose, access, retention and verifiable handling.
Your agent passed the test. What does that prove?
A release decision needs a traceable connection between expected behaviour, test conditions and observed results. Here is a practical way to build that connection.
AI agents in legal operations: assistance without invented authority
Legal agents can organize evidence and prepare work, but professional judgement, client authority and verified legal positions cannot be delegated by interface.