The GDPR case for a self-hosted AI phone assistant

Tel-Agent does not answer a phone call yet. It is at Milestone 0 of 12, and nothing below describes something you can deploy this afternoon. What it describes is the reason the project is built to run on your own machine, and why that decision is a legal one before it is a technical one.

This is not legal advice, and no piece of software is "GDPR compliant" on its own. Compliance is a property of a deployment — who processes what, where it rests, and on what basis. The point of this article is narrower and, I think, more useful: self-hosting removes entire categories of that question rather than answering them.

A recorded call is about as regulated as data gets

A phone call to your business produces two artefacts, and both are personal data under Article 4(1) of the GDPR: the audio and the transcript. The audio is the harder one. It carries not only what the caller said but how they said it — and voice, when processed to identify someone, becomes biometric data under Article 9, which starts from a prohibition rather than a permission.

Callers also do not choose their words for the record. A patient rings a clinic and states a symptom. A tenant rings a housing office and explains why the rent is late. That is health data and financial hardship arriving in your systems because someone needed help, not because they filled in a form. A written enquiry gets composed; a spoken one does not.

Recording it at all is separately regulated. In Germany, §201 StGB makes recording the non-public spoken word without consent a criminal matter, not an administrative one — that is a prison-or-fine provision sitting underneath the data-protection questions, and it is why the announcement at the start of a call is not a formality. The AI Act adds a second disclosure on top: under Article 50, a person interacting with an AI system has to be told they are, unless it is obvious from the context.

None of that is an argument against answering calls with software. It is an argument for knowing exactly where the recording goes in the second after it exists.

Where it usually goes

A voice assistant assembled from hosted parts has a supply chain, and each link is a legal relationship you own.

Speech-to-text is one vendor. The language model is a second. The voice is a third. The telephony layer that bridges SIP to all of them is a fourth. Under Article 28 each is a processor acting on your instructions, which means a data processing agreement per vendor, documented sub-processors, and your accountability for their security under Article 32 — not theirs.

Then geography. Most of these providers are American, so the audio leaves the EU, and Chapter V applies: standard contractual clauses, a transfer impact assessment, and a dependence on the EU–US Data Privacy Framework that is under active legal challenge and has already been struck down twice in previous forms. None of that makes the transfer unlawful. It makes it contingent — on an adequacy decision that a court could withdraw, on terms you did not write, and on a chain of sub-processors that can change with a changelog entry.

You can do all of it correctly. Many organisations do. It is simply a great deal of standing work to keep a phone line answered.

What running it locally removes

Here is the same list with the assistant running on hardware you control.

The rows that matter are the ones that read "none". Nobody negotiates a data processing agreement well; the good outcome is not having to. A transfer impact assessment for a transfer that does not happen is an artefact you never write.

This is the whole argument for a self-hosted voice AI agent in a European context, and it is worth stating plainly rather than as a feature bullet: the cheapest way to satisfy a rule about sending data somewhere is to not send it.

The same property does the work under Article 5(1)(c) — data minimisation — and Article 17. Deleting a recording is a real deletion when the disk is yours. Across four vendors it is four deletion requests and four retention schedules, each honoured on somebody else's timetable.

The part that is not true yet

Everything above is why the project exists. It is not a description of what runs today, and the honest version has a gap in the middle of it.

The design that gets the first call answered uses hosted speech-to-text, a hosted model and a hosted voice — the exact supply chain this article is about. That is a deliberate order of work, not an oversight: the latency budget is brutal, and the specification's 800ms target is far easier to hit with providers who have already solved streaming and warm capacity. Proving the loop closes comes before proving it closes locally.

What turns that from an excuse into a plan is Milestone 1, which is three interfaces — one speech-to-text, one model, one voice — with the hosted services demoted to being their first implementation rather than the architecture. Once those seams exist, "runs entirely on your hardware" is a configuration rather than a rewrite.

So the accurate status is: the local deployment is the design, the interfaces that make it possible are Milestone 1, and neither is finished. If someone sells you an open-source AI phone assistant with a stronger claim than that today, ask them which of their four vendors they removed.

What to read if this is your problem

The architecture, the provider boundaries and the milestone order are in the specification. It is short and it is honest about what is not built.

The project is AGPL-3.0, which is itself part of the argument — you cannot verify where a recording goes in software you cannot read. It is built at Dpro GmbH in Austria, which is to say by people the same rules apply to.

There is nothing to sign up for, no trial and no waiting list. If the problem described here is one you have, the useful thing to do is watch the repository and tell us where the design is wrong before it is built.