Fallstudie: Wenn KI industrielle Mittelmäßigkeit produziert

Dieser Artikel baut auf Ausschreibungen und KI: Auf dem Weg zu einer stillen Mutation des Marktes auf, wo wir feststellten: Die meisten aktuellen Ansätze automatisieren das Falsche. Hier wird es konkret. Ein realer Fall. Ein reales Scheitern. Und was wir daraus lernen.

Das Projekt

Ein IT-Dienstleister von beträchtlicher Größe — mehrere tausend Berater, Hunderte von Ausschreibungsantworten pro Jahr. Die Ausgangslage ist vernünftig: Wir verbringen zu viel Zeit mit Schreiben, wir haben eine reiche Historie gewonnener Antworten — warum nicht ein Modell trainieren, um daraus Kapital zu schlagen?

Das Projekt ist ambitioniert. Budget von mehreren Millionen Euro. Offshore-Entwicklung. Ein dediziertes Team über mehr als ein Jahr. Das Ziel: ein internes Tool, das technische Antworten aus der Historie vergangener Angebote generieren kann.

Mehrere Millionen Euro und mehr als ein Jahr Entwicklung, um ein statistisch optimiertes Copy-Paste zu bauen.

Auf dem Papier klingt das vernünftig. In der Praxis ist es eine angekündigte Katastrophe.

Der fundamentale Fehler: keine Ontologie

Das Modell wurde auf Hunderten vergangener Antworten trainiert. Technische Abschnitte, methodische Absätze, Projektreferenzen, Service-Level-Agreements. Alles durcheinander.

Das Problem: Es wurde vorab keinerlei semantische Struktur aufgebaut.

Das Modell unterscheidet nicht:

• Agil vs. Wasserfallmodell — zwei radikal unterschiedliche Delivery-Philosophien, im selben Trainingskorpus vermischt
• Kubernetes vs. monolithische Architektur — gegensätzliche Infrastruktur-Paradigmen, als austauschbare Textblöcke behandelt
• Ein Lastenheft für ein Ministerium vs. ein Lastenheft für ein Startup — Geschäftskontexte, Anforderungsniveaus, Entscheidungskulturen, die nichts gemeinsam haben
• Ein gewonnenes Angebot vs. ein verlorenes Angebot — keinerlei Gewichtung. Das Modell lernt genauso viel aus Misserfolgen wie aus Erfolgen, ohne es zu wissen

Ergebnis: Das Modell hat den Stil des IT-Dienstleisters gelernt, nicht seine Intelligenz. Es kann Sätze produzieren, die wie Ausschreibungsantworten klingen. Es weiß nicht, warum diese Sätze existieren.

Das Ergebnis: die Mittelmäßigkeitsmaschine

Nach über einem Jahr Entwicklung und mehreren investierten Millionen wird das Tool geliefert. Die ersten Tests sind aufschlussreich.

Nehmen wir ein konkretes Beispiel. Ein Lastenheft für die Neugestaltung eines HR-Informationssystems einer Gebietskörperschaft. Das Lastenheft betont nachdrücklich:

• Die Datenmigration aus einem veralteten Legacy-System
• Die Barrierefreiheit (WCAG)
• Einen engen Zeitplan mit Produktivsetzung vor den Wahlen

Hier ist, was das Modell produziert (anonymisierte Rekonstruktion):

Vom Modell generierte Antwort:

"Unser methodischer Ansatz stützt sich auf ein bewährtes Vorgehen, das die besten agilen Praktiken mit den Prinzipien des Wasserfallmodells verbindet, um eine qualitativ hochwertige Lieferung zu gewährleisten. Unser multidisziplinäres Team wird technische und fachliche Experten mobilisieren, um den Projekterfolg sicherzustellen. Wir schlagen eine moderne, skalierbare und sichere Architektur vor, die auf Marktstandards basiert."

Alles ist wahr. Nichts ist nützlich.

• "Verbindung von Agil und Wasserfall" — weil der Korpus beides enthielt und das Modell gelernt hat, niemanden zu verärgern
• "Multidisziplinäres Team" — eine Phrase, die in 90 % der Trainingsangebote vorkommt
• "Moderne, skalierbare und sichere Architektur" — die hohle Dreifaltigkeit, auf jedes Projekt anwendbar
• Keine Erwähnung der Datenmigration (das eigentliche Thema)
• Keine Erwähnung der WCAG-Barrierefreiheit (eine regulatorische Anforderung)
• Keine Erwähnung des engen Zeitplans (das Hauptrisiko)

Das Modell hat den statistischen Durchschnitt aller vergangenen Antworten produziert. Eine Durchschnittsantwort. Technisch korrekt. Strategisch leer.

Vergleichen wir nun mit dem, was ein kompetenter Bid Manager geschrieben hätte:

Kontextualisierte Antwort:

"Das Hauptrisiko dieses Projekts ist nicht technischer Natur — es ist die Datenmigration aus dem [Legacy-System], dessen Dokumentation lückenhaft und dessen Formate nicht standardisiert sind. Wir schlagen einen Sprint 0 von 4 Wochen vor, der ausschließlich dem Audit und Mapping der bestehenden Daten gewidmet ist, bevor jegliche Entwicklung beginnt. Dieser Ansatz sichert den von Ihnen festgelegten Produktionstermin [Datum], indem die tatsächlichen Blockaden identifiziert werden, bevor sie zu Verzögerungen werden.

Bei der WCAG-Barrierefreiheit integrieren wir eine Konformitätsprüfung in jeden Sprint, nicht erst in der Abnahme. [Vergleichbare Projektreferenz mit messbarem Ergebnis]."

Der Unterschied liegt nicht in der redaktionellen Qualität. Er liegt im Problemverständnis.

Die erste Antwort sagt "wir sind gut". Die zweite sagt "wir haben Ihren Schmerzpunkt verstanden, so gehen wir damit um". Die eine beruhigt vage. Die andere überzeugt.

---

Die Diagnose

Warum funktioniert es nicht? Weil der Ansatz auf einer falschen Annahme beruht: Die Vergangenheit enthält die Antworten für die Zukunft.

Ein Modell auf Ihren vergangenen Angeboten zu trainieren, heißt, ihm beizubringen, zu reproduzieren, was Sie bereits getan haben. Nicht zu verstehen, was der Kunde verlangt. Es ist statistisch optimiertes Copy-Paste.

Die strukturellen Probleme:

• Keine semantische Segmentierung. Das Modell weiß nicht, dass "Agil" im Bankenkontext und "Agil" im Industriekontext zwei verschiedene Realitäten sind. Es hat das Wort gelernt, nicht das Konzept.
• Keine Verbindung zwischen Kontext und Antwort. Das Modell generiert Textblöcke, aber es weiß nicht, warum ein bestimmter Block für einen bestimmten Auftrag relevant war. Es liest das Lastenheft nicht — es überfliegt es auf der Suche nach auslösenden Schlüsselwörtern.
• Kein Qualitätsbegriff. Gewonnenes Angebot, verlorenes Angebot, durchschnittliches Angebot — alles hat dasselbe Gewicht im Korpus. Das Modell hat keinerlei Signal dafür, was funktioniert.
• Keine Kundenanpassung. Das Modell produziert generisches "IT-Dienstleister-Deutsch". Es weiß nicht, wer gegenüber sitzt, was für ihn zählt, was ihn von anderen Auftraggebern unterscheidet.

Zusammengefasst: Auf der Vergangenheit ohne semantische Struktur zu trainieren, heißt intelligentes Copy-Paste zu lernen. Kein Verständnis. Keine Differenzierung.

Warum das eine häufige Falle ist

Dieser IT-Dienstleister ist kein Einzelfall. Die Argumentation ist verlockend:

1. Wir haben 10 Jahre Angebote auf unseren Servern
2. KI kann gut mit Textdaten umgehen
3. Also: Wir trainieren ein Modell auf unseren Angeboten = Wettbewerbsvorteil

Es ist logisch. Es ist falsch. Hier ist warum:

• Volumen ist nicht gleich Wert. 500 vergangene Antworten, von denen 200 verloren haben, 150 mittelmäßig waren und 150 gut — aber Sie wissen nicht, welche welche sind. Das Modell lernt eine Mischung.
• Der Kontext ist König. Eine brillante Antwort für einen Auftrag von 2022 ist möglicherweise obsolet für einen Auftrag von 2026. Technologien ändern sich. Vorschriften entwickeln sich weiter. Kundenerwartungen wandeln sich.
• Der Wettbewerbsvorteil liegt nicht in den Worten. Er liegt in der Fähigkeit zu verstehen, was der Kunde wirklich will, jenseits dessen, was er geschrieben hat. Kein auf Ihren alten Angeboten trainiertes Modell kann das.

Die Alternative: mit der Zukunft denken, nicht mit der Vergangenheit

Das richtige Paradigma ist nicht "was haben wir Ähnliches schon geschrieben?". Sondern: "Was will dieser spezifische Kunde, für sich, und wie können wir ihm noch mehr bieten, als er verlangt?"

Das erfordert eine radikal andere Architektur:

1. Jede atomare Information des Lastenhefts hinterfragen. Nicht überfliegen. Nicht zusammenfassen. Hinterfragen. Jede Anforderung, jede Vorgabe, jede Formulierung ist ein Signal. "Der Kunde hat hier 'zwingend' geschrieben und dort 'wenn möglich' — warum?" "Es gibt 15 Seiten zur Infrastruktur und 2 zum Anwendungsbereich — was sagt das über seine Prioritäten?" "Er erwähnt dreimal die Datenmigration — da liegt sein Schmerzpunkt."

2. Nicht mit der Vergangenheit argumentieren. Die Historie kann informieren (Kundenreferenz, Erfahrungsbericht). Sie darf nicht diktieren. Jeder Auftrag ist ein neues Problem. Der Kunde will nicht wissen, was Sie für andere getan haben — er will wissen, was Sie für ihn tun werden.

3. Mit der Zukunft denken. Was will dieser Kunde in 3 Jahren? Was ist das Problem hinter dem Problem? Was hat er im Lastenheft nicht zu schreiben gewagt, weil er nicht weiß, dass es möglich ist? Hier werden Aufträge gewonnen. Nicht in der Fähigkeit, Absätze zu recyceln, sondern in der Fähigkeit zu antizipieren.

4. Eine Ontologie bauen, keinen Korpus. Der Unterschied zwischen einer Textdatenbank und Intelligenz ist die semantische Struktur. Zu wissen, dass "Agil" in diesem Kontext "Scrum mit 2-Wochen-Sprints und einem 5er-Team" bedeutet — nicht "wir sind flexibel". Zu wissen, dass "Cloud-native Architektur" für diesen Kunden "wir migrieren von On-Premise und haben Angst" bedeutet — nicht "Kubernetes everywhere".

Was Sie sich merken sollten

Der Unterschied zwischen "Ausschreibungen automatisieren" und "Ausschreibungen verstehen" liegt nicht im Volumen der Trainingsdaten. Er liegt in zwei Dingen:

• Die Ontologie: die Fähigkeit, Informationen Sinn zu geben, nicht sie nur zu speichern
• Das kundenzentrierte Denken: die Fähigkeit, vom realen Kundenbedarf auszugehen, nicht von dem, was man schon auf Lager hat

Der IT-Dienstleister dieser Fallstudie hat Millionen investiert, um ein Tool zu bauen, das exakt das tut, was ein müder Bid Manager am Freitagabend macht: Copy-Paste aus dem letzten Dossier, das dem neuen vage ähnelt. Schneller, gewiss. Aber nicht besser.

KI bei Ausschreibungen ist kein Datenproblem. Es ist ein Kognitionsproblem.

Merken Sie sich: Ein Modell auf Ihren vergangenen Angeboten ohne Ontologie zu trainieren, heißt intelligentes Copy-Paste zu lernen. Der Unterschied zwischen Automatisieren und Verstehen liegt nicht im Datenvolumen — er liegt in der Fähigkeit, Sinn zu erzeugen.

---

Bei TenderGraph recyceln wir nicht Ihre alten Angebote. Wir entwickeln Agenten, die ein Lastenheft so lesen, wie es ein Senior Bid Manager tun würde — indem sie das Unausgesprochene suchen, jede Anforderung hinterfragen und für den Kunden denken, der gegenüber sitzt. Nicht für den Durchschnitt Ihrer früheren Kunden.

---

Weiterführende Artikel:

• Ausschreibungen und KI: Auf dem Weg zu einer stillen Mutation des Marktes — Die Makro-Betrachtung: Warum sich der Markt verändert und was das bedeutet.
• Der schlimmste Feind des Bid Managers: er selbst — Die andere Seite des Problems: Auch ohne schlechtes Tool sabotiert das menschliche Gehirn den Antwortprozess.
• Der Mythos des Executive Summary — Das generische Executive Summary ist das sichtbarste Symptom fehlender Ontologie.
• Die Throughput-Falle — Schneller produzieren ohne Ontologie = industrielle Mittelmäßigkeit im großen Maßstab.
• Warum Ihre Kundenreferenzen niemanden überzeugen — Das Modell spuckte Referenzen ohne Relevanz aus. Warum das ein strukturelles Problem ist, kein technologisches.
• Was das Lastenheft nicht sagt — Das Modell des IT-Dienstleisters erkannte keine Mehrdeutigkeiten. Ein kognitives System kennzeichnet sie und verwandelt sie in Fragen.
• Die informationelle Revolution — Der IT-Dienstleister hat eine Maschine für industrielles Rauschen gebaut. Das Signal/Rauschen-Framework erklärt warum.
• Die Beschleunigung der Pre-Sales-Zyklen — Das richtige Tool beschleunigt. Das falsche beschleunigt die Mittelmäßigkeit. Und was macht man dann mit der gewonnenen Zeit?
• Die Kompetenzen der Angebotsvorbereitung im KI-Zeitalter — Der IT-Dienstleister hat das Verstehen an die KI ausgelagert. Die fehlende Kompetenz: die Fähigkeit, das menschliche Signal zu lesen.
• Eine Ausschreibung analysieren wie man die Nachrichten analysieren sollte — Das Modell des IT-Dienstleisters produzierte das Äquivalent viraler Posts: industrielles Rauschen mit der Grammatik des Signals.
• Die Angebotsvorbereitung ist eine Führungsaufgabe — Ohne Karte operieren: Wenn KI produziert, ohne das Terrain zu kennen.