---
title: Wdrożenie lokalnego filtra PII zastąpiło koncepcję samodzielnego hostowania modeli językowych
url: https://www.elseif.net/pl/wdrozenie-lokalnego-filtra-pii-zastapilo-koncepcje-samodzielnego-hostowania-modeli-jezykowych
published: 2026-10-09T15:29:56+00:00
language: pl
section: Harnessy
source: https://habr.com/ru/articles/1091236/?utm_campaign=1091236&utm_source=habrahabr&utm_medium=rss
organizations: Cloud.ru, LiteLLM, OneUptime, Yandex
publisher: elseif
---

# Wdrożenie lokalnego filtra PII zastąpiło koncepcję samodzielnego hostowania modeli językowych

Użytkownik wdrożył własny filtr danych osobowych przed połączeniem z chmurowymi modelami językowymi, rezygnując jednocześnie z planu pełnego hostowania modeli na własnym sprzęcie. Decyzja ta wynika z potrzeby ochrony poufnych informacji oraz optymalizacji kosztów infrastruktury.

W ciągu ostatnich dwóch miesięcy przeprowadzono testy sprzętu, w tym kart graficznych RTX PRO 6000 z 96 gigabajtami pamięci, RTX 4090 z 48 gigabajtami oraz H200. Zakupiono również RTX 5070 Ti oraz V100 z 32 gigabajtami pamięci. Po przeprowadzeniu licznych testów wydajnościowych i obserwacji wzrostu cen sprzętu oraz przypadków wycieków danych do dostawców modeli, podjęto decyzję o zmianie strategii. Zauważono, że ryzyko wycieku danych przy atakach na dostawców jest istotne, co skłoniło do poszukiwania alternatywnych rozwiązań.

Wybrano rozwiązanie typu open-source, które skonfigurowano w trybie wymuszającym. System ten działa jako proxy między użytkownikiem a chmurowymi modelami, przetwarzając zarówno zapytania, jak i odpowiedzi. Posiada dwa tryby pracy: wymuszający, który zastępuje dane osobowe i sekrety zastępnikami, oraz wykrywający, który jedynie rejestruje potencjalne zagrożenia w dzienniku zdarzeń. Pierwsza wersja filtra została uruchomiona 17 września, zastępując wcześniejszy mechanizm haka w kliencie, który powodował problemy z przepływem danych, uszkodzone ciągi znaków oraz konflikty z pamięcią podręczną promptów.

22 września nastąpił awaria systemu filtracji. Przyczyną był brak dostępu do zapisu dla katalogu domowego użytkownika systemowego, co uniemożliwiło kompilację kodu. Skrypt automatyzacji nie wykrył braku pliku wykonywalnego, co doprowadziło do wielokrotnych prób restartu usługi przez system zarządzania procesami. Awaria trwała około czterech godzin, podczas których usługa próbowała się uruchomić ponad dwa tysiące sześćset razy. W rezultacie wszystkie połączenia z chmurowymi modelami zostały zablokowane, co potwierdziło skuteczność mechanizmu bezpieczeństwa.

Naprawa polegała na przeniesieniu katalogów pamięci podręcznej do lokalizacji dostępnej dla użytkownika filtra oraz modyfikacji reguł kompilacji. Wykryto również błąd konfiguracji, w którym tryb wykrywający był ustawiony w miejscach, gdzie powinien obowiązywać tryb wymuszający. Po korekcie wprowadzono dodatkowe mechanizmy weryfikacji stanu usługi. Odrzucono rozwiązanie LiteLLM ze względu na utratę efektywności pamięci podręcznej promptów, która spadłaby o około 90 procent, co przy obecnych wolumenach danych oznaczałoby znaczący wzrost kosztów.

Wdrożono dwa monitory w systemie OneUptime. Pierwszy sprawdza co pięć minut status usługi i tryb pracy, traktując brak sygnału jako incydent. Drugi monitoruje metryki, w tym liczniki zdarzeń typu fail-open, które rejestrują przypadki, gdy zapytanie zostało przesłane bez maskowania ze względu na nieobsługiwany format. Taki mechanizm pozwala na kontynuację pracy przy jednoczesnym rejestrowaniu ryzyka, zamiast całkowitego blokowania systemu. Obecnie lokalne modele Gemma4 i Qwen3.8 znajdują się w trybie gotowości na sprzęcie z kartą RTX 5070 Ti, służąc jako zapasowe rozwiązanie, podczas gdy główne operacje odbywają się przez chmurę z zabezpieczeniem filtra.