Treat privacy as a lifecycle concern
NIST's Generative AI profile is a voluntary resource for incorporating trustworthiness considerations into AI design, development, use, and evaluation. It is useful as a risk-management starting point, not a certification that a particular application is compliant.
For a product team, privacy work begins with knowing where data goes. A single assistant request may pass through the browser, application server, retrieval service, model provider, telemetry system, and support tooling. Reviewing only the visible chat interface misses most of that path.
Technical foundation: NIST: Generative AI risk management profile
Map the minimum information needed
For each step, list the fields received, why they are necessary, where they are stored, and who can access them. A product-description assistant may need public feature information but not buyer addresses. A support assistant may need an order status without needing a full payment record.
Remove unnecessary fields before sending a request. Redaction should happen at a reliable boundary, not as a request asking the model to ignore sensitive values already supplied. If identifiers can be replaced with task-specific references, preserve the mapping only in the application that needs it.
Review storage beyond the database
Prompts and responses can appear in debugging logs, traces, error reports, evaluation fixtures, and cached results. Decide which content may be recorded and for how long. Prefer operational metadata when it is enough to diagnose the problem. Limit access to any retained examples containing personal information.
Retrieval indexes and embeddings also belong in the inventory. They should not be assumed anonymous simply because they are numerical or derived. When a source is deleted or access is revoked, test the corresponding behavior in indexes, caches, and downstream views.
Make promises you can verify
Provider retention, training use, regional processing, and deletion behavior depend on the actual service and agreement. Confirm those terms for the configured account rather than copying a generic privacy statement. Document subprocessors and escalation contacts as part of the operational review.
Tell users what the feature sends and retains in understandable language. For regulated or sensitive uses, obtain qualified privacy and legal review for the relevant context. An engineering checklist helps prepare that review; it does not replace jurisdiction-specific obligations or contractual requirements.
Questions to answer before launch
- Which fields are essential for the task?
- Which systems receive or retain those fields?
- Can a user or administrator revoke access and verify the result?
- Are logs, indexes, caches, and test fixtures included in retention rules?
- Do the product's privacy statements match the deployed configuration?
