Cloud DLP APIs vs on-device masking: what the architecture decides for you
The big clouds both offer mature services for finding and masking personal data. Google Cloud Sensitive Data Protection, which most people still call Cloud DLP, inspects and de-identifies text through its API, priced per gigabyte processed. AWS Comprehend detects and redacts PII priced per hundred characters. These are not the dubious middlemen we wrote about in the cloud scrubber piece; they are professional infrastructure with contracts, certifications and real engineering behind them.
They are also, architecturally, the same shape: your unredacted text is sent to the provider's cloud, processed there, and returned. Everything that follows comes from that one fact.
When a cloud DLP API is the right call
Be fair to these services first. If your data already lives in that cloud, a DLP API adds no new party: text sitting in BigQuery that Google's DLP inspects was already on Google's infrastructure, under the same data processing agreement. For batch de-identification of large stores, for scanning your own warehouses for stray personal data, for pipelines that run where the data is, these services are built for the job and priced for it. Google's API even supports reversible tokenization, with the mapping handled server-side.
The contractual position is real protection. It is also the operative word.
What changes when the text was never theirs
Now take the case this blog cares about: a person about to paste client or patient text into an AI assistant. Routing that text through a DLP API before it reaches the model means the raw, identifying text makes one extra network hop, to one extra processor, before the protection is applied. You have added a second company that handles the original, and your privacy analysis now covers both.
That can be an acceptable, documented trade. But notice what kind of protection it is: a promise about conduct, backed by a contract. The provider processes your raw text and commits to handling it properly. On-device masking makes a different kind of promise, one about architecture: the raw text is not sent to anyone, because the masking already happened on the machine where the text lives. The first promise you audit; the second you can test, by cutting the network and watching the masking still work.
There are practical differences too. A per-gigabyte or per-request API bill scales with usage and requires integration work, an account, credentials and quota. It is infrastructure, with infrastructure's overheads. A local tool has none of that surface: nothing to integrate, no request leaving, nothing metered per paste.
The question that sorts every option
Where does the raw text go before it is protected? Every de-identification product, ours included, should answer that in one sentence. For Google and AWS the answer is "to our cloud, under contract", and for data already resident there, that answer is fine. For text that starts on a person's machine and did not need to leave, "nowhere" is available, and it is the stronger answer precisely because it does not depend on anyone keeping a promise.
Velum's answer is "nowhere": detection and masking run on the device, the reply is restored on the device, and the benchmarks page publishes what the detection catches and what slips through, per language, so the quality of the local answer is measured rather than assumed. If your sensitive text starts on your machine, start there too.