OpenAI hat am 26. August 2026 die Abschaltung von vier Transkriptionsmodellen angekündigt: whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe und gpt-4o-transcribe-diarize. Sie werden am 26. Februar 2027 außer Betrieb genommen. Als Zielmodelle nennt OpenAI gpt-live-transcribe und gpt-transcribe. Für Unternehmen ist das keine abstrakte Produktmeldung, sondern eine feste Betriebsfrist: Jeder produktive Audio-Workflow, der einen der alten Modellnamen verwendet, braucht vor diesem Datum eine getestete Alternative.
Was sich ändert – und welche Systeme betroffen sind
Betroffen sind nicht nur klassische Datei-Uploads. Die Modellliste umfasst bisherige Bausteine für Batch-Transkription, günstigere Varianten, Echtzeitpfade und Sprecherzuordnung. Deshalb reicht eine Suche nach whisper-1 allein nicht aus. Teams sollten Quellcode, Umgebungsvariablen, Workflow-Tools, Integrationsplattformen, serverseitige Funktionen und Anbieter-Konfigurationen nach allen vier Modellnamen prüfen. Zusätzlich gehören indirekte Abhängigkeiten auf die Liste: Ein Callcenter-Tool oder Meeting-Dienst kann OpenAI im Hintergrund nutzen, ohne dass der Modellname in der eigenen Anwendung sichtbar ist.
Bestätigt sind das Abschaltdatum und OpenAIs Empfehlung für die beiden Nachfolger. Nicht aus der Ankündigung ableitbar ist dagegen, dass ein Zielmodell jeden bisherigen Workflow ohne Anpassung ersetzt. Insbesondere bei Sprechertrennung, Streaming-Verhalten, Zeitmarken, Dateiformaten und nachgelagerten Automationen muss das Unternehmen die tatsächliche Funktionsgleichheit selbst prüfen. Auch Aussagen zu besserer Genauigkeit oder niedrigeren Kosten sollten erst nach Messungen mit eigenen Audiodaten getroffen werden.
gpt-live-transcribe oder gpt-transcribe: nach Prozess entscheiden
Die Modellwahl beginnt beim Prozess, nicht beim Namen. gpt-live-transcribe ist der naheliegende Kandidat, wenn Sprache während eines Gesprächs oder Ereignisses verarbeitet werden muss und Verzögerung unmittelbar die Nutzererfahrung beeinflusst. gpt-transcribe passt eher zu dateibasierten Abläufen, in denen Aufnahmen gesammelt, hochgeladen und anschließend verarbeitet werden. Ein Unternehmen mit beiden Mustern sollte zwei Migrationspfade planen, statt einen gemeinsamen Wrapper zu erzwingen. So bleiben Fehlerbudgets, Skalierung und Kosten je Anwendungsfall sichtbar.
Für Diarisierungs-Workflows ist besondere Vorsicht nötig. Die Abkündigung von gpt-4o-transcribe-diarize bestätigt noch nicht, dass bestehende Sprecherlabels, Segmentgrenzen und Ausgabeformate unverändert weiterlaufen. Wenn nachgelagerte Systeme Gesprächsanteile Mitarbeitenden, Kunden oder Rollen zuordnen, kann bereits eine kleine Strukturänderung Auswertungen verfälschen. Dieses Teilproblem braucht einen eigenen Testkorpus und ein separates Freigabegate.
Sechs Schritte für eine kontrollierte Migration
- Inventarisieren: Alle vier abgekündigten Modellnamen in Code, Konfigurationen, Automationen und Lieferantenverträgen suchen; pro Fundstelle Eigentümer und Geschäftskritikalität dokumentieren.
- Segmentieren: Batch-, Live- und Diarisierungsprozesse trennen und je Prozess das passende Zielmodell sowie notwendige Schnittstellenänderungen festlegen.
- Referenzdaten bilden: Reale, rechtmäßig nutzbare Audiobeispiele mit Akzenten, Störgeräuschen, Fachbegriffen und mehreren Sprechern zusammenstellen; sensible Inhalte minimieren.
- Parallel testen: Alte und neue Verarbeitung für denselben Korpus vergleichen und Wortfehler, Sprecherzuordnung, Latenz, Fehlerraten, Durchsatz und Gesamtkosten messen.
- Gestuft ausrollen: Zunächst interne oder risikoarme Volumen umstellen, Telemetrie beobachten und den Anteil nur bei bestandenen Qualitäts- und Betriebsgates erhöhen.
- Rückfall und Abschluss: Umschaltbaren Modellalias, klare Abbruchkriterien und eine Rückfalloption vorhalten; alte Konfigurationen erst nach stabiler Produktion entfernen.
Welche Freigabegates Entscheider verlangen sollten
Die Migration ist bestanden, wenn sie den Geschäftsprozess mindestens so zuverlässig trägt wie die bisherige Lösung. Dazu gehören fachliche Qualität, zulässige Latenz, kalkulierbare Kosten und ein stabiler Fehlerpfad. Für Gesprächsprotokolle kann die korrekte Sprecherzuordnung wichtiger sein als eine kleine Verbesserung der Wortgenauigkeit. Bei Echtzeit-Assistenten ist dagegen die Verzögerung kritisch. Die Grenzwerte sollten vor dem Test feststehen; nachträglich gewählte Kennzahlen machen aus einem Vergleich schnell eine Rechtfertigung.
Auch der Betrieb muss geprüft werden: Wie reagiert der Workflow auf Zeitüberschreitungen, Rate Limits, leere Audiodateien oder Verbindungsabbrüche? Bleiben Wiederholungen idempotent, oder entstehen doppelte Protokolle und Folgeaktionen? Sind Logs und Aufbewahrungsfristen mit den internen Datenschutzregeln vereinbar? Diese Punkte verursachen oft mehr Aufwand als der Austausch eines Modellstrings, bestimmen aber, ob die Umstellung im Tagesgeschäft stabil bleibt.
Die Assistants API zeigt, warum ein zentrales Deprecation-Register nötig ist
Im selben Changelog hält OpenAI fest, dass die Assistants API am 26. August 2026 abgeschaltet wurde und Anwendungen auf Responses API sowie Conversations API wechseln sollen. Das ist ein separater Plattformwechsel, aber eine wichtige Governance-Lehre: Abschaltungen dürfen nicht nur in einzelnen Entwicklungsteams verfolgt werden. Unternehmen brauchen ein zentrales Register für externe APIs und Modelle mit Verantwortlichem, Stichtag, betroffenen Systemen, Migrationsstatus und Eskalationsweg.
Für die Transkriptionsmodelle bleibt ausreichend Zeit, sofern die Arbeit jetzt beginnt. Die sinnvolle Reihenfolge lautet: Bestand sichtbar machen, Zielmodell nach Prozess wählen, mit eigenen Daten vergleichen, gestuft umstellen und den Februar-Termin nicht als Projektstart missverstehen. So wird aus einer erzwungenen Migration zugleich eine belastbare Prüfung von Qualität, Kosten und Betriebsfähigkeit.