---
title: "Bieten, wenn eine Produktfunktion erst später kommt?"
description: "Prüfen Sie Solltermin, heutigen Produktstand, Lieferkette, Abnahmetest und Freigabe, bevor ein Roadmap-Punkt das Angebot trägt."
canonical: "https://zephior.com/de/insights/qualify-a-bid-with-a-product-roadmap-dependency"
last-updated: 2026-09-03
---

# Bieten, wenn eine Produktfunktion erst später kommt?

> Prüfen Sie Solltermin, heutigen Produktstand, Lieferkette, Abnahmetest und Freigabe, bevor ein Roadmap-Punkt das Angebot trägt.

Von [Tony Kim](https://zephior.com/de/authors/tony-kim). Veröffentlicht 2026-09-03; aktualisiert 2026-09-03. 13 Min. Lesezeit.

## Definition

Eine Roadmap-Abhängigkeitsentscheidung klärt, ob ein Angebot auf einer Produktfunktion beruhen darf, die in der angebotenen Fassung heute nicht nachweisbar verfügbar ist. Das Arbeitsergebnis `roadmap_dependency_decision` verbindet eine bestimmte Vergabe, ein Los, einen Bieter, eine Produktedition und ein Betriebsmodell mit der genauen Anforderung, ihrer Wertungswirkung und ihrem Erfüllungsereignis. Es enthält den belegten Ist-Stand, den Status der geplanten Änderung, den Weg bis Release und Kundenabnahme, zulässige Alternativen, Kosten- und Vertragsfolgen, Freigaben, Gegenbelege und Verfallsgründe. Die Entscheidung priorisiert kein Backlog, bewilligt keine Entwicklungsarbeit und verspricht dem Auftraggeber keinen Termin. Auch Bieterfrage, Abweichung, Vertragsannahme und Einreichung brauchen eigene Befugnisse.

## Problem

„Steht auf der Roadmap“ kann eine lose Idee, ein finanziertes Vorhaben oder bereits getesteten Code bezeichnen. Für das Angebot ist dieser Ausdruck wertlos, solange niemand den genauen Umfang, die betroffene Produktfassung und die letzte zulässige Lieferung benennt. Häufig liegt die Angebotsfrist Monate vor der Abnahme. Das kann eine seriöse Entwicklung bis zur Leistungserbringung ermöglichen. Es kann aber ebenso sein, dass eine Muss-Angabe oder die Präsentation schon heute die Funktion verlangt. In beiden Fällen führt dieselbe Ja-Antwort in die Irre. Entweder verzichtet das Unternehmen unnötig auf eine bietbare Chance oder es unterschreibt eine Leistung, für die weder Priorität noch Kapazität und Abnahmeweg gesichert sind.

## Perspektive

Der maßgebliche Termin kommt aus den Vergabeunterlagen, nicht aus der Quartalsspalte eines Produktplans. Legen Sie zuerst fest, welche Eigenschaft zu Angebot, Präsentation, Zuschlag, Implementierungsmeilenstein, Abnahme oder Betriebsbeginn bestehen muss. Belegen Sie dann den heutigen Zustand der tatsächlich angebotenen Edition. Erst die verbleibende Differenz wird als Produktänderung untersucht. Eine technisch denkbare Lösung trägt keine Zusage. Dafür braucht es einen freigegebenen Umfang, gebundene Kapazität, eine vollständige Abhängigkeitskette, passende Abnahmeevidenz sowie eine abgestimmte Preis- und Vertragsposition. Ein Agent darf diese Fakten verbinden und Widersprüche markieren. Die Produkt- und Verpflichtungsentscheidung bleibt bei den benannten Menschen.

## Die Vergabe bestimmt, wann die Funktion vorhanden sein muss

Lesen Sie die Anforderung nie allein. Antwortmatrix, Bewertungsmethode, Präsentationsvorgabe, Terminplan, Abnahmebedingungen und Vertragsentwurf können derselben Funktion unterschiedliche Zeitpunkte geben. „Die Lösung unterstützt parallele Bearbeitung“ kann eine heutige Ja-Nein-Angabe sein. Der Implementierungsteil kann dagegen eine spätere Konfiguration oder Entwicklung bewerten. Halten Sie deshalb zwei Daten fest: wann die Fähigkeit bestehen muss und wann welcher Beleg einzureichen oder vorzuführen ist.

Das deutsche Vergaberecht macht die veröffentlichten Anforderungen für diese Prüfung greifbar. § 121 GWB verlangt eine möglichst eindeutige Leistungsbeschreibung, damit Unternehmen sie gleich verstehen und Angebote vergleichbar bleiben; sie enthält Funktions- oder Leistungsanforderungen und die Bedingungen der Leistungserbringung. Nach § 127 GWB bewertet der Auftraggeber, ob und inwieweit ein Angebot die Zuschlagskriterien erfüllt. § 58 VgV nennt unter anderem technischen Wert, funktionale Eigenschaften, Liefertermin und Ausführungsfristen als mögliche Qualitätsbezüge. Welche Wirkung die konkrete Feature-Zeile hat, ergibt sich trotzdem erst aus den Unterlagen und dem anwendbaren Verfahren.

Ordnen Sie die Zeile als Eignung, formale Angebotsvorgabe, zugelassene Variante, bewertete Leistung, Projektmeilenstein oder Vertragsbedingung ein. § 57 VgV nennt Ausschlussfolgen etwa bei fehlenden geforderten Unterlagen, Änderungen an Vergabeunterlagen oder nicht zugelassenen Nebenangeboten. Daraus folgt keine pauschale Antwort auf jede Zukunftsfunktion. Es zeigt aber, warum eine stillschweigende Abweichung kein sauberer Ausweg ist. Bei widersprüchlichen Fassungen gilt `source_conflict`; eine ungeklärte Rechtsfolge erhält `legal_review_required` oder wird rechtzeitig über den offiziellen Kommunikationsweg gefragt.

**Stichtage einer künftigen Produktfunktion**

| Ereignis | Prüffrage | Geeigneter Beleg |
| --- | --- | --- |
| Angebotsabgabe | Muss die Ist-Edition die Funktion schon besitzen? | Aktueller Test und Antwortvorgabe |
| Präsentation | Welche Bedienung sieht das Wertungsteam? | Ablauf, Testumgebung und Demonstrationsregel |
| Zuschlag oder Vertrag | Welche Aussage wird zur Verpflichtung? | Finales Angebot, Aufklärung und Vertragsanlage |
| Projektabnahme | Welches Ergebnis muss unter welchen Daten bestehen? | Abnahmeszenario, Grenzwerte und Fehlerfolge |
| Betriebsbeginn | Wann muss die Leistung skaliert und supportbar sein? | Starttermin, Mengengerüst und Betriebsbedingungen |

## Ein Produktname reicht für die Ist-Prüfung nicht aus

Fixieren Sie das angebotene Paket so genau, wie es später geliefert würde. Dazu gehören Edition, Release, Hosting- oder On-Premises-Modell, Region, Sprache, Lizenzmodule, Mandantenkonfiguration, Geräte und erforderliche Drittsysteme. Prüfen Sie die geforderte Handlung in einer passenden Umgebung. Speichern Sie Testdatum, Eingaben, Ergebnis, Grenzen und die Person, die den Befund verantwortet. Allgemeine Dokumentation hilft, ersetzt aber keinen versionsbezogenen Nachweis, wenn die Aussage für einzelne Pakete oder Betriebsformen abweicht.

Erst danach wird die Lücke klassifiziert. `available_verified` erfüllt den Sollzustand in der angebotenen Fassung. `configuration_required` braucht nur unterstützte Einstellungen. `existing_integration_required` nutzt eine freigegebene und wartbare Schnittstelle. `custom_delivery_work` gehört zum kundenspezifischen Projekt. Eine neue, wiederverwendbare Eigenschaft des Produkts ist `product_change_required`. Diese Unterscheidung verhindert, dass Entwicklungsbudget einen Einrichtungsfehler löst oder dass Produktmanagement für ungesehene Projektskripte haftet.

Beschreiben Sie den Produktstatus ohne Ampelfarbe: `idea_recorded`, `discovery_active`, `solution_approved`, `funded_unscheduled`, `release_scheduled`, `in_development`, `release_candidate`, `limited_availability` oder `generally_available`. Für jeden Status braucht es eine organisationsintern eindeutige Definition, Quelle, Fassung und zuständige Rolle. Ein finanziertes Vorhaben kann inhaltlich noch nicht vollständig bestimmt sein. Ein Release-Kandidat ist nicht automatisch für alle Kunden freigegeben. Eine allgemein verfügbare Funktion kann dennoch die ausgeschriebene Last oder Integration verfehlen.

**Was ein Produktstatus wirklich belegt**

| Statusgruppe | Belegte Aussage | Offene Aussage |
| --- | --- | --- |
| Idee oder Discovery | Problem und Untersuchungsauftrag sind erfasst | Lösung, Priorität und Termin |
| Lösung freigegeben | Ein definierter Ansatz wurde fachlich angenommen | Finanzierung und Kapazität |
| Finanziert und terminiert | Ressource und Zielkorridor sind vorgesehen | Erfolgreiche Entwicklung und Abnahme |
| In Entwicklung | Arbeit am definierten Umfang hat begonnen | Release-Reife und Kundennutzbarkeit |
| Release-Kandidat | Benannte interne Gates sind erreicht | Produktionsfreigabe und Vertragsfit |
| Allgemein verfügbar | Der freigegebene Umfang ist supportbar | Eignung für jede Edition und Ausschreibung |

## Rechnen Sie bis zur Abnahme und nicht nur bis zum Merge

Beginnen Sie mit dem letzten bestandenen Abnahmefall und arbeiten Sie rückwärts. Vor ihm liegen möglicherweise Kundeneinrichtung, Datenmigration, Integrationstest, Schulung und Deployment-Freigabe. Der Produktrelease kann von Architekturentscheidung, Schnittstellenspezifikation, Entwicklung, Testdaten, Leistungsprüfung, Datenschutz, Informationssicherheit, Barrierefreiheit, Übersetzung, Dokumentation und Supportübergabe abhängen. Nicht jede Funktion braucht jeden Schritt. Doch jeder erforderliche Schritt bleibt mit seiner steuernden Rolle sichtbar.

Geben Sie jedem Meilenstein Vorgänger, Owner, frühestes und spätestes Enddatum sowie einen überprüfbaren Abschlussbeleg. Externe SDKs, Zertifizierungen, Auftraggeberdaten oder Testzugänge erhalten einen eigenen Unsicherheitszweig. Planen zwei zugesagte Features mit denselben Personen, ist diese Kapazitätskollision eine Abhängigkeit und keine Randnotiz. Der maßgebliche Lieferkorridor endet dort, wo der späteste notwendige Pfad endet. Ein einzelner Idealtermin darf ihn nicht ersetzen.

Die Freigabekriterien müssen zum Risiko der konkreten Funktion passen. NIST SP 800-218 beschreibt Sicherheitspraktiken, die in den Softwarelebenszyklus eingebaut werden können. Der Standard beweist keine allgemeine Produktreife und ersetzt keinen Abnahmetest. Er erinnert daran, Sicherheitsarbeit und ihre Evidenz nicht hinter einem Entwicklungsdatum zu verstecken. Ergänzen Sie Betriebs-, Bedienungs-, Leistungs- und Zugänglichkeitsprüfungen, soweit die Leistung sie verlangt. Der Abschlussbeleg ist vor der Zusage festzulegen.

**Felder eines belastbaren Liefermeilensteins**

| Feld | Inhalt | Nutzen |
| --- | --- | --- |
| Verantwortung | Benannte Person oder Funktion | Bestimmt, wer den Zustand bestätigen darf |
| Vorgänger | Alle zuerst zu schließenden Schritte | Macht Blockaden sichtbar |
| Terminkorridor | Belegtes Früh- und Spätdatum | Hält Unsicherheit in der Rechnung |
| Abschlussbeleg | Test, Entscheidung, Release oder Abnahme | Definiert den tatsächlichen Endzustand |
| Negativer Zweig | Verzögerung, Fehler oder Wegfall | Verbindet Risiko mit Konsequenz |
| Verfall | Ereignis, das die Prognose entwertet | Erzwingt eine neue Entscheidung |

## Der freigegebene Satz muss durch alle Angebotsdokumente tragen

Formulieren Sie erst nach der Sachprüfung. „Wir untersuchen“, „wir planen“, „wir bieten an“ und „wir liefern spätestens am 15. März“ bezeichnen unterschiedliche Verbindlichkeit. Eine Ja-Nein-Matrix darf die Differenz nicht verschlucken. Nutzen Sie das vorgesehene Erläuterungs-, Varianten- oder Abweichungsfeld, wenn die Vergabe es zulässt. Ein Vorbehalt im Begleitschreiben hilft nicht, wenn der Auftraggeber nur die Matrix wertet oder Änderungen an den Unterlagen ausschließt.

Die Freigabekette folgt der erzeugten Verpflichtung. Produktverantwortung genehmigt Umfang und wiederverwendbare Priorität. Entwicklung bestätigt Machbarkeit, Kapazität und technische Gates. Delivery trägt Kundenschritte und Implementierung. Commercial übernimmt Kosten, Opportunität und Rechtsfolgen. Datenschutz, Sicherheit oder regulatorische Stellen kommen hinzu, wenn ihr Bereich betroffen ist. Die Rechtsprüfung ordnet Formulierung, Gewährleistung, Haftung, geistiges Eigentum und zulässige Abweichung ein. Protokollieren Sie die exakt gelesene Aussage, nicht nur ein pauschales Sitzungsprotokoll.

Prüfen Sie vor neuer Entwicklung die bereits zulässigen Lösungen. Eine unterstützte Konfiguration kann den gewünschten Prozess erfüllen. Eine veröffentlichte Schnittstelle kann eine vorhandene Komponente anbinden. Der Auftraggeber kann Varianten oder eine gestufte Einführung vorgesehen haben. Eine Bieterfrage darf den maßgeblichen Zeitpunkt oder die Akzeptanz eines funktionalen Äquivalents klären. Jede Alternative behält ihren Fundort, ihre Kosten, ihren Test und ihre Einschränkungen. Aus einer ausgebliebenen Antwort entsteht keine Genehmigung.

**Stufen externer Roadmap-Sprache**

| Aussageart | Mindestgrundlage | Grenze |
| --- | --- | --- |
| Heutige Fähigkeit | Versionsbezogener Nachweis im angebotenen Umfang | Nur beobachtetes Verhalten behaupten |
| Planungsabsicht | Freigegebene, unverbindliche Offenlegung | Keine Lieferzusage andeuten |
| Künftiges Leistungsangebot | Umfang, Pfad, Termin, Preis und Abnahme genehmigt | Nur autorisierte Formulierung verwenden |
| Zulässige Alternative | Verfahrensgrundlage und vollständiger Alternativvorschlag | Unterschiede sichtbar halten |
| Vertragspflicht | Abgestimmter Termin, Rechtsfolge und Abhängigkeit | Alle Anlagen widerspruchsfrei machen |

## Beispiel: Die neue Bearbeitungslogik verfehlt den negativen Pfad

Ein fiktiver Landkreis beschafft eine Plattform für digitale Verwaltungsformulare. Die Angebotsfrist endet am 2. November 2026, die Präsentation findet am 24. November statt und die Abnahme ist für den 1. April 2027 vorgesehen. Gewertet wird das Konzept für gleichzeitige Bearbeitung; zur Abnahme müssen zwölf Sachbearbeitende verschiedene Felder desselben Vorgangs ändern können. Der Test verlangt Konflikterkennung, Versionshistorie und Wiederherstellung. Diese Angaben gehören zu keinem laufenden Verfahren.

Die angebotene Fassung sperrt bisher den ganzen Vorgang. Für feldbezogene Sperren existieren eine genehmigte Lösung und ein finanziertes Release-Fenster im Januar 2027. Der Lasttest für zwölf parallele Sitzungen hängt jedoch von einem Umbau der Persistenzschicht ab. Für die Migration bestehender Mandanten ist noch keine Kapazität reserviert, und die Wiederherstellung wurde nur mit synthetischen Daten erprobt. Der günstige Pfad endet Mitte März, der negative Pfad im Mai. Der Zustand lautet `roadmap_dependency_unresolved`. Eine interne Zielmarke vor der Abnahme reicht nicht, solange Migration, Lasttest und Spätpfad offen sind.

Der strukturierte Datensatz enthält Vergabe- und Loskennung, Quellenfassungen, Bieter- und Produktfingerprint, Solltext, Wertungswirkung, Fähigkeits- und Nachweisereignis, Ist-Test, Produktstatus, Abhängigkeitsgraph, Terminspannen, Abnahmeskript, Alternativen, Preis- und Vertragsfolgen, Aussageentwurf, Freigaben, Gegenbelege, nächste Aktion und Verfallsgründe. Zulässige Ergebnisse sind `bid_on_current_capability`, `bid_with_approved_product_commitment`, `bid_with_permitted_alternative`, `clarification_required`, `roadmap_dependency_unresolved`, `no_bid_dependency`, `source_conflict`, `legal_review_required` und `authority_missing`. Ein Agent darf Fundstellen sammeln, Produkttests vergleichen, Termine rechnen, Widersprüche suchen und eine interne Empfehlung oder befugte Frage entwerfen. Er stoppt vor Priorisierung, Budgetbindung, vertraulicher Offenlegung, Terminversprechen, Abweichungsannahme, Kontakt und Einreichung.

## Nützliche Ergebnisse

- Vergabestelle, Verfahren, Los, Bieter, Produktedition, Betriebsmodell und Prüfzeitpunkt sind festgehalten.
- Die maßgebliche Anforderung besitzt Quelle, Fassung, Wertungsfolge, Sollzustand und Erfüllungsereignis.
- Nachweisbare Standardfunktion, Konfiguration, bestehende Integration und neue Produktentwicklung bleiben getrennt.
- Idee, Discovery, Lösungsfreigabe, Finanzierung, Terminierung, Entwicklung, Release-Kandidat und allgemeine Verfügbarkeit werden nicht vermischt.
- Jede Lieferabhängigkeit nennt Vorgänger, Zuständigkeit, Zeitspanne, Abschlussbeleg und negative Entwicklung.
- Die Planung endet nicht beim Code, sondern umfasst die für den angebotenen Einsatz nötigen Prüfungen und Betriebsfreigaben.
- Der Abnahmetest des Auftraggebers ist vor der externen Termin- oder Leistungszusage beschrieben.
- Varianten, Alternativen, Abweichungen und Fragen werden nur über den im Verfahren zulässigen Weg verwendet.
- Antwort, Preis, Projektplan, Service und Vertrag enthalten dieselbe freigegebene Verpflichtung.
- Kein Agent verändert Produktpriorität, gibt vertrauliche Roadmap-Daten frei oder versendet ohne Einzelvollmacht eine Zusage.

## Ablauf

1. **Prüfgegenstand fixieren.** Erfassen Sie Verfahren, Los, Bieter, angebotene Edition, Betriebsform, aktuelle Dokumente und Beobachtungszeit.
2. **Sollzustand und Stichtag lesen.** Übernehmen Sie Anforderung, Muss- oder Wertungsfolge, verlangten Beleg und das Ereignis, an dem die Funktion bestehen muss.
3. **Ist-Funktion nachweisen.** Testen Sie die angebotene Fassung unter passenden Bedingungen und dokumentieren Sie Konfiguration, Grenze, Quelle, Gültigkeit und Ergebnis.
4. **Änderungsart bestimmen.** Trennen Sie Konfiguration, Integration und Projektarbeit von einer wiederverwendbaren Produktänderung mit belegtem Lifecycle-Status.
5. **Lieferpfad rückwärts bauen.** Gehen Sie von Abnahme und Betriebsbeginn über Deployment, Release, Qualitätssicherung und Entwicklung bis zu Freigabe und Design zurück.
6. **Zulässige Wege vergleichen.** Bewerten Sie Ist-Lösung, unterstützte Konfiguration, bestehende Integration, erlaubte Alternative, Variante, Abweichung und künftige Zusage einzeln.
7. **Folgen durch das Angebot ziehen.** Übertragen Sie Umfang, Abhängigkeiten und Termine in Preis, Projektplan, Abnahme, Servicelevel, Gewährleistung, Haftung und Antworttexte.
8. **Wortlaut freigeben.** Lassen Sie genau die vorgesehene Aussage mit ihrer Verpflichtungswirkung von den erforderlichen Produkt-, Delivery-, Commercial- und Rechtsrollen genehmigen.
9. **Entscheidung überwachen.** Öffnen Sie den Status bei Dokumentenänderung, Testfehler, Terminverschiebung, Kapazitätskonflikt, Drittparteirisiko oder geänderter Vertragslage erneut.

## Wichtige Entscheidungen

- Welche beobachtbare Leistung verlangt die betreffende Zeile wirklich?
- Ist sie formale Muss-Vorgabe, Präsentationspunkt, Zuschlagskriterium, Implementierungsergebnis, Abnahmefall oder Betriebspflicht?
- Zu welchem Ereignis muss die Fähigkeit bestehen, und wann wird welcher Nachweis verlangt?
- Was leistet die angebotene Edition in der vorgesehenen Betriebsform am Prüftag nachweislich?
- Erreicht eine unterstützte Konfiguration oder bestehende Schnittstelle das Ziel ohne Änderung am Produktcode?
- Welchen intern definierten Status besitzt die geplante Funktion, und welches datierte Dokument trägt ihn?
- Welche technischen, organisatorischen, externen und kundenabhängigen Schritte steuern den spätesten Termin?
- Wie sieht der Test aus, der genau die ausgeschriebene Leistung unter ihren Randbedingungen belegt?
- Welche Kosten, Service-, Gewährleistungs-, Haftungs- und Projektfolgen löst das Versprechen aus?
- Welcher externe Satz ist heute wahr, und wer darf ihn als künftige Verpflichtung genehmigen?
- Bei welchem Ereignis oder Datum wird aus einer bedingten Freigabe ein Stopp?

## Risiken

- Eine Quartalsangabe aus der internen Planung wird als festes Lieferdatum angeboten.
- Ein Demonstrator, Feature-Flag oder Testsystem wird als verfügbare Serienfunktion beschrieben.
- Die Funktion ist nur in einer anderen Edition, Region oder Betriebsform vorhanden.
- Eine Aufwandsschätzung wird mit genehmigter Priorität und tatsächlich reservierter Kapazität verwechselt.
- Die Planung endet vor Penetrationstest, Barrierefreiheitsprüfung, Übersetzung, Betriebsübergabe oder Supportfreigabe.
- Die Vergabe verlangt den Nachweis zur Präsentation, während das Team mit einer späteren Abnahme rechnet.
- Ein fachlich ähnlicher Workaround verändert die Leistungsbeschreibung und wird ohne zugelassene Variante angeboten.
- Die technische Antwort verspricht den Termin, aber Preisblatt, Projektplan und Vertragsanlage enthalten andere Annahmen.
- Mehrere Kunden erhalten Zusagen, die dieselbe knappe Entwicklungsressource gleichzeitig voraussetzen.
- Interne Produktplanung, Sicherheitsbefunde oder geschützte Kundendaten gelangen ohne Freigabe an ein Modell oder nach außen.

## Kennzahlen

- Roadmap-abhängige Anforderungen mit Fundstelle, Wertungswirkung und genauem Erfüllungsereignis
- Ist-Zustände mit Editions-, Versions-, Betriebs- und Testevidenz
- geplante Produktänderungen mit belegtem und eindeutig definiertem Lifecycle-Status
- Meilensteine mit Eigentümer, Vorgänger, frühestem und spätestem Termin sowie Abschlussbeleg
- Zusagen, deren Abnahmetest vor der Freigabe vollständig beschrieben ist
- Abhängigkeiten, die in Antwort, Preis, Delivery und Vertrag gleich behandelt werden
- bedingte Entscheidungen, die vor Eintritt ihres Verfallsgrundes neu geprüft wurden
- positive Zukunftszusagen mit benannter Produkt- und Verpflichtungsbefugnis
- unbelegte Features, unbefugte Roadmap-Änderungen und Einreichungen; Zielwert null

## Häufige Fragen

### Darf eine Roadmap-Funktion in einer Ausschreibung mit Ja beantwortet werden?

Nur wenn die Antwort nach den Vergabeunterlagen wahr ist und der künftige Zustand mit Umfang, Lieferpfad, Abnahme, Folgen und Zuständigkeit freigegeben wurde. Der Roadmap-Eintrag allein genügt nicht.

### Ist ein Angebot möglich, wenn die Funktion erst zum Go-live gebraucht wird?

Ja, wenn die Vergabe spätere Erfüllung zulässt und der vollständige Pfad vor dem Sollereignis mit ausreichender Evidenz und Befugnis tragfähig ist. Antwort, Preis, Projektplan und Vertrag müssen denselben Zustand abbilden.

### Wann gilt eine künftige Funktion als hinreichend gesichert?

Wenn Umfang, Priorität, Kapazität, Vorgänger, Terminspanne, Release-Gates, Kundenabhängigkeiten und Abnahmetest belegt sind und die zuständigen Rollen die konkrete Zusage genehmigt haben.

### Kann ein Workaround die Roadmap-Abhängigkeit beseitigen?

Nur wenn er das verlangte Ergebnis erfüllt, in der Vergabe als Lösung oder Alternative zulässig ist, supportbar und bepreist ist und im vorgesehenen Abnahmetest besteht.

### Darf ein KI-Agent die Produktzusage freigeben?

Nein. Er kann Quellen, Tests, Termine und offene Punkte in einer prüfbaren Empfehlung verbinden. Die Produktpriorität, Kundenverpflichtung und externe Handlung genehmigen benannte Menschen.


## Primärquellen

- [Gesetz gegen Wettbewerbsbeschränkungen, § 121 Leistungsbeschreibung](https://www.gesetze-im-internet.de/gwb/__121.html), Bundesministerium der Justiz und Bundesamt für Justiz
- [Gesetz gegen Wettbewerbsbeschränkungen, § 127 Zuschlag](https://www.gesetze-im-internet.de/gwb/__127.html), Bundesministerium der Justiz und Bundesamt für Justiz
- [Vergabeverordnung, § 57 Ausschluss von Angeboten](https://www.gesetze-im-internet.de/vgv_2016/__57.html), Bundesministerium der Justiz und Bundesamt für Justiz
- [Vergabeverordnung, § 58 Zuschlag und Zuschlagskriterien](https://www.gesetze-im-internet.de/vgv_2016/__58.html), Bundesministerium der Justiz und Bundesamt für Justiz
- [Richtlinie 2014/24/EU, konsolidierte Fassung, Artikel 42, 56, 67 und 70](https://eur-lex.europa.eu/eli/dir/2014/24/2026-01-01/deu), EUR-Lex
- [NIST Secure Software Development Framework, Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final), National Institute of Standards and Technology


## Weiterführende Artikel

- [Fehlendes Zertifikat: Ist die Ausschreibung noch bietbar?](https://zephior.com/de/insights/decide-whether-to-bid-with-missing-certification)
- [Bieten, wenn nicht alle Anforderungen erfüllt sind?](https://zephior.com/de/insights/decide-whether-a-partial-capability-fit-is-biddable)
- [Bekanntmachung da, Vergabeunterlagen verfügbar?](https://zephior.com/de/insights/distinguish-notice-publication-from-document-release)
- [Was tun, wenn Fragen und Zuschlagskriterien nicht passen?](https://zephior.com/de/insights/resolve-conflict-between-criteria-and-rfp-questions)