¿Por qué importa procesar el audio en proceso para el RGPD y la IA de voz?
Procesar el audio en proceso mantiene la grabación dentro de tu propio sistema: sin copia adicional, sin un nuevo encargado o subencargado que contratar y sin un nuevo lugar donde se almacene o transfiera el audio. Es contexto de ingeniería, no asesoramiento legal.
Procesar el audio en proceso importa para el RGPD porque el audio nunca sale de un sistema que ya controlas, así que el paso no añade ninguna copia, ningún encargado o subencargado nuevo ni ninguna transferencia nueva que evaluar. Una grabación de voz de una persona identificable es un dato personal según el RGPD, y cada sistema adicional por el que pasa es algo más que documentar.
Esto es contexto de ingeniería, no asesoramiento legal. Que un despliegue cumpla depende de tu base jurídica, tus contratos y tu jurisdicción; consulta a tu asesor legal o a tu delegado de protección de datos.
Qué cambia cuando el paso es en proceso
| Pregunta | SDK en proceso | API de audio alojada |
|---|---|---|
| ¿Sale el audio de tu proceso en este paso? | No | Sí |
| ¿Nuevo encargado o subencargado para el audio? | No (solo duraciones van al servicio de licencias) | Sí, hay que listarlo y contratarlo |
| ¿Dónde se procesa el audio? | Donde corra tu worker | Donde lo ejecute el proveedor |
| ¿Introduce este paso una transferencia internacional? | Ninguna por el audio | Posible, a evaluar |
Tres ideas del RGPD hacen concreta la diferencia:
- Minimización de datos (art. 5.1.c): tratar solo lo necesario. Un paso de mejora que corre dentro del worker maneja el audio que la llamada ya tiene, y no crea un segundo almacén.
- Encargados y subencargados (art. 28): una API de audio alojada que recibe grabaciones es un encargado o subencargado, lo que exige un contrato y un lugar en tu lista de subencargados. Una biblioteca en tu propio proceso no es otra parte que reciba el audio.
- Transferencias internacionales (capítulo V): dónde se procesa el audio decide si hay una transferencia. En proceso, se procesa donde ya elegiste correr el worker, que es también como mantienes el audio en una región dada.
Qué envía y qué no envía el SDK
Nuestro SDK ejecuta el modelo en CPU, sin red en la ruta del audio. El UsageReporter envía duraciones procesadas y mantiene fresco el token de licencia; no envía audio. Eso sigue significando que existe un servicio de licencias, y debes listarlo con precisión según lo que recibe.
| Coste medido de ejecutarlo en proceso | Valor | Fecha |
|---|---|---|
| Retardo algorítmico | 15 ms | 2026-08-14 |
| Factor de tiempo real, un hilo de CPU | 0.067 | 2026-08-14 |
| Peor tiempo de bloque, p99 | 3.96 ms | 2026-08-14 |
Los números son de Null Test, ejecución del 2026-08-14, en un Apple M1 Max. Ejecutar en proceso también significa que el coste es tuyo en CPU, y que el paso no está libre de riesgo de precisión: agregado sobre 19 condiciones nuestro modelo marca 16.59% de WER frente a 14.32% del audio sin tocar, así que actívalo donde hayas medido una mejora (cómo evaluar el aislamiento de hablante).
La misma propiedad vale para el resto del pipeline solo si el resto del pipeline también es tuyo. Un speech-to-text en la nube sigue recibiendo el audio. El aislamiento en proceso elimina un destinatario, no todos.
FAQ
¿Procesar el audio en proceso hace que un agente de voz cumpla el RGPD?
No. Quita un encargado y una transferencia del cuadro. La base jurídica, la información, la retención y los demás encargados de tu stack siguen aplicando.
¿Es un SDK en proceso un subencargado?
El SDK corre dentro de tu proceso y no recibe el audio, así que no es destinatario de él. El servicio de licencias recibe duraciones de uso, y debes describirlo con precisión en tus registros.
¿Va el audio a Anecho?
No. El audio permanece en tu proceso. El reporter envía duraciones.