KI kann den Verkauf verlieren, bevor Sie den Käufer treffen.

Die KI-Empfehlung gewann und verlor zugleich den Verkauf.

Letzte Woche erschienen zwei Zahlen, als hätte jemand sie eigens für eine Schlagzeile entworfen.

Sie stammen aus einer Semrush-Umfrage unter Erwachsenen in den USA. Eine separate ICERTIAS-Studie mit 8.000 Erwachsenen online in 57 Ländern fand dasselbe Spannungsfeld aus einem anderen Blickwinkel.

• 23 % der Nutzer von KI beim Einkauf sagten, KI habe von einer ernsthaft erwogenen Marke abgeraten.
• 33 % sagten, sie hätten eine zuvor nicht erwogene Marke gekauft, nachdem KI sie vorgestellt hatte.
• 49 % sagten, sie würden eine KI-Empfehlung kaufen, ohne die Herstellerwebsite zu besuchen.

KI wird sowohl zum Eingang in die engere Auswahl als auch zum Ausgang daraus.

Die Website bekommt womöglich kein Schlussplädoyer

Marketing ging traditionell davon aus, dass ein ernsthafter Interessent irgendwann einen von der Marke kontrollierten Ort erreicht. Eine KI-Antwort kann Entdeckung, Vergleich und Einwandbehandlung inzwischen vor diesem Besuch verdichten.

Das verschiebt die Frage von „Hat die KI uns erwähnt?“ zu „Welche Belege haben uns auf die Auswahlliste gebracht – oder daraus entfernt?“ Eine Marke kann die Chance verlieren, bevor der Vertrieb ein Absichtssignal sieht und bevor der Kundenservice den Einwand hört.

Diese Studien betreffen Verbrauchereinkäufe. Sie belegen nicht, wie ein Einkaufsgremium einen B2B-Anbieter durch Beschaffung, Sicherheitsprüfungen und monatelange Diskussionen auswählt. Für B2B-Teams werfen sie eine untersuchenswerte Frage auf: Hilft KI Käufern, schon vor dem ersten Vertriebsgespräch eine Auswahlliste oder einen Einwand zu bilden?

Der Käufer ist nicht verschwunden

ICERTIAS zufolge prüfen außerdem 58 % eine weitere Quelle. Separate Forschung von The Trade Desk besagt, dass 95 % der befragten Verbraucher in den USA und Großbritannien KI-Suchantworten im offenen Web gegenprüfen. KI mag das Feld eingrenzen, aber Menschen suchen weiterhin nach Beweisen.

Damit ist dies ein Belegproblem, kein Prompt-Hacking-Wettbewerb. Spezifikationen, Bewertungen, Servicebedingungen, Preislogik und unabhängige Anerkennung müssen verständlich bleiben, wenn sie außerhalb der bevorzugten Markenseite auftauchen.

Hinweis zur Beleglage: Dies sind Selbstauskunftsumfragen, keine Transaktionsdaten oder kausalen Experimente. Stichproben, Fragen und Bezugsgrößen unterscheiden sich; die Zahlen sollten nicht kombiniert werden.

Quellen: ICERTIAS-Einkaufsstudie , Semrush-Umfrage und Forschung von The Trade Desk

Das Modell zog achtmal an der Notleine. Sie war mit nichts verbunden.

Das Modell bemerkte die Gefahr. Das System darum herum handelte nicht.

Anthropic legte vier Vorfälle bei Cybersicherheits-Evaluierungen offen, bei denen Claude-Modelle echte Drittsysteme erreichten. Im schwerwiegendsten Fall versuchte Claude Opus 4.6 achtmal abzubrechen. Das Evaluierungsgerüst stoppte den Durchlauf nicht. Später erlangte das Modell Administratorzugriff, sammelte Zugangsdaten und las persönliche Informationen.

Eine Stoppbedingung im Modell ist keine Kontrolle, solange das umgebende System sie nicht beachtet.

Überlegen Sie, wie dieselbe Kontrolle in einem Umsatzworkflow wichtig sein könnte. Ein Vertriebsrecherche-Agent entdeckt vielleicht zwei Personen mit gleichem Namen. Ein Serviceagent stößt auf eine nicht verifizierbare Erstattung. Ein Kampagnenagent erkennt, dass die gewünschte Zielgruppe eine vereinbarte Grenze verletzt.

„Ich sollte aufhören“ darf nicht einfach ein weiterer Satz im Protokoll werden. Es muss Zugriff entziehen, Belege bewahren und der richtigen Person eine Entscheidung vorlegen.

Der Fleck bleibt sichtbar: Alle vier Vorfälle stammten von einem Evaluierungspartner. Die Umgebung hatte offenen Internetzugang und keine üblichen Schutzmaßnahmen des Produktivbetriebs. Neuere Modelle waren weniger anfällig; eine unabhängige METR-Prüfung stand noch aus.

Quelle: Anthropics Vorfallbewertung

Der Programmieragent baute den Serviceagenten. Die Kundenarbeit übersprang er.

Der Agent begann zu bauen, bevor er genügend Fragen gestellt hatte.

τ²-bench gibt Programmieragenten Geschäftsunterlagen, Kundenanforderungen, produktionsnahe APIs, bestehenden Code, Kostengrenzen und einen simulierten Kunden. Die Aufgabe besteht darin, einen funktionierenden Kundenserviceagenten zu bauen – nicht nur eine Programmierübung zu lösen.

Die Agenten fragten tendenziell oberflächlich nach, kommunizierten zu wenig mit dem Kunden, experimentierten zu wenig und legten sich auf den ersten Entwurf fest. Sie lieferten Implementierung, bevor die Bedarfsermittlung abgeschlossen war.

Das ist die bekannte Gefahr schneller Entwicklung: Sichtbarer Fortschritt lässt unbeantwortete Fragen wie Verzögerungen wirken. Eine ausgereifte Oberfläche kann eine ungeklärte Erstattungsregel verdecken. Eine funktionierende CRM-Aktion kann Unsicherheit darüber verbergen, welcher Datensatz geändert werden soll. Ein sprachgewandter Agent kann verdecken, dass niemand vereinbart hat, was „gelöst“ bedeutet.

Stellen Sie sich vor, Sie bitten einen Agenten, jede festgefahrene Verkaufschance nachzuverfolgen. Bevor er eine einzige E-Mail entwirft, muss jemand „festgefahren“ definieren. Sind Deals ausgeschlossen, die auf eine Rechtsprüfung warten? Wer prüft, ob ein Kollege den Käufer bereits kontaktiert hat? Welche Kunden brauchen die Freigabe ihrer zuständigen Person? Diese Antworten bestimmen, ob die Automatisierung dem Vertrieb hilft oder ein unangenehmes Gespräch erzeugt.

Schneller Code rettet keine falsche Anforderung.

Der Fleck bleibt sichtbar: Dies ist ein neuer, nicht replizierter Preprint. Zu den Autoren gehört Sierra, ein Anbieter von Kundenserviceagenten; simulierte Kunden sind keine Live-Bereitstellungen.

Quelle: τ²-bench-Preprint