Sobald LLMs Tools aufrufen, Pläne schmieden und über mehrere Schritte handeln, verlassen wir den Komfort statischer Inferenz. Die richtigen Fragen sind dann SRE-artig: Wer sieht was, wann, in welchem Kontext, und wer darf es stoppen?

Kernkomponenten für On-Prem-Agentensteuerung:

  • Deterministischer Policy Layer

  • Rollen- und kontextbasierte Tool-Freigaben („Wartungsassistent darf nur read-only in Ersatzteilkatalog; nur mit Freigabe darf er Bestellungen auslösen“).

  • Konfigurierbar als deklarative Policies, versioniert, signiert.

  • Strukturierte Traces pro Agentenschritt
  • Jeder Schritt erzeugt ein strukturiertes Ereignis: Prompt-Kontext-Hinweise (ohne vertrauliche Rohdaten, wenn nicht nötig), getroffene Auswahl, Tool-Aufruf, Ergebnis-Hash, Policy-Entscheidung, Nutzerinteraktion.
  • Kompatibel zu Telemetrie-Standards, damit man mit existierenden Observability-Stacks arbeiten kann.
  • Speicher- und Gedächtnis-Governance
  • Kurzzeitkontext vs. Langzeitspeicher strikt trennen. Kein unkontrolliertes „Anreichern“ mit personenbezogenen oder vertraulichen Betriebsdaten.
  • Speicherobjekte werden klassifiziert, mit Aufbewahrungsfristen versehen und können rechtssicher gelöscht werden.
  • Prompt- und Wissens-Provenienz
  • Alle Systemprompts, Toolbeschreibungen und Wissensartefakte sind versioniert. Jede Entscheidung ist einer konkreten Version zuordenbar.
  • RAG-Pfade dokumentieren: welche Dokumente wurden konsultiert, mit welchen Indizes, welche Passagen sind in die Antwort eingeflossen.
  • Test- und Replay-Harness
  • Agentenläufe müssen offline reproduzierbar sein: deterministische Seeds, eingefrorene Tool-Mocks, gleiches Policy-Set.
  • So wird aus einem Vorfall ein testbarer Fall – Voraussetzung für echte Ursachenanalyse.
  • Live-Kontrolle
  • Kill-Switch pro Agent, pro Tool, pro Nutzergruppe.
  • Autonomie-Drossel (z. B. Schrittlimit, Genehmigungspflicht ab Budget X).
  • Quotenmanagement, damit kein Agent das System flutet.

Welche Metriken sind in der Praxis tragfähig?

  • Task-Erfolgsdefinitionen, die im Business-Prozess verankert sind (z. B. „korrekt erstellter Wartungsbericht mit konsistenten Ersatzteilreferenzen“).

  • Eskalations- und Rücknahmequoten pro Agentenpfad statt generische „Halluzinationsraten“.

  • Policy-Verletzungen und Block-Events als SLO-Reibungspunkte.

  • Drift-Indikatoren im Wissensspeicher: Anteil veralteter Dokumente, nicht referenzierbare Zitate, steigende Nachfragen nach denselben Fakten.

Wir setzen diese Prinzipien in einer On-Prem-Stack-Architektur um: lokale Inferenzserver (z. B. vllm/llama.cpp Klassen), ein souveräner Vektor-Index, ein Policy- und Signaturlayer, ein Telemetrie-Bus, der Agenten-Traces aufnimmt, sowie ein UI für Triage, Replay und Freigaben. Unser eigener Plattformansatz (Alpi-M) ist genau in dieser Nische verankert: Observability und Governance für LLM-Agenten – on-premise und datensouverän. Entscheidend ist, dass Observability als Erstklasse-Bürger gebaut wird, nicht als nachträglicher Logger.

5) Daten- und System-Souveränität als Architekturkonstante

Souveränität bedeutet: Daten bleiben unter eigener Kontrolle; Haftung und Auditierbarkeit sind nicht an externe Blackboxes delegiert. Das hat technische Konsequenzen:

  • Netzwerkzonen
  • Air-Gap oder streng segmentierte Zonen zwischen Produktionsnetz, Wissensspeicher, Inferenzclustern und Management-Ebene.
  • Alle Agententools sind in diesen Zonen verortet und werden wie kritische Betriebssoftware gehärtet.
  • Identität und Signaturen
  • Jede KI-Aktion ist einem Dienstprinzipal zugeordnet (nicht „anonymous agent“), Ergebnisse werden digital signiert und mit Zeitstempel versehen.
  • Freigaben durch Menschen sind kryptografisch gebunden, sodass nachträgliche Manipulation ausgeschlossen ist.
  • Ressourcenplanung statt Cloud-Elastizität
  • On-Prem bedeutet konkrete Kapazitätsplanung: GPU-Scheduling, Prioritätsklassen für Echtzeit versus Batch, Puffer für Spitzen.
  • Vorteil: deterministisches Verhalten, klarer Kostenrahmen, keine Abhängigkeit von fremden SLAs.
  • Datenhaltung und DSGVO
  • Trennung zwischen personenbezogenem, betriebskritischem und öffentlichem Wissen im RAG.
  • Recht auf Vergessen: referenzbasierte Speicher, in denen sich Einträge tatsächlich entfernen lassen; Agenten müssen damit umgehen können (z. B. invalidierter Kontext).
  • Update- und Change-Window
  • Kein „permanent beta“. Geplante Wartungsfenster, Shadow-Rollouts, Canary-Freigaben – dokumentiert, testbar, rücknehmbar.

6) Governance: Wer ist verantwortlich, wenn die KI falsch liegt?

Verantwortung ist eine Funktion aus Design und Organisation. Ein klares Betriebsmodell verhindert, dass „die KI“ zum Sündenbock wird.

  • RACI für KI-gestützte Entscheidungen
  • Responsible: Der menschliche Genehmiger in Stufe 0/1 – mit Tooling, das ihm eine echte Entscheidung ermöglicht (Evidenz, Reversibilität).
  • Accountable: Prozess-/Systemeigentümer, der Policies definiert, SLOs verantwortet und den Änderungspfad steuert.
  • Consulted: Daten- und Modelleigentümer (Trainingsdaten, Modelldokumentation, Limitierungen).
  • Informed: Compliance, Arbeitssicherheit, Betriebsrat je nach Kontext.
  • Nachvollziehbare Freigaben
  • Jede Freigabe hat einen Zweck, eine Evidenzbasis, eine Policy-Version und eine Signatur.
  • Kein Dark-Pattern in der UI: Ablehnen ist gleichwertig zu Freigeben.
  • Vorfälle und Eskalation
  • Runbooks wie in der IT-Operations: Erkennung, Eindämmung (Kill-Switch), Ursachenanalyse (Replay), Korrekturmaßnahme (Policy/Modell/Tool).
  • Regelmäßige Blameless-Reviews mit konkreten Technik- und Prozessänderungen.
  • Change-Management
  • Modell- und Policy-Versionen mit Feature-Gates. Erst Shadow, dann Canary, dann Vollbetrieb – immer mit Telemetrie.
  • Akzeptanzkriterien sind vorab definiert: Welche Aufgaben, in welchem Bereich, mit welchen Eskalationsgrenzen.
  • Safety Case
  • Dokumentierte Annahmen, Betriebsgrenzen, Fallbacks und Evidenz, dass das System innerhalb dieser Grenzen sicher operiert.
  • Für sicherheitskritische Kontexte: Integration mit etablierten Verfahren wie Gefahrenanalysen in der Domäne.

7) Zwei prägnante Anwendungsszenarien

a) Visuelle Inspektion in der Fertigung

  • Problem: Minimieren von Pseudoausschuss ohne echte Fehler durchzuwinken.

  • Architektur:

  • Edge-Inferenz direkt an der Linie, asynchrone Triage für unklare Fälle.

  • Evidence Bus: Bounding-Boxen, Segmentierungen, Merkmale, ähnliche historische Fälle.

  • Kalibrierte Arbeitsbereiche pro Produktvariante; OOD-Erkennung erzwingt menschliche Prüfung.

  • Reversible Operationen: Bauteile erhalten Status „Quarantäne“ bis zur Freigabe.

  • Governance: Zwei-Augen-Freigabe bei hohen Fehlerkosten; Audit-Trail mit Signaturen.

  • Ergebnis: Operatoren entscheiden belastbar anhand konsistenter Evidenz; Prozessingenieure können objektiv nachjustieren (Schrauben an Kalibrierung, Policies, Workflows), statt über „die KI“ zu diskutieren.