
# KI mit synthetischen Daten für die Automatisierung von Sicherheitsfragebögen

*Im Zeitalter generativer KI ist das größte Hindernis für die Skalierung der Fragebogen‑Automatisierung **Daten** – nicht Rechenleistung. Echte Sicherheitsrichtlinien sind geschützt, reich formatiert und selten für maschinelles Lernen gelabelt. Synthetische Daten bieten eine datenschutz‑bewahrende Abkürzung, die es Organisationen ermöglicht, LLMs zu trainieren, zu validieren und kontinuierlich zu verbessern, damit sie auf Abruf genaue, prüfbare Antworten entwerfen können.*

---

## Warum synthetische Daten das fehlende Bindeglied sind

| Herausforderung | Traditioneller Ansatz | Synthetische Alternative |
|-----------------|-----------------------|--------------------------|
| **Datenknappheit** – wenige öffentliche Sicherheits‑Fragebogendatensätze | Manuelle Sammlung, umfangreiche Redaktion, juristische Prüfung | Programmatische Erzeugung von Millionen realistischer Frage‑Antwort‑Paare |
| **Datenschutz‑Risiko** – echter Richtlinientext enthält Geheimnisse | Komplexe Anonymisations‑Pipelines | Keine realen Daten preisgegeben; synthetischer Text ahmt Stil & Struktur nach |
| **Domänen‑Drift** – Vorschriften ändern sich schneller als Modell‑Updates | Periodisches Nach‑Training auf neuem manuellem Datenbestand | Kontinuierliche synthetische Aktualisierung, ausgerichtet an neue Standards |
| **Evaluations‑Bias** – Test‑Sets spiegeln das Trainings‑Bias wider | Überoptimistische Metriken | Kontrollierte synthetische Testsuiten, die Randfälle abdecken |

Indem der Bedarf ersatzlos entfällt, Roh‑Richtlinien in die Trainings‑Schleife einzuspeisen, respektieren synthetische Daten nicht nur die Vertraulichkeit, sondern geben Compliance‑Teams die volle Kontrolle über *was* und *wie* das Modell sich verhalten soll.

---

## Kernkonzepte hinter synthetischen Fragebogendaten

### 1. Prompt‑basierte Generierung

LLMs können angewiesen werden, **als Richtlinien‑Autor** zu agieren und Entwurfsantworten für eine gegebene Fragen‑Vorlage zu erzeugen. Beispiel‑Prompt:

```
You are a compliance officer for a SaaS platform. Write a concise answer (≤150 words) to the following ISO 27001 control:
"Describe how encryption keys are protected at rest and in transit."
```

Wird dieser Prompt über einen Katalog von Kontrollen ausgeführt, entsteht ein **roher synthetischer Korpus**.

### 2. Kontrolliertes Vokabular & Ontologie‑Abgleich

Um den erzeugten Text konsistent zu halten, injizieren wir eine **Sicherheits‑Ontologie** (z. B. [NIST CSF](https://www.nist.gov/cyberframework), [ISO 27001](https://www.iso.org/standard/27001), [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)) die definiert:

- **Entitätstypen**: `Encryption`, `AccessControl`, `IncidentResponse`  
- **Attribute**: `algorithm`, `keyRotationPeriod`, `auditLogRetention`  
- **Beziehungen**: `protects`, `monitoredBy`

Die Ontologie leitet das LLM mittels **strukturierter Prompts** und **Post‑Processing** an, freie Beschreibungen durch ontologie‑gebundene Tokens zu ersetzen, was eine nachträgliche Validierung ermöglicht.

### 3. Rausch‑Injektion & Edge‑Case‑Modellierung

Compliance‑Antworten sind selten perfekt. Synthetische Pipelines fügen bewusst hinzu:

- **Kleinfügige faktische Ungenauigkeiten** (z. B. ein etwas älteres Schlüssel‑Rotationsintervall), um das Modell in Fehlererkennung zu schulen.  
- **Mehrdeutige Formulierungen**, um die Fähigkeit des Modells zu verbessern, Rückfragen zu stellen.  
- **Sprachliche Varianten** (britisches vs. amerikanisches Englisch, formell vs. locker) für mehrsprachige Einsatzfähigkeit.

---

## End‑to‑End‑Pipeline für synthetische Daten

Unten ist ein **Mermaid**‑Flussdiagramm, das den gesamten Prozess von der Kontrollen‑Katalog‑Ingestion bis zur Modell‑Bereitstellung in Procurize abbildet.

```mermaid
flowchart TD
    A["Control Catalog (ISO, SOC, NIST)"] --> B["Prompt Template Library"]
    B --> C["LLM Synthetic Generator"]
    C --> D["Raw Synthetic Answers"]
    D --> E["Ontology Mapper"]
    E --> F["Structured Synthetic Records"]
    F --> G["Noise & Edge‑Case Engine"]
    G --> H["Final Synthetic Dataset"]
    H --> I["Train / Fine‑Tune LLM"]
    I --> J["Evaluation Suite (Synthetic + Real QA)"]
    J --> K["Model Registry"]
    K --> L["Deploy to Procurize AI Engine"]
    L --> M["Live Questionnaire Automation"]
```

### Durchlauf der Pipeline

1. **Kontrollen‑Katalog** – Aktuelle Liste der Fragebogen‑Items aus den Standards beziehen.  
2. **Prompt‑Vorlagen‑Bibliothek** – Wiederverwendbare Prompt‑Muster pro Kontroll‑Kategorie speichern.  
3. **LLM‑synthetischer Generator** – Basis‑LLM (z. B. GPT‑4o) nutzen, um Roh‑Antwortentwürfe zu erzeugen.  
4. **Ontologie‑Mapper** – Freitext mit der Sicherheits‑Ontologie abgleichen und Schlüsselphrasen zu kanonischen Tokens konvertieren.  
5. **Rausch‑ & Edge‑Case‑Engine** – Kontrollierte Störungen hinzufügen.  
6. **Endgültiger synthetischer Datensatz** – In einem version‑kontrollierten Data‑Lake (z. B. Snowflake + Delta Lake) speichern.  
7. **Train / Fine‑Tune LLM** – Instruction‑Tuning mit LoRA oder QLoRA, um Compute‑Kosten gering zu halten.  
8. **Evaluations‑Suite** – Synthetische Testfälle mit einem kleinen, kuratierten realen QA‑Set für Robustheits‑Checks kombinieren.  
9. **Modell‑Register** – Modellversion mit Metadaten (Training‑Daten‑Hash, Compliance‑Version) registrieren.  
10. **Deploy to Procurize AI Engine** – Bereitstellung via API, die in das Fragebogen‑Dashboard integriert wird.  
11. **Live‑Automatisierung** – Teams erhalten KI‑Entwürfe, können in Echtzeit prüfen, editieren und freigeben.

---

## Technischer Deep‑Dive: Feinabstimmung mit LoRA

**Low‑Rank Adaptation (LoRA)** reduziert den Speicherbedarf drastisch, ohne die Modell‑Performance zu beeinträchtigen:

```python
import torch
from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "gpt-4o-mini"
base_model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(model_name)

lora_cfg = LoraConfig(
    r=16,                # rank
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

lora_model = get_peft_model(base_model, lora_cfg)

# Prepare synthetic dataset
train_dataset = SyntheticDataset(tokenizer, synthetic_path="s3://synthetic/qna/train.json")
train_loader = torch.utils.data.DataLoader(train_dataset, batch_size=8, shuffle=True)

optimizer = torch.optim.AdamW(lora_model.parameters(), lr=2e-4)

for epoch in range(3):
    for batch in train_loader:
        outputs = lora_model(**batch)
        loss = outputs.loss
        loss.backward()
        optimizer.step()
        optimizer.zero_grad()
    print(f"Epoch {epoch} loss: {loss.item():.4f}")
```

LoRA ermöglicht schnelle Iterationen – neue synthetische Batches können wöchentlich erzeugt und ohne komplettes Neu‑Training des Basismodells eingebunden werden.

---

## Integration mit Procurize: Vom Modell zur UI

1. **Modell‑Endpoint‑Registrierung** – Das LoRA‑feingetunte Modell in einem sicheren Inference‑Service (z. B. SageMaker, Vertex AI) speichern.  
2. **API‑Bridge** – Der Backend‑Service von Procurize ruft `POST /v1/generate-answer` mit folgendem Payload auf:

```json
{
  "question_id": "SOC2-CC8.1",
  "context": "latest policy version hash",
  "metadata": {
    "requester": "security-team",
    "priority": "high"
  }
}
```

3. **Echtzeit‑Review‑Layer** – Der Entwurf erscheint in der Fragebogen‑UI als **editierbarer Rich‑Text** mit **hervorgehobenen Ontologie‑Tokens** und einem **Vertrauens‑Score** (0‑100).  
4. **Audit‑Trail** – Jede KI‑generierte Antwort wird mit ihrer synthetischen Daten‑Provenienz, Modell‑Version und Reviewer‑Aktionen gespeichert, um regulatorische Nachweis‑Anforderungen zu erfüllen.

---

## Nutzen quantifiziert

| Kennzahl | Vor synthetischer KI | Nach synthetischer KI |
|----------|----------------------|-----------------------|
| **Durchschnittliche Antwortzeit** | 3,2 Tage | 5,4 Stunden |
| **Menschlicher Bearbeitungsaufwand** | 45 % der Antwortlänge | 12 % der Antwortlänge |
| **Compliance‑Audit‑Findings** | 8 kleinere Inkonsistenzen pro Audit | 1 kleinere Inkonsistenz pro Audit |
| **Zeit für neue Standards** | 6 Wochen (manuelle Zuordnung) | 2 Wochen (synthetische Aktualisierung) |

Ein Praxisbeispiel bei **Acme Cloud** zeigte eine **71 % Reduktion der Fragebogen‑Durchlaufzeit**, nachdem ein synthetisch‑daten‑trainiertes LLM in Procurize integriert wurde.

---

## Bewährte Praktiken und zu vermeidende Fallstricke

1. **Ontologie‑Mapping validieren** – Automatisierte Plausibilitäts‑Checks, dass jede generierte Antwort die erforderlichen Tokens (z. B. `encryptionAlgorithm`, `keyRotationPeriod`) enthält.  
2. **Human‑in‑the‑Loop (HITL)** – Für besonders risikoreiche Kontrollen (z. B. Daten‑Pannen‑Meldungen) stets einen Reviewer‑Schritt erzwingen.  
3. **Versionierung synthetischer Daten** – Generierungsskripte, Seed‑Prompts und Zufalls‑Seeds versionieren; das ermöglicht Reproduzierbarkeit und Audit‑Nachvollziehbarkeit der Trainingsdaten.  
4. **Drift überwachen** – Verteilung der Vertrauens‑Scores über die Zeit tracken; plötzliche Verschiebungen können auf veraltete Prompts oder regulatorische Änderungen hinweisen.  
5. **Over‑Fitting vermeiden** – Periodisch einen kleinen Satz realer, anonymisierter Antworten einmischen, um das Modell zu erden.

---

## Zukünftige Richtungen

- **Cross‑Domain‑Transfer:** Synthetische Datensätze aus SaaS, FinTech und Healthcare bündeln, um ein *universelles Compliance‑LLM* zu bauen, das für Nischen‑Domänen mit wenigen hundert Beispielen feinjustiert werden kann.  
- **Privacy‑Preserving Federated Tuning:** Synthetische Daten mit verschlüsselten, föderierten Updates mehrerer Mandanten kombinieren, um ein geteiltes Modell ohne Exposition von Roh‑Richtlinien zu ermöglichen.  
- **Erklärbare Evidenz‑Ketten:** Die synthetische Generation mit einer kausalen Graph‑Engine koppeln, die Antwort‑Fragmente automatisch mit den Quell‑Richtlinien‑Abschnitten verknüpft und Auditoren eine maschinell‑verifizierte Evidenz‑Map liefert.

---

## Fazit

Synthetische Daten sind mehr als ein cleverer Hack – sie sind ein **strategischer Enabler**, der KI‑gestützte Fragebogen‑Automatisierung in die compliance‑first‑Welt bringt. Durch die Erzeugung realistischer, ontologie‑abgeglichener Antwort‑Korpora können Unternehmen leistungsstarke LLMs trainieren, ohne vertrauliche Richtlinien zu gefährden, Reaktionszeiten zu beschleunigen und zugleich einen rigorosen Audit‑Trail zu wahren – und das alles, während sie stets einen Schritt voraus bleiben gegenüber ständig wandelnden regulatorischen Vorgaben. In Kombination mit einer zweckgebauten Plattform wie Procurize verwandelt synthetische‑daten‑basierte KI einen traditionell manuellen Engpass in einen kontinuierlichen, selbstoptimierenden Compliance‑Motor.

---

## <span class='highlight-content'>Siehe</span> auch

- [NIST Special Publication 800‑53 Revision 5 – Security and Privacy Controls for Federal Information Systems](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)  
- OpenAI Cookbook: Fine‑tuning LLMs with LoRA  
- [ISO/IEC 27001:2022 – Information Security Management Systems Requirements](https://www.iso.org/standard/82875.html)  
- Google Cloud AI‑Ready Synthetic Data Documentation