
# Datenschutz‑bewusste Prompt‑Anpassung für die automatisierte Sicherheitsfragebogen‑Erstellung in Multi‑Tenant‑Umgebungen

## Einführung

Sicherheitsfragebögen, Lieferantenbewertungen und Compliance‑Audits sind für SaaS‑Anbieter eine dauerhafte Quelle von Reibungen. Der manuelle Aufwand, der nötig ist, um Nachweise zu sammeln, Antworten zu formulieren und sie aktuell zu halten, kann Verkaufszyklen um Wochen verzögern und das Risiko von menschlichen Fehlern erhöhen. Moderne KI‑Plattformen haben bereits gezeigt, wie große Sprachmodelle (LLMs) Beweise synthetisieren und Antworten innerhalb von Sekunden generieren können.  

Allerdings gehen die meisten bestehenden Implementierungen von einem **Single‑Tenant**‑Kontext aus, in dem das KI‑Modell uneingeschränkten Zugriff auf sämtliche zugrundeliegenden Daten hat. In einer echten Multi‑Tenant‑SaaS‑Umgebung kann jeder Kunde (oder jede interne Abteilung) eigene Richtlinien, Nachweis‑Repositorien und Datenschutz‑Anforderungen besitzen. Das Zulassen, dass das LLM Rohdaten aller Mandanten einsehen kann, verletzt sowohl regulatorische Erwartungen (z. B. [DSGVO](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa)) als auch Verträge, die einen übergreifenden Datenleck ausdrücklich untersagen.

**Datenschutz‑bewusste Prompt‑Anpassung** schließt diese Lücke. Sie passt die generativen Fähigkeiten von LLMs an das jeweilige Wissens‑Repository jedes Mandanten an, während garantiert wird, dass Rohdaten ihren eigenen Silos niemals verlassen. Dieser Artikel führt durch die Kernkonzepte, architektonischen Bausteine und praktischen Schritte, die nötig sind, um eine sichere, skalierbare und konforme Multi‑Tenant‑Fragebogen‑Automatisierungsplattform zu implementieren.

---

## 1. Kernkonzepte

| Konzept | Definition | Warum es wichtig ist |
|---|---|---|
| **Prompt‑Anpassung** | Feinabstimmung eines eingefrorenen LLMs durch das Erlernen einer kleinen Menge kontinuierlicher Prompt‑Vektoren, die das Verhalten des Modells steuern. | Ermöglicht schnelle Individualisierung ohne ein vollständiges Neutraining, spart Rechenleistung und bewahrt die Herkunft des Modells. |
| **Differenzielle Privatsphäre (DP)** | Mathemische Garantie, dass das Ergebnis einer Berechnung nicht offenbart, ob ein bestimmter Eingabedatensatz enthalten war. | Schützt sensible Nachweisdetails, wenn sie über Mandanten hinweg aggregiert oder Feedback für kontinuierliche Verbesserungen gesammelt wird. |
| **Secure Multi‑Party Computation (SMPC)** | Kryptografische Protokolle, die es Parteien erlauben, gemeinsam eine Funktion über ihre Eingaben zu berechnen, ohne diese Eingaben preiszugeben. | Bietet einen Weg, Prompt‑Einbettungen gemeinsam zu trainieren oder zu aktualisieren, ohne rohe Daten an einen zentralen Dienst zu leaken. |
| **Rollenbasierte Zugriffskontrolle (RBAC)** | Berechtigungen werden basierend auf Benutzerrollen statt auf individuellen Identitäten zugewiesen. | Stellt sicher, dass nur autorisiertes Personal mandantenspezifische Prompts oder Nachweis‑Sammlungen einsehen bzw. bearbeiten kann. |
| **Mandanten‑Isolationsschicht** | Logische und physische Trennung (z. B. separate Datenbanken, containerisierte Laufzeiten) für die Daten und Prompt‑Einbettungen jedes Mandanten. | Garantiert die Einhaltung von Daten‑Souveränitäts‑Vorgaben und vereinfacht die Auditierbarkeit. |

---

## 2. Architektur‑Übersicht

Das folgende Mermaid‑Diagramm zeigt den End‑zu‑End‑Fluss vom Anfrage‑Eingang eines Mandanten bis zur KI‑generierten Antwort und hebt die datenschutz‑bewahrenden Kontrollen hervor.

```mermaid
graph TD
    "User Request\n(Questionnaire Item)" --> "Tenant Router"
    "Tenant Router" --> "Policy & Evidence Store"
    "Tenant Router" --> "Prompt Tuning Service"
    "Prompt Tuning Service" --> "Privacy Guard\n(Differential Privacy Layer)"
    "Privacy Guard" --> "LLM Inference Engine"
    "LLM Inference Engine" --> "Answer Formatter"
    "Answer Formatter" --> "Tenant Response Queue"
    "Tenant Response Queue" --> "User Interface"
```

### Schlüsselkomponenten

1. **Tenant Router** – Bestimmt den Mandanten‑Kontext anhand von API‑Keys oder SSO‑Tokens und leitet die Anfrage an die entsprechenden isolierten Dienste weiter.  
2. **Policy & Evidence Store** – Ein mandantenspezifischer, verschlüsselter Data‑Lake (z. B. AWS S3 mit Bucket‑Policies), der Sicherheitsrichtlinien, Audit‑Logs und Nachweis‑Artefakte enthält.  
3. **Prompt Tuning Service** – Generiert oder aktualisiert mandantenspezifische Prompt‑Einbettungen mithilfe von SMPC, sodass rohe Nachweise verborgen bleiben.  
4. **Privacy Guard** – Erzwingt die Injektion von differenzieller‑Privatsphäre‑Rauschen bei allen aggregierten Statistiken oder Feedback, die zur Modellverbesserung genutzt werden.  
5. **LLM Inference Engine** – Ein zustandsloser Container, der das eingefrorene LLM (z. B. Claude‑3, GPT‑4) mit den mandantenspezifischen Prompt‑Vektoren ausführt.  
6. **Answer Formatter** – Wendet Nachbearbeitungsregeln (z. B. Redaktion, Einfügen von Compliance‑Tags) an, bevor die finale Antwort ausgeliefert wird.  
7. **Tenant Response Queue** – Ein nachrichtenbasierter Puffer (z. B. Kafka‑Topic pro Mandant), der Konsistenz und Audit‑Spuren gewährleistet.

---

## 3. Implementierung der datenschutz‑bewussten Prompt‑Anpassung

### 3.1 Vorbereitung des Data Lakes

1. **Verschlüsselung im Ruhezustand** – Nutze serverseitige Verschlüsselung mit kundenverwalteten Schlüsseln (CMKs) für jeden Mandanten‑Bucket.  
2. **Metadaten‑Tagging** – Füge compliance‑bezogene Tags (`iso27001:true`, `gdpr:true`) hinzu, um automatisierte Richtlinien‑Abrufe zu ermöglichen.  
3. **Versionierung** – Aktiviere Objekt‑Versionierung, um einen vollständigen Audit‑Trail für Änderungen an Nachweisen zu erhalten.

### 3.2 Erzeugen mandantenspezifischer Prompt‑Vektoren

1. **Initialisierung der Prompt‑Einbettung** – Generiere zufällig einen kleinen (z. B. 10‑dimensionalen) dichten Vektor pro Mandant.  
2. **SMPC‑Trainingsschleife**  
   - **Schritt 1**: Das sichere Enklave des Mandanten (z. B. AWS Nitro Enclaves) lädt sein relevantes Nachweis‑Subset.  
   - **Schritt 2**: Das Enklave berechnet den Gradienten einer Verlustfunktion, die misst, wie gut das LLM simulierte Fragebogen‑Items mit dem aktuellen Prompt‑Vektor beantwortet.  
   - **Schritt 3**: Gradienten werden mittels additiver Secret‑Sharing über den zentralen Server und das Enklave verteilt.  
   - **Schritt 4**: Der Server aggregiert die Shares, aktualisiert den Prompt‑Vektor und gibt die aktualisierten Shares zurück ans Enklave.  
   - **Schritt 5**: Wiederhole bis zur Konvergenz (typischerweise ≤ 50 Iterationen wegen der geringen Dimensionalität).  

3. **Speichern der Prompt‑Vektoren** – Persistiere die finalen Vektoren in einem mandantenspezifischen KV‑Store (z. B. DynamoDB mit Mandanten‑Partition‑Key), verschlüsselt mit dem CMK des jeweiligen Mandanten.

### 3.3 Durchsetzung differenzieller Privatsphäre

Wenn das System Nutzungsstatistiken aggregiert (z. B. Anzahl der Verweise auf ein bestimmtes Nachweis‑Asset) für zukünftige Modellverbesserungen, wird der Laplace‑Mechanismus angewendet:

\[
\tilde{c} = c + \text{Laplace}\left(\frac{\Delta f}{\epsilon}\right)
\]

- **\(c\)** – Wahrer Zähler des Nachweis‑Verweises.  
- **\(\Delta f = 1\)** – Sensitivität (Hinzufügen/Entfernen eines einzelnen Verweises ändert den Zähler höchstens um 1).  
- **\(\epsilon\)** – Datenschutz‑Budget (Wähle 0,5–1,0 für starke Garantien).  

Alle nachgelagerten Analysen nutzen \(\tilde{c}\), sodass kein Mandant aus den aggregierten Zahlen auf das Vorhandensein eines konkreten Dokuments schließen kann.

### 3.4 Echtzeit‑Inference‑Ablauf

1. **Empfang der Anfrage** – UI sendet ein Fragebogen‑Item mit Mandanten‑Token.  
2. **Abruf des Prompt‑Vektors** – Prompt Tuning Service holt den mandantenspezifischen Vektor aus dem KV‑Store.  
3. **Einfügen des Prompts** – Der Vektor wird als „soft prompt“ an das LLM‑Input angehängt.  
4. **Ausführen des LLM** – Inferenz erfolgt in einem sandboxed Container mit Zero‑Trust‑Netzwerk.  
5. **Nachbearbeitung** – Redaktion aller unbeabsichtigten Datenlecks mittels Muster‑basiertem Filter.  
6. **Rückgabe der Antwort** – Die formatierte Antwort wird an die UI gesendet und für Audits protokolliert.

---

## 4. Sicherheits‑ & Compliance‑Checkliste

| Bereich | Kontrolle | Frequenz |
|---|---|---|
| **Daten‑Isolation** | Verifiziere, dass Bucket‑Policies den Zugriff ausschließlich auf den jeweiligen Mandanten erlauben. | Quartalsweise |
| **Vertraulichkeit der Prompt‑Vektoren** | Rotieren von CMKs und erneutes Durchführen des SMPC‑Tuning nach jeder Schlüsselrotation. | Jährlich / bei Bedarf |
| **DP‑Budget** | Überprüfe \(\epsilon\)-Werte und stelle sicher, dass sie regulatorischen Vorgaben entsprechen. | Halbjährlich |
| **Audit‑Logging** | Speichere unveränderliche Logs für Prompt‑Abrufe und Antwort‑Generierung. | Kontinuierlich |
| **Penetrationstests** | Führe Red‑Team‑Übungen gegen das Inferenz‑Sandbox durch. | Halbjährlich |
| **Compliance‑Mapping** | Ordne jedes Mandanten‑Tag den entsprechenden Kontrollen von [ISO 27001](https://www.iso.org/standard/27001), [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), DSGVO usw. zu. | Laufend |

---

## 5. Leistung und Skalierbarkeit

| Kennzahl | Ziel | Optimierungshinweise |
|---|---|---|
| **Latenz (95‑tes Perzentil)** | < 1,2 s pro Antwort | Warm‑Container nutzen, Prompt‑Vektoren im Speicher cachen, LLM‑Shard‑Modelle vorwärmen. |
| **Durchsatz** | 10 k Anfragen/sek. über alle Mandanten | Horizontales Pod‑Autoscaling, Batching von ähnlichen Prompts, GPU‑beschleunigte Inferenz. |
| **Prompt‑Tuning‑Zeit** | ≤ 5 Min pro Mandant (Initial) | Parallelisiere SMPC über mehrere Enklaven, reduziere Vektor‑Dimensionalität. |
| **DP‑Rauscheffekt** | ≤ 1 % Nutzwertverlust bei aggregierten Metriken | \(\epsilon\) basierend auf empirischen Nutzwert‑Kurven anpassen. |

---

## 6. Praxisbeispiel: FinTech‑SaaS‑Plattform

Ein FinTech‑SaaS‑Anbieter betreibt ein Compliance‑Portal für über 200 Partner. Jeder Partner speichert proprietäre Risikomodelle, KYC‑Dokumente und Audit‑Logs. Durch den Einsatz datenschutz‑bewusster Prompt‑Anpassung:

- **Durchlaufzeit** für **SOC 2**‑Fragebogen‑Antworten fiel von 4 Tagen auf < 2 Stunden.  
- **Cross‑Tenant‑Datenlecks** wurden auf 0 reduziert (externes Audit bestätigt).  
- **Compliance‑Kosten** sanken um ca. 30 % dank automatisierter Nachweis‑Ermittlung und Antwortgenerierung.

Der Anbieter nutzte zudem die DP‑geschützten Nutzungsmetriken, um einen kontinuierlichen Verbesserungs‑Pipeline zu speisen, die neue Nachweis‑Artefakte vorschlug – ohne jemals Partnerdaten offenzulegen.

---

## 7. Schritt‑für‑Schritt‑Bereitstellungs‑Leitfaden

1. **Infrastruktur bereitstellen**  
   - Separate S3‑Buckets pro Mandant mit CMK‑Verschlüsselung anlegen.  
   - Nitro Enclaves oder Confidential VMs für SMPC‑Workloads bereitstellen.  

2. **KV‑Store einrichten**  
   - DynamoDB‑Tabelle mit Partition‑Key `tenant_id` anlegen.  
   - Point‑in‑Time‑Recovery aktivieren, um Prompt‑Vektor‑Rollbacks zu ermöglichen.  

3. **Prompt‑Tuning‑Service integrieren**  
   - Microservice (`/tune-prompt`) mit REST‑API deployen.  
   - SMPC‑Protokoll mittels **MP‑SPDZ**‑Bibliothek (Open‑Source) implementieren.  

4. **Privacy Guard konfigurieren**  
   - Middleware hinzufügen, die Laplace‑Rauschen in alle Telemetrie‑Endpoints injiziert.  

5. **Inference‑Engine deployen**  
   - OCI‑kompatible Container mit GPU‑Durchgriff starten.  
   - Das eingefrorene LLM‑Modell laden (z. B. `claude-3-opus`).  

6. **RBAC umsetzen**  
   - Rollen (`admin`, `analyst`, `viewer`) auf IAM‑Richtlinien abbilden, die den Zugriff auf Prompt‑Vektoren und Nachweis‑Sammlungen beschränken.  

7. **UI‑Schicht bauen**  
   - Fragebogen‑Editor bereitstellen, der Prompts via `/tenant/{id}/prompt` bezieht.  
   - Audit‑Logs und DP‑adjustierte Nutzungs‑Analytics im Dashboard anzeigen.  

8. **Akzeptanztests durchführen**  
   - Cross‑Tenant‑Abfragen simulieren, um Datenlecks zu prüfen.  
   - DP‑Rausch‑Level gegen das festgelegte \(\epsilon\) validieren.  

9. **Live‑Schaltung & Monitoring**  
   - Auto‑Scaling‑Policies aktivieren.  
   - Alerts für Latenz‑Spitzen oder IAM‑Berechtigungs‑Anomalien einrichten.  

---

## 8. Zukünftige Erweiterungen

- **Föderiertes Prompt‑Lernen** – Mandanten können gemeinsam einen Basis‑Prompt verbessern, während die Privatsphäre mittels föderierter Mittelwertbildung erhalten bleibt.  
- **Zero‑Knowledge‑Proofs** – Verifizierbare Beweise erzeugen, dass eine Antwort aus einem bestimmten Nachweis‑Set stammt, ohne das Nachweis‑Set selbst offenzulegen.  
- **Adaptives DP‑Budget** – \(\epsilon\) dynamisch basierend auf der Sensitivität der Anfrage und dem Risikoprofil des Mandanten zuteilen.  
- **Explainable AI (XAI) Overlay** – Rationale Snippets anhängen, die die konkreten Richtlinien‑Abschnitte referenzieren, die zur Antwort geführt haben, um die Audit‑Bereitschaft zu erhöhen.  

---

## Fazit

Datenschutz‑bewusste Prompt‑Anpassung eröffnet die goldene Mitte zwischen **hochwertiger KI‑Automatisierung** und **strikter Multi‑Tenant‑Datenisolation**. Durch die Kombination von SMPC‑basiertem Prompt‑Learning, differenzieller Privatsphäre und robuster RBAC können SaaS‑Anbieter sofort präzise, konforme Antworten auf Sicherheitsfragebögen liefern, ohne das Risiko eines übergreifenden Datenlecks oder regulatorischer Verstöße. Die hier beschriebene Architektur ist sowohl **skalierbar** – sie bewältigt tausende gleichzeitige Anfragen – als auch **zukunftssicher**, bereit für aufkommende Datenschutz‑Technologien.  

Die Einführung dieses Ansatzes verkürzt nicht nur Verkaufszyklen und reduziert manuellen Aufwand, sondern gibt Unternehmen das Vertrauen, dass ihre sensibelsten Compliance‑Nachweise genau dort bleiben, wo sie hingehören: hinter ihrer eigenen Firewall.

---

## Siehe auch

- Differential Privacy in Production – An Introduction (Google AI Blog)  
- Prompt Tuning vs Fine‑Tuning: When to Use Each (OpenAI Technical Report)