Data Retention & Deletion Policy
Effective 2026-08-18 · Version 2.2This policy states, for each type of data Vista del Lago Software LLC holds, how long we keep it, why, and how it is destroyed. It supports our obligations under the GDPR storage-limitation principle (Art. 5(1)(e)), the deletion clause of our Data Processing Addendum (DPA §11), deletion rights under US state privacy laws, and the app-store requirement for a publicly reachable account-deletion path.
We commit to concrete retention periods rather than open-ended "as long as necessary" language, because our architecture already enforces most of these limits automatically.
What "deletion" means here
Your data is protected by per-account envelope encryption: each account's data is encrypted under a data key unique to that account (AES-256-GCM), and that data key is itself encrypted by a key-encryption key held in AWS Key Management Service and cryptographically bound to your account, so it can be unwrapped only for your account.
One store sits outside that model, and we state it here because it changes what deletion means for it: the search index. To let the assistant find things by meaning, we keep an index in which each indexed item contributes a short text excerpt, the vector embedding computed from that excerpt, and a small map of projected fields used for filtering. Those rows are not encrypted under your account's data key — a value encrypted that way cannot be searched by similarity or filtered by a database query. They are still confined to your own account, because every query against them is restricted to your authenticated identity, and the indexed item itself remains encrypted in the primary store. For deletion, there is no key whose destruction would help here, so the paragraph below applies to these rows with even less room for doubt. The index is excluded from the database exports we take for backup, but that does not mean no copy survives removal: the disk volumes of the machine running the database are snapshotted daily, and a snapshot holds whatever was on the disk. Those snapshots are retained for 14 days, well inside the backup window on this page, so a residual index row ages out sooner than everything else, not later. Our security overview describes this exception and its limits in full.
When you request deletion, we remove your account and the Lonzo-held data belonging to it from our live systems within 30 days, and we revoke the Google authorization and the stored tokens that went with it. Residual copies of your data remain in our encrypted backups until those backups age out on our 90-day rolling purge cycle. Deletion is complete — live systems and backups — within 90 days of your request.
Why there are two numbers, and why the longer one is the honest one. We keep three kinds of backup, and they do not expire together. Snapshots of the machine disks are kept for 14 days. Superseded copies of your encrypted content in our object store expire 30 days after they stop being current. The longest-lived is the nightly export of our database, which each night writes a new file that is then kept for 90 days — and that export carries account rows, so a copy of data we removed from live systems on day one can still sit inside a nightly export until it ages out. Until 2026-08-17 this page, the security overview, the DPA and the account-deletion page all said 30 days, which was the object store's window read as though it were the whole picture; the nightly export was three times longer, and stating the shortest of three windows as the bound is exactly the kind of favorable rounding we should not be doing to you. We publish the longest window because that is the one that bounds the promise. What does not change is when we act: removal from live systems happens on handling your request, not at the end of a window, and after it nothing we operate is serving your data.
We keep those exports for 90 days deliberately, as disaster-recovery depth: it is what lets us restore your account after a failure that takes weeks to surface, and shortening it to make this sentence read better would trade a real ability to recover your data for a nicer number. If we ever do shorten it, this page changes with it.
We want to be precise about one thing we do not claim. Destroying a per-account encryption key would render every residual copy of your key-protected data unreadable the instant the key was gone, which is a stronger guarantee than the one above (it would not reach the search-index rows described above at all, since those are not encrypted under that key). We do not currently do that as part of deletion, because the key-encryption key that protects your data key is a single managed key shared across accounts and bound to each account cryptographically rather than held as a separate destroyable key per account. So we do not tell you that your data becomes mathematically unrecoverable the moment you ask. What we commit to is what we actually do: removal from live systems within 30 days, and expiry from encrypted backups within 90.
Two categories are not removed by an account deletion at all, and are bounded by time limits instead — support correspondence, and the records we are required to keep. Both are stated in full below.
(Google, as the authoritative source of your synced email, calendar, contacts, and tasks, is a separate system and is not touched by our deletion — see below.)
Cancelling a request. You can cancel a deletion request by replying to us at any point before we carry it out. Once we have carried it out we cannot restore your account.
Retention schedule
| Data type | Retention period | Why | How it is deleted |
|---|---|---|---|
| Cached Gmail message bodies | 15 minutes, in the working memory of the process that fetched the message — nothing is written to disk, to our object store, or to any durable pointer | We hold a body only as long as the work in front of you needs it; Google remains the authoritative source | It expires 15 minutes after the fetch, and sooner if the message changes, if you disconnect Google, or when the process restarts. There is no stored copy to delete — see the row below for the copy that is stored |
| The text of an email conversation the assistant has been asked to work on | Life of the account, until you delete that conversation — the same as the assistant conversation history row below, which is what it becomes | Answering or replying to a thread means holding the conversation. An assistant cannot draft a reply to messages it is only allowed to keep for fifteen minutes | Delete the conversation in the app; removed from live systems on account deletion. Listed separately from the cache row above because that row is about a cache and this is not one |
| Email/Calendar/Contacts/Tasks (authoritative copy) | Held by Google, not Vista del Lago Software LLC. What we keep of it is the cache in the first row and the conversation copy in the second — nothing else | Google is the system of record | Not applicable — deleting Lonzo data does not touch your Google account |
| Derived memory / assistant-generated context | Life of the account (subject to your deletion of the underlying data) | Powers personalization and continuity of the assistant | Removed from live systems on account deletion; you can also ask us to wipe it while keeping your account. The search-index rows this includes are not encrypted under your account key — see What "deletion" means here — and their residual copies age out with the volume snapshots at 14 days, well inside the backup bound |
| Account data (identity, settings, preferences) | Retained while the account is active | Needed to operate your account | Removed from live systems on account deletion |
| Assistant conversation history | Life of the account, until you delete it | Continuity of the assistant across sessions | A single conversation can be deleted in the app; deleting the whole history is request-based (privacy@lonzo.ai); removed on account deletion |
| Authentication audit events | 90 days, and in no case more than 12 months | Security, fraud prevention, and incident investigation | Purged at the end of the retention window |
| Account-lifecycle log | De-identified after account deletion — no identifiable lifecycle record is retained in live systems beyond the 30-day removal window, or in backups beyond the 90-day purge cycle | Security, compliance, and audit record of account creation, key events, and deletion | De-identified (stripped of personal identifiers) so what remains is non-personal; see legal-basis note below |
| Technical and usage logs (request logs, IP address, device and client identifiers, error and performance telemetry) | 30 days, and in no case more than 90 days where an active security or abuse investigation requires it | Operating, securing, and debugging the Service; abuse and fraud prevention | Auto-expiry on the log retention window |
| Per-account encrypted data (general) | Life of the account | Powers the Service | Removed from live systems on account deletion; residual encrypted backup copies age out on the 90-day cycle |
| Encrypted backups | 90-day rolling purge cycle — the longest of three windows: nightly database exports 90 days, superseded object-store copies 30 days, machine-disk snapshots 14 days | Resilience and disaster recovery | Purged on the 90-day backup cycle; the two shorter windows purge sooner |
| Opt-out records (a recipient asked to stop hearing from your account — through the unsubscribe link or header, or by replying to ask us to stop) | Life of the account — the opt-out itself never expires and cannot be turned off | We must keep a record of a recipient in order not to send to them; discarding it would silently re-enable the sending the person asked us to stop | Held against your account's record of that recipient, minimized to the fact of the opt-out and the medium. Because it belongs to the account that holds it, it is removed with the account on deletion — along with that account's ability to send anything further. It does not by itself silence a different account that holds the same address |
Email-provider suppression entries (an address that hard-bounced, or reported as spam, a message we sent from one of our own lonzo.ai addresses) | Indefinite, by design — a suppression entry never expires | Discarding it would silently re-enable the sending; it is also the record our email provider relies on to protect the address | Keyed to the address rather than to any account, so it covers our own sending addresses for the whole Service and survives an account deletion. Held minimized (the address and the reason, nothing else) and used for no purpose other than suppression. A spam report against a message sent through your own Gmail account goes to Google and does not reach this list |
| Billing, payment and tax records (the record of a purchase, its amount, and the tax charged — we never hold your card details) | Seven (7) years from the transaction, as tax and accounting law require | Legal obligation (tax, accounting, audit) and defending payment disputes | Purged at the end of the statutory period. These survive an account deletion — see below |
| Support correspondence (email you send to support@lonzo.ai or privacy@lonzo.ai, and our record of how it was handled) | 30 days after the case is closed; 180 days from the last activity if it is still open | We need the case to answer you, to follow up if you write again, and to see whether our support is working at all | Auto-expiry on a stored time-to-live + garbage collection. The message as it arrived is also stored separately, before any of our software reads it; that copy expires within 30 days on a storage rule of its own — see One more copy of your message below. These survive an account deletion — see immediately below |
| Escalated support correspondence (the copy of your message forwarded to a person, and their reply) | 180 days from the last message on the thread | A person cannot answer you without reading what you asked, and may need the thread to follow up | Purged from the company mailbox at the end of the window. The stored copy of the message as it arrived expires within 30 days, so it goes well before the mailbox copy does |
The 90-day backup-purge figure here matches the security overview page, DPA Annex II and the account-deletion page. These four are no longer expected to agree by hand: an automated check reads the window out of the infrastructure that configures our backups and fails our build if any published page states a different number. That check is how the previous 30-day figure was caught.
About the two mail rows, and what this page used to say. Until 2026-08-18 the first row read "approximately 30-day time-to-live, held as encrypted Pins and garbage-collected", and it was the only row on this page about the text of your mail. It described a mechanism we had designed and never turned on. What actually runs is shorter and simpler: a fetched message body lives in the memory of the process that asked Google for it, for fifteen minutes, and is never written down. So the old sentence was wrong in the direction that flatters us — we hold a cached body for about a thousandth of the time we told you — and wrong again in the direction that does not, because "the cached body is evicted" was the only thing this page said about mail text, and it implied that after the window nothing of your mail remained here. That is not true of a conversation you ask the assistant to work on. To reply to an email thread the assistant reads the messages of that thread and keeps them as the conversation it is replying in, which is stored for as long as your account exists, is used to build your derived memory, and is deleted when you delete that conversation or your account. Both rows now say so. Neither the cache window nor the conversation store changed on 2026-08-18; only this page did.
Two categories an account deletion does not reach
Stated plainly, because these are the places the description above does not extend:
1. Support correspondence. A support case is held as system-readable text, not encrypted under your per-account key. It has to be. Anyone can email support@lonzo.ai — including someone with no Lonzo account, and including you after your account is gone — so there is often no per-account key to encrypt a case under.
What bounds it instead is a time limit stored on the case itself: the record expires 30 days after the case is closed, or 180 days after the last activity if it is still open, and is then deleted along with the handling history behind it. The longer open-case window is deliberate — it is a backstop against a case nobody has come back to, not a target; anything happening on the case moves the clock forward.
A support case holds your email address, your subject line, and our notes on how the case was handled. It does not hold a copy of your message body.
That is true of the case record, and the case record is not the only place your words go. When we cannot answer your question automatically, or you ask to be put through to a person, the text of what you wrote is sent on to a company mailbox so that someone can read it and write back to you. There is no way to have a person answer you without a person reading what you asked, so we would rather describe this than let the schedule above imply a bound it does not have.
That copy is ordinary work email. It is not encrypted under your per-account key and an account deletion does not remove it — this is correspondence with a company, not data held inside your account. It is bounded: the thread is purged from the company mailbox 180 days after its last message. The person who answers writes to you from their own mailbox, so the reply is ordinary email between you and us. Where the law requires us to keep a record of it, the legal-hold section below applies, exactly as it does everywhere else on this page.
One more copy of your message, and it is the one that would have been easiest not to mention. Every message sent to one of our own lonzo.ai addresses — support@, privacy@, legal@, security@, abuse@ — is written down exactly as it arrived, headers, body and any attachment, into our own storage, before any of our software reads it. It is there so that no message is lost to a failure in the software that forwards or handles it: if that step breaks, the message can be replayed instead of silently disappearing. That copy is not indexed, is not used to build your derived memory, is never used to answer anyone but you, and is reachable only by the people who administer our mail path. It is encrypted at rest by our storage provider, but — like the support case itself, and for the same reason — not under your per-account key, and an account deletion does not remove it. It expires within 30 days, which is inside every window on this page: shorter than the 180 days an open case or an escalated thread may run, so the copy of your message as you sent it goes before either of those does. Until 2026-08-18 it had no expiry at all, and this page did not mention it. That was wrong in both directions — an unbounded copy of exactly the mail people send us when they want us to hold less, and a schedule that could not bound a copy it never disclosed. The expiry rule and an automated check that fails our build if a new address is ever archived without one were added on that date; this paragraph is the disclosure that should have been here from the first day the archive existed.
This applies to a deletion request too, and we would rather say so than let you discover it: asking us to delete your account creates a support case, because a person carries the deletion out and the case is how that request stays on the record until they have. What the case holds depends on which route you used. Asked by email, it holds the address you wrote from, your subject line, and our notes — the same as any other mail to us. Asked from the in-app control, it holds no address and no text of yours at all: your signed-in session identifies you, so the case records the account identifier and the fact that you asked, and there is no message to keep. Either way the case is closed once the deletion has been carried out, and then expires on the schedule above.
2. Records we are required to keep. Billing, payment and tax records are retained for seven years because tax and accounting law requires it, and authentication audit events are retained for their security window. These are not removed by an account deletion. They are minimized (a transaction record, not a profile), access-restricted, and never used to rebuild your assistant or to contact you.
Google is the authoritative source
For email, calendar, contacts, and tasks, Google is the authoritative source and Vista del Lago Software LLC holds caches only. Deleting your Lonzo account destroys our caches of that data; your Gmail, Calendar, and Contacts in Google are untouched and remain exactly as you left them. Conversely, deleting data in Google does not by itself alter Vista del Lago Software LLC's records beyond the normal cache-refresh behavior.
How to delete your data
By request, to privacy@lonzo.ai. You can request deletion of your account and all associated Lonzo-held data at any time, without obstacles, by emailing privacy@lonzo.ai from the address on the account. We verify that the request comes from the account's own address and then carry out the deletion described above. A deletion is never carried out, or refused, by an automatic reply — a person handles it. Writing to support@lonzo.ai also works and is routed to a person, but privacy@lonzo.ai is the address we monitor for this purpose and is the faster route.
Public deletion URL (no app install required). In line with app-store requirements, you can request account and data deletion from a public web page without installing or signing into the app: lonzo.ai/delete-account. The page describes what is deleted and the timeline.
In the app, from your own account. Account → Delete account raises the same request from a signed-in session. It takes two taps — the first opens a confirmation that states what will and will not happen, the second files the request — and it then shows you a receipt. Because the session already proves who you are, there is no identity check to wait out and no confirmation mail to answer. It files a request and deletes nothing itself: nothing is revoked, nothing is dropped, your session continues, and you keep access to your account until a person carries the erasure out. We will not describe that control as a deletion button, because it is not one, and an app-store rule and our own honesty rule both forbid presenting the one act as the other.
Other requests you can make by the same route. Writing to privacy@lonzo.ai is also how you ask us to export a copy of your data, to wipe the derived memory while keeping your account, or to delete your whole assistant conversation history. These are request-based today rather than controls in the product; a single conversation can be deleted in the app.
Deletion-completion timeline (SLA)
Once you request deletion, we complete removal of your data from live systems within thirty (30) days and its expiry from residual encrypted backups within ninety (90) days. The two legs have different bounds because they are different mechanisms: removal from live systems is an action we take on handling the request, while residual encrypted backup copies age out on the 90-day backup purge cycle described above and cannot be reached individually before then. This is reconciled with the deletion/return window in our DPA (DPA §11, the same 30 and 90 days) — the two documents state the same pair of numbers, and an automated check against our backup configuration fails our build if either drifts. The legal-hold exceptions below, and the two categories named above, may extend retention of specific records.
Retention exceptions (legal hold)
We may retain data beyond the periods above where retention is required by applicable law, subject to a legal hold, or reasonably necessary to establish, exercise, or defend legal claims, prevent fraud or abuse, or enforce our agreements. Any data retained under this exception stays encrypted and access-restricted and is deleted once the basis for retention no longer applies.
The authentication audit events (90 days, maximum 12 months) are retained under this legitimate-interest / legal-obligation basis as security and compliance records. Billing, payment and tax records are retained under a legal obligation (tax and accounting law). Both kinds of suppression record are retained under our legitimate interest in honoring an opt-out permanently, which is also the data subject's interest; Art. 17(3) permits retention where erasure would defeat the exercise of the right the record exists to serve. That basis is what carries the email-provider entry past an account deletion. It is not needed for the per-account opt-out record, which is ordinary account data and goes when the account goes: an account that no longer exists cannot resume the sending, so keeping the record would not serve the right it exists to serve. The account-lifecycle log is de-identified after account deletion — stripped of personal identifiers so that what remains is a non-personal record of account events, with no identifiable lifecycle record retained in live systems beyond the 30-day removal window, and none in backups beyond the 90-day purge cycle. We do not keep a permanent identifiable record of your account lifecycle, which resolves any tension with your Art. 17 right to erasure: the identifiable record is removed on deletion, and only a de-identified, non-personal event record remains.
Changes to this policy
We may update this policy from time to time. The current version and its date appear at the top of this page; material changes will be reflected here with an updated date.