Regulatorischer Kontext — EU AI Act
Informativer Überblick über den EU-Rechtsrahmen und seine Entsprechung mit den strukturellen Eigenschaften der Entscheidungsinfrastruktur.
AI Act — Status & Zeitplan
Der wichtigste EU-Rahmen ist die Verordnung (EU) 2024/1689.
In Kraft getreten am 1. August 2024.
Die Anwendung erfolgt gestaffelt: Einige Bestimmungen gelten bereits, andere sind für den 2. August 2026 bzw. den 2. August 2027 vorgesehen.
Am 19. November 2025 veröffentlichte die Europäische Kommission einen Vorschlag zur Änderung des AI Acts ("Digital Omnibus on AI"). Dieser Vorschlag durchläuft das Gesetzgebungsverfahren und ist noch nicht in Kraft. Fristen und Verpflichtungen können sich ändern.
Architektonische Entsprechung
High-Level-Mapping zwischen regulatorischen Erwartungen und strukturellen Eigenschaften.
| Regulatorische Erwartung | Strukturelle Eigenschaft |
|---|---|
| Entscheidungsnachvollziehbarkeit | Deterministische Evaluierung verknüpft mit expliziter Richtlinie |
| Aufbewahrung von Aufzeichnungen | Append-only (Nur-Hinzufügen) Ledger |
| Transparenz | Exportierbare, überprüfbare Beweisartefakte |
| Menschliche Aufsicht | Explizites Routing von unbestimmten (I) Ergebnissen |
| Zugangs-Governance | Richtliniengebundene Autorisierung |
| Schrittweise Einführung | Beobachten / Vergleichen / Anwenden mit Rollback-Möglichkeit |
| Post-Market-Überwachung (Art. 72) | KL-Divergenz-Drifterkennung, T/F/I-Verteilung, Eskalationsmetriken |
| Erklärbarkeit (Art. 13) | Deterministische mehrsprachige Erklärungen (FR/DE/IT/EN), kein LLM |
| Risikomanagement (Art. 9) | AI-Systemrisikoregister mit automatischer Anhang-III-Klassifizierung |
| Anhang III-Klassifizierung | 15-Fragen-Fragebogen, automatisches Pflichtenmapping Art. 9–72 |
| Meldung schwerer Vorfälle (Art. 73) | Automatische Erkennung, Schweregrad-Klassifizierung, Fristenverfolgung, Behördenbenachrichtigung |
| Multi-Regulierungs-Compliance | Regulierungsübergreifend: 8 Frameworks (EU AI Act, DORA, MiFID II, FINMA, DSGVO, LPD/nDSG, SOX, Basel III), 27 Artikel |
| AI-System-Transparenz | AI Bill of Materials (SPDX 3.0): Komponenteninventar pro Entscheidung und System mit Integritätsprüfung |
| Externe Verifizierbarkeit | Öffentliches Verifikationsportal: Zero-Knowledge-Verifikation über Merkle-Inklusionsbeweise |
Von Verpflichtungen zur Architektur
Die Kernverpflichtungen des EU AI Acts für Hochrisiko-Systeme sind keine Checkliste. Sie sind architektonische Anforderungen. OmegaOS™ implementiert jede als technische Eigenschaft.
| Artikel | Verpflichtung | OmegaOS™ Eigenschaft |
|---|---|---|
| Art. 9 | Risikomanagementsystem | Risk Registry + Ascension-Kohärenzprüfung |
| Art. 12 | Automatische Protokollierung / Nachvollziehbarkeit | Append-only Decision Evidence Log |
| Art. 13 | Transparenz | Deterministische mehrsprachige Erklärungen |
| Art. 14 | Menschliche Aufsicht | Trilean-Logik: Unbestimmt erzwingt Eskalation |
| Art. 15 | Genauigkeit, Robustheit, Sicherheit | Formale Invarianten (TLA+), Merkle-Integrität, Ed25519 |
| Art. 72 | Post-Market-Überwachung | KL-Drifterkennung, T/F/I-Verteilung, automatisierte Alarme |
| Art. 73 | Meldung schwerer Vorfälle | Automatisierte Erkennung, Schweregrad-Fristen, Berichterstellung, Behördenbenachrichtigung |
Compliance ist im Code verifizierbar — nicht in einem Dokument.
Multi-Regulierungs-Compliance
Regulatorische Verpflichtungen stammen nicht aus einem einzigen Framework. Banken stehen gleichzeitig vor EU AI Act, DORA, MiFID II, FINMA, DSGVO, LPD/nDSG, SOX und Basel III. OmegaOS™ bewertet jede Entscheidung gegen alle anwendbaren Frameworks in einem einzigen Durchlauf.
| Framework | Abgedeckte Artikel |
|---|---|
| EU AI Act | Art. 9, 12, 13, 14, 15, 72, 73 |
| DSGVO | Art. 6, 22, 25, 35 |
| DORA | Art. 6, 8, 11, 17, 28 |
| MiFID II | Art. 16, 25, 27 |
| FINMA | Rundschreiben 2023/1, Model Risk |
| Schweizer nDSG | Art. 22 |
| SOX / Basel III | Operationelles Risiko, Audit-Trail-Anforderungen |
27 Artikel. 8 Frameworks. Eine Compliance-Matrix pro Tenant. Echtzeit-Lückenanalyse.
Meldung schwerer Vorfälle (Art. 73)
Art. 73 des EU AI Acts verpflichtet Anbieter und Betreiber von Hochrisiko-KI-Systemen, schwere Vorfälle an die zuständigen nationalen Behörden zu melden. Die Fristen sind streng: Erstbericht innerhalb von Tagen, vollständiger Bericht mit Korrekturmassnahmen folgt.
OmegaOS™ automatisiert die gesamte Pipeline: Vorfallserkennung aus Drift-Alarmen oder manueller Erfassung, Schweregrad-Klassifizierung mit berechneten Fristen (2/10/15 Tage), Erstellung von Erst- und Vollberichten sowie strukturierte Behördenbenachrichtigung mit vollständigem Audit-Trail.
AI Bill of Materials (SPDX 3.0)
Transparenzverpflichtungen erfordern eine dokumentierte Kenntnis jeder KI-Systemkomponente. OmegaOS™ generiert ein strukturiertes AI Bill of Materials gemäss dem SPDX 3.0 AI Profile-Standard — pro Entscheidung und pro KI-System.
Jedes BOM verknüpft die Entscheidung mit der vollständigen Komponentenkette: Modelle, Datensätze, Trainingsmethoden, Beweisquellen und Risikobewertungen. Die Integrität wird durch kryptografischen Hash verifiziert. Exportformate: SPDX 3.0 JSON-LD, JSON kompakt, Markdown.
Bewiesene Compliance, nicht erklärte Compliance
Traditionelle Compliance stützt sich auf Dokumentation: verfasste Richtlinien, ausgefüllte Checklisten, Audits zu einem bestimmten Zeitpunkt. OmegaOS™ produziert strukturelle Compliance — jede Entscheidung trägt ihren eigenen kryptografischen Korrektheitsbeweis. Die Nachweise werden nicht nachträglich rekonstruiert. Sie werden zum Entscheidungszeitpunkt generiert, unveränderlich aufgezeichnet und auf Anforderung exportierbar.
Dieser Unterschied ist entscheidend, wenn eine Entscheidung vor einer Aufsichtsbehörde verteidigt werden muss. Eine Checkliste erklärt, dass ein Prozess existierte. Ein Entscheidungsbeweis belegt, dass er befolgt wurde — mit den vorliegenden Beweisen, unter den geltenden Regeln, im exakten Moment der Entscheidung.
Haftungsausschluss
Diese Seite dient ausschließlich Informationszwecken. Sie stellt keine Rechtsberatung dar und impliziert keine Zertifizierung, Genehmigung oder formale Compliance.
Verpflichtungen hängen von der Rolle (Anbieter, Betreiber, Importeur), dem Anwendungsfall und der Gerichtsbarkeit ab.
Konsultieren Sie einen qualifizierten Rechtsbeistand.
Besprechen Sie Ihre Anforderungen
Kontaktieren Sie das Engineering-Team, um die regulatorische Ausrichtung für Ihren operativen Kontext zu besprechen.
Kontakt