Keine Enterprise-KI ohne Anpassung

Die meisten Unternehmen gehen die KI-Einführung genauso an, wie sie früher Unternehmenssoftware gekauft haben: einen Anbieter auswählen, sich auf ein Modell festlegen und es organisationsweit ausrollen.

Die Annahme dahinter: Ein Modell löst jedes Problem. Doch ein Modell, das in der Codegenerierung brilliert, kann sich bei der Security-Analyse schwertun – und ein Frontier-Modell, das sich perfekt fürs Prototyping eignet, erfüllt möglicherweise nicht die Anforderungen an die Data Residency.

Dieser Widerspruch lässt sich nur auflösen, wenn die Bereitstellung von KI-Modellen flexibel bleibt. Manche Teams benötigen großskalige Modelle für anspruchsvolles Reasoning, andere spezialisierte Modelle für domänenspezifische Aufgaben. Entscheidend ist die Fähigkeit, je nach Aufgabe zu kombinieren.

Das KI-Paradox: den gesamten Entwicklungsprozess optimieren

Die KI-Einführung konzentriert sich heute fast vollständig auf die Beschleunigung der Codegenerierung. Doch das Coding macht nur einen Bruchteil der täglichen Entwicklerarbeit aus. Laut GitLabs Global DevSecOps Survey 2025 verbringen Entwickler in Deutschland nur etwa 16 Prozent ihrer Zeit mit dem Schreiben von neuem Code. Der Rest entfällt auf Planung, Code-Reviews, Testing, Debugging, das Management von Abhängigkeiten, die Abstimmung mit Teammitgliedern und die Navigation durch Compliance-Anforderungen.

Daraus entsteht ein KI-Paradox: KI beschleunigt zwar das Coding, doch fragmentierte Toolchains und manuelle Koordination bremsen die Gesamtproduktivität so stark, dass pro Entwickler und Woche nahezu ein ganzer Arbeitstag verloren geht.

Um aus diesem Paradox auszubrechen, muss KI über den gesamten Entwicklungszyklus hinweg wirken – nicht bloß bei der Codegenerierung. Unterschiedliche Aktivitäten im Software-Lifecycle stellen grundlegend unterschiedliche Leistungsanforderungen:

• Geschwindigkeitskritische Aufgaben wie das Autovervollständigen von Code oder das Vorschlagen von Fixes während der aktiven Entwicklung erfordern Antwortzeiten im Subsekundenbereich – das spricht für kleinere, lokal gehostete Modelle.
• Qualitätskritische Aufgaben wie Architekturplanung oder Security-Analyse rechtfertigen die Kosten von Frontier-Modellen mit überlegenem Reasoning.
• Kostensensible Aufgaben in hohem Volumen, etwa das Ausführen von Tests oder das Aktualisieren von Abhängigkeiten über Hunderte von Repositories, verlangen kosteneffiziente Optionen.

Genau deshalb ist Multi-Modell-Anpassung wichtig. Nicht alle Aufgaben im Software-Lifecycle haben denselben Wert. Wer sich auf ein Modell festlegt, zahlt für manche Funktionen zu viel und unterversorgt andere. Unternehmen, die das richtig machen, bauen Systeme, die flexibel genug sind, um jede Aufgabe an das Modell zu leiten, das am besten zu ihrem Profil aus Leistung, Qualität und Kosten passt.

Den Einsatz von Premium-Modellen priorisieren

Der pragmatische Schritt besteht darin, die Modellkosten am Aufgabenwert auszurichten.

Für hochvolumige Routinearbeit – Commit-Messages schreiben, Log-Dateien zusammenfassen oder Testfälle erstellen – greifen Teams zu günstigeren, schnelleren Optionen, teilweise auch zu Open-Source-Modellen. Für Aufgaben, die komplexes Reasoning verlangen, zahlen sie für mehr Leistungsfähigkeit. Bei spezialisierten, deterministischeren Modellen sind Teams womöglich bereit, einen Aufpreis zu zahlen – etwa für die Generierung von Infrastructure-as-Code oder für hochpräzise Datentransformationen.

Die Wahl zwischen verschiedenen Modellen je nach Aufgabe bietet eine Absicherung gegen Leistungsunterschiede, Preisschwankungen und die Realität, dass Anbieter Produkte einstellen oder den Markt ganz verlassen können.

Diese Flexibilität speist sich aus drei Quellen, jede mit eigenen Abwägungen:

• Kommerzielle Frontier-Modelle von Anthropic, OpenAI und Google liefern starke Leistung und verbessern sich kontinuierlich, schaffen aber Abhängigkeit von den Roadmaps und der Preisgestaltung der Anbieter.
• Selbst gehostete kommerzielle oder Open-Source-Modelle geben Kontrolle über Data Residency, Kosten und Verfügbarkeit, erfordern jedoch Infrastrukturmanagement – und können im Fall von Open Source agentische Workflows noch nicht bewältigen.
• Selbst trainierte domänenspezifische Modelle können allgemeine Modelle bei eng umrissenen, kritischen Aufgaben übertreffen, sofern eigene Daten und klare Erfolgskriterien vorliegen; sie erfordern jedoch Spezialwissen und können im Betrieb teuer sein.

Jeder Ansatz bringt Abwägungen mit sich. Entscheidend ist, Systeme zu bauen, die alle drei strategisch nutzbar machen.

KI-Ausgaben wie Cloud-Ausgaben behandeln

Modellflexibilität schafft nur dann Wert, wenn sich die Ökonomie dahinter steuern lässt. Die Preisdifferenz zwischen Modellen ist erheblich: Modelle für komplexes Reasoning können pro Anfrage 500 Prozent mehr kosten als Allzweckmodelle, die für Routineaufgaben völlig ausreichen.

Modell-Routing – die Fähigkeit zu definieren, welche Modelle für welche Aufgaben eingesetzt werden – wird hier entscheidend. Ein Code-Review läuft womöglich über ein Frontier-Modell, während die Generierung von Commit-Messages eine schnellere, günstigere Option nutzt.

Doch Routing allein reicht nicht. Unternehmen brauchen dieselben finanziellen Kontrollen, die sie auf ihre Cloud-Infrastruktur anwenden: Kontingente gegen ausufernde Ausgaben, Limits zur Durchsetzung von Budgetdisziplin und Chargeback-Modelle, die Kosten den Abteilungen zuordnen, die KI-Ressourcen verbrauchen. Ohne diese Leitplanken lässt sich die KI-Einführung im großen Maßstab schwer rechtfertigen.

Deshalb dehnen sich FinOps-Praktiken auf KI aus. IDC schätzt, dass Unternehmen weltweit ihre KI-Infrastrukturkosten bis 2027 um 30 Prozent unterschätzen werden und dass die Verbindung von GenAI mit FinOps-Prozessen für die Beherrschung dieser Komplexität unverzichtbar sein wird. Wer KI-Ausgaben wie Cloud-Ausgaben behandelt – mit Transparenz, Verantwortlichkeit und Governance –, schafft die Voraussetzungen, um KI erfolgreich zu skalieren.

Anpassung ist entscheidend für den ROI

Modellflexibilität hängt auch vom Kontext ab. KI benötigt Informationen, die über Systeme verteilt sind, die nicht dafür ausgelegt waren, standardmäßig zusammenzuarbeiten. Wer einen Fehler debuggt, muss womöglich das Backlog heranziehen, aktuelle Slack-Diskussionen abrufen und App-Performance-Metriken in Grafana prüfen. Wenn jedes System eigene KI-Erfahrung mitbringt und keines davon sauber verbunden ist, erzeugt KI Reibung, statt sie zu beseitigen.

Glücklicherweise adressieren jüngste Open-Source-Entwicklungen wie das Model Context Protocol (MCP) genau das, indem sie Tools ermöglichen, relevanten Kontext und Aktionen innerhalb eines einzigen Workspace zu teilen.

Dieses gemeinsame Fundament eröffnet sinnvolle Anpassung – und die wirksamste Anpassung arbeitet in Schichten, von denen jede abbildet, wie ein Unternehmen arbeitet. Die meisten Entwickler verlassen sich auf vorgefertigte Agenten und Workflows, die KI für gängige Aufgaben verfügbar machen, ohne Spezialwissen zu verlangen. Power-User formen über detailliertes Prompting, wie ein Modell arbeitet – sie bringen ihm im Grunde bei, dem Playbook ihres Unternehmens zu folgen. Experten verbinden mehrere Agenten zu kontrollierten Abläufen, die abbilden, wie Menschen Arbeit liefern, mit strikten Review-Protokollen.

Den stärksten ROI erzielen Unternehmen, wenn sie Systeme gestalten, in denen KI innerhalb definierter Kontext- und Verantwortungsstrukturen agiert und in denen Teams verschiedene Modelle nach Bedarf verbinden können – ob Frontier-Modelle, selbst gehostete Instanzen für die Data Residency oder spezialisierte Modelle für domänenspezifische Arbeit.

Cube liefert ein praktisches Beispiel für diesen Ansatz. Das niederländische Softwareunternehmen betreibt spezialisierte KI-Agenten für Aufgaben von der Ticket-Verfeinerung über die Wiederverwendung von Designs bis hin zu Wartung und Kontexterfassung – alles innerhalb einer gemeinsamen Plattform und Datenschicht. Mithilfe von GitLab berichtet Cube von einer um 50 Prozent schnelleren Projekteinrichtung und fünfmal mehr Produktiv-Deployments pro Tag.

Orchestrierung statt Standardisierung

Enterprise-KI gelingt, wenn sie Ergebnisse liefert, die sich in realen Systemen und unter realen Bedingungen bewähren.

Führende Unternehmen bauen für Modellvielfalt und halten zugleich strikte Governance aufrecht. Sie behandeln KI-Ausgaben wie Cloud-Ausgaben – mit Modell-Routing, Kontingenten und Chargeback. Sie investieren in Orchestrierung, damit KI sich natürlich in tägliche Workflows einfügt und relevanter Kontext über Tools hinweg fließt.

Ein gründlicher Auswahlprozess ist dabei wesentlich. Die besten Plattformen nutzen Subagenten, die Modelle für jede Art von Operation hinsichtlich Qualität, Leistung und Kosten bewerten – und diese Bewertungen für die Nutzer sichtbar machen, damit Teams verstehen, warum ein bestimmtes Modell eine bestimmte Aufgabe übernimmt. Diese Transparenz schafft Vertrauen. Wenn Teams Anforderungen haben, die von den Standardeinstellungen abweichen, sollten sie Modellauswahlen überschreiben oder eigene Modelle einbringen können.

Das gibt Unternehmen die Möglichkeit, Frontier-Modelle dort einzusetzen, wo Leistung zählt, selbst gehostete Modelle dort, wo Data Residency erforderlich ist, und spezialisierte Modelle dort, wo Domänenexpertise den Unterschied macht – alles gesteuert über eine Control Plane, die unabhängig von der Modellquelle einheitliche Standards für Zuverlässigkeit und Sicherheit wahrt.

Enterprise-KI ist nicht die Suche nach dem perfekten Modell, sondern die Herausforderung, Systeme zu bauen, welche die richtigen Modelle mit den richtigen Aufgaben verbinden – mit der Governance, die das absichert.

Autor: Bryan Ross, Field CTO bei GitLab