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
- 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.yamlfile. - 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.
- Erasure (day 4). Your existing erasure workflow runs (Securiti / OneTrust / custom scripts). We don't interfere; we wait.
- Post-erasure verification (day 5-7). We re-scan every surface for any residual marker. Each surface returns a verdict.
- 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
- Sectum AI Class 11 documentation — the technical implementation of the erasure-verification probe.
- Sample attestation PDF — the actual output shape you'll receive.
- Runnable example — the OSS workflow end-to-end.
- vs Securiti — why this engagement complements the DSR workflow rather than replacing it.