Documentation Index
Fetch the complete documentation index at: https://docs.bragi.com/llms.txt
Use this file to discover all available pages before exploring further.
Bragi AI handles user voice data through a privacy-first architecture built on three principles: no data is captured without explicit user consent, data is stored in the user’s jurisdiction rather than a centralised location, and users retain granular control over which services can access their interaction history at any time. Privacy compliance is not a post-launch consideration for the Bragi platform — it is a launch requirement that is designed into the architecture before any data-collecting feature is enabled.
Why voice data privacy requires architectural decisions
Voice data is among the most sensitive categories of personal data a product can collect. It captures not just commands and queries but context, tone, environment, and the content of conversations that users may not intend to be recorded. The regulatory frameworks governing voice data — GDPR in Europe, CCPA in California, PIPL in China, and emerging AI-specific regulations globally — reflect this sensitivity with requirements that are more stringent than those applied to most other data categories.
Meeting these requirements is not achievable through a privacy policy update or a consent banner added at launch. It requires architectural decisions made before the product is built — about where data is stored, how consent is collected and managed, what happens when a user withdraws consent, and how data is isolated between users, brands, and services.
Platforms that treat privacy as a compliance checkbox rather than an architectural foundation create products that are legally exposed in regulated markets and commercially exposed when data incidents occur.
The Bragi consent architecture operates on an opt-in model. No voice data is captured until the user explicitly consents to it. The consent is granular — users can grant access to specific services and capabilities while denying access to others, rather than making a single all-or-nothing consent decision.
The consent flow is presented during product onboarding in language appropriate to the user’s jurisdiction. Users in the EU are presented with GDPR-compliant consent options. Users in jurisdictions with distinct requirements receive consent flows adapted to those requirements. A single consent architecture does not apply uniformly across all markets — the platform adapts to the regulatory requirements of each user’s location.
Users can review and modify their consent decisions at any time through the companion app. Withdrawing consent stops data collection immediately. Data collected prior to withdrawal is subject to the user’s deletion rights under applicable regulations.
How data residency works
User data is stored in infrastructure aligned to the user’s jurisdiction. Data about EU users is stored in EU infrastructure. Data about users in other jurisdictions follows the data residency requirements applicable to those regions. Data does not transfer across jurisdictional boundaries without a legal basis that meets the requirements of the relevant regulatory framework.
This architecture means a product sold globally does not create a single centralised data store that requires universal compliance with the strictest applicable standard. Each user’s data is governed by the framework relevant to their location, managed in infrastructure appropriate to that location.
What users control
Users on Bragi-powered products have three levels of control over their voice data and interaction history.
Consent management — the ability to grant or withdraw consent for data collection at any time, with immediate effect. Withdrawal stops new data collection. It does not retroactively alter data collected under a prior valid consent, but it triggers the user’s right to request deletion of previously collected data.
Service access permissions — the ability to grant specific services access to interaction history while denying others. A user can allow a music service to use listening history for personalisation while preventing a productivity tool from accessing the same data. Permissions are managed at the service level rather than as a binary all-or-nothing setting.
Data deletion — the right to request deletion of collected data under applicable regulations. The platform’s compliance architecture supports deletion requests in a manner consistent with GDPR Article 17 and equivalent provisions in other jurisdictions.
How Bragi handles data on behalf of brands
The Bragi platform manages data on behalf of the brands and ODMs that build on it. Brands do not need to build their own data infrastructure, consent management systems, or compliance frameworks independently. These are platform capabilities that brands inherit when they integrate.
This creates a clear responsibility model. Bragi maintains the technical and operational infrastructure that makes privacy compliance possible. Brands configure the consent flows and service permissions appropriate for their products and markets. Users exercise their rights through the brand’s companion app, with the platform handling the underlying data operations.
What is not yet public
Two aspects of the Bragi privacy architecture are not detailed in this documentation because they are subject to ongoing development and legal review. The specific certifications the platform holds — SOC 2, ISO 27001, and others — will be documented as they are confirmed. The detailed architecture of the Memory Vault, Bragi’s long-term interaction intelligence layer, will be documented separately when it reaches public availability. Both will be reflected in this page when confirmed.
