Prüfung 1: Datenklassifizierung — was fließt durch das System?
Nicht „das Unternehmen" braucht eine Betriebsform, sondern jeder Anwendungsfall einzeln. Und der erste Blick gilt den Daten:
- Öffentlich oder unkritisch: Marketingtexte, öffentliche Dokumente, allgemeine Recherche. Hier spricht wenig gegen leistungsfähige Cloud-Modelle.
- Intern und geschäftskritisch: Kalkulationen, Verträge, Strategie. Hier beginnt die Abwägung: Cloud mit EU-Verarbeitung und sauberer Auftragsverarbeitung — oder lokal.
- Besonders geschützt: Gesundheitsdaten, Mandats- und Verfahrensdaten, Personaldaten, Sozialdaten. Hier führt an lokaler oder streng kontrollierter Verarbeitung selten ein Weg vorbei — nicht aus Prinzip, sondern weil Berufsgeheimnisse und Spezialgesetze den Spielraum definieren.
Ein oft übersehener Punkt: Auch Betriebsdaten sind sensibel. Ticketinhalte, Konfigurationsdaten, Systemlandkarten beschreiben Ihre Organisation von innen — wer sie liest, kennt Ihre Angriffsfläche. Die Klassifizierung endet nicht bei den Fachdaten.
Prüfung 2: Prozesskritikalität — was passiert, wenn es ausfällt oder falsch liegt?
Die zweite Prüfung fragt nicht nach Daten, sondern nach Folgen:
- Wie lange darf der Prozess stehen? Ein Ausfall des Marketing-Assistenten ist ärgerlich. Ein Ausfall des Systems, ohne das keine Akte aufgeht, legt die Organisation lahm. Je kritischer die Verfügbarkeit, desto schwerer wiegen Abhängigkeiten von Internetanbindung, Anbieter-Status und Lizenzservern — und desto attraktiver wird lokaler Betrieb mit definierter Rückfallebene.
- Was kostet eine falsche Ausgabe? Je höher die Fehlerfolgekosten, desto wichtiger werden Nachvollziehbarkeit und Freigabe-Logik — also die Entscheidungsarchitektur nach dem Ausbildungsprinzip. Sie ist betriebsform-unabhängig, aber lokal oft leichter lückenlos zu protokollieren.
Prüfung 3: Exit-Fähigkeit — wie komme ich wieder raus?
Die dritte Prüfung wird am häufigsten vergessen und entscheidet am Ende über die Souveränität der ganzen Konstruktion: Kann ich Modell, Plattform oder Anbieter wechseln, ohne den Prozess neu zu bauen?
Konkret heißt das: austauschbare Modelle hinter einer eigenen Schnittstelle, exportierbare Daten in offenen Formaten, dokumentierte Workflows. Diese Anforderungen gelten für alle drei Betriebsformen — aber sie verschieben die Rechnung: Ein lokales offenes Modell ist per Definition wechselbar. Ein tief integrierter Cloud-Dienst ist es oft nur auf dem Papier.
Das Ergebnis ist fast immer: hybrid — aber begründet
Wer die drei Prüfungen für seine realen Anwendungsfälle durchführt, landet selten bei einem Lager. Das typische Bild in meinen Projekten:
- Cloud für unkritische Breite: Recherche, Textentwürfe, allgemeine Assistenz — mit EU-Verarbeitung und klaren Nutzungsregeln.
- Lokal für die sensiblen Kerne: Dokumente mit Berufsgeheimnis, Personaldaten, kritische Fachprozesse — auf eigener Hardware, mit lokalem Modell, ohne Datenabfluss.
- Hybrid verbunden durch Architektur: Ein Routing entscheidet pro Anfrage, wohin sie darf — nach Datenklasse, nicht nach Bequemlichkeit.
Der Unterschied zum ideologischen Hybrid („wir machen irgendwie beides") liegt im Wort begründet: Für jede Datenklasse und jeden Prozess ist dokumentiert, warum er läuft, wo er läuft. Das ist zugleich die Vorarbeit für Datenschutz-Dokumentation und die Systeminventur, die der AI Act ohnehin verlangt.
Die Kurzform für Ihre nächste Diskussion
Wenn in Ihrem Haus wieder Cloud gegen On-Premise diskutiert wird, ersetzen Sie die Glaubensfrage durch drei Sachfragen:
- Welche Datenklasse fließt durch diesen konkreten Anwendungsfall?
- Was kostet Ausfall oder Fehler dieses konkreten Prozesses?
- Wie sieht der Exit aus — heute, nicht irgendwann?
Die Betriebsform, die dann übrig bleibt, ist keine Meinung mehr. Sie ist eine Ableitung — und genau so sollte sie sich anfühlen.
Quellen und weiterführende Links
- DSGVO, Verordnung (EU) 2016/679 (EUR-Lex, offizieller Text)
- EU AI Act, Verordnung (EU) 2024/1689 (EUR-Lex, offizieller Text)
Alle Links geprüft am 4. August 2026. Externe Inhalte können sich ändern.