Praxisreferenz

AI-Operable IT-Services — eine Machbarkeitsstudie mit lauffähigem Demonstrator

Wie müssen IT-Services gestaltet sein, damit KI-Agentensysteme große Teile ihres Lebenszyklus — Betrieb, Optimierung, Weiterentwicklung — eigenständig und kontrolliert steuern können? Die Studie beantwortet das nicht nur konzeptionell, sondern mit einem realen, governance-geführten Demonstrator.

Worum es geht

Wert entsteht nicht durch den einzelnen, immer stärkeren Agenten, sondern durch das Zusammenspiel von vier Bausteinen. AI-Operability wird damit zu einer eigenständigen Qualitätsdimension — gleichrangig neben Sicherheit, Wartbarkeit und Skalierbarkeit.

01
AI-operabler Service

maschinell verstehbar, beobachtbar und über klar definierte Schnittstellen steuerbar (API-First, Self-Describing, Semantic Observability).

02
Governance

trennt, was ein Agent technisch kann, von dem, was er darf — als ausführbarer Code im Entscheidungspfad, nicht als PDF.

03
Agentensystem

spezialisierte Rollen (Operations, Security, Cost, Evolution, Auditor …) auf einem gemeinsamen, generalisierbaren Rahmen.

04
AI Service Brain

dauerhaftes, modellunabhängiges Gedächtnis für Wissen, Muster und Erfahrungen — überdauert Modelle und Anbieter.

Master Control Center: Leitstelle mit Kennzahlen, Agenten-Ensemble und Governed-Intent-Steuerung
Master Control Center — die Leitstelle macht das Agenten-Ensemble, die Governance-Verteilung und jede ausgeführte Aktion an echten Daten sichtbar. Sie führt selbst nichts aus („Governed Intent“).

Was im Demonstrator real läuft

Zwischen dem 10. und 12. Juni 2026 entstand in einer realen Cloud-Sandbox ein lauffähiger, governance-geführter Demonstrator: eine AI-operable Referenzanwendung, ein befülltes AI Service Brain, ein Agentensystem auf gemeinsamem Rahmen und eine live durchgesetzte Governance. Die folgende Evidenz ist dem Whitepaper entnommen und dort als vorläufig markiert:

  • Governance ausführbar und implementierungstreu: die live durchgesetzte Policy (Open Policy Agent) ist über 156 Prüfungen zu 100 % deckungsgleich mit ihrer Spezifikation — 0 Abweichungen (F-011).
  • Autonomie-Leiter an echten Daten belegt: observe → approval → autonomous; die Stufe bestimmt extern die Policy, nicht der Agentencode. Eine Freigabe ließ den Agenten — nicht die Leitstelle — real skalieren, vollständig auditiert und reversibel (F-002).
  • Das AI Service Brain ist der entscheidende Qualitätshebel: im blinden A/B-Vergleich gewinnt „mit Brain“ bei domänenspezifischen Fragen klar (Qualität ≈ 3,5 vs. 0,5 von 5); blindes Grounding bei themenfremden Fragen schadet → Relevanz-Gating (F-006).
  • Geschlossener Learning Loop: eine Agenten-Empfehlung wurde umgesetzt und ihre Wirkung gemessen — der Modellanbieter-Wechsel senkte die Latenz messbar (~3–10×), der Skalierungs-Hebel nicht (F-005).
  • Modellwahl als governter, reversibler Trade-off: Claude Opus ↔ EU-residentes Gemini zur Laufzeit umschaltbar, ohne Redeploy — gekoppelt an Trust- und Residency-Level (F-004).
Referenzanwendung: gegroundete Antwort mit Evidence-Cards und Modell-Transparenz neben dem semantischen Wissensnetz
Die Referenzanwendung antwortet aus dem AI Service Brain — mit sichtbaren Belegen (Evidence-Cards), transparentem Modell (hier Claude Opus über Vertex AI) und dem aufleuchtenden Wissensnetz rechts.

Bezug zu den sieben Missionen

Die Studie ist das reale Gegenstück zu den Architekturprinzipien dieser Site: Jede der sieben Missionen findet im Demonstrator eine konkrete, teils gemessene Entsprechung. Sie ergänzt damit das didaktische Service-Agent-Beispiel um echte Evidenz.

001 Zielbild & Operating Model Verantwortungsteilung Mensch/Agent, Service Operating Contracts und die Trennung von Autonomy Level (Können) und Trust Level (Dürfen) — Posture pro Service steuerbar. 002 Daten werden zu Kontext Das AI Service Brain als kuratiertes, modellunabhängiges Gedächtnis (RAG, Provenance); der A/B-Vergleich belegt Kontext als Qualitätshebel. 003 APIs werden zu Werkzeugen AI-Operability by Design: Self-Describing Service mit maschinenlesbarer Selbstbeschreibung (/.well-known/ai-operable), Aktionsvokabular und Verträgen — am zweiten, von Grund auf AI-operablen Service gezeigt. 004 Identität, Security & Governance Governance-as-Code (OPA live, 100 % spezifikationstreu), Least-Privilege-Maschinenidentitäten, verpflichtende Freigaben und ein Auditor-Agent, der die Audit-Kette selbst prüft. 005 Evals, Reliability & Observability Semantic Observability, eine geschlossene Audit-Kette Ereignis → Entscheidung → Aktion, Cross-Judge-Evals über einen gelabelten Korpus und ein Confidence-Gate vor riskanten Aktionen. 006 Portability, Sovereignty & Economics Governter, reversibler Modellwechsel (Capability ↔ EU-Datenresidenz ↔ Kosten), ein Cost-Agent mit abgerechneten Kosten und die „Autonomous Service Economics“ als Wirtschaftlichkeitsmodell. 007 AI-native Software Engineering & Platform Ein Service-Evolution-Agent (governte, reversible Self-Maintenance), der selbst-evolvierende „Janus“-Agent (propose-only), SBOM-/Vuln-Awareness und ein Agent, der laufend gegen die 12 hr-EAM-Architekturprinzipien bewertet.

Grenzen & Einordnung

Alle Befunde sind ausdrücklich vorläufig: eine Cloud-Sandbox, zwei Services, kurzer Beobachtungszeitraum, teils synthetischer Korpus und heuristisch gesetzte Confidence-Werte. Die Studie trennt Konzept (Sollform) und Umsetzungsstand bewusst — sie ist ein Forschungsprogramm, kein Produktnachweis.

Diese Seite fasst die Studie kuratiert zusammen und bleibt unabhängig vom hr/ARD-Kontext, in dem sie entstanden ist. Die Screenshots stammen aus dem Demonstrator (Stand Juni 2026).

Whitepaper als Leseprobe

Die Studie liegt als Whitepaper vor (81 Seiten, v3.7, Stand Juni 2026). Eine Leseprobe — Deckblatt, Inhaltsverzeichnis und die Kapitel 1–3 (Executive Summary, Ausgangssituation, Vision und Zielbild) — kann direkt gelesen werden. Die Vollversion gibt es auf Anfrage per E-Mail.

Die Konzepte hinter dieser Referenz?

Nova-7 erklärt Governance, AI-Readiness und Agentenarchitektur aus den sieben Missionen.

Nova-7 fragen