System wsparcia oparty na AI, który miał być zabezpieczony na etapie generowania odpowiedzi przez model, wyciekał dane klientów przez „boczne drzwi”, którymi rekordy CRM trafiają do promptu. Analiza post-mortem autora pokazuje, że ochrona wyłącznie tekstu generowanego przez model nie wystarcza – zapytanie przychodzące, dane pobierane z wewnętrznych narzędzi oraz końcowa emisja wymagają niezależnych zabezpieczeń. W przeciwnym razie firma może ujawnić imiona, adresy e-mail i identyfikatory, nawet nie odnotowując naruszenia na etapie wyjścia modelu.
Dlaczego te trzy granice są istotne
Większość operatorów zakłada, że wyciek następuje, gdy model językowy powtarza ujawnioną wcześniej tajemnicę. W praktyce największe ryzyko występuje jeszcze zanim model w ogóle zobaczy dane. Agent AI otrzymuje trzy strumienie informacji:
- Ingress – surowe zapytanie wpisane przez klienta.
- Return path – informacje, które agent pobiera z systemów zewnętrznych, takich jak CRM.
- Emission – tekst, który model zwraca użytkownikowi.
Jeśli którykolwiek z tych strumieni zawiera niezabezpieczone identyfikatory, agent może nieumyślnie umieścić je w swojej odpowiedzi, nawet jeśli warstwa wyjściowa jest filtrowana.
Od wersji demo do produkcji: ciężko wypracowane lekcje
Przeniesienie prototypu do działającego systemu help desk ujawniło konkretne błędy, których proste podejście „najpierw redaguj, potem wysyłaj” nie wykryło.
Tokenizuj zamiast redagować – Usunięcie imienia lub adresu e-mail przed dotarciem do modelu uniemożliwia systemowi sformułowanie poprawnej odpowiedzi. Przechowuj oryginalną wartość w bezpiecznym sejfie, zastąp ją losowym identyfikatorem UUID w prompcie, a po zakończeniu pracy modelu podmień UUID z powrotem na oryginał. Pozwala to zachować dane surowe poza kontekstem modelu przy jednoczesnym zachowaniu funkcjonalności.
Waliduj identyfikatory za pomocą sum kontrolnych – Wyrażenie regularne wykrywa ciąg znaków wyglądający jak numer konta; suma kontrolna potwierdza, czy jest to prawdziwy identyfikator. Filtr sum kontrolnych zapobiega traktowaniu przez agenta dowolnych liczb jako danych wrażliwych, co ogranicza liczbę wyników fałszywie dodatnich, które w przeciwnym razie wywołałyby niepotrzebną redakcję.
Łącz nakładające się fragmenty – Rekordy klientów często zawierają imię, po którym następuje adres e-mail współdzielący niektóre znaki (np. „John Doe john.doe@example.com”). Tokenizacja samego imienia pozostawia fragment e-maila w postaci jawnego tekstu, który może zostać wyemitowany. Traktuj cały nakładający się obszar jako pojedynczy token.
Testuj właściwą granicę – Test, który przechodzi, sprawdzając jedynie warstwę emisji, daje fałszywe poczucie bezpieczeństwa. Test, który kończy się niepowodzeniem, wykrywając wyciek w ścieżce powrotnej, wymusza naprawę. Projektuj zestawy testowe, które wyraźnie walidują każdą z trzech granic.
Monitoruj stan faktyczny (ground truth) – Gdy człowiek edytuje szkic wygenerowany przez AI przed jego wysłaniem, model już wyprodukował błędną odpowiedź. Porównanie szkicu AI z ostateczną wiadomością zatwierdzoną przez człowieka ujawnia luki w pewności modelu i zapobiega uczeniu się powtarzania błędów.
Stawka dla biznesu
Agenci AI do obsługi klienta znajdują się na styku interakcji publicznych i wewnętrznych magazynów danych.
Kontrargument: dlaczego niektórzy wciąż preferują redakcję
Podsumowanie
Zabezpieczenie agenta obsługi klienta opartego na AI to nie jest problem „jednych drzwi”. Traktuj zapytanie przychodzące, dane pobierane z wewnętrznych systemów oraz tekst wychodzący jak oddzielne ściany; naruszenie którejkolwiek z nich kompromituje całą usługę. Tokenizacja pól wrażliwych, walidacja identyfikatorów, łączenie nakładających się fragmentów, testowanie właściwej granicy oraz ciągłe porównywanie szkiców AI z ostatecznymi wiadomościami od ludzi to praktyczne kroki, które zmieniają „copilota” w godną zaufania, autonomiczną usługę.