It can find what is due and prepare the deletion, but a person should approve it. Deletion cannot be undone, so it sits at the highest level of agent authority. The agent matches records to the retention schedule, checks for legal holds and open matters, and proposes a batch with evidence. A named owner approves before anything is deleted.
Why is deletion treated so carefully?
Because both directions carry risk. Keeping data too long breaches data protection principles: under GDPR and UK GDPR, Article 5 requires that personal data is kept no longer than necessary. Deleting too early can be worse. Records may be needed for a complaint, a legal claim, a regulatory investigation or anti-money laundering duties that require records to be kept for a set period after a relationship ends.
A deletion made in error cannot be reversed. That puts it alongside moving money: depth 4, held for a person.
What may the agent do, and what stays with a person?
| Task | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Matching | Links each record type to its retention rule and trigger date | 1 | Resolving records with no matching rule |
| Due list | Lists records past their retention date | 1 | Nothing |
| Hold checks | Checks for legal holds, open complaints, litigation, investigations, regulatory requests | 1 | Deciding whether a borderline match is a hold |
| Dependencies | Checks whether other records depend on the data, such as a ledger entry | 1 | Deciding how to handle dependencies |
| Batch proposal | Prepares a deletion batch with evidence for each record | 2 | Approving the batch |
| Execution | Triggers deletion in the system of record once approved | 4, held | Approval before execution |
| Verification | Confirms records are gone, including backups as policy requires | 1 | Reviewing exceptions |
| Record | Logs what was deleted, when, on whose approval | 3 | Signing the log |
The wider process of applying schedules, including archiving and anonymisation, is covered in how to apply record retention schedules with an AI agent.
What usually goes wrong?
Hidden holds. A legal hold recorded in the legal team's own system, but not flagged in the customer record, is easily missed. The agent must check every place holds are kept, and say which it checked.
Wrong trigger date. Many retention periods run from an event, such as the end of the relationship or the closing of a claim, not from creation. A record created years ago may still be within its period. The agent should show the trigger it used.
Partial deletion. Data deleted from the main system may survive in exports, reports, emails and agent logs. Verification should cover the copies the policy names.
Deletion that breaks something. Removing a customer record may orphan transactions the firm must keep. Anonymisation, rather than deletion, may be the right answer for some fields.
How is this different from a customer asking to be deleted?
A customer's request to delete their data or close their account starts from a different trigger, the request, and raises questions about which data the firm must still keep. The agent's hold checks are similar, but the decision about what to keep and the reply to the customer follow the request process. See whether an AI agent can delete a customer's account and how to handle requests to delete an account with an AI agent.
An illustrative example
Take a building society running its quarterly retention review on closed savings accounts. The agent lists accounts whose retention period, counted from closure, has ended.
For each, it checks the complaints system, the legal hold register, the financial crime case system and the regulatory request tracker. Most are clear. Eleven accounts appear in a closed complaint that was referred to an ombudsman and is still open there; the agent flags them as held. Two accounts belong to a customer under a court order recorded only in the legal team's matter list; the agent finds them because the matter list is one of its sources. It prepares a batch of the remainder, showing the rule, trigger date and hold checks for each.
The records manager samples the batch, approves it, and the agent triggers deletion in the core system. It verifies the records are gone from the system and the reporting copy, and logs the result. Deletion from backups follows the backup cycle, and the log says so.
What controls make it safe?
- Deletion held for approval at the moment of action, never executed on the agent's judgement.
- Hold sources listed on every batch, so reviewers see where the agent looked.
- Trigger dates shown, not just "past retention".
- A dry run before execution, showing exactly what will be removed.
- Verification and an append-only log of what was deleted, kept for as long as the firm needs to show compliance.
The principle for all compliance agents is in AI compliance agents: second line, never the last word.
Where Pryme fits
In Pryme, deletion is a depth 4 capability: an agent can prepare it, but execution is held for a named person within the customer's own limits. Every verdict, including each approved deletion, is filed in an append-only record.
Questions people ask
Can routine deletion ever run without a person?
Some firms allow automated deletion for low-risk data under a schedule signed off in advance, with holds checked automatically. Even then, a person should approve the rules and review exceptions.
Should the agent delete its own logs on schedule?
Yes, under the same retention rules, approved in the same way. Agent logs often contain personal data.
What about anonymising instead of deleting?
Anonymisation can keep data useful for analysis while removing personal data. Done properly it is also irreversible, so it needs the same approval.