Datenhoheit bei KI: vier Betriebsformen im Vergleich

Achtzehn Tage ohne Modell

Am 12. Juni 2026 setzte eine Exportkontrollanordnung der US-Regierung Anthropic unter Zugzwang. Der Anbieter deaktivierte seine Modelle Claude Fable 5 und Mythos 5 für sämtliche Kunden und über sämtliche Vertriebswege hinweg: AWS Bedrock, Google Cloud, Microsoft Foundry und die eigene Schnittstelle. Am 30. Juni wurde die Anordnung aufgehoben, ab dem 1. Juli war das Modell wieder erreichbar. Dazwischen lagen achtzehn Tage.

Für europäische Anwender war dabei zweierlei bemerkenswert. Der Speicherort spielte keine Rolle, denn abgeschaltet wurde der Dienst und nicht ein Rechenzentrum. Und der Auftragsverarbeitungsvertrag half ebenfalls nicht, weil er den Umgang mit Daten regelt und keine Verfügbarkeit zusichert. Betriebe, die das Modell fest in einen Ablauf eingebunden hatten, arbeiteten in dieser Zeit ohne Ersatz.

Daraus folgt eine Unterscheidung, die in Datenschutzgesprächen selten getrennt wird. Datenhoheit hat zwei Seiten: Wer kann auf die Daten zugreifen, und wer kann den Dienst abschalten. Die vier gängigen Betriebsformen beantworten diese beiden Fragen sehr unterschiedlich.

Die vier Betriebsformen

• Öffentliche Schnittstelle mit Auftragsverarbeitungsvertrag. Der Anbieter betreibt das Modell, Sie schließen einen Vertrag über die Auftragsverarbeitung ab. Schnell eingerichtet, kein eigener Betrieb, geringste Kosten. Der Anbieter behält technischen Zugriff auf die Verarbeitung, und er entscheidet über Verfügbarkeit und Preis. Kostenlose Zugänge ohne Vertrag scheiden im geschäftlichen Einsatz aus.
• Europäische Region eines internationalen Anbieters. Speicherung und Verarbeitung finden in der EU statt; Microsoft hat seine EU Data Boundary dafür abgeschlossen, AWS und Google führen entsprechende Regionen. Das senkt das Übermittlungsrisiko deutlich. Der US CLOUD Act verpflichtet US-Unternehmen allerdings zur Herausgabe von Daten auf Anordnung amerikanischer Behörden, unabhängig vom Speicherort, weshalb der Standort allein kein vollständiger Nachweis ist.
• Souveräne europäische Cloud mit offenen Modellen. Die AWS European Sovereign Cloud ging im Januar 2026 mit ihrer ersten Region in Brandenburg in Betrieb, betrieben über eine deutsche Gesellschaft und logisch wie physisch von den übrigen Regionen getrennt. Daneben stehen europäische Anbieter wie der IONOS AI Model Hub, der offene Modelle über eine einheitliche Schnittstelle in Deutschland betreibt, oder STACKIT der Schwarz Gruppe. Zugriffs- und Abschaltrisiko sinken hier gemeinsam, sobald das Modell offene Gewichte hat.
• Eigene Hardware im Haus. Modell und Daten liegen im eigenen Serverraum, Zugriff und Abschaltbarkeit liegen vollständig beim Betrieb. Dafür fallen Anschaffung, Strom und Betreuung an, unabhängig von der Nutzung, und die Modellauswahl ist auf die vorhandene Speicherklasse begrenzt.

Warum offene Gewichte der eigentliche Hebel sind

Bei einem geschlossenen Modell ist der Anbieter der einzige Bezugsweg. Fällt er aus, weil er abschaltet, den Preis ändert oder das Modell aus dem Angebot nimmt, fällt die darauf aufgebaute Anwendung mit aus. Der Juni 2026 hat gezeigt, dass dieser Fall keine Theorie ist.

Bei offenen Gewichten liegt eine Kopie des Modells vor. Sie lässt sich bei einem anderen Anbieter hochfahren oder im eigenen Haus betreiben, mit demselben Verhalten und denselben Prompts. Der Wechsel dauert dann Tage statt Monate, und das ist der praktische Unterschied zwischen einer Störung und einem Stillstand.

Voraussetzung dafür ist eine Lizenz, die den Einsatz überhaupt erlaubt: Ein Modell, dessen Lizenz Betriebe mit Sitz in der EU von bestimmten Funktionen ausschließt, taugt nicht als Ausweichpfad. Die vier Klauseln, an denen sich das entscheidet, stehen in Open-Source-KI-Modelle: vier Lizenzklauseln vor dem Einsatz, die Einordnung offener Modelle in Souveränität mit offenen Modellen.

Was die Betriebsform nicht löst

Wer im Haus welche Dokumente sehen darf, entscheidet die Berechtigungssteuerung und nicht der Standort des Servers. Ein Modell im eigenen Keller, das jedem Mitarbeiter jede Personalakte vorliest, ist ein größeres Problem als eine europäische Cloud mit sauber gesetzten Rechten; die Praxis dazu steht in Berechtigungen im KI-Assistenten. Zweckbindung, Löschfristen und Betroffenenrechte gelten in allen vier Formen gleichermaßen, siehe DSGVO-konforme KI-Lösungen.

Auch die Pflichten aus der europäischen KI-Verordnung hängen nicht an der Betriebsform. Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 unmittelbar: Nutzer müssen erkennen können, dass sie mit einem KI-System sprechen, und KI-erzeugte Inhalte sind zu kennzeichnen. Diese Pflichten treffen den Betreiber und damit Sie, unabhängig davon, wo das Modell läuft.

Und die Betriebsform sagt nichts über Qualität oder Wirtschaftlichkeit. Ein souverän betriebenes Modell, das die Aufgabe schlechter löst, bleibt die schlechtere Wahl. Beide Fragen gehören getrennt beantwortet und danach zusammengeführt.

Was Sie diese Woche tun können

• Listen Sie alle produktiv genutzten KI-Dienste auf, mit je vier Angaben: Betriebsform, Sitz des Anbieters, offene oder geschlossene Gewichte, und wer im Haus davon abhängt.
• Benennen Sie für jeden produktiven Einsatz einen Ausweichpfad und spielen Sie ihn einmal durch. Ein Ausweichpfad, der nie getestet wurde, ist im Ernstfall eine Vermutung.
• Fordern Sie den Auftragsverarbeitungsvertrag und die Liste der Unterauftragsverarbeiter an. Beides gehört in die Akte, bevor der Dienst in einen Prozess einzieht.
• Halten Sie bei offenen Modellen eine Kopie der Gewichte im Haus vor, soweit die Lizenz das erlaubt. Das kostet Speicherplatz und ersetzt im Störfall ein Projekt.

Die Betriebsform ist eine Entscheidung mit langer Bindung, weil Anbindungen, Berechtigungen und eingespielte Abläufe daran hängen. Sie einmal bewusst zu treffen und im Protokoll festzuhalten, kostet einen halben Tag.