Por que processar o áudio em processo importa para a LGPD/GDPR e a IA de voz?
Processar o áudio em processo mantém a gravação dentro do seu próprio sistema: sem cópia extra, sem novo operador ou suboperador para contratar e sem novo lugar onde o áudio seja armazenado ou transferido. É contexto de engenharia, não aconselhamento jurídico.
Processar o áudio em processo importa para o GDPR porque o áudio nunca sai de um sistema que você já controla, então a etapa não adiciona nenhuma cópia, nenhum operador ou suboperador novo e nenhuma transferência nova a avaliar. Uma gravação de voz de uma pessoa identificável é dado pessoal segundo o GDPR, e cada sistema adicional por onde ela passa é algo a mais para documentar.
Isto é contexto de engenharia, não aconselhamento jurídico. Se uma implantação está em conformidade depende da sua base legal, dos seus contratos e da sua jurisdição; consulte seu advogado ou encarregado de proteção de dados.
O que muda quando a etapa é em processo
| Pergunta | SDK em processo | API de áudio hospedada |
|---|---|---|
| O áudio sai do seu processo nesta etapa? | Não | Sim |
| Novo operador ou suboperador para o áudio? | Não (só durações vão ao serviço de licenças) | Sim, precisa ser listado e contratado |
| Onde o áudio é processado? | Onde seu worker rodar | Onde o provedor o executar |
| Esta etapa introduz transferência internacional? | Nenhuma pelo áudio | Possível, a avaliar |
Três ideias do GDPR tornam a diferença concreta:
- Minimização de dados (art. 5(1)(c)): tratar apenas o necessário. Uma etapa de aprimoramento que roda dentro do worker lida com o áudio que a chamada já tem, e não cria um segundo repositório.
- Operadores e suboperadores (art. 28): uma API de áudio hospedada que recebe gravações é um operador ou suboperador, o que exige contrato e um lugar na sua lista de suboperadores. Uma biblioteca no seu próprio processo não é outra parte recebendo o áudio.
- Transferências internacionais (capítulo V): onde o áudio é processado decide se há transferência. Em processo, ele é processado onde você já escolheu rodar o worker, que é também como você mantém o áudio em uma região.
O que o SDK envia e o que não envia
Nosso SDK roda o modelo em CPU, sem rede no caminho do áudio. O UsageReporter envia durações processadas e mantém o token de licença atualizado; não envia áudio. Isso ainda significa que existe um serviço de licenças, e você deve listá-lo com precisão pelo que ele recebe.
| Custo medido de rodar em processo | Valor | Data |
|---|---|---|
| Atraso algorítmico | 15 ms | 2026-08-14 |
| Fator de tempo real, uma thread de CPU | 0.067 | 2026-08-14 |
| Pior tempo de bloco, p99 | 3.96 ms | 2026-08-14 |
Os números são do Null Test, execução de 2026-08-14, em um Apple M1 Max. Rodar em processo também significa que o custo é seu em CPU, e que a etapa não está livre de risco de precisão: agregado em 19 condições nosso modelo marca 16.59% de WER contra 14.32% do áudio intocado, então ative onde você mediu ganho (como avaliar isolamento de locutor).
A mesma propriedade vale para o resto do pipeline só se o resto do pipeline também for seu. Um speech-to-text em nuvem ainda recebe o áudio. O isolamento em processo remove um destinatário, não todos.
FAQ
Processar o áudio em processo torna um agente de voz conforme ao GDPR?
Não. Tira um operador e uma transferência do quadro. Base legal, aviso, retenção e os demais operadores da sua stack continuam valendo.
Um SDK em processo é um suboperador?
O SDK roda dentro do seu processo e não recebe o áudio, então não é destinatário dele. O serviço de licenças recebe durações de uso, e você deve descrevê-lo com precisão nos seus registros.
O áudio vai para a Anecho?
Não. O áudio permanece no seu processo. O reporter envia durações.