Firmendaten und KI: Auftragsverarbeitungsvertrag und Rechtsgrundlage

Ein Unternehmen implementiert einen KI-Assistenten für den Kundenservice. Das Modell beantwortet Fragen, zitiert Verfahren aus einer internen Wissensdatenbank und sieht dabei manchmal den Namen und die Bestellnummer des Kunden. Die rechtliche Frage stellt sich nach einer Woche Nutzung – nicht vor der Implementierung: Haben wir einen Vertrag mit dem Modellanbieter unterzeichnet? Die Antwort „Wir wissen es nicht“ ist die häufigste Lücke, die wir bei Audits finden. Diese Lücke gibt es nicht in Systemen, die von der ersten Codezeile an mit Compliance im Blick designed werden.

Die RODO unterscheidet zwischen dem Verantwortlichen (entscheidet über Zwecke und Mittel der Verarbeitung) und dem Auftragsverarbeiter (verarbeitet Daten ausschließlich im Auftrag des Verantwortlichen). Ihr Unternehmen ist der Verantwortliche für die Daten Ihrer Kunden und Mitarbeiter. Der KI-Anbieter, der diese Daten erhält, um den Service durchzuführen, ist der Auftragsverarbeiter.

Art. 28 RODO besagt klar: Jede solche Auftragsverarbeitung muss durch einen Vertrag oder ein anderes rechtliches Instrument dokumentiert werden, das Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der Daten, Kategorien betroffener Personen sowie Pflichten und Rechte des Verantwortlichen festlegt.

Die Verpflichtung entsteht, wenn ein externer Dienstleister im Auftrag Ihres Unternehmens Zugang zu personenbezogenen Daten hat. Im KI-Kontext betrifft dies konkret:

• Anbieter von Sprachmodellen (Cloud-APIs), die den Inhalt von Prompts mit Nutzerdaten sehen.
• Automatisierungsplattformen (n8n in der Cloud, Make, Zapier), über die Daten aus CRM oder E-Mails fließen.
• Infrastruktur-Anbieter (AWS, Azure, GCP), auf denen Ihr KI-System läuft und wo Konversations-Logs gespeichert werden.
• Implementierungspartner (wie wir), die während der Konfiguration, Tests und Wartung Zugang zu den Daten haben.

Ein Vertrag ist nicht erforderlich, wenn ein externer Dienstleister die Daten als eigenständiger Verantwortlicher verarbeitet (z. B. eine Bank, die eine Zahlung abwickelt) oder wenn die Daten Ihre Infrastruktur nie verlassen (Self-Hosted-Architektur, lokale Modelle).

Ein standardmäßiger DPA enthält die von Art. 28 RODO geforderten Abschnitte. Bei KI-Implementierungen kommen Klauseln hinzu, die in Vorlagen aus der Zeit vor den Sprachmodellen fehlen.

Die Klausel „Verbot des Trainings mit Kundendaten“ ist ein Punkt, der seriöse KI-Anbieter von denen unterscheidet, die Ihre Daten in ein globales Modell aufnehmen. Bei Cloud-APIs bieten viele Anbieter eine solche Klausel in Enterprise-Verträgen an – standardmäßig ist es jedoch oft umgekehrt. Prüfen Sie immer die API-Bedingungen vor dem ersten produktiven Request.

Der KI-Modellanbieter ist nicht immer ein Auftragsverarbeiter. Die Grenze hängt davon ab, ob und wie er Ihre Daten für eigene Zwecke nutzen kann.

Reiner Auftragsverarbeiter (DPA reicht aus): Der Anbieter führt das Modell ausschließlich in Ihrem Auftrag aus, nutzt die Daten nicht für eigene Zwecke, trainiert nicht damit und speichert sie nicht über die vereinbarte TTL hinaus.

Gemeinsam Verantwortlicher (Vertrag über gemeinsame Verantwortlichkeit nach Art. 26 RODO erforderlich): Der Anbieter hat ein eigenes Interesse an den Daten, z. B. führt er eigene Analysen auf den Abfragen durch, entwickelt damit Produkte oder profiliert Ihre Nutzer. Diese Situation ist bei KI-Modellen seltener, aber bei SaaS-Plattformen mit integrierter KI möglich.

Eigenständig Verantwortlicher: Der Anbieter verarbeitet die Daten für eigene, unabhängige Zwecke, Ihr Vertrag umfasst ihn nicht. In diesem Fall verlangt die RODO, dass Sie die betroffenen Personen darüber informieren, dass ihre Daten an diesen Dienstleister weitergegeben werden, der selbst die Zwecke festlegt.

In der Praxis sind die meisten Enterprise-APIs von Sprachmodellen Auftragsverarbeiter – weshalb der DPA seit 2023 ein Standardbestandteil von IT-Ausschreibungen ist.

Sprachmodelle laufen oft auf Servern außerhalb Europas. Die Übermittlung personenbezogener Daten in den Europäischen Wirtschaftsraum (EWR) ist zulässig, erfordert jedoch eine rechtliche Grundlage: Standardvertragsklauseln (SCCs), Angemessenheitsbeschlüsse oder verbindliche Unternehmensregeln (BCRs).

In der Praxis müssen Sie bei der KI-Implementierung:

1. Identifizieren, wo die Daten physisch verarbeitet werden (Serverregion des API-Anbieters).
2. Prüfen, ob der Anbieter SCCs anbietet oder in einer Region mit Angemessenheitsbeschluss operiert (z. B. EWR, Großbritannien, Japan).
3. Die Grundlage der Übermittlung im Verzeichnis der Verarbeitungstätigkeiten (VVT) dokumentieren.
4. Überlegen, ob Data-Residency in der EU (vertraglich erzwungen oder durch Self-Hosting) das Übermittlungsproblem eliminiert.

Eine Self-Hosted-Architektur mit lokalem Modell und lokaler Vektordatenbank (Qdrant, BGE-M3) beseitigt die Frage der Übermittlung, da personenbezogene Daten Ihre Infrastruktur nie verlassen. Dies ist besonders relevant für Unternehmen mit sensiblen Daten: Kanzleien, medizinische Einrichtungen, Fintechs.

Rechtliche Compliance und technische Compliance sind zwei Seiten derselben Medaille. Der Auftragsverarbeitungsvertrag gibt den rechtlichen Rahmen vor, aber das System muss ihn technisch umsetzen. Konkret:

Maskierung von PII vor dem Modell. Bevor ein Text mit personenbezogenen Daten an den LLM geht, maskiert unser Router sensible Variablen (Namen, Nummern, E-Mails). Das Modell sieht [NAME] statt „Jan Kowalski“. Wenn die Antwort diese Daten nicht benötigt, erhält das Modell sie nicht.

Zero-Retention auf Modellseite. Bei Cloud-APIs wählen wir Endpunkte mit bestätigter Zero-Retention-Policy für Prompts. Bei lokaler Architektur verlassen die Daten den Server nicht. Guardrails blockieren Antworten, die Daten enthalten, nach denen das Modell nicht gefragt werden sollte.

TTL für Logs. Konversations-Logs (für Debugging und Qualitätsaudits benötigt) haben eine definierte Lebensdauer und ein Purge-Verfahren. Personen können die Löschung ihrer Daten verlangen – das System unterstützt dies End-to-End, einschließlich Vektoren in der Datenbank und Logs.

Human-Gate für irreversible Aktionen. KI-Agenten, die E-Mails versenden, Dokumente erstellen oder Daten modifizieren können, durchlaufen eine menschliche Bestätigung. Keine Aktion, die personenbezogene Daten betrifft, ist vollständig autonom ohne explizit definierten Umfang. Dies ist eine technische Anforderung, die die menschliche Aufsicht aus dem AI Act stärkt.

Mehr zur Sicherheitsarchitektur von KI-Agenten im Artikel Sicherheit von KI-Agenten.

AI Act und RODO sind zwei unterschiedliche Regime, die sich im Bereich Daten überschneiden. Der AI Act fügt Verträgen mit KI-Anbietern zusätzliche Elemente hinzu:

• Technische Dokumentation des Systems – Der Anbieter eines Hochrisiko-Systems muss diese bereitstellen. Für Niedrigrisiko-Systeme reicht Transparenz.
• Register – Hochrisiko-Systeme erfordern eine Registrierung in der EU-Datenbank und Risikomanagement-Dokumentation.
• DPIA – Wenn das KI-System profiliert, bewertet oder automatisierte Entscheidungen über Menschen trifft, verlangt die RODO eine Folgenabschätzung, und der AI Act eine Risikoanalyse. In der Praxis: Ein Dokument, das beide Anforderungen abdeckt.

Im Vertrag mit dem KI-Anbieter sollte explizit festgehalten werden, welches Risikoniveau der AI Act für das System vorsieht, wer für die technische Dokumentation verantwortlich ist und wie KI-Sicherheitsvorfälle behandelt werden. Ohne diese Angaben ist es für den Verantwortlichen (Sie) schwierig, die Compliance bei einer möglichen Kontrolle nachzuweisen.

Eine detaillierte Erläuterung des AI Act für Unternehmen, die KI in Polen implementieren, finden Sie im Artikel AI Act und RODO 2026.

Bevor Sie einen Vertrag mit einem Anbieter von Modellen, Plattformen oder Infrastruktur unterzeichnen:

• Bietet der Anbieter einen DPA gemäß Art. 28 RODO an? (Falls nicht – verzichten oder Daten anonym verarbeiten.)
• Enthält der Vertrag eine Klausel, die das Training mit Ihren Daten verbietet?
• Sind die Verarbeitungsregionen und die Grundlage für die Übermittlung außerhalb des EWR festgelegt?
• Gibt es eine Liste der Unterauftragsverarbeiter mit der Pflicht, über Änderungen zu informieren?
• Sind TTL für Logs und das Purge-Verfahren präzise festgelegt?
• Ist geregelt, wie der Anbieter Anfragen von Personen (Zugriff, Löschung) bearbeitet?
• Haben Sie im Falle eines Vorfalls das Recht auf einen Bericht innerhalb von 72 Stunden (RODO-Anforderung)?

Wenn Ihr Vertrag all diese Punkte enthält, haben Sie eine solide Grundlage. Falls nicht – lohnt es sich, dies vor dem Produktionsstart zu ergänzen, nicht erst nach der ersten Anfrage der Aufsichtsbehörde.

Die Bereitschaft Ihrer Organisation in Bezug auf Daten und Compliance können Sie vorab mit der KI-Bereitschaftsbewertung prüfen oder die Kosten einer geeigneten Architektur mit dem ROI-Rechner berechnen. Details zur Architektur besprechen wir im kostenlosen Pilotprojekt.

Beschreiben Sie Ihren KI-Implementierungsfall, und das Modell zeigt auf, welche Elemente des Auftragsverarbeitungsvertrags kritisch sind und worauf Sie bei der Auswahl des Anbieters achten sollten. Dies ist der Ausgangspunkt für die Überprüfung mit einem Anwalt, keine Rechtsberatung. PII werden vor dem Modell maskiert, Zero-Retention.

Die Verpflichtung entsteht, wenn ein externer Dienstleister mit personenbezogenen Daten in Kontakt kommt und diese ausschließlich in Ihrem Auftrag verarbeitet. In der KI-Praxis: wenn die API eines Sprachmodells, eine Automatisierungsplattform oder ein Hosting-Anbieter Inhalte mit Daten Ihrer Kunden oder Mitarbeiter sieht. Das Fehlen eines DPA in dieser Situation ist ein Verstoß gegen Art. 28 RODO – unabhängig davon, ob ein Vorfall überhaupt aufgetreten ist.

Die meisten großen API-Anbieter haben DPAs in ihren Enterprise-Programmen verfügbar. Das Problem liegt darin, dass die Standardbedingungen für Verbraucher oder kostenlose Tarife oft keine DPAs enthalten oder Klauseln, die das Training mit den Daten erlauben. Bevor Sie eine produktive API mit personenbezogenen Daten nutzen, sollten Sie den DPA vom Anbieter anfordern und unterzeichnen – gehen Sie nicht davon aus, dass die Standard-ToS ausreichen.

Ja, in Bezug auf das Modell und die Infrastruktur, die vollständig unter Ihrer Kontrolle steht. Wenn das Sprachmodell, die Vektordatenbank und die Konversations-Logs auf Ihren Servern laufen und keine personenbezogenen Daten Ihr Netzwerk verlassen, gibt es keinen Auftragsverarbeiter, dem Sie Daten anvertrauen müssen. Ein Auftragsverarbeitungsvertrag ist jedoch weiterhin mit dem Implementierungspartner erforderlich, der während der Installation und Wartung Zugang zum System hat. Mehr zur Self-Hosting-Architektur.

Das hängt von der Architektur ab. Generative Modelle „merken“ sich keine Konversationen zwischen den Sessions, aber API-Anbieter können Prompt-Logs bis zu 30 Tage (oder länger) für Debugging und Sicherheit speichern. Im Auftragsverarbeitungsvertrag sollte die TTL der Logs und der Mechanismus zu deren Löschung festgelegt sein. Bei einem lokalen LLM und Zero-Retention auf Modellseite verlassen die Konversationsdaten Ihre Infrastruktur nicht. Vektoren von Embeddings in der Vektordatenbank sind eine separate Ressource, die eine eigene Retentions- und Purge-Policy erfordert.

Nicht immer. Eine DPIA ist erforderlich, wenn die Verarbeitung ein hohes Risiko für die Rechte der betroffenen Personen darstellen kann: Profiling in großem Umfang, Verarbeitung sensibler Daten, automatisierte Entscheidungen über Menschen. Ein Assistent, der nur Fragen aus Ihrer Wissensdatenbank beantwortet und keine Nutzer profiliert, erfordert in der Regel keine DPIA. Ein Assistent, der Stimmungen von Kunden bewertet, sie kategorisiert oder basierend auf Profilen unterschiedliche Pfade vorschlägt, wahrscheinlich