ChatGPT mit eigenen Unternehmensdaten verbinden: Optionen und Risiken

Das Wichtigste in Kürze: Upload, RAG, Enterprise-Suche oder On-Premise: Welche Wege es gibt, ChatGPT mit Unternehmensdaten zu verbinden, und wo die Daten dabei landen.

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 folgt ein zweiter 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. Das gilt für alle 4 Wege, die dieser Artikel vorstellt.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU. Sie stehen vor genau dieser Entscheidung. Wie verbindet man ChatGPT oder ein vergleichbares Sprachmodell mit eigenen Unternehmensdaten? Und wie verliert man dabei nicht die Kontrolle, wer was sieht und wo es gespeichert wird?

Es geht nicht um die Frage „KI ja oder nein“. Es geht 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

4 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. Mehr Struktur als „Datei plus Chatverlauf“ steckt technisch meist nicht dahinter.

RAG (Retrieval Augmented Generation) ist keine einzelne Funktion, sondern ein Baumuster. Ein Sprachmodell bekommt einen gezielten Zugriff auf eine eigene Wissensquelle. So liefert es kontextspezifische Antworten. Typische Beispiele sind unternehmensinterne Chatbots mit Zugriff auf aktuelle Geschäftsdaten. 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 4 Grundmustern. Sie unterscheiden sich vor allem in einer Dimension: 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 4 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 gibt es so nicht. 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. Ein sensibles Dokument wird manchmal einmal hochgeladen. Im Nachhinein lässt sich dann kaum belastbar nachvollziehen, wer es wann gesehen hat.

Bei RAG liegt die Wissensbasis technisch getrennt vom Modell. Sie liegt typischerweise in einer Vektordatenbank, ergänzt um Metadaten wie Quelle, Datum und Zugriffsberechtigung. Bei jeder Anfrage sucht ein Retrieval-Schritt die relevanten Ausschnitte heraus. Er 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. Kontext wird einmalig gebraucht, keine sensiblen Daten sind betroffen. Beispiele sind ein öffentliches Whitepaper oder ein anonymisiertes Beispiel.

Manchmal werden Inhalte wiederkehrend gebraucht. Oder unterschiedliche Personen sollen unterschiedliche Zugriffsrechte haben. Oder die Datenbasis ändert sich regelmäßig. Dann 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. Die Antwort hängt vom konkret gewählten Produkt und Deployment ab. Das wird in Diskussionen häufig vermischt.

Viele Unternehmen in der EU ziehen Azure OpenAI aus Compliance-Gründen dem direkten OpenAI-API-Zugang vor. Microsoft beschreibt in der eigenen Dokumentation ein differenziertes Bild. Prompts und Antworten werden innerhalb der vom Kunden gewählten Geografie verarbeitet. Sie 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. Laut Microsoft dienen sie auch nicht dem Training oder der Verbesserung der Basismodelle.

2 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 übertragen. Auch nicht auf ein privates ChatGPT-Konto.

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. Das gilt, 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 ab (privates Konto, Team, Enterprise, API, Azure). Sie hängt auch am Deployment ab (Standard, Data Zone, Regional). Und am abgeschlossenen Auftragsverarbeitungsvertrag. Diese 3 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 3 technische Schutzmaßnahmen konkret: Mandantentrennung, Rollen- und Rechtekonzepte sowie Zugriffsbeschränkungen auf die Vektordatenbank. Gleichzeitig weist die Konferenz auf eine strukturelle Herausforderung hin. Ein RAG-System hat eine modulare Architektur: Retriever, Vektordatenbank und Sprachmodell sind getrennte Komponenten. Das erschwert die klare Zuordnung von Zwecken. Auch die transparente Information der Betroffenen wird schwerer, wenn sie nicht von Anfang an mitgedacht wird.

Praktisch bedeutet das für ein KMU-Projekt:

• Rechte aus dem Quellsystem übernehmen, nicht neu erfinden. Ist ein Dokument in SharePoint nur für eine Abteilung sichtbar, 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 umsetzbar sein, nicht nur in der Quelldatenbank. Dynamisch generierte Inhalte erschweren das laut Datenschutzkonferenz zusätzlich. Der Grund: Eine Antwort entspricht nicht eins-zu-eins einem gespeicherten Dokument. Deshalb gehören RAG-Architekturen frühzeitig mit Blick auf diese Rechte geplant, nicht nachträglich.

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 3:

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

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

Datenschutz-by-Design als expliziter Anspruch. RAG-Systeme bieten laut Datenschutzkonferenz gerade deshalb Potenzial für Datenschutz-by-Design. Sie können unabhängig von einem externen Cloud-Anbieter betrieben werden. Sie ermöglichen den Einsatz kleinerer, lokal gehosteter Modelle. Das schließt einen Betrieb ohne Übermittlung personenbezogener Daten an Dritte ein.

Der Preis dieser Kontrolle ist Betriebsaufwand. Bei Cloud-Lösungen liegt er beim Anbieter: 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 entstehen sie überwiegend als Infrastruktur- und Betriebskosten, unabhängig von der Nutzung. Der einmalige Einrichtungsaufwand hängt stark von 2 Dingen 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. Sie gilt nicht automatisch für jedes ChatGPT-Konto oder jeden Konkurrenzdienst. Vor jedem neuen Tool lohnt der Blick in die aktuelle Anbieterdokumentation, nicht in Erinnerungen an einen anderen Dienst.

• RAG löst kein Problem eines rechtswidrig trainierten Modells. Die Datenschutzkonferenz weist ausdrücklich darauf hin: RAG beseitigt die datenschutzrechtlichen Probleme eines möglicherweise rechtswidrig trainierten Basismodells nicht. RAG ergänzt ein Modell nur 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. Das passiert, wenn niemand explizit dafür verantwortlich ist.

• Nicht jede Frage braucht ein Sprachmodell. Ist das eigentliche Problem eine schlecht gepflegte Dokumentenablage, 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?

Die folgenden 4 Blöcke mit insgesamt 15 Punkten fassen den Artikel zusammen.

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.

Gerätst du bei den ersten Punkten der Vorbereitung ins Stocken? Das ist 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.