Die Frage, die Ihnen gestellt wird
Wenn Sie seit mehr als einem Jahr einen SOC 2 Type II Report halten, findet dieses Gespräch bereits statt. Ihr Prüfer, angestoßen durch aktualisierte AICPA-Leitlinien und Security-Fragebögen von Kunden, fragt: „Nutzt eines Ihrer Produktivsysteme Large Language Models oder andere AI-Komponenten, und wie sind diese in Ihren Kontrollen abgedeckt?" Sie sagen ja. Er möchte die Kontrollen sehen. Sie haben keine saubere Antwort.
Dieser Beitrag ist die Karte, die wir mit Kunden durchgehen, wenn sie diese Frage beantworten müssen. Er behandelt, welche Trust Service Criteria tatsächlich AI-Komponenten berühren, welche Kontrollen zu ergänzen (nicht zu ersetzen) sind, wie Sie sie nachweisen und was typischerweise schiefläuft. Er richtet sich an Teams, die bereits ein funktionierendes SOC-2-Programm betreiben und den Scope erweitern müssen – nicht an Erstanwender.
Welche TSCs gelten für AI-Komponenten
SOC-2-Berichte decken fünf Trust Service Criteria ab: Security, Availability, Processing Integrity, Confidentiality und Privacy. Security ist verpflichtend, die anderen sind optional. So bilden sie ein typisches LLM-gestütztes Feature ab.
| TSC | Relevanz für LLM-Systeme | Priorität |
|---|---|---|
| Security | Zugriffskontrolle auf Model-Endpunkte, Prompt-Logs, Trainingsdaten. Wie bei jedem Service. | Standard |
| Availability | Vendor-Abhängigkeit von OpenAI/Anthropic. Uptime-SLAs, Fallbacks. | Mittel |
| Processing Integrity | Korrektheit, Vollständigkeit, Gültigkeit der Outputs. Das große Thema bei AI. | Hoch |
| Confidentiality | Prompts können vertrauliche Kundendaten enthalten. Datenverarbeitung beim Anbieter. | Hoch |
| Privacy | PII in Prompts, nutzerbezogene Daten im Training. Überschneidung mit DSGVO. | Hoch, falls im Scope |
Die meisten reifen SOC-2-Berichte umfassen Security, Availability und Confidentiality. Für LLM-Features müssen Sie mit hoher Wahrscheinlichkeit entweder Processing Integrity ergänzen oder dokumentieren, dass Ihre AI-Komponenten die von Processing Integrity regulierten Flows nicht berühren.
AI-Features auf Kontrollen abbilden
Beginnen Sie mit einer einfachen Inventur. Beantworten Sie für jedes AI-Feature:
- Was tut es?
- Welche Daten gelangen in den Prompt?
- Welche Daten kommen heraus?
- Wer oder was darf es aufrufen?
- Von welchen Anbietern hängt es ab?
- Was passiert, wenn es falsch ist?
Dann bilden Sie jede Antwort auf eine Kontrolle ab. Unten ist eine Kontrollmatrix, die wir in Kundenmandaten einsetzen. Sie ist nicht vollständig – Sie ergänzen unternehmensspezifische Kontrollen –, aber sie ist die Basis, mit der wir das Gespräch mit dem Prüfer strukturieren.
Die Kontrollmatrix
Security (CC6.x)
| Control ID | Beschreibung | Nachweis |
|---|---|---|
| AI-SEC-01 | Zugriff auf LLM-API-Keys und Anbieter-Credentials ist auf autorisierte Services beschränkt und wird planmäßig rotiert | Secrets-Manager-Policy, Rotations-Logs |
| AI-SEC-02 | Zugriff auf Trainingsdaten und Fine-Tuning-Datensätze ist rollenbasiert und protokolliert | IAM-Policies, CloudTrail, Access Reviews |
| AI-SEC-03 | MCP-/Tool-Server, die an Agents exponiert werden, erfordern Authentifizierung und Autorisierung pro Aufruf | Auth-Middleware-Code, Integrationstests, Audit-Logs |
| AI-SEC-04 | Prompt-/Response-Logs mit Kundendaten sind at rest mit kunden- oder anbieterverwalteten Keys verschlüsselt | KMS-Konfiguration, S3-Bucket-Policies |
| AI-SEC-05 | AI-Komponenten sind Teil der quartalsweisen Access Reviews | Access-Review-Arbeitsblatt, Sign-off |
Availability (A1.x)
| Control ID | Beschreibung | Nachweis |
|---|---|---|
| AI-AVL-01 | Abhängigkeiten zu Model-Anbietern sind dokumentiert, mit Fallback-Strategien für jeden | Architektur-Dokument, LLM-Gateway-Konfiguration |
| AI-AVL-02 | AI-abhängige User Journeys degradieren graceful, wenn das LLM nicht verfügbar ist | Feature-Flag-Konfiguration, getestete Failure Modes |
| AI-AVL-03 | Incident-Response-Runbooks decken Ausfälle von LLM-Anbietern ab | Runbook, Game-Day-Protokolle |
| AI-AVL-04 | Monitoring umfasst LLM-Latenz, Error-Rate und Kosten-SLOs | Grafana-Dashboards, Alert-Regeln |
Processing Integrity (PI1.x)
| Control ID | Beschreibung | Nachweis |
|---|---|---|
| AI-PI-01 | Modell-Änderungen (Base-Model-Upgrade, Prompt-Änderungen, Fine-Tune-Updates) folgen einem dokumentierten Change-Management-Prozess | PR-Records, Change-Advisory-Meeting-Notizen |
| AI-PI-02 | Regressions-Evaluation läuft gegen ein Golden Dataset, bevor eine wesentliche Modell-Änderung in Produktion geht | Eval-Harness, CI-Logs, Evaluations-Reports |
| AI-PI-03 | Outputs, die in automatisierten Entscheidungen verwendet werden, werden gegen ein Schema validiert und bei Malformation verworfen | Schema-Definitionen, Validierungs-Logs |
| AI-PI-04 | Halluzinations- und Safety-Signale werden in Produktion überwacht, mit Alerting bei Regressionen | Monitoring-Dashboards, Alert-Konfiguration |
| AI-PI-05 | Menschliche Aufsicht ist für irreversible Aktionen, die von AI-Systemen erzeugt werden, erforderlich | Workflow-Definitionen, Human-Review-Logs |
Confidentiality (C1.x)
| Control ID | Beschreibung | Nachweis |
|---|---|---|
| AI-CONF-01 | Sensible Datenkategorien sind dokumentiert; Prompts werden vor Übertragung auf Secrets und PII geprüft | Datenklassifizierung, DLP-Logs |
| AI-CONF-02 | Auftragsverarbeitungsverträge mit Model-Anbietern enthalten angemessene Zero-Retention-, Training-Opt-out- und Regions-Klauseln | Unterzeichnete DPAs |
| AI-CONF-03 | Prompt- und Response-Logs haben definierte Aufbewahrungsfristen und Löschworkflows | Retention-Policy, Lifecycle-Regeln |
| AI-CONF-04 | Kundendaten sind in Prompts, Caches und Logs mandantenisoliert | Code Review, Penetrationstest |
| AI-CONF-05 | Confidentiality-Zusagen sind in Kundenverträgen und internen Richtlinien abgebildet | MSAs, Richtliniendokumente |
Privacy (P1.x bis P8.x, sofern im Scope)
| Control ID | Beschreibung | Nachweis |
|---|---|---|
| AI-PRIV-01 | Nutzer werden informiert, wenn sie mit einem AI-System interagieren | UI-Screenshots, Produktanforderungen |
| AI-PRIV-02 | Nutzeranfragen zur Löschung oder zum Export von Daten umfassen AI-generierte Datensätze und zugehörige Prompt-Logs | DSAR-Workflow, Abschluss-Records |
| AI-PRIV-03 | Modelltraining (falls vorhanden) schließt Kundendaten aus, sofern keine Einwilligung vorliegt | Trainingsdaten-Manifest, Einwilligungs-Records |
| AI-PRIV-04 | Anbieter-DPAs decken grenzüberschreitende Datenübermittlungen mit geeigneten Schutzmaßnahmen ab | SCCs, Transfer Impact Assessment |
Wie gute Nachweise aussehen
SOC-2-Prüfer wollen Nachweise, die reproduzierbar, datiert und an eine konkrete Kontrolle gebunden sind. Für AI-Komponenten automatisieren wir so viel wie möglich davon.
Nachweis für AI-PI-02 (Regressions-Eval)
Die Kontrolle sagt: Eine Regressions-Eval läuft, bevor eine wesentliche Modell-Änderung in Produktion geht. Guter Nachweis sieht so aus:
- Ein
evals/-Verzeichnis im Repo mit dem Golden Dataset und dem Eval-Skript. - CI-Logs, die zeigen, dass die Eval bei jedem PR lief, der das Modell oder die Prompt-Konfiguration verändert hat.
- Eine Summary-Output-Datei, die im Release-Artefakt committed wird.
- Ein Alert, der feuert, wenn die Eval fehlschlägt oder übersprungen wird.
# .github/workflows/model-eval.yaml
name: model-eval
on:
pull_request:
paths:
- "config/models/**"
- "prompts/**"
- "evals/**"
jobs:
eval:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: { python-version: "3.12" }
- run: pip install -r requirements.txt
- name: Run golden dataset eval
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
python -m evals.run \
--dataset evals/golden.jsonl \
--report out/eval-report.json
- name: Fail on regression
run: python -m evals.gate --report out/eval-report.json --min-score 0.88
- uses: actions/upload-artifact@v4
with:
name: eval-report-${{ github.sha }}
path: out/eval-report.json
Am Audit-Tag exportieren Sie die Liste der gemergten PRs für den Zeitraum, gleichen sie mit den Artefakten ab und zeigen dem Prüfer, dass jede relevante Änderung einen zugehörigen Eval-Report hat. Erledigt.
Nachweis für AI-CONF-01 (Prompt-Scanning)
Die Kontrolle sagt: Prompts werden vor der Übertragung auf Secrets und PII geprüft. Guter Nachweis sieht so aus:
- Der Scanning-Code samt Tests.
- Produktions-Logs, die Redaction-Ereignisse über einen Stichprobenzeitraum zeigen.
- Ein Runbook für Vorfälle, in denen die Redaction fehlschlägt.
# app/llm/redact.py
import re
from dataclasses import dataclass
PATTERNS: list[tuple[re.Pattern[str], str]] = [
(re.compile(r"sk-ant-[A-Za-z0-9-]{20,}"), "[REDACTED_ANTHROPIC_KEY]"),
(re.compile(r"AKIA[0-9A-Z]{16}"), "[REDACTED_AWS_KEY]"),
(re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.-]+\b"), "[REDACTED_EMAIL]"),
(re.compile(r"\b(?:\d[ -]*?){13,16}\b"), "[REDACTED_CARD]"),
]
@dataclass
class RedactionResult:
text: str
hits: dict[str, int]
def redact(raw: str) -> RedactionResult:
result = raw
hits: dict[str, int] = {}
for pattern, label in PATTERNS:
matches = pattern.findall(result)
if matches:
hits[label] = len(matches)
result = pattern.sub(label, result)
return RedactionResult(text=result, hits=hits)
Zusammen mit strukturiertem Logging der Redaction-Counts (nicht des Inhalts) kann der Prüfer verifizieren, dass die Kontrolle über den Audit-Zeitraum funktioniert.
Vendor Due Diligence
Für SOC-2-Zwecke ist jeder Model-Anbieter eine Sub-Service-Organisation oder ein Vendor, abhängig davon, wie Sie scopen. In beiden Fällen möchte der Prüfer Ihre Due Diligence zu ihnen sehen. Jeder größere Anbieter veröffentlicht einen SOC-2-Report unter NDA und gibt ihn auf Anfrage heraus.
Vendor-Evidence-Paket, das wir für jeden in Scope befindlichen Model-Anbieter sammeln:
- Aktuellsten SOC 2 Type II Report (unter NDA).
- ISO-27001-Zertifikat, falls verfügbar.
- DPA mit passenden Anlagen.
- Modellspezifische Datenverarbeitungsbedingungen (Zero Retention, Training-Opt-out).
- Zusagen zur Incident-Benachrichtigung.
- Kontakt für Security-Themen.
Ablegen im Vendor-Management-System mit jährlichem Review-Termin.
Häufige Findings und wie Sie sie vermeiden
In den SOC-2-Engagements, die wir begleitet haben, sind dies die wiederkehrenden Findings, wenn AI-Features in den Scope aufgenommen werden.
Finding 1: Modelländerungen umgehen den Change-Management-Prozess. Ein Modell zu fine-tunen oder einen Prompt zu aktualisieren fühlt sich wie ein Config-Tweak an. Prüfer sehen darin eine Änderung an einem System, das kundenseitigen Output erzeugt. Verlangen Sie PR-Review und ein Change-Ticket für jede Prompt- und Modell-Änderung.
Finding 2: Kein Nachweis für Regressionstests vor Release. „Haben wir überflogen" ist kein Nachweis. Bauen Sie die Eval-Harness, selbst wenn sie nur zehn Testfälle enthält.
Finding 3: Prompt-Logs werden unbefristet aufbewahrt. Ohne Lifecycle-Policy füllen sich S3-Buckets. Prüfer flaggen das unter Confidentiality und Privacy. Setzen Sie Lifecycle-Regeln und dokumentieren Sie die Aufbewahrungsfrist.
Finding 4: Kein DPA mit dem Model-Anbieter. Teams registrieren sich mit einer Kreditkarte, schicken Produktionsverkehr hindurch und unterzeichnen nie einen DPA. Vor dem Audit beheben.
Finding 5: Herkunft der Trainingsdaten unklar. Wenn Sie fine-tunen, will der Prüfer wissen, woher die Daten kommen, wer sie freigegeben hat und ob PII entfernt wurde. Pflegen Sie ein Dataset-Manifest.
Finding 6: Kein Incident-Response-Plan für AI-spezifische Themen. „Was passiert, wenn das Modell Kunden-PII ausgibt?" sollte eine dokumentierte Antwort und eine Tabletop-Übung in der Ablage haben.
Finding 7: Kundenverträge offenbaren keine AI-Nutzung. Processing-Integrity- und Confidentiality-Zusagen können vom tatsächlichen Produktverhalten abweichen. Aktualisieren Sie MSAs und Datenschutzhinweise.
Einen bestehenden Report erweitern
Die mechanischen Schritte, einen SOC 2 auf AI zu erweitern:
- Scope-Workshop mit Ihrem Prüfer. Definieren Sie, welche AI-Features im Scope sind und welche TSCs greifen.
- Gap-Assessment gegen die obige Kontrollmatrix. Markieren Sie jede als in place, partial oder missing.
- Remediierung der Partials und Missings. Für ein Team mit bestehender Hygiene typischerweise 4–8 Wochen.
- Nachweis-Erhebung für den Audit-Zeitraum. Wenn die neuen Kontrollen erst seit einem Monat in Kraft sind, attestiert Ihr Type II die operative Wirksamkeit nur für diesen Monat. Planen Sie entsprechend.
- Walkthrough mit dem Prüfer zur Bestätigung des Verständnisses.
- Fieldwork – klassisches SOC-2-Sample-Testing.
- Report-Ausstellung.
In der Praxis können die meisten Kunden die AI-Abdeckung erst in der nächsten Reporting-Periode ergänzen, nicht in der aktuellen – der Prüfer benötigt zeitlich eingegrenzte Nachweise, und Sie brauchen saubere sechs Monate Betrieb.
Eine pragmatische Kurzliste
Wenn Sie dem vor Ihrem nächsten Audit zuvorkommen wollen, erledigen Sie diese sechs Dinge:
- Inventarisieren Sie jedes AI-Feature und klassifizieren Sie es gegen die Kontrollmatrix.
- Bauen Sie die Regressions-Eval-Harness. Lassen Sie sie in CI laufen.
- Fügen Sie Prompt-Scanning-Middleware hinzu und loggen Sie die Hits.
- Unterzeichnen Sie DPAs mit jedem genutzten Model-Anbieter.
- Setzen Sie eine Retention-Policy auf Prompt- und Response-Logs.
- Erweitern Sie Ihr Incident-Runbook um einen AI-Zweig.
Sechs Punkte, grob ein Quartal fokussierte Arbeit. Der Prüfer wird zufrieden sein; wichtiger noch, auch die Security-Teams Ihrer Kunden.
Nächste Schritte
SOC 2 auf AI-Komponenten zu erweitern ist ein Projekt, kein Neuaufbau. Die Fundamente, die Sie bereits haben – Change Management, Zugriffskontrolle, Incident Response – tragen größtenteils. Die wirklich neue Arbeit liegt in Evaluation, Datenverarbeitung und Vendor Management. Starten Sie mit der Matrix, bilden Sie Ihre Features ab und sprechen Sie frühzeitig mit Ihrem Prüfer. Wenn Sie Unterstützung beim Gap-Assessment oder beim Aufbau der Evidence-Collection-Pipeline wünschen, nehmen Sie Kontakt auf.