A local AI model improves the privacy boundary by removing the need to send user content to a remote inference server. It does not prove that the app is private. The same app may still contact model hosts, analytics systems, purchase services, crash reporters, account servers, backup services, or user-selected sharing destinations. Audit the whole data flow, not the location of one model.
Start with a data inventory
List user data by type rather than writing a generic “we value privacy” statement. For an AI app, the inventory may include:
- prompts and generated output;
- photos and extracted text;
- audio and transcripts;
- health or location inputs;
- imported documents and local indexes;
- model selections and settings;
- purchase and entitlement state;
- diagnostics and crash context;
- exported files and clipboard content.
For each type, record where it is created, where it is stored, which process can read it, when it is deleted, whether it participates in backup, and every route by which it can cross the device boundary.
The inventory should live close to the code and be reviewed when a feature adds a dependency. A privacy page that is disconnected from implementation becomes stale precisely when it matters most.
Draw two separate boundaries
On-device AI describes where inference executes. Cloud AI describes inference that receives the input on remote infrastructure. That distinction defines the inference boundary, but an application also has a broader network boundary.
Draw both:
- Inference boundary: what enters the model and where the model runs.
- Application boundary: every request, service, backup, export, and operating-system handoff.
An app can have local inference and remote sync. It can have local transcription and cloud diagnostics. It can have no vendor server but still share through a system intent when the user taps Export. These are different behaviors and should be described separately.
Enumerate network calls by purpose
Cove’s current public boundary distinguishes local user-content processing from model download, Google Play purchase verification, optional newsletter signup, and optional anonymous crash reporting. Its network audit presents those categories separately instead of treating “the app connects to the internet” as one undifferentiated fact.
Use the same structure for any local AI product:
| Field | What to disclose |
|---|---|
| Purpose | Why the request exists |
| Destination | Host and service owner |
| Trigger | Startup, explicit action, schedule, or failure |
| Data | Exact fields transmitted |
| User content | Whether prompt, image, audio, or document content is included |
| Control | Required, optional, or disableable |
| Retention | What the receiver keeps, if known and applicable |
Avoid saying “anonymous” without describing the fields. A request may exclude user content but still contain device or event metadata. Readers should be able to distinguish those cases.
Verify behavior instead of trusting copy
Test the complete feature in airplane mode. If the core task is advertised as offline, it should complete from user input to saved result without a hidden remote dependency after required artifacts are already present.
Then restore connectivity and capture traffic while repeating the same task. Compare idle, first launch, model download, purchase check, optional diagnostics, newsletter signup, and export. Record the app version and environment with the capture.
Network capture does not explain encrypted payloads by itself, so combine it with code review and documented request schemas. The goal is an evidence chain:
feature action -> code path -> destination -> request fields -> public disclosureAny link missing from that chain becomes a review item.
Permissions are not proof of transmission
Android’s official privacy and security guidance treats permissions, data access, storage, and user control as application responsibilities. Those responsibilities remain even when inference happens locally.
Camera, microphone, storage, contacts, and location permissions tell you what an app can access. They do not tell you whether the app sends that data anywhere. Network permission tells you the app can connect, not what it transmits.
Review permissions and traffic together. Ask whether each permission is required for the current feature, requested at the moment of need, and explained in user language. Remove permissions that were added for abandoned code paths.
A privacy-sensitive product should degrade visibly when a permission is denied. It should not substitute a remote path without telling the user.
Logs, crashes, and developer convenience
Sensitive data often escapes through debugging rather than inference. Prompts, transcripts, file paths, OCR output, or generated responses may be included in logs and exceptions during development. A crash reporter can then transmit the exception context.
Adopt a logging policy:
- no raw user content in production logs;
- structured error categories instead of captured payloads;
- redacted identifiers where correlation is necessary;
- debug logging disabled in release builds;
- review of third-party SDK defaults;
- opt-in diagnostics when the product promise requires it.
Test failure paths, not just successful inference. The error handler is where developers are most tempted to dump the entire request for convenience.
Storage, backup, clipboard, and sharing
Local data can leave through system services without an application server. Device backups may copy app data. Clipboard content can be read or surfaced by the operating system and other applications subject to platform behavior. Share sheets intentionally hand data to another app selected by the user.
Define these as separate user actions. A copy button should say what is copied. An export should preview the artifact. A delete action should remove source content and derived content such as transcripts, embeddings, indexes, thumbnails, and cached results.
Do not claim “data never leaves the phone” if system backup remains enabled for that data. Use narrower language that matches the implementation, such as “Cove does not upload your recording for inference.”
Model delivery and updates
Large local models may be downloaded separately from the application. Document the model host, artifact identity, update trigger, expected storage requirement, integrity checks, and behavior when download fails.
The model download request is not the same as sending user content for inference. Keeping those routes separate helps users understand why an offline app may need a connection once during setup.
Privacy release checklist
- Inventory every user-content and metadata type.
- Draw inference and application network boundaries separately.
- Enumerate every outbound destination and trigger.
- Verify the core task in airplane mode.
- Capture traffic for idle, setup, inference, purchase, diagnostics, and export.
- Remove raw user content from production logs.
- Review automatic backup behavior.
- Make clipboard and sharing explicit actions.
- Ensure deletion covers derived artifacts.
- Review SDK defaults after dependency upgrades.
- Update public disclosures in the same change as network behavior.
Cove’s current evidence boundary
Cove is keeping product status separate from privacy architecture. As observed on 2026-09-16, the public download page still presents notification calls to action and no public APK or Google Play link. The security whitepaper and network audit therefore describe implemented boundaries without treating unreleased distribution as user adoption evidence.
Continue with on-device AI vs cloud AI for architecture selection and on-device translation privacy for a task-specific example.
Last reviewed: 2026-09-16.