GDPR Article 17 erasure attestation

A one-time engagement that proves a churned tenant's data has actually left every configured AI surface — the vector DB, caches, logs, agent memory, fine-tunes — not just your primary databases. Per-surface verdicts (ERASED, RESIDUAL DATA, NO BASELINE) in a DPO-ready, cryptographically-timestamped pack you can hand a regulator.

Start an engagement    Scoped per engagement

The problem

A churned tenant invokes their right to be forgotten under GDPR Article 17. Your DSR platform (Securiti, OneTrust, custom) orchestrates the workflow: intake, triage, deletion-script generation, fulfilment, ticket close. The primary data stores are handled.

But the data also lives in the AI surfaces — the vector DB, the tracing pipeline, the agent memory, the semantic cache, the fine-tuned model adapters, the search indexes, the eval sets. How do you prove it's gone?

Securiti's own GDPR-and-AI page acknowledges: "organizations must ensure that their influence on the AI model is minimized as much as possible." That last clause is what this engagement attests — cryptographically, per-surface, in a pack a regulator will accept.

What you get

Per-surface verdicts

Vector DB, tracing, agent memory, semantic cache, model / fine-tune adapters, search index, eval set. Each surface returns ERASED, RESIDUAL DATA (counts itemized), or NO BASELINE.

Cryptographic chain

RFC 3161 TSA timestamp on the run digest. Sigstore Rekor inclusion proof. in-toto attestation envelope. Manifest hash bound into the pack so the test conditions are provable.

DPO-ready PDF

Auditor-grade attestation document — executive summary, scope and methodology, per-surface verdicts, per-finding residual-marker evidence, control mappings (GDPR Art. 17 / 32, EU AI Act Art. 15, NIST AI RMF MEASURE 2.7).

Independent verification

Anyone — you, your DPO, the regulator — runs sectum-ai verify pack and validates the chain end-to-end without trusting us. Mutating any field makes verify exit 4 with a [FAIL] line.

How the engagement works

  1. Kickoff (day 1). We collect the adapter configuration for your AI surfaces — the vector DB DSN reference, the tracing backend, the cache, the model and fine-tune adapters. No secrets cross the boundary; everything resolves from your environment variables / secret manager via references in a sectum-ai.yaml file.
  2. Substrate provisioning (day 2-3). We provision synthetic tenants for the engagement, plant cryptographic canary markers tied to the target tenant's identity, and produce the hashed ground-truth manifest. Pre-erasure baseline confirms the markers are observable on each configured surface.
  3. Erasure (day 4). Your existing erasure workflow runs (Securiti / OneTrust / custom scripts). We don't interfere; we wait.
  4. Post-erasure verification (day 5-7). We re-scan every surface for any residual marker. Each surface returns a verdict.
  5. Attestation delivery. You receive the DPO-ready PDF, the machine-readable evidence.json, the in-toto attestation envelope, the RFC 3161 timestamp token, and (if enabled) the Sigstore Rekor inclusion proof. Invoiced for the engagement.

What we attest, what we don't

Sectum AI verifies and attests; we do not remediate findings and we don't provide runtime protection. If a surface returns RESIDUAL DATA, the pack itemizes the residual marker count and the surface — the remediation belongs to your 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 wording is explicit in the pack itself.

Engagement

Scoped per engagement based on the number of surfaces in scope and the complexity of the AI stack — a minimal engagement (vector DB + tracing + 1-2 additional surfaces) is lighter than a full-stack engagement covering 7+ surfaces (including fine-tune adapters and observability backends). Start an engagement for a quote.

A continuous SKU also exists if you want this on a quarterly cadence; see engagements.

References

Start an engagement What you actually get →