DSGVO-konforme KI im Mittelstand — Architektur-Leitfaden

Was bedeutet das für Ihr Unternehmen?

Sie wollen KI im Alltag einsetzen — Belege auslesen, Helpdesk-Anfragen vorsortieren, Routine-Mails beantworten. Aber im Raum steht die Frage: „Dürfen wir das überhaupt? Was sagt der Datenschutz?”

Die kurze Antwort: Ja, wenn Sie es richtig aufsetzen. Drei Punkte müssen passen — wer Ihre Daten verarbeitet, wo Ihre Daten liegen, und warum Sie das tun dürfen. Wenn diese drei Punkte sauber geklärt sind, ist KI im Mittelstand DSGVO-konform machbar — und zwar ohne Anwalts-Marathon.

Diesen Artikel sollten Sie weiterlesen, wenn Sie die drei Punkte selbst durchgehen oder Ihrem Datenschutzbeauftragten eine fundierte Vorlage geben wollen. Wir gehen jeden Punkt mit den genauen Vertrags-Klauseln und Anbieter-Empfehlungen durch, die wir aus über 400 Mittelstands-Projekten kennen. Wer einen kürzeren Weg sucht: ein 30-minütiges Erstgespräch mit uns ist meist schneller.

TL;DR — DSGVO + KI ist Architektur, kein Verbot

KI-Agenten im Mittelstand DSGVO-konform zu betreiben ist 2026 keine Frage des „Ob”, sondern des „Wie”. Die Architektur entscheidet — drei Säulen müssen stimmen: Auftragsverarbeitungsvertrag (AVV) mit dem KI-Anbieter, EU-Daten-Residenz für die Verarbeitung, dokumentierte Rechtsgrundlage beim Mandanten. Wenn diese drei Säulen sauber sind, sind 80 % der typischen Mittelstands-KI-Use-Cases unkritisch.

Was komplex ist, ist nicht die DSGVO selbst — es ist die Auswahl-Logik zwischen den Plattform-Patterns. Wir bauen seit 2023 KI-Agenten produktiv für deutsche Mittelständler ein und schreiben hier auf, welche Setup-Patterns funktionieren, wo die häufigsten Fehler passieren, und wie eine saubere Architektur aussieht.

Die drei Säulen einer DSGVO-konformen KI-Architektur

Säule 1 — Auftragsverarbeitungsvertrag (AVV) mit dem KI-Anbieter

Sobald die KI personenbezogene Daten verarbeitet (was bei jedem Helpdesk-, CRM-, oder E-Mail-Use-Case automatisch der Fall ist), greift Art. 28 DSGVO: ein schriftlicher Auftragsverarbeitungsvertrag zwischen Mandant und KI-Anbieter ist Pflicht.

Was muss im AVV stehen:

• Was verarbeitet wird — z.B. „Texte aus Helpdesk-Tickets für Klassifikation”
• Wo verarbeitet wird — physische Daten-Region (idealerweise EU)
• Wie lange — typisch 30 Tage Logging, dann automatisch gelöscht
• Wer haftet — bei Datenschutzverstößen primär der Mandant, sekundär der Anbieter
• Welche TOMs — Technische und Organisatorische Maßnahmen (Verschlüsselung, Zugriffsrechte, Backup-Routinen)
• Sub-Verarbeiter — falls der KI-Anbieter selbst Cloud-Services nutzt (typisch der Fall: OpenAI nutzt Microsoft Azure, Anthropic nutzt AWS)

Alle seriösen KI-Anbieter haben AVV-Vorlagen ab Werk. Wenn ein Anbieter sich weigert oder „nehmen Sie unseren Standard-AGB” sagt — das ist ein Warnsignal.

Säule 2 — EU-Daten-Residenz

Hintergrund: Schrems-II (EuGH 2020) hat das EU-US-Privacy-Shield gekippt. Datentransfer in die USA ist seither nur noch mit zusätzlichen Sicherheits-Mechanismen erlaubt (Standard Contractual Clauses + Transfer Impact Assessment). Das ist machbar, aber komplex und mit Restrisiko verbunden.

Pragmatische Lösung: EU-Daten-Residenz vertraglich zusichern. Das heißt: alle Verarbeitungs- und Speicher-Vorgänge finden physisch in der EU statt. Damit umgehen Sie den ganzen Schrems-II-Komplex.

Konkret:

• Zoho hat EU-Datacenter in Amsterdam — Standard-Setup für deutsche Kunden
• OpenAI Enterprise bietet EU-Daten-Residenz (Frankfurt-Region) ab Werk
• Anthropic verarbeitet Anfragen über AWS-EU-Regionen, wenn entsprechend konfiguriert
• Mistral ist eine französische Firma mit EU-Hosting-Standard
• Aleph Alpha ist deutsche Firma mit on-premise / EU-Cloud-Optionen
• Odoo kann self-hosted in eigener EU-Cloud betrieben werden — KI-Module wie OCA-AI lassen sich gegen lokale LLMs koppeln

Wenn der KI-Anbieter Ihnen keine EU-Region zusichern kann — andere Wahl treffen.

Säule 3 — Dokumentierte Rechtsgrundlage

Auf Mandanten-Seite (also bei Ihnen, dem Mittelständler) braucht jede personenbezogene Datenverarbeitung eine Rechtsgrundlage nach Art. 6 DSGVO:

• Vertragserfüllung (Art. 6 Abs. 1 lit. b) — KI-gestützte Bestellungs-Bearbeitung, Auftragsabwicklung
• Berechtigtes Interesse (Art. 6 Abs. 1 lit. f) — KI-Vorqualifizierung im Helpdesk, KI-Belegerfassung in der Buchhaltung
• Einwilligung (Art. 6 Abs. 1 lit. a) — Marketing-Personalisierung, Profiling, Newsletter-Personalisierung

Berechtigtes Interesse ist die häufigste Grundlage im Mittelstands-Kontext. Sie braucht eine Interessenabwägung: Ihr Interesse (Effizienz) vs. das Interesse des Betroffenen (Datenschutz). Bei reiner Vorqualifizierung im Helpdesk überwiegt typisch Ihr Interesse — solange die KI keine Entscheidungen für den Menschen trifft, sondern nur Vorschläge macht.

Diese Abwägung sollten Sie im Verarbeitungsverzeichnis dokumentieren. Wenn Sie das nie geführt haben — dann beim KI-Setup gleich mit anlegen, nicht erst auf die nächste Datenschutz-Prüfung warten.

Plattform-Patterns — drei Wege, KI sauber einzubauen

Pattern A — Plattform-integrierte KI (Zoho Zia, Odoo OCA-AI)

Die KI-Funktionen sind Teil der ERP-/CRM-Plattform. Vorteile: AVV ist bereits Teil der Plattform-Verträge, EU-Daten-Residenz wird über die Plattform selbst sichergestellt, kein zusätzlicher Anbieter im Setup.

Wann das passt:

• Standard-Use-Cases (Helpdesk-Vorqualifizierung, Lead-Scoring, E-Mail-Generierung)
• Kunden mit Zoho One oder Odoo als Backbone
• Wenn Sie KI-Funktionen schnell live haben wollen

Beispiel: Reifen24 nutzt KI-Vorqualifizierung im Helpdesk — die KI klassifiziert eingehende Tickets nach vier Kategorien (Lieferstatus, Reklamation, Beratung, Rechnung). Die Klassifikation läuft auf einem Modell mit EU-Daten-Residenz, personenbezogene Daten werden vorher pseudonymisiert. Mehr dazu im Reifen24-Case.

Detail-Article: /blog/dsgvo-ki-zoho

Pattern B — Custom-LLM in eigener Cloud (Odoo Self-Hosted + Mistral/Aleph Alpha)

Die KI läuft auf eigener Infrastruktur (oder verifiziert EU-Cloud), die ERP-Plattform schickt Anfragen direkt an die LLM-API. Vorteile: maximale Kontrolle, Daten verlassen die eigene Infrastruktur nie.

Wann das passt:

• Hochsensible Daten (Personal, Finanzen)
• Compliance-Vorgaben über DSGVO hinaus (z.B. ISO 27001, BAFIN, Branchen-spezifisch)
• Sehr individuelle Use-Cases mit Custom-Workflows

Aufwand: typisch das 3-4-fache eines Plattform-integrierten Setups. Wir empfehlen das nur, wenn Pattern A wirklich nicht passt.

Detail-Article: /blog/dsgvo-ki-odoo

Pattern C — EU-Cloud-Hosting für externe LLMs (OpenAI EU, Anthropic, Mistral)

Sie nutzen ein State-of-the-Art-LLM (z.B. Claude, GPT, Mistral Large), aber die Verarbeitungs-Region ist verbindlich auf EU gesetzt. Vorteile: beste KI-Qualität, gleichzeitig Schrems-II-konform.

Wann das passt:

• Sie brauchen die volle Capability moderner LLMs (komplexes Reasoning, lange Kontexte, multimodale Inputs)
• Standard-Use-Cases, die aber Qualität brauchen — z.B. Vertragsanalyse, Markt-Recherche, technische Dokumentation
• Sie haben nicht die IT-Tiefe für ein eigenes Self-Hosting-Setup

Detail-Article: /blog/dsgvo-ki-eu-hosting

Häufigste Fehler — was wir bei Discovery-Workshops sehen

1. „Wir nutzen ChatGPT, aber nur kostenlos” — die ChatGPT-Free-Tier hat keinen Enterprise-AVV, kein EU-Daten-Residenz-Commitment, und Anfragen werden standardmäßig zum Training verwendet. Im Mittelstand bei jedem Use-Case mit personenbezogenen Daten unzulässig. Wenn die KI im Setup wirklich gebraucht wird: ChatGPT Enterprise oder API mit Opt-out — aber niemals Free-Tier für Geschäftsdaten.

2. „Der Anbieter sagt, sie sind DSGVO-konform — Punkt” — DSGVO-Konformität ist kein Anbieter-Zertifikat, sondern eine Architektur-Frage. Auch der beste Anbieter wird nicht-konform, wenn der Mandant z.B. ohne Rechtsgrundlage Daten verarbeitet. Die Verantwortung bleibt beim Mandanten — der Anbieter haftet nur für seine TOMs.

3. „Wir haben einen AVV, also passt’s” — der AVV ist Voraussetzung, aber nicht hinreichend. Sie brauchen zusätzlich: dokumentierte Rechtsgrundlage, Datenminimierung, Pseudonymisierung wo möglich, Mitarbeiter-Schulung, Notfall-Plan bei Datenpannen.

4. „Pseudonymisierung machen wir später” — das ist der Punkt, an dem 80 % der Setups scheitern. Pseudonymisierung muss VOR dem Live-Gang stehen, nicht nachträglich nachgeschoben werden. Wir bauen sie immer als ersten Schritt der Daten-Pipeline ein.

5. „Wir brauchen kein Verarbeitungsverzeichnis” — ja, brauchen Sie. Art. 30 DSGVO. Bei Unternehmen mit mehr als 250 Mitarbeitern verpflichtend, bei kleineren Unternehmen empfohlen — und der Datenschutzbeauftragte erwartet es bei jeder Prüfung.

Mate-iT-Empfehlung — drei Faustregeln

Erstens: Architektur vor Tools. Welche KI-Plattform Sie nutzen, ist die zweitwichtigste Entscheidung. Die wichtigste ist: wie Sie sie einbauen — mit oder ohne Pseudonymisierung, mit oder ohne dokumentierter Rechtsgrundlage, mit oder ohne klarem Use-Case-Scope.

Zweitens: EU-Daten-Residenz ist nicht verhandelbar. Die paar Prozent Performance-Unterschied zwischen US- und EU-Region sind irrelevant gegen das Schrems-II-Risiko. Wir lehnen Setups, die nicht EU-Residenz garantieren können, ab.

Drittens: Ein menschlicher Bestätigungs-Schritt im Workflow. Wir bauen KI-Agenten typisch so, dass sie Vorschläge machen, aber nicht selbständig entscheiden. Das schützt vor zwei Risiken: erstens technische Fehler (LLMs halluzinieren), zweitens DSGVO Art. 22 (automatisierte Entscheidungen sind grundsätzlich verboten ohne explizite Einwilligung).

Nächster Schritt

Wenn Sie KI-Agenten DSGVO-konform einführen wollen — schreiben Sie uns. 30 Minuten Erstgespräch, wir gehen Ihren Use-Case, Ihre Daten-Klassifikation und die rechtliche Lage mit Ihrem Datenschutzbeauftragten durch. Am Ende des Gesprächs haben Sie eine klare Einschätzung: ist das Use-Case unkritisch (Standard-Setup), kritisch (mit Pseudonymisierungs-Schicht), oder hochkritisch (eigene Cloud).

Mehr zu unseren KI-Services: /leistungen/ki-agenten. Mehr zu unserer Lösungs-Philosophie: /leistungen/ki-im-alltag. Konkreter Mate-iT-Case mit DSGVO-konformer KI: /cases/reifen24.