Class 11 — GDPR Article 17 erasure verification

A churned tenant invokes their right to be forgotten under GDPR Article 17. The DSR platform handles the primary stores; deletion scripts run. But the data also lives on the AI surfaces — vector DBs, tracing pipelines, agent memory, semantic caches, fine-tunes, search indexes, eval sets. Class 11 is the probe that verifies the data has actually left every configured AI surface.

Goal

Prove a designated tenant's data has actually left every AI surface after an erasure request. The output is a per-surface verdict: ERASED / RESIDUAL DATA (with itemized marker counts) / NO BASELINE (pre-erasure scan found no markers on that surface, so erasure cannot be attested for it).

Method

  1. Pre-erasure baseline. Confirm the target tenant's HARD_CANARY markers are present across all configured surfaces. If a surface returns no markers pre-erasure, the engagement halts — without a baseline to erase against, the post-erasure scan can only return NO BASELINE for that surface, and an attestation that is silent on a surface attests nothing about it.
  2. Erasure window. The customer triggers their erasure workflow (Securiti, OneTrust, custom scripts). Sectum AI does not interfere; the workflow runs against the customer's stores as it normally would.
  3. Post-erasure verification. Re-scan every configured surface for any residual marker. Per-surface verdict lands in the run record.
  4. Attestation pack assembly. The per-surface verdicts go into a control-mapped audit PDF (GDPR Art. 17 / 32, EU AI Act Art. 15) along with the tamper-evident chain: RFC 3161 timestamp, optional Sigstore Rekor inclusion proof, in-toto attestation envelope. The pack is the deliverable; the DPO hands it to the data subject or files it.

Surfaces verified

The standard erasure scope covers up to ten places customer data hides on the AI surface:

  1. Vector DB (namespaces, orphaned collections, soft-deleted vectors)
  2. Prompt / completion logs (Langfuse, LangSmith, Helicone, Phoenix, Datadog APM)
  3. Fine-tuning datasets / adapters
  4. Eval golden sets / test fixtures
  5. Semantic + application caches (Redis, Memcached)
  6. Conversation / agent memory stores
  7. Backup snapshots / exports
  8. Third-party subprocessor residue (provider retention despite ZDR claims — verified by probing, documented as attestable-with-caveat)
  9. OpenTelemetry / tracing pipelines with embedded prompts
  10. Search indexes derived from the RAG corpus

Detection

Any residual marker post-erasure is itemized as RESIDUAL DATA for that surface. Detection uses the same layered pipeline as every other probe: exact canary scan first (zero false positives on HARD_CANARY), then semantic similarity, then a calibrated judge. The manifest binds every confirmed finding to a specific planted marker; the erasure verdict per surface inherits the same zero-false-positive property.

What we attest, what we don't

Sectum AI verifies and attests; we do not remediate findings. If a surface returns RESIDUAL DATA, the pack itemizes the residual marker count and the surface — the remediation belongs to the customer's platform team. The pack is the proof, not the fix.

The control mappings on the pack are assertions of test coverage, not legal certification. The DPO and counsel make the certification call. The wording is explicit in the pack itself.

Engagement shape

Class 11 backs the Erasure Attestation engagement — a 7-day end-to-end engagement from kickoff through attestation delivery. Full engagement walkthrough at erasure attestation and the deliverable detail at erasure attestation deliverable.

References