PRIVACY BY DESIGN

Privacy by architecture, not by promise

A privacy statement describes intent. Architecture determines what can actually happen to data.

Enterprise AI changes the privacy conversation because it makes information easier to find, combine, summarize, and act on. A user may be authorized to open two systems separately but not to infer a sensitive relationship across both. That means privacy cannot live only in legal language or an annual review. It must be expressed in the data paths, permissions, retrieval logic, and records of the system.

Begin with purpose and flow

Document what information enters the capability, why it is needed, where it is processed, who can receive an answer, and how long each artifact remains. Include prompts, retrieved passages, embeddings, generated answers, feedback, logs, backups, and support records—not just the original source files. A useful map follows information from collection to deletion and names an accountable owner at every boundary.

Reduce the privacy blast radius

Collect and expose only what the use case needs. Keep retrieval scoped to the user’s existing authorization. Separate tenants and high-sensitivity domains. Use short retention where operationally possible, and design deletion so it reaches derivative stores. Private deployment can reduce exposure, but it does not replace identity controls, minimization, or monitoring.

Make privacy testable

Translate policy into acceptance criteria: unauthorized content never appears in retrieval; sensitive fields are masked in lower environments; administrative access is time-bound; exports are logged; retention jobs produce evidence. The strongest program links these tests to release approval and repeats them when data sources, models, or workflows change.

Reference: NIST Privacy Framework, a voluntary enterprise risk-management tool for identifying and managing privacy risk.