Die Frage kommt inzwischen in fast jedem Erstgespräch, und sie kommt meistens in derselben Form: „Kann man ChatGPT nicht einfach unsere Daten geben?" Die ehrliche Antwort ist ja, und sie ist gleichzeitig die unbrauchbarste Antwort auf diese Frage. Denn hinter dem Satz stecken vier völlig verschiedene Vorhaben, die unterschiedlich viel kosten, unterschiedlich lange dauern und unterschiedlich schiefgehen.
Dieser Artikel sortiert die vier Wege, sagt bei jedem, wofür er taugt, und benennt die Punkte, an denen solche Projekte in der Praxis hängenbleiben. Es geht dabei ausdrücklich nicht darum, welches Modell das beste ist. Das ist die Frage, die am wenigsten entscheidet.
Ein Sprachmodell weiß nichts über euer Unternehmen. Es hat euren Angebotsprozess nie gesehen, kennt eure Artikelnummern nicht und weiß nicht, welcher Kunde welchen Rahmenvertrag hat. Alles, was es über euch weiß, muss zum Zeitpunkt der Frage im Text stehen, den es zu lesen bekommt. Dieser Text heißt Kontext, und er ist begrenzt.
Daten anbinden heißt deshalb nicht, dem Modell etwas beizubringen. Es heißt, dafür zu sorgen, dass zum richtigen Zeitpunkt die richtigen Ausschnitte eurer Daten in diesem Kontext landen. Wer das einmal verstanden hat, versteht auch, warum die meisten Projekte nicht am Modell scheitern, sondern an der Frage, woher der Ausschnitt kommt und wer ihn sehen darf.
Der einfachste Weg ist der, den alle schon benutzen: Datei hochladen, Text einfügen, Frage stellen. Das ist kein Projekt, das ist eine Arbeitsweise. Für eine einmalige Auswertung, eine Zusammenfassung oder einen Textentwurf reicht es vollkommen.
Die Grenze ist schnell erreicht. Der Kontext ist endlich, und jede Frage beginnt wieder bei null. Wer jeden Morgen dieselben drei Dateien hochlädt, hat kein KI-Projekt, sondern eine Handarbeit mit Zwischenschritt. Genau solche Handgriffe sind der Punkt, an dem sich ein Blick auf die Abläufe lohnt, oft noch bevor überhaupt über KI geredet wird.
Der Standardweg für Unternehmenswissen heißt Retrieval Augmented Generation, kurz RAG. Das Verfahren klingt komplizierter, als es ist. Eure Dokumente werden in Abschnitte zerlegt, jeder Abschnitt wird in eine Zahlenrepräsentation übersetzt, die seine Bedeutung abbildet, und diese Repräsentationen landen in einem durchsuchbaren Speicher. Stellt jemand eine Frage, wird die Frage genauso übersetzt, die passendsten Abschnitte werden herausgesucht und zusammen mit der Frage an das Modell gegeben.
Der Vorteil: die Antwort steht auf einer Quelle, die man nachschlagen kann. Gute Umsetzungen zeigen diese Quelle an. Das ist kein Schönheitsmerkmal, sondern der einzige Weg, eine Antwort zu prüfen, ohne sie komplett nachzuarbeiten.
Der Nachteil: die Qualität hängt vollständig daran, was im Speicher liegt. Ein Verfahrensverzeichnis von 2019 wird genauso selbstbewusst zitiert wie das von letzter Woche. Drei Versionen desselben Angebots ergeben drei Treffer, und das Modell hat keine Möglichkeit zu erkennen, welche gilt. Wer seine Dateiablage nie aufgeräumt hat, räumt sie an dieser Stelle auf, ob er will oder nicht.
Und es gibt eine Frage, die in der Planung regelmäßig untergeht: Wer hält den Speicher aktuell? Ein Abruf ist keine Suche, die live über eure Ablage läuft, sondern eine Kopie, die zu einem Zeitpunkt gezogen wurde. Wird ein Dokument geändert, muss der betroffene Abschnitt neu eingelesen werden. Wird eines gelöscht, muss es verschwinden, sonst beantwortet das System Fragen aus einer Datei, die es offiziell nicht mehr gibt. Das ist kein einmaliger Aufbau, sondern ein Betrieb, und er gehört jemandem zugeordnet. Wer diesen Punkt überspringt, hat nach einem halben Jahr ein System, dem niemand mehr glaubt, ohne sagen zu können, ab wann es angefangen hat.
Manche Fragen lassen sich nicht aus Dokumenten beantworten. „Ist die Bestellung von Müller schon raus?" steht in keinem PDF, sondern in der Warenwirtschaft, und morgen steht dort etwas anderes. Für solche Fragen bekommt das Modell keinen Text, sondern eine Handvoll klar beschriebener Funktionen, die es aufrufen darf: Auftragsstatus lesen, Ticket anlegen, Termin suchen.
Das Modell entscheidet dann selbst, welche Funktion es braucht, ruft sie auf und formuliert die Antwort aus dem Ergebnis. Für diese Anbindung hat sich mit dem Model Context Protocol ein offener Standard etabliert, der von mehreren Anbietern unterstützt wird. Das erspart es, für jedes System und jedes Modell eine eigene Brücke zu bauen.
Hier wird es zum ersten Mal ernst. Ein Werkzeug, das nur liest, ist eine Auskunft. Ein Werkzeug, das schreibt, ist eine Handlung, und die passiert dann in eurem echten System. Was ein Werkzeug darf, gehört deshalb genauso sauber festgelegt wie die Rechte eines Mitarbeiters, und es gehört protokolliert.
Die naheliegende Idee, dem Modell die eigenen Daten „beizubringen", ist in der Praxis selten die richtige. Nachtrainieren verändert zuverlässig Form, Ton und Format einer Antwort. Es ist dagegen ein schlechtes Mittel, um Fakten einzuspeichern: Was heute stimmt, ist nach der nächsten Preisliste falsch, und man sieht dem Modell nicht an, woher eine Aussage stammt. Dazu kommt der Aufwand für Aufbereitung und Wiederholung bei jeder Änderung.
Es gibt Fälle, in denen sich das rechnet, etwa bei einem sehr eigenen Dokumentformat, das immer gleich aussehen muss. Für „unser Wissen soll rein" ist es der teuerste Weg zum schlechtesten Ergebnis.
Bevor irgendetwas angebunden wird, lohnt eine nüchterne Aufnahme. In den meisten mittelständischen Unternehmen verteilt sich das Wissen auf fünf Orte: die Dateiablage, die Postfächer, das ERP oder die Warenwirtschaft, das Ticket- oder CRM-System und die Köpfe. Der letzte Ort ist der größte und der einzige, den keine Anbindung erreicht.
Für die übrigen vier gilt: liegt das Zeug in Microsoft 365 oder Google Workspace, sind die Schnittstellen vorhanden und die Rechte sind bereits definiert. Das ist der angenehme Fall. Liegt es auf einem gewachsenen Dateiserver mit Freigaben, die seit Jahren niemand geprüft hat, ist die Anbindung der leichte Teil und das Aufräumen der schwere.
Das ist der Punkt, der in Präsentationen fehlt und in Projekten alles entscheidet. Eine Suche über Unternehmensdaten muss wissen, wer fragt. Sonst passiert Folgendes: Der Index wird einmal mit einem Dienstkonto gebaut, das alles lesen darf, und danach kann jeder, der fragen darf, alles finden. Die Gehaltsliste, der Aufhebungsvertrag, die Kalkulation zum letzten Angebot.
Technisch ist das lösbar, die Rechte müssen bis in den Abruf durchgereicht und bei jeder Anfrage ausgewertet werden. Organisatorisch bedeutet es, dass eure Rechtestruktur vorher stimmen muss. Wer ISO 27001 im Haus hat, hat diese Arbeit in Anhang A.8 ohnehin schon gemacht. Alle anderen machen sie spätestens jetzt.
Sobald personenbezogene Daten im Spiel sind, und das sind sie bei Postfächern und CRM immer, gelten dieselben Regeln wie für jeden anderen Dienstleister. Ihr braucht einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO mit dem Anbieter des Modells. Die Verarbeitung gehört in das Verzeichnis nach Art. 30. Und ihr müsst sagen können, welche Daten wohin fließen, wie lange sie dort bleiben und ob sie zum Training verwendet werden. Die Geschäftskunden-Angebote der großen Anbieter schließen das Training auf Kundendaten in der Regel vertraglich aus, die Privatkunden-Varianten oft nicht. Der Unterschied steht im Vertrag, nicht auf der Produktseite.
Dazu kommt der EU AI Act, dessen Pflichten davon abhängen, wofür ihr das System einsetzt. Ein Assistent, der Dokumente zusammenfasst, wird anders behandelt als ein System, das über Bewerbungen mitentscheidet. Wer das früh einordnet, spart sich die Diskussion später. Wenn ihr keinen eigenen Datenschutzbeauftragten habt, ist das der Moment, an dem sich einer lohnt.
Es gibt drei Möglichkeiten, und alle drei sind vertretbar. Ein Anbieterdienst mit EU-Rechenzentrum und Geschäftskundenvertrag ist der schnellste Weg und für die meisten Fälle der richtige. Ein Modell in eurer eigenen Private Cloud kostet Hardware und Betrieb, hält aber alles im Haus, was bei besonders schutzbedürftigen Daten den Ausschlag geben kann. Und ein Mischbetrieb, bei dem der Abruf lokal läuft und nur die Formulierung ausgelagert wird, ist der Mittelweg, den viele unterschätzen.
Die Entscheidung fällt nicht nach Gefühl, sondern nach der Frage, welche Daten tatsächlich in den Kontext geraten. Wer nur öffentliche Produktdokumentation anbindet, braucht kein eigenes Rechenzentrum.
Der häufigste Fehler ist, alles auf einmal zu wollen. Der zweithäufigste ist, mit dem Handbuch anzufangen, das niemand liest. Beide führen zu einem System, das beeindruckt und nicht benutzt wird.
Sinnvoller ist der umgekehrte Weg. Sucht eine Frage, die bei euch mehrmals pro Woche gestellt und jedes Mal von Hand beantwortet wird. Schaut nach, wo die Antwort steht, und ob diese Quelle gepflegt ist. Klärt, wer sie sehen darf. Und baut dann genau dafür einen Abruf, mit Quellenangabe, für eine überschaubare Gruppe. Wenn das nach vier Wochen benutzt wird, habt ihr einen Fall, an dem ihr alles Weitere messen könnt. Wenn nicht, habt ihr wenig verloren und viel gelernt.
Der Aufwand liegt fast nie in der Anbindung. Er liegt davor: in der Frage, welche Quelle gilt, wer sie sehen darf und wer sie aktuell hält. Genau diese drei Fragen sind es, die eine KI gnadenlos sichtbar macht, weil sie die Lücken nicht überspielt, sondern selbstbewusst falsch beantwortet.
Wenn ihr wissen wollt, welcher der vier Wege zu eurem Fall passt und was vorher aufgeräumt gehört: vereinbart ein unverbindliches Erstgespräch. Wir sehen uns an, wo eure Daten liegen und womit ein erster Schritt realistisch ist.