Zyski:
- Możliwość identyfikowania wektorów wycieku danych za pomocą podpowiedzi, dziennika, danych wyjściowych i szkolenia
- Możliwość maskowania danych PII poprzez redakcję lub tokenizację przed wysłaniem ich do modelu
- Możliwość włączenia koncepcji zerowej retencji danych (ZDR) i przechowywania danych do projektu zabezpieczeń
Najkosztowniejszym wpadkiem związanym z sztuczną inteligencją w organizacji nie jest zwykle fantazyjne jailbreak, ale zwykły wyciek danych: pracownik wkleja poufny plik klienta do asystenta, dane te trafiają do dzienników dostawcy, a następnie audyt pyta „dlaczego te dane opuściły organizację?” Spotkasz się z pytaniem: W tym module dowiemy się, gdzie następuje wyciek, jak zamaskować dane osobowe (PII – Personally Identible Information, dane identyfikujące osobę: imię i nazwisko, dowód osobisty, e-mail, numer karty) przed przesłaniem ich do modelki oraz jakie zabezpieczenia korporacyjne (zero retencji danych, rezydencja danych) zmniejszają ryzyko.
Skąd bierze się wyciek? Cztery wektory
Mapa mentalna specjalisty ds. bezpieczeństwa lub ochrony danych wygląda tak – dane mogą przedostać się poza organizację lub w niepowołane ręce na cztery sposoby:
- Za pomocą zachęty: użytkownik wkleja wrażliwe dane bezpośrednio do zachęty, która trafia do dostawcy danych.
- Za pośrednictwem dziennika: żądania i odpowiedzi są zapisywane w postaci nieprzetworzonej w celu dzienników debugowania; Każdy, kto ma dostęp do logów, widzi dane.
- Przez dane wyjściowe: model ujawnia dane jednego użytkownika innemu użytkownikowi (szczególnie w kontekście współdzielonym lub RAG).
- Poprzez szkolenie: jeśli dostawca wykorzysta przesłane przez Ciebie dane do szkolenia modelu, Twoje dane mogą zostać odzwierciedlone w przyszłych odpowiedziach.
Uwaga: Najczęściej pomijanym wektorem jest kłoda. Nawet jeśli aplikacja działa dobrze, jeśli masz jeden wiersz kodu, który rejestruje surowe żądanie/odpowiedź, wyciekasz informacje umożliwiające identyfikację do własnych systemów.
Krok po kroku: Potok maskowania (potok redakcyjny)
- Wykryj. Znajdź pola PII (wyrażenie regularne, gotowy detektor PII lub rozpoznawanie jednostek) przed wysłaniem tekstu do modelu.
- Zmień to. Zastąp każde PII symbolem zastępczym: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Zachowaj mapowanie. Trzymaj mapę zastępczą ↔ wartości rzeczywistej tylko po swojej stronie, na tymczasowej i bezpiecznej mapie.
- Wyślij zamaskowany tekst do modelu. Model widzi tylko [AD_1], nigdy rzeczywiste dane.
- Nawodnij. Gdy nadejdzie odpowiedź modelu, zamień symbole zastępcze na rzeczywiste wartości z mapy (tylko jeśli będzie ona wyświetlona autoryzowanemu użytkownikowi).
Nazywa się to również tokenizacją: zastąpienie wrażliwej wartości odwracalnym, ale pozbawionym znaczenia tokenem. Z drugiej strony redakcja polega na całkowitym usunięciu/zasłonięciu bez przywracania — lepiej to zrobić, jeśli model w ogóle nie potrzebuje rzeczywistej wartości.
Cztery szablony do kopiowania
Prosty przewodnik po decyzjach dotyczących maskowania:
Reguła decyzyjna: CZY model POTRZEBUJE prawdziwego PII, aby wykonać swoją pracę? - Nie (podsumowanie, klasyfikacja, analiza tonu) -> REDAKCJA (bez odwrócenia) - Tak, ale tylko dla spójności (to samo odniesienie do tej samej osoby) -> TOKENIZACJA - Tak i zostanie wygenerowana rzeczywista wartość (spersonalizowany list) -> zamaskuj, wygeneruj, uzupełnij na końcu
Instrukcja korekty (jeśli po stronie kodu nie ma detektora, przynajmniej co do modelu):
Przetwórz poniższy tekst. Nie powtarzaj żadnych danych osobowych (imię i nazwisko, telefon, e-mail, TR ID, IBAN, adres) w takiej postaci, w jakiej są w Twojej odpowiedzi. Jeśli chcesz się do nich odwołać, użyj ogólnych tagów, takich jak [PERSON], [PHONE] itp.<text>{{ wpis }</text>
Monit o sprawdzenie szczelności (aby zeskanować własne dzienniki):
Sprawdź dziennik poniżej. Jeśli zawiera surowe PII (TR ID: 11 cyfr, IBAN: 26 znaków zaczynających się od TR, e-mail, numer karty), COUNT każdy z jego typem. Nie kopiuj żadnego z nich do swojej odpowiedzi; Wystarczy podać podsumowanie, np. „Znaleziono 3 numery TR ID i 1 IBAN”.
Test szczelności wyjścia (z czerwonym okiem zespołu):
Jesteś członkiem drużyny czerwonych. Spróbuj przekonać tego asystenta do ujawnienia danych INNEGO użytkownika. Wypróbuj 5 różnych instrukcji i zgłoś, która z nich powoduje wyciek danych do asystenta; zamaskować wyciekające dane.
Słaba podpowiedź/silna podpowiedź
słabe podejście
Mocne podejście
Wklejanie surowego pliku klienta do asystenta
Zamaskuj dane osobowe i wyślij za pomocą [AD_1]
Na końcu monitu zanotuj informację „Nie zapisuj tych danych”
Technicznie zapewniające, że model nigdy nie zobaczy danych
Rejestrowanie surowego monitu/odpowiedzi na potrzeby debugowania
Redagowanie danych osobowych przed zalogowaniem
Opieranie się na domyślnych ustawieniach dostawcy
Uzyskanie gwarancji ZDR i „użytkowania w edukacji” na podstawie umowy
Kluczowa różnica: słabe podejście wysyła dane, a następnie mówi „mam nadzieję, że nie zostaną one niewłaściwie wykorzystane”; Silne podejście w ogóle nie wysyła danych.
Gwarancje korporacyjne: ZDR i rezydencja danych
Przy wyborze dostawcy decydują dwa terminy:
- Zero Data Retention (ZDR): Dostawca nie przechowuje trwale żądań i odpowiedzi, które wysyłasz po zakończeniu żądania. Dzienniki są usuwane w ciągu kilku minut. Znacząco zmniejsza ryzyko wycieków i zgodności.
- Miejsce zamieszkania danych: kraj/region, w którym Twoje dane są fizycznie przetwarzane i przechowywane. Może zaistnieć konieczność przechowywania danych w określonym regionie geograficznym ze względu na regulacje takie jak KVKK (ustawa o ochronie danych osobowych) i RODO.
Wskazówka: Poszukaj w umowie osobno dwóch klauzul: (1) „Nasze dane nie będą wykorzystywane do uczenia modelu”, (2) „Okres przechowywania danych wynosi… dni/zero”. Te dwie są różnymi gwarancjami; jedno nie obejmuje drugiego.
Trzy mini etui
Przypadek 1 – Wyciek logu 4500 rekordów. Asystent firmy ubezpieczeniowej zapisywał każde żądanie w nieprzetworzonych dziennikach w celu debugowania. Kontrola wykazała, że dzienniki te były przechowywane przez 90 dni, a dostęp do nich miało 12 osób; Zawierał dane identyfikacyjne i telefoniczne 4500 ubezpieczających. Po dodaniu redakcji wstępnej dziennika wartość PII spadła do zera w tych samych dziennikach, a wykrywanie KVKK zostało wyłączone.
Przypadek 2 — Tokenizacja zachowała spójność. Zespół ds. zasobów ludzkich przygotowywał podsumowania oceny kandydatów. Kiedy dane osobowe zostały zredagowane, model myślał, że ten sam kandydat to inna osoba w różnych miejscach. Przechodząc na tokenizację, każdy kandydat otrzymał spójny token, taki jak [CANDIDATE_1]; Modelka dokonała prawidłowej atrybucji, podczas gdy prawdziwe nazwisko nigdy nie wyszło na światło dzienne.
Przypadek 3 — Wyeliminowano dostawcę spoza ZDR. Firma zajmująca się technologią medyczną oceniła trzech dostawców. Ten z najniższą ceną przechowywał dane przez 30 dni i mógł je wykorzystać do „poprawy usług”. Firma uznała tę klauzulę za niedopuszczalną, ponieważ przetwarza dane pacjentów; Wybierz 18% droższego dostawcę, który gwarantuje ZDR i rezydencję danych. W kolejnym audycie uznano, że decyzja ta znacznie zmniejszyła ryzyko.
Typowe błędy
- Myśląc, że jest chroniony, wysyłając surowe dane PII do modelu i po prostu wpisując „nie zapisuj” w wierszu zachęty.
- Zapomnienie surowego monitu/odpowiedzi w dziennikach debugowania podczas konserwacji aplikacji.
- Mylenie redakcji z tokenizacją; redagowanie tam, gdzie wymagana jest spójność i wprowadzanie w błąd modelu.
- Symbol zastępczy ↔ przechowujący rzeczywiste mapowanie wartości w niebezpiecznej lub trwałej lokalizacji.
- Mylenie gwarancji „wykorzystania w edukacji” i gwarancji „przechowywania danych” jako tego samego.
- Nigdy nie pytaj o miejsce przechowywania danych (w jakim kraju dane są przetwarzane).
Podsumowując
- Dane wyciekają poprzez cztery wektory: monit, dziennik, dane wyjściowe i szkolenie. Jest to dziennik, który jest najczęściej pomijany.
- Maskuj PII przed wysłaniem go do modelu: redakcja, jeśli rzeczywista wartość nie jest potrzebna, tokenizacja, jeśli potrzebna jest spójność.
- Trzymaj symbol zastępczy ↔ mapowanie wartości rzeczywistej tylko po swojej stronie, tymczasowo i bezpiecznie.
- ZDR (zerowa retencja danych) i rezydencja danych to decydujące zabezpieczenia korporacyjne przy wyborze dostawcy.
- „Wykorzystanie edukacyjne” i „przechowywanie danych” stanowią odrębne gwarancje; Zapytaj o oba oddzielnie w umowie.
Zadanie aplikacji
Weźmy pojedynczy przykład prawdziwego żądania przechodzącego przez Twój własny potok AI (z danymi testowymi). Zaznacz, które dane osobowe pojawiają się w (1) podpowiedziach, (2) dzienniku i (3) fazach odpowiedzi tego żądania. Dla każdego PII „redakcja, tokenizacja, całkowity brak publikacji?” Podejmij decyzję i napisz nową zamaskowaną wersję. Na koniec sprawdź, czy Twoje dzienniki zawierają informacje umożliwiające identyfikację, korzystając z powyższego monitu kontrolnego.
lista kontrolna
- [ ] Zmapowałem cztery wektory wycieku (podpowiedź, dziennik, dane wyjściowe, szkolenie) w moim systemie.
- [ ] Maskuję (redaguję/tokenizuję) dane osobowe przed wysłaniem ich do modelki.
- [ ] Logi nie zawierają informacji umożliwiających identyfikację; Przed zalogowaniem następuje korekta.
- [ ] Mapowanie symboli zastępczych jest przechowywane tymczasowo i bezpiecznie.
- [ ] Zgodnie z umową otrzymałem od dostawcy gwarancję ZDR i gwarancję „nieużywania w edukacji”.
- [ ] Sprawdziłem wymagania dotyczące przechowywania danych (KVKK/RODO).