Sprache und Audio

Ein Sprachmodell arbeitet mit getipptem Text. Token, Prompt, Kontextfenster, Tools, all das setzt ihn voraus. Sobald jemand spricht, kommt eine Schicht davor, und die hat eigene Fehler und eigene Entscheidungen.

Kapitel 01 hat diese Schicht benannt: vorn die Spracherkennung, hinten die Sprachsynthese. Dieses Kapitel nimmt sich die erste vor.

Erkennung und Erzeugung

Zwei entgegengesetzte Wege zwischen Ton und Text. Getrennte Systeme gehen je einen davon, das durchgehende Modell weiter unten geht beide.

Erkennung macht aus Ton Text. Es gab sie lange vor 2022, und die besten Werte kamen damals aus einer Anpassung an den jeweiligen Datenbestand. Die Arbeit, die das änderte, erschien im Dezember 2022:

When scaled to 680,000 hours of multilingual and multitask supervision, the resulting models generalize well to standard benchmarks and are often competitive with prior fully supervised results but in a zero-shot transfer setting without the need for any fine-tuning. (externe Seite, arxiv.org)

Der letzte Halbsatz ist die Neuerung: Das Modell erreicht diese Werte ohne Anpassung an den einzelnen Datenbestand. Der Weg dahin war Menge, allerdings sortierte Menge. Die Autoren beschreiben in Abschnitt 3.1 einen eigenen Apparat, der maschinell erzeugte Abschriften wieder aussortiert, die gesprochene Sprache gegen die geschriebene prüft und Dubletten entfernt. Eingetauscht wurden geprüfte Abschriften gegen mehr Material.

Die Autoren beziffern den Abstand zum Menschen selbst:

When compared to humans, the models approach their accuracy and robustness. (externe Seite, arxiv.org)

Der Satz gilt für die Aufnahmen, an denen sie gemessen haben. Wie schnell solche Zahlen kippen, wenn das Material wechselt, steht in Tiefe 2, und die Warnung davor stammt aus derselben Arbeit.

Erzeugung macht aus Text Ton. Sie kommt in diesem Kapitel kaum vor, weil die Entscheidungen, um die es hier geht, alle an der Erkennung hängen: Was falsch angekommen ist, spricht auch die beste Stimme falsch aus. Wie beide Verfahren gebaut sind, steht in KI-Wissen, Kapitel 07 und KI-Wissen, Kapitel 08.

Zwei Bauformen

Wer etwas mit Sprache bauen will, findet bei einem Anbieter inzwischen drei Bauformen nebeneinander:

Choose between GPT-Live, Realtime API sessions, and chained voice pipelines. (externe Seite, developers.openai.com)

Zwei davon sind die etablierten Gegenpole, um die es in diesem Kapitel geht. Die dritte, GPT-Live, kommt am Ende des Kapitels dazu.

Die Kette. Erkennung, dann ein gewöhnliches Textmodell, dann Sprachausgabe. Drei Systeme hintereinander, dazwischen jeweils Text, den man sehen und prüfen kann.

Inspect or transform intermediate text and replace each component independently. (externe Seite, developers.openai.com)

Das eine Modell. Ton geht hinein, Ton kommt heraus, ohne Umweg über eine Textstufe.

Use one model to interpret audio, decide what to do, and respond in speech. (externe Seite, developers.openai.com)

Reine Formen sind das nur auf dem Papier. Auch beim durchgehenden Modell läuft eine Erkennung nebenher mit, sonst gäbe es dort keine Abschrift, und wer will, mischt beides. Was daraus folgt, steht in Tiefe 3.

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Wofür welche taugt

Der Unterschied klingt technisch und entscheidet praktisch alles.

Die Kette ist langsamer, weil drei Systeme nacheinander arbeiten. Dafür liegt nach jedem Schritt Text vor, und an dem lässt sich prüfen, protokollieren und abbrechen. Der Anbieter empfiehlt sie genau dafür:

Use this path when each stage needs to be visible or replaceable. (externe Seite, developers.openai.com)

Das eine Modell antwortet schneller und klingt natürlicher, weil es hört, wie etwas gesagt wurde und was daneben noch zu hören war. Eine Abschrift bekommt man auch dort, sie entsteht allerdings auf einem eigenen Weg und stimmt nicht zwingend mit dem überein, worauf das Modell geantwortet hat. Was das im Betrieb bedeutet, steht in Tiefe 3.

Die Reihenfolge

Dieselbe Doku formuliert die Regel, die daraus folgt, in einem Satz:

The practical rule is: choose the audio architecture first, then design the rest of the agent workflow the same way you would for text. (externe Seite, developers.openai.com)

Das ist bemerkenswert, weil es die übliche Reihenfolge umdreht. Erst die Bauform, dann alles Weitere. Wer mittendrin wechselt, baut den größeren Teil neu.

Eine Entscheidung steht allerdings noch davor, und sie betrifft beide Bauformen: Wer sagt eigentlich, wann jemand zu Ende geredet hat. Kapitel 03 nimmt sich das vor.

Die dritte Form

GPT-Live trennt die Sprachebene vom Denken dahinter. Ein eigenes Modell hört zu und spricht, und zwar gleichzeitig:

GPT-Live can listen and speak at the same time, a capability called full duplex. (externe Seite, developers.openai.com)

Die Antwort selbst kommt von einem zweiten System, das die eigene Anwendung oder der Anbieter betreibt:

The live model handles the spoken interaction and delegates reasoning and tool use to a separate backend. (externe Seite, developers.openai.com)

Damit liegt GPT-Live zwischen den beiden Polen dieses Kapitels: Die Sprachebene nimmt Ton direkt entgegen wie das eine Modell, das Denken dahinter läuft textbasiert wie bei der Kette. Was das für die Fragen aus Tiefe 2 und Tiefe 3 bedeutet, ist an dieser Stelle noch nicht ausgearbeitet.

Spracherkennung wird mit einer einzigen Zahl bewertet, der Wortfehlerrate, englisch Word Error Rate und in jeder Modellkarte als WER abgekürzt. Sie zählt, wie viele Wörter man ersetzen, löschen oder einfügen müsste, um aus der Abschrift die Sollfassung zu machen, geteilt durch die Zahl der Wörter in der Sollfassung. Ein Wert von 10 Prozent heißt: Auf hundert Wörter Sollfassung kommen zehn solcher Änderungen.

Das ist etwas anderes als „jedes zehnte Wort stimmt nicht“, auch wenn es sich so liest. Am schnellsten sieht man den Unterschied am oberen Ende: Ein Modell, das jedes Wort trifft und zu jedem drei weitere erfindet, steht bei 300 Prozent. Ein Anteil an den gesprochenen Wörtern kann diese Zahl also nicht sein.

Die Zahl ist nützlich und führt in die Irre, sobald man eine Entscheidung darauf stützt. Dieselbe Bauart einer Kennzahl und dieselbe Schwäche gibt es beim Lesen von Text aus Bildern, siehe KI-Wissen, Kapitel 05.

Alle Wörter zählen gleich, alle Wörter sind es nicht

Ein falsch erkanntes „und“ wiegt in dieser Rechnung genauso viel wie ein falsch geschriebener Nachname. Für den Leser des Ergebnisses ist der Unterschied riesig: Das eine liest man weg, das andere macht den Satz falsch.

Wie groß der Abstand wird, zeigt eine eigene Messung an einer Referenzaufnahme mit Fachvokabular. Whisper Large v3 kam dort auf 10,68 Prozent Wortfehler insgesamt, auf den 56 markierten Fachbegriffen derselben Aufnahme aber auf 25,00 Prozent (eigene Messung vom 19.04.2026, ausführlich im Bericht über eine eigene Diktier-App). Jedes vierte Fachwort war falsch, während die Gesamtzahl nach einem guten Ergebnis aussah.

Der Grund liegt in der Bauform. Ein Erkennungsmodell wählt aus, was wahrscheinlich gesagt wurde, und ein Wort, das im Trainingsmaterial selten vorkam, startet mit schlechten Karten. Ein häufiges Wort, das ähnlich klingt, gewinnt.

seitlich verschiebbar

eigene Messung vom 19.04.2026, MacBook Pro M4 Max

Das Gegenmittel und seine Grenze

Gegen genau diesen Fehler gibt es einen Griff, und er steht in der Herstellerdokumentation:

Use keywords for product names, acronyms, and other literal terms that may appear in the audio. (externe Seite, developers.openai.com)

Man reicht also eine Liste der Wörter mit, die vorkommen dürften. Zwei Einschränkungen stehen direkt daneben. Die erste betrifft die Wirkung:

Keywords are hints, not required output. (externe Seite, developers.openai.com)

Die Liste verschiebt Wahrscheinlichkeiten, sie erzwingt nichts. Die zweite betrifft den Platz:

The Realtime API rejects the session update if a keyword contains one of these characters or prompt exceeds the model’s length limit. (externe Seite, developers.openai.com)

Damit wird aus einer scheinbar einfachen Sache eine Auswahlaufgabe. Wer ein Fachwörterbuch mit tausend Einträgen hat, muss entscheiden, welche davon in das Fenster kommen, und diese Entscheidung hängt am Gesprächsthema. Genau hier liegt in der Praxis die meiste Arbeit.

Was in der Stille passiert

Der unangenehmste Fehler ist keiner, den eine Fehlerrate misst. Bekommt ein Erkennungsmodell eine Aufnahme ohne Sprache, gibt ein Teil der Modelle Text aus, den nie jemand gesagt hat.

In der genannten Messreihe fielen zwei Kandidaten genau daran durch: einmal eine Endlosschleife aus 37 Wörtern, einmal die Frage „Kannst du mir helfen?“ Bei einer Taste, die man versehentlich drückt, ist das der Unterschied zwischen einer leeren Zwischenablage und einem erfundenen Satz mitten im Dokument.

Der Mechanismus ist derselbe wie in Grundkurs, Kapitel 07, und greifbar wird er an dem, was dabei herauskommt. Am 18.04.2026 lieferte im Betrieb derselben App der Qualitätssieger von oben genau solche Sätze: „Untertitelung des ZDF, 2020“ und „Thank you for watching! Please subscribe to my channel!“ Das ist die häufigste Fortsetzung an dieser Stelle. Ein großer Teil des Trainingsmaterials sind Untertiteldateien aus dem Netz, und am Ende einer Untertiteldatei steht der Abspann.

Die Abhilfe liegt außerhalb des Modells und hat drei Stufen. Die erste ist eine Lautstärkeschwelle vor der Erkennung, für die die Anbieter einen eigenen Schalter führen:

A higher threshold will require louder audio to activate the model, and thus might perform better in noisy environments. (externe Seite, developers.openai.com)

Sie fängt den Fall, um den es hier geht, und hört genau dort auf. Ein Modell, das bei klarem Signal danebengreift, kommt an ihr vorbei, denn dort war etwas zu hören. Die zweite Stufe sitzt deshalb hinter der Erkennung und sieht sich das Ergebnis an: Eine Wiederholungsschleife oder eine der bekannten Abspann-Formeln wird verworfen, bevor sie irgendwo landet.

Die dritte Stufe ist die Wahl selbst, und sie ist die billigste. Ein dritter Kandidat blieb bei denselben Stille-Aufnahmen stumm, und das entschied über den Standard, gegen die bessere Fehlerrate. Welcher es war, steht im nächsten Abschnitt.

Klein kann reichen

Die Modellwahl folgt hier derselben Logik wie in Grundkurs, Kapitel 10, und die kleinen Modelle stehen besser da, als man erwartet. Ein Erkennungsmodell mit 600 Millionen Parametern deckt heute

25 European languages (externe Seite, huggingface.co)

ab und erkennt die gesprochene Sprache von selbst:

The model automatically detects the language of the audio and transcribes it without requiring additional prompting. (externe Seite, huggingface.co)

Das passt auf einen Laptop, und dort ist es elfmal schneller als das große Modell: 0,0060 gegen 0,067 als Verhältnis von Rechenzeit zu Audiodauer, aus derselben Messung vom 19.04.2026. Bezahlt wird das mit Genauigkeit, und zwar auf beiden Zahlen. 16,19 statt 10,68 Prozent über alle Wörter, 30,36 statt 25,00 Prozent auf den Fachbegriffen.

Standard wurde es trotzdem, und der Grund steht im Abschnitt davor: Es ist der Kandidat, der bei Stille schweigt. Über die Wahl entscheidet das Verhalten im dümmsten Fall, die bessere Zahl kommt danach.

Messen statt schätzen

Die Dokumentation sagt selbst, woran eine Einstellung zu prüfen ist:

Don’t choose a setting from synthetic audio alone. (externe Seite, developers.openai.com)

Eine saubere Studioaufnahme sagt nichts über ein Diktat im Auto, über eine Telefonleitung oder über zwei Sprachen in einem Satz. Wie viel das ausmacht, misst die Modellkarte (externe Seite, huggingface.co) des kleinen Modells selbst: Dieselben acht Testdatensätze, einmal sauber und einmal mit Musik und Störgeräusch so laut wie die Stimme, ergeben 6,34 gegen 11,66 Prozent.

Zur eigenen Aufnahme wird der Abstand noch größer. Auf jenen acht Datensätzen steht dieses Modell bei 6,34 Prozent, auf der Referenzaufnahme weiter oben bei 16,19. Beide Zahlen sind sauber gemessen, sie zählen nur etwas anderes: dort englische Standardaufnahmen, ausgewertet ohne Satzzeichen und Großschreibung, hier sechs Minuten deutsches Fachdiktat.

Wer eine Erkennung auswählt, braucht deshalb eine eigene Aufnahme aus dem eigenen Alltag und eine von Hand geschriebene Sollfassung dazu. Der Aufwand liegt bei einem halben Tag. Er beantwortet eine andere Frage als die Rangliste: Die sagt, welches Modell im Mittel vorn liegt, die eigene Aufnahme sagt, welches bei Ihnen vorn liegt.

Beide Bauformen aus Tiefe 1 funktionieren. Interessant wird der Vergleich an der Frage, was jede von beiden unterwegs verliert, denn das steht in keiner Werbeaussage und entscheidet später über den Umbau.

Die Kette verliert, was sie nicht mitnimmt

Der Übergabepunkt zwischen Erkennung und Textmodell ist eine Zeichenkette. Damit endet dort alles, was sich nicht schreiben lässt: Tonhöhe, Lautstärke, ein Zögern mitten im Satz, Ironie.

Das Textmodell bekommt „Ja, das passt schon“ und erfährt nie, ob das zustimmend oder resigniert klang. Für eine Diktierfunktion ist das ohne Belang. Für ein Gespräch, in dem jemand unsicher wird oder ärgerlich, fehlt genau das Signal, das ein Mensch zuerst hören würde.

Ein Teil davon ließe sich retten, und daran hängt der Unterschied zwischen der Bauform und ihrer üblichen Ausführung. Das Erkennungsmodell aus Tiefe 2 gibt neben dem Text auch

Accurate word-level and segment-level timestamps (externe Seite, huggingface.co)

aus, und wer sie weiterreicht, gibt dem Textmodell Sprechtempo und Pausenlängen mit. Getan wird das selten, weil die Schnittstelle dahinter einen Prompt erwartet und eine Tabelle mit Zeitangaben dort erst einmal untergebracht werden muss. Was ankommt, entscheidet damit die Übergabe, die jemand gebaut hat. Das Verfahren gibt mehr her.

Umgekehrt ist der Textzwischenstand der ganze Vorteil der Kette. Die Herstellerdoku empfiehlt sie ausdrücklich dann, wenn dieser Stand gebraucht wird:

Use this path when each stage needs to be visible or replaceable. (externe Seite, developers.openai.com)

Sichtbar und austauschbar sind hier zwei verschiedene Zusagen. Sichtbar heißt, es gibt ein Protokoll, gegen das man prüfen kann. Austauschbar heißt, die Erkennung lässt sich wechseln, ohne den Rest anzufassen.

Was auf der anderen Seite ankommt

Was die Kette wegwirft, ist beim durchgehenden Modell nicht bloß vorhanden, es wird verwertet. Die Dokumentation zur Tonverarbeitung stellt das an den Anfang:

Gemini understands non-speech sounds (externe Seite, ai.google.dev)

Genannt werden dort Vogelgesang und Sirenen, dazu die Trennung mehrerer Sprecher und der Bezug auf Zeitpunkte in einer Aufnahme. Husten, Klopfen, Tastaturgeräusche und ein Gespräch am Nebentisch fallen in dieselbe Klasse.

Wie weit das reicht, zeigen zwei Einstellungen, die es nur bei dieser Bauform gibt. Die eine gibt dem Modell die Entscheidung, ob es überhaupt antwortet:

Gemini can proactively decide not to respond if the content is not relevant (externe Seite, ai.google.dev)

Die andere richtet den Ton der Antwort nach dem der Frage:

lets Gemini adapt its response style to the input expression and tone (externe Seite, ai.google.dev)

Beides setzt voraus, dass mehr ankommt als der Wortlaut. Beides sagt zugleich etwas über den Stand dieser Bauform. Die zwei Einstellungen laufen nur über eine Vorabfassung der Schnittstelle, und im neuesten Live-Modell desselben Anbieters fehlen sie ganz:

This feature is not supported in Gemini 3.1 Flash Live. (externe Seite, ai.google.dev)

Der Satz steht in derselben Dokumentation zweimal, einmal unter jeder der beiden Einstellungen. Belegt ist damit, dass die Bauform beides hergibt. Wer es einschalten will, geht beim Modell einen Schritt zurück.

Der andere Anbieter formuliert dieselbe Fähigkeit als Anweisung an das Modell, und die Aufzählung darin ist der eigentliche Beleg:

If the latest audio is silence, background noise, hold music, TV audio, side conversation, or speech not addressed to you (externe Seite, developers.openai.com)

Wartemusik von Fernsehton und beides von einem Satz zu unterscheiden, der jemand anderem gilt, ist eine Leistung, die eine Textübergabe strukturell nicht erbringen kann. Dort steht nur, was gesagt wurde.

Praktisch fällt das am stärksten bei drei Dingen ins Gewicht: bei einer Unterhaltung mit Nebengeräuschen, bei mehreren Personen im Raum und überall dort, wo die Stimmung des Gegenübers die richtige Antwort mitbestimmt.

Das Protokoll ist nicht das Gesprochene

Hier kommt der Teil, der beim Bauen überrascht. Auch beim durchgehenden Modell gibt es eine Abschrift, und sie entsteht auf einem eigenen Weg. Der Hersteller schreibt das in seiner Schnittstellenbeschreibung ohne Umschweife hin:

Input audio transcription is not native to the model, since the model consumes audio directly. (externe Seite, developers.openai.com)

Und zur Belastbarkeit dieser Abschrift:

should be treated as guidance of input audio content rather than precisely what the model heard (externe Seite, developers.openai.com)

Es ist also ein zweites Erkennungsmodell, das danebenherläuft:

this relies on a separate ASR model (externe Seite, developers.openai.com)

Using different models for transcription and response generation can lead to discrepancies. (externe Seite, developers.openai.com)

Das dort abgedruckte Beispiel ist lehrreich, weil beide Seiten in dieselbe Richtung falsch liegen könnten und es nicht tun. Mitgeschrieben wird eine Lautfolge ohne Sinn, verstanden wird ein Unfall mit dem Auto. Das Modell hat also recht, und das Protokoll hat unrecht.

Genau dieselbe Erfahrung macht man im Betrieb: Die Abschrift weicht ab, und zwar sichtbar. Die eigene Dokumentationsseite zur Transkription innerhalb einer Sprachsitzung empfiehlt dagegen dasselbe Mittel wie die eigenständige Erkennung:

Use keywords for product names, acronyms, and other literal terms that may appear in the audio. (externe Seite, developers.openai.com)

Der Ausweg steht in derselben Anleitung und ist der Grund, warum sie geschrieben wurde: Man lässt die Abschrift von demselben Modell erzeugen, das auch geantwortet hat, über einen zweiten Auftrag, der die Unterhaltung unberührt lässt. Mit dem Ergebnis ist die Anleitung vorsichtiger, als man erwartet:

Reduced Mismatch: The same model is used for both transcription and generation, minimizing inconsistencies between what the user says and how the agent responds. (externe Seite, developers.openai.com)

Das entscheidende Wort ist minimizing. Die Abweichung wird kleiner. Dazu kommt ein Preis, den dieselbe Anleitung ausrechnet, gemessen am getrennten Erkennungsmodell:

Using only latest user turn: 3-5x (externe Seite, developers.openai.com)

Using full session context: 16-22x (externe Seite, developers.openai.com)

Der zweite Fall ist der interessante. Man schickt die ganze Sitzung mit, damit ein mehrfach genannter Name richtig ankommt, und bezahlt sie bei jeder Abschrift erneut. Der Betrag wächst also mit der Länge des Gesprächs. Wie eine Abrechnung nach Anfrage zustande kommt, steht in Grundkurs, Kapitel 11.

Der Eingriff sitzt woanders

Naheliegend ist der Schluss, dem durchgehenden Modell fehle jede Stelle, an der ein Programm prüfen könnte. Das trifft nur für einen Zeitpunkt zu, nämlich für den vor dem Sprechen. Die Kette hat dort einen Text und damit eine Bedingung, die man abfragen kann. Bei der anderen Bauform gibt es diesen Punkt nicht.

Zwei andere gibt es sehr wohl. Die Abschrift kommt fortlaufend als Ereignis herein, und eine laufende Antwort lässt sich abbrechen, dazu der bereits gesprochene Teil aus der Unterhaltung entfernen. Wer also eine Regel verletzt sieht, kann mitten im Satz eingreifen, und der Rest wird nie gesagt.

Der Unterschied zur Kette liegt damit im Zeitpunkt und in der Gewissheit. Die Kette prüft vorher und weiß genau, worauf sie prüft. Das durchgehende Modell prüft währenddessen, auf einer Abschrift, die eine Näherung ist.

seitlich verschiebbar

eigene Darstellung, Stand 07.08.2026

Für den Betrieb folgen daraus zwei Dinge. Erstens ist das Protokoll einer Sprachsitzung ein Nebenprodukt. Wer es als Beleg verwenden will, muss diesen Unterschied kennen, und der zweite Auftrag von oben verkleinert ihn nur. Zweitens ist die Pflege der Stichwortliste bei beiden Bauformen dieselbe Arbeit, und sie fällt auch dort an, wo man sie nicht erwartet.

Wo die Wartezeit hingeht

Bei der Kette wartet jede Stufe auf die vorige, und die Wartezeiten summieren sich. Das lässt sich mildern, indem jede Stufe zu arbeiten beginnt, bevor die vorige fertig ist, und genau daran hängt viel Aufwand.

Beim durchgehenden Modell fallen die Übergaben weg, und die Doku nennt das als das Merkmal dieser Bauform:

Use one model to interpret audio, decide what to do, and respond in speech. (externe Seite, developers.openai.com)

Die Wartezeit rutscht damit an andere Stellen. Auch dieses Modell wartet erst einmal darauf, dass jemand zu Ende spricht, überträgt über das Netz, denkt und erzeugt dann Ton. Bei Gemini 3.1 Flash Live, dem inzwischen als Vorgänger geführten Modell, ist die Denkstufe sogar eine eigene Einstellung, deren Voreinstellung mit der Wartezeit begründet ist:

Uses thinkingLevel to control thinking depth with settings like minimal, low, medium, and high. Defaults to minimal to optimize for lowest latency. (externe Seite, ai.google.dev)

Das Modell steht damit auf der niedrigsten von vier Denkstufen, damit die Antwort schnell kommt. Wer sie hochdreht, zahlt in derselben Währung wie an der Kette; was dahintersteckt, steht in Grundkurs, Kapitel 10.

Der Vorsprung bleibt trotzdem. Wer eine Aufgabe abarbeitet, bei der zwischen Frage und Antwort ohnehin etwas nachgeschlagen wird, verliert an der Kette wenig.

Ton ist eine eigene Datenart

Was in Beurteilen und Einordnen, Kapitel 01 über Eingaben steht, gilt für Sprache noch einmal eigens, denn in einer Aufnahme steckt mehr als ihr Inhalt. Sie enthält eine Stimme, und die ist ein Merkmal einer Person. Nach dem Abschnitt weiter oben enthält sie außerdem alles, was im Raum sonst noch zu hören war. Was daraus folgt, wenn sich dieses Merkmal nachbilden lässt, steht in Kapitel 09.

Die Anbieter behandeln Ton deshalb getrennt vom Text. Google führt dafür eine eigene Voreinstellung:

Your audio and Gemini Live videos and screenshares aren’t used to improve Google services by default. (externe Seite, support.google.com)

Diese Zusage fällt strenger aus als die für geschriebene Unterhaltungen bei demselben Anbieter. Zwei Einschränkungen hat sie trotzdem. „By default“ heißt, dass es eine Einstellung gibt, die das ändert, und die Seite, auf der der Satz steht, gilt für die Apps des Anbieters. Über die Schnittstelle, an der eine eigene Anwendung hängt, sagt sie nichts.

Was daneben steht, gilt weiter. Unterhaltungen werden gespeichert, ein Teil davon wird gelesen, und das Gelesene überlebt das Löschen:

Chats reviewed by human reviewers (and related data like your language, device type, location info, or feedback) are not deleted when you delete your activity. Instead, they are retained for up to three years. (externe Seite, support.google.com)

Wer die Datenschutzfrage für eine Sprachanwendung klärt, prüft die Angaben für Ton also gesondert, statt sie aus denen für Text abzuleiten, und er prüft sie für den Zugang, den er wirklich benutzt.