Ein AI-Agent wird nicht produktionsreif, weil das verwendete Modell überzeugend formuliert. Er wird produktionsreif, wenn Aufgabe, Datenzugriff, Werkzeugrechte, Kosten und Abbruchverhalten technisch kontrolliert und mit repräsentativen Fällen geprüft werden.
Die entscheidende Einheit ist nicht der Prompt. Es ist der kontrollierte Arbeitsablauf um das Modell.
Diese Perspektive ist besonders wichtig, sobald ein Agent nicht nur Text erzeugt, sondern Dokumente abruft, Code analysiert, Tickets verändert, externe Systeme anspricht oder Sicherheitswerkzeuge ausführt.
Ein klares Ziel und ein expliziter Zustand
„Bearbeite diese Aufgabe“ ist für einen produktiven Agenten zu ungenau. Das System braucht definierte Zustände: noch nicht begonnen, Daten fehlen, Werkzeug läuft, Ergebnis muss geprüft werden, abgeschlossen oder kontrolliert abgebrochen.
Jeder Zustand beantwortet drei Fragen:
- Welche Informationen liegen bereits vor?
- Welche nächste Aktion ist erlaubt?
- Woran erkennt das System Erfolg oder einen sicheren Abbruch?
Ohne dieses Zustandsmodell wiederholt ein Agent Arbeit, überspringt notwendige Prüfungen oder liefert trotz fehlender Informationen ein scheinbar fertiges Ergebnis. Ein expliziter Zustand macht Wiederaufnahme, Monitoring und Fehleranalyse möglich.
Werkzeuge benötigen kleine Verträge
Ein Werkzeug sollte genau eine verständliche Aufgabe erfüllen. Eingaben werden gegen ein Schema validiert, Ausgaben normalisiert und Fehler eindeutig zurückgegeben. Der Agent darf nicht selbst entscheiden, welche beliebigen Befehle auf einem System ausgeführt werden.
Ein sinnvoller Werkzeugvertrag beschreibt:
- zulässige Parameter und Wertebereiche
- benötigte Rolle und Datenklasse
- maximale Laufzeit und Ergebnismenge
- mögliche Seiteneffekte
- protokollierte Ein- und Ausgaben
- Verhalten bei Fehlern oder unvollständigen Ergebnissen
Schreibende oder irreversible Aktionen gehören hinter eine zusätzliche Freigabe. Bei einem Support-Agenten kann das der Versand einer Nachricht sein. Bei einem Entwicklungsagenten betrifft es Änderungen an produktiven Daten oder Deployments. Bei einem Pentest-Agenten sind Zielsystem, erlaubte Werkzeuge und Testregeln verbindliche Grenzen.
Minimale Rechte statt geteilter Systemzugänge
Der Agent erhält nicht die Rechte eines Entwicklers oder Administrators. Jedes Werkzeug arbeitet mit dem kleinsten erforderlichen Zugriff. Mandant, Benutzerrolle und Projektkontext werden vom System vorgegeben und nicht aus einer Modellantwort übernommen.
Das verhindert eine häufige Fehlannahme: Ein korrekt authentifizierter Agent ist nicht automatisch für jede Aktion autorisiert. Dieselben Regeln, die für Benutzer gelten, müssen auch bei indirekten Aufrufen über Modell und Werkzeug durchgesetzt werden.
Kosten und Laufzeit sind Teil der Sicherheitsgrenze
Ein Agent kann auch ohne klassischen Angriff Schaden verursachen: durch Endlosschleifen, unnötige Suchvorgänge, große Kontexte oder wiederholte externe Aufrufe. Deshalb braucht jeder Lauf ein technisches Budget.
Typische Grenzen sind:
- maximale Anzahl von Modell- und Werkzeugaufrufen
- Token-, Zeit- und Kostenbudget
- Höchstzahl gleichartiger Wiederholungen
- maximale Größe geladener Dokumente
- feste Eskalation bei fehlenden Informationen
Wird eine Grenze erreicht, endet der Lauf nicht mit einer erfundenen Antwort. Er hinterlässt einen nachvollziehbaren Zwischenstand und nennt den Grund für den Abbruch.
Evals prüfen Aufgaben statt Formulierungen
Ein einzelner guter Testprompt ist kein Qualitätsnachweis. Vor der Umsetzung werden repräsentative Aufgaben, schwierige Randfälle und unerlaubte Aktionen gesammelt. Dieses Referenzset wird bei Änderungen an Prompt, Modell, Retrieval oder Werkzeugen erneut ausgeführt.
Je nach Anwendung sind unter anderem folgende Messwerte relevant:
- fachlicher Aufgabenerfolg
- korrekter Quellenbezug
- unerlaubte oder unnötige Werkzeugaufrufe
- Einhaltung von Rollen und Freigaben
- Fehlerrate und kontrollierte Abbrüche
- Laufzeit und Kosten pro erfolgreicher Aufgabe
Bei einem RAG-System reicht es beispielsweise nicht, dass eine Antwort korrekt wirkt. Das System muss die passende Quelle verwenden, Unsicherheit kenntlich machen und bei fehlender Grundlage nicht frei ergänzen. Bei einem Agenten zählt zusätzlich, ob der Weg zum Ergebnis zulässig war.
Menschen entscheiden an den teuren Grenzen
Menschliche Freigabe sollte nicht pauschal nach jedem Schritt verlangt werden. Das würde den Nutzen der Automatisierung zerstören. Sie gehört an Stellen mit hoher Auswirkung oder schwerer Umkehrbarkeit.
Beispiele sind externe Kommunikation, Vertrags- oder Rechtsentscheidungen, Änderungen an produktiven Daten, Deployments und aktive Security-Tests. Die Oberfläche muss zeigen, welche Daten und Zwischenschritte zur vorgeschlagenen Aktion geführt haben. Eine Schaltfläche „Bestätigen“ ohne Kontext ist keine sinnvolle Kontrolle.
Lokale Modelle lösen ein Datenproblem, nicht automatisch ein Qualitätsproblem
Lokale Inferenz verhindert, dass vertraulicher Code, juristische Dokumente oder Schwachstellendaten für den Modellaufruf an einen externen Anbieter übertragen werden. Das ist für viele Projekte ein entscheidender Vorteil.
Die lokale Ausführung ersetzt jedoch keine Qualitätsprüfung. Modellgröße, Quantisierung, Kontext, Retrieval und Werkzeugdesign beeinflussen das Ergebnis. Deshalb wird mit realen Aufgaben verglichen, welches Modell die benötigte Qualität innerhalb von Speicher-, Laufzeit- und Kostenrahmen erreicht.
In der Praxis kann ein getrennter Ablauf sinnvoll sein: sensible Inhalte bleiben lokal, während unkritische Entwicklungs- oder Dokumentationsaufgaben ein leistungsfähiges Frontier-Modell nutzen. Entscheidend ist eine verbindliche Datenklassifizierung pro Arbeitsschritt.
Checkliste vor dem produktiven Einsatz
- Aufgabe und Erfolg sind fachlich definiert.
- Zustände, Wiederaufnahme und Abbruch sind implementiert.
- Werkzeuge besitzen validierte Verträge und minimale Rechte.
- Schreibende oder irreversible Aktionen benötigen eine passende Freigabe.
- Zeit-, Token-, Kosten- und Wiederholungsbudgets sind technisch begrenzt.
- Repräsentative Erfolgs-, Fehler- und Missbrauchsfälle laufen automatisiert.
- Modell-, Prompt-, Retrieval- und Werkzeugversionen sind nachvollziehbar.
- Protokolle enthalten genug Kontext für Fehleranalyse, aber keine unnötigen sensiblen Daten.
- Lokale und externe Modellaufrufe folgen einer dokumentierten Datenregel.
- Ein verantwortlicher Mensch kann jeden Lauf stoppen und bewerten.
Fazit
Ein Agent ist dann produktionsreif, wenn sein Verhalten auch bei fehlenden Informationen, Werkzeugfehlern und unerlaubten Aufgaben vorhersehbar bleibt. Das beste Modell kann diese Systemarbeit nicht ersetzen. Ein kleinerer Agent mit klaren Werkzeugen, guten Evals und kontrollierten Zuständen ist für ein Unternehmen oft wertvoller als eine beeindruckende Demo mit weitreichenden Rechten.