KI-Agenten als Service betreiben: sieben Disziplinen

Eine Anzeige, die grün zeigt, während dahinter etwas nicht läuft: So fing es bei meinen KI-Agenten an. Ich betreibe sie so, wie ein IT-Betrieb seine Services betreibt. Sieben Gewohnheiten aus dem Betrieb, jede an einem Fall aus meinem Alltag erklärt, eine Karte zum Ausfüllen, und die Frage, wer am Ende die Verantwortung trägt.

Eine grüne Anzeige beruhigt, weil niemand mehr hinsehen muss. Gefährlich wird sie, wenn das Grün nur bedeutet, dass keine Fehlermeldung eingegangen ist. Dann leuchtet sie weiter, während dahinter etwas längst nicht mehr läuft.

Genau das ist mir mit meinen KI-Agenten passiert. Jeden Morgen liegt ein Bericht bereit, den ich lese. An einem Morgen stand darin, dass keine Routine fehlgeschlagen sei. Tatsächlich war die Sicherung meiner Datenbank am Vortag ausgefallen. Die Fehlermail, die der Ausfall hätte auslösen sollen, kam nie an, und der Bericht kannte nur eine Quelle, die Liste der Fehlermeldungen. Darin kam die Sicherung gar nicht vor. Der Bericht las also eine leere Liste und meldete, was eine leere Liste hergibt: alles in Ordnung. Dass die Sicherung gefehlt hatte, fiel nur auf, weil jemand nachgesehen hat.

Ein Agent ist bei mir ein KI-Programm mit einer festen Aufgabe, so wie ein Mitarbeiter eine Rolle hat. Einer prüft Code, einer schreibt Entwürfe, einer sucht Fundstellen. Darunter laufen einfache Programme ohne KI, sogenannte Skripte, die nur melden, was passiert ist; der Morgenbericht ist so eines. Am Ende entscheide ich, so wie in der Softwareentwicklung der Product Owner entscheidet, was gebaut wird, und sich vom Team berichten lässt. Mein Team besteht nur eben aus Agenten. Ich arbeite dabei mit Claude Code, aber an dem Werkzeug hängt nichts von dem, was hier steht.

Darauf läuft der Beitrag hinaus: Ein Agent ist kein Werkzeug, das man benutzt und weglegt. Er ist ein Service, der läuft, und um einen Service muss sich jemand kümmern. Der IT-Betrieb hat dafür seit Jahrzehnten Gewohnheiten mit Namen. Du willst wissen, ob etwas läuft, ohne dass sich jemand beschwert? Bei mir heißt das Morgenbericht, im IT-Betrieb heißt das Event- und Monitoring-Management. Sieben dieser Gewohnheiten erkläre ich hier an den Fällen aus meinem Betrieb. Es ist ein Werkstattbericht: So sieht mein Betrieb gerade aus, mitten im Bau, mit den Stellen, an denen es noch klemmt.

Woher weiß ich, dass etwas läuft? (Event- und Monitoring-Management)

Überwachung heißt im IT-Betrieb, dass laufend jemand hinsieht, ob ein Service seine Arbeit tut, und nicht erst, wenn sich jemand beschwert. Mein Bericht hatte hingesehen, nur an der falschen Stelle, denn eine Liste, in der die Sicherung nicht vorkommt, kann ihren Ausfall nicht melden. Deshalb prüft der Bericht heute selbst, wie alt die letzte Sicherung ist. Ein Bericht, der „alles gut“ sagen darf, braucht eine zweite Quelle.

Ähnlich ging es mit dem Zeitplan, der meine Routinen startet. Er meldete einen Lauf als erfolgreich, obwohl der nach wenigen Sekunden zu Ende war und nichts getan hatte. Beendet war er ja, nur ohne Ergebnis. Eine Meldung wie „beendet“ sagt eben nur, dass etwas zu Ende ging. Was ich brauche, ist ein Beleg dafür, dass etwas entstanden ist, etwa eine Datei oder ein Eintrag mit Datum. Deshalb schreibt jede wiederkehrende Routine am Ende auf, was sie erreicht hat, und „nichts erreicht“ gilt als Störung. Und ein fehlender Wert darf auf der Anzeige nie grün sein, sondern muss als unbekannt erscheinen.

Läuft es wieder, oder passiert es nicht wieder? (Incident und Problem Management)

Eine Störung heißt im IT-Betrieb Incident, und ein Incident gilt als erledigt, sobald der Service wieder läuft. Bei mir lief die Sicherung am nächsten Tag wieder durch, die Störung war also behoben. Damit war aber noch nichts darüber gesagt, warum niemand etwas gemerkt hatte. Diese Frage nach der Ursache nennt der Betrieb das Problem, und sie macht den Unterschied zwischen „läuft wieder“ und „passiert nicht wieder“. Bei mir hatte das zwei Ursachen: Der Bericht hatte nur eine Quelle, und die Fehlermail war nicht angekommen. Dabei habe ich gemerkt, dass ich einen Meldeweg, auf den ich mich verlasse, besser einmal probeweise auslöse, statt erst im Ernstfall zu erfahren, ob er funktioniert. Die Störung zu beheben ist also der kleinere Teil. Die Ursache zu finden braucht einen Beleg statt einer Vermutung, und bei mir lag sie beide Male in der Art, wie ich den Betrieb aufgesetzt hatte, nicht im KI-Modell.

Wer darf was ändern? (Change Enablement)

Jede Änderung an einem laufenden Service heißt im IT-Betrieb Change, und es gibt Regeln, wer einen Change wann freigibt. Bei mir brauchte am Anfang jede Änderung mein Ja im Einzelfall, und das war richtig, solange ich nichts gemessen hatte. Dann führte mein Betrieb ein Tagesrelease ein. Vorgesehen war, dass geprüfte Änderungen ohne Risiko, also Texte, Dokumentation und Einstellungen, am Abend gesammelt und mir in einer Mail gezeigt werden und am nächsten Tag live gehen, wenn ich nicht widerspreche. Alles, was die Datenbank, die Bezahlung oder die Anmeldung berührt, blieb beim Ja im Einzelfall.

Für Änderungen, die immer gleich ablaufen und wenig Risiko haben, kennt der IT-Betrieb den Standard Change: einmal genehmigt, danach ohne Einzelfreigabe. Bei mir sind das die Dauerfreigaben, jede mit Datum eingetragen, für einen eng umrissenen Fall und jederzeit zurückzuholen. Mein erster Standard Change war ein eigener Weg für kleine Fehlerbehebungen. Die Automatik prüfte bei jedem Lauf, ob eine Änderung dafür infrage kommt, und fand nie eine, bis der Weg abgeschaltet wurde. Ein Weg, den niemand geht, bringt nichts und kann trotzdem Fehler verursachen. Auch das Tagesrelease ist inzwischen abgeschaltet, und einige Dauerfreigaben habe ich zurückgenommen; das Datum am Eintrag zeigt mir, seit wann eine gilt und wann ich sie wieder prüfen sollte.

Bevor die Freigaben umgebaut wurden, hatte ich nachmessen lassen, wen sie eigentlich belasten. Nicht zu viele Freigaben waren das Problem, sondern zu wenige Antworten, und die Antworten kommen von mir. Daraus wurden drei Arten von Arbeit: was ohne mein Ja laufen darf und mir hinterher berichtet wird, was vorbereitet wird und als Paket mit kurzer Beschreibung zu mir kommt, und was nie ohne mein Ja geschieht, nämlich Code der Plattform, Preise, Zahlungen, Veröffentlichen und Kundenkontakt.

Was passiert, wenn der Betrieb ausfällt? (Service Continuity)

Ein Betrieb, der an einer einzigen Stelle hängt, steht still, sobald diese Stelle ausfällt. Die Vorsorge dagegen heißt im IT-Betrieb Service Continuity. Mein Betrieb hat dafür eine Vertretung in der Cloud. Sie sieht regelmäßig nach, wann sich der laufende Betrieb zuletzt gemeldet hat, und springt ein, wenn das länger her ist als eine festgelegte Schwelle. Einmal blieb die Meldung länger aus als geplant, und die Vertretung tat nichts, weil ihre Schwelle knapp über der Länge der Pause lag. Eine Schwelle, die noch nie ausgelöst hat, ist ungetestet, auch wenn sie richtig eingestellt aussieht. Geprobt wurde danach die Übernahme selbst, indem ein Ausfall unterstellt und die Vertretung laufen gelassen wurde. Sie übernahm, las aber die Dateien, die sie lesen muss, nur oberflächlich, und von zwei Wegen, auf denen sie Befehle ausführt, funktionierte in der Cloud nur einer. Die Schwelle ist damit immer noch nicht getestet. Der Eintrag danach hält den Satz fest, der jetzt gilt: Der erste echte Ausfall soll nicht der erste Test sein.

Ein zweiter Fall: An zwei Abenden blieb die Abendmail aus, die mir den Tag zusammenfasst, weil Entwicklungsarbeit das wöchentliche Kontingent an KI-Aufrufen aufgebraucht hatte. Daraus wurde eine Regel: Die Entwicklung hört vor einer Reserve auf, und die Reserve gehört den Läufen, die jeden Tag stattfinden müssen. Beim nächsten Engpass hat die Regel nicht gereicht, und die Abendmail fiel wieder aus. Die Reserve wirklich zu schützen ist bei mir noch offen. Dass man Projektarbeit von Betriebsarbeit trennen muss, bringe ich anderen bei; in meinem eigenen Betrieb ist es noch nicht fertig.

Als Nächstes kommt die Probe, ob sich aus der Sicherung tatsächlich etwas wiederherstellen lässt. Dafür ist in meinem Betrieb eine eigene Abteilung für Backup und Hardening im Aufbau, also für Sicherung und Absicherung, und sie ist noch nicht fertig.

Was bleibt von einer Störung übrig? (Wissensmanagement und kontinuierliche Verbesserung)

Eine Störung, die behoben ist, aber nirgends aufgeschrieben steht, kommt wieder, und dann beginnt die Suche von vorn. Deshalb bekommt bei mir jede Störung einen Eintrag mit Datum, Ursache, einem Warum und einem Anwenden, also was ab jetzt gilt und woran man den Fall wiedererkennt.

Als zwei Prüfagenten das ganze System deutlich schlechter bewerteten als die Selbsteinschätzung davor, lag der Grund an derselben Stelle wie bei der Vertretung. Es ist leicht, gebaut mit belegt gelaufen zu verwechseln, und in meinem Betrieb war genau das passiert. Auch das steht jetzt als Eintrag da.

Ansehen und starten, Konto kostenlos

Wer liest gegen? (Review, Test und Pipeline)

Kein Entwurf wird bei mir zum Ergebnis, nur weil ein Agent ihn geschrieben hat. Ein zweiter Agent, der nur liest und nichts ändert, prüft ihn vorher, und zwar immer den letzten Stand, nicht den vor der letzten Korrektur. Vor einem Livegang fand er eine doppelte Begrüßung, beschädigte Formatierung und eine Einstellung, die Kosten ohne Obergrenze hätte verursachen können.

Eine Grenze sage ich offen. Wenn ein Agent in seine Änderung schreibt, dass sie geprüft wurde, ist das eine Selbstauskunft. Die automatischen Prüfungen, die vor jeder Veröffentlichung laufen, können nicht sehen, ob der Prüfer wirklich gelesen hat. Eine Anweisung im Auftrag ist kein Schloss, das etwas verhindert, sondern nur eine Bitte, und wo ich kein Schloss habe, sage ich das lieber, als mich auf die Zeile zu verlassen.

Wird die Plattform im laufenden Betrieb besser? (Produktverbesserung)

Meine Lernplattform war eine Zeit lang langsam, und aufgefallen ist das bei einer Probe, nicht an einer Kennzahl. Die Rechenleistung lag auf einem anderen Kontinent als die Datenbank, sodass jede Anfrage einen weiten Weg hatte. Wenn jemand ein Symptom spürt, nehme ich es deshalb ernst, auch wenn keine automatische Meldung kommt. Jede Verbesserung an der Plattform ist ein Change mit Ziel, Reihenfolge und Prüfung, und sie geschieht, während die Plattform läuft.

Die Betriebskarte

Im IT-Betrieb hat jeder Service ein Betriebshandbuch, in dem steht, wozu er da ist, wer ihn überwacht und was bei einem Ausfall zu tun ist. Die Betriebskarte ist davon eine Seite für eine einzelne KI-Routine, und wo ein Feld leer bleibt, steht die nächste Aufgabe. Unten ist sie für meine Abendmail ausgefüllt, so weit ich das ehrlich kann.

Betriebskarte für eine KI-Routine (Beispiel: meine Abendmail)

Feld	Gewohnheit (Fachname)	Abendmail
Wozu ist sie da? (ein Satz)	Berichten	fasst den Tag zusammen, zeigt offene Entscheidungen und was auf ein Ja wartet
Läuft sie mit KI?	Überwachen (Monitoring)	ja
Was startet sie? (Zeitplan, Ereignis, Mensch)	Überwachen (Monitoring)	der Zeitplan, am Abend
Was darf sie allein tun? (lesen, vorbereiten, ausführen)	Änderungen freigeben (Change Enablement)	lesen und berichten; schreibt nur an mich selbst
Woran sehe ich, dass sie gelaufen ist? (Datei oder Eintrag, nicht die Meldung des Zeitplans)	Überwachen (Monitoring)	an einem Sendevermerk mit Datum, nicht an der Meldung des Zeitplans
Wer erfährt wie, wenn sie ausfällt?	Störungen beheben (Incident Management)	die Ersatzmail kommt erkennbar als Mail aus der Cloud; fehlen ihr Daten, nennt sie den Grund im Betreff; am nächsten Morgen meldet der Morgenbericht, dass keine Abendmail kam
Zweite Quelle für „alles gut“	Überwachen (Monitoring)	das, was die Routinen am Ende als erreicht aufschreiben, nicht ihre Meldung „beendet“
Wer springt ein?	Vorsorge für den Ausfall (Service Continuity)	eine Ersatzmail aus der Cloud, wenn der Sendevermerk fehlt oder zu alt ist
Was tut sie nie?	Änderungen freigeben (Change Enablement)	veröffentlicht nichts, ändert keine Daten, schreibt an niemanden außer mir
Letzte Störung und die Regel daraus	Ursachen finden, Wissen festhalten (Problem Management, Wissensmanagement)	die reguläre Abendmail blieb aus, weil das Wochenkontingent an KI-Aufrufen erschöpft war; die Ersatzmail aus der Cloud sprang ein, an manchen Abenden nur als Kurzmail mit dem Grund. Regel: Die Reserve für die täglichen Läufe muss auch im Engpass halten; das ist noch offen
Wer prüft das Ergebnis?	Gegenlesen (Review)	ich lese sie; eine Antwort darauf ist meine Entscheidung
Geprüft am	Verbessern	(Datum eintragen)

Direkt öffnen, ohne Konto

Wer trägt am Ende die Verantwortung?

Eines zieht sich durch alle sieben Gewohnheiten: Nicht die Agenten verantworten mein System, sondern ich. Als Leitlinie dafür nehme ich das AI-Fluency-Rahmenwerk von Rick Dakan und Joseph Feller mit seinen vier Kompetenzen, und ich übersetze sie so in meinen Betrieb. Delegation heißt entscheiden, welche Aufgabe an die KI geht und welche nicht; bei mir sind das die Freigabestufen. Beschreibung heißt, die Aufgabe so zu formulieren, dass ein brauchbares Ergebnis entsteht; das sind meine Aufgabenbeschreibungen und der Kontext, den jeder Agent bekommt. Unterscheidung heißt, das Ergebnis kritisch zu prüfen; dafür stehen der zweite Agent, der gegenliest, und der Beleg statt der Meldung „beendet“. Und Sorgfalt heißt, verantwortlich mit Daten, Quellen und Folgen umzugehen. Das ist der Punkt, auf den alles hinausläuft: Die Verantwortung bleibt bei mir, ich unterschreibe, was nach außen geht, und ich berichte offen, wenn etwas schiefging. Diese vier Kompetenzen unterrichte ich im Kurs „Projekte mit KI steuern“; die Übertragung auf meinen eigenen Betrieb ist meine Lesart.

Grenzen

So arbeite ich: ein kleines Unternehmen mit einer Lernplattform und ein System im Aufbau, das Pannen hat. Dein Betrieb ist anders. Sobald mehrere Personen beteiligt sind, wird die Frage, wer eine Dauerfreigabe eintragen darf, zur eigentlichen Arbeit. Sobald ein Werkzeug Kundendaten sieht, kommen andere Fragen vor alle hier genannten, nämlich welche Unterlagen es lesen darf, wo sie verarbeitet werden und wer das freigegeben hat. Die allererste davon, welche KI im Haus überhaupt läuft, habe ich im Beitrag zum AI Act als Reifegradtest gestellt. Nimm das hier als Ausgangspunkt und passe es an deine Rahmenbedingungen an, bevor du es einsetzt. Die Entscheidung, was davon zu dir passt, liegt bei dir.

Wie es weitergeht

Was das alles bringt, kann ich heute nicht mit einer Zahl sagen, nur mit einer Reihenfolge: erst nachweisen, dass es läuft, dann belegen, was es bringt. Der zweite Schritt braucht eine Annahme, einen Messplan und eine Zahl mit Quelle. Er ist ein eigener Beitrag. Dieser Text war der Startschuss einer Artikelreihe. Als Nächstes schreibe ich über den Aufbau des Systems: welche Prozesse, Arbeitsabläufe und Systeme es braucht, geordnet nach den vier Dimensionen des Service Managements. Das sind nach ITIL die Organisation und ihre Menschen, Informationen und Technik, Partner und Lieferanten sowie Wertströme und Prozesse, also vier Blickwinkel, die zusammen zeigen, ob ein Service wirklich trägt.

Quellen

• ITIL® ist eine eingetragene Marke von PeopleCert.
• Beitrag „Der AI Act ist kein Compliance-Projekt. Er ist ein Reifegradtest.“
• AI-Fluency-Rahmenwerk von Rick Dakan und Joseph Feller (vier Kompetenzen: Delegation, Beschreibung, Unterscheidung, Sorgfalt)
• Kurs „Projekte mit KI steuern“
• Kurs „Ergebnisse in den Betrieb bringen“
• Vier Dimensionen des Service Managements nach ITIL (Organisationen und Menschen; Information und Technologie; Partner und Lieferanten; Wertströme und Prozesse)