Benjamin Admin
75f7bd8de4
User-Stresstest VOR der naechsten Regulierung: passt MaschVO/Data-Act/AI-Act/NIS2 ins 6-Klassen-Modell (Obligation/Capability/Procedure/Control/Evidence + Guidance) OHNE neue Objektklasse? Ergebnis 4x NEIN -> Compliance Meta Model steht. 2 Verfeinerungen (realized_by Capability OPTIONAL; Risiko-Niveau/Frist/Hazard-Schwere/Risiko-Tier = Attribute, keine Klassen). 1 Watch-Point: Hazard/Threat (erst noetig bei quantitativem FMEA-Risiko als First-Class-Knoten, nicht fuer Compliance-Abbildung). Kein Code, keine Regulierung ingestiert. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
160 lines
8.6 KiB
Markdown
160 lines
8.6 KiB
Markdown
# Meta-Model Validation v1 — Ist das Modell regulierungsunabhängig?
|
||
|
||
Status: **Phase 6 — Meta-Validierung (2026-06-26). KEIN neues Coding, KEINE Regulierung ingestiert.**
|
||
Dieses Dokument ist der Stresstest VOR der nächsten Regulierung. Baut auf
|
||
[capability_model_v1.md](capability_model_v1.md) (Modell C, #5b materialisiert) +
|
||
[legal_obligation_layer_v1.md](legal_obligation_layer_v1.md).
|
||
|
||
## Die eigentliche Frage
|
||
|
||
Nicht „welche Regulierung kommt als nächstes?", sondern:
|
||
|
||
> **Kann eine völlig neue Regulierung in dieses Modell eingeordnet werden, OHNE eine neue
|
||
> Objektklasse einzuführen?**
|
||
|
||
Wenn ja für MaschVO + Data Act + AI Act + NIS2 → das ist kein CRA-Graph mehr, sondern ein
|
||
**Compliance Meta Model**. Ab dann bringt jede Regulierung primär *Daten*, nicht *Architektur*.
|
||
|
||
## Das zu testende Modell (6 Klassen + Attribute, KEINE weitere Klasse erlaubt)
|
||
|
||
```
|
||
Regulation
|
||
↓ definiert
|
||
Legal Obligation (CORE ⊇ DOMAIN; tier=LEGAL_MINIMUM/BEST_PRACTICE; objective_tags[]; applicability)
|
||
↓ realized_by (OPTIONAL)
|
||
Capability (regulierungs-agnostische technische Faehigkeit; guidance_basis hier)
|
||
↓ deployed_via
|
||
Procedure
|
||
↓ verified_by
|
||
Control
|
||
↓ produces
|
||
Evidence
|
||
```
|
||
Quer: **Guidance** (NIST/OWASP/ISO/BSI) hängt an der Capability. **Attribute** (keine Klassen):
|
||
`tier`, `objective_tags`, `applicability`, später `deadline`/`risk_level`/`severity`.
|
||
Kanten: realized_by · specializes · contributes_to · deployed_via · verified_by · produces · described_by · same_as.
|
||
|
||
---
|
||
|
||
## Test 1 — Maschinenverordnung (EU) 2023/1230
|
||
|
||
| Modell-Klasse | MaschVO-Inhalt |
|
||
|---|---|
|
||
| Legal Obligation (CORE) | `hazard_minimization` (Sicherheits-Analogon zu attack_surface_minimization), `safe_control_systems`, `machine_risk_assessment`, `ce_conformity`, `instructions_for_use` — exakt die `machine_*`-Obligations, die die Reasoning-Session bereits unabhängig geprägt hat. |
|
||
| Capability | **physische Sicherheitsfunktionen**: `emergency_stop`, `safety_interlock`, `two_hand_control`, `guarding`, `safe_torque_off`. → die **Capability-Klasse generalisiert von Cyber auf physische Safety** (gleiche Klasse, andere Domäne). |
|
||
| Procedure | Risikobeurteilung (ISO 12100), CE-Konformitätsbewertung. |
|
||
| Evidence | Technische Unterlagen, Risikobeurteilungsbericht, Konformitätserklärung. |
|
||
|
||
**Stress-Punkt:** „**Hazard**" (mechanisch/elektrisch/thermisch) = Schadensquelle — weder Obligation
|
||
noch Capability. Kandidat für eine neue Klasse? → **Nein, für die Repräsentation:** ein Hazard ist
|
||
ein *Risiko-Treiber* (Attribut/Applicability der Risikobeurteilungs-Procedure); eine Capability
|
||
*mitigiert* einen Hazard, genau wie eine Cyber-Capability eine (implizite) Bedrohung kontert. `PL/SIL`
|
||
= Attribut (wie `tier`). **Hazard wird erst dann eine Klasse, wenn ihr quantitatives FMEA-Risiko als
|
||
First-Class-Graph-Knoten wollt** (vgl. [[project-fmea-safety-direction]]) — nicht für Compliance-Abbildung.
|
||
|
||
**Verdikt: KEINE neue Klasse.** (Stärkstes Ergebnis: die Capability-Klasse trägt von Cyber zu Safety.)
|
||
|
||
---
|
||
|
||
## Test 2 — Data Act (EU) 2023/2854
|
||
|
||
| Modell-Klasse | Data-Act-Inhalt |
|
||
|---|---|
|
||
| Legal Obligation | `data_act_data_access_by_design`, `data_act_user_data_access`, `data_portability_switching`, `fair_contract_terms` (FRAND), `interoperability` — deckt sich mit den `data_act_*`-Obligations der Reasoning-Session. |
|
||
| Capability | `data_export_api`, `interoperability_interface`, `access_control` (**Reuse**). ABER: `fair_contract_terms` hat **KEINE technische Capability**. |
|
||
| Procedure | FRAND-Klauseln entwerfen; Switching-Prozess. |
|
||
| Evidence | Vertrag/Klauselwerk, API-Doku. |
|
||
|
||
**Stress-Punkt:** **vertraglich-rechtliche Pflichten** (FRAND, Verbot unfairer Klauseln) haben kein
|
||
technisches Mittel. → Beleg, dass **`realized_by Capability` OPTIONAL ist**: manche Obligations werden
|
||
rein über **Procedure (Entwurf) + Evidence (Vertrag)** erfüllt. Das ist KEINE neue Klasse — wir haben
|
||
es schon gesehen (SBOM-Familie war Evidence-/Procedure-lastig, kaum Capability).
|
||
|
||
**Verdikt: KEINE neue Klasse.** Verfeinerung: Capability ist optional (Obligation → Procedure → Evidence
|
||
ohne Capability ist gültig).
|
||
|
||
---
|
||
|
||
## Test 3 — AI Act (EU) 2024/1689
|
||
|
||
| Modell-Klasse | AI-Act-Inhalt |
|
||
|---|---|
|
||
| Legal Obligation | `ai_risk_management_system`, `ai_data_governance`, `ai_technical_documentation`, `ai_transparency_disclosure`, `human_oversight`, `accuracy_robustness`, `fundamental_rights_assessment`. |
|
||
| Capability | `event_logging` (**Reuse**!), `bias_detection`, `accuracy_testing`, `human_oversight_mechanism`, `ai_transparency_notice`. |
|
||
| Procedure | Risikomanagement-Prozess; FRIA-Durchführung; Human-Oversight-Prozess. |
|
||
| Evidence | Technische Dokumentation, FRIA-Bericht, Logs. |
|
||
|
||
**Stress-Punkt:** **Risiko-Klassifikation** (unacceptable/high/limited/minimal) bestimmt, WELCHE
|
||
Obligations gelten. → das ist **Applicability** (existiert bereits; analog zu CRA-Produktklasse).
|
||
`human_oversight` = Procedure + Capability (Oversight-UI). `transparency` = Disclosure (Capability/Evidence,
|
||
wie Cookie/DSE-Offenlegung). `FRIA` = Procedure + Evidence.
|
||
|
||
**Verdikt: KEINE neue Klasse.** Verfeinerung: Risiko-Tier = Applicability-Attribut (vorhanden).
|
||
|
||
---
|
||
|
||
## Test 4 — NIS2 (EU) 2022/2555
|
||
|
||
| Modell-Klasse | NIS2-Inhalt |
|
||
|---|---|
|
||
| Legal Obligation | `nis2_risk_management_measures`, `nis2_incident_reporting`, `supply_chain_security`, `governance_accountability`, `business_continuity`. |
|
||
| Capability | **MFA, transport_encryption, security_monitoring_alerting, patch/update, backup** — **dieselben Capabilities wie CRA**. Das ist die Auszahlung: NIS2-Obligations `realized_by` die bereits gebaute Capability-Schicht. |
|
||
| Procedure | Incident-Response-Prozess; Lieferketten-Audit; Governance-Prozess. |
|
||
| Evidence | Incident-Reports, Audit-Logs, Vorstandsprotokolle. |
|
||
|
||
**Stress-Punkt:** **Meldefristen** (24h/72h/1 Monat) = zeitgebundene Procedure → `deadline` = Attribut.
|
||
`governance_accountability` (Management-Haftung) = organisatorische Obligation → Procedure + Evidence.
|
||
|
||
**Verdikt: KEINE neue Klasse.** Stärkster Reuse-Fall (teilt die CRA-Capability-Schicht vollständig).
|
||
|
||
---
|
||
|
||
## Ergebnis: 4 × NEIN → das Metamodell steht
|
||
|
||
Alle vier Regulierungen passen in die 6 Klassen **ohne neue Objektklasse** — unter zwei
|
||
Verfeinerungen, die der Test selbst aufdeckt (beide sind KEINE neuen Klassen):
|
||
|
||
1. **`realized_by Capability` ist OPTIONAL.** Vertraglich/dokumentarisch/prozessuale Obligations
|
||
(Data-Act-FRAND, NIS2-Governance, AI-Act-FRIA) werden rein über Procedure + Evidence erfüllt.
|
||
2. **Risiko-Niveau / Frist / Hazard-Schwere / Risiko-Tier sind ATTRIBUTE**, keine Klassen
|
||
(`tier`-Muster: `deadline`, `risk_level`, `severity`, `risk_tier`).
|
||
|
||
**Der einzige Watch-Point:** **Hazard / Threat.** Heute implizit (Obligations existieren, um sie zu
|
||
kontern). Eine eigene Klasse wird *erst* nötig, wenn ihr **quantitatives Risiko first-class** modelliert
|
||
(FMEA: Hazard→Risiko→Maßnahme als Graph-Knoten). Für die reine Compliance-Abbildung: nicht nötig.
|
||
→ Das ist die präzise Antwort auf „wo wäre erstmals eine neue Klasse nötig?".
|
||
|
||
## Empirische Stütze (nicht nur Theorie)
|
||
|
||
Die 3. Session (Reasoning Engine) hat **unabhängig** `proposed=True`-Obligations für MaschVO
|
||
(`machine_*`) und Data Act (`data_act_*`) geprägt — und brauchte dafür **keine neue Objektklasse**,
|
||
nur Obligation-IDs. Zwei Sessions kommen unabhängig zum selben Schluss.
|
||
|
||
## Konsequenz für die Reasoning-Schicht (Produktvision)
|
||
|
||
Heute: `Product → Applicable Regulations → Applicable Obligations`.
|
||
Mit der Capability-Schicht wird daraus:
|
||
```
|
||
Applicable Capabilities → Required Procedures → Expected Evidence
|
||
```
|
||
Antwort auf die Kundenaussage „Ich habe X umgesetzt" ist dann nicht „CRA Artikel …", sondern:
|
||
```
|
||
✓ Capability A ✓ Capability B ✗ Capability C
|
||
↓
|
||
erfüllt CRA, MaschVO, NIS2 (teilweise)
|
||
```
|
||
Eine Capability erfüllt Obligations über *mehrere Regulierungen* (n:m) → eine Umsetzung wird gegen
|
||
das gesamte Regelwerk bewertet. Das ist qualitativ ein anderes Produkt als RAG.
|
||
|
||
## Entscheidung / nächster Schritt
|
||
|
||
Wenn dieses Dokument akzeptiert ist („keine weitere Klasse nötig"), verschiebt sich die Arbeit von
|
||
**Architektur** zu **Wissensaufbau**: jede neue Regulierung läuft durch
|
||
`Parser → Discovery-Pipeline → Review → Registry` (vorhandene Tooling), statt das Modell zu ändern.
|
||
Offen für den User: (a) Metamodell als stabil einfrieren? (b) den Hazard/Threat-Watch-Point als
|
||
bewusste Nicht-Klasse dokumentieren (bis FMEA-Quantifizierung)? (c) dann erste Regulierung als DATEN.
|
||
|
||
## Bewusst NICHT in diesem Schritt
|
||
|
||
Kein Code, keine Regulierung ingestiert, keine neue Klasse angelegt. Reiner Modell-Stresstest.
|