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 einemetadata.json-Datei, die beschreibt, um welches Gesetz es sich handelt, wie viele Artikel es hat und welche Schluesselbegriffe relevant sind.
2. Zerkleinerung (Chunking): Lange Gesetzestexte werden in kleinere Abschnitte von ca. 512 Zeichen zerlegt. Dabei ueberlappen sich die Abschnitte um 50 Zeichen, damit kein Kontext verloren geht. Stellen Sie sich vor, Sie zerschneiden einen langen Brief in Absaetze, wobei jeder Absatz die letzten zwei Zeilen des vorherigen enthaelt.
3. Vektorisierung (Embedding): Jeder Textabschnitt wird vom Embedding-Modell BGE-M3 in einen Vektor umgewandelt -- eine Liste von 1.024 Zahlen, die die Bedeutung des Textes repraesentieren. Texte mit aehnlicher Bedeutung haben aehnliche Vektoren, unabhaengig von der Wortwahl.
4. Indexierung: Die Vektoren werden in der Vektordatenbank Qdrant gespeichert. Zusammen mit jedem Vektor werden Metadaten hinterlegt: zu welchem Gesetz der Text gehoert, welcher Artikel es ist und welcher Paragraph.

Rechtstext (z.B. DSGVO Art. 32)
     |
     v
┌────────────────────────┐
│  1. Einlesen           │  ← PDF/Markdown/Klartext + metadata.json
│  Metadaten zuordnen    │
└──────────┬─────────────┘
           |
           v
┌────────────────────────┐
│  2. Chunking           │  ← Text in 512-Zeichen-Abschnitte zerlegen
│  Ueberlappung: 50 Zch. │     (mit 50 Zeichen Ueberlappung)
└──────────┬─────────────┘
           |
           v
┌────────────────────────┐
│  3. Embedding          │  ← BGE-M3 wandelt Text in 1024 Zahlen um
│  Text → Vektor         │     (Bedeutungs-Repraesentation)
└──────────┬─────────────┘
           |
           v
┌────────────────────────┐
│  4. Qdrant speichern   │  ← Vektor + Metadaten werden indexiert
│  Sofort durchsuchbar   │     (~2.274 Chunks insgesamt)
└────────────────────────┘

3.3 Wie funktioniert die semantische Suche?

Klassische Suchmaschinen suchen nach Woertern. Wenn Sie “Einwilligung” eingeben, finden sie nur Texte, die genau dieses Wort enthalten. 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. Das funktioniert, weil die Bedeutungsvektoren von “um Erlaubnis bitten” und “Einwilligung” sehr aehnlich sind.

Der Suchvorgang im Detail:

1. Ihre Suchanfrage wird vom gleichen Modell (BGE-M3) in einen Vektor umgewandelt.
2. Qdrant vergleicht diesen Vektor mit allen gespeicherten Vektoren (Kosinus-Aehnlichkeit).
3. Die aehnlichsten Textabschnitte werden zurueckgegeben, sortiert nach Relevanz (Score 0-1).
4. Optional kann nach bestimmten Gesetzen gefiltert werden (nur DSGVO, nur AI Act, etc.).

3.4 Der KI-Rechtsassistent (Legal Q&A)

Ueber die reine Suche hinaus kann das System auch Fragen beantworten. Dabei wird die semantische Suche mit einem Sprachmodell kombiniert:

1. Suche: Das System findet die 5 relevantesten Gesetzesabschnitte zur Frage.
2. Kontext-Erstellung: Diese Abschnitte werden zusammen 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, damit die Aussagen nachpruefbar sind.

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)

Alles beginnt mit einem strukturierten Fragebogen. Der Nutzer beschreibt seinen geplanten Anwendungsfall, indem er Fragen zu folgenden Bereichen beantwortet:

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 und hat folgende Struktur:

• Bedingung: Wann greift die Regel? (z.B. “Art. 9-Daten werden verarbeitet”)
• Schweregrad: INFO (Hinweis), WARN (Risiko, aber loesbar) oder BLOCK (grundsaetzlich nicht zulaessig)
• Auswirkung: Was passiert, wenn die Regel greift? (Risikoerhoehung, zusaetzliche Controls, Eskalation)
• Gesetzesreferenz: Auf welchen Artikel bezieht sich die Regel?

Die Regeln sind in 10 Kategorien organisiert:

4.3 Das Ergebnis: Die Compliance-Bewertung

Nach der Pruefung aller Regeln erhaelt der Nutzer eine strukturierte Bewertung:

Anwendungsfall: "Chatbot fuer Kundenservice mit Zugriff auf Bestellhistorie"

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

Ausgeloeste Regeln:
  R-001  WARN  Personenbezogene Daten werden verarbeitet          (Art. 6 DSGVO)
  R-010  INFO  Verarbeitungszweck: Kundenservice                  (Art. 5 DSGVO)
  R-020  INFO  Assistenzsystem (nicht vollautomatisch)             (Art. 22 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.

Zuweisung: Die Zuweisung erfolgt automatisch an den Pruefer mit der geringsten aktuellen Arbeitslast (Workload-basiertes Round-Robin). Jeder Pruefer hat eine konfigurierbare Obergrenze fuer gleichzeitige Reviews (z.B. 10 fuer Teamleiter, 5 fuer DSB, 3 fuer Rechtsabteilung).

Entscheidung: Der Pruefer kann den Anwendungsfall freigeben,ablehnen, mit Auflagen freigeben oder weiter eskalieren. Jede Entscheidung wird mit Begruendung im Audit-Trail gespeichert.

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

Jeder Control ist mit einem oder mehreren Gesetzesartikeln verknuepft. Diese Mappings machen sichtbar, warum eine Massnahme erforderlich ist:

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

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

6.3 Evidence (Nachweise)

Ein Control allein genuegt nicht -- man muss auch nachweisen, dass er umgesetzt wurde. Das System verwaltet verschiedene Nachweis-Typen:

• 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 (z.B. ein ISO-Zertifikat, das in 3 Monaten erneuert werden muss).

6.4 Risikobewertung

Risiken werden in einer 5x5-Risikomatrix dargestellt. Die beiden Achsen sind:

• Eintrittswahrscheinlichkeit: Wie wahrscheinlich ist es, dass das Risiko eintritt?
• Auswirkung: Wie schwerwiegend waeren die Folgen?

Aus der Kombination ergibt sich die Risikostufe: Minimal, Low,Medium, High oder Critical. Fuer jedes identifizierte Risiko wird dokumentiert, welche Controls es abmildern und wer dafuer verantwortlich ist.

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. Dafuer werden “Fakten” ueber die Organisation gesammelt und gegen die Anwendbarkeitsbedingungen der einzelnen Gesetze geprueft.

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
                 (Ausnahmen fuer bestimmte Sektoren moeglich)

Aehnliche Entscheidungsbaeume existieren fuer DSGVO (Verarbeitung personenbezogener Daten?), AI Act (KI-System im Einsatz? Welche Risikokategorie?) und alle anderen Regelwerke. Das System leitet daraus konkrete Pflichten ab -- z.B. “Meldepflicht bei Sicherheitsvorfaellen innerhalb von 72 Stunden” oder “Ernennung eines Datenschutzbeauftragten”.

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)? Einwilligungen koennen jederzeit widerrufen werden, der Widerruf wird ebenfalls dokumentiert.

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, wenn Fristen drohen zu verstreichen.

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? Jede Verarbeitungstaetigkeit wird mit ihren Datenkategorien, Empfaengern und Loeschfristen erfasst.

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. Das System unterstuetzt den Prozess: Risiken identifizieren, bewerten, Gegenmassnahmen definieren und das Ergebnis dokumentieren.

8.5 TOM (Technisch-Organisatorische Massnahmen)

Dokumentiert die Schutzmassnahmen nach Art. 32 DSGVO. Fuer jede Massnahme wird erfasst: Kategorie (z.B. Verschluesselung, Zugriffskontrolle), Status (implementiert / in Bearbeitung / geplant), 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 bei verschluesselten Daten).

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. Jede Anfrage enthaelt eine Tenant-ID, und die Datenbank-Abfragen filtern automatisch nach dieser ID.

9.1 Rollenbasierte Zugriffskontrolle (RBAC)

Innerhalb eines Mandanten gibt es verschiedene Rollen mit unterschiedlichen Berechtigungen:

9.2 PII-Erkennung und -Schutz

Bevor Texte an ein Sprachmodell gesendet werden, durchlaufen sie eine automatische PII-Erkennung (Personally Identifiable Information). Das System erkennt ueber 20 Arten personenbezogener Daten:

• E-Mail-Adressen, Telefonnummern, Postanschriften
• Sozialversicherungsnummern, Kreditkartennummern
• Personennamen, IP-Adressen
• und weitere...

Je nach Konfiguration werden erkannte PII-Daten geschwuerzt (durch Platzhalter ersetzt), maskiert (nur Anfang/Ende sichtbar) oder nur im Audit-Log markiert.

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

Der Compliance Hub setzt kuenstliche Intelligenz gezielt und kontrolliert ein. Es gibt eine klare Trennung zwischen dem, was die KI tut, und dem, was sie nicht tun darf:

LLM-Provider und Fallback

Das System unterstuetzt mehrere KI-Anbieter mit automatischem 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.

Jeder LLM-Aufruf wird im Audit-Trail protokolliert: Prompt-Hash (SHA-256), verwendetes Modell, Antwortzeit und ob PII erkannt wurde.

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

Der Audit-Trail kann als PDF, CSV oder JSON exportiert werden und dient als Nachweis gegenueber Aufsichtsbehoerden, Wirtschaftspruefern und internen Revisoren.

12. Security Scanner: Technische Sicherheitspruefung

Ergaenzend zur rechtlichen Compliance prueft der Security Scanner die technische Sicherheit:

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

Gefundene Schwachstellen werden nach Schweregrad (Critical, High, Medium, Low) klassifiziert und koennen direkt im System nachverfolgt und behoben werden.

13. Zusammenfassung: Der komplette Datenfluss

Hier ist der gesamte Prozess von Anfang bis Ende:

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

SCHRITT 2: ANWENDBARKEIT PRUEFEN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Obligations Framework ermittelt:
  → DSGVO betroffen? → Ja (personenbezogene Daten)
  → AI Act betroffen? → Ja (KI-System)
  → NIS2 betroffen? → Nein (< 50 Mitarbeiter, kein KRITIS-Sektor)

SCHRITT 3: REGELN PRUEFEN
━━━━━━━━━━━━━━━━━━━━━━━━
Policy Engine wertet 45+ Regeln aus:
  → R-001 (WARN): Personenbezogene Daten           +10 Risiko
  → R-020 (INFO): Assistenzsystem                   +0 Risiko
  → R-060 (WARN): KI-Transparenz fehlt             +15 Risiko
  → ...
  → Gesamt-Risikoscore: 35/100 (LOW)
  → Machbarkeit: CONDITIONAL

SCHRITT 4: CONTROLS ZUORDNEN
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Jede ausgeloeste Regel triggert Controls:
  → C_EXPLICIT_CONSENT: Einwilligung einholen
  → C_TRANSPARENCY: KI-Nutzung offenlegen
  → C_DATA_MINIMIZATION: Datenminimierung

SCHRITT 5: ESKALATION (bei Bedarf)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Score 35 → Stufe E1 → Teamleiter wird benachrichtigt
  → SLA: 24 Stunden fuer Pruefung
  → Entscheidung: Freigabe mit Auflagen

SCHRITT 6: ERKLAERUNG GENERIEREN
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LLM + RAG erstellen verstaendliche Erklaerung:
  → Suche relevante Gesetzesartikel (Qdrant)
  → Generiere Erklaerungstext (Qwen 2.5)
  → Fuege Zitate und Quellen hinzu

SCHRITT 7: DOKUMENTATION
━━━━━━━━━━━━━━━━━━━━━━━
System erzeugt erforderliche Dokumente:
  → DSFA (falls empfohlen)
  → TOM-Dokumentation
  → VVT-Eintrag
  → Compliance-Report (PDF/ZIP/JSON)

SCHRITT 8: MONITORING
━━━━━━━━━━━━━━━━━━━━
Laufende Ueberwachung:
  → Controls werden regelmaessig geprueft
  → Nachweise werden auf Ablauf ueberwacht
  → Gesetzesaenderungen fliessen in den Corpus ein