Wie man Unternehmensdaten für AI und RAG vorbereitet

Unternehmen, die zu schnell einen firmeneigenen AI-Assistenten eingeführt haben, berichten oft über dasselbe Problem: Das Modell antwortet unpräzise oder zitiert veraltete Verfahren von vor zwei Jahren. Die Ursache ist selten ein schlechtes Modell. Die Ursache ist eine ungeordnete Eingabedatenbank. Bevor das gewählte LLM Zugang zum Unternehmenswissen erhält, muss dieses Wissen ordnungsgemäß bereinigt, aufgeteilt und indexiert werden. Das ist Arbeit vor der Implementierung, nicht danach.

RAG funktioniert nach einem einfachen Prinzip: Wenn ein Nutzer eine Frage stellt, durchsucht das System Fragmente Ihres Wissens, die semantisch passen, und gibt sie dem Modell als Kontext für die Antwortformulierung. Das Modell erfindet keine Inhalte – es antwortet ausschließlich basierend auf dem, was es im Index findet.

Die Konsequenz ist direkt: Wenn im Index widersprüchliche Informationen stehen (z. B. zwei Varianten desselben Verfahrens, von denen eine veraltet ist), kann das Modell jede davon zitieren, abhängig davon, welches Fragment im Ranking höher landet. Wenn ein Dokument ein gescannter PDF ohne Textschicht ist, sieht das Modell es überhaupt nicht. Wenn Tabellen mit Preisen in Excel-Dateien sind, die nicht in Text umgewandelt wurden, kann der Assistent keine Werte aus diesen Tabellen liefern.

Eine gute Datenvorbereitung löst diese Probleme, bevor das Modell überhaupt gestartet wird. Das ist eine einmalige Investition mit langfristigem Horizont: Ein indexierter, sauberer Wissensspeicher funktioniert über Jahre mit regelmäßigen Aktualisierungen.

Bevor man mit der Bereinigung beginnt, muss man wissen, was man hat. Ein typisches Daten-Audit für AI beantwortet fünf Fragen:

1. Welche Formate? DOCX, PDF, Excel/Sheets-Tabellen, Seiten in Confluence/Notion, E-Mails, CRM-Gesprächsprotokolle, FAQ-Datenbank. Jedes Format erfordert einen anderen Parser.
2. Wie aktuell? Dokumente älter als 12–18 Monate müssen überprüft werden. Veraltete Verfahren im Index sind eine Quelle für falsche Antworten.
3. Welcher Zugriffsumfang? Einige Dokumente sind vertraulich (Verträge, HR-Daten). Sie sollten nicht in einen für alle Nutzer zugänglichen Index gelangen – oder müssen in einer separaten Sammlung mit Zugriffskontrolle indexiert werden.
4. Gibt es Duplikate? Dasselbe Regelwerk in fünf Versionen, von denen drei veraltet sind, ist keine Wissensbasis – das ist Rauschen.
5. Enthalten die Daten personenbezogene Informationen? Dokumente mit PII erfordern entweder eine Anonymisierung vor der Indexierung oder ausschließlich lokale Speicherung mit entsprechender Rechtsgrundlage nach RODO.

Das Ergebnis des Audits ist eine Liste der Quellen mit Bewertung: indexieren / nach Bereinigung indexieren / ausschließen / in separater Sammlung mit ACL indexieren.

Die RAG-Engine benötigt sauberen Text. Keine PDF-Datei, kein Bild – Text. Parsing ist die Umwandlung jedes Quellformats in flachen oder hierarchischen Text mit Metadaten.

Typische Herausforderungen:

• Gescanntes PDF ohne OCR – ohne Textschicht sind es Bilder. Sie erfordern OCR vor der Indexierung. Die Qualität des OCR beeinflusst direkt die Qualität der Suche.
• PDF mit mehrspaltigem Layout – ein naiver Parser liest Spalten horizontal statt vertikal und erzeugt unleserliche Wortfolgen. Ein layout-aware Parser ist erforderlich.
• Tabellen in PDF oder Word – die meisten Parser verlieren die Tabellenstruktur. Tabellen mit numerischen Daten (Preise, technische Parameter, Zeitpläne) erfordern einen separaten Extraktionspfad zu Markdown oder JSON.
• Excel-Tabellen – jedes Blatt und jeder Datenbereich ist ein separates Fragment. Der Kontext der Spaltenüberschriften muss erhalten bleiben, sonst verlieren die Werte ihre Bedeutung.
• Confluence/Notion-Seiten per API – diese geben normalerweise HTML oder JSON mit reicher Struktur zurück. Überschriften H2/H3 müssen als Hierarchiesignale beim Chunking erhalten bleiben.

Am Ende wird jedes Dokument zu einer Sammlung von Absätzen oder Abschnitten mit Metadaten: Dokumententitel, Datum, Abteilung, Kategorie, Quellformat.

Chunking ist einer der wichtigsten Schritte, der den größten Einfluss auf die Treffergenauigkeit der Suche hat. Eine schlechte Chunking-Strategie kann eine Implementierung mit perfekten Dokumenten ruinieren.

Grundlegende Prinzipien:

• Fragmentgröße 256–512 Token für die meisten Anwendungen. Zu kurze Fragmente (50 Token) verlieren den Kontext. Zu lange (2000 Token) füllen das Kontextfenster des Modells mit einem Dokument und lassen keinen Platz für andere.
• Überlappung (Overlap) von 10–20% zwischen benachbarten Fragmenten erhält die semantische Kontinuität an der Aufteilungsgrenze. Ohne Überlappung verliert der Satz „Fortsetzung des vorherigen Punktes“ seinen vorherigen Punkt.
• Respektiere semantische Grenzen – teile bei Überschriften H2/H3, Absätzen, Listeneinträgen. Eine Aufteilung mitten im Satz ergibt immer ein schlechteres Ergebnis als eine Aufteilung bei einer Überschrift.
• Jedes Fragment trägt Metadaten – Dokumententitel, Abschnittsüberschrift, Datum, Kategorie. Bei der hybriden Suche ermöglichen Filter nach Metadaten die Eingrenzung der Ergebnisse auf eine bestimmte Abteilung oder ein Datum.

Sonderfall: Prozessdokumente Schritt für Schritt. Hier ist das optimale Chunk ein einzelner Schritt mit vollem Kontext des Verfahrens in den Metadaten. Ein Schritt ohne Kontext, der besagt, dass es sich um Schritt 3 von 7 des Reklamationsverfahrens handelt, ist isoliert nutzlos.

Jedes Fragment muss in ein Embedding umgewandelt werden – einen Zahlenvektor, der die Bedeutung des Textes repräsentiert. Dieser Vektor gelangt in die Vektordatenbank und bildet die Grundlage für die semantische Suche.

Wichtige Entscheidungen in dieser Phase:

Auswahl des Embedding-Modells. Wir verwenden BGE-M3, das lokal über Ollama ausgeführt wird. Es unterstützt die polnische Sprache ohne Übersetzung, erzeugt 1024-dimensionale Vektoren und läuft auf der CPU des firmeneigenen Servers. Kein Inhalt verlässt die Infrastruktur während der Indexierung. Bei öffentlichen Inhalten ohne sensible Daten sind auch cloudbasierte Embedding-Modelle akzeptabel, sofern PII zuvor maskiert wurde.

Inkrementelle Indexierung. Die erste Indexierung der gesamten Datenbank kann je nach Volumen Minuten bis Stunden dauern. Jede Aktualisierung eines Dokuments sollte nur die geänderten Fragmente neu indexieren – nicht den gesamten Korpus.

Versionierung. Eine Änderung des Embedding-Modells erfordert eine vollständige Neuindexierung der gesamten Datenbank. Das ist bei der Planung wichtig: Wähle ein Modell langfristig, da die Migration reale Kosten verursacht.

Die Vorbereitung von Daten für AI ist gleichzeitig eine Übung im Datenschutz. Jede Phase der Pipeline ist ein potenzieller Punkt für Datenlecks.

Verpflichtungen bei personenbezogenen Daten:

• Rechtsgrundlage für die Verarbeitung von Daten zu AI-Zwecken muss existieren, bevor die Daten in den Index gelangen. Einwilligung oder berechtigtes Interesse für den jeweiligen Anwendungsfall.
• Minimierung – indexiere nur die für den Zweck des Assistenten notwendigen Daten. Eine vollständige CRM-Datenbank mit Kundenhistorie sollte nicht in einen Assistenten gelangen, der Fragen zu internen Verfahren beantwortet.
• Maskierung von PII – bevor Fragmente an ein externes generatives Modell gesendet werden, erkennen und maskieren wir automatisch personenbezogene Daten: Namen, Telefonnummern, PESEL, E-Mail-Adressen.
• Data Residency und Self-Hosting – bei Daten, die dem Berufsgeheimnis unterliegen (Recht, Medizin, Finanzen) oder sensiblen HR-Daten sollte die gesamte Pipeline (Embeddings, Vektordatenbank, generatives Modell) lokal betrieben werden.
• Recht auf Löschung – wenn RODO die Löschung von Personendaten verlangt, müssen deren Dokumente aus dem Index verschwinden. Die Pipeline sollte selektives Löschen von Fragmenten aus der Vektordatenbank unterstützen.

Für Projekte in den Bereichen HR, Mitarbeiterbewertung oder Finanzen – Bereiche mit hohem Risiko gemäß AI Act – ist eine DPIA (Datenschutz-Folgenabschätzung) vor der Implementierung erforderlich. Details im Artikel AI Act und RODO 2026.

Die Datenvorbereitung ist kein einmaliges Projekt. Die Wissensbasis lebt: Dokumente ändern sich, Prozesse entwickeln sich, neue Produkte kommen auf den Markt.

Gute Praktiken für die Wartung:

• Versionierung von Dokumenten mit Gültigkeitsdatum. Jedes Chunk trägt Metadaten mit dem Dokumentendatum. Das System kann Fragmente, die älter als X Monate sind, depriorisieren oder eine manuelle Bestätigung der Aktualität erfordern.
• Pipeline für automatische Reindexierung. Eine Änderung einer Datei im Wissensrepository (Confluence, SharePoint) löst eine automatische Neuberechnung der betroffenen Fragmente aus. Nicht einmal im Monat – bei jeder Änderung.
• Überwachung der Antwortqualität. Wenn der Assistent häufiger als üblich mit „Ich weiß es nicht“ antwortet, ist das ein Signal, dass die Datenbank aktualisiert werden muss – nicht, dass das Modell defekt ist.
• Thematische Lücken. Observability-Tools verfolgen Fragen, auf die RAG kein Fragment findet. Das ist eine Liste von Themen, die in der Wissensbasis ergänzt werden müssen.

Zyklus: indexieren → Fragen ohne Antworten sammeln → Wissensbasis ergänzen → reindexieren. Nach einigen Iterationen deckt der Assistent den Großteil der tatsächlichen Nutzerfragen ab.

Zeit und Kosten hängen vor allem vom Zustand der Eingangsdaten ab. Saubere, strukturierte Dokumente (Word, Confluence, gut formatierte PDFs) verkürzen das Projekt um ein Vielfaches im Vergleich zu Datenbanken voller Scans und ungeordneten Tabellen.

Die Infrastrukturkosten bei lokalem Hosting bestehen hauptsächlich aus Server und Implementierungszeit. Cloud-basierte Embeddings kosten einige Cent pro Million Token. Bewerten Sie Ihr eigenes Projekt mit dem ROI-Rechner oder nutzen Sie die AI-Readiness-Bewertung, die unter anderem den Zustand Ihrer Wissensbasis bewertet.

Ein vollständiges Projektangebot erstellen wir nach einem Daten-Audit. Schreiben Sie über das Kontaktformular.

Dieser Sandbox führt dieselbe Pipeline aus wie unsere Implementierungen: Fügen Sie einen Ausschnitt Ihrer Wissensbasis ein, und das Modell antwortet ausschließlich basierend auf dem eingegebenen Text. PII wird vor dem Modell maskiert, keine Speicherung.

Beginnen Sie mit einem Audit: Listen Sie alle Systeme auf, in denen das Unternehmenswissen gespeichert ist (SharePoint, Confluence, E-Mails, CRM, Shared Drive), bewerten Sie die Aktualität und das Format jeder Sammlung. Wählen Sie einen thematischen Bereich mit relativ sauberen Daten, z. B. FAQ für den Kundenservice oder Onboarding-Verfahren für Mitarbeiter, und führen Sie einen Pilot für diesen Ausschnitt durch. Es ist besser, einen Assistenten mit 200 guten Dokumenten zu starten als mit 2000 chaotischen. Mehr zum schrittweisen Ansatz im Artikel Wo anfangen mit der AI-Implementierung.

Nein. Bei einem lokalen Embedding-Modell (z. B. BGE-M3 über Ollama) und einer lokalen Vektordatenbank (Qdrant on-prem) läuft die gesamte Indexierungspipeline in Ihrer Infrastruktur. An ein externes generatives Modell werden nur die Abfrage und einige ausgewählte Kontextfragmente gesendet, nach automatischer Maskierung von PII. Sensible HR-, Rechts- und Finanzdaten können wir durch Self-Hosting des gesamten generativen Modells abdecken.

Löschen Sie sie nicht sofort, wenn Sie nicht sicher sind, welche Versionen aktuell sind. Markieren Sie sie stattdessen mit einem Datum und depriorisieren Sie sie im Ranking durch Metadaten: Fragmente, die älter als 18 Monate sind, erhalten bei Gleichstand eine niedrigere Bewertung, und der Assistent kann den Nutzer informieren, dass das Dokument aus einer älteren Version des Verfahrens stammt. Die systematische Bereinigung der Wissensbasis ist ein Projekt für sich, das sich mehrfach auszahlt, da es nicht nur die AI, sondern auch die Suche für Mitarbeiter verbessert.

Das hängt davon ab, wie oft sich die Wissensbasis ändert. Bei aktiv aktualisierten Verfahren ist eine inkrementelle Pipeline optimal, die durch eine Dokumentenänderung ausgelöst wird (Webhook von Confluence oder SharePoint zur Indexierungs-Engine). Bei stabileren Datenbanken reicht ein regelmäßiges wöchentliches oder monatliches Scannen mit automatischer Erkennung von Änderungen durch Prüfsummen. Fehlende Indexaktualisierungen bei sich ändernden Dokumenten sind die häufigste Ursache für die Verschlechterung der Assistentenqualität nach einigen Monaten.

Ja, in jedem Szenario. Selbst fertige RAG-Plattformen (SaaS) erfordern, dass Dokumente maschinenlesbar, aktuell und logisch aufgeteilt sind. Der Unterschied besteht darin, dass fertige SaaS-Tools eine eigene Oberfläche zum Hochladen und Verwalten von Dokumenten bieten, aber die Qualität des Chunkings und der Datenstruktur weiterhin von Ihnen abhängt. Bei sensiblen Daten oder großem Volumen bietet eine eigene Infrastruktur volle Kontrolle darüber, was und wo verarbeitet wird. Ein Vergleich der Ansätze im Artikel Eigener AI-Assistent oder fertig.