Private AI Privacy Checklist: 25 Questions Before You Trust an App

How to use this checklist

Use the questions before entering private text, not after. Find answers in the current privacy notice, technical documentation, app-store disclosure, settings, and observable behavior. Write down the app version and date because an update can add a model provider, analytics service, connected tool, or new retention policy.

Do not convert the results into a universal score. One missing feature may be decisive for your situation: a journalist may care most about local files and exports, a traveler about offline reopening, and an organization about approved contracts and administrator controls. NIST’s Generative AI Profile recommends contextual risk management across privacy, security, transparency, validity, and other trustworthiness characteristics. The checklist is a decision aid, not a certification. [1]

Use synthetic prompts and harmless sample files during testing. If a product does not clearly document a boundary, treat that uncertainty as information and do not supply data you are not prepared to disclose.

1–4. Identity, business model, and claim precision

Privacy starts with accountability. A named publisher, support route, effective date, and change process make a claim easier to challenge. The business model matters too: paid, free, open-source, advertising-supported, and enterprise products can all be responsible, but users should know what funds the service and which party controls it.

The US Federal Trade Commission has warned businesses to keep AI claims supported and avoid exaggerating what a product can do. Apply the same discipline to privacy language: “private,” “anonymous,” “encrypted,” and “on-device” should each be tied to a defined feature and evidence. [2]

1. Who publishes the app, and is there a working privacy or security contact?
2. How is the product funded, and does it contain advertising, subscriptions, usage charges, or paid model access?
3. Does the privacy notice have an effective date and a process for material changes?
4. Are claims scoped to named features, or does the product rely on undefined words such as “fully private”?

5–8. Accounts, inference, and data flow

A no-account product reduces signup data but says nothing by itself about inference. “Local history” describes where a transcript is stored, not where a response is generated. Ask for an action-level map that separates ordinary chat from connected tools.

An on-device reference implementation such as Google AI Edge Gallery states that inference happens on the device and that internet is not required after a model is available. That wording usefully distinguishes inference from installation and model delivery. Expect similarly precise language from any local AI product. [3]

1. Is an account required, optional, or absent, and what identifiers exist without one?
2. Where does the model run during an ordinary text chat?
3. Do prompts, responses, documents, images, audio, or retrieved passages leave the device?
4. Which actions change the normal boundary, for example search, sync, sharing, reporting, or remote models?

Evidence strength for common privacy claims

9–12. Network requests and third parties

A local AI app can legitimately connect for software and model delivery without uploading prompts. The important distinction is content versus ordinary request metadata. A hosting provider or model publisher generally sees an IP address, time, user agent, and requested file. A web-search provider must receive the confirmed query to perform the search. Those recipients and purposes should be named.

Check defaults as carefully as controls. Diagnostics that can contain prompts, filenames, model output, stack traces, or device identifiers need a clear data inventory and scrub rules. Consent offered after an upload is not consent for that upload.

1. Which domains or companies receive app, model, OCR, embedding, or other artifact requests?
2. Are analytics, diagnostics, crash reports, or remote configuration present, and are they enabled by default?
3. Does every content-bearing optional action name the recipient and show what will be sent before confirmation?
4. Are third-party terms linked at the point where their feature is enabled?

13–16. Local storage, encryption, and device permissions

Keeping data local transfers responsibility to the device. Find out whether the app protects chat records, documents, retrieval indexes, memories, credentials, and exports, not just one database. Ask where keys live, what an unlocked session exposes, and whether a provider can recover a forgotten passphrase.

Android Keystore can keep cryptographic key material out of the application process and, on supported devices and configurations, bind keys to secure hardware. Its presence is useful but not a complete security claim: the app still has to encrypt the right data, authenticate safely, handle backups, and protect content while in use. [4]

Permissions should follow the invoked feature. A text chatbot does not automatically need contacts, precise location, or a microphone. Camera and file permissions can be reasonable for image and document features, but the interface should explain when processing is local and whether selecting a file triggers any upload.

1. Which local records and files are encrypted, and which artifacts, such as public model weights, are not?
2. How are encryption keys protected, and can the publisher recover a lost passphrase?
3. What remains readable while the app is unlocked or running in the background?
4. Are camera, file, microphone, notification, location, and other permissions requested only when needed?

17–20. Retention, deletion, exports, and backups

Deletion must follow the data. Removing a chat should address its branches, attachments, local indexes, memories derived from it, and queued operations. Removing local data cannot delete a remote report unless the product retains a credential or another verified way to identify that report. Conversely, a provider cannot remotely erase a local vault it never hosted.

Browser storage is not an immortal database. Official PWA guidance notes that offline data can use Cache Storage and IndexedDB, while users remain in control and storage may be removed. Persistent storage reduces eviction risk but does not replace a backup. An honest local app explains both its privacy advantage and this durability limit. [5]

1. Can you inspect, correct, export, and delete chats, files, memories, credentials, and downloaded models?
2. If any content is stored remotely, what is the retention period and how is early deletion requested and verified?
3. What exactly is included in an export or backup, and is it encrypted with a separate passphrase?
4. What happens if the browser clears storage, the phone is lost, or the vault passphrase is forgotten?

21–23. Documents, retrieval, and hostile content

Document Q&A introduces a second kind of risk. A local file may contain instructions crafted to manipulate the model, including hidden or indirect prompt injection. OWASP documents attacks in which malicious content in files, images, or retrieval sources changes model behavior or attempts to expose sensitive information. Local processing prevents a cloud upload only if the feature is genuinely local; it does not make the content trustworthy. [6]

Prefer tools that preserve source provenance, clearly distinguish retrieved text from trusted system instructions, limit tool permissions, and let you inspect citations. Do not give a document-reading assistant broad external actions merely because the document itself is private.

1. Are documents, OCR, embeddings, indexes, and citations processed and stored under the stated privacy boundary?
2. Does the product treat document and retrieved content as untrusted input and preserve source locations?
3. Can a document-triggered instruction cause a network request, tool action, or disclosure without a separate confirmation?

24–25. Accuracy, safety, and organizational approval

Privacy is not accuracy. A small on-device model can produce plausible but false text, outdated information, biased suggestions, unsafe instructions, or fabricated citations. A larger cloud model can do the same. The product should describe these limitations and avoid presenting private inference as a substitute for medical, legal, financial, safety, or other qualified advice.

Personal control is also not organizational permission. If information belongs to an employer, client, patient, student, or research participant, use only systems approved for that data. A no-account app on a personal phone may conflict with policy even when its technical architecture is strong.

1. Does the product state model limitations and encourage verification for consequential decisions?
2. Are you actually authorized to process this information on this device and in this app?

Applying the checklist to CuriousLM

CuriousLM’s normal-use boundary is explicit: ordinary chat does not require an account, CuriousLM-operated inference server, or hosted conversation storage. Chats, projects, approved memories, documents, images, extracted text, OCR results, indexes, citations, and model inference remain on the device. The PWA protects private structured records and files in a local encrypted vault; Android uses encrypted native storage protected by Android Keystore and device authentication. [7]

The stated network exceptions are app and model delivery; a Tavily search after the user provides a key, previews the query, and confirms; and a response report after the user previews exact excerpts and an optional comment and confirms. Delivery hosts receive ordinary request metadata, not prompt and response text. Reports include product/runtime versions and a random idempotency key but exclude a stable device identifier, API key, complete conversation, and unrelated diagnostics. Diagnostics are off by default. [7]

The notice also states the local trade-off. CuriousLM cannot recover a vault or backup passphrase. Browser or operating-system storage can be removed, and devices can be lost. Optional accepted response reports are scheduled for deletion after 30 days and have an early-deletion route; most other content exists only locally and must be deleted in the app, by clearing site data, or by uninstalling. [7]

This is the right level of claim to test: normal chat should work with the selected model offline after setup; setup and model delivery should produce expected requests; and Tavily or reporting should not receive content before the separate preview and confirmation. Results should always name the version, platform, action, and date.

Red flags and good signs

A strong privacy posture is usually specific and a little unglamorous. It identifies exceptions, explains failure and recovery, and distinguishes security properties. Treat certainty without evidence as a warning.

Fast signals during an initial review