I am building WhyWave, a voice AI companion for children aged three to five. A child asks a question out loud, the system answers out loud, and the parent configures in advance what language to use and where the boundaries sit on difficult subjects.
Before writing any product code, I sat down and read the rules. Primary sources: 16 CFR Part 312 on eCFR, the regulations on EUR-Lex, the Commission's guidelines, Apple's and Google's policies, and the terms of service of the model vendors. I had already read the summaries and the law firm blog posts by then, and they turned out to be worth very little.
Almost everything published on this subject falls into one of two shapes. Either marketing that promises "full compliance", or a legal wall of text that leaves an engineer with no decision they can act on. Several things that determine the architecture of the product appear in neither.
On the child's voice
Under COPPA, personal information includes the following. Quoting § 312.2, paragraph 8 of the definition:
A photograph, video, or audio file where such file contains a child's image or voice
An audio file of a child speaking is personal information on its own. It needs no name attached and no device identifier.
The FTC's position is that collection is complete the moment you gather the file. Deleting it afterwards leaves the fact of collection intact.
There is a consequence worth absorbing before you start. The obligation attaches during the first second of the first sentence. Before the user database exists, before conversation history, before everything people usually treat as the moment they start handling personal data.
On the voice exception
The rule contains one exception that reads as though it were written for voice. Until 2025 it lived as an FTC enforcement policy statement from 2017, and the 2025 amendments wrote it into the text itself, at § 312.5(c)(9).
It waives parental consent when four conditions hold at once. You may collect audio and nothing beyond it, no other personal information whatsoever. You may use it solely to respond to the child's specific request. You may disclose it to no one. You must delete it immediately once the response has been given. On top of that you need an online notice under the new § 312.4(d)(4) stating what you use the audio for and that you delete it right away.
Reading this the first time, I was delighted. Then I read it again.
A companion that remembers the child between turns breaks the fourth condition. One that remembers across sessions breaks it more thoroughly. One that ties the audio to a device or account identifier breaks the first. One that sends audio to a third-party cloud ASR runs into the third.
The exception was written for a voice command. "Turn on the light", "set a timer for five minutes". In WhyWave, memory is the product: the system has to recognise the child, remember what they asked yesterday, and adjust explanations to what they have already grasped. On no reading does that design fit inside the exception.
This is the first item on the list that changes the architecture itself. If you are building a voice companion for children, hiding behind the voice exception is unavailable to you, which means verifiable parental consent and everything that trails behind it.
On the minimum before the first word
Start with the age gate, because a lot of people are counting on it.
There is a concept called mixed audience: a service with a mixed audience may ask for age and treat children differently from adults. A product for three to five year olds does not qualify. It counts as primarily child-directed. The FTC's age verification statement of 25 February 2026 says plainly that such operators must treat all users as children. Asking for a date of birth and sorting it out from there will not work here.
Now the actual list of what you need, with references to the rule text:
| What | Where |
|---|---|
| Online privacy notice with five required elements | § 312.4(d)(1)–(5) |
| Direct notice to a parent before collection | § 312.4(c)(1) |
| Verifiable parental consent | § 312.5(b) |
| Separate consent for third-party disclosure | § 312.5(a)(2) |
| Written information security programme, five elements | § 312.8(b) |
| Written assurances from every vendor touching the data | § 312.8(c) |
| Written and published data retention policy | § 312.10 |
One detail about consent gets misreported constantly. § 312.5(b)(2) lists methods for obtaining it, and that list is often presented as closed. The binding criterion is § 312.5(b)(1): the method must be "reasonably calculated", meaning reasonably calculated to ensure that the person giving consent is the parent. The list illustrates that criterion, and § 312.5(b)(3) together with § 312.12(a) describe how a new method gets approved.
The maximum civil penalty today is $53,088 per violation. The FTC has published no 2026 inflation adjustment, so the January 2025 figure still stands.
On the AI Act timeline
If you are carrying last year's dates in your head, update them.
Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and entered into force on 27 July. It rewrote Article 113 and moved the obligations for Annex III high-risk systems from 2 August 2026 to 2 December 2027.
Article 50 on transparency stayed where it was. It has applied since 2 August 2026, which means today.
You have to tell the user they are talking to an AI. The article carries a caveat for cases where this is obvious anyway, and the Commission's Article 50 guidelines (content approved 20 July 2026, C(2026) 5054 final) put it this way:
the exception cannot be relied upon in order to protect those vulnerable users efficiently
Where children are among the audience, obviousness is off the table.
The same guidelines say that for companions, a single message at first launch falls short. Periodic reminders are expected.
One requirement usually gets missed here. Article 50(2) obliges you to mark synthetic output in machine-readable form. For a voice product that means marking the audio itself as generated, which a line in the interface will not do.
On Article 5
Article 5 of the AI Act lists prohibited practices, and it was the part I least wanted to find. Paragraph 1(b) prohibits systems that exploit a person's vulnerability, including vulnerability due to age, where this causes significant harm.
The Commission published guidelines on prohibited practices, C(2025) 5052 final, dated 29 July 2025. Watch the number: the web is full of citations to C(2025) 884. That number belongs to a draft, and the adopted document carries a different one.
The guidelines give this as an example of a 1(b) violation:
An AI system that is designed in an anthropomorphic way and simulates human-like emotional responses in its interactions with children
The condition that makes it a violation appears alongside: the system fosters unhealthy emotional attachment.
And in the same document, the same design appears as lawful where it causes no significant harm.
Anthropomorphic design and simulated human emotional responses in interactions with children describe an entire product category, WhyWave included. What makes the design lawful or prohibited is whether it produces dependency.
The line therefore runs through engineering decisions. How strongly the system rewards coming back. Whether it can end a conversation. What it says when a child tells it they love it. No lawyer will hand you a document that closes this question, because the question sits outside documents.
On biometrics
One distinction here decides the architecture.
A system that recognises emotions on the basis of biometric data lands in Annex III and becomes high-risk from 2 December 2027. The definition in Article 3(39) hangs on the phrase "on the basis of their biometric data".
Vocal prosody is a biometric signal. Inferring emotion from text a person wrote themselves is expressly carved out by the Commission's guidelines: sentiment analysis of written text does not count as emotion recognition.
So if the pipeline runs ASR, then text, then the model concludes "the child sounds upset" from the words, the classification appears to miss.
That reading is an argument, and it has not become a safe harbour. No regulator has addressed emotion inference from a transcript of a child's speech, and the counter-argument carries weight, since the transcript derives from biometric input and the purpose of the system is to adapt to mood. This is a question for counsel to answer.
The other half of the same subject is Article 9 GDPR, where people routinely get it backwards.
Cloning a parent's voice for playback is ordinary personal data. Speaker recognition is special category data under Article 9.
Article 4(14) draws the line: biometric data means data whose processing allows or confirms the unique identification of a person. The purpose of the processing decides which of the two you are doing. Synthesising a voice and identifying someone by their voice are different things as far as the regulation is concerned.
Worth knowing, incidentally, that the term "GDPR-K", which circulates through vendor blogs and slide decks, does not exist. It appears nowhere in Regulation 2016/679. People use it informally for Article 8. The industry invented itself a statute and now cites it in marketing material.
A data protection impact assessment is effectively mandatory for a product like this. The EDPB's guidelines on voice assistants say such services are very likely to fall into the categories requiring a DPIA, and a children's product hits several criteria at once: vulnerable subjects, innovative technology, sensitive data.
On the UK
The Children's Code, formally the Age Appropriate Design Code, is a statutory code under section 123 of the Data Protection Act 2018.
The ICO on what happens if you ignore it:
if your online service fails to conform to a provision of this code you may find it difficult to demonstrate compliance with the law and you may invite regulatory action
Standard 14 of the code covers connected toys and devices, and it offers an example. The example is a talking teddy bear with a microphone.
On top of that, section 81 of the Data (Use and Access) Act 2025 inserted Article 25(1A) into the UK GDPR, which from 5 February 2026 turned part of the code into a direct statutory duty.
On model vendors
I found this in no material on the subject, though in practice it is the first thing a product trips over.
The Gemini API Additional Terms, effective 23 March 2026, and Google Cloud Service Specific Terms § 20.d prohibit using Google's generative services as part of a service that
is directed towards or is likely to be accessed by individuals under the age of 18
A voice companion for three year olds breaches its supplier agreement before it ever reaches app review.
OpenAI and Anthropic took the opposite route and published conditions for serving minors. OpenAI requires zero data retention when processing personal data of children under thirteen and reserves audit rights. Anthropic requires age verification, moderation, monitoring, and disclosure that the counterpart is an AI.
For a children's product, compliance requirements decide the choice of model, ahead of latency, price and benchmark position.
On app stores
Rule 1.3 of the App Store Review Guidelines, for apps in the Kids Category:
may not send personally identifiable information or device information to third parties
A child's voice is personal information under § 312.2(8). A cloud pipeline with external ASR, LLM and TTS conflicts directly with that rule. On its own developer page Apple softens the wording with a caveat about explicit parental consent, and Apple has not reconciled the discrepancy.
Rule 2.3.8 closes the obvious workaround: the words "For Kids" and "For Children" are reserved for the Kids Category. Meanwhile products already on sale sit outside that category with a 4+ rating. The path everyone takes is a violation on paper.
A curious detail: neither Apple's guidelines nor Google's Families policy contains a single rule specific to AI in children's apps. Both put the hook somewhere else. Apple uses the age rating questionnaire, which asks you to account for how AI assistant and chatbot functionality affects sensitive content. Google uses its generative content policy, which requires an in-app reporting mechanism.
On state laws
Washington's ESHB 2225 takes effect on 1 January 2027. For minors it prohibits reminders and prompts to return for emotional support or companionship, excessive praise designed to foster emotional attachment, and outputs promoting exclusive reliance on an AI companion for emotional support. Three provisions, each describing retention mechanics that come built into this product category by default.
California's SB 243 has been operative since 1 January 2026, New York's General Business Law Article 47 since 5 November 2025.
Worth adding that on 11 September 2025 the FTC issued 6(b) orders to seven companies operating consumer AI companion chatbots, and the questions there cover children and COPPA compliance directly.
On what to do with all this
WhyWave has not launched. Everything above came out of reading before writing product code, which is exactly why it might be useful to someone else.
Several of these rules resist being bolted on as a checklist before release. The voice exception either shapes your memory architecture or does nothing for you. Your choice of model vendor opens or closes entire markets. Emotional attachment is settled by how the dialogue is written.
The calendar needs rechecking every few months. In the time I spent studying this, both the AI Act deadlines and Google's rules on minors changed.
The temptation to put a "COPPA compliant" badge on your landing page is strong. Unsubstantiated compliance claims fall under Section 5 of the FTC Act as deceptive, separately from COPPA itself. The WhyWave site carried such a badge. I took it down.
All references are as of 11 September 2026. This is not legal advice. If you are building something in this space, a paid hour with a children's privacy specialist pays for itself faster than you would think.