The 2026 COPPA rule, explained for toy makers
What changed in the COPPA Rule on April 22, 2026: voiceprints, separate consent for AI training, retention limits, and how a toy team ships compliant flows.
April 22, 2026 has come and gone. That was the day full compliance with the updated COPPA Rule came due, sixteen months after the FTC finalized the amendments, and the Toy Association flagged the deadline well in advance. If you make a toy with a microphone, the rule now describes your product in some detail.
We build an operating system for AI toys, so we have lived inside this rule for a while. This is the plain version for product and legal teams at toy and nursery brands: what actually changed, why a conversational toy cannot route around it, what the states are adding on top, and a checklist you can take into your next planning meeting.
What changed on April 22
COPPA dates from 1998. It covers online services that collect personal information from children under 13, and a connected toy is an online service. The 2025 amendments are the first major rewrite since 2013. Four changes matter most if you ship toys.
A voiceprint is now personal information
Audio files containing a child's voice already counted as personal information. The amended rule goes further. Biometric identifiers now count too, and the list explicitly includes a voiceprint: the mathematical pattern that can recognize a specific child's voice. You cannot compute the embedding, delete the recording, and call what remains anonymous. The fingerprint of the voice is regulated like the voice itself.
Training AI on children's data needs its own consent
This is the change aimed at products like ours. Verifiable parental consent now comes in layers. The consent that lets the toy function does not cover what happens downstream. Using children's data to train or improve an AI model requires its own separate verifiable parental consent, and sharing data with third parties beyond what the service needs sits behind the same kind of separate consent. A checkbox buried in signup does not count. Neither does a clause in the terms.
Retention now has a clock
You may keep a child's personal information only as long as reasonably necessary for the specific purpose you collected it for. Indefinite retention is expressly out. The rule also wants a written, public retention policy: what you collect, why, and when it gets deleted. Holding voice recordings in case they prove useful later is precisely the habit this amendment was written to end.
Security must be a written program
Every operator needs a written children's data security program. Not a value statement. A document with a named owner, risk assessments, safeguards matched to the sensitivity of what you hold, and at least an annual review. Voice data from four-year-olds sits near the top of any sensitivity scale, and the program is expected to reflect that.
Put together, the rule starts to sketch a product architecture: consent before collection, a known path for every recording, deletion that works, and training behind its own gate. Here is what that architecture looks like when it is actually built.
The microphone is the product
A conversational toy cannot scope its way out of this rule. The microphone is the product. The moment a child speaks to it, you are collecting voice data from a child under 13, and the full rule applies. There is no anonymous mode for a toy whose entire job is to understand what a child just said.
Three consequences follow for anyone building one.
- Consent precedes function. The toy must stay inert until a parent completes verifiable consent in an app you control. Design for the unconsented state: a toy in a box on a birthday morning, surrounded by impatient people.
- Every utterance needs a lifecycle. Capture, transcription, storage region, retention clock, deletion. If you cannot trace one recording end to end, you cannot show compliance for any of them.
- You are the operator, even with a vendor inside. If a white-label voice module ships audio to a cloud you have never audited, in a country you did not choose, the FTC's questions still come to you. Outsourcing the stack does not outsource the liability.
The track record here is not encouraging. PIRG's researchers tested AI toys and found weak parental controls and chatbots drifting into topics no toy should go near. A toy can fail that test and still be on shelves today. The rule exists because that kept happening.
The states are not waiting
COPPA is the federal floor, and the states are building on top of it. Maryland passed its AI Toy Safety Act, the first state law aimed squarely at AI in children's toys; Crowell's alert calls it state regulation filling the federal void, which is exactly what it is. Similar bills are moving in other legislatures, and the Toy Association tracks them session by session.
Privacy law has run this play before. One state moves, others copy it, and the strictest version becomes the de facto national spec, because nobody ships fifty variants of one teddy bear. The practical answer is unglamorous: build once, to the strictest plausible standard, and let the statutes catch up to your product instead of the other way around.
Selling outside the US
Two more regimes matter for a global brand. In the EU, the GDPR requires parental consent for children below the digital age of consent, which member states set between 13 and 16, and the EU AI Act separately bans AI that exploits children's vulnerabilities; researchers are already mapping what that means for connected child devices. In India, the DPDP Act draws the line at 18, higher than anywhere else: verifiable parental consent for every minor, and no behavioral tracking or targeted advertising aimed at children at all.
Three regimes, one workable design rule: make the parent the account owner, keep each region's data in that region, and make deletion real rather than a support ticket.
A working checklist
First, the disclaimer, in plain words: this is not legal advice. We build toys, not briefs. Take this table to your counsel and have them mark it up before you ship anything.
The flows we actually shipped
That table doubles as a description of PlayOS, because we built the OS by working through the same list. PlayOS is free for partners and ships with the voice engine, safety filters, over-the-air updates, the parent app and an SDK, in 10+ languages. The compliance flows below are part of the OS, not paid add-ons, and the diagram above is the production data path rather than a roadmap slide.
- Consent at onboarding. The parent app runs verifiable consent before the toy says a word. No consent, no conversation.
- Region-pinned residency. US data stays in the US, EU data in the EU, India data in India.
- One-tap delete. A parent deletes their child's data in one action from the app. That is the whole flow.
- Training consent is separate and opt-in. Our Voice SLM, a sub-1B model arriving Q4 2026, is trained only on parent-consented, kid-safe conversations. The training ask is its own consent, apart from signup.
- No ads, no data resale, ever. There is no advertising layer in PlayOS and no data broker behind it, which removes the third-party disclosure problem at the root.
- A kill-switch that works fleet-wide. Every PlayOS toy takes OTA updates, and we can switch off a capability across all of them if red-teaming or field reports call for it. Red-teaming is a release gate for us, not a press release.
Underneath those flows sits the rest of the safety stack: on-device and cloud filters, age-graded responses, and no open internet access from the toy. None of this is slideware. Lumi, our companion toy, is live with ten families today. Lori, our baby monitor, is production-ready.
For a partner brand, integration takes four to six weeks, and these flows arrive already built. The deadline has passed. The brands that treat it as a product question rather than a paperwork question are the ones parents will end up trusting, and in this category, trust is the whole market.