Standard • Bezpieczeństwo i ryzyko

Redakcja danych i DLP

Jak wdrożyć DLP w systemach LLM: redakcja wejścia i wyjścia, detektory, tryby block/redact/report‑only oraz regresje.

Powiązane: Dane i prywatność Powiązane: Bezpieczeństwo LLM
W skrócie
  • DLP działa w dwóch kierunkach: redakcja wejścia (do modelu) i wyjścia (do użytkownika).
  • Tryb „report‑only” jest akceptowalny na start, ale musi mieć termin wygaszenia.
  • Detektory: reguły (regex/allowlist) + modele pomocnicze + kontekst (np. tenant).
  • Regresje: DLP wymaga testów, bo „poprawki” potrafią złamać normalne przypadki.

DLP w Luage jest traktowane jako element inżynierii kontekstu: zanim dane trafią do modelu, są klasyfikowane i redagowane. Analogicznie — zanim odpowiedź trafi do użytkownika, jest sprawdzana pod kątem wycieku PII/sekretów.

1. Model mentalny: dwa kierunki

Input DLP (do modelu)
  • maskowanie PII, sekretów, identyfikatorów
  • minimalizacja pól (tylko to, co potrzebne)
  • logowanie metadanych zamiast treści
Output DLP (do użytkownika)
  • wykrywanie wycieku danych
  • blokada lub redakcja fragmentu
  • eskalacja / approval dla incydentów

2. Demonstrator redakcji

Poniżej jest uproszczony demonstrator (lokalny) pokazujący ideę. W produkcji detekcja jest bogatsza (kontekst, allowlisty, słowniki, modele pomocnicze), ale mechanika jest ta sama.

Redakcja danych — tryb demonstracyjny
Zaznacz detektory — zobacz jak zmienia się tekst i lista trafień.
Wejście (surowe)
Po redakcji (do modelu / do logów)
Trafienia detektorów

3. Pipeline: gdzie wpiąć DLP

  1. Przed kontekstem: redakcja danych wejściowych użytkownika i narzędzi.
  2. Przed RAG: filtrowanie źródeł po ACL oraz usuwanie danych spoza celu.
  3. Przed odpowiedzią: detekcja wycieku i polityka blokady/eskalacji.
  4. Przed logami: zawsze redakcja — trace bez danych wrażliwych.

4. Tryby pracy i wyjątki

Dla wdrożeń produkcyjnych Luage zakłada trzy tryby:

  • Block — twarda blokada (sekrety, dane prawnie wrażliwe).
  • Redact — maskowanie i kontynuacja (część PII).
  • Report‑only — wykrywanie i logowanie zdarzeń (start, pilotaż).
Report‑only jest wyjątkiem, nie docelowym stanem. Jeśli jest użyty, powinien pojawić się w rejestrze wyjątków z terminem wygaszenia i planem przejścia na tryb „block/redact”.

5. Testy i regresje

DLP ma typowy problem: poprawka jednego detektora psuje inne. Dlatego potrzebne są regresje:

  • zestaw przypadków pozytywnych i negatywnych (false positives są kosztowne),
  • testy „przez domenę” (support, sprzedaż, HR),
  • metadane i telemetry (częstość trafień, koszt redakcji, latencja).

6. Checklist standardu

  • Detektory: e‑mail/telefon/sekrety/identyfikatory + allowlisty kontekstowe.
  • DLP wpięte na wejściu, na wyjściu i przed logowaniem.
  • Tryb report‑only ma termin wygaszenia; wyjątki są rejestrowane.
  • Regresje i monitoring (false positives / false negatives).
Powiązane
Na tej stronie
Spis
    Nawigacja
    ← Poprzedni Następny →
    Status merytoryczny
    Metryka (wersja, owner, terminy przeglądu) jest wypełniana automatycznie na podstawie manifestu.