Wo Kundendaten bei Cloud-Automatisierung tatsächlich landen
Ein Cloud-Automatisierer ist ein Vermittler. Er holt die Daten aus dem Quellsystem, verarbeitet sie auf seiner Infrastruktur und schreibt das Ergebnis ins Zielsystem. Das bedeutet, dass jeder einzelne Datensatz durch fremde Systeme läuft: Rechnungsbeträge, Kundennamen, Lieferadressen, im Zweifel der komplette Inhalt einer Mail.
Für sich genommen ist das kein Problem, es ist ein Fall von Auftragsverarbeitung, und dafür gibt es Verträge. Die praktischen Fragen fangen danach an. Wie lange werden Ausführungsdaten gespeichert, damit man Fehler nachvollziehen kann? Wo stehen die Server, auf denen diese Protokolle liegen? Welche Subunternehmer sind eingebunden, und in welchen Ländern sitzen die? Die Antworten stehen in den Unterlagen, aber sie stehen selten in der Übersicht, die beim Kauf gezeigt wird.
Dazu kommt eine Frage, die selten gestellt wird: was passiert bei einem Anbieterwechsel mit den Daten, die bereits durchgelaufen sind. Löschfristen stehen in den Bedingungen, die Umsetzung prüft im Zweifel niemand nach. Das ist kein Vorwurf an einzelne Anbieter, sondern eine strukturelle Eigenschaft von Vermittlern.
Der Punkt, der im Alltag am meisten unterschätzt wird, sind die Ausführungsprotokolle. Ein Automatisierungsdienst, der zur Fehlersuche die verarbeiteten Daten mitschreibt, hat damit eine Kopie der Nutzdaten, Wochen oder Monate lang, je nach Einstellung. Wer nur den Datenfluss betrachtet und die Protokolle übersieht, bewertet die Lage falsch.
Was self-hosted an Datenhoheit ändert
Bei einem self-hosted Betrieb entfällt der Vermittler. Die Workflow-Engine läuft auf Infrastruktur, die dem Kunden zuzurechnen ist. Die Daten wandern zwischen den Systemen des Betriebs hin und her, ohne dass ein Dritter sie zwischenspeichert. Es gibt keinen Cloud-Zwischenspeicher, über den man einen Vertrag schließen müsste, weil es diesen Zwischenspeicher schlicht nicht gibt.
Bei mir kommt eine zweite Entscheidung dazu: Die Workflows verarbeiten Daten in Echtzeit und legen sie nicht ab. Ein Beleg wird ausgelesen, geprüft, übergeben. Was gespeichert wird, ist das Ergebnis im Zielsystem und die revisionssichere Ablage, die ohnehin gebraucht wird. Keine dauerhafte Kopie in einer Zwischendatenbank. Das reduziert nicht nur die rechtliche Angriffsfläche, es reduziert auch die Menge an Orten, an denen bei einem Zwischenfall gesucht werden muss.
Ganz ohne Dritte geht es nicht, und das gehört sauber benannt: Wo eine KI-Schicht unstrukturierte Dokumente auswertet, geht der Inhalt an einen Modellanbieter. Genau deshalb steht das Prinzip AI last, not first nicht nur aus Kostengründen da. Je mehr ein Workflow über deterministische Regeln löst, desto weniger Inhalte verlassen überhaupt das Haus.
EU-Rechenzentrum vs. on-premise
Self-hosted heißt nicht automatisch, dass ein Server im Serverraum steht. Beide Varianten erfüllen dieselbe Anforderung, sie unterscheiden sich im Betrieb. On-premise bedeutet: die Maschine steht im Haus, die Daten verlassen das Netz nicht, und die Verantwortung für Strom, Backup und Ausfallsicherheit liegt beim Betrieb. Das passt, wenn ohnehin eine Serverlandschaft existiert und jemand sie betreut.
Ein EU-Rechenzentrum bedeutet: eine eigene Instanz bei einem Hoster mit Standort in der EU. Verfügbarkeit, Stromversorgung und physische Sicherheit kommen vom Anbieter, die Instanz selbst bleibt exklusiv. Das ist der pragmatischere Weg für Betriebe ohne eigene IT-Mannschaft, und die Datenlage ist eine andere als bei einem geteilten Cloud-Dienst: Es geht um Hosting, nicht um Verarbeitung durch einen Dienstleister.
Die Entscheidung fällt in der Praxis selten über Datenschutz, sondern über Betriebsführung. Wer nachts niemanden hat, der einen hängenden Dienst neu startet, ist im Rechenzentrum besser aufgehoben. Wer aus anderen Gründen ohnehin alles im Haus hält, bleibt konsequent dabei.
Was das im Betrieb kostet
Der ehrliche Vergleich hat zwei Seiten. Self-hosted kostet Infrastruktur und Betreuung: eine Instanz, Backups, Updates, gelegentlich ein Blick auf Logs. In Summe ist das bei den meisten Projekten ein niedriger zweistelliger Monatsbetrag plus Betreuungsaufwand, den ich in der Regel mit übernehme. Dieser Betrag ist konstant, unabhängig vom Volumen.
Cloud kostet nichts an Infrastruktur und dafür pro Vorgang. Solange wenig läuft, ist das günstiger. Ab dem Punkt, an dem ein Prozess wirklich in Betrieb ist, dreht sich das Verhältnis, und zwar dauerhaft: der Preis steigt genau dann, wenn die Automatisierung ihren Zweck erfüllt. Wer die beiden Modelle über drei Jahre rechnet statt über das erste, kommt regelmäßig zu einem anderen Ergebnis als im Angebotsvergleich.
Was in beiden Modellen gleich bleibt, ist der Aufwand für Änderungen. Ein Lieferant stellt sein Format um, eine Freigabegrenze ändert sich, ein Zielsystem bekommt ein Update. Das ist kein Argument für oder gegen self-hosted, aber es gehört in die Rechnung: ein Workflow ist kein Möbelstück, das man einmal aufstellt. Wer diesen Posten weglässt, vergleicht zwei Angebote, von denen keines vollständig ist.
Meine Position ist deshalb keine grundsätzliche. Für einen Prozess, der zwanzigmal im Monat läuft und keine sensiblen Daten berührt, ist ein Cloud-Abo völlig in Ordnung. Für Belegverarbeitung, Rechnungsdaten und alles was durch die Buchhaltung geht, ist self-hosted der Weg, der beide Fragen gleichzeitig löst: die nach den Kosten und die nach der Datenhoheit.