Dokumentu augšupielāde AI čatbotā: failu pārbaude, datu aizsardzība un nodošana darbiniekam
Faila augšupielāde tīmekļa vietnes čatbotā prasa ko vairāk par saspraudes pogu. Šī pamācība apvieno skaidras robežas, tehnisko pārbaudi, saprotamus statusa ziņojumus un drošu nodošanu darbiniekam.
Augšupielādes ikona tērzēšanas logā izskatās vienkārša: izvēlieties failu, uzdodiet jautājumu, saņemiet atbildi. Tomēr no tehniskā un redakcionālā viedokļa šajā brīdī sākas atsevišķs process. Dokuments var saturēt personas datus, aktīvu saturu, manipulētas failu struktūras, nenolasāmus skenējumus vai instrukcijas, kuras valodas modelis nedrīkst apstrādāt kā uzticamus faktus. Tāpēc dokumentu augšupielādei AI čatbotā ir nepieciešamas skaidras robežas pirms pārsūtīšanas, vairāki pārbaudes posmi pēc tās un saprotams risinājums, ja kaut kas nedarbojas.
Tālāk sniegtā pamācība ir paredzēta tīmekļa vietņu, atbalsta un produktu komandām. Tā neapraksta kāda viena ražotāja funkciju, bet gan uzticamu mērķa modeli: cilvēki pirms augšupielādes zina, kas ir atļauts; sistēma nošķir saņemšanu, drošības pārbaudi un satura novērtēšanu; kļūdas paliek saprotamas; jutīgi gadījumi tiek kontrolēti nodoti cilvēkam.

Augšupielādei ir nepieciešams skaidrs mērķis
Nesāciet ar pēc iespējas garāku atbalstīto formātu sarakstu, bet gan ar dažiem uzdevumiem. Vai čatbotam ir jāpaskaidro dati no rēķina, jāapkopo tehniskā dokumentācija vai jāpapildina atbalsta pieprasījums ar ekrānuzņēmumu? Katram uzdevumam ir jābūt skaidram, kāds saturs ir nepieciešams, kādu lēmumu sistēma drīkst pieņemt un kad cilvēka pārbaude ir obligāta.
Šī mērķa piesaiste novērš to, ka augšupielāde kļūst par vispārīgu dokumentu glabātuvi. Tā palīdz arī izstrādē: reklamācijas apliecinājumam ir nepieciešamas citādas norādes un glabāšanas noteikumi nekā publiskam produkta aprakstam zināšanu bāzei. Esošā pamācība par apmācību ar bieži uzdotajiem jautājumiem (BUJ), dokumentiem un mājaslapas saturu attiecas uz kurētu zināšanu bāzi; turpretī šeit ir runa par failiem, kurus apmeklētāji iesniedz tekošās sarunas laikā.
Padariet redzamus atļautos failu tipus, izmērus un daudzumus
Cilvēkiem būtu jāredz noteikumi, pirms atveras faila izvēles dialoglodziņš: atļautie formāti, maksimālais izmērs, maksimālais skaits un tas, vai tiek pieņemti ar paroli aizsargāti vai saspiesti faili. Izmantojiet atļauto failu sarakstu (positive list), kas pieļauj tikai biznesam nepieciešamos formātus. "Visi dokumenti" nav noderīga prasība.
HTML atribūts accept uzlabo izvēli pārlūkprogrammā, taču nav drošības kontrole. MDN skaidri norāda, ka lietotāji bieži var apiet izvēles ierobežojumu, tāpēc pārbaude ir jāveic servera pusē. Tātad saskarne drīkst piedāvāt atbilstošus paplašinājumus, kamēr serveris neatkarīgi no tā novērtē paplašinājumu, ziņoto MIME tipu, faktisko parakstu un struktūru.
Nepārņemiet failu nosaukumus un metadatus nepārbaudītus
Oriģinālajā nosaukumā var būt speciālās rakstzīmes, ceļa sastāvdaļas, ļoti garas rakstzīmju virknes vai jutīga informācija. Iekšējai glabāšanai sistēmai vajadzētu piešķirt savu nejaušu identifikatoru un redzamo nosaukumu apstrādāt tikai kā attīrītu displeja informāciju. Arī iebūvētie metadati var saturēt vārdus, ierīces informāciju vai atrašanās vietas datus. Tam, vai šie dati ir nepieciešami, ir jāizriet no mērķa.
OWASP File Upload Cheat Sheet cita starpā iesaka atļauto paplašinājumu sarakstu, neatkarīgu tipu pārbaudi, drošus failu nosaukumus, izmēra ierobežojumus, glabāšanu ārpus webroot un aizsardzību pret neatļautām augšupielādēm. Neviena atsevišķa pārbaude nav pietiekama pati par sevi; jēgpilna ir mazu, saprotamu klašu un kontroļu ķēde.
Nošķiriet saņemšanu, drošības pārbaudi un novērtēšanu
Saņemtajam failam nevajadzētu būt uzreiz pieejamam čatā. Stabilā procesā ir vismaz trīs stāvokļi: saņemts, tiek pārbaudīts un apstiprināts novērtēšanai. Pārbaudes laikā fails atrodas izolētā zonā. Tikai pēc veiksmīgas kontroles ieguvei tiek piešķirta piekļuve. Jāvairās no tiešām publiskām URL adresēm vai paredzamiem glabāšanas ceļiem.
Ļaunprātīgas programmatūras un struktūras pārbaude
Atkarībā no riska procesā jāiekļauj vīrusu skenēšana vai smilškaste (sandbox), parakstu pārbaude un piemērotiem Office vai PDF failiem arī Content Disarm and Reconstruction (CDR). Arhīviem, ligzdotajiem failiem un neparasti stipri saspiestam saturam ir nepieciešami savi ierobežojumi, jo tie var patērēt resursus vai uzbrukt parsētājiem. Skeneriem un bibliotēkām ir jābūt atjauninātām un konfigurētām tā, lai noildze vai parsētāja kļūda netiktu uzskatīta par apstiprinājumu.
Teksta ieguve ir atsevišķs kvalitātes statuss
Drošs fails tomēr var būt nelietojams: šķībs skenējums, fotogrāfija ar atspīdumiem, ar roku rakstīta piezīme vai PDF bez iegūstama teksta slāņa. Tāpēc sistēmai vajadzētu atsevišķi ziņot, vai fails ir droši pieņemts un vai saturs ir pietiekami nolasāms. Zema ieguves kvalitāte nedrīkst tikt maskēta ar izdomātiem papildinājumiem.
Formulējiet kļūdas precīzi un rīcībspējīgi
"Augšupielāde neizdevās" atstāj neatbildētu jautājumu par to, kas jādara tālāk. Labāk ir izmantot atšķiramus ziņojumus: formāts netiek atbalstīts, fails ir pārāk liels, konstatēta aizsardzība ar paroli, drošības pārbaude nav izturēta, teksts nav nolasāms vai apstrāde īslaicīgi nav pieejama. Ziņojumam nevajadzētu atklāt iekšējā skenera vai infrastruktūras detaļas, bet gan piedāvāt drošu korekciju.
WCAG 2.2 pieprasa teksta identifikāciju un aprakstu automātiski atpazītām ievades kļūdām. Skaidrojums par Success Criterion 3.3.1 Error Identification uzsver, ka ar vienkāršu atkārtotu formas attēlošanu nepietiek. Čatam tas nozīmē: norādīt faila nosaukumu vai augšupielādes pozīciju, paskaidrot kļūdu teksta veidā un piedāvāt konkrētu opciju aizstāšanai, noņemšanai vai nodošanai darbiniekam.
Paziņojiet par progresu piekļūstamā veidā
Lielāku failu gadījumā rodas gaidīšanas laiks. Vizuāla josla vien nepalīdz visiem cilvēkiem. Statusa izmaiņām, piemēram, "notiek augšupielāde", "drošības pārbaude", "satura nolasīšana" un "gatavs", vajadzētu būt programmātiski atpazīstamām, neizmainot tastatūras fokusu bez prasīšanas. W3C skaidrojumā par WCAG 4.1.3 Status Messages progress, veiksme un kļūda ir skaidri nosaukti kā būtiska statusa informācija.
Atcelšanas darbībai ir jāpaliek sasniedzamai. Pēc atcelšanas būtu jābūt redzamam, vai pārsūtīšana tiešām tika pārtraukta un jau saņemtā kopija tika dzēsta. Mobilajās ierīcēs faila nosaukums, progress un noņemšanas poga ir jāsakārto tā, lai tie neaizsegtu ne ievadi, ne svarīgu navigāciju.
Paskaidrojiet datu aizsardzību pirms augšupielādes
Norādei pirms datu pārsūtīšanas ir jāatbild uz jautājumiem: Kam tiks izmantots fails? Kas to var redzēt? Cik ilgi tas paliks saglabāts? Vai tā saturs tiks izmantots modeļa uzlabošanai? Kā failu var izdzēst? Vispārīgās privātuma politikas paliek svarīgas, taču tās neaizstāj kontekstuālu norādi tieši pie augšupielādes.
Vispārīgās datu aizsardzības regulas 5. pants cita starpā ietver mērķa ierobežojumu, datu minimizēšanu un glabāšanas ierobežojumu. Praksē tas nozīmē: pieprasīt tikai nepieciešamos dokumentus, izvairīties no nevajadzīgām lapām vai metadatiem, noteikt pamatotu dzēšanas termiņu un tehniski pārbaudīt faktisko dzēšanu. Šīs nav individuālas juridiskās konsultācijas; konkrētie pienākumi ir jāizvērtē katram lietojumam atsevišķi.
Nošķiriet publiskos čatus un aizsargātus procesus
Publisks tīmekļa vietnes čats nav automātiski īstā vieta līgumiem, personu apliecinošiem dokumentiem, veselības datiem vai kontu dokumentiem. Jutīgu procesu gadījumā sarunai vajadzētu pāriet uz autentificētu zonu vai izveidotu drošu kanālu. Raksts publisks AI čatbots pret klientu portālu parāda, kā tiek nošķirta identitāte un piekļuve datiem.
Arī pieteikšanās zonā spēkā ir mazāko privilēģiju principa ievērošana. Atbalsta darbiniekam var būt nepieciešams ieskatīties dokumentā, taču ne automātiski pastāvīga piekļuve visiem konta augšupielādētajiem dokumentiem. Piekļuvei, lejupielādēm un dzēšanai vajadzētu tikt izsekojami reģistrētām žurnālā, nekopējot dokumenta saturu nevajadzīgi analītikas notikumos.
Dokumenta saturs joprojām nav uzticams
Apstiprināts fails ir tehniski apstrādāts, taču satura ziņā tas vēl nav autoritatīvs avots. Dokumenti var būt novecojuši, pretrunīgi vai tīši manipulēti. Tie var saturēt arī instrukcijas, kuru mērķis ir likt modelim nopludināt datus vai apiet noteikumus. Tāpēc apstrādājiet iegūto tekstu kā neuzticamu saturu (untrusted content), nošķiriet to no sistēmas noteikumiem un ierobežojiet rīkus un piekļuvi datiem.
Pamācībā par prompt injection tīmekļa vietnes čatbotiem ir paskaidrota šī robeža attiecībā uz RAG un rīkiem. Augšupielādēm klāt nāk tas, ka atbildēm vajadzētu atsaukties uz atpazīstamām dokumenta vietām, norādīt uz nenoteiktību un kritisku lēmumu gadījumā nepapildināt trūkstošās ziņas.
Nodošana cilvēkam (Human Handoff) ar mazu konteksta paketi
Nodošana ir nepieciešama, ja drošības pārbaude atkārtoti neizdodas, ieguve paliek neuzticama, identitāte vai pilnvaras nav skaidras vai speciālista lēmums ir ārpus čatbota kompetences. Tiek nodota tikai tā informācija, kas cilvēkam ir nepieciešama turpināšanai: pieprasījums, augšupielādes statuss, droša dokumenta atsauce, konkrēts kļūdas ziņojums, jau apstiprinātie dati un vēlamais nākamais solis.
Failu nedrīkst papildus nosūtīt neaizsargātā e-pastā tikai tāpēc, ka čatbots to nevarēja nolasīt. Plānots human handoff process saglabā kontekstu, atbildību un cerības, nevajadzīgi nedublējot jutīgu saturu.
Māriet ar notikumiem, nevis ar dokumentu saturu
Produkta uzlabošanai bieži vien pietiek ar strukturētiem notikumiem: izvēle sākta, augšupielāde atcelta, tips noraidīts, sasniegts izmēra limits, drošības pārbaude izturēta, ieguve nepietiekama, izvēlēta nodošana un apstiprināta dzēšana. Failu nosaukumi, iegūtais teksts un personas dati pieder pie lietām, kurām nav automātiski jānonāk analītikā vai kļūdu žurnālos.
Novērtējiet veiksmes un aizsardzības rādītājus kopā. Augsts augšupielādes līmenis ir bezvērtīgs, ja daudzi cilvēki nesaprot, kāds fails tiek gaidīts, vai ja jutīgi dokumenti nonāk publiskajā čatā. Tāpēc svarīgi ir arī korekciju līmenis, atteikšanās pēc datu aizsardzības norādes, nenolasāmu failu īpatsvars, laiks līdz saprotamam kļūdas ziņojumam un veiksmīga turpināšana pēc nodošanas darbiniekam.
Pārbaudes saraksts pirms palaišanas
- Vai katram augšupielādes gadījumam ir definēts skaidrs mērķis un atļautais dokumenta tips?
- Vai formāts, izmērs, skaits, paroles aizsardzība un glabāšana ir redzama pirms izvēles?
- Vai serveris pārbauda paplašinājumu, MIME tipu, parakstu, struktūru un izmēra limitus neatkarīgi no pārlūkprogrammas?
- Vai karantīna, ļaunprātīgas programmatūras pārbaude, ieguve un apstiprināšana ir īstenotas kā nošķirti stāvokļi?
- Vai cilvēki saņem precīzus, piekļūstamus progresa un kļūdu ziņojumus?
- Vai jutīgi procesi tiek pārvietoti uz autentificētu vai cilvēku apkalpotu kanālu?
- Vai dzēšanas termiņš, piekļuve, žurnālu kārtošana un apstiprināta dzēšana ir praktiski pārbaudīti?
- Vai čatbots apstrādā iegūto tekstu kā neuzticamu un citē izsekojamas vietas?
- Vai analītika satur tikai nepieciešamos notikumus, nevis failu nosaukumus vai dokumentu saturu?
- Vai nodošana darbiniekam ir pārbaudīta ar reāliem kļūdu gadījumiem uz galddatora un mobilajām ierīcēm?
Secinājums: Droša augšupielāde sākas pirms faila
Laba dokumentu augšupielāde padara robežas redzamas, pirms sākas datu plūsma. Pēc tam tā nošķir tehnisko saņemšanu, drošības pārbaudi, satura kvalitāti un speciālista lēmumu. Tādējādi AI čatbots var izmantot dokumentus kā noderīgu sarunas kontekstu, nepasaļāvīgi neuzticoties katram saņemtajam baitam vai katrai iegūtajai instrukcijai.
Ikvienam, kurš vēlas izveidot tīmekļa vietnes čatbotu un iekļaut šādus procesus uzticamā kopējā arhitektūrā, var iepazīties ar ChatReact funkciju klāstu. Plānojiet augšupielādi kā kontrolētu pakalpojumu procesu – ar skaidru piekrišanu, saprotamu statusu un drošu ceļu pie cilvēka.
Avoti
Pārvērtiet vietnes apmeklējumus par labākām sarunām
Palaidiet AI čata robotu, kas ir noderīgs no pirmās dienas
Apmāciet ChatReact ar savu vietni, dokumentiem un apstiprinātiem faktiem, lai apmeklētāji saņemtu ātrākas atbildes, un jūsu komanda saņem mazāk atkārtotu pieprasījumu.
Saistītie raksti
Turpināt lasīt
Kā apmācīt AI tērzēšanas robotu ar biežāk uzdotajiem jautājumiem, dokumentiem un vietnes saturu
Ko vietņu komandas jāsagatavo pirms palaišanas, lai robots būtu precīzs, noderīgs un saskaņots ar apstiprināto uzņēmuma informāciju.

Publisks AI čatbots vs. klientu portāls: droša identitātes un datu piekļuves nošķiršana
Publiskam tīmekļa vietnes čatbotam un autentificētam AI čatbotam klientu portālā ir nepieciešamas atšķirīgas datu, rīku un drošības robežas. Šajā rokasgrāmatā sniegta praktiska arhitektūra un testa matrica.

Prompt Injection tīmekļa vietņu čatbotos: RAG, rīku un datu aizsardzība
Kā tīmekļa vietņu komandas ierobežo tiešo un netiešo prompt injection, izmantojot nošķirtas uzticības zonas, minimālo privilēģiju principu, izvades pārbaudi un mērķtiecīgus drošības testus.