Skip to main content

Right to Erasure for AI: Handling GDPR Deletion for Governance Records

Right to Erasure for AI: Handling GDPR Deletion for Governance Records

The hardest part of AI deletion is not the delete command. It is deciding what should still exist after the request is honored. Governance systems create multiple record types: request content, session history, decision events, escalation notes, and evidence exports. Treat them all the same and you either delete too much for operations or too little for privacy. Keeptrusts helps by giving you a documented erasure signal path through gdpr-compliance, a real session-deletion workflow through kt history delete-session, and the minimization controls that reduce how much personal data is present in governance records to begin with.

Use this page when​

  • You need a practical GDPR erasure workflow for AI traffic governed through Keeptrusts.
  • You want to delete conversation-level data without pretending that every audit artifact should disappear automatically.
  • You need a privacy program that is grounded in current Keeptrusts docs and commands.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Privacy officers, Technical Leaders, AI Agents

The problem​

Most AI governance stacks keep more than one kind of record, and those records have different purposes.

Conversation history is the obvious deletion target because it may contain the raw content that triggered the request in the first place. Export artifacts are also sensitive because they can preserve a point-in-time copy of the event stream. Decision events and escalation metadata are more complicated. They exist so teams can prove that controls were active, investigate incidents, and review operational outcomes. If those records contain raw personal data, the platform creates a direct conflict between privacy and auditability.

This is why right-to-erasure work often fails. Teams discover too late that they relied on immutable or semi-permanent logs to store information that should have been redacted before the request ever reached the control point.

There is also a process problem. Even when the downstream privacy team has a good erasure system, the AI gateway is rarely wired into it. Consent checks may exist, but erasure events do not trigger any workflow on the governed path. The result is a manual spreadsheet process that is easy to forget and hard to prove.

The solution​

Use Keeptrusts for three concrete jobs and avoid asking it to do a fourth job it does not claim to do.

First, use Compliance Policies Configuration and the gdpr-compliance policy to require the right consent header, verify it against an external service, and trigger an erasure_webhook when the request carries X-Erasure-Request. That gives the privacy system a reliable signal that an erasure-aware action occurred on the AI path.

Second, use PII Detector and DLP Filter so governance records contain less raw personal data in the first place. Erasure is dramatically easier when the platform stores labels and hashes instead of full identifiers.

Third, use History for the actual conversation-session delete workflow and Export Jobs or Export Evidence for a Review when the privacy or legal team needs a controlled evidence packet before deletion.

The fourth job to avoid is pretending that one policy block makes audit records disappear automatically. Keeptrusts gives you an erasure signal path and concrete history deletion. It does not turn AI governance into a magical no-records system. The right answer is minimization plus targeted deletion plus documented review evidence.

Implementation​

This policy chain enforces consent on the request path, emits a webhook when an erasure request is flagged, and redacts common identifiers before content reaches the provider.

pack:
  name: gdpr-erasure-workflow
  version: "1.0.0"
  enabled: true

policies:
  chain:
    - gdpr-compliance
    - pii-detector
    - audit-logger

policy:
  gdpr-compliance:
    consent_required: true
    consent_header: X-GDPR-Consent
    consent_verification_endpoint: https://privacy.internal.finneuron.com/consent/verify
    erasure_webhook: https://privacy.internal.finneuron.com/erasure/notify
    data_categories:
      - personal
      - sensitive
      - support
    retention_days: 30
    timeout_ms: 3000

  pii-detector:
    action: redact
    pci_mode: true
    redaction:
      marker_format: label
      include_metadata: true

  audit-logger: {}

The request-side control is only half the story. Once a privacy case is approved, use the CLI to export what needs review and then delete the captured session data explicitly:

kt history export session_20260514_finneuron_7f3a9e --format json --output erasure-review-session.json
kt history delete-session --session-id session_20260514_finneuron_7f3a9e --yes
kt export-jobs create --type events --format json --date-from 2026-05-01 --date-to 2026-05-31

kt history export gives the privacy or legal team a bounded artifact for case review. kt history delete-session performs the concrete session deletion. kt export-jobs create is useful when the review needs a wider time-bound evidence package rather than one conversation transcript.

The operational discipline matters more than the command itself. Export only what the review requires, delete the session once the case is ready, and keep event-level evidence scoped to the minimum window needed for the decision. That is how you prevent the erasure workflow from creating a second archive of the very data you are trying to reduce.

If your organization has a dedicated privacy owner, Privacy Officer is a useful companion page because it frames consent-gated access, data-subject rights, and DPIA evidence in one operational context.

Results and impact​

The main benefit of this pattern is that erasure stops being a purely legal instruction and becomes an operational flow with checkpoints.

Session-level data can be deleted through a concrete command. Privacy systems receive an erasure signal through the gateway path. Reviewers can export only the evidence needed for the case instead of handing around whole logs by default. Most importantly, minimization reduces the amount of personal data that remains in governance artifacts after the session itself is gone.

That is a far better posture than trying to retroactively scrub every record after the fact.

Key takeaways​

  • Use gdpr-compliance for consent checks and erasure webhook signaling on the request path.
  • Use History for actual session deletion when a case is approved.
  • Use exports sparingly and deliberately so deletion workflows do not create new uncontrolled copies.
  • Make erasure easier by minimizing and redacting personal data before the request is logged or reviewed.
  • Treat AI governance records as multiple data classes, not one undifferentiated archive.

Next steps​