An AI email tool reads your mail. It keeps its own copy, sends pieces of that copy to a model somebody else owns, and stores what comes back. Everyone asks about the reading. Your exposure sits in the keeping and the storing, and both of those have answers you can look up.
- Every product in this category reads your mail, because that’s what you bought. The useful question is what gets built out of the reading, and how long each of those things lasts.
- After you connect, your mail lives in more than one place. There are the messages, an index built from them, and the summaries and drafts made from them. There’s also an excerpt sitting on a model provider’s servers, under that company’s terms. That’s four separate objects with four separate lifetimes.
- Two documents govern most of this before any vendor’s privacy page does. They’re Google’s and Microsoft’s developer policies for their own mail interfaces. They’re the floor under every tool connected to a Gmail or Microsoft 365 account, and they make several vendor assurances less impressive than they sound.
- What’s kept, and until when, is the part with a factual answer. Almost everything else is a company describing itself. That’s worth something, and it’s a different kind of thing.
The path a message takes
Six steps, and the language people use collapses four of them into one.
Your provider still receives the mail. Your mailbox stays where it is. The message arrives at Google or Microsoft exactly as it did last year, under the same address, and it sits there whatever the tool does afterwards. The rest of this page is about what happens alongside that, and why switching email apps involves no migration is a separate subject with its own answer.
The tool pulls a copy through the provider’s interface. It works on an authorization you issued at your provider’s own sign-in, and that page lists what the tool is allowed to reach. Your password stays with your provider. That grant is the outer edge of everything below, and where your email credentials are kept is where the shape of it is set out.
It stores that copy on its own infrastructure. This is the step the phrase “reads your mail” hides. Reading suggests a glance. What happens is a sync. The messages, the headers, the recipients, the attachments and the folder structure land in a database belonging to the company you bought the software from, and they stay there. You search, you read a briefing, you ask a question about a thread. Each one queries that copy rather than your mailbox.
Excerpts go to a model. Ranking a message. Summarizing a thread. Pulling a task out of a paragraph. Drafting a reply. Each one puts the relevant text into a prompt and sends it to a large language model. In nearly every product in this category, that model belongs to a third company rather than to the vendor. So an excerpt of your correspondence crosses to a fourth party’s infrastructure. It’s processed there, and it leaves behind whatever that company’s logs retain.
What comes back is stored beside your mail. A priority score, a summary, a suggested task, a draft, a set of numbers that represent the meaning of a message so it can be found later. These are new objects. They’re made from your mail, they live on the vendor’s side, and they have their own retention.
Actions are written back through the same grant. Archiving, labeling, replying, sending. That direction runs back out to your provider. It’s why a thread filed inside the tool is filed in your mailbox too.
Only the fourth step is momentary. Steps three and five are states, and a state has a duration. So the questions worth putting to a vendor are almost all about the third and fifth steps. “Does it read my email” is nearly the least useful of them.
What a tool makes from your mail
The derived material is the part firms forget to ask about, and it’s often the part that outlives everything else.
Point’s privacy policy is unusually specific about the categories, which makes it a good worked example rather than a good advertisement. It lists among the things processed “search queries, search indexes, embeddings, summaries, points, generated titles, generated descriptions, and other AI Output”. It also says Point “may derive information to provide the Services, such as message priority, urgency, summaries, points, labels, circles, suggested tasks, reminders, scheduling suggestions, style preferences, relationship importance, and activity recommendations.” (Privacy policy, version 1.0, effective July 7, 2026, checked September 6, 2026.)
Four kinds of thing sit in that list, and they behave differently.
The index. You want to find a message by what you remember rather than by the words in it. So the tool converts your text into embeddings: long lists of numbers that place a message near other messages about the same thing. An embedding reads as numbers rather than prose, and it stays identifiable. It’s computed from your sentences, and the search that uses it has to get back to them. What semantic search is covers the mechanism. What matters here is that the index is a second body of data, derived from the first.
The summaries and the drafts. Short pieces of generated text that quote or paraphrase the original. A summary of a client’s message about their divorce is as sensitive as the message. It’s shorter, and that’s the whole difference.
The judgments. Priority, urgency, who matters to you, which people belong to which part of your life. These are inferences about your relationships rather than copies of your correspondence, and they’re the least visible category by a distance.
The learned preferences. The rules a tool builds up about how you write and what you want done. In a well-built product they’re readable sentences you can edit. That’s the difference between a preference and a black box, and seeing what an AI has learned about you is where that goes.
One question gets a real answer out of a vendor. Ask whether deleting a message reaches the index entry, the summary and the inference built from it, or only the message. A tool can honestly say your email was deleted while the embedding of it, and the summary of it, sit exactly where they were.
Everyone who touches a message
Count the companies. In this category the list runs longer than the purchase suggests.
Your mail provider comes first, and it’s the one you already had. What’s new is that it hands data out through an interface. Then the vendor’s hosting company, which holds the synced copy and everything derived from it. Then one or more model providers. Then, usually, a separate provider for embeddings, because the model that writes well and the model that indexes cheaply are rarely the same one. Then the smaller services around the edges: transactional email, billing, error monitoring, and mobile push.
Push is worth a sentence of its own, because it’s the one that gets missed. A notification has to carry enough of the message to be worth reading on a lock screen. It travels through a push service to reach your phone. Point’s own list states the case plainly, describing the data processed by Google’s Firebase Cloud Messaging as “device push tokens and notification payload fragments, which may include message-derived snippets.” (Subprocessors, version 1.0, effective July 7, 2026, checked September 6, 2026.) So a fragment of your correspondence passes through a company you never evaluated, on the way to a device you carry.
Here’s the structural point, and it decides how much any of this should worry you. Your agreement is with the vendor. Everyone else in that chain is under contract to the vendor rather than to you, and their handling of your data runs under their terms rather than the ones you read. Point’s data processing addendum says so directly. It asks the customer to acknowledge that AI providers and other subprocessors “may process prompts, requests, outputs, metadata, logs, and telemetry” for a list of their own purposes, running from safety and abuse prevention through to legal compliance, subject to those providers’ terms. (Terms, data processing addendum section 7.2, checked September 6, 2026.)
All of this is ordinary, and it’s still worth knowing. Fragments of your correspondence rest on infrastructure you never chose, for however long the company that owns it decides. So the durable answer here is a published, dated list of who those companies are, kept where you can compare it against the copy you saved. A vendor that names its model providers has answered something most of the category deflects.
The rules Google and Microsoft already set
Here’s the part that changes how you read a security page, and it rarely comes up.
Before a vendor writes a single privacy commitment, they’ve already agreed to one. Any application reading Gmail through Google’s interfaces is bound by Google’s Workspace user data and developer policy. Any application reading a Microsoft 365 mailbox is bound by the Microsoft APIs Terms of Use. Both are public. Both are short enough to read in ten minutes.
Google’s policy restricts what a developer may do with the data at all: “Limit your use of data to providing or improving your appropriate use case or features that are visible and prominent in the requesting application’s user interface.” It restricts human eyes, and the wording runs “Do not allow humans to read user data, unless: You have obtained and documented the user’s explicit consent or affirmative agreement to view specific messages, files, or other data … The data (including derivations) is aggregated and anonymized and used for internal operations … It’s necessary for security purposes (for example, investigating a bug or abuse); or, To comply with applicable laws and/or regulations.” And it forbids, in terms, “transferring, selling, or using user data to create, train, or improve a machine learning or artificial intelligence model beyond that specific user’s personalized model for the appropriate use case or user-facing feature.” (Google Workspace user data and developer policy, checked September 6, 2026.)
Microsoft’s version is narrower in one place and wider in another. Here’s the narrow part. “Unless you have use permissions expressly and specifically granted by Customers in connection with using your Application, you may not use Microsoft email protocols and APIs for any purpose other than: 1. syncing email messages, calendar events, and contacts, or 2. backing up email messages, calendar events, and contacts.” So everything an AI email tool does beyond syncing rests on permissions you granted. That’s a reasonable arrangement, and it’s worth knowing that it is the arrangement. Here’s the wide part. The advertising ban reaches derived data explicitly, and it prohibits use or transfer of API data “including any data aggregated, anonymized or derived from that data” for targeting or serving ads. There’s also a deletion obligation, and most privacy pages leave it out. It requires developers to “implement proper retention and deletion policies, including deleting all data when your user abandons your Application, uninstalls your Application, closes its account with you, or abandons the account.” (Microsoft APIs Terms of Use, last updated October 2025, checked September 6, 2026.)
Three things follow, and the third is the one worth carrying around.
First, several assurances that look like differentiators are floor. “We will never sell your mail” and “we do not use your mail for advertising” are already required of every tool touching a Gmail or Microsoft 365 mailbox. A vendor leading with those has told you they meet the minimum.
Second, part of the training question is settled at the platform level rather than in the vendor’s policy. For Google data specifically, using it to build a model beyond your own personalized features is already prohibited. That’s narrower than a general training ban, and it’s still worth having.
Third, here’s the limit. Both documents run between the platform and the developer, and you sit outside them. Enforcement belongs to Google and Microsoft, and their remedy is to cut off the application rather than to compensate you. Both companies can also change their own terms, and Microsoft says as much. “We may modify these API Terms at any time with or without individual notice to you.” So treat the platform rules as a floor you get for free, and the vendor’s own contract as the thing you actually negotiate.
When a person reads your mail
Every serious policy in this category lists the circumstances where a person at the company can see a message. That list is the honest version. A vendor promising that nobody ever looks has promised something they can’t honor.
Google’s own policy makes the exceptions explicit, and it lists documented user consent, aggregated and anonymized internal operations, security investigation, and legal compliance. Point’s privacy policy is written the same way, and here’s the sentence. “Point limits human access to Customer Content to circumstances such as providing support at your request, security and abuse investigation, legal compliance, troubleshooting, service operation, or with your consent.” (Privacy policy, section 6.8, checked September 6, 2026.)
Read the list rather than the reassurance, and notice how ordinary the common case is. You write to support saying a thread was summarized wrong. Somebody has to look at the thread. That’s human access, you asked for it, and it’s the right outcome. The awkward ones sit further down the list: an abuse investigation you never hear about, a bug traced through real data because test data doesn’t reproduce it, and a legal demand.
So ask which circumstances are on the list. Ask who inside the company is authorized under each, whether the access is logged, and whether you’re told afterwards. A vendor with a written list has thought about it. A vendor who answers with a flat no is either describing an aspiration or has yet to think about it.
How long any of it lives
Retention is where most of the honest answer sits, and it’s the section of a privacy policy people skip.
The shape to want is a table rather than a sentence, with a line for each kind of data. The interesting lifetimes differ from each other by years. Point’s table runs to nine rows, and three of them carry the argument of this whole page.
Derived data gets its own line. Search indexes, embeddings, summaries and the rest are “generally retained while the related Customer Content or account is retained, unless separated for security, legal, or de-identified analytics.” That’s the answer to the question from two sections ago, in writing, and a good policy looks like that. Deleted content gets another line: “deleted from active systems within a reasonable period; backups may persist until overwritten under backup cycles.” Connected-account tokens are held only until the account is disconnected, the authorization expires or the account is deleted. That ties the life of the key to the life of the connection. (Privacy policy, section 10, checked September 6, 2026.)
Then there’s the end of the relationship. It’s a different clause in a different document, and it’s the one to check while you’re still choosing. Point’s data processing addendum sets it at 60 days from termination or expiry, “at Customer’s choice if supported by the Services and specified in the Agreement”. Point is free to delete rather than return if no choice was recorded, and backups are held until overwritten under normal cycles. (Terms, data processing addendum section 12, checked September 6, 2026.)
Two habits of reading are worth forming here.
Backups are the honest exception, and seeing them in a policy is a good sign. Deleting from immutable backup media on request is past what any system does, and a vendor claiming instant total erasure is describing infrastructure that doesn’t exist. Look for whether the exception is stated and bounded.
And here’s the contrast worth holding on to. Deleting inside the tool is a different act from deleting in your mailbox. Your provider holds the original on its own schedule, and a message the tool removes from its copy is still sitting where it always was. That cuts both ways. Your mail survives whatever the tool files, and a message you delete in the tool is still at your provider.
What you can check for yourself
Three of the answers on this page are facts you can verify today, on your own. The rest are promises. Sorting them into the right pile is most of the work.
The grant is visible in your own provider account. It sits there under the vendor’s name, listing what was allowed, in an account you had before you met the company. You can withdraw it from there. That makes it the one control on this page that works whether or not the vendor is still reachable and still reasonable. Microsoft goes so far as to require developers to point you at it. An application’s privacy statement has to link to Microsoft’s consent pages “with a clear indication that Customers and end users can go to the Microsoft site(s) to revoke Data Access Consents at any time.”
The subprocessor list is a document with a version on it. Save a copy the day you sign up. A list that names AI providers by company, dates itself, and separates the vendor’s own suppliers from the accounts you connected is one you can compare against next year’s. This matters because routing changes. Point’s terms reserve the ability to “select, route, replace, or change” its models, its embedding models and its providers at any time. So does every serious product in this category, because a product frozen to a single model provider would be a worse one by spring. The dated list turns that from an invisible change into a visible one.
A privacy request is the only test of the deletion machinery. Access, a copy, correction, deletion. Most vendors list those rights, and a request is the only way to learn whether the process behind them works and how long it takes. In California those rights are statutory rather than a courtesy. A resident can require the company to say what it holds and, subject to the exceptions the law allows, to delete it. One small request in week one tells you more than another hour of reading.
One thing stays out of reach, and it’s what happens to the excerpt after it arrives at a model provider. That company’s systems answer to the vendor rather than to you, so there’s no request you can make that would produce evidence either way. That belongs in the promise pile, which still counts for something, and keeping data out of AI model training is where the training question is taken apart properly.
One habit protects the rest. Whatever you’re told is true on the day you’re told it, and policies change. The Federal Trade Commission put its view of quiet changes on the record on February 13, 2024. Adopting “more permissive data practices” and telling people about it only through what the agency called “a surreptitious, retroactive amendment” to the terms or the privacy policy may be unfair or deceptive. Sharing data with third parties, and using it for AI training, are the two examples the agency chose. (FTC, checked September 6, 2026.) Keeping the dated copy is what makes that protection usable, because a change you can’t demonstrate is a change nobody has to answer for.
Vetting one product before you hand it a mailbox is narrower work than understanding the category, and what to check before connecting your inbox covers that end of it.
The same questions put to Point
Point is an AI email client, and every question on this page lands on Point too. What’s worth setting out is which document holds each answer, so you can go and read it rather than take a paragraph’s word for it.
- What’s held, and what’s made from it, is itemized rather than implied. The privacy policy names messages, headers, recipients and attachments in one list. Search indexes, embeddings, summaries, generated titles and inferred priorities sit in another. An itemized list is what makes a deletion question answerable at all.
- The companies are named, with roles separated. Subprocessors carries a version and an effective date. Hosting is AWS. AI processing is Anthropic and OpenAI, with OpenAI also handling voice. Google’s Generative AI API covers text embeddings, Firebase Cloud Messaging covers push, Resend covers transactional mail, Stripe covers billing and Cloudflare covers the marketing site. Google and Microsoft appear separately as connected service providers acting on your instruction. That’s the correct distinction, and most lists blur it.
- The Google commitment sits in Point’s own document as well as Google’s. Section 6.6 of the privacy policy adopts the Google API Services User Data Policy and its Limited Use requirements by name. It states that Google API data from Gmail, Google Calendar or Google Sign-In stays out of Google’s advertising products, even though Point uses those products on its public marketing pages. Naming the awkward case tells you more than leaving it out.
- Human access is a written list. Section 6.8, quoted above, scopes it to support at your request, security and abuse investigation, legal compliance, troubleshooting, service operation, and your consent.
- Retention is a table, and derived data has its own row. So does the token, so does deleted content, and the backup exception is stated rather than glossed.
- The model routing is explicitly changeable. Terms section 6.7 reserves it, and that’s the reason to watch the dated list rather than to distrust the answer.
- Processing is US-based, with the caveat stated. Point is a Delaware corporation with primary offices in California. The policy says personal information may be processed in the United States and in other countries where Point or its providers operate. That second half is the part worth noticing.
- You’re responsible for the grant. Terms section 4.3 puts two things on your side of the line: reviewing the permissions before you authorize, and disconnecting accounts you’ve finished with. That’s accurate rather than evasive, and it’s the part of this that only you can do.
- Regulated data sits outside the standard service. Section 14.7 keeps that agreement separate: privacy disclosures, security controls and subprocessor lists don’t stand in for a required regulated-data agreement. If your mailbox carries tax return information or protected health information, that sentence is the one to read first.
How much Point does on its own affects your exposure more than any clause in any of those documents. It’s a setting per kind of work, and it starts on review. You’ll find it in setting how much your inbox does on its own. The full account of what Point does, feature by feature, is on the benefits page.
Common questions
Does an AI email tool read every message, or only the ones I open?
Every message, as it arrives. Ranking and summarizing an inbox works only when everything in it has been read, so that’s the product working rather than a setting somebody left on. Look instead at what survives the reading. There’s a copy on the vendor’s infrastructure, an index built from it, summaries and inferences, and an excerpt that went to a model provider. Those four have four different lifetimes, and the lifetimes are where your actual exposure lives.
Does my mail leave the company I bought the software from?
Yes, in nearly every product in this category. A vendor who says otherwise is either running its own models or being loose with you. Excerpts go to a model provider for anything AI does. Embeddings usually go to a different provider again, and push notification fragments travel through a messaging service on the way to your phone. Each of those companies is under contract to the vendor rather than to you. The document that answers this properly is a dated subprocessor list naming each of them, and a vendor missing one has told you more than any assurance would.
If I delete an email, is it gone from the AI tool as well?
Not automatically, and this question separates a thorough vendor from a vague one. Deleting a message in your mailbox may or may not reach the tool’s copy. Even where it does, the summary of that message and the index entry built from it are separate objects with their own retention. Point’s policy handles that by giving derived data its own retention line, tied to the life of the related content or the account. Ask any vendor the same question in those words. The answer for the message is easy, and the answer for what was made from it is the one that matters.
Can somebody at the vendor read my email?
Under listed circumstances, yes, and every serious policy in this category says so. Google’s platform rules permit human access for documented user consent, security investigation and legal compliance. Vendors write their own lists on top of that. The common case is ordinary and starts with you: a support ticket about a thread means somebody looks at the thread. Ask for the list of circumstances, who’s authorized under each, and whether the access is logged. That beats a promise of no access at all, which nobody can keep.
Is my mail being used to train AI?
Two answers, and they get mixed up. For data taken from a Gmail or Google Workspace account, Google’s own developer policy already prohibits using it to create, train or improve a model beyond your personalized features, whatever the vendor says. Past that boundary you’re relying on the vendor’s own commitment. That commitment typically covers generalized third-party models and leaves improving the product for you outside it. Training needs a copy somebody kept, so the retention answers are the ones with evidence behind them, and the training clause proper is taken apart in keeping data out of AI model training.
The short version
- Your exposure is the copy of your mailbox living on a vendor’s infrastructure, plus the index, summaries and inferences built from it. Each one has its own lifetime. The reading is the part everyone asks about, and it’s the smaller half.
- Excerpts of your mail reach a model provider, an embeddings provider and a push service. Each of them is under contract to the vendor rather than to you. A dated subprocessor list naming them is the durable form of that answer, because routing changes without notice.
- Google’s and Microsoft’s developer policies already restrict human access, advertising use and, for Google data, model training, before any vendor writes a word. Assurances that repeat those are floor rather than merit, and enforcement belongs to Google and Microsoft.
- The good answer on human access is a written list of the circumstances, and the ordinary one on that list is the support request you sent.
- Retention decides more than any single promise. Look for a table with a row for derived data, a stated backup exception, and a deletion period at the end of the relationship. Keep the dated copy, so a quiet change is a change you can show.
If connecting any tool to your mailbox still feels like a step too far, that’s a reasonable place to stand, and why you are right to be careful with AI starts from that end instead. What Point can see, and what it cannot is the same ground drawn narrowly around one product, and questions to ask any AI tool about your data is the list to send, in writing, before you decide.