Przesyłanie dokumentów w chatbocie AI: Weryfikacja plików, ochrona danych i handoff

Ikona przesyłania w oknie czatu wygląda niepozornie: wybierz plik, zadaj pytanie, otrzymaj odpowiedź. Od strony technicznej i edytorskiej w tym miejscu rozpoczyna się jednak osobny proces. Dokument może zawierać dane osobowe, aktywną zawartość, zmanipulowaną strukturę plików, nieczytelne skany lub instrukcje, których model językowy nie może traktować jako wiarygodne fakty. Dlatego przesyłanie dokumentów w chatbocie AI wymaga jasnych ograniczeń przed transmisją, kilku etapów weryfikacji po jej zakończeniu oraz przewidywalnej ścieżki awaryjnej, gdy coś pójdzie nie tak.

Poniższy przewodnik jest skierowany do zespołów odpowiedzialnych za strony internetowe, wsparcie techniczne i produkty. Nie opisuje on pojedynczej funkcji konkretnego dostawcy, lecz przedstawia stabilny model docelowy: użytkownicy wiedzą przed przesłaniem, co jest dozwolone; system rozdziela odbiór, kontrolę bezpieczeństwa i analizę treści; błędy pozostają zrozumiałe; a wrażliwe przypadki są w kontrolowany sposób przekazywane człowiekowi.

Przesyłanie plików wymaga jasnego celu

Nie zaczynaj od jak najdłuższej listy obsługiwanych formatów, lecz od kilku konkretnych zadań. Czy chatbot ma wyjaśniać pozycje na fakturze, podsumowywać dokumentację techniczną, czy uzupełniać zgłoszenie serwisowe o zrzut ekranu? Dla każdego zadania należy ustalić, jakie treści są potrzebne, jakie decyzje może podjąć system i kiedy niezbędna jest weryfikacja przez człowieka.

Takie powiązanie z celem zapobiega sytuacji, w której moduł przesyłania staje się ogólnym repozytorium dokumentów. Pomaga to również w projektowaniu interfejsu: dowód zakupu do reklamacji wymaga innych informacji i reguł przechowywania niż publiczny opis produktu w bazie wiedzy. Istniejący przewodnik dotyczący trenowania na FAQ, dokumentach i treściach stron www opisuje zarządzaną bazę wiedzy; tutaj chodzi natomiast o pliki przesyłane przez odwiedzających w trakcie trwającej rozmowy.

Uwypuklij dozwolone typy plików, rozmiary i limity ilościowe

Użytkownicy powinni widzieć zasady, zanim otworzy się okno wyboru pliku: dozwolone formaty, maksymalny rozmiar, maksymalną liczbę plików oraz informację, czy akceptowane są pliki chronione hasłem lub skompresowane. Stosuj listę dozwolonych formatów (allowlist), uwzględniającą tylko te typy plików, które są niezbędne biznesowo. „Wszystkie dokumenty” nie jest prawidłowym wymaganiem.

Atrybut HTML accept ułatwia wybór w przeglądarce, ale nie stanowi zabezpieczenia. MDN wyraźnie wskazuje, że użytkownicy mogą łatwo obejść ograniczenia wyboru, dlatego weryfikacja musi odbywać się po stronie serwera. Interfejs może więc sugerować odpowiednie rozszerzenia, podczas gdy serwer niezależnie ocenia rozszerzenie, zgłoszony typ MIME, rzeczywistą sygnaturę pliku oraz jego strukturę.

Nie przyjmuj nazw plików ani metadanych bez weryfikacji

Oryginalna nazwa pliku może zawierać znaki specjalne, ścieżki dostępowe, bardzo długie ciągi znaków lub dane wrażliwe. Do celów wewnętrznego przechowywania system powinien przypisywać własny, losowy identyfikator, a widoczną nazwę traktować jedynie jako oczyszczoną informację wyświetlaną. Wbudowane metadane mogą również zawierać nazwiska, informacje o urządzeniu czy lokalizacji. To, czy te dane są potrzebne, musi wynikać z celu przetwarzania.

Dokument OWASP File Upload Cheat Sheet zaleca m.in. stosowanie listy dozwolonych rozszerzeń, niezależną weryfikację typu, bezpieczne nazwy plików, limity rozmiaru, przechowywanie poza katalogiem webroot oraz ochronę przed nieuprawnionym przesłaniem. Żadna pojedyncza kontrola nie jest wystarczająca; kluczem jest łańcuch małych, przejrzystych mechanizmów sprawdzających.

Rozdziel odbiór, kontrolę bezpieczeństwa i analizę

Przyjęty plik nie powinien być natychmiast dostępny w oknie czatu. Stabilny proces obejmuje co najmniej trzy stany: odebrany, w trakcie weryfikacji oraz zatwierdzony do analizy. Podczas kontroli plik znajduje się w odizolowanym środowisku. Dopiero po pomyślnym przejściu weryfikacji moduł ekstrakcji otrzymuje do niego dostęp. Należy unikać bezpośrednich, publicznych adresów URL oraz przewidywalnych ścieżek przechowywania.

Sprawdzanie pod kątem złośliwego oprogramowania i struktury

W zależności od poziomu ryzyka proces powinien obejmować skanowanie antywirusowe lub piaskownicę (sandbox), weryfikację sygnatur, a w przypadku odpowiednich plików Office lub PDF – procedurę Content Disarm and Reconstruction (CDR). Archiwa, pliki zagnieżdżone oraz zasoby o nietypowo wysokim stopniu kompresji wymagają osobnych limitów, ponieważ mogą obciążać zasoby lub atakować parsery. Skanery i biblioteki muszą być aktualne i skonfigurowane tak, aby błąd przekroczenia limitu czasu (timeout) lub błąd parsera nie był traktowany jako zatwierdzenie pliku.

Ekstrakcja tekstu to osobny status jakościowy

Bezpieczny plik nadal może być nieprzydatny: krzywy skan, zdjęcie z odblaskami światła, notatka odręczna czy plik PDF bez warstwy tekstowej. System powinien więc osobno informować, czy plik został bezpiecznie przyjęty i czy jego treść udało się odczytać w wystarczającym stopniu. Niska jakość ekstrakcji tekstu nie może być maskowana przez generowanie zmyślonych uzupełnień.

Formułuj błędy precyzyjnie i w sposób umożliwiający działanie

Komunikat „Przesyłanie nie powiodło się” nie daje wskazówki, co należy zrobić w następnej kolejności. Lepsze są jednoznaczne komunikaty: format nie jest obsługiwany, plik jest za duży, wykryto ochronę hasłem, weryfikacja bezpieczeństwa nie powiodła się, tekst jest nieczytelny lub przetwarzanie jest tymczasowo niedostępne. Komunikat nie powinien ujawniać szczegółów dotyczących wewnętrznych skanerów czy infrastruktury, ale musi oferować bezpieczną opcję poprawy.

Standard WCAG 2.2 wymaga identyfikacji i opisu słownego w przypadku automatycznie wykrytych błędów wprowadzania danych. Wyjaśnienie do Kryterium Sukcesu 3.3.1 (Identyfikacja błędu) podkreśla, że ponowne wyświetlenie formularza jest niewystarczające. W kontekście czatu oznacza to: wskazanie nazwy pliku lub pozycji przesyłania, wyjaśnienie błędu w formie tekstowej oraz zaoferowanie konkretnej opcji zastąpienia, usunięcia lub przekazania pliku dalej.

Informuj o postępie w sposób dostępny (a11y)

W przypadku większych plików pojawia się czas oczekiwania. Sam wizualny pasek postępu nie jest wystarczający dla wszystkich użytkowników. Zmiany statusu, takie như „Trwa przesyłanie”, „Weryfikacja bezpieczeństwa”, „Odczytywanie treści” oraz „Gotowe”, powinny być rozpoznawalne programistycznie, bez samowolnego przenoszenia fokusu klawiatury. Dokumentacja W3C do WCAG 4.1.3 (Komunikaty o statusie) wyraźnie wymienia postęp, sukces i błędy jako istotne informacje o statusie.

Przycisk anulowania musi pozostać łatwo dostępny. Po anulowaniu użytkownik powinien widzieć, czy transmisja została rzeczywiście zatrzymana, a odebrana już kopia usunięta. Na urządzeniach mobilnych nazwa pliku, postęp oraz przycisk usunięcia powinny być rozmieszczone tak, aby nie przesłaniały pola wprowadzania tekstu ani kluczowej nawigacji.

Wyjaśnij zasady ochrony danych przed przesłaniem pliku

Informacja przed wysłaniem danych musi odpowiadać na pytania: W jakim celu plik będzie używany? Kto może go zobaczyć? Jak długo będzie przechowywany? Czy jego treść zostanie wykorzystana do ulepszania modelu? Jak można usunąć plik? Ogólne polityki prywatności są ważne, ale nie zastępują informacji kontekstowej umieszczonej bezpośrednio przy formularzu uploadu.

Artykuł 5 Ogólnego Rozporządzenia o Ochronie Danych (RODO) określa m.in. zasady ograniczenia celu, minimalizacji danych oraz ograniczenia przechowywania. W praktyce oznacza to: wymagaj tylko niezbędnych dokumentów, unikaj niepotrzebnych stron lub metadanych, ustal uzasadniony okres przechowywania i weryfikuj technicznie proces faktycznego usuwania. Nie jest to indywidualna porada prawna; konkretne obowiązki muszą zostać ocenione dla danego wdrożenia.

Rozdziel czaty publiczne od procesów chronionych

Publiczny chatbot na stronie nie zawsze jest właściwym miejscem na przesyłanie umów, dokumentów tożsamości, danych medycznych czy historii rachunku bankowego. W przypadku poufnych operacji rozmowa powinna zostać przeniesiona do strefy uwierzytelnionej lub sprawdzonego, bezpiecznego kanału. Artykuł Publiczny chatbot AI a portal klienta wyjaśnia, jak skutecznie rozdzielić tożsamość i dostęp do danych.

Nawet po zalogowaniu obowiązuje zasada minimalnych uprawnień (least privilege). Pracownik wsparcia może potrzebować wglądu w rachunek, ale nie musi mieć stałego dostępu do wszystkich przesłanych dokumentów na danym koncie. Dostęp, pobieranie i usuwanie plików powinny być rejestrowane w logach w sposób umożliwiający audyt, bez niepotrzebnego kopiowania treści dokumentów do zdarzeń analitycznych.

Treść dokumentu nie jest automatycznie zaufana

Zatwierdzony plik jest przetworzony technicznie, ale pod względem treści nadal nie stanowi autorytatywnego źródła informacji. Dokumenty mogą być nieaktualne, sprzeczne lub celowo zmanipulowane. Mogą również zawierać instrukcje mające na celu skłonienie modelu do wycieku danych lub obejścia reguł bezpieczeństwa. Dlatego wyekstrahowany tekst należy traktować jako treść niezaufaną (untrusted content), odizolować go od reguł systemowych oraz ograniczyć narzędzia i dostęp do danych.

Przewodnik dotyczący Prompt Injection w chatbotach na stronie opisuje te ograniczenia w kontekście RAG i narzędzi. W przypadku przesyłania plików dochodzi dodatkowa zasada: odpowiedzi powinny odwoływać się do wskazanych fragmentów dokumentu, sygnalizować niepewność i nie uzupełniać brakujących informacji przy podejmowaniu krytycznych decyzji.

Human Handoff z zwięzłym pakietem kontekstowym

Przekazanie rozmowy człowiekowi jest konieczne, gdy weryfikacja bezpieczeństwa wielokrotnie się nie powodzi, ekstrakcja tekstu jest nieskuteczna, tożsamość lub uprawnienia są niejasne, albo decyzja merytoryczna wykracza poza możliwości chatbota. Przekazywane są tylko te informacje, których konsultant potrzebuje do kontynuowania sprawy: zgłoszenie, status pliku, bezpieczny odnośnik do dokumentu, konkretny komunikat o błędzie, potwierdzone już dane oraz oczekiwany następny krok.

Plik nie powinien być dodatkowo wysyłany niezaszyfrowaną wiadomością e-mail tylko dlatego, że chatbot nie mógł go odczytać. Przemyślany proces Human Handoff zachowuje kontekst, odpowiedzialność i oczekiwania klienta bez niepotrzebnego powielania wrażliwych treści.

Mierz zdarzenia, a nie treść dokumentów

Do ulepszania produktu wystarczą z reguły ustrukturyzowane zdarzenia (events): rozpoczęto wybór, anulowano przesyłanie, odrzucono typ pliku, przekroczono limit rozmiaru, weryfikacja bezpieczeństwa zaliczona, ekstrakcja niewystarczająca, wybrano przekazanie do konsultanta oraz potwierdzono usunięcie. Nazwy plików, wyekstrahowany tekst i dane osobowe nie powinny trafiać do analityki ani logów błędów.

Analizuj wskaźniki sukcesu łącznie z wskaźnikami ochrony. Wysoki współczynnik przesyłania plików jest bezwartościowy, jeśli użytkownicy nie wiedzą, jakiego pliku się od nich oczekuje, lub gdy poufne dokumenty lądują w publicznym czacie. Dlatego równie ważne są: współczynnik poprawek, rezygnacja po wyświetleniu informacji o ochronie danych, udział nieczytelnych plików, czas do wyświetlenia zrozumiałego błędu oraz skuteczna kontynuacja obsługi po przekazaniu do konsultanta.

Lista kontrolna przed uruchomieniem (Go-live)

• Czy dla każdego scenariusza przesyłania zdefiniowano jasny cel i dozwolony typ dokumentu?
• Czy format, rozmiar, liczba plików, ochrona hasłem i czas przechowywania są widoczne przed wyborem pliku?
• Czy serwer weryfikuje rozszerzenie, typ MIME, sygnaturę, strukturę i limity rozmiaru niezależnie od przeglądarki?
• Czy kwarantanna, skanowanie pod kątem złośliwego oprogramowania, ekstrakcja i zatwierdzenie są zrealizowane jako osobne stany?
• Czy użytkownicy otrzymują precyzyjne, dostępne (a11y) komunikaty o postępie i błędach?
• Czy wrażliwe procesy są przenoszone do kanału uwierzytelnionego lub obsługiwanego przez człowieka?
• Czy okres przechowywania, dostęp, logowanie oraz potwierdzenie usunięcia zostały przetestowane w praktyce?
• Czy chatbot traktuje wyekstrahowany tekst jako niezaufany i cytuje weryfikowalne fragmenty?
• Czy analityka zawiera wyłącznie niezbędne zdarzenia zamiast nazw plików czy ich treści?
• Czy proces przekazania (handoff) został przetestowany na rzeczywistych błędach na komputerach i urządzeniach mobilnych?

Podsumowanie: Bezpieczne przesyłanie zaczyna się przed wyborem pliku

Dobre moduły przesyłania dokumentów wyraźnie komunikują zasady, zanim dane zostaną przesłane. Następnie rozdzielają techniczny odbiór, kontrolę bezpieczeństwa, ocenę jakości treści i decyzję merytoryczną. Dzięki temu chatbot AI może wykorzystywać dokumenty jako pomocny kontekst rozmowy, nie ufając przedwcześnie każdemu odebranemu bajtowi ani wyekstrahowanej instrukcji.

Jeśli chcesz wdrożyć chatbota na stronie i wpisać takie procesy w bezpieczną architekturę, sprawdź możliwości i funkcje ChatReact. Zaplanuj przesyłanie plików jako kontrolowany proces obsługi – z jasną zgodą, zrozumiałym statusem i bezpieczną ścieżką kontaktu z człowiekiem.

Źródła

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