# RunWork OS — Externalisierung als Produkt

Ziel laut Auftrag: die intern gewonnene Erfahrung (schnelle Analyse und Empfehlung von
Geschäftsabläufen) als eigenständiges Produkt "RunWork OS" für andere Unternehmen
anbieten — ein "Hebel, mit dem wir in Zukunft Adapter für andere Unternehmen bauen können,
um dort eine schnelle Evaluierung der Geschäftsabläufe zu bekommen."

Dieses Kapitel ist bewusst kurz gehalten, weil RunWork OS als Produkt logisch **nachgelagert**
ist: Es kann erst entstehen, wenn Flexoptix OS intern so weit konsolidiert ist, dass sich
die Muster (FoCI-artige Abteilungsauswertung, Magatama als Sicherheitsschicht,
ComplianceRobot als Reifegrad-Messung) sauber von Flexoptix-internen Daten trennen lassen.

## Was RunWork OS strukturell von Flexoptix OS unterscheiden muss

| Aspekt | Flexoptix OS (intern) | RunWork OS (extern, Produkt) |
|---|---|---|
| Datenmodell | Fest verdrahtet auf Flexoptix-Abteilungen/-Prozesse | Muss generisch/konfigurierbar sein (Mandantenfähigkeit) |
| Compliance-Mapper (NIS2/ISO/SOC2) | Fest auf ShieldX-Fähigkeiten gemappt | Muss pro Kunde die *deren* Systemlandschaft abbilden — die hart codierten `shieldxEvidence`-Listen in `NIS2Mapper.ts` etc. sind ein Beispiel, kein Produkt |
| Anonymisierung | Ein Unternehmen, ein Trust-Kontext | Mandantentrennung zwingend (Presidio-Pipeline pro Mandant, keine geteilten Vektor-Stores) |
| Betriebsmodell | On-Prem, ein Deployment | Muss als deploybares Paket (Docker-Compose/Helm) pro Kunde installierbar sein |

## Warum ComplianceRobot als Vorlage für den "Hebel" taugt

Die Architekturentscheidung, in `ComplianceRobot.ts` **jede Kontrolle explizit als
`implemented: true/false` mit Beleg oder Lückenbegründung** zu modellieren (siehe Kapitel
03), ist zufällig genau das Muster, das RunWork OS für "schnelle Evaluierung von
Geschäftsabläufen" braucht: eine strukturierte Ist-Zustand-Abfrage plus priorisierter
Aktionsplan, generisch über Frameworks hinweg. Der Unterschied zum heutigen Code: RunWork
OS bräuchte diese Mapper-Tabellen **konfigurierbar** (z. B. aus einer Kunden-Onboarding-
Befragung generiert) statt hart codiert.

## Empfehlung

RunWork OS jetzt **nicht** parallel zu BEO/Magatama/BIO aktiv entwickeln. Stattdessen:

1. Flexoptix OS intern bauen (Kapitel 02–04), bewusst mit klarer Trennung zwischen
   "Flexoptix-spezifisch" und "generisch übertragbar" (genau wie die Tabelle oben zeigt).
2. Sobald 2–3 Fachtools produktiv unter Flexoptix OS laufen, eine Bestandsaufnahme machen:
   Welche Teile von ComplianceRobot/EUAIActAgent/BEO-Skill-Routing sind bereits generisch
   genug, um als RunWork-OS-Kern ausgekoppelt zu werden?
3. Erst dann RunWork OS als eigenes Repo/Produkt aufsetzen — mit Mandantenfähigkeit von
   Anfang an mitgedacht, nicht nachträglich draufgesetzt.

Diese Reihenfolge verhindert das klassische Risiko, ein "Plattform-Produkt" zu bauen,
bevor der erste echte interne Anwendungsfall (Flexoptix selbst) bewiesen hat, dass das
Muster trägt.