Parental controls are a hardware decision, not a settings page

The privacy page of a children’s AI toy is usually written last, by the marketing side, and it describes the app. The actual privacy of the product was decided months earlier, on a schematic, when someone chose whether the microphone shares a power rail with the always-on wake engine.

Three examples of the gap, from designs we have been handed to fix.

The mute that wasn’t

A product with a mute button in the app and a switch on the shell. On the schematic, the microphone bias and the wake engine ran from the same rail, and the switch toggled a register. So the microphone kept sampling whenever the board was awake, and the “mute” controlled only whether samples were sent. To the user, nothing. To a reviewer with a scope: the circuit listens at all times. The fix — a switch in series with the microphone supply, plus a codec mute pin that gates the digital path — took an afternoon of routing and a second revision of one small board area. It should have been a requirement, not a patch.

The wake word in the cloud

The cheapest silicon for keyword spotting is none: stream audio to a server and detect the wake word there. Accuracy is excellent. But the property the brand then has to defend is that a child’s bedroom audio reaches a data centre before the toy has been asked anything. For some adult products that is defensible. For a bedtime plush it usually is not, and retrofitting an on-device wake engine means a new board, not a firmware update. Decide the wake architecture when the product is a block diagram; it is the one decision that cannot be patched in.

The audio column

A backend with a column for raw audio “for quality improvement”. Every conversation, from every child’s room, sitting in a table. The defence offered was a retention policy in a document. The fix was a schema change: transcripts with an expiry, audio released from the buffer as soon as recognition returns, the child’s profile holding a nickname. Data minimisation is not a policy paragraph. It is either true in the database or it is false everywhere else.

What this means for a development project

Put the controls on the requirement sheet as hardware items, not app items: a mute switch that opens the circuit, a wake word that runs locally, a data model with no raw-audio column, transcripts the parent can read and delete. Then put the sentence on the box in the parent’s language — “it waits for its name, and only then listens” — because that sentence has to survive a teardown by someone who does not trust you.

None of this is expensive at requirement-sheet stage. All of it is expensive after tooling.