Signing an Auftragsverarbeitungsvertrag with your voice agent provider is the easy 30 percent. The harder 70 percent is what the practice itself has to do. Patient information notices, professional secrecy authorisation, the AI Act Art. 50 disclosure, and the operational running of all of it. Concrete.
Article 28 GDPR requires a data processing agreement (AVV) between the controller (the clinic) and the processor (the voice agent provider). German market convention has standardised this. You can sign one in under ten minutes; mine is at /avv with all ten mandatory elements, sub-processor annex inline, voice-agent-specific clauses, and a download button. Lots of providers have one. Some are even good.
That is the easy part. Once it is signed, almost every clinic I have talked to acts as if compliance is done. It is not done. It is roughly 30 percent done. The remaining 70 percent is what the clinic itself has to operate, and there is very little public material on what that actually looks like.
This essay is the concrete checklist of what the AVV does not cover. Written for a Praxisinhaber, not for a Datenschutzbeauftragter; the DSB knows this already.
The AVV makes the processor legally bound to handle data correctly. It does not inform the patient that their data is being handled by a voice agent. That information obligation is on the controller, which is the practice. It exists in three places at once:
Skipping any one of these is the kind of finding that BayLDA picks up on a cold check. The remediation is annoying but easy. The fine for it is real: Art. 83 GDPR allows up to 4 percent of annual turnover for Art. 13 violations. In practice, first findings against small practices land in the €5,000 to €50,000 range, with abatement orders. Don't be a test case.
German medical professionals are Berufsgeheimnisträger under § 203 StGB. They are criminally liable for disclosing patient information to third parties without authorisation. The 2017 amendment to § 203 Abs. 3 and 4 added the concept of mitwirkende Personen (assisting persons) to legalise modern outsourcing: a doctor can engage a billing service, a backup provider, an IT support firm, without it being criminal disclosure, if the provider is contractually obligated to confidentiality.
The AVV does this for the primary processor. It does not automatically extend to every sub-processor in the chain. Each must be enumerated by name in the agreement that the clinic signs, and each must itself be under matching confidentiality obligation. A change in the sub-processor list mid-contract requires re-authorisation. In my AVV that is handled by 30-day advance notice with a right of objection (§ 4.4), but the practice must still tick a box for each new entry. Auto-accepting the change moves the clinic into the criminal-disclosure side of the line.
Practical version: when you get a sub-processor change notification, read it. If the new provider is a US LLM vendor and your practice has any patient data flowing through the agent, your DSB needs to bless it before the 30 days run. The AVV cannot do that for you.
AI Act Art. 50 requires that any natural person interacting with an AI system be informed that they are interacting with an AI, unless that is obvious from the context. For a voice agent receiving an inbound call from a patient, it is not obvious from the context. The agent is good enough that callers routinely do not realise.
The disclosure has to happen at the start of every call, clearly and intelligibly. It must not be hidden in a website footer. It must not be conditional on the caller knowing to ask. The wording I use: "Sie sprechen mit dem KI-Telefonassistenten der Praxis Dr. X. Wenn Sie lieber mit einem Menschen sprechen möchten, sagen Sie bitte 'Mensch'."
Applicability date is 2 August 2026. Many providers will tell you they have time. They do, on paper. In practice, BayLDA already cites Art. 50 in its current voice-agent guidance as a forward-looking obligation, and the reasonable interpretation is that a practice deploying a voice agent in May 2026 should be compliant on day one rather than retrofitting in August. The cost of being compliant early is one extra sentence in the call intro. The cost of retrofitting late is rewriting your patient notice template and your internal documentation.
Most voice agents transcribe the call and store the transcript. Many do not retain audio. Some retain audio for "quality assurance". The transition between these two regimes is legally non-trivial.
§ 201 StGB criminalises recording the spoken word without consent. For a voice agent, this means: if you store the raw audio at any point beyond transient streaming, you need explicit consent at the start of each call, with a meaningful opt-out (the caller saying "nein, nicht aufzeichnen" must cause the audio to stop being captured within seconds, and the buffer must be irretrievably deleted). Storing audio without that consent flow is a criminal offence.
The AVV cannot waive this. The clinic cannot waive this on behalf of the caller. The processor must implement the consent flow technically, and the controller must verify that it is wired up. In my system the default is transcript-only with no audio retention beyond 60 seconds of streaming buffer. Audio recording is opt-in per clinic and triggers an additional consent announcement at call start. Consent logs are documented per call with timestamp and caller response.
Practical version: ask your provider, in writing, two questions. (a) Is audio retained beyond transient processing? (b) If yes, how is consent obtained and documented per call? If they cannot answer both in two sentences, do not proceed.
Caller utterances during an appointment booking call routinely contain health information under Art. 9 GDPR (special category). "Ich habe seit Wochen Rückenschmerzen", "Mein Vater hat Diabetes, ich glaube ich brauche einen Test", "Ich bin schwanger und brauche...". The AVV basis Art. 9 Abs. 2 lit. h (processing for healthcare provision) is the right lawful basis, but it has a narrow scope.
Art. 9 Abs. 2 lit. h covers data processed for the purpose of providing healthcare to that data subject. It does not cover training data generation, secondary analytics, model improvement, or any aggregation across patients. It does not cover the LLM provider using your patient transcripts to improve future models. That is why my agreement with Anthropic for the LLM backbone is the commercial-terms mode with explicit no-training-on-input; the free-tier and consumer-tier Anthropic terms would not pass an Art. 9 audit.
Practical version: in your provider's AVV or its sub-processor list, find the LLM provider, find the agreement type, and verify the training-on-input stance. If the provider routes through a consumer-tier API, that is a finding.
§ 38 BDSG requires a Datenschutzbeauftragter when a controller has more than 20 employees handling personal data, or when the core activity involves regular and systematic monitoring or processing of special categories. Most private medical practices already have one for the former reason.
Adding a voice agent does not independently trigger a DSB obligation if one of the criteria was not already met. But it does change what the existing DSB needs to be aware of: new processor, new data flow, new TIA documents to review, new patient information template. Expect a 2-4 hour review when you onboard.
For practices under the 20-employee threshold without a DSB, the question becomes "is the voice agent regular and systematic monitoring of special categories?" The defensible answer is no, if the agent is functionally limited to appointment scheduling and information lookup (no diagnosis, no triage). That is part of why I designed mine that way: see the safeguards essay. The classification is fact-dependent and your DSB should write the determination down.
Transcripts and appointment records have different retention obligations. Transcripts are not legally required to be retained at all; they are an operational artefact. The default in my system is 90 days, configurable per clinic between 7 and 365 days. Appointment records (name, date, concern category) sit on top of the clinic's primary practice-management system and follow that system's retention rules, which are anchored in § 630f BGB and the Berufsordnung of the respective Landesärztekammer (10-year minimum for medical records).
The mistake practices make: setting the voice agent transcript retention to "the same as the medical records" because it sounds safe. It is not safe. It is over-retention of special-category data without lawful basis. Art. 5 Abs. 1 lit. c (data minimisation) requires you to retain the transcript only as long as you need it for the operational purpose. 30 to 90 days covers the realistic complaint-handling window. Beyond that, you are keeping it for the wrong reason.
In Bavaria, voice-agent deployments fall under BayLDA (Bayerisches Landesamt für Datenschutzaufsicht) for non-public bodies. Other Länder route to their respective Landesdatenschutzbeauftragter. BayLDA has been the most vocal authority on AI and Art. 9 issues; their guidance on cookie banners from 2024 was the de-facto national standard within six months. Expect their voice-agent guidance, when it lands, to be similarly load-bearing.
Practical version: if you are about to deploy a voice agent in Bavaria and you have a DSB, have them check the BayLDA orientation papers from the last 12 months. The guidance is not codified in the GDPR text; it lives in those papers and in informal correspondence.
Every obligation above is one the AVV alone does not discharge. A practice that signs the AVV and considers compliance done is a practice that will fail a cold audit on at least half of them. The remediation is straightforward in every case (patient information template, consent flow, DSB review, retention configuration, sub-processor review), but it is the clinic's work, not the provider's.
The good news: most of it is a one-time setup. The patient information template goes in once. The waiting-room notice goes up once. The § 203 authorisation is signed once and re-authorised on sub-processor change. The DSB review happens once at onboarding. The total operational burden after first launch is low. What is high is the first-launch burden if no one has thought about it ahead of time.
The customer-facing version of this is the plain-language Datenschutz-FAQ. The legally binding version lives in the AVV, the Datenschutzerklärung, and the TOM annex. This essay is the engineering version: the part that does not fit into any of those documents but that every clinic IT department asks me about within the first call.
Reply: [email protected]. Real replies. No comments section. Back to all essays.