Gemini Live im Browser: Voice-AI-Prototyp in drei Stunden

Letzte Woche hatte ich mal wieder so ein typisches Screening-Telefonat: freundlich, strukturiert, aber irgendwie austauschbar. Eher digitales Formular als echtes Gespräch. Danach wollte ich wissen, wie weit sich ein Sprachassistent an einem Nachmittag bringen lässt.

Das Ergebnis war Uschi: eine Browser-Demo für die Terminabfrage in einer fiktiven Allgemeinarztpraxis, gebaut mit synthetischen Testdaten.

Mein Prototyp entstand in ungefähr drei Stunden. Das ist meine Bauzeit für eine begrenzte Demo, keine Zusage für andere Projekte. Gezeigt werden ein Gespräch im Browser, Unterbrechungen, ein Sprachwechsel und eine Terminabfrage aus einer kleinen Textdatei. Telefonie, Praxissoftware, belastbare Fehlerbehandlung und ein produktiver Datenschutzrahmen fehlen.

Der Prototyp: Uschi, KI-Sprechstundenhilfe

Sie heißt Uschi. Sprechstundenhilfe in einer Allgemeinarztpraxis in Köln-Ehrenfeld. Mitte 50, macht den Job seit 25 Jahren. Fragt erstmal, wie es dir geht, bevor sie zum Termin kommt. Fällt dir ins Wort, wenn sie was sagen will. Wechselt auf Türkisch, wenn du kein Deutsch sprichst. Und sucht nebenbei nach einem freien Termin.

Uschi ist eine KI. Ihre Persönlichkeit ist ein System Prompt mit ein paar Absätzen, die Terminabfrage läuft über eine Funktion. Der Rest kommt vom Modell.

Das Ganze läuft im Browser. Mikrofon an, reden. Kein „Bitte drücken Sie die 1“. Kein „Ihr Anruf ist uns wichtig“. Das Video zeigt die tatsächliche Demo:

Demo und Transkript auf LinkedIn

Im Prototyp getestet

• Spracheingabe und Audioausgabe im Browser
• Unterbrechung einer laufenden Antwort
• Wechsel zwischen mehreren Sprachen in manuellen Gesprächen
• synchrone Terminabfrage aus einer lokalen Textdatei

Nicht gezeigt

• echte Rufnummer, SIP/PSTN oder Weiterleitung
• Anschluss an Doctolib, PVS oder einen produktiven Kalender
• Authentifizierung, Berechtigung und belastbare Ausfalllogik
• Messung von Latenz, Dialektgenauigkeit oder Gesprächserfolg
• Verarbeitung echter Patienten- oder Termindaten

Damit bleibt die Demo eine Arbeitsprobe für Prototyping und Integrationsdenken. Sie ist kein fertiger Telefonassistent.

Technischer Stand am 15. August 2026

Die Demo nutzt die Live-API-Architektur von Google. Der aktuelle Modellname lautet gemini-3.1-flash-live-preview; Google veröffentlichte ihn am 26. März 2026 und führt ihn weiterhin als Preview.¹² Preview-Modelle und Endpunkte können sich ändern, deshalb gehört ein Release-Check vor jede Weiterentwicklung.

Google dokumentiert für das Modell bidirektionale Audio-, Video- und Texteingaben sowie native Audioausgabe. Die Dokumentation listet 97 unterstützte Sprachen und den Sprachwechsel mitten im Gespräch.¹ Das belegt, dass die Funktion existiert, nicht dass sie bei jedem Akzent oder Dialekt gleich gut arbeitet. Meine Gespräche waren ein Funktionstest, kein Sprachbenchmark.

Der Datenfluss meines Prototyps ist schlicht:

Browser → Python-Server → Gemini Live API

Der Browser streamt Audio zum Server. Dieser hält den API-Schlüssel und leitet Audio-Chunks über WebSockets weiter. Ein API-Schlüssel gehört nicht in Browser-Code; bei einer direkten Client-Verbindung empfiehlt Google kurzlebige Ephemeral Tokens.¹

Natives Audio macht in dieser Architektur keine separate Speech-to-Text-/Text-to-Speech-Kaskade nötig. Optionale Ein- und Ausgabe-Transkriptionen lassen sich trotzdem aktivieren. Ob die Stimme dadurch „natürlicher“ wirkt, war in meinem Test eine Beobachtung, keine Messung.

Function Calling und Wartezeit

Für die Terminabfrage definiert der Server eine Funktion mit Parametern wie Datum und Tageszeit. Erkennt das Modell eine passende Absicht, ruft es diese Funktion auf und wartet auf das Ergebnis.

Bei gemini-3.1-flash-live-preview läuft Function Calling synchron und sequenziell; NON_BLOCKING wird laut aktueller Vergleichsdokumentation nicht unterstützt.¹ Im kleinen Textdatei-Test war die Pause kurz. Ein produktives System braucht trotzdem Timeouts, Berechtigungsprüfung, Abbruch, Wiederholung und eine verständliche Fehlermeldung. Genau diese Arbeit passt nicht in den Drei-Stunden-Prototyp.

Was kostet das?

Alle folgenden Zahlen rechnen dasselbe Szenario: ein Gespräch mit 90 Sekunden Eingabe und 90 Sekunden Ausgabe, also drei Minuten verteilte aktive Audiozeit. Alle Preise sind Stand 15. August 2026.

Google listet für Gemini 3.1 Flash Live 0,005 US-Dollar pro Audio-Eingangsminute und 0,018 US-Dollar pro Audio-Ausgangsminute.³ OpenAI verlangt für seine Realtime-Modelle Audio-Tokenpreise, die sich auf dasselbe Szenario umrechnen lassen.⁷

Hochgerechnet auf eine Praxis mit 50 Anrufen am Tag und 22 Arbeitstagen, also 1.100 Gesprächen im Monat: etwa 38 US-Dollar bei Gemini, 50 bei OpenAIs kleinem Modell, 158 beim großen.

Das sind Untergrenzen, keine Gesprächspreise. Native Audio-Token im aktiven Kontext werden pro Sprecherwechsel erneut berechnet, aktivierte Transkriptionen kosten zusätzlich. Telefonie, Hosting, Monitoring, Ausfälle und Compliance fehlen komplett. Für eine belastbare Kalkulation braucht es echte Sitzungslogs.

Die Größenordnung reicht trotzdem für eine Aussage: Zum Vergleich kostet eine Sprechstundenhilfe, die einen erheblichen Teil ihrer Arbeitszeit am Telefon verbringt, mit Arbeitgeberanteilen ein Vielfaches davon im Monat. Die API-Kosten sind nicht der Engpass. Teuer wird ein Produktivsystem durch Entwicklung, Telefonie-Anbindung, Betrieb und Compliance.

Datenschutz und Nutzungsgrenzen

Die Demo arbeitet mit einer fiktiven Praxis und synthetischen Daten. Daraus lässt sich keine Freigabe für einen echten Praxisbetrieb ableiten.

Für kostenpflichtige Gemini-API-Dienste verwendet Google Prompts und Antworten laut Bedingungen nicht zur Produktverbesserung. Das bedeutet nicht, dass Daten niemals gespeichert oder außerhalb der EU verarbeitet werden. Missbrauchsprotokolle, Caching, konkrete Region und Vertragsbedingungen müssen separat geprüft werden.⁴⁵

Session Resumption ist standardmäßig deaktiviert. Wird die Funktion aktiviert, kann Google den Gesprächszustand mit Audio, Video, Text und Modellausgaben bis zu 24 Stunden für die Wiederaufnahme speichern.⁵ Ein Ziel wie Zero Data Retention hängt daher von der konkreten Konfiguration ab und darf nicht mit „Audio wird nie gespeichert“ abgekürzt werden.

Deutschland ist als verfügbares Land für Google AI Studio und die Gemini API gelistet. Das ist keine Zusage für ausschließliche EU-Verarbeitung.⁶ Regionale Vertex-/Enterprise-Endpunkte sind ein separates Produkt- und Vertragssetup; Modell- und Funktionsumfang müssen dort neu geprüft werden.

Am wichtigsten für diesen Demonstrator: Googles Additional Terms untersagen die Nutzung in clinical practice und für medizinische Beratung.⁴ Der Satz „Reine Terminvergabe ist unproblematisch“ wäre deshalb zu weit gegangen. Eine produktive deutsche Praxislösung braucht eine eigene technische, vertragliche, datenschutzrechtliche und medizinrechtliche Prüfung.

Übergabe an Menschen

In einem Produktivsystem wäre die wichtigste Funktion nicht das Reden, sondern das Erkennen, wann ein Mensch übernehmen muss.

Ein Voice-Bot in einer Praxis müsste merken, wann er nicht weiterkommt. Wörter wie Brustschmerzen, Atemnot oder Notfall gehörten sofort an einen Menschen weitergeleitet. Und nach drei erfolglosen Versuchen sollte die KI ehrlich sagen: „Da verbinde ich Sie lieber mit jemandem aus dem Team.“

Im Prototyp ist davon nichts umgesetzt. Für Produktion wären Zustandslogik, Rufweiterleitung, Erreichbarkeitsprüfung, Logging und ein Fallback für den Fall nötig, dass gerade niemand erreichbar ist. Das ist ein eigener Produktteil, kein zusätzlicher Prompt-Satz.

Was bleibt

Drei Stunden, ein Prototyp, der Gespräche führt, die Sprache wechselt und Termine aus einer Textdatei nachschlägt. Die Demo zeigt den Sprung vom Modell zur Interaktion.

Sie zeigt nicht, dass ein medizinischer Telefonassistent in drei Stunden fertig, datenschutzkonform oder zuverlässig wäre. Zwischen dieser Demo und einem System, das in einer echten Praxis Anrufe entgegennimmt, liegen Telefonie-Infrastruktur, Praxissoftware-Anbindung, Datenschutz-Architektur und viel Testing.

Gerade diese Grenze macht den Versuch nützlich. Ein schneller Prototyp beantwortet, ob sich eine Interaktion überhaupt bauen und erleben lässt. Und der Aufwand, das herauszufinden, ist überraschend gering geworden.

Tech-Stack und Quellen

• Backend: Python, FastAPI, WebSockets
• Frontend: Vanilla HTML/JS, AudioWorklet API
• Modell: gemini-3.1-flash-live-preview
• Daten: synthetische Termin-Textdatei