Upload af dokumenter i AI-chatbots: Filvalidering, databeskyttelse og handoff
Upload af filer i en chatbot på hjemmesiden kræver mere end blot en papirklipsknap. Denne guide kombinerer klare grænser, teknisk validering, forståelige statusmeddelelser og en sikker overdragelse.
Et upload-ikon i chatvinduet virker ukompliceret: vælg en fil, stil et spørgsmål, modtag et svar. Teknisk og redaktionelt begynder der dog en særskilt proces på dette tidspunkt. Et dokument kan indeholde personoplysninger, aktivt indhold, manipulerede filstrukturer, ulæselige scanninger eller instruktioner, som en sprogmodel ikke må behandle som pålidelige kendsgerninger. Derfor kræver et dokumentupload i en AI-chatbot klare grænser før overførslen, flere kontrolstationer bagefter og en gennemskuelig udvej, hvis noget ikke fungerer.
Følgende guide henvender sig til hjemmeside-, support- og produktteams. Den beskriver ikke en enkelt producentfunktion, men et robust målbillede: Brugerne ved før uploadet, hvad der er tilladt; systemet adskiller modtagelse, sikkerhedskontrol og indholdsevaluering; fejl forbliver forståelige; følsomme sager overføres kontrolleret til et menneske.
Uploadet skal have et klart formål
Start ikke med en så lang liste som muligt over understøttede formater, men med få opgaver. Skal chatbotten forklare oplysninger fra en faktura, opsummere teknisk dokumentation eller supplere en supportanmodning med et screenshot? For hver opgave skal det ligge fast, hvilket indhold der kræves, hvilken beslutning systemet må træffe, og hvornår en menneskelig kontrol er obligatorisk.
Denne formålsbestemthed forhindrer, at uploadet bliver et generelt dokumentlager. Den hjælper også med udformningen: Et bilag til en reklamation kræver andre anvisninger og opbevaringsregler end en offentlig produktbeskrivelse til en videnbase. Den eksisterende guide til træning med FAQ'er, dokumenter og indhold fra hjemmesiden behandler den kuraterede videnbase; her handler det derimod om filer, som besøgende indsender under en igangværende samtale.
Gør tilladte filtyper, størrelser og mængder synlige
Brugere bør se reglerne, før fildialogen åbner: tilladte formater, maksimal størrelse, maksimalt antal, og om adgangskodebeskyttede eller komprimerede filer accepteres. Brug en positivliste, der kun tillader forretningsmæssigt nødvendige formater. "Alle dokumenter" er ikke et hjælpsomt krav.
HTML-attributten accept forbedrer valget i browseren, men er ikke en sikkerhedskontrol. MDN gør udtrykkeligt opmærksom på, at brugere ofte kan omgå valgbegrænsningen, og at kontrollen derfor skal ske på serversiden. Grænsefladen må altså gerne tilbyde passende filendelser, mens serveren uafhængigt heraf vurderer extension, anmeldt MIME-type, faktiske signatur og struktur.
Overtag ikke filnavne og metadata ukontrolleret
Et originalt navn kan indeholde specialtegn, stidele, meget lange tegnstrenge eller følsomme oplysninger. Til intern opbevaring bør systemet tildele et eget tilfældigt ID og kun behandle det synlige navn som en renset visningsinformation. Indlejrede metadata kan også indeholde navne, enhedsoplysninger eller stedangivelser. Om disse data er nødvendige, skal fremgå af formålet.
OWASP's File Upload Cheat Sheet anbefaler blandt andet en positivliste over filendelser, uafhængig typekontrol, sikre filnavne, størrelsesgrænser, lagring uden for webroot og beskyttelse mod uautoriserede uploads. Ingen enkelt kontrol er nok i sig selv; en kæde af små, gennemskuelige kontroller er den mest hensigtsmæssige fremgangsmåde.
Adskil modtagelse, sikkerhedskontrol og evaluering
En modtaget fil bør ikke straks være tilgængelig i chatten. Et robust forløb kender mindst tre tilstande: modtaget, under kontrol og frigivet til evaluering. Under kontrollen ligger filen i et isoleret område. Først efter bestået kontrol får ekstraktionen adgang. Direkte offentlige URL'er eller forudsigelige lagringsstier skal undgås.
Malware- og strukturkontrol
Afhængigt af risikoen hører virusscan eller sandbox, signaturkontrol og – ved egnede Office- eller PDF-filer – Content Disarm and Reconstruction til i processen. Arkiver, indlejrede filer og usædvanligt stærkt komprimeret indhold kræver deres egne grænser, da de kan beslaglægge ressourcer eller angribe parsere. Scannere og biblioteker skal være opdaterede og konfigureret således, at en timeout eller parserfejl ikke betragtes som en godkendelse.
Tekstekstraktion er en selvstændig kvalitetstilstand
En sikker fil kan stadig være ubrugelig: en skæv scanning, et foto med refleksioner, et håndskrevet notat eller en PDF uden ekstraherbart tekstlag. Systemet bør derfor melde separat, om filen er modtaget sikkert, og om indholdet kunne læses tilstrækkeligt. En lav ekstraktionskvalitet må ikke sløres af opdigtede tilføjelser.
Formuler fejl præcist og handlingsorienteret
"Upload mislykkedes" lader det stå åbent, hvad der skal gøres som det næste. Bedre er meddelelser, der kan skelnes fra hinanden: Format ikke understøttet, fil for stor, adgangskodebeskyttelse registreret, sikkerhedskontrol ikke bestået, tekst ikke læsbar eller behandling midlertidigt utilgængelig. Meddelelsen skal ikke afsløre interne scanner- eller infrastrukturoplysninger, men tilbyde en sikker korrektion.
WCAG 2.2 kræver en tekstbaseret identifikation og beskrivelse ved automatisk registrerede indtastningsfejl. Forklaringen til Success Criterion 3.3.1 Error Identification fremhæver, at en formular, der blot vises igen, ikke er tilstrækkelig. For chatten betyder det: Nævn filnavn eller upload-position, forklar fejlen i tekstform, og tilbyd en konkret mulighed for at erstatte, fjerne eller overdrage.
Kommuniker status tilgængeligt
Ved større filer opstår der ventetid. En visuel indikator alene hjælper ikke alle. Statusændringer som "Upload i gang", "Sikkerhedskontrol", "Indhold læses" og "Klar" bør kunne registreres programmatisk uden at flytte tastaturfokus uanmodet. W3C-forklaringen til WCAG 4.1.3 Status Messages nævner udtrykkeligt fremdrift, succes og fejl som relevante statusoplysninger.
En annulleringshandling skal være tilgængelig. Efter en annullering bør det være synligt, om overførslen reelt blev stoppet, og om en allerede modtaget kopi blev slettet. På mobile enheder skal filnavn, fremdrift og fjern-knap placeres således, at de hverken dækker for indtastningsfeltet eller vigtig navigation.
Forklar databeskyttelse før uploadet
Meddelelsen skal før dataoverførslen besvare: Hvad bruges filen til? Hvem kan se den? Hvor længe opbevares den? Bruges indholdet til at forbedre en model? Hvordan kan filen fjernes? Generelle privatlivspolitikker forbliver vigtige, men erstatter ikke den kontekstbaserede oplysning direkte ved uploadet.
Artikel 5 i databeskyttelsesforordningen (GDPR) indeholder blandt andet formålsbegrænsning, dataminimering og opbevaringsbegrænsning. I praksis betyder det: Anmod kun om nødvendige dokumenter, undgå unødvendige sider eller metadata, fastsæt en begrundet slettefrist, og kontroller den faktiske sletning teknisk. Dette er ikke individuel juridisk rådgivning; konkrete forpligtelser skal vurderes for det enkelte anvendelsesformål.
Adskil offentlige chats og beskyttede sager
En offentlig chat på hjemmesiden er ikke automatisk det rette sted til kontrakter, legitimation, helbredsoplysninger eller kontooplysninger. Ved følsomme sager bør samtalen flytte til et autentificeret område eller en etableret sikker kanal. Indlægget om offentlig AI-chatbot versus kundeportal viser, hvordan identitet og dataadgang adskilles.
Også i det indloggede område gælder princippet om mindste råderet (least privilege). En supportmedarbejder kan have brug for indblik i et bilag, men ikke automatisk permanent adgang til alle uploadede dokumenter på en konto. Adgange, downloads og sletninger bør logges sporbart uden unødigt at kopiere dokumentindholdet over i analysehændelser.
Dokumentindhold forbliver ikke-betroet
En godkendt fil er teknisk behandlet, men indholdsmæssigt endnu ikke en autoritativ kilde. Dokumenter kan være forældede, modstridende eller bevidst manipulerede. De kan desuden indeholde instruktioner, der har til formål at få modellen til at lække data eller omgå regler. Behandl derfor ekstraheret tekst som untrusted content, adskil den fra systemregler, og begræns værktøjer og dataadgange.
Guiden om prompt injection ved chatbots på hjemmesider forklarer denne grænse for RAG og værktøjer. For uploads gælder desuden: Svar bør henvise til konkrete steder i dokumentet, angive usikkerhed og ikke supplere manglende oplysninger ved kritiske beslutninger.
Human handoff med en lille kontekstpakke
En overdragelse er nødvendig, hvis sikkerhedskontrollen fejler gentagne gange, ekstraktionen forbliver utilregnelig, identitet eller rettigheder er uklare, eller en faglig beslutning ligger uden for chatbotten. Kun de oplysninger, som mennesket har brug for til at fortsætte, overdrages: henvendelse, upload-status, sikker dokumenthenvisning, konkret fejlmeddelelse, allerede bekræftede oplysninger og ønsket næste skridt.
Filen bør ikke desuden sendes via ubeskyttet e-mail, blot fordi chatbotten ikke kunne læse den. En planlagt human handoff-proces bevarer kontekst, ansvar og forventninger uden unødigt at mangfoldiggøre følsomt indhold.
Mål med hændelser, ikke med dokumentindhold
Til produktforbedring er strukturerede hændelser ofte tilstrækkelige: valg startet, upload annulleret, type afvist, størrelsesgrænse nået, sikkerhedskontrol bestået, ekstraktion utilstrækkelig, overdragelse valgt og sletning bekræftet. Filnavne, ekstraheret tekst og personoplysninger hører ikke automatisk hjemme i analytics eller fejllogge.
Evaluer succes- og beskyttelsesparametre sammen. En høj uploadrate er værdiløs, hvis mange mennesker ikke forstår, hvilket dokument der forventes, eller hvis følsomme dokumenter lander i den offentlige chat. Derfor er korrektionsrate, afbrydelse efter databeskyttelsesoplysning, andel af ulæselige filer, tid indtil forståelig fejlmeddelelse og succesfuld fortsættelse efter handoff også vigtige.
Tjekliste før go-live
- Er der defineret et klart formål og en tilladt dokumenttype for hvert upload-scenarie?
- Er format, størrelse, antal, adgangskodebeskyttelse og opbevaring synlige før valget?
- Kontrollerer serveren extension, MIME-type, signatur, struktur og størrelsesgrænser uafhængigt af browseren?
- Er karantæne, malware-kontrol, ekstraktion og frigivelse implementeret som adskilte tilstande?
- Modtager brugerne præcise, tilgængelige status- og fejlmeddelelser?
- Flyttes følsomme sager til en autentificeret eller menneskeligt betjent kanal?
- Er slettefrist, adgang, logning og bekræftet sletning afprøvet i praksis?
- Behandler chatbotten ekstraheret tekst som ikke-betroet og citerer sporbare steder?
- Indeholder analytics kun nødvendige hændelser i stedet for filnavne eller dokumentindhold?
- Er handoff testet med reelle fejltilfælde på desktop og mobil?
Konklusion: Det sikre upload begynder før filen
Et godt dokumentupload gør grænserne synlige, før data begynder at flyde. Derefter adskiller det teknisk modtagelse, sikkerhedskontrol, indholdskvalitet og faglig beslutning. På denne måde kan en AI-chatbot bruge dokumenter som en hjælpsom samtalekontekst uden overilet at stole på hver modtaget byte eller hver ekstraheret instruktion.
Hvis du vil opbygge en chatbot på hjemmesiden og indpasse sådanne arbejdsgange i en pålidelig samlet arkitektur, kan du se nærmere på funktionerne i ChatReact. Planlæg uploadet som en kontrolleret serviceproces – med klart samtykke, forståelig status og en sikker vej til et menneske.
Kilder
Gør hjemmesidebesøg til bedre samtaler
Lancér en AI-chatbot, der er nyttig fra dag ét
Træn ChatReact med dit website, dokumenter og godkendte fakta, så besøgende får hurtigere svar, og dit team får færre gentagne forespørgsler.
Relaterede artikler
Fortsæt læsningen
Hvordan man træner en AI-chatbot med ofte stillede spørgsmål, dokumenter og webindhold
Hvad webteamet bør forberede før lancering, så chatbotten forbliver præcis, hjælpsom og i overensstemmelse med godkendte virksomhedsoplysninger.
Offentlig AI-chatbot vs. kundeportal: Adskil identitet og dataadgang sikkert
En offentlig website-chatbot og en autentificeret AI-chatbot i kundeportalen har brug for forskellige data-, værktøjs- og sikkerhedsgrænser. Denne guide viser en praktisk arkitektur inklusiv testmatrix.
Prompt injection i website-chatbots: Beskyttelse af RAG, værktøjer og data
Sådan begrænser website-teams direkte og indirekte prompt injection med adskilte tillidszoner, least privilege, validering af output og målrettede sikkerhedstests.