Privacy

Privacy as a Feature, Not a Compliance Check

There are two types of privacy in software today. The one written by lawyers, and the one built by engineers. Here is why the difference matters.

I've always found privacy policies to be basically theater.

There are two types of privacy in software right now. The first kind is written by lawyers. It's a 10-page PDF that you're forced to agree to during onboarding. It exists entirely to give a company legal cover to extract your data, package it up, and send it to a server you'll never see. It's compliance disguised as a feature.

The second kind is built by engineers. It doesn't need a sprawling legal document because the premise is brutally simple: the data literally never leaves your phone.

That is privacy as a physical property of the system.

The cloud compromise

When you build an AI feature using a cloud API, you're making a silent compromise on behalf of your users.

Their text leaves their device. It travels across a network, hits a server farm operated by a massive third party, gets logged, and maybe gets used for training data later. You don't own the infrastructure. You're just hoping the vendor honors whatever their Terms of Service happens to say today.

If you're building a weather app, who cares.

But I keep thinking about developers building mental health journals, or finance trackers, or apps for kids. "Your most intimate thoughts are sent to a remote server for processing" isn't a product feature. It's a massive liability.

The architecture of trust

Trust is hard to earn and incredibly easy to lose.

When inference runs entirely on-device, your architecture does the heavy lifting for you. You don't have to convince users to trust a third-party data processor. You just tell them the truth: there is no cloud. Your data stays yours.

This actually changes how you build software:

No Data Processing Agreements. If you aren't sending personal data to a third-party AI provider, you don't need to sign a GDPR DPA with them. The compliance burden just vanishes.

Shorter privacy policies. You don't need to write a convoluted section explaining how AI models ingest user data, because they don't.

Zero consent friction. You don't need to interrupt your user experience with a dialog box begging for permission to send their data away. The feature just works.

Writing the code

Apple figured this out years ago. They started putting Neural Engines in every device because they knew ambient intelligence couldn't rely on a fragile network ping. It had to be local, and it had to be private by default.

With modern silicon and quantized models like Qwen 2.5 1.5B, we finally have the compute to actually do it. You have server-class hardware resting in your user's palm.

Implementing it shouldn't require a machine learning background. It should look like this:

import Onde
 
let engine = OndeChatEngine()
 
// The model loads into local memory. No network connection required.
try await engine.loadDefaultModel(
    systemPrompt: "You are a private, on-device assistant.",
    sampling: nil
)
 
// The user's input never leaves the silicon.
let response = try await engine.sendMessage(
    message: userInput  
)

The choice

You can keep building AI the old way. You can write the massive privacy policies, apologize for the network latency, and cross your fingers that your cloud provider doesn't change their data retention rules next week.

Or you can just use the hardware your users already paid for. You can respect their data and make privacy a foundational feature of your product, woven directly into the code.

It's honestly just a better way to build.