KI-Architektur: Warum Daten-Governance entscheidet

Ein KI-Vorhaben ist ein Datenvorhaben in besserer Kleidung. Das ist keine Kritik an KI — es beschreibt, wo die Arbeit liegt.

Modelle werden zunehmend zur Massenware. Ein sehr gutes lässt sich pro Token mieten. Nicht mieten lässt sich eine saubere, verknüpfte, dokumentierte Sicht auf das eigene Geschäft — und genau dieser Teil fehlt bei jedem steckengebliebenen KI-Projekt.

Das Muster hinter steckengebliebenen KI-Projekten

Es scheitert selten laut. Der Ablauf sieht so aus:

Ein Pilot funktioniert auf einem Auszug, den jemand von Hand vorbereitet hat. Er überzeugt genug für ein Budget. Dann versucht das Team, ihn auf Echtdaten zu betreiben, und stellt fest: Der Auszug war nicht repräsentativ. Er war bereinigt, entdoppelt und verknüpft von einer Person, die hundert kleine Ermessensentscheide getroffen hat, die niemand aufgeschrieben hat.

Diese Ermessensentscheide in einer Pipeline nachzubilden ist das eigentliche Projekt. Es war nie im Umfang, also verschiebt sich der Termin — und mit ihm das Vertrauen der Auftraggeberin.

Die diagnostische Frage: Könnten Sie die Frage, die Ihr Modell beantwortet, heute mit SQL und genügend Zeit selbst beantworten? Wenn nein, wird das Modell sie auch nicht beantworten — es wird eine plausible Zahl ohne Grundlage erzeugen.

Was Governance hier bedeutet

«Daten-Governance» klingt nach Gremien und schreckt Engineering-Teams ab. In diesem Zusammenhang meint es vier konkrete Fähigkeiten, die sich alle bauen lassen.

Integrierte Datensysteme

Der erste Blocker ist fast immer Fragmentierung. Kundendaten in drei Systemen mit drei Schlüsseln, keine Einigung darüber, welches führend ist, und ein Abgleich von Hand.

Was Integration braucht, ist unspektakulärer als ein Plattformkauf: ein vereinbartes führendes System je Domäne, ein definierter Weg, wie Daten zwischen Systemen fliessen, und eine Regel für Widersprüche. Die Technik ist weniger wichtig als die Einigung.

Stammdatenverwaltung

Stammdaten sind die wenigen Objekte, auf die alles andere verweist — Kunde, Produkt, Lieferant, Mitarbeitende, Standort. Fehlt hier eine einheitliche Definition, ist jede nachgelagerte Zahl verhandelbar.

Das Symptom ist bekannt: Zwei Abteilungen nennen unterschiedliche Umsatzzahlen, und beide sind begründbar, weil sie unterschiedliche Kundengruppen gezählt haben.

Für KI ist das keine Berichtsunannehmlichkeit. Ein Modell, das auf uneinheitlichen Definitionen trainiert wird, lernt die Uneinheitlichkeit mit.

Metadaten und Datenherkunft

Herkunft beantwortet eine einfache Frage mit unbequemen Folgen: Woher kommt diese Zahl?

Sie brauchen das aus drei getrennten Gründen:

• Fehlersuche. Wirkt ein Ergebnis falsch, verfolgen Sie es zurück. Ohne Herkunft raten Sie.
• Vertrauen. Wer die Herleitung nicht sehen kann, handelt nicht danach — und die Nutzung stirbt leise.
• Regulierung. Nach dem EU AI Act brauchen Hochrisiko-Systeme eine dokumentierte Daten-Governance für Trainings- und Eingabedaten. Nach revDSG/nDSG und DSGVO müssen Sie automatisierte Entscheide gegenüber betroffenen Personen erklären können. Beides verlangt eine Herkunft, die Sie auf Verlangen vorlegen.

Herkunft nachträglich einzubauen, wenn ein Modell produktiv ist, gehört zu den teureren Korrekturen — weil die einzige ehrliche Lösung manchmal ein erneutes Training auf dokumentierter Basis ist.

Zugriffskontrolle, nicht nur Speicherort

Dieser Punkt wird am häufigsten falsch dargestellt, und er wiegt in der Schweiz schwerer als in den meisten Märkten.

Speicherung in einer Schweizer oder EU-Region beantwortet die Frage des Datenstandorts. Sie beantwortet nicht, wer darauf zugreifen kann — Supportpersonal in einer anderen Rechtsordnung, ein Unterauftragsverarbeiter zwei Ebenen tiefer, ein Administrator mit stehendem Zugriff, den niemand überprüft.

Standort und Zugriff sind zwei Fragen. Schweizer und deutsche Beschaffungsstellen stellen beide, und nur eine davon wird durch eine Regionseinstellung beantwortet.

Was es kostet, das zu überspringen

Drei Kosten, aufsteigend nach Schmerz:

1. Nacharbeit. Die Pipeline wird zweimal gebaut, weil die erste Fassung die Annahmen des handgemachten Auszugs übernommen hat.
2. Aufgabe. Das Modell funktioniert, aber niemand vertraut ihm, also wird es nie für etwas Folgenreiches genutzt. Das ist das häufigste Ergebnis und das unsichtbarste, weil nie etwas für gescheitert erklärt wurde.
3. Erneutes Training unter Auflage. Eine Aufsicht oder eine Kundin verlangt Herkunftsnachweise, diese lassen sich nicht erbringen, und die einzige saubere Antwort ist der Neuaufbau auf dokumentierter Basis.

Eine realistische Reihenfolge

Sie brauchen keine fertige Datenplattform, bevor Sie mit KI beginnen. Sie brauchen genug Fundament für den konkreten Anwendungsfall — und das ist deutlich weniger.

• Zuerst den Anwendungsfall wählen, dann nur die Daten kartieren, die er berührt. Ein vollständiges Datenprogramm vor jeder KI ist der Weg zu dreijährigen Initiativen ohne vorzeigbares Ergebnis.
• Die Identität der benötigten Objekte klären. Meist ein bis zwei, nicht alle.
• Herkunft von Beginn an für diesen Pfad mitführen. Später ergänzen ist die teure Richtung.
• Die Zugriffsfrage vor der Architektur klären, nicht danach. Sie schränkt die Hosting-Wahl ein, und eine Hosting-Entscheidung zurückzudrehen ist teuer.

Das ist bewusst eng gefasst. Es bringt einen Anwendungsfall produktiv, auf einem Fundament, das der zweite und dritte erweitern können — statt einer Plattform, die noch niemand genutzt hat.

Weiterführend

• KI-Einführung: 6 Hürden für Schweizer Unternehmen — wo dieser Punkt unter den anderen Hürden steht
• EU AI Act: Was CTOs im DACH-Raum jetzt tun müssen — die Dokumentationspflichten im Detail
• KI-Strategie & Beratung und MLOps & KI-Infrastruktur

Wenn Sie wissen möchten, ob Ihr Datenfundament den geplanten Anwendungsfall trägt, ist der KI-Sprint genau für diese Frage zugeschnitten. Oder vereinbaren Sie ein Gespräch — unverbindlich.