Wie hosten KMU eine KI-App datenschutzkonform?

Wer eine KI-Funktion in seine App oder sein Produkt einbaut, kommt schnell zu einem Punkt, den viele unterschätzen: Sobald Nutzerdaten verarbeitet werden, greift die DSGVO — nicht erst wenn die App groß ist, sondern ab dem ersten produktiven Request. Viele KMU merken das zu spät: Die App ist live, der Hosting-Vertrag unterschrieben, und dann kommt die Frage des Datenschutzbeauftragten. Dieser Artikel erklärt, was vor dem Deployment zu klären ist.

Kurze Antwort

Damit eine KI-App die DSGVO-Anforderungen erfüllt, braucht es drei Dinge gleichzeitig: ein Rechenzentrum im Europäischen Wirtschaftsraum (EWR), einen unterzeichneten AVV mit dem Hosting-Anbieter — und einen AVV mit dem KI-Modell-Anbieter, der KI-Training mit Kundendaten explizit ausschließt. Wer bei einem US-amerikanischen Anbieter hostet, muss zusätzlich den Cloud Act berücksichtigen und die Transfer-Grundlage dokumentieren.

Wo entstehen DSGVO-Risiken in einer KI-App?

Eine KI-App verarbeitet Daten an mindestens drei Stellen — und jede davon hat eigene DSGVO-Anforderungen.

1. Der KI-Modell-Anbieter (API)

Die meisten KI-Apps senden Nutzereingaben an eine externe KI-API — OpenAI, Anthropic, Google oder ähnliche. Sobald diese Eingaben personenbezogene Daten enthalten (Namen, E-Mail-Adressen, Beschreibungen realer Situationen), wird der Anbieter zum Auftragsverarbeiter. Ein AVV ist dann erforderlich, sofern der Anbieter als Auftragsverarbeiter tätig wird. Der entscheidende Punkt: Prüfen, ob der AVV KI-Training mit Kundendaten explizit ausschließt — viele Standard-Verträge tun das nicht automatisch.

2. Der Hosting-Anbieter (Server)

Auf dem Server laufen Backend, Datenbank und Logs. Auch dort werden personenbezogene Daten verarbeitet — Nutzer-IDs, IP-Adressen, Request-Logs. Ohne AVV mit dem Hosting-Anbieter fehlt die rechtliche Grundlage für diese Verarbeitung.

3. Logs und gespeicherte Nutzeranfragen

KI-Apps erzeugen oft umfangreiche Logs: Wer hat was gefragt, wann, mit welchem Ergebnis. Diese Logs sind datenschutzrechtlich relevant. Speicherdauer, Zugriffsbeschränkung und Löschkonzept müssen von Anfang an mitgeplant werden — nicht nachträglich.

EU-Serverstandort: Was er löst — und was nicht

Der EU-Serverstandort ist eine Grundbedingung, aber kein Freifahrtschein.

Ein Rechenzentrum in Frankfurt, Amsterdam oder Paris stellt sicher, dass Daten den EWR physisch nicht verlassen. Das ist die Mindestvoraussetzung und schließt viele Anbieter aus, die ausschließlich US-Rechenzentren betreiben.

Was der EU-Standort nicht löst: Wenn der Hosting-Anbieter ein US-amerikanisches Unternehmen ist, unterliegt er dem CLOUD Act. US-Behörden können unter bestimmten Voraussetzungen Zugriff auf Daten verlangen — unabhängig davon, wo der Server physisch steht. Ein Rechenzentrum in Frankfurt ändert daran nichts, wenn das Unternehmen in den USA registriert ist.

Das schließt US-Anbieter nicht automatisch aus. Seit 2023 gibt es mit dem Data Privacy Framework (DPF) eine Transfer-Grundlage für zertifizierte US-Unternehmen. Wer einen US-Anbieter nutzt, sollte die DPF-Zertifizierung prüfen und eine TIA (Transfer Impact Assessment) durchführen und dokumentieren — Datenschutzberater empfehlen das auch bei DPF-zertifizierten Anbietern.

Faustregel: EU-Unternehmen als Hosting-Anbieter bedeutet den geringsten Dokumentationsaufwand. US-Unternehmen mit EU-Rechenzentrum sind möglich, erfordern aber mehr Sorgfalt bei der Transfer-Dokumentation.

Was ein AVV wirklich abdeckt

Der Auftragsverarbeitungsvertrag ist kein Allheilmittel — er ist ein Vertrag, der die Spielregeln festlegt.

Was der AVV regelt:

Der Anbieter verarbeitet Daten nur nach Weisung des Verantwortlichen
Der Anbieter muss Daten nach Vertragsende löschen oder zurückgeben
Der Anbieter muss technische und organisatorische Maßnahmen nachweisen
Unterauftragsverarbeiter (Subprocessors) müssen gelistet und genehmigt sein

Was der AVV nicht regelt:

Er verhindert keinen behördlichen Zugriff nach CLOUD Act
Er schützt nicht vor Sicherheitslücken im eigenen Anwendungscode
Er ersetzt keine Datenschutz-Folgenabschätzung (DSFA) bei besonders risikoreichen Verarbeitungen

Der wichtigste Punkt für KI-Apps: Viele Standard-AVVs von KI-Anbietern schließen Modell-Training nicht explizit aus — oder nur wenn eine bestimmte Option aktiv aktiviert wird. Einige Anbieter bieten Zero-Data-Retention-Optionen an. Diese müssen aktiv konfiguriert werden und sollten im AVV schriftlich fixiert sein.

Checkliste vor dem ersten Deployment

Vor dem ersten produktiven Betrieb einer KI-App sollte Folgendes abgehakt sein:

EU-Rechenzentrum bestätigt — Serverstandort in der Anbieter-Dokumentation geprüft, nicht nur in der Marketing-Aussage
AVV mit Hosting-Anbieter — unterschrieben, aktuell, Subprocessor-Liste vorhanden
AVV mit KI-Modell-Anbieter — enthält expliziten Ausschluss von KI-Training mit Kundendaten
Cloud-Act-Prüfung — bei US-Anbietern: DPF-Zertifizierung geprüft, TIA dokumentiert
Log-Konzept — Speicherdauer, Löschfristen und Zugriffsbeschränkung festgelegt
Datenschutzerklärung aktualisiert — KI-Verarbeitung, eingesetzte Anbieter und Verarbeitungszweck genannt
Datenschutzbeauftragter eingebunden — bei systematischer Verarbeitung oder Verarbeitung sensibler Daten

Welche Hosting-Anbieter eignen sich aus DSGVO-Sicht?

Eine Auswahl an Hosting-Anbietern mit EU-Rechenzentren und verfügbarem AVV (Stand: 2026-06, Angaben laut Anbieter-Dokumentation):

Anbieter	Hauptsitz	EU-Rechenzentrum	Cloud-Act-Risiko	AVV verfügbar
Hetzner	Deutschland	Nürnberg, Falkenstein, Helsinki	Nein (EU-Muttergesellschaft)	Ja (laut Anbieter)
OVHcloud	Frankreich	Straßburg, Roubaix u.a.	Nein (EU-Muttergesellschaft)	Ja (laut Anbieter)
Ionos	Deutschland	Deutschland	Nein (EU-Muttergesellschaft)	Ja (laut Anbieter)
DigitalOcean	USA	Frankfurt (FRA1)	Ja — DPF-zertifiziert, TIA empfohlen	Ja (laut Anbieter)

Angaben ohne Gewähr — AVV-Bedingungen, Serverstandorte und DPF-Zertifizierungen können sich ändern. Immer die aktuelle Dokumentation des jeweiligen Anbieters prüfen.

Warum fehlen AWS, Azure und Google Cloud?

AWS, Azure und Google Cloud betreiben alle EU-Rechenzentren — in Frankfurt, Amsterdam, Stockholm und weiteren Standorten. Technisch sind sie als Hosting-Plattform nutzbar. Als US-amerikanische Unternehmen unterliegen sie jedoch dem Cloud Act, was den Dokumentationsaufwand erhöht:

Alle drei sind DPF-zertifiziert; eine TIA und dokumentierte Risikoentscheidung werden von Datenschutzberatern trotzdem empfohlen
Microsoft Azure bietet mit dem Azure OpenAI Service die Möglichkeit, KI-Modelle direkt in EU-Rechenzentren zu betreiben — für KMU, die bereits Microsoft-Infrastruktur nutzen, eine prüfenswerte Option
Der Zusatzaufwand für Transfer-Dokumentation ist für KMU ohne eigenen Datenschutzberater schwer zu leisten

Für KMU ohne dedizierten Datenschutzberater sind EU-ansässige Anbieter (Hetzner, OVHcloud, Ionos) der Pfad mit dem geringsten Dokumentationsaufwand.

KI-Modell-Anbieter: AVV und Datenschutz

Neben dem Hosting-Anbieter braucht es auch mit dem KI-Modell-Anbieter (API) einen AVV. Die drei am häufigsten genutzten Anbieter im Überblick (Stand: 2026-06, Angaben laut Anbieter-Dokumentation):

Anbieter	AVV verfügbar	Training-Opt-out (API)	EU-Serverstandort
OpenAI	Ja (DPA abrufbar)	API: kein Training by default	Nein (Azure OpenAI als Alternative)
Anthropic	Ja (DPA abrufbar)	API: kein Training by default	Nein (AWS Bedrock EU als Alternative)
Google (Gemini)	Ja (Google Cloud DPA)	Enterprise: konfigurierbar	Ja (Vertex AI, EU-Regionen)

Hinweis: “Kein Training by default” für API-Nutzer bedeutet, dass diese Einstellung aktiv in der Anbieter-Dokumentation geprüft werden sollte — Vertragsbedingungen können sich ändern. Bei der Vertragsprüfung im Rahmen des AVV-Prozesses sollte der Training-Ausschluss schriftlich festgehalten werden.

Angaben ohne Gewähr — AVV-Bedingungen und Training-Richtlinien können sich ändern. Immer die aktuelle Dokumentation beim jeweiligen Anbieter prüfen.

Häufig gestellte Fragen

Brauche ich einen AVV, wenn ich nur die OpenAI-API nutze? Ja — sofern Nutzerdaten an die API übermittelt werden, auch indirekt über Kontext in Prompts. OpenAI stellt ein Data Processing Agreement (DPA) bereit, das als AVV gilt. Es muss aktiv abgeschlossen werden, und die Einstellungen für Training-Opt-out sollten geprüft werden.

Ist Azure OpenAI datenschutzrechtlich anders zu bewerten als die direkte OpenAI-API? Aus DSGVO-Sicht ja — mit Azure OpenAI lassen sich KI-Modelle in EU-Rechenzentren von Microsoft betreiben, mit einem Microsoft-AVV. Das Cloud-Act-Risiko bleibt bestehen, da Microsoft ein US-Unternehmen ist, lässt sich aber mit DPF-Zertifizierung und TIA-Dokumentation adressieren. Für Unternehmen, die bereits Microsoft-Produkte nutzen und bestehende Datenschutzverträge mit Microsoft haben, ist Azure OpenAI eine prüfenswerte Alternative zur direkten OpenAI-API.

Ist Hetzner aus DSGVO-Sicht vorteilhafter als ein US-Anbieter mit EU-Rechenzentrum? Aus Datenschutzsicht ja — der Hauptunterschied ist der CLOUD Act. Als deutsches Unternehmen unterliegt Hetzner nicht der US-Strafverfolgungsjurisdiktion. Ein US-Anbieter mit Frankfurter Rechenzentrum ist nicht ausgeschlossen, erfordert aber mehr Dokumentation: DPF-Prüfung, TIA und ggf. Abstimmung mit dem Datenschutzbeauftragten.

Was ist eine TIA und muss ich das wirklich machen? Eine Transfer Impact Assessment prüft, ob Daten bei einem Transfer in ein Drittland ausreichend geschützt sind. Bei US-Anbietern empfehlen viele Datenschutzberater eine dokumentierte TIA — auch wenn der Anbieter DPF-zertifiziert ist. Der Aufwand ist überschaubar, wenn der Anbieter eigene TIA-Unterlagen bereitstellt.

Muss ich für die OpenAI-API eine TIA durchführen? Das hängt davon ab, ob personenbezogene Daten an die API übermittelt werden. Wenn ja, handelt es sich um eine Drittlandübermittlung in die USA, für die eine Transfer-Grundlage (z.B. DPF-Zertifizierung) und nach Empfehlung vieler Datenschutzberater eine TIA-Dokumentation sinnvoll ist. OpenAI stellt Unterlagen zur Transfer-Dokumentation bereit — diese sollten im Rahmen des AVV-Prozesses geprüft und intern festgehalten werden.

Reicht es, wenn ich keine sensiblen Daten verarbeite? Nein. Die DSGVO gilt für alle personenbezogenen Daten — also auch für Namen, E-Mail-Adressen oder IP-Adressen. Besonders schützenswerte Daten nach Art. 9 DSGVO erfordern zusätzliche Maßnahmen, aber die Grundanforderungen gelten unabhängig davon.

Muss ich Nutzer informieren, dass eine KI ihre Daten verarbeitet? Ja. Die Datenschutzerklärung muss die KI-Verarbeitung, den eingesetzten Anbieter und den Verarbeitungszweck nennen. Wenn KI-Ausgaben für automatisierte Entscheidungen mit rechtlicher oder wesentlicher Wirkung genutzt werden, können zusätzlich Informationspflichten nach Art. 22 DSGVO greifen.

Was ist, wenn mein Entwickler sagt “das macht der Anbieter schon”? Das ist die häufigste Fehleinschätzung. Die DSGVO-Verantwortung liegt beim Verantwortlichen — also beim Unternehmen, das die App betreibt, nicht beim Hoster. Der AVV überträgt dem Anbieter bestimmte Pflichten, aber die Auswahl des Anbieters und die Prüfung seiner Eignung bleibt Aufgabe des Unternehmens.

Fazit

Eine KI-App datenschutzkonform zu betreiben ist kein Hexenwerk — aber es erfordert, drei Dinge gleichzeitig im Blick zu haben: Serverstandort, AVV und Cloud-Act-Risiko. Wer von Anfang an auf einen EU-Anbieter setzt und beide AVVs korrekt abschließt (Hosting und KI-Modell), hat die größten Risiken abgedeckt. Der häufigste Fehler ist, diese Fragen erst nach dem Launch zu stellen. Die Checkliste in diesem Artikel ist dafür gedacht, genau das zu verhindern.

Weiterführende Lexikon-Artikel

Passende Tooltests