Ein Serverstandort in Deutschland macht eine KI-Anwendung nicht automatisch sicher, während sensible Daten umgekehrt nicht grundsätzlich auf eigener Hardware bleiben müssen. Entscheidend ist, welche Kontrolle ein konkreter Anwendungsfall tatsächlich braucht.
In unseren Schulungen begegnen uns beide Annahmen regelmäßig. Die erste unterschätzt Zugriffe und Betriebsprozesse, während die zweite aus jedem KI-Projekt vorsorglich ein Infrastrukturprojekt macht.
Fragen Sie deshalb nicht zuerst nach Cloud oder On-Premises, sondern klären Sie die verarbeiteten Daten und die notwendige Kontrolle. Erst danach lässt sich das passende Betriebsmodell wählen.
Sensible Daten sind keine einheitliche Kategorie
Der Begriff „sensible Unternehmensdaten“ ist praktisch, aber rechtlich unscharf und umfasst Informationen mit sehr unterschiedlichen Risiken.
Die Datenschutz-Grundverordnung erfasst personenbezogene Daten, wobei Artikel 9 etwa für Gesundheitsdaten und biometrische Daten erhöhte Anforderungen vorsieht.
Daneben schützen Unternehmen Informationen ohne Personenbezug, darunter Quellcode, Forschungsergebnisse, Kalkulationen, Vertragsentwürfe und strategische Pläne. Solche Informationen können Geschäftsgeheimnisse oder kritisches geistiges Eigentum darstellen.
Für die erste Einordnung helfen vier Klassen:
| Klasse | Beispiele | Erste Arbeitsregel |
|---|---|---|
| Öffentlich | Website-Texte, Pressemitteilungen, veröffentlichte Produktinformationen | In freigegebenen KI-Werkzeugen meist unkritisch |
| Intern | Prozessbeschreibungen, normale Projektdokumentation, interne Präsentationen | Nur in freigegebenen Unternehmensprodukten verarbeiten |
| Vertraulich | Kundenakten, Kalkulationen, Personalvorgänge, nicht veröffentlichter Quellcode | Anbieter, Vertrag und Datenfluss gesondert prüfen |
| Streng vertraulich | Zugangsdaten, kritische Forschung, Gesundheitsdaten, besonders geschützte Geschäftsgeheimnisse | Isolierte oder private Betriebsmodelle ernsthaft prüfen |
Die Einteilung ist keine rechtliche Bewertung, zeigt aber die Fälle mit dem größten Prüfbedarf. Vertraulichkeit ist außerdem nur ein Schutzziel, denn Integrität und Verfügbarkeit können ebenso wichtig sein. Manipulierte Produktionsdaten verursachen andere Schäden als ein offengelegtes Dokument, während ein Systemausfall einen kritischen Prozess vollständig stoppen kann.
Prüfen Sie den vollständigen Datenweg
Viele Anbieterfragen beginnen und enden beim Speicherort, obwohl er für eine tragfähige Entscheidung nicht ausreicht.
Eine KI-Anwendung verarbeitet oft mehr als den sichtbaren Prompt, denn zum System gehören Anhänge, Chatverläufe, Suchindizes, Embeddings, Konnektoren und Ausgaben. Protokolle, Telemetrie, Backups und Supportdaten erweitern den Datenweg zusätzlich.
Bei einem Confluence-Assistenten ist deshalb nicht nur die eingegebene Frage relevant, sondern auch sein erlaubter Suchbereich. Übernimmt er bestehende Berechtigungen korrekt, und kann er Inhalte aus geschützten Bereichen in einer Antwort zusammenführen?
Bei Jira entstehen ähnliche Fragen, weil Tickets häufig Namen, Vertragsinformationen, Fehlerprotokolle oder technische Details enthalten. Ein unscheinbarer Connector kann dadurch größere Datenmengen verarbeiten als ein einzelner Chat.
Dokumentieren Sie für jeden Anwendungsfall mindestens:
- die Daten, die in das System gelangen,
- zusätzliche Quellen, die es abrufen kann,
- Speicherorte für Eingaben, Ausgaben, Logs und Backups,
- administrative Zugriffsrechte,
- beteiligte Unterauftragnehmer,
- Speicher- und Löschfristen,
- eine mögliche Nutzung für Training oder Produktverbesserung,
- Export- und Löschwege beim Anbieterwechsel.
„Nicht für Training verwendet“ bedeutet nicht „nicht gespeichert“, und eine EU-Datenregion sagt wenig über Supportzugriffe oder globale Unterauftragnehmer aus.
Ein deutscher Speicherort kann Risiken reduzieren, beantwortet aber nicht jede Frage zur Betreiberstruktur. Der CLOUD Act knüpft bei betroffenen US-Anbietern an Besitz, Gewahrsam oder Kontrolle an, nicht allein an den Serverstandort, wie das US-Justizministerium erläutert.
US-Dienste sind deshalb nicht generell unzulässig, denn bei Übermittlungen an entsprechend zertifizierte US-Unternehmen kann der EU-US Data Privacy Framework eine Transfergrundlage bieten. Maßgeblich bleiben der konkrete Dienst, die beteiligten Gesellschaften und die vereinbarten Schutzmaßnahmen, wie die Übersicht der Europäischen Kommission zeigt.
Datenresidenz, Sicherheit und Souveränität trennen
Diese Begriffe beschreiben unterschiedliche Systemeigenschaften: Datenresidenz beantwortet, wo Daten gespeichert oder verarbeitet werden. Sicherheit umfasst die Maßnahmen gegen Verlust, Manipulation, Ausfall und unbefugte Zugriffe.
Cloud-Souveränität reicht weiter und betrifft die rechtliche, technische sowie operative Kontrolle einer Organisation. Dazu gehören auch Lieferkette, Wechselbarkeit und wirtschaftliche Abhängigkeiten.
Die Europäische Kommission hat 2026 einen Rahmen mit 48 Kriterien in acht Dimensionen veröffentlicht. Er betrachtet unter anderem Jurisdiktion, Daten, Betrieb, Technologie, Lieferkette und Sicherheit, wie das Cloud Sovereignty Framework zeigt.
Eine deutsche Datenregion beantwortet möglicherweise die Residenzfrage, ohne volle Souveränität zu schaffen. Umgekehrt kann ein externer Betrieb genügend Kontrolle bieten, wenn Zugriffe, Nachweise und Exit klar geregelt sind.
Wann ein SaaS-Angebot ausreichen kann
SaaS ist nicht automatisch unsicherer als eine lokale Installation. Ein professionell betriebener Dienst kann besser geschützt sein als ein vernachlässigtes System im eigenen Haus.
Für viele Anwendungsfälle reicht ein Unternehmensprodukt, wenn die benötigten Kontrollen nachweisbar sind. Das gilt häufig für öffentliche Inhalte, normale interne Dokumente und begrenzte personenbezogene Daten.
Prüfen Sie vor der Freigabe:
- Besteht ein geeigneter Vertrag zur Auftragsverarbeitung?
- Ist die Nutzung der Daten für Modelltraining ausgeschlossen?
- Sind Speicherfristen und Löschwege dokumentiert?
- Passen Datenregion und Unterauftragnehmer zum Anwendungsfall?
- Unterstützt das Produkt Rollen, Mehrfaktor-Authentifizierung und Protokollierung?
- Lassen sich Freigaben auf bestimmte Nutzergruppen und Datenquellen begrenzen?
- Können Sie Daten vollständig exportieren und löschen?
- Wer trägt intern die Verantwortung für die Freigabe?
Ein Business- oder Enterprise-Tarif allein genügt nicht, denn die konkrete Produktversion, der Vertrag und die Konfiguration müssen zusammenpassen.
Für die Zusammenfassung veröffentlichter Produktbeschreibungen wäre eine eigene Infrastruktur kaum zu rechtfertigen. Ein freigegebenes SaaS-Werkzeug bietet meist den besseren Aufwand-Nutzen-Ausgleich.
Bei einem Assistenten für Personalakten steigen Schutzbedarf und mögliche Folgen erheblich. Das Unternehmen muss Rechtsgrundlage, Berechtigungen, Protokollierung und Datenflüsse wesentlich genauer prüfen.
Die Datenschutzkonferenz empfiehlt diese Prüfung bereits bei Auswahl und Einführung einer KI-Anwendung, denn Technik ersetzt die organisatorische Entscheidung nicht.
Wann Private Cloud sinnvoll wird
Private Cloud wird interessant, wenn eine notwendige Kontrolle im SaaS-Modell fehlt, doch die Datenklasse allein begründet den Aufwand noch nicht.
Typische Gründe sind:
- Kundendaten müssen in einer bestimmten Liegenschaft verbleiben.
- Administrative Zugriffe sollen technisch oder organisatorisch enger begrenzt werden.
- Das Unternehmen benötigt eigene Schlüssel und kontrollierte Entschlüsselungspfade.
- Netze oder Systeme dürfen nur zeitweise mit externen Diensten verbunden sein.
- Forschung, Produktion oder Diagnostik verlangen sehr niedrige Latenzen.
- Ein dauerhafter Workload rechtfertigt dedizierte Kapazität.
- Ein Audit verlangt detaillierte Nachweise zu Betrieb, Lieferkette und Wiederherstellung.
Private Cloud bedeutet nicht zwingend Eigenbetrieb, denn ein Dienstleister kann Hardware und Plattform beim Kunden betreiben. Das Unternehmen gewinnt dadurch mehr physische Kontrolle, ohne den kompletten Betrieb selbst übernehmen zu müssen.
Diese Arbeitsteilung verlangt klare Antworten: Wer installiert Sicherheitsupdates, kontrolliert Fernzugriffe und hält die Schlüssel? Wohin fließen Telemetrie und andere Betriebsdaten, und wie funktioniert der Weiterbetrieb nach Vertragsende?
Offene Technologien beseitigen Abhängigkeiten nicht vollständig, auch wenn OpenStack, Kubernetes und offene Schnittstellen einen Wechsel erleichtern. Betriebswissen, Automatisierung, Hardware und Vertragslaufzeiten erzeugen trotzdem Bindungen.
Der BSI-Kriterienkatalog C5 beschreibt konkrete Anforderungen an einen sicheren Cloud-Betrieb. Ein C5-Prüfbericht besitzt einen definierten Umfang und Zeitraum, ist aber keine allgemeine BSI-Zertifizierung.
Airgap bleibt ein Sonderfall
Eine vollständig abgeschottete Umgebung reduziert externe Netzwerkpfade, löst aber nicht jedes Sicherheitsproblem. Updates, Modelle, Softwarepakete und Signaturen müssen kontrolliert in die Umgebung gelangen, wobei Wechselmedien eigene Angriffswege schaffen. Support und Wiederherstellung werden dadurch aufwendiger.
Ein Airgap passt vor allem zu klar abgegrenzten, sehr kritischen Workloads. Für normale Wissensarbeit wäre der zusätzliche Betrieb meist unverhältnismäßig.
Zwischen dauerhaft online und vollständig getrennt liegen weitere Modelle, die sich etwa nur in festgelegten Wartungsfenstern verbinden. Andere erlauben freigegebene Datenübertragungen über kontrollierte Übergabepunkte.
Fünf Betriebsmodelle im Vergleich
| Modell | Typischer Nutzen | Zentrale Prüfung |
|---|---|---|
| Enterprise-SaaS | Schneller Einstieg, geringer eigener Betrieb | Vertrag, Speicherung, Training, Datenregion, Unterauftragnehmer |
| Managed Cloud in Deutschland | Flexible Infrastruktur mit deutschem Betriebsstandort | Betreiberstruktur, Mandantentrennung, Schlüssel, SLA und Exit |
| Dedizierte Hosted Cloud | Eigene Ressourcen in einem externen Rechenzentrum | Physische Infrastruktur, Administration, Backup und Portabilität |
| Managed Private Cloud beim Kunden | Hohe Standortkontrolle ohne vollständigen Eigenbetrieb | Fernzugriff, Telemetrie, Schlüssel, Standort und Vertragsende |
| Airgapped Private Cloud | Starke Netzwerkisolation für besonders kritische Workloads | Updates, Wechselmedien, Support, Forensik und Wiederanlauf |
Mehr Isolation ist nicht automatisch besser und lohnt sich nur, wenn sie eine konkrete Kontrolllücke schließt.
Typische KI-Anwendungsfälle
| Anwendungsfall | Plausibler Ausgangspunkt | Grund |
|---|---|---|
| Öffentliche Marketingtexte zusammenfassen | Freigegebenes SaaS | Geringer Schutzbedarf |
| Interne Richtlinien durchsuchen | Enterprise-SaaS oder Managed Cloud | Berechtigungen und Datenquellen kontrollieren |
| Jira-Tickets mit Kundendaten analysieren | Unternehmensprodukt nach gesonderter Prüfung | Personenbezug, Anhänge und Protokolle |
| Personalakten auswerten | Stark begrenzte, gesondert geprüfte Umgebung | Hohe Folgen für betroffene Personen |
| Unveröffentlichten Quellcode analysieren | Enterprise-SaaS oder Private Cloud | Geschäftsgeheimnisse und Zugriffspfade schützen |
| Kritische Forschungsdaten verarbeiten | Private oder getrennte Umgebung prüfen | Hoher wirtschaftlicher Schaden bei Kontrollverlust |
| Gesundheitsdaten für ein KI-System nutzen | Dedizierte Architektur und Einzelfallprüfung | Besondere Datenkategorie und möglicher hoher Schaden |
Brillianza als Beispiel für eine gemanagte Private Cloud
Brillianza beschreibt eine gemanagte Private Cloud in der eigenen Liegenschaft. Hardware und Plattform befinden sich nach Anbieterangaben beim Kunden, während Brillianza den technischen Betrieb übernimmt.
Damit bleibt die Infrastruktur vor Ort, ohne dass das Unternehmen den vollständigen Betrieb selbst übernehmen muss. Auf der Website unterscheidet Brillianza zwischen Online-, Detached- und Airgapped-Betrieb.
Das Modell passt vor allem zu dauerhaften, sensiblen Workloads und einem geeigneten Standort. Für stark schwankende Lasten oder kurzfristige Projekte kann ein flexibles SaaS- oder Hosted-Modell sinnvoller sein.
Die technischen und vertraglichen Details sollten Unternehmen trotzdem selbst prüfen, darunter Fernzugriffe, Telemetrie, Schlüsselkontrolle, Unterauftragnehmer, Backup, SLA und Exit-Regeln.
Zwölf Fragen an Cloud- und KI-Anbieter
- Welche juristische Gesellschaft schließt den Vertrag?
- Wo werden Nutzdaten, Metadaten, Logs und Backups verarbeitet?
- Welche Unterauftragnehmer erhalten Zugriff oder verarbeiten Daten?
- Wer kann administrative Zugriffe freigeben und nachvollziehen?
- Wer erzeugt, besitzt und rotiert die Verschlüsselungsschlüssel?
- Welche Daten nutzt der Anbieter für Training oder Produktverbesserung?
- Welche Aufbewahrungs- und Löschfristen gelten tatsächlich?
- Welche SLA, RPO und RTO werden vertraglich zugesagt?
- Wie häufig werden vollständige Wiederherstellungen getestet?
- Welche Zertifikate oder Prüfberichte bestehen für welchen Umfang?
- Wie lassen sich Daten, Konfigurationen und Protokolle exportieren?
- Was geschieht bei Kündigung, Anbieterwechsel oder Insolvenz?
Allgemeine Sicherheitsversprechen beantworten diese Fragen nicht, denn die Nachweise müssen zum konkreten Produkt und zum vereinbarten Betrieb passen.
So treffen Sie die Entscheidung
- Beschreiben Sie den Anwendungsfall. Halten Sie Aufgabe, Nutzer, Datenquellen und erwartete Ausgaben fest.
- Bestimmen Sie den Schutzbedarf. Bewerten Sie Vertraulichkeit, Integrität und Verfügbarkeit. Berücksichtigen Sie Personenbezug, Geschäftsgeheimnisse und mögliche Schäden.
- Zeichnen Sie den Datenweg. Erfassen Sie Speicherorte, Konnektoren, Logs, Backups, Support und Unterauftragnehmer.
- Formulieren Sie notwendige Kontrollen. Definieren Sie Anforderungen an Zugriff, Schlüssel, Isolation, Löschung, Wiederherstellung und Exit.
- Vergleichen Sie Betriebsmodelle. Wählen Sie das einfachste Modell, das die Anforderungen nachweisbar erfüllt. Halten Sie verbleibende Risiken und Verantwortlichkeiten fest.
So vermeiden Sie unnötig komplexe Infrastruktur, ohne bei wichtigen Kontrollen Abstriche zu machen.
Was Unternehmen nicht automatisch brauchen
Viele KI-Projekte benötigen keine Private Cloud, und auch Personenbezug verlangt nicht automatisch lokale Hardware. Die Herkunft eines Anbieters löst ebenfalls nicht jedes Sicherheitsproblem.
Eine vollständige Cloud-Strategie muss nicht vor jedem begrenzten Pilot stehen. Ein sauber abgegrenzter Anwendungsfall kann mit anonymisierten oder öffentlichen Daten beginnen.
Eine dokumentierte Freigabe bleibt wichtig, damit Beschäftigte die erlaubten Werkzeuge und Datenklassen kennen. Eine Plattform kann Regeln technisch durchsetzen, den Beschäftigten die Entscheidung im Alltag aber nicht abnehmen. Die Anforderungen an KI-Kompetenz nach Artikel 4 des EU AI Act betreffen genau diese organisatorische Arbeit.
Unsere KI-Schulungen verbinden deshalb die praktische Nutzung mit Datenschutz und Governance. Für Führungskräfte behandelt Claude für Entscheider zusätzlich Produktauswahl, Verträge und Einführung.
Fazit
Welche Infrastruktur passt, lässt sich weder am Etikett „sensible Daten“ noch am Serverstandort ablesen. Ausgangspunkt sind die Daten, der Zweck und die benötigten Kontrollen.
Zeichnen Sie zuerst den vollständigen Datenweg, denn nachvollziehbare Zugriffe, Speicherung, Löschung und Exit sprechen für das SaaS-Modell. Fehlt eine notwendige Kontrolle, sollten Sie eine private oder getrennte Umgebung prüfen.
Das Betriebsmodell nimmt dem Unternehmen die Verantwortung nicht ab. Eine dokumentierte Entscheidung mit klaren Nachweisen macht jedoch sichtbar, welche Risiken akzeptiert wurden und wer sie trägt.
Häufige Fragen
Welche Unternehmensdaten dürfen in ChatGPT, Claude oder Copilot eingegeben werden?
Das hängt vom freigegebenen Produkt, Vertrag, Zweck und Schutzbedarf ab. Öffentliche Inhalte sind meist unkritisch, während vertrauliche oder personenbezogene Daten eine gesonderte Freigabe benötigen.
Ist Private Cloud dasselbe wie On-Premises?
Nicht zwingend, denn eine Private Cloud kann im eigenen Gebäude oder bei einem Dienstleister stehen. Sie kann selbst betrieben oder vollständig gemanagt werden.
Verlangt der EU AI Act eine Private Cloud für sensible Daten?
Nein, der AI Act schreibt kein allgemeines Betriebsmodell vor. Je nach System gelten jedoch Anforderungen an Risikomanagement, Dokumentation und menschliche Aufsicht, wie der vollständige Verordnungstext bei EUR-Lex zeigt.
Wie vermeiden Unternehmen Vendor Lock-in?
Prüfen Sie offene Schnittstellen, Exportformate, Dokumentation, Vertragslaufzeiten und Übergabepflichten. Ein praktischer Exit-Test ist aussagekräftiger als das Versprechen „kein Lock-in“.
Über den Autor
Stephan Hannach ist zertifizierter Atlassian- und KI-Trainer und begleitet Unternehmen bei der Einführung von Claude und Atlassian-Werkzeugen.
Hinweis
Dieser Beitrag bietet eine allgemeine Orientierung und ist keine Rechtsberatung, denn die konkrete Anwendung hängt vom Einzelfall ab. Bei Zweifeln fragen Sie eine Rechtsanwältin oder einen Rechtsanwalt.
Quellen
Stand aller Angaben: 31. Juli 2026.
- Europäische Union: Datenschutz-Grundverordnung, Verordnung (EU) 2016/679. eur-lex.europa.eu
- Datenschutzkonferenz: Orientierungshilfe KI und Datenschutz. datenschutzkonferenz-online.de
- Bundesamt für Sicherheit in der Informationstechnik: C5-Kriterienkatalog. bsi.bund.de
- Europäische Kommission: Cloud Sovereignty Framework. commission.europa.eu
- U.S. Department of Justice: CLOUD Act. justice.gov
- Europäische Kommission: Angemessenheitsbeschlüsse für internationale Datenübermittlungen. commission.europa.eu
- Europäische Union: KI-Verordnung, Verordnung (EU) 2024/1689. eur-lex.europa.eu