Habit guide

AI Assistant Privacy Checklist

Use this checklist to evaluate AI assistant permissions, processors, encryption, isolation, action controls, retention and deletion claims.

“Private” is a design claim to investigate, not a conclusion to accept. Ask which sources the assistant reads, where data is stored, which processors receive it, how one customer is isolated from another, who may authorise actions, and what happens when access is revoked.

Checklist 01

Map the full data path.

A connected assistant can involve the source provider, application services, databases, queues, observability tools and AI processors.

List each system that can receive content or metadata. Record what enters, why it is needed, where it is processed, how long it remains and which organisation operates that part of the path.

  • Which calendars, mailboxes, contacts, documents or conversations can be read?
  • Is raw content copied, selectively retrieved or transformed into another record?
  • Which sub-processors can receive prompts, attachments, embeddings or logs?
  • Do processing and storage locations differ?

Checklist 02

Inspect permissions and revocation.

The product should make the requested scope and the way back out understandable before connection.

Purpose

Can the product explain why each permission is required for a user-visible capability?

Scope

Is access limited to supported sources and operations, or does the explanation rely on broad “all your data” language?

Revocation

Can the user pause or disconnect access, and is the effect on future access distinct from deletion of retained records?

Checklist 03

Separate encryption from isolation.

Encryption protects data in a particular state. Tenant or principal isolation controls which authenticated path may reach it.

Ask about transport encryption, encryption at rest and field-level encryption separately. Ask who controls the keys and which services can decrypt data. Do not treat “encrypted” as evidence of end-to-end encryption unless only the intended endpoints can access plaintext.

Then test the customer boundary: application scoping, database row policies, background jobs, caches, credentials and memory retrieval should all carry the same customer or principal context. Encryption does not prevent a correctly decrypted record from being returned through the wrong tenant path.

Checklist 04

Ask AI providers about secondary use.

A model provider’s answer may vary by product, account type, contract, region and settings.

Training and improvement

Does the applicable service use submitted content to train or improve models, and can that use be disabled or contractually excluded?

Retention

How long may prompts, responses, files and abuse-monitoring records remain, and what exceptions apply?

Sub-processors and regions

Which entities and locations may process the selected context, including safety and observability systems?

Checklist 05

Treat action authority as a privacy control.

The ability to send, change or delete on a person’s behalf can be as consequential as access to the source data.

  • Does the interface distinguish drafting from executing?
  • Can a user inspect the target, payload and intended change before approval?
  • Is any standing authorisation off by default and limited to an eligible category?
  • Do destructive operations remain review-gated?
  • Is there a useful history of proposals, decisions and outcomes?

Checklist 06

Make retention, deletion and failure states testable.

Credible controls explain the process and its limits instead of promising that every copy disappears instantly.

Ask which records are deleted, anonymised or retained after disconnection, account closure or a rights request. Look for time frames, backup handling, legal exceptions and a way to confirm that the request has entered the process.

Also examine failure transparency. If a source is unavailable, the assistant should not present an incomplete brief as complete. If an action fails, the product should not imply it succeeded. Accurate state is part of keeping people in control.

Questions

Privacy terms to make precise.

What does “private AI assistant” mean?
It should describe explicit permissions, known processor paths, isolation, protected storage, action controls and usable revocation—not imply that data never leaves a device.
Are encryption at rest and end-to-end encryption the same?
No. Encryption at rest protects stored data. End-to-end encryption additionally prevents intermediary services from accessing plaintext.
Which actions are safe to automate?
Only bounded, reversible categories with clear targets and an explicit user authorisation should be considered. Destructive or ambiguous actions need a review boundary.
What makes a deletion claim credible?
A defined request path, stated scope, expected timing, backup treatment, exceptions and confirmation are more credible than an absolute “deleted everywhere instantly” promise.
Does a provider train on my data?
Check the exact product, plan, contract and settings in use. The answer cannot safely be inferred from the model name alone.

Habit today

Compare the checklist with current product details.

The checklist is an evaluation tool, not a claim that any product satisfies every item.

Habit’s security page describes current technical and action-control boundaries. The published Privacy Policy is a legal disclosure that must be kept aligned with the operative product; it is not, by itself, evidence that a technical control works. Read both against the questions above.

See how Habit currently answers these questions
Read Habit’s published Privacy Policy

Keep reading