Open Source darf jetzt ausgeschrieben werden – was das Gutachten WD 7 - 3000 - 010/26 für die KI-Beschaffung bedeutet

Wer in einer Kommune, einem kommunalen Klinikum oder einem Stadtwerk ein KI-System beschaffen will, kennt die Szene: Die IT will einen selbst betriebenen Stack – On-Premise, offene Modellgewichte, volle Kontrolle über Protokolle und Index. Die Vergabestelle winkt ab. Produktneutralität, heißt es. Sie dürfen das nicht vorschreiben. Also landet die Leistungsbeschreibung bei „marktübliche KI-Plattform mit deutschem Rechenzentrumsstandort“ – und damit faktisch bei drei Anbietern, von denen zwei US-Konzerne sind.

Diese Reflexschleife hat seit Juli 2026 ein belastbares Gegenargument. Der Wissenschaftliche Dienst des Deutschen Bundestages hat in einem Gutachten für einen Abgeordneten aufgearbeitet, unter welchen Bedingungen eine Beschränkung des Auftragsgegenstands auf Open-Source-Software vergaberechtlich hält. Das Ergebnis ist differenzierter als die Schlagzeilen – und gerade deshalb im Verfahren brauchbar.

Der bisherige Denkfehler: Produktneutralität gleich Hyperscaler

Der Grundsatz der Produktneutralität steht in § 31 Abs. 6 VgV (oberhalb der EU-Schwellenwerte) und in § 23 Abs. 5 UVgO (darunter). Er verbietet, in der Leistungsbeschreibung auf eine bestimmte Produktion, Herkunft, ein besonderes Verfahren, eine Marke, ein Patent oder einen Typ zu verweisen, wenn dadurch bestimmte Unternehmen begünstigt oder ausgeschlossen werden.

Er verbietet damit Marken, nicht Eigenschaften. „Microsoft 365 Copilot“ ist eine Marke. „Das System muss so beschaffen sein, dass der Auftraggeber die Verarbeitung personenbezogener Daten technisch selbst kontrollieren kann“ ist eine Eigenschaft. In der Praxis wird dieser Unterschied regelmäßig eingeebnet, mit drei Folgen:

• Faktische Vorfestlegung durch Standardleistungsbeschreibungen. Wer eine Vorlage aus dem Nachbarlandkreis übernimmt, in der API-Kompatibilität, Verfügbarkeitszusagen und Zertifikatslandschaft eines bestimmten Ökosystems beschrieben sind, hat produktneutral formuliert – und trotzdem faktisch einen Anbieter vorgegeben.
• Lock-in als Sachzwang statt als Risiko. Die Folgekosten eines Anbieterwechsels wurden in der Wirtschaftlichkeitsbetrachtung oft gar nicht bewertet, weil sie erst in der übernächsten Haushaltsperiode anfallen.
• Angst vor der Rüge. Vergabestellen wählen im Zweifel die Formulierung, gegen die noch nie jemand vorgegangen ist – nicht die, die dem Bedarf entspricht.

Genau an Punkt zwei setzt die europäische Rechtsprechung an: Der EuGH hat am 9. Januar 2025 in der Sache C-578/23 (IBM Česká republika) entschieden, dass ein selbst herbeigeführter Vendor Lock-in spätere Direktvergaben ohne Teilnahmewettbewerb regelmäßig nicht rechtfertigt. Wer sich sehenden Auges in die Abhängigkeit begibt, kann sich später nicht auf sie berufen. Das Gutachten leitet daraus einen bemerkenswerten Satz ab: Die Entscheidung für Open Source beziehungsweise für umfassende Nutzungsrechte am Quellcode könne „nicht nur wirtschaftlich sinnvoll, sondern auch vergaberechtlich geboten sein“.

Was das Gutachten WD 7 - 3000 - 010/26 tatsächlich sagt

Zunächst die Formalien, weil sie in der Berichterstattung durcheinandergeraten sind. Das Dokument trägt das Aktenzeichen WD 7 - 3000 - 010/26 und den Titel „Vergabeverfahren zur Bereitstellung, Entwicklung und Änderung von Computersoftware – Zur Zulässigkeit der Beschränkung eines öffentlichen Auftragsgegenstandes auf Open Source Software“. Zuständig war der Fachbereich WD 7 (Zivil-, Straf- und Medienrecht, Bauen und Wohnen). Als „Abschluss der Arbeit“ ist der 5. März 2026 vermerkt. Öffentlich breit rezipiert wurde es erst Mitte Juli 2026: Die OSB Alliance meldete es am 16. Juli, die Fachpresse zog am 20. und 21. Juli nach. Wer im Vermerk „veröffentlicht am 21. Juli 2026“ schreibt, zitiert die Pressewelle, nicht das Dokument.

Die Kernaussage steht im Fazit auf Seite 17 und ist wörtlich zitierfähig:

Ebenso wichtig ist, was das Gutachten nicht sagt. Überschriften wie „Open-Source-First ist geboten“ überdehnen den Befund. Das Gutachten formuliert ausdrücklich, eine Beschränkung auf Open Source sei „weder generell unzulässig noch uneingeschränkt zulässig“, und eine pauschale Festlegung auf Open Source in der Leistungsbeschreibung stelle „regelmäßig eine produkt- bzw. herkunftsbezogene Beschränkung im Sinne von § 31 Abs. 6 VgV“ dar. „Geboten“ ist Open Source nur im spezifischen Lock-in-Kontext der EuGH-Rechtsprechung.

Und: Ein Gutachten des Wissenschaftlichen Dienstes ist nicht bindend. Der Disclaimer im Dokument stellt klar, dass die Arbeiten „nicht die Auffassung des Deutschen Bundestages, eines seiner Organe oder der Bundestagsverwaltung“ wiedergeben. Es handelt sich um individuelle Auftragsarbeit für einen Abgeordneten. In einem Vergabevermerk zitiert man es als juristische Auslegungshilfe – nicht als Rechtslage und schon gar nicht als Beschluss. Wer es anders darstellt, liefert dem Bieteranwalt die erste Angriffsfläche.

Die Normenkette, auf die Sie sich stützen

Das Gutachten arbeitet mit einem überschaubaren Normenkanon, den Sie im Vermerk sauber durchdeklinieren sollten: § 103 GWB (Auftragsbegriff), § 106 GWB (Schwellenwerte), § 121 Abs. 1 GWB (Leistungsbeschreibung), § 31 Abs. 6 VgV (Produktneutralität und der Zusatz „oder gleichwertig“), § 14 Abs. 4 und Abs. 6 VgV (Verhandlungsverfahren ohne Teilnahmewettbewerb, Zurechenbarkeit von Ausschließlichkeitsrechten) sowie § 23 Abs. 5 UVgO für den Unterschwellenbereich.

Die vier im Gutachten genannten Sachgründe – und wie man sie belegt

Das Gutachten nennt als tragfähige Rechtfertigungen „etwa IT-Sicherheitsanforderungen, Interoperabilität, langfristige Weiterentwicklungsfähigkeit oder die Vermeidung von ‚Vendor Lock-in‘-Effekten“. Das Wörtchen „etwa“ ist juristisch entscheidend: Es macht die Aufzählung zu einer offenen, nicht abschließenden Liste. Sie sind also nicht auf diese vier Gründe beschränkt – aber diese vier sind die, die im Nachprüfungsverfahren am wenigsten Erklärungsbedarf auslösen.

Entscheidend ist die Belegtiefe. „Wir wollen IT-Sicherheit“ ist kein Sachgrund, sondern eine Präambel. Diese Beweisführung trägt:

Sachgrund	Was Sie in der Akte belegen	Konkreter Nachweis
IT-Sicherheit	Quelloffenheit ermöglicht eigene Prüfung, Härtung und Patch-Fähigkeit ohne Anbieterzustimmung	BSI-Grundschutz-Baustein, Pentest-Auflage, Schutzbedarfsfeststellung „hoch“
Interoperabilität	Offene Schnittstellen und Formate statt proprietärer Container	Liste der anzubindenden Fachverfahren, XÖV-/FHIR-Bezug, bestehende API-Landschaft
Weiterentwicklungsfähigkeit	Fortbestand des Betriebs unabhängig vom Fortbestand des Anbieters	Nutzungsdauer laut Abschreibung (oft 8–10 Jahre), Support-Endedaten vergleichbarer Produkte
Lock-in-Vermeidung	Vermeidung einer selbst herbeigeführten Abhängigkeit	EuGH C-578/23 vom 09.01.2025, Migrationskostenschätzung, Exit-Szenario

Für einen KI-Stack lässt sich das sehr konkret führen. Ein Large Language Model mit offenen Gewichten können Sie im eigenen Rechenzentrum evaluieren, auf Prompt-Injection testen, mit eigenen Guardrails versehen und – der praktisch wichtigste Punkt – auf einer Version einfrieren, bis die Fachabteilung die neue freigegeben hat. Bei einem gehosteten Modell entscheidet der Anbieter, wann sich das Verhalten Ihres Systems ändert. Für Anwendungen, die unter den EU AI Act fallen und dokumentierte Stabilität brauchen, ist das ein handfester Sachgrund und keine Geschmacksfrage.

Formulierungsbausteine für die KI-Leistungsbeschreibung

Und noch eine Pflicht, ohne die jeder Textbaustein unbrauchbar ist: Nach § 31 Abs. 6 Satz 2 VgV muss die Leistungsbeschreibung bei solchen Beschränkungen den Zusatz „oder gleichwertig“ enthalten – es sei denn, der Auftraggeber kann nachweisen, dass keine gleich geeignete Alternative existiert. Die Darlegungs- und Beweislast liegt beim Auftraggeber. Der EuGH hat am 16. Januar 2025 in der Sache C-424/23 entschieden, dass ein Verfahren bei fehlendem Zusatz im Ganzen rechtswidrig sein kann, wenn dieser Nachweis nicht gelingt.

Baustein 1 – Offene Modellgewichte

„Das eingesetzte Sprachmodell muss unter einer Lizenz stehen, die die kommerzielle Nutzung, die Weitergabe und die Modifikation der Modellgewichte gestattet. Die Gewichte sind dem Auftraggeber in einem gängigen offenen Format (z. B. safetensors) zu übergeben oder aus einer öffentlich zugänglichen Quelle abrufbar zu halten. Gleichwertige Lösungen, die dem Auftraggeber dieselbe technische Kontrolle über Modellstand, Modellversionierung und Modellbetrieb einräumen, sind zugelassen.“

Baustein 2 – Verarbeitungsort und Kontrolle

„Die Verarbeitung von Eingaben, Kontextdaten und Ausgaben erfolgt ausschließlich in einer vom Auftraggeber betriebenen oder von ihm benannten Infrastruktur. Eine Übermittlung an Systeme Dritter zu Zwecken der Modellverbesserung, Telemetrie oder Missbrauchserkennung ist ausgeschlossen. Der Auftraggeber muss den Betrieb ohne Internetverbindung zum Auftragnehmer aufrechterhalten können.“

Baustein 3 – Exit-Fähigkeit

„Der Auftragnehmer stellt sicher, dass Vektorindex, Chunking-Konfiguration, System-Prompts, Bewertungsdatensätze sowie sämtliche Betriebs- und Auditprotokolle jederzeit vollständig in dokumentierten, offenen Formaten exportierbar sind. Der Export ist einmalig im Rahmen der Abnahme praktisch nachzuweisen.“

Baustein 3 ist der wirksamste – und der, den Bieter am ehesten realistisch beantworten. Er zwingt niemanden zu Open Source und macht trotzdem den Wechsel möglich. Wer den Export im Abnahmetest tatsächlich durchspielt, merkt sehr schnell, welche Plattform ihn nur auf dem Papier anbietet. Ergänzend gehören Nachweise zur Modelldokumentation in die Leistungsbeschreibung – eine Model Card mit Trainingsdatenherkunft, bekannten Limitierungen und Evaluationsergebnissen ist unter dem AI Act ohnehin Pflichtprogramm, lässt sich aber nur bei offenen Modellen wirklich prüfen. Für den Dauerbetrieb kommen die üblichen LLMOps-Anforderungen hinzu: reproduzierbare Deployments, Versionsstände, Rollback-Fähigkeit.

Vergabebeschleunigungsgesetz und Open-Source-Vertragsbedingungen

Das Gutachten steht nicht allein. Zwei Entwicklungen aus dem Frühjahr 2026 stützen die Argumentation – und beide sind, anders als das Gutachten, geltendes Recht beziehungsweise verbindlicher Vertragsstandard.

Vergabebeschleunigungsgesetz: seit 1. Juli 2026 in Kraft

Der Bundestag beschloss das Vergabebeschleunigungsgesetz am 23. April 2026, der Bundesrat stimmte am 8. Mai 2026 zu, in Kraft getreten ist es am 1. Juli 2026. Digitale Souveränität ist darin nicht diffus „verankert“, sondern an drei präzisen Stellen:

• § 128 Abs. 2 GWB – „Versorgungssicherheit oder digitale Souveränität“ als zulässige Ausführungsbedingung.
• § 107 Abs. 2 Satz 3 Nr. 2 lit. b GWB – Cybersicherheit und digitale Souveränität können „wesentliche Sicherheitsinteressen“ begründen; bei besonders hohen Anforderungen an Vertraulichkeit, Verfügbarkeit oder Integrität von Daten und Systemen greift eine Ausnahme vom Vergaberecht.
• § 58 Abs. 2 Satz 2 Nr. 4 VgV – Aspekte der digitalen Souveränität ausdrücklich als Zuschlagskriterium.

Die Gesetzesbegründung nennt als zulässige Souveränitätskriterien unter anderem interoperable und offene IT-Systeme, Kontrolle über die Datenverarbeitungsvorgänge, Datenlokalisierung, Exit- und Migrationsszenarien, besondere personelle Anforderungen sowie rechtliche, organisatorische und technische Immunität gegen unerwünschte Zugriffe. Das ist, in Gesetzgebersprache, exakt die Anforderungsliste eines On-Premise-KI-Betriebs. Nebenbei wurde die Wertgrenze für Direktaufträge des Bundes auf 50.000 Euro angehoben – für Pilotprojekte eine erhebliche Erleichterung.

EVB-IT: Open Source wird Regelfall

Am 20. März 2026 haben das Bundesministerium für Digitales und Staatsmodernisierung (BMDS) und der Bitkom einheitliche Standards für die Beschaffung von Open-Source-Lösungen vereinbart. Wichtig für die korrekte Zitierung: Es wurden keine neuen Vertragsbedingungen geschaffen, sondern die bestehenden EVB-IT (Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen) in der bislang umfangreichsten Überarbeitung angepasst. Freigegeben hat sie der IT-Planungsrat im November 2025; kostenfrei abrufbar sind sie unter evb-it.gov.de. Open-Source-Entwicklung wird darin zum Regelfall für neue Softwareprojekte, proprietäre Beschaffung bleibt als Option erhalten. Staatssekretär Markus Richter (BMDS) bezeichnete die modernisierten Bedingungen als „entscheidenden Hebel“; Bitkom-Hauptgeschäftsführer Dr. Bernhard Rohleder betonte: „Einheitliche Vertragsstandards beschleunigen die öffentliche IT-Beschaffung und machen sie rechtssicherer.“

Auf Landesebene existiert mit dem Thüringer Vergabegesetz (Fassung vom 23. Januar 2020, zuletzt geändert am 16. November 2023) bereits ein Beispiel dafür, wie eine politische Priorisierung von Open Source zulässig ausgestaltet werden kann – nämlich indem sie an technische Möglichkeit und Wirtschaftlichkeit anknüpft. Das Gutachten hält ausdrücklich fest: „Eine entsprechende Regelung existiert auf Bundesebene bislang nicht.“

Praxispfad für Kommunen, Kliniken und Stadtwerke

Bevor Sie über Formulierungen streiten, klären Sie das Verfahrensregime. Seit dem 1. Januar 2026 gelten neue EU-Schwellenwerte (Bekanntmachung im Bundesanzeiger vom 18. Dezember 2025):

Auftragsart	Schwellenwert seit 01.01.2026	Relevanz KI-Beschaffung
Liefer- und Dienstleistungen (allgemein)	216.000 €	Regelfall für Kommunen und Kliniken
Oberste und obere Bundesbehörden	140.000 €	Bundesressorts und nachgeordnete Behörden
Sektorenaufträge	432.000 €	Stadtwerke, Energie- und Wasserversorger
Soziale und andere besondere Dienstleistungen	750.000 €	Teilweise für Kliniken und Sozialträger
Bauaufträge und Konzessionen	5.404.000 €	Nur bei RZ-Bau relevant

Praktische Konsequenz: Die meisten kommunalen KI-Beschaffungen – ein GPU-Server, ein Chat-Frontend, ein RAG-Index, Integration und drei Jahre Betrieb – bleiben unter 216.000 Euro und laufen damit im Haushaltsvergaberecht nach UVgO. Das ist eine gute Nachricht. Nach § 23 Abs. 5 UVgO gilt zwar eine vergleichbare Produktneutralitätspflicht, aber das Primat von Wirtschaftlichkeit und Sparsamkeit tritt stärker hervor – und diese Grundsätze können laut Gutachten im Einzelfall sogar für eine bevorzugte Berücksichtigung von Open Source sprechen, wenn dadurch langfristige Kosten, Abhängigkeiten oder Migrationsaufwände sinken.

Ablauf in sechs Schritten

1. Bedarf funktional beschreiben. Nicht „KI-Assistent“, sondern: welche Dokumentenbestände, welche Nutzergruppen, welcher Schutzbedarf, welche Antwortzeiten, welche Fachverfahren sind anzubinden.
2. Markterkundung durchführen und dokumentieren. Mindestens fünf Anbieter anschreiben, Rückläufe archivieren. Das ist der Beleg dafür, dass die Open-Source-Vorgabe den Wettbewerb nicht auf einen Anbieter verengt – das häufigste Rügeargument.
3. Sachgrund schriftlich herleiten. Ein bis zwei Seiten Vermerk: Schutzbedarf, Nutzungsdauer, Migrationskostenschätzung, Verweis auf § 128 Abs. 2 GWB und auf das Gutachten als Auslegungshilfe – nicht als Rechtsgrundlage.
4. Lose bilden. Hardware (GPU-Server, Netz, Rack), Modell und Software-Stack, Integration und Betrieb. Die Losaufteilung ist bei mittelständischen Bietern ohnehin gefordert und senkt gleichzeitig das Lock-in-Risiko, weil kein Los das andere technisch determiniert.
5. Zuschlagskriterien gewichten. Souveränitätsaspekte nach § 58 Abs. 2 Satz 2 Nr. 4 VgV mit einem spürbaren, aber begründbaren Anteil ansetzen – 15 bis 25 Prozent sind in der Praxis vertretbar; darüber wird die Herleitung anspruchsvoll.
6. Betriebskonzept und Nachweispflichten früh mitdenken. Wer betreibt das Modell nach der Abnahme, wer patcht, wer dokumentiert für den AI Act? Diese Fragen gehören in die Leistungsbeschreibung, nicht in die erste Betriebsbesprechung.

Der Vollständigkeit halber: Der Schritt, an dem Projekte scheitern, ist selten die Formulierung. Es ist Schritt drei. Vergabestellen kennen die Argumente – aber niemand schreibt sie auf, weil der Vermerk Zeit kostet und weil die Verantwortung dafür zwischen IT, Fachbereich und Vergabestelle pendelt. Genau dieser Vermerk ist im Nachprüfungsverfahren jedoch das einzige, was zählt. Wenn Sie ihn brauchen, unterstützen wir bei der Ausschreibungsbegleitung und bei der technischen Auslegung des On-Premise-Stacks; für die Finanzierungsseite lohnt ein Blick auf die verfügbaren Förderprogramme.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. Wissenschaftlicher Dienst des Bundestages, WD 7 - 3000 - 010/26 (PDF) Primärquelle, Volltext ausgewertet; Fazit S. 17, Abschluss der Arbeit 05.03.2026
2. Vergabeblog, 21. Juli 2026 Fachliche Einordnung des Gutachtens
3. cosinex Blog, 28. Juli 2026 Zulässigkeit der Beschränkung in der Leistungsbeschreibung
4. OSB Alliance, Pressemitteilung vom 16. Juli 2026 Erstmeldung, die das Gutachten öffentlich machte
5. Bitkom, Presseinformation vom 20. März 2026 EVB-IT-Überarbeitung, Zitat Dr. Bernhard Rohleder
6. BMDS, „Open Source rechtssicher beschaffen“ Zitat Staatssekretär Markus Richter, Verweis auf evb-it.gov.de
7. Gleiss Lutz: Bundestag verabschiedet Vergabebeschleunigungsgesetz Gesetzgebungsverlauf, Beschluss 23.04.2026
8. KPMG Law: Vergabebeschleunigungsgesetz – neue Anforderungen und Spielräume § 128 Abs. 2 GWB, § 58 Abs. 2 VgV, Direktauftragsgrenze 50.000 €
9. cosinex Blog: Digitale Souveränität in der öffentlichen Beschaffung Auslegung der Souveränitätskriterien aus der Gesetzesbegründung
10. Deutscher Bundestag, Textarchiv KW 17/2026 Parlamentarischer Vorgang zum Vergabebeschleunigungsgesetz

Häufig gestellte Fragen zur Open-Source-Vorgabe in Ausschreibungen

Darf ich Open Source einfach als Pflicht in die Leistungsbeschreibung schreiben?

Ja, wenn die Beschränkung sachlich gerechtfertigt, verhältnismäßig und transparent dokumentiert ist. Eine pauschale Vorgabe ohne Auftragsbezug bleibt unzulässig. Zusätzlich verlangt § 31 Abs. 6 Satz 2 VgV in aller Regel den Zusatz „oder gleichwertig“ – es sei denn, Sie können nachweisen, dass keine gleich geeignete Alternative existiert.

Welche Begründung trägt am besten?

Das Gutachten nennt beispielhaft IT-Sicherheitsanforderungen, Interoperabilität, langfristige Weiterentwicklungsfähigkeit und die Vermeidung von Vendor-Lock-in-Effekten. Die Liste ist ausdrücklich nicht abschließend – entscheidend ist, dass die Begründung konkret auf den Auftragsgegenstand bezogen und in der Vergabeakte belegt ist.

Gilt das auch für offene Modellgewichte, nicht nur für Software?

Das Gutachten behandelt ausschließlich Computersoftware und erwähnt KI, Sprachmodelle oder Modellgewichte an keiner Stelle. Die Argumentationslinie lässt sich fachlich übertragen – offene Gewichte sichern Prüfbarkeit, Betriebskontinuität und Wechselfähigkeit –, das ist jedoch eine Extrapolation und keine Aussage des Gutachtens.

Was passiert bei einer Rüge durch einen Bieter?

Entscheidend ist die dokumentierte Begründung in der Vergabeakte. Die Darlegungs- und Beweislast liegt beim öffentlichen Auftraggeber. Fehlt die Dokumentation oder der Zusatz „oder gleichwertig“, wird die Beschränkung angreifbar – unabhängig davon, wie überzeugend sie inhaltlich wäre. Der EuGH hat am 16. Januar 2025 (C-424/23) entschieden, dass ein Verfahren in solchen Fällen insgesamt rechtswidrig sein kann.