Ein gemeinsamer Kanal hat ein gemeinsames Publikum
ChatGPT kann in freigegebenen Slack-/Teams-Konversationen mit den dort konfigurierten Tools arbeiten. Eine Antwort ist für die Gesprächsteilnehmer sichtbar. Du darfst deshalb nicht einfach einen privaten Chat oder eine vertrauliche Quelle in einen allgemeinen Kanal übertragen. Die zugrunde liegende Verbindung kann außerdem von deinen persönlichen Apprechten abweichen.
Diese gemeinsamen Oberflächen gehören zu den Enterprise-Neuerungen des DevDay vom 29. September 2026. Rollout, Plan und Organisationsfreigabe bleiben Voraussetzungen. Der Guide erklärt die Vorbereitung und einen kontrollierten Pilot; er installiert keine Firmenapp für dich.
Schritt 1: Publikum und Arbeitsgegenstand festlegen
Wähle einen ausdrücklich freigegebenen Demokanal oder eine entsprechende Teamgruppe. Der Arbeitsgegenstand ist die interne Workshopnotiz mit fiktiven Daten. Definiere, wer Antworten sehen und die verwendeten Quellen lesen darf. Ein externer Gast verändert die Datenfreigabe, auch wenn er nur zum Gespräch hinzugefügt wird.
Schritt 2: Die konkrete Verbindung prüfen
Administratoren können Unternehmensverbindungen mit angebotenem Authentifizierungsverfahren einrichten und Benutzungs- wie Verwaltungsrechte getrennt vergeben. Die Rechte des verbundenen externen Kontos begrenzen den Zugriff. Ein Name wie „Teamquelle“ beweist nicht, dass nur die gewünschten Ordner freigegeben sind.
Halte Connection Owner, Kontoidentität, erlaubte Quellen und Wiederanmeldungsweg fest. Ein einzelnes Postfach, eine Gruppe und eine Serviceidentität sind nicht austauschbar. Secrets gehören weder in einen Kanalthread noch in einen Screenshot des Pilots.
Schritt 3: Eine begrenzte gemeinsame Frage stellen
Fasse in diesem freigegebenen Demokanal nur den fiktiven Workshopstand
aus den konfigurierten Teamquellen zusammen. Zeige bestätigte Fakten,
offene Fragen und nächste menschliche Entscheidungen mit Quellen.
Nutze keine privaten Nutzerquellen oder früheren persönlichen Chats.
Wenn ein Detail für dieses Publikum nicht freigegeben ist, lass es aus
und benenne die Zugriffslücke. Keine externen Nachrichten oder Buchungen.
Schritt 4: Positive und negative Zugänge testen
Prüfe den erlaubten Kanal, einen ausgeschlossenen Kontext und die tatsächlich zugelassenen Nutzer. In Slack blockiert Selected channels only laut Dokumentation nicht automatisch Direktnachrichten. DMs verdienen deshalb einen getrennten Test und eine eigene Entscheidung. In Teams prüfst du zugewiesene und nicht zugewiesene Nutzer. Solche Tests werden nur mit eigenen freigegebenen Demoidentitäten durchgeführt.
Bestehende Slackinstallationen können für die neue Erfahrung zusätzliche genehmigte Apprechte benötigen. Eine alte Installation ist kein Beleg, dass die aktuelle Konfiguration bereits richtig ist. Prüfe die angebotenen Rechte mit dem zuständigen Admin, statt einen Fehler durch pauschale Freigaben zu verdecken.
Schritt 5: Sicherheitsbereiche getrennt betrachten
Agent Security bildet ein aktuelles Adminmodell. Lokale und Codex-Cloud-Einstellungen, Work-Cloud-Container und dot-Cloudcomputer haben unterschiedliche Ausführungsvorgaben. Lokale Datei-/Netzwerkgrenzen werden nicht automatisch in jede Cloudumgebung übertragen. Browserzugriff und Code-/Shell-Netzwerk sind ebenfalls getrennte Rechte. Der Kanalpilot braucht nur seine freigegebenen Quellen, keine globale Sicherheitsumstellung.
Deine Abnahme
Publikum und verwendete Identität sind bekannt. Der erlaubte Kontext liefert die richtigen fiktiven Quellen; ausgeschlossene Kontexte sind entsprechend geprüft. Antworten enthalten keine privaten Informationen. Ein Betreiber kann Verbindungen erneuern oder im regulären Weg widerrufen. Ergebnisse bleiben als Entwürfe erkennbar und lösen keine externen Aktionen aus.
Unternehmensverbindung konkret vorbereiten
Dieser Ablauf betrifft zuständige Workspace-Verantwortliche; die Leserübung selbst richtet keine fremden Konten ein. Öffne Admin Console → Workspace connections → + und wähle die benötigte App. Authentifiziere das ausdrücklich dafür vorgesehene Unternehmenskonto über den angebotenen Weg, prüfe Identität und angefragte Rechte und gib der Verbindung einen sprechenden Namen, beispielsweise „Workshopquellen: Lesen“.
Vergib Nutzung und Verwaltung separat an den erlaubten Kreis. Die Sichtbarkeit der Verbindung, die Rolle des Nutzers, die Rechte des Quellkontos und die Auswahl im tatsächlichen Workflow sind vier Ebenen. Ein Mitarbeiter kann durch eine freigegebene Unternehmensverbindung auf andere Daten zugreifen als über sein persönliches Konto; genau deshalb müssen Quellenumfang und Publikum geprüft werden.
Für den Pilotablauf prüft der Surface-Verantwortliche den richtigen Slack-Workspace beziehungsweise Teams-Tenant, öffnet die Plugin-Einstellungen der @ChatGPT-Oberfläche, fügt das genehmigte Plugin hinzu, wählt die gespeicherte Workspace-Verbindung und speichert. Öffne die Einstellungen anschließend erneut und kontrolliere die Auswahl. Eine gespeicherte Verbindung wird nicht automatisch von jedem Kanalworkflow genutzt.
Teste zunächst nur das Lesen einer ausdrücklich erlaubten fiktiven Quelle. Erwartet: richtige Identität, richtige Projektdatei und keine Daten außerhalb des genehmigten Umfangs. Der Zugriff eines berechtigten Testnutzers soll funktionieren, ein nicht berechtigter Kontext darf die Verbindung nicht verwenden. Ein Quellenlink allein verleiht dem Kanalpublikum keine Leserechte auf die Originaldatei. Einen echten Post oder Versand testest du erst mit ausdrücklich erlaubtem Empfänger; diese Begleitübung verlangt keine Nachricht an Dritte.
Fehlt die Verbindung, prüfe Workspace, Rolle und konfiguriertes Publikum mit dem Admin. Ist sie sichtbar, wird aber nicht verwendet, prüfe die gespeicherte Auswahl in der Surface. Schlägt nur eine Quelle fehl, prüfe das Quellkonto. Entfernst du später die ChatGPT-Verbindung, ist die providerseitige Autorisierung separat zu prüfen und gegebenenfalls zu widerrufen.
Quelle: Workspace connections, Surface-Konfiguration, geprüft am 5. Oktober 2026.
Wenn es hakt
Falsche Quelle: Identität und Connection-Rechte prüfen. Zu große Sichtbarkeit: Publikum und Surfacekonfiguration gemeinsam untersuchen. Kanalbegrenzung reicht nicht: DM-Regeln getrennt kontrollieren. Antwort bleibt aus: tatsächliche Appinstallation, Rollout und freigegebene Nutzer prüfen. Beginne mit einem kleinen dokumentierten Pilot und erweitere erst nach bestandenen Tests.