Wie funktioniert der Compliance Service?

1. Was ist der Compliance Hub?

Der BreakPilot Compliance Hub ist ein System, das Organisationen dabei unterstuetzt, gesetzliche Vorschriften einzuhalten. Er beantwortet die zentrale Frage:

“Duerfen wir das, was wir vorhaben, ueberhaupt so machen -- und wenn ja, welche Auflagen muessen wir dafuer erfuellen?”

Konkret geht es um EU- und deutsche Gesetze, die fuer den Umgang mit Daten und kuenstlicher Intelligenz relevant sind: die DSGVO, den AI Act, die NIS2-Richtlinie und viele weitere Regelwerke. Das System hat vier Hauptaufgaben:

1. Wissen bereitstellen: Hunderte Rechtstexte sind eingelesen und durchsuchbar -- nicht nur per Stichwort, sondern nach Bedeutung (semantische Suche).
2. Bewerten: Wenn ein Nutzer einen geplanten KI-Anwendungsfall beschreibt, bewertet das System automatisch, ob er zulaessig ist, welches Risiko besteht und welche Massnahmen noetig sind.
3. Dokumentieren: Das System erzeugt die Dokumente, die Aufsichtsbehoerden verlangen: Datenschutz-Folgenabschaetzungen (DSFA), technisch-organisatorische Massnahmen (TOM), Verarbeitungsverzeichnisse (VVT) und mehr.
4. Nachweisen: Jede Bewertung, jede Entscheidung und jeder Zugriff wird revisionssicher protokolliert -- als Nachweis gegenueber Pruefer und Behoerden.

2. Architektur im Ueberblick

Das System besteht aus mehreren Bausteinen, die jeweils eine klar abgegrenzte Aufgabe haben. Man kann es sich wie ein Buero vorstellen:

Wie die Bausteine zusammenspielen

Benutzer (Browser)
     |
     v
┌─────────────────────────────┐
│  API-Gateway (Port 8080)    │  ← Authentifizierung, Rate-Limiting, Tenant-Isolation
│  "Wer bist du? Darfst du?"  │
└──────────┬──────────────────┘
           |
     ┌─────┼──────────────────────────────┐
     v     v                              v
┌─────────────┐  ┌──────────────┐  ┌──────────────┐
│  Compliance  │  │  RAG Service │  │  Security    │
│  Engine      │  │  (Bibliothek)│  │  Scanner     │
│  (Bewertung) │  │              │  │              │
└──────┬───┬──┘  └──────┬───────┘  └──────────────┘
       |   |            |
       |   |     ┌──────┴───────┐
       |   |     │   Qdrant     │  ← Vektordatenbank mit allen Rechtstexten
       |   |     │ (Suchindex)  │
       |   |     └──────────────┘
       |   |
       |   └──────────────────────┐
       v                          v
┌──────────────┐          ┌──────────────┐
│  PostgreSQL  │          │  Eskalation  │
│  (Speicher)  │          │  (E0-E3)     │
└──────────────┘          └──────────────┘

3. Der Katalogmanager: Die Wissensbasis

Das Herzstueck des Systems ist seine Wissensbasis -- eine Sammlung aller relevanten Rechtstexte, die das System kennt und durchsuchen kann. Wir nennen das den Legal Corpus (wörtlich: “Rechtlicher Koerper”).

3.1 Welche Dokumente sind enthalten?

Der Legal Corpus ist in zwei Hauptbereiche gegliedert: EU-Recht und deutsches Recht.

EU-Verordnungen und -Richtlinien

Deutsches Recht

Standards und Normen

3.2 Wie werden Rechtstexte gespeichert?

Jeder Rechtstext durchlaeuft eine Verarbeitungspipeline, bevor er im System durchsuchbar ist. Der Vorgang laesst sich mit dem Erstellen eines Bibliothekskatalogs vergleichen:

1. Erfassung (Ingestion): Der Rechtstext wird als Dokument (PDF, Markdown oder Klartext) in das System geladen. Fuer jede Verordnung gibt es eine metadata.json-Datei.
2. Zerkleinerung (Chunking): Lange Gesetzestexte werden in kleinere Abschnitte von ca. 512 Zeichen zerlegt. Dabei ueberlappen sich die Abschnitte um 50 Zeichen.
3. Vektorisierung (Embedding): Jeder Textabschnitt wird vom Embedding-Modell BGE-M3 in einen Vektor umgewandelt -- eine Liste von 1.024 Zahlen.
4. Indexierung: Die Vektoren werden in der Vektordatenbank Qdrant gespeichert. Zusammen mit jedem Vektor werden Metadaten hinterlegt.

Rechtstext (z.B. DSGVO Art. 32)
     |
     v
┌────────────────────────┐
│  1. Einlesen           │  ← PDF/Markdown/Klartext + metadata.json
└──────────┬─────────────┘
           v
┌────────────────────────┐
│  2. Chunking           │  ← Text in 512-Zeichen-Abschnitte zerlegen
└──────────┬─────────────┘
           v
┌────────────────────────┐
│  3. Embedding          │  ← BGE-M3 wandelt Text in 1024 Zahlen um
└──────────┬─────────────┘
           v
┌────────────────────────┐
│  4. Qdrant speichern   │  ← Vektor + Metadaten werden indexiert
└────────────────────────┘

3.3 Wie funktioniert die semantische Suche?

Klassische Suchmaschinen suchen nach Woertern. Unsere semantische Suche funktioniert anders: Sie sucht nach Bedeutung.

Beispiel: Wenn Sie fragen “Wann muss ich den Nutzer um Erlaubnis bitten?”, findet das System Art. 7 DSGVO (Bedingungen fuer die Einwilligung), obwohl Ihre Frage das Wort “Einwilligung” gar nicht enthaelt.

3.4 Der KI-Rechtsassistent (Legal Q&A)

Ueber die reine Suche hinaus kann das System auch Fragen beantworten:

1. Suche: Das System findet die 5 relevantesten Gesetzesabschnitte zur Frage.
2. Kontext-Erstellung: Diese Abschnitte werden mit der Frage an das Sprachmodell (Qwen 2.5 32B) uebergeben.
3. Antwort-Generierung: Das Modell formuliert eine verstaendliche Antwort auf Deutsch und zitiert die verwendeten Rechtsquellen.
4. Quellenangabe: Jede Antwort enthaelt exakte Zitate mit Artikelangaben.

4. Die Compliance Engine: Wie Bewertungen funktionieren

Das Kernmodul des Compliance Hub ist die UCCA Engine (Unified Compliance Control Assessment). Sie bewertet, ob ein geplanter KI-Anwendungsfall zulaessig ist.

4.1 Der Fragebogen (Use Case Intake)

4.2 Die Pruefregeln (Policy Engine)

Die Antworten des Fragebogens werden gegen ein Regelwerk von ueber 45 Regelngeprueft. Jede Regel ist in einer YAML-Datei definiert. Die Regeln sind in 10 Kategorien organisiert:

4.3 Das Ergebnis: Die Compliance-Bewertung

Anwendungsfall: "Chatbot fuer Kundenservice mit Zugriff auf Bestellhistorie"

Machbarkeit:       CONDITIONAL (bedingt zulaessig)
Risikoscore:       35/100 (LOW)

Ausgeloeste Regeln:
  R-001  WARN  Personenbezogene Daten werden verarbeitet          (Art. 6 DSGVO)
  R-010  INFO  Verarbeitungszweck: Kundenservice                  (Art. 5 DSGVO)
  R-060  WARN  Nutzer muessen ueber KI-Nutzung informiert werden  (AI Act Art. 52)

Erforderliche Controls:
  C_EXPLICIT_CONSENT   Einwilligung fuer Chatbot-Nutzung einholen
  C_TRANSPARENCY       Hinweis "Sie sprechen mit einer KI"
  C_DATA_MINIMIZATION  Nur notwendige Bestelldaten abrufen

DSFA erforderlich:     Nein (Risikoscore unter 40)
Eskalation:            E0 (keine manuelle Pruefung noetig)

5. Das Eskalations-System: Wann Menschen entscheiden

Nicht jede Bewertung ist eindeutig. Fuer heikle Faelle gibt es ein abgestuftes Eskalations-System, das sicherstellt, dass die richtigen Menschen die endgueltige Entscheidung treffen.

6. Controls, Nachweise und Risiken

6.1 Was sind Controls?

Ein Control ist eine konkrete Massnahme, die eine Organisation umsetzt, um ein Compliance-Risiko zu beherrschen. Es gibt drei Arten:

• Technische Controls: Verschluesselung, Zugangskontrollen, Firewalls, Pseudonymisierung
• Organisatorische Controls: Schulungen, Richtlinien, Verantwortlichkeiten, Audits
• Physische Controls: Zutrittskontrolle zu Serverraeumen, Schliesssysteme

Der Compliance Hub verwaltet einen Katalog von ueber 100 vordefinierten Controls, die in 9 Domaenen organisiert sind:

6.2 Wie Controls mit Gesetzen verknuepft sind

Control: AC-01 (Zugriffskontrolle)
├── DSGVO Art. 32    → "Sicherheit der Verarbeitung"
├── NIS2 Art. 21     → "Massnahmen zum Management von Cyberrisiken"
└── ISO 27001 A.9    → "Zugangskontrolle"

Control: DP-03 (Datenverschluesselung)
├── DSGVO Art. 32    → "Verschluesselung personenbezogener Daten"
└── NIS2 Art. 21     → "Einsatz von Kryptographie"

6.3 Evidence (Nachweise)

Nachweis-Typen, die das System verwaltet:

• Zertifikate: ISO 27001-Zertifikat, SOC2-Report
• Richtlinien: Interne Datenschutzrichtlinie, Passwort-Policy
• Audit-Berichte: Ergebnisse interner oder externer Pruefungen
• Screenshots / Konfigurationen: Nachweis technischer Umsetzung

Jeder Nachweis hat ein Ablaufdatum. Das System warnt automatisch, wenn Nachweise bald ablaufen.

6.4 Risikobewertung

Risiken werden in einer 5x5-Risikomatrix dargestellt. Die beiden Achsen sind Eintrittswahrscheinlichkeit und Auswirkung. Aus der Kombination ergibt sich die Risikostufe: Minimal, Low, Medium, High oder Critical.

7. Pflichten-Ableitung: Welche Gesetze gelten fuer mich?

Nicht jedes Gesetz gilt fuer jede Organisation. Das Obligations Frameworkermittelt automatisch, welche konkreten Pflichten sich aus der Situation einer Organisation ergeben.

Beispiel: NIS2-Anwendbarkeit

Ist Ihr Unternehmen in einem der NIS2-Sektoren taetig?
(Energie, Transport, Banken, Gesundheit, Wasser, Digitale Infrastruktur, ...)
  │
  ├── Nein → NIS2 gilt NICHT fuer Sie
  │
  └── Ja → Wie gross ist Ihr Unternehmen?
            │
            ├── >= 250 Mitarbeiter ODER >= 50 Mio. EUR Umsatz
            │    → ESSENTIAL ENTITY (wesentliche Einrichtung)
            │    → Volle NIS2-Pflichten, strenge Aufsicht
            │    → Bussgelder bis 10 Mio. EUR oder 2% Jahresumsatz
            │
            ├── >= 50 Mitarbeiter ODER >= 10 Mio. EUR Umsatz
            │    → IMPORTANT ENTITY (wichtige Einrichtung)
            │    → NIS2-Pflichten, reaktive Aufsicht
            │    → Bussgelder bis 7 Mio. EUR oder 1,4% Jahresumsatz
            │
            └── Kleiner → NIS2 gilt grundsaetzlich NICHT

8. DSGVO-Compliance-Module im Detail

Fuer die Einhaltung der DSGVO bietet der Compliance Hub spezialisierte Module:

8.1 Consent Management (Einwilligungsverwaltung)

Verwaltet die Einwilligung von Nutzern gemaess Art. 6/7 DSGVO. Jede Einwilligung wird protokolliert: wer hat wann, auf welchem Kanal, fuer welchen Zweck zugestimmt (oder abgelehnt)?

Zwecke: Essential (funktionsnotwendig), Functional, Analytics, Marketing, Personalization, Third-Party.

8.2 DSR Management (Betroffenenrechte)

Verwaltet Antraege betroffener Personen nach Art. 15-21 DSGVO: Auskunft, Berichtigung, Loeschung, Datenportabilitaet, Einschraenkung und Widerspruch. Das System ueberwacht die 30-Tage-Frist (Art. 12) und eskaliert automatisch bei drohenden Fristverstossen.

8.3 VVT (Verzeichnis von Verarbeitungstaetigkeiten)

Dokumentiert alle Datenverarbeitungen gemaess Art. 30 DSGVO: Welche Daten werden fuer welchen Zweck, auf welcher Rechtsgrundlage, wie lange und von wem verarbeitet?

8.4 DSFA (Datenschutz-Folgenabschaetzung)

Wenn eine Datenverarbeitung voraussichtlich ein hohes Risiko fuer die Rechte natuerlicher Personen mit sich bringt, ist eine DSFA nach Art. 35 DSGVO Pflicht.

8.5 TOM (Technisch-Organisatorische Massnahmen)

Dokumentiert die Schutzmassnahmen nach Art. 32 DSGVO. Fuer jede Massnahme wird erfasst: Kategorie (z.B. Verschluesselung, Zugriffskontrolle), Status, Verantwortlicher und Nachweise.

8.6 Loeschkonzept

Verwaltet Aufbewahrungsfristen und automatische Loeschung gemaess Art. 5/17 DSGVO. Fuer jede Datenkategorie wird definiert: wie lange darf sie gespeichert werden, wann muss sie geloescht werden und wie (z.B. Ueberschreiben, Schluesselloeschung).

9. Multi-Tenancy und Zugriffskontrolle

Das System ist mandantenfaehig (Multi-Tenant): Mehrere Organisationen koennen es gleichzeitig nutzen, ohne dass sie gegenseitig auf ihre Daten zugreifen koennen.

9.1 Rollenbasierte Zugriffskontrolle (RBAC)

9.2 PII-Erkennung und -Schutz

Bevor Texte an ein Sprachmodell gesendet werden, durchlaufen sie eine automatische PII-Erkennung. Das System erkennt ueber 20 Arten personenbezogener Daten (E-Mail-Adressen, Telefonnummern, Namen, IP-Adressen, etc.). Je nach Konfiguration werden erkannte PII-Daten geschwuerzt, maskiertoder nur im Audit-Log markiert.

10. Wie das System KI nutzt (und wie nicht)

LLM-Provider und Fallback

1. Primaer: Ollama (lokal) -- Qwen 2.5 32B bzw. Mistral, laeuft direkt auf dem Server. Keine Daten verlassen das lokale Netzwerk.
2. Fallback: Anthropic Claude -- Wird nur aktiviert, wenn das lokale Modell nicht verfuegbar ist.

11. Audit-Trail: Alles wird protokolliert

Saemtliche Aktionen im System werden revisionssicher protokolliert:

• Jede Compliance-Bewertung mit allen Ein- und Ausgaben
• Jede Eskalationsentscheidung mit Begruendung
• Jeder LLM-Aufruf (wer hat was wann gefragt, welches Modell wurde verwendet)
• Jede Aenderung an Controls, Evidence und Policies
• Jeder Login und Daten-Export

12. Security Scanner: Technische Sicherheitspruefung

• Container-Scanning (Trivy): Prueft Docker-Images auf bekannte Schwachstellen (CVEs)
• Statische Code-Analyse (Semgrep): Sucht im Quellcode nach Sicherheitsluecken
• Secret Detection (Gitleaks): Findet versehentlich eingecheckte Passwoerter, API-Keys und Tokens
• SBOM-Generierung: Erstellt eine vollstaendige Liste aller verwendeten Bibliotheken und deren Lizenzen

13. Zusammenfassung: Der komplette Datenfluss

SCHRITT 1: FAKTEN SAMMELN
Nutzer fuellt Fragebogen aus: Welche Daten? Welcher Zweck? Welche Branche? Wo gehostet?

SCHRITT 2: ANWENDBARKEIT PRUEFEN
Obligations Framework: DSGVO? AI Act? NIS2?

SCHRITT 3: REGELN PRUEFEN (45+ Regeln)
  R-001 (WARN): Personenbezogene Daten +10 Risiko
  R-060 (WARN): KI-Transparenz fehlt   +15 Risiko
  → Gesamt-Risikoscore: 35/100 (LOW), Machbarkeit: CONDITIONAL

SCHRITT 4: CONTROLS ZUORDNEN
  C_EXPLICIT_CONSENT, C_TRANSPARENCY, C_DATA_MINIMIZATION

SCHRITT 5: ESKALATION (bei Bedarf)
  Score 35 → Stufe E1 → Teamleiter, SLA 24h

SCHRITT 6: ERKLAERUNG GENERIEREN
  LLM + RAG: Gesetzesartikel suchen, Erklaerungstext generieren

SCHRITT 7: DOKUMENTATION
  DSFA, TOM, VVT, Compliance-Report (PDF/ZIP/JSON)

SCHRITT 8: MONITORING
  Controls regelmaessig pruefen, Nachweise auf Ablauf ueberwachen