Warum KI-Projekte an Infrastruktur und Menschen scheitern

Warum KI-Projekte selten am Modell allein scheitern

Viele Enttaeuschungen rund um KI sehen auf den ersten Blick wie ein Modellproblem aus: Die Antworten sind ungenau, der Pilot bringt wenig Nutzen, die Kosten steigen schneller als der Mehrwert. Fuer Unternehmen liegt der eigentliche Engpass aber oft tiefer. Wenn Daten nicht sauber angebunden sind, Rechte zu breit vergeben werden, Monitoring fehlt und niemand den Betrieb wirklich besitzt, wird auch ein gutes Modell nicht produktionsreif.

Genau dort ist die Ausgangsthese der The-New-Stack-Analyse stark: Sie verschiebt den Blick weg von der reinen Modellqualitaet hin zu Infrastruktur und Menschen. Das ist plausibel, weil auch belastbare Rahmenquellen KI nicht nur als Software-Funktion behandeln, sondern als laufendes Risikomanagement- und Betriebsproblem. NIST beschreibt mit dem AI Risk Management Framework einen freiwilligen Rahmen fuer den Entwurf, die Nutzung und die Bewertung vertrauenswuerdiger KI. Schon daran sieht man: KI-Erfolg ist keine einzelne Beschaffungsentscheidung, sondern eine dauerhafte Steuerungsaufgabe.

Fuer B2B-Leser ist das die wichtigere Nachricht als jede neue Modellankuendigung. Ein Pilot kann im Demo-Modus beeindrucken und trotzdem im Alltag kippen, sobald echte Berechtigungen, echte Daten, echte Last und echte Freigabeprozesse ins Spiel kommen. Darum wird gerade im Enterprise-Markt immer deutlicher, warum Anbieter ihre Milliarden nicht nur ins Modell selbst stecken, sondern in Routing, Governance und Betrieb. Wer das vertiefen will, findet genau diese Verschiebung auch in Warum Microsoft, AWS und Anthropic Milliarden nicht ins Modell selbst stecken.

Kurz gesagt: Wenn Unternehmen fragen, warum ihre KI nicht liefert, sollten sie nicht nur auf Prompting oder Modellwechsel schauen. Die naechste Prueffrage lautet meist: Ist das System dahinter ueberhaupt als produktiver Dienst gedacht worden?

Was KI-Betrieb technisch schwer macht

Der schwierigste Teil produktiver KI ist selten der erste API-Aufruf. Schwer wird es dort, wo aus einer Einzelfunktion ein verlaesslicher Dienst werden soll. Dann zaehlen ploetzlich Dinge, die in fruehen Piloten oft unsichtbar bleiben: Wie kommt das System an die richtigen Daten? Welche Antworten duerfen automatisiert weiterverarbeitet werden? Was passiert bei Zeitueberschreitungen, Modellfehlern oder fehlenden Abhaengigkeiten? Und wer merkt es zuerst, wenn die Qualitaet langsam sinkt?

In Alltagssprache heisst das: KI scheitert haeufig an den Wegen drum herum. Ein Assistent kann in der Demo klug wirken, aber im Betrieb trotzdem unbrauchbar sein, wenn Datenquellen veraltet sind, Antwortzeiten schwanken oder Schnittstellen brechen. Microsofts Leitfaden zu AI Workload Operations beschreibt genau diese operative Ebene: Beobachtbarkeit, Incident-Management, Rueckverfolgbarkeit von Daten und Modellaenderungen sowie disziplinierte Betriebsprozesse gehoeren nicht spaeter dazu, sondern von Anfang an.

Besonders unterschaetzt wird die Kombination aus Datenzugang und Rechteverwaltung. Ein KI-System ist nur so hilfreich wie der Ausschnitt der Realitaet, den es sicher und regelkonform sehen darf. Zu wenig Zugriff erzeugt oberflaechliche Antworten. Zu viel Zugriff schafft Sicherheits- und Compliance-Risiken. Die technische Kunst liegt deshalb nicht in maximaler Offenheit, sondern in sauber begrenzten Verantwortungsraeumen.

Dazu kommt Resilienz. AWS beschreibt fuer generative Agenten nicht zufaellig Muster wie Guardrails, kontrollierte Fehlerpfade und Failure-Injection-Tests. Dahinter steckt eine einfache Wahrheit: In produktiver KI reicht es nicht zu hoffen, dass schon alles funktioniert. Teams muessen vorab testen, wie Systeme reagieren, wenn Modelle halluzinieren, Tools nicht antworten, externe Services langsam werden oder ein Agent einen Zwischenschritt falsch interpretiert.

Gerade agentische Systeme verschaerfen das Problem. Sobald ein Modell nicht nur Text erzeugt, sondern Tools ansteuert, Dateien oeffnet oder Folgeschritte ausloest, wird aus KI eine kleine Laufzeitumgebung mit echten Betriebsfolgen. Dann wachsen Latenz, Kosten, Fehlerketten und Sicherheitsanforderungen zusammen. Das ist einer der Gruende, warum viele Teams den Weg vom Pilot zur Produktion deutlich schwieriger erleben als erwartet.

Was das fuer Kosten, Tempo und Nutzen bedeutet

Wenn diese Grundlagen fehlen, sieht der Schaden oft zuerst wie ein Business-Problem aus. Projekte ziehen sich, weil Integrationen nachtraeglich gebaut werden muessen. Fachbereiche verlieren Vertrauen, weil Ergebnisse inkonsistent wirken. Security bremst spaet, weil Zugriffe nie sauber modelliert wurden. Und die Kosten steigen, weil Teams auf Fehler mit mehr Modellaufrufen, mehr manueller Kontrolle oder noch einem weiteren Tool reagieren.

Deshalb ist Infrastruktur bei KI keine Backend-Nebensache. Sie bestimmt direkt, ob ein Anwendungsfall schnell produktiv werden kann, ob der Nutzen messbar bleibt und ob spaetere Skalierung geordnet oder chaotisch verlaeuft. Ein Unternehmen kann also durchaus am Markt vorbei ueber das "beste" Modell diskutieren, waehrend der eigentliche Flaschenhals bei Logging, Freigaben, Datenqualitaet oder Ausfallverhalten liegt.

Warum Teams und Verantwortlichkeiten mitwachsen muessen

Der zweite Teil der Ausgangsthese ist mindestens so wichtig wie die Infrastruktur: die Menschen. Gemeint sind damit nicht nur fehlende KI-Skills im engeren Sinn. Gemeint sind vor allem unklare Ownership, zerstreute Verantwortung und Prozesse, die fuer klassische Software noch ausreichen mochten, fuer KI aber zu locker sind.

Viele KI-Projekte starten in einer Grauzone. Der Fachbereich sieht den Nutzen, IT soll integrieren, Security soll spaeter prüfen, Data- oder Plattform-Teams helfen punktuell, aber niemand besitzt das System als Ganzes. Genau dann entstehen die typischen Reibungen: Wer entscheidet ueber den produktiven Datenzugriff? Wer misst Antwortqualitaet im Betrieb? Wer genehmigt Modellwechsel? Wer stoppt einen Anwendungsfall, wenn Risiken steigen, aber der Fachbereich weiter Druck macht?

NIST behandelt diese Seite nicht zufaellig als Governance-Thema. Im AI RMF Core geht es nicht nur um technische Kontrollen, sondern auch um Richtlinien, Rollen, Verantwortlichkeit und laufende Aufsicht. Fuer Unternehmen ist das eine nuetzliche Korrektur gegen den Reflex, KI als reines Experimentierfeld zu sehen. Spätestens dann, wenn ein System Entscheidungen vorbereitet, Inhalte an Kunden ausgibt oder intern Prozesse anstoesst, braucht es klare Zuständigkeiten wie jedes andere kritische System auch.

Wichtig ist dabei die Balance. Gute Governance soll ein Projekt nicht ersticken, sondern Friktion an den richtigen Stellen erzeugen. Ein kleines internes Hilfstool braucht nicht denselben Steuerungsaufwand wie ein Agent mit Zugriff auf CRM, Vertragsdaten und Produktivsysteme. Aber selbst einfache Anwendungsfaelle brauchen Mindestdisziplin: dokumentierte Datenquellen, definierte Freigaben, Rollback-Moeglichkeiten, Monitoring und eine klare Person oder ein klares Team, das im Zweifel den Stecker ziehen darf.

Gerade kleinere Unternehmen unterschaetzen oft den Betriebsanteil. Sie investieren in Lizenzen und Prototypen, aber nicht in Pflege, Tests, Rechtekonzepte und kontrollierte Testumgebungen. Dabei entscheidet genau das darueber, ob aus einem spannenden Versuch ein belastbarer Prozess wird. Wer praktische Vorarbeit dafuer sucht, kann bei Mit Testdaten sicher testen: So bleiben echte Daten geschuetzt ansetzen.

Ein nuetzlicher Merksatz lautet deshalb: KI braucht nicht nur Prompts und Modelle, sondern Betreiber. Erst wenn Verantwortung, Sicherheitsgrenzen und Betriebsdisziplin sichtbar benannt sind, sinkt das Risiko, dass ein Projekt an der Organisation scheitert, obwohl die Technik auf dem Papier gut genug waere.

Was die Quelle offenlaesst

Die Grundrichtung der Ausgangsquelle ist ueberzeugend: Viele KI-Probleme sind in Unternehmen eher Betriebs- als Modellprobleme. Trotzdem sollte man die Aussage sauber lesen. Der Beitrag ist ein Analyse- und Meinungsstueck, keine Primärstudie mit einheitlicher Definition von "Scheitern". Deshalb waere es unklug, daraus eine exakte allgemeine Fehlerquote fuer alle KI-Projekte abzuleiten.

Belastbar ist aber etwas anderes: Autoritative Rahmen und Herstellerleitfaeden behandeln KI inzwischen klar als Kombination aus Risiko, Betrieb, Rechteverwaltung und organisatorischer Steuerung. NIST entwickelt sein AI RMF weiter, fuehrt seit Juli 2024 ein Generative-AI-Profil und verweist seit dem 7. April 2026 auch auf ein Profil fuer vertrauenswuerdige KI in kritischer Infrastruktur. Parallel zeigen Azure- und AWS-Leitfaeden, dass produktive KI ohne Monitoring, kontrollierte Aenderungen, Guardrails und Fehlertests nicht ernsthaft skaliert.

Die offenere Frage ist daher nicht, ob Infrastruktur und Menschen wichtig sind. Die offenere Frage ist, wie viel davon ein konkreter Anwendungsfall wirklich braucht. Genau dort muessen Unternehmen differenzieren: zwischen einfachem internen Assistenten, fachbereichsnaher Automatisierung und agentischem System mit echten Schreibrechten. Je naeher KI an produktive Prozesse rueckt, desto weniger ist sie ein Tooltest und desto mehr eine Betriebsentscheidung.

Das ist am Ende auch die nuetzlichste Lesart fuer Entscheider: Nicht jedes schwache KI-Ergebnis bedeutet, dass das Modell falsch gewaehlt wurde. Sehr oft zeigt es, dass die Organisation eine Produktivfrage noch wie ein Experiment behandelt.