Securing a medical voicebot without slowing it down

At transtorm.ai, we built Camille, a voice assistant that handles phone appointment booking for the front desk of several medical centers. She identifies the patient, offers time slots, moves or cancels an appointment and leaves a message for the team.

On a system like this, a flaw does not produce a wrong answer. It produces a cancelled appointment, a forged message or leaked health data. So we built an application around the language model to protect it. It rests on three choices: lightweight local infrastructure, decision models alongside the language model, and tuned prompts and connections so that callers never notice these protections on the phone.

What a caller might try

A voicebot combines the risks of a chatbot with those of a telephone switchboard. Anyone can call, with no account or password, and everything they say reaches the language model.

Transcription adds its own uncertainty: a misheard name or a lost negation is enough to change the meaning of a sentence. So Camille has to stay safe even when she mishears.

Local infrastructure, deliberately lightweight

The patient’s voice, its transcription and the generated answer stay on our servers. Conversations are not sent to a public API. That is the first protection, before a single line of the prompt is written. It is also the basis of our GDPR posture: no health data is handed to an AI model provider.

This infrastructure stays lightweight: the whole voice chain, from transcription through decision to synthesis, fits on a single 32 GB graphics card. The language model is an MoE (mixture of experts): it has 26 billion parameters, but only about 4 billion are used for each word it produces. The decision model, at around 4 billion parameters, is small enough to run on the same card, alongside speech recognition and speech synthesis. There is no data center to rent and no subscription to a large provider.

Keeping the chain in-house also gives us control over response times. When a large provider’s speech synthesis API stalled for 11 to 32 seconds, our local synthesis was answering in 80 to 130 milliseconds.

The LLM talks, the decision model decides, the code executes

The language model leads the conversation, but it does not decide alone and never carries anything out itself. We keep three roles separate.

Choices made on the practice’s behalf are handed to decision models, like the ones we presented in our article on decision models. They receive the patient’s answer and a fixed list of options: which doctor, which type of consultation, which of the offered slots. They return one of those options with a confidence score, or “I don’t know”. Below the confidence threshold, Camille asks the question again rather than guessing.

Everything else is checked by the program. A date has to be a real date, a slot has to come from an actual search of the calendar, an email address has to have been confirmed. These checks are written in the code, not in the prompt, and no cleverly worded sentence can sway them.

Booking, cancelling or forwarding a message is carried out by the code, after a fixed summary and a clear “yes”.

Camille also moves forward in stages, and each stage only has access to the tools it needs. So a trick sentence spoken during the greeting cannot cancel anything. At the stages that carry out an action, every sentence is also screened for manipulation attempts. An alert blocks the action and forwards the message to the front desk, marked “to be checked”.

The first six steps prepare and check. Only the last one changes anything, and it is the code that carries it out. None of these safeguards is enough on its own: to do harm, an attack has to fool the language model, the decision model and the code’s checks all at once.

This way, Camille can be safer than a receptionist, because she checks systematically. The patient’s identity, the requested date and the slot are checked on every call, without exception, even when the phone never stops ringing.

Prompts and connections built for speed

Every added check can delay the answer, and on the phone, any silence longer than a second and a half gets noticed. The median delay between the end of the patient’s sentence and the start of the answer used to be 1.3 seconds; it is now about one second. Figure 1 shows where that time goes, and why the checks add almost nothing to it.

Several choices keep us within this budget:

1. End of speech detected sooner. This is the longest step in a turn. Camille now decides the patient has finished speaking after 0.3 seconds of silence, instead of 0.55: median detection time dropped from 816 to 524 milliseconds.
2. The checks run in parallel with the language model, not before it. On ordinary turns, our hardening against injection cost one millisecond on average.
3. Connections are opened once, then reused. Opening an encrypted connection for each decision cost about 100 milliseconds, compared with 40 with a shared connection.
4. Only one decision at a time alongside the language model. The two share the same graphics card, and a second simultaneous request slowed the answer by about 40 milliseconds. Parallelism has its limits on shared hardware.
5. A stable prompt. The static part of the prompt is cached, while the variable part, such as the date and time, is placed at the end. The first answer in a call dropped from 0.91 to 0.66 seconds.
6. Sentences prepared in advance. The greeting and the fixed questions are synthesized once, then served from a cache.
7. An answer streamed as it is written. The language model’s text is sent to speech synthesis piece by piece, and the voice plays without waiting for the full answer.

A test bench that simulates attacks

An untested protection is still just a hypothesis. An automated test bench regularly calls Camille and tries the manipulations described above, against simulated actions, so nothing breaks.

The bench runs ten attack scenarios, three times each. Before hardening, 18 of the 30 attacks managed to trigger an action nobody had asked for: cancelling or moving an appointment, confirming a slot that was never offered, accepting an absurd date. These results guided the protections described in this article. After hardening, none of the 30 attacks succeeded.

Security that got in the way of real patients would be a failure. So the bench also runs eight ordinary-caller scenarios: in these, Camille uses the same tools, carries out the same actions and keeps the same wording as before hardening. We also ran 42 recorded calls through the new version of Camille, 241 speaking turns in all: none was wrongly flagged, and no legitimate request was refused. The bench is rerun before and after every prompt or model change.

Our takeaways

A safe medical voicebot keeps its data in-house, never lets the language model act alone, hands decisions to models and code that can be checked, and is regularly put through a test bench that simulates the known attacks. Built well, this security costs almost nothing in response time.

The same choice of local infrastructure guides our reception kiosk, which identifies patients on arrival and builds the doctor’s worklist.

If you are considering an AI receptionist for your practice or an AI phone agent for your customer service, write to us at the bottom of this page, or book a slot directly in our calendar.