Jak bezpiecznie wdrożyć Qwena w firmie

Bezpieczne wdrożenie lokalnego modelu obejmuje całą drogę danych. Trzeba kontrolować laptop użytkownika, aplikację sterującą agentem, bramę dostępu, serwer modelu, dokumenty, narzędzia i logi. Uruchomienie wag Qwena na firmowym komputerze określa tylko miejsce ich działania. Pozostałe zabezpieczenia wymagają osobnego projektu.

W domowej konfiguracji na MacBooku działał harness. To klient sterujący przebiegiem agenta i narzędziami repozytorium. Komputer z RTX 3090 udostępniał model w sieci lokalnej. Klucz był w pliku z uprawnieniami 0600, zapora dopuszczała wybraną podsieć, a dostęp spoza zaufanej sieci wymagał SSH lub Tailscale.

Taki układ wystarczył jednej osobie do eksperymentu. W firmie potrzebne są osobne tożsamości użytkowników, szyfrowanie całej trasy i kontrola skutków każdego działania. Wspólny klucz, HTTP w sieci lokalnej i terminal na laptopie nie spełniają tych wymagań.

Najpierw narysuj rzeczywisty 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. Hasło „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 obejmował

Tabela opisuje kierunek prac. Nie jest certyfikatem ani uniwersalną listą kontrolną. 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 dało się zmienić sekret, lecz trudno było ustalić, kto użył starego klucza i do jakiego procesu.

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

Unieważniony token powinien zwrócić 401, użytkownik bez roli powinien dostać 403, a log powinien pozwolić powiązać dozwolone żądanie z tożsamością bez zapisywania całego polecenia.

Scenariusz 2. Dokument zawiera instrukcję dla agenta

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

Sama instrukcja systemowa nie wystarczy. Wyszukiwarka sprawdza uprawnienia użytkownika przed pobraniem dokumentu. Treść zachowuje informację o pochodzeniu. Model może zaproponować działanie, lecz osobna usługa sprawdza format, tożsamość, zakres, reguły biznesowe i wymaganą akceptację. Narzędzie wysyłkowe nie przyjmuje dowolnego adresu z odpowiedzi modelu.

Złośliwy dokument nie może zmienić źródła odpowiedzi ani uruchomić połączenia sieciowego. Ten przypadek wykonaj w docelowym środowisku i zachowaj pełny wynik przed udostępnieniem agentowi dokumentów firmy.

Scenariusz 3. Agent ma terminal na laptopie

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

Wdrożenie firmowe powinno 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.

Próba odczytu pliku spoza udostępnionego katalogu powinna zakończyć się odmową. Tak samo powinny zakończyć się połączenie z niezatwierdzonym hostem, uruchomienie uprzywilejowanego procesu i zapis do chronionej gałęzi.

Scenariusz 4. Aktualizacja zewnętrznej poprawki serwera

Najlepszy profil domowego eksperymentu używał zamrożonego, zewnętrznie zmodyfikowanego vLLM 0.27.1. To istotne ryzyko łańcucha dostaw. Nie należy przedstawiać tego stosu jako oficjalnego, niezmodyfikowanego wydania vLLM.

Wspólne wytyczne CISA i partnerów obejmują twarde granice środowiska, listy dozwolonych połączeń, ochronę plików modelu i obrazów systemowych, monitoring oraz przygotowanie odtwarzania. W naszym profilu oznacza to skrót kryptograficzny obrazu i wag, zapis źródła poprawki, skan zależności, osobne środowisko aktualizacji oraz zestaw testów regresji przed skierowaniem ruchu.

Po zmianie obrazu to samo repozytorium testowe powinno przejść test funkcjonalny i bezpieczeństwa. Profil powinien zgłosić właściwy model oraz kontekst, a operator przywrócić poprzednią wersję bez ręcznego odtwarzania ustawień.

Scenariusz 5. Log staje się drugim wyciekiem

Pełny zapis zdarzeń agenta może zawierać polecenie użytkownika, kod, wynik działania narzędzia i ścieżki plików. Sam fakt prowadzenia audytu nie uzasadnia przechowywania wszystkich danych bez końca.

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 i węższym dostępem.

Sekret i dane oznaczone jako wrażliwe nie mogą pojawić się w panelu, eksporcie błędów ani odpowiedzi dla użytkownika. Uprawniony operator powinien móc odtworzyć sekwencję decyzji.

Pakiet potrzebny przed uruchomieniem

Przed bezpiecznym uruchomieniem firma powinna mieć:

• 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ń, wstrzykiwania polecenia, błędnego formatu danych i przerwanego żądania;
• panel stanu, alerty, rozwiązanie zapasowe i wynik ćwiczenia przywrócenia 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. W projekcie oznacza to właściciela, mapę 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.