Industry
Part of Age restrictions are four separate rules that get mistaken for one law
Age restrictions risks: the two errors and who bears each
Age restrictions risks run in both directions: wrongly excluded adults, wrongly admitted children, the evidence a check leaves behind, and the signals to watch.
The risk everybody plans for is that a young user gets in. The risks that actually materialise are usually created by the check itself: data you now hold, adults you cannot serve, a vendor you cannot audit, and a support queue full of people who cannot prove who they are.
None of that is an argument against checking. It is an argument for counting age restrictions risks on both sides of the ledger before you pick a method, and for watching a short list of signals afterwards.
What to take away
- Every check produces two kinds of error, and tuning to reduce one increases the other. Decide which you will make before you choose the method.
- The evidence collected during a check is usually more sensitive than anything else the service holds. Retention is the decision that matters most.
- An appeal route that demands more information than the original check is a design failure, not a safeguard.
The two errors, and who bears each one
A check that wrongly excludes an adult costs that person access and costs you a support contact and a complaint. A check that wrongly admits a child costs a young user exposure to something built for adults, and costs you a great deal more than a support contact.
Two errors, two costs
Wrongly excludes adult
- Who pays
- The adult
- Immediate cost
- Support contact
- Scale of cost
- Complaint
- Who is affected
- No documents, no payment
- Design trade-off
- Fewer children admitted
Wrongly admits child
- Who pays
- The child
- Immediate cost
- Exposure to adult content
- Scale of cost
- Far greater
- Who is affected
- Young user
- Design trade-off
- More adults excluded
They are not symmetrical, and that asymmetry is the whole design problem.
A method tuned to admit fewer children excludes more adults. Those excluded are disproportionately people without documents, without a payment relationship, with a face the estimator handles poorly, or on a shared or unusual device. It is a fairness question and a commercial one at once.
Write down which error you are choosing to make and why, before you configure anything. A team that has not made that choice explicitly has still made it, in the settings, without a record.
Risks the check itself creates
| Risk | Warning sign | Safer response |
|---|---|---|
| Sensitive evidence retained by default | Nobody can state the retention period without checking the code | Decide retention before collection; in most designs, keep the result and discard the evidence |
| The check becomes a breach surface | Document images sit in the same store as ordinary content | Separate storage, separate access, shortest viable life |
| Vendor opacity | The contract describes the service but not what is kept | Get retention, location, sub-processors and end-of-contract deletion in writing |
| Repeated re-checks | The flow runs on every session rather than at a decision point | Check at the decision, store the conclusion, re-check on defined triggers |
| Age data spreading | The value appears in advertising or analytics pipelines | Record what depends on the field, and restrict it deliberately |
| The appeal costs more than the check | An excluded adult is asked for a document the check never wanted | Make the appeal no more intrusive than the original path |
| Exclusion nobody measures | Support tickets are counted, refusals are not | Count refusals and abandonments by method, and look at who is affected |
The last row is the one that hides longest. Refusals leave quietly, and a system can be failing a whole category of legitimate users for a year without producing a single metric that says so.
Check-created risks and responses
- Sensitive evidence retained by defaultdecide retention before collection
- Check becomes a breach surfaceseparate storage, shortest viable life
- Vendor opacityget retention and deletion in writing
- Repeated re-checkscheck at decision, store conclusion
- Age data spreadingrestrict the field deliberately
- Appeal costs more than checkmake appeal no more intrusive
- Exclusion nobody measurescount refusals and abandonments
Risks to the young user that a check does not address
A gate answers one question and is often mistaken for a safety program.
An age band does not make defaults appropriate, and the defaults are what a young user experiences every day. A verified account does not tell you who is at the keyboard. A supervision link does not survive the child using a different device.
Collecting identity evidence from a minor, or from a parent on a minor's behalf, creates a record about a child that has to be protected for as long as it exists. That is a new risk rather than a mitigation.
The practical response is to treat the check as one control among several, and to spend at least as much effort on what a young account can do by default as on establishing that it is a young account.
Risks to the organization, in order of how often they bite
Data you did not need. The most likely bad outcome is not a regulatory one. It is holding sensitive material with no live purpose when something goes wrong elsewhere.
A method chosen without a decision record. When someone asks later why you check this way, the absence of a written reason is the problem, not the method.
A single vendor holding the whole function. Concentration is fine until the contract, the pricing or the availability changes. Know what happens if the service stops. A vendor concentration question is also a platform terms and rules question, because the contract can be rewritten.
Silent scope creep. The field was added for one decision and is now read by three systems, one of which is advertising. That change is rarely deliberate and rarely reviewed.
Assuming a check discharges an obligation. It may be one element of several, and what applies to you depends on where you operate and changes. In the United States the children's privacy law is COPPA, the Children's Online Privacy Protection Act, and the Federal Trade Commission's own material on it, including its COPPA rule review, is where the detail lives. In the United Kingdom the Information Commissioner's Office publishes the Age Appropriate Design Code, its children's code, and the two regulators do not say the same things. Take what applies to you from your regulator's current material and from a qualified adviser, not from any general page including this one. Which body to ask is itself a question with a method, set out in finding the responsible body.
Signals worth watching after launch
- Refusal and abandonment rates at the check, broken down by method and by anything you can see about the population affected.
- Appeals per thousand checks, and how many succeed. A high success rate means the check is miscalibrated, not that the appeal is working well.
- Time to resolve an appeal. This is the number a wrongly excluded person experiences.
- Support contacts mentioning the check. Read a sample rather than counting them.
- Any new system that starts reading the age field.
Set a review date and look at these together. Individually each is easy to explain away.
When it goes wrong for an individual
An account restricted on an age question follows the same path as any other restriction, and the same preparation helps. Keep your own copies and know which address the notices reach. Do not open a second account, which is treated far more harshly than the original problem.
The mechanics are in how enforcement outcomes work, the layers behind the rule are in four rules that get mistaken for one, and the shape of the rules themselves is in how an age rule is built.
Common questions
Is the least intrusive method always the right one?
No. The right method is the one whose error profile you can live with and defend. Sometimes that is more intrusive than you would like, and the decision record is what makes it defensible.
Can we keep the evidence in case of a dispute?
Ask what dispute, and whether the stored conclusion and basis would answer it. Usually they would, at a fraction of the risk.
Our vendor says they handle compliance. Is that enough?
A vendor can perform a check. It cannot hold your obligations for you, and its assurances are worth what the contract says they are worth.
