Your model documentation states that the system records each decision's inputs to satisfy the EU AI Act's record-keeping obligations - Article 12 requires a high-risk system to allow automatic recording of events over its lifetime and Article 19 requires providers to keep those logs for at least six months where they control them. The log holds the full application record including personal data. A customer exercises their right to erasure. What happens next and which design survives both obligations?

What happens in the next thirty days

The erasure request lands on a team whose deletion tooling covers the application database and knows nothing about the decision log. Someone then discovers that the log was written to immutable storage with a retention hold, so it cannot be edited at all, and the choice has narrowed to breaking the audit chain or missing a statutory deadline. Both outcomes are reportable, which is how a logging decision made in a sprint becomes a legal question.

The design that satisfies both

The log exists to make the decision traceable: which model version decided, on which inputs, against which thresholds, with which human involved. Traceability needs references and derived values, not a second copy of the customer file.

• Write stable references to the application records, plus the feature vector the model actually scored, plus a hash of the input payload. The hash proves what was decided on without holding the payload.
• Keep the identifying payload in the system of record the erasure process already operates on. Erasure removes the payload; the decision record stays intact and still reconciles, because the hash and the references survive.
• Where identifying data must be inside an immutable log, encrypt per subject at write time with a key held in a key store, so erasure becomes destruction of one key. The cost is real: a key per subject at millions of subjects, and once the key is gone the record is unreadable for analytics as well as for the assessor.

Why the other options fail

• "Delete the entries." It treats a conflict of obligations as an architecture decision. Which duty prevails is a legal determination, and the architecture's job is to leave the organisation a choice rather than one irreversible answer.
• "Refuse the request." Article 19's six-month floor is explicitly subject to other Union law, data protection included, and it applies to logs under the provider's control. Quoting a retention floor as a blanket exemption is the kind of answer that creates a complaint.
• "Pseudonymise after six months." It mistakes the floor for the whole requirement and leaves the first six months unsolved, which is the window the request actually arrives in. A log you cannot re-identify is also a log you cannot use to explain a decision to the person who contested it.

What it costs

Two joins where there was one table, a reconciliation job proving every decision record still resolves to its references, and the operational burden of key management if you take the crypto-shredding path. In exchange the log stops being a parallel copy of the customer database with a different retention policy and a different owner.

When this is the wrong answer

For a system that is not high-risk, retaining full decision inputs for six months creates an obligation nobody asked for. Log the decision reference and the outcome, keep the retention short, and spend the effort on the systems where the obligation is real. Minimising what is recorded is a control too, and it is the cheapest one available.