Du hast zwei oder drei Agenten in Produktion. Einer beantwortet Kundenanfragen, einer bereitet Dokumente auf, vielleicht schiebt ein dritter Daten zwischen Systemen. Sie funktionieren. Und genau dann, wenn sie zu funktionieren beginnen, sagt dir jemand, du bräuchtest jetzt „AgentOps“. Du schaust nach, und was du findest, setzt einen Kubernetes-Cluster voraus, eine interne Plattform, ein eigenes Team und ein Observability-Budget, das es in deinem Unternehmen nicht gibt und nicht geben wird.
Die These in einem Satz: Fast alles, was über AgentOps veröffentlicht wird, ist aus dem Unternehmen heraus geschrieben, das die Plattform verkauft — und verwechselt deshalb Infrastruktur mit Kontrolle. Was einen kleinen Betrieb wirklich schützt, sind nicht die Werkzeuge: es sind fünf Entscheidungen, und alle fünf lassen sich ohne eine einzige Neueinstellung treffen.
AgentOps für KMU: warum die Frameworks sich nicht eins zu eins übertragen lassen
AgentOps heißt in seiner vernünftigen Definition: den Lebenszyklus eines Agenten in Produktion betreiben — versionieren, beobachten, bewerten, eingrenzen, was er darf, und reparieren, wenn er sich verschlechtert. Diese Aussage ist richtig und gilt für ein Unternehmen mit zwölf Leuten genauso wie für eines mit zwölftausend. Was nicht gleich gilt, ist die Umsetzung.
Die kursierenden Frameworks stammen von Infrastrukturherstellern und schleppen deren Annahmen mit: dass du Container-Orchestrierung hast, dass ein Plattform-Team einen Observability-Stack aufsetzen kann, dass es einen Deployment-Zyklus mit getrennten Umgebungen gibt und dass jemand Wochen fürs Instrumentieren übrig hat. Liest ein KMU das, zieht es einen von zwei Schlüssen, und beide sind schlecht: entweder „das ist nichts für mich, schaue ich später an“ oder „gut, dann bauen wir die Plattform“ — also beim Dach anfangen und das Budget verbrennen, bevor die erste Kontrolle steht.
Der eigentliche Fehler ist, AgentOps als Technologieschicht zu behandeln, obwohl es im kleinen Betrieb vor allem eine Entscheidungsschicht ist. Die nützliche Frage lautet nicht „welche Plattform baue ich?“, sondern „was darf dieser Agent tun, ohne dass es jemand freigibt, und wie erfahre ich, wenn etwas schiefläuft?“. Diese Frage beantwortet man mit und ohne Kubernetes gleich.
Die fünf Kontrollen, die du wirklich brauchst (und wo sie im KMU leben)
Diese fünf Kontrollen decken den größten Teil des realen Risikos beim Betrieb von Agenten ab. Keine verlangt eine eigene Plattform; alle verlangen, dass jemand entscheidet und es aufschreibt.
| Kontrolle | Was sie verhindert | KMU-Version: wo sie lebt |
|---|---|---|
| Agenten-Identität | Dass ein kompromittierter oder verwirrter Agent die Schlüssel zu allem hat | Ein eigener technischer Nutzer je Agent in jedem System, minimale Rechte, nicht der Admin-Account |
| Leitplanken | Dass er die unumkehrbare Aktion allein ausführt: zahlen, löschen, den Kunden anschreiben, veröffentlichen | Kurze Liste der Aktionen mit menschlicher Freigabe, geschrieben bevor irgendetwas verbunden wird |
| Spur | Dass niemand erklären kann, warum der Agent tat, was er tat | Ein Eintrag je Fall mit Eingabe, Anweisungsversion und Ausgabe — und sei es eine Tabelle |
| Kostenkontrolle | Dass die Anbieterrechnung zum Monatsende überrascht | Ausgabelimit je Agent und Alarm über der Tagesschwelle, in der Konsole des Anbieters |
| Mensch im Regelkreis | Dass ein kleiner Fehler sich tausendfach vervielfacht, bevor jemand hinsieht | Ein Prüfpunkt, an dem jemand eine Stichprobe sieht und den Agenten mit einem Klick stoppen kann |
1. Eigene Identität je Agent
Der häufigste und am billigsten zu behebende Fehler: Der Agent läuft mit den Zugangsdaten von jemandem —meist dem, der ihn gebaut hat— und kann daher alles, was diese Person kann. Gib jedem Agenten seinen eigenen Nutzer im CRM, in der Mail, im ERP, mit genau den Rechten seiner Aufgabe. Wenn ein Agent nur Bestellungen lesen soll, darf er sie nicht löschen können. Eine halbe Stunde Konfiguration — und der Unterschied zwischen einem eingegrenzten Vorfall und einem, der dich zwingt, alles zu prüfen.
2. Leitplanken: die Liste dessen, was nie allein läuft
Bevor du einen Agenten an ein echtes System hängst, schreib die Liste der Aktionen auf, die er nie ohne ein menschliches Ja ausführt: Geld bewegen, Datensätze löschen, einen Kunden zum ersten Mal anschreiben, nach außen veröffentlichen, Preise ändern. Die Liste muss kurz sein —bei zwanzig Zeilen hält sich niemand daran— und vorher geschrieben werden, nicht nach dem ersten Schreck. Es ist dasselbe Kriterium wie bei der Automatisierung jedes Prozesses: wir entfalten es im Leitfaden zu Governance und Kontrolle der KI-Automatisierung.
3. Spur: ein Eintrag je Fall, und sei es eine Tabelle
Du brauchst keine Observability-Plattform, um eine Spur zu haben. Du brauchst, dass jede Handlung des Agenten eine Zeile mit vier Dingen hinterlässt: was hereinkam, welche Anweisungsversion aktiv war, was er tat und was herauskam. Damit kannst du einen Fall rekonstruieren, wenn ein Kunde reklamiert — und, im Alltag wichtiger, unterscheiden, ob ein Fehler vom Modell, von den Daten oder von einer schlecht geschriebenen Anweisung kommt. Ohne diesen Eintrag ist jede Diskussion darüber, warum der Agent versagt hat, Meinung.
4. Kostenkontrolle, bevor die Rechnung kommt
Ein Agent in der Schleife kann an einem Nachmittag das Quartalsbudget verbrauchen. Nichts Aufwendiges nötig: Ausgabelimit je Agent in der Anbieterkonsole, Alarm, wenn der Tagesverbrauch aus dem gewohnten Band läuft, und eine Referenzzahl —was ein gelöster Fall kostet—, um sagen zu können, ob es sich rechnet. Diese Zahl macht aus „KI ist teuer“ außerdem eine Entscheidung.
5. Mensch im Regelkreis, aber mit Stichprobe
Der KMU-Fehler ist hier binär: entweder alles prüfen (dann spart der Agent nichts) oder nichts prüfen (dann entdeckt der Kunde den Fehler). Die Version, die funktioniert, liegt dazwischen: vollständige Prüfung, solange die Trefferquote nicht stabil ist, danach Stichprobe —ein zufälliger Anteil der Fälle plus hundert Prozent derer, die der Agent selbst als zweifelhaft markiert—. Wie dieser Prüfpunkt entworfen wird, steht im Leitfaden zu Mensch im Regelkreis bei der KI-Automatisierung.
Die Reihenfolge zählt: womit anfangen
Wer alle fünf gleichzeitig angeht, bringt keine zu Ende. Das ist die Reihenfolge, die im kleinen Betrieb trägt, vom Dringendsten abwärts:
- Identität und minimale Rechte je Agent. Am billigsten und nimmt das meiste Risiko.
- Die Liste der Aktionen mit Freigabepflicht. Eine halbe Seite, entschieden von der Prozessverantwortung.
- Der Eintrag je Fall. Auch wenn er als Tabelle beginnt, gefüttert vom Ablauf selbst.
- Ausgabelimit und Alarm. Zehn Minuten in der Anbieterkonsole.
- Die Prüf-Stichprobe. Wird mit den Daten der ersten Wochen justiert, nicht vorher.
Wann du die große Version wirklich brauchst
Nichts davon heißt, dass Infrastruktur nie zählt. Es gibt konkrete Signale, dass dir der manuelle Ansatz zu klein geworden ist, und es lohnt sich, sie früh zu erkennen:
- Du überschreitest ein Dutzend Agenten und weißt nicht mehr auswendig, was jeder tut und wer für ihn geradesteht.
- Die Agenten rufen einander auf, ein Fehler in einem pflanzt sich fort und die Spur je Fall reicht nicht mehr.
- Du arbeitest in einer regulierten Branche oder triffst Entscheidungen über Menschen: dort ist die Spur keine gute Praxis mehr, sondern Pflicht mit Aufbewahrungsfrist.
- Die monatlichen Modellkosten sind in der Gewinn- und Verlustrechnung sichtbar und müssen je Prozess zugeordnet werden, nicht je Anbieter.
- Mehr als ein Team fasst dieselben Agenten an und Änderungen überschreiben sich.
Treten zwei oder drei dieser Signale zusammen auf, ist die Arbeit keine Konfiguration mehr, sondern Wartung: Versionen, laufende Bewertung, zugewiesene Verantwortliche und ein Verbesserungszyklus. Diesen Sprung behandeln wir im Leitfaden zur Wartung deiner KI-Automatisierungen, und die Frage, wer es macht —du, jemand aus deinem Team oder jemand von außen—, entfalten wir in wer deine KI-Agenten wartet.
Was AgentOps für KMU nicht ist
Es ist nicht der Kauf eines Werkzeugs, auf dessen Preisseite „AgentOps“ steht. Fast alle sind in einer der fünf Sachen gut —meist der Spur— und lassen dir die anderen vier, die ohnehin deine Entscheidungen sind. Es ist auch kein zwanzigseitiges Richtlinienpapier, das niemand liest. Und es ist nicht, zu warten, bis du jemanden für die Plattform hast: wenn du darauf wartest, laufen deine Agenten monatelang in Produktion ohne eine einzige der fünf Kontrollen — genau das Szenario, vor dem alle warnen.
Die ehrliche Version für ein kleines Unternehmen passt in einen Nachmittag Entscheidungen und ein paar Stunden Konfiguration: jeder Agent mit eigener Identität, eine kurze Liste dessen, was er nie allein tut, ein Eintrag je Fall, ein Ausgabelimit und ein Prüfpunkt mit Stichprobe. Das ist nicht glamourös und sieht keinem Architekturdiagramm ähnlich. Aber es sorgt dafür, dass du in sechs Monaten erklären kannst, was dein Agent getan hat und warum — das Einzige, wonach man dich fragen wird.