A practical guide

How do you use AI on confidential documents without uploading them?

If you hold client files, medical records or privileged material, the obvious move — point a chat assistant at the folder — is the one thing you cannot do. This is a plain account of the six approaches that exist, what each actually protects, and what each one costs you.

Written by the team building Veldrun, which is one of the six. We have tried to describe the others as their own documentation describes them, and to be specific about where our approach is worse as well as where it is better. Last reviewed 1 September 2026.

First, the constraint that makes this hard

Anything that can search your documents can read your documents. Those are the same sentence. Server-side search, summarisation, previews and AI assistants all work by reading the file — so a provider that has genuinely given up the ability to read your content has also given up the ability to offer those features over it.

That single fact generates the entire market. Every product below is a different answer to it, and each answer buys protection with something.

A test worth applying to any vendor in this category. Ask what the encryption costs you. Credible products publish a list of what stops working — no server-side AI, no preview, no coauthoring, no discovery search. If the answer is “nothing stops working, and we still can’t read it,” at least one of those two claims is not holding.

The six approaches

Approach 1

Paste it into a general chat assistant

Fast, capable, and for most regulated work not available to you. The content leaves your control, the provider’s consumer terms usually differ from its business terms, and you are relying on a setting rather than a boundary.

Protects: Nothing structurally.
Costs: Potentially your confidentiality obligation. Consider whether disclosure to a processor is permitted before, not after.
Right when: The material is genuinely public or fully anonymised already.

Approach 2

Enterprise AI with a data-protection contract

The dominant answer in legal and professional software. Your documents are sent to a hosted model, under commitments that the provider will not retain them and will not train on them — often with a zero-data-retention agreement behind it.

This is a real protection and it is not nothing. But be precise about its nature: it is a promise about conduct, not a property of the system. The documents are readable at the far end; what stops them being read is an agreement and the vendor’s controls.

Protects: Against retention and training. Contractually, not architecturally.
Costs: Your data is legible to a third party at the moment of processing. Diligence becomes vendor diligence.
Right when: Your obligations permit disclosure to a processor and you can stand behind the vendor’s controls.

Approach 3

Redact in flight, before each request

A guardrail sits between you and the model, scrubs identifiers out of each prompt or payload, and often restores them in the response. Several commercial products and open-source libraries do this, and it is a sound idea.

Its limit is scope. It protects the request, not the repository. Your documents and your search index are untouched and still fully identifiable; only the thing crossing the wire is cleaned. If the concern is the archive itself — backups, exports, an integration, a departing employee — this does not reach it.

Protects: Each individual model call.
Costs: Nothing to your stack, but it leaves the stored corpus as exposed as it was.
Right when: You have an existing system and want to bolt safety onto its outbound calls.

Approach 4

End-to-end encrypted storage

Encrypt so that the provider genuinely cannot read your files. Strong, honest, and it collides head-on with the constraint at the top of this page: the provider now cannot offer search, preview, summarisation or AI over that content, because all of those require reading it.

Vendors in this category are usually candid about it, publishing exactly which features stop working. Take that candour as a good sign, and take the list seriously.

Protects: Content at rest and in transit, against the provider itself.
Costs: The features you wanted. Also, if keys are held only by individuals, recovery and legal-hold obligations become a real problem.
Right when: You need storage and sharing, not search and analysis.

Approach 5

Run the models locally

Keep everything on hardware you own. A healthy open-source ecosystem does this well, and nothing crosses a network. The privacy claim here is locality — your files stay put.

Two honest limits. First, local models are generally less capable than frontier models, so you accept a quality ceiling. Second — and this is the one people miss — locality is not de-identification. Your index, your embeddings, your exports and your backups still contain every name and account number in the archive. Local protects you from the outside; it does nothing about what you have built on the inside.

Protects: Against anything leaving the machine.
Costs: Capable always-on hardware, slower first indexing, and usually a weaker model than you could otherwise use.
Right when: The requirement is genuinely “nothing leaves,” and you can live with the quality ceiling.

Approach 6

De-identify at ingest, before anything is stored

Read and redact each document on the way into the index rather than on the way out. Names, addresses and account numbers become placeholders before a single passage is written down, and the map back to the real values is encrypted separately and held only by the owner. A document that cannot be redacted confidently is set aside rather than indexed.

The consequence is the point: the searchable archive contains no identifiers at all. Not because anyone promised not to look — because they are not in it. Everything built on top — search, classification, insights, an integration, an export, a backup — inherits that.

It also changes what model you may use. Once text is de-identified, sending it somewhere is a different question than sending the original would have been, so model choice can become a performance decision rather than a privacy one.

Protects: The stored corpus and everything derived from it.
Costs: Redaction is imperfect and must be measured, not asserted. Over-redaction hides ordinary words. And you need the ingest pipeline in the first place — this is not something you bolt on.
Right when: The archive itself is the asset you are protecting, not just the outbound call.

Side by side

What each approach actually protects. “Store” means your index, embeddings, exports and backups — not just the original files.

Approach	Originals stay put	Store is de-identified	Search & AI still work	Frontier-model quality available
Chat assistant, pasted in	No	No	Yes	Yes
Enterprise AI + contract	Usually not	No	Yes	Yes
Redact in flight	Yes	No	Yes	Yes
End-to-end encrypted storage	Yes	n/a — unreadable	No	No
Local models	Yes	No	Yes	No
De-identify at ingest	Yes	Yes	Yes	Possible, on de-identified text

Questions worth asking any vendor

Does my content reach a model you do not run? “Your data stays in your environment” often means a contractual retention promise, not the absence of an outbound call. Ask which.
What is in your index? If the answer is “your documents,” then your index is as sensitive as your documents, and it needs the same controls, backups and disposal.
What accuracy do you publish, on what corpus? Most de-identification vendors publish none, substituting certifications and volume. A certification attests to a dataset under stated conditions; it does not measure a detector’s recall.
Can an administrator recover an employee’s content? If no, ask how you will meet legal-hold, records-retention and offboarding obligations. If yes, ask who is notified and what is logged.
What stops working because of the encryption? A vendor who cannot answer has probably not made the trade they are describing.
Is it on-premise, or on-premise with a licence check? Some “air-gapped” products stop serving if they cannot reach a billing endpoint. Ask directly.

Where Veldrun sits, and where it does not

Veldrun is approach six. It reads scanned and photographed documents locally, de-identifies them before they are indexed, answers questions with links to the exact passage used, and is built to weigh sources by whether they deserve to be believed rather than only by textual similarity. It runs on a Windows machine you own.

It is a poor fit if:

You need macOS or Linux today — both are planned, neither exists yet.
You want a hosted service with no hardware of your own.
You need full-text search on a phone, or a large multi-office deployment right now.
You want something you can buy this afternoon. It is in pre-release and is not for sale.

We publish our redaction measurements, the method behind them and their known gaps, because in a category where almost nobody publishes numbers we would rather be checked than believed.

See the measurements Follow development