Senior AI Platform and Model Operations Engineer

We are currently looking for a Senior AI Platform and Model Operations Engineer to join a professional German-based product company team that designs innovative eHealth solutions for hospitals.
You will work on a stable healthcare product.

You'd own the models and the platform around them, serving every channel we put in front of a patient.

The phone assistant is first because it's already underway, but it isn't the point of the job. Next is a chat assistant in the patient portal that can answer questions and walk someone through booking an
appointment, and after that whatever channel comes along.

The thing you're actually building is one internal API that every channel calls, so that the rules about what a patient can do live in one place instead of being written three times, slightly differently. The phone assistant and the web chat are two front ends onto the same thing.

Alongside that: moving off the vendor. Right now we pay per minute for speech recognition and language models, and within about a year we want to be running them ourselves — because we're dealing with
patient data, and because we don't want a vendor swapping a model underneath us without telling us.

To be clear about scope: we mean serving open-weight models and adapting them to our domain. We don't mean training a model from scratch.

One thing we want to be direct about. We are not looking for someone to build what we've already decided on. We don't yet know whether running these models ourselves is the right call — we don't have an accuracy figure on real German phone audio, and we don't have a proper cost comparison. Your first job is to produce both, and if they say we should keep paying the vendor for another year, we need you to tell us that plainly. Someone who quietly builds the thing because we asked for it is worse than no hire at all. If being the person who says "the numbers don't support this" makes you uncomfortable, this isn't the job.

You need
To have made a language model available behind an API that more than one product called, and to have kept it running: streaming responses, timeouts, retries, and errors that tell the caller something useful.
To have run a speech recognition model or a language model in production on hardware that you were responsible for. We do not mean a notebook or another company's API. You can tell us about one outage and what you changed after it.
To be able to size it and calculate its cost: how many people one GPU serves at the same time, what an hour of audio or a million tokens costs you, and at what load it starts to fail.
Tool calling in production, and a clear opinion on where the boundary is. The assistant will guide patients to book an appointment. This means that the model proposes an action, and our code decides whether the action is permitted. If you built a system where the model was trusted to act, we want to talk about what you would do differently.
To have handled untrusted text that reaches a model which can trigger actions. A chat box on a patient portal is much easier to attack than a phone call, and someone will try.
Experience to ground a model on your own content, so that it does not invent things, and honesty about where that still fails.
A habit to be suspicious of your own benchmark numbers, especially the good ones.
Python and Linux, containers, and a serving stack such as vLLM or SGLang.
Enough experience to work without an ML team around you, and to give a team lead bad news when it is necessary.

Nice to have
Experience to fine-tune or adapt an open-weight model, with LoRA, PEFT or an equivalent method, and the honesty to say whether it was worth the effort. This work comes later. It is not a condition to start.
Quantization, and an opinion on how much accuracy it costs you.
Audio processing: sample rates, codecs, and what a phone network does to a recording.
GPU scheduling, Kubernetes.
Experience with a system where the same assistant had to behave consistently in more than one channel.
Experience at a company that took GDPR seriously, and did not only mention it sometimes.
To know that training a model on patient conversations is a different legal question from processing the conversations to answer the patient. We will give you written rules and a review step for everything that moves patient data. A candidate who does not care about patient data is still not a fit.

You do not need
To have built a voice assistant. That is the other role. The phone assistant is the first consumer of what you build, and its narrowband audio is the first thing that you will measure against. But we buy and configure the telephony, we do not build it, and nobody expects you to have operated it.
To speak German.
To know PHP. You would define what our backend must provide. Another team builds it.