Compliance

Sichere Integration von KI-Chatbots — Leitfaden nach EU AI Act

Wie Unternehmen KI-Chatbots rechtssicher, technisch robust und nachweisbar qualitätsgesichert integrieren: EU AI Act, Evaluations-Framework, RAG Triad und LLM Best Practices.

Seiten·PDF-Leitfaden·guides.updatedAt

Inhaltsverzeichnis

  1. 1.Einleitung
  2. 2.Kapitel 1: Der EU AI Act — Was Chatbot-Betreiber jetzt wissen müssen
  3. 3.Kapitel 2: Architektur eines sicheren Chatbot-Systems
  4. 4.Kapitel 3: Evaluations-Framework — Warum „funktioniert" nicht reicht
  5. 5.Kapitel 4: Die RAG Triad — Das operative Qualitätsmodell
  6. 6.Kapitel 5: LLM Best Practices — Vom Prompt bis zum Incident
  7. 7.Kapitel 6: Sicherheit — OWASP LLM Top 10 in der Praxis
  8. 8.Kapitel 7: Go-Live-Checkliste — Vom Projekt zum zuverlässigen Produkt
  9. 9.Fazit: Von der Spielerei zur Infrastruktur

Einleitung

KI-Chatbots sind 2026 kein Hype mehr, sondern Infrastruktur. Ob im Kundenservice, in der internen Wissenssuche, bei der Lead-Qualifizierung oder in HR-Prozessen — Large Language Models beantworten inzwischen Millionen von Fragen pro Tag in deutschen Unternehmen. Der Einstieg ist trivial geworden: Ein API-Key, ein Prompt, ein paar Zeilen Code, fertig ist der „Bot".

Genau das ist das Problem.

Denn ein Chatbot, der scheinbar funktioniert, und ein Chatbot, der in Produktion verlässlich, sicher und regulatorisch zulässig operiert, sind zwei völlig verschiedene Dinge. Der Unterschied ist nicht das Modell — die Modelle sind exzellent. Der Unterschied liegt in Evaluierung, Grounding, Guardrails, Monitoring und Compliance-Architektur.

Seit dem 2. Februar 2025 gelten die ersten Vorschriften des EU AI Act. Ab dem 2. August 2026 werden weitere Pflichten scharf geschaltet, insbesondere für Hochrisiko-Systeme. Gleichzeitig steigen die Erwartungen von Kunden, Aufsichtsbehörden und Betriebsräten an die Nachvollziehbarkeit und Qualitätssicherung KI-gestützter Systeme. Wer jetzt noch Chatbots „auf Zuruf" baut, produziert in den nächsten zwölf Monaten drei Klassen von Problemen: regulatorische Risiken, reputationale Risiken und operative Risiken.

Dieser Leitfaden ist die Antwort. Er ist kein akademisches Framework, sondern eine operative Anleitung, wie wir bei cierra KI-Chatbots für unsere Kunden integrieren — rechtssicher, technisch belastbar und mit einem Qualitätsnachweis, der vor Aufsichtsbehörden, Betriebsräten und internen Auditoren Bestand hat.

Was Sie in diesem Leitfaden erfahren

  • Wie der EU AI Act Chatbot-Projekte konkret betrifft — Risikoklassen, Pflichten, Fristen, Strafen
  • Warum „funktioniert" und „evaluiert" nicht dasselbe ist — und wie Sie ein belastbares Evaluations-Framework aufbauen
  • Die RAG Triad (Context Relevance, Groundedness, Answer Relevance) als operatives Qualitätsmodell mit konkreten Metriken
  • LLM Best Practices von Prompt-Design über Guardrails bis zu Human-in-the-Loop
  • Sicherheit: Prompt Injection, Data Exfiltration, OWASP LLM Top 10 und wie Sie sie abwehren
  • Eine Go-Live-Checkliste, mit der Sie Ihren Chatbot nachweisbar produktionsreif machen

Zielgruppe: Geschäftsführer, CTOs, IT-Leiter, Innovations- und Compliance-Verantwortliche in Unternehmen ab 50 Mitarbeitern, die Chatbots nicht als Experiment, sondern als verlässlichen Geschäftsprozess betreiben wollen.

Hinweis: Dieser Leitfaden ersetzt keine Rechtsberatung. Alle Angaben zu regulatorischen Pflichten entsprechen unserem Kenntnisstand im April 2026. Für verbindliche Einschätzungen konsultieren Sie bitte einen auf IT- und Datenschutzrecht spezialisierten Anwalt.


Kapitel 1: Der EU AI Act — Was Chatbot-Betreiber jetzt wissen müssen

Der EU AI Act (Verordnung (EU) 2024/1689) ist weltweit die erste umfassende Regulierung künstlicher Intelligenz. Seit dem 1. August 2024 ist er in Kraft, die Anwendungspflichten greifen gestaffelt bis 2027. Für Chatbot-Projekte ist er in 90 Prozent der Fälle nicht dramatisch, aber immer relevant — und Unkenntnis schützt nicht vor Strafen von bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes.

Wir beobachten in der Beratung zwei extreme Reaktionsmuster: Einerseits Panik („wir dürfen keine KI mehr einsetzen"), andererseits Ignoranz („das betrifft uns nicht, wir sind ja nur Mittelstand"). Beides ist falsch. Der AI Act ist ein risikobasiertes Regelwerk — je höher das potenzielle Schadensrisiko, desto strenger die Pflichten. Für typische Kundenservice-Chatbots heißt das: überschaubare, aber konkrete Pflichten.

1.1 Zeitplan — Was gilt wann?

Datum Pflicht wird wirksam
2. Februar 2025 Verbot von AI-Systemen mit unzulässigem Risiko (Art. 5), AI-Literacy-Pflicht für Personal (Art. 4)
2. August 2025 Pflichten für General-Purpose AI (GPAI) Modelle (Art. 51–55), Governance-Strukturen, Sanktionssystem
2. August 2026 Hauptanwendung: Pflichten für Hochrisiko-Systeme Anhang III, Transparenzpflichten (Art. 50), Konformitätsbewertungsverfahren
2. August 2027 Pflichten für Hochrisiko-Systeme Anhang I (Produktsicherheit)

Für Chatbot-Projekte besonders relevant: Artikel 50 (Transparenzpflichten) und gegebenenfalls Artikel 6 ff. (Hochrisiko) ab 2. August 2026. Wer heute — April 2026 — einen Chatbot plant, hat vier Monate, um compliant zu sein.

1.2 Die vier Risikoklassen

Der AI Act ordnet KI-Systeme in vier Klassen ein:

Klasse Beschreibung Konsequenz
Unacceptable Risk (Art. 5) Social Scoring, Emotion Recognition am Arbeitsplatz, manipulative Systeme, biometrische Kategorisierung nach sensiblen Merkmalen Verboten seit Feb 2025
High Risk (Art. 6, Anhang III) HR-Systeme, Bonitätsprüfung, Behördenleistungen, kritische Infrastruktur, Bildungszulassung, Strafverfolgung Konformitätsbewertung, Risikomanagement, Dokumentation, Human Oversight, Registrierung in EU-Datenbank
Limited Risk (Art. 50) Chatbots, Deepfakes, emotions- oder kategorisierungsbasierte Systeme Transparenzpflicht: Nutzer muss erkennen, dass er mit KI interagiert
Minimal Risk Alles andere (Spam-Filter, Empfehlungssysteme, KI-gestützte Spiele) Keine spezifischen Pflichten, nur allgemeine EU-Gesetze (DSGVO etc.)

1.3 Chatbots im AI Act — Der Regelfall

Die gute Nachricht zuerst: Der typische Unternehmens-Chatbot — FAQ-Assistent, Kundenservice-Bot, interner Wissens-Assistent — fällt in Limited Risk. Damit ist die zentrale Pflicht Artikel 50(1):

„Anbieter stellen sicher, dass KI-Systeme, die für die direkte Interaktion mit natürlichen Personen bestimmt sind, so konzipiert und entwickelt werden, dass die betreffenden natürlichen Personen informiert werden, dass sie mit einem KI-System interagieren."

Was das praktisch bedeutet:

  1. Sichtbare Kennzeichnung: „Sie chatten mit einem KI-Assistenten" muss spätestens beim ersten Kontakt klar erkennbar sein — im Begrüßungstext, im Avatar-Label, im Footer.
  2. Maschinenlesbare Markierung generierter Inhalte (Art. 50(2)): Wenn der Bot Texte, Audio oder Bilder generiert, müssen diese technisch als AI-generiert erkennbar sein (z. B. Watermarking, Metadaten).
  3. Hinweis bei emotionaler oder biometrischer Verarbeitung (Art. 50(3)): Analysiert der Bot Stimmungen oder biometrische Daten, ist dies zusätzlich zu kennzeichnen.
  4. Ausnahme: Nur, wenn es „für eine vernünftig informierte, aufmerksame und verständige natürliche Person offensichtlich ist", dass sie mit einer KI spricht — ein Anwendungsfall, der im B2C-Kontext praktisch nie zutrifft.

1.4 Wann wird ein Chatbot zum Hochrisiko-System?

Die Einordnung ändert sich schlagartig, sobald der Bot Entscheidungen mit rechtlicher oder erheblicher Wirkung trifft oder vorbereitet. Anhang III AI Act listet acht Bereiche auf. Für Chatbot-Projekte besonders relevant:

  • Beschäftigung (Anhang III Nr. 4): Chatbots, die Bewerbungen vorselektieren, Mitarbeitende bewerten oder Beförderungsentscheidungen unterstützen.
  • Zugang zu wesentlichen Diensten (Anhang III Nr. 5): Bots, die Kreditwürdigkeit prüfen, Versicherungs-Scoring vornehmen, Zugang zu öffentlichen Leistungen gewähren oder verweigern.
  • Bildung (Anhang III Nr. 3): Bots, die Zugang zu Bildungseinrichtungen steuern oder Lernleistungen bewerten.
  • Strafverfolgung und Migration (Anhang III Nr. 6, 7): Bots in Behördenkontexten.

In diesen Fällen gelten erheblich strengere Pflichten:

  • Risikomanagementsystem (Art. 9)
  • Daten-Governance mit dokumentierter Qualitätssicherung (Art. 10)
  • Technische Dokumentation (Art. 11)
  • Automatische Protokollierung (Art. 12)
  • Transparenz gegenüber Nutzern (Art. 13)
  • Menschliche Aufsicht (Art. 14)
  • Genauigkeit, Robustheit, Cybersicherheit (Art. 15)
  • Konformitätsbewertung und CE-Kennzeichnung (Art. 43 ff.)
  • Eintrag in die EU-Datenbank (Art. 49)

Unsere Erfahrung: Viele Unternehmen unterschätzen die Trigger. Ein „harmlos wirkender" HR-Chatbot, der Bewerberfragen beantwortet und gleichzeitig Profildaten scored oder in ein Ranking übernimmt, ist bereits Hochrisiko. Die Grenze ist nicht die Funktionalität des Bots, sondern ob seine Outputs in nachgelagerte Entscheidungen mit Personenbezug einfließen.

1.5 GPAI-Modelle — Was, wenn Sie GPT, Claude oder Gemini nutzen?

Die meisten Unternehmens-Chatbots basieren auf General-Purpose AI Modellen (GPAI) von OpenAI, Anthropic, Google oder Mistral. Artikel 51–55 regelt deren Pflichten — hauptsächlich beim Anbieter des Modells, nicht beim Bot-Betreiber. Aber:

  • Sie werden Teil der Lieferkette: Anbieter wie OpenAI müssen Ihnen technische Dokumentation, Trainingsdatenzusammenfassungen und Copyright-Transparenz zur Verfügung stellen. Nutzen Sie das — für Ihre eigene Dokumentation.
  • „Systemisches Risiko" (Art. 51): Modelle mit Training-Compute ≥ 10²⁵ FLOPS (aktuell nur die größten Frontier-Modelle) unterliegen zusätzlichen Pflichten. Für Sie als Integrator relevant: Diese Modelle kommen mit detaillierteren Compliance-Unterlagen.
  • Fine-Tuning-Risiko: Wenn Sie ein GPAI-Modell substanziell fine-tunen oder mit proprietären Daten modifizieren, können Sie selbst zum „Anbieter" im Sinne des AI Act werden. Das ist eine Statusänderung mit erheblichen Folgen. In der Praxis vermeidet man sie durch RAG statt Fine-Tuning, wo immer möglich.

1.6 Strafen — Warum das kein Paper-Tiger ist

Der Sanktionskatalog (Art. 99) ist bewusst scharf:

  • Verbotene Praktiken (Art. 5): bis zu 35 Mio. € oder 7 % des weltweiten Jahresumsatzes
  • Verletzung der Kernpflichten (Art. 8–15, 25–49, 50): bis zu 15 Mio. € oder 3 %
  • Falschangaben gegenüber Behörden: bis zu 7,5 Mio. € oder 1 %
  • Für KMU und Start-ups gelten die jeweils niedrigeren Beträge, aber prozentual gleich hart

Zuständig in Deutschland ist die Bundesnetzagentur (als AI-Aufsichtsbehörde benannt) in Koordination mit dem BfDI und fachspezifischen Aufsichten (BaFin für Finanz-KI, BfArM für Medizin-KI). Der erste Prüffokus wird erfahrungsgemäß auf großen Plattformen und öffentlichkeitswirksamen Vorfällen liegen — aber Beschwerden von Betroffenen können jeden Anbieter ins Visier bringen.

1.7 Cierra-Checkliste: AI-Act-Readiness für Chatbots

Diese Checkliste nutzen wir in der Initialberatung:

  • Risikoklassifizierung dokumentiert — Limited Risk oder Hochrisiko? Mit Begründung.
  • Transparenzhinweis implementiert — „Sie chatten mit einem KI-Assistenten" im Opening und Footer.
  • Generative Outputs gekennzeichnet — Watermark, Metadaten oder mindestens textueller Disclaimer.
  • AI-Literacy-Programm für alle Mitarbeitenden mit Bot-Berührung (Art. 4) aufgesetzt.
  • Datenschutz-Folgenabschätzung (DSFA) nach DSGVO Art. 35 durchgeführt.
  • Logging aller Interaktionen für mindestens 6 Monate (Art. 12 bei Hochrisiko, sonst Best Practice).
  • Human-in-the-Loop-Prozess definiert für kritische Antworten (Eskalation an Mitarbeitende).
  • GPAI-Lieferantendokumentation vom Modellanbieter eingeholt und archiviert.
  • Impressum / Datenschutzerklärung ergänzt um KI-Hinweise.
  • Betriebsrat informiert (bei internen Bots mit Mitarbeiterbezug — § 87 BetrVG).

Wer diese zehn Punkte sauber abgearbeitet hat, ist im Regelfall (Limited Risk) AI-Act-compliant. Bei Hochrisiko-Systemen vervielfacht sich die Checkliste — dann gilt: Nicht ohne spezialisierte Beratung.


Der häufigste Designfehler in Chatbot-Projekten: Das LLM ist nicht „der Chatbot". Das LLM ist eine Komponente in einem Gesamtsystem, das aus mindestens acht Schichten besteht. Wer diese Schichten nicht sauber trennt, produziert ein System, das weder auditierbar noch skalierbar ist — und im Fehlerfall nicht kontrolliert reagieren kann.

2.1 Die Referenzarchitektur

Unsere Standard-Architektur für produktive Chatbot-Systeme besteht aus:

  1. Client Layer — Web-Widget, App, Messenger-Integration. Rendert UI, liefert Transparenzhinweise, sammelt Feedback.
  2. Gateway / API Layer — Authentifizierung, Rate Limiting, Request-Validation, PII-Maskierung auf dem Weg nach innen.
  3. Orchestration Layer — Dialog-State-Management, Routing (welche Anfrage geht an welches Modell, welche Tools werden gerufen), Fallback-Logik.
  4. Retrieval Layer — Vector Store, Re-Ranker, Hybrid-Suche. Liefert den Kontext für Grounding.
  5. LLM Layer — Das oder die Sprachmodelle. Meist GPAI, in regulierten Kontexten zusätzlich ein kleineres Open-Source-Modell als Fallback.
  6. Guardrails Layer — Input- und Output-Filter, Toxicity-/PII-Detection, Jailbreak-Detection, Policy-Checks.
  7. Observability Layer — Logging, Tracing, Cost-Tracking, Eval-Pipelines, Dashboards.
  8. Governance Layer — Human Review Queue, Audit-Export, Model-Registry, Policy-Versionen.

Diese Schichten sind nicht akademisch. Sie entsprechen genau den Pflichten des AI Act (Logging → Art. 12, Guardrails → Art. 15, Governance → Art. 9/14) und den etablierten Security-Patterns aus dem OWASP LLM Top 10.

2.2 Das wichtigste Architektur-Prinzip: Trust Boundaries

In jedem Chatbot-System verlaufen mehrere Vertrauensgrenzen:

  • Nutzereingabe → System: grundsätzlich nicht vertrauenswürdig (Prompt Injection möglich)
  • Retrieval-Kontext → LLM: potenziell vergiftbar (Indirect Prompt Injection)
  • LLM-Output → Nutzer: muss auf Halluzinationen, PII-Leaks, Toxicity geprüft werden
  • LLM-Output → Tool-Call: besonders kritisch, wenn der Bot Aktionen auslösen kann

Die Regel: An jeder Trust Boundary findet eine Validierung statt. Nie ein Rohformat vom Nutzer direkt ins Modell, nie ein Modell-Output direkt in ein Backend-System. Wer diese Regel verletzt, baut einen Bot, der sich jederzeit fremdsteuern lässt.

2.3 RAG als Default — und warum Fine-Tuning selten die Antwort ist

Für 95 Prozent aller Chatbot-Anwendungsfälle ist Retrieval-Augmented Generation (RAG) die richtige Architektur:

  • Wissen bleibt in der Datenquelle (Dokumente, Wiki, CRM), nicht im Modellgewicht.
  • Updates sind sofort wirksam, ohne Re-Training.
  • Quellen sind nachweisbar — zentral für Groundedness (siehe Kapitel 4).
  • Datenschutz-Grenzen bleiben sauber — Nutzerdaten werden nicht Teil eines Modells.
  • Der Bot wird nicht zum „Anbieter" im Sinne des AI Act durch Modellmodifikation.

Fine-Tuning ist sinnvoll für: Tonalität und Domain-Terminologie, spezifische Struktur-Outputs, stark repetitive Muster. Nicht sinnvoll für: Aktuelles Faktenwissen, häufig ändernde Inhalte, sensible Einzeldaten.

2.4 Die unsichtbare Komponente: Observability

Was nicht gemessen wird, existiert nicht. Chatbot-Projekte, die nach Go-Live scheitern, scheitern fast immer an fehlender Observability. Unser Minimum-Standard:

  • Strukturiertes Trace-Logging jeder Anfrage: Input, verwendeter Kontext, Modell-Request, Response, Latency pro Stufe, Tokens, Kosten.
  • PII-sichere Speicherung: Logs werden beim Schreiben gefiltert, nicht erst beim Lesen. Niemals Klartext-Identifikatoren in Log-Indexen.
  • Eval-Scores pro Response (mindestens Stichprobe) — siehe Kapitel 3/4.
  • User-Feedback-Kanal (Daumen hoch/runter, Kommentar), gekoppelt an Trace-IDs.
  • Cost-Budget-Alerts pro Tag und pro Nutzergruppe.
  • Drift-Monitoring: Täglicher Lauf gegen Golden Dataset, Alarm bei Qualitätsabfall.

Tools, die sich in der Praxis bewährt haben: Langfuse (Open Source, EU-hostbar), Arize Phoenix (Open Source), Braintrust (kommerziell, sehr gute Eval-Integration), Weights & Biases Weave, Helicone. Vendor-Lock-in vermeiden, indem alle Traces zusätzlich in OpenTelemetry exportiert werden.

2.5 Cierra-Prinzip: „Boring Architecture"

Wir lehnen Experimentierfreude in produktiven Chatbot-Systemen bewusst ab. Das LLM-Ökosystem verändert sich monatlich — deshalb bleiben alle anderen Komponenten langweilig stabil: Postgres statt exotische Vector-DBs (pgvector reicht für die meisten Fälle bis 10 Mio. Chunks), Redis für Session-State, OpenTelemetry für Traces, klassische API-Gateways (Kong, nginx) statt LLM-spezifischer Proxies. So ersetzen wir das Modell, wenn ein besseres kommt — ohne das halbe System umzubauen.


Leitfaden herunterladen

Geben Sie Ihre E-Mail-Adresse ein, um den vollständigen Leitfaden als PDF zu erhalten.