Datenstrategie für KI – was einen Piloten tatsächlich in die Produktion bringt

Zentrale Erkenntnisse

• Eine Datenstrategie für KI unterscheidet sich von einem BI-Datenplan. Sie plant für Trainingsdaten, Drift, Datenherkunft und On-Premise-Anforderungen, nicht nur für Dashboards.
• In einem tatsächlichen ML-Projekt beansprucht die Datenaufbereitung 50–65 % des Aufwands. Die Modellierung liegt bei 10–15 %. Wenn Ihre Roadmap dieses Verhältnis umkehrt, ist die Roadmap falsch.
• Semantische Konsistenz (eine Definition von „Umsatz“, „aktivem Nutzer“, „Abwanderung“) ist wichtiger als die Wahl des Algorithmus.
• On-Premise- und lokale LLM-Setups lösen tatsächliche DSGVO- und EU-AI-Act-Anforderungen, sind aber im Betrieb teurer. Das ist ein Abwägen, kein kostenloser Gewinn.
• Beginnen Sie mit dem einfachsten Modell, das funktionieren könnte. Manchmal ist SQL die Antwort, und das offen auszusprechen gehört zum Handwerk.

Was eine Datenstrategie für KI tatsächlich bedeutet

Eine Datenstrategie für KI plant den gesamten Lebenszyklus der Daten, aus denen ein Modell lernt, mit denen es arbeitet und gegen die es an Genauigkeit verliert. Sie ist kein Data-Warehouse-Plan. Eine traditionelle Datenstrategie beantwortet historische Fragen: Was wurde im letzten Quartal verkauft, wo sind die Kosten aus dem Ruder gelaufen. Eine KI-orientierte Datenstrategie beantwortet eine andere Frage: Kann dieser Datensatz ein Modell tragen, das morgen eine Entscheidung trifft und noch in sechs Monaten, wenn sich die Welt verschoben hat?

Konkret umfasst dieser Lebenszyklus fünf Aspekte:

• Erhebung. Welche Daten benötigt dieser spezifische Anwendungsfall, nicht welche Daten sind bequem verfügbar.
• Governance. Wer besitzt jedes Feld, wer darf darauf zugreifen und auf welcher rechtlichen Grundlage (DSGVO, FERPA für Bildungsdaten, branchenspezifische Regelungen im Gesundheitswesen).
• Qualität an der Quelle. Validierungsregeln dort, wo Daten in das System eintreten. Bereinigung im Warehouse ist der teure Weg.
• Architektur. Pipelines, die Training, Batch-Inferenz und, wo nötig, latenzarme Bereitstellung unterstützen.
• Semantik. Eine Definition pro Geschäftsbegriff über Abteilungen hinweg. „Umsatz“ im Vertrieb und „Umsatz“ im Finanzwesen müssen übereinstimmen, sonst erbt das Modell den Widerspruch.

Der Vorteil dieser Herangehensweise ist, dass das Modell zum einfachen Teil wird. Der Nachteil ist ehrlich: Es kostet zu Beginn mehr und erzwingt Gespräche zwischen Abteilungen, die die meisten Organisationen seit Jahren vermieden haben. Lohnenswert, aber nicht kostenlos.

Häufige Datenprobleme, die KI im großen Maßstab blockieren

Die meisten KI-Piloten scheitern aus vier Gründen, und drei davon betreffen Daten. Die Harvard Business Review verfolgt dasselbe Muster über Branchen hinweg. Nachfolgend das, was wir bei Silk Data auf der Engineering-Seite am häufigsten sehen.

1. Silos. Kundendaten im Marketing, Transaktionen in der Finanzabteilung, Betriebsdaten in einem separaten ERP. Das Modell sieht nur Fragmente. Ein Join zur Abfragezeit ist langsam. Ein Join weiter oben in der Pipeline erfordert Governance, die die meisten Teams noch nicht aufgebaut haben.
2. Klassenungleichgewicht und Datenvolumen. Betrugserkennung ist das klassische Beispiel. Betrügerische Transaktionen machen üblicherweise 0,05–0,3 % des Volumens aus, und die operativen Kosten von Falschalarmen sind fast so hoch wie die Kosten übersehener Fälle. Der Reflex ist, auf Resampling-Techniken wie SMOTE oder Klassengewichtung zu setzen. Diese helfen, aber nur innerhalb eines Modells. Die strukturelle Lösung liegt weiter oben: mehr Transaktionshistorie, mehr Verhaltensmerkmale pro Kunde und längere Zeitfenster, die saisonale Muster erfassen. Ein Modell, das auf sechs Wochen Zahlungsdaten trainiert wurde, wird Betrugsmuster übersehen, die sich über sechs Monate herausbilden.
3. Qualität an der Quelle. In unserer Arbeit an prädiktiver Analytik für große Tierhaltungsbetriebe fanden wir Datensätze mit Tieren, die mehrere Dutzend Tonnen wogen. Ein defekter Sensor oder ein fehlerhaftes Formularfeld, über Jahre von Datensätzen fortgepflanzt. Kein Algorithmus behebt das. Validierung bei der Eingabe schon.
4. Semantische Drift zwischen Teams. Derselbe Feldname bedeutet für verschiedene Teams unterschiedliche Dinge. Trainieren Sie ein Modell auf der Vereinigung, wird das Ergebnis konsistent falsch sein, auf eine Weise, die schwer zu diagnostizieren ist.

Das Gegenargument ist erwähnenswert. Nicht jedes Problem erfordert eine Datenüberholung, bevor irgendwelche KI-Arbeiten beginnen. Manchmal ist ein enger PoC auf einem sauberen Datenausschnitt der richtige Weg, um zu lernen, wie die vollständige Datenstrategie aussehen sollte. Der Fehler ist, von diesem PoC in die Produktion zu springen, ohne die Strategiearbeit dazwischen zu leisten.

Was eine KI-fähige Datenstrategie tatsächlich enthält

Eine funktionierende Strategie besteht aus vier operativen Bausteinen. Jeder hat seine Kosten und seinen Nutzen. Die folgende Tabelle fasst zusammen, was jeder Baustein leistet, was er kostet und wo er sich auszahlt.

Eine Anmerkung zur Reihenfolge. Governance und Semantik fühlen sich oft wie Overhead an. Sie sind die Bausteine, die sich am spätesten auszahlen. Aber wer sie überspringt, erzeugt Modelle, die im Demo funktionieren und im vierten Monat auseinanderbrechen. Wir haben genügend solcher Fälle nachgebaut, um zu empfehlen, die unspektakuläre Arbeit zuerst zu erledigen.

Ein praktischer Mechanismus, der es wert ist, benannt zu werden. Die Disziplin, die „Qualität an der Quelle“ in modernen Datenplattformen operationalisiert, ist der Datenvertrag: eine formale Vereinbarung zwischen dem datenerzeugenden und dem datenverbrauchenden System, die Schema, Semantik, Aktualität und Qualitätsgrenzen festlegt und mit automatisierter Validierung durchsetzt, welche die Pipeline unterbricht, sobald sie verletzt wird. Anders als beim klassischen ETL lebt der Vertrag zwischen Produzent und Konsument statt in der Bereinigungsschicht des Konsumenten. Der Produzent wird auf den Vertrag verpflichtet, nicht das Datenteam, das nachträglich Korrekturen einbaut. Für KI-Workloads, bei denen die Integrität der Trainingsdaten direkt die Modellqualität bestimmt, ist dies das architektonische Muster, das verhindert, dass „Müll rein“ zu „Modell raus“ wird, bevor es jemand bemerkt.

Ein zweiter Mechanismus, der speziell für KI relevant ist: der Feature Store. Sobald ein Modell ein Feature verwendet (etwa „durchschnittlicher Transaktionswert der letzten 30 Tage“), werden andere Modelle dasselbe Feature nutzen wollen. Ohne Feature Store berechnet jedes Team es geringfügig anders, und die resultierenden Modellergebnisse stimmen nicht überein. Mit einem Feature Store (Feast, Tecton oder Eigenentwicklung) wird das Feature einmal definiert, einmal berechnet und von jedem Modell konsumiert. Das wird spätestens beim dritten oder vierten ausgelieferten Modell essenziell. Vorher ist es Over-Engineering.

Wohin der Aufwand in einem KI-Projekt tatsächlich fließt

Wenn Sie sich nur eine Aufschlüsselung aus diesem Artikel merken, dann diese. In den KI-Projekten, die wir durchführen, verteilt sich der Aufwand ungefähr wie folgt:

• Metrikdefinition: ~10 %
• Datenaufbereitung: 50–65 %
• Modellierung: 10–15 %
• Bereitstellung und Integration: 10–15 %
• Überwachung: kontinuierlich, nie abgeschlossen

Anbieter, die das Gegenteil versprechen – 60 % für „fortschrittliche Modelle“, 10 % für Daten – unterschätzen entweder die Datenarbeit oder verschleiern sie. Wir sagen das direkt. Wir haben zu viele Projekte übernommen, in denen jemand anderes dieses Versprechen abgegeben hat. Wenn prädiktive Analytik auf Ihrer Roadmap steht, planen Sie die Datenarbeit zuerst und die Modellierung danach. Die Reihenfolge ist entscheidend.

Yuliya Marazenko, Head of AI Implementation bei Silk Data, dazu, wo Piloten scheitern: „Wir haben Modelle übernommen, die auf dem Papier funktionierten und in der Produktion versagten. Die Ursache ist fast immer dieselbe. Datendrift wurde nicht überwacht, Retraining wurde nicht eingeplant, und das Team, das das Modell gebaut hat, war nicht mehr da. Ein Modell ohne Verantwortlichen auf der Fachseite verfällt still und leise.“

Governance, DSGVO und der EU AI Act – ein separater, kleinerer Baustein

Compliance ist Teil der Datenstrategie, aber ein eigenes Thema. Technische und rechtliche Schichten getrennt zu halten, vermeidet die Falle, das eine spät auf das andere aufzusetzen.

Für Organisationen, die in der EU tätig sind, setzen zwei Rahmenwerke die Mindestanforderungen:

• DSGVO. Gilt, sobald personenbezogene Daten verarbeitet werden. Regelt Rechtsgrundlage, Aufbewahrung und Zugriffskontrollen. Relevant für fast jeden kundenorientierten KI-Anwendungsfall.
• EU AI Act. Klassifiziert KI-Systeme nach Risikostufen. Hochrisiko-Systeme (Kreditbewertung, Beschäftigungsentscheidungen, bestimmte Bildungsanwendungen) lösen Dokumentations-, Daten-Governance- und Überwachungspflichten aus.

Für rein US-basierte EdTech gilt FERPA für Bildungsakten. Für Einsätze in Großbritannien ist die ICO die zuständige Datenschutzbehörde. Diese sind nicht austauschbar. Passen Sie das Rahmenwerk an die Jurisdiktion und den Fachbereich an. Die praktische Auswirkung auf die Datenstrategie ist konkret. Hochrisiko-KI-Systeme in der EU benötigen dokumentierte Datenqualitätsprozesse und Nachvollziehbarkeit, die sich nicht günstig nachrüsten lassen. Bauen Sie diese von der Datenschicht aufwärts ein.

Hier verdient auch die Bereitstellung on-premise und über lokale LLMs ihren Platz. Für einen Marketingkunden haben wir ein LLM on-premise innerhalb seiner internen Plattform bereitgestellt. Der Kompromiss ist offensichtlich. Höhere Betriebskosten und mehr Infrastrukturarbeit, im Gegenzug Daten, die den Perimeter nie verlassen, und ein Modell, dessen Updates der Kunde selbst steuert. Für regulierte Branchen rechnet sich dieser Kompromiss meist. Für ein internes Werkzeug mit geringem Risiko meist nicht. Siehe die LLM-Fallstudien für die Bereitstellungsmuster, die wir verwenden.

Woran Sie erkennen, dass Ihre Daten bereit sind – ein praktischer Reifegradcheck

Bevor Sie ein Modell in Auftrag geben, gehen Sie diese Fragen mit Ihrem Daten- und Fachteam gemeinsam im selben Raum durch. Wenn die Antwort auf eine der ersten vier Fragen „nein“ lautet, beheben Sie das vor der Modellierung.

1. Können Sie die geschäftliche Entscheidung, die das Modell unterstützen soll, in einem Satz mit Maßeinheit aufschreiben?
2. Hat das Datenfeld, das das Modell benötigt, eine Definition, auf die sich Finanzabteilung, Betrieb und Produktbereich einigen?
3. Haben Sie genügend Datenvolumen für das Signal, das Sie erkennen möchten? (Bei seltenen Ereignissen ist dies meist der Knackpunkt.)
4. Gibt es eine Person auf der Fachseite, die die Modellergebnisse verantwortet und danach handelt?
5. Haben Sie eine Möglichkeit, Datendrift nach der Bereitstellung zu erkennen, und einen definierten Retraining-Rhythmus?
6. Wenn personenbezogene oder regulierte Daten beteiligt sind, ist die Rechtsgrundlage dokumentiert?

Der Vorteil, diese Checkliste vor einem Piloten abzuarbeiten, ist, dass Sie kostspielige Fehlstarts vermeiden. Der Nachteil ist, dass sich der Projektstart um einige Wochen verzögert und unbequeme Antworten zutage treten. Unsere Position: Die paar Wochen sind es wert. Ein umrissener PoC läuft typischerweise etwa drei Monate von Anfang bis Ende. Der Reifegradcheck ist es, was einen PoC, der eine Entscheidung informiert, von einem unterscheidet, der lediglich eine Präsentation hervorbringt.

Was eine ausgereifte Datenstrategie in der Praxis ermöglicht

Wenn die Datenschicht in Form ist, zahlt sich jede weitere KI-Initiative schneller aus. Einige Beispiele aus Silk-Data-Projekten:

• Suche, die findet, was Menschen meinen. Für einen FinTech-Kunden mit über 6 Millionen Bildern haben wir eine Ähnlichkeitssuche auf ElasticSearch aufgebaut. Möglich war das, weil die Metadaten-Pipeline sauber war. Ohne diese hätte die Suche nur Rauschen zurückgegeben. KI-gestützte Suche funktioniert bei Dokumenten nach demselben Prinzip.
• Dokumenten-Workflows, die tatsächlich Zeit sparen. Für unseren Kunden APT hat Plagiarix die Prüfungsdurchsichtszeit um 90 % reduziert. Das Modell ist ein Klassifikator. Der Gewinn ergab sich aus der Datenpipeline drumherum.
• Jedes weitere Modell kostet weniger als das vorherige. Wenn die Datenschicht solide ist, kehrt sich die Kostenkurve für den Aufbau zusätzlicher Modelle gegenüber dem üblichen Muster um. Das erste Modell zahlt die Datenarbeit. Das zweite erbt saubere Pipelines, definierte Features und einen funktionierenden Überwachungs-Stack. Wir sehen einen Aufwandsrückgang von 40–60 % pro nachfolgendem Modell in derselben Domäne, weil die Datenaufbereitung nicht mehr dominiert. Das ist der strukturelle Grund, warum eine Datenstrategie es wert ist, ordentlich aufgesetzt zu werden. Nicht das erste Modell amortisiert die Investition. Sondern das fünfte.

Nichts davon erfordert das neueste Modell. Es erfordert, dass die darunterliegenden Daten belastbar sind.

Wie Silk Data unterstützt

Wir bauen seit mehr als zehn Jahren KI-Produkte in den Bereichen FinTech, EdTech, Publishing und Marketing. Jedes Projekt beginnt mit derselben Frage, die wir Ihnen empfehlen sich zu stellen. Sind die Daten bereit, die KI zu tragen, die Sie bauen möchten? Wenn ja, ist die Modellierung die kleinere Hälfte der Arbeit. Wenn nicht, sagen wir das offen. Yuri Svirid, unser CEO, hat 30 Jahre in EdTech und FinTech damit verbracht, diese Einschätzung zu treffen.

Wenn Sie eine strukturierte Zweitmeinung wünschen, bevor Sie Budget freigeben, deckt AI-Consulting Machbarkeit, Datenreife und Build-vs-Buy-Bewertungen ab. Wenn Sie den Anwendungsfall bereits kennen und ihn kostengünstig validieren möchten, dauert ein PoC etwa drei Monate. Wenn Sie mit semantischen oder Governance-Themen teamübergreifend ringen, ist Data Science und Analytik meist der Ausgangspunkt. Die Fallstudien zeigen, wie sich diese Projekte über verschiedene Branchen hinweg entwickelt haben.