AVV für KI-Agenten: Was Ihr Standard-Vertrag nicht abdeckt
Warum klassische Auftragsverarbeitungsverträge für Enterprise-KI nicht reichen. Mit Anforderungskatalog als Checkliste für HR und Compliance.
Ein Auftragsverarbeitungsvertrag (AVV) für KI-Infrastruktur muss zehn Themen abdecken, die Standard-SaaS-AVVs nicht regeln: Prompt-Logging-Policies, Umgebungstrennung (Dev/Staging/Prod), Modell-Provider-Ketten, In-flight- vs. At-rest-Datenverarbeitung, RAG-Embedding-Datenschutz, Drittlandzugriffe auf Produktivdaten, §203-StGB-Kompatibilität, PII-Tokenisierung, Decision-Layer-Audit-Trails und Nachweisbarkeit technischer Maßnahmen.
Warum Standard-AVVs bei KI-Infrastruktur versagen
Ein klassischer Auftragsverarbeitungsvertrag regelt, wie ein Dienstleister personenbezogene Daten im Auftrag verarbeitet. Er definiert Zweck, Datenkategorien, technische und organisatorische Maßnahmen, Unterauftragsverarbeiter und Löschfristen. Für ein CRM-System oder eine HR-Software reicht das.
Bei Enterprise-KI-Infrastruktur entstehen Konstellationen, die kein Standard-AVV abbildet. Ein Sprachmodell verarbeitet Prompts - also Freitexteingaben, die potenziell alles enthalten können: Personaldaten, Mandanteninformationen, Geschäftsgeheimnisse, sogar besondere Kategorien nach Art. 9 DSGVO (EU AI Act verschärft diese Anforderungen zusätzlich), wenn ein Mitarbeitender eine medizinische Frage stellt. Die Daten fließen durch eine Kette von Systemen: vom Frontend über eine Orchestrierungsschicht zum Modell-Provider, zurück in eine Datenbank, möglicherweise durch eine RAG-Pipeline mit Embedding-Vektoren. An jeder Station stellen sich andere Fragen zu Speicherung, Zugriff und Löschung.
Wer einen KI-Vendor nach seinem AVV fragt und ein Standarddokument bekommt, sollte stutzig werden. Nicht weil der Vendor unseriös ist, sondern weil die spezifischen Risiken von KI-Infrastruktur andere Regelungen erfordern als die einer klassischen SaaS-Anwendung.
Die zehn Lücken zwischen Standard-AVV und KI-Realität
1. Prompt-Inhalte als neue Datenkategorie
Standard-AVVs listen Datenkategorien auf: Name, E-Mail, Personalnummer. Bei KI-Agenten kommt eine Kategorie hinzu, die sich nicht vorab definieren lässt - der Prompt. Ein Prompt kann eine harmlose Frage zur Urlaubsregelung sein oder ein vollständiger Mandantenbrief mit personenbezogenen Daten. Der AVV muss regeln, dass die Verantwortung für die Inhaltsklassifizierung beim Unternehmen liegt und der KI-Anbieter keine inhaltliche Vorabprüfung trifft. Gleichzeitig muss der Anbieter technische Maßnahmen nachweisen, die den Schutz aller eingegebenen Inhalte gewährleisten - unabhängig von deren Sensibilität.
2. Logging-Policy: Was darf in Logs stehen?
Bei klassischer Software wird geloggt, was technisch notwendig ist. Bei KI-Infrastruktur hat Logging eine andere Dimension: Werden Prompt-Inhalte geloggt? Werden Modellantworten gespeichert? Werden hochgeladene Dokumente in Fehlerlogs geschrieben?
Ein belastbarer AVV für KI-Infrastruktur muss explizit regeln, dass in der Produktivumgebung kein Request-/Response-Body-Logging stattfindet, dass ausschließlich technische Metadaten protokolliert werden (Statuscodes, Laufzeiten, Request-IDs), dass Debug-Logging in Produktion deaktiviert ist und dass Stacktraces keine Prompt- oder Dokumentinhalte enthalten. Das klingt selbstverständlich - ist es aber nicht. Fragen Sie Ihren Vendor nach seiner Logging-Policy für die Produktivumgebung. Wenn er keine hat, ist das ein Warnsignal.
3. Umgebungstrennung: Dev, Staging, Prod
Jedes Enterprise-Setup hat Entwicklungs-, Test- und Produktivumgebungen. Bei KI-Infrastruktur ist die Trennung sicherheitskritisch, weil in der Entwicklung echte Daten als Testdaten missbraucht werden können. Ein KI-spezifischer AVV muss festlegen, dass Dev und Staging ausschließlich synthetische oder anonymisierte Daten verwenden, dass der Produktivzugriff auf definierte Rollen in Deutschland/EWR beschränkt ist und dass Supportfälle nur mit vom Unternehmen freigegebenen Testdaten bearbeitet werden.
4. Modell-Provider-Kette statt klassischer Subdienstleister
Bei klassischer Software hat der Anbieter Unterauftragsverarbeiter: einen Hosting-Provider, vielleicht einen E-Mail-Dienst. Bei KI-Infrastruktur entsteht eine dreistufige Kette: Der KI-Infrastruktur-Anbieter betreibt die Plattform. Die Modell-Provider (Azure OpenAI, Google Vertex AI, Anthropic) verarbeiten die Prompts. Die Plattform-Provider (Supabase, Vercel) hosten Datenbank und Frontend.
Der entscheidende Punkt: Wer ist Vertragspartner der Modell-Provider? Laufen die Modelle im Tenant des KI-Anbieters oder im Tenant des Unternehmens? Dieser Unterschied bestimmt, ob der Modell-Provider Unterauftragsverarbeiter des Anbieters ist oder ob das Unternehmen selbst die Lieferantensteuerung übernimmt. Ein guter AVV klärt diese Abgrenzung explizit.
| Komponente | Im Tenant des Kunden | Im Tenant des Anbieters |
|---|---|---|
| Azure Entra ID (SSO) | ✓ Kunde | - |
| Azure OpenAI / Vertex AI | ✓ Kunde | - |
| Supabase (Datenbank) | ✓ Kunde | - |
| Vercel (Hosting) | ✓ Kunde | - |
| Plane (Ticketsystem) | - | ✓ Anbieter |
| GitHub (Code-Hosting) | - | ✓ Anbieter |
| Google Workspace (Kommunikation) | - | ✓ Anbieter |
Komponenten im Kundentenant werden vom Kunden in der eigenen Lieferantenakte geführt. Komponenten im Anbietertenant sind Gegenstand der Unterauftragsverarbeiterliste im AVV.
5. In-flight vs. at-rest: Wo bleiben die Daten?
Bei klassischer Software ist die Frage einfach: Daten liegen in einer Datenbank. Bei KI-Infrastruktur gibt es zwei Verarbeitungsmodi. In-flight-Verarbeitung: Der Prompt wird an den Modell-Provider gesendet, verarbeitet und die Antwort zurückgegeben. Keine persistente Speicherung beim Provider. At-rest-Speicherung: Chats, Uploads, Embeddings werden in einer Datenbank gespeichert (z.B. Supabase) - persistent und dem Nutzer zugeordnet.
Der AVV muss für beide Modi separate Regelungen treffen. Für in-flight: Ist die Content-Retention beim Provider deaktiviert? Werden die Daten zu Trainingszwecken verwendet? Für at-rest: Wo liegt die Datenbank? Wer hat Zugriff? Wie funktioniert Löschung?
6. RAG und Embeddings: Vektordaten als neue Herausforderung
Retrieval Augmented Generation (RAG) macht Unternehmensdokumente für KI durchsuchbar. Dabei werden Dokumente in Embedding-Vektoren umgewandelt und in einer Vektordatenbank gespeichert. Diese Vektoren sind eine neue Datenkategorie: Sie enthalten keine lesbaren Texte, können aber unter bestimmten Umständen Rückschlüsse auf den Originalinhalt ermöglichen. Der AVV muss Embeddings als personenbezogene Daten behandeln, sofern sie aus Dokumenten mit personenbezogenen Inhalten generiert werden. Zugriffssteuerung, Löschung und Mandantentrennung müssen auch für die Vektordatenbank gelten.
7. Drittlandzugriffe auf Produktivdaten
Viele KI-Anbieter arbeiten mit verteilten Teams. Wenn ein Entwickler aus einem Drittland Zugriff auf die Produktivumgebung hat, entsteht ein Datentransfer im Sinne der DSGVO - selbst wenn keine Daten physisch übertragen werden. Ein KI-spezifischer AVV muss definieren, dass Produktivzugriffe auf Deutschland/EWR beschränkt sind, dass Dev/Staging-Zugriffe aus Drittländern zulässig sind (weil nur synthetische Daten), dass RBAC (rollenbasierte Zugriffskontrolle) getrennte Admin-Gruppen für Prod und Dev/Staging vorsieht und dass ein Ausnahmeverfahren existiert, das schriftliche Freigabe durch den Verantwortlichen erfordert.
8. §203 StGB: Berufsgeheimnisse in der KI-Plattform
Für regulierte Branchen - Anwaltskanzleien, Steuerberater, Wirtschaftsprüfer, aber auch Unternehmen mit berufsgeheimnisrelevanten Prozessen - gilt: Mandats- und Berufsgeheimnisse dürfen nur verarbeitet werden, wenn der AVV explizite Regelungen enthält. Der Auftragsverarbeiter muss alle Mitarbeitenden und Freelancer schriftlich zur Vertraulichkeit verpflichten, Verpflichtungserklärungen inkl. Belehrung nach §203 StGB müssen vorliegen und auf Anfrage nachweisbar sein. Standardklauseln zur Vertraulichkeit reichen hier nicht.
9. PII-Tokenisierung als optionales Modul
Eingangs- und Ausgangsfilter, die personenbezogene Daten erkennen und vor der Weiterleitung an den Modell-Provider pseudonymisieren, sind eine zusätzliche Schutzschicht. Diese PII-Tokenisierung ist nicht in jedem Setup notwendig, aber der AVV sollte sie als optionales Modul vorsehen. Wichtig: Wenn eine reversible Re-Identifizierung möglich ist, muss der AVV regeln, wer Zugriff auf die Zuordnungstabelle hat, wie Mapping-Keys gespeichert und verschlüsselt werden und dass Re-Identifizierung nur zweckgebunden nach dokumentierter Freigabe erfolgt.
10. Audit-Trail und Decision Layer
KI-Agenten treffen oder bereiten Entscheidungen vor. Jede dieser Entscheidungen muss nachvollziehbar sein - nicht nur für den Datenschutz, sondern auch für interne Revision, Wirtschaftsprüfung und Betriebsratsrechte. Der Decision Layer zerlegt jeden Prozess in einzelne Entscheidungsschritte und definiert für jeden Schritt: Mensch, Regelwerk oder KI. Der AVV muss den Audit-Trail als Vertragsbestandteil verankern: Welche Daten werden pro Entscheidung geloggt? Wie lange werden sie aufbewahrt? Wer hat Zugriff?
Die Checkliste: 25 Fragen an Ihren KI-Vendor
Die folgende Checkliste fasst die zehn Lücken in konkrete Prüffragen zusammen.
Anforderungskatalog ansehen: 25 Prüffragen für KI-AVVs →
A - Datenkategorien und Verarbeitungszwecke
- Sind Prompt-Inhalte und Modellantworten als eigenständige Datenkategorie im AVV aufgeführt?
- Ist geregelt, wer die Verantwortung für die Inhaltsklassifizierung trägt (Unternehmen, nicht Anbieter)?
- Sind Embeddings/Vektoren als potenziell personenbezogene Daten klassifiziert?
- Enthält der AVV eine Regelung für besondere Kategorien nach Art. 9 DSGVO, die durch Nutzereingaben entstehen können?
B - Logging und Monitoring
- Ist Request-/Response-Body-Logging in der Produktivumgebung deaktiviert?
- Welche Metadaten werden protokolliert (Statuscodes, Laufzeiten, Request-IDs)?
- Ist Debug-Logging in Produktion nachweisbar deaktiviert?
- Werden Stacktraces und Fehlermeldungen so konfiguriert, dass keine Inhaltsdaten in Logs gelangen?
- Ist die Prüfung der Logging-Einstellungen Bestandteil des Release-Prozesses?
C - Umgebungstrennung und Zugriff
- Existieren getrennte Umgebungen (Dev, Staging, Prod) mit unterschiedlichen Datenpolicies?
- Enthalten Dev/Staging ausschließlich synthetische oder anonymisierte Daten?
- Ist der Produktivzugriff auf autorisierte Rollen in Deutschland/EWR beschränkt?
- Gibt es ein dokumentiertes Ausnahmeverfahren für Supportfälle mit Datenbezug?
D - Modell-Provider und Subdienstleister
- Ist die Abgrenzung klar: Welche Provider sind Unterauftragsverarbeiter des Anbieters, welche laufen im Tenant des Unternehmens?
- Ist Content-Retention bei den Modell-Providern deaktiviert?
- Ist der Ausschluss der Nutzung zu Trainingszwecken vertraglich dokumentiert?
- Wo liegen die Modell-Endpunkte (EU-Region, US, andere)?
E - Datenspeicherung und Löschung
- Ist geregelt, wo persistente Inhaltsdaten gespeichert werden (Datenbank, Region, Provider)?
- Welche Backup-Retention gilt und wie wird mit gelöschten Daten in Backups umgegangen?
- Kann der einzelne Nutzer seine Daten in der Anwendung selbst löschen?
F - Regulierte Branchen
- Enthält der AVV eine Regelung zur §203-StGB-Kompatibilität (oder landesspezifischem Äquivalent)?
- Liegen Vertraulichkeitsverpflichtungen für alle mitwirkenden Personen vor?
- Ist PII-Tokenisierung als optionales Modul vorgesehen?
G - Governance und Nachweisbarkeit
- Ist ein Audit-Trail für Agenten-Entscheidungen als Vertragsbestandteil verankert?
- Ist der Nachweis der TOMs auf Anfrage möglich (Konfigurationsnachweise, geschwärzte Logauszüge)?
Von der Checkliste zur Architektur
Diese 25 Fragen sind kein juristisches Werkzeug. Sie sind ein Architektur-Kompass. Jede Frage, die Ihr KI-Vendor nicht beantworten kann, zeigt eine Lücke in seiner Infrastruktur - nicht nur in seinem Vertrag.
Bei Gosign haben wir diese Anforderungen in die Architektur eingebaut: Umgebungstrennung mit Prod-Lockdown, Logging ohne Inhaltsdaten, Modell-Provider im Kundentenant, Decision Layer mit vollständigem Audit-Trail. Nicht weil ein Kunde es verlangt hat, sondern weil Enterprise-KI ohne diese Grundlagen nicht auditierbar ist.
Wenn Sie prüfen möchten, wie Ihre aktuelle KI-Infrastruktur gegen diese 25 Punkte abschneidet - oder wenn Sie eine neue Plattform evaluieren - sprechen wir gerne darüber.