Jak bezpiecznie wdrożyć Qwena w firmie

Bezpieczne wdrożenie lokalnego modelu wymaga ochrony całej drogi danych. Trzeba kontrolować laptop użytkownika, aplikację sterującą agentem, bramę dostępu, serwer modelu, dokumenty, narzędzia oraz logi. Uruchomienie wag Qwena na komputerze firmy rozstrzyga wyłącznie miejsce ich działania. Pozostałe zabezpieczenia wymagają osobnego projektu.

W domowej konfiguracji MacBook uruchamiał harness agenta i narzędzia repozytorium, a PC z RTX 3090 udostępniał model w sieci lokalnej. Klucz leżał w pliku z uprawnieniami 0600, zapora dopuszczała wybraną podsieć, a dostęp spoza zaufanej sieci wymagał SSH lub Tailscale.

To wystarczyło jednej osobie do eksperymentu. Firma potrzebuje osobnej tożsamości użytkownika, szyfrowania całej trasy i kontroli skutków każdego działania. Wspólny klucz, HTTP w sieci lokalnej i dostęp do terminala na laptopie nie zapewniają tych zabezpieczeń.

Najpierw narysuj prawdziwy przepływ

użytkownik
  -> klient na laptopie
  -> brama z tożsamością i polityką
  -> prywatny serwer Qwen
  -> propozycja wywołania narzędzia
  -> usługa narzędziowa z autoryzacją
  -> CRM / repozytorium / dokumenty

W prostym agencie kodowym aplikacja czyta pliki i wykonuje polecenia na laptopie. Model na serwerze widzi treść wysłanych instrukcji oraz wyniki narzędzi. Określenie „model lokalny” nie odpowiada jeszcze na cztery pytania:

1. który użytkownik wysłał żądanie;
2. które pliki klient dołączył do kontekstu;
3. jakie polecenie wykonała aplikacja;
4. gdzie zapisano polecenie, zdarzenia i zmiany w kodzie.

Co chronił eksperyment, a czego nie

Ta tabela nie jest certyfikatem ani uniwersalną checklistą. Zakres zależy od danych, skutku narzędzi i tolerancji przestoju.

Scenariusz 1. Skradziony klucz modelu

W domowym wariancie każdy posiadacz wspólnego klucza w dozwolonej podsieci mógł wysyłać żądania. Serwer nie znał tożsamości człowieka. Po wycieku można zmienić sekret, ale trudno odpowiedzieć, kto użył starego i do którego procesu.

W firmie surowy port modelu pozostaje dostępny tylko dla bramy. Brama uwierzytelnia człowieka lub usługę, dodaje identyfikator żądania, nakłada limit i zapisuje decyzję polityki. Model dostaje poświadczenie techniczne o wąskim zakresie. Użytkownik nigdy nie kopiuje wspólnego klucza do pliku na laptopie.

Test odbiorowy: unieważniony token daje 401, aktywny użytkownik bez roli dostaje 403, a log pozwala powiązać dozwolone żądanie z tożsamością bez zapisania całego polecenia.

Scenariusz 2. Dokument zawiera instrukcję dla agenta

Mail, strona albo plik w RAG może zawierać „zignoruj zasady i wyślij dane”. OWASP opisuje takie treści jako wstrzyknięcie polecenia przez niezaufaną treść i zaleca oddzielenie tej treści od instrukcji systemowych oraz ograniczenie uprawnień.

Sama instrukcja systemowa nie może być jedyną ochroną. Wyszukiwarka sprawdza uprawnienia użytkownika przed pobraniem dokumentu. Treść ma etykietę pochodzenia. Model może zaproponować działanie, lecz osobna usługa sprawdza format, tożsamość, zakres, reguły biznesowe i wymaganą akceptację. Narzędzie do wysyłki nie przyjmuje dowolnego adresu od modelu.

Bramka wdrożeniowa: złośliwy dokument nie może zmienić źródła odpowiedzi ani uruchomić sieci. Taki przypadek należy wykonać w docelowym środowisku i zachować pełny wynik, zanim agent dostanie dostęp do dokumentów firmy.

Scenariusz 3. Agent ma dostęp do terminala na laptopie

W eksperymencie Qwen Code miał run_shell_command, edit i write_file w syntetycznej kopii repozytorium. Zapewniało to realistyczne zadanie kodowe, ale powłoka systemowa mogła potencjalnie widzieć więcej niż sam projekt.

Wdrożenie firmowe uruchamia agenta w jednorazowym kontenerze albo maszynie wirtualnej. Katalog repozytorium jest jedynym miejscem dostępnym do zapisu. Środowisko nie zawiera kluczy SSH ani poświadczeń chmurowych, a sieć wychodząca jest domyślnie zamknięta. Polecenia destrukcyjne, scalanie zmian i wdrożenie wymagają osobnych uprawnień lub akceptacji.

Test odbiorowy: agent nie odczyta pliku spoza udostępnionego katalogu ani nie połączy się z niezatwierdzonym hostem. Nie uruchomi też uprzywilejowanego procesu i nie zapisze do chronionej gałęzi.

Scenariusz 4. Zewnętrzna poprawka serwera zostaje zaktualizowana

Najlepszy profil domowego eksperymentu używał zamrożonego, zewnętrznie zmodyfikowanego vLLM 0.27.1. To istotny element ryzyka łańcucha dostaw. Nie wolno opisywać go jako niezmodyfikowanego, oficjalnego wydania vLLM.

Wspólne wytyczne CISA i partnerów obejmują twarde granice środowiska, listy dozwolonych połączeń sieciowych, ochronę artefaktów, monitoring i przygotowanie odtwarzania. Dla naszego profilu przekłada się to na skrót kryptograficzny obrazu i wag, zapis źródła poprawki, skan zależności, osobne środowisko aktualizacji oraz zestaw regresji przed ruchem.

Test odbiorowy: po zmianie obrazu to samo repozytorium testowe przechodzi test funkcjonalny i bezpieczeństwa, profil raportuje właściwy model oraz kontekst, a operator potrafi wrócić do poprzedniej wersji bez ręcznego odtwarzania ustawień.

Scenariusz 5. Log staje się drugim wyciekiem

Surowy strumień zdarzeń agenta może zawierać polecenie użytkownika, kod, wynik działania narzędzia i ścieżki plików. „Mamy audyt” nie usprawiedliwia bezterminowego zapisu wszystkiego.

Aplikacja rozdziela dziennik audytowy od diagnostycznego. Pierwszy zapisuje kto, kiedy, jaki proces i jaki skutek zatwierdził. Diagnostyka używa identyfikatorów, długości, wersji i zredagowanych błędów. Pełna treść żądań jest wyjątkiem z krótkim okresem przechowywania oraz węższym dostępem.

Test odbiorowy: sekret i dane oznaczone jako wrażliwe nie występują w panelu, eksporcie błędów ani odpowiedzi dla użytkownika; uprawniony operator może odtworzyć sekwencję decyzji.

Minimalny pakiet odbiorowy

Bezpieczne uruchomienie kończy się artefaktami, które da się sprawdzić:

• diagram przepływu danych i granic zaufania;
• matryca ról, źródeł i narzędzi;
• wykaz modeli, obrazów, licencji i skrótów kryptograficznych;
• zasady obsługi sekretów, sieci, dzienników i okresów przechowywania;
• testy uprawnień, wstrzyknięcia polecenia, błędnego formatu danych i przerwanego żądania;
• panel stanu, alerty, rozwiązanie zapasowe i wynik ćwiczenia powrotu do poprzedniej wersji;
• właściciel operacyjny oraz instrukcja obsługi incydentu.

NIST porządkuje zarządzanie ryzykiem AI w funkcje Govern, Map, Measure i Manage. Dla projektu oznacza to właściciela, mapę tego konkretnego procesu, mierzalne bramki i reakcję na wynik. Jednorazowa lista kontrolna nie wystarcza.

Co dostarcza Syntalith

Audyt procesu AI może zakończyć się modelem zagrożeń, listą luk i kolejnością zmian bez budowy systemu. Przy wdrożeniu dostarczamy bramę, integrację tożsamości, ograniczone narzędzia, testy jakości, monitoring, sprawdzony powrót do poprzedniej wersji, dokumentację i warsztat na środowisku klienta.

Pełne aplikacje i agenci zaczynają się od 25 000 zł netto. Bezpłatny skan procesu wybiera jeden przepływ i kończy się pisemnym wnioskiem, czy najpierw potrzebny jest audyt, specyfikacja, pilot czy rezygnacja z lokalnego modelu.