AI Governance & Cooperation Framework
Governance ohne Black Box

Die Herausforderung

AI-Systeme werden immer autonomer. Gleichzeitig müssen sie vertrauenswürdig sein. Aber wie kannst du Governance-Anforderungen in Code ausdrücken? Und wie stellst du sicher, dass AI-Agenten sich an Sicherheitsstandards halten?

Das IIO Governance-Framework antwortet: Nicht "verbot alles", sondern "stelle Checkpoints ein". AI-Agenten können autonom arbeiten, pausieren aber vor kritischen Entscheidungen (HITL-Gates) und hinterlassen eine vollständige Evidence-Chain.

259 Governance-Layer: Ein Baukasten für Alle

Die 259 Layer sind nicht eine zentrale Regulierung, sondern ein modularer Baukasten. Jede Organisation instanziiert nur die Layer, die sie braucht. Beispiele:

Besonderheit: Jeder Layer ist selbst ein Micro-Governance-System mit eigenen Policies, Workflows, Compliance-Checklisten und Evidence-Trails. Sie sind keine isolierten Silos — sie sind über eine semantische Knowledge Graph verbunden.

546 Auditierbare Flows

Ein Flow ist ein deklarativer Prozess: "Wenn X passiert, führe Schritte A, B, C aus." Alle 546 Flows sind:

• Deklarativ: YAML-basiert, maschinenlesbar, versionskontrolliert
• Auditierbar: Jeder Schritt erzeugt einen Evidence-Record mit Timestamp, Actor-ID, Input, Output
• HITL-fähig: Flows können Approval-Gates einbauen
• Transaktional: Atomare Ausführung oder vollständiger Rollback
• Observable: Live-Monitoring, Incident-Alerts, Performance-Tracking

HITL-Gate-Pattern: Human-in-the-Loop

HITL (Human-in-the-Loop) ist das Herz des IIO Governance-Frameworks. Vor jeder irreversiblen oder hochriskanten Aktion öffnet sich ein Gate.

Das Wichtigste: HITL ist keine "stop everything"–Strategie. Viele Aktionen sind automiert (LOW-Risk). Nur HIGH/CRITICAL-Aktionen öffnen Gates.

Flow-Schema v2.0: Die Sprache

Flows werden in YAML beschrieben. Flow-Schema v2.0 ist eine Spezifikation für strukturierte, HITL-fähige Workflows.

---
apiVersion: iio.space/v2
kind: Flow
metadata:
  name: provision-tenant
  namespace: infra
  tags: [production, critical]
spec:
  triggers:
    - type: queue
      selector: queue_item_type == "provision_tenant"
  steps:
    - name: validate-input
      uses: builtin/validation
      with:
        schema: tenant-profile.json
    - name: check-duplicate
      uses: layer-data-governance/duplicate-check
    - name: project-config
      uses: projection-engine
      with:
        profile: "$config_input.profile_id"
    - name: gate-approval
      uses: builtin/hitl-gate
      gate_id: "gate.provision-tenant-$config_input.tenant_id"
      classify: HIGH
      timeout_hours: 4
    - name: provision-infrastructure
      uses: infra-production-ops/provision
      if: "gates.approved"
      with:
        tenant_id: "$config_input.tenant_id"
        config: "$config_project.output"
    - name: evidence-audit
      uses: builtin/evidence
      with:
        action_type: "tenant_provisioned"
        actor_id: "$gate.approver_id"
        timestamp: "$now"
        input: "$config_input"
        output: "$config_provision.output"
  on_failure:
    - name: notify-ops
      uses: builtin/notify
      with:
        channel: matrix
        severity: P1
        title: "Tenant Provisioning Failed"

Schlüsselkonzepte:

• triggers: Was startet diesen Flow? (Queue, Cron, API, Event)
• steps: Sequenz von Aktionen, die ausgeführt werden
• uses: Welche Komponente führt den Schritt aus? (builtin, Layer, Remote-Op)
• gate-approval: HITL-Gate mit Classify-Policy (HIGH → HITL immer)
• evidence: Automatische Audit-Trail Erstellung
• on_failure: Was tun, wenn ein Schritt fehlschlägt? (Alerts, Rollback, Escalation)

Projection Engine: Config aus Profilen

Die Projection Engine ist ein deterministischer Generator. Input: ein Tenant-Profil (kmu_standard, enterprise, partner). Output: vollständige YAML-Config (welche Services, welche Limits, welche Features).

services:
  - knowledge-api
  - chat-backend
  - glossary
capacity:
  max_users: 500
  storage_gb: 50
  concurrent_inferences: 10
billing:
  model: flat
  amount_eur: 299
  includes: [5k API calls, 10k chat msgs]
  rate_card: {...}

Warum deterministic? Damit jede Instanz des Profils identische Konfiguration erzeugt. Keine "unterschiedliche Behavior" je nach Laune. Reproduzierbar, versionierbar, auditierbar.

Showcase: Governance als lauffähige Referenzimplementierung

Nicht nur Dokumentation: Governance-Mechanik am Beispiel eines physischen Systems — ein humanoider Roboter (Tony, TonyPi Pro), der sich nur bewegt, wenn ein HITL-Gate genehmigt ist. Risk-Stratifizierung green/yellow/red, Fail-Closed Safe-Ranges, vollständiger Evidence-Trail — dieselbe PDP-Logik wie im Software-Framework, nur auf Servo-Bewegungen angewendet statt auf API-Calls.

6 Proposed Open Standards: Governance & Cooperation

Diese Protokolle formalisieren Muster, die IIO intern lebt — als herstellerneutrale offene Standards zur Nachnutzung durch andere AI-Systeme und Organisationen.

Hinweis: MMASP (Multi-Modal Agent Surface Pattern) beschreibt IIOs eigene Architektur, ist aber kein interoperables Protokoll — kein Wire-Format, keine Drittimplementierung möglich. Dokumentiert als Architecture Pattern in patterns/mmasp/ARCHITECTURE.md ↗.

Vollständiger Reifegrad-Vergleich und Prior-Art-Analyse: maturity-ladder.md ↗ · relation-to-prior-art.md ↗

Vollständig Open Source: Apache-2.0

Das gesamte Framework ist auf GitLab verfügbar:

Verwenden Sie das Framework für:

• Intern: eigene AI-Governance, Compliance-Workflows
• Kunden: als Service (OCC)Governance-as-a-Service)
• Community: Mitgestaltung, Verbesserungsvorschläge