Warum RAG-Projekte bei den Daten beginnen: 7 Fragen vor dem ersten Pilot

Bei RAG-Projekten beginnt das Gespräch oft sehr technisch: Welches Sprachmodell nehmen wir? Wie groß sollen die Textabschnitte sein? Welche Datenbank brauchen wir?

Das sind berechtigte Fragen. Nur kommen sie meistens zu früh. Denn auch die beste KI kann keine verlässliche Antwort geben, wenn sie mit alten, widersprüchlichen oder unvollständigen Informationen arbeitet.

RAG lässt sich einfach erklären: Stellen wir uns eine sehr schnelle Assistenz vor. Bevor sie antwortet, sucht sie in den freigegebenen Unterlagen des Unternehmens nach passenden Informationen. Findet sie dort die richtige und aktuelle Arbeitsanweisung, kann sie gut helfen. Findet sie drei unterschiedliche Versionen ohne Datum, wird die Antwort zum Glücksspiel.

Ein guter RAG-Pilot beginnt für mich deshalb mit drei einfachen Fragen: Was soll das System beantworten? Wo liegt die richtige Information? Und wer kann sagen, ob die Antwort stimmt?

Genau hier wird es in Unternehmen oft spannend. Wissen liegt selten ordentlich an einem Ort. Ein Teil steckt in SharePoint, ein Teil im Netzlaufwerk, vieles in E-Mails und manches nur in den Köpfen einzelner Mitarbeiter. Das ist völlig normal. Man muss es nur wissen, bevor man mit dem Aufbau beginnt.

Auch Untersuchungen zur Datenqualität in RAG-Systemen zeigen: Probleme entstehen oft schon beim Einlesen und Aufbereiten der Inhalte und ziehen sich dann durch das ganze System. Die Technik am Ende zu optimieren, löst diese Ursache nicht. Hier geht es zur Studie.

„Wir möchten unser Wissen mit KI nutzen“ klingt gut, ist aber noch zu allgemein. Besser wäre zum Beispiel: Der Kundenservice soll innerhalb weniger Sekunden die aktuell gültige Garantierichtlinie finden. Oder: Projektleiter sollen Anforderungen aus mehreren Handbüchern vergleichen können.

Je konkreter die Aufgabe, desto einfacher lässt sich später prüfen, ob das System wirklich hilft.

Hier lohnt sich eine ehrliche Liste: SharePoint, Netzlaufwerke, CRM, Ticketsystem, E-Mails, Wiki oder eine Fachsoftware. Danach wird geklärt, welche Quelle verbindlich ist. Ein freigegebenes Handbuch hat schließlich einen anderen Stellenwert als eine zwei Jahre alte E-Mail.

Für wichtige Inhalte braucht es eine verantwortliche Person oder Abteilung. Nehmen wir eine interne Reisekostenregelung: Die Buchhaltung muss sagen können, welche Version gilt und welche Antwort korrekt wäre. Ohne diese fachliche Prüfung kann die Technik nur vermuten.

Ein Dateiname wie „Richtlinie_neu_final_v2“ hilft weder Menschen noch einer KI besonders viel. Dokumente brauchen zumindest ein Datum, einen Status und eine klare Zuordnung. Sonst kann das System eine alte Regel finden, obwohl längst eine neue gilt.

Ein internes KI-System darf keine Hintertür zu vertraulichen Daten werden. Wenn Mitarbeiter heute keinen Zugriff auf Personalakten oder sensible Projektdaten haben, dürfen diese Informationen auch nicht über eine KI-Antwort sichtbar werden.

Doppelte Dateien, schlecht lesbare Scans, unterschiedliche Begriffe für dieselbe Sache oder riesige Sammeldokumente sind typische Beispiele. Nicht alles muss vor dem Pilot perfekt aufgeräumt sein. Aber bekannte Probleme gehören auf den Tisch, damit die Erwartungen realistisch bleiben.

Ein paar spontane Fragen in einer Präsentation reichen nicht. Sinnvoller ist eine Liste aus dem Arbeitsalltag: echte Fragen, die erwartete Antwort und die gültige Quelle dazu. Das System sollte außerdem klar sagen können, wenn es keine verlässliche Antwort findet.

„Pilotfähig“ heißt nicht, dass im ganzen Unternehmen bereits perfekte Ordnung herrschen muss. Es reicht, einen sinnvollen Bereich sauber abzugrenzen und dort kontrolliert zu lernen.

1. Aufgabe festlegen: Wer soll wobei konkret unterstützt werden?
2. Datenkanäle erfassen: Wo liegen wichtige, ergänzende und vertrauliche Informationen?
3. Quellen prüfen: Was ist aktuell, wer darf es sehen und wer ist dafür verantwortlich?
4. Echte Testfragen sammeln: Welche Antworten werden im Alltag wirklich gebraucht?
5. Klein starten: Ein klar begrenzter Bereich liefert mehr Erkenntnisse als ein riesiger Pilot mit allem gleichzeitig.

Auch das NIST AI Risk Management Framework stellt Verantwortlichkeiten, Risikobewertung und laufende Messung in den Mittelpunkt. Praktisch übersetzt bedeutet das: Quellen, Rechte und Qualitätskontrolle gehören von Anfang an zur Lösung und nicht erst später in einen Ordner mit Dokumentation.

Datenaufbereitung ist nicht die lästige Vorbereitung vor dem eigentlichen KI-Projekt. Sie ist ein wesentlicher Teil davon. Hier entscheidet sich, welche Fragen beantwortet werden können, wer die Antworten sehen darf und ob das System auch in einem Jahr noch verlässlich arbeitet.

Eine strukturierte Daten- & KI-Readiness-Analyse schafft dafür einen verständlichen Überblick: Wo stehen wir, welche Daten können wir sinnvoll nutzen und womit sollten wir beginnen? So wird zuerst das Fundament geklärt, bevor unnötig Geld in Technik fließt.

• Data Quality Challenges in Retrieval-Augmented Generation
• NIST AI Risk Management Framework