Prompt and log retention limits

What it does

It limits how long conversational data exists. A retention schedule states, for each class of prompt, output and log, why it is kept and for how long, and deletion is automated at the end of the period. The same limits are agreed with providers. Records management sets the periods with the data protection officer; the system owner is accountable for applying them. It is designed in at build and operates continuously.

How to implement it

• Classify what is logged: full text, metadata, safety flags, audit records.
• Set a period for each class from its purpose, and separate records that must be kept from those that need not be.
• Prefer metadata to full text where it serves the purpose.
• Automate deletion, including backups and derived stores such as caches and indexes.
• Agree retention, review and training-use terms with each provider, and choose the settings that match.
• Verify deletion by test, and review the schedule annually.

Evidence it operates

Design: a retention schedule covering AI prompts and logs; provider terms and configured settings. Operation: deletion job records; a test confirming that expired data is gone; store sizes consistent with the schedule.

Where it fits

Built at design and running through operation and retirement. It is the primary control for excessive retention of prompts and logs and supports unfulfillable data subject rights by leaving less to search. It works with AI record-keeping and audit trail, which defines what must be kept.

Limits

Retention pulls in two directions: accountability needs records and data protection needs deletion, and the schedule has to reconcile them case by case. Deletion at a provider is hard to verify independently. Data already used to train a model is not removed by deleting the log it came from. Short periods can remove evidence needed for a complaint that arrives late.