Cómo protege Gaavala el audio de tus reuniones: una arquitectura que prioriza la privacidad

Cada día laborable, millones de profesionales entran en reuniones donde se habla de información sensible — negociaciones de fusiones, consultas médicas, estrategia legal, avances de resultados trimestrales, decisiones de personal. Cuando esas reuniones cruzan barreras de idioma, la traducción en tiempo real se vuelve imprescindible. Pero la mayoría de las herramientas de traducción de reuniones exige enviar tu audio en bruto a la nube de un proveedor, creando exactamente el tipo de superficie de exposición de datos que los equipos legales, de cumplimiento y de seguridad cada vez pueden aprobar menos.

Gaavala está diseñado para salirse por completo de la ruta del audio. Cuando pasas una reunión por nuestra extensión de Chrome, tu audio no viaja a través de servidores de Gaavala. Se transmite directamente desde tu navegador al motor de voz a texto de Soniox mediante un WebSocket cifrado — y nuestro backend nunca ve ni un solo byte de él.

Este artículo recorre exactamente cómo funciona eso, qué datos cruzan el cable y cómo encaja la arquitectura en los marcos de cumplimiento más habituales.

El principio de privacidad de fondo

La mayoría de las herramientas SaaS de traducción sigue un flujo de datos conocido:

1. Tu navegador captura el audio de la reunión
2. El audio se sube al backend del proveedor
3. El backend del proveedor hace de proxy del audio hacia un motor de voz a texto
4. Las transcripciones vuelven a través del backend del proveedor
5. Los servidores del proveedor a menudo registran, cachean o retienen el audio por el camino

Cada salto de esa cadena es una frontera de confianza. Cada salto es un lugar donde un fallo de registro, una filtración de credenciales, una citación judicial o un ingeniero deshonesto podría exponer el contenido de tu reunión. Cuantas más partes tocan el audio, más difícil es demostrarle a un auditor que nadie lo retuvo.

Gaavala elimina el paso de proxy por completo. El flujo de datos es:

1. Tu navegador captura el audio de la reunión desde la pestaña
2. Tu navegador abre un WebSocket directo a Soniox
3. El audio se transmite directamente por ese WebSocket
4. Soniox devuelve las transcripciones directamente a tu navegador
5. El backend de Gaavala no interviene en ningún momento

La extensión de Chrome que se ejecuta en tu máquina es la única pieza de nuestro código que llega a tocar tu audio — y no nos envía ese audio.

Por qué elegimos esta arquitectura

Cuando reconstruimos Gaavala como extensión de Chrome, tomamos una decisión arquitectónica deliberada: la extensión autenticaría a los usuarios a través de nuestro backend, gestionaría el estado de la suscripción y serviría metadatos — pero nunca estaría en la ruta del audio. El razonamiento era sencillo:

• Superficie de cumplimiento: cada byte de audio de cliente que procesamos es un byte del que tenemos que responder en las DPIA, en los informes SOC 2 y en las negociaciones de BAA. La forma más limpia de mantener esa superficie en cero es no tocar el audio en primer lugar.
• Radio de impacto de una brecha: una brecha en un servidor que procesa audio es fundamentalmente peor que una brecha en un servidor que procesa metadatos de texto. Preferimos que nuestros sistemas más sensibles manejen los datos menos sensibles.
• Latencia: cada salto de proxy añade tiempo de ida y vuelta. La transmisión directa del navegador a Soniox elimina un salto entero, lo que nos da una latencia de subtítulos notablemente mejor.
• Costes alineados con la privacidad: operar nuestro propio proxy de audio significaría pagar ancho de banda y cómputo en cada reunión. No operarlo ahorra dinero y protege a los clientes. Cuando los incentivos están alineados, la arquitectura tiende a mantenerse honesta.

El flujo de datos en detalle

Veamos qué ocurre realmente cuando inicias la transcripción en una reunión.

Paso 1: autenticación

La primera vez que inicias sesión en Gaavala, la extensión usa la API chrome.identity.launchWebAuthFlow de Chrome para completar un flujo OAuth Authorization Code con Google o con Microsoft. El proveedor de identidad devuelve un código de autorización a tu navegador, que la extensión intercambia con nuestro backend por un JWT de sesión de Gaavala. Ese JWT se guarda en chrome.storage.local y sirve para autenticar las siguientes llamadas a nuestra API.

Nada de esto maneja audio. El flujo OAuth es solo texto — tokens, claims, campos de perfil.

Paso 2: clave temporal de Soniox

Cuando haces clic en "Start" en una reunión, la extensión llama a la API de nuestro backend para pedir una clave temporal de Soniox de corta duración. Esta clave tiene tres propiedades importantes:

• Está limitada únicamente a voz a texto — a nada más de la superficie de la API de Soniox
• Caduca en minutos, no en días
• Se emite una vez por sesión y no se persiste en tu dispositivo

El patrón de clave temporal es crítico para la historia de privacidad. Si Gaavala distribuyera una clave de API de Soniox de larga duración dentro del paquete de la extensión, cualquiera podría extraerla. En su lugar, emitimos claves desechables que se acuñan bajo demanda, quedan ligadas a tu sesión autenticada y se invalidan poco después de que la sesión termine.

Nuestro backend registra solo los metadatos de esa petición — qué usuario, a qué hora, con qué nivel de plan. No ve ningún audio porque todavía no se ha capturado audio alguno.

Paso 3: captura del audio de la pestaña

Te unes a tu llamada de Microsoft Teams, Zoom, Google Meet o Webex en una pestaña de Chrome. La extensión de Gaavala abre el panel lateral y te pide iniciar la captura de audio. Cuando confirmas, la extensión usa la API tabCapture de Chrome — una API exclusiva de extensiones que permite capturar el audio de la pestaña activa con permiso explícito del usuario y un indicador visible.

Chrome dirige el audio capturado a un documento offscreen que Gaavala ejecuta en segundo plano. El documento offscreen es una página aislada que la extensión puede usar para procesar audio sin mantener interfaz visible. Dentro de ese documento offscreen, Gaavala abre un MediaStream, lo conecta a un AudioContext y lo prepara para la transmisión.

Es fundamental que el audio pase además por un grafo de audio local que devuelve el sonido a tus altavoces. Eso significa que sigues oyendo la reunión con normalidad mientras Gaavala la captura — nada se silencia ni se redirige.

Paso 4: WebSocket directo a Soniox

El documento offscreen abre entonces una conexión WebSocket directamente a Soniox (wss://stt-rt.soniox.com/...). Esta conexión:

• Usa TLS 1.2 o superior
• Se autentica con la clave temporal de corta duración del paso 2
• Se origina en la pila de red de tu navegador — los paquetes van de tu sistema operativo a Soniox, no a Gaavala

Los fotogramas de audio capturados de la pestaña se codifican como PCM y se envían por el WebSocket. Soniox los procesa en tiempo real y devuelve tokens de transcripción por la misma conexión. Esos tokens — fragmentos de texto con marca de tiempo y etiquetas de hablante — llegan directamente al documento offscreen, que los reenvía al panel lateral para mostrarlos.

En ningún punto de todo ese bucle llega un paquete de audio a un servidor operado por Gaavala. Puedes verificarlo tú mismo con Chrome DevTools: abre la pestaña Network con el filtro WS activo mientras Gaavala está en marcha y verás exactamente un WebSocket — hacia un host de soniox.com — y cero tráfico saliente hacia gaavala.com que contenga audio.

Paso 5: visualización de la transcripción y resumen opcional

Los tokens de transcripción se renderizan en tres superficies: el panel lateral, un overlay flotante sobre la pestaña de la reunión y el búfer en memoria que se usa para exportar. Ninguna de esas superficies serializa audio. Solo manejan texto.

Cuando pides un resumen de IA al final de una reunión, el resumen se genera íntegramente en tu dispositivo mediante la IA integrada de Chrome (Gemini Nano). El texto de la transcripción nunca sale de tu máquina — no se envía al backend de Gaavala ni a ningún tercero. El contenido de la reunión, sea audio o texto, no cruza en absoluto el backend de Gaavala; lo único que sí lo hace siguen siendo los metadatos de autenticación y de suscripción.

Qué datos ven los servidores de Gaavala

Esta es la lista exacta de datos que maneja nuestro backend, en todas las funciones:

Y esta es la lista exacta de datos que nuestro backend no ve:

• Audio de reunión en bruto (en cualquier formato, en cualquier momento)
• Flujos de audio comprimido
• Búferes de audio o representaciones intermedias
• Datos biométricos de voz
• Identidad de los hablantes más allá de los identificadores anónimos que asigna Soniox
• Texto de la transcripción — los resúmenes se generan en el dispositivo; las transcripciones nunca salen de tu máquina

Si un tribunal requiriera a Gaavala el audio de una reunión concreta, la respuesta técnicamente veraz sería que no lo tenemos y que no podemos recuperarlo. Nunca existió en nuestros sistemas.

Audítalo tú mismo

Una de las ventajas de funcionar como extensión de Chrome es que todo el runtime es inspeccionable. Tu equipo de IT puede verificar nuestras afirmaciones de privacidad sin creerse una sola palabra de este artículo:

Método 1 — inspección de red. Abre chrome://extensions, localiza Gaavala y haz clic en "service worker" o en "inspect views > background page". En DevTools, ve a la pestaña Network y filtra por WS (WebSocket). Inicia una reunión. Verás exactamente un WebSocket abierto, hacia un host de soniox.com. Ningún audio va a gaavala.com.

Método 2 — inspección del manifiesto. En chrome://extensions, despliega "Details" en Gaavala y revisa los permisos. Los host_permissions declaran exactamente a qué orígenes puede llegar la extensión. Verás endpoints de Soniox para la transmisión y endpoints de Gaavala para autenticación y suscripción. No hay permiso de host comodín ni acceso de red no declarado.

Método 3 — inspección del código en ejecución. La extensión incluye un service worker, un documento offscreen, un panel lateral y content scripts. Chrome expone todos ellos para su inspección mediante las herramientas de desarrollo. Tu equipo de seguridad puede engancharse a la background page o al documento offscreen en cualquier momento y leer el estado en ejecución — incluida la confirmación de que el objeto del stream de audio nunca se serializa hacia un fetch o un XHR dirigido a nuestro dominio.

Publicamos el manifiesto y los permisos de host como parte de la ficha de la Chrome Web Store, y damos la bienvenida a revisiones de seguridad de terceros.

Correspondencia con los marcos de cumplimiento

GDPR y minimización de datos

El artículo 5(1)(c) del GDPR establece el principio de minimización de datos: los datos personales deben ser "adecuados, pertinentes y limitados a lo necesario". La voz es un dato personal bajo el GDPR, y un dato biométrico si se usa para identificar.

La arquitectura de Gaavala se alinea directamente con ese principio. Al mantener el audio completamente fuera de nuestros sistemas, reducimos los datos personales que tratamos al mínimo absoluto necesario para operar un negocio de suscripción — email, nombre, estado de facturación. Para clientes que realizan DPIA, nuestro backend es efectivamente transparente en cuanto al tratamiento de audio: no hay nada que evaluar porque nada nos llega.

Soniox es un procesador aparte dentro de tu cadena de cumplimiento. Puedes revisar su postura de privacidad de forma independiente, y Soniox publica condiciones de tratamiento de datos que se aplican a la conexión directa que tu navegador establece con ellos.

HIPAA y audio que contiene PHI

Bajo HIPAA, todo proveedor que trate, almacene o transmita Información de Salud Protegida debe firmar un Business Associate Agreement. Las consultas médicas contienen PHI con frecuencia — nombres de pacientes, diagnósticos, planes de tratamiento.

Como el backend de Gaavala nunca recibe el audio de la reunión, la canalización de audio queda fuera del alcance del BAA de Gaavala. La relación que evalúas para el tratamiento del audio es entre tú y Soniox directamente — Gaavala no es business associate de esos datos porque los datos no nos tocan. Si generas resúmenes de IA, se producen en el dispositivo mediante la IA integrada de Chrome — el texto de la transcripción se queda en tu máquina, así que la función de resumen tampoco introduce a Gaavala ni a ningún proveedor adicional en la cadena de tratamiento de PHI.

Riesgo de proveedores en SOC 2

Las auditorías SOC 2 exigen a las organizaciones documentar y evaluar todos los proveedores externos de su cadena de tratamiento de datos. Cada proveedor añade complejidad a tu System Description y amplía el alcance de tu evaluación de riesgos.

En la arquitectura de Gaavala, Soniox es un procesador de datos con el que interactúas directamente, no a través de Gaavala. Tu registro de riesgo de proveedores debería evaluar a Soniox en sus propios términos, algo que muchos equipos de seguridad encuentran más sencillo que evaluar una relación de subencargado. El alcance de Gaavala en tu registro de riesgos es más estrecho: gestionamos identidad y facturación — no audio en bruto, y tampoco el texto de la transcripción ni del resumen, que nunca sale de la máquina del usuario.

Por qué importa el formato de extensión de Chrome

Buena parte de las garantías de privacidad anteriores depende de que Gaavala funcione como extensión de Chrome con un patrón de red directo al proveedor. Consideramos, y descartamos, varias alternativas:

• Proxy de audio en el servidor: sencillo de implementar, pero nos obligaría a manejar el audio de todos los clientes en nuestra propia infraestructura. Eso es justo lo que queríamos evitar de forma explícita.
• Aplicación web con STT integrado: capturar el audio de una pestaña desde una página web requiere getDisplayMedia, que muestra al usuario un selector a nivel de sistema operativo en cada sesión y ata la captura a la pestaña que elija. Peor aún: no hay forma fiable de que una página web mantenga un stream de audio en segundo plano mientras el usuario interactúa con otras pestañas.
• Aplicación nativa de escritorio: nos daría más control, pero añadiría fricción de instalación, costes de firma y una carga de desarrollo específica por sistema operativo. Y aun así no eliminaría nuestro papel como procesador del audio salvo que fuéramos muy cuidadosos — lo que significa que reinventaríamos exactamente los mismos problemas.

El formato de extensión de Chrome fue el único que permitió la arquitectura de privacidad que queríamos. tabCapture, los documentos offscreen y el modelo de service worker de Manifest V3 permiten juntos que la extensión maneje el audio íntegramente en la máquina del usuario, abra conexiones directas a servicios externos y mantenga el estado en segundo plano que exigen las reuniones largas — sin enrutar nada a través de nosotros.

Lo que todavía tenemos que hacer bien

La arquitectura de privacidad no termina en "no tocamos el audio". Hay preocupaciones adyacentes que también nos tomamos en serio:

• Acuñación de claves temporales: las claves de Soniox de corta duración que acuñamos podrían usarse de forma abusiva si nuestro backend las acuñara para un atacante. Autenticamos cada petición con tu JWT, limitamos la tasa de emisión de claves y registramos las anomalías.
• Actualizaciones de la extensión: una versión actualizada de la extensión podría, en teoría, cambiar el patrón de red. Versionamos el manifiesto, publicamos changelogs y la Chrome Web Store muestra cualquier permiso nuevo antes de que se instale una actualización.
• Texto del resumen: los resúmenes se generan íntegramente en el dispositivo mediante la IA integrada de Chrome (Gemini Nano), así que la transcripción nunca llega a nuestro backend — este riesgo no existe en la arquitectura actual. Si incluso el procesamiento local de IA es más de lo que una reunión concreta puede tolerar, basta con no usar la función de resumen; nada más depende de ella.
• Muestra de referencia del clon de voz (Pro): si creas un clon personal de tu voz, tu muestra de ~20 segundos se guarda cifrada (AES-256-GCM) en los servidores de Gaavala, se usa únicamente para construir tu voz y se elimina cuando lo pides — consulta la Política de Privacidad.
• Requerimientos legales: nos comprometemos públicamente a responder a requerimientos legales solo con los datos que realmente tenemos. En el caso del audio, la respuesta siempre será "no lo tenemos".

Comparación con otras herramientas de traducción de reuniones

¿Cómo se compara el modelo de privacidad de Gaavala con el de otras herramientas habituales de traducción de reuniones?

El diferenciador que importa: en todas las demás filas de esa tabla estás confiando en lo que el proveedor afirma sobre cómo maneja el audio en sus servidores. Con Gaavala no hay servidores en los que confiar para el audio, porque no hay audio en nuestros servidores. La afirmación es verificable con las herramientas de desarrollo estándar de Chrome.

La privacidad es el valor por defecto, no un nivel de pago

El nivel gratuito de Gaavala te da la misma arquitectura directa a Soniox, la misma diarización de hablantes, la misma cobertura de 60 idiomas. Pro desbloquea 120 minutos al día, Speak Mode y la clonación de voz — no la privacidad. No creemos que los usuarios preocupados por su privacidad deban pagar más para mantener sus datos a salvo.

Si tu organización ha rechazado históricamente las herramientas de traducción de reuniones porque cumplimiento dijo que no a enviar audio a la nube de un proveedor, Gaavala se construyó para esa conversación. La canalización está diseñada para que tus equipos legales, de seguridad y de cumplimiento tengan menos que revisar, no más.

Añade Gaavala a Chrome →

Prueba gratuita única: 5 minutos de transcripción, nunca se reinicia. Sin tarjeta de crédito. Sin registro en el sitio web.

Artículos relacionados

• Cómo traducir una reunión de Zoom con la extensión de Gaavala
• Cómo traducir una reunión de Microsoft Teams