Local can mean four different things. Only one of them removes the copy.

In-browser: the rules ship with the page and execute on the visitor's machine. The content never leaves the tab, and there is no copy to retain, no subprocessor to list and no retention default to negotiate.

On-premise: software runs on your own infrastructure. The data stays inside your network, but you now own the deployment, the updates and the rule set versioning.

Private cloud: an isolated tenancy at a vendor. Strong contractual controls, and the analysis still happens on somebody else's hardware, which means a copy exists.

Vendor-side processing: the common case. Content is uploaded, analysed and may be logged. Workable for public material, awkward for anything under NDA.

A local check is not a stronger promise about data handling. It removes the handling step, which is a different category of assurance.

Practically, that means no data processing agreement amendment, no new subprocessor on the list, no retention question and no export to review. The security questionnaire gets shorter rather than better answered.

It also makes the check cheap enough to run on everything. A round trip takes time and costs money; a local rule engine takes milliseconds, which is why it can sit on every paste rather than on a sample.

Browser execution sees only what you give it: one document, one file, the pasted text. It cannot crawl a site, resolve a cross-page anchor or check an external link.

It also inherits the browser's constraints. Very large files, unusual formats and older devices are all narrower limits than a server would have.

And rules must be delivered to the browser, so they are visible to anyone who looks. For pattern matching that is fine; for anything involving a secret or a proprietary model, it is not.

Ask where the analysis happens, then verify it: run a check with the network panel open, then again with networking disabled. If the second run still returns findings, the analysis is local.

Most organisations need more than one answer. Public marketing pages can go through a vendor-side service without much thought; a client's unreleased financial model, a legal draft or a pre-launch product screenshot cannot.

So classify by content rather than choosing one tool for everything. The classification is small: public, internal, confidential, regulated. Each class maps to a placement.

Write that mapping down. It is the artefact that stops a well-meaning person pasting the wrong document into the wrong tool.

Local execution removes the data risk, not the judgement. Someone still has to decide whether the finding is acceptable, whether the work is fit to publish and who is accountable.

For confidential material that decision is usually internal: an editor, an engineer, a compliance reader. For client work it often belongs to a named external reviewer who signs a defined scope.

The architecture determines what you can prove about handling. Only a person can say whether the work should go out.