Startseite
AI Act Governance
AI Act Governance

EU AI Act Governance ohne Excel.

Der EU AI Act tritt schrittweise ab August 2026 in Kraft. Für Anbieter und Betreiber von Hochrisiko-KI-Systemen entstehen konkrete technische Pflichten — Risikomanagement (Art. 9), Datenqualität (Art. 10), technische Dokumentation (Art. 11), Logging (Art. 12), Transparenz (Art. 13), Human Oversight (Art. 14), Robustheit (Art. 15). Dieser Hub beschreibt, wie RealSyncDynamics.AI diese Pflichten als laufende Governance-Runtime abbildet — nicht als jährlichen Word-Export.

Klassifizierung statt Vermutung

Der Kern der AI-Act-Compliance ist nicht der Output — es ist die Frage: welche Risikoklasse hat dieser Usecase? Annex III listet acht Bereiche, die automatisch als Hochrisiko gelten: Biometrik, kritische Infrastruktur, Bildung, Beschäftigung, essentielle private und öffentliche Dienste, Strafverfolgung, Migration und Justizverwaltung. Wer ein Recruiting-Tool mit Auto-Screening betreibt, ist nach §4(a) automatisch in Annex III. Wer ein Modell für Krisen-Triage in der Telemedizin laufen lässt, ist in §5.

Der AI-Risk-Classifier in RealSyncDynamics.AI ist deterministisch: Annex I und III sind als Entscheidungsbaum kodiert. Ein KI-Usecase wird über sieben Felder beschrieben (Purpose, Domain, Model-Kind, Decision-Autonomy, Affected-Subjects, Training-Data-PII, Geo-Scope), und die Klasse fällt eindeutig. Bei Edge-Cases (Confidence unter 0.95) wird eine LLM-Review getriggert, die flaggt, aber nicht entscheidet. Die finale Klassifikation landet als ai_act_class-Spalte am Asset und ist an die nachgelagerten Obligations gekoppelt.

Obligation-Engine

Für jeden Hochrisiko-Usecase instanziiert die Obligation-Engine eine Pflichtenliste mit Owner-Role und maschinenprüfbarer Verifikationsmethode. Konkret:

  • Art. 9 (Risikomanagement) — Workflow risk_management_plan muss signiert sein, einmal pro Release.
  • Art. 10 (Data Governance) — jedes Dataset braucht lawful_basis, provenance_url, pii_review_passed.
  • Art. 11 (Annex IV) — Reporting-Service generiert das Pack on demand, aus Live-Graph-State, nicht aus Templates.
  • Art. 12 (Record Keeping) — Telemetrie-Retention mindestens 6 Monate.
  • Art. 13 (Transparenz) — Deployment-Manifest muss transparency_notice_url enthalten, die 200 zurückgibt.
  • Art. 14 (Human Oversight) — Deployment exponiert /override oder ist mit der Approval-Queue verbunden.
  • Art. 15 (Accuracy + Robustness) — Eval-Suite-Ergebnisse mit Mindest-Schwellen pro Release.

Fehlgeschlagene Checks öffnen einen Workflow im Workflow-Engine. Owner-Role wird per RBAC zugewiesen. Approval-SLA und Eskalations-Pfad sind konfigurierbar pro Tenant.

Post-Market-Monitoring

Der AI Act verlangt nicht nur eine Inbetriebnahme-Konformitäts­erklärung — er verlangt laufendes Monitoring. Zwei Detektoren laufen kontinuierlich gegen den Telemetrie-Stream:

  • Drift-Detector — vergleicht die rollende 7-Tage-Verteilung von Inputs/Outputs gegen eine Release-Baseline. KS-Test plus Population Stability Index. Bei PSI > 0.25 wird model.drift.detected emittiert.
  • Performance-Regression-Detector — vergleicht die aktuelle Accuracy auf Canary-Inputs gegen die Release-Zeit-Accuracy.

Beide Detektoren öffnen bei Hochrisiko-Usecases automatisch einen AI-Act-Art.-62-Incident. Der Incident-Workflow hat einen 72-Stunden-Timer für die Meldung an die zuständige Behörde (kombiniert mit GDPR Art. 33, wenn personenbezogene Daten betroffen sind).

Annex IV als Live-Dokument

Anstatt jährlich ein Word-Dokument zu pflegen, generiert das Reporting-Service die Annex IV technische Dokumentation aus dem Live-Graph. Sektion 1 (allgemeine Beschreibung) liest aus AiUsecase-Properties. Sektion 2 (Elemente) joint Model, Dataset, Prompt mit Version-Pins. Sektion 3 (Monitoring) zieht die letzten 90 Tage Drift-/Performance-Findings. Sektion 5 (Changes) ist der gefilterte Audit-Log. Sektion 6 (harmonisierte Normen) sind die Control-Nodes mit framework='EN_ISO_*'.

Output ist eine deterministisch benannte ZIP-Datei (annex-iv-<usecase_id>-<sealed_at>.zip) mit Manifest, SHA-256 pro Datei, signiert. Regenerieren mit identischem Snapshot ergibt eine byte-stabile Datei. Eine Behörde kann den Hash unabhängig nachrechnen — der Pack ist verifizierbar, nicht nur vorgelegt.

Was diese Page nicht ist

Dieser Hub ist keine Rechtsberatung. Wer in Annex III §1 (Biometrik) operiert, braucht eine Konformitätsbewertung durch eine notifizierte Stelle — RealSyncDynamics.AI bereitet die technischen Belege auf, ersetzt aber die juristische Prüfung nicht. Für jede konkrete Pflichteinordnung sollte ein Fachanwalt oder zertifizierter DSB konsultiert werden.

Weiterlesen

Live ausprobieren

Beispiel-Workspace mit Seed-Daten oder Compliance-Check für die eigene Domain.