Capstone — die Achsen zusammen anwenden

Der Fall: ein Incident-Copilot mit Wirkung

Ein mittelständischer Betreiber plant OpsPilot: Das System soll Alerts, Runbooks und aktuelle Monitoringdaten zusammenführen, eine Diagnose formulieren und für bekannte Störungen Maßnahmen vorschlagen. Später soll es ausgewählte Aktionen selbst ausführen. Der erste Demo-Flow funktioniert: Ein Alarm wird zusammengefasst, das passende Runbook erscheint und ein Neustart behebt den Testfehler. Genau jetzt beginnt die Architekturarbeit, denn ein erfolgreicher Happy Path beantwortet weder Aufgaben-Fit noch Fehlerwirkung, Datenfluss, Retrievalqualität oder Autorisierung.

Dieses Capstone lehrt keine neue Universaltechnik. Es führt die Achsen des Tracks an einem Fall zusammen und zeigt ihre Reihenfolge. Jede Entscheidung erzeugt ein Artefakt: Aufgabenschnitt, Quellen- und Toolvertrag, Eval-Plan, Kontrollmatrix, Trust Boundaries, Kostenmodell und Rolloutgate. Der Preis dieser Disziplin ist ein langsamerer Weg von Demo zu Produktion. Der Gewinn ist, dass ein Modellfehler nicht automatisch zum Infrastrukturereignis wird.

Der reale Entscheidungsdruck kommt aus drei Richtungen. Der Service-Desk erwartet kürzere Incidentzeiten, Security fürchtet Toolmissbrauch, und Finance will einen belastbaren Kostenpfad. Keine dieser Perspektiven darf die anderen durch einen pauschalen Score ersetzen. Das Architekturprotokoll hält deshalb pro Entscheidung Annahme, Evidenz, gewählte Grenze, akzeptierten Nachteil und Revisit-Trigger fest. Ein Revisit wird etwa durch neue Schreibrechte, neue Datenklasse, anderes Modell oder veränderte Last ausgelöst.

Vor dem Design definiert das Team einen sicheren Nicht-AI-Pfad. Fällt Modell, Retrieval oder Toolintegration aus, bleiben Alarmanzeige, Runbookzugriff und manuelle Aktion verfügbar. Dadurch ist der Copilot eine Zusatzfähigkeit statt eine neue Single Point of Failure. Nachteil: Doppelte Bedienwege müssen dokumentiert und geübt werden. Sie ermöglichen aber, Experimente abzubrechen, ohne die Incidentfähigkeit zu verlieren.

Schritt 1: Geschäftsprozess in Aufgaben schneiden

Der Satz „AI soll Incidents lösen“ wird in getrennte Aufgaben zerlegt: Alertdaten normalisieren, relevante Dokumente finden, Live-Zustand lesen, Hypothese formulieren, zulässige Maßnahme auswählen, Autorisierung prüfen, Aktion ausführen und Wirkung beobachten. Normalisierung, Policy und Ausführung sind deterministische Systemaufgaben. Sprachliche Zusammenfassung und Hypothesengenerierung sind Modellkandidaten. Retrieval und Tools liefern unterschiedliche Wissensarten.

Runbook finden

Retrieval auf versioniertem Dokumentbestand

Aktuelle Replikazahl lesen

Tool gegen Monitoring oder Orchestrator

Neustart zulässig?

Deterministische Policy mit Nutzer, Dienst und Wartungsfenster

Diagnose erklären

LLM-Vorschlag mit Quellen und Unsicherheitsweg

Der Aufgabenschnitt verhindert End-to-End-Autonomie als Default. Nachteil: Mehr Komponenten und Schnittstellen. Er macht jedoch jede Garantie an der Schicht prüfbar, die sie leisten kann. Im ersten Release bleibt jede Aktion ein Vorschlag; damit kann das Team Text- und Retrievalqualität messen, ohne zugleich Toolautonomie freizugeben.

Für jeden Schritt wird ein Owner benannt. Das Plattformteam verantwortet Serving und Telemetrie, der Dienst-Owner die zulässigen Aktionen, Security die Policy-Anforderungen und der fachliche Betreiber die Eval-Labels. Gemeinsame Verantwortung ohne Entscheidungsrecht erzeugt im Incident Stillstand. Nachteil: Klare Zuständigkeit macht Ressourcenbedarf sichtbar und verhindert den bequemen Eindruck, der Modellanbieter trage den gesamten Betriebsprozess.

Schritt 2: Wissen nach Herkunft und Zeit ordnen

OpsPilot braucht drei Wissensklassen. Allgemeine technische Sprache kann aus parametrischem Wissen stammen. Interne Runbooks und Postmortems liegen versioniert im Retrieval-Korpus. Live-Zustand wie Podzahl, letzte Deployments und aktuelle Fehlerrate kommt aus lesenden Tools. Das Modell darf eine Runbook-Aussage nicht gegen einen veralteten Trainingsrest austauschen und einen Live-Wert nicht aus einem Dokument erraten.

Für Dokumente gelten Status- und Vorrangregeln: nur freigegebene Versionen, Mandantenfilter vor dem Ranking und sichtbare Dokument-ID mit Gültigkeit. Für Tools gelten Timeout, Datenminimierung und Read-only-Rechte. Preis: Mehrere Wissenspfade können widersprechen. Der Antwortcontract verlangt dann, den Konflikt zu benennen und zu eskalieren, statt eine glatte Synthese zu erfinden.

Die Wissenspfade bekommen getrennte Frischeziele. Ein Runbook kann bei jeder Freigabe neu indexiert werden; Monitoringdaten brauchen Sekundenaktualität; allgemeine Modellkenntnis hat keinen garantierten Zeitstempel. Diese Frische wird im Trace ausgewiesen. Ist ein Toolergebnis zu alt, darf die Diagnose es nicht als aktuellen Zustand darstellen. Preis: Frischeprüfung erzeugt Ablehnungen bei gestörten Datenquellen, statt mit veralteten Werten weiterzuarbeiten.

Die Quellenpipeline misst nicht nur Treffer, sondern Frische und Autorisierung. Ein formal aktuelles Dokument kann für einen anderen Mandanten bestimmt sein; ein autorisierter Ausschnitt kann durch eine neuere Betriebsanweisung überholt sein. Beide Metadaten werden vor dem Modell geprüft. Der Generator erhält keine Dokumente, die der auslösende Nutzer nicht sehen darf. Nachteil: Frühe Filter machen Metadatenfehler zu sichtbaren No-answer-Fällen statt sie durch breite Suche zu kaschieren.

Schritt 3: Fehlerbilder in der richtigen Reihenfolge diagnostizieren

Wenn OpsPilot eine falsche Diagnose liefert, beginnt die Untersuchung nicht mit einem größeren Modell. Zuerst wird der fehlgeschlagene Request rekonstruiert: Eingaben, Filter, Retrieval-Kandidaten, Toolantworten, finaler Kontext, Modell- und Promptversion sowie Ausgabevalidierung. Fehlt das richtige Runbook im Kandidatenset, liegt der erste Hebel bei Retrieval. Ist es vorhanden, aber nicht im Kontext, bei Auswahl oder Budget. Wird es trotz Kontext ignoriert, bei Prompt, Widerspruch oder Generator.

Rechenwerte und harte Zustände werden extern geprüft. Eine selbstberichtete Sicherheit wird erst nach Kalibrierung auf gelabelten Incidents als Signal verwendet. Ein LLM-Judge wird mit getauschter Kandidatenreihenfolge und menschlichen Ankern geprüft. Nachteil: Diese Diagnose speichert mehr strukturierte Telemetrie und erzeugt Testkosten. Rohinhalte werden minimiert, damit Beobachtbarkeit nicht zum Datenschutzleck wird.

Ein Incident kann mehrere Symptome gleichzeitig zeigen. Das Runbook wird gefunden, doch der Live-Toolaufruf scheitert und das Modell ergänzt einen plausiblen Status. Die Diagnose trennt dann Retrievalerfolg, Toolfehler und unbelegte Generierung. Eine einzelne Antwortnote würde diese Kette verbergen. Nachteil: Stufenmetriken sind komplexer, erlauben aber, genau den fehlgeschlagenen Vertrag zu reparieren und den sicheren Fallback zu testen.

Schritt 4: Eval-Plan und Baseline bauen

Die Baseline ist der heutige On-call-Prozess: Zeit bis zur ersten brauchbaren Hypothese, Korrektheit der referenzierten Runbooks, Zahl unnötiger Aktionen und Eskalationszeit. Das Eval-Set enthält häufige Standardfälle, seltene kritische Incidents, widersprüchliche Dokumente, fehlende Evidenz, lange Kontexte und manipulierte Inhalte. Jeder Fall trägt erwartete Quellen, zulässige Aktion und Schaden einer falschen Entscheidung.

Das Testset enthält auch negative Fälle, in denen keine Aktion richtig ist. Ohne sie lernt der Prozess nur, zwischen Maßnahmen zu wählen, nie abzubrechen. Weitere Gegenfälle vertauschen Dokumentversionen, platzieren relevante Evidenz an verschiedenen Kontextpositionen und variieren die behauptete Nutzermeinung. Der Preis ist ein größeres Set; der Gewinn ist eine Prüfung der tatsächlichen Systemgrenzen statt einer Sammlung erfolgreicher Demos.

Für jede Metrik ist die Reaktion festgelegt. Sinkt kritischer Retrieval-Recall, stoppt der Diagnosepfad. Steigt nur die stilistische Abweichung, folgt Review statt sofortigem Rollback. Wird ein unautorisierter Toolversuch beobachtet, bleibt das Schreibrecht gesperrt und Security untersucht den Trace. Diese Kopplung verhindert Dashboard-Theater. Nachteil: Harte Reaktionen können Verfügbarkeit reduzieren; genau deshalb werden Gates vor dem Rollout auf ihre fachlichen Kosten geprüft.

Schritt 5: Autonomie und menschliche Kontrolle dosieren

Der Kontrollgrad wird pro Aktion bestimmt. Eine Zusammenfassung ist leicht reversibel und kann nachgelagert stichprobenartig geprüft werden. Ein Neustart ist begrenzt reversibel, kann aber Verfügbarkeit beeinträchtigen; er braucht Dienst-Allowlist, Wartungszustand, konkrete Bestätigung und Ergebnisbeobachtung. Datenlöschung oder Berechtigungsänderung bleiben außerhalb des Agentenpfads.

Die Reviewkapazität wird vor dem Rollout gerechnet. Kann der On-call nur zehn Vorschläge pro Stunde gründlich prüfen, darf das System nicht hundert Pflichtfreigaben erzeugen. Risikoarme Fälle werden enger automatisiert oder nur stichprobenartig geprüft; kritische Fälle erhalten Priorität. Preis: Der erreichbare Automatisierungsgrad bleibt kleiner als in der Demo. Dafür bleibt der Mensch eine reale Kontrollinstanz.

• Keine vorgewählte Zustimmung in der Review-UI.
• Evidenz und Rohzustand vor dem Modellvorschlag sichtbar machen.
• Ablehnung und Rückfrage als normale, gemessene Ergebnisse behandeln.
• Bei fehlender Kapazität sicher abbrechen statt ungeprüft fortfahren.

Autonomie wird nach einem Fehler nicht pauschal deaktiviert oder erweitert. Das Team prüft, welche Fallklasse und Kontrolle betroffen war. Ein Retrievalregress kann den Diagnosepfad stoppen, ohne die reine Alertzusammenfassung abzuschalten. Ein Autorisierungsfehler stoppt alle schreibenden Tools. Nachteil: Feingranulare Kill Switches brauchen Architekturarbeit; sie vermeiden die Wahl zwischen vollständigem Ausfall und unkontrolliertem Weiterbetrieb.

Schritt 6: Trust Boundaries und Toolrechte ziehen

Alerts, Runbooks, Tickets und Toolantworten sind untrusted Eingaben. Ein kompromittiertes Dokument kann indirekte Prompt Injection enthalten; eine Modellantwort kann wiederum schädlichen Text für einen Downstream erzeugen. Der Host validiert Toolargumente, die Policy autorisiert Nutzer und Ressource, und der Executor besitzt nur die minimalen Rechte. Geheimnisse werden zur Ausführung injiziert und niemals in den Modellkontext gelegt.

Modell

Schlägt Diagnose und enges Tool mit Argumenten vor

Host und Policy

Validieren Schema, Identität, Ressource, Risiko und Bestätigung

Executor

Führt genau die erlaubte Operation mit kurzlebiger Berechtigung aus

Zielsystem

Prüft Autorisierung erneut und liefert strukturiertes Ergebnis

Preis: Kleine Tools und vollständige Vermittlung brauchen mehr API-Design als run_shell. Der Sicherheitsgewinn ist fundamental: Ein manipuliertes Modell kann nur innerhalb eines eng definierten Wirkungsraums scheitern.

Das Threat Model betrachtet Angreifer, kompromittierte Quellen und unbeabsichtigte Modellfehler gleichwertig an der Wirkungsgrenze. Eine sichere Tool-Policy fragt nicht, warum ein falscher Aufruf entstand, sondern ob er zulässig ist. Rate Limit und Budget begrenzen Wiederholung; Audit und Alarm machen Ablehnungen sichtbar. Preis: Manche legitime Notfallaktion passt nicht in den Standardpfad und braucht einen getrennten, menschlich kontrollierten Break-glass-Prozess.

Die Tool-Allowlist ist je Dienst und Umgebung getrennt. Ein in Staging zulässiger Neustart ist nicht automatisch in Produktion erlaubt; eine lesende Diagnosefähigkeit erhält keinen Schreibtoken. Kurzlebige Credentials werden erst nach bestandener Policy ausgestellt. Nachteil: Mehr Identitäten und Policies erhöhen Verwaltungsaufwand. Sie begrenzen jedoch den Blast Radius eines falschen Plans und machen Berechtigungsänderungen unabhängig vom Modell deploybar.

Schritt 7: Kosten- und Betriebsmodell entscheiden

Das Team misst Tokenverteilung, Retrieval- und Tool-Aufrufe, Retry, Reviewzeit, p95-TTFT und gesamte Incidentdauer. Interaktive On-call-Anfragen erhalten einen getrennten Pfad von asynchroner Postmortem-Zusammenfassung. Ein kleineres Modell darf nur für Fallklassen routen, in denen es das Qualitätsgate besteht. Der Router erhält harte Risiko- und Datenpolicy als Eingabe, nicht nur eine geschätzte Schwierigkeit.

API und Eigenbetrieb werden mit Vollkosten verglichen. Für ungleichmäßige Last kann variable API-Kapazität trotz höherem Stückpreis wirtschaftlicher sein; für stabile hohe Last kann Eigenbetrieb interessant werden. Bereitschaft, Redundanz, Updates, Datenanforderungen und Exit-Test gehören in dieselbe Rechnung. Nachteil: Ein Hybridpfad optimiert Kosten, vergrößert aber die Test- und Betriebsoberfläche.

Die Wirtschaftlichkeitsrechnung verwendet Kosten pro fachlich akzeptiertem Incidentbeitrag. Abgelehnte oder korrigierte Vorschläge zählen nicht als voller Erfolg; menschliche Reviewzeit bleibt enthalten. Gleichzeitig wird der Wert schnellerer Triage separat gemessen. Nachteil: Ende-zu-Ende-Kennzahlen sind schwerer als Tokens pro Request, verhindern aber eine Optimierung, die Modellkosten senkt und On-call-Arbeit erhöht.

Schritt 8: Pilot, Register und Rolloutgate

OpsPilot startet read-only für eine Dienstklasse im Schattenbetrieb. Das Register nennt Zweck, Owner, Nutzer, Daten, Modell, Quellen, Tools, Risikostufe, Eval-Version, Aufbewahrung und Reviewdatum. Vorab festgelegte Stop-Kriterien sind unautorisierter Datenzugriff, erfundene belegte Quelle, negative Nettozeit oder Überschreitung der Reviewkapazität. Erst nach bestandenem Gate wird ein enges, idempotentes Schreibtool in einem separaten Pilot aktiviert.

Transparenz gilt nach innen und, je Use Case, gegenüber Betroffenen: Nutzer sehen Modellrolle, Quellen, Grenzen, Freigabestatus und Eskalationsweg. Ein Incidentsignal kann den AI-Pfad unabhängig von der restlichen Plattform deaktivieren. Preis: Feature-Rollout wird stufig und messbar statt schnell und vollständig. Das entspricht der tatsächlichen Beweislage: Textqualität, Retrieval, Toolwirkung und Autonomie sind verschiedene Freigaben.

Jede Rolloutstufe besitzt ein eigenes Rollback. Read-only kann durch Abschalten des Modellpfads auf manuelle Diagnose zurückfallen. Ein Schreibtool kann separat aus der Capability-Liste entfernt oder serverseitig gesperrt werden. Der Fallback wird geprobt, bevor er gebraucht wird. Nachteil: Parallele manuelle Fähigkeit muss erhalten bleiben; ohne sie wird das Experiment faktisch irreversibel und der Abbruchdruck steigt.

Nach jeder Stufe vergleicht das Team nicht nur Qualität, sondern Nettozeit, Ablehnungsquote, Reviewlast, Sicherheitsereignisse und Betriebskosten mit der vorherigen Stufe. Eine höhere Automatisierung kann zurückgenommen werden, obwohl das Modell unverändert bleibt. Nachteil: Der Rollout besitzt keine garantierte Zielstufe. Er endet dort, wo zusätzliche Autonomie ihren Kontroll- und Betriebsaufwand nicht mehr rechtfertigt.

Dein Entscheidungsprotokoll für die Checks

In den folgenden Checks triffst du die Entscheidungen des Falls selbst. Nutze immer dieselbe Reihenfolge: Aufgabe schneiden, Wissen und Zustand zuordnen, Fehlerstufe diagnostizieren, Qualität messen, Wirkung begrenzen, Kosten und Rollout entscheiden. Eine spätere Achse darf eine frühere harte Grenze nicht überschreiben. Ein billigeres Modell rechtfertigt keine schlechtere Sicherheitsklasse; menschliche Freigabe rechtfertigt keine unmögliche Reviewlast.

• Benenne den zuständigen Systembaustein statt „die KI“.
• Verlange Evidenz für die beobachtete Fehlerursache.
• Wähle die kleinste reversible Maßnahme.
• Nenne den Nachteil der richtigen Wahl.
• Sichere den Fall als messbare Regression.

Für jede Antwortoption im Capstone fragst du: Welche Annahme macht sie, welche Evidenz stützt sie, welche Systemgrenze setzt sie und welchen Preis akzeptiert sie? Eine Option ist nicht richtig, weil sie die meisten Kontrollen nennt. Sie ist richtig, wenn sie den konkreten Fehler mit der kleinsten ausreichenden und betreibbaren Maßnahme adressiert. Dieses Urteil ist das Lernziel des gesamten Tracks.

Halte außerdem fest, welche Evidenz eine Entscheidung später widerlegen würde. Ein Modell darf gewechselt werden, wenn ein Kandidat das gleiche Fehlerklassengate mit geringeren Vollkosten besteht. Ein Toolrecht darf erweitert werden, wenn ein neuer Use Case seinen Schaden, Rollback und Reviewpfad separat belegt. Eine Pilotstufe darf dauerhaft bleiben, wenn mehr Autonomie keinen Nettoeffekt liefert. Diese Revisit-Kriterien verhindern sowohl Techniktreue als auch unkontrolliertes Wachstum. Der Abschluss ist daher kein Architekturdiagramm, sondern ein versioniertes Entscheidungsprotokoll mit offenen Risiken, Ownern und nächstem Prüfpunkt. Preis: Die Organisation akzeptiert, dass Unsicherheit nicht durch einen einmaligen Go-live verschwindet. Der Gewinn ist ein System, das seine Grenzen kennt und bei neuen Daten gezielt verändert werden kann.

Vor der Übergabe an den Betrieb führt ein unabhängiger Reviewer einen Fall vom Eingang bis zur Wirkung durch. Er prüft, ob Trace und Register dieselbe Modell-, Prompt-, Quellen-, Tool- und Policyversion nennen, ob Ablehnung wirklich ohne Seiteneffekt endet und ob der manuelle Fallback erreichbar bleibt. Offene Risiken werden nicht als spätere Optimierung versteckt, sondern mit Owner und Frist angenommen. Der menschliche Review setzt review nicht automatisch auf Freigabe; er liefert die fachliche Entscheidung, die kein Generator delegiert bekommen darf.

Im Ergebnis muss jede Freigabe auf eine konkrete Evidenz, Systemgrenze und verantwortliche Rolle zeigen.