Ein KI-Assistent scheitert im Unternehmen selten am Sprachmodell. Er scheitert daran, dass er auf veraltete Richtlinien, falsche Dokumentversionen oder unvollständige Daten zugreift. Wer eine Praxisguide RAG Architektur planen will, muss deshalb nicht zuerst über Modelle sprechen, sondern über Wissen, Zugriffsrechte und Geschäftsprozesse. Eine RAG-Lösung ist dann wirtschaftlich sinnvoll, wenn sie verlässliche Antworten in einem klar abgegrenzten Anwendungsfall liefert - etwa im Vertrieb, Service, Qualitätsmanagement oder in der internen Beratung.
RAG steht für Retrieval-Augmented Generation. Vereinfacht gesagt sucht das System vor einer Antwort in freigegebenen Unternehmensquellen nach passenden Informationen. Erst dann formuliert das Sprachmodell seine Antwort auf Basis dieser Inhalte. Das reduziert frei erfundene Aussagen und macht Antworten prüfbar. Es ersetzt jedoch keine saubere Datenbasis und keine klare fachliche Verantwortung.
Was eine RAG-Architektur geschäftlich leisten muss
Für den Mittelstand ist RAG keine Wissensdatenbank mit Chatfenster. Richtig geplant, verkürzt sie Suchzeiten, standardisiert wiederkehrende Auskünfte und macht relevantes Wissen an der Stelle verfügbar, an der Mitarbeiter arbeiten. Das kann beispielsweise bedeuten, dass ein Service-Mitarbeiter technische Handbücher und frühere Lösungsfälle durchsucht, ohne mehrere Systeme manuell öffnen zu müssen.
Die Architektur muss dabei vier Anforderungen gleichzeitig erfüllen:
- Sie liefert fachlich belegbare Antworten statt plausibel klingender Texte.
- Sie berücksichtigt Berechtigungen aus den Quellsystemen.
- Sie lässt sich in bestehende Arbeitsabläufe und Anwendungen integrieren.
- Sie bleibt bei neuen Dokumenten, geänderten Prozessen und wachsender Nutzung beherrschbar.
Zwischen diesen Zielen entstehen Zielkonflikte. Eine sehr breite Dokumentenbasis erhöht die theoretische Abdeckung, aber auch das Risiko widersprüchlicher oder irrelevanter Treffer. Sehr strenge Freigaben verbessern die Kontrolle, können aber den Nutzen einschränken. Die richtige Ausgestaltung hängt vom Einsatzfall ab. Ein Assistent für verbindliche Arbeitsanweisungen braucht andere Kontrollmechanismen als eine Recherchehilfe für den Vertrieb.
RAG Architektur planen: Mit dem Prozess beginnen
Der häufigste Planungsfehler ist ein technischer Startpunkt: Dokumente werden in eine Vektordatenbank geladen, danach sucht das Unternehmen nach einem sinnvollen Einsatzgebiet. Besser ist die umgekehrte Reihenfolge. Ausgangspunkt ist ein Prozess mit hoher Informationslast und messbarem Aufwand.
Geeignete Fragen sind konkret: Welche Anfragen wiederholen sich? Wo suchen Mitarbeiter heute in Ordnerstrukturen, E-Mails oder mehreren Fachsystemen? Bei welchen Entscheidungen ist die Antwort bereits dokumentiert, aber nicht schnell auffindbar? Und wo entstehen Fehler, weil Wissen uneinheitlich interpretiert wird?
Ein guter erster Anwendungsfall hat eine klare Nutzergruppe, begrenzte Quellen und einen erkennbaren Qualitätsmaßstab. Beispielsweise kann ein interner Assistent für Angebotsfreigaben auf Produktinformationen, Preisrichtlinien und Vertragsbausteine zugreifen. Sein Erfolg lässt sich an Recherchezeit, Rückfragen, Bearbeitungsdauer und fachlicher Trefferquote messen. Ein allgemeiner Chat über sämtliche Unternehmensdaten ist dagegen kein sinnvoller Pilot, sondern ein offenes Risiko.
Vor der technischen Umsetzung sollte das Unternehmen festlegen, welche Aussagen der Assistent machen darf. Soll er nur Quellen zusammenfassen, Handlungsvorschläge erstellen oder direkt Daten in ein Fachsystem schreiben? Je stärker eine Antwort operative Folgen auslöst, desto höher müssen Prüfung, Berechtigungsmodell und Protokollierung sein.
Die Wissensbasis entscheidet über die Antwortqualität
Eine RAG-Lösung übernimmt nicht automatisch die Wahrheit der hinterlegten Dokumente. Sie macht vorhandenes Wissen lediglich besser auffindbar. Deshalb beginnt die Datenarbeit mit einer Inventur: Welche Systeme enthalten verbindliche Informationen? Welche Dokumente sind aktuell? Wo liegen Dubletten? Wer ist fachlich für Inhalte verantwortlich?
Typische Quellen sind Dokumentenmanagement-Systeme, SharePoint-Bereiche, ERP- und CRM-Daten, Qualitätsdokumente, Handbücher, Ticketsysteme oder strukturierte Produktdaten. Nicht jede Quelle gehört in den ersten Ausbauschritt. Besonders bei personenbezogenen Daten, Vertragsakten oder sensiblen Finanzinformationen ist genau zu prüfen, ob ein Zugriff erforderlich und zulässig ist.
Entscheidend sind Metadaten. Ein Dokument sollte nicht nur als Text vorliegen, sondern etwa mit Dokumenttyp, Version, Fachbereich, Gültigkeitsdatum, Produktbezug und Berechtigungsgruppe versehen sein. Diese Informationen helfen dem System, aktuelle Prozessanweisungen gegenüber alten Dateien zu priorisieren. Sie ermöglichen außerdem, dass Mitarbeiter nur Inhalte sehen, für die sie autorisiert sind.
Auch die Aufteilung von Dokumenten, das sogenannte Chunking, beeinflusst die Qualität erheblich. Zu große Textabschnitte enthalten oft mehrere Themen und führen zu unscharfen Treffern. Zu kleine Abschnitte verlieren ihren Kontext. Eine Arbeitsanweisung, eine Tabelle oder ein Vertragsabschnitt brauchen deshalb häufig unterschiedliche Regeln. Hier lohnt sich fachliche Prüfung mit realen Nutzerfragen statt einer pauschalen Standardkonfiguration.
Retrieval: So findet das System belastbare Quellen
Im Retrieval-Schritt wird die Nutzerfrage in eine Suchanfrage überführt. Vektorsuche findet Inhalte mit ähnlicher Bedeutung, selbst wenn nicht dieselben Worte verwendet werden. Das ist wertvoll bei natürlicher Sprache und unterschiedlichen Fachbegriffen. Allein reicht sie in der Praxis jedoch oft nicht aus.
Bei Artikelnummern, Normen, exakten Produktbezeichnungen oder Vertragsklauseln ist eine klassische Stichwortsuche häufig präziser. Deshalb verbindet eine leistungsfähige Architektur meist semantische Suche und Keyword-Suche. Ein nachgelagerter Reranker bewertet die besten Treffer noch einmal anhand der konkreten Frage und sortiert irrelevante Fundstellen aus.
Die Antwortgenerierung sollte nur mit den tatsächlich gefundenen, freigegebenen Quellen arbeiten. Das Modell erhält eine klare Anweisung: Fehlt eine ausreichende Grundlage, soll es keine Vermutung formulieren, sondern auf die fehlende Information hinweisen. Idealerweise zeigt die Anwendung die verwendeten Dokumentstellen an. So kann der Mitarbeiter die Aussage unmittelbar prüfen, und Fachverantwortliche erkennen schneller, wenn Quellen korrigiert werden müssen.
Ein zentraler Architekturentscheid betrifft die Datenhaltung. Für viele Unternehmen ist eine Kombination aus gesicherter Dokumentenablage, Suchindex und Vektordatenbank sinnvoll. Welche Technologie eingesetzt wird, ist weniger entscheidend als die Frage, ob Datenflüsse, Verschlüsselung, Mandantentrennung, Löschkonzepte und Zugriffe nachvollziehbar umgesetzt sind. Eine technisch elegante Plattform ohne saubere Berechtigungskette ist keine unternehmensfähige Lösung.
Datenschutz und Sicherheit als Teil des Designs
DSGVO-Konformität entsteht nicht durch einen Hinweis im Projektplan. Sie muss in die Architektur übersetzt werden. Dazu zählen Datenklassifizierung, Rollen- und Rechtekonzepte, definierte Speicherorte, Auftragsverarbeitungsverträge, Protokollierung sowie klare Regeln für Löschung und Aktualisierung.
Besondere Aufmerksamkeit verdienen die Übergänge zwischen Systemen. Wenn ein Mitarbeiter eine Frage stellt, welche Daten verlassen das Quellsystem? Welche Inhalte werden an das Sprachmodell übermittelt? Werden Prompts oder Antworten gespeichert? Können Nutzer über geschickte Eingaben versuchen, geschützte Informationen aus anderen Bereichen abzufragen? Diese Fragen betreffen nicht nur IT-Sicherheit, sondern auch das Vertrauen in die Lösung.
Für sensible Unternehmensdaten bieten geschlossene Corporate-LLM-Umgebungen klare Vorteile. Sie erlauben eine kontrollierte Infrastruktur, definierte Datenverarbeitung und eine Integration in vorhandene Identitäts- und Berechtigungssysteme. Trotzdem bleibt die Verantwortung im Unternehmen: Fachbereiche müssen Inhalte freigeben, die IT kontrolliert den Betrieb, und die Geschäftsführung setzt den Rahmen für erlaubte Anwendungsfälle.
Qualität vor breitem Rollout messen
Eine RAG-Lösung sollte nicht nach einer gelungenen Demo bewertet werden. Erforderlich ist ein Testkatalog aus echten Fragen, die den Arbeitsalltag abbilden. Dieser Katalog enthält einfache Standardfragen, mehrdeutige Anfragen, Fragen mit widersprüchlichen Quellen und Fälle, in denen bewusst keine Antwort vorhanden sein sollte.
Bewertet werden mindestens vier Dimensionen: Findet das System die richtige Quelle? Ist die Antwort fachlich korrekt? Bezieht sie sich auf aktuelle und berechtigte Inhalte? Und liefert sie das Ergebnis schnell genug für den jeweiligen Prozess? Eine sehr genaue Antwort nach 30 Sekunden kann für eine komplexe Fachrecherche akzeptabel sein, für den telefonischen Kundenservice jedoch nicht.
Nach dem Start braucht die Lösung einen geregelten Verbesserungsprozess. Fehlende Treffer, Nutzerfeedback und Abbrüche zeigen, wo Dokumente, Metadaten oder Suchlogik nachgeschärft werden müssen. Dabei darf Nutzerfeedback nicht ungeprüft als Wahrheit gelten. Fachverantwortliche sollten regelmäßig prüfen, ob die Korrekturen inhaltlich belastbar sind und keine unerwünschten Effekte erzeugen.
Integration macht aus Recherche operative Wirkung
Der höchste Nutzen entsteht selten in einem isolierten KI-Portal. Mitarbeiter sollten den Assistenten dort nutzen können, wo sie bereits arbeiten: im CRM, Ticketsystem, Intranet oder einer internen Fachanwendung. Eine Integration kann beispielsweise einen Fallkontext automatisch übergeben, passende Wissensquellen auswählen und einen Antwortentwurf direkt im Vorgang bereitstellen.
Nicht jede RAG-Anfrage muss automatisiert weiterverarbeitet werden. Bei sensiblen Vorgängen ist ein Freigabeschritt sinnvoll. Bei standardisierten Fällen kann der Assistent dagegen strukturierte Ergebnisse an einen Workflow übergeben, etwa zur Ticketklassifizierung, Dokumentenerstellung oder Vorprüfung. Der richtige Automatisierungsgrad richtet sich nach Fehlerrisiko, Fallvolumen und Prozessreife.
Eine belastbare RAG-Architektur entsteht nicht durch die größte Modellauswahl, sondern durch klare Entscheidungen über Wissen, Rechte, Qualität und Prozessintegration. Wer klein, messbar und mit einem fachlich verantworteten Anwendungsfall startet, schafft die Grundlage für einen kontrollierten Ausbau. Der nächste sinnvolle Schritt ist daher nicht die Beschaffung eines Chattools, sondern die Auswahl eines Prozesses, in dem verlässliches Wissen heute nachweislich Zeit, Qualität oder Umsatz kostet.