How do I honor a GDPR erasure request when my AI agent's audit log is tamper-evident?

What should I check, step by step?

1. List what the agent's log holds and mark every field that could identify a person: names, emails, account or order numbers, IP addresses, free-text prompts and outputs, attached documents, and ids that point back to a customer record.

2. Split each record in two. Personal details go to a store you control and can delete from (a database table or object store). The chained log gets only non-personal fields (action type, outcome, time, an internal random event id) and the SHA-256 of the full stored record.
3. Salt every record: generate a random salt of at least 32 bytes, keep it with the stored record, and hash salt plus record. Without a salt, a hash of a short value such as an email address can be confirmed by guessing. The EDPB treats a salted or keyed hash as personal data while the salt exists, and as no longer linkable once the salt is deleted, provided it was long, random and never leaked.
4. Or encrypt each person's records under their own key and delete the key to erase them (crypto-shredding). NIST SP 800-88 Rev. 2 accepts cryptographic erase only if the data was never stored in plaintext and every copy of the key is destroyed, so check backups, caches and key escrow.
5. On Rightshold, send record_action with action_type, outcome, occurred_at and action_sha256 (the salted hash). Leave summary out or keep it generic ('refund issued'), and use a random id as client_event_id, never an email or a customer's order number. Recorded events can't be edited or deleted, so whatever you put in those fields stays.
6. Enforce it on the stream: set require_action_sha256 to true and list allowed_action_types, so events without a hash or with an unexpected action type are refused.
7. When an erasure request arrives, check the exemptions first (GDPR Article 17(3), for example a legal obligation to keep the record, or legal claims). If one applies, keep the record, limit who can open it and tell the person. If not, delete the stored record and its salt, or the key, from live systems without undue delay.
8. Deal with backups: the ICO expects backup copies to be put beyond use until they are overwritten on their normal schedule, and every restore to re-apply the deletion list so erased records don't come back.
9. Log the erasure itself without personal data: a new entry such as privacy.erasure_completed with the internal event ids affected and the date, so an auditor can see why those records can no longer be opened.

Why can't I just delete personal data from a tamper-evident AI agent log?

A tamper-evident log works because each entry commits to the one before it (or to a Merkle root), and the head is kept somewhere you don't control. Removing or editing an entry changes every hash after it, which is exactly what the log exists to expose. A log that keeps personal data inside its chained entries can't honor erasure without breaking its own proof.

• GDPR has no exception for that. Article 17 gives the right to erasure, Article 5(1)(c) and (e) require data minimisation and storage limitation, and Article 25 requires data protection by design. The EDPB says the rights to erasure and to object must be complied with by design, and that it isn't advisable to register personal data on a chain in clear text, encrypted or hashed form; it should be stored off-chain.
• Erasure isn't absolute. Article 17(3) lists exceptions, including processing needed to comply with a legal obligation and for the establishment, exercise or defence of legal claims. You may have to keep some audit records, so the design has to support both: keeping a record when an exemption applies, and making it unlinkable when none does.

How do I keep personal data out of a hash-chained AI agent log?

Store the agent's full record where you can delete it, and chain only a salted hash of it. Checking still works: anyone holding the stored record and its salt can recompute the hash and match it to the chained entry, and the chain shows the entry hasn't changed since it was written.

• Erasure then means deleting the stored record and its salt. The EDPB notes that once the salt or key is deleted, a hash made with a state-of-the-art function and a long random salt should no longer be linkable to the original data, unless the algorithm is broken or the salt leaked or was poorly chosen. Crypto-shredding reaches the same result for encrypted records, under NIST's conditions for cryptographic erase.
• Watch the fields that look harmless. An event id built from an email address, a tag holding a customer name, or a summary like 'refunded Jane Smith' puts personal data into the permanent part of the log.

What does Rightshold keep from a recorded agent action, and what can't it erase?

record_action appends the event to your account's private stream and puts a salted commitment to it on the public ledger, which reveals nothing unless you choose to open it. The event itself (action_type, outcome, occurred_at, summary, action_sha256, client_event_id, tags) is stored privately and can't be edited or deleted, so personal data sent in summary, client_event_id or tags stays for good. Send the salted hash in action_sha256 instead.

• Rightshold doesn't hold your stored records or salts, can't delete them for you and doesn't decide whether an exemption applies. A receipt proves what was submitted and when, and that it hasn't changed since. It doesn't prove the action happened. Not legal advice.