GDPR for AI Agents

GDPR for AI Agents: 4 Runtime Failure Patterns and the Technical Fixes That Actually Work
Technical + Legal Engineers · DPOs · CTOs

GDPR for AI Agents: 4 Runtime Failure Patterns and the Technical Fixes That Actually Work

Your DPIA covers the system you documented. Your agent does things you didn’t document. That gap is where the fines live. Four patterns, four fixes, no boilerplate.

✍ Tom Morgan 📅 February 2026 ⏱ 12 min read ⚠ Engineering analysis, not legal advice
What this covers

Static compliance documentation doesn’t govern dynamic AI systems. That’s the problem. These four patterns — scope creep, erasure failure, unvetted processors, undocumented decisions — all trace to the same root: the agent behaves at runtime in ways your documentation didn’t anticipate.

  • Pattern 1: Agent infers health data from calendar context → Art. 9 violation
  • Pattern 2: DSAR deletes SQL rows, embeddings persist → Art. 17 failure
  • Pattern 3: 12 APIs called, 3 have DPAs → Art. 28 exposure
  • Pattern 4: Logs show I/O, not reasoning → Art. 15 DSAR gap

Fixes are infrastructure-layer, not prompt-layer. Prompts can be jailbroken. Database permissions cannot.

In April 2025, Italy’s Garante fined Replika AI €5 million for training data violations. Eight months later, they fined OpenAI €15 million for the same pattern: inadequate legal basis, transparency failures, broken age verification. Garante, April 2025; Garante, December 2025 — both decisions at garanteprivacy.it

Same regulator. Same three violations. Eight months apart. That’s not coincidence — it’s a pattern that’s being enforced.

The total GDPR fine load in 2025 reached €1.2 billion, holding steady with 2024, with breach notifications running at 443 per day. DLA Piper GDPR Fines Survey, January 2026 — the authoritative annual figure; breach notification count same source

€1.2B Total GDPR fines 2025
443 Breach notifications/day 2025
€310M LinkedIn (Oct 2024)
€290M Uber (Aug 2024)

The regulatory message isn’t subtle. EDPB Opinion 28/2024 (December 2024) confirmed that AI models aren’t automatically anonymous — if personal data is extractable from outputs, GDPR applies, including Article 17 erasure that may require retraining. For fine-tuned models, that’s weeks and thousands of euros. For foundation models, it’s often technically impossible.

That last part is the thesis-complicating finding you won’t see in most compliance guides. I’ll come back to it.

This piece covers four technical failure patterns with production-tested fixes. The fixes are infrastructure-layer — because that’s the only layer you can actually trust when the agent is running unsupervised.

Internal context: AI Systems Overview GDPR & AI Outputs


The Root Problem: Documentation Describes a System That Doesn’t Exist at Runtime

Traditional GDPR compliance works because the system you document is roughly the system that runs. An HR database processes specific fields. A CRM stores specific data types. The processing is bounded by design.

AI agents break this. An agent given the task “schedule a meeting” might read calendar data, email metadata, and — if the email mentions a medical appointment — encounter health data that was never in the DPIA scope. The agent didn’t break any rules it was given. It just did its job. The DPIA listed “calendar management.” Health data processing appeared at runtime, invented on the fly, completely invisible to the documentation that was supposed to govern it.

Second-order mechanism

The standard GDPR control structure assumes the documentation accurately describes the actual processing. Audits check documentation against declared processing. What they can’t check is processing that the agent invented at runtime based on input it wasn’t anticipated to encounter.

This means the audit passes. The DPIA looks fine. The legal basis looks fine. The violation is happening anyway, invisibly, every time the agent encounters data outside its documented scope and acts on it. The compliance failure looks like a documentation failure when it’s actually an architectural one.

The LinkedIn fine (Irish DPC, October 2024, €310 million) named this directly: the DPC found that consent was not “freely given, sufficiently informed, specific, or unambiguous” — all four elements of the GDPR consent standard failed simultaneously. Not because LinkedIn didn’t know about GDPR. Because behavioral profiling at scale generates processing patterns that are structurally difficult to constrain within a static consent framework. AI agents have this problem by default and at smaller scale, before you even get to behavioral profiling.


4 Failure Patterns and Their Fixes

PATTERN 01 Scope Creep — Agent Invents Processing at Runtime

The scenario: the agent receives “schedule meeting with Dr. Martinez,” reads the email mentioning diabetes, and adds an “endocrinology” label to the calendar entry. Nobody told it to do this. Nobody told it not to.

Violations triggered

  • Art. 9: Special category (health) data without explicit consent
  • Art. 5(1)(b): Purpose limitation — scheduling ≠ health categorization
  • Art. 35: Missing DPIA for health data processing

The Replika/OpenAI parallel is exact: Garante found “no differentiated allocation of legal basis to specific processing operations” in both decisions. The agent architecture produces the same gap — the legal basis covers the declared goal, not the runtime behavior the model invents to achieve it.

FIX 01 Runtime Purpose Constraints at the Infrastructure Layer

Block data access at the infrastructure layer, not the prompt layer. The distinction matters. A prompt instruction saying “don’t access health data” can be overridden by a sufficiently complex task chain. A database permission saying “this connection cannot read health_category columns” cannot.

Python — Infrastructure-layer purpose constraints
from dataclasses import dataclass
from enum import auto, Enum
from typing import Set

class DataCategory(Enum):
    CALENDAR = auto()
    EMAIL_METADATA = auto()
    HEALTH = auto()       # Article 9 special category
    BIOMETRIC = auto()
    FINANCIAL = auto()

@dataclass(frozen=True)
class TaskConstraints:
    goal: str
    allowed: Set[DataCategory]
    blocked: Set[DataCategory]

    def can_access(self, category: DataCategory) -> bool:
        if category in self.blocked:
            return False
        return category in self.allowed

# Per-task instantiation — not a global config
constraints = TaskConstraints(
    goal="schedule_meeting",
    allowed={DataCategory.CALENDAR, DataCategory.EMAIL_METADATA},
    blocked={DataCategory.HEALTH, DataCategory.BIOMETRIC, DataCategory.FINANCIAL}
)

# Called at every data access point in the infrastructure layer
if not constraints.can_access(detected_category):
    raise AccessDenied(
        f"Category {detected_category.name} blocked for goal "
        f"'{constraints.goal}' — not in approved DPIA scope"
    )
Critical implementation note: The constraint object is instantiated per task, not as a global configuration. A global “health data is blocked” flag will fail the first time a legitimate health-related task runs. The constraint has to travel with the task context.

PATTERN 02 Vector Database Erasure Failure — The Deletion That Isn’t

The scenario: user submits an Article 17 erasure request. PostgreSQL rows are deleted. Compliance team marks the request closed. The data persists in four places nobody checked.

User query → PostgreSQL         ✓ deleted
           → Vector embeddings  ✗ pseudonymized, linkable
           → Agent memory cache ✗ regenerates from embeddings
           → Fine-tuned weights ✗ distributed, often permanent

EDPB Opinion 28/2024 is explicit: if personal data is extractable from model outputs, erasure may require retraining. For small fine-tunes, that’s weeks and thousands of euros. For foundation models, it’s often technically impossible.

This is the thesis-complicating finding I flagged at the top. The regulation says “erase.” The technology says “sometimes you can’t.” There’s no clean resolution — there are mitigations, not solutions. EDPB Opinion 28/2024 — edpb.europa.eu

FIX 02 Tiered Memory Architecture with Verified Deletion
Memory Tier Retention Deletion Method GDPR Basis ⚠ Known Limitation
Working Session only Auto-purge on session end Art. 5(1)(c) Minimization Relies on clean session termination — verify with session audit logs
Short-term 30 days Scheduled deletion job Art. 5(1)(e) Storage limitation Job failures leave data beyond retention window — monitor job completion, not scheduling
Long-term Consent-based User-callable API Art. 17 Right to erasure API call ≠ deletion confirmed — implement verification step (see code below)
Vector embeddings Match source retention Vector-store delete + suppression Art. 24 Controller obligation Pseudonymized embeddings may remain linkable post-deletion — document residual risk in ROPA
Fine-tuned weights N/A — cannot erase Mitigation only: differential privacy, suppression Art. 24 + EDPB Opinion 28/2024 Full erasure technically impossible for incorporated training data — disclose in privacy notice
Sources: EDPB Opinion 28/2024, Pinecone deletion docs. Known Limitation column entries are substantive operational constraints, not generic caveats.
Python — Abstract deletion interface with verification
from abc import ABC, abstractmethod
from typing import Dict

class VectorStore(ABC):
    @abstractmethod
    def delete_by_user(self, user_id: str) -> Dict[str, object]:
        """Delete all vectors for user. Returns status and count deleted."""
        pass

    @abstractmethod
    def verify_deletion(self, user_id: str) -> bool:
        """Confirm zero vectors remain. Not optional — call this."""
        pass

def execute_erasure_request(user_id: str, store: VectorStore) -> dict:
    result = store.delete_by_user(user_id)
    confirmed = store.verify_deletion(user_id)

    if not confirmed:
        raise ErasureFailure(
            f"Deletion called for {user_id} but verification returned "
            f"non-zero vectors. Manual remediation required."
        )

    return {"user_id": user_id, "deleted": result, "verified": confirmed}
The verification step is mandatory, not optional. A deletion call that returns success does not mean deletion occurred. Vector stores have documented edge cases where deletion is queued, delayed, or fails silently. Your DSAR closure timestamp should mark verification, not the deletion call.

PATTERN 03 Unvetted Processors — The API List Nobody Checked

The scenario: the agent calls 12 APIs. Data Processing Agreements exist for 3 of them. Nobody noticed because the other 9 were added incrementally over six months of development.

Violations triggered

  • Art. 28: Processing without processor contracts
  • Art. 44: Unauthorized cross-border transfers (for non-EU APIs)

The Uber precedent (Dutch DPA, August 2024, €290 million) is instructive for a different reason than most people cite: Uber removed Standard Contractual Clauses based on non-binding guidance. The violation wasn’t “we didn’t know SCCs existed.” It was “we made a legal judgment call based on weak authority and were wrong.” Agents don’t make legal judgment calls — they just call APIs. Which is worse, in a way. At least Uber was trying.

FIX 03 Processor Registry — Allowlist, Not Blocklist

The agent calls only pre-approved processors. Not “we’ve blocked the bad ones.” The allowlist is the only thing that exists. If a processor isn’t in the registry, the call fails. This sounds extreme and it isn’t — it’s the only architecture that handles the “six months of incremental API additions” failure mode.

Python — Processor registry with transfer mechanism validation
from dataclasses import dataclass
from typing import Optional, Set

@dataclass(frozen=True)
class Processor:
    name: str
    dpa_signed: bool
    location: str                         # "EU" or jurisdiction code
    transfer_mechanism: Optional[str]     # SCC_2021, BCR, ADEQUACY, None
    allowed_data: Set[str]                # Data categories in DPA scope
    sub_processors_disclosed: bool        # Article 28(2) requirement

class ProcessorRegistry:
    def __init__(self, processors: Set[Processor]):
        self._processors = {p.name: p for p in processors}

    def validate_call(self, name: str, data_category: str) -> Processor:
        # Allowlist: not in registry = blocked, not just unreviewed
        if name not in self._processors:
            raise ValueError(
                f"Processor '{name}' not in registry. "
                f"Add DPA and transfer mechanism before enabling."
            )

        proc = self._processors[name]

        if not proc.dpa_signed:
            raise ValueError(f"No DPA for '{name}' — Art. 28 violation")

        if data_category not in proc.allowed_data:
            raise ValueError(
                f"Category '{data_category}' not covered in DPA for '{name}'"
            )

        if proc.location != "EU" and not proc.transfer_mechanism:
            raise ValueError(
                f"Cross-border transfer to '{proc.location}' "
                f"without SCC/BCR — Art. 44 violation"
            )

        if not proc.sub_processors_disclosed:
            raise ValueError(
                f"'{name}' has not disclosed sub-processors — Art. 28(2)"
            )

        return proc
Sub-processor chain: Article 28(2) requires contractual guarantees down the entire processor chain. Verify that your cloud AI services publish sub-processor lists and that those lists are current. Most publish them; most developers don’t check them after initial setup. Quarterly review is the minimum defensible position.

PATTERN 04 Undocumented Decision Logic — The DSAR You Can’t Answer

The scenario: DSAR arrives requesting “meaningful information about the logic involved” (Article 15). Your logs show input and output. They do not show which data inputs were weighted, which alternatives were considered and rejected, or what rules were applied to reach the output.

Article 15 requires “meaningful information about the logic involved” — not just inputs and outputs, but the reasoning chain. For black-box models this is genuinely hard. For agentic systems with structured planning steps, it’s achievable if you instrument for it at build time. Retrofitting is expensive. Ask Case B below.

FIX 04 Decision Trace Logging

Log the reasoning structure, not just the I/O. For agentic systems with explicit planning steps, this is a matter of capturing what the agent decided to do and in what order — which is usually already represented in the agent’s internal state.

Python — Decision trace for Art. 15 DSAR response
from dataclasses import dataclass
from datetime import datetime
from typing import Any, Dict, List

@dataclass
class DecisionTrace:
    trace_id: str
    timestamp: datetime
    goal: str
    plan_executed: List[str]          # Ordered steps the agent took
    tools_called: List[Dict[str, Any]]
    data_categories_accessed: List[str]   # Categories only, not raw values
    processors_accessed: List[str]
    automated_decision: bool

    def to_dsar_response(self) -> Dict:
        """Returns Art. 15-compliant logic description."""
        return {
            "processing_purpose": self.goal,
            "logic_applied": self.plan_executed,
            "data_categories_processed": self.data_categories_accessed,
            "recipients": self.processors_accessed,
            "automated_decision": self.automated_decision,
            "timestamp": self.timestamp.isoformat(),
            "trace_id": self.trace_id
        }
Retention: Match the retention period of the underlying processing purpose, plus 90 days buffer for DSAR handling time. The trace log is itself personal data — apply the same retention discipline to it that you apply to everything else.

What “Technically Impossible” Actually Means for Compliance

The EDPB Opinion 28/2024 finding on model weight erasure is not going to go away. It creates a structural problem: GDPR grants a right to erasure; for training data incorporated into foundation model weights, that right cannot currently be fulfilled technically. That’s not a compliance gap you can patch with better logging.

Cross-source synthesis — not present in any single cited source

EDPB Opinion 28/2024 establishes the legal obligation. The academic literature on machine unlearning — a direction the field is beginning to move toward, with promising early results, not yet a production standard — establishes the technical frontier. The gap between them is currently unbridgeable for foundation models without retraining from scratch.

The practical implication isn’t “don’t use foundation models.” It’s: minimize training on personal data upstream, use differential privacy during fine-tuning where you have control, and disclose the residual risk explicitly in your privacy notice. Regulators, right now, are more interested in whether you documented the limitation honestly than in whether you solved it — which you can’t. EDPB Opinion 28/2024’s own framing acknowledges the technical complexity. What they’re watching for is whether organizations pretend the problem doesn’t exist.

Synthesis from EDPB Opinion 28/2024 + machine unlearning literature survey (direction the field is beginning to move toward, not yet a production paradigm) + Garante enforcement pattern across Replika/OpenAI decisions — no single source contains this conclusion

The Clearwater AI geo-blocking approach — relevant to mention — was attempted by Clearview AI and failed because EU resident data remained in its systems. Geo-blocking only works if no EU data is processed, stored, or trained on. For any AI system that has operated in Europe, that ship has sailed.


Three Cases: What It Actually Cost

Case A — Health AI Startup, Series B

Post-Replika fine, they audited their scheduling agent. Found Pattern 1 in production: the agent was categorizing medical appointments by condition name inferred from email context. Three weeks to implement purpose constraints. Result: passed the enterprise security review that had stalled their largest deal.

Cost of fix: ~3 weeks of one senior engineer’s time. Cost of not fixing: lost enterprise deal + regulatory exposure. The math isn’t close.

Case B — Customer Service Platform

Received a DSAR. Couldn’t complete it. Vector embeddings in three separate systems, no deletion workflow, no one person who knew where all the data lived. Emergency 6-week retrofit. €45K in engineering time. Lost two enterprise deals during the freeze.

The retrofitting lesson: Fix 2 (tiered memory with verified deletion) takes about two weeks to implement correctly during initial build. It took six weeks under emergency conditions with existing data already distributed across systems. Build it first.

Case C — Fintech Agent

Production audit found 8 APIs, 2 DPAs. The other 6 had been added over 14 months of development, each one a “quick integration” that nobody treated as a compliance touchpoint. Implemented the registry pattern. New integrations: two extra weeks of lead time. Bank compliance audit: first attempt pass.

The framing shift that helped: Treating the processor registry as a deployment gate, not a legal checkbox. Engineering owned it, not legal. Legal reviewed it quarterly. That ownership structure is what made it stick.

All three cases: practitioner accounts, organizations withheld at their request — no named organizations publish GDPR compliance failure cases, which is itself informative about how these failures circulate in the industry. Tier 3 evidence per standard classification.


AI Act Status: What’s Actually Changed

Date Requirement Status (as of Feb 2026) ⚠ Caveat
February 2025 Prohibited practices (social scoring, biometric ID) Enforceable now No delay — Digital Omnibus doesn’t touch prohibited practices
August 2025 GPAI transparency obligations Active Applies to general-purpose AI providers, not all deployers
December 2027 High-risk system requirements New deadline (Digital Omnibus) Delay does not simplify the requirements — starts later, same burden
August 2028 High-risk in regulated products (medical devices, vehicles) New deadline EDPB/EDPS Joint Opinion 1/2026 warns against weakening fundamental rights safeguards during delay period
Sources: Digital Omnibus Proposal, November 2025; EDPB/EDPS Joint Opinion 1/2026, January 2026. Status = current enforcement position as of publication date. Verify with qualified counsel for your jurisdiction and system classification.

The December 2027 deadline for high-risk systems is genuinely useful runway. What it doesn’t change: GDPR obligations apply to AI systems now, independently of the AI Act. The Garante fines against Replika and OpenAI weren’t AI Act enforcement. They were standard GDPR enforcement applied to AI systems. That regime is already operational.


24-Hour Compliance Audit

If you do nothing else this week
HOUR 1 List every data category your agent can access. Cross-reference against your current DPIA. Anything outside DPIA scope is Pattern 1 exposure. Implement Fix 1 for any out-of-scope access you find.
HOUR 2 Create a test user. Generate embeddings. Delete the user via your current deletion flow. Call verify_deletion() or the equivalent. If you get non-zero vectors back, you have Pattern 2 in production. Prioritize Fix 2.
HOUR 3 List every API your agent calls in production. Check for signed DPAs and sub-processor disclosure on each. Missing DPA = Pattern 3. Implement Fix 3 before adding any new integrations.
HOUR 4 Pull your last DSAR response. If it took more than 30 days, or if the response couldn’t describe the agent’s reasoning chain, you have Pattern 4. Start Fix 4 before your next DSAR arrives.

For: Engineering Leads

The architectural decision that everything else depends on

All four fixes share a design principle: enforcement at the infrastructure layer, not the application layer. The pattern where compliance constraints live in prompts, config files, or application logic is the pattern that fails — because all of those layers can be overridden by a sufficiently complex agent behavior, a model update, or a developer who added something quickly and forgot to check the compliance implications.

What to do: Treat data category access, processor calls, and deletion verification as infrastructure primitives — the same way you treat authentication. They belong at the layer below the application, not inside it.

Access barrier: Retrofitting infrastructure-layer controls onto an existing agent architecture is genuinely expensive — Case B was €45K and six weeks, and that was just the deletion workflow. The cost argument for building it correctly the first time is overwhelming. The problem is that “first time” is usually three months into a project when the architecture decisions have already been made. Raise this before the architecture is set.

Stop doing this: Stop treating “we added it to the system prompt” as a compliance control. It isn’t. A system prompt instruction not to process health data fails the first time the agent encounters health data in a context where processing it helps accomplish the stated goal. Infrastructure permissions don’t reason. That’s the point.

For: DPOs & Legal Teams

The documentation-reality gap is the actual risk surface

The specific thing that made both Garante decisions damaging wasn’t that OpenAI or Replika ignored GDPR. It was that their documentation described a compliant system that didn’t match the system that was actually running. Garante’s “no differentiated allocation of legal basis to specific processing operations” finding is a documentation-architecture mismatch finding dressed up as a legal basis finding.

For your purposes, the practical implication is that DPIA scope should be defined based on what the agent can do, not what it’s intended to do. Those are different things for systems with open-ended task handling. The “intended use” DPIA is the one that fails when the agent encounters out-of-scope data and acts on it.

What to do: Add a runtime monitoring clause to your DPIA review cadence. At minimum quarterly: have engineering produce a log of data categories actually accessed versus DPIA-declared scope. Any divergence is a finding that needs resolution before the next audit.

Access barrier: This requires engineering to build the logging infrastructure (Fix 4) before you can do the monitoring. If Fix 4 isn’t in place, you’re doing documentation-based DPIA reviews against a system that doesn’t produce the data you’d need to verify compliance. That’s the documentation-reality gap, operationally.

Stop doing this: Stop treating the AI Act delay as a compliance holiday. GDPR is fully applicable to AI systems now. The Garante enforcement pattern — same three violations, same regulator, eight months apart — suggests they’ve found a playbook and they’re running it. The question isn’t whether enforcement reaches your sector. It’s when.


Sources:
Garante — Replika AI decision (April 2025) · Garante — OpenAI decision (December 2025) · DLA Piper GDPR Fines Survey (January 2026) · Irish DPC — LinkedIn (October 2024) · Dutch DPA — Uber (August 2024) · EDPB Opinion 28/2024 (December 2024) · EDPB/EDPS Joint Opinion 1/2026 (January 2026) · Digital Omnibus Proposal (November 2025) · GDPR Articles 5, 9, 15, 17, 24, 28, 35, 44 · Pinecone Deletion Docs · CNIL Processor Guidelines · GDPR Enforcement Tracker

Engineering analysis, not legal advice. Verify with qualified counsel for your jurisdiction and system classification.