Data Privacy Checklist for Teams Running Their Own Models

It's easy to assume personal data means the fields in your database schema: name, email, address. In a prompt, personal data can be anything a user typed, including things that never touch a structured field: a complaint describing a specific situation, a pasted document, a screenshot's transcribed text.

Treat prompt content as potentially personal by default, rather than trying to enumerate every case where it might be. That changes how you log it, how long you keep it, and who can read it, closer to how you'd treat a support ticket than a generic API payload.

Default retention for logs is often forever, because nobody set an explicit policy and the storage is cheap enough not to notice. That's a liability once a user asks what data you hold about them, or a regulator asks the same question with less patience.

Set an explicit retention period for prompts and completions, short enough to match an actual business need, and automate the deletion rather than relying on someone remembering to run a cleanup script. If you need certain interactions for longer, for a dispute or a support case, move those into a separate, deliberately retained record instead of extending the default for everything.

When a user asks for their data to be deleted, model-serving specifics complicate a normal deletion flow:

• Raw prompts and completions logged for debugging need to be findable by user, not just by request ID.
• If the same data was used to fine-tune a model, deletion from logs doesn't remove it from the model's weights; that requires a separate decision about retraining.
• Cached responses keyed by prompt text can outlive the deletion of the original request that generated them.

Handle all three, not just the log line, or the deletion is incomplete even though it looks done.

If you call an external model API, your privacy posture depends partly on their terms, and those terms vary a lot on data retention and whether your prompts can be used for training. Read the actual data processing terms, not just the marketing page, before sending customer data through any model API.

Where your contract or a regulation requires it, confirm zero-retention or opt-out-of-training settings explicitly rather than assuming a default you haven't verified. For anything jurisdiction-specific, check with your attorney; this varies enough by provider and by region that a general rule isn't reliable.

If your model provider processes data outside your users' region, that's a cross-border transfer, and it needs the same attention you'd give any other subprocessor handling data that way. Confirm what transfer mechanism the provider relies on and whether it actually covers the categories of data you're sending them.

This is squarely attorney territory rather than an engineering decision; the right mechanism depends on your users' jurisdictions and your provider's own setup, and it changes as regulations do. Flag it early rather than discovering it during a customer's security review.

• Logging full prompts for debugging in a system with broader read access than your production database.
• Assuming a third-party provider's default settings are privacy-protective without checking their actual data processing terms.
• Treating a deletion request as complete once the log line is gone, without checking caches or fine-tuning data.

Each of these is invisible until someone asks the right question, usually a user, sometimes a regulator.