security-scan / secret-scan (push) Failing after 3s

Details

feat(compliance): add NIS2/ISO27001/SOC2 mappers, Compliance-Robot, EU-AI-Act-Agent; docs(flexoptix-os): consolidation concept

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.

2026-07-14 14:46:51 +00:00

7.1 KiB

Raw Blame History

Qualitätsmanagement, Compliance-Robot und EU-AI-Act-Agent

Das war dein expliziter Nachtrag: "Qualitätsmanagement, Compliance und EU AI Act Implementierung innerhalb der Firma, innerhalb des Systems, ein Roboter mit Ansagen, was wir zu machen haben, um compliant zu werden — NIS2, SOC 2, ISO 27001 — und ein separater Roboter für EU AI Act."

Das ist der einzige Teil dieses Konzepts, der bereits als lauffähiger, getesteter Code in diesem Branch existiert (nicht nur als Plan) — weil Magatama/ShieldX bereits ein Compliance-Modul hatte (src/compliance/: ATLASMapper, OWASPMapper, EUAIActReporter, ReportGenerator), an das sich die neuen Bausteine sauber anschließen ließen.

Was neu hinzugefügt wurde

Datei	Rolle
`src/compliance/NIS2Mapper.ts`	Bildet die 10 Risikomanagement-Maßnahmen aus NIS2 Art. 21(2)(a)–(j) auf ShieldX-Fähigkeiten ab
`src/compliance/ISO27001Mapper.ts`	Bildet eine repräsentative Auswahl von ISO/IEC-27001:2022-Annex-A-Controls ab (technologisch/organisatorisch/Personen/physisch)
`src/compliance/SOC2Mapper.ts`	Bildet SOC-2-Trust-Services-Kriterien ab (Security/Confidentiality/Processing Integrity/Availability/Privacy)
`src/compliance/ComplianceRobot.ts`	Der "Compliance-Robot" — aggregiert alle drei Mapper + EU-AI-Act-Report zu einem priorisierten, verantwortlichkeitszugewiesenen Aktionsplan
`src/compliance/EUAIActAgent.ts`	Der "EU-AI-Act-Agent" — Risikoklassifizierung (Art. 6/Annex III), Annex-IV-Dokumentationsgerüst, Art.-72-Post-Market-Monitoring-Plan
`src/types/compliance.ts`	Erweitert um alle neuen Typen

Alle Module folgen exakt dem bestehenden Code-Stil (TypeScript strict, Object.freeze, JSDoc auf jeder public Methode, keine rohen Nutzerdaten). 5 neue Testdateien (tests/unit/compliance/*.test.ts) decken die neuen Module ab — 46 neue Tests, alle grün, Gesamt-Testsuite 411/411 bestanden.

Warum ehrlich über Lücken statt Grün-Färben

Jeder Mapper markiert explizit, was ShieldX nicht abdeckt — nach demselben Prinzip wie die bereits bestehende EU-AI-Act-Dokumentation ("ShieldX is not a legal compliance tool"). Beispiele:

NIS2 Art. 21.2.j (MFA, sichere Kommunikation): implemented: false — ShieldX hat keine eigene Auth-Schicht; das muss die umgebende Anwendung liefern (NextAuth, IdP, ...).
NIS2 Art. 21.2.i (HR-Sicherheit, Access Control, Asset Management): implemented: false — Organisationsthema, kein Software-Thema.
ISO 27001 A.7.1 (physische Sicherheitszonen): implemented: false — ShieldX ist reine Software ohne physischen Fußabdruck.
SOC 2 A1.2 (Verfügbarkeit/Backup/Recovery): implemented: false — Infrastrukturthema (Hosting, Failover), nicht Bibliotheksthema.
SOC 2 P1.1 (Datenschutzhinweise/Einwilligung): implemented: false — Rechtsthema.

Das ist bewusst so gebaut: Ein "Compliance-Robot", der 100 % Abdeckung behauptet, wo Magatama technisch gar nicht zuständig sein kann, wäre irreführend und würde bei einem echten Audit auffliegen. Der Wert liegt darin, präzise zu zeigen, was durch Magatama bereits erledigt ist (Vorfall-Behandlung, Lieferketten-Prüfung, Logging, Verschlüsselungs- Verifikation, Monitoring — das ist ein erstaunlich großer Teil!) und was explizit an Management/Legal/Engineering zurückgespielt werden muss.

Der Compliance-Robot in Aktion

import { ComplianceRobot } from '@shieldx/core/compliance'

const robot = new ComplianceRobot()
const assessment = robot.assess(currentLearningStats)

// assessment.overallReadiness → { nis2: 0.6, iso27001: 0.85, soc2: 0.8, eu_ai_act: 0.8 }
// assessment.actionPlan → sortiert nach Priorität, z.B.:
//   { framework: 'nis2', controlId: 'NIS2.Art21.2.j', priority: 'high',
//     owner: 'engineering', recommendation: 'ShieldX hat keine eigene Auth-Schicht...' }

Dieser Aufruf lässt sich zeitgesteuert (z. B. wöchentlich, analog zum bestehenden generateComplianceReport-Muster) in ein Dashboard einspeisen — genau das Cockpit, das du für das Management wolltest.

Der EU-AI-Act-Agent: die wichtigste Korrektur zuerst

Die Hochrisiko-Pflichten aus Annex III wurden von der EU-Kommission verschoben — nicht mehr 2. August 2026, sondern 2. Dezember 2027 für eigenständige Hochrisiko-KI-Systeme, und 2. August 2028 für Hochrisiko-Systeme, die in Annex-I-regulierte Produkte eingebettet sind. Das steht jetzt maschinenlesbar im Code (EU_AI_ACT_TIMELINE in EUAIActAgent.ts), damit diese Frist nicht versehentlich mit dem alten (falschen) Datum in Planungen landet. Wichtig: Diese Verschiebung war zum Zeitpunkt der Recherche (Draft-Guidance, offen für Stakeholder-Feedback bis 23. Juni 2026) noch nicht final — vor einer Fristenplanung im AI Act Service Desk gegenprüfen.

Der EUAIActAgent bietet drei Funktionen, die über das bestehende reine Reporting hinausgehen:

classifyRisk(deploymentContext) — Stichwort-basierte Vorprüfung, ob ein LLM-System in eine Annex-III-Hochrisikokategorie fällt (Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, Strafverfolgung, Migration/Grenzschutz, Justiz) oder gar eine nach Art. 5 verbotene Praxis berührt (Social Scoring, subliminale Manipulation). Das ist explizit keine Rechtsberatung — jedes Ergebnis trägt requiresLegalReview: true.
generateAnnexIVDocumentation(stats) — erzeugt die technischen Felder der Annex-IV-Dokumentation (Risikomanagement, Logging, Human Oversight, Genauigkeit/ Robustheit/Cybersicherheit) aus echten ShieldX-Betriebsdaten und listet separat auf, welche der ca. 47 Annex-IV-Felder zwingend juristischen/geschäftlichen Input brauchen (Anbieteridentität, Inverkehrbringungs-Kanäle, Konformitätsbewertungsverfahren).
generatePostMarketMonitoringPlan(stats) — Art.-72-Plan, der auf real existierende ShieldX-Mechanismen verweist (Drift-Erkennung, aktives Lernen, Red-Team-Selbsttests), statt einen generischen Prozess zu erfinden.

Fraunhofer IAIS AI Assessment Catalog — Einordnung

Der "AI Assessment Catalog" von Fraunhofer IAIS wurde recherchiert, weil er ein naheliegendes Vorbild für strukturierte KI-Bewertung ist. Wichtige Klarstellung: Er ist kein harmonisierter Standard und ersetzt kein offizielles Konformitätsbewertungsverfahren nach EU AI Act — er ist ein Entwicklungsleitfaden mit 6 Vertrauenswürdigkeits-Dimensionen. Nützlich als Design-Input für zukünftige EUAIActAgent-Erweiterungen, aber nicht als Compliance-Abkürzung zu verkaufen.

Qualitätsmanagement — Anschlussstelle

Das im Auftrag erwähnte "Qualitätsmanagement" fügt sich technisch dort ein, wo ComplianceReport.coverageScore und ComplianceRobotAssessment.overallReadiness bereits Kennzahlen liefern: Ein QM-Cockpit im Flexoptix-OS-Dashboard kann pro Fachtool (BEO, Fossy, Lupo, BIO) denselben ComplianceRobot instanziieren (sobald diese Tools ebenfalls über die Magatama-Middleware laufen) und die Werte nebeneinander darstellen — das liefert die "komplette Transparenz des Unternehmens", die als Ziel genannt wurde, ohne dass jedes Fachtool eigene QM-Logik bauen muss.

7.1 KiB Raw Blame History Unescape Escape