Why does processing audio in-process matter for GDPR and voice AI?
Processing audio in-process keeps the recording inside your own system: no extra copy, no new processor or sub-processor to contract, and no new place the audio is stored or transferred. This is engineering context, not legal advice.
Processing audio in-process matters for GDPR because the audio never leaves a system you already control, so the step adds no new copy, no new processor or sub-processor, and no new transfer to assess. A voice recording of an identifiable person is personal data under the GDPR, and every extra system it passes through is another thing to document.
This is engineering context, not legal advice. Whether a given deployment complies depends on your lawful basis, contracts and jurisdiction; ask your counsel or data protection officer.
What changes when the step is in-process
| Question | In-process SDK | Hosted audio API |
|---|---|---|
| Does the audio leave your process for this step? | No | Yes |
| New processor or sub-processor for audio? | No (durations only go to the licence service) | Yes, to be listed and contracted |
| Where is the audio processed? | Wherever your worker runs | Wherever the provider runs it |
| Cross-border transfer introduced by this step? | None from the audio | Possible, to be assessed |
Three GDPR ideas make the difference concrete:
- Data minimisation (Art. 5(1)(c)): process only what is necessary. An enhancement step that runs inside the worker handles the audio the call already has, and creates no second store of it.
- Processors and sub-processors (Art. 28): a hosted audio API that receives recordings is a processor or sub-processor, which needs a contract and a place on your sub-processor list. A library in your own process is not another party receiving the audio.
- International transfers (Chapter V): where the audio is processed decides whether a transfer happens. In-process, it is processed wherever you already chose to run the worker, which is also how you keep audio in a given region.
What the SDK does and does not send
Our SDK runs the model on CPU, with no network in the audio path. The UsageReporter sends processed durations and keeps the licence token fresh; it does not send audio. That still means a licence service exists, and you should list it accurately for what it receives.
| Measured cost of running it in-process | Value | Date |
|---|---|---|
| Algorithmic delay | 15 ms | 2026-08-14 |
| Real-time factor, one CPU thread | 0.067 | 2026-08-14 |
| Worst block time, p99 | 3.96 ms | 2026-08-14 |
The numbers are from Null Test, run of 2026-08-14, on an Apple M1 Max. Running in-process also means the cost is yours in CPU, and that the step is not free of accuracy risk: pooled over 19 conditions our model scores 16.59% WER against 14.32% for untouched audio, so enable it where you have measured a gain (how to evaluate speaker isolation).
The same property holds for the rest of the pipeline only if the rest of the pipeline is also yours. A cloud speech-to-text still receives the audio. In-process isolation removes one recipient, not all of them.
FAQ
Does processing audio in-process make a voice agent GDPR compliant?
No. It removes one processor and one transfer from the picture. Lawful basis, notice, retention and the other processors in your stack still apply.
Is an in-process SDK a sub-processor?
The SDK runs inside your process and does not receive the audio, so it is not a recipient of it. The licence service receives usage durations, and you should describe it accurately in your records.
Does the audio go to Anecho?
No. Audio stays in your process. The reporter sends durations.