RAG-System im Mittelstand einführen: Use Cases, Datenhoheit und die Fragen vor dem Start

Die Zahlen der Bitkom-Studie zur Digitalisierung der Wirtschaft 2026 sind eindeutig: 41 Prozent der Unternehmen in Deutschland setzen KI ein, nach 17 Prozent im Vorjahr. Interessanter als der Sprung sind allerdings die Hürden, die dieselbe Befragung nennt – 41 Prozent führen Unsicherheit beim Datenschutz an, 37 Prozent unklare Kosten, und ein Drittel berichtet, dass KI teurer wurde als erwartet. Genau an diesen drei Punkten entscheidet sich, ob ein RAG-Projekt im Mittelstand trägt. Was wir dabei übernehmen, steht auf unserer Seite zu RAG und KI-Agenten.

Warum RAG der pragmatische Einstieg ist

Retrieval-Augmented Generation heißt im Kern: Das Sprachmodell antwortet nicht aus seinem Training, sondern aus Ihren Dokumenten – und nennt die Quelle dazu. Damit lösen sich zwei Probleme auf einmal, die den Einstieg sonst blockieren. Halluzinationen werden überprüfbar, weil jede Aussage einen Beleg mitbringt. Und das Modell muss nicht auf Firmendaten trainiert werden, was Aufwand, Kosten und die heikelsten Datenschutzfragen von vornherein vermeidet.

Wie das technisch funktioniert, haben wir an anderer Stelle ausführlich beschrieben – zur Rolle der Vektordatenbanken und zur Kombination mit Wissensgraphen bei GraphRAG. Dieser Beitrag geht die andere Richtung: Was verlangt so ein Projekt organisatorisch, bevor die erste Zeile Code entsteht?

Der Use Case entscheidet, nicht die Technik

Der häufigste Fehler beim Einstieg ist, mit der Technologie zu beginnen statt mit der Frage, welche Frage eigentlich beantwortet werden soll. Ein erster Anwendungsfall taugt, wenn er vier Bedingungen erfüllt:

• Die Frage wiederholt sich. Wenn dieselbe Auskunft mehrmals pro Woche von verschiedenen Leuten gesucht wird, gibt es einen messbaren Nutzen. Einmalige Spezialrecherchen rechtfertigen kein System.
• Die Antwort steht in Dokumenten. RAG findet, was geschrieben wurde. Wissen, das ausschließlich in den Köpfen erfahrener Kolleginnen und Kollegen liegt, kann kein Retrieval heben – das ist ein Dokumentationsprojekt, kein KI-Projekt.
• Ein Fehler ist erkennbar. Wer die Antwort bekommt, muss beurteilen können, ob sie stimmt. Deshalb funktionieren interne Assistenzsysteme für Fachleute deutlich besser als Auskunftssysteme für Laien.
• Es gibt einen Verantwortlichen. Jemand aus der Fachabteilung muss entscheiden, welche Dokumente gelten und welche veraltet sind. Ohne diese Rolle veraltet der Wissensbestand schneller, als das System Nutzen stiftet.

Typische Kandidaten, die diese Kriterien erfüllen: Service- und Wartungsdokumentation, Angebots- und Vertragsvorlagen, interne Richtlinien und Arbeitsanweisungen, technische Normen. Der Klassiker „ein Chatbot für alles“ erfüllt keine einzige davon.

Was seit dem 2. August 2026 zusätzlich gilt

Hier lohnt der genaue Blick, weil die Schlagzeilen in beide Richtungen in die Irre führen. Seit dem 2. August 2026 greifen die Transparenzpflichten nach Artikel 50 der EU-KI-Verordnung: Wer mit einem KI-System interagiert, muss das erkennen können, und KI-generierte Inhalte müssen gekennzeichnet werden. Die Pflichten für Hochrisiko-Systeme wurden dagegen durch den Digital Omnibus (Verordnung (EU) 2026/1744, in Kraft seit dem 27. Juli 2026) nach hinten geschoben – eigenständige Hochrisiko-Systeme nach Anhang III auf den 2. Dezember 2027, KI als Sicherheitskomponente in Produkten nach Anhang I auf den 2. August 2028.

Für einen internen Wissensassistenten heißt das: Ein System, das Servicetechnikern die passende Wartungsanweisung heraussucht, ist ohnehin in aller Regel kein Hochrisiko-System. Die Transparenzpflicht gilt trotzdem, ebenso die Pflicht aus Artikel 4, die eigenen Mitarbeitenden im Umgang mit KI zu befähigen.

Anders sieht es aus, sobald Personalentscheidungen berührt werden. Bewerbervorauswahl, Leistungsbewertung und Kreditwürdigkeitsprüfungen zählen ausdrücklich zu den Hochrisiko-Anwendungen nach Anhang III – mit Konformitätsbewertung, Qualitätsmanagementsystem und dokumentierter menschlicher Aufsicht. Verschoben wurde dabei der Stichtag, nicht die Substanz: Wer heute ein RAG-System auf Personalakten ansetzt, legt mit Architektur, Protokollierung und Datenherkunft bereits fest, ob die Konformitätsbewertung später eine Formalie oder ein Reengineering-Projekt wird. Was am 2. August tatsächlich in Kraft getreten ist und was nicht, haben wir in einem eigenen Beitrag zum EU AI Act aufgeschlüsselt; die Einordnung für Ihr Unternehmen fasst unsere Seite zur KI-Governance zusammen.

Die Frage ist nicht, ob ein RAG-System reguliert ist, sondern welche Dokumente es lesen darf. Diese Antwort steht meist schon im Berechtigungskonzept – sie muss nur ins System übernommen werden.

Datenhoheit ist mehr als der Hosting-Ort

Wenn 41 Prozent der Unternehmen Datenschutzunsicherheit als Hürde nennen, meinen sie meist die Frage, wohin die Daten fließen. Die lässt sich sauber beantworten: Ein RAG-System kann vollständig in der eigenen Infrastruktur oder in einem privaten Deployment laufen, ohne dass ein Dokument nach außen geht.

Die schwierigere Frage stellt kaum jemand vorab – und sie ist die, an der Projekte im Betrieb auffliegen: Ein RAG-System darf das bestehende Berechtigungskonzept nicht aushebeln. Wird ein Dokumentenbestand ohne Rücksicht auf Zugriffsrechte indexiert, kann anschließend jeder Nutzer über eine geschickt gestellte Frage an Inhalte kommen, die er im Dateisystem nie hätte öffnen dürfen. Gehaltslisten, Kündigungsentwürfe, Angebotskalkulationen – alles, was in einem Ordner liegt, den das System lesen darf. Die Berechtigungen müssen deshalb bis in die Suchergebnisse durchgereicht werden, nicht erst in der Oberfläche gefiltert.

Woran RAG-Projekte scheitern

Neben dem Berechtigungsthema wiederholen sich drei Muster. Erstens die Dokumentenqualität: Zehn Versionen desselben Handbuchs in einem Ordner führen dazu, dass das System zuverlässig die falsche zitiert – ohne Ordnung im Bestand hilft keine Technik. Zweitens die fehlende Messung. Ob ein System besser wird, lässt sich nur beurteilen, wenn Retrieval und Antwortqualität getrennt bewertet werden; wie das geht, steht in unserem Beitrag zur Evaluierung von RAG-Systemen. Und drittens die Erwartungshaltung: Ein System, das mit fünfzig kuratierten Dokumenten hervorragend funktioniert, wird nicht automatisch besser, wenn man fünftausend ungeprüfte hinzufügt. Es wird schlechter.

Vom Proof of Concept zum Betrieb

Der Weg, der sich bewährt hat, ist unspektakulär. Am Anfang steht ein eng geschnittener Anwendungsfall mit einem überschaubaren, aber echten Dokumentenbestand und einer festen Gruppe von Testnutzern aus der Fachabteilung. Dieser Proof of Concept beantwortet die einzige Frage, die zu diesem Zeitpunkt zählt: Sind die Antworten gut genug, dass die Leute das System freiwillig benutzen? Erst danach folgen Anbindung an die Quellsysteme, Berechtigungslogik, Betriebsprozesse und die Ausweitung auf weitere Bestände.

Zu den Kosten: Belastbare Zahlen entstehen erst, wenn drei Dinge feststehen – der Zustand und die Menge der Dokumente, die Zahl der anzubindenden Quellsysteme und die Frage, ob On-Premise betrieben wird oder in einer verwalteten Umgebung. Wer vor dieser Klärung eine Pauschale nennt, kalkuliert die Unsicherheit ein, und zwar zu Ihren Lasten. Der PoC hat unter anderem den Zweck, aus Schätzungen Zahlen zu machen.

Fazit

RAG ist im Mittelstand deshalb der sinnvolle Einstieg in KI, weil es ohne Training auf eigenen Daten auskommt, Antworten belegbar macht und vollständig im eigenen Haus laufen kann. Die Schwierigkeiten liegen selten im Modell, sondern in der Vorarbeit: ein Anwendungsfall, der die vier Kriterien erfüllt, ein geordneter Dokumentenbestand, ein sauber durchgereichtes Berechtigungskonzept und eine Messgröße für Qualität. Wenn Sie einschätzen wollen, ob und mit welchem Anwendungsfall ein Einstieg bei Ihnen trägt, sprechen Sie uns an – ein Erstgespräch kostet nichts außer einer Stunde Zeit.

Weiterführende Quellen

• Bitkom Research – Digitalisierung der Wirtschaft 2026
• Europäische Kommission – Regulatory framework on Artificial Intelligence
• EUR-Lex – Verordnung (EU) 2026/1744 (Digital Omnibus on AI)

Hinweis: Dieser Beitrag gibt den öffentlich berichteten Stand wieder und ersetzt keine individuelle Rechtsberatung. Wie ein konkretes System einzuordnen ist, sollte im Einzelfall geprüft werden.