Private vs Privacy: Why the Difference Matters in the AI Era

Private vs Privacy: Why the Difference Matters in the AI Era

People often say an AI tool is “private” when they really mean something narrower: the tool has a private mode, a paid plan, or a promise not to train on prompts. Those details can matter, but privacy is a system property rather than a label on a button.

Private from whom?

Start by naming the threat and the data flow. Is the data private from other users, the provider's employees, a browser extension, a cloud administrator, or a future dataset? A company can keep prompts out of model training and still retain logs for abuse monitoring or billing.

A useful map is:

~text
input → browser/app → provider API → logs/storage → model or human review
~

Each arrow is a place to ask what is collected, for how long, who can access it, and whether deletion is real.

Confidentiality is not anonymity

Encryption in transit protects a connection while it moves. Encryption at rest protects stored data from some forms of access. Neither guarantees that an authorised service cannot read the plaintext in order to process a request.

Removing a name does not always anonymise a record. A code snippet, timestamp, project identifier, or rare incident can identify a person when combined with other data. Use data minimisation and redact secrets before they reach a model.

A practical checklist for an AI tool

Before pasting private material, check:

1. whether prompts and outputs are retained;
2. whether they are used for training or product improvement;
3. where data is processed and stored;
4. who can access logs and support tickets;
5. how deletion, export, and account closure work;
6. which subprocessors receive the data;
7. whether an administrator can inspect workspace content.

If the answer is unclear, treat the tool as unsuitable for secrets, customer data, credentials, or unreleased source code.

Privacy is also a product decision

Collect less by default. Set a retention period. Separate diagnostic logs from user content. Limit staff access. Record a reason for each sensitive field. Give users a way to understand and control the data rather than hiding everything behind a vague “secure” claim.

No checklist makes a service risk-free. The honest statement is narrower: which data is protected, from which party, under which configuration, and for how long?

References

• NIST Privacy Framework
• NIST AI Risk Management Framework
• OWASP: Top 10 for Large Language Model Applications