On-device vs cloud PII redaction: which is safe for GDPR?: Amaze

On-device (local) PII redaction processes your data entirely on your own machine, so no third party ever receives it — there is no new processor to contract, no cross-border transfer to justify, and no extra breach surface. Cloud PII redaction uploads your raw, still-identifiable data to a third-party server before it is masked, which under the GDPR adds a processor (Art. 28), a possible international transfer (Chapter V), and one more place your data can leak. For sensitive data, local is the lower-risk default.

TL;DR

On-device redaction = data never leaves your device. The vendor processes nothing, so no data processing agreement (DPA) is needed for the redaction step itself, no transfer rules apply, and it works with the network unplugged.
Cloud redaction = you send un-redacted personal data to the vendor to redact it. That upload is a processing activity by a new processor, often in a third country, before any masking happens.
The paradox of cloud redaction: to protect the data, you first have to expose it to another company.
Cloud can be fine for low-sensitivity data with a solid DPA and lawful transfer mechanism. For client, patient, or special-category data, on-device is the safer default.
Amaze runs the whole redaction locally — it can work fully air-gapped, so nothing is uploaded to be masked.

How does cloud PII redaction actually work?

A cloud PII-redaction tool follows a simple flow: you upload your document, their server detects and masks the personal data, and it sends the redacted version back. The important word is upload. The masking happens on infrastructure you don’t control, which means the un-redacted data — the version that still contains every name, ID number, and email — has to travel to and sit on a third party’s systems, at least in memory, before anything is removed.

That single design choice has four consequences under the GDPR:

A new processor. The vendor processes personal data on your behalf, so they are a processor under Article 28 GDPR. Article 28 requires a binding written contract (a DPA) that sets out the subject matter, duration, nature and purpose of processing, the types of data, and the processor’s obligations — including that it acts only on your documented instructions and applies appropriate security under Article 32.
A sub-processor chain. Most SaaS vendors run on someone else’s cloud (AWS, Azure, GCP) and use further sub-services. Under Article 28, engaging a sub-processor needs your prior authorisation, and your original processor stays fully liable for what those sub-processors do. Every link is another entity touching your data.
A possible cross-border transfer. If the vendor or any sub-processor stores or processes the data outside the EEA, you have an international transfer under Chapter V (Art. 44 GDPR). A transfer is only lawful with an adequacy decision or appropriate safeguards under Article 46, such as Standard Contractual Clauses — and after Schrems II, SCCs may require a transfer impact assessment on top.
A new breach surface. Data in transit and data at rest on someone else’s servers is one more place that can be misconfigured, subpoenaed, or breached. You cannot delegate away your accountability as controller.

How does on-device (local) redaction work?

On-device redaction runs the detection and masking on your own computer or infrastructure, so the raw data never leaves the machine. You open a file locally, the tool scans it in place, and only a masked version is produced — nothing is transmitted to be processed. Amaze works exactly this way: it detects and masks personal data “entirely on your own machine or infrastructure,” and it is air-gap ready — you can disconnect from the network completely and anonymization still works, with no outbound connections while a document is processed.

Because no third party ever receives the data:

There is no processor to contract for the redaction step — Article 28 governs a processor that receives data, and here none does.
There is no transfer — the data doesn’t cross a border because it doesn’t leave the device.
There is no added breach surface from the tool — the attack surface is the machine you already control and already secure.

This is the cleanest expression of data minimisation and security-by-design (Art. 25, Art. 32): the most private way to handle personal data is to not send it anywhere in the first place.

It can be — but it is never automatically compliant. Using a cloud redaction tool lawfully means you must, at minimum:

sign an Article 28 DPA with the vendor,
confirm and authorise the full sub-processor chain,
establish a lawful basis for the transfer if any processing happens outside the EEA (adequacy or Art. 46 safeguards, plus a transfer risk assessment where needed),
satisfy yourself the vendor’s Article 32 security is adequate,
and account for the extra breach surface in your risk assessment and, where relevant, your DPIA.

None of that is impossible. It is simply work and residual risk that on-device redaction removes entirely — because the trigger for all of it is the vendor receiving your data, and on-device tools never do.

On-device vs cloud PII redaction: the comparison table

Criterion	On-device / local redaction	Cloud redaction
Where the raw data is processed	On your own machine / infrastructure	Uploaded to the vendor’s servers
New processor under Art. 28?	No — the vendor receives no data	Yes — vendor is a processor; DPA required
Sub-processor chain?	None introduced by the tool	Usually (cloud host + sub-services)
Cross-border transfer (Chapter V)?	No — data never leaves the device	Possible — depends on vendor/sub-processor location
DPA needed for the redaction step?	No	Yes (Art. 28)
Extra breach surface	None beyond your own device	Data in transit + at rest on third-party systems
Works offline / air-gapped?	Yes	No — needs a connection to upload
Who stays accountable as controller	You	You (accountability can’t be outsourced)

When is cloud redaction acceptable?

On-device is the safer default, but cloud redaction is a reasonable choice when:

the data is low-sensitivity (not special-category, not client/patient/legal material),
you already have a vetted DPA and lawful transfer mechanism with that vendor for other purposes,
you need large-scale, server-side throughput that local hardware can’t match, or
the redaction is part of a pipeline that already lawfully lives in the cloud.

Cloud redaction is hard to justify when: you’re handling client, patient, or special-category data; you have no DPA or transfer basis in place; you operate under professional secrecy (lawyers, doctors); or you simply want the smallest possible attack surface. For those cases, keep the data on the device.

Before and after: what redaction looks like

Redaction replaces each identifier with a consistent placeholder token, so the text stays usable while the personal data is gone.

Before (raw — this is what a cloud tool would upload):

Patient Anna Nowak (PESEL 85010212345), email [email protected], was admitted on 12 March with chest pain.

After (masked — on-device, before anything is sent anywhere):

Patient [PERSON] (PESEL [PESEL]), email [EMAIL], was admitted on [DATE] with chest pain.

With on-device redaction, the “before” version never leaves your computer. With cloud redaction, the “before” version is exactly what you transmit to a third party — the un-redacted original — in order to get the “after” back.

FAQ

Is on-device PII redaction more GDPR-compliant than cloud? It removes several compliance obligations rather than being “more compliant” in the abstract. Because no third party receives the data, there is no Article 28 processor relationship for the redaction step, no Chapter V transfer, and no added breach surface — so there is simply less to document and less that can go wrong.

Do I still need a DPA if I use an on-device tool? Not for the redaction step, because the vendor never processes your data. You still handle your own controller obligations (records of processing, security, data subject rights), but there is no processor to contract for the local masking itself. Always confirm the tool genuinely runs locally and sends nothing home.

Does cloud redaction always mean an international transfer? No — only if the vendor or a sub-processor stores or processes the data outside the EEA. But you have to verify that across the whole sub-processor chain, and it can change over time. On-device sidesteps the question entirely.

Isn’t the data protected in transit to a cloud redactor? Encryption in transit and at rest reduces risk but doesn’t remove it: the vendor still receives, processes, and can access the un-redacted data, which is exactly what creates the processor relationship and the breach surface. Encryption is a safeguard, not the absence of a transfer.

Can on-device redaction work with no internet at all? Yes. A properly local tool works air-gapped — Amaze runs with the network disconnected and makes no outbound connections while a document is processed, so it’s suitable even for isolated or classified environments.

Keep sensitive data on your machine

If your data is sensitive, the safest redaction is the one that never uploads it. Amaze detects and masks personal data — names (including Polish names across grammatical cases), emails, phone numbers, and Polish identifiers like PESEL, NIP, REGON and KRS — entirely on your own device, so lawyers, doctors, and analysts can use ChatGPT, Claude, and Gemini without sending client data to the cloud. It runs fully offline, and every masking is reversible locally with your private key.

On-device vs cloud PII redaction: which is safe for GDPR?