Consent Design for Hybrid Local and Cloud AI

Direct answer

Consent for a hybrid AI feature must describe the route that is about to be used, the data crossing the device boundary, the recipient or service category, and what the app will do if the person declines. A general statement that “AI may use cloud services” is too broad to support a particular transfer. The architecture fact `ARCH-02` says a hybrid design can keep some tasks local and send other tasks remotely, but the routing rule and transmitted data must be stated explicitly. `PRIVACY-01` adds that local inference does not establish that other requests are absent. These are design constraints, not product-specific proof that a particular app currently has a cloud route. Begin with a route map per feature. For each task, mark whether the selected path is local, remote, or not yet known; the triggering condition; required content and metadata; whether optional fields can be removed; and the user's visible choice. Treat attachment bytes, extracted text, prompt context, output, account identifiers, and diagnostics as distinct data. Do not use “the document” as one vague field if only a page excerpt is needed. An offline alternative should be described accurately: it may be a different task, a limited local feature, or no available action. Never imply that a local model is ready simply because the network request failed. Place the disclosure before sending, while it can still change the decision. State the destination category, exact selected content, purpose, whether the transfer is optional, and the consequence of declining. Separate a one-time action from a standing preference. A remembered choice should be scoped to a clearly named feature and route, with a way to review or withdraw it; it must not silently authorize newly added data categories. The model may propose an action or route, but application policy and user choice—not model-generated text—control transfer. Design denial as a normal branch. If the person declines, retain the source data locally and do not start the remote request. If the feature cannot continue without the remote capability, say so before the decision and preserve any non-cloud alternative without overstating its capabilities. If connectivity changes after consent, cancel or pause the request according to a documented policy; do not silently retry through a different destination or upload a larger context. A retry after route change is a new transfer decision when the data or recipient changes. Handle ambiguous network state conservatively and show whether a task was not started, cancelled, or completed locally. Validate the implementation with a request ledger and network tests. A route test should verify the expected endpoint, method, payload fields, account context, and absence of excluded source material. Use synthetic documents with unique canary spans to check minimization. Exercise allow, deny, revoke, timeout, airplane mode, network loss during upload, and local fallback states. Network Inspector can show supported libraries but does not cover every client; combine it with call-site review and dependency inventory. The user interface, request payload, and privacy statement must all agree. Consent does not cure an unnecessary transfer, make an inaccurate disclosure acceptable, or prove legal compliance. Product teams still need a purpose limitation, data minimization, security review, retention/deletion rule, and any applicable policy/legal review. A useful record identifies the feature, route version, displayed disclosure, fields sent, user choice, request outcome, and test build—without collecting the content itself as proof. This supports a narrow statement about tested behavior and makes later route changes visible to reviewers.

A local-first assistant offers an optional remote rewrite

A user drafts a paragraph in an offline note feature. The app can rewrite a selected passage remotely, while the local model handles a narrower task. Connectivity is lost while the user is reviewing the choice.

Decision

Show the exact selected passage and remote-service category before upload, make the local alternative explicit, and bind the decision to that request only.

Expected outcome

The app either sends only the approved selection, proceeds on the stated local path, or does not start; a connectivity change does not silently switch routes.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Routing table
• Consent state
• Denied-transfer behavior

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Map routes and data by feature. For every user action, identify route, trigger, recipient, exact fields, optional data, and fallback. Mark unknown implementation behavior as unknown, not “local by default.”
2. Minimize before disclosure. Select only the text or media required for the task. Remove unrelated conversation history, filenames, hidden metadata, and diagnostic context unless each has a justified purpose.
3. Present a request-specific choice. Before the request starts, name the remote route, data subset, purpose, and decline consequence. Keep one-time consent separate from a persistent preference and make the latter reviewable.
4. Implement deny and route-change branches. On decline, do not construct or send the request. On network loss, cancel or pause according to policy; never retry to a different service or enlarge the payload without a fresh disclosure and choice.
5. Test payload and state transitions. Use canary text and verify allow, deny, revoke, timeout, airplane mode, upload interruption, and fallback. Compare UI disclosure, request ledger, inspected traffic, and privacy statement.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The disclosure identifies the active remote route and the exact selected data categories before any request is sent.
• Decline and revoked consent produce no remote request, and a network change cannot silently transfer the task to a different recipient.
• A synthetic canary test proves only selected fields are sent, with route state, user choice, and outcome observable without logging source content.

Decision table

Failure patterns to prevent

• Model-controlled consent
• Sending full source unnecessarily

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• On-device and hybrid routing boundary
• Android security and privacy overview
• Android Studio Network Inspector
• FTC Mobile Health App Interactive Tool (privacy considerations)

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions