A child-focused AI toy is not only a physical toy with a microphone. It can also involve an app, cloud account, speech recognition, an AI model, text-to-speech, conversation history, selected memory, device logs and third-party service providers.
For brands planning to sell an AI plush toy or interactive robot in Brazil, this creates an important product-development question:
What data moves through the system, why is it needed, who processes it and what control do parents have?
Brazil's Lei Geral de Proteção de Dados Pessoais, or LGPD, provides the legal framework for personal-data processing. Article 14 gives specific attention to children and adolescents and requires processing to be carried out in their best interests. It also addresses clear information, parental or legal-guardian involvement and limits on collecting more information than an activity requires.
This guide is a product-planning checklist for buyers and development teams. It is not legal advice, and it does not mean that choosing a particular module, cloud platform or data center automatically makes a finished product LGPD-compliant.
Begin with the Complete Data Flow
Before evaluating consent language or a privacy policy, map the actual technical path.
A connected voice toy may use a flow such as:
Child speaks → device microphone → connectivity layer → speech recognition → AI Agent or language model → text-to-speech → toy response
Other services may operate around that main path:
- account registration and parental verification,
- device binding and app controls,
- conversation history,
- selected long-term memory,
- safety filtering,
- device and security logs,
- analytics,
- firmware updates,
- and customer-support records.
The finished data map should identify each service, the type of data it receives, its purpose, storage or retention behavior, processing region and the organization responsible for it.
Separate Four Different Voice-Data Layers
Buyers often use the phrase “voice data” as if it describes one item. In practice, at least four different layers may exist.
1. Raw voice audio
This is the audio captured by the microphone. A project must verify whether it is processed only in transit, retained temporarily, stored for troubleshooting or retained for another stated purpose.
2. Transcript or conversation history
Speech recognition may convert audio into text. The resulting transcript is different from the original audio and may have its own retention, access and deletion rules.
3. Extracted memory
An AI system may save selected facts or preferences for future personalization. This is not necessarily the same as retaining an entire conversation. Buyers should define what can be remembered, for how long and how a parent can review or delete it.
4. Voiceprint or cloned voice
A voiceprint used for identification and a synthetic voice created from recordings are separate from ordinary speech-to-text processing. They can introduce additional biometric, consent, rights and security questions. A normal TTS voice selected from an approved library should not be described as voice cloning.
These layers should never be combined into one vague statement such as “voice is saved securely.” Each one needs its own confirmed answer.
Design for the Child’s Best Interests
LGPD Article 14 states that processing children's and adolescents' personal data must be carried out in their best interests. For a commercial AI toy, this principle should influence the product architecture, not only the final legal notice.
A practical review should ask:
- Is each requested data field necessary for the core experience?
- Does the AI avoid asking children for addresses, school details, phone numbers or other unnecessary identifiers?
- Is the AI identity explained clearly rather than presented as a real human?
- Can the product work with less data or a shorter retention period?
- Are explanations understandable to parents and appropriate for children?
- Can a parent disable, unlink or delete relevant functions and data?
The strongest first version is often not the version that collects the most information. It is the version that delivers the intended experience with the smallest justified data footprint.
Parental Notice, Consent and Verification
Article 14 includes requirements concerning specific and prominent consent from at least one parent or legal guardian for processing children's data, together with reasonable efforts to verify that the consent came from the responsible adult. The correct legal basis and implementation should be reviewed for the actual product and service.
From a product perspective, buyers should confirm:
- who creates the account;
- how the adult is informed before activation;
- what data types and purposes are presented;
- how the adult's authority is verified where required;
- how consent or another applicable basis is recorded;
- how preferences can be changed later;
- and what happens if the adult does not agree.
A generic checkbox inside an app is not a complete child-data strategy. The account flow, product instructions, privacy notice and technical configuration need to support the same decisions.
Retention and Deletion Must Be Defined by Data Type
LGPD addresses the end of processing, deletion and data-subject rights. A buyer should therefore avoid asking only, “Can data be deleted?”
The more useful questions are:
- Which data can the parent see?
- Which data can be deleted directly in the app?
- Does deletion cover raw audio, transcripts, memory and account data?
- How is deletion communicated to processors or other service providers?
- Are backups affected immediately or through a documented lifecycle?
- Which limited records must be retained for legal, security or operational reasons?
- What happens when the toy is transferred to another family?
Retention periods should follow a stated purpose. Conversation history, security logs and device-maintenance records do not automatically need the same period.
Identify the Controller, Processor and Service Chain
An AI toy project can involve the brand, manufacturer, app provider, IoT platform, cloud host, ASR provider, AI-model provider and TTS provider. Their roles are not determined only by what they are called commercially; they depend on who decides the purpose and essential means of each processing activity.
The buyer's due-diligence file should identify:
- the likely controller or controllers,
- processors acting on their instructions,
- relevant subprocessors,
- the service performed by each party,
- applicable data-processing agreements,
- security and confidentiality obligations,
- change-notification arrangements,
- and deletion or return obligations when service ends.
Public platform documentation can help explain an architecture, but it may not identify every provider used in one specific commercial deployment. Deployment-specific documents should be requested before making final claims.
Data Center Selection Is Not the Whole Answer
A regional data center can be an important deployment choice, but it does not by itself prove where every data layer is processed.
The project may need to distinguish:
- app-account region,
- IoT device region,
- primary database location,
- ASR processing,
- AI-model processing,
- TTS processing,
- operational logs,
- analytics,
- support access,
- and backups.
Some of these services may be delivered by different providers. Therefore, a statement such as “the app uses a selected regional data center” should not be expanded into “all data always remains in that country” unless the complete service chain has been verified.
For Brazilian deployment, the team should also review applicable international-transfer requirements and the contractual or legal mechanisms used for transfers.
Do Not Confuse Service Operation with Model Training
Another common buyer question is whether children's conversations will be used to train AI models.
The answer must come from the applicable commercial service terms and the confirmed deployment—not from assumptions about a consumer chatbot.
The review should separate:
- processing needed to generate a response,
- temporary safety or abuse monitoring,
- operational logging,
- product analytics,
- service improvement,
- and model training.
These are different purposes. If the project cannot verify a purpose and its terms, it should not publish a simple yes-or-no promise on behalf of every provider.
Platform Capability Is Not Finished-Product Compliance
An established IoT or AI platform may provide parental controls, regional infrastructure, security functions, retention settings or child-safety features. Those capabilities can reduce development risk, but the finished product still depends on its actual configuration.
The final review should cover:
- selected product identifier and cloud region,
- enabled AI Agent and model,
- child-safety configuration,
- parent-app functions,
- data and memory settings,
- firmware and OTA process,
- physical toy safety,
- destination-market documentation,
- packaging and instructions,
- and the brand's own privacy and support processes.
It is safer to state “this capability is available for project configuration” than to state that every product automatically includes or satisfies it.
A Practical Pre-Production Checklist
Before mass production, a Brazil-focused child AI toy project should be able to answer the following questions in writing:
- What exact data enters the system?
- Which data is required and which is optional?
- What are the purposes for each data type?
- Who is the controller, processor and relevant subprocessor?
- Where is each service performed?
- What is stored and for how long?
- How does a parent exercise access, correction, deletion or consent choices?
- Does the product create memory, a voiceprint or a cloned voice?
- Are conversations used for any purpose beyond providing and securing the service?
- Which child-safety and parent-control functions are enabled in the commercial configuration?
- What happens when an account is closed or a toy is transferred?
- Which answers still require written confirmation from the platform or service provider?
This checklist turns a broad compliance discussion into concrete product decisions.
What EmotiToy Can Confirm During Development
For an OEM/ODM project, EmotiToy can help organize the physical product and integration questions: toy structure, electronics placement, microphone and speaker integration, connectivity, movement, sensors, charging, controller selection, product configuration and the path from demo to production.
Cloud, AI-model, data-retention and legal claims must remain tied to the selected platform and confirmed commercial deployment. Where a capability has not been verified for the project, it should remain marked as requiring confirmation rather than being presented as a finished-product promise.
That distinction protects both the buyer and the manufacturer while keeping the project focused on what can actually be engineered, documented and delivered.
Related EmotiToy Resources
- What Is Tuya Child Safety Mode?
- AI Toy Memory, Privacy and Child Data
- Regional Data Centers for AI Toy OEM Apps
- What a Parent App for an AI Toy Should Control
- AI Robot Toy OEM/ODM Development
Official Sources
- Brazil — Lei Geral de Proteção de Dados Pessoais (Law No. 13,709/2018)
https://www.planalto.gov.br/ccivil03/ato2015-2018/2018/lei/l13709.htm
- Brazil ANPD — Data Subjects, Controllers and Operators
https://www.gov.br/anpd/pt-br/assuntos/titular-de-dados
- Tuya Child Safety Mode
https://developer.tuya.com/en/docs/iot/security_compliance?id=Kfezdig2xq0x9
- Tuya Data Center Introduction
https://developer.tuya.com/en/docs/iot/DataCenterIntroduction?id=Kav2hlac2ppnw
- Tuya Data Privacy Trust Center
https://www.tuya.com/trustcenter/data_privacy
