Stand: 1. Oktober 2026
Wer sich in den vergangenen Jahren einen eigenen GPT gebaut hat, sollte sich ein Datum merken:
11. Dezember 2026.
OpenAI plant, Custom GPTs an diesem Tag einzustellen. Der Übergang betrifft grundsätzlich alle ChatGPT-Pläne. Migration, Plugin-Zugriff und einzelne Ausnahmen können jedoch je nach Account oder Workspace unterschiedlich ausfallen. Für qualifizierte Enterprise-Workspaces mit genehmigtem Aufschub nennt OpenAI derzeit den 11. Februar 2027.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Bevor jetzt jemand nervös wird:
ChatGPT wird nicht abgeschafft. Und auch GPT als zugrunde liegende Modelltechnologie verschwindet nicht.
Es geht um die sogenannten Custom GPTs – also jene spezialisierten ChatGPT-Assistenten, die wir mit eigenen Anweisungen, Wissen und teilweise zusätzlichen Funktionen ausgestattet haben.
Kurz erklärt
OpenAI ersetzt Custom GPTs nicht einfach durch einen neuen Namen. Bei der Migration werden ihre Bestandteile neu organisiert: Aus den Instructions wird ein Skill, Knowledge Files werden zu Referenzdateien und verbundene Apps werden in ein Plugin übernommen. Custom Actions, bestehende Unterhaltungen, das gewählte Modell und bisherige Sharing-Einstellungen werden dagegen nicht automatisch übertragen.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Und genau deshalb halte ich diese Änderung für wesentlich interessanter als eine normale Produktabschaltung.
Denn eigentlich verändert sich gerade das Grundprinzip, wie wir spezialisierte KI-Fähigkeiten bauen und benutzen.
Was war eigentlich ein Custom GPT?
Wer noch nie selbst einen GPT gebaut hat, kann sich das ungefähr so vorstellen:
Man nimmt ChatGPT und gibt ihm zusätzliche Regeln, Wissen und gegebenenfalls Zugriff auf andere Systeme.
So konnte aus dem allgemeinen ChatGPT beispielsweise ein persönlicher Strategie-Berater, ein HR-Assistent, ein Research-Spezialist oder ein Experte für agile Transformation werden.
Das war unglaublich praktisch.
Denn anstatt ChatGPT bei jeder neuen Unterhaltung wieder zu erklären, welche Rolle es übernehmen, welche Regeln es beachten und welches Wissen es verwenden soll, konnte man diese Informationen einmal im Custom GPT hinterlegen.
Der GPT war damit eine Art fertig eingerichteter Spezialist.
Und genau darin steckt gleichzeitig eine Schwäche dieses Konzepts.
Je mehr dieser Spezialist können sollte, desto mehr musste man in ihn hineinpacken: Anweisungen, Wissen, Regeln, Dateien, Schnittstellen, Sonderfälle und Beispiele.
Irgendwann entsteht daraus ein digitales Schweizer Taschenmesser.
Es kann viel.
Aber es wird zunehmend schwieriger zu erkennen, welche Bestandteile eigentlich für welche Aufgabe verantwortlich sind.
OpenAI zerlegt jetzt den Werkzeugkasten
Um die neue Welt zu verstehen, hilft eine einfache Analogie.
Stellen wir uns einen Handwerker vor.
Bisher haben wir diesem Handwerker eine große Werkzeugkiste gegeben. Darin befand sich alles, was dieser eine Spezialist benötigt.
Genau so funktionierte vereinfacht ein Custom GPT.
Jetzt wird dieses Prinzip modularer.
Vier Begriffe, die man kennen sollte
Skill: Ein wiederverwendbarer Arbeitsablauf, der ChatGPT erklärt, wie eine bestimmte Aufgabe durchgeführt werden soll. Skills können Anweisungen, Beispiele, Ressourcen, Skripte und Code enthalten. ChatGPT kann einen installierten Skill auch automatisch auswählen, wenn dessen Beschreibung zur Aufgabe passt.
Quelle: OpenAI – Skills in ChatGPT
App: Eine Verbindung zu einem externen Dienst oder System. Apps können externe Informationen und – abhängig von den jeweiligen Berechtigungen – Aktionen verfügbar machen.
Quelle: OpenAI – Apps in ChatGPT
Plugin: Ein Paket, das Skills, verbundene Apps und weitere Funktionen für bestimmte Arbeitsabläufe zusammenbringen kann. Einige Plugins enthalten mehrere Apps, andere bestehen ausschließlich aus Skills.
Quelle: OpenAI – Plugins in ChatGPT und Codex
Agent: Ein System, das Aufgaben im Auftrag eines Menschen mit einem hohen Grad an Eigenständigkeit ausführt. Ein Agent nutzt ein Sprachmodell zur Steuerung des Workflows und kann Werkzeuge abhängig vom aktuellen Zustand der Aufgabe auswählen.
Quelle: OpenAI – A practical guide to building agents
Und jetzt zurück zu unserem Handwerker.
Ein Skill ist die erlernte Arbeitsweise
Ein Skill beschreibt beispielsweise:
„So analysierst du ein Angebot.“
Oder:
„So prüfst du einen Projektstatus.“
Oder:
„So bereitest du ein Management-Briefing vor.“
Der Skill ist nicht einfach der Schraubenzieher.
Der Skill ist das Wissen darüber, wann ich welchen Schraubenzieher brauche und wie ich damit die Aufgabe erledige.
OpenAI beschreibt Skills entsprechend als wiederholbare Workflows rund um konkrete Nutzerziele.
Quelle: OpenAI Developer Documentation – Skills
Eine App öffnet die Tür zu einem anderen System
Vielleicht benötigt unser Handwerker Informationen aus einem Lager.
Oder er muss anschließend etwas in einem anderen System aktualisieren.
Eine App verbindet ChatGPT mit einem solchen externen Dienst.
Quelle: OpenAI – Apps in ChatGPT
MCP verbindet KI mit Werkzeugen und aktuellen Daten
Jetzt wird es kurz etwas technischer.
MCP steht für Model Context Protocol.
Für diesen Artikel reicht eine einfache Erklärung:
Ein MCP-Server kann einer KI Zugriff auf aktuelle Informationen und kontrollierte Aktionen in externen Systemen geben.
OpenAI trennt hier sehr sauber die Verantwortlichkeiten:
Der Skill beschreibt den Workflow. Ein MCP-Server kann die dafür notwendigen Live-Daten und Werkzeuge bereitstellen.
Quellen: OpenAI Developer Documentation – Skills und OpenAI Developer Documentation – MCP Server
Und das Plugin?
Das Plugin ist unsere Werkzeugkiste.
Ein Plugin für „AI Transformation“ könnte beispielsweise mehrere Skills enthalten: Strategie analysieren, Governance bewerten, Use Cases strukturieren oder ein Management-Briefing erstellen.
Zusätzlich könnten Apps oder andere Werkzeuge Zugriff auf relevante Unternehmensinformationen ermöglichen.
OpenAI beschreibt Plugins entsprechend als kombinierbare Pakete aus Skills, Apps und weiteren Fähigkeiten.
Quelle: OpenAI – Plugins in ChatGPT und Codex
Jetzt wird der Unterschied zum bisherigen GPT langsam sichtbar.
Wir bauen nicht mehr zwangsläufig einen großen Spezialisten, der möglichst alles können soll.
Wir können kleinere, klar definierte Fähigkeiten bauen und miteinander kombinieren.
Was passiert bei der Migration eines Custom GPT zu einem Plugin?
OpenAI beschreibt inzwischen sehr konkret, wie die geplante Migration funktioniert.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
| Custom GPT heute | Nach der Migration |
|---|---|
| Instructions | werden zu einem Skill |
| Knowledge Files | werden zu Referenzdateien |
| verbundene Apps | werden Apps im Plugin |
| ausgewähltes Modell | wird nicht übernommen |
| bestehende GPT-Unterhaltungen | werden nicht übertragen |
| Sharing-Einstellungen | werden nicht automatisch übernommen |
| Custom Actions | werden nicht automatisch migriert |
Das ist ein entscheidender Punkt:
Ein GPT wird nicht einfach umbenannt und heißt anschließend Plugin. Seine Bestandteile werden neu organisiert.
OpenAI weist außerdem ausdrücklich darauf hin, dass sich ein migriertes Plugin anders verhalten kann als der ursprüngliche GPT.
Deshalb empfiehlt OpenAI, typische Aufgaben sowie mindestens einen schwierigeren Anwendungsfall nach der Migration erneut zu testen. Dabei sollte geprüft werden, ob der richtige Skill verwendet wird, die erwarteten Referenzen berücksichtigt werden und die notwendigen Tools weiterhin verfügbar sind.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Warum macht OpenAI das?
Jetzt wird es interessanter.
Denn hier verlassen wir die reine Produktmeldung und kommen zur eigentlichen Bedeutung dieser Veränderung.
OpenAI beschreibt Plugins als eine Möglichkeit, wiederverwendbare Workflows, Wissen und verbundene Werkzeuge zusammenzuführen. Skills wiederum liefern dabei die wiederverwendbaren Anweisungen für konkrete Arbeitsabläufe.
Quellen: OpenAI – Plugins in ChatGPT und Codex und OpenAI Developer Documentation – Skills
Daraus ergibt sich für mich ein grundlegender Architekturwechsel.
Bisher lautete die zentrale Frage häufig:
Welchen KI-Spezialisten baue ich?
Künftig wird die Frage stärker lauten:
Welche KI-Fähigkeiten benötigt mein System?
Das klingt zunächst nach einem kleinen semantischen Unterschied.
Ich halte ihn für wesentlich größer.
Meine These: Von der Assistant Architecture zur Capability Architecture
Nehmen wir einen Projektmanagement-GPT.
Darin könnten heute beispielsweise Funktionen stecken wie Projektstatus erstellen, Risiken analysieren, Managementberichte schreiben, Meetings vorbereiten, Maßnahmen verfolgen oder Stakeholder-Kommunikation vorbereiten.
Bisher hätte man daraus wahrscheinlich einen großen Projektmanagement-GPT gebaut.
Im neuen Modell können daraus mehrere fokussierte Skills entstehen.
OpenAI empfiehlt selbst, Skills auf klar erkennbare Nutzerziele auszurichten und unterschiedliche Workflows zu trennen, wenn sich deren Trigger, Eingaben oder Erfolgskriterien unterscheiden.
Quelle: OpenAI Developer Documentation – Building Skills
Und plötzlich stellt sich eine interessante Frage:
Warum sollte beispielsweise die Fähigkeit „Risiken analysieren“ ausschließlich in einem Projektmanagement-Assistenten stecken?
Vielleicht benötigt dieselbe Fähigkeit auch ein Transformations-Workflow.
Oder Portfolio Management.
Oder ein Management Reporting.
Genau deshalb würde ich den Architekturwechsel so beschreiben:
Custom GPTs organisieren KI primär um einen Spezialisten. Skills und Plugins organisieren KI stärker um Fähigkeiten.
Damit verschiebt sich das Denken von:
„Dieser Assistent kann das.“
zu:
„Diese Fähigkeit steht für diese Aufgabe zur Verfügung.“
Für mich ist das der Übergang von einer Assistant Architecture zu einer Capability Architecture.
Oder noch kürzer:
Custom GPTs haben uns beigebracht, KI zu konfigurieren. Skills und Plugins bringen uns bei, KI-Fähigkeiten zu komponieren.
Gerade für Organisationen halte ich diese Perspektive für wesentlich interessanter als die Frage, ob irgendwo künftig noch ein zusätzlicher Chatbot existiert.
Vielleicht müssen wir künftig gar nicht mehr wissen, welchen Spezialisten wir benötigen
Wer mehrere Custom GPTs verwendet, kennt wahrscheinlich diese Situation:
Welchen nehme ich eigentlich für diese Aufgabe?
Den Research-GPT?
Den Strategie-GPT?
Den Content-GPT?
Oder einfach das normale ChatGPT?
Skills können anders funktionieren.
OpenAI beschreibt, dass ChatGPT einen oder mehrere installierte Skills automatisch verwenden kann, wenn deren Beschreibung zur aktuellen Aufgabe passt. Skills lassen sich gleichzeitig auch gezielt auswählen.
Quelle: OpenAI – Skills in ChatGPT
Das verändert möglicherweise langfristig sogar die Bedienlogik.
Heute:
„Welchen GPT soll ich öffnen?“
Zunehmend:
„Was möchte ich erledigen?“
Das System kann dann beurteilen, welche verfügbaren Fähigkeiten für die Aufgabe hilfreich sind.
Das funktioniert nicht magisch und auch nicht bei jeder Anfrage. OpenAI weist darauf hin, dass automatische Auswahl von Aufgabe und verfügbaren Fähigkeiten abhängt.
Quelle: OpenAI – Skills in ChatGPT
Aber das zugrunde liegende Prinzip verändert sich.
KI wird weniger Persona und mehr Capability.
Und jetzt kommen die Agenten ins Spiel
An dieser Stelle müssen wir allerdings mit einem Missverständnis aufräumen.
Ein Skill ist kein Agent.
Ein Plugin ist ebenfalls kein Agent.
Und auch ein Custom GPT war in vielen Fällen kein wirklicher Agent.
OpenAI definiert Agenten als Systeme, die Aufgaben im Auftrag eines Nutzers mit hoher Eigenständigkeit ausführen. Das Sprachmodell steuert dabei den Workflow, trifft Entscheidungen und kann unterschiedliche Werkzeuge dynamisch einsetzen. Ein einfacher Chatbot oder eine einzelne LLM-Antwort erfüllt diese Definition nicht.
Quelle: OpenAI – A practical guide to building agents
Damit können wir unsere Werkzeugkiste noch einmal erweitern.
Der Skill sagt:
So wird diese Aufgabe erledigt.
Die App oder das Tool sagt:
Damit kannst du Informationen beschaffen oder etwas tun.
Das Plugin sagt:
Diese Fähigkeiten und Werkzeuge gehören zusammen.
Und ein agentisches System kann zunehmend entscheiden:
Welche dieser Fähigkeiten und Werkzeuge benötige ich, um das Ziel zu erreichen?
Genau deshalb halte ich die Umstellung von Custom GPTs auf eine modularere Skill- und Plugin-Architektur für relevanter als eine normale Produktänderung.
Sie schafft bessere Bausteine für agentisches Arbeiten.
Das bedeutet ausdrücklich nicht, dass jetzt jedes Plugin automatisch ein Agent ist.
Aber Skills, Tools und externe Datenzugriffe lassen sich wesentlich sauberer kombinieren – und genau solche Komponenten gehören laut OpenAI zu den Grundlagen agentischer Systeme.
Quelle: OpenAI – A practical guide to building agents
Ein kleines Beispiel
Stellen wir uns vor, eine Führungskraft sagt:
„Bereite mir den aktuellen Status unseres Transformationsprogramms für das Steering Committee vor.“
Ein einfaches ChatGPT könnte zunächst fragen, welche Informationen verwendet werden sollen.
Ein spezialisierter GPT könnte bereits wissen, wie der Bericht aufgebaut sein soll.
Ein stärker agentisch arbeitendes System könnte dagegen – sofern es dafür autorisiert ist und innerhalb definierter Zugriffs-, Datenschutz- und Governance-Regeln arbeitet – die relevanten Projektdaten beschaffen, Risiken und Abweichungen analysieren, bekannte Reporting-Regeln anwenden, fehlende Informationen erkennen, daraus einen Managementbericht erstellen und anschließend den nächsten sinnvollen Schritt vorbereiten.
Dafür benötigt es nicht unbedingt einen riesigen Super-GPT.
Es benötigt passende Fähigkeiten, Informationen und Werkzeuge.
Und genau hier wird die neue Architektur interessant.
Klingt perfekt. Ist es aber noch nicht.
Bei aller Begeisterung für die neue Architektur sollte man die aktuellen Nachteile nicht unterschlagen.
Migration bedeutet nicht identisches Verhalten
OpenAI weist ausdrücklich darauf hin, dass ein migriertes Plugin anders reagieren kann als der ursprüngliche GPT.
Wer geschäftskritische Workflows verwendet, sollte deshalb testen – und zwar nicht nur den Lieblingsprompt, sondern auch schwierige und ungewöhnliche Fälle.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Custom Actions sind der größte technische Stolperstein
Custom Actions werden nicht automatisch migriert.
Wer damit externe Systeme angebunden hat, muss prüfen, ob eine passende App existiert oder ob die Integration neu aufgebaut werden muss. OpenAI nennt einen eigenen MCP-Server ausdrücklich als mögliche technische Lösung.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Für einen einfachen persönlichen GPT ist das möglicherweise kein großes Problem.
Für komplexere Unternehmenslösungen kann daraus aber ein echtes Migrationsprojekt entstehen.
Alte Unterhaltungen ziehen nicht mit um
Bestehende Gespräche mit einem GPT werden nicht in das neue Plugin übertragen. Der ursprüngliche GPT bleibt nach einer Migration bis zu seinem Abschalttermin verfügbar, wird für seinen Ersteller jedoch schreibgeschützt.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Sharing wird nicht einfach übernommen
Auch die bisherige Freigabe eines GPTs wird bei der Migration nicht automatisch übertragen.
Ein migriertes persönliches Plugin startet zunächst privat. Die Veröffentlichung eines Plugins erfolgt über einen separaten Prozess.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Gerade für Menschen, die öffentliche Custom GPTs bereitgestellt haben, ist das keine Kleinigkeit.
Die neue Architektur ist damit technisch interessanter – aber nicht automatisch in jedem bisherigen Anwendungsfall komfortabler.
Was wird tatsächlich besser?
Trotz dieser Einschränkungen sehe ich mehrere strukturelle Vorteile.
Fähigkeiten werden modularer. Statt eines riesigen Instructions-Blocks können fokussierte Arbeitsabläufe entstehen.
Systeme können wartbarer werden. Ändert sich beispielsweise nur der Ablauf einer Risikoanalyse, muss nicht zwangsläufig der komplette Assistent neu konzipiert werden.
Wissen, Workflow und Werkzeuge lassen sich sauberer trennen. Der Skill beschreibt die Arbeitsweise. Referenzmaterial liefert Wissen. Apps oder MCP-Verbindungen können aktuelle Informationen und Aktionen bereitstellen.
Quelle: OpenAI Developer Documentation – Skills
Und vor allem:
KI lässt sich besser mit realen Arbeitsprozessen verbinden.
Der langfristige Nutzen von KI in Organisationen entsteht aus meiner Sicht nicht dadurch, dass Beschäftigte lediglich schneller Texte schreiben.
Interessant wird KI dort, wo sie Bestandteil eines End-to-End-Arbeitsablaufs wird:
Informationen beschaffen, bewerten, Entscheidungen vorbereiten, Aktionen durchführen und Ergebnisse in den nächsten Prozessschritt übergeben.
Dafür braucht man mehr als einen guten Prompt.
Was ich bei meiner eigenen Migration gerade lerne
Ich habe inzwischen die Custom GPTs beziehungsweise spezialisierten Agenten migriert, die für mich aktuell tatsächlich einen Wert liefern.
Schon allein diese Bereinigung war interessant.
Denn plötzlich stellt sich nicht mehr nur die Frage:
„Welchen meiner GPTs möchte ich behalten?“
Sondern:
„Welche Fähigkeiten darin sind eigentlich wirklich wertvoll?“
Und genau dort wird der Architekturwechsel praktisch sichtbar.
Ein bisheriger Spezialist besteht bei genauerer Betrachtung häufig aus mehreren Dingen: einer Rolle, wiederverwendbaren Arbeitsanweisungen, spezifischem Wissen und möglicherweise Zugriff auf weitere Systeme.
Wenn man diese Bestandteile auseinanderzieht, wird deutlich, dass nicht zwangsläufig die künstliche Persona der wertvollste Teil war.
Oft ist es der wiederverwendbare Workflow dahinter.
Für mich ist das momentan einer der interessantesten Effekte dieser Migration:
Man beginnt weniger darüber nachzudenken, welche KI-Person man bauen möchte – und stärker darüber, welche Fähigkeit man eigentlich benötigt.
Wie gut sich das in der täglichen Nutzung langfristig bewährt, muss sich allerdings noch zeigen.
Gerade deshalb halte ich Tests nach der Migration für so wichtig.
Was sollte ich jetzt tun?
Wer eigene Custom GPTs gebaut hat, muss deshalb nicht morgen alles umbauen.
Ignorieren würde ich das Thema aber ebenfalls nicht.
Ich würde derzeit in sieben Schritten vorgehen:
- Inventur machen: Welche eigenen GPTs existieren und welche davon werden tatsächlich genutzt?
- Wert prüfen: Nicht jeder experimentelle GPT muss migriert werden.
- Instructions und Wissensdateien prüfen: Was wird wirklich benötigt und was ist inzwischen veraltet?
- Custom Actions identifizieren: Hier kann zusätzlicher technischer Aufwand entstehen.
- Testfälle sichern: Einige typische Prompts und mindestens einen schwierigen Fall speichern.
- Migrieren und vergleichen: Prüfen, ob Skill-Auswahl, Referenzmaterial, Ausgabeformat und benötigte Werkzeuge weiterhin funktionieren.
- Sharing und Zugriff kontrollieren: Bestehende Nutzer erhalten nicht automatisch Zugriff auf das neue Plugin.
OpenAI weist außerdem darauf hin, dass bei der Migration die zuletzt veröffentlichte Version eines GPTs verwendet wird. Entwürfe und unveröffentlichte Änderungen werden nicht übernommen.
Quelle: OpenAI – Custom GPT retirement and migration FAQ
Wer wichtige GPTs besitzt, sollte deshalb nicht erst am 10. Dezember damit anfangen.
Die eigentliche Veränderung beginnt erst danach
Vielleicht ist der 11. Dezember 2026 am Ende gar nicht das Interessanteste an dieser Geschichte.
Custom GPTs haben vielen von uns beigebracht, KI zu konfigurieren.
Wir haben Rollen definiert.
Prompts geschrieben.
Dokumente hinterlegt.
Spezialisten gebaut.
Skills und Plugins führen dieses Prinzip einen Schritt weiter.
Sie zwingen uns stärker darüber nachzudenken:
Welche Fähigkeit braucht meine KI eigentlich?
Welche Informationen benötigt sie dafür?
Welche Werkzeuge darf sie verwenden?
Und welche Aufgaben darf sie zunehmend selbstständig erledigen?
Vielleicht verändert sich dadurch auch unsere Sprache im Umgang mit KI.
Gestern:
„Welchen GPT soll ich dafür nehmen?“
Heute:
„Welchen Skill brauche ich dafür?“
Und morgen vielleicht nur noch:
„Erledige das.“
Die KI entscheidet dann innerhalb definierter Regeln, Berechtigungen und Sicherheitsvorgaben – und wo erforderlich mit menschlicher Freigabe –, welche Fähigkeiten, Informationen und Werkzeuge sie benötigt, um das Ziel zu erreichen.
Das wäre tatsächlich Agentic AI.
Und vielleicht ist genau deshalb das Ende der Custom GPTs weniger das Ende einer Produktfunktion.
Vielleicht ist es der Anfang einer wesentlich interessanteren Phase:
Wir bauen weniger künstliche Persönlichkeiten.
Und dafür mehr echte KI-Fähigkeiten.
Quellen und weiterführende Informationen
- OpenAI – Custom GPT retirement and migration FAQ
- OpenAI – Skills in ChatGPT
- OpenAI – Plugins in ChatGPT und Codex
- OpenAI – Apps in ChatGPT
- OpenAI Developer Documentation – Skills
- OpenAI Developer Documentation – MCP Server
- OpenAI Developer Documentation – Building Skills
- OpenAI – A practical guide to building agents
