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 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:

Plans rewritten mid-run — APIs the agent calls were not anticipated in the DPIA.
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.
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.
Derived artefacts persist — vector embeddings, summaries, labels stay beyond task scope, violating storage limitation.
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 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 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