1b5f698f4c
Extends the existing ATLAS/OWASP/EU-AI-Act compliance module with three new control-framework mappers (NIS2 Art. 21(2), ISO/IEC 27001 Annex A, SOC 2 Trust Services Criteria), each honestly marking what ShieldX covers vs. what remains an organizational/legal gap. ComplianceRobot aggregates all four frameworks into a single prioritized, owned action plan. EUAIActAgent adds active workflows on top of the existing static reporter: Art. 6/Annex III risk pre-screening, Annex IV technical documentation scaffolding, Art. 72 post-market monitoring plan, and the corrected 2027/2028 enforcement timeline. Adds docs/flexoptix-os/ — a broader consolidation concept covering the current state (Magatama/ShieldX, EO Global Pulse), target architecture for BEO (LibreChat/Presidio-based), a Transceiver Intelligence Platform architecture recommendation, and RunWork OS externalization strategy, grounded in adversarially-verified research citations.
2.9 KiB
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:
- Flexoptix OS intern bauen (Kapitel 02–04), bewusst mit klarer Trennung zwischen "Flexoptix-spezifisch" und "generisch übertragbar" (genau wie die Tabelle oben zeigt).
- 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?
- 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.