Erase personal data from AI systems. Prove it.
When an Article 17 erasure request arrives, Deletable destroys that person's key — their data becomes cryptographically inaccessible at once, including in backups — then deletes the underlying data within a defined window, and issues a certificate that states exactly what was verified.
- key destroyed
- inaccessible in backups
- deletion certificate
- custody you control
Deletion is a promise, not a proof
When a company is asked to delete someone's data, the honest answer is usually "we think so." Data spreads into caches, backups, replicas, and AI-derived state. Removing it everywhere, and showing that you did, is genuinely hard.
Regulators are now looking. In February 2026 the European Data Protection Board published the results of a year-long coordinated action on the right to erasure: 32 supervisory authorities, 764 controllers, seven recurring issues identified, nine authorities opening or continuing formal investigations. Under GDPR Article 5(2), it is not enough to have deleted the data. You have to be able to demonstrate that you did.
Unlearning doesn't work
Removing a person's influence from a trained model is approximate and hard to verify. The reliable path is architectural: make sure their data only ever lived in key-scoped state, so deletion becomes destroying a key.
Deletable makes deletion an event you can prove, not a promise you make.
A phased lifecycle
- 01
Destroy the key (immediate).
Each subject’s data is held under its own key, derived through a per-subject key tree. Destroying that key orphans everything beneath it in one operation — the data is cryptographically inaccessible at once, backups included. This step is self-verifying: no key opens the data, and the evidence is independently checkable.
- 02
The verifiable window.
A defined window follows, during which deletion propagates and can be checked. The window is a stated security parameter: longer means more time to verify and more exposure, and the certificate records which you chose. The window is bounded on purpose. Encrypted data that is retained indefinitely invites the argument that it was pseudonymised rather than erased, which is why the lifecycle does not stop here.
- 03
Destroy the data.
The underlying encrypted data is then removed from storage, backups, and replicas, and the certificate advances to record it. This is the step that closes the pseudonymisation question: after Phase 3 there is no retained ciphertext to re-identify, and the certificate records the date it happened.
Deletable attests destruction of data within its keyed boundary. It does not certify that no copy ever escaped that boundary, and it does not delete data from merged model weights. The certificate enumerates exactly what is and is not covered.
Every deletion produces a certificate in two clearly separated parts.
Holds even if we lie.
Coverage was not narrowed. No key opens the data. The binding to the subject is intact. Influence is gone. You can check every one of these yourself, without trusting us.
Signed by us.
The key-destruction event and the custody mode, signed. The evidence above is independently checkable today; independent signature verification is on the roadmap. We say which parts you must take on trust, and we are working to remove them.
A certificate that says what it proves, and admits what it only attests.
This is the artifact behind your Article 17 response — the record a controller hands to a supervisory authority, or to their own board, when asked to show that an erasure actually happened.
The obvious question a DPO asks: what stops you reversing an erasure?
Deletable's trust root is pluggable. Under customer-held custody, the vendor structurally cannot hold the key that would undo a deletion — and the certificate records the custody mode, measured from the live system, so a weak configuration cannot present itself as a strong one.
vendor_can_hold_root: false — recorded in the certificate, not promised in a sales call.
Under Article 28, a controller stays accountable for what their processors do. Custody mode in the certificate is how that accountability is evidenced rather than assumed.
Deletable governs the surfaces where personal data actually lives in an AI stack.
Retrieval & vector state
LIVEPer-subject deletion across vector search, running on the deletion spine today. Encrypted and bound to the subject at rest; wrong-subject reads return nothing; recall preserved under keying.
Serving & agent memory
SAME SPINEKV-cache and session memory sit on the same key tree. Not yet covered by the current certificate — stated explicitly, not implied.
Model weights
OUT OF SCOPEMerged weights are not deletable, and Deletable says so. The architecture’s job is to keep personal data out of weights and in deletable, key-scoped state.
Deletable produces mechanism and evidence. Whether an erasure request is satisfied is the controller's determination, made with their DPO. We do not make legal conclusions and we do not sell one.
The lane
Machine unlearning
Retroactively remove a person’s influence from a trained model. Approximate, hard to verify, and publicly documented as unreliable.
Deletable
Architect so personal data only ever lives in key-scoped state. Deletion becomes a key ceremony: immediate, effective across backups, and recorded in a certificate that states its own coverage. Prevention with proof, not retroactive erasure.
Manual deletion
Find and remove data by hand across systems. Doesn’t scale, and ends in “we think so.”
DSAR platforms route the erasure request. Deletable is the enforcement layer they route to, and the evidence layer they currently have to take on trust.
Built on the Cittela isolation primitive. Per-subject crypto-erasure, filed UK provisional patent applications.
Part of the Cittela family. Isolation at isovert.com, confidential vector search at nabladb.com