Privacy engineering for AI systems
Follow personal data beyond the first prompt.
Privacy engineering examines what information is collected, retained, retrieved and transferred through an AI workflow. Connect the intended purpose to the controls and evidence across every relevant copy.
Follow personal data beyond the first prompt
- Collection purpose
- Relates each data category to the intended workflow use.
- Derived state
- Includes memory, embeddings, indexes and operational logs.
- Access and transfer
- Tracks which identities and providers can receive information.
- Correction and deletion
- Follows changes through the retained copies in scope.
Discipline model
Trace personal data across the copies it creates
The relationships that define the discipline
- Collection purpose
- The purpose defines why a data category belongs in the workflow at all.
- Derived state
- Transformations can create additional copies beyond the original record.
- Access and transfer
- Identity and provider boundaries determine where those copies may become visible.
- Correction and deletion
- Removal or correction must propagate along the relevant derived-data paths.
A privacy boundary can span more than the original record. Prompts, retrieval stores, memory, traces and tool outputs may create or expose additional copies. Map those flows alongside the purpose and user or tenant context. This helps the privacy and engineering owners identify where minimisation, access or retention decisions must be enforced.
Working artefact
A finding should connect data, rule and behaviour
Illustrative working record
Illustrative working format
- Collection purpose
- Define the subject and the requirement the record addresses.
- Evidence reference
- Link source, version and observed condition without copying sensitive material.
- Access and transfer
- Explain the finding or choice and its consequence.
- Correction and deletion
- Assign the next action and state what remains unresolved.
A privacy control finding should identify the data category, purpose, storage or transfer point, intended rule and observed behaviour. A deletion case needs to distinguish removing the original source from preventing access through derived copies. The output should help an engineer locate the control and a privacy owner judge the requirement it serves.
Working approach
Examine the control alongside its intended purpose
Proposed investigation sequence
- Define collection purpose
State the decision and conditions the work must address.
- Map derived state
Connect the relevant actors, configuration and evidence.
- Examine access and transfer
Use agreed evidence and controlled cases where appropriate.
- Review correction and deletion
Record limits, ownership and the condition for a next decision.
Start with a representative data flow and the applicable requirements supplied by qualified owners. Identify collection, transformation, storage, retrieval and transfer points. Examine purpose limits, tenant isolation, retention and deletion propagation using authorised evidence and controlled cases. Record technical observations separately from legal interpretations and questions requiring specialist advice.
Illustrative situation
Deleting a source may leave a retrieval path
A constructed situation to reason through
Illustrative scenario
- Record deleted
A person’s source information is removed from the application.
- Derived copy remains
A retrieval index may still supply part of that information.
- Control decision
Trace deletion propagation and route the gap to the responsible owners.
Use this situation to identify the evidence that would change the decision. The proposed examination must stay within the agreed scope, and any conclusion must describe the conditions actually inspected.
Scope and next decision
Engineering findings need qualified privacy review
Prepare a bounded next discussion
- Collection purpose
- Bring one concrete workflow question and its accountable owner.
- Derived state
- Identify the evidence and access that can be made available.
- Access and transfer
- Agree the specialist involvement and responsibilities required.
- Written scope
- Confirm activities, evidence, readiness and acceptance before commitment.
This discipline provides engineering evidence and proposed controls, not legal advice or a compliance guarantee. Personal data, credentials and sensitive artefacts should remain in approved systems. Production testing and cross-provider access require specific authorisation.
Explore the discipline
Specialist areas within this capability
Choose a question to explore its methods, boundaries and indicative outputs.
- AI privacy impact assessment
- Agent privacy threat modelling
- Privacy-by-design architecture
- Sensitive-data flow mapping
- Purpose-limitation control design
- Data-minimisation review
- AI data-retention design
- Memory privacy review
- Consent management for AI interactions
- Cross-border AI data-flow assessment
- Model-provider privacy assessment
- Training-data exposure analysis
- Inference privacy review
- PII detection and redaction
- Privacy-preserving retrieval
- Tenant privacy isolation
- Right-to-access and deletion workflows
- Privacy leakage red teaming
- Confidential-computing assessment
- Synthetic-data strategy
- Differential privacy advisory
- AI privacy control validation
Related services
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.
Relevant insights
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.
The anatomy of a tool-using AI agent
A tool-using agent is a controlled system around a model, not a model with an API key. Map its runtime layers before deciding what to test, trust or release.
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.