OpenAIs Assistants API endet: Warum KMU ihre KI-Chatbots jetzt prüfen müssen

Viele KI-Chatbots wirken im Alltag unspektakulär: Sie beantworten Website-Fragen, durchsuchen Dokumente, qualifizieren Leads oder helfen intern bei wiederkehrenden Aufgaben. Genau darin liegt das Risiko. Wenn so ein Assistent einmal funktioniert, gerät schnell in Vergessenheit, welche API, welche Speicherlogik und welche Tool-Anbindung darunter liegt. Bei OpenAI gibt es dafür jetzt ein sehr konkretes Ablaufdatum: Die Assistants API wird am 26. August 2026 abgeschaltet. Für österreichische KMU ist das keine Panikmeldung, aber ein guter Anlass für einen nüchternen Technik- und Prozesscheck.

Der wichtigste Punkt: Es geht nicht darum, ob KI weiter sinnvoll ist. Es geht darum, ob bestehende KI-Workflows wartbar, dokumentiert und migrierbar sind. Wer heute einen Website-Chatbot, einen Angebotsassistenten, eine interne Dokumentensuche oder einen einfachen Agenten auf der alten Assistants API betreibt, sollte nicht bis zur letzten Augustwoche warten. Migration klingt technisch, entscheidet aber am Ende über Vertrieb, Servicequalität, Datenschutz, Kostenkontrolle und Vertrauen.

Was OpenAI konkret ändert

OpenAI beschreibt die Assistants API inzwischen als Legacy-Pfad. Nach eigener Darstellung ist die API nach erreichter Funktionsparität mit der Responses API abgekündigt; die Abschaltung ist für den 26. August 2026 angesetzt. Die empfohlene Richtung ist die Responses API, die Eingaben und Ausgaben direkter modelliert und neue Funktionen wie Deep Research, MCP-Anbindungen und Computer Use besser integriert.

Für Entwickler klingt das zunächst wie ein normaler Versionswechsel. In der Praxis ist es häufig mehr als ein anderer Endpoint. Viele ältere Implementierungen denken in Assistenten, Threads, Messages und Runs. Neuere Implementierungen mit der Responses API bilden Aufgaben, Tool-Aufrufe, Ausgaben, Konversationszustand und Freigaben anders ab. Dazu kommen File Search, Function Calling, Streaming, Logging, Kostenlimits und Berechtigungen. Wenn ein Assistent nur Text beantwortet, kann die Migration überschaubar sein. Wenn er aber CRM-Daten liest, Dateien durchsucht, Buchungen vorbereitet oder interne Systeme anstößt, wird daraus ein kleines Betriebsprojekt.

Das passt zu einem größeren Trend: KI-Plattformen bewegen sich weg vom Experimentierbaukasten hin zu produktionsfähigen Agenten- und Tool-Architekturen. Genau deshalb hatten wir bereits beim Beitrag OpenAI beendet Agent Builder und Evals: Warum KMU KI-Workflows portabel bauen sollten vor der Abhängigkeit von einzelnen Oberflächen gewarnt. Die Assistants-Frist macht diesen Punkt jetzt noch konkreter.

Warum das österreichische KMU besonders betrifft

Österreichs Wirtschaft ist stark mittelständisch geprägt. Laut Bundesministerium für Wirtschaft zählten im Jahr 2024 rund 604.100 Unternehmen in der marktorientierten Wirtschaft zu den KMU; das waren 99,7 Prozent aller heimischen Unternehmen in diesem Bereich. Viele davon haben keine eigene Plattformabteilung, sondern arbeiten mit Agenturen, Freelancern, SaaS-Tools, WordPress-Plugins oder kleinen internen Automationen.

Gerade deshalb sind KI-Integrationen oft pragmatisch entstanden: ein Chatbot auf der Website, ein Dokumentenassistent für Angebote, eine interne Suche in Preislisten, ein Formular, das Anfragen vorsortiert. Das ist völlig legitim. Aber wenn niemand mehr weiß, ob darunter die Assistants API, die Chat Completions API, eine No-Code-Integration oder ein Agentenframework läuft, wird ein Abschaltdatum schnell zum operativen Risiko.

Für Kundinnen und Kunden ist die Ursache egal. Sie sehen nicht, ob eine API abgekündigt wurde. Sie sehen nur, dass der Chatbot keine Antworten liefert, Anhänge nicht mehr findet oder ein Lead-Flow hängen bleibt. Für ein KMU kann das im ungünstigen Moment mehr Schaden anrichten als ein kleiner technischer Fehler, weil der Assistent oft genau dort steht, wo Vertrauen entsteht: auf der Website, im Support oder im Vertrieb.

Der erste Schritt ist ein KI-Inventar, kein Rewrite

Eine sinnvolle Reaktion beginnt nicht mit hektischem Umbau. Sie beginnt mit einer einfachen Frage: Wo arbeitet im Unternehmen bereits KI mit, und welche davon hängt an OpenAI-APIs?

Ein brauchbares Inventar unterscheidet mindestens fünf Dinge. Erstens: Welche Anwendung ist öffentlich sichtbar und welche nur intern? Zweitens: Werden personenbezogene Daten, Kundendaten, Bewerbungen oder Vertragsinformationen verarbeitet? Drittens: Ist der Assistent rein lesend oder darf er Aktionen vorbereiten oder auslösen? Viertens: Welche Dateien, Datenbanken oder Tools sind angebunden? Fünftens: Gibt es Tests, Logs und eine verantwortliche Person, die Fehler bewerten kann?

Für Ostheimer gehört genau diese Bestandsaufnahme in den Kernbereich Künstliche Intelligenz für Unternehmen. KI-Beratung ist hier nicht die Auswahl des neuesten Modells, sondern die Übersetzung eines Arbeitsprozesses in eine robuste technische Lösung: mit Datenquellen, Rollen, Grenzen, Kostenrahmen, Testfällen und einem klaren Fallback, falls ein Modell oder ein Anbieter sich ändert.

Was bei der Migration wirklich geprüft werden sollte

Eine Assistants-zu-Responses-Migration sollte nicht nur fragen: Bekommen wir wieder eine Antwort? Besser ist ein kleiner Abnahmekatalog, der echte Geschäftsfälle abdeckt.

Für einen Website-Chatbot könnten das typische Fragen zu Preisen, Leistungen, Kontaktwegen, Liefergebieten und Ausschlüssen sein. Für einen internen Dokumentenassistenten braucht es Fälle mit aktuellen, veralteten und widersprüchlichen Dokumenten. Für einen Lead-Assistenten zählen Datenschutz, Einwilligung, Übergabe an Menschen und die Frage, welche Angaben niemals automatisch bewertet werden dürfen.

Technisch lohnt sich ein Parallelbetrieb. Die alte Implementierung bleibt zunächst aktiv, während eine neue Responses-Variante mit denselben Beispielanfragen getestet wird. Unterschiede werden dokumentiert: Antwortqualität, Quellenbezug, Geschwindigkeit, Tokenkosten, Verhalten bei fehlenden Informationen, Verhalten bei Tool-Fehlern. Erst wenn diese Punkte passen, wird umgeschaltet.

Besonders wichtig sind Tool-Aufrufe. OpenAI beschreibt Function Calling als Möglichkeit, Modelle mit externen Systemen und Daten zu verbinden. Das ist nützlich, aber nicht harmlos. Ein Tool, das nur Öffnungszeiten liest, hat ein anderes Risiko als ein Tool, das einen Termin bucht, ein Ticket aktualisiert oder Kundendaten abruft. Wer hier sauber migriert, definiert Tool-Schemas eng, prüft Eingaben serverseitig und protokolliert, was der Assistent angefordert und was das eigene System tatsächlich ausgeführt hat.

Die Chance: Weniger Prototyp, mehr Betrieb

Der erzwungene Blick auf die API kann positiv sein. Viele erste KI-Projekte wurden unter Zeitdruck gebaut: Prompt in die Oberfläche, ein paar Dateien hochgeladen, erster Chatbot fertig. Das war als Experiment okay, aber für den Betrieb zu dünn. Die Migration ist eine Gelegenheit, die Architektur aufzuräumen.

Dazu gehört, Prompts und Systemanweisungen versioniert im Projekt abzulegen, statt sie nur in einem Dashboard zu pflegen. Dazu gehört, Testfragen zu speichern, damit neue Modelle und neue API-Versionen vergleichbar bleiben. Dazu gehört auch, Wissensquellen bewusst zu kuratieren: Welche PDF ist noch gültig? Welche Preisliste darf ein Bot verwenden? Welche Antwort muss immer an eine Person eskaliert werden?

Für komplexere Abläufe ist die Seite AI Agent Entwicklung der passendere Anschluss: Dort geht es nicht nur um Antworten, sondern um Agenten, die mit Tools arbeiten, Übergaben auslösen und dabei kontrollierbar bleiben müssen. Bei öffentlichen Chatbots auf Websites spielt zusätzlich Webdesign hinein, weil Oberfläche, Ladezeit, Tracking, Barrierefreiheit und Vertrauen genauso wichtig sind wie der Modellaufruf im Hintergrund.

Grenzen: Migration löst keine Governance-Probleme automatisch

Die Responses API macht eine alte Integration nicht automatisch sicher, wirtschaftlich oder korrekt. Sie schafft nur eine modernere Grundlage. Entscheidend bleibt, wie der Assistent eingesetzt wird.

Ein Beispiel: Wenn ein Bot bisher vage Antworten aus veralteten Dokumenten gegeben hat, wird er nach der Migration nicht automatisch fachlich besser. Wenn Rollen und Freigaben fehlen, bleiben sie fehlend. Wenn niemand Kosten überwacht, können längere Tool-Ketten teurer werden als erwartet. Und wenn ein Bot mit Kundinnen und Kunden spricht, muss auch die rechtliche Transparenz stimmen.

Hier kommt der EU AI Act ins Spiel. Die österreichische RTR-KI-Servicestelle weist darauf hin, dass Transparenzpflichten nach Artikel 50 für direkt interagierende KI-Systeme ab 2. August 2026 relevant werden. Vereinfacht gesagt: Wenn Menschen mit einem KI-System sprechen, muss in vielen Fällen erkennbar sein, dass es KI ist. Das ist keine Rechtsberatung, aber ein sehr praktischer Hinweis für Website-Chatbots, Voicebots und automatisierte Supportstrecken. Die technische Migration und die sichtbare Nutzerinformation sollten deshalb gemeinsam geprüft werden.

Ein pragmatischer 30-Tage-Plan

Für KMU reicht oft ein schlanker Plan, solange er konsequent ist.

Woche eins: Inventar. Alle KI-Funktionen sammeln, Anbieter und API-Pfade prüfen, Verantwortliche benennen, Datenarten notieren. Dazu gehören auch scheinbar kleine Integrationen in Formularen, internen Tools oder WordPress-Plugins.

Woche zwei: Priorisieren. Öffentliche Systeme, Systeme mit personenbezogenen Daten und Systeme mit Tool-Aktionen kommen zuerst. Rein interne Texthelfer ohne kritische Daten sind meist weniger dringend.

Woche drei: Parallelmigration. Eine Responses-Version wird aufgebaut, mit realen Testfällen geprüft und gegen die bisherige Variante verglichen. Fehlerfälle sind wichtiger als Schönwetterfragen.

Woche vier: Rollout. Umschalten, Monitoring aktivieren, Logs prüfen, Kosten beobachten, Fallback sichtbar halten. Danach wird dokumentiert, welche Prompts, Tools, Datenquellen und Freigaben produktiv sind.

Dieser Plan ist bewusst unspektakulär. Genau darin liegt sein Wert. KI-Projekte werden erwachsen, wenn sie nicht mehr von Demos leben, sondern von Betrieb, Tests und klaren Zuständigkeiten.

Was Ostheimer daraus praktisch machen kann

Ostheimer kann bestehende KI-Assistenten auf drei Ebenen prüfen. Erstens technisch: Welche API, welche Modelle, welche Tools und welche Datenquellen sind im Einsatz? Zweitens fachlich: Welche Antworten müssen stimmen, welche Grenzen braucht der Assistent, wo ist eine menschliche Übergabe nötig? Drittens betrieblich: Wer überwacht Logs, Kosten, Änderungen und Fristen?

Das Ergebnis muss nicht immer ein großes Projekt sein. Manchmal reicht ein Migration Audit mit klarer Ampel: sofort migrieren, später einplanen, abschalten oder neu bauen. In anderen Fällen ist ein sauberer Neuaufbau sinnvoller, etwa wenn aus einem einfachen Chatbot ein Agent mit CRM-Anbindung, Dokumentensuche oder Supportübergabe werden soll. Wichtig ist, die Entscheidung vor dem 26. August 2026 zu treffen, nicht danach.

Fazit

OpenAIs Assistants-Ende ist kein Grund zur Hektik, aber ein sehr guter Filter für KI-Reife. Wer weiß, wo KI im Unternehmen arbeitet, welche Daten sie nutzt und welche Aktionen sie auslösen darf, kann relativ entspannt migrieren. Wer das nicht weiß, sollte jetzt anfangen.

Für österreichische KMU ist die wichtigste Lehre nicht, dass eine API ausläuft. Die wichtigste Lehre ist: KI-Systeme brauchen denselben Betriebsblick wie Websites, Kampagnen oder Buchhaltungstools. Sie müssen auffindbar, dokumentiert, testbar und austauschbar sein. Dann wird ein Abschaltdatum nicht zur Krise, sondern zu einem sinnvollen Wartungsfenster.

Quellen

OpenAI Developers: Assistants migration guide, abgerufen am 1. Juli 2026; nennt die Abschaltung der Assistants API zum 26. August 2026.
OpenAI Developers: Migrate to the Responses API, abgerufen am 1. Juli 2026; beschreibt die Responses API als zukünftige Richtung für Agenten.
OpenAI Developers: Deprecations, abgerufen am 1. Juli 2026; enthält weitere Plattform-Abkündigungen vom Juni 2026.
OpenAI Developers: Function calling, abgerufen am 1. Juli 2026; beschreibt Tool-Aufrufe als Schnittstelle zu externen Systemen.
Bundesministerium für Wirtschaft, Energie und Tourismus: KMU in Österreich, abgerufen am 1. Juli 2026.
RTR KI-Servicestelle: FAQ zum AI Act, abgerufen am 1. Juli 2026; Hinweise zu Transparenzpflichten ab 2. August 2026.