Cloud, On-Premise oder Self-hosted: Automatisierung passend betreiben

Kurzantwort: Welches Betriebsmodell passt zur Automatisierung?

Das passende Betriebsmodell ist die Variante, in der Daten, Systemwirkungen und Betriebsverantwortung für den konkreten Prozess beherrschbar bleiben. Cloud eignet sich häufig für standardisierte Dienste, elastische Last und schnell verfügbare Plattformfunktionen. On-Premise kann bei enger Nähe zu lokalen Fachsystemen, speziellen Latenz- oder Offline-Anforderungen sinnvoll sein. Self-hosting schafft eigene Konfigurations- und Betriebsverantwortung, unabhängig davon, ob die Infrastruktur im eigenen Gebäude oder bei einem Provider steht.

Viele Unternehmen benötigen keine Entweder-oder-Entscheidung. Beispielsweise können Eingang und Modellservice als Cloud-Dienst laufen, während sensible Referenzdaten lokal abgefragt und schreibende Aktionen über einen begrenzten Connector im Unternehmensnetz ausgeführt werden. Entscheidend ist, dass jeder Übergang, jede Verantwortlichkeit und jedes Ausfallszenario ausdrücklich entworfen wird.

Cloud, On-Premise und Self-hosted sauber voneinander trennen

Cloud bezeichnet einen Dienst, der standardisiert über ein Netz bereitgestellt wird und dessen Ressourcen durch den Anbieter oder eine darüberliegende Plattform betrieben werden. On-Premise bedeutet, dass die betreffende Infrastruktur in der eigenen Umgebung oder unter direkter organisatorischer Kontrolle betrieben wird. Self-hosted beschreibt, dass das Unternehmen oder sein beauftragter Dienstleister die Anwendung selbst installiert, konfiguriert und betreibt. Self-hosted ist deshalb nicht automatisch On-Premise.

Auch Managed Hosting ist eine andere Achse. Es beantwortet, wer den laufenden Betrieb übernimmt, nicht allein, wo die Technik steht. Eine Cloud-Anwendung kann weitgehend vom Anbieter betrieben sein; eine selbst gehostete Anwendung auf einer Cloud-VM bleibt dagegen in vielen Schichten Verantwortung des Kunden oder seines Betriebsdienstleisters.

Den Prozess in betreibbare Komponenten zerlegen

Eine Automatisierung besteht selten aus einem einzigen System. Typische Komponenten sind Eingangskanal, Dateiprüfung, Datenaufbereitung, Orchestrierung, Modell- oder Regelservice, kurzzeitige Zustandsdaten, Wissensspeicher, Connectoren und die führenden Fachsysteme. Für jede Komponente werden Daten, Rechte, Verfügbarkeit, Skalierung, Wartung und Abhängigkeiten festgehalten.

Erst danach wird der Betriebsort gewählt. Ein Modellservice kann extern liegen, während der Connector nur geprüfte Parameter erhält und im internen Netz arbeitet. Umgekehrt kann eine lokale Modellkomponente sinnvoll sein, während Ticketing oder Monitoring als Cloud-Dienst betrieben werden. Die Architektur folgt dem Prozess und seinen Grenzen, nicht der Vertriebsbezeichnung einer Plattform.

• Eingang und Originaldaten: Wo entstehen sie und wo müssen sie beweissicher bleiben?
• Verarbeitung: Welche Inhalte werden extrahiert, verändert oder zwischengespeichert?
• Entscheidung: Welche Regel oder welches Modell erzeugt welchen Vorschlag?
• Wirkung: Welche Komponente darf welches Zielsystem lesen oder verändern?
• Nachweis: Wo liegen Version, Freigabe, Protokoll und technische Bestätigung?
• Betrieb: Wer überwacht, aktualisiert, sichert und unterstützt jede Schicht?

Sechs Kriterien statt pauschaler Vor- und Nachteile bewerten

Eine allgemeine Liste von Cloud-Vorteilen und On-Premise-Nachteilen hilft nur begrenzt. Bewerten Sie jede Komponente gegen denselben Kriterienkatalog. Ein Kriterium darf die übrigen nicht verdecken: Ein lokaler Betrieb schützt Daten nicht automatisch, wenn Rechte und Updates schlecht organisiert sind; ein geprüfter Cloud-Dienst löst nicht automatisch die fachliche Verantwortung.

• Daten und Schutzbedarf: Welche Inhalte, Metadaten und Protokolle werden verarbeitet?
• Systemnähe: Welche lokalen Anwendungen, Geräte oder Identitätsdienste müssen erreichbar sein?
• Latenz und Offline-Fähigkeit: Was geschieht bei langsamer oder unterbrochener Verbindung?
• Last und Veränderung: Wie stark schwanken Volumen, Modellgröße oder Funktionsbedarf?
• Betriebsfähigkeit: Wer beherrscht Updates, Monitoring, Backup, Incident und Wiederherstellung?
• Wechselbarkeit: Welche Daten, Konfigurationen und Schnittstellen lassen sich in eine andere Umgebung überführen?

Verantwortung je Dienstschicht ausdrücklich zuordnen

Der BSI-Kriterienkatalog C5 weist darauf hin, dass Informationssicherheit eines Cloud-Dienstes nicht allein beim Anbieter liegt. Abhängig vom Dienstmodell bleiben Kundenseite und beauftragte Betreiber für Identitäten, Konfiguration, Betriebssystem, Anwendung oder Daten verantwortlich. Ein Prüfbericht ist daher ein Eingang für die eigene Bewertung, keine pauschale Freigabe des konkreten Einsatzes.

Erstellen Sie eine Verantwortungsmatrix für Infrastruktur, Plattform, Anwendung, Daten, Identität, Schlüssel, Schnittstellen, Monitoring, Backup, Wiederherstellung und fachliche Freigabe. Jede Zeile benötigt eine ausführende und eine entscheidende Rolle sowie einen Vertretungsweg. Formulierungen wie „macht der Anbieter“ werden durch den konkreten Leistungsumfang und den Nachweis ersetzt.

Hybride Datenwege mit klaren Vertrauensgrenzen entwerfen

Eine hybride Architektur ist sinnvoll, wenn unterschiedliche Komponenten unterschiedliche Anforderungen haben. Sie darf jedoch nicht zu einem unkontrollierten Dauerexport interner Daten führen. Zwischen den Zonen werden erlaubte Datenfelder, Richtung, Zweck, Verschlüsselung, Identität, Protokollierung und Fehlerverhalten festgelegt. Ein Connector erhält nur die Rechte, die seine konkrete Aktion benötigt.

Bei einer Unterbrechung muss das Verhalten eindeutig sein. Ein Eingang kann gegebenenfalls gepuffert werden; eine schreibende Aktion darf nach einem Timeout nicht blind wiederholt werden. Lokale und externe Zustände werden über eine gemeinsame Vorgangs-ID abgeglichen. Veraltete Queues, doppelte Übergaben und Teilerfolge gehören in einen sichtbaren Klärungsweg.

• Datenminimierung vor dem Übergang statt nachgelagerter Bereinigung
• separate Identität und minimaler Rechteumfang je Connector
• ausgehende Ziele und eingehende Aufrufe technisch begrenzen
• Vorgangs-ID, Idempotenz und Bestätigung über Zonengrenzen führen
• Ausfallmodus, Puffergrenze und manuelle Übernahme definieren
• Protokolle ohne unnötige vertrauliche Inhalte korrelierbar halten

Kosten über den Lebenszyklus statt nur pro Ausführung vergleichen

Ein Cloud-Preis pro Nutzung und ein Serverpreis sind nicht direkt vergleichbar. Berücksichtigen Sie Einrichtung, Integration, Identitätsanbindung, Netze, Lizenzen, Updates, Beobachtbarkeit, Bereitschaft, Backups, Wiederherstellungstests, Kapazitätsreserve und Änderungen. Self-hosting kann variable Plattformkosten reduzieren, erhöht aber je nach System die eigene Betriebs- und Aktualisierungsarbeit.

Für die Entscheidung werden keine pauschalen Einsparungen unterstellt. Erfassen Sie stattdessen Kostenarten und Verantwortungsstunden im vorgesehenen Lastprofil. Ein Szenario für Normalbetrieb, Spitzenlast, Störung und Anbieterwechsel zeigt eher, welche Variante tragfähig ist als eine Momentaufnahme aus dem Pilot.

Sicherheitsnachweise auf den konkreten Dienst beziehen

Der BSI C5 strukturiert Kriterien unter anderem zu Organisation, Personal, physischen Kontrollen, Betrieb, Identitäten, Kryptografie, Portabilität und Umgang mit Ermittlungsanfragen. Für die Auswahl ist wichtig, auf welche konkrete Dienstleistung, Region und Prüfperiode ein Nachweis gilt. Ausnahmen, Unterauftragnehmer und Umfeldparameter müssen zum eigenen Einsatz passen.

On-Premise und Self-hosting benötigen dieselben Fragen in eigener Verantwortung: Wer patcht die Plattform, überwacht privilegierte Zugriffe, schützt Sicherungen, testet Wiederherstellung und reagiert auf Schwachstellen? Die Entscheidung sollte dokumentieren, welcher Nachweis je Kontrolle vorliegt und welche Lücke durch eine eigene Maßnahme geschlossen wird.

Exit, Export und Rückführung vor Vertragsabschluss prüfen

Die Verordnung (EU) 2023/2854 enthält Vorgaben zum Wechsel von Datenverarbeitungsdiensten. Artikel 25 verlangt, dass Rechte und Pflichten zum Wechsel in einem schriftlichen Vertrag festgehalten werden; vorgesehen sind unter anderem der Wechsel zu einem anderen Dienst oder gegebenenfalls zu einer On-Premise-Infrastruktur. Welche Regel im Einzelfall greift, ist rechtlich und vertraglich zu prüfen. Technische Wechselbarkeit entsteht nicht allein durch eine Vertragsklausel.

Ein Exit-Test klärt, welche Daten und digitalen Artefakte exportierbar sind, in welchem Format sie vorliegen und wie Identitäten, Schlüssel, Workflows, Prompts, Regeln, Wissensindizes, Protokolle und offene Vorgänge übertragen werden. Proprietäre Funktionen werden als Abhängigkeit dokumentiert. Nach einem Testimport muss ein definierter Beispielprozess in der Zielumgebung funktionieren; ein erfolgreicher Dateidownload genügt nicht.

Beispielarchitektur: E-Mail-Aufträge hybrid verarbeiten

Ein Unternehmen empfängt Aufträge per E-Mail. Der Maildienst stellt Nachrichten in einer kontrollierten Eingangszone bereit. Ein externer Modellservice erhält nur den für Klassifikation und Extraktion erforderlichen Inhalt; Original und verbindliche Dokumentversion bleiben im internen Dokumentenspeicher. Ein lokal betriebener Connector gleicht Kundennummer, Artikel und Dubletten gegen das ERP ab.

Das Modell erzeugt keinen ERP-Auftrag. Es liefert einen strukturierten Vorschlag mit Unsicherheiten. Die interne Prozessschicht prüft Pflichtfelder, Stammdaten, Berechtigung und Freigabestatus und legt erst danach den Vorgang an. Bei Ausfall des externen Dienstes bleibt die Nachricht im Eingang und wird manuell oder später verarbeitet; bei einem Timeout des ERP wird der Status abgeglichen, bevor eine Wiederholung möglich ist. Diese Aufteilung kann sinnvoll sein, wenn sie aus Anforderungen abgeleitet und betrieblich beherrscht wird – nicht weil „hybrid“ an sich besser wäre.

Das Betriebsmodell in acht Schritten auswählen

Die Entscheidung wird als Architektur- und Betriebsfreigabe dokumentiert. Datenschutz, Informationssicherheit und weitere Fachstellen werden passend zu Daten und Wirkung einbezogen; dieser Leitfaden ersetzt keine rechtliche Einzelfallprüfung.

• 1. Zielprozess, Fallklassen, Daten und geplante Systemwirkungen beschreiben.
• 2. Komponenten, Schnittstellen, Identitäten und führende Systeme inventarisieren.
• 3. Schutzbedarf, Systemnähe, Latenz, Last und Offline-Verhalten je Komponente bewerten.
• 4. Cloud-, On-Premise-, Self-hosted- und Hybridvarianten auf denselben Datenfluss anwenden.
• 5. Verantwortung, Nachweise, Kostenarten und Betriebsfähigkeit je Schicht zuordnen.
• 6. Ausfall, Wiederanlauf, Providerstörung und eingeschränkten Betrieb praktisch testen.
• 7. Export, Exit und Rückführung mit einem Beispielprozess nachweisen.
• 8. Entscheidung, Grenzen und Auslöser für eine Neubewertung freigeben.