Open Standards gegen Lock-in: Warum digitale Souveränität technische Regeln braucht

Digitale Abhängigkeit sieht im Alltag oft harmlos aus. Eine Behörde kann ihre Daten zwar „exportieren“, aber nur in einem Format, das außerhalb der bisherigen Software kaum sauber weiterverarbeitet werden kann. Ein Unternehmen hat seine Prozesse in die Cloud verlagert, merkt dann aber, dass nicht nur die Daten, sondern auch Identitäten, Zugriffsrechte, Automatismen und Schnittstellen am bisherigen Anbieter hängen. Eine Schule kauft ein bequemes Komplettpaket ein und stellt Jahre später fest, dass jeder Wechsel teuer, chaotisch und politisch riskant geworden ist.

Genau dort beginnt das, was in der Debatte über digitale Souveränität oft zu abstrakt klingt. Souverän ist digital nicht, wer „irgendetwas mit KI“ oder „eine europäische Plattform“ besitzt. Souverän ist, wer Optionen hat: den Anbieter wechseln, Daten mitnehmen, Systeme koppeln, Bausteine austauschen und Regeln selbst setzen kann. Und diese Optionen entstehen nicht aus Imagekampagnen, sondern aus technischen Standards.

Lock-in ist kein Nebeneffekt, sondern eine Machtstruktur

Vendor Lock-in bedeutet mehr als nur hohe Wechselkosten. Es beschreibt eine Lage, in der ein System zwar formal genutzt, aber praktisch nicht mehr frei gestaltet werden kann. Genau so beschreibt es auch die europäische Initiative zu offenen Standards in der IT-Beschaffung: Wer Änderungen, Erweiterungen oder neue Komponenten nur noch beim bisherigen Anbieter einkaufen kann, verliert Flexibilität, Verhandlungsmacht und oft auch Geld.

Das Problem entsteht auf mehreren Ebenen gleichzeitig. Da sind erstens proprietäre Formate, in denen Informationen zwar vorliegen, aber nur in einer bestimmten Software vollständig lesbar bleiben. Da sind zweitens Schnittstellen, die zwar technisch existieren, aber so unvollständig, teuer oder speziell gestaltet sind, dass andere Systeme nur mit Mühe andocken können. Und da ist drittens die organisatorische Gewohnheit: Teams werden auf ein Ökosystem trainiert, Prozesse werden darum herum gebaut, Archive und Vorlagen wachsen mit. Irgendwann ist nicht nur die Technik gebunden, sondern die gesamte Praxis.

Definition: Was digitale Souveränität in diesem Kontext heißt

Digitale Souveränität bedeutet nicht digitale Autarkie. Gemeint ist die reale Fähigkeit, technische Entscheidungen selbstbestimmt zu treffen, Abhängigkeiten zu begrenzen und Systeme ohne Erlaubnis eines einzelnen Anbieters weiterzuentwickeln.

Deshalb ist Lock-in nicht bloß ein Beschaffungsthema. Es ist eine Frage darüber, wer in digitalen Infrastrukturen die Spielregeln setzt.

Offene Standards sind keine Nebensache, sondern Exit-Infrastruktur

Wenn über offene Standards gesprochen wird, denken viele zuerst an Dateiendungen. Das ist zu klein. Standards betreffen Dateiformate, aber ebenso Protokolle, Programmierschnittstellen, Identifikatoren, Metadaten, Sicherheitsverfahren und gemeinsame Bedeutungen von Datenfeldern.

Das offene Web ist genau deshalb so mächtig geworden, weil es auf gemeinsam nutzbaren Regeln beruht. Die W3C-Webarchitektur empfiehlt ausdrücklich, bestehende Standards wiederzuverwenden, Formate versionierbar zu halten und Erweiterungen so zu bauen, dass Interoperabilität nicht zerstört wird. Genau das ist der Grund, warum ein Browser nicht für jede einzelne Website von demselben Hersteller stammen muss wie der Server, auf dem sie läuft.

Offene Standards schaffen also kein Paradies. Aber sie schaffen Austauschbarkeit unter Bedingungen. Sie sorgen dafür, dass ein Dokument nicht an eine einzige Anwendung gefesselt bleibt, dass eine Schnittstelle nicht nur für ein einziges Partnerprodukt gedacht ist und dass neue Anbieter überhaupt eine Chance haben, in bestehende Ökosysteme einzusteigen.

Die eigentliche Pointe ist dabei unbequem: Offenheit ist nicht der natürliche Zustand digitaler Märkte. Sie muss entworfen, dokumentiert, getestet, gepflegt und manchmal regulatorisch erzwungen werden.

Interoperabilität ist mehr als Technik

Das europäische European Interoperability Framework ist deshalb interessant, weil es Interoperabilität nicht auf Kabel und APIs reduziert. Dort geht es um rechtliche, organisatorische, semantische und technische Interoperabilität. Außerdem nennt das Framework als Leitprinzipien ausdrücklich Offenheit, Wiederverwendbarkeit sowie technologische Neutralität und Datenportabilität.

Das wirkt zunächst bürokratisch, trifft aber einen entscheidenden Punkt: Zwei Systeme können formal Daten austauschen und trotzdem nicht sinnvoll zusammenarbeiten. Wenn ein Feld in System A „Status“ heißt, in System B aber etwas anderes bedeutet, entsteht kein offener Markt, sondern nur eine teure Fehlübersetzung. Wenn eine Verwaltung Daten exportieren darf, aber rechtlich nicht weiterverwenden kann, fehlt ebenfalls Souveränität. Und wenn ein Anbieter eine API dokumentiert, aber jede wichtige Funktion außerhalb dieser API hält, ist die Schnittstelle eher Schaufenster als Befreiung.

Der aktuelle Interoperable Europe Act der EU-Kommission macht aus dieser Einsicht inzwischen Politik. Die Kommission beschreibt den Rechtsrahmen als Instrument zur Stärkung grenzüberschreitender Interoperabilität; der Act trat am 11. April 2024 in Kraft. Besonders aufschlussreich ist, dass er verpflichtende Interoperabilitätsbewertungen für relevante IT-Änderungen vorsieht. Dahinter steckt ein reifer Gedanke: Nicht erst nach dem Lock-in fragen, wenn der Vertrag ausläuft, sondern schon beim Design prüfen, welche Abhängigkeiten gerade gebaut werden.

Warum das Thema gerade in der Cloud so scharf wird

In klassischen Softwarewelten ließ sich Lock-in oft noch als Frage von Lizenzen oder Dateiformaten erzählen. In der Cloud ist das schwieriger. Dort hängen Anwendungen an Speicherklassen, Datenbanken, Identitätsdiensten, Event-Systemen, proprietären Automatisierungen und Betriebswerkzeugen. Ein reiner Datenexport löst das Problem dann kaum. Wer nur Tabellen herausbekommt, aber nicht die Logik, Rechte, Trigger und Betriebsabläufe, ist noch nicht wirklich frei.

Genau deshalb ist der EU Data Act so relevant. In der offiziellen Zusammenfassung wird deutlich, dass Cloud-Wechsel nicht als freundliche Kulanz der Anbieter verstanden werden, sondern als regelbedürftiger Vorgang. Verträge müssen den Wechsel zu einem anderen Dienst regeln, die Übergangsfrist soll höchstens 30 Kalendertage betragen, Anbieter müssen beim Wechsel unterstützen, und für viele Dienste sind offene Schnittstellen vorgesehen, damit Portabilität und Interoperabilität nicht nur auf dem Papier existieren.

Das ist ein wichtiger Perspektivwechsel. Digitale Souveränität bedeutet hier nicht, alles selbst zu hosten. Sie bedeutet, dass ein Kunde den Exit planen kann, bevor er in Panik gerät. Wer keine tragfähige Exit-Option hat, besitzt keine souveräne Cloud-Strategie, sondern nur Komfort auf Abruf.

Open Source hilft, aber ersetzt Standards nicht

An diesem Punkt wird oft verkürzt argumentiert: Man müsse bloß Open Source einsetzen, dann verschwinde das Problem. Das stimmt nur teilweise. Open-Source-Software kann Quellcode prüfbar machen, lokale Anpassungen erlauben und Monopole abschwächen. Sie ist oft ein starker Verbündeter offener Standards. Aber auch offene Software kann neue Abhängigkeiten schaffen, wenn sie nur mit einem bestimmten Hosting-Angebot sauber funktioniert, wenn Datenmodelle schlecht dokumentiert sind oder wenn es faktisch nur einen dominanten Dienstleister für Betrieb und Pflege gibt.

Umgekehrt gilt: Auch proprietäre Produkte können auf offenen Standards aufbauen und dadurch Wechselkosten begrenzen. Das macht sie nicht automatisch harmlos, aber es verschiebt die Machtbalance. Der Punkt ist also nicht „offen gegen geschlossen“ als moralische Pose. Der Punkt ist, ob zentrale Bestandteile eines Systems übertragbar, dokumentiert und anschlussfähig sind.

Wer Souveränität will, muss Beschaffung ernst nehmen

Viele Abhängigkeiten entstehen nicht im Quellcode, sondern in Ausschreibungen, Verträgen und Lastenheften. Die europäische Seite zu Open Standards für ICT Procurement formuliert das bemerkenswert klar: Lock-in führt zu weniger Wettbewerb, höherer Trägheit und schlechterem Gegenwert für öffentliche Mittel. Dort wird auch eine Schätzung genannt, nach der eine Verdopplung der Bieterzahl die Vertragswerte in der EU-Beschaffung um etwa neun Prozent senken könnte.

Das ist keine romantische Open-Source-Parole, sondern nüchterne Marktlogik. Wenn ein Auftraggeber in Ausschreibungen faktisch nur Produkte zulässt, die rückwärtskompatibel zu proprietären Altlasten eines einzelnen Anbieters sind, dann ist der Markt bereits vor der Angebotsphase verengt. Offenheit beginnt deshalb oft mit scheinbar trockenen Fragen:

• Sind Datenexporte vollständig und maschinenlesbar?

• Sind Schnittstellen öffentlich dokumentiert und diskriminierungsfrei nutzbar?

• Werden Identitäten, Rollen und Protokolle nach gängigen Standards abgebildet?

• Ist eine Migration mit realistischem Aufwand vorgesehen oder nur theoretisch möglich?

• Werden proprietäre Komfortfunktionen so dominant, dass sie den Exit später faktisch verhindern?

Wer diese Fragen nicht stellt, beschafft meist nicht nur Software, sondern zukünftige Ohnmacht.

Warum Staaten und Unternehmen jetzt plötzlich von Souveränität reden

Der Begriff „digitale Souveränität“ hat natürlich auch eine geopolitische Schicht. Lieferkettenkrisen, geopolitische Spannungen, extraterritoriale Rechtsrisiken und Konzentration im Cloud-Markt haben das Thema sichtbar gemacht. Aber die technisch ernsthafte Seite des Begriffs ist viel unspektakulärer und gerade deshalb wichtiger: Souveränität entsteht aus Diversifizierung, Portabilität, Interoperabilität und internen Kompetenzen.

Wie praktisch diese Sicht inzwischen geworden ist, zeigt sogar die aktuelle Beschaffungspolitik der EU-Kommission. In ihrer Meldung vom 17. April 2026 zur Vergabe eines Sovereign-Cloud-Rahmens betont sie Diversifizierung und Resilienz und nennt ausdrücklich die Vermeidung potenziellen Lock-ins durch einen einzelnen Anbieter als Ziel. Auch hier also dieselbe Logik: Nicht die perfekte Einheitslösung soll retten, sondern die Fähigkeit, Abhängigkeiten aktiv zu begrenzen.

Merksatz: Der Kern der Sache

Digitale Souveränität beginnt nicht im Rechenzentrum, sondern in den Regeln, nach denen Daten, Schnittstellen und Wechselpfade gestaltet werden.

Die unbequeme Wahrheit: Offene Standards kosten zuerst Mühe

Es wäre unseriös, das Thema zu idealisieren. Offene Standards sind nicht automatisch elegant. Manche sind sperrig, manche mehrdeutig, manche werden schlecht implementiert. Wer Standards ernst nimmt, muss Dokumentation pflegen, Versionen managen, Testfälle definieren und intern Kompetenz aufbauen. Kurzfristig wirkt ein geschlossenes Komplettsystem oft bequemer.

Genau deshalb ist Lock-in so verführerisch. Er verkauft sich anfangs als Reibungslosigkeit. Erst später zeigt sich der Preis: teure Migrationen, gebremste Innovation, schwächere Verhandlungsmacht, größere Sicherheits- und Compliance-Risiken, weil kritisches Wissen und technische Kontrolle außerhalb der eigenen Organisation liegen.

Die Frage ist also nicht, ob offene Standards anstrengend sind. Die Frage ist, wann die Komplexität bezahlt wird: am Anfang als gestaltbare Architekturarbeit oder später als erzwungene Krisenmigration.

Was ein souveränerer Standard-Ansatz konkret bedeuten würde

Für Behörden, Unternehmen, Hochschulen und Bildungseinrichtungen ergibt sich daraus eine ziemlich klare Agenda.

• Offene Formate sollten dort Standard sein, wo Wissen langfristig archiviert, geteilt oder weiterverarbeitet werden muss.

• APIs sollten vollständig dokumentiert, versioniert und von Anfang an als Wechselschnittstellen gedacht werden.

• Verträge für Plattform- und Cloud-Dienste brauchen belastbare Exit-Klauseln, realistische Migrationsfenster und klare Verantwortlichkeiten.

• Semantische Modelle müssen mitgedacht werden, damit Daten nach einem Export nicht nur vorhanden, sondern auch verständlich bleiben.

• Eigene technische Kompetenz darf nicht vollständig ausgelagert werden, sonst nützt selbst der beste Standard wenig.

Das ist kein nostalgischer Rückzug aus der digitalen Moderne. Im Gegenteil: Gerade hochkomplexe digitale Systeme brauchen offene Regeln, wenn sie innovativ bleiben sollen. Denn nur dort, wo Komponenten austauschbar und anschlussfähig sind, kann Neues entstehen, ohne dass jedes Mal das gesamte Ökosystem um Erlaubnis gefragt werden muss.

Offene Regeln sind die eigentliche Infrastruktur der Freiheit

Die Debatte über digitale Souveränität wird oft mit zu großen Symbolen geführt: europäische Champions, Superclouds, technologische Unabhängigkeit. All das mag politisch verständlich sein, trifft aber nicht den Kern. Die eigentliche Infrastruktur digitaler Freiheit besteht aus kleineren, zäheren, technisch unspektakulären Dingen: offenen Spezifikationen, portablen Daten, dokumentierten Schnittstellen, sauberer Semantik und Beschaffung, die künftige Wechsel ernst nimmt.

Open Standards sind deshalb nicht bloß Ingenieursfolklore. Sie sind Machtbegrenzung in technischer Form. Wer sie vernachlässigt, kauft Bequemlichkeit auf Kredit. Wer sie ernst nimmt, schafft Spielraum: für Wettbewerb, für Innovation und für die Fähigkeit, digitale Systeme später noch selbst gestalten zu können.

Wenn dich interessiert, wie ähnliche Machtfragen in anderen digitalen Feldern auftauchen, dann passen auch diese Beiträge dazu: Open Source: Warum unbezahlter Code das Rückgrat der digitalen Welt geworden ist, Datenschutz als Freiheitsfrage: Warum Privatsphäre politisch und nicht privat ist und Digitale Identität: Zwischen Bequemlichkeit, Kontrolle und Ausschluss.

Instagram

Facebook

Weiterlesen

• Open Source: Warum unbezahlter Code das Rückgrat der digitalen Welt geworden ist

• Datenschutz als Freiheitsfrage: Warum Privatsphäre politisch und nicht privat ist

• Digitale Identität: Zwischen Bequemlichkeit, Kontrolle und Ausschluss