Warum die Einführung von KI in Unternehmen so schwierig ist

Viele KI-Projekte beginnen mit einer überzeugenden Demonstration. Erst bei der Einführung in reale Geschäftsprozesse zeigen sich widersprüchliche Daten, ungeklärte Verantwortlichkeiten und fehlende Qualitätsregeln.

KI-Projekte scheitern häufig nicht am Modell allein. Entscheidend sind Daten, fachliche Definitionen, Prozesse, Verantwortung und die Fähigkeit, Ergebnisse laufend zu prüfen.

Einordnung: fachliche These, keine universelle statistische Aussage. Nicht jeder KI-Anwendungsfall benötigt eine unternehmensweite Data-Domain-Architektur. Fachlicher Leitfaden, Stand 27.10.2026, illustrative Unternehmensbeispiele. Grundbegriffe erklärt der Artikel Künstliche Intelligenz verstehen.

Zwölf Gründe, warum KI-Einführungen schwierig werden

Die Hürden verstärken sich oft gegenseitig. Ein technisch gut integriertes Modell kann fachlich unzuverlässig bleiben, wenn Daten und Begriffe nicht geklärt sind.

1. Fehlende Data-Domain-Architektur: Daten sind nach Anwendungen statt nach fachlicher Bedeutung organisiert.
2. Unklare Datenverantwortung: Für Definitionen, Qualität und Konflikte fehlt eine verbindliche Entscheidungsperson.
3. Schlechte Datenqualität: Unvollständige, veraltete oder widersprüchliche Daten verzerren Ergebnisse.
4. Fehlende Quality Assurance: Tests konzentrieren sich auf Demos statt auf reale Fachfälle und Betrieb.
5. Fragmentierte Systemlandschaft: ERP, CRM, Dateien und Fachsysteme sind nicht konsistent integriert.
6. Fehlende semantische Ebene: Geschäftsbegriffe und Kennzahlen sind nicht einheitlich definiert.
7. Unklare Datenherkunft: Quellen und Transformationen lassen sich nicht ausreichend nachvollziehen.
8. Unklare Anwendungsfälle: Ein Modell wird ausgewählt, bevor der Geschäftsnutzen feststeht.
9. Schwache Prozessintegration: KI bleibt ein isolierter Chatbot ohne tragfähigen Prozessanschluss.
10. Sicherheits- und Berechtigungslücken: Vertrauliche Daten und Zugriffsrechte werden unzureichend berücksichtigt.
11. Fehlendes Change Management: Mitarbeitende werden nicht einbezogen und ausreichend qualifiziert.
12. Fehlende Betriebsverantwortung: Monitoring, Änderungen, Kosten und Qualitätsabfälle bleiben ungesteuert.

Wichtige Abgrenzung: Ein allgemeiner Schreibassistent benötigt nicht dieselbe Datenarchitektur wie ein KI-System, das Finanzkennzahlen aus mehreren Unternehmenssystemen zusammenführt. Architektur und Kontrollen müssen zum Anwendungsfall passen.

Was ist eine Data Domain?

Eine Data Domain (Datendomäne) ist ein fachlich abgegrenzter Bereich von Unternehmensdaten. Sie wird durch Geschäftsbegriffe, Verantwortlichkeiten und die Nutzung der Daten bestimmt, nicht allein durch ein IT-System.

Beispielhafte Domänenaufteilung eines Unternehmens: Kunden, Produkte, Finanzen, Vertrieb, Lieferanten und Personal. Je Domäne gelten eine fachliche Definition, Verantwortliche, Qualitätsregeln und Berechtigungen. Die tatsächliche Struktur hängt von den Geschäftsprozessen ab.

Was eine Data-Domain-Architektur festlegt

• Fachliche Grenzen, Begriffe und Datenobjekte jeder Domäne.
• Entscheidungsrechte und Verantwortliche für Daten und Qualität.
• Gemeinsam nutzbare Datenprodukte, Schnittstellen und Serviceerwartungen.
• Qualitätsregeln, Aktualität, Metadaten und nachvollziehbare Herkunft.
• Zugriffsrechte, Datenschutz und Regeln für domänenübergreifende Nutzung.

Eine Data Domain ist nicht automatisch eine Datenbank, ein ERP-Modul oder eine Abteilung. Daten aus mehreren Anwendungen können zu einer fachlichen Domäne gehören.

Wer ist für welche Daten verantwortlich?

„Die IT kümmert sich darum“ reicht nicht aus. Fachliche Definitionen und Entscheidungen müssen von Personen getroffen werden, die den Geschäftsprozess kennen.

Rolle	Aufgabe	Typische Entscheidung
Data Owner	Fachliche Verantwortung, Regeln und Qualitätsziele	Welche Umsatzdefinition ist verbindlich?
Data Steward	Pflege von Metadaten, Regeln und Qualitätsabweichungen	Wie werden Dubletten behandelt?
Data Product Owner	Nutzbarkeit und Weiterentwicklung eines Datenprodukts	Welche Schnittstelle wird angeboten?
Data Engineer	Integration, Verarbeitung, technische Tests	Wie werden Daten zuverlässig bereitgestellt?
Data Architect	Domänen, Modelle und Architekturstandards	Wie werden gemeinsame Datenobjekte modelliert?
AI Product Owner	Geschäftsnutzen und Qualität der KI-Anwendung	Welche Fehler sind für den Einsatz akzeptabel?
Security / Privacy	Schutzbedarf, Berechtigungen, Datenschutz	Wer darf welche Daten verwenden?

Rollen können in kleinen Organisationen zusammenfallen. Entscheidungsrechte sollten dennoch eindeutig dokumentiert sein.

Praxisbeispiel: „Wie hoch war unser Umsatz?“ Vertrieb, ERP und Controlling melden unterschiedliche Zahlen. Das kann an Auftragseingang, Rechnungsstellung, Erlösschmälerungen oder Buchungszeitpunkten liegen. Eine KI kann diese fachliche Entscheidung nicht eigenständig verbindlich treffen. Die richtige Antwort benötigt Definition, Zeitraum, Quelle und zuständige Freigabe.

Sechs Dimensionen verlässlicher Daten

Eine einzelne Prozentzahl für „Datenqualität“ ist oft wenig aussagekräftig. Je Anwendungsfall müssen messbare Regeln für relevante Qualitätsdimensionen festgelegt werden.

• Richtigkeit: Entsprechen Daten der fachlichen Realität?
• Vollständigkeit: Sind erforderliche Felder und Datensätze vorhanden?
• Konsistenz: Widersprechen sich Systeme oder Definitionen?
• Aktualität: Sind Daten rechtzeitig für den Zweck verfügbar?
• Eindeutigkeit: Sind unerwünschte Dubletten erkennbar?
• Gültigkeit: Erfüllen Werte Formate und Geschäftsregeln?

Beispiel einer messbaren Qualitätsregel (Domäne: Kunden, Datenprodukt: Kundenstamm)

Regel: Jeder aktive Geschäftskunde besitzt eine eindeutige Kunden-ID und ein gültiges Landeskürzel. Beispielhafter Zielwert: mindestens 99 % vollständige IDs, geprüft täglich.

Illustratives Soll, keine Messung oder allgemein verbindliche Branchenvorgabe. Grenzwerte müssen fachlich vereinbart werden.

Von Quellsystemen zu geprüften KI-Ergebnissen

Eine belastbare Architektur verbindet fachliche Verantwortung mit technischer Verarbeitung. Datenschutz, Sicherheit und Monitoring begleiten jede Stufe.

1. Quellsysteme und Geschäftsprozesse: ERP, CRM, Dokumente, Fachanwendungen.
2. Data Domains und Data Owners: Definitionen, Verantwortung, Qualitätsziele.
3. Governed Data Products: Datenqualität, Herkunft, Metadaten, Zugriff.
4. KI-Anwendungen: RAG, Analytik, Copilots, Agenten.
5. Geprüfte Ergebnisse und Entscheidungen: fachliche Kontrolle, messbarer Nutzen, Überwachung.

Vereinfachtes Architekturzielbild, kein universell vorgeschriebener Implementierungsstandard.

Die oft fehlende semantische Ebene

Technisch korrekte Daten sind nicht automatisch fachlich eindeutig. Begriffe wie „aktiver Kunde“, „Umsatz“, „abgeschlossener Auftrag“ oder „Deckungsbeitrag“ müssen unternehmensweit oder zumindest für den Anwendungsfall präzise definiert sein.

Ohne semantische Regeln: Dieselbe Frage liefert je nach System unterschiedliche Antworten. Das Modell kann die Unterschiede nicht zuverlässig erkennen.

Mit verbindlicher Begriffswelt: Business Glossary, Kennzahlendefinitionen, Datenherkunft und Domänenverantwortung schaffen nachvollziehbare Antworten.

Empfehlung: Für kritische Kennzahlen jeweils Definition, Formel, Granularität, Zeitraum, Datenquelle und fachlichen Owner dokumentieren.

End-to-End-Qualität: Nicht nur die KI-Antwort testen

Die Qualität einer KI-Anwendung hängt von der gesamten Verarbeitungskette ab. Insbesondere bei RAG-Anwendungen muss geprüft werden, ob die richtigen Quellen gefunden und korrekt verwendet werden.

1. Quelldaten: Richtigkeit und Vollständigkeit.
2. Transformation: Berechnungen und Zuordnungen.
3. Retrieval: passende und erlaubte Quellen.
4. Generierung: Ist die Antwort durch Quellen gedeckt?
5. Fachliche Abnahme: korrekt für den Geschäftsfall?
6. Laufender Betrieb: Monitoring und Regressionstests.

• Testdatensätze: Repräsentative Fachfragen mit erwarteten Ergebnissen und Grenzfällen.
• Quellenbindung: Prüfen, ob Antworten tatsächlich durch freigegebene Quellen gestützt sind.
• Berechtigungen: Sicherstellen, dass KI keine Informationen aus unzulässigen Datenbereichen preisgibt.
• Änderungskontrolle: Nach Modell-, Prompt-, Daten- und Systemänderungen erneut testen.

Technisch erfolgreich ist nicht automatisch wirtschaftlich sinnvoll

KI-Projekte brauchen messbare Ziele und eine vollständige Betrachtung der Kosten. Dazu gehören neben Modell- und Lizenzgebühren auch Integration, Datenbereinigung, Tests, Schulungen, menschliche Kontrolle und Betrieb.

Nutzen messen

• Bearbeitungszeit je Vorgang
• Fehlerquote und Nacharbeit
• Qualität und Kundenzufriedenheit
• Durchlaufzeit und Kapazität

Gesamtkosten messen

• Software und Modellnutzung
• Datenaufbereitung und Integration
• Prüfung, Governance und Sicherheit
• Schulung, Betreuung und Betrieb

Entscheidungsfrage: Verbessert die KI-Anwendung einen definierten Prozess unter akzeptablen Qualitäts-, Risiko- und Kostenbedingungen?

Wie gut ist Ihr Unternehmen auf KI vorbereitet?

Beantworten Sie die zehn Aussagen mit Ja oder Nein und zählen Sie Ihre Ja-Antworten. Der Test dient der ersten Orientierung und ersetzt weder eine Architekturprüfung noch eine formale Reifegradbewertung.

1. Unsere wichtigsten Data Domains sind fachlich definiert.
2. Für jede relevante Domäne gibt es eine verantwortliche Person.
3. Geschäftsbegriffe und Kennzahlen sind verbindlich dokumentiert.
4. Wir messen Datenqualität anhand definierter Regeln.
5. Datenherkunft und Transformationen sind nachvollziehbar.
6. Unsere KI-Anwendungen berücksichtigen Zugriffsberechtigungen.
7. KI-Ergebnisse werden anhand fachlicher Testfälle geprüft.
8. Für KI-Anwendungen gibt es klare Betriebsverantwortung.
9. Wir haben messbare wirtschaftliche Ziele festgelegt.
10. Unsere Mitarbeitenden werden bei der Einführung eingebunden.

Auswertung:

• 0 bis 3 Ja: Wesentliche organisatorische und technische Voraussetzungen sollten geprüft werden.
• 4 bis 7 Ja: Es bestehen Grundlagen, aber einzelne Lücken können Qualität und Skalierung beeinträchtigen.
• 8 bis 10 Ja: Viele Grundlagen sind vorhanden. Prüfen Sie nun konkrete Anwendungsfälle und deren Akzeptanzkriterien.

Orientierung anhand gleich gewichteter Ja/Nein-Fragen, keine zertifizierte Reifegradmessung.

Wie Unternehmen strukturiert beginnen können

1. Geschäftsfall auswählen: Eine konkrete Entscheidung oder Aufgabe mit messbarem Nutzen bestimmen.
2. Domänen klären: Relevante Daten, Begriffe, Owner und Zugriffsregeln identifizieren.
3. Qualität prüfen: Quellen, Datenqualität, Testfälle und Akzeptanzkriterien festlegen.
4. Pilot durchführen: Mit begrenztem Umfang, echten Fachfragen und menschlicher Prüfung starten.
5. Wirkung messen: Nutzen, Fehler, Kosten und Akzeptanz mit einer Ausgangsbasis vergleichen.
6. Gezielt skalieren: Nur bewährte Lösungen mit klarer Betriebsverantwortung ausweiten.

Die nächste Entscheidung ist nicht „Welches KI-Modell kaufen wir?“, sondern „Welchen Geschäftsprozess können wir mit welchen verlässlichen Daten nachweisbar verbessern?“

Fachliche Grundlagen und Nachweise

Die Quellen beschreiben etablierte Ansätze für Datenarchitektur, Governance und KI-Risikomanagement. Die im Artikel formulierten Maßnahmen sind redaktionelle Empfehlungen; illustrative Zahlen und Beispiele sind entsprechend gekennzeichnet.

1. Google Cloud – Data Mesh Architecture
   Domänenorientierte Datenarchitektur und Datenprodukte · Quellenstand nicht live geprüft
2. IBM – What is a Data Mesh?
   Data Ownership, Datenprodukte und Governance · Quellenstand nicht live geprüft
3. Microsoft Learn – RAG Evaluation
   Bewertung von Retrieval und generierten Antworten · Dokumentationspfad vor Veröffentlichung prüfen
4. NIST – AI Risk Management Framework
   Rahmenwerk für vertrauenswürdiges KI-Risikomanagement
5. ISO/IEC 25012 – Data Quality Model
   Referenz für Datenqualitätsmerkmale; Normtext gegebenenfalls kostenpflichtig

Transparenz: Die Links sind als weiterführende Originalquellen hinterlegt.