You Ran It Through a Local LLM to Keep It Private. Then You Emailed the Output.

Last updated: 2026-07-04

The Short Answer

Running Ollama, LM Studio, or a self-hosted model instead of ChatGPT solves exactly one problem: your prompts and source documents never leave your machine during inference. It does nothing for the next step — handing the output to a client, a collaborator, or a regulator.

That handoff is where most "private AI" workflows quietly fail. The redacted contract analysis gets emailed as a .docx attachment. The anonymized dataset gets dropped into a Google Drive folder and shared "anyone with the link." The audit summary goes out over Slack DM. Every one of those channels puts a copy of a sensitive file on a server you don't control, indefinitely, with no expiration and no way to revoke access once it's sent.

If the reason you run a local model is that you don't trust third parties with the input, you need a transfer method that doesn't trust third parties with the output either. That's a narrower, more solvable problem than "AI privacy" as a whole, and it's the one this guide covers.

---

The Blind Spot: Inference Is Local, Delivery Isn't

Privacy-conscious developers and consultants have gotten good at locking down the inference layer. Local models, encrypted vector stores, no telemetry, no cloud API calls. It's a real improvement over routing everything through a hosted chatbot.

But the output of that pipeline is a normal file — a PDF, a spreadsheet, a markdown report, a .json export of structured findings — and normal files get moved the way files have always been moved: attached to an email, or dropped into whatever cloud storage folder is already open. Neither of those was designed with your threat model in mind.

Email attachments sit on your mail provider's servers and the recipient's, unencrypted from the provider's point of view, often forwarded, printed, or synced to a phone with no further controls. If the file contains a client's financial records or a patient's redacted-but-reconstructible medical history, that attachment is now living in at least two inboxes you don't manage.

Public or "anyone with the link" cloud shares are worse in a specific way: the link itself becomes the only access control. It can be forwarded, indexed by a browser's autofill, or left active for months after the reason for sharing it has passed. Google Drive and Dropbox both hold the decryption keys server-side — a valid legal request or an internal breach exposes the file in plaintext, no matter how private your local model was.

Slack and Teams DMs persist in a searchable history that outlives the conversation, often gets exported for e-discovery, and syncs to devices you have no visibility into.

None of these are hypothetical edge cases. They're the default behavior of the tools most people already have open.

---

What "Secure Enough for This" Actually Requires

A transfer method closes the gap only if it satisfies four things at once:

1. End-to-end encryption where the provider never holds a readable copy. Encryption "at rest" on the provider's servers isn't the same thing — if they can decrypt it to serve it to you, they can decrypt it for someone else with the right subpoena.
2. An expiration you control. A link or shared file that's accessible today should not still be accessible in six months because nobody remembered to remove it.
3. Revocation. If you send something to the wrong person, or a project ends, you need to be able to kill access immediately — not just delete your copy and hope.
4. No account requirement for the recipient. If your client or collaborator has to create an account with a new service to receive one file, they won't, and you'll end up back on email "just this once."

Most consumer tools satisfy zero of these. A password-protected zip emailed as an attachment satisfies maybe one, and weakly — email providers and endpoint security tools routinely scan attachment contents, and a shared password sent in a follow-up email defeats the point.

---

Comparing the Realistic Options

| Method | E2E encrypted | Expiring access | Revocable | Recipient needs account |

|---|---|---|---|---|

| Email attachment | No | No | No | No |

| Google Drive / Dropbox link | No (provider holds keys) | Manual only | Yes, manually | No |

| Password-protected zip via email | Partial | No | No | No |

| WeTransfer (free tier) | No | Yes (7 days, fixed) | No | No |

| Tresorit Send | Yes | Yes, custom | Yes, instantly | No |

The pattern worth noticing: the tools people default to (email, Drive, WeTransfer) all fail on end-to-end encryption, revocation, or both. Tresorit Send is built specifically for this one-off transfer case — it doesn't require the recipient to have a Tresorit account, the file is encrypted before it leaves your device, and you can set an expiration date or kill the link the moment it's no longer needed.

This is a narrower use case than Tresorit's team storage plans (covered in our Tresorit vs. Proton Drive comparison for AI teams handling ongoing RAG pipelines). Send is the right tool when you have a single output file that needs to go to someone outside your organization, once, and you need proof of when access ended.

---

Setting Up a Secure Send Workflow

The practical version of this, once, so it becomes routine:

1. Finish your local AI analysis the way you already do — Ollama, LM Studio, or whatever self-hosted stack processes the source material.
2. Export the output to a dedicated "outbound" folder, separate from your working files. This makes it obvious what's about to leave your machine.
3. Upload to Tresorit Send rather than attaching to the email you're about to write. The file encrypts client-side before upload.
4. Set an expiration. For a one-time deliverable, 7–14 days is usually enough. For an ongoing engagement, set a review reminder to revoke and re-send rather than leaving a link open indefinitely.
5. Send the link, not the file, in whatever channel you'd normally use — email, Slack, a project management tool. The link itself grants no access without going through Tresorit's encrypted delivery.
6. Revoke access as soon as the recipient confirms receipt, if the file was a one-time deliverable. Don't rely on the expiration date alone if the engagement is sensitive enough to matter.

The overhead is one extra step per delivery. For a freelancer or consultant handling even a handful of sensitive engagements a year, that's a small, fixed cost against a real reduction in exposure.

Affiliate Disclosure: This article may contain affiliate links. If you make a purchase through these links, we may earn a small commission at no extra cost to you. We only recommend products we genuinely believe in. This helps support our work and allows us to continue providing free content.

Subscribe