Dokumente im KI-Chatbot hochladen: Dateiprüfung, Datenschutz und Handoff

Ein Upload-Symbol im Chatfenster wirkt unkompliziert: Datei auswählen, Frage stellen, Antwort erhalten. Technisch und redaktionell beginnt an dieser Stelle jedoch ein eigener Prozess. Ein Dokument kann personenbezogene Daten, aktive Inhalte, manipulierte Dateistrukturen, unlesbare Scans oder Anweisungen enthalten, die ein Sprachmodell nicht als vertrauenswürdige Fakten behandeln darf. Deshalb braucht ein Dokument-Upload im KI-Chatbot klare Grenzen vor der Übertragung, mehrere Prüfstationen danach und einen nachvollziehbaren Ausweg, wenn etwas nicht funktioniert.

Der folgende Leitfaden richtet sich an Website-, Support- und Produktteams. Er beschreibt keine einzelne Herstellerfunktion, sondern ein belastbares Zielbild: Menschen wissen vor dem Upload, was erlaubt ist; das System trennt Annahme, Sicherheitsprüfung und Inhaltsauswertung; Fehler bleiben verständlich; sensible Fälle wechseln kontrolliert zu einem Menschen.

Der Upload braucht einen klaren Zweck

Beginnen Sie nicht mit einer möglichst langen Liste unterstützter Formate, sondern mit wenigen Aufgaben. Soll der Chatbot Angaben aus einer Rechnung erklären, technische Unterlagen zusammenfassen oder eine Supportanfrage mit einem Screenshot ergänzen? Für jede Aufgabe muss feststehen, welche Inhalte benötigt werden, welche Entscheidung das System treffen darf und wann eine menschliche Prüfung zwingend ist.

Diese Zweckbindung verhindert, dass der Upload zum allgemeinen Dokumentenspeicher wird. Sie hilft außerdem bei der Gestaltung: Ein Beleg für eine Reklamation braucht andere Hinweise und Aufbewahrungsregeln als eine öffentliche Produktbeschreibung für eine Wissensbasis. Der bestehende Leitfaden zum Training mit FAQs, Dokumenten und Website-Inhalten behandelt die kuratierte Wissensbasis; hier geht es dagegen um Dateien, die Besucher während eines laufenden Gesprächs einreichen.

Erlaubte Dateitypen, Größen und Mengen sichtbar machen

Menschen sollten die Regeln sehen, bevor sich der Dateidialog öffnet: erlaubte Formate, maximale Größe, maximale Anzahl und ob passwortgeschützte oder komprimierte Dateien akzeptiert werden. Verwenden Sie eine Positivliste, die nur geschäftlich notwendige Formate zulässt. „Alle Dokumente“ ist keine hilfreiche Anforderung.

Das HTML-Attribut accept verbessert die Auswahl im Browser, ist aber keine Sicherheitskontrolle. MDN weist ausdrücklich darauf hin, dass Nutzer die Auswahlbeschränkung häufig umgehen können und die Prüfung deshalb serverseitig erfolgen muss. Die Oberfläche darf also passende Dateiendungen anbieten, während der Server unabhängig davon Extension, gemeldeten MIME-Typ, tatsächliche Signatur und Struktur bewertet.

Dateinamen und Metadaten nicht ungeprüft übernehmen

Ein Originalname kann Sonderzeichen, Pfadbestandteile, sehr lange Zeichenfolgen oder sensible Informationen enthalten. Für die interne Ablage sollte das System eine eigene zufällige Kennung vergeben und den sichtbaren Namen nur als bereinigte Anzeigeinformation behandeln. Auch eingebettete Metadaten können Namen, Geräteinformationen oder Ortsangaben enthalten. Ob diese Daten benötigt werden, muss sich aus dem Zweck ergeben.

Die OWASP File Upload Cheat Sheet empfiehlt unter anderem eine Positivliste für Erweiterungen, unabhängige Typprüfung, sichere Dateinamen, Größenlimits, Speicherung außerhalb des Webroots und Schutz vor unberechtigten Uploads. Keine einzelne Prüfung reicht allein aus; sinnvoll ist eine Kette kleiner, nachvollziehbarer Kontrollen.

Annahme, Sicherheitsprüfung und Auswertung trennen

Eine angenommene Datei sollte nicht sofort im Chat verfügbar sein. Ein robuster Ablauf kennt mindestens drei Zustände: empfangen, in Prüfung und zur Auswertung freigegeben. Während der Prüfung liegt die Datei in einem abgeschotteten Bereich. Erst nach bestandener Kontrolle erhält die Extraktion Zugriff. Direkte öffentliche URLs oder vorhersehbare Speicherpfade sind zu vermeiden.

Malware- und Strukturprüfung

Je nach Risiko gehören Virenscan oder Sandbox, Signaturprüfung und bei geeigneten Office- oder PDF-Dateien Content Disarm and Reconstruction in den Prozess. Archive, verschachtelte Dateien und ungewöhnlich stark komprimierte Inhalte brauchen eigene Grenzen, weil sie Ressourcen binden oder Parser angreifen können. Scanner und Bibliotheken müssen aktuell und so konfiguriert sein, dass ein Timeout oder Parserfehler nicht als Freigabe gilt.

Textextraktion ist ein eigener Qualitätsstatus

Eine sichere Datei kann trotzdem unbrauchbar sein: ein schiefer Scan, ein Foto mit Reflexionen, eine handschriftliche Notiz oder ein PDF ohne extrahierbare Textebene. Das System sollte daher getrennt melden, ob die Datei sicher angenommen wurde und ob der Inhalt ausreichend gelesen werden konnte. Eine niedrige Extraktionsqualität darf nicht durch erfundene Ergänzungen kaschiert werden.

Fehler präzise und handlungsfähig formulieren

„Upload fehlgeschlagen“ lässt offen, was als Nächstes zu tun ist. Besser sind unterscheidbare Meldungen: Format nicht unterstützt, Datei zu groß, Kennwortschutz erkannt, Sicherheitsprüfung nicht bestanden, Text nicht lesbar oder Verarbeitung vorübergehend nicht verfügbar. Die Meldung soll keine internen Scanner- oder Infrastrukturdetails verraten, aber eine sichere Korrektur anbieten.

WCAG 2.2 verlangt bei automatisch erkannten Eingabefehlern eine textliche Identifikation und Beschreibung. Die Erläuterung zu Success Criterion 3.3.1 Error Identification betont, dass ein bloß erneut angezeigtes Formular nicht genügt. Für den Chat bedeutet das: Dateiname beziehungsweise Upload-Position nennen, Fehler in Textform erklären und eine konkrete Option zum Ersetzen, Entfernen oder Übergeben anbieten.

Fortschritt barrierefrei mitteilen

Bei größeren Dateien entstehen Wartezeiten. Ein visueller Balken allein hilft nicht allen Menschen. Statusänderungen wie „Upload läuft“, „Sicherheitsprüfung“, „Inhalt wird gelesen“ und „bereit“ sollten programmatisch erkennbar sein, ohne den Tastaturfokus ungefragt zu verschieben. Die W3C-Erläuterung zu WCAG 4.1.3 Status Messages nennt Fortschritt, Erfolg und Fehler ausdrücklich als relevante Statusinformationen.

Eine Abbrechen-Aktion muss erreichbar bleiben. Nach dem Abbruch sollte sichtbar werden, ob die Übertragung tatsächlich gestoppt und eine bereits empfangene Kopie verworfen wurde. Auf Mobilgeräten sind Dateiname, Fortschritt und Entfernen-Schaltfläche so anzuordnen, dass sie weder die Eingabe noch wichtige Navigation überdecken.

Datenschutz vor dem Upload erklären

Der Hinweis muss vor der Datenübertragung beantworten: Wofür wird die Datei verwendet? Wer kann sie sehen? Wie lange bleibt sie gespeichert? Wird ihr Inhalt zur Verbesserung eines Modells genutzt? Wie kann die Datei entfernt werden? Allgemeine Datenschutzerklärungen bleiben wichtig, ersetzen aber nicht den kontextbezogenen Hinweis direkt am Upload.

Artikel 5 der Datenschutz-Grundverordnung enthält unter anderem Zweckbindung, Datenminimierung und Speicherbegrenzung. Praktisch heißt das: nur notwendige Dokumente anfordern, unnötige Seiten oder Metadaten vermeiden, eine begründete Löschfrist festlegen und die tatsächliche Löschung technisch prüfen. Das ist keine individuelle Rechtsberatung; konkrete Pflichten müssen für den jeweiligen Einsatz bewertet werden.

Öffentliche Chats und geschützte Vorgänge trennen

Ein öffentlicher Website-Chat ist nicht automatisch der richtige Ort für Verträge, Ausweisdokumente, Gesundheitsdaten oder Kontounterlagen. Bei sensiblen Vorgängen sollte die Unterhaltung in einen authentifizierten Bereich oder einen etablierten sicheren Kanal wechseln. Der Beitrag öffentlicher KI-Chatbot versus Kundenportal zeigt, wie Identität und Datenzugriff getrennt werden.

Auch im eingeloggten Bereich gilt das Prinzip der geringsten Berechtigung. Ein Supportmitarbeiter benötigt möglicherweise Einsicht in einen Beleg, aber nicht automatisch dauerhaften Zugriff auf alle hochgeladenen Dokumente eines Kontos. Zugriffe, Downloads und Löschungen sollten nachvollziehbar protokolliert werden, ohne den Dokumentinhalt unnötig in Analyseereignisse zu kopieren.

Dokumentinhalt bleibt nicht vertrauenswürdig

Eine freigegebene Datei ist technisch verarbeitet, aber inhaltlich noch keine autoritative Quelle. Dokumente können veraltet, widersprüchlich oder absichtlich manipuliert sein. Sie können außerdem Anweisungen enthalten, die das Modell zu Datenabfluss oder Regelumgehung bewegen sollen. Behandeln Sie extrahierten Text deshalb als untrusted content, trennen Sie ihn von Systemregeln und begrenzen Sie Werkzeuge und Datenzugriffe.

Der Leitfaden zu Prompt Injection bei Website-Chatbots erläutert diese Grenze für RAG und Tools. Für Uploads kommt hinzu: Antworten sollten sich auf erkennbare Dokumentstellen beziehen, Unsicherheit benennen und bei kritischen Entscheidungen keine fehlenden Angaben ergänzen.

Human Handoff mit einem kleinen Kontextpaket

Eine Übergabe ist nötig, wenn die Sicherheitsprüfung wiederholt scheitert, die Extraktion unzuverlässig bleibt, Identität oder Berechtigung unklar sind oder eine fachliche Entscheidung außerhalb des Chatbots liegt. Übergeben werden nur die Informationen, die der Mensch zur Fortsetzung braucht: Anliegen, Upload-Status, sicherer Dokumentverweis, konkrete Fehlermeldung, bereits bestätigte Angaben und gewünschter nächster Schritt.

Die Datei sollte nicht zusätzlich per ungeschützter E-Mail versendet werden, nur weil der Chatbot sie nicht lesen konnte. Ein geplanter Human-Handoff-Prozess bewahrt Kontext, Zuständigkeit und Erwartungen, ohne sensible Inhalte unnötig zu vervielfältigen.

Mit Ereignissen messen, nicht mit Dokumentinhalten

Für die Produktverbesserung genügen häufig strukturierte Ereignisse: Auswahl gestartet, Upload abgebrochen, Typ abgelehnt, Größenlimit erreicht, Sicherheitsprüfung bestanden, Extraktion unzureichend, Übergabe gewählt und Löschung bestätigt. Dateinamen, extrahierter Text und personenbezogene Inhalte gehören nicht automatisch in Analytics oder Fehlerlogs.

Werten Sie Erfolgs- und Schutzkennzahlen gemeinsam aus. Eine hohe Uploadquote ist wertlos, wenn viele Menschen nicht verstehen, welche Datei erwartet wird, oder wenn sensible Dokumente im öffentlichen Chat landen. Wichtig sind deshalb auch Korrekturrate, Abbruch nach Datenschutzhinweis, Anteil unlesbarer Dateien, Zeit bis zur verständlichen Fehlermeldung und erfolgreiche Fortsetzung nach dem Handoff.

Checkliste vor dem Go-live

• Ist für jeden Upload-Fall ein klarer Zweck und ein erlaubter Dokumenttyp definiert?
• Sind Format, Größe, Anzahl, Kennwortschutz und Aufbewahrung vor der Auswahl sichtbar?
• Prüft der Server Extension, MIME-Typ, Signatur, Struktur und Größenlimits unabhängig vom Browser?
• Sind Quarantäne, Malware-Prüfung, Extraktion und Freigabe als getrennte Zustände umgesetzt?
• Erhalten Menschen präzise, barrierefreie Fortschritts- und Fehlermeldungen?
• Werden sensible Vorgänge in einen authentifizierten oder menschlich betreuten Kanal verlagert?
• Sind Löschfrist, Zugriff, Protokollierung und bestätigte Löschung praktisch getestet?
• Behandelt der Chatbot extrahierten Text als nicht vertrauenswürdig und zitiert nachvollziehbare Stellen?
• Enthalten Analytics nur notwendige Ereignisse statt Dateinamen oder Dokumentinhalte?
• Ist der Handoff mit realen Fehlerfällen auf Desktop und Mobil getestet?

Fazit: Der sichere Upload beginnt vor der Datei

Ein guter Dokument-Upload macht Grenzen sichtbar, bevor Daten fließen. Danach trennt er technische Annahme, Sicherheitsprüfung, Inhaltsqualität und fachliche Entscheidung. So kann ein KI-Chatbot Dokumente als hilfreichen Gesprächskontext nutzen, ohne jedes empfangene Byte oder jede extrahierte Anweisung vorschnell zu vertrauen.

Wer einen Website-Chatbot aufbauen und solche Abläufe in eine verlässliche Gesamtarchitektur einordnen möchte, kann sich den Funktionsumfang von ChatReact ansehen. Planen Sie den Upload dabei als kontrollierten Serviceprozess – mit klarer Zustimmung, verständlichem Status und einem sicheren Weg zum Menschen.

Quellen

• OWASP Cheat Sheet Series: File Upload
• MDN: accept HTML attribute
• W3C WAI: Understanding Status Messages
• W3C WAI: Understanding Error Identification
• EUR-Lex: Verordnung (EU) 2016/679