Why AI can't define your business objects

Im ersten Teil dieser Serie haben wir das grundlegende Paradox beleuchtet: KI-Systeme benötigen perfekt strukturierte Daten, können aber die notwendigen Datenmodelle nicht selbst erstellen. Jetzt wird es konkreter. Warum scheitert selbst die leistungsfähigste KI daran, zu verstehen, was ein "Kunde" oder ein "Produkt" in einem spezifischen Unternehmen bedeutet? Und warum ist genau diese Definitionsarbeit der Schlüssel zum Erfolg jeder KI-Implementierung?

Serie: KI-gestützte Datenmodellierung | Teil 2 von 4

Was ist ein "Kunde"? Es kommt darauf an

Die Frage klingt banal. Jedes Unternehmen weiß doch, wer seine Kunden sind, oder? In der Realität zeigt sich aber schnell: Die Definition von "Kunde" ist alles andere als eindeutig – und genau hier beginnen die Probleme für KI-gestützte Ansätze.

Schauen wir uns drei verschiedene Branchen an:

Versicherungsunternehmen: Hier ist die Unterscheidung zwischen Versicherungsnehmer und versicherter Person fundamental. Der Versicherungsnehmer zahlt die Prämien und ist Vertragspartner. Die versicherte Person genießt den Versicherungsschutz – das kann, muss aber nicht dieselbe Person sein. Bei einer Lebensversicherung für Kinder oder einer Kfz-Versicherung, bei der mehrere Fahrer eingetragen sind, fallen diese Rollen auseinander. Ein generisches KI-Modell würde hier vermutlich ein einziges "Customer"-Objekt vorschlagen – und damit die geschäftskritische Differenzierung ignorieren.

What Is a Customer? It Depends!

E-Commerce-Unternehmen: Im Online-Handel gibt es verschiedene Grade der Kundenbeziehung. Ein registrierter User hat ein Konto angelegt, aber noch nie etwas gekauft. Ein Käufer hat mindestens eine Transaktion abgeschlossen. Ein Newsletter-Abonnent hat sein Einverständnis zur Kommunikation gegeben, ist aber vielleicht weder registriert noch Käufer. Welche dieser Gruppen ist "der Kunde"? Die Antwort hängt vom Kontext ab: Für das Marketing sind alle drei relevant, für die Logistik nur tatsächliche Käufer, für den Datenschutz gelten für Newsletter-Abonnenten besondere Regeln.

B2B-SaaS-Unternehmen: Hier wird es noch komplexer. Die zahlende Einheit ist die Organisation. Innerhalb dieser Organisation gibt es verschiedene Workspaces oder Teams. In jedem Workspace arbeiten individuelle User. Der Rechnungsempfänger (Billing Contact) ist wieder eine andere Person als der technische Administrator oder der tägliche Nutzer. Wer ist hier "der Kunde"? Die Organisation, weil sie zahlt? Der User, weil er die Software nutzt? Der Administrator, weil er Entscheidungen trifft? Alle haben unterschiedliche Attribute, Berechtigungen und Beziehungen zueinander.

Diese Beispiele zeigen: "Kunde" ist kein universeller Begriff, sondern ein hochgradig kontextabhängiges Konstrukt. Und genau diese Kontextabhängigkeit kann KI nicht erfassen.

Die Illusion des generischen Modells

Viele KI-Tools und Standard-Schemas versprechen, genau dieses Problem zu lösen. Sie bieten vordefinierte Datenmodelle für verschiedene Branchen: Retail, Healthcare, Financial Services, Manufacturing. Die Idee ist verlockend: Man wählt sein Branchen-Template aus, passt ein paar Parameter an, und fertig ist das Datenmodell.

In der Praxis funktioniert das selten. Warum nicht?

Standard Schema vs. Business RealityStandard-Schemas bilden den Durchschnitt ab, nicht die Spezifik. Ein generisches Retail-Schema kennt vielleicht "Customer", "Product" und "Order". Es weiß aber nichts über die Besonderheiten eines Unternehmens, das sowohl B2C als auch B2B bedient. Es berücksichtigt nicht, dass manche Kunden über Marktplätze kommen und dort andere Datenstrukturen gelten. Es versteht nicht, dass bestimmte Produkte regulatorisch anders behandelt werden müssen als andere.

Die Differenzierung liegt im Detail. Was ein Unternehmen von seinen Wettbewerbern unterscheidet, ist oft nicht die grundsätzliche Struktur, sondern die spezifische Ausgestaltung. Ein Online-Händler für Lebensmittel hat andere Anforderungen an Produktstammdaten (Mindesthaltbarkeit, Kühlkette, Allergene) als ein Elektronikhändler (Garantie, Kompatibilität, technische Spezifikationen). Ein generisches Schema kann diese Nuancen nicht abbilden.

Historisch gewachsene Systeme haben ihre eigene Logik. Viele Unternehmen arbeiten mit Datenstrukturen, die über Jahre oder Jahrzehnte entstanden sind. Fusionen, Akquisitionen, System-Migrationen – all das hinterlässt Spuren in den Daten. Eine "saubere" KI-Generierung würde diese historische Dimension ignorieren und damit faktisch unbrauchbare Modelle liefern, weil sie nicht zur bestehenden IT-Landschaft passen.

 


Über diese Serie: Dies ist Teil 2 von 4 unserer Serie über KI-gestützte Datenmodellierung. Teil 1 beleuchtet das grundlegende Paradox. Teil 3 stellt einen hybriden Ansatz vor, der KI-Geschwindigkeit mit menschlicher Expertise verbindet.


Tieferes Verständnis gewünscht?

In unserem Data Modeling Training lernen Sie, wie unternehmensspezifische Datenmodelle entwickelt werden – jenseits generischer Templates und Standard-Schemas.

Warum Domain Knowledge nicht ersetzbar ist

Die Grenzen der KI-Automatisierung werden besonders deutlich, wenn wir uns anschauen, was alles in die Definition eines Geschäftsobjekts einfließt:

Geschäftsprozesse bestimmen Datenstrukturen. Nehmen wir das Beispiel "Auftrag" in der Fertigung. Für ein Unternehmen, das auf Lager produziert, ist ein Auftrag ein relativ einfaches Konstrukt: Kunde bestellt Produkt X in Menge Y zur Lieferung am Datum Z. Für einen Auftragsfertiger dagegen ist jeder Auftrag einzigartig, mit spezifischen Anforderungen, Freigabeprozessen, Änderungshistorien und Qualitätsprüfungen. Die Datenstruktur muss diese Prozessrealität abbilden – und die kennt nur, wer den Prozess versteht.

Why Domain Knowledge Cannot Be ReplacedRegulatorische Anforderungen sind hochspezifisch. Ein Pharmaunternehmen muss für seine Produkte vollständige Chargen-Rückverfolgbarkeit sicherstellen – gesetzlich vorgeschrieben. Ein Finanzdienstleister muss bestimmte Kundendaten für Compliance-Zwecke über Jahre aufbewahren, andere nach DSGVO wieder löschen. Ein Medizintechnik-Hersteller unterliegt strengen Dokumentationspflichten. Diese regulatorischen Rahmenbedingungen fließen direkt in die Datenmodellierung ein – und sie sind (vermutlich) nicht Teil des Trainingsdatensatzes irgendeiner KI.

Historisch gewachsene Systeme verlangen Integration, nicht Revolution. Die wenigsten Unternehmen können oder wollen ihre gesamte IT-Landschaft auf einmal erneuern. Neue Datenmodelle müssen mit bestehenden Systemen kommunizieren können. Das bedeutet: Man muss verstehen, welche Datenformate die Legacy-Systeme sprechen, welche Integrationspunkte existieren, welche Transformationen nötig sind. Eine KI, die ein "optimales" Modell ohne Rücksicht auf bestehende Infrastruktur vorschlägt, hilft nicht weiter.

Der fundamentale Unterschied: Syntax vs. Semantik

The Fundamental Difference Syntax vs. SemanticsHier kommen wir zum Kern des Problems. KI-Systeme – auch Large Language Models – arbeiten auf der Ebene von Mustern und Wahrscheinlichkeiten. Sie erkennen, dass bestimmte Begriffe häufig zusammen auftreten, dass bestimmte Strukturen typisch für bestimmte Kontexte sind. Das ist Syntax: die formale Struktur der Daten.

Was KI nicht leisten kann: Semantik verstehen. Die Bedeutung eines Begriffs im spezifischen Geschäftskontext erschließt sich nicht aus Häufigkeitsverteilungen. Wenn in einer Datenbank "customer_type" meistens die Werte "B2B" oder "B2C" hat, kann eine KI das Muster erkennen. Sie weiß aber nicht, dass "B2B" in diesem Unternehmen Kunden mit einem Mindestbestellwert von 10.000 Euro meint, während "B2C" nur Direktkunden ohne Rabattvereinbarungen umfasst – und dass es zusätzlich noch die Kategorie "Reseller" gibt, die anders behandelt wird als beide.

Ein menschlicher Datenmodellierer bringt dieses Kontextverständnis mit. Er fragt nach: "Was bedeutet B2B in eurem Prozess? Welche Attribute sind für diese Unterscheidung relevant? Wie wirkt sich das auf nachgelagerte Systeme aus?" Diese Fragen kann KI nicht stellen – zumindest nicht in einer Form, die zu verwertbaren Antworten führt.

Was das für die Praxis bedeutet

Heißt das nun, dass KI für die Datenmodellierung vollkommen nutzlos ist? Keineswegs. Aber es bedeutet, dass wir KI dort einsetzen müssen, wo ihre Stärken liegen – und nicht dort, wo fundamentales Geschäftsverständnis gefragt ist.

The Limits of (AI) AutomationKI kann hervorragend dabei helfen, Muster in bestehenden Datenstrukturen zu erkennen, Inkonsistenzen aufzudecken, Vorschläge für Standardisierungen zu machen. Sie kann repetitive Aufgaben automatisieren, Dokumentation generieren, Code-Templates erstellen. All das beschleunigt die Arbeit von Datenmodellierern erheblich.

Was KI nicht kann: Die strategischen Entscheidungen treffen, die ein Datenmodell ausmachen. Welche Geschäftsobjekte sind zentral? Wie sind sie definiert? Welche Beziehungen bestehen zwischen ihnen? Welche Attribute sind geschäftskritisch? Diese Fragen erfordern Domain Knowledge, Prozessverständnis und die Fähigkeit, verschiedene Stakeholder-Perspektiven zu integrieren.

Im nächsten Artikel dieser Serie zeigen wir einen konkreten hybriden Ansatz: Wie können Datenmodellierer KI nutzen, um ihre Arbeit zu beschleunigen – ohne die Kontrolle über die entscheidenden Definitionen abzugeben? Dabei geht es um den praktischen Einsatz von KI in der Anforderungsanalyse, um Templates und Validierung, und um die Frage, welche Aufgaben sich automatisieren lassen und welche menschliche Expertise erfordern.