Your Age Sweep Has No Undo Button

There is a code path in your platform that deletes a user account, and until this year almost nobody thought of it as an age assurance control.

It was written for spam. Or for a terms-of-service violation, or a support agent honouring a deletion request. It takes an account ID, tears down the rows, drops the media, and returns 204. It is well tested, it does what it says, and it has exactly one property that matters now: it cannot be undone.

That path is about to be called several million times by a batch job whose selection criterion is a machine learning model with a published error rate.

This is the half of age assurance that has gone almost entirely unwritten. Three years of industry discussion — including a lot of ours — has been about the front door. Which method, what threshold, how to cut drop-off, what to do when the provider is down. All of it assumes the subject is a stranger standing at your gate, and that the worst case is friction. The duties that actually arrived in 2026 point somewhere else entirely: at the users who are already inside, who signed up in 2019 under a self-declared date of birth, and who now have to be sorted. That sorting is destructive, it runs at population scale, and it is graded by a model.

The duty moved from the door to the floor

Read Australia’s regulatory guidance closely and the shape becomes obvious. The eSafety Commissioner does not describe a signup check. It describes a layered obligation to work out which accounts you already hold belong to age-restricted users, deactivate or remove them, prevent those users from creating new accounts, and mitigate circumvention of all of the above (eSafety regulatory guidance, DLA Piper). Measures will not count as reasonable steps if they rely entirely on self-declaration to determine the age of existing or prospective account holders. Existing sits in the same clause as prospective, and it is the larger population by orders of magnitude.

Two of those four limbs are remediation, not verification. One is anti-recidivism. Only the first is what most teams have built.

Indonesia went further and named the end state. Ministerial Regulation No. 9 of 2026, the implementing rule under PP Tunas, classifies social media as high-risk and obliges operators to deactivate and delete accounts held by children under 16, on a phased implementation running from 28 March 2026, with access blocking available as an administrative sanction for operators that fail to report compliance (Library of Congress, Biometric Update). The obligation is not “check them.” It is “delete them.”

The Meta consent decree does the same thing in private-contract form. Alongside the false-positive ceilings we covered when the settlement landed, Meta must deploy detection models to identify and remove under-13 users on a staged timetable running into year three, and the independent auditor appointed for the full ten-year term has express power to audit under-13 enforcement volumes (Pearl Cohen, Security Boulevard). Enforcement volumes. Not check completion rates — the number of accounts acted upon. Someone with subpoena-adjacent access is going to ask how that number was produced, and what happened to the people in it.

The UK arrived at the same place from a different direction. On 12 March 2026 Ofcom wrote to Facebook, Instagram, Roblox, Snapchat, TikTok and YouTube telling them to actually enforce their own minimum ages using highly effective age assurance, with a report due by 30 April on the specific actions they would take, citing research that 72% of children aged 8 to 12 are on their services (Ofcom). A platform whose stated minimum age is 13 and whose under-13 population is measured in the millions is not being asked to improve its signup flow. It is being asked about the floor.

And section 12 of the Online Safety Act, as we have noted before, never mentions account creation at all. It asks whether children can normally encounter the content. That is a question about everyone holding an account, not everyone opening one.

Removals are not verifications

Here is where the published record gets genuinely confusing, and where a lot of internal reporting is about to mislead a lot of boards.

Within a month of Australia’s law commencing, ten platforms reported removing or deactivating roughly 4.7 million accounts, with Meta confirming about 550,000 of its own (NBC News, Al Jazeera). That is a big, quotable, politically satisfying number.

Roblox published a different kind of number. When facial age checks became mandatory for chat, roughly 45% of its 144 million daily active users had completed one as of January 2026, climbing to around 51% globally by the end of March and about 65% in the United States; by August the system had processed 338 million age-check records (Roblox, Roblox newsroom).

These two numbers answer different questions and only one of them is a measure of assurance. A removal count tells you how many accounts you acted on. A completion rate tells you how much of your base you now actually know something about. A platform can post an enormous removal figure while the overwhelming majority of its base remains exactly as unverified as it was before — because removals are concentrated on the accounts that were easiest to identify, which are usually the ones that self-declared honestly in the first place. You deleted the users who told you the truth. The ones who lied at signup in 2019 are still there, and your removal metric went up.

If your quarterly compliance pack contains a removals number and no denominator, it is not evidence. It is activity. We have written separately about what actually counts as proof that an age assurance programme works; the same discipline applies here, and the denominator is the whole point.

A sweep is not a bigger gate

The instinct is to treat back-book remediation as the signup flow pointed at a larger population. It is a materially different risk object, in four ways.

Selection is by model, not by user action. At the gate, a user presents themselves and a check runs. In a sweep, you choose who gets challenged, using inference over behavioural signals, account age, declared date of birth, network, or an estimation model run over existing media. The false positive rate that matters is no longer per-check; it is per-population, multiplied by a cohort you selected. A 1% error rate against a 40-million-account base is 400,000 wrongly flagged adults, and they did not choose to be there.

The error is silent. A false positive at the gate is visible and immediate: someone is standing at a verification screen, annoyed, and they will retry or contact support. A false positive in a sweep hits someone mid-life. They are not attempting anything. They get an email, or they do not, and their account is gone. Our post on adult lockout from age estimation covers the mechanics of the error; the sweep case adds that the affected person often has no idea a check occurred.

The cost of error is stock, not flow. Blocking a signup costs you one acquisition. Deleting an eight-year-old account destroys purchase history, saved content, social graph, creator revenue, and, for a business account, an operating dependency. It is not the same magnitude of harm and it should not clear the same evidentiary bar.

Volume is a spike against a steady-state support org. Whatever fraction of a sweep lands in a support queue arrives in weeks, not years. A support team sized for organic contact volume will be somewhere between overwhelmed and non-functional, which is precisely when appeals stop being handled “in a timely, diligent and non-arbitrary manner” — language that, as we will see, is not aspirational.

The remediation ladder

The single most useful design decision is to stop treating “action the account” as one operation. It is a ladder, and each rung has a different reversibility and should demand a different class of evidence.

Rung	What happens	Reversible?	Evidence it should require
Flag	Internal marker only; user experience unchanged	Fully	Model signal alone
Restrict	High-risk capabilities withheld — chat, DMs, discovery, monetisation	Fully	Model signal above threshold
Default down	Account moved to the strictest minor-appropriate configuration	Fully	Model signal above threshold
Suspend	Access blocked, data intact, user notified with a route back	Fully	Model signal plus a second independent signal
Deactivate	Account and content hidden from all surfaces, data retained under legal hold	Reversible within a defined window	Completed check, or expiry of an appeal window after notice
Delete	Personal data destroyed	Never	Confirmed evidence, or an exhausted appeal window, or a statutory deletion duty that has actually attached

The rule that makes this work is one line: irreversibility must be earned by evidence class, never by model output alone. A model can move an account down the ladder as far as suspension. It should never be wired directly to the delete path.

That sounds obvious written down. It is not what most sweep implementations do, because the batch job was specified as “identify and remove under-16 accounts” and someone implemented exactly that sentence.

The rungs above suspension are also where most of the actual child-safety benefit lives, at a fraction of the harm. An account restricted to a minor-appropriate configuration with messaging and discovery off is no longer a risk surface, and if the classification was wrong, the affected adult loses some features for a few days rather than a decade of history. The DSA’s Article 28 guidelines push in the same direction — minors’ accounts configured to the highest protection level by default — which means “treat as a minor” is a compliant end state in the EU, not merely a waypoint (Freshfields). For a large share of your flagged cohort, the ladder can simply stop there.

Where deletion duties and redress duties collide

Now the hard part, and the reason this needs designing rather than improvising.

Several regimes push you toward destroying the data. The amended COPPA Rule prohibits indefinite retention and requires deletion once children’s personal information is no longer reasonably necessary for the purpose it was collected for, with written retention policies stating specific periods (Fenwick). Indonesia’s Regulation 9/2026 obliges deletion outright. GDPR erasure rights and data minimisation point the same way, and everything we said about why holding verification data is a liability still applies.

Meanwhile, a different set of rules requires you to give the person a real way back.

Under Article 17 of the DSA, suspending or terminating a recipient’s account is a restriction that triggers a clear and specific statement of reasons, delivered to the affected recipient, including information about available redress (DSA Art. 17). Under Article 20, that recipient gets access to an internal complaint-handling system that is easy to use and that handles complaints in a timely, non-discriminatory, diligent and non-arbitrary way — and decisions on complaints cannot be purely algorithmic; appropriately qualified staff must be involved (DSA Art. 20). Article 21 adds out-of-court dispute settlement on top.

Layer on GDPR Article 22, which restricts decisions based solely on automated processing that produce legal or similarly significant effects, and requires — where an exception applies — the right to obtain human intervention, express a point of view, and contest the decision. A human rubber-stamping model output does not count; the reviewer has to be able to depart from the recommendation (Art. 22 GDPR, ICO). Whether the automated destruction of a person’s long-standing account clears the “similarly significant” bar is not a question you want to litigate for the first time after the batch job has run.

Put plainly: you cannot offer meaningful redress against an action you have already made irreversible. An Article 20 complaints process attached to a delete path is theatre. The complaint arrives, a qualified human reviews it, agrees the classification was wrong, and has nothing to restore.

The pattern that resolves this is a quarantine tier with a documented hold, sitting between deactivation and deletion:

1. Deactivation removes the account from every surface immediately — the safety outcome lands on day zero, which is the outcome the regulator cares about.
2. The data moves to a segregated, encrypted, access-controlled store. Nothing about it is available to product, analytics, advertising, or model training. It is not “still in the database”; it is in a vault with a different key and a different access log.
3. The statement of reasons goes out with an explicit appeal route and an explicit deadline, in the account’s language.
4. Deletion executes automatically when the window expires, or immediately on confirmation, or on the user’s own request.
5. The legal basis and duration of the hold are written down before the sweep runs, in the retention schedule, as a defined and specific period — which is what COPPA’s retention-policy requirement asks for anyway.

The window length is a judgement call and there is no published safe harbour, because no regulator has issued one. It should at minimum exceed the DSA’s six-month internal-complaint window for the accounts that window covers, and it should be shorter for accounts where you have confirmed evidence rather than an inference. Whatever you choose, choose it in advance and document why. “We held minors’ data for an unspecified period because our appeals backlog was long” is a bad sentence to write to a data protection authority.

There is a legitimate objection here: quarantining a suspected minor’s data is retaining a child’s personal data, which is the thing everyone is trying to avoid. That tension is real and it does not fully resolve. What makes it defensible is that the hold is bounded, documented, minimised to what an appeal actually requires, segregated from all processing, and shorter than the harm of destroying an adult’s account with no route back. Write the reasoning down. That reasoning is the compliance artefact.

The re-registration paradox

eSafety’s guidance contains a requirement that quietly contradicts the deletion duty: measures are not reasonable steps if they fail to stop a deactivated or removed age-restricted user from immediately reactivating or creating a new account.

So you must delete the person, and also recognise them if they come back tomorrow. With what?

The answer is not to keep the record. It is to keep a one-way derived token — a salted hash of a stable identifier, or a device or credential binding, stored with no reversible link to the deleted profile, in a suppression list that can answer exactly one question: has this identifier been actioned before? That preserves the recidivism control while destroying everything else. It is the same architectural move as storing a verification decision rather than a passport image, applied to the exit path instead of the entry path, and it connects directly to the binding and shared-device problems that make circumvention hard to measure in the first place.

Two cautions. A suppression list is still personal data — pseudonymised, not anonymous — so it needs its own retention period and its own entry in the record of processing. And it will produce false matches on shared devices and recycled phone numbers, which means it also needs an appeal route. Everything in this pipeline needs an appeal route. That is the theme.

What to log, and the one number an auditor will ask for

No regulator currently requires a per-user, per-check audit trail for age assurance, and the ICO’s position points firmly the other way — a service may only need to retain a yes/no output once a check completes. So this is not an argument for building a dossier on everyone you swept. It is an argument for aggregate, decision-level records about the system, which is what an information notice or an independent auditor actually reaches.

For any remediation exercise, the record worth keeping is:

• the cohort definition and how it was selected, versioned;
• the model or rule version and the threshold in force, per cohort;
• the evidence class that authorised each rung of action, in counts;
• action counts per rung, per jurisdiction, per period;
• notices sent, and delivery outcomes;
• appeals opened, appeals upheld, and time to resolution;
• the reversal rate — the share of actioned accounts restored on appeal;
• deletions executed, and the hold period each one served.

Reversal rate is the number that matters most and the one nobody instruments. It is your only empirical estimate of the sweep’s false positive rate on your own population, as opposed to the vendor’s benchmark on theirs. It is also, in the post-Meta-settlement world, exactly the kind of figure an auditor with data access will reconstruct whether you measured it or not — and the difference between reporting it and having it reconstructed for you is considerable. When a settlement puts numeric false-positive ceilings into an enforceable instrument, a reversal rate is the operational shadow of that ceiling.

Then use it as a control, not just a report. If the reversal rate in a cohort exceeds a threshold you set in advance, the sweep pauses automatically. A batch job that can delete accounts should have a circuit breaker on its own error rate, for the same reason a deployment pipeline has one on error budgets.

Sequencing a sweep you can defend

Roughly in order:

1. Sample your data quality first. Before sizing anything, find out what fraction of your base has details that could be matched against anything at all. Initials instead of names, obviously fake dates of birth, addresses that are commercial premises. This is a query you can run this week, and it determines how much of the base can be cleared silently versus how much has to be asked.
2. Clear by reuse before you challenge anyone. Any user whose age can be resolved against a credential they already hold, or a prior verification, or a device-bound decision, should never see a prompt. This is the single biggest lever on both cost and churn, and it is the whole argument for reusable credentials.
3. Pilot one cohort. Take a defined slice, run the full pipeline including notices and appeals, and measure completion, support contacts and reversal rate. Nobody has published benchmarks you can borrow, so the numbers in your plan have to be yours.
4. Offer more than one route, and escalate rather than dead-end. An inconclusive result that stops is a support ticket you paid for and learned nothing from. Layered orchestration matters more in a sweep than at the gate, because the population is everyone rather than the subset who happen to hold one document type.
5. Throttle to appeal capacity, not to infrastructure capacity. The binding constraint is qualified humans reviewing complaints, and Article 20 does not have a load-shedding provision.
6. Never let a fresh self-declaration clear an account. Re-asking a user to confirm their age is not a check, and prompting users who previously declared themselves underage to revise their stated age upward has already been treated as a compliance concern in Australia. It looks, from the outside, exactly like helping.

Where this lands architecturally

The economics of a sweep are unlike the economics of a gate, and they push toward the same architecture we argue for everywhere else.

At the gate, you pay per new user. In a back book, you pay per existing user, once, across the entire base, in a single quarter. If the unit you are multiplying by is a full document scan — OCR, face match, the expensive path — the exercise is unaffordable for anyone with a large base, and the finance conversation will kill it before the compliance conversation finishes. That is exactly why we treat Checks and Verifications as separate operation types rather than pricing everything as though it were a passport scan. A returning-user credential lookup or a lightweight age check is roughly an order of magnitude cheaper than a document verification, and a back book is the single largest concentration of returning users any platform will ever process. Most of a sweep should resolve on the cheap path, with the expensive path reserved for genuine escalation and contested appeals — which, incidentally, is also the sequence that produces the strongest evidence where it counts.

And store the decision, not the artifact. A record that says over 18, at this timestamp, by this method, at this confidence, under this policy version is small, re-checkable, safe to hold, and sufficient to answer both the auditor and the appeal. A stored identity document is a breach liability that helps with neither.

Four questions to ask this week

1. If we ran a sweep tomorrow, what does the flagged path actually call? Read the code. If a model output can reach a hard-delete function without a human, a second signal, or an elapsed appeal window, that is the finding.
2. What is our reversal rate? If you have already actioned accounts on age grounds and cannot produce this number, you do not currently know your false positive rate on your own population — only your vendor’s on theirs.
3. Does our age remediation path emit a statement of reasons and land in the same complaints system as our content moderation appeals? In most organisations these are two different pipelines built by two different teams, and only one of them was designed against Article 17.
4. What is the documented legal basis and duration of our quarantine hold? If the answer is that there is no quarantine, then either the safety action is reversible and you have not really acted, or it is irreversible and your appeal process cannot do anything.

None of this is an argument against remediating a back book. The obligations are real, the regulators have been explicit, and a platform that gated its front door while leaving millions of unverified accounts untouched has not discharged anything. The argument is narrower: the sweep is a destructive, irreversible, population-scale operation being specified in most organisations as a single sentence in a compliance plan, and implemented by whoever picked up the ticket. It deserves the same design rigour as a database migration, because that is precisely what it is — except that the rows are people, and the rollback script does not exist.

If you are sizing a back-book exercise and want to work through what it costs, what it deletes, and what the record looks like afterwards, we are happy to look at it with you.