Offline Health Data Boundary for AI Apps

Direct answer

A health-oriented AI feature needs two separate reviews: what it does with sensitive information and what users may infer from its output. A local model does not by itself prove that data stays only in app storage, that backups are excluded, or that a suggestion is clinically correct. `PRIVACY-01` states the local-inference boundary, while `COVE-STATUS-03` records that the project's health module has real-device guardrail validation still pending in its checked status. The local product specification separately requires disclaimers, a clinician boundary, and emergency escalation. Keep these statements distinct and current; do not turn source-code readiness into clinical validation or regulatory approval. Begin by mapping inputs and outputs: symptoms, severity selections, free text, images, health history, generated explanation, triage category, emergency recommendation, logs, analytics, backup, export, and support. For every field state why it is needed, whether the user can skip it, where it is stored, which component reads it, and whether it leaves the device. A local inference route only covers the inference stage. Permissions, crash reporting, purchase checks, model downloads, and optional services require separate evidence. Android privacy guidance treats access, storage, and user control as application responsibilities, so a “local AI” badge cannot replace the data map. Keep the user-facing scope modest. Distinguish general educational information, symptom organization, and clinician-facing decision support rather than presenting them as interchangeable. Avoid diagnosis, treatment direction, or claims that a generated urgency category is medically validated unless the intended use and evidence have been reviewed by qualified experts. Preserve uncertainty, explain that generated suggestions can be wrong, and provide a route to professional care. For emergency language, give the product's defined instruction to contact local emergency services; do not ask a model to decide whether a real emergency merits help. Design safe failures. Missing permission, incomplete information, model unavailable, malformed output, and network loss should not be converted into reassurance. Show when no assessment was completed, retain only state allowed by the user's choice, and offer clear next steps. A cloud fallback must never be silent: identify the route and data before transfer and allow the person to decline. If no route is available, say so instead of fabricating an answer. Do not cache health content in logs, screenshots, notification text, or analytics by default. Test with synthetic or approved de-identified cases, not unreviewed patient content. Include boundary prompts, contradictory symptoms, missing data, urgent wording, unsupported requests, prompt injection, restart, cancellation, and permissions revoked mid-task. Assert not only expected UI copy but that dangerous generated instructions are blocked or accompanied by the required limits. A source specification says the app should preserve disclaimers; verify the exact strings and all result paths. Recheck after prompt or model changes. Any clinical-quality evaluation needs a separate protocol, representative cases, qualified review, and raw evidence; a unit test or offline run is not that validation. Finally, write privacy copy from implementation and service configuration. Describe collected inputs, optionality, local storage, backup, export, deletion, diagnostics, and any remote route without conflating them. The FTC's mobile-health guidance encourages data minimization and limiting access; Android's data-use guidance requires developers to understand data access by the app and included libraries. Neither source determines a particular app's legal status. Legal obligations vary by function and jurisdiction, so this page is a product-engineering checklist, not legal advice. Record unresolved questions and keep the page noindex until health-specific facts, sources, and review requirements pass the site's editorial and technical gates.

A symptom assistant receives incomplete information

A user chooses a symptom and severity but leaves duration blank. The local model returns a confident explanation; the app also has an optional help route that can send information remotely.

Decision

Treat missing duration as missing, avoid presenting a generated explanation as diagnosis, preserve emergency guidance, and require separate consent before any remote route.

Expected outcome

The user sees the limitation and next step, and the app does not imply clinical validation or transmit health data silently.

Evidence to collect

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

• Content and network inventory
• Safety refusal tests
• Deletion verification

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Inventory sensitive fields and derived data. Map user selections, free text, media, generated result, triage status, logs, analytics, backup, and exports to owners and storage locations. Mark which fields are optional and which are sent remotely, if any.
2. Write the intended-use boundary. State whether the feature organizes information, gives general education, or supports a clinical workflow. Remove unsupported diagnosis and treatment language; route emergency statements through reviewed deterministic product copy.
3. Specify incomplete and unsafe outputs. Define behavior for missing inputs, contradictory information, malformed generation, unavailable model, and urgent language. Do not convert uncertainty or failure into reassurance.
4. Gate every route and user-data action. Test local processing, optional cloud route, export, diagnostics, and deletion separately. Before any transfer identify data and recipient and let the user decline; never let a model decide consent.
5. Run safety and privacy fixtures. Use approved synthetic cases for urgent, ambiguous, adversarial, and incomplete prompts; verify disclaimer and escalation on every result path, plus no content in logs and recovery after permission change.

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

Acceptance criteria

• The data map covers sensitive inputs, generated outputs, derivatives, storage, backup, export, diagnostics, and each network route.
• Missing, urgent, contradictory, unsupported, or malformed cases preserve reviewed safety copy and never create unsupported diagnosis or reassurance.
• Privacy disclosure matches implementation, optional remote transfer requires an explicit choice, and health-specific review status is accurately recorded.

Decision table

Failure patterns to prevent

• Medical performance claims
• Hidden cloud fallback

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

• Cove product roadmap
• FTC Mobile Health App Developers: Best Practices
• Android: Declare your app data use
• FDA Clinical Decision Support Software guidance

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

Frequently asked questions