Eine KI-Halluzination in einem Angebot ist eine generierte Aussage, die glaubwürdig wirkt, aber unbelegt, widersprochen oder wesentlich sicherer formuliert ist, als freigegebene Unternehmens- und Chancenevidenz erlaubt.

Angebotssprache besitzt besonders teure Fehlerbilder. Eine flüssige Antwort kann versehentlich ein Zertifikat, einen Hostingort, eine Produktfunktion, ein Service Level, ein Referenzergebnis oder eine vertragliche Zusage behaupten, die der Anbieter nicht belegen kann. Die Vergabestelle kann sich darauf stützen, Bewertende können Punkte vergeben und die unterzeichnete Offerte macht sie relevant. Normales Korrektorat findet holprige Sprache, aber oft keine plausible Falschaussage.

Das Ziel ist nicht ein Sprachmodell, das niemals irrt. Das Ziel ist ein Antwortsystem, in dem unbelegte Aussagen schwer zu erzeugen, leicht zu erkennen und ohne verantwortliche Freigabe unmöglich zu veröffentlichen sind. Retrieval, Prompt und Modell helfen. Evidenzdesign, Oberfläche, Berechtigungen, Evaluation und menschliche Autorität bilden jedoch die eigentliche Kontrolle.

Fehlerbilder

Halluzinationen sind mehr als frei erfundene Fakten

Ein erfundenes Zertifikat ist offensichtlich, doch subtilere Fehler treten häufiger auf. Eine Quelle beschreibt ein Produkt und die Antwort behauptet alle Produkte. Eine Roadmap wird zur heutigen Funktion. Eine Policy gilt als Beweis, dass ein Control operativ läuft. Eine Referenz aus einer Region wird global. Alle Wörter können in der Library stehen, obwohl die Aussage unbelegt bleibt.

Ein weiteres Fehlerbild ist unberechtigte Sicherheit. Evidenz kann “mit Konfiguration verfügbar” stützen, während die Antwort “standardmässig enthalten” sagt. Sie kann ein Ziel, aber kein vertragliches Service Level belegen. Sie kann Absicht statt gemessener Leistung beschreiben. Die Kontrolle prüft deshalb Scope, Modalität, Zeit und Autorität, nicht nur Wortähnlichkeit. Reviewer sollten fragen, was das Unternehmen zusagt, wenn der Käufer den Satz wörtlich akzeptiert.

Häufige Fehler in Angebotsaussagen
FehlerMusterKontrolle
ErfindungKeine freigegebene Quelle stützt die AussageEvidenzlücke und Owner-Eskalation
Scope-AusweitungEin Produkt oder eine Region wird universellMetadatenfilter und Geltungsreview
Zeitliche VerschiebungHistorische oder geplante Funktion wird aktuellGültigkeitsstatus und Wirksamkeitsdaten
ZusageverstärkungPraxis oder Ziel wird zur GarantieCommercial- oder Rechtsfreigabe
Falsche BelegwirkungZitat ist verwandt, beweist den Claim aber nichtPassagenreview und gezielte Tests

Kontrollen

Mehrere unabhängige Kontrollen statt eines perfekten Prompts

Prompts können das Modell auf Kontext begrenzen, schaffen aber weder vertrauenswürdigen Kontext noch verantwortliche Prüfung. Die Quellenschicht begrenzt Retrieval. Metadaten begrenzen die Geltung. Generierung drückt fehlende Information aus. Die Oberfläche hält Zitate und Warnungen sichtbar. Workflow routet relevante Claims. Evaluation misst Verhalten. Release-Rechte verhindern, dass ein ungeprüfter Output zum Angebot wird.

Diese Kontrollen sollen unabhängig sicher scheitern. Liefert Retrieval nichts, darf Generierung die Lücke nicht füllen. Vergisst die Generierung eine Warnung, muss eine Pflichtfreigabe die Claim-Klasse weiterhin fangen. Akzeptiert ein Reviewer eine Ausnahme, zeigt das Protokoll Person und Grund. NIST beschreibt Konfabulation als sicher präsentierten falschen Inhalt. OWASP betont Fehlinformation und Overreliance. Beides verlangt Risikosteuerung über Modellgenauigkeit hinaus.

  • Beschränken Sie Retrieval nach Berechtigung, Produkt, Entität, Geografie und Gültigkeit.
  • Binden Sie Unterstützung an einzelne Claims statt generische Links an den Absatz.
  • Machen Sie fehlende freigegebene Evidenz zu einem erfolgreichen Systemergebnis.
  • Fordern Sie explizite Freigabe für Zusagen mit vertraglicher oder operativer Wirkung.
  • Protokollieren Sie genug für Rekonstruktion, ohne Daten unbegrenzt aufzubewahren.

Evaluation

Testen Sie die Fehler, die für das Unternehmen zählen

Ein generischer Genauigkeitstest repräsentiert das Lieferantenrisiko nicht. Bauen Sie einen versionierten Satz echter Fragemuster mit erwartetem Verhalten. Enthalten sind direkte Antwort, Teilevidenz, keine Evidenz, widersprüchliche Quellen, unklarer Produktscope und abgelaufener Inhalt. Ergänzen Sie Security, Datenstandort, Zertifikate, Barrierefreiheit, Unterauftragnehmer, Service Levels und Roadmap.

Messen Sie mehr als Textähnlichkeit: richtige Evidenz, erhaltene Einschränkung, Verweigerung unbelegter Ergänzung, korrektes Routing und Einhaltung von Berechtigungen. Bewerten Sie Fehler nach Schwere. Eine harmlose Stilanpassung und ein erfundenes Zertifikat gehören nicht in denselben Durchschnitt. Wiederholen Sie Tests bei Änderungen an Quellen, Retrieval, Prompt, Modell, Oberfläche oder Freigaberegel.

  • Definieren Sie erwarteten Antwortzustand und erwartete Evidenz für jeden Test.
  • Nehmen Sie Negativfälle auf, deren richtige Ausgabe eine Lücke oder Rückfrage ist.
  • Testen Sie manipulative Anweisungen in Dokumenten als nicht vertrauenswürdige Daten.
  • Führen Sie kritische Fehler getrennt von redaktionellen Mängeln.
  • Verlangen Sie Regressionsergebnisse vor materiellen Änderungen im Live-Prozess.

Menschliches Review

Review gegen den Automation Bias flüssiger Texte gestalten

“Alles prüfen” ist keine Kontrolle, wenn die Oberfläche nur polierte Prosa zeigt. Bringen Sie Käuferfrage, Entwurf, Claim-Markierungen, Passagen, Quellenmetadaten und Warnungen in eine Ansicht. Reviewer bestätigen zuerst die faktische Aussage und bearbeiten danach Stil. Für sensitive Claims erfassen Sie benannte Freigabe, statt Schweigen als Zustimmung zu interpretieren.

Auch die Last zählt. Routen Sie risikoarme gestützte Antworten anders als Rechts- oder Security-Ausnahmen und bündeln Sie Fragen für denselben Owner. Nutzen Sie Fristen und Stellvertretungen, entfernen Sie aber nicht die Evidenzansicht für mehr Tempo. Korrigiert ein Reviewer einen Fakt, schlägt er eine Quellenänderung mit Scope und Owner vor. Erst Governance übernimmt sie, damit ein hektischer Deal nicht die Unternehmenswahrheit definiert.

  • Zeigen Sie Passagen, ohne Reviewer in ein anderes Repository zu schicken.
  • Markieren Sie unbelegte Teilsätze in gemischt gestützten Antworten.
  • Trennen Sie faktische, kommerzielle und redaktionelle Freigabe.
  • Erfassen Sie Owner und Grund jeder wesentlichen Ausnahme.
  • Messen Sie Reviewqualität ebenso wie Antwortgeschwindigkeit.

Woran gute Arbeit erkennbar ist

Konkrete Ergebnisse für KI-Halluzinationen in Angeboten verhindern

  • Jede wesentliche Antwort zeigt die freigegebenen Quellen und genauen Passagen ihrer Unterstützung.
  • Fehlende, widersprüchliche und abgelaufene Evidenz bleibt sichtbar, statt in sichere Prosa verwandelt zu werden.
  • Claims mit hoher Wirkung erreichen verantwortliche Personen aus Security, Recht, Commercial, Produkt oder Delivery.
  • Reviewer prüfen eine Aussage gegen ihre Evidenz, ohne den Antwortworkflow zu verlassen.
  • Der Einreichungsnachweis erhält freigegebenen Text, Evidenz, Entscheide und ungelöste Einschränkungen.

Betriebsmodell

So wird die Arbeit ausgeführt

  1. 01

    Claim-Risiko vor der Generierung klassifizieren

    Definieren Sie Aussagen, die aus normalen freigegebenen Inhalten entworfen werden dürfen, und Aussagen mit benannter Fachfreigabe. Behandeln Sie Zertifikate, Recht, Security Controls, Personendaten, Preis, Roadmap, Service Levels, Referenzen und Lieferzusagen als eigene Risikoklassen. Setzen Sie pro Klasse Quellen, Eskalation und Release-Regel.

  2. 02

    Begrenzte Evidenzschicht aufbauen

    Nehmen Sie nur Dokumente mit Owner, Geltung, Produkt- oder Entitätskontext, Sichtbarkeit, Gültigkeit und Reviewdatum auf. Teilen Sie sie in auffindbare Passagen, ohne Überschriften, Tabellen oder Einschränkungen zu verlieren. Zeigen Sie Quelle und exakte Stelle neben der Antwort. Internetinhalte und alte Angebote werden durch Auffindbarkeit nicht zu bestätigten Fakten.

  3. 03

    Mit expliziten Evidenzzuständen generieren

    Lassen Sie nur aus erlaubtem Kontext antworten und unterscheiden Sie gestützt, teilweise gestützt, widersprüchlich und fehlend. Verlangen Sie ein Zitat für jede wesentliche Faktengruppe, nicht eines für den ganzen Absatz. Fehlt Evidenz, entstehen eine fokussierte Owner-Frage oder eine klare Lücke, aber keine Vermutung.

  4. 04

    Aussage und Belegwirkung prüfen

    Zeigen Sie generierten Text neben Passage und Käuferfrage. Der Reviewer prüft, ob die Stelle die Aussage wirklich trägt, ob Umfang und Zeit passen und ob eine neue Zusage entsteht. Wesentliche Ausnahmen gehen an den verantwortlichen Owner. Ein Zitat belegt Herkunft, aber nicht automatisch Wahrheit oder Zulässigkeit.

  5. 05

    Testen, freigeben und sicher lernen

    Nutzen Sie einen festen Evaluationssatz mit fehlenden Fakten, ähnlichen Treffern, widersprüchlichen Dokumenten, alten Policies und manipulativen Weisungen in Käuferdateien. Blockieren Sie den Release bis Pflichtfreigaben und Evidenzzustände geklärt sind. Erfassen Sie Korrekturen als vorgeschlagene Quellen- oder Prozessänderungen, nicht als automatisches globales Lernen.

Bewertung

Fragen, die den Entscheid verändern

  • Welche Evidenz ist pro Produkt, Rechtseinheit, Region und Claim-Typ massgeblich?
  • Welche Aussagen darf das Proposal Review freigeben und welche brauchen einen benannten Domain Owner?
  • Wie zeigt das System teilweise Unterstützung, Widerspruch, Ablauf und fehlende Information?
  • Wie granular muss eine Passage die exakte generierte Sprache stützen?
  • Welche Evaluationsfehler blockieren den Einsatz oder führen zurück zu manueller Arbeit?

Fehlermuster

Wo Teams die Kontrolle verlieren

01

Retrieval kann eine semantisch ähnliche Passage finden, die den generierten Claim nicht wirklich trägt.

02

Eine alte Gewinnofferte kann kundenspezifischen Text, veraltete Fakten oder nie global freigegebene Zusagen enthalten.

03

Ein sichtbarer Confidence Score kann Vertrauen schaffen, obwohl Kalibrierung und Bedeutung unklar sind.

04

Reviewer unter Termindruck können flüssige Antworten freigeben, ohne die Evidenz zu öffnen.

05

Käuferdokumente können manipulative Anweisungen enthalten, wenn fremder Inhalt nicht isoliert wird.

06

Ein korrigierter Entwurf kann unsicheren Text global lehren, wenn Änderungen die Governance umgehen.

Messung

Das fertige Ergebnis messen

Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.

  • wichtige Claims mit akzeptierter Unterstützung auf Passagenebene
  • unbelegte oder falsch eingegrenzte Claims aus Review und nach Einreichung
  • Antworten mit fehlender, widersprüchlicher oder abgelaufener Evidenz
  • Akzeptanzrate von Zitaten nach Prüfung ihrer Belegwirkung
  • faktische Änderungen zwischen KI-Entwurf und Freigabe nach Risikoklasse
  • Evaluationsquote für Abwesenheit, Widerspruch, Alter und manipulative Testfälle

Fragen

Häufige Fragen

Kann RAG Halluzinationen in Angebotsantworten beseitigen?

Nein. Retrieval kann aktuellen freigegebenen Kontext liefern, aber eine falsche Passage wählen und das Modell kann ihre Aussage übertreiben. Nutzen Sie Scope-Metadaten, Claim-Zitate, Lückenstatus, Evaluation und verantwortliches Review rund um RAG.

Beweist ein Zitat die Richtigkeit einer KI-Antwort?

Nein. Es zeigt, dass eine Quelle zugeordnet wurde. Ein Reviewer prüft weiterhin, ob die genaue Passage den Claim stützt, für Produkt und Kontext gilt, aktuell ist und eine Zusage in der Antwort autorisiert.

Soll KI ohne freigegebene Evidenz eine Angebotsfrage beantworten?

Sie soll keine Vollständigkeit erfinden. Sinnvoll sind eine sichtbare Evidenzlücke, eine fokussierte Frage an den Owner und gegebenenfalls eine klar markierte Antwortstruktur ohne erfundene Unternehmensfakten.

Welche Claims brauchen zwingend menschliche Freigabe?

Definieren Sie sie mindestens für wesentliche rechtliche, sicherheitsbezogene, datenschutzbezogene, kommerzielle, finanzielle, produktbezogene und operative Wirkung. Zertifikate, Service Levels, Preis, Roadmap und Vertragszusagen sind typische Beispiele.

Quellen

Primärquellen

Tony Kim

Über den Autor

Tony Kim

Gründer und CEO

Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.

Autorenprofil LinkedIn-Profil

Ziva

Proposal-Software für quellenbasierte Antworten auf RFPs, RFIs, DDQs und Fragebögen.

Bid-Management, Proposal-Teams, Presales sowie Security- und Compliance-Verantwortliche. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.

Ziva ansehen→