+150 XP

Sharing, Governance und Custom GPTs im Arbeitsalltag

# Sharing, Governance und Custom GPTs im Arbeitsalltag

Ein Custom GPT kann genau drei Zustände haben: privat für Sie, per Link geteilt mit allen, die die URL haben, oder im GPT Store veröffentlicht. Den falschen Zustand zu wählen, ist der Grund, warum ein Sales-Enablement-GPT plötzlich Ihre noch nicht veröffentlichten Preise indexiert oder ein „schneller interner Helfer" zur Support-Last wird, für die niemand zuständig ist. In dieser Lektion geht es darum, diese Entscheidungen richtig zu treffen, bevor ein Team von der Sache abhängt.

Die drei Sichtbarkeitszustände, genau betrachtet

Wenn Sie ein GPT im Editor bauen, bietet der Share-Dialog:

  • Only me (privat): die Standardeinstellung. Das GPT existiert nur in Ihrem Account.
  • Anyone with the link: nutzbar von allen, die die URL haben. In einem persönlichen Plan kann das öffentlich sein. In einem Team- oder Enterprise-Workspace bedeutet „Link" Link *innerhalb des Workspace*, sofern Ihr Admin externes Teilen nicht erlaubt.
  • GPT Store: veröffentlicht und auffindbar. In Team/Enterprise können Sie stattdessen im internen Store Ihres Workspace veröffentlichen.

Der Unterschied, über den viele stolpern: 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 Team and Enterprise.

Was beim Teilen tatsächlich mitgeht

Das ist der Teil, den die meisten Builder falsch machen. Wenn Sie ein GPT teilen, teilen Sie seine Konfiguration: die Instructions, die Conversation Starters, die aktivierten Capabilities (Websuche, Code Interpreter, Bildgenerierung), alle Actions (API-Aufrufe, die es machen kann) und alle Dateien, die Sie in sein Knowledge hochgeladen haben.

Diese Knowledge-Dateien sind wichtig. Wenn Sie eine Tabelle mit internen Margen hochgeladen haben, damit das GPT darüber schlussfolgern kann, dann kann jeder Nutzer dieses GPT diesen Inhalt extrahieren. Ein entschlossener Nutzer kann das GPT bitten, seine Instructions auszugeben oder seine Knowledge-Dateien wörtlich auszuwerfen, und häufig tut es das. Behandeln Sie alles in der Konfiguration eines GPT als lesbar für jeden, der es nutzen kann.

Ein konkretes Rollout-Szenario

Machen wir es greifbar. Ihr RevOps-Team will einen „Deal Desk Assistant" als GPT, der Account Executives beim Entwurf von Quote-Freigaben hilft. Er soll:

1. Fragen zu einer internen Discounting-Policy (ein PDF) beantworten.

2. Live-Deal-Daten aus Ihrem CRM abrufen.

3. Einen strukturierten Freigabeantrag entwerfen.

So spielen die drei Themen (Sharing, Governance, Daten/Sicherheit) bei diesem Aufbau zusammen.

Schritt 1: Zielgruppe zuerst festlegen, nicht zuletzt

Die Zielgruppe sind „AEs in unserem Workspace", nicht die Öffentlichkeit. Also ist das ein im Workspace veröffentlichtes GPT, im Besitz des RevOps-Admin-Accounts, nicht einer Einzelperson, die das Unternehmen verlassen könnte. Ownership ist Governance: Ein GPT im Besitz eines ausgeschiedenen Mitarbeiters ist ein GPT, das niemand aktualisieren kann.

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

Schritt 2: Die Discounting-Policy (Knowledge, nicht Copy-Paste)

Sie hängen das Policy-PDF als Knowledge an. Sofort zwei Sicherheitsfragen:

  • Darf jeder AE dieses PDF vollständig lesen? Wenn es Schwellenwerte nur für die Geschäftsführung enthält, teilen Sie das Dokument auf. Nehmen Sie nur die AE-relevanten Regeln ins GPT.
  • Wird das GPT die Datei leaken? Fügen Sie eine Instruction hinzu, die wörtliche Ausgaben unterbindet, aber verlassen Sie sich nicht darauf als Kontrolle. Die echte Kontrolle ist, *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 zu ziehen, braucht das GPT eine GPT Action: ein OpenAPI-Schema, das einen Endpoint beschreibt, den das GPT aufrufen kann, plus eine Authentifizierungsmethode.

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

yaml
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, die wichtiger sind als das Schema:

  • Richtig authentifizieren. GPT Actions unterstützen API-Keys und OAuth. Für nutzerbezogenen Zugriff (damit das GPT nur Deals sieht, die ein bestimmter AE sehen darf) nutzen Sie OAuth, sodass der Request als der eingeloggte Nutzer läuft und nicht mit einem gemeinsamen Service-Key. Ein gemeinsamer Key bedeutet, dass jeder AE mit denselben Berechtigungen abfragt, was meist zu viel gewährt.
  • Endpoint auf Read-only beschränken. Dieses GPT sollte niemals einen Endpoint aufrufen, der einen Deal *verändert*. Exponieren Sie GET, nicht POST/DELETE. Je enger die API-Oberfläche, desto kleiner der Blast Radius.
  • Achten Sie auf Data Egress. Wenn das GPT Ihre Action aufruft, sendet es Request-Daten an OpenAIs Server, um die Antwort zu generieren. Bestätigen Sie, dass dieser Fluss nach Ihrer Datenrichtlinie zulässig ist. Geschäftsdaten aus dem Workspace werden bei Team/Enterprise standardmäßig nicht zum Training von OpenAI-Modellen genutzt, aber „nicht zum Training genutzt" ist etwas anderes als „verlässt Ihr Netzwerk nie". Es verlässt Ihr Netzwerk. Prüfen Sie die Enterprise privacy commitments.

Building GPT Actions with OpenAPI and OAuth

Watch on YouTube

Schritt 4: Der strukturierte Entwurf (Capabilities)

Die Aufgabe „Freigabeantrag entwerfen" profitiert von einer konsistenten Form. Geben Sie in den GPT-Instructions das exakte Output-Template vor. Innerhalb eines Custom GPT bekommen Sie nicht die per JSON-Schema erzwungenen Structured Outputs der API, das ist ein API-Feature, aber eine gut spezifizierte Instruction plus ein Conversation Starter liefert Ihnen verlässliche Formatierung für Entwürfe, die Menschen lesen.

Wenn das Team später *garantiert* maschinenlesbaren Output braucht (etwa um Freigaben automatisch abzulegen), ist das das Signal, von einem Custom GPT auf eine API-Integration mit der Responses API und Structured Outputs umzusteigen. Mehr zu dieser Grenze unten.

Governance-Fragen, die vor dem Launch zu klären sind

Gehen Sie diese Checkliste mit demjenigen durch, der das Risiko verantwortet. Nichts davon ist optional für ein GPT, auf das sich ein Team verlässt.

Datenklassifizierung. Was sind die sensibelsten Daten, die dieses GPT berühren kann, über Knowledge-Dateien *und* über Actions? Klassifizieren Sie auf dieser Stufe und wenden Sie Ihre bestehenden Handhabungsregeln an. Das GPT bekommt keine Sonderfreigabe.

Identität und Zugriff. Wer darf es nutzen? In Enterprise kann der GPT-Zugriff eingegrenzt werden, und SSO regelt, wer überhaupt im Workspace ist. Bestätigen Sie, dass Offboarding (jemand geht) 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, Nutzungstransparenz und die Compliance API zum Abruf von Konversations- und Audit-Daten. Wenn Sie die Frage „wer hat den Deal Desk Assistant nach Deal X gefragt" beantworten müssen, brauchen Sie das *vor* dem Launch, nicht nach einem Vorfall. Siehe Enterprise compliance and admin features.

Memory und Projects. Seien Sie sich bewusst, wo State liegt. Memory und Custom Instructions sind nutzerbezogener persönlicher Kontext, nicht Teil der geteilten GPT-Konfiguration, sie leaken also nicht zwischen Nutzern. Aber wenn Ihr Team in einem geteilten Project arbeitet, werden Dateien und Instructions, die diesem Project hinzugefügt werden, mit den Project-Mitgliedern geteilt. Verwechseln Sie ein Project (ein geteilter Arbeitsbereich für Chats und Dateien) nicht mit einem Custom GPT (ein konfigurierter Assistent). Sie haben unterschiedliche Sharing-Modelle.

Die Halluzinationsgrenze. Ein Deal Desk Assistant, der zur Discount-Policy *autoritativ klingt*, kann selbstbewusst einen Schwellenwert erfinden. Entscheiden Sie, wofür er Source of Truth sein darf. Gute Praxis: Weisen Sie ihn an, den Policy-Abschnitt zu zitieren und lieber abzulehnen als zu raten, wenn die Policy dazu schweigt.

Wissenscheck

1. Wenn Sie ein Custom GPT mit Kollegen teilen, was wird tatsächlich für alle zugänglich, die es nutzen können?

2. Warum ist es riskant, „Anyone with the link" in einem Team- oder Enterprise-Workspace automatisch als „nur intern" zu verstehen?

3. Ein Builder lädt eine Tabelle mit internen Margen in das Knowledge eines GPT, damit es darüber schlussfolgern kann, und teilt das GPT dann mit dem gesamten Team. Wie ist diese Datenlage richtig zu bewerten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE der folgenden Optionen aus, die laut Lektion gültige Sichtbarkeitszustände für ein Custom GPT sind.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen aus, die eine solide Governance-Logik beim Rollout eines geteilten Arbeits-GPT wie dem „Deal Desk Assistant" widerspiegeln.

Wählen Sie alle richtigen Antworten aus.

Wann ein Custom GPT das falsche Werkzeug ist

Custom GPTs sind hervorragend für konversationelle 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 Assistentenverhalten in Ihre eigene App zu bringen, bauen Sie auf der API.
  • Sie garantierten strukturierten Output oder programmatische Kontrolle brauchen. Nutzen Sie die Responses API mit Structured Outputs und Function Calling.
  • Sie mehrstufige Autonomie über Tools hinweg und eigene Orchestrierung brauchen. Das ist das Terrain des Agents SDK oder des ChatGPT agent für autonome Aufgaben im Produkt.

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

python
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-4.1",
    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 kontrolliert *Ihr* Code die Authentifizierung, führt den tatsächlichen getDeal-Aufruf aus und kann Policy im Code erzwingen, statt zu hoffen, dass der Prompt hält. Die Responses API docs behandeln den kompletten Tool-Calling-Loop.

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

Kernpunkte

  • Wählen Sie den Sichtbarkeitszustand bewusst und denken Sie daran, dass alles in der Konfiguration für jeden Nutzer lesbar ist. Laden Sie niemals Knowledge-Dateien hoch oder hinterlegen Secrets hart, die die Zielgruppe nicht vollständig sehen soll.
  • Besitzen Sie GPTs auf Workspace-/Admin-Ebene, nicht über einen persönlichen Account. Eine Team-Abhängigkeit, die einer einzelnen Person gehört, stirbt mit deren Abgang.
  • Nutzen Sie OAuth für Actions, die nutzerbezogene Daten berühren, und halten Sie Endpoints read-only, sofern Schreibzugriff nicht wirklich nötig ist. Enge API-Oberfläche verkleinert den Blast Radius.
  • Arbeiten Sie eine Pre-Launch-Checkliste ab: Datenklassifizierung, Identität/Offboarding, Audit/Compliance API und eine klare „Source of Truth"-Grenze, um selbstbewusste Halluzinationen zu begrenzen.
  • Wissen Sie, wann der Wechsel zur API fällig ist. Wenn Sie garantierte Struktur, Einbettung in Ihr eigenes Produkt oder erzwungene Zugriffskontrolle brauchen, gehen Sie vom Custom GPT zur Responses API oder zum Agents SDK.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Team-GPTs auf Workspace-/Admin-Ebene besitzen und nur workspace-intern veröffentlichen
  • Führen Sie eine Pre-Launch-Checkliste durch, die Datenklassifizierung, Identität, Audit und Source of Truth abdeckt
  • OAuth für user-scoped Actions oder solche mit Schreibzugriff nutzen; API Keys nur für gemeinsame Read-only-Zugriffe
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.