9. März 2026

IT-Architektur und Vergabedesign: Das strukturelle Problem mit Managed Services

1. Erkenntnis aus dem Diskurs: Wo Technik und Vergabe aneinander vorbeilaufen

Ich habe Ehrgeiz immer ambivalent gesehen. Es gibt den Ehrgeiz, das eigene Denken kontinuierlich zu schärfen. Und es gibt den Ehrgeiz, sich über andere zu stellen. Gerade im juristischen Umfeld ist diese Spannung gut zu beobachten. Für mich ist der Maßstab die Qualität meines eigenen Denkens und Handelns.

Nach meinem letzten Artikel hat mir ein Experte für Managed IT Services sein Buch geschickt, verbunden mit der Nachricht: „Vielleicht finden Sie hier Antworten auf einige Ihrer Fragen.” Das hat mich ehrlich berührt. Weniger wegen des Buchs selbst, sondern weil es erkennbar um die gemeinsame Auseinandersetzung mit der Sache ging.

An dem Punkt musste ich auch an den Kommentar von Christoph Puppe unter diesem Artikel denken. Christoph Puppe ist ehemaliger Penetrationstester, nun Auditteamleiter für ISO 27001, tief im BSI-Grundschutz verankert und Cloud-Architektur-Experte. In der Diskussion schrieb er sinngemäß, dass Cloud-Leistungen als Self-Service-Modelle vergaberechtlich keinen wirklichen Sinn ergäben.

Der Kommentar machte eine Bruchstelle sichtbar, die in vielen Diskussionen unterbelichtet bleibt.

2. IT-Architektur entscheidet vorab – Vergabedesign verpasst Steuerungsoptionen

Technisch ist vieles gedacht, beschrieben und teilweise auch umgesetzt.

In Vergabestellen und im Vergabedesign kommt diese Logik jedoch oft nicht als echte Steuerungsoption und -struktur an. Bei KI- und LLM-basierten Leistungen tritt dieses Muster noch deutlicher hervor.

In seinem Buch beschreibt Michael Schmid sehr klar, warum insbesondere gemanagte KI-Leistungen für kritische Bereiche strukturell problematisch sind: Architektur-, Betriebs- und Verantwortungsebenen werden miteinander vermischt, die eigentlich getrennt gedacht werden müssten.

Hier liegt die Lücke, über die wir sprechen.

IT-Architektur wirkt ex ante und legt die im späteren Betrieb vorhandenen Handlungsmöglichkeiten vorab fest. Vergabe wird häufig ex post gedacht: Vergaberecht und Vergabedesign reagieren nachträglich auf diese Festlegungen, ohne die Steuerungsoptionen und weitreichenden Auswirkungen hinreichend zu antizipieren.

Die Verantwortung verbleibt beim öffentlichen Auftraggeber, auch wenn im späteren Betrieb durch architektonische, vergaberechtliche und vertragliche Festlegungen faktisch keine wirksamen Steuerungsoptionen mehr bestehen.

Cloud- und KI-Architekturen müssen daher bereits im Vergabedesign ausdrücklich festgelegt, begründet und dokumentiert werden.

Denn dort werden der Beschaffungsgegenstand, die Marktöffnung und die verbindlichen Rahmenbedingungen der Nutzung definiert. Nur auf dieser Ebene lassen sich Nutzungsspielräume, Abhängigkeiten und Exit-Fähigkeit vergaberechtlich nachvollziehbar steuern, etwa im Rahmen der Begründung von Leistungszuschnitten, der Losbildung oder des Verzichts auf eine losweise Vergabe im Vergabevermerk.

3. Steuerbarkeit hängt von der Leistungsebene ab – Managed Services verschieben Risiken, nicht Verantwortung

Die Problematik hängt davon ab, was genau als "Managed Service" bezogen wird.

Bei Infrastruktur- und Plattformleistungen (IaaS/PaaS), etwa Landing Zones, Policies oder IAM-Konfigurationen – ist ein wesentlicher Teil der Steuerungsqualität objektiv überprüfbar: Liegt eine Ressource in der EU-Region? Ist Verschlüsselung aktiv? Sind Logs zentral erfasst? Diese Parameter lassen sich technisch erzwingen, messen und auditieren.

Bei Fachverfahren und Anwendungen (SaaS) wird es kritisch: Die Fachlogik liegt in der Black Box des Anbieters. Ob ein Steuererklärungssystem oder ein automatisiertes Widerspruchsprüfverfahren fachlich korrekt arbeitet, lässt sich nur durch domänenspezifische Validierung beurteilen, also durch genau die Expertise (Steuerrecht, Verwaltungsverfahren etc.), die der Managed Service eigentlich ersetzen oder entlasten sollte.

Bei KI- und LLM-Leistungen verschärft sich diese Problematik strukturell: Selbst mit vorhandener domänenspezifischer Expertise sind zentrale Leistungsversprechen nicht verlässlich zusicherbar. Stochastische Systeme produzieren probabilistische Outputs, Korrektheit lässt sich nicht garantieren, sondern nur erwarten. Michael Schmid beschreibt dies als „Helferlein-Paradox": Wer die fachliche Kompetenz hat, die Ergebnisse zu validieren, braucht den Managed Service kaum. Wer diese Kompetenz nicht hat, kann die Leistung nicht sicher nutzen. Der Validierungsaufwand entspricht wirtschaftlich dem Eigenbetrieb und unterläuft den Managed-Service-Gedanken.

Daraus folgt für kritische Verwaltungsleistungen:

- Managed SaaS ist strukturell problematisch, wenn die Organisation nicht über hinreichende fachliche Kompetenz verfügt, die zugrunde liegende Fachlogik fortlaufend zu validieren, zu überwachen und bei Bedarf zu korrigieren.

- Managed KI/LLM scheidet als reines Managed-Service-Modell strukturell aus, weil die Validierung nicht nur Expertise erfordert, sondern selbst mit Expertise an den Grenzen probabilistischer Systeme scheitert.

- Managed IaaS/PaaS kann funktionieren, wenn Governance und Betrieb klar getrennt sind und die Steuerungshoheit beim Auftraggeber verbleibt.

Für unkritische Anwendungen – etwa interne Tools oder standardisierte SaaS-Anwendungen ohne fachkritische Logik – kann der Trade-off zwischen Entlastung und Validierungsaufwand vertretbar sein.

4. Digitale Souveränität entsteht durch Organisation, Architektur und technisch durchgesetzte Guardrails – nicht durch Einkauf

Für Cloud-Leistungen gilt:

Für kritische Verwaltungsleistungen ist Modell C (Managed Cloud als Bündel, bei dem Steuerung, Betrieb und Providerzugang in einer Hand liegen) aus meinem letzten Artikel strukturell problematisch und regelmäßig nicht zu empfehlen.

Die Verantwortung für Zweckmäßigkeit, Rechtmäßigkeit und Folgen der Leistung verbleibt beim Auftraggeber. Auch die Pflicht zur Beurteilung der Leistungsergebnisse kann nicht ausgelagert werden.

Die strukturelle Problematik unterscheidet sich jedoch je nach Leistungsebene:

- Bei stark abstrahierten Leistungen (insbesondere Managed SaaS und KI-Diensten) ist die fachliche Validierung der Leistungsergebnisse häufig nicht mehr realistisch leistbar.

- Bei Managed IaaS/PaaS liegt das Problem weniger in der Validierung als in der fehlenden laufenden Steuerungs- und Eingriffsmöglichkeit im Betrieb.

In beiden Fällen verbleibt die Verantwortung beim Auftraggeber, während die tatsächliche Steuerungsfähigkeit architektonisch eingeschränkt sein kann.

Was funktioniert, ist eine klare Trennung:

Modell B (Governance als separate, extern erbrachte Dienstleistung) unterstützt Steuerung extern, lässt aber Verantwortung und Beschaffungsentscheidungen intern.

Modell A (vollständig interne Steuerung) bei ausreichenden personellen und fachlichen Ressourcen.

Bei KI/LLM-Leistungen greift jedoch auch Modell B nicht vollständig: Die fachliche Validierung der Ergebnisse kann nicht extern erbracht werden, sie erfordert die domänenspezifische Expertise, die nur intern vorhanden ist. Hier verbleibt nicht nur Verantwortung, sondern auch die operative Prüfleistung zwingend beim Auftraggeber.

Je stärker Leistungen abstrahiert, automatisiert und als „Managed Services“ konsumierbar werden, desto größer wird die Gefahr, dass Steuerungsfähigkeit architektonisch entgleitet, während Verantwortung in der Organisation verbleibt.

Die gute Nachricht ist, dass diese Übersetzung möglich ist und in der Praxis bereits existiert.

Was meiner Meinung nach in der deutschen Verwaltung bislang fehlt, ist nicht das Modell selbst – Umsetzungen existieren –, sondern ein systematischer Diskurs darüber, wie diese Prinzipien in die Breite getragen werden können.

Denn dort, wo diese Übersetzung gelingt, entsteht digitale Souveränität nicht durch Einkauf, sondern durch Organisation. Nicht im Rahmenvertrag, sondern in der bewussten Trennung von Steuerung und Betrieb.

Dieser Diskurs beginnt nicht mit Technologie, sondern mit Vertragsstrukturen: Wie sind Standard-Hyperscaler-Rahmenverträge aufgebaut? Welche Architektur-Vorüberlegungen lassen sich hieraus ableiten? Und wie lässt sich Steuerung unter diesen Bedingungen organisieren?