ChatGPT · Teilen, Governance und Custom GPTs im Arbeitsalltag

Ein Custom GPT hat nur wenige Sichtbarkeitsoptionen: privat für Sie, geteilt mit bestimmten Personen oder per Link, oder in einem Store veröffentlicht (dem öffentlichen GPT Store oder dem internen Store Ihres Workspace). Mit der falschen Option indexiert ein Sales-Enablement-GPT plötzlich Ihre noch nicht veröffentlichten Preise, oder ein „schneller interner Helfer“ wird zur Support-Last, für die sich niemand zuständig fühlt. In dieser Lektion geht es darum, diese Entscheidungen richtig zu treffen, bevor ein Team von dem GPT abhängt.

Die Sichtbarkeitsoptionen im Detail

Wenn Sie ein GPT im Editor erstellen, bietet Ihnen der Dialog Share Folgendes:

• Only me (privat): die Standardeinstellung. Das GPT existiert nur in Ihrem Account.
• Specific people or groups: verfügbar in einem Business- oder Enterprise-Workspace. Sie legen fest, wer es nutzen darf (und, sofern erlaubt, wer es bearbeiten darf).
• Anyone with the link: nutzbar für jeden, der die URL hat. In einem persönlichen Plan kann das öffentlich sein. In einem Business- oder Enterprise-Workspace bedeutet „Link“ einen Link *innerhalb des Workspace*, sofern Ihr Admin externes Teilen nicht erlaubt.
• GPT Store: veröffentlicht und auffindbar. Bei Business/Enterprise kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen Sie statt im öffentlichen Store im internen Store Ihres Workspace veröffentlichen.

Die Unterscheidung, an der viele scheitern: Innerhalb eines Workspace ist das Teilen durch den Workspace begrenzt. Ein per Link geteiltes GPT ist für Kollegen erreichbar, nicht für das offene Internet, wenn Ihr Admin externes Teilen gesperrt hat. Prüfen Sie diese Annahme, bevor Sie „nur Link“ als „nur intern“ behandeln. Siehe die Übersicht von OpenAI zu Custom GPTs in Business und Enterprise.

(ChatGPT Team wurde 2025 in ChatGPT Business umbenannt. Ältere Dokumentationen und Admin-Screenshots zeigen eventuell noch „Team“.)

Was beim Teilen tatsächlich weitergegeben wird

Hier machen die meisten Builder Fehler. Wenn Sie ein GPT teilen, teilen Sie seine Konfiguration: die Instruktionen, die Conversation Starters, die aktivierten Fähigkeiten (Websuche, Code Interpreter, Bildgenerierung), alle Actions (APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen →-Aufrufe, die es ausführen kann) und alle Dateien, die Sie in seine Knowledge hochgeladen haben.

Diese Knowledge-Dateien sind relevant. Wenn Sie eine Tabelle mit internen Margen hochgeladen haben, damit das GPT damit arbeiten kann, kann jeder Nutzer dieses GPT diesen Inhalt extrahieren. Ein hartnäckiger Nutzer kann das GPT auffordern, seine Instruktionen auszugeben oder seine Knowledge-Dateien wörtlich wiederzugeben, und oft tut es das auch. Behandeln Sie alles in der Konfiguration eines GPT als lesbar für jeden, der es nutzen kann.

Ein konkretes Rollout-Szenario

Machen wir es konkret. Ihr RevOps-Team möchte ein GPT namens „Deal Desk Assistant“, das Account Executives beim Entwurf von Angebotsfreigaben unterstützt. Es soll:

1. Fragen anhand einer internen Rabattrichtlinie (ein PDF) beantworten.
2. Live-Deal-Daten aus Ihrem CRMCRMCustomer Relationship Management: Software und Strategie, um Kundeninteraktionen über den gesamten Lifecycle zu steuern und zu analysieren.Vollständige Definition ansehen → abrufen.
3. Einen strukturierten Freigabeantrag entwerfen.

So spielen Teilen, Governance und Datensicherheit bei diesem Build zusammen.

Schritt 1: Die Zielgruppe zuerst festlegen, nicht zuletzt

Die Zielgruppe sind „AEs in unserem Workspace“, nicht die Öffentlichkeit. Es handelt sich also um ein im Workspace veröffentlichtes GPT (oder eines, das mit einer AE-Gruppe geteilt wird), das dem RevOps-Admin-Account gehört und nicht einer einzelnen Person, die das Unternehmen verlassen könnte. Ownership ist Governance: Ein GPT, das einem ausgeschiedenen Mitarbeiter gehört, kann niemand mehr aktualisieren.

In Enterprise kann ein Admin festlegen, wer überhaupt GPTs *erstellen* und *veröffentlichen* darf, und prüfen, was im internen Store veröffentlicht wird. Wenn Sie der Builder sind, klären Sie die Richtlinie Ihres Workspace, bevor Sie eine Woche in etwas investieren, das die IT blockieren wird.

Schritt 2: Die Rabattrichtlinie (Knowledge, nicht Einfügen)

Sie hängen das Richtlinien-PDF als Knowledge an. Sofort stellen sich zwei Sicherheitsfragen:

• Darf jeder AE dieses PDF vollständig lesen? Wenn es Schwellenwerte enthält, die nur für die Geschäftsleitung bestimmt sind, teilen Sie das Dokument auf. Nehmen Sie nur die für AEs relevanten Regeln in das GPT auf.
• Wird das GPT die Datei preisgeben? Fügen Sie eine Instruktion hinzu, die wörtliche Ausgaben unterbindet, verlassen Sie sich aber nicht darauf als Kontrolle. Die eigentliche Kontrolle besteht darin, *nichts hochzuladen, was die Zielgruppe nicht haben sollte.*

Schritt 3: Live-CRM-Daten (das ist eine Action)

Ein statisches PDF ist einfach. Bei Live-Daten wird Governance ernst. Um Deal-Datensätze abzurufen, braucht das GPT eine GPT Action: ein OpenAPI-SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →, das einen Endpunkt beschreibt, den das GPT aufrufen kann, plus eine Authentifizierungsmethode.

Hier ein minimales Action-Schema für einen Read-only-Deal-Lookup:

openapi: 3.1.0
info:
  title: Deal Lookup
  version: "1.0.0"
servers:
  - url: https://api.internal.example.com
paths:
  /deals/{dealId}:
    get:
      operationId: getDeal
      summary: Fetch a single deal by ID
      parameters:
        - name: dealId
          in: path
          required: true
          schema: { type: string }
      responses:
        "200":
          description: Deal record
          content:
            application/json:
              schema:
                type: object
                properties:
                  id: { type: string }
                  amount: { type: number }
                  stage: { type: string }
                  discountPct: { type: number }

Drei Governance-Regeln für Actions sind wichtiger als das Schema:

• Sauber authentifizieren. GPT Actions unterstützen API-Keys und OAuth. Für nutzerbezogenen Zugriff (damit das GPT nur die Deals sieht, die ein bestimmter AE sehen darf) verwenden Sie OAuth, sodass die Anfrage als angemeldeter Nutzer läuft und nicht über einen gemeinsamen Service-Key. Ein gemeinsamer Key bedeutet, dass jeder AE mit denselben Berechtigungen abfragt, was meist zu viele Rechte vergibt.
• Den Endpunkt auf Read-only beschränken. Dieses GPT sollte nie einen Endpunkt aufrufen, der einen Deal *verändert*. Stellen Sie GET bereit, nicht POST/DELETE. Je kleiner die API-Oberfläche, desto kleiner der Blast Radius.
• Auf Datenabfluss achten. Wenn das GPT Ihre Action aufruft, sendet es Anfragedaten an die Server von OpenAI, um die Antwort zu generieren. Prüfen Sie, ob dieser Datenfluss mit Ihrer Datenrichtlinie vereinbar ist. Geschäftsdaten aus dem Workspace werden bei Business/Enterprise standardmäßig nicht zum Training der Modelle von OpenAI verwendet, aber „wird nicht zum Training verwendet“ ist etwas anderes als „verlässt nie Ihr Netzwerk“. Die Daten verlassen Ihr Netzwerk. Lesen Sie die Enterprise-Datenschutzzusagen.

Schritt 4: Der strukturierte Entwurf (Fähigkeiten)

Die Aufgabe „Freigabeantrag entwerfen“ profitiert von einer einheitlichen Form. Legen Sie in den Instruktionen des GPT die genaue Ausgabevorlage fest. Die per JSON-Schema erzwungenen Structured Outputs der API haben Sie in einem Custom GPT nicht (das ist eine API-Funktion), aber eine gut formulierte Instruktion plus ein Conversation Starter liefern verlässliche Formatierung für Entwürfe, die Menschen lesen.

Wenn das Team später *garantiert* maschinenlesbare Ausgaben braucht (zum Beispiel, um Freigaben automatisch abzulegen), ist das das Signal, vom Custom GPT auf eine API-Integration mit der Responses API und Structured Outputs umzusteigen. Mehr zu dieser Grenze weiter unten.

Governance-Fragen, die vor dem Launch geklärt sein müssen

Gehen Sie diese Checkliste mit der Person durch, die für das Risiko verantwortlich ist. Bei einem GPT, auf das sich ein Team verlässt, ist keiner dieser Punkte optional.

Datenklassifizierung. Welche sind die sensibelsten Daten, auf die dieses GPT zugreifen kann, über Knowledge-Dateien *und* über Actions? Klassifizieren Sie auf dieser Stufe und wenden Sie Ihre bestehenden Regeln zum Umgang damit an. Das GPT bekommt keine Sonderausnahme.

Identität und Zugriff. Wer darf es nutzen? In Business und Enterprise lässt sich der Zugriff auf GPTs auf Personen oder Gruppen beschränken, und SSO regelt, wer überhaupt im Workspace ist. Prüfen Sie, ob Offboarding (jemand verlässt das Unternehmen) den Zugriff tatsächlich entfernt. Das tut es, wenn der Zugriff über den Workspace läuft, aber prüfen Sie es bei per Link geteilten GPTs.

Auditierbarkeit. Enterprise-Workspaces bieten Admin-Kontrollen, Einblick in die Nutzung und die Compliance API zum Abrufen von Konversations- und Audit-Daten. Wenn Sie beantworten müssen, „wer den Deal Desk Assistant zu Deal X befragt hat“, muss das *vor* dem Launch eingerichtet sein, nicht erst nach einem Vorfall. Siehe Enterprise-Compliance- und Admin-Funktionen.

Memory und Projects. Achten Sie darauf, wo Zustände gespeichert werden. Memory und Custom Instructions sind persönlicher Kontext pro Nutzer und nicht Teil der geteilten Konfiguration des GPT, sie fließen also nicht zwischen Nutzern ab. Wenn Ihr Team aber in einem gemeinsamen Project arbeitet, werden Dateien und Instruktionen in diesem Project mit den Project-Mitgliedern geteilt. Verwechseln Sie ein Project (einen gemeinsamen Arbeitsbereich für Chats und Dateien) nicht mit einem Custom GPT (einem konfigurierten Assistenten). Beide haben unterschiedliche Sharing-Modelle.

Die Grenze bei Halluzinationen. Ein Deal Desk Assistant, der beim Thema Rabattrichtlinie kompetent *klingt*, kann selbstbewusst einen Schwellenwert erfinden. Legen Sie fest, wofür ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → die mamaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßgebliche Quelle sein darf. Bewährt hat sich: Weisen Sie ihn an, den Abschnitt der Richtlinie zu zitieren und abzulehnen statt zu raten, wenn die Richtlinie nichts dazu sagt.

Wann ein Custom GPT das falsche Werkzeug ist

Custom GPTs eignen sich hervorragend für dialogbasierte Workflows mit Human in the Loop innerhalb von ChatGPT. Sie sind das falsche Werkzeug, wenn:

• Sie es in ein anderes Produkt einbetten müssen. GPTs leben in ChatGPT. Um Assistenzfunktionen in Ihre eigene App zu bringen, bauen Sie auf der API auf.
• Sie garantiert strukturierte Ausgaben oder programmatische Kontrolle brauchen. Nutzen Sie die Responses API mit Structured Outputs und Function Calling.
• Sie mehrstufige Autonomie über verschiedene Tools und Ihre eigene Orchestrierung brauchen. Das ist Terrain für das Agents SDK oder für ChatGPT agent bei autonomen Aufgaben innerhalb des Produkts.

Der Migrationspfad für unser Szenario: Wenn RevOps später Freigaben automatisch ablegen möchte, wird dasselbe OpenAPI-Tool zu einer Function bzw. einem Tool, das das Modell programmatisch aufruft. So sieht das in der Responses API aus:

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5",
    input="Draft an approval for deal D-8842 and flag if discount exceeds policy.",
    tools=[{
        "type": "function",
        "name": "getDeal",
        "description": "Fetch a single deal by ID",
        "parameters": {
            "type": "object",
            "properties": {"dealId": {"type": "string"}},
            "required": ["dealId"],
        },
    }],
)

print(response.output_text)

Dieselbe Geschäftslogik, aber jetzt steuert *Ihr* Code die Authentifizierung, führt den eigentlichen getDeal-Aufruf aus und kann Richtlinien im Code durchsetzen, statt darauf zu hoffen, dass der Prompt hält. Die Responses-API-Dokumentation beschreibt den kompletten Tool-Calling-Loop.

Die Faustregel: Ein Custom GPT ist eine geteilte Konfiguration, keine kontrollierte Anwendung. Sobald Sie echte Zugriffskontrolle, Audit-Garantien oder deterministisches Verhalten brauchen, sind Sie im Terrain der API.

Key Takeaways

• Wählen Sie die Sichtbarkeitsoption bewusst, und denken Sie daran, dass alles in der Konfiguration für jeden Nutzer lesbar ist. Laden Sie nie Knowledge-Dateien hoch und hinterlegen Sie nie Secrets im Code, die die Zielgruppe nicht vollständig sehen sollte.
• GPTs gehören auf Workspace- oder Admin-Ebene, nicht in einen persönlichen Account. Eine Team-Abhängigkeit, die einem einzelnen Mitarbeiter gehört, stirbt, wenn diese Person geht.
• Nutzen Sie OAuth für Actions, die auf nutzerbezogene Daten zugreifen, und halten Sie Endpunkte Read-only, sofern Änderungen nicht wirklich erforderlich sind. Verkleinern Sie die API-Oberfläche, um den Blast Radius zu reduzieren.
• Arbeiten Sie vor dem Launch eine Checkliste ab: Datenklassifizierung, Identität/Offboarding, Audit/Compliance API und eine klare Grenze für die „maßgebliche Quelle“, um selbstbewusste Halluzinationen einzudämmen.
• Erkennen Sie, wann der Umstieg auf die API fällig ist. Wenn Sie garantierte Struktur, die Einbettung in Ihr eigenes Produkt oder durchgesetzte Zugriffskontrolle brauchen, wechseln Sie vom Custom GPT zur Responses API oder zum Agents SDK.