Ein KI-Assistent für den Support im B2B-Shop: Tools, Berechtigungen und die Übergabe an Menschen

Support in einem B2B-Shop sieht anders aus als im Endkundengeschäft. Es schreiben Einkäufer, Techniker und Buchhalter, die genau wissen, was sie wollen: den Liefertermin von Auftrag 4711, eine Kopie der Rechnung vom letzten Monat, die Konformitätserklärung für ein Teil, den Ersatz für einen abgekündigten Artikel. Die meisten dieser Antworten liegen schon im ERP, im PIM oder in einem Dokumentenspeicher; Zeit kostet das Finden und Aufschreiben.

Das macht B2B-Support zu einem guten Einsatzfeld für einen LLM-Assistenten und zugleich zu einem Ort, an dem Fehler teuer sind: Ein falscher Liefertermin stoppt eine Fertigungslinie, ein falscher Preis wird zum Streitfall. Dieser Beitrag beschreibt, wie ich einen solchen Assistenten für einen B2B-Shop entwerfen würde: welche Anfragen er übernimmt, wie Tools ihre Berechtigungen bekommen, wo Menschen eingebunden bleiben und woran man erkennt, ob er funktioniert.

Was B2B-Kunden den Support tatsächlich fragen

Bevor man ein Modell oder einen Anbieter wählt, sortiert man ein paar hundert echte Tickets nach Anfragetypen. In den B2B-Shops, an denen ich arbeite, kehren dieselben Kategorien wieder; sie unterscheiden sich vor allem darin, wo die Antwort liegt und was eine falsche Antwort kostet.

Die ersten drei Zeilen sind Abfragen mit genau einer richtigen Antwort in einem System, das Sie kontrollieren. Dort verdient sich ein Assistent seinen Platz. Die letzte Zeile ist der Bereich, in dem er nie improvisieren sollte.

Zwei Lehren aus dem Endkunden-Support

Die bekanntesten Zahlen kommen von Klarna. Im Februar 2024 meldete das Unternehmen, sein KI-Assistent habe im ersten Monat 2,3 Millionen Gespräche geführt, zwei Drittel der Kundenservice-Chats, und die Arbeit von 700 Vollzeitkräften erledigt, mit 25 % weniger Folgeanfragen und Anliegen, die in unter 2 statt 11 Minuten gelöst wurden. Im Mai 2025 sagte der CEO gegenüber Bloomberg, Klarna stelle wieder menschliche Supportkräfte ein, weil der günstigere KI-Service geringere Qualität geliefert habe, und Kunden müssten immer wissen, dass es einen Menschen gibt, wenn sie einen wollen.

Die zweite Lehre ist rechtlich. Im Fall Moffatt gegen Air Canada befasste sich ein Tribunal in British Columbia mit einem Chatbot, der einem Kunden sagte, er könne einen Trauerfalltarif nachträglich beantragen, was einer anderen Seite der Airline widersprach. Air Canada argumentierte, der Chatbot sei eine eigene Rechtsperson, die für ihr Handeln selbst verantwortlich sei. Das Tribunal wies das zurück, machte die Airline für alle Informationen auf ihrer Website verantwortlich, ob von einer statischen Seite oder einem Chatbot, stellte fest, dass sie nicht angemessen dafür gesorgt habe, dass der Chatbot korrekt ist, und sprach rund 650 kanadische Dollar plus Zinsen und Gebühren zu. Es ist eine Entscheidung in einem Bagatellverfahren und kein Präzedenzfall für Österreich oder Deutschland, aber die Begründung ist die, die ich von jedem Gericht erwarten würde.

Architektur: Retrieval, Tools und ein Übergabeweg

Ein B2B-Support-Assistent hat drei Arten von Fähigkeiten, und ihre Trennung macht ihn sicher. Retrieval über öffentliches Wissen: Produktdokumentation, FAQs, AGB, Versandregeln. Tools über Kontodaten: Bestellungen, Lieferungen, Rechnungen, alle auf die eingeloggte Firma beschränkt. Und ein Übergabe-Tool, das im Ticketsystem oder CRM einen Fall mit Zusammenfassung anlegt, damit die Person, die übernimmt, nicht bei null beginnt.

Für die Retrieval-Seite gilt die übliche RAG-Technik: Chunking, hybride Suche für Artikelnummern und Reranking, wie in einer produktiven RAG-Pipeline. Ein B2B-spezifischer Punkt: AGB, Versandregeln und Gewährleistungsbedingungen ändern sich, und ein Assistent, der die Rückgabefrist vom letzten Jahr nennt, ist das Air-Canada-Szenario im Kleinen. Dokumente mit Gültigkeitsdatum und genau einer aktuellen Version indexieren und den Assistenten das Dokument zitieren lassen, aus dem er geantwortet hat.

Tools, die im Kontext des Kunden laufen

OWASPs LLM06:2025 Excessive Agency nennt drei Ursachen: zu viel Funktionalität, zu viele Berechtigungen und zu viel Autonomie. Die Gegenmaßnahmen lesen sich wie eine Designvorgabe für einen Support-Assistenten: nur nötige Tools anbieten, jedes Tool eng halten, Erweiterungen im Kontext des Nutzers mit minimalen Rechten ausführen, für folgenreiche Aktionen eine Freigabe verlangen und Autorisierung in den nachgelagerten Systemen durchsetzen, statt das Modell entscheiden zu lassen, was erlaubt ist.

Im Code ist die Regel einfach: Das Modell darf eine Auftragsnummer übergeben, nie eine Kundennummer. Der Server nimmt die Firmen-ID aus der Session, und die Backend-API prüft sie noch einmal. Eine eingeschleuste Anweisung in einer Produktbewertung kann den Assistenten nicht dazu bringen, fremde Rechnungen zu lesen, weil kein Tool diesen Parameter annimmt.

// server/api/assistant.post.ts (Nuxt, AI SDK style tools)
import { z } from 'zod'
import { tool } from 'ai'

export default defineEventHandler(async (event) => {
  const { user } = await requireUserSession(event)        // 401 if not logged in
  const companyId = user.companyId                          // from the session, never from the model

  const tools = {
    getOrderStatus: tool({
      description: 'Status, delivery date and tracking for one order of the current customer.',
      inputSchema: z.object({ orderNumber: z.string().regex(/^[0-9]{6,10}$/) }),
      execute: async ({ orderNumber }) => {
        const order = await erp.getOrder(orderNumber, { companyId })   // ERP enforces the scope too
        if (!order) return { found: false }
        return { found: true, status: order.status, confirmedDelivery: order.confirmedDate ?? null, tracking: order.trackingUrl ?? null }
      },
    }),
    handOffToSupport: tool({
      description: 'Create a support case with a summary when the request needs a person.',
      inputSchema: z.object({ topic: z.enum(['price', 'complaint', 'return', 'technical', 'other']), summary: z.string().max(1500) }),
      execute: async ({ topic, summary }) => crm.createCase({ companyId, userId: user.id, topic, summary }),
    }),
  }
  // ... streamText({ model, system, messages, tools, stopWhen: stepCountIs(5) })
})

Man beachte, was das Bestell-Tool zurückgibt: einen bestätigten Liefertermin oder null. Hat das ERP keinen bestätigten Termin, sagt der Assistent das, statt zu schätzen. Diese eine Designentscheidung verhindert die schädlichste Klasse von B2B-Supportfehlern. Die größeren Identitätsfragen, Service-Accounts und Token-Scopes, behandle ich in KI-Agenten sind Identitäten.

Was bei Menschen bleibt

Ein Rollout ist eine Abfolge von Berechtigungen, kein Launch. Ich beginne nur lesend: Status, Dokumente, Rechnungen. Schreibende Aktionen wie das Nachbestellen eines früheren Auftrags oder das Anlegen einer Retourenanfrage folgen danach, und nur mit einem ausdrücklichen Bestätigungsschritt in der Oberfläche, der genau zeigt, was abgeschickt wird, nach dem Muster aus Freigabestufen mit Human in the Loop. Manches wandert nie zum Assistenten:

• Preise, Rabatte und Angebote außerhalb der veröffentlichten Preisliste.
• Lieferzusagen, die das ERP nicht bestätigt hat.
• Auslegung von Verträgen, Gewährleistung oder Haftung.
• Technische Freigabe eines Ersatzteils für eine sicherheitsrelevante Anwendung.
• Alles, was einen verärgerten Key Account betrifft; nach Kundenstufe routen, nicht nur nach Thema.

In diesen Fällen besteht die Aufgabe des Assistenten darin, die Fakten zu sammeln, also Auftragsnummer, Artikel, Menge und was schiefging, und mit einer Zusammenfassung zu übergeben. Das ist trotzdem wertvolle Arbeit, und es ist der Teil, den Kunden bemerken, wenn die Person, die zurückruft, den Fall schon kennt.

Die Übergabe gestalten

Klarnas CEO hat die Anforderung klar formuliert: Kunden müssen wissen, dass es immer einen Menschen gibt, wenn sie einen wollen. In einem B2B-Shop heißt das: eine jederzeit sichtbare Option „mit einem Menschen sprechen“ im Chat, nicht erst nach drei gescheiterten Antworten, plus klare Angaben zu den Supportzeiten. Bei der Übergabe sollte der Fall das Gespräch, die genutzten Tool-Ergebnisse und die eigene Zusammenfassung enthalten, als maschinell erzeugt gekennzeichnet, damit der Mitarbeiter sie prüft, statt ihr zu vertrauen.

Zwei Auslöser für die automatische Übergabe funktionieren gut: Die Anfrage fällt unter ein Thema der Liste „bleibt bei Menschen“, oder der Assistent hat für seine Antwort kein Tool-Ergebnis und keine Quelle. Der zweite Auslöser ist der wichtige. Ein Assistent, der sagt „Ich habe keinen bestätigten Liefertermin gefunden und das an unser Auftragsteam weitergegeben“, ist nützlich; einer, der rät, ist ein Haftungsrisiko.

Transparenz, AI Act und Datenschutz

Artikel 50 des EU AI Act gilt ab 2. August 2026. Sein erster Absatz verlangt von Anbietern, KI-Systeme, die direkt mit Menschen interagieren, so zu gestalten, dass die Betroffenen erfahren, dass sie mit einem KI-System interagieren, es sei denn, das ist für eine angemessen informierte, aufmerksame und verständige Person offensichtlich. Ein Chat-Widget, das wie ein Live-Chat mit benanntem Mitarbeiter aussieht, ist genau der Fall, in dem es nicht offensichtlich ist; also kennzeichnen. Meine Checkliste zu Artikel 50 behandelt die Umsetzungsdetails.

B2B heißt nicht: keine personenbezogenen Daten. Ansprechpartner, Mail-Adressen und Lieferadressen von Personen bei Ihren Kunden sind personenbezogene Daten im Sinne der DSGVO, und das Gesprächsprotokoll wird sie enthalten. Legen Sie die Aufbewahrungsdauer für Transkripte fest, was zum Modellanbieter gelangt und unter welchen Auftragsverarbeitungsbedingungen, und ob Sie eine DSFA brauchen; das durchgerechnete DSFA-Beispiel nimmt genau einen Support-Assistenten als Fall.

Messen, ob es hilft

Die Entlastungsquote, also der Anteil der Chats, die nie einen Menschen erreichen, ist die Zahl, die Anbieter mögen, und die, die Fehler verdeckt: Ein Kunde, der aufgibt, erreicht auch nie einen Menschen. Anbieter definieren außerdem Lösung auf eigene Weise. Intercom, das seinen Agenten Fin mit 0,99 Dollar pro Ergebnis abrechnet, zählt eine Lösung, wenn nach der letzten Antwort von Fin keine weitere Hilfe angefragt wird, und berechnet ein Ergebnis pro Gespräch. Das ist eine vernünftige Abrechnungsregel und eine schwache Qualitätskennzahl, also messen Sie selbst.

Die geprüften Gespräche in ein Eval-Set überführen und es vor jeder Prompt- oder Modelländerung laufen lassen, wie in LLM-Evals für Produktfunktionen beschrieben. Und bevor Kunden irgendetwas sehen, den Assistenten einige Wochen als internes Werkzeug für das eigene Supportteam betreiben, das Antwortentwürfe verschickt oder verwirft. So entstehen gelabelte Daten, das Team lernt, wo er scheitert, und die erste Version für Kunden startet mit bekannten Grenzen statt mit Hoffnungen.

Quellen

1. Klarna: AI assistant handles two-thirds of customer service chats in its first month (press release, 2024)
2. Entrepreneur: Klarna is hiring customer service agents again, according to its CEO (May 2025)
3. ABA Business Law Today: BC tribunal confirms companies remain liable for information provided by AI chatbot
4. OWASP GenAI Security Project: LLM06:2025 Excessive Agency
5. OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
6. EU AI Act, Article 50: Transparency obligations
7. Intercom: Fin pricing and billable outcomes