Why on-device AI is private by design

Most AI tools work by uploading your data to a server, running a model there, and sending the result back. Their privacy promise is a policy: "we won't keep it," "we won't look," "we'll delete it after." You have to trust that promise, and you have no way to verify it. On-device AI is different — the model runs on your machine, so there is nothing to upload and nothing to trust.

This is the core idea behind how the Novus apps are built. It is worth understanding why "private by design" is a stronger claim than "private by policy."

Policy privacy says: your data goes to our server, but we have rules about how we handle it. Even when those rules are sincere, the data still left your control — it traveled across the network, sat in a server's memory, and depended on the provider's security and good faith. A breach, a policy change, or a subpoena can all reach it.

Structural privacy says: your data never leaves your device, so there is no server copy to handle, breach, or hand over. The privacy is a consequence of where the computation happens, not a promise about what someone does with your data. That is what "private by design" means.

In a tool like NSS Background Remover, the AI model downloads to your browser once and then runs locally. When you remove a background, the inference happens on your device — there is no network request for processing, no server log of your image, and no third party that ever sees it. The app even works offline once the model is cached.

The pattern is sometimes described as "bringing the model to the data instead of the data to the model." The model is a few dozen to a couple hundred megabytes; your sensitive images stay exactly where they are.

For casual snapshots, server upload is no big deal. But people regularly run client deliverables, unpublished product photography, confidential documents, personal family photos, and their own face-on-camera through these tools. For all of those, "the data never left my machine" is a meaningfully different guarantee than "a company says it deleted my upload."

On-device processing also removes a whole category of risk: there is no breach of a server that does not hold your data, and no policy change that can retroactively expose what was never collected.

Security people reason about privacy through threat models — explicit lists of what could go wrong and which designs protect against each — and running the two architectures through one makes the abstract difference tangible. Consider the threats to data that has been uploaded to a server: the server could be breached by an attacker, the provider could be compelled by legal process to hand the data over, the company could change its retention policy after you used it, a malicious or careless insider could access it, and the data could be swept into a model-training set you never agreed to. Each of these is a real, documented way uploaded data has been exposed.

Now run on-device processing through the same model. A breach of the provider's servers cannot reach your data, because your data was never on those servers. A subpoena to the provider returns nothing about your content, because they never received it. A policy change cannot retroactively expose what was never collected. An insider cannot access a copy that does not exist. And your content cannot be added to a training set it never entered. The on-device architecture does not mitigate these threats one by one; it removes the precondition all of them share — the existence of a server-side copy. That is what makes structural privacy categorically stronger than policy privacy: it eliminates the target rather than guarding it.

A common reassurance from cloud tools is that uploads are deleted promptly after processing, and it is worth examining why that promise, however sincere, is fundamentally weaker than it sounds. The problem is not that providers are lying; it is that the claim is unverifiable from the outside. You cannot inspect their servers, audit their deletion process, or confirm that a copy was not retained in a backup, a log, or a cache. You are asked to trust an assertion about the internal behavior of a system you have no visibility into, and trust is exactly the thing a strong privacy guarantee should not require.

Even a provider who deletes diligently cannot fully eliminate the window of exposure, because the data still existed on their infrastructure for some period, traversed their network, and sat in memory or storage long enough to be processed. During that window it was subject to every threat in the model above. "We delete it after" shrinks the window but does not close it, and it remains a claim you take on faith. On-device processing makes the deletion question moot: there is nothing to delete because nothing was ever uploaded, so the guarantee does not depend on the provider doing anything correctly after the fact. The strongest version of "we deleted your data" is "we never received it."

Privacy discussions tend to focus on the obvious payload — the image, the audio, the document — but uploading to a server can expose more than the file itself, and on-device processing protects that too. When you send a file to a remote service, the request can carry metadata: when you used the tool, how often, from what network, alongside what other requests, building a usage pattern even if the content were somehow protected. The file may also carry embedded data of its own, like location or device information in a photo's metadata, which travels with it to the server.

On-device processing keeps all of that local along with the content. There is no server compiling a record of when and how often you remove backgrounds, no request pattern accumulating on someone else's infrastructure, and no embedded file metadata being transmitted, because the file never leaves your machine to carry anything anywhere. This is a subtler layer of privacy than the headline "your image stays local," but it matters for anyone whose usage patterns or file metadata are themselves sensitive. The structural guarantee covers not just the content you are conscious of but the surrounding data you might not think about, simply because none of it is ever sent.

A dimension of cloud privacy that is easy to forget is that the entity holding your data may not stay the same entity, and its successors may not honor the original promises. Companies are acquired, go bankrupt, change leadership, and pivot their business models, and data held on their servers can be treated as an asset that passes to whoever takes over — under new terms you never agreed to. A privacy policy is a promise by a particular company at a particular time, and that company can change or cease to exist while the data it collected persists.

On-device processing makes the privacy guarantee independent of the provider's corporate future. Because your data was never collected, there is nothing to be sold in an acquisition, exposed in a bankruptcy, or governed by a new owner's different policies. The guarantee does not depend on the company continuing to exist or continuing to behave as it promised, because it is not a behavior of the company at all — it is a property of where the computation happened. For data you expect to remain private for years, the durability of a structural guarantee that survives any corporate change is worth far more than a policy promise that is only as stable as the company making it.

For anyone operating under data-protection obligations, on-device processing has a quietly powerful property: the easiest data to handle compliantly is data you never collect. Regulations that govern personal data impose duties around storage, access, retention, breach notification, and deletion — all of which presuppose that the data is in your custody. A tool that processes everything on the user's own device, transmitting nothing, never takes custody of the user's content in the first place, which sidesteps an entire category of obligations rather than trying to satisfy them.

This is a meaningful advantage for both the tool's operator and its users. The operator is not holding a trove of user images or audio that must be secured, retained correctly, and deleted on request, because they hold none of it. The user, in turn, can process sensitive material — including material they themselves are responsible for protecting — without it passing through a third party's systems, which simplifies their own compliance posture. Minimizing data collection is widely recognized as a sound privacy principle precisely because uncollected data cannot be mishandled, and on-device processing is that principle taken to its logical end: the tool works without collecting the user's content at all.

The reason "private by design" is a strong claim connects to a general principle in security and privacy engineering: it is more robust to make a class of problem impossible than to manage it carefully. Eliminating the existence of a sensitive copy is structurally safer than guarding that copy well, because guarding depends on continued correct behavior — good security, sound policy, careful staff — across time, while elimination depends on nothing ongoing. The most reliable way to protect data is to not hold it, and the most reliable way to prevent its exposure in transit is to not transmit it.

On-device AI is an application of that principle to a specific domain, and seeing it as an instance of a broader idea explains why it feels categorically different from a privacy policy rather than just better. A policy is a promise to manage a risk; a structural design removes the risk's precondition. The same logic underlies many strong security practices — minimizing what you collect, reducing attack surface, designing so that the sensitive thing simply is not there to be compromised. When privacy is achieved this way, it is not a feature layered on top that could be misconfigured or revoked; it is a consequence of the architecture that holds as long as the architecture does, which is what earns it the phrase "by design."

While structural privacy benefits everyone, it is worth naming who it matters most for, because for some users it is the difference between being able to use a tool and not. Professionals handling client work under confidentiality obligations cannot responsibly upload deliverables to an opaque third party, regardless of the provider's policy. People processing identity documents, medical images, or other sensitive personal material face real consequences if that data is exposed. Creators working on unreleased material need it not to leak before launch. And anyone in a vulnerable situation may have specific, serious reasons their images or audio must not leave their control.

For these users, "we promise to handle your upload responsibly" is not good enough, because the consequences of the promise failing are too high and the promise is unverifiable. A structural guarantee that the data never leaves their device is what lets them use the tool at all, and it lets them do so without having to investigate and trust the provider first. By building the privacy into the architecture rather than the policy, an on-device tool serves exactly the users who most need a guarantee they can rely on absolutely — which is a large and important population, even though the casual user processing a snapshot may never need to think about it.

One of the most appealing properties of structural privacy is that you do not have to take it on faith — it is observable in a way a policy promise can never be. The simplest demonstration is the offline test: if a tool keeps working with your internet connection switched off, it cannot be sending your data anywhere, because there is no connection for it to use. A tool that removes a background or transcribes audio with the network disabled is proving, in the plainest possible terms, that the work is happening on your machine and nowhere else.

More technically inclined users can go further and watch the tool's network activity directly through their browser's developer tools, observing that no request carries their content to a processing endpoint. The point is not that everyone will perform these checks but that they are possible at all — the claim is falsifiable, which a policy promise is not. You cannot audit a provider's servers to confirm they deleted your upload, but you can confirm, from your own machine, that an on-device tool never sent it. That observability is itself part of what makes structural privacy trustworthy: it does not ask for trust, it offers proof.

A reasonable question is whether a cloud tool that encrypts your upload provides comparable privacy, and the distinction is worth drawing carefully because encryption is genuinely valuable but solves a different problem. Encrypting data in transit protects it from being intercepted while it travels to the server, which is important — but once it arrives, it must typically be decrypted for the server to process it, at which point a usable copy exists on the provider's infrastructure, subject to every threat in the model: breach, subpoena, policy change, insider access. Encryption in transit guards the journey, not the destination.

On-device processing protects against a threat encryption of an upload cannot: the existence of the data on someone else's machine at all. Because nothing is uploaded, there is no journey to protect and no destination copy to worry about, so the question of whether the server handles the decrypted data well never arises. This is not to dismiss encryption, which is essential for the data that genuinely must be transmitted; it is to clarify that encrypting an upload and not uploading at all are different guarantees. The former protects sensitive data in motion to a place it will still exist; the latter ensures it never goes to that place. For the strongest privacy, not transmitting beats transmitting securely.

Intellectual honesty requires being clear about the boundary of the guarantee, because "private by design" protects against a specific set of threats and not all conceivable ones. On-device processing ensures your data is not sent to the tool provider's servers; it does not, by itself, secure your own device. If your computer is compromised by malware, or someone has physical access to it, the data on it — including what you process locally — is at risk from that, just as everything else on your device is. The on-device guarantee is about the provider and the network, not about the security of your own machine.

This boundary is not a weakness of the approach so much as a clarification of what it claims. On-device privacy removes the provider and the network from the threat picture entirely, which is a large and meaningful reduction, but it leaves the responsibility for your own device's security where it always was — with you and your normal practices. The honest framing is that on-device processing makes the tool itself not a privacy risk, rather than making your device invulnerable to every threat. That is still a profound improvement over a model where you must trust both your own security and a remote provider's; it simply does not claim to be more than it is, which is consistent with the broader honesty the approach is built on.

On-device AI asks your device to do the work, so a very old or weak machine will be slower, and the first use downloads the model. It also means the provider cannot offer some server-only conveniences. For most people, those are small prices for genuine, structural privacy — and modern browsers (via WebGPU and WebAssembly) make local AI fast enough to be practical.

The Novus apps make that trade deliberately: keep the processing local, keep the tools free and unlimited, and let privacy be something you do not have to trust because it is built into how the software works.