Section 1
Purpose limitation is the constraint that bites
Most teams get the lawful basis question roughly right and then break purpose limitation without noticing. You collected support transcripts to resolve support tickets. Using them to fine tune a model, to build a sales scoring system, or to train a summariser is a new purpose, and the original basis does not automatically stretch to cover it. The same applies to retention. Data kept because it might be useful for training later is data kept without a purpose. If a system holds personal data that no current process requires, it is a liability with storage costs attached. The practical test before any new AI use of existing data: could you describe this use to the person it came from, in a sentence, and would they recognise it as consistent with why they gave it to you.
Section 2
Minimise at the prompt, not at the database
Data minimisation is usually implemented at collection and then abandoned at the point of use. A retrieval system that pulls a whole customer record into context when the task needs one field has quietly maximised rather than minimised. Concrete controls that work: strip or tokenise identifiers before the model call and reattach them afterwards in your own system. Pass the field, not the record. Redact free-text notes, which are where the unexpected special category data hides. Keep separate indexes for data with different sensitivity rather than one convenient store of everything. This is also the cheapest privacy control available, because it reduces exposure at every downstream layer at once: logs, caches, vendor retention, and breach scope. The security dimension is covered in [Data Security Concerns in AI Automation](/blog/data-security-concerns-in-ai-automation).
Section 3
Know who is the controller and who is the processor
You decide why and how the data is used, so you are the controller and you carry the accountability. Your AI vendor is typically a processor, and their model provider is a sub-processor. The chain matters because obligations flow down it and information does not flow back up it unless you require that in the contract. What to establish before you send production data anywhere: whether inputs and outputs are used to train or improve the vendor's models, how long prompts and completions are retained and where, which sub-processors are involved and whether you get notice before that list changes, which region processing happens in, and what happens to your data on termination. A vendor who cannot answer these quickly is telling you something useful about their maturity.
Section 4
Deletion is harder than you think
A deletion request is simple against a database and awkward against an AI stack. The record comes out of the primary store, and then you find copies in the vector index, the prompt logs, the evaluation set someone exported to a spreadsheet, the vendor's retention window, and any model that was fine tuned on it. Design for this before you have to answer a request under a deadline. Keep an inventory of every place personal data lands, including derived stores. Prefer retrieval over fine tuning for personal data, because you can delete a document from an index and you cannot cleanly delete a person from model weights. Set short retention on prompt logs by default and extend deliberately where you need the audit trail. Test the deletion path once with a real record, because a process nobody has run is a process that does not work.
Section 5
Rights, assessments, and automated decisions
NIST frames AI risk management around trustworthiness, design, evaluation, and use, and the privacy specific version of that discipline has three parts a small company can actually run. Assess before you deploy. Where processing is likely to be high risk, particularly profiling and large scale processing of sensitive data, do a written assessment. It does not need to be long. It needs to name the risk, the mitigation, and the residual. Respect the rights that attach to automated decisions. If a system makes a decision with legal or similarly significant effect on a person, expect obligations around human review, explanation, and contest. Build the route for that review as part of the feature rather than as an exception process. Disclose plainly. A privacy notice that mentions AI in a subclause is compliant on paper and useless in practice. Tell people what the system does with their information in language they would use themselves. The employment-facing version of these obligations is in [AI Automation and Job Displacement: What Founders Should Know](/blog/ai-automation-and-job-displacement-what-founders-should-know).
Section 6
What to measure
Track the number of systems sending personal data to third parties, the retention period on each, the proportion of prompts that carry identifiers, the time to complete a deletion request end to end, and the age of your last vendor terms review. The single most useful exercise is an annual data flow walk: pick one customer, and trace every system, index, log, and vendor that holds something about them. Teams that do this find at least one surprise. The analytics-facing side of this trade-off is discussed in [Using AI and Data Analytics to Enhance Storytelling](/blog/using-ai-and-data-analytics-to-enhance-storytelling).