# 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

```typescript
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:

1. **`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`.
2. **`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).
3. **`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.