:quality(78))
Eine KI-Anbindung kann monatelang zuverlässig laufen und trotzdem ein Ablaufdatum bekommen. Anthropic hat am 30. September angekündigt, Claude Sonnet 4.5 auf seiner API zum 30. November 2026 einzustellen. Wer das Modell in einer eigenen Anwendung nutzt, sollte jetzt nachsehen, wo es hinterlegt ist. Die Nachricht betrifft auch Unternehmen, deren Mitarbeitende den Modellnamen im Alltag nie sehen.
Die Ankündigung nennt konkret claude-sonnet-4-5-20250929. Als Ersatz empfiehlt Anthropic Sonnet 5.5. Damit steht für betroffene Teams eine überschaubare, aber wichtige Betriebsaufgabe an: Wie lässt sich der Wechsel prüfen, bevor ein laufender Prozess davon abhängt? Ankündigung vom 30. September.
Zuerst klären, welche Anbindung betroffen ist
„Deprecated“ bedeutet laut Anthropic, dass ein Modell noch funktioniert, aber nicht mehr empfohlen wird. Nach der Stilllegung schlagen Anfragen an das betreffende Modell fehl. Der angekündigte Termin ist deshalb ein sinnvoller Anlass, die eigene Bestandsliste zu prüfen.
Dabei zählt der konkrete Zugangsweg. Amazon Bedrock und Google Cloud haben eigene Zeitpläne; aus der Meldung zur Claude API lässt sich deren Abschaltdatum nicht ableiten. Wer Claude über eine fertige Fachanwendung bezieht, sollte beim Anbieter nachfragen, welche Version dahinterliegt und wer die Umstellung übernimmt. Die Nutzung einer Claude-App allein belegt noch keine betroffene eigene API-Integration.
Für direkte API-Kunden beschreibt Anthropic einen hilfreichen Einstieg: Auf der Usage-Seite der Console lässt sich ein CSV-Export mit Nutzung nach API-Schlüssel und Modell abrufen. Lebenszyklus und Nutzungsprüfung.
Unsere Empfehlung wäre, diese technische Liste um eine betriebliche Spalte zu ergänzen: Welcher Arbeitsablauf hängt daran? Ein interner Textentwurf braucht andere Vorkehrungen als eine Anwendung, die Ergebnisse automatisiert an weitere Systeme übergibt. Außerdem sollte für jeden betroffenen Ablauf eine verantwortliche Person feststehen. Eine Liste voller Schlüsselbezeichnungen hilft wenig, wenn niemand den dazugehörigen Prozess kennt.
Der Modellname ist nur ein Teil des Wechsels
Ein Austausch der Kennung ist schnell gemacht. Ob dieselbe Anfrage beim neuen Modell akzeptiert wird, muss separat geprüft werden. Ein konkretes Beispiel aus Anthropics Migrationsanleitung zu Sonnet 5.5: Erzwungene Werkzeugnutzung über tool_choice mit any oder tool führt dort zu einem Fehler mit Status 400. Anwendungen, die sich auf diese Einstellung verlassen, brauchen eine Anpassung. Migrationsanleitung zu Sonnet 5.5.
Dieses Beispiel ist kein vollständiger Umstellungsplan für Sonnet 4.5. Der tatsächliche Aufwand hängt von den verwendeten Funktionen ab. Deshalb würden wir zuerst eine vorhandene Anfrage in einer getrennten Testumgebung ausführen und dann die relevanten Optionen anhand der aktuellen Anleitung durchgehen. Vertrauliche Inhalte gehören dabei nur in die dafür freigegebene Umgebung.
Eine erfolgreiche API-Antwort beantwortet außerdem noch keine fachliche Frage. Der Aufruf kann technisch funktionieren und ein Ergebnis liefern, das für den nächsten Verarbeitungsschritt ungeeignet ist. Genau diesen Unterschied sollte die Abnahme sichtbar machen.
Mit bekannten Fällen vergleichen
Nehmen wir als hypothetisches Beispiel eine Anwendung, die aus eingehenden Anfragen einen Entwurf für die interne Bearbeitung erstellt. Für den Modellwechsel könnte das Team einige freigegebene Testfälle auswählen: eine vollständige Anfrage, einen Text mit fehlenden Angaben und einen Fall mit widersprüchlichen Informationen. Erwartete Ergebnisse werden vorher festgehalten.
Bei der vollständigen Anfrage prüfen die Verantwortlichen, ob die wichtigen Angaben erhalten bleiben. Beim unvollständigen Fall sollte nachvollziehbar sein, welche Information fehlt. Der widersprüchliche Text darf keine scheinbar sichere Aussage erzeugen, die der nächste Bearbeiter ungeprüft übernimmt. Welche Formulierung akzeptabel ist, entscheidet das Team anhand seines tatsächlichen Prozesses.
So entsteht ein brauchbarer Vergleich mit der bisherigen Lösung. Er muss weder riesig noch besonders elegant sein. Wichtiger ist, dass bekannte Problemfälle enthalten sind und jemand die Ergebnisse fachlich beurteilt. Bei einer individuellen KI-Softwareentwicklung würden wir diese Fälle als wiederholbare Prüfung der Integration festhalten, damit sie beim nächsten Wechsel erneut verfügbar sind.
Den Übergang vor dem letzten Tag planen
Wir würden die Umstellung mit etwas Abstand zum angekündigten Termin einplanen. Bis dahin sollte feststehen, wer den Wechsel freigibt, wie Fehler auffallen und was bei einem gescheiterten Test passiert. Ein Rückwechsel auf das alte Modell hilft nach dessen Abschaltung nicht mehr. Für kritische Abläufe braucht es deshalb eine andere vorbereitete Ausweichmöglichkeit, etwa eine vorübergehende manuelle Bearbeitung.
Wer seine KI-Anbindungen noch nicht überblickt, kann mit einer kleinen Bestandsaufnahme beginnen. Eine KI-Beratung sollte hier zuerst die vorhandenen Abläufe und Zuständigkeiten klären. Ein neues Modell auszuwählen kommt danach.
Der angekündigte Termin lässt Zeit für einen geordneten Wechsel. Nutzen lässt sie sich am besten mit einer konkreten Frage: Können wir heute erklären, woran wir erkennen, dass unsere Anwendung mit dem Nachfolger weiterhin richtig arbeitet?
Quellen und Links
Quellenstand: 1. Oktober 2026. Der Abschalttermin ist eine Herstellerankündigung. Vorgehen und Testbeispiel sind redaktionelle Empfehlungen, keine dokumentierten Kundenerfahrungen. Titelbild: KI-generierte Illustration auf Basis des freigegebenen Porträts von Nikolas Gottschol.
:quality(78))
:quality(78))
:quality(78))
