Skip to main content

GDPR and AI: Governing Personal Data Processing in LLM Workflows

GDPR applies to AI workflows whenever personal data appears anywhere in the chain: prompts, retrieved context, model outputs, logs, or provider-routing decisions. Regulation (EU) 2016/679 does not have an "LLM exception." If a user asks a model to summarize a complaint file, classify customer emails, draft an HR response, or answer a support ticket with personal data in context, you are processing personal data. Keeptrusts helps by enforcing data minimization, narrowing provider eligibility, and preserving an accountable evidence trail, but it does not create a lawful basis, write your privacy notice, or complete your transfer assessment for you.

Use this page when​

  • You need to apply GDPR principles to prompt, retrieval, and output flows that touch personal data.
  • You want an implementation-focused view of where Keeptrusts helps and where privacy governance stays outside the gateway.
  • You need a practical baseline for LLM routes that handle customer, employee, or patient-adjacent data.

Primary audience​

  • Primary: Privacy officers, compliance officers, platform engineers
  • Secondary: Security teams, data protection leads, product counsel

The problem​

The main GDPR risk in LLM workflows is not just that personal data enters a prompt. It is that the same data can appear at multiple stages and in multiple forms. A prompt may contain a name or account number. The retrieval layer may add emails, case notes, or transcripts. The provider may process the full combined request. The model output may restate the data. Logs and exports may preserve a record of what happened.

That multi-stage processing makes several GDPR principles relevant at once. Article 5 requires lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, confidentiality, and accountability. Article 25 requires data protection by design and by default. Article 28 matters when providers operate as processors or sub-processors. Article 32 requires appropriate security. Articles 44 to 49 matter when international transfers are involved. If special category data under Article 9 is present, the stakes increase again.

Teams often respond with policy statements rather than technical constraints. They tell employees not to paste personal data into AI tools, but the route still allows it. They prefer EU providers, but the gateway still falls back to any target. They say personal data is minimized, but outputs can reintroduce it and logs retain the trace.

The solution​

Keeptrusts gives you a practical GDPR control pattern for LLM traffic.

For Article 5 data minimization and Article 25 privacy by default, use pii-detector to redact or block known sensitive identifiers before upstream routing. The detector is especially useful when the safest route is to remove personal data at the input boundary unless a route explicitly requires it.

For provider governance and transfer control, use data-routing-policy. It filters providers.targets[] according to the declared data_policy metadata, including zero-data-retention, training opt-out, retention limits, internet egress, and local-only processing flags. That does not replace a transfer impact assessment, but it prevents casual routing to providers that do not meet the route's stated privacy constraints.

For accountability, pair route controls with decision events and exports. The current audit-logger policy is an allow-only audit marker in the chain. Actual record persistence and exports happen in the platform around it. That still matters because it makes the governed path visible and reviewable.

Where sensitive or regulated personal data is involved, route separation is critical. A low-risk drafting assistant should not share the same provider pool or redaction expectations as a workflow processing customer complaints or employee investigations.

Implementation​

The following example is a realistic privacy-first route for LLM workflows that should minimize personal data exposure and restrict provider selection.

pack:
  name: gdpr-llm-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: eu-zdr-provider
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        allow_internet_egress: false
        accepts_tokenized_input: true

policies:
  chain:
    - pii-detector
    - data-routing-policy
    - audit-logger

policy:
  pii-detector:
    action: redact
    healthcare_mode: false
    pci_mode: false
    detect_patterns:
      - 'EMP-\d{6}'
      - 'CASE-\d{8}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-ID]"

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    tokenize_sensitive_fields: true
    allow_internet_egress: false
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

This configuration does a few important things. It removes obvious identifiers before the provider sees them, extends detection to route-specific employee and case references, and blocks the request if no provider target meets the declared privacy constraints. That means privacy requirements are not advisory. They alter routing behavior at runtime.

The next design step is usually route-specific policy. If a workflow involves Article 9 special category data, a generic redact-and-forward path may still be too permissive. In that case, the safer route is often a tighter provider pool, additional application-side access controls, and a more explicit decision on whether the workflow should use an external model at all.

This is also where cross-framework clarity helps. For financial entities, the same routing and evidence controls may support operational resilience evidence under DORA, Regulation (EU) 2022/2554. That is useful, but DORA does not replace GDPR and GDPR does not replace DORA. The lawful-basis and transfer analysis remain privacy questions even when the same gateway produces operational logs.

For the core product references, keep Configuration & Policy Overview, PII Detector, Data Routing Policy, EU AI Act Compliance, Meet EU AI Act Requirements with Pre-Built Controls, and Compliance Officer Guide close at hand.

Results and impact​

The practical outcome is that privacy controls move closer to the processing point. Instead of relying on user discipline alone, the gateway removes data, rejects non-compliant routing choices, and creates a visible record that the governed route ran under the expected policy chain.

That improves internal accountability. Privacy teams can review which routes require zero-data-retention. Security teams can see when a provider was excluded for policy reasons. Product teams can distinguish between routes that are safe for summarized content and routes that should never accept raw personal data.

Most importantly, this pattern reduces quiet scope creep. The more successful an internal AI assistant becomes, the more likely people are to start pasting in regulated data. Route-level privacy controls make that behavior observable and enforceable before it becomes an informal business process.

Key takeaways​

  • GDPR applies to LLM workflows whenever personal data is processed, not only when data is stored.
  • pii-detector supports data minimization at the input boundary and helps implement privacy-by-default patterns.
  • data-routing-policy turns provider restrictions into runtime behavior instead of procurement assumptions.
  • Current audit-logger behavior should be described accurately as a marker in the chain, with evidence persistence handled by platform services around it.
  • Keeptrusts supports GDPR implementation, but lawful basis, notices, contracts, and transfer analysis still require separate privacy work.

Next steps​