What to ask before putting a document into a redaction tool

Choosing a redaction tool means handing your most sensitive documents to someone else — often the exact documents you were trying to protect. It's worth ten minutes of due diligence, and the answers aren't always where the marketing puts them.

These are the five questions worth establishing before you upload anything, and how to find real answers rather than reassuring ones.

General guidance, not legal advice. Requirements differ by jurisdiction and by the type of data involved — in the UK and EU the relevant authority is your data protection regulator (the ICO's guidance on controller and processor contracts is a good starting point); in the US it depends which regime applies to you.

1. Does the content leave your machine?

There are three broad architectures, and the difference matters.

Fully local. The tool runs entirely in your browser or as desktop software. Nothing is transmitted. That is the architecture if policy says the file must never leave the device.

Hosted processing. The document is sent to a server, processed, and returned. Whether that's acceptable depends entirely on the answers to the questions below. The pattern that belongs in legal and healthcare work is: nothing written to disk, no outside model. "We delete it in 30 days" is a different claim.

Hybrid — and read this one carefully. Some tools describe keeping your file in the browser while sending only the extracted text for analysis. That's a genuine architectural difference, but consider what it protects. For a document you're redacting, the text is the sensitive part. The names, addresses, account numbers and case details are all in the text being transmitted. Keeping the file container local while sending its contents is a much smaller privacy guarantee than the phrasing usually implies.

The question to ask isn't "do you upload my file." It's "does any part of my document's content leave my device, and if so which part."

2. Who else processes it?

Many redaction tools use a third-party AI service to identify personal data. If so, your document content is being sent to another company, and this has consequences beyond the vendor's own privacy policy.

Every major privacy regime treats this the same way in substance, even though the vocabulary differs:

Most other US state privacy laws — Virginia, Colorado, Connecticut and the rest of the growing patchwork — follow the controller/processor structure closely enough that the GDPR column is a reasonable guide.

Whichever applies, the consequences are similar:

• your vendor generally needs your authorisation before using a sub-processor
• the arrangement has to be covered contractually, down the chain
• under GDPR the sub-processor belongs in your record of processing activities
• under HIPAA, a subcontractor handling PHI needs its own BAA — the vendor's agreement with you doesn't cover them by itself
• if the data crosses a border, you may have a transfer to assess and document (SCCs in the EU, the IDTA or UK Addendum in the UK)

None of this is prohibitive. Organisations use sub-processors constantly. But it's work you have to do, and you can only do it if you know the sub-processor exists — which is why it's worth asking directly rather than inferring from the homepage.

Note that infrastructure hosting is a different question. Every hosted service runs on someone's servers, and a cloud host that stores encrypted data at rest is a very different proposition from an AI service that reads your document contents to analyse them. Don't conflate the two, in either direction.

3. How long is it kept?

"We don't store your documents" and "we delete your documents within 30 days" are very different statements, and they can appear on the same page.

A retention period is not an absence of retention. If content is deleted after some window, then during that window it exists somewhere, on someone's disk, within reach of their staff, their backups, and anyone who compromises them.

Ask specifically:

• Is content written to disk at any point, or held only in memory?
• If it's stored, for how long, and where?
• What about logs? Content can end up in application logs even when the main flow doesn't store it.
• What about the redacted output — is that retained, even if the input isn't?

The last one catches people out. A tool can honestly claim it doesn't keep your original while retaining the processed version.

4. What does the redaction actually do?

Some tools cover content rather than removing it. A black rectangle drawn over text leaves the text in the file, fully recoverable by anyone who receives it — this has caused real disclosure incidents, and it's covered in why drawing a black box isn't redaction.

Ask whether the output has the original content removed or obscured, and then verify it yourself: open the result, select the text under a redaction, copy it, and paste it somewhere plain. That takes thirty seconds and is worth more than any claim on a features page.

Also ask what happens to document metadata. Author names, original filenames and editing history survive redaction in plenty of tools that handle the visible page correctly.

5. What does using it oblige you to do?

This is the question people skip, and it's the one that creates work later.

Choosing a tool that sends content to third parties means you may need a contract with that vendor and cover for its subcontractors, an entry in your records of processing, a transfer assessment if the data crosses a border, and a defensible answer if a data subject or a regulator asks who has handled the information.

If you're handling health data in the US, that includes getting a BAA from the vendor and satisfying yourself its subcontractors are covered — a vendor that won't sign a BAA is simply not usable for PHI, whatever its feature list says.

Choosing a tool that processes content without third parties means most of that disappears. Not because compliance stops mattering, but because there are fewer parties in the chain to account for.

Neither is right or wrong. But the cheaper tool is not cheaper if it adds a fortnight of paperwork to your compliance calendar.

Where to find real answers

Not the homepage. Marketing copy is written to reassure and is often technically defensible while leaving a misleading impression — "we don't upload your files" can coexist with transmitting every word they contain.

Look instead at:

• The privacy policy and any data processing agreement. Sub-processors are usually listed here, sometimes on a dedicated page, because they have to be.
• The security or trust page, if one exists, for retention specifics.
• A direct question by email. "Does any of my document content leave my device, does any third party process it, and is anything written to disk?" A vendor confident in their architecture will answer plainly. Vagueness is itself an answer.

One caveat on certifications, since US procurement often starts there: SOC 2 tells you a firm has controls and has been audited against them. It does not tell you where your data goes. A SOC 2 Type II vendor can still route every document through a third-party AI service — entirely legitimately, and entirely within scope of its report. The same goes for ISO 27001. They're worth having and worth asking about, but they answer a different question from the five above, and a certification badge is not a substitute for knowing the architecture.

Where eleyed sits

For completeness, and because you should hold this page to its own standard:

eleyed is hosted: the file is processed on eleyed's servers, in memory, and discarded. Detection runs on infrastructure eleyed operates — content is never sent to OpenAI, Anthropic, Google or any other outside model, so there is no AI sub-processor to put on a processing record. Neither the original nor the redacted output is written to disk, and content does not appear in logs. Activity records hold only what was done, not what was in the document.

You can use it in the browser or call the REST API. Scanned PDFs are included; built-in OCR reads the page.

If the job is a subject access response specifically, what eleyed does and does not do with a SAR bundle is set out separately.

The redaction removes content rather than covering it. Verify that with the copy-paste test above rather than taking it on trust.

If a file must never leave the device, a fully local editor is the architecture for that constraint. For everyone else, the five questions above are the ones that matter.