What's the difference between contractual and architectural zero-retention?
The difference is where the data actually travels. In the contractual model, the data reaches the vendor's servers, is processed there, and the vendor commits to deleting it. In the architectural model, processing happens on the user's side — in the browser or on the device — and the data is simply never sent anywhere.
| Aspect | Contractual zero-retention | Architectural zero-retention |
|---|---|---|
| Where data travels | Reaches the vendor's servers, deleted after processing | Stays on the user's device — never sent |
| What you rely on | A promise, a contract, and the vendor's implementation | A technical design you can verify (network traffic) |
| Exposure to vendor bugs or breaches | Exists — during processing the data is there | None — there is nothing to breach |
| How to verify | Policy documents, DPAs, third-party audits | Open Developer Tools and confirm nothing is uploaded |
Why isn't a contractual promise enough for sensitive documents?
Because a promise is only as good as its implementation. Even a perfectly honest vendor is exposed to bugs, forgotten logs, backup copies and breaches — and the moment your data sits on someone else's server, it is part of that vendor's attack surface, as we explain in our guide to preventing AI data leaks.
- The processing window — even "immediate deletion" leaves a window in which the data exists on the server.
- The subprocessor chain — your vendor runs on cloud infrastructure and third-party services; the promise must cover all of them.
- Policy changes — terms of service change; architecture doesn't.
- Regulatory weight — under GDPR, sending personal data to a processor requires a data processing agreement and oversight; data that is never sent needs none of that.
How does browser-side processing deliver true zero-retention?
When the processing runs as code in your own browser, the file is opened, scanned and transformed on your local machine only. No document is uploaded and no results are sent back — so there is no deletion promise to trust: there is nothing to delete. That is also the practical answer for teams adopting AI safely: prepare the document locally, then use whatever AI tool you like.
What should you check when a vendor claims zero-retention?
- Where processing happens — in the browser/on-device, or on the vendor's servers?
- What exactly is not retained — the content itself? Logs too? Request metadata?
- Whether data trains models — demand an explicit written commitment that content is never used for training.
- Who the subprocessors are — cloud, analytics, monitoring — and whether the commitment binds them too.
- Independent verification — can you confirm it technically (network traffic) or through a third-party audit?
And remember: zero-retention governs what happens to data after processing. It does not change what you chose to send in the first place — which is why the safest input is still one that contains nothing you'd regret pasting.