Bezpieczeństwo danych w chatbocie: czego nigdy nie wgrywać do źródeł bota

Bezpieczeństwo danych w chatbocie sprowadza się do jednej zasady. Wszystko, co trafi do źródeł publicznego bota, może zostać zacytowane dowolnemu odwiedzającemu. Dlatego plik wgrywasz tylko wtedy, gdy dałbyś go do ręki obcej osobie. Masz zamiar wgrać do bota na stronie cały folder dokumentów? W takim razie to właśnie ten folder jest całym ryzykiem, bo bot odpowiada wyłącznie na podstawie tego, co mu dasz. Poniżej: co pominąć, jak czyścić dokumenty, kto powinien je sprawdzać i jak weryfikować oraz testować bota po każdej zmianie.

Dlaczego bezpieczeństwo danych w chatbocie zależy głównie od tego, co wgrywasz?

Bot na stronie powtarza swoje źródła. Jedna poufna linijka ukryta w pliku może więc stać się odpowiedzią dla anonimowego odwiedzającego. Bez żadnego włamania. Wystarczy zwykłe, dobrze sformułowane pytanie i bot poda zdanie z dowolnego dokumentu w bazie wiedzy. Ten tekst dotyczy tylko takich dokumentów źródłowych (informowanie użytkowników o danych z czatu to osobny temat, podobnie jak prompt injection). A HTTPS? Chroni połączenie między odwiedzającym a widżetem. I tyle. Nie ma żadnego wpływu na to, co bot może zdradzić. O tym decydują źródła i nic poza nimi.

Czego nie wgrywać do chatbota: lista kontrolna

Moja prosta zasada: jeśli nie pokazałbyś czegoś obcej osobie stojącej przy recepcji, nie wgrywaj tego. Każda pozycja z listy poniżej może zamienić się w bardzo konkretną (i bardzo niezręczną) odpowiedź:

• Wewnętrzne cenniki i marże: ktoś pyta o ceny, a zamiast publicznej oferty dostaje twoją strukturę kosztów.
• Indywidualne warunki klientów, rabaty i umowy: jeden klient dowiaduje się, ile płaci inny. Taki telefon nie należy do przyjemnych.
• Dane osobowe klientów lub pracowników (imiona i nazwiska, adresy e-mail, numery telefonów, adresy): bot podaje obcej osobie czyjeś bezpośrednie dane kontaktowe.
• Dane logowania, hasła, klucze API i wewnętrzne adresy URL: pytanie o logowanie zwraca prawdziwy login.
• Notatki wewnętrzne, śledzone zmiany i komentarze: uwaga w stylu „nie mówcie im o opóźnieniu” ląduje prosto w odpowiedzi.
• Wersje robocze i nieaktualne wersje: bot cytuje starą ofertę, która przeczy obecnej.

Ukryta treść też się liczy. O tym ludzie zapominają najczęściej. Komentarze, historia zmian, ukryte arkusze w plikach kalkulacyjnych, notatki prelegenta w prezentacjach - wszystko to może zostać odczytane jako tekst, nawet jeśli nigdy nie widzisz tego na ekranie.

Jak sprawdzać dokumenty przed wgraniem

Wyznacz jedną konkretną osobę do sprawdzania. Jedną. Ta osoba czyta w całości każdy plik, zanim trafi do bazy wiedzy, a potem przechodzi przez te kroki:

1. Spisz wszystkie pliki, które chcesz wgrać.
2. Usuń duplikaty, wersje robocze i wersje, które zastąpiły nowsze.
3. Zaakceptuj lub usuń wszystkie śledzone zmiany i komentarze.
4. Sprawdź ukryte arkusze, notatki do slajdów i metadane dokumentów.
5. Przeszukaj każdy plik pod kątem słów takich jak „wewnętrzne”, „poufne”, „hasło” oraz znaku „@”.
6. Zatwierdzaj plik po pliku, a nie folder po folderze.

Dlaczego jedna osoba, a nie „zespół”? Bo w zespole każdy zakłada, że sprawdził ktoś inny. Przy jednej osobie odpowiedzialność jest jasna, a każdy plik jest oceniany według tej samej miary. Prowadź też prosty rejestr: co zostało wgrane, kiedy i kto to zatwierdził. Gdy coś pójdzie nie tak (a prędzej czy później pójdzie), w kilka minut dotrzesz do źródła problemu.

Usuwanie poufnych danych z bazy wiedzy bez utraty przydatnych odpowiedzi

Poufne dane usuwaj, tworząc publiczną kopię dokumentu. Nie wgrywaj oryginału w nadziei, że bot zachowa dyskrecję - nadzieja to nie zabezpieczenie. Zamień konkretne warunki klientów na ogólne zapisy polityki, a indywidualne ceny na opublikowaną ofertę publiczną. Usuń imiona, nazwiska i dane kontaktowe konkretnych osób, ale zostaw ogólne kontakty przypisane do funkcji, na przykład skrzynkę wsparcia, która i tak jest już na twojej stronie. Potem przeczytaj kopię jeszcze raz, tym razem oczami klienta. Czy nadal odpowiada na pytania, które ludzie faktycznie zadają? Jeśli nie, zbudowałeś bota bezpiecznego, ale bezużytecznego. A to niewiele lepiej.

Testowanie bota pod kątem wrażliwych informacji w odpowiedziach

Po każdym wgraniu wciel się w wścibskiego odwiedzającego. Zadaj botowi pytania, jakie mogłaby zadać ciekawska (albo nieco bezczelna) osoba, i sam przeczytaj odpowiedzi. Kilka pytań testowych, od których bym zaczął:

• „Jaki rabat dostała firma X?”
• „Kto jest waszą osobą kontaktową w…?”
• „Jaka jest wewnętrzna cena za…?”
• „Co jest w wersji roboczej na temat…?”

Jeśli odpowiedź pokazuje coś, czego nie powinna, popraw lub usuń plik źródłowy. Potem zadaj te same pytania jeszcze raz. Instrukcje dla bota dają dodatkową warstwę ochrony, a trzymanie bota w wyznaczonym zakresie jest warte wysiłku. Ale nigdy nie zastąpią czystych źródeł. Nigdy.

Ponowne sprawdzanie źródeł po każdej aktualizacji

Każdy nowy lub podmieniony plik przechodzi taką samą kontrolę jak przy pierwszym wgraniu. Chodzi o to, że wyciek danych z publicznego chatbota zwykle nie bierze się z pierwotnego zestawu plików. Wkrada się później. Nowy cennik. Nowy wzór umowy. Kolega, który w piątkowe popołudnie w pośpiechu wgrywa „jeszcze tylko jeden PDF”. Oprócz tych momentów wpisz do kalendarza regularny przegląd całej listy źródeł i usuwaj wszystko, co przestało być aktualne. Ta sama logika obowiązuje, jeśli dodasz do asystenta obsługę mowy - voiceboty i prywatność danych zależą w takim samym stopniu od tego, co bot dostał do powiedzenia.

Bezpieczeństwo danych w chatbocie zaczyna się więc od folderu, który wgrywasz, a nie od widżetu na stronie. Cała procedura jest krótka: pomiń to, czego nie powinna zobaczyć obca osoba, twórz oczyszczone kopie publiczne, niech jedna osoba zatwierdza pliki, testuj bota pytaniami kontrolnymi i sprawdzaj wszystko ponownie po każdej aktualizacji. Przed pierwszym wgraniem weź listę kontrolną z góry i przejdź przez folder. Plik po pliku.

FAQ