Die Modellwahl ist der Teil, über den alle streiten, und der Teil, der am wenigsten zählt. Die Lücke zwischen einem KI-Programm, das funktioniert, und einem, das stockt, liegt fast immer im Zustand der darunterliegenden Daten – und diese Lücke lässt sich diagnostizieren, bevor Sie eine einzige Zeile Code schreiben.

Zu Beginn jeder KI-Initiative im Unternehmen läuft ein vorhersehbares Ritual ab: wochenlange Debatten darüber, welches Modell man verwenden soll. Es ist die falsche Debatte. Die Modelle liegen in ihren Fähigkeiten nahe genug beieinander, dass die Wahl selten über das Ergebnis entscheidet, und sie werden alle paar Monate besser, egal welches Sie wählen. Was über das Ergebnis entscheidet, ist, ob Ihre Daten in einem Zustand sind, den die KI tatsächlich nutzen kann – und genau dort verliert ein Projekt meist still und leise sechs Monate, die es nie budgetiert hatte.

Wir haben gut finanzierte KI-Programme scheitern sehen, nicht weil das Modell falsch war, sondern weil das benötigte Wissen in inkonsistenten PDFs lag, in einem CRM voller Freitext und in drei Systemen, die sich über denselben Kunden uneinig waren. Data Readiness ist die Voraussetzung, für die niemand zuständig sein will – und diejenige, die alles Nachgelagerte bestimmt.

Das eigentliche Problem: KI legt Datenschulden offen, die Sie seit Jahren mitschleppen

Ihre Organisation häuft seit einem Jahrzehnt Datenschulden an – doppelte Datensätze, fehlende Felder, undokumentierte Bedeutungen, widersprüchliche Sources of Truth – und kommt damit durch, weil Menschen die Lücken überbrücken. Eine Person, die einen unordentlichen Datensatz liest, erschliesst sich, was gemeint ist. Ein KI-System erschliesst sich Ihr Stammeswissen nicht; es nimmt die Daten für bare Münze und produziert aus fehlerhaftem Input selbstbewussten Output. Die KI erzeugt das Datenproblem nicht. Sie entfernt den menschlichen Puffer, der es verborgen hat.

Deshalb enttäuscht «Lassen wir doch einfach ein LLM auf unsere Dokumente los» so oft. Die Dokumente widersprechen sich, die neueste Version ist unklar, und die Hälfte des institutionellen Wissens wurde nie aufgeschrieben. Das Modell spiegelt das Chaos getreu wider.

Ein Reifegradmodell für Data Readiness

Bevor Sie sich auf einen KI-Use-Case festlegen, verorten Sie die relevanten Daten auf fünf Stufen. Der Use Case kann nur so gut sein wie die schwächste Stufe, von der er abhängt.

1. Zugänglich. Können Sie die Daten programmatisch herausholen, oder sind sie in einem System ohne API gefangen, in gescannten Bildern oder im Posteingang von jemandem? Wenn Sie sie nicht zuverlässig abrufen können, spielt alles andere keine Rolle.
2. Ausreichend strukturiert. Liegen sie in einer Form vor, welche die KI verarbeiten kann – sauberer Text, parsebare Tabellen, konsistente Formate –, oder herrscht Freitext-Chaos mit zerstückelten Tabellen? Die meisten Unternehmensdaten stehen hier und brauchen Arbeit.
3. Korrekt und aktuell. Sind sie richtig und auf dem neuesten Stand, mit einer klar erkennbaren aktuellen Version? Eine KI, die auf veralteten oder doppelten Daten fusst, liegt selbstbewusst falsch.
4. Bedeutungsklar (dokumentiert). Sind Feldbedeutungen, Codes und Sonderfälle dokumentiert, oder braucht es einen altgedienten Mitarbeitenden, um «Status = 7» zu interpretieren? Undokumentierte Semantik wird zu KI-Fehlern.
5. Governed. Kennen Sie Herkunft, Sensitivität und zulässige Verwendungen? Das ist sowohl für Qualität als auch für Compliance nötig – und damit das Retrieval Zugriffsrechte respektieren kann.

Ein Use Case, der auf Daten beruht, die zugänglich und strukturiert, aber weder aktuell noch dokumentiert sind, ist ein Use Case, der in der Demo glänzt und in der Produktion scheitert. Diagnostizieren Sie das zuerst, und Sie werden Ihre Roadmap zugunsten jener Use Cases neu priorisieren, deren Daten tatsächlich bereit sind.

Praxisbeispiel: eine Roadmap nach Data Readiness sequenzieren

Ein Industrieunternehmen wollte drei KI-Fähigkeiten und beabsichtigte, mit der strategisch wichtigsten zu beginnen: einem Assistenten über seiner Engineering-Wissensdatenbank. Wir haben zuerst jede davon am Reifegradmodell gemessen.

• Engineering-Assistent – Daten zugänglich, aber 40 % der Dokumente waren gescannte Zeichnungen, die Versionen waren unklar und die Feldsemantik undokumentiert. Readiness: tief. Geschätzt 4–5 Monate Datenarbeit, bevor KI-Nutzen möglich ist.
• Triage von Lieferanten-E-Mails – strukturiert, aktuell, gut verstanden. Readiness: hoch. KI-Nutzen in rund 6 Wochen.
• Zusammenfassung von Qualitätsberichten – strukturiert und aktuell, einige Dokumentationslücken. Readiness: mittel.

Wir haben neu sequenziert: zuerst die Lieferanten-Triage ausliefern (ein schneller, sichtbarer Erfolg, der Glaubwürdigkeit einbrachte), parallel die Qualitätszusammenfassung umsetzen und die Datenbereinigung der Engineering-Basis als eigenen, finanzierten Arbeitsstrang starten, statt die 5-Monats-Lücke mitten im Projekt zu entdecken. Der strategische Use Case kam trotzdem – aber mit einem realistischen Zeitplan, bei dem die Datenarbeit benannt und budgetiert war, statt das Projekt aus dem Hinterhalt zu überfallen.

Die Lehre, welche die Geschäftsleitung daraus zog: Data Readiness sollte die Reihenfolge stärker bestimmen als strategische Ambition. Mit dem wichtigsten Use Case auf den am wenigsten bereiten Daten zu beginnen, ist der Weg, wie Programme ihr erstes Jahr und die Geduld ihres Sponsors verlieren.

RAG rettet schlechte Daten nicht – es verstärkt sie

Eine gefährliche Annahme hat sich festgesetzt: dass Retrieval-Augmented Generation Datenarbeit überflüssig macht, weil das Modell Ihre Dokumente ja einfach zur Abfragezeit liest. Das Gegenteil ist der Fall. RAG macht Datenqualität noch folgenreicher, denn die Antworten des Systems sind nur so gut wie die Dokumente, die es abruft, und es hat keine Möglichkeit zu wissen, dass Dokument A die überholte Version ist und Dokument B die aktuelle. Richten Sie RAG auf einen Ordner, in dem drei Versionen einer Richtlinie nebeneinander existieren, und es wird selbstbewusst jene zitieren, die der Retriever am höchsten gerankt hat – und das ist genauso wahrscheinlich die veraltete. Das Modell entscheidet nicht über Wahrheit; es fördert Text zutage.

Deshalb enttäuscht «Wir machen einfach RAG über SharePoint» so zuverlässig. Der Korpus enthält Duplikate, Entwürfe, Widersprüche und verwaiste Seiten, durch die ein Mensch navigiert, weil er weiss, welcher Quelle er trauen kann. RAG hat kein solches Urteilsvermögen. Bevor man einem Retrieval-System vertrauen kann, muss jemand festlegen, welche Quellen massgebend sind, die veralteten ausmustern oder in Quarantäne stellen und die Versionierung explizit machen, damit der Index aktuelle Inhalte bevorzugen kann. Diese Kuratierung ist Datenarbeit – und genau die Arbeit, die Teams mit RAG überspringen zu können hoffen. Das werden sie nicht.

Die praktische Konsequenz für die Reihenfolge: Ein RAG-Use-Case ist nur so bereit, wie sein Korpus kuratiert ist, und die Kuratierung des Korpus bleibt meist unsichtbar, bis Sie die Retrieval-Qualität gegen ein echtes Fragen-Set messen. Wir stellen regelmässig fest, dass die entscheidende Aufgabe bei einem Wissensassistenten nicht der Bau des Assistenten ist – das dauert ein paar Wochen –, sondern den zugrunde liegenden Dokumentenbestand in einen Zustand zu bringen, in dem «der relevanteste Chunk» auch «der korrekte Chunk» ist. Budgetieren Sie das explizit, und ein RAG-Projekt wird planbar; gehen Sie davon aus, dass das Modell es schon richtet, und das Projekt bleibt auf demselben Genauigkeitsplateau in den hohen Siebzigern stecken, das nichts mit dem Modell und alles mit den Daten darunter zu tun hat.

Was Sie zuerst beheben sollten

• Zugang vor allem anderen. Wenn Sie die Daten nicht zuverlässig herausholen können, lösen Sie das zuerst; keine noch so hohe Modellqualität gleicht das aus.
• Dokumentieren Sie die Semantik der Daten, die Ihr Use Case berührt. Sie müssen nicht den ganzen Bestand dokumentieren – nur das, was die KI verarbeiten wird. Das hat enorme Hebelwirkung und wird routinemässig übersprungen.
• Legen Sie eine Source of Truth fest. Wo Systeme sich widersprechen, entscheiden Sie, welches gewinnt, bevor die KI es tun muss.
• Beheben Sie Strukturprobleme wo möglich an der Quelle. Eine einmalige Parsing-Pipeline hilft; die Ursache zu beheben, warum die Daten unstrukturiert sind, hilft für immer.

Entscheidungs-Checkliste

1. Wo stehen die Daten für diesen Use Case auf dem fünfstufigen Reifegradmodell?
2. Welches ist die schwächste Stufe, und wie lange dauert es, sie anzuheben, bevor KI-Nutzen möglich ist?
3. Können wir die Daten heute programmatisch und zuverlässig abrufen?
4. Gibt es eine klare, aktuelle Source of Truth, oder widersprechen sich die Systeme?
5. Sind Feldbedeutungen und Sonderfälle für das dokumentiert, was die KI verarbeiten wird?
6. Haben wir die Roadmap nach Data Readiness sequenziert und nicht nur nach strategischer Priorität?
7. Ist die nötige Datenbereinigung ein benannter, finanzierter Arbeitsstrang – und keine versteckte Annahme?

Die gridz-Sicht

Das Wertvollste, was wir zu Beginn eines KI-Mandats tun, ist oft unspektakulär: die Daten bewerten, nicht die Modelle. Das ordnet Roadmaps neu, bringt die versteckten Monate ans Licht und verwandelt «Warum dauert das so lange?» in einen Plan, dem alle von Anfang an zugestimmt haben. Wählen Sie für den ersten Erfolg den Use Case, dessen Daten bereit sind, finanzieren Sie die Datenarbeit für den strategischen Use Case explizit, und lassen Sie sich von der Modelldebatte nicht länger von dem ablenken, was tatsächlich über das Ergebnis entscheidet. Wir beurteilen die Data Readiness, bevor ein einziger Prompt geschrieben wird – denn das Modell ist der einfache Teil, und bei den Daten werden Projekte gewonnen oder verloren. Wenn Sie das für Ihre nächste Initiative klären möchten, sprechen Sie uns an.

Bevor Ihre nächste KI-Initiative bei der Debatte um die Modellwahl ankommt, bewerten Sie die konkreten Daten, von denen sie abhängt, anhand der fünf Stufen und seien Sie ehrlich bei der schwächsten. Diese eine Stunde Assessment sagt Ihnen, ob Sie sechs Wochen oder sechs Monate vom Nutzen entfernt sind, mit welchem Use Case Sie beginnen sollten und welche Datenarbeit Sie explizit finanzieren müssen, statt sie auf halbem Weg zu entdecken. Es ist die unspektakulärste Folie im Deck und diejenige, die ein KI-Programm am zuverlässigsten davor bewahrt, sein erstes Jahr – und das Vertrauen seines Sponsors – an ein Datenproblem zu verlieren, das niemand eingeplant hatte.