Vom KI-Pilot zum kontrollierten Betriebsmodell.

Ein Chatfenster ist noch kein Prozess. Ein Tool-Call ist noch kein belastbarer Betrieb. Agentisch wird ein System erst, wenn es innerhalb definierter Grenzen selbst einen nächsten Schritt auswählen und ausführen kann. Genau dadurch entstehen Chancen – und neue Pflichten.

Die zentrale Managementaufgabe lautet: Welche Entscheidungen darf das System unter welchen Bedingungen treffen, und wie wird ihr Ergebnis bewertet? Technologie ist ein Teil der Antwort. Prozessdesign, Rollen, Kosten und Evidenz sind ebenso wichtig.

Woran eine agentische Transformation erkennbar ist

• Outcome statt Demo: Eine Kosten-, Qualitäts- oder Durchsatzkennzahl ist definiert.
• Werkzeugzugriff: Das System kann freigegebene Daten lesen oder Aktionen ausführen.
• Policy Gates: Regeln begrenzen Daten, Budget, Aktionen und Risikoklassen.
• Eskalation: Unklarheit führt in einen geplanten menschlichen Zustand.
• Beobachtbarkeit: Eingaben, Quellen, Aktionen, Kosten und Outcome werden nachvollziehbar.
• Verantwortung: Fachliche und technische Owner bleiben benannt.

Use Cases wirtschaftlich auswählen

Der stärkste Kandidat ist nicht zwingend der spektakulärste. Bewertet werden mindestens sechs Dimensionen:

Hohes Volumen, klarer Wert und niedrige Fehlerfolgen sind gute Startbedingungen. Ein Prozess mit sensiblen Daten und rechtsverbindlichen Entscheidungen kann technisch attraktiv sein, ist aber selten der richtige erste Pilot.

Die sieben Gates von Shadow Mode bis Produktion

1. Baseline Gate: Ausgangskosten, Qualität und Volumen sind dokumentiert.
2. Data Gate: Zweck, Felder, Quellen, Löschung und Zugriffsrechte sind freigegeben.
3. Offline Gate: Historische Fälle erreichen definierte Qualitätswerte.
4. Shadow Gate: Das System arbeitet parallel, ohne den echten Prozess zu verändern.
5. Approval Gate: Menschen prüfen vorgeschlagene Aktionen definierter Fallklassen.
6. Limited Action Gate: Nur reversible, risikoarme Aktionen werden automatisch ausgeführt.
7. Scale Gate: Wirkung, Fehler, Kosten und Betrieb rechtfertigen mehr Volumen oder Rechte.

Ein Gate ist keine Projektphase mit festem Kalenderdatum. Es ist eine nachweisbare Bedingung. Wenn die Bedingung nicht erfüllt ist, bleibt das System auf der vorherigen Stufe oder wird gestoppt.

Die Kostenrechnung hinter dem Agenten

Ein vollständiger TCO umfasst Entwicklung, Integration, Modelle, Infrastruktur, Evaluation, menschliche Reviews, Monitoring, Security, Wartung und erwartete Störungen. Auf der Nutzenseite werden mindestens vier Effekte getrennt:

• Cash Savings: tatsächlich vermiedene Lizenzen oder externe Leistungen
• Cost Avoidance: vermiedene künftige Ausgaben, etwa zusätzliche SaaS-Seats
• Capacity: frei gewordene Zeit ohne automatische Budgetreduktion
• Quality / Revenue: weniger Fehler, schnellere Antwort oder höherer Durchsatz

Diese Kategorien dürfen nicht zu einer einzigen großen „Einsparung“ addiert werden, ohne ihre Realisierungslogik zu nennen. Ein Savings Ledger hält Baseline, Annahme, Confidence, Owner, Status und Beleg pro Maßnahme fest.

Architektur: möglichst wenig KI, so viel wie nötig

Deterministische Regeln gehören in klassische Softwarelogik. Ein Sprachmodell wird an den Stellen eingesetzt, an denen Sprache, Dokumente oder variable Entscheidungspfade den Mehrwert rechtfertigen. Dadurch sinken Kosten und Fehlersuche wird einfacher.

Trigger
  ↓
Identität + Policy
  ↓
Deterministische Vorprüfung
  ↓
KI-Entscheidung nur bei Varianz
  ↓
Tool mit minimalem Recht
  ↓
Freigabe / Aktion / Eskalation
  ↓
Outcome + Kosten + Audit-Log

Organisation und Verantwortung

Für jeden produktiven Agenten sollten mindestens Business Owner, Process Owner und Technical Owner benannt sein. Je nach Daten und Risiko kommen Datenschutz, Informationssicherheit, Recht, Betriebsrat oder Fachaufsicht hinzu. „Der Agent hat entschieden“ ist keine Verantwortungszuordnung.

Auch ein Open-Source- oder Self-Host-Stack hebt diese Pflichten nicht auf. Er kann Austauschbarkeit und Kontrolle verbessern, verlangt aber eigene Betriebsfähigkeit. Modelle, Frameworks und Integrationen bleiben Abhängigkeiten, selbst wenn ihr Quellcode offen ist.

Ein realistischer 90-Tage-Rahmen

1. Tage 1–15: Prozess auswählen, Baseline erstellen, Risiko und Datenzugang klären.
2. Tage 16–35: Offline-Evaluation und minimalen Workflow bauen.
3. Tage 36–55: Shadow Mode, Fehlerklassen und Kosten pro Fall messen.
4. Tage 56–75: begrenzter Freigabebetrieb mit echten Operatoren.
5. Tage 76–90: Wirkung belegen und Stop, Anpassung oder Skalierung entscheiden.

Je nach Integration und Risikoklasse kann dieser Rahmen kürzer oder wesentlich länger sein. Die Qualität des Programms zeigt sich nicht an Geschwindigkeit, sondern daran, dass jede nächste Stufe durch Daten begründet ist.