KI-Halluzinationen - was das ist und wie man das Geschäftsrisiko senkt

Eine KI-Halluzination ist eine selbstbewusste, kohärente und glaubwürdige Antwort des Modells, die nicht mit den Fakten, Ihrer Wissensdatenbank oder dem realen Systemzustand übereinstimmt. Fürs Geschäft liegt die Gefahr nicht in ungeschickter Formulierung - sondern in Output, der handlungsreif wirkt: Preise, Fristen, Rechtsformulierungen, Bestellstatus, Code-Tipps. Unten - was Halluzinationen einfach bedeuten, wo Risiko kritisch ist, und ein praktischer Kontrollrahmen, der Schaden senkt, ohne auf KI zu verzichten.

• Halluzination - plausible, aber falsche oder nicht prüfbare LLM-Antwort
• Risiko - Entscheidungen, Geld, Kunden, Reputation und Rechtsformulierungen
• Ursachen - fehlender Kontext, veraltete Daten, schwacher Prompt, keine Prüfung
• Minderung - RAG, geerdete Antworten, Human-in-the-loop, Evals
• Kein Allheilmittel - auch starke Modelle irren; nötig ist Kontrollarchitektur
• Start - ein Szenario mit Fehler-KPI, nicht „KI überall sofort“

Was KI-Halluzinationen in einfachen Worten sind

Ein Large Language Model (LLM) sagt den nächsten Textausschnitt nach Wahrscheinlichkeit vorher. Es „kennt die Wahrheit“ nicht im Alltagssinn und prüft Ihr CRM nicht von allein. Fehlen Daten, widersprechen sie sich oder braucht die Aufgabe eine genaue Referenz auf ein internes Dokument, füllt das Modell Lücken: Daten, Zahlen, Namen, „als wäre es evident“.

Typische Formen im Geschäft:

Eine Halluzination wirkt selten wie Unsinn. Häufiger ist es eine sorgfältig formulierte Unwahrheit - deshalb rutscht sie durch.

Warum Modelle „erfinden“

Kurze Ursachen, die für Geschäftsinhaber zählen:

1. Wenig oder kein Kontext. Das Modell antwortet aus Allgemeinwissen, nicht aus Ihrer Basis. Hier helfen Context Engineering und RAG.
2. Veraltetes Modellwissen. Tarife, Gesetze, Bestände und Unternehmensrichtlinien ändern sich schneller als Modellgewichte.
3. Schwache Aufgabenstellung. Vager Prompt ohne Antwortformat und ohne Erlaubnis zu „ich weiß es nicht“.
4. Druck auf Vollständigkeit. Soll das System „dem Kunden immer antworten“, erfindet das Modell lieber, als eine Lücke zuzugeben.
5. Komplexe Mehrschritt-Ketten. Ein KI-Agent oder ein Multi-Agent-Setup stapelt Fehler: ein falscher Schritt verdirbt das Ergebnis.
6. Temperatur und „kreativer“ Modus, wo Fakten nötig sind. Für Auskünfte und Status besser strengerer deterministischer Modus und Structured Output.

Trennen Sie zwei Probleme: unvollkommener Prompt und fehlende Wahrheitsquelle. Ein schöner Prompt ohne aktuelle Daten heilt keine Preis- und Bestands-Halluzinationen.

Wo Risiko fürs Geschäft kritisch ist

Nicht alle Szenarien sind gleich gefährlich. Sortieren Sie nach Fehlerkosten:

Hohes Risiko (ohne Kontrolle = nicht freigeben):

• Preise, Rabatte, Vertragsbedingungen, SLA;
• rechtliche und steuerliche Formulierungen;
• medizinische, finanzielle, HR-Hinweise „als Fakt“;
• Systemaktionen: Abbuchungen, Löschungen, Kundenmails;
• Antworten des Chatbots zum Bestellstatus ohne Backend-Check.

Mittleres Risiko:

• interne Entwürfe von Mails und Reports mit Menschenprüfung;
• Zusammenfassung langer Dokumente mit Stichproben;
• Analysehilfe, bei der der Manager entscheidet.

Niedriges Risiko:

• Brainstorming von Ideen;
• Gliederung einer Präsentation;
• Umformulierung bereits geprüften Texts.

Einfache Regel: je näher die Antwort an Geld, Kunde und irreversible Aktion - desto strenger die Prüfkette.

Wie man Risiko senkt: praktischer Kontrollstapel

1. Grounding und RAG

Bitten Sie das Modell nicht, die Preisliste zu „erinnern“. Geben Sie Fragmente aus aktueller Wissensbasis und fordern Sie Antworten nur daraus, mit Verweis auf Dokument/Absatz. Für Unternehmenswissen bauen Sie ein RAG-System: relevante Chunks finden + daraus generieren.

Mindestregeln:

• keine relevanten Fragmente - „Daten unzureichend“ antworten;
• Quelle nennen (Dokument-ID, Versionsdatum);
• „Modellmeinung“ und „Fakt aus der Basis“ nicht unmarkiert mischen.

2. Erlaubnis zu „ich weiß es nicht“

In der Systemanweisung explizit:

• Zahlen, Daten, Vertragsklauseln erfinden verbieten;
• Unsicherheit angeben lassen;
• bei Lücken an Menschen eskalieren.

Ohne das füllt jedes „höfliche“ Modell Stille mit schönem Text.

3. Structured Output und Tools statt freiem Erzählen

Wo Wahrheit im System liegt - soll das Modell ein Tool/API aufrufen, nicht über den Bestellstatus spekulieren. Status, Preis, Bestand kommen aus CRM, ERP, Lager; das Modell formatiert die Antwort über dem Fakt.

Ablauf:

Kundenfrage
     │
     ▼
Klassifizieren: Fakt / Beratung / Aktion
     │
     ├─ Fakt → API / DB / RAG → Antwort + Quelle
     ├─ Beratung → Entwurf → Mensch (bei Risiko)
     └─ Aktion → menschliche Freigabe → Tool

Ebenso bei KI im CRM: Scoring und Entwürfe - ja; Deal-Stufe ändern und Kunden allein anschreiben - nur mit Regeln und Freigabe.

4. Human-in-the-loop bei kritischen Schritten

Ein Mensch freigibt:

• Beträge und Angebote;
• ausgehende Kundenbotschaften zu strittigen Themen;
• Produktionsänderungen und Zahlungen.

Das ist kein „Misstrauen gegen KI“ - sondern operative Kontrolle, ohne die ein Pilot nicht in Produktion geht.

5. Evaluation und Qualitätsregression

Sammeln Sie 50-200 echte Fragen mit Referenzantwort oder klaren Kriterien. Vor dem Release messen:

• Anteil Antworten ohne Quelle;
• Anteil faktischer Fehler bei kritischen Feldern;
• Anteil falscher Dokumentverweise;
• durchschnittliche Eskalationszeit an Menschen.

Ohne Metriken verbessern Sie „Demo-Gefühl“, nicht Risiko.

6. Rolle und Rechte des Agenten begrenzen

Enge Rolle + enger Tool-Satz = weniger Schaden durch Halluzination. Ein Support-Agent darf keine Deals löschen. Der Orchestrator soll dem Subagenten nicht den rohen vollständigen Log geben - nur ein Briefing. Siehe Praxis Multi-Agent-Systeme.

7. Wissensversionen und Haltbarkeit

Dokumente in der Basis brauchen Datum und Owner. Eine Regel wie „Chunks älter als 90 Tage - nicht für Preise verwenden“ streicht eine ganze Fehlerklasse. Gleiches Prinzip bei Prompt und Tarifen im Vergleich Prompt / RAG / Fine-Tuning: Fine-Tuning ersetzt keine aktuelle Preisliste.

Checkliste vor dem KI-Start im Kundenkanal

Mehr als zwei „nein“ - zu früh für Auto-Antworten an Kunden. Assistant intern für Entwürfe lassen.

Häufige Umsetzungsfehler

• Chatbot auf der Website ohne RAG und ohne „ich weiß es nicht“.
• Modell bitten, „um jeden Preis hilfreich“ zu sein - es fängt an zu erfinden.
• Demo mit Idealfragen mit Produktion an krummen Kundenformulierungen verwechseln.
• Agenten breite Rechte „für alle Fälle“ geben.
• Antworten nach Release nicht monitoren: Halluzinationen kommen über Beschwerden, nicht über Metriken.
• Glauben, ein „klügeres“ Modell ersetze Kontrollarchitektur.

Fazit

KI-Halluzinationen sind kein „Bug eines schlechten Anbieters“ - sie sind eine Eigenschaft generativer Modelle: sie füllen Lücken mit glaubwürdigem Text. Fürs Geschäft heißt die Aufgabe nicht „KI verbieten“, sondern einen Kontur zu bauen, in dem das Modell nicht unbemerkt über Preise, Status und Verpflichtungen lügen kann. Fundament - aktuelle Quellen, Erlaubnis zu „ich weiß es nicht“, Tools statt Vermutungen, Menschen bei Risiken und regelmäßige Qualitätsprüfung. Dann beschleunigt KI die Arbeit, statt einen teuren Strom selbstsicherer Fehler zu erzeugen.

Häufig gestellte Fragen

Kann man KI-Halluzinationen vollständig beseitigen?

Vollständig - nein, wenn freie Textgenerierung gemeint ist. Schaden lässt sich stark senken: Antworten an Quellen binden, Erfinden verbieten, Fakten aus API/DB holen und kritische Felder prüfen. Ziel des Geschäfts ist beherrschbares Risiko, nicht das „perfekte Modell“.

Garantiert RAG, dass das Modell nicht lügt?

Nein. RAG senkt Risiko, wenn Retrieval den richtigen Ausschnitt findet und der Prompt Überschreiten verbietet. Liefert Retrieval Irrelevantes oder Veraltetes, kann das Modell trotzdem eine überzeugende, aber falsche Antwort bauen. Nötig sind Indexqualität, Dokumentversionen und Ablehnung bei schwachem Match.

Braucht man Human-in-the-loop immer?

Bei Risiken - ja. Für interne Team-Entwürfe darf Kontrolle lockerer sein. Für Kundenantworten zu Geld, Verträgen und Systemaktionen sind menschliche Bestätigung oder eine harte Backend-Regel am Start Pflicht und bleiben oft in Produktion.

Hilft ein teureres Modell (GPT / Claude / Gemini)?

Ein stärkeres Modell folgt meist besser Anweisungen und bricht seltener bei schwierigem Text - ersetzt aber weder aktuelle Daten noch Checks. Für Fakten über Ihr Geschäft zählen Grounding und Tools mehr als die Chat-Marke. Vergleichen Sie „Modell + Architektur“, nicht nur die Browser-Demo.

Womit startet ein kleines Unternehmen in 1-2 Wochen?

Wählen Sie ein Szenario (z. B. FAQ-Antworten aus einer Wissensbasis). Verbinden Sie 20-50 Dokumente, aktivieren Sie „ich weiß es nicht“, loggen Sie Antworten, sammeln Sie 30 Referenzfragen, messen Sie die Fehlerrate. Erst nach Qualitätsschwelle Kunden anbinden - und menschliche Eskalation für strittige Fälle behalten.