KI im Unternehmen: warum die meisten Projekte nie in Produktion gehen

KI im Unternehmen ist in den meisten Organisationen längst kein Erkenntnisproblem mehr, sondern ein Umsetzungsproblem. Modelle werden trainiert, Demos beeindrucken den Vorstand, und dann passiert: nichts. Das Vorhaben versandet zwischen Pilot und Betrieb. Dieser Artikel erklärt, warum das so regelmäßig passiert, und was den Unterschied zwischen einem KI-Projekt und einem produktiven System ausmacht.

Die ernüchternde Quote, und warum sie keine Überraschung ist

Über die genaue Zahl streiten sich die Analysten, aber die Richtung ist eindeutig. Gartner prognostizierte, dass bis Ende 2025 mindestens 30 Prozent der generativen KI-Projekte nach dem Proof of Concept eingestellt werden, unter anderem wegen schlechter Datenqualität, unzureichender Risikokontrolle und steigender Kosten. Frühere Erhebungen zu klassischen ML-Vorhaben kamen über Jahre hinweg auf noch höhere Abbruchquoten.

Das Muster ist nicht neu, und es liegt selten am Modell. Das Modell ist der einfache Teil. Frameworks sind ausgereift, vortrainierte Modelle frei verfügbar, und ein kompetentes Team bekommt in wenigen Wochen einen funktionierenden Prototyp hin. Was schwer ist, ist alles drumherum: verlässliche Daten, reproduzierbarer Betrieb, eine Organisation, die das Ergebnis trägt. Genau dort entscheidet sich, ob KI im Unternehmen ankommt oder im Pilotstadium stecken bleibt.

Die Proof-of-Concept-Falle

Ein Proof of Concept hat eine klar umrissene Aufgabe: zu zeigen, dass etwas grundsätzlich machbar ist. Er läuft auf einem handverlesenen Datensatz, in einer kontrollierten Umgebung, betreut von den Menschen, die ihn gebaut haben. Unter diesen Bedingungen sehen Ergebnisse fast immer gut aus.

Das Problem beginnt, wenn der PoC mit Produktionsreife verwechselt wird. Im PoC sind die Daten bereinigt, im Betrieb kommen sie verrauscht und unvollständig an. Im PoC ist der Datenstand eingefroren, im Betrieb verschiebt sich die Verteilung der Eingangsdaten über die Zeit (Data Drift). Im PoC reicht eine Genauigkeit, die im Mittel überzeugt, im Betrieb entscheiden die Randfälle über Akzeptanz und Haftung.

Der Sprung vom PoC in den produktiven Betrieb ist kein letzter Schritt von neunzig auf hundert Prozent. Er ist oft der größere Teil des gesamten Aufwands. Wer ein KI-Projekt budgetiert, als wäre der gelungene Prototyp das Ziel, hat den eigentlichen Aufwand noch vor sich, nicht hinter sich.

Ohne Datenfundament kein verlässliches Modell

Ein Modell ist immer nur so gut wie die Daten, aus denen es lernt und mit denen es im Betrieb gefüttert wird. Das klingt banal, wird aber in der Praxis systematisch unterschätzt. Die meisten KI-Projekte, die scheitern, scheitern nicht an einem zu schwachen Algorithmus, sondern an einem Datenfundament, das nie für produktive Nutzung gebaut wurde.

Konkret bedeutet ein tragfähiges Datenfundament:

• Verfügbarkeit: Die benötigten Daten existieren, sind auffindbar und zugänglich, nicht über Abteilungssilos und undokumentierte Exporte verstreut.
• Qualität: Vollständigkeit, Konsistenz und Aktualität sind messbar und werden überwacht, nicht einmalig zum Projektstart geprüft.
• Nachvollziehbarkeit: Die Herkunft der Daten ist dokumentiert (Data Lineage). Wenn ein Modell falsche Vorhersagen liefert, muss man zurückverfolgen können, welche Quelldaten das Training beeinflusst haben.
• Bereitstellung: Die Daten lassen sich reproduzierbar und in der nötigen Frequenz an das Modell liefern, im Training wie in der Inferenz.

Hier schließt sich der Kreis zur Datenarchitektur. Ein gut zonierter Data Lake oder ein Lakehouse, mit Katalog, klarem Ownership und Governance, ist keine separate Initiative neben dem KI-Vorhaben. Es ist die Voraussetzung dafür. Wer KI im Unternehmen produktiv machen will, ohne vorher die Datenstrategie geklärt zu haben, baut auf Sand. Die Reihenfolge ist nicht verhandelbar: erst das Fundament, dann das Modell.

MLOps: der Weg vom Notebook in den Betrieb

Ein trainiertes Modell in einem Notebook ist ein Artefakt, kein System. Zwischen dem Modell und einem verlässlichen Produktivbetrieb liegt eine Disziplin, die in vielen Organisationen schlicht fehlt: MLOps, also die Übertragung von DevOps-Prinzipien auf den Lebenszyklus von Machine-Learning-Modellen.

Was dazugehört, und was im PoC bequem ignoriert wird:

• Reproduzierbarkeit: Versionierung von Code, Daten und Modellen, sodass ein Trainingslauf jederzeit nachvollziehbar und wiederholbar ist.
• Deployment-Pipeline: Ein automatisierter Weg vom validierten Modell zur produktiven Inferenz, mit Tests und Rollback-Möglichkeit, nicht ein manueller Export, den eine einzelne Person im Kopf hat.
• Monitoring: Überwachung nicht nur der Infrastruktur, sondern der Modellqualität selbst. Ein Modell degradiert leise. Es wirft keine Exception, es wird einfach über Wochen schlechter, während die Eingangsdaten von der Trainingsverteilung abweichen.
• Retraining: Ein definierter Prozess, wann und wie ein Modell neu trainiert wird, ausgelöst durch Metriken, nicht durch Zufall.

Der Unterschied zwischen einem PoC und KI in Produktion ist im Wesentlichen der Unterschied zwischen einem einmaligen Ergebnis und einem System, das über Monate verlässlich liefert. Letzteres erfordert Engineering-Disziplin, kein zweites Modell. Genau diese Disziplin ist es, an der die meisten KI-Projekte nach dem Pilot zerbrechen.

Use-Case-Auswahl: Geschäftswert schlägt Hype

Viele KI-Vorhaben sind schon bei der Auswahl falsch aufgesetzt. Sie starten mit der Technologie und suchen anschließend ein Problem, statt mit einem Problem zu starten und die passende Lösung zu wählen. Das Ergebnis sind technisch interessante Piloten ohne Anschluss an den Geschäftsbetrieb.

Eine belastbare Use-Case-Auswahl prüft drei Dinge nüchtern:

• Geschäftswert: Löst der Use Case ein reales, quantifizierbares Problem? Ein Modell, das einen teuren manuellen Prozess verlässlich verkürzt, schlägt zehn Demos, die niemand braucht.
• Datenverfügbarkeit: Existieren die Daten in ausreichender Menge und Qualität, um das Modell zu trainieren und im Betrieb zu versorgen? Der beste Use Case ist wertlos, wenn die Datengrundlage fehlt.
• Machbarkeit und Tragbarkeit: Lässt sich das Ergebnis betreiben und verantworten? Ein Use Case, dessen Fehlerfolgen niemand tragen will, gehört nicht in Produktion, egal wie gut die Demo aussah.

Der pragmatischste Einstieg ist selten der spektakulärste. Ein eng umrissener Use Case mit klarem Wertbeitrag und vorhandenen Daten bringt KI ins Unternehmen und schafft die Grundlage, auf der das nächste Vorhaben aufsetzen kann. Breit und ambitioniert zu starten, bevor ein erster Anwendungsfall produktiv läuft, ist der zuverlässigste Weg, nie fertig zu werden.

Governance und EU AI Act: nicht nachrüstbar

Im europäischen, besonders im DACH-Kontext kommt eine Dimension hinzu, die spät einzuplanen teuer wird. Der EU AI Act ist seit August 2024 in Kraft und wird gestaffelt anwendbar. Er klassifiziert KI-Systeme nach Risiko und knüpft daran konkrete Pflichten: Dokumentation, Transparenz, menschliche Aufsicht, Datenqualität und Risikomanagement für Hochrisiko-Anwendungen.

Das ist keine reine Rechtsabteilungsfrage, sondern eine Architekturentscheidung. Nachvollziehbarkeit der Modellentscheidungen, lückenlose Dokumentation der Trainingsdaten und ein klar definierter Punkt menschlicher Aufsicht lassen sich nicht im Nachhinein über ein fertiges System stülpen. Sie müssen von Anfang an Teil des Designs sein, genauso wie Löschkonzepte und Zugriffskontrolle Teil einer DSGVO-konformen Datenarchitektur sind.

Wer Governance als Bremse begreift, hat sie missverstanden. In regulierten Branchen ist sie das, was ein KI-System überhaupt produktionsfähig macht. Ein Modell, das niemand verantworten und dokumentieren kann, geht in einem ernsthaften Unternehmen zu Recht nicht in Betrieb.

Die Organisationsfrage: wer betreibt das Modell?

Am Ende scheitern KI-Projekte oft an einer Frage, die in keinem Architekturdiagramm steht: Wer ist nach dem Go-live eigentlich verantwortlich? Das Modell wurde von einem Datenwissenschaftler oder einem externen Dienstleister gebaut. Aber wer überwacht es im Betrieb, wer verantwortet die Qualität der Vorhersagen, wer entscheidet über ein Retraining, wer haftet, wenn es falsch liegt?

Ohne klare Antworten verläuft jedes KI-Vorhaben im Sand, unabhängig von der technischen Qualität. Ein produktives Modell braucht ein Betriebsmodell: definiertes Ownership, eingebettete Prozesse, geschulte Fachbereiche, die dem Ergebnis vertrauen und es nutzen. Das ist eine Change-Aufgabe, keine technische. Sie wird regelmäßig unterschätzt, weil sie sich nicht in einer Demo zeigt.

KI im Unternehmen ist deshalb nie ein reines Technologieprojekt. Es ist ein Zusammenspiel aus Datenarchitektur, Engineering und Organisation. Fehlt eines der drei, bleibt selbst das beste Modell ein Prototyp.

KI im Unternehmen tragfähig aufsetzen

DNA Solutions begleitet Unternehmen im DACH-Raum dabei, KI-Vorhaben aus dem Pilotstadium in den verlässlichen Betrieb zu bringen: von der ehrlichen Use-Case-Bewertung über das Datenfundament und die MLOps-Infrastruktur bis zur Governance, die dem EU AI Act standhält. Wenn ein vielversprechender Prototyp den Weg in die Produktion nicht findet, oder Sie ein KI-Projekt von Anfang an tragfähig aufsetzen wollen: Sprechen Sie uns an.