Governance & Richtlinien Governance & Policies
Was dürfen Agenten tun — und was nicht? What are agents allowed to do — and what not?
Wenn Agenten reale Aktionen ausführen — E-Mails senden, Geld transferieren, Code deployen — wird Governance zur existenziellen Überlebensfrage. Diese Dimension definiert die GaaS-Architektur, die Policy-Taxonomie, Autonomiestufen L0–L5 und das Algorithmische Consent-Protokoll. When agents perform real-world actions — sending emails, transferring money, deploying code — governance becomes an existential survival question. This dimension defines the GaaS architecture, policy taxonomy, autonomy levels L0–L5, and the Algorithmic Consent protocol.
Zusammenfassung
Ein fehlerhafter Agent in einer Schleife kann Reputation und Kapital innerhalb von Minuten zerstören. Diese Dimension definiert die Governance-Architektur: Governance-as-a-Service (GaaS), Policy-as-Code, sechs Policy-Kategorien, Autonomiestufen L0–L5, das Algorithmische Consent-Protokoll und Degraded Operations.
Zwei Grundprinzipien leiten das Design:
- „Software mit Software, Menschen mit Menschen“ — Governance-Regeln sind als ausführbarer Code kodiert, nicht als natürlichsprachliche Richtlinien
- Governance-first — Governance-Architektur wird vor operativen Fähigkeiten designed, da Kontrollmechanismen den Prozessen vorausgehen müssen, die sie regulieren
Kontext im VCOM-Framework
Governance überlagert die Organisationsstruktur (Dim 01) mit Regeln darüber, was Agenten tun dürfen. Strikte Trennung zwischen Governance (Meta-Ebene: Policy-Anpassung, Review, Verfassungsupdates) und Operations (Ausführung: schnelle autonome Arbeit innerhalb bestehender Policy-Grenzen). Governance setzt die Regeln; Operations befolgt sie.
Summary
A malfunctioning agent in a loop can destroy reputation and capital within minutes. This dimension defines the governance architecture: Governance-as-a-Service (GaaS), Policy-as-Code, six policy categories, autonomy levels L0–L5, the Algorithmic Consent protocol, and degraded operations.
Two foundational principles guide the design:
- "Software with software, humans with humans" — Governance rules are encoded as executable code, not natural-language guidelines
- Governance-first — Governance architecture is designed before operational capabilities, because control mechanisms must precede the processes they regulate
Context within the VCOM Framework
Governance overlays the organizational structure (Dim 01) with rules about what agents are allowed to do. Strict separation between governance (meta-level: policy adjustment, review, constitution updates) and operations (execution: fast autonomous work within existing policy bounds). Governance sets the rules; operations follows them.
Jeder Agent operiert innerhalb einer GaaS-Schicht, die jede Aktion vor Ausführung gegen Policy-Regeln prüft. Agenten können beispielsweise keine E-Mails ohne Review senden oder Commits ohne Referenz auf ein Issue erstellen. Die Governance-Regeln werden zentral gepflegt und überall durchgesetzt.
Every agent operates within a GaaS layer that evaluates each action against policy rules before execution. Agents cannot, for example, send emails without review or create commits without referencing an issue. Governance rules are centrally managed and enforced everywhere.
Gartner prognostiziert, dass 40% aller frühen Agentic-AI-Projekte bis 2027 an Governance-Lücken scheitern werden. VCOM adressiert dies durch eine präventive, konstitutionelle Governance-Architektur — nicht durch nachträgliche Log-Analyse.
Gartner predicts that 40% of early agentic AI projects will fail due to governance gaps by 2027. VCOM addresses this with a preventive, constitutional governance architecture — not post-hoc log analysis.
Autonomie ist eine Design-Entscheidung
Ein hochfähiger Agent kann bei L1 operieren, wenn das die richtige Design-Entscheidung für seine Domäne ist. Autonomiestufen werden nach Risikoprofil gesetzt, nicht nach dem, was das Modell kann. Dies operationalisiert Ashby's Law of Requisite Variety: das Governance-System muss ausreichende Kontrollgranularität besitzen.
Die effektive Autonomiestufe eines Agenten = Minimum aus (Trust-Score-abgeleitetes Level, Autonomie-Ceiling der Domäne).
Die Autonomiestufen L0–L5
Autonomy is a Design Decision
A highly capable agent can operate at L1 if that is the appropriate design decision for its domain. Autonomy levels are set by risk profile, not by model capability. This operationalizes Ashby's Law of Requisite Variety: the governance system must possess sufficient control granularity.
An agent's effective autonomy level = minimum of (trust-score-derived level, domain's autonomy ceiling).
Autonomy Levels L0–L5
| Level | Name | Agent-Verhalten | Menschliche Rolle |
|---|---|---|---|
| L0 | Manuell | AI als reines Werkzeug; keine eigenständige Aktion | Dominator |
| L1 | Assistenz | Agent führt Sub-Schritte aus, schlägt Aktionen vor; Mensch bestätigt jede Aktion (HITL) | Approver |
| L2 | Teilautonom | Agent führt definierte Prozesse autonom aus; stoppt bei Entscheidungen oder Abweichungen (HOTL) | Supervisor |
| L3 | Bedingt autonom | Agent plant und führt komplexe Ziele aus; berichtet nur bei Ausnahmen | Manager |
| L4 | Hochautonom | Agent handelt strategisch, proaktiv, lernt aus Fehlern; periodisch evaluiert | Auditor |
| L5 | Vollautonom | Theoretisches Maximum; Agent operiert als unternehmerischer Partner | Partner |
| Level | Name | Agent Behavior | Human Role |
|---|---|---|---|
| L0 | Manual | AI as pure tool; no independent action | Dominator |
| L1 | Assisted | Agent executes sub-steps, proposes actions; human confirms every action (HITL) | Approver |
| L2 | Partial | Agent autonomously executes defined processes; stops at decisions or deviations (HOTL) | Supervisor |
| L3 | Conditional | Agent plans and executes complex goals; reports only on exceptions | Manager |
| L4 | High | Agent acts strategically, proactively, learns from errors; evaluated periodically | Auditor |
| L5 | Full | Theoretical maximum; agent operates as entrepreneurial partner | Partner |
Policy-Taxonomie
Sechs Policy-Kategorien stellen vollständige Abdeckung des Agenten-Aktionsraums sicher. Inspiriert durch militärische Rules of Engagement, umformuliert in neutrale Organisationsterminologie:
- Standing Policies: Immer aktiv; Kern-Sicherheitseinschränkungen (z.B. „Niemals Finanztransaktionen >10.000$ ohne menschliche Freigabe“)
- Supplementary Policies: Situationsspezifisch; aktivier-/deaktivierbar (z.B. „Während Client-Demo: keine externen API-Calls“)
- Pre-Authorized: Explizit erlaubt ab bestimmten Autonomiestufen (z.B. „L3+ Agenten dürfen Content im Staging veröffentlichen“)
- Prohibited: Niemals erlaubt; kein Überschreiben auf Agent-Ebene
- Escalation-Required: Muss Supervisor-/Human-Freigabe erhalten
- Degraded-Mode: Fallback-Verhalten bei Governance-Ausfall
Algorithmischer Konsent (Soziokratie 3.0)
Entscheidungsprotokoll für komplexe Governance-Entscheidungen, abgeleitet von S3's Consent-Prozess. Operativer Leitsatz: „Safe enough to try, good enough for now.“
Policy Taxonomy
Six policy categories ensure complete coverage of the agent action space. Inspired by military Rules of Engagement, reframed with neutral organizational terminology:
- Standing Policies: Always in effect; core safety constraints (e.g., "Never execute financial transactions >$10,000 without human approval")
- Supplementary Policies: Situation-specific; can be activated/deactivated (e.g., "During client demo: no external API calls")
- Pre-Authorized: Explicitly permitted at certain autonomy levels (e.g., "L3+ agents may publish content to staging")
- Prohibited: Never allowed; no override at agent level
- Escalation-Required: Must receive supervisor/human approval
- Degraded-Mode: Fallback behavior when governance systems are unavailable
Algorithmic Consent (Sociocracy 3.0)
Decision-making protocol for complex governance decisions, derived from S3's consent process. Operational philosophy: "Safe enough to try, good enough for now."
Algorithmischer Konsent: 7-Schritte-Protokoll
Algorithmic Consent: 7-Step Protocol
- Consent to Driver: Bestätigung, dass der zugrundeliegende Bedarf valide ist
- Klärungsfragen: Teilnehmende Agenten erfragen zusätzlichen Kontext
- Informationssammlung: Constraints aus GaaS, Ressourcenverfügbarkeit, Abhängigkeiten sammeln
- Generative Fragen: Jeder Agent trägt mögliche Optionen bei
- Ideen sammeln: Vorschläge aggregieren, deduplizieren, Themen identifizieren
- Tuner-Agenten wählen: 1–2 Agenten mit relevanter Expertise zur Synthese auswählen
- Proposal designen: Tuner-Agenten erstellen formalen Vorschlag mit Driver, Aktion, Outcomes, Evaluationskriterien, Review-Datum
Einwand-Qualifikation (3-Fragen-Test): (1) Effektivität: Adressiert der Vorschlag den Driver nicht? (2) Nebenwirkungen: Entstehen untragbare Risiken? (3) Effizienz: Wird eine leichte Verbesserung verpasst? Einwände blockieren und müssen gelöst werden (max. 3 Rekursionstiefe). Bedenken werden notiert, blockieren aber nicht.
- Consent to Driver: Confirm the underlying need is valid
- Clarifying Questions: Participating agents query for additional context
- Information Gathering: Collect constraints from GaaS, resource availability, dependencies
- Generative Questions: Each agent contributes possible options
- Collect Ideas: Aggregate proposals, deduplicate, identify themes
- Choose Tuner Agents: Select 1–2 agents with relevant expertise to synthesize
- Design Proposal: Tuner agents produce formal proposal with driver, action, outcomes, evaluation criteria, review date
Objection Qualification (3-Question Test): (1) Effectiveness: Does the proposal fail to address the driver? (2) Side-effects: Does it create risks the organization cannot afford? (3) Efficiency: Does it miss a worthwhile improvement? Objections block and must be resolved (max recursion depth: 3). Concerns are recorded but do not block.
Governance Backlog
Persistente, priorisierte Warteschlange von Governance-Items — Entkopplungsmechanismus zwischen Spannungserkennung und Governance-Antwort. Getrennt von operativen Backlogs. Triage durch den Governance Facilitator nach: (1) blockierender Auswirkung, (2) Risikoschwere, (3) Alter, (4) Scope (multi-domänen-Items werden priorisiert).
Governance Backlog
Persistent, prioritized queue of governance items — decoupling mechanism between tension detection and governance response. Distinct from operational backlogs. Triaged by the Governance Facilitator based on: (1) blocking impact, (2) risk severity, (3) age, (4) scope (multi-domain items are prioritized).
Sie müssen nicht jeden Agenten-Output einzeln prüfen. Die GaaS-Schicht übernimmt die regelbasierte Prüfung. Sie definieren die Regeln und greifen nur bei Ausnahmen ein — Management by Exception statt Mikromanagement.
You do not need to review every agent output individually. The GaaS layer handles rule-based evaluation. You define the rules and intervene only on exceptions — management by exception instead of micromanagement.
Governance-as-a-Service (GaaS)
Eine dedizierte Middleware-Schicht, die als Proxy zwischen Agenten und der Außenwelt (Tools, APIs, externe Systeme) fungiert. Die Architektur kombiniert Constitutional AI (Bai et al., 2022) mit Ostroms institutionellen Design-Prinzipien in einer operativ durchsetzbaren Middleware.
Mechanismus
- Agent plant eine Aktion (z.B. „Sende Vertragsangebot an Kunde X mit 25% Rabatt“)
- GaaS-Schicht fängt den Intent vor Ausführung ab
- Intent wird gegen deklarative Policy-Regeln evaluiert (Policy-as-Code)
- Wenn konform: Aktion wird ausgeführt und geloggt
- Wenn Verstoß: Aktion blockiert. Agent erhält strukturiertes Feedback („Aktion verweigert: Rabatt überschreitet Maximum von 20%. Anpassen und erneut einreichen.“)
Eigenschaften
- Zentrale Regelverwaltung — einmal ändern, überall durchsetzen
- Trust Score Berechnung basierend auf historischer Compliance (siehe Dim 04)
- Audit Trail für jede evaluierte Aktion
Governance-as-a-Service (GaaS)
A dedicated middleware layer functioning as a proxy between agents and the external world (tools, APIs, external systems). The architecture combines Constitutional AI (Bai et al., 2022) with Ostrom's institutional design principles in an operationally enforceable middleware.
Mechanism
- Agent plans an action (e.g., "Send contract offer to client X at 25% discount")
- GaaS layer intercepts the intent before execution
- Intent evaluated against declarative Policy-as-Code rules
- If compliant: Action proceeds and is logged
- If violation: Action blocked. Agent receives structured feedback ("Action denied: discount exceeds maximum of 20%. Adjust and resubmit.")
Properties
- Central rule management — update once, enforce everywhere
- Trust Score computation based on historical compliance (see Dim 04)
- Audit trail for every evaluated action
GaaS Policy Example (YAML)
gaas_policy:
id: "POL-CONTENT-PUB-001"
title: "Content Publication Policy"
type: standing
scope:
domains: ["content-operations"]
autonomy_levels: ["L2", "L3", "L4"]
rules:
- action: "publish_to_production"
condition: "autonomy_level >= L3 AND content_type != 'legal'"
verdict: allow
- action: "publish_to_production"
condition: "content_type == 'legal'"
verdict: escalation_required
escalation_target: "principal"
review_date: "2026-05-07"
evaluation_criteria:
- "Publication error rate < 1%"
- "No unreviewed legal content published"Domain Risk Appetite
Jede Domäne deklariert eine explizite Risikobereitschaft, die das Governance-Gewicht bestimmt:
| Risikobereitschaft | Governance-Gewicht | Autonomie-Ceiling |
|---|---|---|
| Konservativ | Schwer — häufige GaaS-Checks, niedrige Pre-Authorization | L2 |
| Moderat | Standard-GaaS-Checks, moderate Pre-Authorization | L3 |
| Aggressiv | Leicht — nur Standing Policies, breite Pre-Authorization | L4 |
Governance-Zyklen
- Governance Review (wöchentlich): Agenda-Bildung aus Governance Backlog, Proposal-Forming, Consent-Runde, Einwand-Auflösung, Logbuch-Eintrag, Meta-Assessment
- Operational Coordination (täglich): Leichtgewichtiger Batch-Statusaustausch. Jeder Agent veröffentlicht Zustand, Coordinator aggregiert, Agenten bestätigen Commitments
- Planning & Review (zweiwöchentlich): Review abgeschlossener Arbeit, Planung kommender Arbeit, Prozessbewertung
Compliance-Mapping
- NIST AI RMF — GOVERN → GaaS + Policy Lifecycle; MAP → Rollendesign + Risk Appetite; MEASURE → KPI Framework; MANAGE → Eskalation + Degraded Ops
- ISO/IEC 42001 — Dokumentation → Agent Manifests + Logbook; Monitoring → Trust Scores + KPIs
- EU AI Act — Hochrisiko → L0–L2 mit HITL; Transparenz → Agent-Identitäts-Disclosure
- DSGVO — Datenminimierung → Tool-Whitelists; Zweckbindung → Manifest-Constraints
Domain Risk Appetite
Each domain declares an explicit risk appetite that determines the governance weight applied:
| Risk Appetite | Governance Weight | Autonomy Ceiling |
|---|---|---|
| Conservative | Heavy — frequent GaaS checks, low pre-authorization | L2 |
| Moderate | Standard GaaS checks, moderate pre-authorization | L3 |
| Aggressive | Light — standing policies only, broad pre-authorization | L4 |
Governance Cycles
- Governance Review (weekly): Agenda formation from governance backlog, proposal forming, consent round, objection resolution, logbook entry, meta-assessment
- Operational Coordination (daily): Lightweight batch state exchange. Each agent publishes state, coordinator aggregates, agents confirm commitments
- Planning & Review (bi-weekly): Review completed work, plan upcoming work, evaluate processes
Compliance Mapping
- NIST AI RMF — GOVERN → GaaS + policy lifecycle; MAP → role design + risk appetite; MEASURE → KPI framework; MANAGE → escalation + degraded ops
- ISO/IEC 42001 — Documentation → Agent Manifests + logbook; Monitoring → trust scores + KPIs
- EU AI Act — High-risk → L0–L2 with HITL; Transparency → agent identity disclosure
- GDPR — Data minimization → tool whitelists; Purpose limitation → manifest constraints
Degraded Operations Protocol
Wenn die Governance-Infrastruktur ausfällt, greifen vordefinierte Fallback-Regeln:
| Level | Trigger | Agent-Verhalten |
|---|---|---|
| Grün | Alle Systeme operativ | Volle Autonomie innerhalb zugewiesener Stufe |
| Gelb | 3 aufeinanderfolgende fehlende Heartbeats | Autonomie um 2 Stufen senken; nur Standing-Policy-konforme Aktionen |
| Rot | GaaS unerreichbar >5 Min | Nur letzte bekannte Standing Orders; keine neuen Initiativen; Graceful Shutdown nach 30 Min |
When governance infrastructure becomes unavailable, pre-defined fallback rules apply:
| Level | Trigger | Agent Behavior |
|---|---|---|
| Green | All systems operational | Full autonomy within assigned level |
| Yellow | 3 consecutive missed heartbeats | Drop autonomy by 2 levels; execute only standing-policy-compliant actions |
| Red | GaaS unreachable >5 min | Execute last-known standing orders only; no new initiatives; graceful shutdown at 30 min |
Die GaaS-Schicht ist branchenunabhängig. Branchenpartner definieren branchenspezifische Policies (z.B. Compliance-Regeln für Energieversorger, Qualitätsstandards für Fertigung), die in die zentrale GaaS-Architektur eingehängt werden.
The GaaS layer is industry-agnostic. Industry partners define domain-specific policies (e.g., compliance rules for energy utilities, quality standards for manufacturing) that plug into the central GaaS architecture.