← Back to selected work
Privacy and routing

Case Study: A Hybrid Local/Cloud AI Router With a Code-Enforced Data-Sovereignty Gate

A fail-to-local router with a deterministic redaction gate and code-enforced outbound boundary.

Anonymized portfolio piece. This describes a local-first personal AI operating system I built and run daily. All identifying detail about what the system is used for is removed; the architecture, mechanism, and validation figures are real.


The problem

Running every request through a frontier cloud model is the easy default, and the expensive one. Most requests are pure general-knowledge questions that any capable model can answer, but a meaningful share carry proprietary, regulated, or confidential context that should never leave your own hardware. Treat every request the same way and you either overpay for cloud inference on work a cheap local model handles fine, or you build a system where a careless prompt can leak sensitive data to a third-party API. Most teams solve this with a policy document: a rule that says "do not send sensitive data to the cloud." Policies get read once and violated under deadline pressure. A working boundary has to be enforced in code.

What I built

A router that classifies every incoming request, before it goes anywhere, as either general-knowledge (safe for a cheap external model) or sensitive/proprietary (must stay on local hardware), and routes accordingly. The classifier runs locally, on the request itself, so nothing crosses the boundary just to decide whether it should. The routing posture is fail-to-local: any low classifier confidence, any classifier error, any attachment present, or any ambiguity at all defaults to local, never to cloud. Confidence has to clear a deliberately high bar before a request is ever allowed out.

The actual enforcement does not live in that classifier, though. It lives one layer deeper: a deterministic redaction gate is the single code path in the entire system allowed to emit anything externally. Every field in every outbound payload passes through an allowlist; anything not explicitly recognized as safe metadata gets tagged and stripped rather than passed through. If a new, unrecognized data field ever gets added upstream, it redacts by default instead of leaking by default. The gate also runs a self-test on its own output before emitting anything, and refuses to emit at all if any substantive source content survived. A buggy version of this gate fails safe.

The result

Cost drops because only genuinely general-knowledge requests incur cloud-model cost; everything sensitive runs on cheaper local inference instead. The privacy boundary was validated against the full production transcript history: 1,821 transcripts and 19,124 individual events, zero confirmed leaks. Because escalation runs through exactly one code path with no parallel route around it, there is no bypass to audit for. The gate either holds for every request or it does not run at all.

Why it transfers

The pattern generalizes past any single system:

  1. Classify before you route, using a model cheap and local enough that the classification itself never becomes a new leak surface.
  2. Default to the safe side on doubt. Low confidence, missing signal, or any anomaly degrades to the conservative path automatically, before anyone has to notice.
  3. Enforce the boundary in one place, in code, with a fail-closed allowlist and a self-check, so the guarantee does not depend on every future contributor remembering a rule.

That is the shape of AI cost savings that keeps you in control of your own data: cheap where it is safe, private where it matters, and a boundary that holds because the code refuses to cross it.


Josiah Bujanda. AI & Construction Technology Consultant. Mechanical engineer with more than ten years in commercial lighting controls and Division 26 electrical, plus hands-on architecture of production AI and automation systems.