Data Retention & Deletion Policy
Effective 2026-09-16 · Version 3.11This 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.
Three categories are not removed by an account deletion at all — support correspondence and the records we are required to keep, both bounded by time limits instead, and the de-identified record that a device credential was revoked, which holds no credential, no password and nothing out of your mail, calendar or contacts, and is kept on purpose: a revocation that could be removed would stop refusing the credential it exists to refuse. All three 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, the conversation copy in the second, and the three records the assistant builds out of it that have rows of their own further down — the Agenda insight cards, the Agenda row summaries and the sent-mail recipient record — each stating what it holds and for how long | 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 |
| Sign-in credentials (the renewal token that keeps one device signed in, held as a one-way digest — the store never holds the token itself — beside the account it belongs to, the device key it was issued to, and the two dates the bounds opposite are measured from) | The credential itself stops working 14 days after it was issued, and the sign-in it renews ends at the latest 30 days after you signed in on that device, or after 7 days in which that device has not renewed — whichever of the three comes first. The stored record has no expiry of its own: nothing sweeps a lapsed credential out of storage, so the record is kept for the life of the account | A device has to be able to stay signed in without holding your password, and the three bounds are what stop a device that renews indefinitely from becoming a permanent key to your account | Overwritten with a marker that names no account and no device when you sign out on that device, when you use Sign out everywhere, when your password is changed, and on account deletion. The marker is kept, not removed — see the note below the table. The marker also carries a key-protected, one-way identifier of the account holder the credential belonged to — it cannot be turned back into an account by anyone, and can be matched to one only by us, using a key we hold — and it is kept for exactly as long as the marker is |
| Device keys (the short-lived client certificate one installation of the app, or one browser, uses to prove it is a device you signed in on — the device generates the key, we sign it, and what we store is the public half and its identifier) | The certificate is valid for 14 days, or 7 days for a guest link, and is refused at every connection after that. The record of the key is kept for the life of the account, and once a key has been revoked its identifier is kept indefinitely | A certificate that has to be renewed limits what a lost or borrowed device can do before anyone notices; a revocation has to outlive the credential it refuses, or a restart would begin honouring that credential again | Revoked when you sign out on that device, when you use Sign out everywhere, when your password is changed, and on account deletion. A revocation is a record we keep, and the identity record holding it outlives the account — see the note below the table |
| Password (held only as a one-way hash — we never store the password itself, and nothing in the Service can recover it) | Life of the account. No timer expires it and there is no periodic-rotation requirement; a password reset carried out by us requires you to set a new one at your next sign-in | We have to be able to check a sign-in, and a hash is the least we can hold and still do that. Making people rotate passwords on a schedule is well established to produce weaker ones, so we do not | Deleted with the account record on account deletion, together with the username, email address and roles on that record |
| 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 |
| Device tokens (the delivery address a Lonzo client registers for one installation of the app, the platform it reported, the device that registered it, and the calendar day it last registered) | Life of the account — no timer expires a registration today | A delivery address is useless if we discard it between sessions; the day-grain date is there so that a future expiry has something to measure against | Removed when you sign out on that device, when that device's registration is removed, and on account deletion. Nothing we operate delivers to one — see the note below the table |
| Weekly measurement summaries of the assistant's automatic mail handling (one row a week, holding counts and dates only: how many of the assistant's own decisions about your mail were shown to you, how many of those you acted on, how many it took without showing you, the percentages you were shown, and the two UTC calendar days the summarised period begins and ends on) | 52 weeks. A row is dropped once it has aged out of that year, and the store never holds more than 52 of them | The figures the app shows you about how the assistant's automatic handling is going are worked out from a short window of recent activity, so a figure you were shown last month cannot be recomputed afterwards. Keeping one dated summary a week is what lets the app show you a year rather than only this week, and show you the number you were actually given | Ages out at 52 weeks; removed from live systems on account deletion. It holds no message, no sender, no subject, no thread and no time of day — see the note below the table |
| Agenda insight cards (the cards the Agenda in the app shows you — each a title, a short line of context and a few per-card details, and for a card about an email a pointer to that message. A card's title or context can carry the name of the person who wrote to you and the subject line of the message, and a card about an open commitment names the person it is with) | Life of the account. No timer expires a card and there is no cap on how many are kept — ageing cards out by date would remove the most consequential ones first, so we do not | The cards are the Agenda: what the assistant has noticed in your mail, calendar and habits and wants you to see | Removed from live systems on account deletion. Before that, a card about an email is retired when that message is archived or deleted in Gmail, and a card you dismiss in the app is dropped; nothing else expires one — see the note below the table |
| Agenda row summaries (the headline, and sometimes a one-line summary, that the assistant writes for an item on your Agenda, kept against that item with when it was written and which model wrote it. It is written from the item's own details, so a summary can repeat a correspondent's name or words from a subject line) | Life of the account. No timer expires one and there is no cap. A summary is kept rather than rewritten, so that what you were shown stays what you were shown | An item's wording should not change under you between one look and the next | Removed from live systems on account deletion. Before that, removal is best-effort: when an item leaves the Agenda its summary is usually dropped with it, but not always, so a summary can outlive the item it described |
| Sent-mail recipient record (for each of the 100 most recent messages in your Gmail Sent folder: the message and thread identifiers, when it was sent, and the To line exactly as Gmail returns it — the addresses, and any display names, of the people you wrote to. It holds no message text and no subject) | Life of the account, as a rolling window: the record is rebuilt from your Sent folder every six hours and replaced as a whole, so it never holds more than 100 messages and a message leaves it once 100 newer ones have been sent. If your Sent folder comes back empty the previous record is kept rather than replaced | Who you have written to recently is how the assistant tells mail from someone you correspond with apart from a stranger's, when it decides how to treat what arrives | Replaced every six hours; removed from live systems on account deletion. The people on the To line have no account with us to delete — this record goes with yours |
| Correspondence links between Lonzo accounts (when another Lonzo account holder sends a message to yours, a small record is written into your account linking your copy of that conversation to the sender's copy and naming the sender's account. It holds no message text) | Life of the account. One record per correspondence; nothing expires one and there is no cap | The link is what routes the next message in the same correspondence into the same conversation on your side instead of opening a new one | The records in your account are removed from live systems on account deletion. The matching record in the other account holder's account is part of their account, not yours: it names your account and stays until they delete theirs. Deleting the conversation in the app does not remove the link — see the note below the table. |
| 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 the List-Unsubscribe header, on a message the Service sent them from one of our own lonzo.ai addresses) | 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. Until 2026-09-02 this row also named "replying to ask us to stop" as a route to this record. That reading of a reply belongs to coordination outreach to meeting participants, which the Service does not currently send at all — on any medium, on any plan — so the route is not open today; if that path is ever switched on, a reply asking us to stop will be read for a fixed list of phrasings and will write this same record, and none of the retention or deletion above changes with it |
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.
About the three credential rows, and the difference between a credential expiring and a record of it being deleted. Until 2026-09-06 this schedule had no row of any kind for the things that keep you signed in — no credential, no renewal token, no device key, no password. That was not a wrong number, it was a missing one: every window above is a window we enforce, and the credentials had none published at all, which left a reader to infer that the account-data row above covered them and that they went when the account went. Most of the numbers in those rows bound what a credential can do. Only one clause in each bounds how long a record of it is kept, and that clause is the life of the account. We would rather set the two side by side than let an expiry read as a retention period.
A lapsed sign-in credential is not swept up. Nothing runs over that store looking for credentials that have expired, and the store itself replaces a record rather than removing one. So a device you stopped using keeps its record — the one-way digest, the account it belonged to, the device key it was issued to, and the two dates — until you sign out on that device, use Sign out everywhere, change your password, or delete your account. Any of those overwrites it with a marker naming no account and no device. That marker is then kept, and it is kept for a reason: it is what makes a credential that was spent stay spent after a restart. If the marker were removed instead, the place it occupied would answer "no such credential", and a copy of the original taken beforehand could be presented again. So one marker remains for each credential ever issued, holding a one-way digest and the key-protected owner identifier described in the row above — which names no account to anyone who does not hold our key — and nothing else about you. On an account deletion the credentials are burned first and the account is removed second, which is the order that matters: the deletion is refused rather than completed if the credential sweep does not finish.
A revoked device key is kept deliberately, and the record that holds it outlives your account. Revoking a device means writing its key identifier onto a list of keys to refuse, for exactly the reason above. That list lives on an identity record rather than on your account record, and an account deletion removes the account record and revokes the credentials on it, but does not remove the identity record. What is left there is a set of key identifiers and the fact that keys once existed, filed under an internal account identifier — no credential, no password, no name, no address, and nothing out of your mail, calendar or contacts. Two further limits belong in the same paragraph rather than in a footnote. The list of keys a device ever had is an issuance record and is not pruned when a certificate expires, so it grows by one entry each time a device enrols and is read by checking each entry rather than by trusting the list; and revocation on deletion reaches the devices whose sign-in credential was still live, because a device whose credential had already lapsed has nothing left to revoke — its certificate is refused by its own expiry instead. None of this is a residue we are content with, and it is the reason these rows say "indefinitely" where that is the true answer rather than borrowing the 90-day figure from the row above. Three of the records this schedule describes have no end date at all, and a reader is owed the difference between them. They are the de-identified marker described just above, this revoked key identifier, and — a separate record from either, kept for a separate reason — the email provider's suppression entry, which is keyed to an address rather than to an account because a message we sent to that address bounced or was reported as spam. A revoked key identifier is none of those things: it is not an address, it is not a request to stop hearing from anyone, it never reaches that provider list, and its only use is to go on refusing the key it names. The per-account opt-out record is not on that list either — it is ordinary account data, and it goes when your account goes.
About the device-token row, and the part of it that is easiest not to mention. A device token is issued by the platform's own messaging service — Firebase Cloud Messaging for an Android client, the browser's own service on the web — and it addresses one installation of the app rather than you. It is still a third-party identifier held against your account for as long as that account exists, so it belongs on this schedule, and two things about it are worth stating plainly rather than leaving to be inferred from the row.
The first is that nothing we operate delivers to one. The capability that would carry a message out to a registered device is declared in our system and is not built, and no Lonzo client registers a token today. So the row above describes what the store holds when one does — a disclosure published ahead of the behavior it describes, rather than after it. If we build the delivery path, that row and the Privacy Policy change with it, and we would rather have written this down early than have the store quietly precede the page.
The second is that the retention is the life of the account, and no timer shortens it. A registration goes when you sign out on that device, when that device's registration is removed, or when your account is deleted — those are the only three ways, and none of them is a clock. The date recorded beside each token is deliberately a calendar day and not a time of day: a timestamp taken every time a device checked in would accumulate into a record of when each of your devices was in use, which we do not need in order to reach it, while the day is enough for a future expiry to measure against. That expiry is not built yet either, and this page will say so until it is.
About the weekly measurement rows, and the two dates inside one. Where the assistant handles something in your mail on its own, the app tells you how that is going — how many of its decisions it showed you, how many of those you went on to act on, and how many it took without showing you. Those figures are worked out from a short window of your recent activity, which means the window a figure came from rolls off and the figure cannot be recomputed later; re-reading it after new activity arrives can even change an answer you were already shown. So once a week we write one small summary and keep it, and what the app shows you for an earlier week is that stored summary rather than a fresh guess at it.
A summary holds counts and dates, and nothing out of your mail. There is no message, no sender, no subject and no thread in one — the store cannot be read as a record of who wrote to you or about what, only as a record of how many decisions there were and how they went. The two dates in a row are calendar days, for the same reason the device-token date is: a row also states how much history it summarised, and stating that as an exact instant would have recorded the moment you reacted to a single message on a quiet week, which accumulates into a record of when you were at your mail and is not something a weekly figure needs. Both ends are rounded down to the start of the day, so a row understates the period it covers by up to a day rather than overstating it. These rows are shown to you and are not used on you: nothing in the Service reads them to change a threshold, to decide what the assistant does next, or to write anything to your calendar, mail or contacts. We keep them for 52 weeks because a year is what makes a change you made visible to you — long enough to see a season, short enough that this is not an open-ended history — and because that is a shorter period than the life-of-account row below it, which is what this store would otherwise sit inside.
About the four rows added on 2026-09-16, and why they were not here before. Each of the four — Agenda insight cards, Agenda row summaries, the sent-mail recipient record and the correspondence links between Lonzo accounts — describes a store that existed before this page named it. Nothing we hold changed on that date; the page caught up with it. We found them the way we now find such things: an automated check reads every durable per-account store out of our own code and refuses our build until each is either named on this page or recorded, with a date, as a disclosure we still owe — these four were recorded as owed in September 2026 and are published now. Two things about them are worth saying plainly rather than leaving in a table cell. The Agenda cards and row summaries can carry another person's name and the subject line of a message, because they are built from your mail — so a card is not merely a pointer to a message, and archiving or deleting the message in Gmail is what retires the card, not the other way round. And the correspondence link is the one record on this page of which a copy exists in somebody else's account: when another account holder writes to you, the link in their account names yours and is theirs to keep or to delete with their account, exactly as the link in your account naming theirs is yours.
Three 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.
3. The record that a device credential was revoked. Revoking a device key means writing its identifier onto a list of keys to refuse, and that list lives on an identity record that an account deletion does not remove. What remains there is a set of key identifiers and the fact that keys once existed, filed under an internal account identifier — no credential, no password, no name, no address, and nothing out of your mail, calendar or contacts. It is kept on purpose and is on none of the clocks above: a revocation that could be removed would stop refusing the credential it exists to refuse. The Device keys row of the schedule and the note beneath the table describe it in full.
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 three 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.