Documenten uploaden in een AI-chatbot: Bestandscontrole, privacy en handoff

Een uploadpictogram in het chatvenster lijkt eenvoudig: bestand selecteren, vraag stellen, antwoord krijgen. Technisch en redactioneel begint op dat moment echter een afzonderlijk proces. Een document kan persoonsgegevens, actieve inhoud, gemanipuleerde bestandsstructuren, onleesbare scans of instructies bevatten die een taalmodel niet als betrouwbare feiten mag behandelen. Daarom heeft een documentupload in een AI-chatbot duidelijke grenzen nodig vóór de overdracht, meerdere controle-instanties daarna en een transparante uitweg als er iets misgaat.

De volgende gids is bedoeld voor website-, support- en productteams. Het beschrijft geen specifieke functionaliteit van één leverancier, maar een robuust streefbeeld: mensen weten vóór het uploaden wat is toegestaan; het systeem scheidt ontvangst, veiligheidscontrole en inhoudsanalyse; foutmeldingen blijven Begrijpelijk; gevoelige situaties schakelen gecontroleerd over naar een menselijke medewerker.

De upload heeft een duidelijk doel nodig

Begin niet met een zo lang mogelijke lijst van ondersteunde formaten, maar met een beperkt aantal taken. Moet de chatbot gegevens uit een factuur uitleggen, technische documentatie samenvatten of een supportaanvraag aanvullen met een screenshot? Voor elke taak moet vaststaan welke inhoud nodig is, welke beslissing het systeem mag nemen en wanneer menselijke controle verplicht is.

Deze doelbinding voorkomt dat de uploadfunctie een algemene documentopslag wordt. Het helpt ook bij het ontwerp: een bewijsstuk voor een klacht vereist andere instructies en bewaarregels dan een openbare productbeschrijving voor een kennisbank. De bestaande gids over trainen met FAQ's, documenten en website-inhoud behandelt de gecureerde kennisbank; hier gaat het daarentegen om bestanden die bezoekers tijdens een lopend gesprek indienen.

Toegestane bestandstypen, grootte en aantallen zichtbaar maken

Mensen moeten de regels zien voordat het bestandsvenster opent: toegestane formaten, maximale grootte, maximaal aantal en of met een wachtwoord beveiligde of gecomprimeerde bestanden worden geaccepteerd. Gebruik een whitelist die alleen zakelijk noodzakelijke formaten toestaat. "Alle documenten" is geen nuttige vereiste.

Het HTML-attribuut accept verbetert de selectie in de browser, maar is geen veiligheidscontrole. MDN wijst er uitdrukkelijk op dat gebruikers de selectiebeperking vaak kunnen omzeilen en dat de controle daarom aan de serverzijde moet plaatsvinden. De interface mag dus passende bestandsextensies aanbieden, terwijl de server onafhankelijk daarvan de extensie, het gemelde MIME-type, de daadwerkelijke handtekening en de structuur beoordeelt.

Bestandsnamen en metadata niet ongecontroleerd overnemen

Een oorspronkelijke naam kan speciale tekens, padcomponenten, zeer lange tekenreeksen o gevoelige informatie bevatten. Voor interne opslag moet het systeem een eigen willekeurige ID toewijzen en de zichtbare naam alleen als geschoonde weergave-informatie behandelen. Ingesloten metadata kunnen ook namen, apparaatinformatie of locatiedetails bevatten. Of deze gegevens nodig zijn, moet voortvloeien uit het doel.

De OWASP File Upload Cheat Sheet adviseert onder meer een whitelist voor extensies, onafhankelijke typecontrole, veilige bestandsnamen, limieten voor bestandsgrootte, opslag buiten de webroot en bescherming tegen onbevoegde uploads. Geen enkele controle volstaat op zichzelf; een keten van kleine, transparante controles is de beste aanpak.

Ontvangst, veiligheidscontrole en analyse scheiden

Een geaccepteerd bestand mag niet direct beschikbaar zijn in de chat. Een robuust proces kent minimaal drie statussen: ontvangen, in controle en vrijgegeven voor analyse. Tijdens de controle bevindt het bestand zich in een afgeschermde omgeving. Pas na een succesvolle controle krijgt het extractieproces toegang. Directe openbare URL's of voorspelbare opslagpaden moeten worden vermeden.

Malware- en structuurcontrole

Afhankelijk van het risico maken een virusscan of sandbox, handtekeningcontrole en bij geschikte Office- of PDF-bestanden Content Disarm and Reconstruction deel uit van het proces. Archieven, geneste bestanden en ongebruikelijk sterk gecomprimeerde inhoud vereisen eigen limieten, omdat ze systeembronnen kunnen belasten of parsers kunnen aanvallen. Scanners en bibliotheken moeten up-to-date zijn en zo geconfigureerd dat een time-out of parserfout niet als een goedkeuring geldt.

Tekstextractie is een afzonderlijke kwaliteitsstatus

Een veilig bestand kan toch onbruikbaar zijn: een scheve scan, een foto met reflecties, een handgeschreven notitie of een PDF zonder extraheerbare tekstlaag. Het systeem moet daarom afzonderlijk melden of het bestand veilig is ontvangen en of de inhoud voldoende kon worden gelezen. Een lage extractiekwaliteit mag niet worden verhuld door verzonnen aanvullingen.

Fouten precies en handelingsgericht formuleren

"Upload mislukt" laat in het midden wat er nu moet gebeuren. Beter zijn onderscheidende meldingen: formaat niet ondersteund, bestand te groot, wachtwoordbeveiliging gedetecteerd, veiligheidscontrole niet geslaagd, tekst niet leesbaar of verwerking tijdelijk niet beschikbaar. De melding mag geen interne scanner- of infrastructuurdetails prijsgeven, maar moet een veilige correctiemogelijkheid bieden.

WCAG 2.2 vereist tekstuele identificatie en beschrijving bij automatisch gedetecteerde invoerfouten. De toelichting bij Success Criterion 3.3.1 Error Identification benadrukt dat het enkel opnieuw tonen van een formulier niet volstaat. Voor de chat betekent dit: bestandsnaam of uploadpositie noemen, de fout in tekstvorm uitleggen en een concrete optie bieden voor vervangen, verwijderen of overdragen.

Voortgang toegankelijk communiceren

Bij grotere bestanden ontstaan wachttijden. Een visuele balk alleen helpt niet iedereen. Statusveranderingen zoals "Upload bezig", "Veiligheidscontrole", "Inhoud wordt gelezen" en "Gereed" moeten programmatisch herkenbaar zijn, zonder ongevraagd de toetsenbordfocus te verplaatsen. De W3C-toelichting bij WCAG 4.1.3 Status Messages noemt voortgang, succes en fouten uitdrukkelijk als relevante statusinformatie.

Een annuleerknop moet bereikbaar blijven. Na het annuleren moet duidelijk worden of de overdracht daadwerkelijk is gestopt en een reeds ontvangen kopie is verwijderd. Op mobiele apparaten moeten de bestandsnaam, voortgang en verwijderknop zo worden geplaatst dat ze de invoer of belangrijke navigatie niet overlappen.

Privacy toelichten vóór de upload

De informatie moet vóór de gegevensoverdracht antwoord geven op: Waarvoor wordt het bestand gebruikt? Wie kan het zien? Hoe lang blijft het opgeslagen? Wordt de inhoud gebruikt om een model te verbeteren? Hoe kan het bestand worden verwijderd? Algemene privacyverklaringen blijven belangrijk, maar vervangen de contextuele toelichting direct bij de uploadknop niet.

Artikel 5 van de Algemene Verordening Gegevensbescherming (AVG) omvat onder meer doelbinding, minimale gegevensverwerking en opslagbeperking. In de praktijk betekent dit: vraag alleen noodzakelijke documenten op, vermijd onnodige pagina's of metadata, stel een onderbouwde bewaartermijn vast en controleer de daadwerkelijke verwijdering technisch. Dit is geen individueel juridisch advies; concrete verplichtingen moeten per toepassing worden beoordeeld.

Openbare chats en beveiligde processen scheiden

Een openbare websitechat is niet automatisch de juiste plek voor contracten, identiteitsbewijzen, gezondheidsgegevens of bankafschriften. Bij gevoelige processen moet het gesprek verplaatsen naar een geauthenticeerde omgeving of een gevestigd veilig kanaal. Het artikel over openbare AI-chatbots versus klantportalen laat zien hoe identiteit en datatoegang gescheiden worden.

Ook in een ingelogde omgeving geldt het principe van de minste privileges. Een supportmedewerker moet mogelijk een bewijsstuk inzien, maar heeft niet automatisch permanente toegang nodig tot alle geüploade documenten van een account. Toegang, downloads en verwijderingen moeten transparant worden gelogd, zonder de documentinhoud onnodig naar analyse-gebeurtenissen te kopiëren.

Documentinhoud blijft onbetrouwbaar

Een goedgekeurd bestand is technisch verwerkt, maar inhoudelijk nog geen autoritatieve bron. Documenten kunnen verouderd, tegenstrijdig of opzettelijk gemanipuleerd zijn. Ze kunnen bovendien instructies bevatten die het model proberen te verleiden tot datalekkage of het omzeilen van regels. Behandel geëxtraheerde tekst daarom als untrusted content, scheid deze van systeemregels en beperk tools en datatoegang.

De gids over prompt injection bij website-chatbots licht deze grens toe voor RAG en tools. Voor uploads komt daar bij: antwoorden moeten verwijzen naar aanwijsbare passages in het document, onzekerheid benoemen en bij kritische beslissingen geen ontbrekende gegevens zelf aanvullen.

Human handoff met een compact contextpakket

Een overdracht is nodig wanneer de veiligheidscontrole herhaaldelijk mislukt, de extractie onbetrouwbaar blijft, identiteit of bevoegdheid onduidelijk zijn of een inhoudelijke beslissing buiten de chatbot valt. Alleen de informatie die de medewerker nodig heeft om door te gaan wordt overgedragen: de vraag, de uploadstatus, een veilige referentie naar het document, de concrete foutmelding, al bevestigde gegevens en de gewenste volgende stap.

Het bestand mag niet ook nog eens via onbeveiligde e-mail worden verzonden, puur omdat de chatbot het niet kon lezen. Een goed ontworpen human handoff-proces behoudt context, verantwoordelijkheid en verwachtingen, zonder gevoelige inhoud onnodig te vermenigvuldigen.

Meten met gebeurtenissen, niet met documentinhoud

Voor productverbetering volstaan vaak gestructureerde gebeurtenissen: selectie gestart, upload geannuleerd, type geweigerd, grootte-limiet bereikt, veiligheidscontrole geslaagd, extractie onvoldoende, overdracht gekozen en verwijdering bevestigd. Bestandsnamen, geëxtraheerde tekst en persoonsgegevens horen niet automatisch thuis in analytics of foutlogs.

Evalueer succes- en beveiligingsstatistieken in samenhang. Een hoog uploadpercentage is waardeloos als veel mensen niet begrijpen welk bestand wordt verwacht, of als gevoelige documenten in de openbare chat belanden. Belangrijk zijn daarom ook de correctiefrequentie, afhaakpercentage na de privacy-instructie, het aandeel onleesbare bestanden, de tijd tot een begrijpelijke foutmelding en een succesvolle voortzetting na de handoff.

Checklist voor de go-live

• Is er voor elk uploadscenario een duidelijk doel en een toegestaan documenttype gedefinieerd?
• Zijn formaat, grootte, aantal, wachtwoordbeveiliging en bewaartermijn zichtbaar vóór de selectie?
• Controleert de server extensie, MIME-type, handtekening, structuur en grootte-limieten onafhankelijk van de browser?
• Zijn quarantaine, malwarecontrole, extractie en vrijgave ingericht als gescheiden statussen?
• Krijgen gebruikers nauwkeurige, toegankelijke voortgangs- en foutmeldingen?
• Worden gevoelige processen verplaatst naar een geauthenticeerd of menselijk ondersteund kanaal?
• Zijn de bewaartermijn, toegang, logging en bevestigde verwijdering in de praktijk getest?
• Behandelt de chatbot geëxtraheerde tekst als onbetrouwbaar en citeert deze controleerbare bronnen?
• Bevatten analytics alleen noodzakelijke gebeurtenissen in plaats van bestandsnamen of documentinhoud?
• Is de handoff getest met echte foutsituaties op desktop en mobiel?

Conclusie: De veilige upload begint vóór het bestand

Een goede documentupload maakt grenzen zichtbaar voordat de data gaan stromen. Daarna scheidt het de technische ontvangst, veiligheidscontrole, inhoudskwaliteit en inhoudelijke besluitvorming. Zo kan een AI-chatbot documenten gebruiken als nuttige gesprekscontext, zonder elke ontvangen byte of geëxtraheerde instructie voortijdig te vertrouwen.

Wie een website-chatbot wil bouwen en dergelijke processen wil inpassen in een betrouwbare algehele architectuur, kan de functionaliteiten van ChatReact bekijken. Richt de upload daarbij in als een gecontroleerd serviceproces – met duidelijke toestemming, een begrijpelijke status en een veilige weg naar een menselijke medewerker.

Bronnen

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