Eine am 6. Juli 2026 auf arXiv veröffentlichte Auswertung hat 302 qualitätsgeprüfte Kubernetes-Vorfälle durch retrieval-gestützte Modelle laufen lassen und zwei Fähigkeiten getrennt bewertet. Den Dienst mit der Grundursache benennen: in 91,4 % bis 99,7 % der Fälle richtig. Eine gültige Wiederherstellungsmaßnahme für den soeben diagnostizierten Vorfall wählen: 36,8 % bis 60,3 %. Zwischen diesen beiden Spalten liegen vierzig bis fünfundfünfzig Punkte, und dieser Abstand ist die nützlichste Zahl, die dieses Jahr über AIOps veröffentlicht wurde.
Das ist eine Aussage über Arten von Arbeit, nicht über Modellqualität. Das Modell liest gut und entscheidet schlecht, und das sortiert den Markt in zwei Stapel. Manche Betriebsarbeit scheitert sichtbar, vor den Augen desjenigen, der sie in der Hand hält. Manche scheitert, indem sie zu einer Aktion gegen die Produktion wird. AIOps verdient sein Geld bei der ersten Art und ist bei der zweiten derzeit ein Risiko - und die meiste Enttäuschung in diesem Markt entsteht dadurch, dass man es für die zweite kauft, nachdem man eine Demo der ersten gesehen hat.
Alert-Korrelation, Deduplizierung und die erste Fassung der Geschichte
PagerDuty bewirbt sein AIOps-Produkt damit, das Alert-Rauschen um bis zu 91 % zu senken. Lesen Sie das neben einer von NeuBird gesponserten Umfrage vom Februar 2026 unter 1.039 SRE-, DevOps- und IT-Operations-Fachleuten, in der 44 % einen Ausfall im vergangenen Jahr meldeten, der mit unterdrückten oder ignorierten Alerts zusammenhing. Eine Korrelation, die vierzig Meldungen zu einem Vorfall zusammenfasst, ist ein echter Gewinn. Eine Korrelation, die still entscheidet, welche Meldungen Sie nie zu sehen bekommen, ist der Weg zu diesen 44 % - und der Unterschied zwischen beiden liegt darin, ob die Gruppierung nachprüfbar ist.
Die stärksten Fälle sind die, die ein Mensch in Sekunden prüfen kann. Ein Modell, das die Deploy-Historie, die Metrik-Verschiebung und drei Log-Streams liest und daraus den Vorfallsbericht entwirft, erledigt Arbeit, die sonst um 3 Uhr nachts jemand mit schlechtem Erinnerungsvermögen macht - und wenn es falsch liegt, steht der Beleg dafür im Absatz. Zu erklären, warum sich eine Rechnung bewegt hat, ist dieselbe Art von Aufgabe, voller Zusammenhänge, die ein Mensch einen Monat zu spät bemerkt; der State of FinOps 2026 der FinOps Foundation, veröffentlicht am 19. Februar 2026 auf Basis von 1.192 Befragten, die zusammen mehr als 83 Milliarden USD an Jahresausgaben verwalten, fand, dass 98 % von ihnen inzwischen KI-Ausgaben steuern, gegenüber 31 % zwei Jahre zuvor. Einen abgeschlossenen Vorfall in ein geschriebenes Runbook zu verwandeln, ist noch besser: Die Fakten stehen fest, und das schlimmste Ergebnis ist ein Mensch, der einen Satz korrigiert.
KI-Code-Review auf Infrastruktur fängt eine Fehlerklasse und ist für eine andere blind
Veracodes GenAI Code Security Report 2026, veröffentlicht am 28. Juli 2026, hat mehr als 100 Modelle getestet und fand, dass die durchschnittliche Bestehensquote bei Sicherheit bei 56 % stagniert, einen Punkt über den 55 % davor. Rund 44 % der Generierungsaufgaben führten eine riskante Schwachstelle ein, wenn niemand ausdrücklich nach Sicherheit gefragt hatte. Das beste Modell, GPT-5.5, kam auf 68 % und scheiterte damit immer noch an jeder dritten Sicherheitsaufgabe.
Der ungleichmäßige Teil ist der nützliche. Diese Modelle bestanden Aufgaben zu SQL-Injection in 83 % der Fälle und zu Kryptographie in 87 %, aber Cross-Site-Scripting nur in 15 % und Log-Injection in 12 %. Ein KI-Reviewer ist stark bei dem, was er tausendfach beschriftet gesehen hat, und anderswo nahezu blind - und er wird Ihnen nicht sagen, in welchem der beiden Modi er gerade ist. Setzen Sie ihn bei einem Infrastructure-as-Code-Diff als zweiten Leser für die Fehler ein, die im Nachhinein offensichtlich sind: die Security Group, die auf 0.0.0.0/0 geöffnet wurde, die Änderung, die ein Ersetzen statt eines Updates ist. Machen Sie ihn nicht zum Gate: Die Klassen, die er übersieht, sind genau die, für die niemand eine Regel geschrieben hat.
Bei autonomer Behebung stützen die Belege den Pitch nicht mehr
Dieselbe Studie enthält den Befund, der das Gespräch über Self-Healing für ein weiteres Jahr beenden sollte. Selbst wenn das Modell sowohl den Dienst mit der Grundursache als auch die Fehlerart korrekt bestimmt hatte, wählte es in 39,5 % bis 62,0 % dieser korrekt diagnostizierten Vorfälle eine ungültige Behebung. Diagnose überträgt sich nicht auf Handlung. Gartners Prognose vom Juni 2025, dass über 40 % der Projekte mit agentischer KI bis Ende 2027 eingestellt würden, nannte neben den Kosten unzureichende Risikokontrollen - und genau die fehlen hier.
Kapazitätsplanung scheitert aus einem verwandten Grund: Das Modell produziert aus dünnen Belegen eine selbstbewusste Zahl, und eine selbstbewusste Zahl ist genau das, was ein Planungsmeeting hören will. Artikel 14 der KI-Verordnung ist genau dagegen geschrieben; er verlangt, dass eine aufsichtführende Person ein Hochrisikosystem unterbrechen und in einen sicheren Zustand bringen kann, und benennt den Automation Bias als das, wogegen sich die Aufsicht wehren muss.
Die Ausgabenobergrenze muss über der Abrechnungskonsole des Providers liegen
Im Mai 2026 bekam ein autonomer Agent unbeschränkte AWS-Credentials und den Auftrag, DN42 zu portscannen, ein Hobby-Netzwerk. Er provisionierte fünf m8g.12xlarge-Instanzen mit je 48 vCPUs, dazu Load Balancer und Lambda-Funktionen, und wendete dann immer wieder dasselbe CloudFormation-Template an. Der Betreiber erfuhr davon rund 24 Stunden später über Kreditkartenbelastungen von insgesamt 6.531,30 USD - für einen Workload, von dem die Community meinte, er passe auf einen VPS für 5 USD im Monat. AWS senkte die Rechnung später auf 1.894 USD. Der Schutz, der funktioniert hat, war eine Kulanzgutschrift.
Kein Budget-Tooling der großen Provider hätte das gestoppt, und alle drei sagen das schriftlich. Amazon dokumentiert, dass AWS Budgets bis zu dreimal täglich aktualisiert wird, wobei jede Aktualisierung typischerweise 8 bis 12 Stunden hinter der letzten liegt - eine Taktung, gebaut für Menschen, die teure Fehler einzeln machen. Microsoft schreibt, dass eine überschrittene Azure-Budgetschwelle keine Ressourcen beeinflusst und den Verbrauch nicht stoppt, wobei Kostendaten typischerweise innerhalb von 8 bis 24 Stunden vorliegen. Google Cloud schreibt, dass ein reines Alert-Budget die Nutzung oder die Ausgaben nicht automatisch deckelt. AWS liefert eine quelloffene Budget-Controls-Lösung aus, die bei 90 % eines Budgets eingreift, vier Dienste in einer Region abdeckt und einräumt, dass Storage und Networking weiter Kosten verursachen. Eine Agentur mit drei Personen, im Juli 2026 dokumentiert, fing sich an einem einzigen Tag eine AWS-Belastung von 14.000 USD ein, gegenüber einer normalen Monatsrechnung von 10 bis 15 USD, nachdem Angreifer statische Schlüssel von einer Instanz abgezogen und für Bedrock-Modellaufrufe ausgegeben hatten.
Unsere Antwort ist, die Grenze dort zu setzen, wo die Credentials ausgegeben werden, und nicht dort, wo die Rechnung zusammengestellt wird. In Sencai wird Spend erfasst, während er anfällt, nach Provider, Projekt und Umgebung, mit Caps und Budgets, die während des Auflaufens alarmieren statt auf einem Abrechnungszyklus von 8 bis 24 Stunden. Auf eine überschrittene Obergrenze automatisch zu reagieren, steht auf unserer Roadmap und ist nicht ausgeliefert; heute zieht also weiterhin ein Mensch das Credential. KI ist das eine Budget, das wir vorab begrenzen können: Sie wird in Credits gekauft, und ein Credit ist ein fester Geldbetrag und keine Tokenzahl - eine Preisänderung beim Modell verschiebt also, wie viele Tokens ein Credit kauft, und niemals, was er wert ist. Jeder kostenpflichtige persönliche Plan hat ein monatliches Kontingent und eine harte Obergrenze, die auf ein Vielfaches davon gesetzt ist, sodass ein außer Kontrolle geratenes Skript keine unbegrenzte Rechnung erzeugen kann. Runbooks sind aus demselben Grund freigabepflichtig: Das Modell schlägt vor, ein namentlich benannter Mensch führt aus.
Ein Audit-Trail, der sagen kann, ob ein Mensch oder ein Modell es war
Artikel 12 Absatz 1 der KI-Verordnung verlangt, dass Hochrisikosysteme die automatische Aufzeichnung von Ereignissen über die Lebensdauer des Systems technisch ermöglichen, und Artikel 26 Absatz 6 verlangt von Betreibern, diese Protokolle mindestens sechs Monate aufzubewahren, sofern anderes Recht nichts Längeres vorschreibt. Wenn Sie gegen ein Datum im August 2026 planen, korrigieren Sie es. Die Verordnung (EU) 2026/1744, der Digital Omnibus zur KI, seit dem 27. Juli 2026 in Kraft, hat eigenständige Hochrisikosysteme aus Anhang III auf den 2. Dezember 2027 verschoben und in Produkte eingebettete Systeme aus Anhang I auf den 2. August 2028. Die Daten haben sich verschoben, die Pflichten nicht.
Der betriebliche Grund, das zu bauen, hat mit der Frist nichts zu tun. Sechs Monate nach einem Vorfall lautet die Frage, ob ein Mensch oder ein Modell die Änderung vorgenommen hat, und ein Aufbau, der KI-Aktionen in einem System und menschliche in einem anderen aufzeichnet, kann das nur über einen Join beantworten, dem niemand traut. Wir haben uns geweigert, zwei Aufzeichnungen zu führen: Modellaktionen und menschliche Aktionen landen in einem einzigen Append-only-Trail. Sencai exportiert ihn als CSV mit entry_hash und prev_hash in jeder Zeile, sodass ein Leser, der uns nicht glaubt, die Chain nachrechnen kann. Das Feld, das sich seinen Platz verdient, ist das kleine neben dem Actor, das sagt, ob die Änderung von einem Menschen kam oder von einem Modell, das das Kontingent eines Menschen ausgibt.
Die Regel, die aus den Belegen folgt, ist unglamourös und hält. Lassen Sie ein Modell alles lesen, auch das, was es schlecht liest, denn eine schlechte Lesart ist in dem Absatz sichtbar, den es geschrieben hat. Lassen Sie es nur dort schreiben, wo ein namentlich benannter Mensch die Änderung unterschreibt und darunter ein Credential-Limit liegt, falls auch dieser Mensch sich irrt. Zwischen einer Provider-Benachrichtigung auf einem Zyklus von 8 bis 24 Stunden und jemandem, der werktags E-Mails liest, steht ein Rauchmelder und keine Sprinkleranlage. Der Betreiber von DN42 hatte einen Rauchmelder.