Privacy and data rules

Map data from source to deletion:

1. Collection: Where did the data originate, and what were people told?
2. Input: What enters the model directly, through files, logs, retrieval, or connected tools?
3. Processing: What does the system infer, transform, classify, or generate?
4. Sharing: Which model provider, cloud host, vendor, employee, or downstream system receives it?
5. Storage: Where are prompts, outputs, embeddings, backups, and logs kept?
6. Reuse: Can data be used for analytics, evaluation, abuse monitoring, or model improvement?
7. Deletion: When is each copy removed, and can a request be honored across systems?

Teams often map only the prompt and miss retrieved documents, telemetry, human-review queues, cached outputs, and vendor support access. Those are part of the system too.

Personal data can include obvious identifiers such as a name or email address, but also device identifiers, location, employee IDs, voice recordings, and combinations that can single someone out. Inferences can matter as much as raw fields. A model that predicts health status, political interest, or financial stress may create sensitive information even when those labels were not collected directly.

Sensitivity depends on context and jurisdiction. Health, biometric, financial, precise-location, communications, and children’s data commonly receive special attention. “Publicly available” does not always mean unrestricted. Data visible on a website may still carry terms, expectations, intellectual-property interests, or legal protections.

De-identification can reduce risk, but deleting names is not always enough. Rare job titles, dates, locations, or free-text stories can re-identify a person. Test whether records can be linked back when combined with other information.

A durable privacy habit is to state the purpose narrowly. “Use data for AI” is not a purpose. “Summarize support tickets so assigned agents can respond” is clearer. The team can then ask whether every field is necessary.

Data minimization means using the least data reasonably needed. Practical techniques include:

• remove identifiers before sending text to a model;
• retrieve only the relevant passage instead of an entire personnel file;
• use synthetic or approved test data during development;
• block unsupported file types or sensitive fields;
• shorten log retention and restrict log access;
• keep production data out of experimentation accounts;
• choose a provider setting that prevents training reuse when required.

Minimization also improves security and sometimes quality. Extra context can distract a model and expose unrelated people.

An organization should know who decides the processing purpose and who acts on instructions. Legal labels vary, but operational questions remain useful: Who can change the purpose? Who chooses retention? Can the vendor use data for its own goals? Which subcontractors are involved? Where is data processed? What happens when the contract ends?

Vendor review should examine evidence, not slogans. Check contractual terms, security controls, incident notice, deletion behavior, data-location options, model-improvement settings, audit information, and support access. A “zero retention” setting may apply to one endpoint but not abuse logs or optional features. Confirm the exact service configuration.

Depending on applicable law, people may have rights to access, correct, delete, restrict, or object to certain processing. Even where a specific right does not apply, correction and complaint paths are good operational controls.

AI complicates response handling. If incorrect data entered a retrieval index, deleting the source document may not immediately remove cached chunks or derived records. If a generated claim was copied into a case file, the team must correct the consequential record, not merely rerun the model.

Design a route from a person’s request to all relevant systems. Assign an owner and test the route before scale.

Fairness testing may require demographic data that a production workflow otherwise would not need. Refusing to collect any such data can make disparities invisible; collecting it casually creates privacy and misuse risks. A proportionate design may separate an access-controlled evaluation dataset, limit its purpose and retention, use aggregation, and prevent the sensitive attributes from driving individual decisions.

There is no universal answer. Document why the data is needed, who can use it, and what safer alternatives were considered.