Die Grenzen digitaler Unabhängigkeit

Im Januar 2022 migrierte eine deutsche Kreisverwaltung — rund 800 Beschäftigte, zwei IT-Vollzeitkräfte — ihre E-Mail von Microsoft 365 zu einer selbst gehosteten Open-Xchange-Installation. Die Migration war technisch sauber. Sechs Monate später lief ein TLS-Zertifikat unbemerkt ab — das IT-Team kämpfte gleichzeitig mit einem Storage-Ausfall. Ausgehende E-Mails schlugen drei Tage lang lautlos fehl. Verträge blieben unsigniert. Eine Ausschreibungsfrist verstrich. Niemand wusste Bescheid, bis ein Lieferant anrief und fragte, warum das Angebot nicht eingegangen sei.

Die Verwaltung hatte Souveränität über ihre E-Mail erreicht. Sie hatte auch Souveränität über ihre Ausfälle erreicht.

Dieses Muster — technisch gelungene Migration, gefolgt von Betriebsausfall durch Unterfinanzierung — wiederholt sich in den Fallstudien auf dieser Seite. Schleswig-Holstein investierte 9 Millionen Euro und ein dediziertes Team. Die französische Gendarmerie baute über zwei Jahrzehnte eine interne IT-Organisation auf. Die Kreisverwaltung oben investierte in eine Migration, aber nicht in den Betrieb, um sie aufrechtzuerhalten. Der Unterschied im Ergebnis war nicht die Software — es war die Personalausstattung.

Jeder andere Beitrag auf dieser Seite argumentiert für die Reduzierung der Abhängigkeit von nicht-europäischen Anbietern. Dieser stellt die Frage, die dieses Argument offen lässt: Wie weit sollte man gehen?

Die Antwort ist nicht „so weit wie möglich". Sie ist eine Kalkulation — Souveränitätswert gegen Betriebskosten, Sicherheitsrisiko bei Unterfinanzierung und Opportunitätskosten der Umleitung von Expertise von der eigentlichen Aufgabe. Manchmal spricht diese Kalkulation für Souveränität. Manchmal nicht. Den Unterschied zu kennen trennt Strategie von Ideologie.

Die Souveränitätsprämie

Jedes System, das Sie selbst betreiben, kostet mehr als ein Managed Service — nicht bei den Lizenzgebühren, sondern bei der Aufmerksamkeit. Das ist die Souveränitätsprämie, und sie wird routinemäßig unterschätzt.

Eine verwaltete Datenbank auf AWS (RDS) bedeutet: Amazon kümmert sich um Patches, Backups, Failover, Monitoring und Skalierung. Eine selbst gehostete PostgreSQL-Instanz bei Hetzner bedeutet: Sie kümmern sich um all das — genauer gesagt, Ihr Team kümmert sich darum, zusätzlich zu allem anderen, was es bereits tut. Die monatliche Rechnung ist niedriger. Die Gesamtbetriebskosten sind es möglicherweise nicht.

Ein konkretes Szenario: eine Organisation mit 200 Mitarbeitern, die fünf Kerndienste selbst hostet — E-Mail (Open-Xchange), Dateisynchronisation (Nextcloud), Identität (Keycloak), eine PostgreSQL-Datenbank und einen Kubernetes-Cluster.

• Hosting-Kosten: circa 800 €/Monat auf Hetzner-Dedicated-Servern. Das Äquivalent auf AWS: 3.000–4.000 €/Monat. Die 3–5-fache Ersparnis ist real.
• Betriebskosten: Jeder Dienst braucht Monitoring, Patching, Backup-Verifizierung, Kapazitätsplanung und Incident Response. Bei konservativ geschätzten 6 Stunden pro Dienst pro Monat sind das 30 Stunden — rund 20 % der Kapazität eines Senior Engineers. Bei 80 €/Stunde vollbelastet: 2.400 €/Monat Personalkosten.
• Ausfallkosten: Wenn AWS RDS ausfällt, reagiert Amazons Bereitschaftsteam in Minuten. Wenn Ihre selbst gehostete PostgreSQL samstags um 2 Uhr morgens ausfällt, reagiert Ihr Team — sofern Sie Wochenend-Bereitschaft haben. Ein einziger 8-Stunden-Ausfall kostet mehr an verlorener Produktivität als ein Monat Hosting-Ersparnis.
• Opportunitätskosten: Der Senior Engineer, der fünf Infrastrukturdienste wartet, baut nicht am Produkt, verbessert nicht den Workflow und schult nicht das Team.

Die Nettorechnung: 800 €/Monat Hosting + 2.400 €/Monat Personal = 3.200 €/Monat — vergleichbar mit der Hyperscaler-Rechnung, der Sie entkommen wollten, aber mit dem Betriebsrisiko auf Ihrer Seite. Die Ersparnis ist nur real, wenn Sie das Team bereits haben. Wenn Sie dafür einstellen müssen, sind die ersten zwei Jahre ein Nettoverlust.

Nichts davon bedeutet, dass Self-Hosting falsch ist. Es bedeutet, dass Self-Hosting eine Investition ist, und Investitionen nur dann Rendite bringen, wenn sie angemessen finanziert werden. Ein selbst gehosteter E-Mail-Server, betrieben von einem kompetenten Team mit professionellem Monitoring, ist souveräner und potenziell sicherer als ein Managed Service. Ein selbst gehosteter E-Mail-Server, betrieben von einem unterbesetzten Team, das gleichzeitig die Firewall, den Desktop-Bestand und die Druckerwarteschlange betreut, ist ein Sicherheitsvorfall, der nur darauf wartet, einzutreten.

Die Souveränitätsfrage lautet nicht „Sollten wir das kontrollieren?" Sondern: „Können wir das auf dem Niveau an Zuverlässigkeit und Sicherheit betreiben, das der Anwendungsfall erfordert?" Wenn die Antwort Nein lautet, ist Souveränität kein Vorteil — sie ist eine Belastung.

Wo proprietäre Lösungen tatsächlich besser sind

Es gibt eine Version des Souveränitätsarguments, die lautet: „Jede Open-Source-Alternative ist gut genug; man muss sich nur mehr Mühe geben." Das stimmt nicht, und so zu tun kostet Glaubwürdigkeit. Einige proprietäre Lösungen sind heute messbar besser als ihre Open-Source-Entsprechungen — nicht weil Open Source grundsätzlich unterlegen ist, sondern weil bestimmte Probleme die Art konzentrierter, nachhaltiger Investition belohnen, die milliardenschwere Umsätze ermöglichen.

Kollaboratives Editieren von Dokumenten

Das ist die sichtbarste Lücke. Collabora Online und OnlyOffice sind funktional und verbessern sich, aber Echtzeit-Co-Authoring — die Erfahrung, dass mehrere Personen gleichzeitig im selben Dokument tippen, mit sofortiger Cursor-Verfolgung, Live-Kommentaren und nahtloser Konfliktlösung — funktioniert in Google Docs und Microsoft 365 nach wie vor flüssiger. Für Teams, bei denen Echtzeit-Zusammenarbeit der Kern-Workflow ist (Redaktionen, Rechtsentwürfe, Vorstandskommunikation), ist diese Lücke nicht theoretisch. Sie ist eine tägliche Reibung.

Die ehrliche Empfehlung: Für die Erstellung von Dokumenten — Schreiben, Formatieren, Einzelarbeit — ist LibreOffice voll konkurrenzfähig. Für Echtzeit-Zusammenarbeit evaluieren Sie Collabora oder OnlyOffice anhand Ihres tatsächlichen Workflows. Wenn die Lücke für Ihr Team relevant ist, gestehen Sie das ein — statt so zu tun, als existiere sie nicht.

Videokonferenzen im großen Maßstab

Jitsi funktioniert gut für Meetings mit bis zu 30–50 Teilnehmern. Für Großveranstaltungen — All-Hands-Meetings mit 500 Personen, Webinare mit Bildschirmfreigabe und Breakout-Räumen, hybride Events mit Studio-Qualität-Streaming — haben Teams, Zoom und Google Meet Hunderte Millionen Dollar in Infrastruktur investiert, die kein Open-Source-Projekt bisher erreicht hat. Die Qualitätslücke bei kleinen Meetings hat sich erheblich verringert. Die Lücke bei Großveranstaltungen nicht.

KI-Frontmodelle

Der souveräne KI-Stack ist real und für die meisten Anwendungsfälle praktikabel. Aber die Spitze — die leistungsfähigsten Reasoning-Modelle, die größten Kontextfenster, die fortschrittlichsten multimodalen Fähigkeiten — bleibt die Domäne von OpenAI, Anthropic und Google. Open-Weight-Modelle holen schnell auf, und für 90 % der geschäftlichen Anwendungsfälle reicht ein Mistral- oder LLaMA-Deployment auf europäischer Infrastruktur. Aber für die verbleibenden 10 % — Spitzenforschung, komplexe mehrstufige Reasoning-Aufgaben, fortgeschrittene Code-Generierung — sind die proprietären Frontmodelle messbar besser.

Managed-Service-Ökosysteme

Das ist der strukturelle Vorteil, nicht ein einzelnes Produkt. AWS bietet über 200 Managed Services. Jeder einzelne eliminiert eine Kategorie operativer Arbeit. Ein Startup, das auf Lambda, API Gateway, DynamoDB, Cognito und CloudFront aufbaut, hat den Betrieb für fünf Infrastruktur-Kategorien effektiv ausgelagert. Das Äquivalent bei europäischen Anbietern erfordert fünf separate Tools, fünf Konfigurationsaufwände, fünf Monitoring-Setups. Die einzelnen Tools existieren. Das integrierte Ökosystem nicht.

Die ehrliche Einschätzung: Für Organisationen, die tief in Hyperscaler-Ökosysteme eingebettet sind, sind die Wechselkosten nicht nur finanziell — sie sind architektonisch. So zu tun, als sei dem nicht so, hilft niemandem.

Die Self-Hosting-Falle

Self-Hosting ist der schärfste Ausdruck digitaler Unabhängigkeit — und derjenige, der ohne ausreichende Ressourcen am wahrscheinlichsten schiefgeht.

Software deployen ist ein Projekt. Software betreiben ist eine Verpflichtung. Das Muster wiederholt sich branchenübergreifend: Eine Organisation hostet einen Dienst selbst, feiert das Go-live und stellt dann — Monate oder Jahre später — fest, dass den Dienst zuverlässig zu betreiben schwieriger ist als ihn zu installieren.

Die Sicherheitsdimension

Ein Managed-Service-Anbieter beschäftigt dedizierte Sicherheitsteams, betreibt Bug-Bounty-Programme, deployt Patches innerhalb von Stunden und überwacht rund um die Uhr auf Eindringlinge. Eine selbst gehostete Installation ist genau so sicher wie das Team, das sie betreibt — nicht mehr.

Betrachten Sie Keycloak, den Open-Source-Identity-Provider, der für souveränes Identitätsmanagement empfohlen wird. Keycloak ist exzellente Software. Aber eine Keycloak-Instanz, die drei Minor-Versionen hinter den Sicherheitspatches zurückliegt, weil das Team mit anderen Prioritäten beschäftigt war, ist schlechter als Okta — nicht weil Okta souveräner ist, sondern weil Okta von einem Team gepatcht wird, dessen einzige Aufgabe das Patchen ist.

Das ist kein Argument gegen Self-Hosting von Keycloak. Es ist ein Argument dafür, die betriebliche Kapazität zu finanzieren, um es richtig zu machen. Wenn das Budget existiert, ein Team einzustellen oder zu beauftragen, das die Instanz aktuell, überwacht und gesichert hält — ist selbst gehostetes Keycloak die bessere Wahl, Punkt. Wenn das Budget nicht existiert, wird der Souveränitätsgewinn durch den Sicherheitsverlust aufgewogen.

Der blinde Fleck beim Monitoring

Abstürze sind offensichtlich. Schleichende Degradation nicht — und sie ist der gefährlichere Fehlermodus. Ein Managed Service benachrichtigt jemanden, wenn die Datenbank-Antwortzeit sich verdoppelt, wenn ein Zertifikat abzulaufen droht, wenn die Festplattenauslastung 80 % überschreitet. Selbst gehostete Systeme haben Alerting nur dann, wenn jemand es gebaut, getestet und die Alerting-Infrastruktur selbst wartet. Monitoring ist Infrastruktur. Es braucht eigene Wartung.

Die Kreisverwaltung aus dem Einstieg hat ihre E-Mail nicht verloren, weil der Server abgestürzt ist. Sie hat sie verloren, weil ein Zertifikat ablief und niemand zugeschaut hat. Kein Technologieproblem — ein Ressourcenproblem. Und Ressourcenprobleme verschwinden nicht, nur weil die Software Open Source ist.

Ein Entscheidungsrahmen

Die Kreisverwaltung aus dem Einstieg und die französische Gendarmerie betreiben dieselbe Kategorie Software. Die eine verlor drei Tage lang ihre E-Mail; die andere betreibt seit zwei Jahrzehnten 103.000 Linux-Arbeitsplätze mit 40 % niedrigeren Gesamtbetriebskosten als die Windows-Alternative. Der Unterschied ist nicht die Technologie. Es ist nicht einmal das Budget. Es ist die Übereinstimmung zwischen Ambition und betrieblicher Kapazität — und die Bereitschaft, über die Lücke ehrlich zu sein.

Die folgende Matrix bietet eine strukturierte Methode, diese Einschätzung vorzunehmen: wo Souveränität Wert schafft und wo sie Risiko schafft.

Achse 1: Souveränitätswert

Wie stark reduziert die Kontrolle über dieses System Ihr Konzentrationsrisiko?

• Hoch: Identitätsmanagement, E-Mail, zentrale Datenspeicherung. Diese Systeme enthalten Ihre sensibelsten Daten und sind am gefährlichsten unter fremder Jurisdiktion. Eine Störung hier ist existenzbedrohend.
• Mittel: Office-Suite, Dateisynchronisation, internes Messaging. Wichtig, aber eine vorübergehende Störung ist überlebbar. Die Datensensitivität variiert nach Anwendungsfall.
• Niedrig: CDN, Public-Website-Hosting, Monitoring-Tools, CI/CD-Pipelines. Diese Systeme verarbeiten wenig sensible Daten und können schnell ersetzt werden.

Achse 2: Betriebskomplexität

Wie schwer ist es, dieses System zuverlässig zu betreiben?

• Hoch: E-Mail (Deliverability), Kubernetes-Cluster, Datenbanken mit strengen Uptime-Anforderungen, Identitätsmanagement im großen Maßstab. Erfordern dedizierte Expertise und 24/7-Monitoring.
• Mittel: Dateisynchronisation (Nextcloud), Hosting statischer Seiten, einfache Anwendungsserver. Brauchen Aufmerksamkeit, sind aber mit einem kompetenten Team handhabbar.
• Niedrig: Desktop-Anwendungen (LibreOffice), Dokumentformat-Entscheidungen (ODF), Browser-Wahl. Nahezu null betrieblicher Overhead.

Die Matrix

Die obere linke Ecke (hoher Wert, niedrige Komplexität) ist der Ausgangspunkt für jede Organisation. Auf offene Dokumentformate umzustellen kostet nichts und schafft Optionalität. FIDO2-Hardware-Keys zu deployen verbessert Sicherheit und Souveränität. LibreOffice zu installieren erfordert keine Infrastruktur.

Die untere rechte Ecke (niedriger Wert, hohe Komplexität) ist der Bereich, in dem Souveränitätsbemühungen Ressourcen verschwenden. Ein eigenes CDN für eine öffentliche Website zu betreiben ist betrieblich teuer und bringt nichts — es stehen keine sensiblen Daten auf dem Spiel, und CDNs sind trivial austauschbar. Eine US-gehostete KI-API für nicht-sensible Aufgaben zu nutzen (öffentliche Dokumente zusammenfassen, Marketing-Texte generieren) ist eine pragmatische Entscheidung, wenn die Alternative darin besteht, einen GPU-Cluster für Low-Stakes-Arbeit zu deployen und zu warten.

Die schwierigen Entscheidungen liegen in der Mitte und oben rechts: Systeme, deren Kontrolle hohen Wert hat, die aber betrieblich komplex sind. Hier hängt die Entscheidung von Ressourcen ab, nicht von Prinzipien. Wenn Sie das Team und das Budget haben, hosten Sie selbst. Wenn nicht, nutzen Sie einen europäischen Managed Provider. Wenn kein adäquater europäischer Managed Provider existiert, ist ein US-Anbieter mit souveränitätsbewusstem Vertrag (Datenresidenz, Exit-Klauseln, Data-Act-Konformität) eine bessere Wahl als eine unterfinanzierte selbst gehostete Installation.

Fünf Regeln für rationale Souveränität

Aus den Mustern auf dieser Seite — den Erfolgen und Misserfolgen der Migrationen im öffentlichen Sektor, der Managed-Services-Lücke in der Cloud, der TCO-Realität souveräner Arbeitsplätze — ergeben sich fünf Regeln:

1. Zuerst die kostenlosen Gewinne einfahren

Offene Dokumentformate. FIDO2-Hardware-Keys. LibreOffice. Offene Standards. Kosten nichts, brauchen keine Infrastruktur, führen null betriebliches Risiko ein — schaffen aber mehr Optionalität als jede Server-Migration. ODF statt .docx bedeutet: Ihre Dokumente überleben einen Anbieterwechsel. Ein 50-€-FIDO2-Key eliminiert den häufigsten Angriffsvektor. Wenn Ihre Organisation das noch nicht getan hat, ist alles andere verfrüht.

2. Nie selbst hosten, was Sie nicht besetzen können

Eine selbst gehostete Nextcloud ohne Backup ist schlechter als Dropbox. Ein selbst gehostetes Keycloak ohne Patches ist schlechter als Okta. Jeder unüberwachte Dienst, den Sie betreiben, ist kein Souveränitätsgewinn — er ist eine unüberwachte Angriffsfläche. Die Regel ist einfach: Wenn Sie keine Rufbereitschaft dafür finanzieren können, können Sie es nicht selbst hosten. Nutzen Sie stattdessen einen europäischen Managed Provider — Managed Keycloak, Managed Nextcloud, Managed Matrix gibt es. Souveränität erfordert nicht, den Server selbst zu betreiben; sie erfordert, Daten unter einer Jurisdiktion zu halten, die Sie kontrollieren.

3. Datensouveränität von Software-Souveränität unterscheiden

Das sind unterschiedliche Probleme mit unterschiedlichen Lösungen. Datensouveränität — sicherzustellen, dass Ihre Daten unter einer Jurisdiktion bleiben, die Sie durchsetzen können — ist selbst mit proprietärer Software erreichbar. Das französische Bleu-Modell (Microsoft-Software auf französisch kontrollierter Infrastruktur) demonstriert dies. Software-Souveränität — sicherzustellen, dass Sie nicht von der Produkt-Roadmap eines einzigen Anbieters abhängig sind — erfordert Open Source. Sie benötigen möglicherweise das eine, das andere oder beides, abhängig von Ihrem Bedrohungsmodell. Die beiden zu verwechseln führt zu schlechten Entscheidungen.

4. Hybrid ist die Zielarchitektur, kein Kompromiss

Keine erfolgreiche Migration auf dieser Seite erreichte 100 % Souveränität — und keine versuchte es. Die Gendarmerie behielt 3 % auf Windows. Schleswig-Holstein erkennt permanente Ausnahmen an. Österreich behielt Teams für externe Meetings. Das sind keine Zugeständnisse; es sind Designentscheidungen.

Eine hybride Architektur mit dokumentierten Kriterien — „diese Systeme sind souverän, jene sind gemanagt, und hier ist warum" — ist resilienter als vollständige Abhängigkeit oder unterfinanzierte vollständige Unabhängigkeit. Das Ziel ist nicht null US-Software. Es ist kein Single Point of Failure: kein einzelner Anbieter, dessen Verschwinden Ihren Betrieb stoppt.

5. Souveränität an Resilienz messen, nicht an Reinheit

Der Test einer Souveränitätsstrategie lautet nicht „Nutzen wir irgendeine US-Software?" Sondern: „Was passiert, wenn unser größter Anbieter morgen nicht mehr verfügbar ist?" Wenn die Antwort lautet „Wir wechseln innerhalb von Tagen oder Wochen zu einer dokumentierten Alternative", funktioniert Ihre Souveränitätsstrategie — selbst wenn Sie aktuell Hyperscaler-Dienste nutzen. Wenn die Antwort lautet „Die Verwaltung steht still", hat Ihre Souveränitätsstrategie versagt — selbst wenn jeder Server Linux ausführt.

Resilienz ist das Ziel. Souveränität ist die Methode. Verwechseln Sie nicht beides.

Die fünf Fehlermodi der Souveränität

Das Argument für die Reduzierung der Abhängigkeit von nicht-europäischen Anbietern ist stichhaltig — Konzentrationsrisiko ist real, die wirtschaftliche Abhängigkeit ist messbar, und die Alternativen werden zunehmend tragfähig. Aber die Souveränitätsbewegung hat wiederkehrende Fehlermodi, die ihre eigenen Ziele untergraben. Fünf verdienen es, benannt zu werden:

Souveränitätstheater. Ein Open-Source-Tool deployen und den Sieg erklären, ohne das Operations-Team zu finanzieren, das es am Laufen hält. Das Tool steht da, ungepatcht, unüberwacht und weniger sicher als der proprietäre Dienst, den es ersetzt hat. Das Häkchen ist gesetzt. Das Risiko hat zugenommen.

100 % Reinheit als Ziel. Sich weigern, irgendeinen US-basierten Dienst zu nutzen, ungeachtet der Betriebskosten, was zu unterfinanzierten Alternativen für jedes System führt, statt zu gut finanzierten Alternativen für die Systeme, die zählen. Das Perfekte ist der Feind des Guten — und bei Infrastruktur ist das Perfekte oft der Feind des Funktionierenden.

Den Nutzer ignorieren. Die Münchner LiMux-Wende war politisch, aber der politische Fall basierte auf realen Nutzerbeschwerden. Souveränität, die die tägliche Erfahrung der Menschen verschlechtert, die die Systeme nutzen, erzeugt Widerstand — und dieser Widerstand findet irgendwann ein politisches Vehikel. Nutzererfahrung ist kein Luxus, sie ist eine Voraussetzung für Nachhaltigkeit.

Annehmen, dass europäisch vertrauenswürdig bedeutet. Ein europäisches Unternehmen unterliegt europäischem Recht — das ist ein echter struktureller Vorteil für Datensouveränität. Aber „europäisch" ist kein Qualitätssiegel. Europäische Software kann schlecht gewartet sein. Europäische Anbieter können unzureichende Sicherheit haben. Europäische Startups können von nicht-europäischen Unternehmen übernommen werden, wie der DigiD/Solvinity-Fall zeigte. Bewerten Sie Anbieter nach Kompetenz und Governance, nicht nur nach Jurisdiktion.

Transitionskosten unterschätzen. Jeder Artikel auf dieser Seite enthält eine „Ehrlich bei Trade-offs"-Dimension. Aber die aggregierten Transitionskosten — Cloud, Office, E-Mail, Identität, Betriebssystem und KI gleichzeitig zu migrieren — sind enorm. Organisationen, die versuchen, alles auf einmal zu machen, machen typischerweise nichts gut. Die Gendarmerie brauchte zwanzig Jahre. Schleswig-Holstein plant mit fünf bis sieben. Diese Zeiträume sind keine Zeichen von Langsamkeit; sie sind Zeichen von Ernsthaftigkeit.

Was folgt

Digitale Unabhängigkeit ist eine Risikomanagement-Strategie. Wie jedes Risikomanagement beinhaltet sie Trade-offs. Ein Risiko zu eliminieren (Anbieterabhängigkeit) kann ein anderes einführen (betriebliche Fragilität). Die Organisationen, die das erfolgreich navigieren, sind nicht diejenigen, die Souveränität am aggressivsten verfolgen — sondern diejenigen, die sie am intelligentesten verfolgen.

Die praktische Reihenfolge, unter Berücksichtigung der oben genannten Grenzen:

Sofort beginnen (null Kosten, null Risiko):

• Auf offene Dokumentformate umstellen. In ODF speichern, nicht in .docx. Das ist der wirkungsvollste Souveränitätsschritt, und er kostet nichts. Jede nachfolgende Migration wird einfacher, wenn Ihre Daten in offenen Formaten vorliegen.
• FIDO2-Hardware-Keys deployen für Administratoren und Führungskräfte. 50 € pro Key. Verbessert Sicherheit und Souveränität. Kein betrieblicher Overhead.
• Ihre Anbieterabhängigkeiten auditieren. Jedes kritische System seinem Anbieter, seiner Jurisdiktion und seiner Alternative zuordnen. Sie können Risiko nicht managen, das Sie nicht gemessen haben.

In diesem Quartal beginnen (niedriges Risiko, hoher Ertrag):

• LibreOffice organisationsweit deployen. Schleswig-Holstein und das italienische Militär begannen hier. Keine Infrastruktur erforderlich. Die Dokumentkompatibilitätslücke ist mit Planung handhabbar.
• Einen europäischen Cloud-Anbieter für neue Workloads evaluieren. Migrieren Sie keine bestehenden Systeme. Deployen Sie das nächste neue Projekt bei Hetzner, Scaleway oder einem SCS-zertifizierten Anbieter. Sammeln Sie Erfahrung, bevor Sie sie brauchen.

In Monaten planen (moderater Aufwand, Team-Investment nötig):

• Nextcloud, Element oder Keycloak pilotieren — aber nur, wenn Sie die betriebliche Kapazität committen können. Ein Pilot, der aus Vernachlässigung stirbt, lehrt Sie nichts. Budgetieren Sie die Personalzeit, bevor Sie die Software deployen.
• Wenn Self-Hosting nicht realistisch ist, nutzen Sie einen europäischen Managed Provider. Managed Keycloak, Managed Nextcloud, Managed Matrix — das gibt es, und es sind legitime Souveränitäts-Entscheidungen. Sie müssen den Server nicht selbst betreiben, um Daten unter europäischer Jurisdiktion zu halten.

Akzeptieren und managen (laufend):

• Einige Systeme werden beim Hyperscaler bleiben. Globales CDN, Frontier-KI-APIs für nicht-sensible Aufgaben, spezialisierte Managed Services ohne europäisches Äquivalent — das sind rationale Entscheidungen, keine Souveränitäts-Versagen. Dokumentieren Sie sie. Stellen Sie Exit-Klauseln sicher. Überprüfen Sie jährlich.
• Hybrid ist der Normalzustand. Das Ziel ist nicht 100 % Souveränität — es ist genug Souveränität, dass keine einzelne Störung katastrophal ist. Eine bewusste, dokumentierte Hybridstrategie ist resilienter als entweder vollständige Abhängigkeit oder unterfinanzierte vollständige Unabhängigkeit.

Die Organisationen, die die nächste Disruption überstehen werden — ob Lizenzänderung, Sanktionsausweitung, Preiserhöhung oder Übernahme — sind nicht diejenigen, die jeden US-Dienst ersetzt haben. Es sind diejenigen, die ihre Abhängigkeit so weit reduziert haben, dass jede einzelne Störung ein Ärgernis ist, keine Katastrophe. Sie haben dort investiert, wo es am meisten zählt — nicht Ressourcen dünn über alles verteilt.

Die Kreisverwaltung aus dem Einstieg hat das auf die teure Art gelernt: Souveränität ohne betriebliches Investment ist nur eine andere Art von Fragilität. Die Gendarmerie hat es über zwanzig Jahre gelernt: Souveränität mit Investment kumuliert zu echter Unabhängigkeit. Der Unterschied zwischen beiden ist nicht die Überzeugung — es ist die Kapazität.

Digitale Unabhängigkeit ist kein Zielzustand. Sie ist eine Fähigkeit — die Fähigkeit zu wechseln, sich anzupassen, eine Störung zu absorbieren, ohne dass der Betrieb stillsteht. Bauen Sie diese Fähigkeit dort auf, wo es zählt. Mieten Sie den Rest. Und seien Sie ehrlich darüber, was was ist.

Beginnen Sie mit unserem Überblick: Warum digital-independence.org?