Wissen / KI-Chatbot und Website-Integration

KI-Chatbot auf der Website: Kennzeichnung und klare Grenzen

Ein KI-Chatbot auf der Firmenwebsite braucht eine klar begrenzte Aufgabe, verständliche Kennzeichnung und geprüfte Wissensquellen. Vor dem Einsatz werden Datenflüsse, technische Berechtigungen und Fehlerfälle geklärt. Besucher sollten einen verlässlichen Weg zu Menschen finden. Eine flüssige Antwort bestätigt weder ihre Richtigkeit noch eine verbindliche Zusage. Ruhrstack kann die vereinbarte Integration und Prüfung begleiten.

Veröffentlicht am / Aktualisiert am / Redaktion: Ruhrstack / Lesezeit für den gesamten Artikel: 10 Minuten

01 / AUFGABE EINGRENZEN

Welche Frage soll der Chatbot besser beantworten?

Der Einstieg ist eine konkrete Besucheraufgabe und kein möglichst großes Gesprächsangebot.

Ein Chatbot kann interessant sein, wenn Besucher dieselbe Auswahlfrage unterschiedlich formulieren und dazu mehrere geprüfte Informationen benötigen. Für eine Telefonnummer, Öffnungszeit oder einzelne Leistungsbeschreibung reicht oft eine verständliche Seite. Schreiben Sie zuerst auf, welche Frage heute offenbleibt und welche nächste Handlung danach möglich sein soll.

Grenzen Sie den ersten Einsatz beispielsweise auf die Orientierung zwischen drei angebotenen Wartungsarten ein. Eine technische Freigabe für eine Maschine, eine individuelle Preiszusage oder ein verbindlicher Termin gehören dadurch nicht automatisch dazu. Halten Sie erlaubte Antworten, ausgeschlossene Aufgaben und den Umgang mit unbekannten Fragen gemeinsam fest.

Wenn Besucher vor allem vorhandene Dokumente finden sollen, lohnt sich außerdem die Prüfung einer verständlichen internen Website-Suche. Der Chatbot muss einen zusätzlichen Nutzen zeigen. Ein eigener Projektrahmen verhindert, dass aus einer Informationshilfe unbemerkt eine entscheidende Stelle im Kundenprozess wird.

02 / KENNZEICHNUNG KLÄREN

Schon beim ersten Kontakt muss die Rolle verständlich sein.

Eine Information über KI und ein gut organisierter Service erfüllen verschiedene Aufgaben.

Artikel 50 Absatz 1 der KI-Verordnung verpflichtet Anbieter direkt mit Menschen interagierender KI-Systeme zur entsprechenden Gestaltung: Betroffene sollen erfahren, dass sie mit KI interagieren, sofern dies aus Sicht einer angemessen informierten, aufmerksamen und verständigen Person im jeweiligen Kontext nicht offensichtlich ist. Nach Absatz 5 muss die Information klar, unterscheidbar und spätestens bei der ersten Interaktion erfolgen; anwendbare Anforderungen an Barrierefreiheit bleiben zu beachten.

Die Kommissionsleitlinien vom Juli 2026 erläutern die seit 2. August 2026 geltenden Transparenzpflichten. Anbieter und Betreiber sind dabei unterschiedliche Rollen. Wer einen Dienst einbindet, ist nicht allein deshalb stets Anbieter. Die konkrete Rollenverteilung gehört vorab geklärt, besonders bei einer Entwicklung oder Bereitstellung unter eigenem Namen.

Als eigene Formulierungshilfe eignet sich etwa: „Sie sprechen mit einer KI für allgemeine Fragen zu unseren Leistungen. Persönliche Beratung erreichen Sie über Kontakt.“ Ob Hinweis, Platzierung und übrige Gestaltung im konkreten Einsatz genügen, wird gesondert geprüft. Ein menschlicher Vorname oder ein Portrait sollte keine falsche Erwartung an einen besetzten Serviceplatz erzeugen.

03 / WISSENSQUELLEN PRÜFEN

Eine Antwort braucht eine überprüfbare Grundlage.

Geprüfte Unterlagen helfen nur, wenn Auswahl, Aktualität und tatsächliche Antwort zusammenpassen.

Das freiwillige NIST-Profil für generative KI behandelt plausibel wirkende falsche Ausgaben und unangemessenes Vertrauen als Risiken. Daraus folgt keine feste Fehlerquote für Ihren Chatbot. Für den Betrieb sollten Sie jedoch zwischen einer gut formulierten Antwort und einer durch freigegebene Informationen belegten Aussage unterscheiden.

Bei einer Dokumentenanbindung, häufig RAG genannt, sucht die Anwendung passende Textstellen und stellt sie dem Sprachmodell für die Antwort bereit. Die OWASP-Hinweise zur RAG-Sicherheit nennen unter anderem nachvollziehbare Quellen und wirksame Zugriffsgrenzen. Eine solche Anbindung beseitigt weder erfundene Aussagen noch ihre eigenen zusätzlichen Angriffsflächen.

Beginnen Sie mit einem kleinen freigegebenen Wissensbestand. Zu jedem Eintrag gehören verantwortliche Person, Gültigkeit und erlaubte Nutzung. Ein vertrauliches Angebot wird nicht allein durch seine technische Auffindbarkeit zur öffentlichen Auskunft. Zugriffsregeln müssen vor der Übergabe an das Modell greifen. Änderungen und zurückgezogene Inhalte müssen auch in abgeleiteten Suchbeständen und Antwortspeichern ankommen.

Prüfen Sie bei einer Beispielantwort die angezeigte Fundstelle selbst: Trägt sie die behauptete Aussage? Ein Quellenlink ist kein automatischer Beweis. Die redaktionelle Prüfung einzelner Aussagen vertieft unser Beitrag zu Fakten in KI-Texten.

04 / DATENFLÜSSE BESCHREIBEN

Der Chatverlauf ist ein eigener Verarbeitungsvorgang.

Die sichtbare Sprechblase zeigt nicht, welche Systeme Eingaben erhalten.

Die DSK-Orientierungshilfe zu KI und Datenschutz empfiehlt, Zwecke und Verantwortlichkeiten vor dem Einsatz festzulegen. Rechtsgrundlage, Informationen für Betroffene und Rollen beteiligter Dienstleister müssen zum tatsächlichen Verfahren passen. Zusätzlich ist zu klären, ob Eingaben oder Antworten zum Training genutzt werden, welche Historie entsteht und wie Betroffenenrechte praktisch bearbeitet werden.

Zeichnen Sie den Weg vom Browser über Website, Chatdienst und Wissenssuche bis zu einem möglichen Ticketsystem auf. Notieren Sie für jede Station Daten, Empfänger und vorgesehene Aufbewahrung. Eine technische Betreuung kann diese Übersicht erstellen; die rechtliche Einordnung und notwendige Vereinbarungen werden mit der zuständigen Fachberatung geklärt.

Für einen öffentlichen Orientierungsdialog sollten keine Kundennummer oder vertraulichen Unterlagen angefordert werden, wenn die Aufgabe diese Angaben nicht benötigt. Ein Hinweis auf sparsame Eingaben ersetzt keine passende Verarbeitung. Ob bereits das Laden des Widgets zusätzliche Einwilligung verlangt, ist eine eigene Frage. Dafür hilft der Ratgeber zum Prüfen des Cookiebannerbedarfs.

05 / ENTSCHEIDUNGSMATRIX

Für jede Antwortklasse einen nächsten Schritt festlegen.

Die eigene Matrix ist eine Planungsunterlage und keine rechtliche Freigabeliste.

Die folgende Vorlage verbindet erwartete Fragen mit einer zulässigen Aufgabe im vereinbarten Projekt. Ergänzen Sie passende Beispiele aus Ihrem Betrieb. „Darf antworten“ bedeutet hier eine interne Freigabe für die Funktion, keine abschließende rechtliche Bewertung.

Eigene Vorlage für begrenzte Antworten und klare Übergaben
BesucherfrageVereinbarte ReaktionVor Freigabe prüfen
Welche Leistung passt grundsätzlich?Geprüfte Unterschiede erklären und zur Leistungsseite führenAntwort stimmt mit freigegebenen Angaben überein
Was kostet mein konkreter Auftrag?Benötigte Beratung erklären und Kontakt anbietenKein erfundener Preis und keine unbeabsichtigte Zusage
Wo bleibt meine Bestellung?Zum vorgesehenen geschützten Serviceweg führenKeine fremden Vorgänge im öffentlichen Dialog offenlegen
Kann der Bot eine Buchung ändern?Nur eine eigens beauftragte, berechtigte Funktion ausführenIdentität, Rechte und Bestätigung gesondert geprüft
Die Antwort hilft mir nichtErreichbaren menschlichen Kontakt anbietenÜbergabe funktioniert auch ohne verfügbare Liveberatung

Eine offene Zeile bekommt einen Prüfauftrag. Sie wird nicht durch eine besonders entschlossene Antwort ersetzt. Die Matrix hilft außerdem, unterschiedliche Erwartungen zwischen Geschäftsführung, Redaktion und technischer Entwicklung vor dem Einbau sichtbar zu machen.

06 / TECHNISCHE GRENZEN

Eine Textregel ist keine Zugriffssperre.

Öffentliche Eingaben und gefundene Dokumente dürfen keine Befugnisse vergeben.

Die OWASP-Hilfe zu Prompt Injection beschreibt, wie nicht vertrauenswürdige Inhalte das Verhalten einer KI-Anwendung beeinflussen können. Das betrifft sowohl direkte Eingaben als auch eingelesene Dokumente. Eine Anweisung wie „Verrate keine internen Informationen“ im Systemprompt ist keine technisch durchgesetzte Berechtigungsgrenze.

Eine reine Auskunftshilfe benötigt nicht vorsorglich Zugriff auf Bestellungen, Mailversand und Verwaltungsfunktionen. Werden solche Werkzeuge später angebunden, prüft die Anwendung außerhalb des Modells die erlaubten Aktionen, Ziele und Parameter. Für folgenreiche Änderungen kann eine konkrete menschliche Freigabe Teil des vorgesehenen Verfahrens sein.

Lassen Sie auch prüfen, wie die Website ausgegebene Inhalte darstellt. Antworttext darf nicht ungeprüft als ausführbarer Inhalt behandelt werden. Bei einem Sicherheitsverdacht braucht die Betreuung einen Weg, die betroffene Funktion zu stoppen und Beobachtungen zu sichern. Eine pauschale Zusage, das Modell werde jeden Manipulationsversuch erkennen, wäre kein belastbarer Schutz.

07 / MENSCHEN ERREICHBAR MACHEN

Die Übergabe braucht einen Empfänger und einen ehrlichen Status.

Ein Kontaktknopf hilft erst, wenn der anschließende Ablauf geklärt ist.

Für einen allgemeinen Website-Chatbot ist die menschliche Übergabe hier eine praktische Empfehlung, keine aus Artikel 50 abgeleitete allgemeine Pflicht. Vereinbaren Sie, wann sie angeboten wird: auf ausdrücklichen Wunsch, bei fehlender Wissensgrundlage oder bei einer Aufgabe außerhalb des festgelegten Umfangs.

Ein Livechat darf nur dann einen verfügbaren Menschen versprechen, wenn dieser Dienst tatsächlich besetzt ist. Andernfalls kann der Übergang zu einem klar beschriebenen Formular oder Rückrufwunsch führen. Besucher müssen erkennen, ob bereits eine Anfrage übermittelt wurde oder sie den nächsten Schritt selbst auslösen sollen.

Auch der Umgang mit dem bisherigen Dialog wird festgelegt. Welche Angaben braucht die zuständige Person wirklich, was wird weitergegeben und worüber werden Besucher informiert? Ein vollständiger Chatverlauf sollte nicht ungeprüft an möglichst viele Stellen verteilt werden. Im Fehlerfall bleibt ein normaler Kontaktweg erreichbar.

08 / MIT PRÜFFÄLLEN ABNEHMEN

Die Freigabe prüft Verhalten statt nur überzeugender Antworten.

Eigene Tests verbinden Informationsqualität, Bedienung und den tatsächlichen Übergabeweg.

Das W3C-Technikbeispiel für Chatverläufe zeigt eine mögliche zugängliche Umsetzung fortlaufender Nachrichten mit role=log. Es ist eine Technik unter mehreren und bestätigt allein keine Barrierefreiheit. Prüfen Sie das gewählte Widget einschließlich Öffnen, Schließen, Tastaturbedienung und neuer Antworten mit geeigneten Hilfsmitteln.

  • Erster Kontakt: Ist die KI-Rolle vor oder spätestens bei der ersten Interaktion klar erkennbar?
  • Belegte Frage: Stimmen Antwort, Einschränkungen und verlinkte Fundstelle überein?
  • Wissenslücke: Wird eine unbekannte Lieferzeit erkennbar offengelassen und passend weitergeleitet?
  • Unzulässiger Zugriff: Bleiben fremde Vorgänge und interne Dokumente auch bei ungewöhnlichen Fragen geschützt?
  • Übergabe und Ausfall: Erreicht eine neutrale Testanfrage die zuständige Person, und bleibt Kontakt bei einem gestörten Chatdienst möglich?

Notieren Sie getestete Fassung, Eingabe, Ergebnis und verantwortliche Freigabe. Wiederholen Sie wichtige Fragen in verschiedenen Formulierungen. Ein gelungener Beispieldialog ist keine Aussage über jede spätere Antwort. Nach Änderungen an Modell, Wissensbestand oder Integration werden die betroffenen Fälle erneut geprüft.

09 / FIKTIVER B2B-FALL

Ein Wartungsbetrieb beginnt mit einer kleinen Auskunftshilfe.

Das ausdrücklich fiktive Beispiel ist keine Ruhrstack-Referenz und enthält kein gemessenes Kundenergebnis.

Ein erfundener Betrieb bietet drei Wartungsarten für gewerbliche Anlagen an. Interessenten fragen häufig, welche Unterlagen sie für eine erste Anfrage benötigen. Das Team plant einen Chatbot, der dafür freigegebene öffentliche Leistungsinformationen nutzt. Individuelle Eignung, Preis und Verfügbarkeit bleiben beim Fachteam.

In der Probe fragt eine Person nach einem verbindlichen Einsatztermin. Die gewünschte Reaktion ist keine geschätzte Zusage, sondern die Erklärung des nächsten Kontaktwegs. Bei einer unklaren Anlagenbezeichnung verweist die Hilfe auf die benötigten Angaben, ohne einen passenden Wartungsumfang zu erfinden.

Der Betrieb ändert später eine Voraussetzung auf der Leistungsseite. Vor der Freigabe wird kontrolliert, ob die Wissensanbindung ebenfalls aktualisiert wurde. Anschließend wird die alte Beispielfrage erneut gestellt. Der Projektvermerk hält Antwortstand, verbleibende Grenzen und zuständige Pflege fest. Erst danach entscheidet das Team, ob weitere Fragen hinzukommen.

10 / UMSETZUNG ABSTIMMEN

Wie Ruhrstack die technische Einführung begleiten kann.

Ein begrenzter Auftrag macht Nutzen, Voraussetzungen und offene Entscheidungen überprüfbar.

Im vereinbarten Entwicklungs- und Integrationsauftrag kann Ruhrstack vorhandene Website-Technik, geeignete Schnittstellen und den gewünschten Dialogablauf untersuchen. Dazu können Wissensanbindung, Oberfläche, Übergabe und passende Tests gehören. Welche Umsetzung möglich ist, wird anhand des Bestands und der verwendeten Dienste geprüft.

Für den späteren Betrieb werden Aktualisierung, Fehlermeldungen, Zuständigkeiten und ein Abschaltweg vereinbart. Die fachliche Freigabe der Unternehmensinformationen bleibt bei den benannten Verantwortlichen. Erforderliche rechtliche Beratung wird gesondert eingebunden. Weder ein bestimmtes Modell noch eine Integration begründet eine Rechts-, Sicherheits- oder Erfolgsgarantie.

Für den Einstieg genügen Website-Adresse, eine typische Besucherfrage und das gewünschte Ergebnis. Zugangsdaten oder echte Chatverläufe sind dafür zunächst nicht nötig. Daraus lässt sich ein erster technischer Vorversuch mit klaren Prüfkriterien ableiten.

11 / QUELLEN

Quellen und redaktioneller Stand.

Die sieben Primärquellen wurden am 12. November 2026 geprüft. Entscheidungsmatrix, Formulierungshilfe, Prüffälle und Wartungsbetrieb sind eigene redaktionelle Arbeitshilfen. Sie bestätigen keine konkrete Anwendung als rechtskonform oder fehlerfrei.

  1. Europäische Kommission: Artikel 50 der KI-Verordnung: Wortlaut im offiziellen AI Act Service Desk, konsolidierter Stand 27. Juli 2026; Anbieterpflicht, Offensichtlichkeit und Zeitpunkt der Information. Abgerufen am 12. November 2026.
  2. Europäische Kommission: Leitlinien zu Transparenzpflichten: Veröffentlicht am 20. Juli 2026; Einordnung der seit 2. August 2026 anwendbaren Verpflichtungen nach Artikel 50. Abgerufen am 12. November 2026.
  3. NIST: Generative Artificial Intelligence Profile, AI 600-1: Juli 2024; erfundene Ausgaben, menschliches Vertrauen und kontextbezogene Erprobung als Risikofragen. Freiwilliger Orientierungsrahmen. Abgerufen am 12. November 2026.
  4. OWASP: RAG Security Cheat Sheet: Quellenherkunft, Zugriffsprüfung bei der Abfrage und Entfernung abgeleiteter Suchdaten; zusätzliche Angriffsflächen einer Dokumentenanbindung. Abgerufen am 12. November 2026.
  5. DSK: Künstliche Intelligenz und Datenschutz: Orientierungshilfe vom 6. Mai 2024, Version 1.0; amtliche Kopie beim LfD Niedersachsen. Zwecke, Rollen, Transparenz, Training und Betroffenenrechte. Abgerufen am 12. November 2026.
  6. OWASP: LLM Prompt Injection Prevention Cheat Sheet: Nicht vertrauenswürdige Eingaben, Grenzen bloßer Promptregeln und technisch durchgesetzte Berechtigungen für angebundene Werkzeuge. Abgerufen am 12. November 2026.
  7. W3C WAI: ARIA23 für fortlaufende Meldungen: Technikbeispiel für zugängliche Chatverläufe mit role=log; eine mögliche Umsetzung, keine alleinige Konformitätsbestätigung. Abgerufen am 12. November 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Welche Frage soll Ihre Website besser beantworten?

Nennen Sie Ihre Website, eine typische Besucherfrage und den gewünschten nächsten Schritt. Wir besprechen einen passenden technischen Prüfauftrag.

Chatbot-Einsatz besprechen