DSGVO-konforme KI für Unternehmen: was wirklich zählt

DSGVO-Konformität ist keine Produkteigenschaft. EU-Hosting allein reicht nicht; Self-hosting ist ebenfalls nicht automatisch DSGVO-konform. Die entscheidende Frage ist früher gestellt: Welche Daten muss dieser konkrete AI-Use-Case sehen, welche Systeme dürfen sie verarbeiten, und welche Kontrolle muss das Unternehmen dabei behalten?

Das ist eine Architekturentscheidung, bevor es eine Anbieterentscheidung ist. Erst Use Case, Datenklasse, Datenfluss und Systemgrenzen grenzen das passende Betriebsmodell ein. Danach folgt die juristische Bewertung – nicht umgekehrt. Ob der EU AI Act ChatGPT & Copilot ab August 2026 verbietet, klären wir separat im Artikel ChatGPT & Copilot im Unternehmen.

Kurzantwort: Eine belastbare KI-Architektur beginnt nicht beim Anbieter, sondern bei Use Case, Datenklasse und Kontrollgrenze. Sie macht sichtbar, welche Daten in Anwendung, Retrieval, Modell, Logs und externe Dienste gelangen – und wer Zugriff, Speicherung und Löschung steuert. Daraus ergibt sich das passende Betriebsmodell; keines ist damit automatisch rechtlich freigegeben.

Zuletzt fachlich aktualisiert: 17. August 2026

Die Architekturentscheidung beginnt mit den Daten

Die Leitfrage lautet nicht: „Welches Modell ist am besten?" Sondern: Welche Daten muss diese Aufgabe tatsächlich sehen? Für die technische Risikoeinordnung helfen grobe Klassen:

• Öffentliche oder unkritische Inhalte: etwa allgemein verfügbare Texte oder Ideen ohne Bezug zu internen Vorgängen.
• Internes Unternehmenswissen: Richtlinien, Prozessdokumente, Produktwissen oder nicht öffentliche Arbeitsstände.
• Vertrauliche oder geschäftskritische Daten: Verträge, Angebote, Strategie, Quellcode, Preise oder Geschäftsgeheimnisse.
• Personenbezogene Daten: Kunden-, Beschäftigten- oder Kontaktdaten sowie Inhalte mit Personenbezug.
• Besondere Kategorien oder stark regulierte Daten: beispielsweise Gesundheitsdaten oder Daten aus besonders regulierten Fachprozessen.

Diese Klassen ersetzen keine rechtliche Klassifikation. Sie helfen, den technischen Schutzbedarf früh sichtbar zu machen. Ein Modell „für Unternehmen" sagt darüber allein nichts aus.

Gate 1: Use Case und Datenklasse

Nicht das Modell bestimmt die Architektur, sondern die Kombination aus Aufgabe und Daten.

Ein allgemeiner Textentwurf ohne interne Inhalte kann mit einem zentral verwalteten Business-SaaS sinnvoll gelöst werden. Ein internes RAG-System muss dagegen Dokumente, Berechtigungen und Retrieval-Kontext sehen. Ein Support-Assistent mit Kundendaten verarbeitet zusätzlich Personenbezug; bei besonders sensiblen oder regulierten Daten steigen die Anforderungen an Isolation, Nachvollziehbarkeit und fachliche Prüfung deutlich.

Der konkrete Use Case ist damit der Filter gegen zwei Fehlentscheidungen: eine überteuerte Isolation für harmlose Aufgaben – und ein bequemes Standard-SaaS für Daten, die diese Kontrollgrenze nicht überschreiten sollten.

Gate 2: Der tatsächliche Datenfluss

„EU Storage" oder „EU Hosting" beschreibt nur einen Ausschnitt. Für die Architektur zählt der vollständige Weg der Daten:

• User und Client: Was geben Mitarbeitende ein, welche Dateien laden sie hoch, was speichert der Browser?
• Anwendung sowie Auth und Identity: Wer darf den Use Case nutzen und welche Rollen werden durchgesetzt?
• Datenquelle und Retrieval: Welche Dokumente werden indexiert, welche Passagen werden für eine Anfrage ausgewählt, bleiben Quellberechtigungen erhalten?
• Prompt, Context und Model Inference: Welche Inhalte erreichen das Modell – und wo wird die Inferenz tatsächlich ausgeführt?
• Logs, Telemetrie und Monitoring: Welche Prompts, Metadaten oder Fehlerdaten bleiben dort zurück, wer kann sie einsehen und wie lange?
• Support-Zugriffe, Subprozessoren und externe Integrationen: Welche weiteren Empfänger können Daten erhalten, auch wenn sie im sichtbaren Anbieterprodukt nicht auftauchen?
• Backups und Retention: Wann verschwinden Dateien, Embeddings, Chats und Protokolldaten tatsächlich aus produktiven und gesicherten Systemen?

Storage und Inference sind getrennt zu betrachten. Daten können in der EU gespeichert sein, während Modellanfragen, Telemetrie oder Support-Zugriffe andere Grenzen überschreiten. Der sichtbare AI-Anbieter ist ebenso nicht zwingend der einzige Empfänger von Daten.

Das gilt auch für etablierte Business-Produkte. OpenAI beschreibt in seinem Data Processing Addendum die Transfermechanismen für EWR-Daten; Geschäftsdaten aus ChatGPT Business und Enterprise werden laut OpenAI nicht standardmäßig zum Training verwendet. Die vom Anbieter beschriebene Daten- und Inference-Residenz ist jedoch an berechtigte Enterprise- und Edu-Kunden gebunden und deckt nicht zwangsläufig jede Metadaten-, Support- oder Integrationsverarbeitung ab. Das ist keine Bewertung von OpenAI, sondern ein Beispiel dafür, warum der Datenfluss wichtiger ist als ein einzelnes Produktmerkmal.

Gate 3: Wo liegt die Kontrollgrenze?

Eine Kontrollgrenze beschreibt, welche Komponenten das Unternehmen selbst kontrolliert und ab welchem Punkt Verarbeitung an externe Anbieter delegiert wird. Sie ist keine abstrakte Souveränitätsdebatte, sondern eine konkrete Betriebsentscheidung.

Relevant sind insbesondere:

• Identität, Rollen und Admin-Zugriffe,
• Datenzugriff und Netzwerkpfade,
• Retrieval-Daten und Modellzugriff,
• Protokollierung ohne unnötige sensible Inhalte,
• Retention, Löschung und Backups,
• Support-Zugriffe und Subprozessoren,
• Provider-Abhängigkeiten sowie eine realistische Exit- oder Wechselmöglichkeit.

Je weiter diese Punkte außerhalb der eigenen Kontrolle liegen, desto genauer müssen Vertrag, Konfiguration und tatsächlicher Betrieb geprüft werden. Je mehr das Unternehmen selbst übernimmt, desto mehr Gestaltungsspielraum gewinnt es – aber auch Verantwortung für Sicherheit, Updates, Verfügbarkeit und Wiederherstellbarkeit.

Betriebsmodell aus dem Schutzbedarf eingrenzen

1. 01

   Welchen Use Case soll die KI erfüllen?

   • Allgemeine Produktivität

     Keine internen oder personenbezogenen Inhalte nötig.

   • Wissen, Support oder Fachprozess

     Der Use Case benötigt Unternehmens- oder Kundendaten.

2. 02

   Welche Datenklasse muss den Datenfluss passieren?

   • Öffentlich oder unkritisch

     Business SaaS kann ein angemessener Ausgangspunkt sein.

   • Intern, vertraulich oder personenbezogen

     Retrieval, Logs, Inference und Empfänger gezielt prüfen.

3. 03

   Ist externe Verarbeitung innerhalb der geforderten Grenze zulässig?

   • Ja, mit kontrolliertem Vertrag und Setup

     Business- oder EU-/Enterprise-SaaS kann passen.

   • Nur eingeschränkt oder nein

     Private Cloud oder isolierter eigener Betrieb stärker prüfen.

4. 04

   Welche Kontrolltiefe und Betriebsverantwortung sind tragbar?

   • Schneller Start, weniger Betrieb

     Business SaaS oder EU-gehostetes SaaS.

   • Höhere Kontrolle, mehr Betriebsverantwortung

     Private Cloud, Self-hosted oder On-Premise stärker prüfen.

Gate 4: Das passende Betriebsmodell

Die Modelle unterscheiden sich nicht nur durch den Standort. Sie verschieben Datenkontrolle, externe Datenflüsse, Betriebsaufwand und Lock-in-Risiko auf unterschiedliche Weise.

Mehr Kontrolle ist nicht automatisch besser. Für einen unkritischen Produktivitäts-Use-Case kann SaaS die vernünftige Entscheidung sein. On-Premise bringt keine Abkürzung zur Konformität, sondern zusätzliche Betriebsverantwortung. Private Cloud ist oft sinnvoll, wenn die Schutzanforderungen über Standard-SaaS hinausgehen, ein vollständiger Eigenbetrieb aber nicht zum Team passt. Die breiteren Trade-offs von Public Cloud, EU Hosting, Private Cloud, On-Premise und Hybrid erläutert Private AI vs. Public Cloud.

Wenn aus dieser Entscheidung eine eigene, private oder stärker integrierte Architektur folgt, sollte vor Build oder Go-live die Gesamtarchitektur geprüft werden: Daten, Identity, Security, Evaluation, Failure Modes und Betrieb. Dafür dient die KI-Architektur-Checkliste für Unternehmen.

Drei Entscheidungsszenarien

Szenario A: Allgemeine Produktivitäts-KI

Für Entwürfe, Zusammenfassungen oder Ideen ohne vertrauliche und personenbezogene Inhalte kann Business SaaS genügen. Die Architekturentscheidung ist dann bewusst einfach: zentrale Accounts und Administration, klare Nutzungsgrenzen, Trainingseinstellungen und Retention prüfen. Eine lokale Plattform wäre hier nicht automatisch verhältnismäßig.

Szenario B: RAG über internes Unternehmenswissen

Ein RAG-System über Richtlinien, Dokumente oder Produktwissen verändert die Entscheidung. Datenquelle, Index, Retrieval und Modell sind getrennte Komponenten; die Berechtigungen der Quelle müssen beim Retrieval erhalten bleiben. Das ist kein Detail, sondern Teil der Kontrollgrenze. Je nach Schutzbedarf kann EU-SaaS, Private Cloud oder eine kontrollierte eigene Architektur passen. Die technische Umsetzung beschreibt RAG-Implementierung & KI-Integration; warum Berechtigungen beim Retrieval nicht verloren gehen dürfen, behandelt RAG Permissions & Security Trimming.

Szenario C: Sensible oder regulierte Daten

Bei besonderen Kategorien personenbezogener Daten, sensiblen Kundendaten oder stark regulierten Prozessen sind Isolation, Zugriffspfade, Retention und Support-Zugriffe zentrale Architekturfragen. Private Cloud, Self-hosting oder On-Premise verdienen dann eine deutlich stärkere Prüfung. Die Architektur kann Risiken begrenzen, die verbindliche rechtliche Einordnung muss jedoch fachkundig erfolgen.

Was Architektur nicht entscheidet

Eine saubere Architektur schafft Entscheidungsgrundlagen, ersetzt aber keine Rechtsberatung. Insbesondere entscheidet sie nicht abschließend über:

• Rechtsgrundlage und Zweckbindung,
• Rollen von Verantwortlichem und Auftragsverarbeiter sowie einen gegebenenfalls erforderlichen AVV,
• Drittlandtransfers, etwa über EU-US Data Privacy Framework, Angemessenheitsbeschlüsse oder Standardvertragsklauseln,
• eine gegebenenfalls erforderliche DSFA,
• Informations-, Dokumentations- und Betroffenenrechte, einschließlich eines Verzeichnisses der Verarbeitungstätigkeiten.

Für österreichische Unternehmen gilt die DSGVO unmittelbar; das österreichische Datenschutzgesetz ergänzt sie. Die österreichische Datenschutzbehörde erläutert die maßgeblichen Rechtsquellen. Eine Architekturentscheidung kann diese Prüfung strukturieren, aber nicht ersetzen.

Technischer Proof: kontrollierte Architektur unter realen Vorgaben

In der Referenzübersicht ist eine für experdoo aufgebaute, vollständig selbstgehostete KI-Plattform dokumentiert. Ausgangspunkt waren strenge regulatorische Anforderungen, sensibles Unternehmenswissen und die Vorgabe, für diese Daten keine externe Public-Cloud-KI einzusetzen.

Die Umsetzung umfasste eine selbstgehostete Plattform, RAG über Dokumente, Richtlinien und Fachprozesse, mehrere Agents sowie eine mandantenfähige Architektur mit klarer Daten- und Rechte-Trennung. Das beweist nicht „Self-hosting = DSGVO-konform". Es zeigt den technischen Wert einer kontrollierten Architektur: Datenflüsse, Systemgrenzen, Zugriffe und Wissensquellen lassen sich gezielt gestalten, statt sie einem Standard-SaaS-Setup zu überlassen.

Praktische Konsequenz

Das größte Risiko ist oft nicht die falsche Plattform, sondern das Fehlen einer bewusst bereitgestellten und kontrollierten Alternative. Schatten-KI im Unternehmen entsteht häufig, weil Mitarbeitende ein Produktivitätsproblem lösen wollen und es keine brauchbare Freigabe gibt.

Der Souveränitäts-Check übersetzt Use Case, Schutzbedarf, bestehende Datenflüsse und Betriebsaufwand in eine nachvollziehbare Architekturentscheidung. Ist bereits ein problematischer Upload passiert, hilft die KI-Vorfall-Soforthilfe bei der ersten technischen Einordnung und Dokumentation.

Hinweis: Dieser Beitrag bietet eine technische Orientierung und ersetzt keine Rechtsberatung. Für die verbindliche Bewertung eines konkreten Falls ist fachkundiger Rechtsrat erforderlich.

Häufige Fragen

Ist ChatGPT DSGVO-konform? Ob ChatGPT DSGVO-konform eingesetzt werden kann, hängt von Tarif, Vertrag, Konfiguration und dem konkreten Datenfluss ab. Geschäftsdaten aus ChatGPT Business und Enterprise werden laut Anbieter standardmäßig nicht zum Training verwendet; EU-Residenz ist nur für berechtigte Enterprise- und Edu-Kunden verfügbar und deckt nicht jede Verarbeitung ab.

Welche KI ist DSGVO-konform? Keine Architektur ist es automatisch. Entscheidend sind Use Case, Datenklasse, Datenfluss, Kontrollgrenze und der juristische Rahmen. EU-gehostete oder selbst betriebene Lösungen können Kontroll- und Transferrisiken reduzieren, ersetzen die Prüfung aber nicht.

Müssen Daten in der EU bleiben? Nicht zwingend. Transfers an zertifizierte US-Unternehmen können derzeit auf das DPF gestützt werden; je nach Empfänger kommen auch Standardvertragsklauseln und ergänzende Maßnahmen in Betracht. EU-Verarbeitung reduziert den Transferaufwand, löst aber nicht automatisch alle Anforderungen.

Ist lokale KI automatisch DSGVO-konform? Nein. Eigener Betrieb kann externe Datenflüsse reduzieren, sofern auch APIs, Telemetrie, Supportzugriffe und angebundene Dienste kontrolliert sind. Rechtsgrundlage, Zweckbindung, Berechtigungen, Löschung und Transparenz bleiben erforderlich.

---

Sie wollen wissen, welche Kontrollgrenze Ihr AI-Use-Case braucht? Der Souveränitäts-Check schafft in einer Woche Klarheit über Datenflüsse, Betriebsmodell und nächste Architekturentscheidungen.