Wenn Sie 2026 ein SOC 2 Type II Audit durchlaufen und Ihr Unternehmen AI-Tools nutzt – was der Fall ist – erwarten Sie, dass AI zur Sprache kommt. Nicht in einer Ecke des Fragebogens. In der zentralen Kontrollnarrative.
Auditoren gehen mit AI je nach Prüfungsgesellschaft auf eine von zwei Arten um. Der progressivere Ansatz behandelt die AI-Tool-Nutzung als neue Kategorie innerhalb der bestehenden Trust Services Criteria – konkret logische Zugriffskontrollen, Change Management und Risikomanagement. Der vorsichtigere Ansatz kennzeichnet ungesteuerte AI-Nutzung als Feststellung unter der CC6-Reihe (logische und physische Zugriffskontrollen) oder CC9 (Risikomanagement), je nachdem, wie der Auditor den Umfang auslegt.
In beiden Fällen ist die Frage dieselbe: Verfügt Ihre Organisation über dokumentierte, durchgesetzte Kontrollen darüber, wie AI-Tools genutzt werden, welche Daten in sie eingehen und wer Zugriff auf sie hat?
Dieser Beitrag erläutert, wonach Auditoren suchen, welche Nachweise die Frage beantworten und welche häufigsten Lücken zu Feststellungen führen.
Warum AI jetzt im SOC-2-Umfang liegt
SOC-2-Audits prüfen gegen die Trust Services Criteria der AICPA. Die Kriterien selbst wurden nicht überarbeitet, um spezifische AI-Kontrollen aufzunehmen, doch die bestehenden Kriterien sind breit genug, um die AI-Tool-Nutzung zu erfassen:
- CC6.1 (Logischer Zugriff): Die Organisation beschränkt den logischen Zugriff auf Informationswerte. AI-Tools sind Informationswerte. Wenn Mitarbeiter AI-Tools mit unbeschränktem Zugriff auf sensible Daten nutzen, greift CC6.
- CC6.6 (Grenzschutz): Die Organisation verhindert unbefugten Zugriff aus externen Quellen. AI-Modellanbieter sind extern – sie erhalten alle Daten, die Mitarbeiter übermitteln. Die Frage ist, ob diese Übertragung kontrolliert wird.
- CC9.2 (Risikobewertung): Die Organisation bewertet Risiken aus der Nutzung von Technologie von Anbietern und Geschäftspartnern. AI-Anbieter sind Lieferanten. Ein AI-Anbieter, der Kundendaten ohne dokumentierte Risikobewertung erhält, ist eine CC9-Lücke.
- A1.2 (Verfügbarkeit – für AI-abhängige Systeme): Wenn Produktionssysteme von AI abhängen, werden Verfügbarkeit und Resilienz dieser AI-Abhängigkeit Teil des Umfangs.
Die AICPA hat 2023 eine Leitlinie herausgegeben, die AI als aufkommenden Risikobereich anerkennt. Prüfungsgesellschaften, insbesondere die größeren, haben interne Praxisstandards dafür entwickelt, wie AI-Kontrollen zu bewerten sind. Die praktische Folge ist, dass Unternehmen, die 2026 ein SOC 2 durchlaufen, AI-Fragen in der Risikobewertungsphase und AI-Nachweisanfragen während der Feldarbeit erwarten sollten.
Die drei Bereiche, die Auditoren prüfen
1. AI-Tool-Inventar und Zugriffsverwaltung
Wonach sie fragen: Welche AI-Tools nutzt Ihre Organisation? Wer hat Zugriff darauf? Sind sie über Ihren Lieferantenmanagement-Prozess genehmigt?
Der Auditor prüft CC6.1 (logischer Zugriff) und CC9.2 (Lieferantenmanagement). Eine Organisation, die kein aktuelles Inventar der genutzten AI-Tools vorlegen kann – mit derselben Sorgfalt wie bei ihrem SaaS-Lieferanteninventar – hat eine Dokumentationslücke.
Was die Frage beantwortet:
- Ein gepflegtes AI-Tool-Inventar, das genehmigte Tools, ihre Datenklassifizierung, ihre Risikobewertung und ihren Zugriffsumfang auflistet (wer nutzt sie, zu welchen Zwecken)
- Nachweise, dass nicht genehmigte Tools eingeschränkt oder überwacht werden (Zugriffskontroll-Konfigurationen, Netzwerkprotokolle oder ein Nutzungsüberwachungsbericht)
- Unterzeichnete Auftragsverarbeitungsverträge (AVV) oder gleichwertige vertragliche Datenverarbeitungs-Zusagen von AI-Anbietern, die Kundendaten verarbeiten
- Nachweise einer Lieferanten-Risikobewertung für jeden AI-Anbieter, der als Unterauftragsverarbeiter oder Hochrisiko-Lieferant eingestuft ist
Das Inventar sollte mit derselben Disziplin behandelt werden wie Ihr SaaS-Tool-Inventar. Wenn Ihre SOC-2-Vorbereitung bereits ein Lieferantenregister mit Risikostufen umfasst, gehören AI-Tools hinein.
Häufige Feststellung: Das Inventar existiert für die Unternehmens-IT-Tools, doch AI-Tools wurden ad hoc hinzugefügt, ohne den Lieferantenbewertungsprozess zu durchlaufen. Der Auditor stellt fest, dass mehrere AI-Anbieter Zugriff auf Kundendaten haben, aber nicht im Lieferantenregister geführt werden.
2. Datenverarbeitungskontrollen: Was in AI-Tools eingeht
Wonach sie fragen: Welche Datenkategorien dürfen Mitarbeiter an AI-Tools übermitteln? Gibt es Kontrollen, die verhindern, dass Kundendaten an externe AI-Modelle übermittelt werden?
Diese Frage prüft CC6.6 (Grenzschutz) und kann je nach im Umfang befindlicher Trust-Services-Kategorie auch die Kriterien Verfügbarkeit oder Vertraulichkeit berühren.
Der Kernpunkt ist: Wenn Kundendaten einen AI-Modellanbieter erreichen können, ist dieser Anbieter ein Unterauftragsverarbeiter der Daten Ihrer Kunden. Sofern Sie keine Einwilligung des Kunden (typischerweise über Ihren AVV/Ihre Nutzungsbedingungen) und keine vertraglichen Schutzmaßnahmen mit dem AI-Anbieter haben, ist diese Übertragung eine potenzielle Feststellung.
Was die Frage beantwortet:
- Eine dokumentierte Richtlinie, die festlegt, welche Datenkategorien an AI-Tools übermittelt werden dürfen und welche nicht (z. B. interne Entwürfe und nicht sensible Recherchen = erlaubt; Kunden-PII, Transaktionsdaten und vertrauliche Geschäftsinformationen = eingeschränkt)
- Technische Kontrollen, die die Richtlinie durchsetzen: Prompt-Prüfung oder Content-Filterung, die sensible Daten erkennt und blockiert oder schwärzt, bevor sie das Modell erreichen
- Nachweise, dass die Kontrollen wirksam sind – typischerweise ein Auszug aus dem AI-Aktivitätsprotokoll, der die Durchsetzungsmaßnahmen der Richtlinie über den Prüfzeitraum zeigt
- Falls Kundendaten in AI-Tools eingehen: Nachweise, dass Kunden informiert sind (AVV-Klausel oder Offenlegung in den Nutzungsbedingungen) und dass der AI-Anbieter einen AVV mit gleichwertigem Schutz unterzeichnet hat
Häufige Feststellung: Die Richtlinie existiert im Mitarbeiterhandbuch, aber es gibt keine technische Durchsetzung. Der Auditor fragt nach Nachweisen, dass die Richtlinie wie vorgesehen wirksam ist, und es gibt keine – weil der einzige Durchsetzungsmechanismus eine Schulung war. Eine Richtlinie ohne Kontrolle ist eine Lücke.
3. Audit-Trail und Überwachung
Wonach sie fragen: Wie überwachen Sie die AI-Tool-Nutzung? Können Sie Richtlinienverstöße erkennen? Haben Sie einen Audit-Trail für AI-Aktivität?
Dies prüft CC7.2 (Systemüberwachung) und CC7.3 (Anomalieerkennung und -reaktion). Der Auditor sucht nach Nachweisen, dass Sie es bemerken würden, wenn etwas schiefginge – und dass Sie Aufzeichnungen haben, um es zu untersuchen, falls es passiert.
Was die Frage beantwortet:
- Ein AI-Aktivitätsprotokoll, das Folgendes erfasst: Nutzeridentität, genutztes Tool oder Modell, Zeitstempel, angewandte Richtlinienentscheidung und etwaige Erkennungsereignisse sensibler Inhalte
- Nachweise, dass das Protokoll geprüft wird – entweder durch automatisierte Alarmierung bei Richtlinienverstößen oder durch einen periodischen menschlichen Prüfprozess, der in Ihren Security-Operations-Verfahren dokumentiert ist
- Aufbewahrung der AI-Aktivitätsprotokolle für die nach Ihrer Aufbewahrungsrichtlinie erforderliche Dauer (typischerweise 12 Monate, um mit den Prüfzeiträumen übereinzustimmen)
- Nachweise, dass der Überwachungsprozess einen Richtlinienverstoß erkennen würde – etwa ein Beispiel für ein erkanntes und bearbeitetes Ereignis oder eine Dokumentation, dass die automatisierte Alarmierung konfiguriert und getestet ist
Häufige Feststellung: Die Organisation nutzt die nativen Protokolle des AI-Anbieters (z. B. OpenAI-Nutzungsprotokolle) als Überwachungsnachweis. Auditoren kennzeichnen dies typischerweise, weil anbieterseitige Protokolle nicht das vollständige Bild erfassen: Sie zeigen nicht, welche Richtlinie zum jeweiligen Zeitpunkt galt, ob die Übermittlung unter dieser Richtlinie autorisiert war oder was nachgelagert geschah. Ein unabhängiger Audit-Trail – einer, den Ihre Organisation kontrolliert – ist der stärkere Nachweis.
Den Nachweispfad vor der Feldarbeit aufbauen
Der beste Zeitpunkt, um AI-Governance-Dokumentation für SOC 2 aufzubauen, ist sechs Monate vor Beginn des Audits. Der zweitbeste Zeitpunkt ist jetzt.
Die erforderliche Dokumentation lässt sich direkt den drei oben genannten Bereichen zuordnen:
Für Inventar und Lieferantenmanagement:
- Fügen Sie AI-Tools Ihrem Lieferantenregister hinzu; weisen Sie Risikostufen zu
- Erstellen Sie eine Lieferanten-Risikobewertung für jeden AI-Anbieter, der Kundendaten verarbeitet
- Holen Sie AVVs von AI-Anbietern ein, wo erforderlich; dokumentieren Sie, wo AVVs ausstehen
- Definieren Sie den Zugriffsumfang je Tool im Inventar
Für Datenverarbeitungskontrollen:
- Verfassen Sie einen AI-Datenverarbeitungs-Anhang zu Ihrer bestehenden Datenklassifizierungs-Richtlinie
- Definieren Sie erlaubte und eingeschränkte Datenkategorien je AI-Tool-Stufe
- Setzen Sie technische Durchsetzung ein (AI-Gateway, Prompt-Prüfung oder gleichwertig)
- Dokumentieren Sie die technische Kontrolle in Ihrem Kontrollinventar mit einem Test der Wirksamkeit im Betrieb
Für Überwachung und Audit-Trail:
- Konfigurieren Sie AI-Aktivitäts-Logging in Ihrer Governance-Schicht (nicht nur Anbieterprotokolle)
- Definieren Sie die Überwachungskadenz: automatisierte Alarme, menschliche Prüfung oder beides
- Dokumentieren Sie den Prüfprozess in Ihrem Security-Operations-Runbook
- Bewahren Sie Protokolle für den vollständigen Prüfzeitraum auf, bevor die Feldarbeit beginnt
Was Auditoren als Nachweis für AI-Kontrollen akzeptieren
Die praktische Frage ist, welche Formate Auditoren akzeptieren. Auf Basis der Muster aus den SOC-2-Vorbereitungszyklen 2025 und 2026 beantworten die folgenden Nachweisarten AI-Kontrollfragen durchgängig:
| Bereich | Nachweisart | Stärke |
|---|---|---|
| Tool-Inventar | AI-Tool-Register mit Risikobewertungen und Zugriffsumfang, datiert und aktuell | Stark |
| Lieferantenmanagement | Unterzeichnete AVVs von AI-Anbietern; Dokumentation der Lieferanten-Risikobewertung | Stark |
| Datenklassifizierung | Schriftliche AI-Datenverarbeitungs-Richtlinie, versionskontrolliert | Mittel |
| Technische Durchsetzung | Konfigurations-Screenshot + Richtliniendefinition aus AI-Gateway oder DLP-Tool | Stark |
| Überwachung | Beispielhafter Auszug aus dem AI-Aktivitätsprotokoll (geschwärzt) mit Richtlinienentscheidungen | Stark |
| Überwachung | Nachweis der Konfiguration automatisierter Alarme + dokumentierte Prüfhistorie | Stark |
| Protokollaufbewahrung | Aufbewahrungsrichtlinien-Dokument + Bestätigung, dass Protokolle für den Prüfzeitraum verfügbar sind | Mittel |
| Nur anbieterseitige Protokolle | OpenAI-Nutzungs-Dashboard, Anthropic-Aktivitätsprotokoll, Microsoft-Copilot-Audit-Protokoll | Schwach – nur ergänzend |
„Mittlere“ Nachweise beantworten die Frage, wenn sie mit anderen Nachweisen kombiniert werden. „Schwache“ Nachweise (Anbieterprotokolle allein) lösen typischerweise eine Folgeanfrage nach unabhängigen Kontrollnachweisen aus und können zu einer Management-Empfehlung führen, wenn sie der einzige verfügbare Nachweis sind.
Die AI-Governance-Schicht als SOC-2-Kontrolle
Wenn Sie dies für ein bevorstehendes Audit von Grund auf aufbauen, ist der schnellste Weg zur Beantwortung aller drei Bereiche die Bereitstellung einer dedizierten AI-Governance-Schicht:
- Inventar und Zugriff werden zu einem Nebenprodukt der Gateway-Konfiguration – jedes genehmigte Tool steht in der Richtlinie, und alles außerhalb der Richtlinie wird blockiert oder markiert.
- Durchsetzung der Datenverarbeitung ist eingebaut – das Gateway prüft Prompts und setzt Datenklassifizierungsregeln in Echtzeit durch.
- Audit-Trail ist die native Ausgabe des Gateways – ein strukturiertes, manipulationssicheres Protokoll jeder AI-Interaktion, das Sie kontrollieren und aufbewahren.
Dies ist auch das Nachweisformat, das Auditoren am überzeugendsten finden, weil es ein Nachweis auf Infrastrukturebene ist und nicht ein Dokumentationsnachweis. Ein Gateway-Protokoll ist ein Test der Wirksamkeit einer Kontrolle im Betrieb. Ein Richtliniendokument ist eine Richtlinie.
Für ein US-Scale-up, das ein SOC 2 Type II mit einem 12-monatigen Beobachtungszeitraum durchläuft, ist das Audit-Fenster der Zeitraum, in dem Sie Nachweise dafür benötigen, dass Ihre Kontrollen durchgängig wirksam waren – nicht nur, dass sie zum Zeitpunkt des Audits dokumentiert waren.
Qadar AI Shield ist für Teams konzipiert, die ein SOC 2 mit AI im Umfang durchlaufen: eingebautes AI-Aktivitäts-Logging, Durchsetzung von Richtlinien über Browser-, Desktop- und API-Zugriff hinweg und ein manipulationssicherer Audit-Trail, der die Nachweisanfragen der SOC-2-Feldarbeit erfüllt. Sehen Sie, wie es funktioniert.
