Was braucht „ChatGPT für die Firma“ wirklich?

Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage:

Wer beruflich irgendetwas mit IT macht, kennt wahrscheinlich die Frage: „Kannst du mir kurz mit meinem Drucker helfen?“ Bei KI geht es mir inzwischen ähnlich. Ich benutze Modelle in der IDE, im Chatfenster und für Reviews. Viele Einzelteile verstehe ich gut genug, um sie vermutlich auch selbst bauen zu können. Aber auf die beiläufige Frage „Was brauchen wir eigentlich, um ChatGPT in unserer Firma einzusetzen?“ hätte ich trotzdem keine beiläufige Antwort.

Denn eine Komponente zu installieren ist das eine. Ein System so zu betreiben, dass viele Menschen verlässlich damit arbeiten können, ist etwas anderes.

Meine Frage:

Was braucht „ChatGPT für die Firma“ wirklich?

Hier ist die Antwort von ChatGPT:

Die kurze Antwort lautet: Man beginnt nicht mit RAG, einer Vektordatenbank oder einem Architekturdiagramm. Man beginnt mit der Arbeit, die jemand damit erledigen soll.

„ChatGPT für die Firma“ kann nämlich mindestens vier Dinge bedeuten:

• ein fertiges Chatprodukt für allgemeine Assistenz;
• eine eigene Oberfläche vor einem Sprachmodell;
• eine Suche oder Frage-Antwort-Anwendung über Unternehmensdokumente;
• eine Fachanwendung, in der ein Modell einen einzelnen Arbeitsschritt übernimmt.

Diese Systeme können ähnlich aussehen und technisch fast nichts miteinander gemeinsam haben. Der Chat ist nur eine mögliche Oberfläche. Das Modell ist nur eine Komponente. Der Unternehmensdienst ist das Ganze darum herum.

Der kleinste brauchbare Kern

Nehmen wir einen sehr kleinen Anwendungsfall. Ein Formular soll aus einer groben Notiz eine freundliche Kundenmail machen. Die Notiz wird übertragen, das Modell antwortet, das Ergebnis wird angezeigt. Dafür braucht man keinen Gesprächsverlauf, keine Dokumentensuche, keine Embeddings und keine Vektordatenbank. Vielleicht braucht man nicht einmal einen eigenen Chat.

Ganz ohne Architektur geht es trotzdem nicht. Jemand muss entscheiden, welche Daten an den Modellanbieter gehen dürfen. Der Zugangsschlüssel muss sicher aufbewahrt werden. Der Aufruf braucht ein Zeitlimit und einen verständlichen Fehlerpfad. Es muss klar sein, ob Eingaben gespeichert oder protokolliert werden. Und jemand muss merken, wenn Qualität, Kosten oder Verfügbarkeit kippen.

Das ist der kleinste gemeinsame Kern, den ich aus den Quellen ableite:

1. eine klar begrenzte Aufgabe;
2. ein kontrollierter Modellzugang;
3. Anwendungscode, der Eingabe, Ausgabe und Fehler behandelt;
4. bewusste Daten- und Sicherheitsgrenzen;
5. eine überprüfbare Betriebsentscheidung.

Alles Weitere muss ein konkretes Problem lösen. Sonst baut man Architektur aus Gewohnheit.

„Unser Wissen“ sind mehrere Probleme

Sobald jemand sagt, die KI müsse „unser Unternehmenswissen kennen“, wird die Sache interessanter. Dieser Satz kann sehr verschiedene Informationsarten meinen.

Wer eine bestimmte Richtlinie, Produktnummer oder Vertragsvorlage sucht, braucht vielleicht klassische Volltextsuche. Sie findet exakte Begriffe gut und kann einfach einen Link zum Original liefern. Wer denselben Sachverhalt in anderen Worten beschreibt, profitiert möglicherweise von semantischer Suche: Textstellen werden als Zahlenvektoren repräsentiert und nach inhaltlicher Nähe gesucht. PostgreSQL dokumentiert Volltextsuche; die Erweiterung pgvector ergänzt Vektorsuche und beschreibt auch die Kombination beider Signale.¹

Diese Kombination heißt meist Hybrid Search. Sie ist eine Strategie, kein Standard. Auch für die Zusammenführung der beiden Trefferlisten gibt es mehrere Methoden. Ob die Kombination besser ist, muss am eigenen Korpus und an echten Fragen gemessen werden.

RAG kommt erst einen Schritt später. Retrieval-Augmented Generation bedeutet im Kern: Zuerst werden passende externe Informationen gesucht, dann erhält das Modell diese Informationen als Kontext für seine Antwort. Der ursprüngliche RAG-Beitrag beschreibt genau diese Verbindung von Retrieval und Generierung.² Er schreibt nicht vor, dass das Retrieval zwingend mit Embeddings oder in einer besonderen Vektordatenbank stattfinden muss. Lexikalische Suche kann ebenfalls Kontext für eine generierte Antwort liefern.

Und manchmal ist auch RAG das falsche Werkzeug. Ein aktueller Lagerbestand gehört nicht als gelegentlich aktualisierte Textpassage in einen Index. Das Modell sollte ihn über eine Fach-API abfragen. Soll es ein Ticket anlegen oder einen Urlaubsvorgang starten, braucht es einen kontrollierten Tool-Aufruf. Die Provider-Dokumentation beschreibt dafür eine klare Arbeitsteilung: Das Modell schlägt einen Aufruf mit strukturierten Argumenten vor; die Anwendung validiert ihn, prüft Berechtigungen und führt ihn aus.³

Die hilfreiche Rückfrage lautet deshalb nicht „Welche Vektordatenbank nehmen wir?“, sondern:

Fehlt dem Modell Dokumenttext, ein exakter Fund, ein aktueller strukturierter Zustand – oder die Möglichkeit, etwas zu tun?

Erst dann kann man zwischen Suche, semantischem Retrieval, RAG, SQL und Tool/API sinnvoll wählen.

RAG ist keine Einkaufsliste

Rund um RAG werden Begriffe gern zu einer festen Lieferkette zusammengeschoben: Dokumente laden, in 500-Token-Stücke schneiden, Embeddings berechnen, Vektordatenbank anschließen, fertig.

Das kann ein brauchbarer Prototyp sein. Ein Standard ist es nicht.

Schon die passende Einheit hängt vom Material ab. Ein Gesetz, eine Tabelle, ein Handbuch und ein Supportticket haben andere Strukturen. Anbieter können automatisches Chunking und Standardwerte übernehmen, dokumentieren diese aber als Konfiguration ihrer Dienste.⁴ Die Qualität muss mit den eigenen Dokumenten und Fragen geprüft werden. Forschung zu RAG-Evaluation misst deshalb getrennt, ob der gefundene Kontext relevant ist und ob die Antwort tatsächlich darauf gestützt ist.⁵

Auch Fine-Tuning löst ein anderes Problem. Es kann Verhalten, Format oder die Leistung bei einer eng umrissenen Aufgabe an gute Beispiele anpassen. Für Wissen, das häufig geändert, gezielt gelöscht und mit einer Fundstelle belegt werden soll, ist es kein guter Standardersatz für Suche oder Tools.⁶ Die absolute Aussage „Fine-Tuning speichert kein Wissen“ wäre trotzdem falsch. Die saubere Unterscheidung ist praktischer: Geht es um gewünschtes Verhalten – oder um einen veränderlichen Informationsbestand?

Das schwierige Stück beginnt nach dem Upload

Ein Dokument in einen Index zu bekommen, ist heute erstaunlich einfach. Es dort verantwortlich zu betreiben, ist es nicht.

Eine brauchbare Wissenskette sieht eher so aus:

Quelle → Import → Version → Extraktion → Metadaten → Rechte → Suchindex → Fundstelle → Modellkontext → Antwort

Daneben laufen weniger fotogene Wege:

• Ein Dokument ändert sich und muss neu verarbeitet werden.
• Ein Mitarbeiter wechselt die Abteilung und seine Rechte ändern sich.
• Eine Quelle wird gelöscht und soll auch aus Index, Cache und Ableitungen verschwinden.
• Ein Parser scheitert an einzelnen Dateien, ohne dass der gesamte Import rot wird.
• Ein neues Embedding-Modell oder eine neue Chunking-Regel verlangt einen reproduzierbaren Neuaufbau.

Diese Kette ist meine Synthese aus den untersuchten Komponenten, kein externer Standard. Gerade deshalb ist sie wichtig: Die einzelnen Produkte zeigen jeweils nur einen Ausschnitt.

Wer eine fertige Plattform oder einen verwalteten Retrieval-Dienst kauft, kann viel davon abgeben. Dann sollte die Einkaufsfrage jedoch nicht nur „Unterstützt ihr PDF?“ lauten. Interessanter sind Löschung, Rechte-Synchronisation, fehlgeschlagene Importe, Versionen, Export und Wiederaufbau. Ein verwalteter Dienst verschiebt die Betriebsarbeit. Er entfernt nicht die Verantwortung dafür, was in den Wissensraum hinein darf.

Berechtigungen folgen den Informationen, nicht der Kopfzahl

Identität wird in Gesprächen über Unternehmens-KI oft mit drei Buchstaben erledigt: SSO. Technisch sind mehrere Dinge zu trennen.

OpenID Connect authentifiziert einen Menschen und transportiert Angaben über seine Identität.⁷ SCIM ist ein IETF-Standards-Track-Protokoll, mit dem Accounts und Gruppen zwischen Systemen provisioniert und verwaltet werden können.⁸ Beide entscheiden noch nicht, ob dieser Mensch die Gehaltsliste, den Betriebsratsordner oder nur das öffentliche Handbuch lesen darf. Das ist Autorisierung – etwa über Rollen, Attribute, ACLs oder andere Regeln.

Die wichtigste Regel ist unabhängig vom gewählten Modell:

Nur Information, die ein Mensch sehen darf, darf als Kontext beim Modell landen.

Microsoft beschreibt Document-Level Access für Suchindizes als Filterung anhand von Identitäten oder Berechtigungsmetadaten.⁹ Das Problem stammt also nicht erst aus der generativen KI. Enterprise Search musste Dokumentrechte schon vorher beachten.

Die Generierung verschärft allerdings die Folgen eines Fehlers. Ein unberechtigter Treffer kann nicht nur als Suchresultat auftauchen. Er kann in eine flüssige Antwort einfließen, mit erlaubten Informationen vermischt werden und später kaum noch als Fremdkörper erkennbar sein. OWASP nennt bei Vektor- und Embedding-Systemen unter anderem unberechtigten Zugriff, Informationsabfluss zwischen Mandanten, Embedding-Inversion und vergiftete Wissensbestände.¹⁰

Ob Rechte in den Index kopiert oder bei jeder Anfrage im Quellsystem geprüft werden, ist eine Abwägung. Kopierte Rechte machen Retrieval schnell, können aber veralten. Live-Prüfung ist aktueller, erhöht jedoch Latenz und Abhängigkeit. Getrennte Datenräume können stark isolieren, erhöhen aber den Betriebsaufwand. Wichtig ist nicht, überall „ACL“ anzukreuzen. Wichtig ist ein definierter Vertrag: Woher kommt das Recht, wann wird eine Änderung wirksam und was passiert bei einem Fehler?

Deshalb kann ein System für 15 Personen mit Personalakten anspruchsvoller sein als eines für 2.000 Menschen, die ausschließlich öffentliche Handbücher durchsuchen. Berechtigungen sind keine Enterprise-Zutat, die erst ab einer bestimmten Mitarbeiterzahl dazukommt.

Ein Quellenlink ist noch keine Provenance

Viele Systeme können unter einer Antwort Dateinamen oder Links anzeigen. Das ist nützlich. Es beantwortet aber noch nicht alle Fragen, die das Wort „Quelle“ verspricht.

Hat das System genau diese Passage verwendet? Aus welcher Dokumentversion stammt sie? Welche Extraktion und welcher Indexstand lagen dazwischen? Gibt die generierte Aussage den Fund überhaupt korrekt wieder?

Für echte Nachvollziehbarkeit muss die Anwendung Beziehungen zwischen Antwort, Kontextpassage, Fundstelle, Dokumentversion, Original und Verarbeitung erhalten. W3C PROV-DM bietet dafür ein allgemeines Vokabular: Entitäten, Aktivitäten, verantwortliche Akteure sowie Ableitungs- und Revisionsbeziehungen.¹¹ Das ist keine fertige RAG-Datenstruktur. Aber es zeigt, dass Provenance mehr ist als ein hübscher Fußnotenlink.

Die praktische Konsequenz muss nicht sofort ein formales PROV-System sein. Sie kann klein beginnen: stabile Dokument- und Versions-IDs, gespeicherte Fundstellen, reproduzierbare Verarbeitung und ein Link zum Original. Nur sollte man eine Modellfußnote nicht mit einem Beweis verwechseln.

Provider-Abstraktion ist kein Ausweg aus dem Lock-in

Eine eigene Schnittstelle zwischen Anwendung und Modellanbieter ist sinnvoll. Sie hält API-Schlüssel, Request-Formate und Providerwechsel aus dem restlichen System heraus. Provider dokumentieren allerdings unterschiedliche Zustands-, Tool-, Aufbewahrungs- und Limitmodelle.¹²

Sie macht Modelle aber nicht beliebig austauschbar.

Sobald eine Anwendung providergebundene Funktionen nutzt – etwa spezielle Tool-Aufrufe, strukturierte Ausgaben, Caching oder bestimmte Retrieval-Funktionen – wächst die Bindung wieder. Und selbst bei identischer Schnittstelle können sich Modelle bei Qualität, Latenz und Verhalten deutlich unterscheiden.

Die Abstraktion löst deshalb nicht den Lock-in. Sie macht sichtbar, wo er entsteht.

Die wichtigere Frage lautet nicht: Können wir morgen den Provider wechseln?

Sondern: Welche Teile unseres Systems wollen wir bewusst von einem Anbieter abhängig machen?

Was bereits beim kleinen System Betrieb ist

Die unspektakulären Regeln sind oft die wertvollsten. Zugangsdaten und andere Secrets gehören weder in Quellcode noch in Logzeilen. OWASP empfiehlt eine zentrale, kontrollierte Secret-Verwaltung und Rotation.¹³ Aufrufe nach außen brauchen Zeitlimits und eine begrenzte Zahl von Wiederholungsversuchen. Bei Anbieterlimits ist nicht jeder sofortige Wiederholungsversuch hilfreich; Provider empfehlen Wiederholungen mit wachsendem Abstand und eine Planung gegen definierte Quoten.¹⁴

Logs brauchen Korrelation, Fehlerklassen und genug Kontext für eine Diagnose. Sie brauchen nicht automatisch den vollständigen Prompt, jedes gefundene Dokument und jede Antwort. OpenTelemetry standardisiert, wie Logeinträge transportiert und korreliert werden können.¹⁵ Es entscheidet nicht, welche sensiblen Inhalte eine Firma vervielfältigen darf. Technische Beobachtbarkeit ist keine Erlaubnis zum Mitschreiben.

Sobald Zustand gespeichert wird, entstehen weitere Fragen: Wie lange? Wer kann löschen? Was ist der autoritative Bestand? Lässt sich die Datenbank wiederherstellen? Reicht bei einem Suchindex ein reproduzierbarer Neuaufbau oder braucht er ein Backup? Die PostgreSQL-Dokumentation trennt logische und physische Backupverfahren; die richtige Wahl hängt davon ab, welchen Zustand man tatsächlich erhalten muss.¹⁶

Auch das ist Betrieb – schon bevor der tausendste Mensch einen Account bekommt.

Was sich bei 1.000 Menschen wirklich ändert

Tausend Menschen sind keine Lastangabe. Vielleicht öffnen 40 von ihnen das Werkzeug einmal pro Woche. Vielleicht lassen 200 Personen gleichzeitig große Dokumentpakete auswerten. Vielleicht hängt ein kritischer Kundenprozess daran. Diese drei Fälle haben dieselbe Zahl von Konten und fast keine gemeinsame Betriebsarchitektur.

Für die Planung werden deshalb andere Zahlen wichtig:

• aktive und gleichzeitig aktive Nutzer;
• Anfragen pro Zeit und Größe der Kontexte;
• Importvolumen und Änderungsrate der Quellen;
• Providerquoten, Wartezeiten und Kosten pro Arbeitsablauf;
• gewünschte Verfügbarkeit und akzeptable Einschränkungen im Störungsfall;
• Supportaufkommen, Rolloutgeschwindigkeit und Missbrauchsfälle.

Aus diesen Messwerten folgen Warteschlangen, Lastbegrenzung, Kapazität, Budgets und vielleicht Hochverfügbarkeit. Nicht aus der runden Zahl 1.000. Auch Kubernetes ist keine automatische Antwort. Ein verwalteter Dienst kann die technische Skalierung übernehmen; eine einfache Anwendung kann auf wenigen Instanzen laufen; ein kleiner, aber kritischer Dienst kann sehr hohe Verfügbarkeit benötigen.

Mit der Reichweite wächst außerdem die organisatorische Fläche. Wer besitzt den Dienst? Wer entscheidet bei Qualitätsproblemen? Wer beantwortet Nutzerfragen? Wer stoppt einen fehlerhaften Datenkonnektor? Wer kommuniziert einen Störungsfall? NIST ordnet Governance, Messung und Risikobehandlung über den gesamten Lebenszyklus ein und betont, dass nicht jede vorgeschlagene Maßnahme für jeden Akteur passt.¹⁷ Governance beginnt damit nicht erst bei 1.000 Menschen. Bei 1.000 wird nur sichtbarer, wenn sie vorher niemand übernommen hat.

Kaufen oder bauen ist die falsche Zweiteilung

Für viele Firmen ist ein fertiger Unternehmensdienst der vernünftigste Start. Oberfläche, Modellzugang, Administration und möglicherweise Suche oder Datenkonnektoren kommen aus einer Hand. Das spart Plattformbau. Es bindet das Unternehmen aber an Datenmodell, Funktionsgrenzen, Preise und Exportmöglichkeiten des Produkts.

Dazwischen liegen viele Mischformen: eine selbst hostbare Oberfläche, verwaltete Modell- und Suchdienste, gekaufte Parser, ein bestehender Identitätsdienst, eine eigene Fachanwendung oder eine eigene Retrieval- und Rechte-Logik. „Eigenbau“ kann bedeuten, fünf Standarddienste bewusst zu verbinden – nicht, ein Sprachmodell zu trainieren.

Die bessere Frage pro Schicht lautet:

Welche Fähigkeit kaufen wir ein, und welche Verantwortung bleibt danach bei uns?

Auch beim vollständig gekauften Dienst bleiben mindestens Problemwahl, Datenfreigabe, Rechte, Zielqualität, Nutzerbetrieb, Umgang mit Störungen sowie Ausstieg und Datenexport beim Unternehmen. Beim Eigenbau kommen Patches, Skalierung, Rufbereitschaft und Lebenszyklus der Komponenten dazu.

Die Antwort für das nächste Gespräch

Gibt es also einen belastbaren Blueprint für „ChatGPT in der Firma“?

Für einzelne Bausteine ja. OIDC und SCIM lösen definierte Aufgaben rund um Identität. Suchmaschinen, relationale Datenbanken und Vektorindizes liefern bekannte Mechaniken. RAG, Tool-Aufrufe und Evaluation sind dokumentierte Muster und Methoden. Verwaltete Produkte können große Teile davon übernehmen.

In den untersuchten Primärquellen habe ich aber keine universelle Gesamtarchitektur gefunden, die für jede Firma und jeden Anwendungsfall gilt. Das ist kein Beweis, dass niemand irgendwo eine solche Zeichnung veröffentlicht hat. Es ist ein Hinweis darauf, dass die gemeinsame Ebene woanders liegt.

Mein Ergebnis ist deshalb kein Komponentenbild, sondern eine Folge von Rückfragen:

1. Welche Arbeit soll am Dienstagmorgen leichter werden?
2. Welche Information fehlt dafür – und wer darf sie sehen?
3. Wie aktuell, löschbar und nachvollziehbar muss sie sein?
4. Welchen Fehler können wir akzeptieren, und wie würden wir ihn bemerken?
5. Welche Fähigkeit kaufen wir, welche integrieren wir und welche betreiben wir dauerhaft?

Wer diese Fragen beantworten kann, muss keinen Suchindex an ein Whiteboard malen. Er kann aber erkennen, welche Entscheidung in einem Anbieter- oder Architekturgespräch gerade tatsächlich getroffen wird.

Vielleicht ist das die unspektakuläre Antwort: Die Bausteine kann man kaufen oder installieren. Verantworten muss man ihre Übergänge.