Hybrid architectures must pin down which data types never leave

What it is

Real intelligent environments are rarely pure-local or pure-cloud; most are hybrid: some data processed on-device, some sent up. A hybrid's security ceiling is set not by "share of cloud" but by whether data classification is explicit — which types may leave and which never do, written down as an architectural decision rather than improvised per feature.

A hybrid without a classification list is out of control: what gets sent becomes path-dependent — whichever feature ships under deadline exports what it needs — and later nobody can answer "why is this data out there?". An explicit classification compiles the privacy constraint into the architecture, making "never leaves" an enforceable, auditable boundary.

Why it happens

Why classification is the safety core of hybrids:

• Sensitivity differs by orders of magnitude and must be treated by class. Raw audio/video (reconstructs life directly) > derived features (a "person detected" event) > metadata (timestamps, device state) > usage telemetry (crashes, battery). The consequences of leaking each are entirely different — a raw-footage leak is a catastrophe; an event-feature leak is minor harm. Classification draws the boundary along exactly this ordering.
• Explicit classification makes constraints enforceable. Once "this class rides only the local bus" is an architectural rule, it maps to network-level enforcement (isolated segments, firewall defaults) where violating traffic is rejected by infrastructure — the constraint graduates from developer discipline to architectural physics.
• Without classification, export is path-dependent. Feature teams decide data destinations under their own deadline pressure; locally reasonable choices accumulate into a globally unauditable state, and by the time a privacy incident forces a review, the data has scattered beyond recovery.

Hybrids also have a problem of their own — authority of judgement: local and cloud models can disagree on the same input (local says nobody home; cloud says somebody). Which side is authoritative must be fixed in the architecture, or the system's visible behaviour drifts with network conditions and stops being predictable.

Studying it

• Data-flow enumeration audits: enumerate every flow in the hybrid system, tag each by "data type × processing location × retention × reachability", and compare with the claimed policy for a consistency rate — a method that serves research and operations alike.
• Operationalising data minimisation: the privacy-by-design literature treats classification as the main way to turn "minimum necessary" into an enforceable engineering constraint.
• Feature-inversion studies: test the assumption that "derived features are safe" — whether aggregated low-dimensional features still allow inferring sensitive patterns (membership inference, re-identification), calibrating where class boundaries should sit. Such work warns against stopping at a raw-versus-processed dichotomy.

One methodological caution: audit under real deployment configurations — factory defaults, post-tweaks, and post-firmware-update states can all differ; auditing only the shipping state overstates consistency.

Where it stops holding

• Classification is not decided once. Firmware updates can silently redirect flows — a new feature lifts previously local data into the cloud. Keep the scheme versioned: re-run the exfiltration audit after every update and surface changes to the user.
• "Anonymised features" are not zero-risk. Aggregated derived features can still reconstruct individual patterns (rhythm-of-life, presence statistics); when the classification sheet admits a "feature" class, assess it on aggregated risk, not on the harmlessness of a single event.
• Enforcement has real costs. Network-level enforcement (isolation, cut-offs) sacrifices conveniences (remote playback, cross-device sync); honest classification accepts "sensitivity costs convenience" rather than opening back doors for it.

Applying it

• Keep a data classification sheet: rows are data types (raw audio/video, feature events, metadata, telemetry), columns are processing location, retention, and reachability; whether each type "never leaves" is fixed on the sheet.
• Map the sheet to network enforcement: admitted classes ride normal channels; never-leave classes are confined to an isolated segment with firewall-default-deny outbound — do not rely on application code's good behaviour.
• Fix authority of judgement: when local and cloud disagree, decide which side wins (typically: safety-relevant judgements authoritative locally; learning, in the cloud), and make degraded behaviour consistent with that rule.
• Re-audit after firmware updates: any update note mentioning data, cloud, or analytics re-triggers the exfiltration test.
• How to check: sample each class's actual flows against the sheet (per-class capture and compare); the number of mismatches is the architecture's breach surface. Zero is the target; a growing count means new features are routing around the classification.

Related

• Same group: Z6.07.1 Local processing lowers exposure risk but caps capability · Z6.07.2 Cloud processing is more capable but enlarges the transport and storage attack surface · Z6.07.4 The choice of processing location must be visible, not hidden
• Nearby: Z6.05.4 Storage location determines the actual risk of exposure · Z2.05 Visibility of sensing for privacy
• Search terms: data classification · hybrid architecture · data minimisation · privacy by design