Architektur von IIO

1. Systemaufbau: Eine Engine, viele Adapter

IIO besteht aus einem Kern — der Governance Engine — und einer Vielzahl von Adaptern, die verschiedene Arbeitsweisen ermöglichen:

• Governance Engine: Policy Decision Points (PDPs), HITL-Gates, Compliance-Checks, Evidence-Trail
• 5 Adapter:
  • coding — AI-Coding-Agenten mit Sandbox und Planner-Worker-Judge
  • flow-runner — Deklarative Workflows aus flow.yaml
  • www-publishing — Content, Websites, Living Books
  • execution-dispatch — Remote-Operationen (SSH, Ansible, Stack-Ops)
  • direct-executor — Direkte Konfiguration und Berechnungen
• Projection Engine: Nimmt ein Tenant-Profil (KMU, Enterprise, Developer-Partner) und materialisiert einen konkreten Systemzustand

Ergebnis: Ein Tenant mit Profil enterprise erhält Keycloak, Monitoring, Dedicated GPU, Service Topology — automatisch. Ein kmu-standard erhält Shared GPU, zentrale Keycloak, einfacheres Monitoring.

2. Ausführungspfad: Intent → Policy → Adapter → Evidence

Jede Aktion in IIO folgt demselben Pfad — ob Coding, Deployment, Content-Publishing oder Infrastruktur-Betrieb:

graph TD
    A["Operator/Agent
formuliert Intent"] -->|"Deploy Keycloak"| B["Policy Decision Point
aggregiert 5 Quellen"]
    B -->|"Kontext: Server,
Sensibilität, Budget"| CPDP<br/>Entscheidung?
    C -->|AUTO| D["Adapter
auto-exec"]
    C -->|HITL| E["Gate öffnen
Operator wartet"]
    C -->|BLOCK| F["Action stoppen
dokumentiert"]
    E -->|"genehmigt"| D
    D -->|"coding"| G1["Sandbox +
Planner-Worker-Judge"]
    D -->|"flow-runner"| G2["flow.yaml
Stages+Gates"]
    D -->|"www-publishing"| G3["Emotion-Rendering
GEO-Optimize"]
    D -->|"execution-dispatch"| G4["SSH/Ansible
Multi-Server"]
    D -->|"direct-executor"| G5["Direkte Config"]
    G1 --> H["Evidence:
SHA+Gate+Actor
+Timestamp"]
    G2 --> H
    G3 --> H
    G4 --> H
    G5 --> H
    H --> I["Aktion
abgeschlossen"]
      

Ausführungspfad als Schritte:

1. Intent formulieren: Operator oder Agent äußert einen Wunsch: "Deploy Keycloak zu diesem Server", "Generiere Code für Feature X", "Publiziere Blogpost".
2. Policy Decision Point (PDP) prüft: Der PDP aggregiert 5 Quellen: Governance-Policy, Infra-Mode, Cost-Budget, Data-Sensitivity, Deployment-Zone. Beispiel:
   • Kleine Änderung im Standard-Server → AUTO
   • Production-Deploy → HITL (Gate öffnet, Operator genehmigt)
   • Kostspieliger Cluster-Restart während Cost-Hold → BLOCK
3. PDP entscheidet: AUTO / HITL / BLOCK
   • AUTO: Adapter wird sofort aufgerufen
   • HITL: Gate öffnet, Operator wartet auf Genehmigung
   • BLOCK: Action wird gestoppt, Grund wird dokumentiert
4. Adapter wählt Ausführungsmodus: Je nach Kartenkarte (code-feature, flow, content, infra, config):
   • coding: Sandbox spinnt auf, Planner-Worker-Judge-Loop, Code wird generiert
   • flow-runner: flow.yaml wird sequenziell/parallel abgearbeitet, HITL-Gates beachtet
   • www-publishing: Emotion-Sensitivität bestimmt Ton, GEO-Optimization skaliert Bilder
   • execution-dispatch: SSH-Befehl oder Ansible-Playbook auf Multi-Server, mit automatischem Retry
   • direct-executor: Direkte YAML-Schreib- oder Konfigurationsanwendung
5. Aktion ausgeführt: Adapter macht die Arbeit (Code, Deployment, Content, Berechnung).
6. Evidence loggen: Jeder Schritt wird dokumentiert:
   • Git-Commit-SHA oder Deployment-Manifest-ID
   • Gate-ID (falls HITL)
   • Actor (Operator/Agent-ID)
   • Timestamp und Ergebnis
7. Audit-Trail komplett: Die Aktion ist für immer nachvollziehbar. Kein Silent-State — alles Evidence.

3. Flow-Modell: Workflows mit Gates und Reifegrad

IIO definiert 651 Flows — deklarative Workflows, die komplexe Operationen aus wiederverwendbaren Stufen aufbauen.

Flow-Struktur:

• flow.yaml: Deklaration einer Workflow-Sequenz (oder DAG)
• Stufen (stages): Jede Stufe hat einen eindeutigen Task (Ansible, Bash, Python, HTTP-Call, etc.)
• HITL-Gates: Beliebig viele Gates pro Flow — Operator kann Workflows pausieren und genehmigen
• Evidence-Sammlung: Jede Stufe schreibt ihre Outputs (Logs, Metriken, Ergebnisse)
• Reifegrad: Flows haben Status (draft, stable, production, deprecated) — wird bei Ausführung geprüft

Beispiel: Der Flow deploy-new-tenant hat 3618 kumulierte Schritte über alle Flows hinweg. Ein einzelner Flow kann 20–50 Stufen haben.

Für Inspektionen: /flows (Seite zeigt alle Flows mit Reifegrad, letztem Run, und Details).

4. Betriebsmodelle: Geteilt, Dediziert, On-Prem

Die Projection Engine kann jeden Tenant in einem von drei Betriebsmodellen instantiieren:

Ein Tenant kann mehrere Modelle mischen: z.B. Datenbank dediziert, KI-Inferenz geteilt, Geheime Keys on-prem.

5. KI-Betrieb: Lokale Inferenz, LiteLLM-Router, 0 EUR Token-Kosten

IIO betreibt lokale KI-Modelle auf Nvidia-GPUs. Das bedeutet: Alle Inferenzen laufen inneres Rechenzentrums, 0 EUR Token-Kosten.

Infrastruktur:

• GPU-Fleet: Mehrere spezialisierte Rechner mit Nvidia GPUs (H100, A40, etc.), zusammengefasst unter Ollama
• LiteLLM-Router: Intelligent verteilt Anfragen an die beste GPU. Load-Balancer und Fallback bei Ausfällen.
• Ollama: Open-Source-Server, der lokale Modelle (Llama, Mistral, CodeLlama) hostet
• Cost-Guard: Monitoring von GPU-Auslastung, Speicher, Wärme. Automatischer Shutdown bei thermischen Problemen.

Warum 0 EUR?

Wenn ein Coding-Agent Anfragen sendet oder ein Operator einen Publishing-Flow startet, wird die KI-Berechnung lokal erledigt:

1. Anfrage kommt rein → LiteLLM-Router entscheidet, welche GPU
2. Ollama führt Inferenz lokal aus (auf eigenem Rechenzentrum)
3. Ergebnis kommt zurück
4. 0 Netzwerk nach außen → 0 externe API-Kosten

Grenze: Externe APIs

Erreichbare Grenze: Wir nutzen externe APIs nur, wenn lokal nicht möglich:

• Realtime-Finanzquoten → externe API (kostet ~€0,02/Anfrage)
• Rechtsvalidation (DSGVO-Abfrage) → externe Spezialist-API (kostet €0,50/Abfrage)
• Bild-Generierung via FLUX → lokal oder externe FLUX-API falls GPU zu langsam

Transparenz: Jeder Tenant weiß, wo die Grenzen liegen. Wir nennen die Kosten explizit.

6. Datenhaltung und Mandantentrennung

Jeder Tenant hat eine logische Datengrenze. Physisch können mehrere Tenants Infrastruktur teilen, aber Daten sind isoliert:

• Datenbanknamespace: PostgreSQL/Direktus-Schemas pro Tenant
• Keycloak-Realm: Jeder Tenant hat eigenen SSO-Realm oder teilt sich Realms mit RBAC-Trennung
• Dateisystem-Trennung: S3-Buckets oder lokale Volumes pro Tenant
• HITL-Identity: Access-Policy verfügt, wer auf welche Tenant-Daten zugreifen darf

Keine Tenant-Daten sehen andere Tenants. Das ist per Policy erzwungen und mit automatischer Audit-Kontrolle überwacht.

7. Beobachtbarkeit: Metriken, Logs, Alarmierung und Rogue-Unit-Erkennung

IIO betreibt ein durchgehendes Monitoring-System, das alle Ebenen der Infrastruktur beobachtet:

Säulen der Beobachtbarkeit:

• Metriken: VictoriaMetrics sammelt Zeitserien-Daten (CPU, Speicher, Netzwerk, GPU-VRAM) von allen Servern
• Logs: Loki speichert strukturierte und unstrukturierte Logs (Syslog, Docker, Applikations-Logs) mit 30-Tage-Retention
• Alarme: Grafana + Alertmanager triggern bei kritischen Metriken (z.B. Disk >90%, API-Fehler >5%)
• Health-Checks: Blackbox-Exporter testet die Erreichbarkeit von Services alle 30 Sekunden
• Service Topology: Überwacht, welche systemd-Services auf jedem Server autorisiert sind (und erkennt illegale/verdächtige Services)

Service Topology — Rogue-Unit-Erkennung:

Die Service Topology Layer hat eine Soll-Liste aller autorisierten systemd-Services pro Server. Bei jeder Prüfung wird die Ist-Liste gegen die Soll-Liste verglichen:

• Expected: z.B. caddy.service, iio-mcp.service — autorisiert
• Missing: z.B. fail2ban.service soll laufen, fehlt → WARN, Service wird rekonstruiert
• Rogue: z.B. crypto-miner.service läuft, aber nicht in der Soll-Liste → CRITICAL HITL-Gate öffnet sofort, Service wird deaktiviert

Praktisches Beispiel: Wenn ein Security-Incident eine systemd-Unit mit verdächtigem Namen (z.B. system-update-helper.service, die eigentlich ein Cryptominer ist) auf einen Server schleicht, erkennt die Service Topology das beim nächsten Scan und meldet es als Rogue-Unit mit höchster Priorität.

Node Health:

Pro Server wird der Zustand aktualisiert: Disk-Nutzung, Swap, Docker-Daemon-Health, SSH-Schlüssel-Rotation, Zertifikat-Ablauf. Proaktive Benachrichtigungen vor kritischen Events.

8. Kooperation mit externen Systemen: MCP, A2A, Agent-Docking

IIO ist designed, um mit externen Systemen zu kooperieren. Drei Protokolle verbinden externe Agenten/Tools zu IIO:

• MCP (Model Context Protocol): Claude, ChatGPT, Cursor und andere können 12 IIO-Governance-Tools aufrufen. Über stdio oder HTTP.
• A2A (Agent-to-Agent): Andere AI-Agenten (z.B. Gemini, CrewAI, AutoGen) können Tasks an IIO senden und auf Ergebnisse warten.
• Agent-Docking: Ein Coding-Agent oder Agentur-AI kann sich selbst in IIO "andocken" — erhält dann Zugriff auf Keycloak, Queue, HITL-Gates.

Für Details: /kooperation (Seite zeigt Protokolle, Beispiele und Integrationsschritte).

9. Grenzen: Was IIO nicht löst