--- title: "Souveränität ist eine Architekturentscheidung, keine Hosting-Frage" url: "https://hurukan.com/de/blog/souveraenitaet-ist-eine-architekturentscheidung" description: "Ein inländisches Rechenzentrum macht nicht souverän. Das tun Schlüssel, das Modell des Geschäfts und der Ausstieg – und die entscheidet das Design." --- # Souveränität ist eine Architekturentscheidung, keine Hosting-Frage 14\. April 2026·4 Min. Lesezeit·Redaktion Die Hand eines Technikers hält einen kleinen Messingschlüssel vor einen verschlossenen graphitfarbenen Serverschrank, ein schmales blaues Statuslicht an der Schranktür und kühler Dunst des Serverraums dahinter Ein Unternehmen beschließt, die Kontrolle über seine Daten zu wollen. Das Projekt bekommt ein Budget, ein Anbieter wird ausgewählt, und achtzehn Monate später laufen die Systeme in einem Rechenzentrum im Inland, zu Vertragsbedingungen, mit denen die Rechtsabteilung zufrieden ist. Dem Vorstand wird gemeldet, das Unternehmen sei nun souverän. Dann stellt jemand eine praktische Frage. Wenn der Anbieter im nächsten Jahr die Preise kräftig anhebt – wie lange würde der Ausstieg dauern? Niemand kann antworten. Das Datenmodell gehört zum Produkt des Anbieters. Die Freigabeketten sind in dessen Admin-Masken konfiguriert. Die Verschlüsselungsschlüssel liegen in seinem Schlüsseldienst, und das Sprachmodell, das Kundenantworten entwirft, wird über sein Konto aufgerufen. Die Server sind umgezogen. Die Abhängigkeit nicht. Die Ursache: Souveränität wurde als Frage des _Wo_ behandelt, dabei ist sie eine Frage dessen, _wer was tun kann, ohne zu fragen_. Der Standort zählt: Er entscheidet, welches Recht gilt und wer zur Herausgabe von Daten gezwungen werden kann. Aber er ist eine Eigenschaft unter mehreren, und die einzige, die man von der Stange kaufen kann. Die anderen müssen ins Design eingebaut werden. ## Wo „souverän“ unbemerkt scheitert **Schlüssel, die woanders liegen.** Liegen die Verschlüsselungsschlüssel in einem Dienst, den der Anbieter kontrolliert, kann der Anbieter die Daten lesen – und jeder, der ihn dazu zwingen kann, ebenso. Daten, die in Ihrem Land gespeichert und mit einem Schlüssel verschlüsselt sind, den Sie nicht halten, sind verortet, nicht kontrolliert. **Ein Modell des Geschäfts, das Sie nicht mitnehmen können.** Jedes System bietet einen Export. Nur wenige exportieren Beziehungen, Regeln und Historie in einer Form, die ein anderes System laden kann. Ein Satz Tabellen ohne die Bedeutung ihrer Spalten ist ein Backup, kein Ausstieg. **Logik, die in der Konfiguration lebt.** Freigabegrenzen, Preisregeln, Routing: Sind das Klicks in einer proprietären Maske, lassen sie sich weder lesen noch prüfen noch mitnehmen. Die Arbeitsweise des Unternehmens steckt in einem Format, das nur ein Produkt versteht. **Ein Modell, ein Anbieter.** Läuft jede sprachliche Arbeit über ein einziges externes Modell unter einem einzigen Konto, hängt die Handlungsfähigkeit des Unternehmens nun an Preisen, Verfügbarkeit und Nutzungsbedingungen dieses Anbieters. Das ist ein Lieferkettenrisiko, und es taucht selten in einem Risikoregister auf. **Ein Ausstieg, den niemand geprobt hat.** Ein Ausstiegsplan, der nie durchgespielt wurde, ist eine Hoffnung. Zum ersten Mal getestet wird, ob das Unternehmen umziehen kann, meist in dem Moment, in dem es muss. ## Was stattdessen zu gestalten ist Behandeln Sie Souveränität als eine Reihe von Eigenschaften der Architektur, von denen jede überprüfbar ist – von jemandem, der sich nicht auf das Wort des Anbieters verlassen muss. **Die Schlüssel gehören Ihnen.** Verschlüsselungsschlüssel werden auf Infrastruktur erzeugt und gehalten, die das Unternehmen kontrolliert, und wer die Plattform betreibt, kann sie nicht ohne Mitwirkung des Unternehmens nutzen. **Das Modell des Unternehmens reist mit den Daten.** Objekte, Beziehungen und Regeln sind in einer offenen, lesbaren Form beschrieben und versioniert, sodass das, was das Unternehmen unter einem Auftrag oder einem Kunden versteht, mit den Datensätzen gehen kann. Genau das ist die Aufgabe einer [Ontologie](https://hurukan.com/de/system/ontologie): Die Bedeutung liegt neben den Daten, nicht im Produkt eines Anbieters. **Logik ist etwas, das man lesen kann.** Regeln und Prozesse werden als prüfbare Artefakte mit Historie gespeichert, nicht als Zustand einer Konfigurationsmaske. Hat ein Agent eine Regel geändert, hat die Änderung einen Urheber, einen Grund und eine Freigabe. **Modelle sind austauschbar.** Sprachliche Arbeit wird je Aufgabe geroutet: Sensible Arbeit kann an ein Modell auf Ihrer eigenen Hardware gehen, allgemeine an ein Frontier-Modell, und beide lassen sich austauschen, ohne die Prozesse umzuschreiben, die sie nutzen. Wo ein [kleines Modell auf eigener Hardware](https://hurukan.com/de/blog/kleine-modelle-auf-eigener-hardware) gut genug ist, sollte die Architektur es Ihnen erlauben, es zu nutzen. **Der Stack ist Open Source, wo es darauf ankommt.** Open Source garantiert keine Souveränität, beseitigt aber die eine Abhängigkeit, die sich nie wegverhandeln lässt: die Erlaubnis, die Software überhaupt zu betreiben. Nach diesem Design wird Hurukan gebaut. Seine [Ebene Sicherheit und Souveränität](https://hurukan.com/de/system/sicherheit-und-souveraenitaet) setzt Berechtigungen auf dem Server durch, protokolliert jede Änderung danach, ob sie von einem Menschen, einem Agenten oder dem System stammt, läuft auf Infrastruktur, die das Unternehmen wählt, und legt den Ausstieg von Anfang an schriftlich fest. Es ist im Aufbau, nicht im Einsatz – was hier beschrieben wird, ist also das Design, keine Erfolgsbilanz. ## Ein Test für diese Woche Nehmen Sie einen Prozess, der zählt. Die Fakturierung ist ein guter Kandidat, weil sie Kunden, Preise, Zahlungen und das Recht berührt. Beantworten Sie fünf Fragen schriftlich: 1. Wo liegen die Verschlüsselungsschlüssel für diese Daten, und wer kann sie nutzen? 2. Wenn Sie heute alles exportierten – könnte ein anderes System nachbilden, was eine Rechnung hier _bedeutet_: ihre Zustände, ihre Freigaberegeln, ihre Verknüpfungen mit Aufträgen und Zahlungen? 3. Wo liegen die Regeln für diesen Prozess, und kann ein Mensch sie lesen, ohne sich im Werkzeug des Anbieters anzumelden? 4. Welche externen Modelle berühren diese Daten, unter wessen Konto, und was passiert mit dem Prozess, wenn das Modell eine Woche lang nicht verfügbar ist? 5. Wann hat zuletzt jemand diesen Prozess oder eine Kopie davon auf eine andere Infrastruktur verlagert? Jede Frage, deren Beantwortung länger als einen Tag dauert, markiert eine Abhängigkeit, die niemand gestaltet hat. Die Antworten zeigen auch, welche Daten die meiste Sorgfalt verdienen – darum geht es in einem eigenen Beitrag darüber, [welche Daten im Haus bleiben müssen](https://hurukan.com/de/blog/welche-daten-im-haus-bleiben-muessen). Als Hosting-Vertrag gekaufte Souveränität hält bis zur ersten harten Verhandlung. In Schlüssel, Modell, Logik und Ausstieg hineingestaltete Souveränität ist noch da, wenn die Verhandlung schwierig wird. Die [Hurukan-Übersicht](https://hurukan.com/de) zeigt, wie die Ebenen zusammenpassen. - Datensouveränität - Vendor-Lock-in - Verschlüsselungsschlüssel - Open Source ## Weiterlesen - [Eine Identität für Menschen und Agenten: wer was tun darf](https://hurukan.com/de/blog/eine-identitaet-fuer-menschen-und-agenten) - [Laufender Zustand und Aufzeichnung: die zwei Gedächtnisse eines Unternehmensbetriebssystems](https://hurukan.com/de/blog/laufender-zustand-und-aufzeichnung-zwei-gedaechtnisse)