ChatGPT mit eigenen Unternehmensdaten verbinden: Optionen und Risiken

Das eigentliche Problem: Nutzen wollen, ohne die Kontrolle zu verlieren

„Wir wollen ChatGPT mit unseren Dokumenten verbinden” ist einer der häufigsten Sätze, die ich in Erstgesprächen höre — meist gefolgt von einem zweiten Satz: „Aber wir wissen nicht, wo die Daten dann landen.” Beides gehört zusammen. Der Wunsch ist berechtigt: Support-Teams wollen in Handbüchern suchen, Vertrieb will Angebote aus alten Verträgen ziehen, die Geschäftsführung will eine interne Suche, die Antworten statt nur Treffer liefert. Der Vorbehalt ist genauso berechtigt: Sobald Kundendaten, Personalunterlagen oder Vertragsdetails in einen Chat wandern, ist die Frage nach Kontrolle keine Nebensache mehr.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in kleinen und mittleren Unternehmen, die vor genau dieser Entscheidung stehen: Wie verbindet man ChatGPT oder ein vergleichbares Sprachmodell mit eigenen Unternehmensdaten, ohne die Kontrolle darüber zu verlieren, wer was sieht und wo es gespeichert wird? Es geht nicht um die Frage „KI ja oder nein”, sondern um die Wahl des richtigen Wegs für den jeweiligen Anwendungsfall — und um das ehrliche Benennen der Grenzen, die dabei bleiben.

Meine Kurzposition vorweg: Es gibt keinen Königsweg, der für jeden Anwendungsfall gleich gut passt. Ein Upload für eine einmalige Analyse ist etwas anderes als ein produktiver Chatbot mit Zugriff auf das gesamte Vertragsarchiv. Wer beides mit derselben Lösung erschlagen will, bekommt entweder zu wenig Kontrolle oder zu viel Aufwand für zu wenig Nutzen.

Begriffe kurz geklärt: Upload, RAG, On-Premise

Vier Begriffe tauchen in diesem Themenfeld ständig auf und werden oft synonym verwendet, obwohl sie technisch sehr unterschiedliche Dinge bedeuten:

Upload meint das direkte Hochladen einer Datei in einen einzelnen Chat oder ein Custom GPT. Das Dokument wird Teil des Gesprächskontexts (oder eines an das Custom GPT gebundenen Datei-Speichers) — mehr Struktur als „Datei plus Chatverlauf” steckt technisch meist nicht dahinter.

RAG (Retrieval Augmented Generation) ist keine einzelne Funktion, sondern ein Baumuster: Ein Sprachmodell wird um einen gezielten Zugriff auf eine eigene Wissensquelle ergänzt, um kontextspezifische Antworten zu liefern. Typische Beispiele sind unternehmensinterne Chatbots, die auf aktuelle Geschäftsdaten zugreifen, oder wissenschaftliche Assistenzsysteme, die Forschungsdatenbanken einbeziehen. Mehr zu Funktionsweise und Architektur findest du auf der Themenseite RAG und Wissensdatenbanken.

Enterprise-Suche mit KI-Zusammenfassung ist ein verwandtes, aber eigenständiges Muster: Eine klassische Suchmaschine über Unternehmensdaten (SharePoint, Confluence, DMS) bekommt eine KI-Komponente vorgeschaltet, die Treffer zusammenfasst statt nur aufzulisten. Technisch ist das häufig ebenfalls RAG, kommt aber meist als fertiges Produkt statt als Eigenbau.

On-Premise / lokal gehostetes Modell bedeutet, dass das Sprachmodell selbst — nicht nur die Daten — auf eigener oder vertraglich klar zugeordneter Infrastruktur läuft, ohne dass Anfragen einen fremden Cloud-Dienst verlassen.

Welche Optionen gibt es?

Wer „ChatGPT mit eigenen Daten verbinden” sucht, landet in der Praxis bei vier Grundmustern, die sich vor allem in einer Dimension unterscheiden: wie viel Kontrolle du über Zugriff, Aktualität und Speicherort behältst.

1. Direkter Upload in Chat oder Custom GPT. Schnellster Einstieg, kein Entwicklungsaufwand, aber ohne Rechtekonzept: Jeder, der Zugriff auf den Chat oder das Custom GPT hat, sieht die hochgeladenen Inhalte. Kein Versionsmanagement, keine Protokollierung, wer wann worauf zugegriffen hat.
2. RAG-Anbindung über API oder Enterprise-Produkt. Eine eigene oder über einen Anbieter betriebene Wissensbasis (meist eine Vektordatenbank, siehe dazu die Grundlagen zu Vektordatenbanken) wird an das Modell angebunden. Zugriff, Aktualisierung und Protokollierung lassen sich auf dieser Ebene sauber steuern — mit entsprechendem Einrichtungsaufwand.
3. Enterprise-Suche mit KI-Aufsatz. Fertige Produkte, die eine bestehende Dokumentenablage durchsuchbar machen und KI-generierte Zusammenfassungen liefern. Geringerer Eigenbau-Aufwand als eine RAG-Lösung von Grund auf, dafür weniger Freiheit bei der Anpassung.
4. On-Premise oder lokal gehostetes Modell. Volle Kontrolle über Infrastruktur und Datenfluss, aber voller Betriebsaufwand: Wartung, Skalierung und Absicherung liegen bei dir statt beim Cloud-Anbieter.

Diese vier Optionen schließen sich nicht gegenseitig aus. In der Praxis sehe ich häufig eine Kombination: Upload für spontane Einzelfälle ohne sensible Daten, RAG für den produktiven, wiederkehrenden Anwendungsfall.

Entscheidungsmatrix: Welche Option passt zu welchem Fall?

Diese Matrix ist meine eigene Arbeitshilfe aus Projekten — sie ersetzt keine Einzelfallprüfung, sortiert aber die typischen Ausgangslagen:

Option	Datenkontrolle	Aktualität der Daten	Einrichtungsaufwand	Typischer Einsatzfall
Direkter Upload	Niedrig	Nur bei erneutem Upload	Sehr gering	Einmalige Analyse, unkritische Inhalte
Custom GPT mit Wissensdatei	Niedrig–mittel	Manuelle Pflege nötig	Gering	Wiederkehrende, aber kleine Wissensbasis
RAG-Anbindung (API/eigene Wissensbasis)	Hoch, bei sauberer Rechteübernahme	Laufend aktualisierbar	Mittel–hoch	Produktiver interner Assistent, Support, Vertrieb
Enterprise-Suche mit KI-Zusammenfassung	Hoch, an bestehende Systemrechte gebunden	Laufend (folgt Quellsystem)	Mittel	Wissensmanagement über bestehende Ablage
On-Premise / lokales Modell	Sehr hoch	Laufend, volle Eigenverantwortung	Hoch	Hochsensible Daten, strenge Compliance-Vorgaben

Der Punkt, den diese Matrix sichtbar macht: Datenkontrolle und Einrichtungsaufwand laufen meist gegenläufig. Wer beides maximieren will — volle Kontrolle bei minimalem Aufwand — sucht nach einer Kombination, die es so nicht gibt. Die reale Entscheidung ist ein Trade-off, kein Suchproblem.

Upload vs. RAG: Wo liegt der Unterschied?

Das ist die technisch wichtigste Unterscheidung in diesem Themenfeld, weil sie bestimmt, ob sich Zugriffsrechte überhaupt sauber abbilden lassen.

Beim Upload wird ein Dokument Teil des Gesprächskontexts. Es gibt keine separate Speicherebene mit eigenem Rechtekonzept — die Zugriffskontrolle beschränkt sich darauf, wer den Chat oder das Custom GPT überhaupt nutzen darf. Wird ein sensibles Dokument einmal hochgeladen, lässt sich im Nachhinein kaum belastbar nachvollziehen, wer es wann gesehen hat.

Bei RAG liegt die Wissensbasis technisch getrennt vom Modell — typischerweise in einer Vektordatenbank, ergänzt um Metadaten wie Quelle, Datum und Zugriffsberechtigung. Bei jeder Anfrage sucht ein Retrieval-Schritt die relevanten Ausschnitte heraus und reicht nur diese an das Modell weiter; das Modell selbst „kennt” die Gesamtheit der Dokumente nicht dauerhaft. Diese Trennung ist der entscheidende Vorteil: Zugriffsrechte, Versionierung und Protokollierung lassen sich auf der Ebene der Wissensbasis umsetzen, unabhängig vom Modell.

Für die Praxis heißt das: Upload ist gut geeignet für Einzelfälle, in denen Kontext einmalig gebraucht wird und keine sensiblen Daten betroffen sind — ein öffentliches Whitepaper, ein anonymisiertes Beispiel. Sobald Inhalte wiederkehrend gebraucht werden, unterschiedliche Personen unterschiedliche Zugriffsrechte haben sollen oder sich die Datenbasis regelmäßig ändert, ist RAG die tragfähigere Architektur — mit entsprechend höherem Einrichtungsaufwand.

Wo werden die Daten verarbeitet?

Diese Frage lässt sich nicht pauschal für „ChatGPT” beantworten, weil die Antwort vom konkret gewählten Produkt und Deployment abhängt — und das wird in Diskussionen häufig vermischt.

Am Beispiel von Azure OpenAI, das viele Unternehmen in der EU aus Compliance-Gründen dem direkten OpenAI-API-Zugang vorziehen, beschreibt Microsoft in der eigenen Dokumentation ein differenziertes Bild: Prompts und Antworten werden innerhalb der vom Kunden gewählten Geografie verarbeitet, können aber innerhalb dieser Geografie regionsübergreifend verarbeitet werden — außer bei sogenannten Data-Zone- oder Regional-Deployments. Bei einem „DataZone”-Deployment mit einer in der EU liegenden Ressource werden Prompts und Antworten ausschließlich innerhalb von EU-Mitgliedstaaten verarbeitet. Wichtig für die RAG-Frage: Beim Feature „Azure OpenAI on your data” verbleiben die angebundenen Daten in der vom Kunden festgelegten Datenquelle und Region — der Dienst legt laut Microsoft keinen zusätzlichen Datenspeicher an. Modelle werden zudem als zustandslos beschrieben: Prompts und Antworten werden nicht im Modell gespeichert und laut Microsoft nicht zum Training oder zur Verbesserung der Basismodelle verwendet.

Zwei Einschränkungen gehören zur ehrlichen Einordnung dazu: Erstens gilt diese Beschreibung für Azure OpenAI als konkretes Enterprise-Produkt — sie lässt sich nicht automatisch auf jeden anderen Anbieter oder auf ein privates ChatGPT-Konto übertragen. Zweitens betreibt Microsoft ein Missbrauchsüberwachungssystem: Bei Verdacht auf Verstöße gegen die Nutzungsbedingungen können Prompts und Antworten für eine menschliche Prüfung herangezogen werden, sofern ein Kunde keine angepasste Missbrauchsüberwachung beantragt hat. Für EU-Kunden sitzen die dafür autorisierten Mitarbeitenden laut Microsoft im Europäischen Wirtschaftsraum.

Die Konsequenz für die Praxis: „Wo landen unsere Daten” ist keine Frage, die sich mit „bei ChatGPT” abschließend beantworten lässt. Sie hängt am gewählten Produkt (privates Konto, Team, Enterprise, API, Azure), am Deployment (Standard, Data Zone, Regional) und am abgeschlossenen Auftragsverarbeitungsvertrag. Diese drei Punkte solltest du für jede Lösung einzeln klären, bevor produktive Daten hineinfließen — nicht danach.

Wie setzt man Rechte und Berechtigungen um?

Die Datenschutzkonferenz benennt in ihrer Orientierungshilfe zu RAG-Systemen technische Schutzmaßnahmen konkret: Mandantentrennung, Rollen- und Rechtekonzepte sowie Zugriffsbeschränkungen auf die Vektordatenbank gehören zu den zentralen Bausteinen. Gleichzeitig weist die Konferenz auf eine strukturelle Herausforderung hin: Die modulare Architektur eines RAG-Systems — Retriever, Vektordatenbank, Sprachmodell als getrennte Komponenten — erschwert die klare Zuordnung von Zwecken und die transparente Information der Betroffenen, wenn sie nicht von Anfang an mitgedacht wird.

Praktisch bedeutet das für ein KMU-Projekt:

• Rechte aus dem Quellsystem übernehmen, nicht neu erfinden. Wenn ein Dokument in SharePoint nur für eine Abteilung sichtbar ist, muss diese Einschränkung beim Indexieren in die Wissensbasis übertragen werden — sonst hebelt die RAG-Anbindung bestehende Zugriffsbeschränkungen faktisch aus.
• Rechte bei jeder Abfrage prüfen, nicht nur beim Import. Ein einmaliger Rechte-Check beim Einspielen der Dokumente reicht nicht, wenn sich Rollen oder Zugehörigkeiten später ändern. Die Prüfung gehört in den Abfragepfad, nicht nur in die Importlogik.
• Systemprompts zur Quellenbindung nutzen. Die Datenschutzkonferenz nennt als technisch-organisatorische Maßnahme unter anderem Systemprompts zur Quellenbindung, eine regelmäßige Prüfung der Referenzdokumente und ein Monitoring der KI-Ausgaben.
• Dokumentation aktuell halten. Empfohlen wird die Aktualisierung und Pflege der Dokumentation — etwa des Verzeichnisses von Verarbeitungstätigkeiten — inklusive einer Beschreibung der erweiterten Anfrage und der Datenflüsse durch das RAG-System.

Ein Punkt, der in Projekten regelmäßig unterschätzt wird: Betroffenenrechte (Auskunft, Berichtigung, Löschung) müssen in allen Komponenten des RAG-Systems umgesetzt werden können — nicht nur in der Quelldatenbank. Dynamisch generierte Inhalte erschweren das laut Datenschutzkonferenz zusätzlich, weil eine Antwort nicht eins-zu-eins einem gespeicherten Dokument entspricht. Das ist ein Grund, RAG-Architekturen frühzeitig mit Blick auf diese Rechte statt nachträglich zu planen.

Wann ist On-Premise sinnvoll?

On-Premise oder ein selbst gehostetes Modell ist keine Standardempfehlung, sondern die Antwort auf spezifische Ausgangslagen. Aus meiner Projekterfahrung sind das vor allem drei:

Rechtliche oder vertragliche Bindung an den Standort. Wenn Daten aus regulatorischen Gründen (etwa in bestimmten öffentlichen oder besonders regulierten Branchen) eine definierte Infrastrukturgrenze nicht verlassen dürfen, ist eine Cloud-Lösung — egal mit welcher Region-Einstellung — meist nicht die richtige Antwort.

Ein Auftragsverarbeitungsvertrag lässt sich nicht sauber abschließen oder durchsetzen. Die Datenschutzkonferenz weist in ihrer Orientierungshilfe zu KI-Systemen ausdrücklich darauf hin, dass die Übermittlung personenbezogener Daten in die USA mit erheblichen Risiken verbunden ist und ein unzureichendes Datenschutzniveau bestehen kann. Wo ein Anbieter diese Fragen nicht vertraglich und technisch belastbar beantwortet, bleibt On-Premise oder ein europäischer Anbieter mit klar zugeordneter Verarbeitung die verlässlichere Option.

Datenschutz-by-Design als expliziter Anspruch. RAG-Systeme bieten laut Datenschutzkonferenz gerade deshalb Potenzial für Datenschutz-by-Design, weil sie unabhängig von einem externen Cloud-Anbieter betrieben werden können und den Einsatz kleinerer, lokal gehosteter Modelle ermöglichen — inklusive eines Betriebs ohne Übermittlung personenbezogener Daten an Dritte.

Der Preis dieser Kontrolle ist Betriebsaufwand, der bei Cloud-Lösungen beim Anbieter liegt: Infrastruktur bereitstellen und skalieren, Modelle aktuell halten, Sicherheitslücken patchen, Ausfallsicherheit selbst organisieren. Für ein kleines Unternehmen ohne eigenes Infrastruktur-Team ist das ein reales Gegenargument — On-Premise lohnt sich dort, wo die Kontrollanforderung den Mehraufwand eindeutig rechtfertigt, nicht als generelle Vorsichtsmaßnahme.

Umsetzung: Vom ersten Test zum produktiven Einsatz

So gehe ich in Projekten vor, bewusst klein geschnitten:

1. Einen Anwendungsfall wählen, nicht „die ganze Wissensbasis”. Ein Support-Assistent für ein Produkthandbuch ist ein anderes Projekt als ein Assistent über das gesamte Vertragsarchiv. Klein anfangen erlaubt, Rechte- und Aktualisierungslogik an überschaubaren Daten zu testen.
2. Datenklassifizierung vor der Technikwahl. Welche Dokumente sind unkritisch, welche enthalten personenbezogene oder vertraulich eingestufte Daten? Diese Einordnung entscheidet, ob Upload überhaupt infrage kommt oder RAG mit striktem Rechtekonzept nötig ist.
3. Anbieter und Deployment konkret prüfen, nicht raten. Auftragsverarbeitungsvertrag, Verarbeitungsregion und Trainingsausschluss stehen in der jeweiligen Anbieterdokumentation — sie unterscheiden sich zwischen privatem Konto, Team-, Enterprise- und API-Zugang teils erheblich.
4. Rechtekonzept mitplanen, nicht nachrüsten. Wer die Quellsystem-Rechte erst nach dem ersten Produktivstart auf die Wissensbasis überträgt, riskiert eine Phase, in der mehr sichtbar ist, als sein sollte.
5. Datenschutz-Folgenabschätzung einplanen, wenn personenbezogene Daten betroffen sind. Alle Komponenten des Systems — Retriever, Vektordatenbank, Sprachmodell — gehören laut Datenschutzkonferenz in diese Bewertung, nicht nur das sichtbare Chat-Interface.
6. Parallelbetrieb und Feedback-Schleife. Bevor ein Assistent den bisherigen Prozess ersetzt, läuft er eine Zeit lang unterstützend daneben — mit einer klaren Möglichkeit für Nutzer:innen, falsche oder unpassende Antworten zu melden.

Zu Aufwand und Kosten lässt sich ohne konkrete Anbieterangebote nur die Struktur benennen, keine Zahl: Laufende Kosten entstehen bei Cloud-Lösungen meist nutzungsabhängig (pro Anfrage oder Token), bei On-Premise überwiegend als Infrastruktur- und Betriebskosten unabhängig von der Nutzung. Der einmalige Einrichtungsaufwand hängt stark davon ab, wie viele Dokumenttypen und Rechtestufen abgebildet werden müssen und wie gut die Quellsysteme über Schnittstellen erreichbar sind. Belastbare Zahlen bekommst du nur anhand deines konkreten Dokumentenbestands und Anbieterangebots — pauschale Preisangaben ohne diesen Blick halte ich für unseriös.

Risiken und Grenzen — ehrlich benannt

Stand Juli 2026. Das Folgende ist Orientierung, keine Rechtsberatung — für den konkreten Fall gehören Datenschutzbeauftragte und gegebenenfalls Rechtsberatung an den Tisch.

• Der Anbieterwechsel-Effekt. Prompts und Antworten „nicht zum Training zu nutzen” ist eine vertragliche Zusage des jeweiligen Produkts, kein Naturgesetz der Technologie. Sie gilt für das konkrete Produkt (etwa Azure OpenAI oder ein Enterprise-Tarif), nicht automatisch für jedes ChatGPT-Konto oder jeden Konkurrenzdienst. Vor jedem neuen Tool lohnt der Blick in die aktuelle Anbieterdokumentation statt in Erinnerungen an einen anderen Dienst.
• RAG löst kein Problem eines rechtswidrig trainierten Modells. Die Datenschutzkonferenz weist ausdrücklich darauf hin, dass RAG die datenschutzrechtlichen Probleme eines möglicherweise rechtswidrig trainierten Basismodells nicht beseitigt — RAG ergänzt ein Modell um Kontext, es „repariert” nicht dessen Trainingshistorie.
• Betroffenenrechte bleiben eine offene Baustelle. Auskunft, Berichtigung und Löschung über alle Komponenten eines RAG-Systems hinweg sauber umzusetzen, ist technisch anspruchsvoller als bei einer klassischen Datenbank — das gilt es einzuplanen, nicht zu ignorieren.
• Drittlandtransfer bleibt ein reales Risiko. Bei US-Anbietern ohne EU-Verarbeitungsgarantie ist die Übermittlung personenbezogener Daten in die USA laut Datenschutzkonferenz mit erheblichen Risiken verbunden. Wer das ignoriert, verlagert ein rechtliches Risiko in den laufenden Betrieb statt in die Planungsphase.
• Zugriffsrechte veralten, wenn sie niemand pflegt. Ein Rechtekonzept, das beim Rollout korrekt war, driftet mit jeder Reorganisation, jedem Rollenwechsel und jedem neuen Dokumenttyp auseinander, wenn niemand explizit dafür verantwortlich ist.
• Nicht jede Frage braucht ein Sprachmodell. Wenn das eigentliche Problem eine schlecht gepflegte Dokumentenablage ist, löst keine noch so gute RAG-Anbindung das zugrunde liegende Ordnungsproblem — sie macht die Unordnung nur schneller durchsuchbar.

Checkliste: Bereit für ChatGPT mit eigenen Daten?

Vorbereitung

• Konkreter Anwendungsfall benannt (nicht „die ganze Wissensbasis auf einmal”)
• Datenklassifizierung durchgeführt: unkritisch, personenbezogen, vertraulich
• Zielsysteme mit ihren bestehenden Zugriffsrechten identifiziert (SharePoint, DMS, CRM …)

Anbieter- und Architekturwahl

• Passendes Muster gewählt: Upload, RAG, Enterprise-Suche oder On-Premise (siehe Entscheidungsmatrix)
• Auftragsverarbeitungsvertrag mit dem Anbieter geprüft
• Verarbeitungsregion und Deployment-Typ konkret geklärt (nicht nur „Cloud” angenommen)
• Trainingsausschluss der Eingaben für das gewählte Produkt verifiziert, nicht angenommen

Rechte und Datenschutz

• Rechtekonzept aus Quellsystemen auf die Wissensbasis übertragen
• Rechteprüfung im Abfragepfad verankert, nicht nur beim Import
• Datenschutz-Folgenabschätzung geprüft, wenn personenbezogene Daten betroffen sind
• Verzeichnis von Verarbeitungstätigkeiten und Datenflüsse aktualisiert
• Betroffenenrechte (Auskunft, Berichtigung, Löschung) für alle Systemkomponenten geklärt

Betrieb

• Parallelbetrieb mit Feedback-Möglichkeit für Nutzer:innen geplant
• Verantwortliche Person für Rechte- und Datenpflege benannt
• Regelmäßige Prüfung von Referenzdokumenten und KI-Ausgaben eingeplant

Wenn du bei den ersten Punkten der Vorbereitung ins Stocken gerätst, ist das kein Zeichen, dass die Technik zu kompliziert ist — es heißt nur, dass die Sortierung der eigenen Daten die eigentliche erste Aufgabe ist. Genau dabei hilft ein strukturierter Blick von außen, etwa in einem Erstgespräch oder im Rahmen einer KI-Beratung.