Age Assurance: Prove You're 16 Without Proving Who You Are

The bottle shop on the corner has a sign by the till. It says the staff will ask for ID if you look under 25. You are well past 25, and a little flattered. You hand over your licence. The attendant glances at it, nods and gives it back.

Think about what that card told him. Your full name and home address. Your date of birth, to the day. A licence number, your photo, your signature and the class of vehicle you may drive. He needed one fact: that you were born before a certain date. He got a dozen, and he forgot all of them before the bag was packed. That forgetting is the only reason the arrangement works.

Now picture a different bottle shop. This attendant photocopies the licence. Then he photographs your face, twice, from slightly different angles, "for liveness". He files the copies in a cabinet in the back room, sorted by suburb, in case a regulator ever wants proof that he checked. On each copy he notes that he estimated your age at 38—which is kind—and how confident he felt about it, to two decimal places. Then he outsources the filing to a firm in another city, whose back door is held shut with a folded piece of cardboard. By Friday the cabinet holds the face, name and home address of every adult in the district who has ever bought a bottle of pinot noir. The only thing anybody wanted to know was whether they were over 18.

No bottle shop does this. But from 10 December 2025, software is asking a version of the attendant's question at national scale, and whether the answer comes with a photocopy is a design choice somebody is making right now.

On 10 December, Australia's social media minimum age took effect. Ten platforms—Facebook, Instagram, Threads, Kick, Reddit, Snapchat, TikTok, Twitch, X and YouTube—must now take "reasonable steps" to stop Australians under 16 from having accounts, or face civil penalties of up to $49.5 million.¹ The law does not say how to find the under-16s. It does say, quite firmly, what platforms may do with everything they learn along the way. And because the checks are estimates, some people who are 16 or over may be asked too.

So this is a piece about how not to become the second bottle shop. We will take the three ways a machine can work out an age down to the arithmetic, which shows why 16 is such an awkward number to check. We will meet the two regulators and the section of the Act that joins them, and the difference between keeping an answer and keeping a face. Then a (made-up) 16-year-old from Sorell gets checked three ways in three days, and you get the questions to put to any age-check vendor.

Let's get into it.

Part 1: One Bit, Asked a Dozen Ways

The question the law asks is: is this account holder an Australian under 16? That is one bit of information. Everything else a platform collects to answer it is overhead, and in privacy terms, overhead is risk.

The umbrella name for the answering is age assurance. The OAIC's guidance defines it as "an umbrella term for a set of processes and methods used to verify, estimate and/or infer the age or age range of an individual". Three verbs, three families of method. "Age verification" is only one of them, and when people say "the government wants everyone's ID", they are describing that one family, which the Act says can never be the only option.

The guidance sorts the personal information in an age check into three piles:

• Inputs: what goes into the check, "e.g. photo, voice, document scan".
• Outputs: the decision that comes out, "e.g. '16+ yes/no' token", linked to an account.
• Existing personal information: what the platform already held about you before anybody asked.

Most privacy questions in this scheme are about which pile something is in, and how long it may stay. One more point catches people out: the guidance says the information in an age check is likely to be personal information, and that this includes situations "where the information is inferred, generated or incorrect". A guess about your age is personal information about you, even a wrong one. The attendant's note that you looked 38 is about you, even though you are not 38.

The OAIC's page lists the names people use for it—the social media "'ban', 'delay', 'age restriction', or 'age obligation'". I will say minimum age, or SMMA, as the regulators do. It annoys everybody equally.

Part 2: Two Regulators, Two Rulebooks, One Field

The law sits in a new Part 4A of the Online Safety Act 2021, added by the Social Media Minimum Age amendment in December 2024. Its central duty, s 63D, is one sentence long: "A provider of an age‑restricted social media platform must take reasonable steps to prevent age‑restricted users having accounts with the age‑restricted social media platform."

That is all the Act says about method. Two regulators share the rest.

eSafety draws the field

eSafety enforces s 63D, and in September it published its regulatory guidance on reasonable steps. It is deliberately "principles-based", and some positions will surprise anyone who expected a checklist:

• eSafety "does not propose a minimum accuracy level for age assurance methods". Each platform must decide what gives it "sufficient confidence", define its own error thresholds and be able to report its error rates.
• "Providers are not required to age verify all their end-users to meet their reasonable steps obligations."
• Self-declaration on its own, the "enter your date of birth" box, is not reasonable.
• Nor are measures that result in "substantial numbers of end-users who are not age-restricted users, being removed or blocked". Over-blocking adults is a failure too.
• Nor are measures that rely on a child holding an account for "an unreasonable period of time" so the platform can collect enough data to guess their age.

The OAIC paints the out-of-bounds line

The OAIC co-regulates the scheme and owns its privacy provisions. Launching its own guidance on 10 October, Privacy Commissioner Carly Kind reached for a sporting metaphor, and I am happy to borrow it: "eSafety has provided the rules of the game with their 'reasonable steps.' Now the OAIC is setting out what is out-of-bounds when it comes to the handling of personal information for age assurance in the social media minimum age context." She also said: "SMMA is not a blank cheque to use personal or sensitive information in all circumstances".

So eSafety marks out the field, and the OAIC paints the line you may not cross. One sentence in eSafety's guidance, which the OAIC echoes in its own, turns the two rulebooks into one game: "Steps to comply with the SMMA obligation will not be reasonable unless providers also comply with their information and privacy obligations under Part 4A of the Act, as well as the Privacy Act and the Australian Privacy Principles".

A platform that finds every under-16 in the country but keeps a photocopy of everyone's face has not taken reasonable steps. Kick the goal from outside the line and it does not count.

The line itself: sections 63DB and 63F

Two sections of the Act do the painting.

Section 63DB stops a platform collecting government-issued identification material, or using an accredited Digital ID service, to comply with the minimum age, unless it also offers "alternative means" that are "reasonable in the circumstances". The definition covers identification documents issued by the Commonwealth, a State or a Territory, including copies, and a digital ID they issue. So a platform may offer ID as one option. It may never make it the only one. As the ABC put it on day one, platforms "are prohibited from compelling users to provide ID and must offer an alternative".

Section 63F is the one that would stop the second bottle shop. It has three parts, and each has teeth:

1. Purpose limitation. Personal information collected to take reasonable steps may be used or disclosed only to work out whether the person is under 16, in a short list of exceptional circumstances borrowed from APP 6.2 (for example, where a law or court order requires it), or with consent.
2. A stricter kind of consent. That consent must be "voluntary", "informed", "current", "specific" and "unambiguous", and the person must be able to withdraw it "in a manner that is easily accessible". The OAIC says the word "unambiguous" is specific to this scheme and "precludes entities from seeking consent through pre-selected settings or opt-outs". A pre-ticked box is not consent here, full stop.²
3. Destruction. The entity "must destroy the information after using or disclosing it for the purposes for which it was collected".

Break any of these, and the Act says the breach is "an interference with the privacy of the individual for the purposes of the Privacy Act 1988". That opens the Privacy Act's complaint process and the Information Commissioner's enforcement powers. It also applies to any "entity" in the Privacy Act sense, so it reaches the age-check vendor, not only the platform.³

When I unpacked the Privacy Act review in 2023, one proposal was a Children's Online Privacy Code. Section 63F is narrower, and already in force. It covers one activity, age assurance, and it is stricter about it than the general Privacy Act is about almost anything.

Part 3: Three Ways to Guess an Age

max_tokensPOST./v1/messages

eSafety's guidance uses definitions aligned with the trial and a draft international standard, ISO/IEC 27566-1. There are three methods:

• Age verification: "calculating the difference between a verified year or date of birth of an individual and a subsequent date".
• Age estimation: "analysis of biological or behavioural features of humans that vary with age".
• Age inference: "uses information, other than a date of birth, which indirectly implies that an individual is over or under a certain age or within an age range".

In plain terms: check a record, look at the person, or read the clues. The bottle shop attendant verifies. A bartender who waves you through has estimated. A teacher who knows the class in the corner is Year 10 has inferred. Each machine version has a different privacy cost.

The government-commissioned Age Assurance Technology Trial, run by the UK-based Age Check Certification Scheme and published at the end of August, tested all three. Its headline was that "Age assurance can be done in Australia privately, efficiently and effectively", with "no one-size-fits-all solution". The useful parts are in the detail.

Verification: the subtraction

Verification is arithmetic: take a date of birth from an authoritative source, subtract it from today, compare with 16. The hard part is proving the date of birth belongs to the person holding the phone, which the trial calls "securely binding DOB to individuals". So a document scan is usually paired with a selfie and a liveness check.

The privacy problem is the bottle shop's: a licence carries a dozen facts to deliver one. The OAIC's advice is blunt: "Where possible, collect binary outcomes ('16+ yes/no') rather than DOB or exact age", and "If scanning a document, only parse the DOB and redact or avoid non-DOB fields." It also describes a better route: a "tokenised assertion from a digital identity credential", where a bank, a telco or an education institution that already knows your age confirms "16+" and "no other identity attributes are collected". We will come back to tokens in Part 5.

The trial rated verification highly, but found "a concerning trend among a minority of providers" towards over-preparing for investigatory or forensic requests. This included "the retention of full biometric or document data for all users, even when such retention was not required or requested".

Estimation: the guess, and its margin

Start with you. You guess ages all day. The new colleague is "about 30". The kid on the bike is "maybe 12". Asked how good you are at it, you might say "usually within a few years".

Name it. That "usually within a few years" has a formal name: mean absolute error, or MAE. For each person, take the size of your miss and ignore its direction—guessing 28 for a 30-year-old and 32 for another both count as a miss of 2 years. Average the misses. That average is your MAE.⁴ A lower number is better.

Now the machine. A facial age estimation model is trained on a very large set of face images with known ages. Give it a new face and it returns an estimated age. The trial found that "some systems achieved mean absolute errors (MAE) of approximately one year in controlled conditions", and it reports the best-performing systems at 1.3 to 1.5 years across its tests. Vendors publish their own figures too: Yoti, which the ABC reports is running Meta's appeal checks, reported an MAE of 1.1 years for 13 to 17 year olds in July, in its own white paper.⁵ The machines have improved fast: the US National Institute of Standards and Technology reported in 2024 that on one set of visa photos, MAE had fallen from 4.3 years to 3.1 years since 2014.⁶

Now the mechanism that matters. An MAE of a little over a year is excellent for most ages. The trouble is the threshold. If the typical miss is about a year, a real 16-year-old will quite often be estimated at 15, and a real 15-year-old at 16. Averages hide this, because most people are nowhere near 16.

At the 16+ gate, the trial reported that systems "fell short of 95% accuracy at the target age". Real 16-year-olds were wrongly rejected 8.5% of the time, and real 17-year-olds 2.6% of the time, both "above acceptable levels". The true positive rate—the share of eligible people correctly let in—"consistently exceeded 95% only at age 19 or higher". The trial's conclusion is that systems need to apply age buffers, "often granting access only when the estimated age exceeds the legal threshold by 2-3 years".

That margin is called a buffer.

stop_reasoneval:.pass

The trial's age estimation report describes "a 'grey zone'" of "around 2–3 years on either side of the age gate", where uncertainty is higher. Its table for the 16+ gate says wrong passes tend to zero once the estimate reaches about 19 or 20, and people aged 12 or 13 are reliably rejected. Everyone in between is where estimation, on its own, cannot decide. The trial calls it "a fundamental misunderstanding" to treat estimation as an exact gate, and says that with a buffer, "false negatives will then be inevitable and alternative methods will be required to correct them".

Notice who lives in the upper half of the grey zone: 16-, 17- and 18-year-olds, the people the law says are allowed in. Every buffer decides how many legitimate teenagers you send to a second check. That is why eSafety says a buffer must be set "having considered" the "risk of unreasonably over-blocking users", and why "All age assurance methods should be backed by accessible, timely and accurate review processes." The review process is not a courtesy. For estimation, it is part of the method.

There is one more honest caveat. The trial's headline says systems performed "broadly consistently across demographic groups", but its detailed findings are less tidy. Part A reports that some systems "showed reduced accuracy for older adults, non-Caucasian users and female-presenting individuals near policy thresholds". Part D lists "increased false positives for users with darker skin tones or aged 16–20".⁷ So eSafety expects accuracy to be "evaluated and recorded across different cohorts" in the Australian context. If a vendor quotes one MAE for everyone, ask for the breakdown.

The trial found most estimation vendors used "temporary biometric processing with no image retention", and some ran the model on the device. They also run "presentation attack detection", which checks that a real face is in front of the camera and not a photo or a deepfake. Those frames are inputs too, and they belong in the same "destroy after use" pile as the selfie.

Inference: the clues you left lying around

Start with you again. Someone who has had the same email address since 2009 is not 14. A person in the Year 10 group chat probably is. You infer ages from context constantly.

Name it. eSafety calls this age inference: "probabilistic conclusions about facts other than a date of birth". The trial's inference report gives Australian examples: being on the electoral roll implies 18 or over; being enrolled in Year 9 implies "typically 13-15".

Now the machine. A platform already holds a great deal about its users. The OAIC's guidance, drawing on eSafety's list, names the kinds of signals a platform might use: the "age of account (e.g. the account has existed for 10 or more years)", "engagement with content targeted at children or early teens", "linguistic analysis", "visual content analysis (e.g. facial age analysis performed on photos and videos uploaded to the platform)", "audio analysis", and "connection with other end-users who appear to be under 16". A system weighs signals into a score, compares it with a threshold, and acts: leave the account alone, restrict it, or ask for a stronger check.

The trial found that strong, binary signals such as a "verified credit card transaction" were "considered more reliable than those based on broader behavioural trends", and weaker signals "like content engagement or account activity patterns" were typically combined or used as "early screening layers".

Now the mechanism that matters, which is legal. Here intuitions often go wrong, so here is the OAIC in its own words. The signals a platform already holds were collected for other purposes, so "s 63F will not apply to the original inputs". They stay under the ordinary Privacy Act, and the platform needs a lawful pathway under APP 6 to reuse them.⁸ But: "Where an entity uses inference methods to generate personal information (e.g. +/-16 score, pass/fail age flag, Australian resident flag), the resulting new artefact will be considered a collection of personal information and is subject to the restrictions in s 63F including purpose limitation and destruction".

The ingredients are old, but the cake is new. The moment a platform writes possibly_under_16 next to your account, that flag is a fresh collection. It can be used only for the age decision, it must be destroyed when that is done, and it must not leak into the advertising model, however tempting a list of "probably 15" accounts looks to someone in sales.

The OAIC warns that inference may "also result in the collection and retention of disproportionate amounts of personal information". Its advice is to prefer "non-content signals such as metadata and system data", to treat posts, groups, interests and communications as "higher privacy risk", to use "event-based, point-in-time checks", and to "avoid building long-lived behavioural profiles". With eSafety's rule against waiting months to gather data, inference has a narrow lane. It works best for the easy cases: the OAIC notes that for many users of long-standing platforms, account tenure alone may confirm "at a high level of confidence" that they are over 16.

page_viewtool_use

Stacking them: the waterfall

Nobody uses one method alone. eSafety encourages "successive validation", or a "waterfall": start with the least intrusive method, and move to a stronger one only for the cases it cannot decide. The OAIC says the same in privacy language: "Escalate to more intrusive personal information handling only as necessary." It adds a warning for the product team: "The fact that a particular age assurance method or combination of methods is available, convenient or desirable should not be relied on to establish necessity."

Part 4: The Photocopy Problem

utm_source=SELECT

The second bottle shop's attendant was not malicious. He was being careful, in case someone one day asked him to prove that he checked.

The trial found that instinct in the real market. Its main report says that "in the absence of specific guidance, service providers were apparently over-anticipating the eventual needs of regulators", and that some were "building tools to enable regulators, law enforcement or Coroners to retrace the actions taken by individuals to verify their age", which "could lead to increased risk of privacy breaches". The estimation report found some systems keeping more than a pass or a fail: "Estimated age scores (e.g. 17.2)", "Confidence values or probability distributions", and "Metadata about facial features used in the decision". Combined with session IDs, it warned, such data "could act as a quasi-profile".

The regulators want much less kept. eSafety: "eSafety does not expect providers to retain personal information as a record of individual age checks", and "Information about individual end-users, their unique age assurance checks or outcomes is not necessary to demonstrate the taking of reasonable steps." The regulator wants evidence that your system works—error rates, review numbers, audits—not a filing cabinet of faces.

Inputs are hot; outputs are cool

The OAIC turns this into a rule using the three piles from Part 1.

Inputs are "generally higher risk": document images, selfies, liveness videos, biometric templates. The instruction is short: "Process for the purpose of age assurance, then destroy immediately", "Do not store inputs 'just in case'", and "Ensure destruction covers caches and transient storage." Engineers forget that last one. The selfie leaves the database, but a copy sits in a debugging bucket or a crash report for six months.

Outputs are "generally lower risk": the binary outcome, the method, the provider ID, a timestamp and a "non-linkable" reference. These may be kept "strictly for limited purposes"—evidence of compliance, troubleshooting, complaints and reviews, fraud and circumvention—with "bright-line, limited retention windows". The OAIC's list of don'ts is specific: do not store "selfie frames, ID images, biometric templates or age scores/confidences that are no longer required".

Section 63F's destruction duty is also stricter than the general Privacy Act rule in APP 11.2, in two ways the OAIC spells out. First, "there is no allowance for de-identification". Under APP 11.2 you can often de-identify instead of destroying. Here you cannot. Second, "there is no allowance for retention just because there is another potential business use case". The OAIC calls the workaround by name—"purpose padding"—and rules out "broad, speculative or open-ended purposes" such as "product improvement, research". You cannot write "and to improve our models" on the form and keep the faces.

The OAIC recommends a ring-fence: a separate "SMMA environment" for the artefacts, documented to show "the inputs, transient processing, outputs, retention points and destruction paths", and able to destroy data "automatically and independently of other organisational data". In its worked example, the product team never sees the table. It calls a read-only endpoint that answers yes or no, and advertising, analytics and machine learning pipelines are blocked from the store. That is the whole architecture in one sentence: a small, sealed box of answers, and a read-only question for everyone else.

aria-labelgtm.js

The review path is where photocopies hide

The riskiest part of an age check is usually not the check. It is the appeal.

When estimation says "cannot confirm", a person who is actually 16 needs a way to prove it, often a photo of a document sent to a human reviewer. That photo is exactly the input s 63F wants destroyed, and exactly the file that ends up in a support ticket that nobody ever cleans out.

We have a recent example of what that costs. In October, Discord disclosed that an unauthorised party had breached 5CA, one of its customer support vendors, and that approximately 70,000 users "may have had government-ID photos exposed". Those were IDs "which our vendor used to review age-related appeals". Discord is not on Australia's list of ten platforms, and this says nothing about any Australian platform. But it shows the shape of the risk: the appeal ran through a ticketing system, and the documents stayed there.

So read the OAIC's guidance on reviews closely. Accept "redacted DOB evidence in a view-only bucket"; "destroy the document immediately after the decision"; do not keep "copies of documents or OCR text beyond the review". In its example, the reviewer sees only the date of birth, in a restricted console where "downloads are blocked", and the document is destroyed when the reviewer presses "Resolve". If your vendor's appeal process is "email us a photo of your licence", you have found your photocopier.

Reuse needs a separate yes

Finally, the temptation. A platform that has confirmed millions of people are over 16 holds something other services, and its own advertising team, would love to use.

Section 63F allows reuse only with that strict, "unambiguous" consent, and the OAIC's guidance describes what that looks like in practice: "Implement a separate consent flow dedicated to secondary purposes; do not bundle with the SMMA purpose", "Set defaults to 'off'", and "Do not bundle consent at sign-up or use pre-selected tick boxes." If you have read my piece on consent management, none of this is new in spirit. What is new is that for age assurance data, the strict version is the law.

Part 5: Proving You're 16 Without Proving Who You Are

So far we have talked about limiting the damage: collect less, destroy faster, fence off what is left. There is a better idea. Go back to the bottle shop one last time, and imagine you could hand the attendant a small card with no name, no address and no photo. It says only "over 18", and it carries a seal that he can check is genuine. He does not know who you are. The office that issued the card does not know which shop you went to. Each of them knows half the story, and nobody knows all of it.

That is not a fantasy. France's data protection authority, the CNIL, described exactly this model in 2022, and called it a "three-fold protection of privacy". The provider of the proof "knows the identity of the Internet user but does not know which site the latter is visiting", and the site "knows the age of the user (or just their majority)" but "does not know their identity". The proof's validity is guaranteed "by means of cryptographic signatures".

How the seal works. It is a digital signature, the same technology that secures your connection to your bank. The issuer—a bank, a telco, a government wallet—checks your age once, the hard way. It writes a tiny statement, "over 16", and signs it with its private key. The platform checks the signature with the issuer's public key, which anyone can hold. If it checks out, the statement is genuine, and the platform never needs to call the issuer. That is why the issuer does not learn where you used it.

The European Commission's age verification blueprint, released in July for pilots in Denmark, France, Greece, Italy and Spain, is built on this idea. Online services "will only receive a proof that the user is over 18, without any other personal details", the proof provider "will not be informed about the services where the proof is used", and "Each proof will only be used once."

That last rule is the subtle one. A token you reuse everywhere is a tracking identifier with good manners: five sites that see it can compare notes. One-time tokens stop that, and the Commission says work on "zero-knowledge proofs" is ongoing to make transactions harder still to link. The OAIC's guidance names the same risk from the other side. Among its "higher risk practices" is "logging tokens in a way that enables cross-service tracking", and its own example of good practice has a user share "a '16+' assertion only" from a bank-issued wallet card, with "no document numbers or dates of birth" shared.

There are two limits in Australia. First, s 63DB means that where the token comes from an accredited Digital ID service, it cannot be the only option; there must be a reasonable alternative. The privacy-best method is allowed, but it cannot be compulsory. Second, a token is only as private as the way it is stored and passed around. A platform that writes the token, your account ID and the issuer into a log line that goes to its analytics vendor has undone the whole design.

Part 6: Imogen's Three Days

Imogen turned 16 in October. She lives in Sorell and plays in her school's netball team. She is made up, and so is Pademelon, the photo-sharing app she joined in September. (If a phone asked you to blink at it this week, the next bit may feel familiar.)

Pademelon built its checks the way the guidance describes. Here is what each system records.

Wednesday 10 December. The minimum age takes effect. Pademelon's inference system runs over its Australian accounts. Imogen's account is young (three months), it is linked to an Australian phone number, and she follows her school's netball club. Pademelon deliberately does not read her messages or scan her photos; it uses account metadata first, as the OAIC recommends. The score lands in the "not sure" band. Pademelon writes a flag, possibly_under_16, into its ring-fenced store, and shows Imogen a notice that explains why she is being asked and offers her three ways to answer: a quick selfie check, a "16+" token from a digital wallet, or a review.

What exists now: the old account data, under the ordinary Privacy Act, and one new flag under s 63F.

Thursday 11 December. Imogen tries the selfie and turns her head for the liveness check. Because she is 16, the estimate lands in the grey zone. The vendor returns "cannot confirm", not a number. It destroys the selfie frames and the liveness clip, and sends Pademelon an attestation that it has done so. Pademelon writes a short-lived artefact: outcome, method, provider, timestamp, token.

What exists now: no face and no estimated age. Two small artefacts in a sealed box. Imogen is restricted, with a message that says the result is an estimate and she can try another way.

Friday 12 December. Imogen has no digital wallet credential, so she chooses the review. The app asks for a photo of her passport's details page, and masks every field except the date of birth before it leaves her phone. It goes to a view-only reviews area. A single reviewer, in a console that blocks downloads, sees the date, confirms she is 16 and presses "Resolve". The image is destroyed at that moment, with no copy and no OCR text kept. The flag and the "cannot confirm" artefact are replaced by one new artefact: 16_plus, method "review", timestamp, token. It has a retention period written down against each purpose it serves.

What exists now: one yes, in one box, with an expiry date. Pademelon's product code can ask the box one question—is this account 16 or over?—and get one answer.

Now run the same three days through the second bottle shop. On Wednesday, the inference system reads Imogen's captions and her friends' ages, and the score goes into her ad profile. On Thursday, the vendor keeps her selfie frames "for quality assurance", tagged 15.8 with a confidence of 0.62. On Friday, she emails her unmasked passport to a support address, where it sits in a ticket next to her name and suburb, forever.

Both platforms reached the same decision: Imogen keeps her account. Only one took reasonable steps.

How to Judge an Age-Check Vendor This Week

These are the questions I would put to any age-check flow. Each maps to a specific duty or finding.

1. What exactly do you send back to us? A minimal artefact: outcome, method, provider ID, timestamp, opaque token. Not a date of birth, an estimated age or a confidence score (OAIC guidance, sections 4.1 and 5.1).
2. What do you keep, where, and for how long? Ask for the retention schedule by data type, including caches, logs and backups. Inputs should be destroyed immediately (s 63F(3); OAIC section 5.1).
3. Will you put destruction in the contract and attest to it? The OAIC's example contract forbids keeping raw inputs and provides "destruction attestations".
4. Do you use any data from our checks to train or improve your models? If the answer is yes without a separate, opt-in, default-off consent, that is purpose padding (s 63F(1) and (2); OAIC section 5.2).
5. Where does the flow stop if the user will not show government ID? There must be a reasonable alternative that does not involve government ID or an accredited Digital ID (s 63DB). Test this path yourself.
6. What buffer is configured at the 16+ gate, and who chose it? Ask for the estimated-age band that passes, the band that fails and the band that escalates, with the vendor's error rates at 16, 17 and 18 (trial Part D; eSafety section 2.3.1).
7. What are your error rates by cohort, on Australian users? Skin tone, gender and age bands near the threshold, not one headline MAE (eSafety section 2.3.3; trial Part D, D.8.11).
8. What happens in a review, and what does the reviewer see? Look for DOB-only redaction, a view-only store, blocked downloads and destruction on decision. If the appeal is an email address, stop (OAIC sections 5.1 and 5.3).
9. For inference, which signals do you use, and do you read content? Prefer account metadata. Treat posts, messages and photos as higher risk. Check there is a documented APP 6 pathway for reusing existing data, and that the resulting flag is ring-fenced (OAIC section 4.3).
10. Can tokens be linked across services? They should be single-use or scoped to one relying party, and never written to logs that other systems read (OAIC section 4.1; European Commission blueprint).
11. Is the flow explained in plain language, at the moment it matters? eSafety expects alignment with WCAG 2.1. The OAIC expects just-in-time APP 5 notices on what is collected, why, by whom, for how long, and the choices.
12. Have you done a privacy impact assessment for this method, and can I read it? The OAIC recommends one when choosing a method. Check that it covers the liveness frames too.

If you are a user or a parent, the short version is this. You can choose a method that does not use your ID. You can ask the platform what it keeps. And if it has kept or reused what it should have destroyed, the OAIC says to complain to the platform first, and then to the OAIC. When I wrote about the Privacy Act overhaul in 2023, most of the rights on the table were proposals. For age assurance data, this one is already law.

Final Thoughts

Think back to the first bottle shop. The attendant saw a dozen facts, used one and forgot the rest before the bag was packed. That was a habit, not a technical achievement, and it was the whole reason we trusted him with our licences.

The minimum age asks platforms to learn that habit at national scale, and for once the rules are specific. The question has one bit of answer. The face, the document and the score are inputs, and inputs are destroyed. What survives is a small, sealed yes or no, with an expiry date and nothing that points back to who you are. As of December 2025, the trial says this can be done privately, and the OAIC has said, in writing, that it will be watching to make sure it is.

If you run or buy one of these systems, do one thing this week. Ask your vendor for two documents: the exact schema of what it sends you after a check, and its retention schedule for everything else. If either document contains a face, a date of birth or an estimated age, you have found your photocopier.

Now, if you'll excuse me, the kettle has boiled. It did not ask how old I am, and it has never kept a copy of my face. That is one of the many reasons I trust it with about 1,820 cups of tea a year.⁹

Notes

1. The ABC rounded the maximum to "up to $50 million". eSafety's guidance gives the exact basis: 150,000 penalty units for a body corporate, "currently the equivalent to $49.5 million", at $330 a unit as at September 2025. ↩

2. The APP guidelines already describe consent as informed, voluntary, current and specific, given by someone with capacity. Section 63F adds "unambiguous" and the right to withdraw easily, which is why an opt-out or a pre-ticked box cannot work for age assurance data. ↩

3. Small businesses with an annual turnover of $3 million or less are usually exempt from the Privacy Act. The OAIC's guidance says s 63F applies to them anyway when they handle personal information for the minimum age, so a small age-check vendor is covered. ↩

4. The absolute value is the point of the word "absolute". A model that guesses 15 for one 16-year-old and 17 for another has an MAE of exactly one year and a perfect average of 16, while being wrong about both of them. ↩

5. Yoti's figure comes from its own white paper, not from an independent test. The trial measured vendors under its own test conditions, including field trials in Australian schools. The two numbers come from different people under different conditions, so they cannot be compared directly. ↩

6. NIST also found that error rates "were almost always higher for female faces than for males", a pattern that held in its 2014 tests, and said "the underlying reasons are unknown". It makes no recommendation on whether any software is fit for a particular use. ↩

7. The trial grouped its test subjects by the Fitzpatrick scale, a dermatology classification with six skin types from very fair to very dark. It explains that darker skin absorbs more light, which reduces the contrast a camera captures. ↩

8. The OAIC lists three possible APP 6 pathways for reusing data a platform already holds: the person's consent, a use the person would reasonably expect that is related to the original purpose, or a use required or authorised by law, which here means s 63D itself. ↩

9. Five cups a day, give or take. None of them has ever asked for proof of age, although a few of the stronger ones probably should. ↩