KI-Agenten in Produktion: die Landkarte vom Piloten zum verlässlichen Betrieb

Die Demo läuft, der Vorstand klatscht — und sechs Monate später steht der Agent immer noch nicht im Tagesgeschäft. Das ist kein Pech, das ist das Muster: In Studien wie der viel zitierten MIT-Untersuchung kommt die große Mehrheit der GenAI-Piloten nie über die Brücke vom „sieht beeindruckend aus" zum „trägt am Dienstagnachmittag echte Kunden". Nicht weil die Modelle zu schwach wären. Sondern weil nach dem Applaus die unglamouröse Arbeit beginnt — und sich dafür im Org-Chart niemand zuständig fühlt.

Diese Seite ist die kanonische Landkarte unseres Agenten-Clusters. Sie erzählt den ganzen Weg vom Piloten zum verlässlichen Betrieb in einem Stück und verzweigt an jeder Station in den jeweiligen Deep-Dive. Wer im Detail steckt, springt direkt rein. Wer den Überblick braucht, liest von oben nach unten — denn die Reihenfolge ist hier nicht Dekoration, sondern der eigentliche Inhalt.

TL;DR

• Die These: Verlässlichkeit ist kein Modell-Feature, das man einkauft. Sie ist eine Betriebs-Disziplin, die man baut — und sie entsteht in genau dieser Reihenfolge.
• Fünf Stationen, eine Treppe: Betriebslücke erkennen → Observability → Evals als Gates → Sicherheit → Autonomie dosieren. Keine Station ist überspringbar, weil jede die vorherige voraussetzt.
• Warum das so ist: Man kann nicht messen, was man nicht sieht (Evals brauchen Observability). Man gibt keine Kontrolle ab ohne Schleusentor (Autonomie braucht Evals). Man sichert nur ab, was man beobachtet und gegated hat.
• Für den Mittelstand: Der Wettbewerbsvorteil liegt nicht im glänzendsten Piloten, sondern in der Bereitschaft, die fünf unglamourösen Stationen wirklich zu gehen. Kein Forschungslabor nötig — ein Name pro Stufe und die Demut, die nächste erst zu betreten, wenn die vorige trägt.

Die Klammer-These: Verlässlichkeit ist eine Betriebs-Disziplin

Ein größeres Modell schließt die Lücke nicht. Es macht den Piloten nur überzeugender — und den Absturz teurer. Der Pilot beweist, dass der Motor anspringt. Der Betrieb ist alles, was die Maschine in der Luft hält, wenn niemand zuschaut.

Das ist die nicht-offensichtliche Pointe des gesamten Clusters: Verlässlichkeit ist kein Feature im Datenblatt. Sie ist eine Disziplin, die in einer festen Folge entsteht. Jede der folgenden fünf Stationen ist für sich ein eigenes Handwerk und ein eigener Deep-Dive. Aber zusammen bilden sie eine Treppe — und wer Stufe fünf zuerst nimmt, baut einen schnellen, selbstbewussten, unkontrollierten Fehler.

Station 1 — Die Betriebslücke erkennen

Zuerst muss man begreifen, dass die Lücke überhaupt existiert. Zwischen „funktioniert in der Demo" und „läuft verlässlich im Tagesgeschäft" liegt ein Tal, das kein Modell-Update zuschüttet. Wer es nicht benennt, plant es nicht ein — und scheitert leise. Der Pilot gehört der Innovationsabteilung. Der Betrieb gehört, wenn man nicht aufpasst, niemandem.

Die ehrliche Frage dieser Station ist organisatorisch, nicht technisch: Wer trägt diesen Agenten um 3 Uhr nachts, wenn er Unsinn produziert? Gibt es darauf keinen Namen, ist alles Weitere Theater. Ein Agent braucht einen Eigentümer mit Pager, bevor er den ersten Kunden sieht — und der Eigentümer sitzt in der Geschäftsführung, nicht bei „der IT". Verantwortung lässt sich nicht an ein Modell delegieren.

→ tiefer: Warum KI-Piloten im Mittelstand nie in Produktion gehen — die Betriebslücke

Station 2 — Observability: Agenten sind still falsch

Bevor man irgendetwas verbessern kann, muss man es sehen. Und Agenten haben eine perfide Eigenschaft: Sie crashen nicht laut. Eine klassische App wirft einen 500er, und der Bereitschaftsdienst klingelt. Ein Agent liefert selbstbewusst die falsche Rechnung — perfekt formuliert, vollständig erfunden, und keiner merkt es wochenlang. Das ist der Unterschied zwischen „kaputt" und „still falsch".

Deshalb steht Observability ganz vorn im technischen Teil. Ohne Logs, Traces und systematische Stichproben fliegt man im Nebel: Man kann nur abstellen, was man sieht. Die Frage hier lautet schlicht Würde ich es überhaupt merken? — und solange die Antwort „vermutlich nicht" ist, ist Skalierung fahrlässig. Owner: Engineering, mit der Fachabteilung als Stichproben-Geber, die „auffällig" von „korrekt" unterscheiden kann.

→ tiefer: KI-Agenten im Betrieb überwachen — das Problem mit „still falsch"

Station 3 — Evals als Gates: Ketten multiplizieren Fehler

Wer sehen kann, kann messen. Erst jetzt — nicht früher — lassen sich Qualitätsschwellen setzen, die schlechte Versionen blockieren, bevor sie den Kunden erreichen. Der Hebel dahinter ist Mathematik: Ein Agent, der pro Schritt zu 95 % richtig liegt, liegt über fünf Schritte nur noch zu rund 77 % richtig. Ketten multiplizieren Fehler, sie addieren sie nicht.

Evals machen aus „fühlt sich besser an" ein Tor, das man passieren muss — kein Bericht fürs Meeting, sondern ein Schleusentor vor dem Release. Die Frage ist Welche Antworten lasse ich nie durch? — und die beantwortet die Fachabteilung (sie definiert „richtig"), während Engineering die Prüfung automatisiert.

→ tiefer: wie man so ein Gate baut, das wirklich blockiert statt nur zu berichten — Evals als Gates und Ketten-Zuverlässigkeit erzwingen

Station 4 — Sicherheit: jeder Input wird zum Befehl

Sobald ein Agent Werkzeuge bedient — E-Mails liest und sendet, Datenbanken abfragt und schreibt, Aktionen auslöst — wird jeder Input ein potenzieller Befehl. Prompt-Injection ist kein Rand-Risiko, sondern die neue Angriffsfläche: die SQL-Injection dieser Generation. Eine manipulierte Eingabe kapert die Handlung, und der Agent führt sie gehorsam aus, weil er Daten und Anweisungen nicht zuverlässig auseinanderhält.

Diese Station kommt bewusst an vierter Stelle: Man kann erst absichern, was man beobachtet (Station 2) und gegated (Station 3) hat. Die Leitfrage ist die nach dem Schaden: Was kann dieser Agent im schlimmsten Fall anrichten — und wer hat das genehmigt? Die Kunst ist, den Werkzeug-Zugriff einzudämmen, ohne den Agenten zu lähmen. Owner: Security gemeinsam mit den Fachverantwortlichen — Sicherheit ist hier keine Mauer drumherum, sondern eine Eigenschaft des Entwurfs.

→ tiefer: Der verwirrte Stellvertreter — Prompt-Injection und wie man Agenten absichert

Station 5 — Autonomie bewusst dosieren

Am Ende steht kein Schalter, sondern ein Regler. Autonomie ist nichts, was man an- oder ausstellt — man dreht sie schrittweise auf, exakt so weit, wie die ersten vier Stationen es tragen. Man beginnt beim Vorschlag, geht zum Entwurf-mit-Freigabe, dann zum Handeln im engen Korridor. Mehr Freiheit gibt man nur dem System, das man sehen, messen und absichern kann.

Der teuerste Fehler ist, den Regler hochzudrehen, weil die Roadmap es verlangt — statt weil die Evals es erlauben. Die Frage dieser Station: Welche Entscheidung darf der Agent allein treffen, und welche legt er einem Menschen vor? Owner ist der Prozess-Eigner, der den Korridor verantwortet. Autonomie ohne die vier Stufen darunter ist ein Werkzeugkasten in fremder Hand.

→ tiefer: Das Autonomie-Spektrum — Stufen für den Mittelstand und wann man weiterdreht

Die wiederkehrenden Anti-Patterns

Dieselbe Reise scheitert immer an denselben Stellen. Wer sich hier wiedererkennt, hat schon die halbe Diagnose:

1. Die Demo-Fixierung. Der Pilot wird auf den glücklichen Pfad optimiert: saubere Eingaben, freundliche Fragen, kuratierte Daten. Produktion ist der unglückliche Pfad — der Tippfehler, das leere Feld, die widersprüchliche Anweisung. Korrektur: Bewerten Sie einen Piloten nie an seinem besten Tag, sondern an seinem zehntschlechtesten.
2. Niemand owned den Betrieb. Es gibt keinen Bereitschaftsdienst für einen Agenten, der höflich Unsinn produziert. Korrektur: erst der Name, dann der Kunde.
3. Kein Tracing, keine Evals. „Still falsch" bleibt wochenlang unbemerkt, weil niemand hinschaut. Korrektur: Observability vor Skalierung.
4. Evals als Kür statt Pflicht. Ein Eval-Set, das niemanden blockiert, ist Dekoration. Korrektur: Das Gate hat Veto-Recht über den Release.
5. Sicherheit als Nachgedanke. Tool-Zugriff zuerst, Absicherung „später". Korrektur: Behandeln Sie jeden Modell-Output als nicht vertrauenswürdig, bevor er eine Aktion auslöst.
6. Autonomie zu hoch gedreht. Der Regler springt auf „voll", weil es mutiger aussieht. Korrektur: Hochdrehen, wenn die Evals halten — nicht wenn die Präsentation es verlangt.

Der praktische Fahrplan

Die fünf Stationen sind keine Menüauswahl, sondern eine Treppe. So geht man sie konkret:

• Noch vor Stufe 1: den richtigen Use-Case wählen. Diese Treppe lohnt sich nur, wenn der Pilot überhaupt der richtige war. Welchen Vorgang ein Mittelständler zuerst angeht — und warum der sichtbarste fast immer der falsche ist — steht in Welchen KI-Use-Case zuerst?.
• Pro Stufe ein Name. Bevor die Technik kommt, klären Sie Eigentum — eine Stufe, ein Owner, eine Leitfrage (siehe Tabelle oben). Ohne Namen bleibt jede Maßnahme Theater.
• Eine Stufe nach der anderen. Observability vor Evals (Sie können nicht messen, was Sie nicht sehen). Evals vor Autonomie (Sie geben keine Kontrolle ab ohne Schleusentor). Wer Stufe 5 zuerst angeht, baut einen schnellen, unkontrollierten Fehler.
• Werkzeuge anschlussfähig halten. Lock-in ist ein Betriebsrisiko, kein Komfortthema — offene Standards halten die Tür offen. Mehr dazu in MCP: der Werkzeug-Standard ohne Lock-in.
• Die Frage „wo läuft das?" früh stellen. Datenresidenz und Kontrolle gehören in die Architektur, nicht ans Ende. Siehe Wo Mittelstands-KI laufen sollte.
• Wenn intern die Kapazität fehlt: Die Treppe lässt sich begleiten. Unser Ansatz steht in der KI-Beratung für den Mittelstand und in The azena Way.

Die Pointe

Kein Modell macht diese Reise überflüssig — es verschiebt nur den Startpunkt. Für den Mittelstand ist das eine gute Nachricht: Es braucht kein Forschungslabor, sondern einen Namen pro Stufe und die Demut, die nächste erst zu betreten, wenn die vorige trägt. Die kurzen Wege, die klare Verantwortung und die echte Prozesskenntnis, die mittelständische Häuser auszeichnen, sind genau das, was Betrieb braucht.

Die Konkurrenz, deren Pilot in der Schublade verstaubt, hat keine schlechteren Modelle. Sie hat nur nie die Treppe gebaut. Verlässlichkeit wird gebaut, nicht gekauft — eine Stufe nach der anderen. Wählen Sie eine Tür; die Landkarte wartet.

Schwester-Landkarten: [Souveräne KI im Mittelstand](/blog/souveraene-ki-mittelstand-landkarte) · davor die [Adoptions-Landkarte](/blog/ki-mittelstand-einfuehren-adoptions-landkarte) (welchen Use-Case zuerst, mit wem, wie schnell).