CustomGPT, Claude Project oder Gem: wo du deinen Assistenten baust
Die Plattform ist die kleinste der Entscheidungen, die du beim Bauen eines Assistenten triffst. Wichtiger sind vier Fragen: Wer nutzt ihn, wo dürfen die Daten liegen, wie oft ändert sich das hinterlegte Wissen, und ist die Aufgabe für das Modell überhaupt lösbar.
Trotzdem ist „welches Tool?” fast immer die erste Frage im Raum. Ich verstehe warum. Eine Tool-Entscheidung fühlt sich nach Fortschritt an und lässt sich in zehn Minuten treffen. Nur trifft sie in der Praxis kaum darüber, ob dein Assistent hinterher benutzt wird.
Dieser Artikel gehört zum Guide zum Bauen eigener KI-Assistenten mit Firmenwissen. Er liefert bewusst keine Feature-Tabelle und keine Preise. Feature-Listen sind bei diesen Produkten nach wenigen Wochen falsch, und Preise ändern sich noch schneller. Was bleibt, ist die Entscheidungslogik.
Worum es überhaupt geht
Alle drei Bauformen machen im Kern dasselbe. Du hinterlegst eine dauerhafte Anweisung, legst optional Dokumente dazu und bekommst einen wiederverwendbaren Einstiegspunkt, statt bei jedem Chat neu anzufangen.
- CustomGPT ist die Bauform im ChatGPT-Ökosystem von OpenAI.
- Claude Project ist die Bauform bei Anthropic.
- Gem ist die Bauform bei Google im Gemini-Umfeld.
Wie verbreitet dieses Muster ist, zeigt ein Blick auf den Start des GPT Store. OpenAI hat den Store am 10. Januar 2024 eröffnet und dabei angegeben, dass in den rund zwei Monaten seit Einführung der GPTs bereits über drei Millionen eigene Versionen von ChatGPT gebaut worden waren. Die Zahl sagt nichts über Qualität aus. Sie sagt etwas über die Einstiegshürde: Bauen kann praktisch jeder, und das ist genau der Grund, warum so viele dieser Assistenten nie einen Alltag finden. Warum das passiert und was dagegen hilft, habe ich in Vom Test-Assistenten zum Alltags-Assistenten auseinandergenommen.
Achse 1: Wer nutzt ihn?
Die erste und in meiner Erfahrung wichtigste Frage.
Nur du. Dann nimm das Tool, in dem du sowieso arbeitest, und hör auf zu vergleichen. Ein Assistent in deinem Zweit-Tool wird seltener geöffnet als einer in deinem Erst-Tool, unabhängig davon, welches technisch das bessere ist.
Dein Team. Jetzt wird es interessant. Prüfe drei Dinge, bevor du dich festlegst: Haben alle, die ihn nutzen sollen, dort überhaupt einen Zugang? Können sie ihn nutzen, ohne ihn versehentlich zu verändern? Und was passiert mit dem Assistenten, wenn die Person, die ihn gebaut hat, das Unternehmen verlässt? Die Antworten unterscheiden sich zwischen den Ökosystemen deutlich, und sie sind wichtiger als jede Feature-Frage. Der Artikel KI-Assistenten im Team teilen geht auf Rollen und Rechte im Detail ein.
Kunden oder Öffentlichkeit. Hier verlässt du den Bereich, für den diese Bauformen gedacht sind. Ein öffentlich geteilter Assistent gibt hinterlegtes Wissen an Leute weiter, die du nicht kennst. Wenn du das wirklich willst, brauchst du eine andere Architektur und eine Prüfung, was in der Wissensbasis nichts zu suchen hat.
Die Ehrlichkeit an dieser Stelle spart viel Zeit. Ein Assistent, der intern brillant ist, wird nach außen zum Risiko, sobald er Preisspannen, Argumentationslinien oder interne Bewertungen kennt. Frag also zuerst, für welchen Kreis du baust, und danach erst, womit.
Achse 2: Wo dürfen die Daten liegen?
Das ist keine Geschmacksfrage. Sobald in deiner Wissensbasis Kundendaten, Personaldaten oder vertragliche Geheimhaltungspflichten stecken, entscheidet diese Achse mit über die Zulässigkeit.
Drei Dinge, die du pro Anbieter prüfen solltest, bevor du echtes Firmenwissen hochlädst:
- Gibt es einen Vertrag zur Auftragsverarbeitung, und gilt er für deinen konkreten Tarif? Consumer-Tarif und Business-Tarif unterscheiden sich hier bei allen drei Anbietern.
- Werden deine Inhalte zum Training verwendet, und lässt sich das abschalten? Die Antwort hängt ebenfalls am Tarif, nicht am Produkt.
- Wohin fließen die Daten geografisch? Für den Drittlandtransfer gibt es einen Rahmen, aber der gilt nicht pauschal für jeden Anbieter.
Ich gehe darauf in DSGVO und Firmenwissen: was in einen KI-Assistenten darf im Einzelnen ein, inklusive der Frage, welche Dokumente du besser gar nicht erst hochlädst. Für die Tool-Wahl reicht die Merkregel: Prüfe den Tarif, nicht die Marke.
Achse 3: Wie oft ändert sich das Wissen?
Diese Achse wird fast immer übersehen und rächt sich am zuverlässigsten.
Wissen, das stabil ist. Methodenbeschreibungen, Tonalitätsvorgaben, Struktur eurer Angebote, Positionierung. Solche Dokumente kannst du hochladen und ein Jahr lang in Ruhe lassen. Für diesen Fall ist jede der drei Bauformen brauchbar.
Wissen, das quartalsweise wackelt. Preislisten, Produktdetails, Ansprechpartner, Prozessbeschreibungen. Hier brauchst du einen Menschen, der eine Erinnerung im Kalender hat, und eine Wissensbasis, die sich in fünf Minuten austauschen lässt. Wenn das Aktualisieren in deinem Wunsch-Tool umständlich ist, wird es nicht gemacht.
Wissen, das täglich lebt. Bestände, Tickets, laufende Projekte. Dafür sind hochgeladene Dokumente das falsche Werkzeug, egal in welchem Ökosystem. Du brauchst eine Anbindung an das System, in dem die Daten sowieso stehen, oder du akzeptierst, dass der Assistent für diese Aufgabe nicht taugt. Der Reflex, es trotzdem mit einem Dokumenten-Upload zu versuchen, ist einer der häufigsten Fehler beim ersten KI-Assistenten.
Ein zweiter Punkt zur Wissensmenge, weil er oft zu Enttäuschungen führt: Mehr Dokumente sind nicht automatisch besser. Nelson F. Liu und Kolleginnen und Kollegen haben in „Lost in the Middle: How Language Models Use Long Contexts” gezeigt, dass Sprachmodelle relevante Informationen am zuverlässigsten finden, wenn sie am Anfang oder am Ende des Kontexts stehen, und dass die Trefferquote deutlich sinkt, wenn die entscheidende Stelle in der Mitte eines langen Kontexts liegt. Die Arbeit erschien 2023 als Preprint und 2024 in den Transactions of the Association for Computational Linguistics. Für dich heißt das: Eine kuratierte, kurze Wissensbasis schlägt den Ordner mit allem. Wie du auswählst, steht in Welche Dokumente in die Wissensbasis gehören.
Achse 4: Kann das Modell die Aufgabe?
Erst hier wird es zur Modellfrage, und auch hier ist die praktische Antwort unspektakulär.
Teste deine drei schwierigsten realen Fälle in allen drei Umgebungen, bevor du dich festlegst. Nicht das Demo-Beispiel, sondern die Anfrage, bei der du selbst zweimal lesen musst. Der Vergleich dauert eine Stunde und ist aussagekräftiger als jeder Benchmark, den du online findest, weil er deine Dokumente, deine Sprache und deine Sonderfälle benutzt.
Worauf ich dabei achte:
- Hält sich das Modell an die Constraints, auch wenn der Input schludrig ist?
- Erfindet es plausibel klingende Details, die nicht in den Dokumenten stehen?
- Sagt es „steht nicht in meinen Unterlagen”, oder rät es lieber?
- Wie sieht das Ergebnis aus, wenn zwei hinterlegte Dokumente sich widersprechen?
Der letzte Punkt ist mein liebster Test. Ein Assistent, der einen Widerspruch benennt statt ihn zu glätten, spart dir später echte Fehler. Wie du solche Prüfungen systematisch anlegst, statt nach Gefühl zu urteilen, steht in KI-Assistent testen: Qualität prüfen.
Zur Modellwahl noch eine Beobachtung, die dir Vergleichsarbeit spart: Die Unterschiede zwischen den Spitzenmodellen sind bei typischen Büroaufgaben inzwischen kleiner als die Unterschiede zwischen einer schlampigen und einer sauberen Anweisung. Wer dieselbe halbherzige Beschreibung in drei Tools kippt, bekommt dreimal ein mittelmäßiges Ergebnis und hält das dann für einen Modellvergleich. Der Test ist erst dann aussagekräftig, wenn die Anweisung in allen drei Umgebungen identisch und ordentlich ist.
Die ehrlichen Trade-offs
Damit das hier keine Anleitung zur Bequemlichkeit wird, die vier Abwägungen, um die niemand herumkommt:
Bequemlichkeit gegen Unabhängigkeit. Der Assistent im Haus-Ökosystem ist am schnellsten gebaut und am schwersten umzuziehen. Deine Anweisungen und deine kuratierten Dokumente solltest du deshalb außerhalb des Tools versioniert liegen haben. Dann ist ein Wechsel eine Kopieraufgabe und kein Neubau.
Ein Tool für alle gegen das jeweils beste Tool. Mehrere Ökosysteme parallel bedeuten mehr Verträge, mehr Datenschutzprüfungen, mehr Erklärungsbedarf und mehr Stellen, an denen Firmenwissen liegt. Für Teams unter 20 Personen halte ich Konsolidierung fast immer für die bessere Wahl, auch wenn ein anderes Modell bei einer einzelnen Aufgabe besser abschneidet.
Alles im Chat gegen alles im Prozess. Diese Bauformen leben im Chatfenster. Das macht sie schnell zugänglich und schlecht automatisierbar. Sobald eine Aufgabe hundertmal am Tag anfällt oder an ein anderes System andocken soll, bist du im Bereich Schnittstellen und Automatisierung, und dann ist keine der drei Bauformen die richtige Antwort. Für Teams unter 20 Personen ist das seltener der Fall, als Anbieter suggerieren, aber es kommt vor. Erkennungsmerkmal: Wenn niemand die Ergebnisse mehr liest, gehört die Aufgabe nicht in einen Chat-Assistenten.
Früh festlegen gegen lange vergleichen. Der Vergleich hat einen abnehmenden Ertrag. Wenn du nach einem halben Tag keine Entscheidung hast, entscheidet dich das Tool, in dem dein Team ohnehin arbeitet, und du steckst die gesparte Zeit in Constraints. Die machen erfahrungsgemäß den größeren Unterschied, siehe Constraints schreiben für den KI-Assistenten.
Wenn du dich immer noch nicht entscheiden kannst
Dann fehlt dir wahrscheinlich der Use Case und nicht die Tool-Info. Welche Aufgabe genau soll der Assistent übernehmen, wie oft kommt sie vor, und wer macht sie heute?
Wer diese drei Antworten hat, findet die Plattform in zehn Minuten. Wer sie nicht hat, vergleicht Tools als Ersatzhandlung. Falls das bei euch der Fall ist, lohnt sich der Schritt zurück: Der KI-Readiness-Check sortiert, wo ihr steht und welche Aufgaben sich als Erstes lohnen, bevor Budget in Lizenzen wandert.
Quellen
- Introducing the GPT Store – OpenAI, Januar 2024
- OpenAI Launches GPT Store – Forbes, 10.01.2024
- OpenAI's GPT Store is now live with over 3 million custom chatbots to try – Tom's Guide, 2024
- GPT Store – Wikipedia (Überblicksartikel mit Belegen)
- Lost in the Middle: How Language Models Use Long Contexts – Liu et al., Transactions of the ACL 12, 2024
- Lost in the Middle: How Language Models Use Long Contexts – MIT Press, TACL, 2024
- Lost in the Middle: How Language Models Use Long Contexts (Preprint) – arXiv:2307.03172, 2023
- Code und Daten zu Lost in the Middle – GitHub, Nelson F. Liu