Custom GPTs werden abgeschaltet so klappt der Umzug zu Plugins.

OpenAI schaltet Custom GPTs ab: Standardtermin ist der 11.12.2026, Enterprise-Workspaces mit genehmigtem Aufschub haben bis zum 11.02.2027 Zeit. Nachfolger sind Plugins, die Anweisungen als Skill, Wissensdateien als Reference Files und verbundene Apps übernehmen. Custom Actions, die gewählte Modellversion und die Freigabeeinstellungen wandern dagegen nicht automatisch mit, und das migrierte Plugin startet privat. Wer GPTs im Unternehmen produktiv nutzt, sollte deshalb nicht bis Dezember warten: Inventur, Referenztests, Ersatz für Actions und neue Freigaben brauchen einige Wochen. Im Folgenden finden Sie die Fristen, die Lücken der Migration, den Ersatz für Actions über Apps oder einen eigenen MCP-Server und einen realistischen Fahrplan bis Dezember. Stand Oktober 2026; einige Termine nennt OpenAI ausdrücklich als geplant, Details können sich noch ändern.

Was hat OpenAI zu Custom GPTs angekündigt und welche Fristen gelten?

Am 11.09.2026 hat OpenAI angekündigt, Custom GPTs auslaufen zu lassen. Custom GPTs sind die selbst konfigurierten ChatGPT-Varianten mit eigenen Anweisungen, Wissensdateien und optionalen Schnittstellen, die viele Teams für wiederkehrende Aufgaben nutzen. An ihre Stelle treten Plugins. Am 09.07.2026 hat OpenAI in ChatGPT das bisherige App Directory durch das Plugin Directory ersetzt. Ein Plugin bündelt Skills (wiederverwendbare Anweisungen und Arbeitsabläufe), Connected Apps, App-Templates und Extensions.

Laut Release Notes und Hilfeartikel von OpenAI gelten diese Termine:

Zwei Punkte sind für die Planung entscheidend. Erstens ist der Aufschub bis Februar keine automatische Verlängerung. Er gilt nur für Enterprise-Kunden, bei denen er genehmigt wurde, und die genauen Zeitpunkte können je Konto und Workspace abweichen. Zweitens sollen Enterprise-Nutzer ab dem 26.10.2026 keine neuen Custom GPTs mehr anlegen können. Bestehende, noch nicht migrierte GPTs lassen sich weiter bearbeiten, Entwürfe, die migriert werden sollen, müssen aber vorher veröffentlicht sein. Wer jetzt noch einen neuen Assistenten plant, baut ihn sinnvollerweise gleich als Plugin und spart sich die spätere Migration.

Inventur jetzt: Welche GPTs sind geschäftskritisch?

Vor der Migration steht die Bestandsaufnahme. In vielen Workspaces existieren mehr GPTs, als jemand im Blick hat: Experimente, Duplikate, Assistenten von Kollegen, die längst andere Aufgaben haben. Nicht jedes davon verdient den Umzug.

Erfassen Sie pro GPT: Ersteller, Zweck, Zahl der aktiven Nutzer, Knowledge-Dateien, Custom Actions (Schnittstellen zu externen Systemen) und angebundene Systeme sowie den Freigabekreis. Ordnen Sie danach jedes GPT einer von drei Klassen zu:

Nutzt Ihr Team GPTs anderer Ersteller, prüfen Sie, ob der jeweilige Anbieter ein Plugin bereitstellt. Gibt es keines, brauchen Sie einen Ersatz. Das sollte nicht erst in der Woche vor der Abschaltung auffallen.

Was wird bei der Migration übernommen und was nicht?

OpenAI bietet die Migration direkt in der Oberfläche „My GPTs“ an, sobald sie für das jeweilige Konto freigeschaltet ist („Migrate to plugin“). Aus einem GPT entsteht dabei ein Plugin. Grundlage ist die zuletzt veröffentlichte Version; Entwürfe und unveröffentlichte Änderungen werden nicht übertragen. Veröffentlichen heißt dabei nicht öffentlich teilen. Nicht alles kommt mit:

Das Original-GPT bleibt bis zur Abschaltung nutzbar, wird nach der Migration aber schreibgeschützt und kann vom Ersteller nicht gelöscht werden. Wichtige Änderungen sollten Sie also vorher abschließen. Bisherige Nutzer erhalten nicht automatisch Zugriff auf das neue Plugin. Für ein Team heißt das: Direkt nach der Migration kann zunächst nur die Person, die migriert hat, mit dem Plugin arbeiten, bis die Freigaben neu gesetzt sind. Legen Sie Migration, Test und Freigabe deshalb zeitlich eng zusammen und informieren Sie die Nutzer vorher.

Alte Gespräche bleiben laut OpenAI-Hilfe auch nach der Abschaltung zugänglich, dafür ist keine Aktion nötig. Ins Plugin wandern sie aber nicht. Ergebnisse, die nur in Chatverläufen stehen und die das Plugin künftig nutzen soll, etwa abgestimmte Textbausteine oder Formulierungen, gehören deshalb in ein Dokument oder direkt in die Reference Files.

Wie ersetzt man Custom Actions durch Apps oder einen MCP-Server?

Custom Actions waren die Schnittstellen, über die ein GPT per OpenAPI-Beschreibung externe Systeme aufrief, etwa ein CRM, ein Ticketsystem oder eine interne Datenbank. Sie sind der aufwendigste Teil des Umzugs, weil OpenAI sie nicht überträgt. Es gibt zwei Wege.

Weg 1: eine vorhandene App nutzen. Für verbreitete Dienste gibt es im Plugin Directory häufig schon eine fertige App. Prüfen Sie, ob sie die Funktionen abdeckt, die Ihre Action genutzt hat, und welche Daten sie lesen und schreiben darf. Das Kennzeichen „OpenAI Verified“ ersetzt laut OpenAI keine eigene Datenschutz- und Sicherheitsprüfung.

Weg 2: einen eigenen MCP-Server bauen. MCP (Model Context Protocol) ist ein offener Standard, über den KI-Anwendungen Werkzeuge und Daten anbinden. In der Plugin-Architektur liefert der MCP-Server die Werkzeuge, die vorher die Action bereitgestellt hat. Grundlagen zum Protokoll finden Sie im Artikel MCP-Protokoll im Mittelstand. Für den Ersatz von Actions zählen laut OpenAI-Entwicklerdokumentation vor allem diese Punkte:

• Erreichbarkeit: Der Server braucht einen öffentlichen HTTPS-Endpunkt, üblich ist Streamable HTTP unter /mcp, oder einen „Secure MCP Tunnel“. Eingebunden wird er in ChatGPT über „Add custom MCP server“.
• Anmeldung: Vorgesehen ist OAuth 2.1 mit Authorization Code Flow und PKCE, bei öffentlichen Daten auch ein Betrieb ohne Anmeldung. Eigene API-Schlüssel, Maschine-zu-Maschine-Grants wie Client Credentials und kundenseitige mTLS-Zertifikate werden nicht unterstützt. Actions, die mit einem festen API-Key liefen, brauchen also ein neues Anmeldekonzept.
• Werkzeugschnitt: Lieber mehrere eng gefasste Tools wie get_ticket und update_ticket als ein Universalwerkzeug. Kennzeichnungen wie readOnlyHint und destructiveHint zeigen dem Modell, ob ein Tool nur liest oder etwas unwiderruflich ändert.
• Bestätigung: Für unumkehrbare Aktionen empfiehlt OpenAI eine menschliche Bestätigung.

Typisches Beispiel: Ein Vertriebs-GPT hat über eine Action Kundendaten aus dem CRM gelesen, authentifiziert mit einem zentralen Service-Schlüssel. Nach der Migration fehlt diese Verbindung. Gibt es eine passende CRM-App, melden sich die Nutzer in der Regel mit ihrem eigenen Konto an, und es gelten ihre CRM-Rechte. Gibt es keine, wird ein kleiner MCP-Server mit zwei, drei Lese-Tools und OAuth-Anbindung an den vorhandenen Identity Provider gebaut. Das ist eine Entwicklungsaufgabe mit Test und Betrieb und gehört entsprechend in die Planung.

Wie prüfen Sie, ob das migrierte Plugin gleich gut arbeitet?

OpenAI weist ausdrücklich darauf hin, dass ein migriertes Plugin anders antworten kann, und empfiehlt, vertraute Prompts und mindestens einen schwierigeren Fall zu vergleichen: Wird der richtige Skill gewählt, das erwartete Referenzmaterial genutzt, das Ausgabeformat eingehalten, und stehen die nötigen Integrationen bereit? Der Grund liegt nahe: Die Modellwahl wird nicht übernommen, und ein Skill wird anders eingebunden als die Anweisungen eines GPT. Wie man Modellwechsel generell absichert, beschreibt der Artikel Modellwechsel ohne Reue.

Ein pragmatischer Testplan hat vier Schritte:

1. Referenz-Prompts sammeln, bevor Sie migrieren. 10 bis 20 echte Anfragen pro GPT, aus dem Arbeitsalltag der Nutzer. Speichern Sie die Antworten des alten GPT als Vergleich, solange es noch unverändert läuft.
2. Testfälle nach Typ mischen. Die OpenAI-Entwicklerdokumentation nennt für Plugins: direkte Anfragen, die ein bestimmtes Tool auslösen sollen; indirekte Formulierungen desselben Ziels; Folgefragen, die auf frühere Angaben zurückgreifen; schreibende Aktionen mit Berechtigungsprüfung; und Anfragen, bei denen das Plugin gerade nicht aktiv werden soll.
3. Nach festen Kriterien bewerten. Zum Beispiel: Fakten korrekt aus den Reference Files übernommen, Ausgabeformat eingehalten, richtiges Tool aufgerufen, keine unerwünschten Schreibzugriffe. Ein einfaches Raster „besser, gleich, schlechter“ reicht für den Anfang.
4. Nachschärfen und erneut testen. Häufige Ursachen für Abweichungen sind unklare Skill-Anweisungen, überholte Dateien oder zu breit beschriebene Tools.

Für die Abnahme hilft eine einfache Regel: Ein Plugin geht erst an das Team, wenn es bei den geschäftskritischen Referenz-Prompts mindestens so gut abschneidet wie das alte GPT. Bei Plugins mit eigenem MCP-Server lohnt sich zusätzlich ein direkter Tooltest, etwa mit dem MCP Inspector, bevor Sie in ChatGPT testen. So trennen Sie Fehler im Server von Fehlern in der Anweisung.

Wie regeln Sie Freigaben und Zugriff nach der Migration?

Weil Freigaben nicht übernommen werden und jedes migrierte Plugin privat startet, ist der Umzug ein guter Anlass, Zugriffe bewusst neu zu vergeben, statt gewachsene Freigaben ungeprüft zu kopieren.

• Verantwortliche benennen: Jedes Plugin bekommt eine fachlich verantwortliche Person, die Skill, Reference Files und Testfälle pflegt.
• Nutzerkreis festlegen: Wer hatte bisher Zugriff, wer braucht ihn wirklich? Plugins mit Zugriff auf Kunden- oder Personaldaten nur für die Rollen freigeben, die diese Daten auch sonst sehen dürfen.
• Rollenrechte prüfen: In Enterprise-Workspaces steuern Admins über Rollen, wer Plugins nutzen, hochladen, mit MCP erstellen und teilen darf. Laut OpenAI ist „Use plugins“ standardmäßig aktiv, „Upload plugins“ und „Create plugins with MCPs“ sind standardmäßig aus. Teilen („Share plugins“) und Veröffentlichen im Workspace-Verzeichnis („Publish plugins to workspace“) sind getrennte Rechte. In Business-Workspaces sind Apps standardmäßig aktiviert, eine bewusste Prüfung ist dort umso wichtiger.
• Dokumentieren: Eine kurze Liste mit Plugin, Zweck, verantwortlicher Person, Datenquellen und Freigabekreis genügt. Sie ist zugleich eine gute Grundlage für Ihre interne KI-Richtlinie.

Wer bisher keine Regeln für selbst gebaute Assistenten hatte, kann sie jetzt einführen, ohne einen eingespielten Ablauf zu stören. Die Migration erzwingt ohnehin, dass jede Freigabe neu angefasst wird.

Grenzen und Risiken der Migration.

Die Migrationsfunktion nimmt Ihnen das Kopieren ab, nicht die Verantwortung für das Ergebnis. Diese Punkte werden am häufigsten unterschätzt:

• Anderes Verhalten: Auch mit gutem Testplan bleiben Randfälle, die erst im Alltag auffallen. Planen Sie nach dem Rollout zwei bis drei Wochen ein, in denen Nutzer Abweichungen einfach melden können.
• Aufwand für Actions: Ein eigener MCP-Server ist ein produktives System. OpenAI rät, davon auszugehen, dass Prompt Injection und bösartige Eingaben den Server erreichen, alle Eingaben serverseitig zu prüfen, nur die nötigen Berechtigungen anzufordern und personenbezogene Daten vor dem Logging zu entfernen. Das erfordert Entwicklung, Betrieb und Wartung.
• Anmeldung ohne API-Key: Da feste API-Schlüssel nicht unterstützt werden, braucht ein authentifizierter MCP-Server einen OAuth-fähigen Identity Provider. Für kleinere Unternehmen ohne zentrale Anmeldung ist das ein eigenes Projekt.
• Verschiebbare Termine: Mehrere Termine nennt OpenAI ausdrücklich als geplant. Prüfen Sie den Hilfeartikel regelmäßig und planen Sie nicht auf die letzte Woche.
• Wissen in alten Chats: Bestehende Konversationen bleiben zwar zugänglich, fließen aber nicht ins Plugin ein. Was das Plugin künftig wissen soll, muss aktiv in Skill oder Reference Files übertragen werden.
• Plattformbindung: Plugins sind an ChatGPT und Codex gebunden. Ein MCP-Server lässt sich dagegen grundsätzlich auch von anderen MCP-fähigen Anwendungen nutzen. Wer ohnehin neu baut, gewinnt damit etwas Unabhängigkeit.

Fahrplan bis zur Abschaltung: Was Sie jetzt tun können.

Rechnet man vom 11.12.2026 zurück, bleiben ab Anfang Oktober gut neun Wochen. Ein realistischer Ablauf für ein Unternehmen mit einer Handvoll produktiv genutzter GPTs:

Enterprise-Kunden, die mehr Zeit brauchen, sollten früh über ihr Account-Team klären, welcher Termin für ihren Workspace gilt, statt sich stillschweigend auf einen Aufschub bis zum 11.02.2027 zu verlassen. Die Standard-E-Mails an Admins nennen laut OpenAI nur die Standardtermine. Für alle anderen ist der 11.12.2026 der Standardtermin.

Wenn Sie bei Inventur, Testplan oder dem Bau eines MCP-Servers Unterstützung suchen: In der KI-Beratung begleite ich solche Umstellungen von der Bestandsaufnahme bis zur Einweisung des Teams.

Häufige Fragen.

Wann werden Custom GPTs abgeschaltet?

Laut OpenAI ist der Standardtermin der 11.12.2026. Enterprise-Workspaces mit genehmigtem Aufschub können Custom GPTs bis zum 11.02.2027 nutzen. Für Enterprise ist zudem geplant, dass ab dem 26.10.2026 keine neuen Custom GPTs mehr angelegt werden können. Die Termine gelten Stand Oktober 2026 und können je Konto abweichen.

Funktionieren meine Custom Actions nach der Migration zum Plugin weiter?

Nein, Custom Actions werden nicht übernommen. Sie müssen durch eine passende App aus dem Plugin Directory oder durch einen eigenen MCP-Server ersetzt werden. Ein eigener MCP-Server meldet Nutzer per OAuth 2.1 an; feste API-Schlüssel, wie sie viele Actions genutzt haben, werden dafür nicht unterstützt.

Gehen meine Chats mit einem Custom GPT bei der Abschaltung verloren?

Nein. Laut OpenAI bleiben bestehende Konversationen mit Custom GPTs auch nach der Abschaltung zugänglich, dafür müssen Sie nichts tun. Sie werden aber nicht ins neue Plugin übernommen. Das Original-GPT wird nach der Migration schreibgeschützt. Ergebnisse aus alten Chats, die das Plugin künftig nutzen soll, etwa Textbausteine, übertragen Sie in den Skill oder die Reference Files.

Wer kann ein migriertes Plugin nutzen?

Zunächst nur die Person, die migriert hat, denn migrierte Plugins starten privat und Freigabeeinstellungen werden nicht übernommen. Bisherige Nutzer des GPT erhalten nicht automatisch Zugriff. Die Freigaben müssen neu gesetzt werden; in Enterprise-Workspaces steuern Admins zusätzlich über Rollen, wer Plugins nutzen, erstellen und teilen darf.

Muss ich für die Migration eines Custom GPT programmieren können?

Für GPTs ohne Custom Actions nicht: Anweisungen, Wissensdateien und verbundene Apps überträgt die Migrationsfunktion in der Oberfläche „My GPTs“. Danach ist vor allem Testen und Nachschärfen nötig. Programmierarbeit fällt an, wenn Actions durch einen eigenen MCP-Server ersetzt werden müssen, weil es keine passende App gibt.

Quellen und Stand.

• Custom GPT retirement and migration FAQ — OpenAI Help Center
• Plugins in ChatGPT — OpenAI Help Center
• ChatGPT — Release Notes (09.07.2026: Plugin Directory; 11.09.2026: geplante Abschaltung der Custom GPTs) — OpenAI Help Center
• Authentication (Plugins) — OpenAI Developers
• Build an MCP server — OpenAI Developers
• Connect and test your plugin — OpenAI Developers
• Security and privacy for plugins — OpenAI Developers
• OpenAI to Retire Custom GPTs, Replace Them with Plugins — Virtualization Review

Stand: 6. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen Ihre Custom GPTs geordnet zu Plugins umziehen? Unverbindlich anfragen — wir klären Inventur, Testplan und den Ersatz für Ihre Custom Actions. Mehr zu meinem Angebot: KI-Workshops für Unternehmen und KI-Beratung.