Illustratives zusammengesetztes Szenario, 14. Juli 2026. Der Geschäftsführer eines mittelständischen Maschinenbauers sieht am Montagmorgen im Wiener Besprechungsraum ein neues Frontier-Modell. Es erkennt Widersprüche in einer Ausschreibung, formuliert eine saubere deutsche Zusammenfassung und beantwortet eine englische Rückfrage überzeugend. Noch bevor die Präsentation endet, fällt der Satz: „Dann stellen wir jetzt alle Workflows auf das stärkste Modell um.“ Die Betriebsleiterin denkt an drei andere Dinge: die Freigabegrenze bei Vertragsabweichungen, die Kostenstelle für tausende Routinevorgänge und die Nacharbeit, die bisher in keiner Modellrechnung auftaucht.
Dieses illustrative Szenario bündelt typische Muster aus dem DACH-Mittelstand. Es ist kein Kundenfall und keine behauptete Kundenreferenz oder Ergebniszusage. Ein neues Modell kann leistungsfähiger sein und trotzdem als pauschaler Standard das falsche Betriebsmodell erzeugen.
Unbequeme Wahrheit: Ein plausibler Satz mit hohen Folgekosten
Im Betrieb führt diese pauschale Vorgabe dazu, dass Routinevorgänge teure Rechenleistung belegen, während Freigaben, Nacharbeit und Kostenverantwortung ungeklärt bleiben. Aus dem Wunsch des Geschäftsführers, sämtliche Abläufe auf ein neues Frontier-Modell umzustellen, wird so ein unkontrollierter Betriebsstandard.
„Nehmen wir für alles das beste Modell“ klingt nach Qualitätsorientierung. Tatsächlich werden damit Lieferscheinprüfung, Reklamationsantwort, technische Recherche, Angebotsbewertung und Vertragsfreigabe zu derselben Rechenentscheidung. Die Rechnung des Anbieters steigt sichtbar. Prüfaufwand, Wartezeit, Nacharbeit und fachliche Haftung verteilen sich unsichtbar auf mehrere Kostenstellen.
Der umgekehrte Reflex ist ebenso gefährlich. Wer überall das billigste Modell einsetzt, spart möglicherweise beim Aufruf und bezahlt anschließend Sachbearbeiter dafür, unpräzise Ergebnisse zu korrigieren. Ein günstiger Lauf ist kein belastbares Ergebnis.
Leitsatz: Nicht das Modell standardisieren, sondern die Entscheidung
Ein Unternehmen braucht keinen Glaubenssatz zu einem Anbieter. Es braucht eine wiederholbare Entscheidung: Welche Modellstufe darf diese konkrete Aufgabe unter diesem Risiko, mit dieser Qualitätsanforderung und diesem Kostenrahmen bearbeiten?
Genau dafür dient ein KI-Workload-Router. Er hält Routinearbeit schnell und wirtschaftlich, reserviert aufwendige Modelle für begründete Fälle und stoppt Vorgänge, die eine menschliche Freigabe benötigen. Die Stärke liegt nicht in möglichst vielen Modellen, sondern in einem nachvollziehbaren Betriebsmodell.
Was Sie aufbauen können
Sie können KI-Workloads nach Aufgabe und Wirkung klassifizieren, die Kosten pro belastbarem Ergebnis messen und eine Routing-Regel mit Qualitätsprüfung, Fallback, Freigabe, Datenstandort und Ausfallweg umsetzen. Dazu erhalten Sie eine Routing-Matrix, eine Telemetrie-Scorecard, einen 30/60/90-Tage-Plan, eine Checkliste und eine Routing-Policy-Vorlage für Geschäftsführung, Fachbereich, IT, Risikofunktion und Controlling.
Ein Standardmodell erzeugt versteckte Kosten oder Risiken
Ein einziges Modell vereinfacht zunächst Beschaffung und Entwicklung. Ist es die leistungsstärkste Stufe, laufen auch Klassifikation, Datenbereinigung und strukturierte Extraktion über teure Kapazität. Die Latenz kann steigen, Limits treffen mehr Prozesse und die Kostenstelle kann kaum erklären, warum Routinearbeit Premium-Rechenleistung benötigt. Das sind vermeidbare Mehrkosten.
Ist das Standardmodell dagegen klein und günstig, werden sprachlich anspruchsvolle Reklamationen, technische Ausnahmen oder Vertragsklauseln schnell zum Qualitätsrisiko. Mitarbeitende prüfen mehr, öffnen Fälle erneut und übernehmen Nacharbeit. Der Preis pro Token sinkt, während die Kosten pro akzeptiertem Ergebnis steigen.
Die belastbare Lösung ist eine abgestufte Entscheidung: Wo genügt eine wirtschaftliche Modellstufe? Wo rechtfertigt der Fall ein leistungsfähigeres Modell? Und wo gilt unabhängig vom Modell eine Freigabegrenze?
Was ist ein KI-Workload-Router, und was ist er nicht?
Ein KI-Workload-Router ist eine Policy-Schicht. Er liest Merkmale des Vorgangs, wendet eine Routing-Richtlinie an, wählt eine erlaubte Modellstufe, prüft das Ergebnis und löst bei Abweichungen Fallback oder Eskalation aus. Relevante Merkmale sind Aufgabe, Sprache, Datenklasse, Rechtsraum, Schadenspotenzial, Latenz, Qualitätsziel, Budget und Verfügbarkeit des Providers.
Ein Router ist kein API-Gateway. Das Gateway kann Zugriffe authentifizieren, begrenzen, protokollieren und technisch weiterleiten. Es entscheidet aber nicht automatisch, ob eine Abweichung in einem Liefervertrag eine juristische Freigabe braucht. Der Router kann ein Gateway als Durchsetzungspunkt nutzen.
Er ist auch kein Modell-Benchmark und keine Benchmark-Rangliste. Ein Benchmark vergleicht Modelle unter vorgegebenen Tests. Die Routing-Policy entscheidet anhand eigener Akzeptanzkriterien. Nicht „Wer ist Erster?“, sondern „Welche erlaubte Route liefert für diesen Vorgang ein belastbares Ergebnis zu vertretbaren Gesamtkosten?“
T-R-Q-C: Vier Definitionen vor der Modellauswahl
Das T-R-Q-C-Entscheidungsmodell zwingt Fachbereich und IT, Aufgabe, Risiko, Qualität und Kosten zu definieren, bevor ein Produktname die Diskussion dominiert.
T - Task / Aufgabe
Die Aufgabe beschreibt den kleinsten messbaren Arbeitsvorgang: Eingaben, Sprache, Werkzeuge, Ausgabeformat, Termin und Umkehrbarkeit. „Kundenservice“ ist zu breit. „Deutsche Antwort zum Lieferstatus aus freigegebenen Auftragsfeldern entwerfen“ lässt sich gezielt routen.
R - Risk / Risiko
Das Risiko ist die glaubwürdige Folge eines falschen, verspäteten, offengelegten oder unbefugten Ergebnisses. Dazu gehören finanzielle Zusagen, Rechtswirkung, Personendaten, Reputation und die Frage, ob der Schritt vor Außenwirkung rückgängig gemacht werden kann.
Q - Quality / Qualität
Qualität wird als prüfbare Abnahmebedingung formuliert: korrekte Felder, belegte Aussage, einheitliche Terminologie, gültiges Schema, sprachliche Prüfung oder Übereinstimmung mit Referenzfällen. „Klingt professionell“ reicht als Qualitätsprüfung nicht.
C - Cost / Kosten
Kosten umfassen Modell- und Tool-Nutzung, Latenz, menschliche Prüfung, Fehlversuche und Nacharbeit. Sie gehören zum Workload und zu einer verantwortlichen Kostenstelle. Die sinnvolle Kennzahl lautet Kosten pro belastbarem Ergebnis.
Routing-Tabelle: Der einzelne Vorgang entscheidet
| Workload / Aufgabe | Modellstufe | Risiko | Qualitätsprüfung | Eskalation / Fallback |
|---|---|---|---|---|
| Service-E-Mails nach Anliegen sortieren | Economy | Niedrig, Zuordnung ist umkehrbar | Gültige Kategorie und kalibrierter Konfidenzwert | Bei Unsicherheit Fallback auf Standard, unbekannte Fälle an Disposition |
| Rechnungsfelder eines Lieferanten extrahieren | Economy, strukturierte Ausgabe | Mittel wegen Zahlungsprüfung | Schema gültig, Summe plausibel, Lieferant eindeutig | Abweichung an Standardmodell und Kreditorenprüfung |
| Deutsch-englische Reklamationsantwort entwerfen | Multilingual Standard | Mittel, externe Wirkung | Falldaten belegt, Terminologie korrekt, keine Zusage erfunden | Preisnachlass oder Eskalation oberhalb der Freigabegrenze muss von einer verantwortlichen Person freigegeben werden |
| Technische Ausschreibung zusammenfassen | Advanced | Mittel, Auslassung beeinflusst Angebot | Wesentliche Aussage mit Abschnittsnachweis | Fehlender Beleg: einmaliger Retry, danach Fachprüfung |
| Nicht standardisierte Vertragsklausel bewerten | Advanced mit begrenztem Wissenszugriff | Hoch, rechtliche und kaufmännische Wirkung | Klausel zitiert, Unsicherheit genannt, Playbook angewandt | Keine autonome Entscheidung; zwingende juristische Freigabe |
| Investitionsszenario für die Geschäftsleitung | Advanced mit Rechenwerkzeug | Hoch, Kapitalentscheidung | Quellen nachvollziehbar, Rechnung reproduzierbar, Alternativen sichtbar | Freigabe durch Finance; Provider-Ausfall nutzt getestete Ersatzroute |
Eine gute Routing-Tabelle beschreibt immer den nächsten Schritt. Ein niedriger Konfidenzwert darf keine endlose Wiederholung auslösen. Möglich sind ein begrenzter Retry, ein stärkeres Modell, eine enger formulierte Aufgabe oder die Übergabe an eine benannte Rolle.
Kosten pro belastbarem Ergebnis: Die Ergebnisökonomie
Preis pro Token und Preis pro Aufruf sind Einkaufsgrößen. Für den Betrieb reichen sie nicht. Ein billiger Lauf mit zwei Fehlversuchen und zehn Minuten Korrektur kann teurer sein als ein hochwertiger erster Entwurf. Deshalb gilt pro Workload:
Kosten pro belastbarem Ergebnis = (KI-Laufkosten + Prüfkosten + Kosten der Nacharbeit) / akzeptierte Ergebnisse. Anders gesagt: Die Summe wird geteilt durch die Ergebnisse, die die definierte Abnahme tatsächlich bestanden haben.
Die KI-Laufkosten enthalten Modell, Retrieval, Embeddings, Tools und Retries. Prüfkosten bewerten die erforderliche menschliche Prüfung konsistent. Nacharbeit umfasst Korrektur, erneut geöffnete Vorgänge und Reparatur im Folgeprozess. Antworten ohne bestandene Abnahme gehören nicht in den Nenner.
Routen werden nur mit gleicher Fallstruktur und gleicher Qualitätsgrenze verglichen. Ein leistungsstarkes Modell kann bei seltenen, wertvollen Ausnahmen wirtschaftlich sein und bei Routinevolumen unnötige Kosten erzeugen. Ein Economy-Modell kann bei Rechnungsfeldern überzeugen und bei mehrsprachigen Vertragsausnahmen scheitern.
Für eine nachvollziehbare Verbindung zwischen technischer Nutzung, Kostenstelle und Geschäftsergebnis eignet sich ein CFOProof-Kostenbeleg mit operativem Audit. Entscheidend ist nicht eine schöne Token-Kurve, sondern ein prüfbarer Ergebnisbezug.
Betriebliche Sicherungen: Evaluation, Fallback und Freigabe
- Evaluation: Eine automatische Qualitätsprüfung kontrolliert Schema, Belege, verbotene Aussagen, Sprache und workloadeigene Regeln, bevor das Ergebnis weiterläuft.
- Fallback-Modell: Für niedrige Konfidenz, ungültige Ausgaben, Timeouts oder Regelkonflikte gibt es eine definierte Fallback-Route. Retries sind begrenzt und bleiben im selben Fall nachvollziehbar.
- Menschliche Freigabe: Finanzielle Zusagen, rechtliche Auslegungen, sensible Außenkommunikation und Ausnahmen oberhalb der Freigabegrenze müssen von einer namentlich verantwortlichen Person freigegeben werden.
- Datenresidenz: Datenklasse und Datenstandort bestimmen erlaubte Regionen, Provider und Aufbewahrung. Preis und Modellstärke können diese Vorgabe nicht überstimmen.
- Provider-Ausfall: Ein getestetes Ausweichmodell, ein reduzierter Betriebsmodus oder eine manuelle Warteschlange hält den Prozess kontrollierbar. Die Ersatzroute wird vor dem Ernstfall mit Identität, Tools, Evaluation und Protokollierung geprüft.
Diese Sicherungen gehören in eine durchgängige KI-Systemarchitektur. Liefert ein Altsystem keine stabilen Ereignisse, Berechtigungen oder Fallnummern, wird das als konkrete Abhängigkeit der Legacy-Modernisierung geführt. Daraus folgt kein pauschales ERP- oder CRM-Projekt.
Telemetrie-Scorecard: Routing anhand von Belegen verbessern
Der offizielle GenAI-Observability-Überblick von OpenTelemetry vom 14. Mai 2026 erläutert die noch entstehenden und aktiv weiterentwickelten semantischen GenAI-Konventionen für Modell-, Token-, Latenz- und Tool-Aufruf-Telemetrie. Er ist keine abschließende Leitlinie; allerdings lautet Alis architektonische Schlussfolgerung, eine gemeinsame technische Beweisschicht um Akzeptanzquote und Nacharbeit zu ergänzen, weil Telemetrie allein kein belastbares Ergebnis nachweist.
| Signal | Betriebliche Entscheidung | Rhythmus |
|---|---|---|
| Workload, Route, Modell, Policy-Version | Welche Regel die Route auswählte und ob eine Änderung Drift auslöste | Wöchentlich und nach Releases |
| Input-/Output-Token und Tool-Aufruf | Ausführungskosten je Prozess und Kostenstelle | Tägliche Ausnahme, Monatstrend |
| Latenz, Timeout, Retry, Provider-Status | Ob eine günstige Route Durchlaufzeit oder Stabilität verschlechtert | Laufend |
| Evaluation und Akzeptanzquote | Ob Ausgaben zu akzeptierten Ergebnissen werden | Nach Workload und Sprache |
| Prüfminuten und Nacharbeit | Ob Einsparungen beim Modell Aufwand in den Fachbereich verlagern | Wöchentlich, monatlicher Abschluss |
| Eskalation, Freigabe, Datenstandort-Ausnahme | Wo die Routing-Regel nachgeschärft werden muss | Je Ausnahme |
Nicht der Durchschnitt entscheidet. Akzeptanz, Latenz und Nacharbeit werden nach Aufgabe, Sprache, Standort, Modellstufe und Policy-Version getrennt. Sonst verdeckt eine gute Routinequote die schlechte Qualität seltener, aber folgenreicher Fälle.
Was die Quellen von 2026 belegen und was nicht
Herstellerangabe, OpenAI, 9. Juli 2026: OpenAI berichtet in der Ankündigung zu GPT-5.6 über unterschiedliche Leistungs- und Preismerkmale neuer Modelloptionen. Das ist eine Anbieterangabe, kein allgemeiner Beleg für Überlegenheit oder Einsparung. Alis architektonische Schlussfolgerung ist enger: Unterschiedliche Stufen machen aufgabenbezogenes Routing betrieblich relevanter.
Anbieterperspektive, Microsoft, 16. Juni 2026: Laut Microsoft gehört nach Achieving success with AI die Kostensteuerung neben Leistung, Sicherheit und Compliance. Das bedeutet, dass ein Betriebsmodell Kosten nicht erst nach der Einführung betrachten darf; es ist aber kein Beleg für ein bestimmtes Routing-Produkt.
Anbieterperspektive, Google Cloud, 22. April 2026: Die Ankündigung der Gemini-Enterprise-Agentenplattform und der Überblick zur Enterprise-Plattform beschreiben Multi-Modell-Flexibilität und Modellauswahl je Aufgabe. Das sind Herstellerangaben. Allerdings lautet Alis Schlussfolgerung, dass die Auswahl als eigene Richtlinie außerhalb einer einzelnen Modellfamilie geführt werden sollte.
Kontext der FinOps Foundation, 2026: Das Thema AI for FinOps berichtet, wie Praktiker KI im FinOps-Alltag einsetzen, und verbindet dies mit der breiteren Priorität FinOps for AI und Wertsteuerung, die das Thema AI Value sowie das Framework zur Technologiekategorie AI erläutern. Zusammen stützen diese Quellen die Steuerung von Kosten anhand akzeptierter Ergebnisse, schreiben aber weder T-R-Q-C vor noch belegen sie einen konkreten Return on Investment.
Umsetzungsplan für 30/60/90 Tage
Erste 30 Tage: Einordnen und Basis messen
- Drei Workloads mit unterschiedlichem Volumen und Risiko auswählen.
- T-R-Q-C und Abnahmetests je Vorgang definieren.
- Ausführung, Prüfung, Nacharbeit, Latenz und akzeptierte Ergebnisse messen.
- Fachlichen, kaufmännischen, Risiko- und technischen Eigentümer benennen.
Tag 31 bis 60: Kontrollierte Routen umsetzen
- Stabile Modellstufen und erste Routing-Richtlinie einführen.
- Evaluation, begrenzten Fallback, Freigabe, Datenresidenz und Ausfallregeln ergänzen.
- Eine Spur von Anfrage bis akzeptiertem Ergebnis aufbauen.
- Vergleiche im Schattenbetrieb durchführen, bevor der Produktivverkehr umgestellt wird.
Tag 61 bis 90: Nachschärfen und entscheiden
- Scorecard nach Workload, Sprache und Policy-Version prüfen.
- Pro Änderung nur eine Routing-Regel anpassen und begründen.
- Provider-Ausfall und manuelle Warteschlange üben.
- Nur Routen mit stabiler Qualität, geklärten Ausnahmen und vertretbaren Kosten skalieren.
Routing-Rezept: Checkliste und Policy-Vorlage
Wiederverwendbare Checkliste
- Ist die Aufgabe eng und messbar beschrieben?
- Basiert das Risiko auf glaubwürdiger Folge und Umkehrbarkeit?
- Ist Qualität mit einer prüfbaren Abnahmegrenze definiert?
- Enthalten die Kosten Ausführung, Prüfung und Nacharbeit?
- Sind Modellstufen, Regionen, Werkzeuge und Datenklassen erlaubt und dokumentiert?
- Sind Retry, Fallback, Eskalation und Freigabe begrenzt?
- Verbindet Telemetrie die Route mit Ergebnis und Kostenstelle?
- Wurde die Ersatzroute bei simuliertem Ausfall getestet?
Routing-Policy-Vorlage
Wenn Workload = [Aufgabe], Sprache = [Sprache], Datenklasse = [Klasse], Risiko = [Stufe] und Provider-Status = [Status], route zu [Modellstufe] in [Region] mit [Werkzeugen]. Akzeptiere nur, wenn [Qualitätsregeln] innerhalb von [Latenz-/Kostengrenze] bestehen. Eskaliere an [Route/Rolle], wenn [Bedingung]. Fallback auf [Ersatzroute/manuelle Queue] nach [Anzahl] Versuchen. Protokolliere Policy-Version, Modell, Token, Tool-Aufruf, Latenz, Prüfung, Nacharbeit, Ergebnis und Kostenstelle.
FAQ
Was ist ein KI-Workload-Router?
Ein KI-Workload-Router ist eine Policy-Schicht, die Geschäftsvorgänge klassifiziert, erlaubte Modellstufen auswählt, Ergebnisse prüft und Ausnahmen nach unternehmenseigenen Abnahmekriterien an ein stärkeres Modell, eine Fallback-Route oder eine verantwortliche Person übergibt.
Sollte jeder Workflow das stärkste KI-Modell verwenden?
Nein; das stärkste Modell ist nur dort sinnvoll, wo Aufgabe, Risiko, Qualitätsanforderung und Kosten pro akzeptiertem Ergebnis es rechtfertigen, während geprüfte Routinearbeit eine wirtschaftliche Stufe nutzen kann.
Wie berechnet ein Unternehmen KI-Kosten pro belastbarem Ergebnis?
Ein Unternehmen addiert KI-Laufkosten einschließlich Retries und Tool-Aufrufen, menschliche Prüfkosten und Nacharbeit und teilt die Summe durch die Ergebnisse, die die festgelegte Abnahme bestanden haben.
Welche Kontrollen braucht eine Multi-Modell-KI-Architektur?
Eine Multi-Modell-KI-Architektur braucht aufgabenspezifische Evaluation, begrenzte Retries, getestete Fallback- oder manuelle Wege, menschliche Freigaben, Datenresidenz- und Ausfallregeln, versionierte Richtlinien und ergebnisbezogene Telemetrie.
Nächster Schritt: KI-System-Review buchen
Bringen Sie einen volumenstarken und einen folgenreichen Workload, aktuelle Modellrechnungen, akzeptierte und abgelehnte Beispiele sowie die Verantwortlichen für Betrieb und Kosten mit. Ali Najafzadeh verbindet als KI-Systemarchitekt T-R-Q-C, Routing-Policy, Sicherungen, Telemetrie und 90-Tage-Entscheidungspfad. KI-System-Review buchen und aus einer Modellauswahl ein belastbares Betriebsmodell machen.
Continue Reading
