Referenz-Story: Souveränität ausschreiben - wie aus einem Anspruch prüfbare Kriterien werden
Wie eine Landes-IT eine souveräne Private Cloud im offenen Verfahren ausgeschrieben hat: Exit-Fähigkeit als Hauptkriterium, Open Source mit Staffel, Air-Gap als Pflicht. Drei Entscheidungen aus dem Mandat.
Anfang 2026 bin ich in ein Mandat bei einer Landes-IT eingestiegen, die eine eigene Private Cloud beschaffen wollte: Hardware im eigenen Rechenzentrum, darauf eine Cloud-Plattform mit Self-Service, Kubernetes und Managed-Datenbanken, Betrieb zunächst durch den Anbieter. Die Unterlagen für das offene Verfahren lagen in einer Vorfassung vor. Meine Aufgabe war, sie fachlich zu prüfen und bis zur Veröffentlichungsreife zu bringen - Leistungsscheine, Kriterienkatalog und Preisblatt, in täglichen Abstimmungen mit dem Projektteam des Kunden.
Die Vorgaben waren ambitioniert und politisch klar: Daten mit hohem Schutzbedarf nur in Deutschland, kein Vendor-Lock-in, Open Source wo immer möglich, vorbereitet für KI-Workloads - und nach einer Übergangsphase sollte der Kunde den Betrieb selbst übernehmen und die Plattform vollständig vom Internet getrennt betreiben können. Das Wort „Souveränität” stand über allem. Die eigentliche Arbeit bestand darin, daraus etwas zu machen, das sich in einem Vergabeverfahren auch bewerten lässt.
Drei Entscheidungen aus dem Mandat halte ich für übertragbar.
Entscheidung 1: Souveränität in bewertbare Kriterien übersetzen
In einem offenen Verfahren wird nicht verhandelt. Was nicht im Kriterienkatalog steht, spielt bei der Wertung keine Rolle, und was dort nur als Absichtserklärung steht, lässt sich nicht nachprüfbar bewerten. Ein Satz wie „die Lösung muss souverän sein” hilft der Vergabestelle am Ende wenig.
Wir haben den Anspruch deshalb auf zwei Ebenen heruntergebrochen. Was zwingend ist, wurde zum Ausschlusskriterium: sofortige Offline-Fähigkeit, eine vollständige REST-API, ein Terraform-Provider, eine Open-Source-kompatible Laufzeitumgebung. Wer das nicht erfüllt, ist raus - egal wie gut der Rest aussieht. Was graduell besser oder schlechter sein kann, wurde zum gewichteten Bewertungskriterium mit Punkteskala, etwa der Open-Source-Anteil, gestaffelt von wenigen Prozent bis zu einem sehr hohen Anteil.
Das klingt nach Formalie, ist aber vermutlich der wichtigste Schritt. Erst mit dieser Übersetzung wird aus einem politischen Anspruch eine Anforderung, gegen die sich Angebote vergleichen lassen - und die einer vergaberechtlichen Prüfung standhält.
Entscheidung 2: Exit-Fähigkeit als Hauptkriterium, nicht als Vertragsanhang
Exit-Klauseln gibt es in fast jedem Cloud-Vertrag. In der Praxis hängt die Wechselfähigkeit aber selten am Vertrag, sondern eher daran, ob man den Betrieb überhaupt übernehmen könnte: Sind die Komponenten offen? Ist das Wissen dokumentiert? Kommt man an die Automatisierung heran?
Deshalb stand die Exit-Fähigkeit im Kriterienkatalog nicht als Nebenbedingung, sondern mit demselben Gewicht wie das Lieferkonzept des Anbieters: Bewertet wurde, wie überzeugend der Anbieter darlegt, dass der Kunde den Betrieb nach der Übergangsphase vollständig übernehmen kann. Daneben stand die Kompatibilität zu Public-Cloud-Standards als eigenes Kriterium - auch das eine Frage der Wechselfähigkeit, nur aus einer anderen Perspektive gedacht.
Ehrlicherweise macht das die Angebotserstellung für die Bieter aufwendiger, auch die Wertung wird anspruchsvoller als bei reinen Preis-Leistungs-Kennzahlen. Für mich ist das aber genau der Kern von Souveränität: weniger der Eigenbetrieb an sich als die realistische Möglichkeit, ihn übernehmen oder den Dienstleister wechseln zu können.
Entscheidung 3: Die Unterlagen gegeneinander lesen
Eine Ausschreibung dieser Größe besteht aus mehreren Leistungsscheinen, die oft von verschiedenen Menschen geschrieben werden - Hardware, Plattform, Security, IT-Service-Management. Jeder Schein ist für sich schlüssig. Die Probleme entstehen an den Stellen, an denen sie sich überschneiden.
Ein typisches Beispiel für diese Art von Bruch: Die Plattform ist als Service des Anbieters beschrieben, gleichzeitig soll sie später komplett ohne externen Zugriff laufen. Beides zusammen geht nur, wenn vorab explizit festgelegt wird, wie das konkret aussehen soll. Ähnliches gilt für Service-Level-Werte, die an zwei Stellen unterschiedlich angegeben sind, oder für Formulierungen aus einem anderen Verfahrenstyp, die in einem offenen Verfahren schlicht nicht passen. Solche Stellen findet man nicht beim Lesen eines einzelnen Dokuments, sondern erst, wenn die Unterlagen quer gegeneinander geprüft werden - am besten mit einer Liste, welche Anforderung wo definiert ist.
Dazu gehört auch ein Abgleich, der gerne vergessen wird: die Ausschlusskriterien gegen den realen Anbietermarkt. Mindestumsätze, Zertifikate und Referenzen sind jeweils für sich gut begründet. In Summe können sie den Kreis möglicher Bieter aber stärker verengen, als man beabsichtigt hat. Das sollte vor der Veröffentlichung klar sein und bewusst entschieden werden.
Was ich mitnehme
Souveränität ist in Ausschreibungen zuerst mal eine Übersetzungsaufgabe. Der Anspruch ist meist schnell formuliert. Die Arbeit ist, ihn in Kriterien zu gießen, die messbar, gewichtet und untereinander widerspruchsfrei sind. Die Exit-Fähigkeit gehört dabei für mich nach vorn, weil sie am ehesten zeigt, ob die gewünschte Unabhängigkeit auch im Betrieb umgesetzt werden kann.
Weiterführend aus dem Blog: KI-Ausschreibungen: Was der öffentliche Sektor wirklich sucht und IT-Security im öffentlichen Sektor.
Steht bei Ihnen eine Cloud-Beschaffung oder eine Souveränitätsentscheidung an? Genau dafür gibt es unser Cluster Architektur & Transformation im regulierten Umfeld - vom Architektur-Review mit klarem Urteil bis zur Begleitung von Ausschreibungen. Oder direkt: Erstgespräch vereinbaren.