Privacy by design for personal AI

I've written about the PII problem, the on-prem case, and the redaction-pattern floor enough times that the position should be clear: I don't put sensitive data into public AI. That's a stance. What I want to write down here is the architecture that makes the stance livable, the concrete patterns that make a personal AI useful in 2026 without quietly becoming a leak.

The category arrived sooner than the keynote conversation acknowledges and the privacy story is still mostly told as policy ("we don't train on your data," "enterprise tier is different," "memory is opt-in"). Policy is what you fall back on when architecture didn't do the job. Privacy by design means the architecture does the job and the policy is the cherry on top, not the load-bearing wall.

These are the patterns I've landed on. None of them are novel individually. The combination is what makes a personal AI privacy-respecting in practice rather than in marketing copy.

Local-first as the default placement

The first question for any piece of context, any tool call, any memory write is: does this need to leave the device? Default: no. The on-device model handles it, the on-device tool runs it, the on-device store remembers it. The hosted frontier model gets called when the local model can't, and only with the minimum context the task needs.

Concretely in 2026 that looks like:

• A capable local model (Apple Silicon + MLX, or a Linux box with a decent GPU) doing the routine work, drafting, summarizing, classifying, light reasoning, tool orchestration.
• A frontier hosted model on tap for the hard things, the long-context reasoning, the specialized capability the local model doesn't have.
• A router that decides which one runs, and a default that errs local.

The router is the load-bearing piece. Without it, "local-first" collapses into "local-when-I-remember-to-toggle-it" which is not a real privacy posture. The router needs a policy: by sensitivity tag, by tool, by data class. The defaults need to be conservative.

The redaction layer between local and hosted

When a request does need the hosted model, it goes through a redaction layer first. Names, emails, addresses, account numbers, anything tagged sensitive, replaced with stable placeholders before the request leaves the device. The hosted model reasons over the placeholders. The response comes back, the placeholders rehydrate locally, the user sees the real thing.

This is the pattern I wrote about in the PII redaction piece. A year on, the tooling is more mature: presidio-style detectors plus per-user pattern dictionaries, structured-output contracts that force the model to keep the placeholders intact, deterministic rehydration at the boundary. The principled-user community has converged on this; it works.

The trap is treating redaction as the only privacy primitive. It's necessary and not sufficient. Redaction handles the "minimize what crosses the boundary" job. The other patterns handle the rest.

Scoped access for tools and memory

Personal AI in 2026 is a tool-using AI. It reads your calendar, drafts your email, queries your notes, runs commands. Each of those tools is a privacy surface. The pattern that survives contact with reality:

• Per-tool scoped credentials. The mail tool reads, doesn't send without confirmation. The calendar tool reads one calendar, not all. The shell tool runs in a sandboxed working directory, not the home folder.
• Per-session capability grants. The assistant gets the tools it needs for this session, not the union of every tool it's ever needed.
• Read/write asymmetry. Reads are cheaper to grant than writes. Writes need a confirmation step or a higher trust threshold.

The memory layer follows the same shape. The assistant's memory isn't one undifferentiated bucket; it's tagged by sensitivity, scoped by domain, and the retrieval at inference time pulls only what the current task justifies. Cross-domain leakage, work memory bleeding into personal context, personal context bleeding into a hosted call, is the failure mode the scoping prevents.

Audit trails that the user actually reads

Every cross-boundary event gets logged. What was sent, where it went, what came back, what tool was called with what arguments, what got written to memory. Local file, append-only, queryable.

The point isn't compliance theater. The point is that the user can answer the question "what did my AI do today, and what did it expose?" without trusting the vendor's dashboard. If the audit log lives on-device and the user controls it, the trust model is verifiable rather than asserted.

In practice the log gets read rarely. The discipline of producing it correctly is what matters, it forces the architecture to be honest about what crosses what boundary, and it gives you the evidence when something goes wrong.

Deliberate sync, not ambient sync

Multi-device personal AI is the reality now. The phone, the laptop, the desktop, maybe a home server. The naive pattern is: sync everything everywhere, always. The privacy-respecting pattern is: sync deliberately, with the user's knowledge, with the minimum surface.

What I do:

• A primary device that owns the standard memory. The desktop, in my case. Other devices are clients.
• End-to-end encrypted sync for the subset of memory that needs to be available on multiple devices, with the keys held only on the user's devices.
• Sensitivity-tagged sync policies. Routine context syncs everywhere. Sensitive context stays on the primary device and gets accessed remotely only when the user explicitly asks for it.
• No silent cloud backup of memory. If memory backs up, it backs up encrypted, to storage the user controls.

The "ambient sync everywhere" pattern is convenient and it's the pattern that makes privacy-by-design impossible. The deliberate-sync pattern costs a small amount of UX friction and recovers the architectural property that matters: the user knows where their context is.

The hosted-AI carveout

I'm not absolutist. Hosted frontier models are useful, and there's a class of work where they're the right tool. The carveout pattern:

• Hosted model gets called via the router, with redacted input, scoped tool access, and the audit log running.
• The vendor relationship is via the privacy-respecting tier (enterprise / API with no-training contractually committed).
• Memory written from hosted-model conversations is reviewed before it lands in the persistent store. The hosted model can suggest a memory; the local pipeline decides whether to keep it.

This isn't perfect, contractual privacy is weaker than architectural privacy. It's the realistic carveout for the tasks the local model can't do. The discipline is keeping the carveout small and visible.

What this isn't

A few things this pattern set is not, to be clear:

• Not air-gapped. The privacy goal is "user controls what crosses each boundary," not "nothing ever crosses any boundary." The latter is a different product (and a worse one for most people).
• Not anti-hosted. The frontier hosted models are part of the architecture. They're the extra capability, not the foundation. The foundation is local.
• Not a product you can buy in 2026. The bridge product I keep writing about (the consumer-friendly principled-personal-AI) still doesn't exist as a category. These patterns are what the user community builds by hand. The product version is downstream of the patterns becoming common.
• Not a guarantee. Architecture reduces the surface; it doesn't eliminate it. The audit trail catches what the architecture missed; the user's judgment catches what the audit trail surfaces. Defense in depth is the only honest framing.

The shape of the stance

Privacy by design for personal AI in 2026 is a small set of architectural commitments, local-first by default, redact at the boundary, scope every tool and every memory, log every crossing, sync deliberately, carve out the hosted use carefully, combined with the discipline to actually build them rather than gesturing at them.

The discipline is the hard part. The patterns are well-known to the community now; the gap is between knowing them and running them. I run them because I've decided the trade-off is worth it. The sensitive data stays out of the public AI. The useful AI stays useful. The architecture is what makes both true at once.

When the bridge product ships (Apple's, or someone else's) the test of whether it's the real thing or the marketing thing will be whether these patterns are baked in or bolted on. Bolted-on privacy is policy. Baked-in privacy is design. The category needs the second to be the durable one I bet on.

Until then: the patterns above. Not novel. Not glamorous. The right ones.