---
title: "Engineering GDPR compliance in the age of agentic AI"
type: source
tags: [gdpr, agentic-ai, dpia, data-protection-by-design, runtime-controls, opinion, legal, regulatory-risk, privacy-engineering]
authors: [Navaie Keivan]
year: 2025
venue: "IAPP (International Association of Privacy Professionals) — opinion piece, 8 October 2025"
kind: webpage
raw_path: "raw/Legal/2025-navaie-iapp-engineering-gdpr-compliance-agentic-ai.pdf"
url: "https://iapp.org/news/a/engineering-gdpr-compliance-in-the-age-of-agentic-ai/"
created: 2026-04-27
updated: 2026-04-27
key_claims:
  - GDPR's principles still hold for agentic AI; what fails is the *operating model* — stable data flows, predictable toolchains, and human approvals at fixed points all break when an agent rewrites its plan mid-run.
  - Static documents (DPIAs, periodic audits) cannot govern systems whose behaviour mutates per execution. The fix is to shift from documentation to runtime *mechanisms* that enforce policy as the system runs.
  - Four engineering controls are proposed for agentic stacks: (1) **purpose locks** that gate at runtime when context shifts; (2) **execution traces** that record every plan, tool call, data category, and state change; (3) **tiered memory governance** distinguishing working memory, long-lived profiles, and vector embeddings; (4) **live controller/processor mapping** that resolves roles per call.
  - Execution traces simultaneously satisfy GDPR Art. 15 (right of access, "meaningful information about the logic"), GDPR DSAR auditability, AI Act log/post-market-monitoring obligations, and DPIA evidence.
  - Compliance and innovation are not in tension — purpose locks prevent expensive incidents, traces reduce emergency-response time, memory policies simplify deletion. The four controls let organisations confidently say *yes* to agentic use cases.
---

# Navaie 2025 — Engineering GDPR compliance in the age of agentic AI

IAPP opinion piece by **Keivan Navaie**, Professor of Intelligent Networks at Lancaster University School of Computing and Communications. Published 8 October 2025; explicitly marked "OPINION" with the IAPP editor's note that the publisher is policy-neutral. **The most concrete operational complement** to [[sources/2023-lazcoz-dehert-humans-in-gdpr-and-aia-governance|Lazcoz & de Hert 2023]] in the legal-risk cluster — where Lazcoz/de Hert frame *what meaningful intervention requires*, Navaie answers *how to engineer the system so the GDPR survives agentic runtime*.

## The core diagnosis

> *"The GDPR's compass still points true: purpose limitation, data minimization, transparency, storage limitation and accountability. What is failing is the operating model around those principles: stable data flows, predictable toolchains and human approvals at key points."*

Agentic systems break the operating model in five specific ways:

1. **Plans rewritten mid-run** — APIs the agent calls were not anticipated in the DPIA.
2. **Purpose drift at runtime** — a "schedule a meeting" task expands into health inference, credit decisions, etc., crossing into Art. 9 special-category territory without consent.
3. **Cross-border transfers via tool calls** — a translation API outside the EEA is invoked without a Standard Contractual Clauses (SCC) check or transfer-risk assessment.
4. **Derived artefacts persist** — vector embeddings, summaries, labels stay beyond task scope, violating storage limitation.
5. **Controller/processor roles flip per call** — the same plugin may act as processor on one call and determiner of purpose/means on the next, contradicting the EDPB's functional role-allocation test.

## The concrete worked example

An AI agent triages inboxes, drafts replies, manages calendars. A user asks: *"Schedule a follow-up with Dr. Rossi the week of 14 Oct."* The agent then:
- Pulls recent threads for context.
- Inspects availability via internal calendar.
- Checks travel time via a map API.
- Uploads the doctor's last message to a third-party summarizer to extract dates.
- Runs a translation service hosted outside the EEA on an Italian phrase.
- Stores vector embeddings of message and invite.
- Notices a discharge note mentioning "diabetes" and labels the mailbox "endocrinology".
- Resolves a calendar conflict with a "Union organizing meeting" via a scheduling plugin.

**GDPR violations triggered in a single task:**
- Purpose broadening from *schedule meeting* to *health inference / labour-relations inference*.
- Special-category processing (Art. 9) without an Art. 9(2) condition (e.g. explicit consent).
- Unvetted disclosure to third-party summarizer + translation service — controller/processor roles need EDPB-functional-test assessment.
- Cross-border transfer requiring SCC + transfer-risk assessment (Chapter V).
- Persistent derived artefacts (storage limitation).
- Article 22 implications: scheduling decision with significant impact + lacking meaningful human oversight.

## The four engineering controls

### 1. Purpose locks (dynamic gating)
- Surface purpose-changes at runtime; check lawful basis and compatibility (Art. 5(1)(b), Art. 6, Art. 9).
- On mismatch: **block**, request fresh consent, or route to a human approver.
- Prevents drift into Article 9 special-category territory mid-task.

### 2. Execution traces (durable, searchable record)
- Record: the plan the agent generated, each tool call executed, data categories observed/produced, where data went, every state update.
- DSAR (Art. 15) becomes mechanical instead of archaeology — what data, by which component, when, for which sub-purpose can be identified directly.
- Provides the "meaningful information about the logic" required under Art. 15 in automated contexts.
- **Same trace doubles for AI Act**: high-risk-system log requirements + post-market monitoring (Art. 12, Art. 72 AIA).
- One artefact, two compliance regimes.

### 3. Memory governance with tiers
- Treat memory tiers differently:
  - **Short-lived working memory** (a few turns of context) — strict ephemeral timeline.
  - **Long-lived profiles / vector embeddings** — purpose-scoped namespaces, retention budgets, deletion + unlearning APIs.
- Capture evidence that primary data and derived artefacts were handled per policy.
- Pragmatic implementation of storage-limitation and privacy-by-design (Art. 25).

### 4. Live controller/processor mapping
- Roles can differ per use in an agentic stack — a plugin acts as processor on one call and determines purposes/means on the next.
- Maintain a registry that resolves roles at runtime, ties resolution to contractual hooks, and records cross-border pathways.
- Couple with prechecked transfer tools (SCCs).
- Mirrors the EDPB's functional test: role allocation must reflect actual purposes/means, not formal labels.

## Implementation pattern

- **Privacy-engineering squad embedded inside the AI platform group** — the four controls (purpose locks, traces, memory controls, controller/processor cartography) are their mandate.
- **SDKs and policy-aware middleware** so compliant patterns are the default rather than the exception. This concretely implements Art. 25's design-and-default duties.
- **Privacy dashboards by run and by user** — lineage, transfer destinations, legal bases, role resolutions, open DSAR/DPIA links anchored to relevant execution traces.
- **Contracts must match runtime realities** — trace-level logging and deletion APIs in processor agreements; sub-processor notifications event-driven, not quarterly emails; deterministic role-resolution policies in code with conformity tests.

## "Why this accelerates innovation"

The author closes with a counter-narrative to the *compliance vs. innovation* framing:
- Purpose locks **prevent expensive incidents**.
- Traces **reduce emergency-response time** (answers discoverable rather than reconstructed).
- Memory policies **simplify DSARs and deletion requests**.
- The controls let organisations **say yes to agentic use cases with confidence** because evidence exists.

## Critical read

- **Strength:** the only piece in the legal cluster that translates the GDPR-vs-agentic-AI gap into concrete engineering primitives. It maps cleanly onto the [[sources/2023-lazcoz-dehert-humans-in-gdpr-and-aia-governance|Lazcoz & de Hert]] thesis that meaningful intervention + accountability is operationalised through DPIAs — Navaie's traces *are* the evidence DPIAs need.
- **Limitation:** opinion piece, not peer-reviewed; no empirical validation; the four-control framework is not a published standard. Useful as a reasoned engineering proposal, not as authority.
- **Tension with the IAPP audience framing:** the piece is directed at privacy engineers and compliance leaders, not regulators — terminology like "execution traces" is software-engineering, not legal. This is a strength for adoption but weakens its citation value.

## Connections

**Concepts:** [[concepts/gdpr-article-22]] · [[concepts/automated-decision-making]] · [[concepts/dpia]] · [[concepts/eu-ai-act]] · [[concepts/data-protection-by-design]] · [[concepts/agentic-bpm]] · [[concepts/agent-process-observability]] (Navaie's "execution traces" overlap directly with [[sources/2025-fournier-agentic-ai-process-observability|Fournier 2025]]'s observability traces — same artefact, different motivation)
**Authors:** [[entities/keivan-navaie]]
**Related sources (in this wiki):** [[sources/2023-lazcoz-dehert-humans-in-gdpr-and-aia-governance]] (legal complement) · [[sources/2025-fournier-agentic-ai-process-observability]] (BPM-side complement on traces) · [[sources/gdpr-article-22-text]]
**Syntheses:** [[syntheses/legal-risk-mapping-ai-process-automation]]