Warum die Daten, nicht das Modell, der Engpass sind
Das Modell ist zunehmend eine Ware von der Stange. Sie rufen eine API auf oder betreiben ein offenes Modell auf eigener Hardware; so oder so kommt die Intelligenz fertig aus dem Regal und wird ohne Ihr Zutun besser. Was nicht von der Stange kommt, sind Ihre Daten — ihre Form, ihr Zustand und die Frage, ob das System im Bedarfsfall das richtige Stück findet. Jedes ernsthafte KI-Projekt, das ich ausgeliefert habe, hat mehr Aufwand darauf verwendet, Daten in einen brauchbaren Zustand zu bringen, als auf alles Modellbezogene — und das mit deutlichem Abstand.
Wenn ein Projekt sich verzögert oder enttäuscht, liegt es fast nie daran, dass das Modell „nicht schlau genug“ war. Es liegt daran, dass das Modell aus Daten antworten sollte, die unvollständig, widersprüchlich, veraltet oder schlicht nicht erreichbar waren. „Müll rein, Müll raus“ ist eine alte Regel, aber ein LLM macht sie schlimmer, nicht besser: Ein Sprachmodell mit schlechten Daten scheitert nicht laut, es scheitert eloquent. Die falsche Antwort kommt selbstsicher, gut formuliert und plausibel daher — und das ist weit gefährlicher als eine Fehlermeldung.
Wo Ihre Unternehmensdaten wirklich liegen
Fragen Sie ein mittelständisches Unternehmen „Haben Sie die Daten dafür?“, ist die ehrliche Antwort meist „Ja — irgendwo.“ Das Problem ist das irgendwo. In einem typischen Mittelstandsbetrieb ist das Wissen, das eine KI bräuchte, verteilt über ein ERP (SAP oder ein Nischensystem der Branche) mit Aufträgen und Stammdaten; über Tausende PDFs — Angebote, Datenblätter, Zertifikate, gescannte Verträge — auf einem Netzlaufwerk, das seit 2015 niemand aufgeräumt hat; über ein Postfach, in dem die Hälfte des Firmenwissens als E-Mail-Verläufe steckt; über ein Ticket- oder CRM-System voller Support-Historie; über ein Confluence- oder SharePoint-Wiki, das zu 40 % veraltet ist; und über eine Handvoll Excel-Dateien, die insgeheim das eigentliche führende System sind.
Nichts davon wurde gebaut, um von einer Maschine gelesen zu werden. Es wurde für Menschen gebaut, die den Kontext bereits kennen — die wissen, dass „die alte Spezifikation“ die Revision von 2018 meint und dass der Preis in diesem Blatt netto ist, nicht brutto. Die Zerstreuung ist das eigentliche Problem, nicht die Menge. Die Daten existieren fast immer. Dass sie in sechs Systemen, in sechs Formaten, hinter sechs Berechtigungsmodellen und ohne gemeinsames Vokabular liegen — das macht es schwer. Ein KI-Projekt ist in der Praxis sehr oft ein Datenintegrationsprojekt mit einem spannenderen Hut auf.
Ein konkretes Beispiel: Ein Maschinenbauer möchte einen Assistenten, der beantwortet „Welches Ersatzteil passt in diese ältere Maschine?“. Die Antwort existiert tatsächlich — verteilt über jahrzehntealte PDF-Ersatzteilkataloge, den Artikelstamm im ERP und die Köpfe von zwei langgedienten Servicetechnikern. Zu einer verlässlichen Antwort zu kommen besteht vielleicht zu 80 % darin, diese drei Quellen zusammenzuführen und abzugleichen, und zu 20 % aus der KI-Schicht obendrauf. Die KI ist die einfachen 20 % — und die beiden Techniker gehen irgendwann in Rente, Grund genug, ihr Wissen jetzt greifbar zu machen.
Daten Schritt für Schritt bereitmachen
Nichts davon erfordert Zauberei. Es erfordert eine geordnete, unglamouröse Abfolge — inventarisieren, bereinigen, strukturieren, berechtigen, aktuell halten — und zwar nur so tief, wie der Anwendungsfall es tatsächlich braucht. Die Abbildung zeigt die Form davon: rohe, verstreute Quellen links, ein System, das eine vertrauenswürdige Antwort abrufen kann, rechts — und dazwischen die ehrliche Arbeit.
Inventarisieren und Zugriff klären — finden, bevor Sie bereinigen
Bevor Sie eine einzige Datei bereinigen, listen Sie auf, was existiert und wer es erreichen kann. Welche Systeme halten relevante Daten, in welchem Format, wie viel davon, wie aktuell — und, die Frage, die die meisten Zeitpläne versenkt: Kommen wir technisch überhaupt daran? Über einen Export, eine API, einen Datenbank-Lesezugriff? Am Zugriff bleiben Projekte leise wochenlang hängen: Die Daten sind da, aber sie sitzen hinter einem Anbieter, der für den Export Geld verlangt, hinter einem Altsystem ohne API oder hinter einer IT-Freigabe, die einen Monat dauert. Machen Sie das früh sichtbar, solange es ein Terminproblem ist und keine Krise. Ein nüchternes einseitiges Inventar — „rund 12.000 PDFs auf dem Netzlaufwerk, ein wöchentlicher SAP-Export, den wir bekommen können, ein CRM mit API, eine Excel-Datei, auf die es ankommt“ — ist mehr wert als jede große Datenstrategie.
Bereinigen, entdoppeln und für den Abruf strukturieren
Dann wird bereinigt — aber nur so viel, wie der Anwendungsfall wirklich braucht. Exakte und Beinahe-Duplikate entfernen (dieselbe Richtlinie in vier Versionen, drei davon veraltet), Textbausteine streichen, kaputte PDF-Textextraktionen reparieren, Navigations-Ballast entfernen. Für alles, was in ein Abrufsystem geht, zählt Struktur mehr als Politur: Dokumente werden in Chunks der richtigen Größe zerlegt — klein genug, um konkret zu sein, groß genug, um ihre Bedeutung zu behalten. Ein 90-seitiges Handbuch, naiv gechunkt, wird zu 90 Seiten kontextloser Fragmente; entlang seiner echten Struktur zerlegt, Abschnitt für Abschnitt mit erhaltenen Überschriften, wird es beantwortbar. Diesen Schritt unterschätzen die meisten, und er entscheidet am unmittelbarsten darüber, ob der Abruf die richtige Passage liefert oder eine plausibel aussehende falsche.
Metadaten, Berechtigungen und das Aktuellhalten
Drei Dinge bringen die Sache zu Ende. Metadaten: Versehen Sie jeden Chunk damit, woher er stammt, wie aktuell er ist und zu welchem Produkt, Standort oder welcher Abteilung er gehört — damit das System filtern, seine Quelle nennen und das Dokument von 2026 dem von 2019 vorziehen kann. Berechtigungen: Das System muss respektieren, wer was sehen darf. Wenn der Vertrieb Margen sehen darf und die Fertigung nicht, muss diese Grenze in der Datenschicht leben und nicht nachträglich angeschraubt werden — der schnellste Weg, ein internes KI-Projekt zu killen, ist, dass es fröhlich eine Gehaltsliste an die falsche Person ausspielt. Und Aktualität: Daten sind keine einmalige Ladung. Preise ändern sich, Dokumente werden ersetzt, neue Tickets kommen herein. Eine Pipeline, die einmal einliest und nie wieder, ist ein System, das jede Woche ein Stück falscher wird. Legen Sie von Anfang an fest, wie es aktuell bleibt — nächtlicher Abgleich, bei Änderung, wöchentlich —, denn „die Updates klären wir später“ ist der Weg, auf dem eine gute Demo zur Belastung verrottet.
Wie „gut genug“ aussieht — und wo Tippel ins Spiel kommt
Gut genug ist nicht perfekt, und dem Perfekten hinterherzujagen ist ein eigener Fehlermodus. Sie brauchen nicht jedes Dokument, nicht jedes ausgefüllte Feld und keine einzige „goldene“ Wahrheitsquelle. Sie brauchen die Daten, die die Fragen abdecken, die dieser Anwendungsfall tatsächlich bekommt — in einem Zustand, mit dem die Abrufschicht arbeiten kann, aktuell genug, um ihnen zu trauen. Abdeckung schlägt Vollständigkeit: Es ist völlig in Ordnung, mit 80 % gut beantworteten Fragen zu starten und für den Rest ehrlich „Das habe ich nicht“ zu sagen — weit besser als ein System, das rät, um Lücken zu füllen. Dieses „Das habe ich nicht“ ist ein Feature, und es hängt ganz an der Datenqualität, denn ein System, das nicht wissen kann, was es nicht weiß, erfindet selbstsicher eine Antwort über jedes Loch hinweg.
Deshalb sind Datenarbeit und Abrufqualität dasselbe Gespräch. In einer RAG-Pipeline kann das Modell nur so gut sein wie das, was der Abruf ihm reicht, und der Abruf nur so gut wie die Daten darunter. Deshalb ist Datenreife auch der größte einzelne Hebel dafür, was ein KI-Projekt kostet und wie lange es dauert: Eine saubere, erreichbare Quelle kann ein paar Wochen bedeuten; eine verstreute, zugriffsgesperrte kann Monate bedeuten. Die Daten sind kein Posten, um den Sie sich am Ende kümmern — sie sind das, was das ganze Budget festlegt.
Genau deshalb schaue ich zuerst darauf. Die Datenfrage ist der unglamouröseste Teil eines KI-Projekts und der Teil, der es am ehesten versenkt — also ist es der Punkt, an dem ich den ersten, harten, ehrlichen Blick verbringe. Der KI-Readiness-Check ist unter anderem dafür da, sie zu beantworten, bevor jemand ein Baubudget bindet: welche Daten Sie haben, in welchem Zustand sie wirklich sind, was es bräuchte, um sie für Ihren geplanten Anwendungsfall auf „gut genug“ zu bringen — und ob das Wochen oder Monate sind, nicht ein vages „kommt darauf an“. Wenn Sie es lieber erst besprechen möchten, nehmen Sie Kontakt auf.