KI-Chatbot im Unternehmen: 7 Fragen, die Sie vor der Einführung klären müssen

Ein Chatbot bewegt sich zwischen zwei Regelwerken, die parallel gelten. Die DSGVO greift, sobald personenbezogene Daten verarbeitet werden – und das ist bei jedem Chat der Fall, in dem ein Kunde Name, Bestellnummer oder ein Anliegen eingibt. Der EU AI Act reguliert zusätzlich das KI-System selbst, unabhängig davon, ob personenbezogene Daten fließen.

Der Stichtag 2. August 2026 bringt die Transparenzpflicht nach Artikel 50: Ein Chatbot muss sich als KI zu erkennen geben, und mit KI erzeugte Inhalte müssen entsprechend gekennzeichnet werden. In der Praxis genügt dafür oft ein klarer Hinweis zu Beginn der Konversation – aber er muss vorhanden und eindeutig sein. Wichtig zur Einordnung: Das im Mai 2026 politisch geeinigte „Digital-Omnibus“-Paket hat viele der umfangreichen Hochrisiko-Pflichten voraussichtlich auf 2027/2028 verschoben. Die Transparenzpflicht für Chatbots bleibt davon jedoch unberührt und gilt zum August 2026.

Ein zweiter Punkt wird gern übersehen: Die Pflicht zur KI-Kompetenz (Artikel 4) gilt bereits seit Februar 2025. Unternehmen müssen sicherstellen, dass Mitarbeitende, die KI-Systeme bedienen, ausreichend geschult sind. Wer das nie dokumentiert hat, ist streng genommen schon heute in der Pflicht.

Auf der DSGVO-Seite lauten die entscheidenden Fragen: Wohin fließen die Gesprächsdaten? Existiert ein Auftragsverarbeitungsvertrag mit dem Anbieter? Verlassen Prompts und Protokolle den europäischen Rechtsraum? Und werden Ihre Eingaben womöglich zum Training fremder Modelle genutzt? Das Bußgeldrisiko hat DSGVO-Dimension – ein Grund mehr, diese Frage vor dem Go-live zu klären, nicht danach.

Diese Architekturentscheidung ist die folgenreichste überhaupt, und sie ergibt sich direkt aus Frage 1. Sie bestimmt, wer Ihre Daten sieht, was der Betrieb kostet und wie schnell Sie starten können.

Cloud-Modelle großer Anbieter sind leistungsstark und in Minuten angebunden. Der Preis dafür: Ihre Daten verlassen das Haus. Hier lohnt der genaue Blick auf Serverstandort, Auftragsverarbeitungsvertrag und die Frage, ob sich das Training mit Ihren Daten abschalten lässt.

Lokale, selbst gehostete Modelle – etwa über Ollama auf eigener oder deutscher Infrastruktur – behalten die Daten vollständig in Ihrer Kontrolle. Für sensible Kunden- und Unternehmensdaten ist das der datenschutzrechtlich saubere Weg. Der Kompromiss liegt in Infrastruktur und Modellgröße: Ein lokal betriebenes Modell braucht passende Hardware und erreicht nicht immer die Spitzenqualität der größten Cloud-Modelle – für die meisten Fachanwendungen ist der Unterschied aber gering.

In der Praxis ist oft ein hybrider Ansatz die beste Antwort: sensible Daten bleiben lokal, unkritische Aufgaben dürfen in die Cloud. Genau auf diesem Prinzip basiert unsere Plattform RAGspace – DSGVO-konform, in Deutschland gehostet und mit lokaler Inferenz für schützenswerte Daten.

Ein RAG-Chatbot ist immer nur so gut wie das Wissen, auf das er zugreift. Das Prinzip: Bevor das Sprachmodell antwortet, holt es die passenden Stellen aus Ihren Dokumenten und formuliert daraus eine Antwort. Das macht den Bot fachlich – und verlagert die Verantwortung auf die Datenqualität.

Der alte Grundsatz „Garbage in, garbage out“ gilt hier gnadenlos. Veraltete PDFs, sich widersprechende Handbücher, unstrukturierte Datenberge – all das produziert falsche oder widersprüchliche Antworten, und zwar überzeugend formuliert. Die Fragen vor dem Start lauten deshalb: Welche Quellen speist der Bot? Wie aktuell sind sie? Wer pflegt sie? Und wie werden die Inhalte zerlegt, in Vektoren überführt (Embeddings) und indexiert?

Sprachmodelle können mit voller Überzeugung Dinge erfinden. Im internen Test ist das ärgerlich – im Kundendialog kann eine erfundene Preisauskunft, eine falsche Rechtsangabe oder ein nicht existierendes Versprechen echten Schaden anrichten.

Vollständig ausschließen lässt sich das Risiko nicht, aber wirksam eindämmen. Die wichtigsten Hebel: eine strikte RAG-Verankerung, bei der der Bot ausschließlich aus den abgerufenen Quellen antwortet; Quellenangaben, damit Nutzer die Antwort nachvollziehen können; ein sauberer Fallback nach dem Muster „Das weiß ich nicht sicher – ich verbinde Sie mit einem Kollegen“ statt einer geratenen Antwort; sowie Tests mit realen Fragen vor und nach dem Launch.

Der Denkfehler, den es zu vermeiden gilt: nicht auf hundertprozentige Korrektheit hoffen, sondern das System so gestalten, dass es im Zweifel elegant scheitert und an einen Menschen übergibt.

Die Kosten eines KI-Chatbots teilen sich in zwei Blöcke. Der Setup-Aufwand umfasst Integration, Datenaufbereitung und Indexierung. Der laufende Betrieb umfasst Inferenz (Cloud-Nutzung oder eigene Hardware), Hosting sowie Wartung und Kuratierung.

Die beiden Architekturen aus Frage 2 verhalten sich hier gegensätzlich: Cloud bedeutet niedrige Anfangskosten, aber nutzungsabhängige laufende Kosten, die mit dem Volumen steigen. Lokal bedeutet höhere Anfangsinvestition in Hardware, dafür planbare, weitgehend feste Betriebskosten – bei hohem Volumen oft günstiger und datenschutzrechtlich im Vorteil.

Unterschätzt werden fast immer die „weichen“ Posten: laufende Inhaltspflege, Monitoring und die Iteration nach dem Launch. Wer diese einplant, erlebt später keine Überraschung. Und die entscheidende Gegenrechnung: Welches Problem löst der Bot? Weniger Support-Tickets, kürzere Einarbeitung neuer Mitarbeitender, eine 24/7-Vorabberatung im Verkauf? Definieren Sie den Nutzen vor dem Bau – womit wir bei Frage 7 wären.

Ein Chatbot steht selten für sich. Erst die Anbindung an bestehende Systeme macht ihn wertvoll – und stellt gleichzeitig die meisten technischen Fragen. Entscheidend ist, wo der Bot lebt und worauf er zugreifen muss.

Auf der Website arbeitet er als Support- und Vorverkaufs-Widget. Im Intranet wird er zum internen Wissens- und Onboarding-Assistenten. In Verbindung mit CRM oder Ticketsystem gewinnt er Kontext, kann sauber an menschliche Kollegen übergeben und protokolliert Vorgänge nachvollziehbar.

Die Leitfragen: Welche Systeme sollen angebunden werden, über welche Schnittstellen? Wird eine Anmeldung (SSO) benötigt? Wie funktioniert die Übergabe an einen Mitarbeiter? Und wie werden Gespräche für Qualitätssicherung und Compliance protokolliert? Ein Chatbot, der weder übergeben noch protokollieren kann, ist nur eine halbe Lösung.

Ohne Kennzahlen lässt sich echter Nutzen nicht von Neuheitseffekt unterscheiden. Legen Sie die KPIs deshalb vor dem Launch fest – nicht danach, wenn die Zahlen bereits laufen.

Je nach Einsatzzweck bieten sich unterschiedliche Größen an: die Lösungsquote (wie viele Anliegen der Bot eigenständig klärt), die Entlastung des Supports, die Kundenzufriedenheit nach dem Chat, die Antwortzeit, die verkürzte Einarbeitungszeit oder die Zahl qualifizierter Leads. Wichtig sind außerdem die „Warnzahlen“: Eskalationsquote und Anteil der Fälle, in denen der Bot keine Antwort findet.

Setzen Sie eine Baseline, prüfen Sie nach vier bis acht Wochen und iterieren Sie an Inhalten und Prompts. Die Erfolgsmessung schließt den Kreis: Sie deckt genau die Schwächen bei Datenqualität und Halluzinationen auf, um die es in den Fragen 3 und 4 ging.