Dass produktive KI-Systeme vor allem aus Nicht-KI bestehen, ist keine neue Erkenntnis, sondern ein Klassiker der Informatik: Schon das berühmte NeurIPS-Paper „Hidden Technical Debt in Machine Learning Systems“ von Sculley et al. (2015) zeigte, dass der eigentliche Machine-Learning-Code nur eine kleine Box inmitten von Datenpipelines, Konfiguration, Monitoring und Serving-Infrastruktur ist. Google hat daraus MLOps-Reifegrade abgeleitet – von Level 0 (alles manuell) bis Level 2 (vollständige CI/CD-Automatisierung). Für den Mittelstand ist weniger die Levelnummer wichtig als die Grundidee: Der Weg vom Modell in den Betrieb muss ein wiederholbarer Prozess sein, kein Heldenstück.

Was sich in der LLM-Ära ändert

Mit Sprachmodellen verschiebt sich der Schwerpunkt: Die wenigsten Mittelständler trainieren eigene Modelle – laut IW-Report 33/2025 nur 3,6 Prozent der Unternehmen. Fast alle bauen stattdessen auf Foundation Models auf, per API, mit Prompts, RAG und Werkzeuganbindung. Damit wandern die Betriebsrisiken vom Training in die Nutzung. Vier Elemente bilden den Kern des LLMOps:

  1. Evals – das Herzstück. Ein Eval ist ein automatisierter Qualitätstest: eine kuratierte Sammlung realer Aufgaben Ihres Use Cases mit Bewertungslogik. Vor jeder Änderung – neues Modell, neuer Prompt, neue Datenquelle – läuft die Basislinie. Evals sind zugleich Ihre Wechselversicherung: Wer eine Eval-Suite besitzt, kann Anbieter und Modelle in Stunden statt Monaten vergleichen und entgeht so dem Lock-in.
  2. Monitoring. Vier Größen gehören auf ein Dashboard: Qualität (Stichproben, Nutzerfeedback, Eskalationsquote), Drift (verändert sich das Eingabeprofil?), Latenz und Kosten. Was für Datenqualität gilt, gilt auch für Modellqualität: Messen ist billiger als Raten.
  3. Versionierung. Prompts, Modellversionen, Systemkonfiguration und Wissensbasen werden versioniert wie Quellcode. Ohne Versionsstand keine Fehleranalyse, keine Reproduzierbarkeit – und keine saubere Dokumentation gegenüber den Pflichten aus dem EU AI Act.
  4. Freigabe- und Incident-Prozesse. Jede produktive KI-Anwendung hat einen definierten Freigabeweg (fachlich, Datenschutz, Sicherheit) und einen Störfallprozess: Wer schaltet ab, wer informiert wen, wie sieht der Rückfallbetrieb aus?

Bausteine statt Insellösungen

Der zweite Betriebshebel ist Architektur: Nicht jedes Team baut seinen eigenen Stack. Ein zentrales Kernteam stellt drei Bausteine bereit, die alle Use Cases teilen – ein API-Gateway als einheitlicher Zugangspunkt zu allen Modellen (mit Protokollierung, Budgetgrenzen und Zugriffskontrolle), die RAG-Pipeline auf dem unternehmensweiten Datenfundament und den Eval-Harness, in den jedes Team seine Testfälle einhängt. So sinken Grenzkosten und Time-to-Market mit jedem weiteren Use Case – statt zu steigen.

ISO/IEC 42001 als Struktur-Steinbruch

Wer für all das ein Ordnungsgerüst sucht, findet es seit Dezember 2023 in der ISO/IEC 42001, dem ersten zertifizierbaren Managementsystem-Standard für KI. Die Norm verlangt unter anderem Kontext- und Rollenklärung, Risikomanagement, ein „AI System Impact Assessment“ und Lieferantensteuerung. Erste Anbieter haben sich früh zertifizieren lassen – AWS im November 2024, Anthropic im Januar 2025, dazu zahlreiche Microsoft-Dienste. Für die meisten Mittelständler ist die Zertifizierung optional; der eigentliche Wert liegt im Struktur-Steinbruch: Die Norm ist eine geprüfte Checkliste dafür, welche Prozesse ein KI-Betrieb braucht – und wer sein Betriebssystem entlang dieser Struktur baut, ist zugleich für AI-Act-Nachweise und Kundenaudits vorbereitet.

Warum KI-Kosten anders ticken

Der dritte Pfeiler ist die Kostensteuerung – und sie ist kein Nebenschauplatz. In einer Gartner-CIO-Umfrage (Juni bis Juli 2024, über 300 Teilnehmende) gaben mehr als 90 Prozent der CIOs an, dass das Kostenmanagement ihre Fähigkeit begrenzt, Wert aus KI zu ziehen. Noch drastischer ist die Gartner-Warnung zur Kalkulationsunsicherheit: Wer nicht versteht, wie GenAI-Kosten skalieren, kann sich um 500 bis 1.000 Prozent verkalkulieren – wohlgemerkt eine Warnung vor Fehlkalkulation, keine Prognose tatsächlicher Budgetüberschreitungen.

Die FinOps Foundation, das herstellerübergreifende Gremium für Cloud-Kostensteuerung, hat die Besonderheiten systematisiert: Abgerechnet wird in Tokens, deren Verbrauch vom Nutzerverhalten abhängt; die Allokation ist schwieriger, weil sich viele Konsumenten ein Modell teilen; und Prognosen sind unsicherer als im klassischen Cloud-Betrieb. Die Foundation empfiehlt ein Crawl-Walk-Run-Vorgehen: erst Sichtbarkeit schaffen, dann zuordnen, dann optimieren. Der Rückenwind dabei: Die Preise je Leistungsklasse fallen seit Jahren drastisch – wer heute Unit Economics sauber aufsetzt, wird von der Preisentwicklung tendenziell positiv überrascht. Dass Kostendisziplin Mainstream wird, zeigt die Wharton-Erhebung vom Oktober 2025 (800 US-Führungskräfte): 72 Prozent der Unternehmen verfolgen mittlerweile strukturierte ROI-Metriken für ihre GenAI-Investitionen.

Die drei dokumentierten Kostenhebel

Jenseits guter Prozesse gibt es drei technische Hebel, die in den Preislisten der Anbieter selbst dokumentiert sind (Stand Juli 2026):

  • Modell-Routing / Right-Sizing: Einfache Aufgaben laufen auf kleinen, schwere auf großen Modellen. Die Preisspreizung ist erheblich: Kleine Modelle kosten in der Anthropic-Preisliste in der Größenordnung 1 USD je Million Input- und 5 USD je Million Output-Token, große Modelle etwa 5 beziehungsweise 25 USD, das jeweils neueste Spitzenmodell 10 beziehungsweise 50 USD – ein Faktor von fünf bis zehn allein durch die Modellwahl.
  • Prompt Caching: Wiederkehrende Prompt-Anteile wie Systemprompt und Wissenskontext werden zwischengespeichert statt neu berechnet. Cache-Reads werden mit rund einem Zehntel des regulären Input-Preises abgerechnet – bis zu rund 90 Prozent Ersparnis auf gecachte Anteile.
  • Batch-Verarbeitung: Nicht zeitkritische Aufträge wie Nachtläufe und Massenklassifikation laufen gesammelt asynchron. Die Batch-APIs von Anthropic und OpenAI gewähren 50 Prozent Rabatt auf die Token-Preise.

Vier FinOps-Regeln für den Mittelstand

Aus alldem folgt ein Minimalprogramm mit vier Regeln. Erstens: Kosten je Use Case, nicht je Rechnung – jeder API-Schlüssel und jede Lizenz ist einem Use Case zugeordnet, Sammelposten wie „KI allgemein“ sind verboten. Zweitens: Budget-Alerts vor Budget-Schmerz – je Use Case ein Monatsbudget mit Warnschwelle, damit Ausreißer diskutiert werden, bevor die Rechnung kommt. Drittens: Unit Economics statt Monatssummen – die Steuerungsgröße ist der Betrag pro Vorgang (pro bearbeitetem Ticket, pro geprüfter Rechnung) im Verhältnis zum Wert des Vorgangs; nur so bleibt Wachstum der Nutzung eine gute Nachricht. Viertens: Right-Sizing als Standard – neue Use Cases starten auf dem kleinsten Modell, das den Eval besteht; ein Upgrade gibt es nur bei nachgewiesenem Qualitätsbedarf. Diese vierte Regel verbindet FinOps direkt mit dem Eval-Harness: Qualitätsmessung und Kostensteuerung sind zwei Seiten desselben Maschinenraums.

Wer Qualität nicht misst und Kosten nicht pro Vorgang kennt, skaliert Risiken statt Wert. Die vollständige Analyse – inklusive LLMOps-Loop, Kostentabellen und 12-Monats-Fahrplan – finden Sie im Whitepaper „Vom Piloten zum Betriebssystem“.