Der neue Data Agent von OpenAI kann angebundene Unternehmensdaten mit den bestehenden Berechtigungen des verbundenen Kontos abfragen. Damit ist noch nicht entschieden, wer das daraus erstellte Dashboard erhalten darf. Laut OpenAIs Einrichtungsanleitung werden beim Veröffentlichen einer Analyse über ChatGPT Sites die verwendeten Analysedaten in die Website kopiert. Für deutsche Unternehmen kommt eine weitere Einschränkung hinzu: Sites ist laut aktueller Hilfedokumentation zum Start nicht im Europäischen Wirtschaftsraum verfügbar.
Die praktische Entscheidung lautet deshalb nicht einfach: „Konversationelle Business Intelligence einschalten.“ Prüfen Sie Quellidentität, Kennzahlendefinition und Ausgabeziel getrennt. Eine zulässige Abfrage berechtigt nicht automatisch zur Weitergabe ihres Ergebnisses an einen größeren Empfängerkreis. Und die Verfügbarkeit des Data-Plugins belegt nicht, dass jede empfohlene Veröffentlichungsfunktion nutzbar ist.
Was sich ändert: ein gebündelter Workflow für Datenanalysen
Am 10. September 2026 hat OpenAI den Data Agent in ChatGPT Work vorgestellt. Er verbindet freigegebene Unternehmensquellen, untersucht geschäftliche Fragen und erstellt interaktive Dashboards. Die Ankündigung nennt unter anderem Amazon Redshift, Datadog, Google BigQuery, ClickHouse, Databricks, MongoDB und Snowflake. Dokumente aus Google Drive und SharePoint können zusätzlichen Kontext liefern.
Der Agent kann Geschäftsdefinitionen und Datenbeziehungen aus semantischen Ebenen und vertrauenswürdigen Quellen berücksichtigen, darunter dbt, Databricks Genie Ontology und Snowflake Horizon. OpenAI beschreibt außerdem die Anbindung bestehender BI-Werkzeuge wie Power BI, Tableau, Sigma und ThoughtSpot. Das sind dokumentierte Anbieterfunktionen, keine unabhängige Messung analytischer Korrektheit und keine Zusage, dass jeder Konnektor jede Aktion unterstützt.
Die Neuerung ist weder die Erfindung natürlichsprachlicher Datenanalyse noch ein Ersatz für ein kontrolliertes Data Warehouse. Ihr Nutzen liegt darin, Quellenzugriff, Geschäftskontext, Untersuchung und Ergebniserstellung in einem Workflow zu bündeln. Gegenüber einem konventionellen BI-Bericht kann das die Schritte zwischen Frage und vorgeschlagener Analyse reduzieren. Zugleich müssen Definitionen, Verknüpfungen und Empfänger ausdrücklich geprüft werden, statt hinter einer überzeugend gestalteten Grafik als gegeben zu erscheinen.
Dieser Beitrag bewertet die Ankündigung und die am 13. September abgerufene Dokumentation. Er behauptet weder eine eigene Produktimplementierung noch einen gemessenen Produktivitätsgewinn.
Wer Data nutzen kann – und welche Funktion in Deutschland fehlt
Laut Anleitung zum Data-Plugin muss das Plugin im jeweiligen ChatGPT-Work- oder Codex-Konto beziehungsweise Workspace verfügbar sein. Administratoren konfigurieren es unter Workspace settings > Plugins und können Verfügbarkeit oder Installation für berechtigte Rollen und Gruppen festlegen. Zusätzlich müssen das passende Datenquellen-Plugin und die enthaltene App freigeschaltet und verbunden sein. Manche Integrationen erfordern zunächst die Einrichtung einer App-Vorlage durch einen Administrator.
Installation ist keine Autorisierung. Die allgemeine Plugin-Dokumentation unterscheidet das Paket aus Skills und Apps von den Berechtigungen jeder enthaltenen App. Ein sichtbarer Verzeichniseintrag oder ein installiertes Plugin belegt weder Snowflake-Zugriff noch die Freigabe einer Schreibaktion oder das Recht, ein Dashboard zu veröffentlichen. Tarif, Rolle, Workspace-Einstellungen, Region und unterstützte Produktoberfläche können den Zugriff jeweils begrenzen.
OpenAI empfiehlt eine Warehouse-Anbindung, eine verbindliche semantische Ebene und Sites zur Veröffentlichung von Dashboards; ein vorhandenes BI-Werkzeug ist optional. Die Sites-Dokumentation beschreibt Sites jedoch als öffentliche Beta und schließt zum Start den EWR, die Schweiz und das Vereinigte Königreich aus. Sie erklärt außerdem, dass Sites zum Start weder Datenresidenz noch Inferenzresidenz unterstützt. Das umfasst veröffentlichte Websites, Code, Speicher, Artefakte und Protokolle.
Planen Sie einen deutschen Rollout daher nicht mit Sites, bevor sich die tatsächliche regionale Verfügbarkeit geändert hat und Ihr Unternehmen diesen Dienst freigegeben hat. Daraus folgt nicht, dass der gesamte Data Agent in Deutschland unverfügbar ist. Es bedeutet, dass der empfohlene Workflow eine Komponente mit separat zu prüfender regionaler Einschränkung enthält. Untersuchen Sie ein bereits freigegebenes BI-Ziel nur dann als Alternative, wenn der konkrete Konnektor die benötigten Aktionen unterstützt. Funktionsgleichheit und identische Freigaberegeln sind nicht vorauszusetzen.
Quellberechtigungen und veröffentlichte Kopien sind getrennte Kontrollen
OpenAI zufolge verwenden Abfragen die Berechtigungen des verbundenen Kontos einschließlich anwendbarer Tabellen-, Zeilen- und Spaltenbeschränkungen. Klären Sie zuerst, welches Konto verbunden ist und was es lesen darf. Eine weitreichende Warehouse-Rolle bleibt auch beim Zugriff durch einen Agenten weitreichend. Das Kontrollprinzip entspricht unserem Leitfaden zur Zugriffskontrolle vor dem Retrieval: Das Modell ist nicht die Instanz, die Zugriffsrechte festlegt.
Die Data-Anleitung enthält dann einen eigenständigen Hinweis: Die für eine Analyse verwendeten Daten werden in eine veröffentlichte Site kopiert. Für diese Website gelten eigene Empfängereinstellungen. Die Sites-Dokumentation beschreibt Zugriff für Eigentümer und Administratoren, ausgewählte Personen oder Gruppen, soweit unterstützt, den Workspace sowie öffentliche Freigaben, sofern aktiviert. In Enterprise ist öffentliches Veröffentlichen standardmäßig ausgeschaltet. Doch auch ein interner Empfängerkreis kann für einen abteilungsgebundenen Datensatz zu groß sein.
Die technische Schlussfolgerung lautet nicht, dass OpenAI eine Zugriffsschwachstelle nachgewiesen hätte. Vielmehr müssen Abfrageberechtigung und Artefaktfreigabe getrennt getestet werden. Setzen Sie nicht voraus, dass ein Entzug des Warehouse-Zugriffs bereits eingebettete Daten aus einem veröffentlichten Artefakt entfernt. Die geprüfte Dokumentation belegt keine automatische Übertragung dieses Rechteentzugs auf jede kopierte Ausgabe.
Ein Finanzanalyst darf beispielsweise regionale Margendaten abfragen. Ein unternehmensweit verfügbares Dashboard mit kundenbezogenen Margen könnte dagegen einen unzulässigen Empfängerkreis haben. Das Entfernen einer sichtbaren Detailgrafik reicht nicht, wenn die generierte Website diese Datensätze weiterhin im Datenbestand enthält. Prüfen Sie exportierte Felder und eingebettete Daten, nicht nur die Bildschirmansicht. Dies ist ein vorgeschlagener Abnahmetest, kein berichteter Vorfall beim Data Agent.
Behandeln Sie jede geteilte Ausgabe als abgeleitetes Datenobjekt: mit Verantwortlichem, Quelle, Klassifizierung, Extraktionszeitpunkt, zugelassenem Empfängerkreis und Entfernungsverfahren. Unser Leitfaden zur RAG-Daten-Governance liefert die Grundlage für diesen Lebenszyklus. Die aktuelle Produkteinführung ergänzt die konkrete Frage, welche Daten von einer berechtigungsgesteuerten Abfrage in eine separat gehostete Analysekopie gelangen.
Korrekte Berechtigungen machen eine Kennzahl noch nicht korrekt
Der Agent kann genau die richtigen Datensätze sehen und trotzdem die falsche Frage beantworten. „Umsatz“ kann gebuchte Aufträge, gestellte Rechnungen oder realisierten Umsatz meinen. „Dieses Quartal“ kann sich auf das Geschäftsjahr oder das Kalenderjahr beziehen. Eine Verknüpfung von Ergebnissen auf Kundenebene mit einzelnen Positionen kann Beträge vervielfachen, obwohl jeder gelesene Datensatz zulässig ist.
OpenAI empfiehlt verbindliche Geschäftsdefinitionen und fordert Nutzer auf, Quellen, Zeiträume, Filter und Kennzahlendefinitionen vor der Verwendung eines Ergebnisses zu prüfen. Machen Sie daraus ein Abnahmekriterium: Binden Sie die Analyse an eine benannte Definition, eine festgelegte Datenkörnung, Zeitzone, Währungsbehandlung und Referenzabfrage. Lassen Sie den Datenverantwortlichen ein begrenztes Ergebnis mit dem bestehenden Bericht abstimmen, bevor Sie bewerten, wie schnell der Agent es erstellt hat.
Fehlt eine Definition, muss eine Rückfrage erfolgen. Eine plausible Modellinterpretation darf nicht unbeabsichtigt zur Management-Kennzahl werden. Unterscheiden Sie bei vermeintlichen Einflussfaktoren außerdem beschreibende Zusammenhänge von kausalen Nachweisen. Zwei gleichzeitige Bewegungen in einem Dashboard belegen keine Ursache-Wirkungs-Beziehung.
Preise und Betriebsgrenzen: den gesamten Weg prüfen
Die hier geprüfte Ankündigung und Data-Einrichtungsanleitung nennen weder einen eigenständigen Data-Agent-Tarif noch einen vollständigen Preis pro Analyse. Bezeichnen Sie die Funktion deshalb nicht als kostenlos. Übertragen Sie auch keine API-Tokenpreise eines anderen Angebots auf den gesamten Workflow. Prüfen Sie den erworbenen Tarif, enthaltene Funktionen und Konnektorbedingungen für den vorgesehenen Workspace.
Laut Sites-Dokumentation ist die Beta-Nutzung innerhalb tarifabhängiger Grenzen enthalten; diese Grenzen können sich ändern. Das ist weder eine Zusage unbegrenzten Hostings noch eine Aufhebung der regionalen Einschränkung. Warehouse-Abfragen, externe BI-Dienste, wiederkehrende Aktualisierungen und menschliche Prüfung können zusätzliche Kosten und Kapazitätsgrenzen außerhalb des Data-Plugins verursachen.
Messen Sie im Pilot akzeptierte Analysen, Warehouse-Ressourcenverbrauch, Durchlaufzeit und Korrekturen durch Prüfer. Begrenzen Sie teure explorative Abfragen, bevor Sie wiederkehrende Aktualisierungen aktivieren. Eine günstige erste Antwort spart nichts, wenn Definition und Empfängerliste anschließend jedes Mal manuell rekonstruiert werden müssen.
Checkliste für die Freigabe: fünf Prüfungen vor der Ausweitung
1. Konto, Region und Ausgabeziel konkret verifizieren
Dokumentieren Sie Workspace, berechtigte Rolle, Data-Plugin, Quell-App, Verbindungsidentität und geplantes Ausgabeziel. Bestätigen Sie die Verfügbarkeit im tatsächlichen Konto, nicht allein anhand des Plugin-Verzeichnisses. Nehmen Sie Sites für ein deutsches Team nicht in den Rollout auf, solange der dokumentierte EWR-Ausschluss gilt. Die Prüfung ist erst bestanden, wenn der gesamte gewählte Weg verfügbar und freigegeben ist.
2. Die Abfragegrenze mit synthetischen Datensätzen nachweisen
Legen Sie in einer Testumgebung einen erlaubten und einen gesperrten Datenausschnitt an. Prüfen Sie Tabellen-, Zeilen- und Spaltenbeschränkungen mit der verbundenen Identität, einschließlich einer ausdrücklich unzulässigen Anfrage. Bewahren Sie bereinigte Abfragenachweise und das Autorisierungsergebnis der Quelle auf. Stoppen Sie, wenn ein Konnektor umfassendere Rechte verlangt, als der Anwendungsfall rechtfertigt. Eine breitere Warehouse-Rolle ist keine zulässige Reparatur eines fehlgeschlagenen Tests.
3. Vor dem Vergleich eine Kennzahlendefinition festschreiben
Wählen Sie eine bestehende Geschäftsfrage und ihre genehmigte Definition. Halten Sie Quellversion oder Extraktionszeitpunkt, Verknüpfungskörnung, Zeitraum, Zeitzone, Filter und erwartetes Abstimmungsergebnis fest. Verlangen Sie offengelegte Annahmen und Nachweise. Die Prüfung ist bestanden, wenn ein Prüfer das Ergebnis reproduzieren kann. Pausieren Sie bei ungeklärten Definitionen oder unerklärten Abweichungen von der Referenz.
4. Kopierte Daten prüfen und Empfängerzugriff testen
Ist ein Veröffentlichungsweg verfügbar und freigegeben, prüfen Sie vor der Veröffentlichung enthaltene Daten und geplanten Empfängerkreis. Testen Sie mit synthetischen Inhalten sowohl einen separat berechtigten als auch einen separat unberechtigten Empfänger. Üben Sie den Entzug von Quellrechten und Artefaktzugriff unabhängig voneinander und dokumentieren Sie die tatsächliche Wirkung. Sperren Sie die Weitergabe, solange sensible Felder, Empfängerkreis oder Löschverantwortung ungeklärt sind. Verwenden Sie für einen Test öffentlicher Links keine echten vertraulichen Datensätze.
5. Aktualisierung und Folgeaktionen begrenzen
Benennen Sie Verantwortliche, Quellidentität, Ausgabenlimit und Fehlerbenachrichtigung für Aktualisierungen. Prüfen Sie, ob ein späterer Lauf neue Felder ergänzen oder den Umfang offengelegter Daten verändern kann. Lassen Sie Slack-Freigaben, E-Mail-Verteilung und Schreibzugriffe auf Geschäftssysteme deaktiviert, bis Ziele und Genehmigungskontrollen geprüft sind. Setzen Sie für folgenreiche Aktionen menschliche Freigabeschritte ein, statt eine generierte Empfehlung als Ausführungsauftrag zu behandeln.
Mit der Ausgabegrenze beginnen, nicht mit einer unternehmensweiten Freischaltung
Der Data Agent kann eine nützliche Oberfläche für etablierte Dateninfrastruktur bieten. Sein Nutzen hängt davon ab, dass Definitionen und Berechtigungsgrenzen erhalten bleiben, die diese Infrastruktur verlässlich machen. Die dokumentierte Kopie nach Sites und dessen regionale Startbeschränkungen machen die Kontrolle von Ausgaben zu einer Beschaffungsvoraussetzung – nicht zu einer Aufräumaufgabe, nachdem Dashboards bereits zirkulieren.
Beginnen Sie mit einer nicht sensiblen Geschäftsfrage, einer Quellidentität und einem freigegebenen Ziel. Weiten Sie den Einsatz erst aus, wenn Abfragebeschränkungen, Ergebnisabgleich, Empfängerzugriff und Entfernungstests bestanden sind. Diese Kontrollen verursachen Prüfaufwand und können den ersten Rollout verlangsamen. Sie schaffen zugleich die Grundlage, einen hilfreichen Analyseworkflow von einem lediglich bequemeren Exportweg zu unterscheiden.
Bei einem abgegrenzten Projekt zur KI-Automatisierung und Implementierung sollte das erste Ergebnis eine Datenfluss- und Abnahmeprüfung sein: Was wird abgefragt, was wird kopiert, wer erhält es und wie wird die Kopie zurückgezogen? Dies ist technische Orientierung, keine Rechtsberatung. Lassen Sie die tatsächlichen Verarbeitungsvereinbarungen und anwendbaren Pflichten durch Ihre Rechtsberatung und Datenschutzverantwortlichen prüfen.
