Jak zbudować prywatną chmurę z użyciem serwera NAS i kontenera z AI do analizy danych

Po co prywatna chmura z AI zamiast „gotowego” rozwiązania?

Prywatność danych i pełna kontrola nad infrastrukturą

Prywatna chmura na serwerze NAS z warstwą AI to odpowiedź na dwa konkretne problemy: bezpieczeństwo danych i uzależnienie od zewnętrznych dostawców. Pliki firmowe, dokumentacja projektowa, skany faktur, umowy i notatki z badań to dane zbyt wrażliwe, aby bezrefleksyjnie wysyłać je do usług typu Google Drive, OneDrive czy publiczne API modeli AI. Zwłaszcza gdy te dane zawierają dane osobowe, informacje handlowe albo know-how, które realnie stanowi przewagę konkurencyjną.

Własny serwer NAS (Network Attached Storage – sieciowy magazyn danych) pozwala zbudować prywatną chmurę, w której to właściciel decyduje:

• gdzie fizycznie leżą dane (konkretny pokój, szafa, serwerownia),
• jak są szyfrowane i kto ma do nich dostęp,
• kiedy wykonywane są backupy,
• jaka warstwa AI ma do nich dostęp i co wolno jej robić.

Warstwa AI zintegrowana lokalnie z NAS-em dodatkowo eliminuje wysyłkę treści dokumentów do zewnętrznych API. Analiza tekstu, podsumowania, wyszukiwanie „po znaczeniu”, ekstrakcja danych z plików PDF odbywają się wewnątrz Twojej sieci. To istotne zarówno dla RODO, jak i dla spokoju psychicznego: nie wysyłasz tajemnic firmy na obce serwery, nie polegasz na zapisach w regulaminie o „anonimizacji” danych.

Scenariusze: dom, małe biuro, freelancer, zespół projektowy

Prywatna chmura z AI nie jest tylko dla dużych firm. Najczęściej sensownie wykorzystują ją cztery typy użytkowników:

1. Dom z wieloma urządzeniami. Zdjęcia z telefonów, dokumenty z pracy zdalnej, filmy z kamer monitoringu, skany ważnych dokumentów (akty, świadectwa, polisy). NAS pełni funkcję centralnego dysku z wersjonowaniem i dostępem z każdego urządzenia, a AI pomaga:

• opisywać zdjęcia i przypinać do nich tagi,
• wyszukiwać pliki „po treści” (np. znaleźć polisę po frazie „OC samochodu 2023”),
• tworzyć podsumowania długich PDF-ów, np. umów.

2. Małe biuro / mikro-firma. Typowy przypadek: 3–10 osób, brak własnego działu IT, a rosnąca ilość plików: oferty, umowy, protokoły, dokumentacja techniczna. Prywatna chmura z AI może:

• pełnić funkcję centralnego repozytorium dokumentów z wersjonowaniem,
• automatycznie indeksować PDF-y i prezentacje pod kątem wyszukiwania semantycznego,
• generować krótkie syntezy raportów dla zarządu.

3. Freelancer i indywidualny konsultant. Freelancer IT, grafik, architekt, prawnik czy doradca podatkowy przechowuje duże ilości plików klientów. Publiczna chmura oznacza wysyłkę prawnie wrażliwych danych na zewnątrz. NAS z AI daje:

• własny „notatnik AI”, który zna treść projektów, ofert, ustaleń,
• możliwość szybkiego generowania streszczeń umów, wymagań i zmian,
• dostęp przez HTTPS spoza biura bez budowania rozbudowanej infrastruktury.

4. Zespół projektowy / mały software house. Kod źródłowy trzymany w Git, ale dokumentacja, backlog, analizy – często jako pliki, notatki, PDF-y. NAS spina to całość, a AI:

• wyszukuje „po znaczeniu” fragmenty dokumentacji,
• tworzy podsumowania spotkań na podstawie notatek lub nagrań (po transkrypcji),
• pomaga budować własne narzędzia, np. chatbota wyszkolonego na dokumentach projektu.

Dlaczego sama przestrzeń dyskowa to za mało

Sam NAS z folderami to de facto „mądrzejszy dysk sieciowy”. Dopiero po dodaniu:

• usług typu prywatny dysk w chmurze (np. Synology Drive, QNAP Qsync),
• aplikacji webowych (galerie zdjęć, notatniki, wiki),
• kontenerów z AI udostępniających API

powstaje prawdziwa prywatna chmura, która:

• obsługuje użytkowników i uprawnienia jak SaaS,
• udostępnia dane i funkcje przez HTTPS,
• może być integrowana z innymi aplikacjami poprzez API.

Warstwa AI zamienia pasywny magazyn w aktywny system wiedzy. Plik PDF nie jest tylko binarnym obiektem leżącym w folderze, ale zasobem, który można:

• zindeksować (embeddingi wektorowe),
• przeszukać „po sensie”, a nie tylko po słowach kluczowych,
• streścić, skategoryzować, wyciągnąć kluczowe liczby i nazwy.

Wybór i przygotowanie sprzętu: NAS, dyski, sieć, ewentualne GPU

Parametry NAS: CPU, RAM, obsługa kontenerów

Pierwszy krok to dobór serwera NAS. Najprościej: wybierasz pudełko, wkładasz dyski, konfigurujesz system producenta. Kluczowe parametry z perspektywy prywatnej chmury z AI:

• CPU (procesor): ARM vs x86, liczba rdzeni, obecność jednostek wspomagających (AES-NI do szyfrowania).
• RAM: minimum 4 GB do komfortowego działania podstawowych usług, lepiej 8–16 GB, jeśli planujesz kontenery z AI.
• Obsługa Docker / kontenerów: oficjalna aplikacja kontenerowa (Synology Container Manager / dawniej Docker, QNAP Container Station, TrueNAS SCALE Kubernetes/Apps).

Synology i QNAP oferują zarówno modele z procesorami ARM (tańsze, energooszczędne, słabsze do AI), jak i x86 (Intel/AMD – mocniejsze, często z obsługą wirtualizacji i kontenerów). Dla lokalnej warstwy AI procesor x86 jest praktycznym wyborem: łatwiej uruchamiać gotowe obrazy kontenerów, a wydajność CPU jest po prostu wyższa.

Do analizy dokumentów (OCR, podstawowa wektorowa wyszukiwarka, lekkie LLM) sensownym minimum jest 4-rdzeniowy CPU i 8 GB RAM. Jeżeli planujesz większe modele LLM lub kilka usług AI równolegle, celuj w 6–8 rdzeni i 16 GB RAM. W przypadku NAS-ów z możliwością rozbudowy pamięci RAM łatwiej startować skromniej i później dołożyć moduł.

Dyski, RAID i konsekwencje dla wydajności

Serwer NAS to przede wszystkim dyski. Ich dobór wpływa jednocześnie na:

• pojemność,
• wydajność (przepustowość i IOPS),
• odporność na awarie.

Do prywatnej chmury z AI najczęściej używa się klasycznych dysków HDD (3.5") w konfiguracji RAID. AI nie wymaga ekstremalnej liczby operacji na sekundę – ważniejsza będzie przepustowość przy indexowaniu i backupach. Typowe konfiguracje:

• RAID 1 – lustrzane odbicie: 2 dyski, pojemność jednego, wysoka odporność na awarię jednego napędu, prosta konfiguracja.
• RAID 5 – minimum 3 dyski, pojemność N-1, kompromis pomiędzy bezpieczeństwem a wykorzystaniem przestrzeni, dobra wydajność przy odczycie.
• RAID 6 – minimum 4 dyski, pojemność N-2, większa odporność (awaria 2 dysków), kosztem pojemności.

Do scenariuszy domowych i mikro-firmowych RAID 1 lub RAID 5 będzie zazwyczaj optymalny. Dodatkowo wiele NAS-ów pozwala na użycie SSD jako cache (przyspieszenie odczytu/zapisu). Przy intensywnych operacjach AI na małych plikach (embeddingi, indeksy) warto umieścić same indeksy na SSD, a surowe dokumenty na HDD.

Równolegle trzeba pamiętać: RAID to nie backup. Ochrona przed awarią fizyczną dysku nie zastępuje kopii zapasowych na innym urządzeniu (drugi NAS, zewnętrzny dysk, chmura obca). Do tego wrócimy przy konfiguracji backupu i snapshotów.

Sieć: od gigabita do 2.5/10 GbE i porządne okablowanie

Warstwa sieciowa często jest niedoceniana. Jeśli klienci (laptopy, PC, telefony) mają wygodnie korzystać z prywatnej chmury, a AI ma w tle indeksować duże zbiory plików, potrzebna jest stabilna i szybka sieć LAN.

Minimalny sensowny poziom to:

• Gigabit Ethernet (1 GbE) między NAS a przełącznikiem/routerem,
• okablowanie kategorii co najmniej Cat5e/Cat6,
• przełącznik nie dławiący ruchu (nie starożytny 10/100 Mb).

Przy rosnącej ilości danych i kilku użytkownikach równolegle warto rozważyć:

• 2.5 GbE – coraz częściej spotykane w nowych routerach i laptopach, dobry kompromis prędkości i kosztu,
• 10 GbE – opłacalne przy dużych ilościach danych (np. wideo 4K, duże backupy VM, zespoły pracujące na ciężkich plikach graficznych).

Jeżeli NAS ma dwa porty gigabitowe, możesz skorzystać z agregacji łącza (LACP) – serwer ma wtedy większą przepustowość sumaryczną do wielu klientów, choć pojedyncze połączenie dalej będzie ograniczone do 1 Gb/s.

Czy potrzebne jest GPU do lokalnej AI?

Pytanie o GPU w NAS-ie wraca zawsze, gdy pojawia się temat lokalnych modeli AI. Odpowiedź: to zależy od typu zadań.

• Lekkie modele LLM (np. 3–7B parametrów, wersje quantized – 4-bit/8-bit) oraz indeksowanie tekstu (embeddingi, wektorowe bazy) często można wygodnie uruchomić na mocniejszym CPU x86 bez dedykowanego GPU.
• Średnie i duże modele LLM (13B+ parametrów), generacja obrazów (Stable Diffusion) czy masowa analiza materiału wideo zaczynają wymagać sensownej karty GPU – często o pamięci rzędu kilkunastu GB.

Wiele komercyjnych NAS-ów nie ma gniazd PCIe na pełnowymiarowe GPU albo mają bardzo ogranicloną listę wspieranych modeli kart. Dlatego rozsądnym wariantem jest:

• NAS jako magazyn i podstawowe usługi (chmura, backup, indeksowanie, wyszukiwanie),
• osobny serwer / stacja robocza z GPU, uruchamiana jako węzeł AI, korzystająca z danych przez NFS/SMB.

Takie podejście jest elastyczniejsze: NAS może być energooszczędny, działać 24/7, a mocny serwer GPU może być włączany tylko na czas cięższych zadań AI.

Hałas, pobór mocy i miejsce instalacji

Technicznie wszystko może działać na biurku obok monitora, ale w praktyce:

• dyski HDD generują hałas (szczególnie przy intensywnym indeksowaniu),
• wentylatory NAS-a zwiększają obroty przy wyższej temperaturze i obciążeniu,
• GPU (jeśli występuje) potrafi być bardzo głośne i ciepłe.

Dobrym miejscem na NAS jest:

• szafa teleinformatyczna w przedpokoju,
• garderoba z dobrą wentylacją,
• małe pomieszczenie gospodarcze.

Trzeba zapewnić dopływ chłodnego powietrza, unikać ciasnych zamkniętych szafek bez otworów wentylacyjnych i zadbać o stabilne zasilanie (przynajmniej prosty UPS). Pobór mocy 2–4-dyskowego NAS-a typowo mieści się w kilkudziesięciu watów, co przy całodobowej pracy ma już zauważalny wpływ na rachunek za energię, ale nadal jest to akceptowalne w porównaniu do ciągle włączonej stacji roboczej klasy PC.

System NAS jako baza prywatnej chmury: funkcje, które trzeba poznać

Kluczowe usługi: SMB/NFS, użytkownicy i uprawnienia

System operacyjny NAS-a (DSM w Synology, QTS/QTS hero w QNAP, TrueNAS, itp.) udostępnia kilka fundamentalnych mechanizmów:

• SMB/CIFS – standardowe udziały sieciowe dla Windows/macOS/Linux,
• NFS – wydajny protokół dostępu do plików, często używany do mountowania zasobów przez serwery i kontenery,
• FTP/SFTP – dostęp plikowy „po staremu”, przydatny czasem do integracji z urządzeniami zewnętrznymi,
• usługa katalogowa / integracja z LDAP/AD – centralne zarządzanie użytkownikami, grupami i uprawnieniami.

Proces konfiguracji zwykle wygląda podobnie, niezależnie od platformy. Tworzysz konta użytkowników (lub grupy, np. biuro, it, zarząd), potem udziały sieciowe (np. dane-firma, projekty, ai-indeksy) i przypisujesz im uprawnienia: od pełnego dostępu, przez tylko odczyt, po całkowity brak widoczności zasobu. Dobrą praktyką jest nadawanie uprawnień głównie grupom, a nie pojedynczym kontom – łatwiej wtedy dołączać nowych użytkowników lub zmieniać role.

Dla warstwy AI przydaje się separacja przestrzeni roboczych. Możesz stworzyć osobny udział na surowe dokumenty (tylko wybrane osoby z zapisem), osobny na wyniki analizy (raporty, eksporty) oraz wydzielony udział na dane techniczne AI (indeksy wektorowe, bazy metadanych). Ułatwia to kontrolę dostępu – serwis AI montuje tylko te zasoby, które są mu niezbędne, a użytkownicy „końcowi” nie muszą widzieć plików roboczych kontenerów.

Jeśli środowisko jest większe niż kilka osób, rozsądnie jest spięcie NAS-a z istniejącą usługą katalogową (AD/LDAP). Użytkownicy logują się wtedy wszędzie tym samym loginem i hasłem, a zmiana hasła lub zablokowanie konta w jednym miejscu natychmiast działa również na dostęp do chmury i zasobów dla AI. Z punktu widzenia bezpieczeństwa oraz audytu (kto co czytał/zmieniał) jest to dużo czytelniejsze niż lokalne konta rozsiane po kilku urządzeniach.

Kontenery i usługi AI na NAS-ie: praktyczny schemat

Większość współczesnych systemów NAS udostępnia własne GUI do zarządzania kontenerami: Synology Container Manager, QNAP Container Station, w TrueNAS SCALE – sekcję „Apps” opartą na Kubernetes/Helm. Mechanizm pod spodem jest podobny: pobierasz obraz z rejestru (Docker Hub, GHCR, własny registry), konfigurujesz sieć i wolumeny, uruchamiasz kontener jako usługę. Dla prostych wdrożeń nie ma potrzeby poznawania całego ekosystemu Kubernetes – pojedyncze kontenery lub lekkie docker-compose w zupełności wystarczą.

W efekcie NAS i kontener AI tworzą prywatny ekosystem, który z powodzeniem konkuruje funkcjonalnością z wieloma usługami chmurowymi, przy zachowaniu pełnej kontroli nad danymi. Jeśli interesuje Cię szerszy kontekst trendów, porównań i narzędzi, dobrze pasuje tu serwis Informatyka, Nowe technologie, AI, który zbiera praktyczne przykłady z różnych obszarów IT.

Realistyczna konfiguracja prywatnej chmury z AI może wyglądać tak:

• kontener z wektorową bazą danych (np. Qdrant, Milvus, Chroma) podpięty do udziału ai-indeksy,
• kontener z serwisem embeddingów (np. sentence-transformers, OpenAI-kompatybilne API typu text-embedding) korzystający z CPU lub lokalnego GPU,
• kontener LLM API (np. opary/llama.cpp, text-generation-webui, Ollama) obsługujący zapytania użytkowników,
• mały kontener „worker” skanujący udział z dokumentami (NFS/SMB) i zlecający kolejne zadania: OCR, ekstrakcję tekstu, generowanie embeddingów i aktualizację indeksu.

Taki układ modułowy ma kilka plusów. Można niezależnie aktualizować komponenty (np. wymienić model embeddingów bez ruszania LLM), a przy większym obciążeniu skalować tylko wybrany element – np. odpalić drugi kontener workerów od indeksowania lub dodatkową instancję LLM. Uwaga: na typowym NAS-ie limitem będzie RAM i liczba rdzeni, więc zbyt agresywna „mikroserwisyzacja” przynosi więcej szkody niż pożytku; lepiej zacząć od dwóch–trzech dobrze skonfigurowanych usług.

Przy mapowaniu wolumenów zwróć uwagę na rozdzielenie danych użytkownika od konfiguracji i logów kontenerów. Zazwyczaj robi się osobne katalogi typu /docker/appname/config, /docker/appname/data, /docker/appname/log, z przypisanymi limitami uprawnień. Dzięki temu aktualizacja obrazu lub podmiana całego stosu (np. nowa wersja wektorowej bazy) nie niszczy danych, a ewentualne awarie łatwiej diagnozować przez logi trzymane w jednym, przewidywalnym miejscu.

Przy usługach AI opartych na kontenerach istotna jest także polityka aktualizacji. Modele i biblioteki zmieniają się szybko, więc lepiej nie aktualizować wszystkiego „na żywca” na produkcyjnym NAS-ie. Prostym, ale skutecznym wzorcem jest klon konfiguracji w osobnym stacku testowym (inne porty, osobne katalogi /docker-test/...), sprawdzenie nowej wersji kontenera na ograniczonym zbiorze danych i dopiero później podmiana obrazu w środowisku głównym. Przy modelach LLM i embeddingów testuj nie tylko to, czy serwis „wstaje”, ale też jakość odpowiedzi i kompatybilność API – drobne zmiany nazw pól potrafią wyłożyć cały pipeline.

Dobrym usprawnieniem jest spójny schemat nazewnictwa kontenerów i sieci. Jeśli każdy element stosu ma przewidywalną nazwę (ai-llm, ai-embeddings, ai-vector-db, ai-worker), to konfiguracje klientów (np. aplikacja webowa, rozszerzenie przeglądarki, skrypt CLI) stają się prostsze i łatwiejsze do przeniesienia między maszynami. W środowiskach, gdzie NAS udostępnia wbudowany reverse proxy, sensownie jest wystawiać publicznie tylko jeden front (np. https://ai.twojadomena.local), a poszczególne usługi wiązać ścieżkami (/api/chat, /api/embed, /api/search) zamiast otwierać w sieci lokalnej kilka-kilkanaście portów.

Przy rosnącej liczbie usług pojawia się temat obserwowalności. Nawet na domowym lub małym firmowym NAS-ie przydaje się prosty monitoring: metriki zasobów (CPU, RAM, IO, sieć), logi kontenerów w jednym miejscu oraz krótkie alerty, gdy coś zużywa zasoby w sposób nietypowy. Czasem wystarczy wbudowany panel NAS-a z wykresami, czasem drobna instalacja stacku typu Prometheus + Grafana + Loki na osobnym, lekkim serwerze. Kluczowe jest, żeby w razie problemów (nagłe spowolnienie zapytań LLM, brak odpowiedzi od bazy wektorowej) dało się w kilka minut ustalić, czy winne są zasoby, sieć, czy może aktualizacja jednego z obrazów.

Kiedy wszystkie elementy zaczynają ze sobą współpracować – NAS jako magazyn danych, kontenery AI jako „warstwa inteligencji”, a sieć jako krwioobieg – pojawia się wrażenie, że prywatna chmura przestaje być tylko dyskiem sieciowym, a staje się małym, samowystarczalnym środowiskiem obliczeniowym. Od prostych backupów, przez współdzielone katalogi projektów, aż po lokalne modele analizujące firmowe dokumenty bez opuszczania Twojej sieci – ten sam zestaw klocków pozwala zbudować rozwiązanie dopasowane do konkretnego domu czy firmy, zamiast próbować naginać się do gotowej oferty zewnętrznych chmur.

Bezpieczeństwo, izolacja i kontrola dostępu do usług AI

Segmentacja sieci i dostęp tylko z zaufanych stref

Serwer NAS z usługami AI to już nie tylko „dysk w sieci”, ale ważny element infrastruktury. Jeśli obsługuje firmowe dokumenty, projekty czy dane klientów, odsłanianie go bezpośrednio do internetu jest proszeniem się o kłopoty. Rozsądny schemat to segmentacja sieci:

• oddzielna sieć LAN/VLAN dla serwerów (NAS, ewentualny serwer GPU),
• osobny segment dla zwykłych stacji roboczych i urządzeń mobilnych,
• strefa „gościnna” Wi-Fi bez dostępu do NAS-a i kontenerów.

Dostęp do API AI odbywa się wtedy przez wybrane porty na firewallu lub wbudowany reverse proxy NAS-a. Klient (np. wewnętrzna aplikacja webowa) może być wystawiony szerzej, ale komunikacja z zapleczem AI pozostaje w sieci serwerowej. Przy prostych topologiach wystarcza router z obsługą VLAN i regułami typu „użytkownicy mogą łączyć się na port 443 do NAS-a, brak innych połączeń przychodzących”.

Jeżeli modele mają być dostępne zdalnie (np. praca hybrydowa), bezpieczniejszym wariantem jest VPN. Domenowy VPN (OpenVPN/WireGuard na routerze lub NAS-ie) łączy użytkownika z siecią tak, jakby siedział biurko obok, więc nie trzeba otwierać na świat API LLM i wektorowej bazy. Równocześnie znikają problemy typu „zmienne IP w domu”, bo klient VPN rozwiązuje to za Ciebie.

Autoryzacja aplikacji i ograniczanie zakresu danych

Sama segmentacja sieci nie wystarczy, jeśli każde konto użytkownika widzi wszystkie dokumenty. Warstwa AI powinna dostawać tylko to, do czego użytkownik ma prawo. Można to rozwiązać na kilka sposobów.

• Filtr uprawnień po stronie workera – worker indeksujący dokumenty sprawdza ACL-e (listy kontroli dostępu) udziałów NAS-a i zapisuje przy każdym wektorze informację o tym, kto może dany fragment przeglądać (np. identyfikatory użytkowników/grup z AD). Przy zapytaniu użytkownika filtruje wyniki wyszukiwania semantycznego po jego tożsamości.
• Osobne indeksy na poziomie działów – prostsze warianty: ai-indeksy-biuro, ai-indeksy-zarzad, ai-indeksy-it. Frontend decyduje, z których indeksów może korzystać dany użytkownik (na bazie grup z AD/LDAP). Mniej elastyczne, ale łatwiejsze do ogarnięcia na starcie.

Przy aplikacjach korzystających z API AI warto stosować klucze lub tokeny. Nawet jeśli użytkownik działa w sieci lokalnej, generujesz dla klienta (aplikacja webowa, bot, plugin) klucz API, przypisujesz prawa (np. maksymalna liczba zapytań na minutę, dostępne kolekcje indeksu) i rotujesz te klucze przy zmianie konfiguracji. Przy małych instalacjach można użyć prostego mechanizmu z plikiem konfiguracyjnym JSON na NAS-ie, przy większych – dedykowanego serwisu autoryzacyjnego.

Szyfrowanie, hasła i tajne klucze w kontenerach

Dokumenty na NAS-ie często zawierają dane wrażliwe, więc naturalnym ruchem jest włączenie szyfrowania wolumenów lub folderów współdzielonych. W systemach typu DSM/TrueNAS można szyfrować całe zbiory danych (np. udział dane-firma) i zabezpieczać je hasłem lub kluczem sprzętowym. Serwis AI montuje wtedy już odszyfrowane zasoby, ale dane spoczywające na dyskach (at rest) są chronione.

Druga sprawa to klucze i hasła używane przez kontenery. Nie ma sensu wypychać ich wprost do zmiennych środowisk w pliku docker-compose.yml trzymanym w git bez kontroli dostępu. Lepsze warianty:

• sekrety Dockera/Kubernetes (w TrueNAS SCALE – „Secrets”) z ograniczonym dostępem,
• szyfrowane pliki konfiguracyjne .env, do których ma dostęp tylko uprzywilejowany admin NAS-a,
• integracja z zewnętrznym sejfem tajemnic (Vault, Bitwarden Secrets Manager), jeśli infrastruktura już taki komponent posiada.

Uwaga: w środowisku z prywatną chmurą AI często pojawia się pokusa, żeby „na chwilę” wpiąć klucz do zewnętrznego API (np. chmurowego modelu) do pliku konfiguracyjnego na udziale współdzielonym. Ktoś kopiując konfigurację do innego projektu często nieświadomie publikuje go dalej. Dobrą praktyką jest osobny udział tylko do konfiguracji systemowej, z dostępem dla ograniczonej grupy administratorów.

Pipeline przetwarzania dokumentów: od pliku do wiedzy

Etap 1: Ingest i klasyfikacja źródeł

Żeby AI na NAS-ie miała sens, musi mieć z czym pracować. Źródłem są najczęściej:

• udziały plikowe z dokumentami (SMB/NFS),
• skany z urządzeń wielofunkcyjnych (MFP) zapisujące pliki PDF na NAS-ie,
• eksporty z systemów biznesowych (CSV, XLSX, JSON),
• archiwa poczty (EML, mbox) lub pliki z backupów.

Worker odpowiedzialny za ingest monitoruje katalogi źródłowe (inotify/fanotify w Linuksie, harmonogram odpytywania, API NAS-a) i zapisuje metadane każdego nowego pliku: ścieżkę, właściciela, datę, potencjalny typ (umowa, faktura, raport). Ta klasyfikacja może być prosta (regexy po nazwach, typ MIME) albo bardziej inteligentna – mini-model klasyfikacyjny w kontenerze, który po krótkim skanie tekstu przypisuje kategorie.

Tip: przy wielu źródłach rozsądnie jest stworzyć katalog „buforowy” typu /ai-inbox/, do którego kopiowane są dokumenty do indeksacji. Zmniejsza to ryzyko wyścigów (plik jeszcze się kopiuje, a worker już próbuje go czytać) i pozwala na ew. walidację (np. odrzucenie plików ponad ustalony rozmiar).

Etap 2: OCR i ekstrakcja tekstu

Wszelkie skany (PDF, obrazki TIFF/JPEG/PNG) wymagają OCR (rozpoznawania tekstu). Na NAS-ie zwykle sprawdza się:

• Tesseract w kontenerze – otwarte rozwiązanie, sensowne przy dokumentach w kilku językach,
• zamknięte biblioteki OCR, jeśli licencja i budżet na to pozwalają (często lepiej radzą sobie z „trudnymi” skanami).

Worker w kontenerze pobiera plik, uruchamia OCR, generuje:

• pełny tekst (np. plik .txt lub JSON),
• metadane pozycyjne (koordynaty bloków tekstu) – przydatne, jeśli chcesz w przyszłości wizualizować wyniki na oryginalnym skanie.

Znane formaty biurowe (DOCX, PPTX, XLSX, PDF tekstowy) można rozpakować i wyczyścić przy pomocy bibliotek typu Apache Tika lub textract. W praktyce dobrze sprawdzają się lekkie, jednofunkcyjne kontenery: jeden do OCR, drugi do ekstrakcji tekstu z dokumentów „cyfrowych”. Worker steruje całością przez kolejkę (np. RabbitMQ, Redis, prosty katalog „do zrobienia”/„zrobione”).

Etap 3: Chunkowanie i generowanie embeddingów

Modele wektorowe pracują na fragmentach tekstu (tzw. chunkach). Cały 100-stronicowy raport podany „w jednym kawałku” jest nie tylko nieefektywny, ale ograniczony rozmiarem kontekstu modelu. Typowy pipeline:

1. Podział tekstu na akapity lub sekcje (nagłówki, listy, tabele).
2. Łączenie krótszych akapitów w większe bloki o zadanej długości znaków/tokenów (np. 500–1000 tokenów), z niewielką zakładką (overlap), żeby uniknąć „cięcia w połowie myśli”.
3. Dla każdego chunka wywołanie API embeddingów i zapisanie wektora oraz metadanych (ID dokumentu, pozycja, typ).

Kontener embeddingów może być bardzo prosty: model sentence-transformers uruchomiony w trybie serwera (FastAPI/uvicorn), który na wejściu przyjmuje listę tekstów, a na wyjściu oddaje macierz wektorów. Jeśli NAS ma GPU (QNAP/Synology z PCIe lub TrueNAS na własnym sprzęcie), modele potrafią liczyć embeddingi kilkukrotnie szybciej. W mniejszych środowiskach CPU zwykle też daje radę, tylko pipeline musi działać bardziej w tle.

Etap 4: Indeksacja w bazie wektorowej i metadane

Wektorowa baza danych (Qdrant, Milvus, Chroma) przechowuje embeddingi w kolekcjach. Sensowny schemat:

• jedna kolekcja na typ dokumentów (np. umowy, procedury, projekty),
• jedno globalne pole na identyfikator dokumentu (np. hash ścieżki),
• pole z informacją o uprawnieniach (ID grup/rol z AD),
• dodatkowe tagi: język, data, autor, dział.

Worker po otrzymaniu wektorów zapisuje każdy chunk jako osobny rekord w kolekcji. Kluczowa jest spójność identyfikatorów – jeśli dokument zostaje zaktualizowany lub usunięty, trzeba umieć znaleźć i wyczyścić odpowiadające rekordy. Najprościej nadać każdemu dokumentowi stabilny document_id (np. hash pliku + ścieżka) i wszystkie chunki wiązać tym ID. Aktualizacja to:

1. oznaczenie starych rekordów z tym document_id jako nieaktywne lub ich usunięcie,
2. ponowne przetworzenie dokumentu i zapis nowych chunków.

Przy większej liczbie dokumentów przydaje się osobna baza metadanych (PostgreSQL/SQLite) powiązana z indeksem wektorowym. Trzymasz tam informacje o wersjach dokumentów, log przetworzeń (kiedy ostatnio robiłeś OCR/embedding) i mapowanie na fizyczną ścieżkę na NAS-ie.

Etap 5: Wyszukiwanie hybrydowe i RAG

Samo podobieństwo semantyczne to nie wszystko. Wyszukiwanie hybrydowe łączy:

• klasyczne kryteria (frazy, filtry po metadanych: data, autor, typ dokumentu),
• zapytanie wektorowe (embedding pytania użytkownika).

Standardowy schemat: frontend wysyła pytanie i ew. filtry (np. „pokaż tylko dokumenty działu sprzedaży z ostatniego kwartału”), serwis pośredni tworzy embedding pytania, odpyta bazę wektorową z filtrami po metadanych i uprawnieniach, a wyniki (kilka–kilkanaście chunków) przekazuje do LLM jako kontekst. To właśnie jest RAG (Retrieval-Augmented Generation) – model generujący nie „wymyśla” odpowiedzi z powietrza, tylko opiera się na znalezionych fragmentach dokumentów.

W praktyce dobrze działa ograniczenie liczby chunków przekazywanych do LLM oraz agresywne filtrowanie po uprawnieniach. Zamiast brać wszystko, co ma wysoki wynik podobieństwa, można zastosować np. regułę: „maksymalnie 3 dokumenty źródłowe, z każdego po 2–3 chunki” i sortowanie po dacie/priorytecie. W firmowych scenariuszach ważniejsze jest, żeby odpowiedź była łatwa do prześledzenia (z linkami do źródeł) niż maksymalnie „sprytna”.

Interfejsy dla użytkowników: jak udostępnić AI bez chaosu

Panel webowy na NAS-ie lub osobnym kontenerze

Najwygodniejszą formą korzystania z prywatnej chmury z AI jest lekka aplikacja webowa. Można ją uruchomić jako dodatkowy kontener z backendem (Node.js/Python/Go) i frontendem (React/Vue/Svelte albo proste HTML+JS) i wystawić przez wbudowany reverse proxy NAS-a jako https://ai.twoja-domena.local.

Backend pełni kilka ról:

• pośredniczy w rozmowie z LLM (RAG) – pobiera dokumenty z bazy wektorowej, skleja kontekst, wysyła zapytanie do kontenera LLM,
• sprawdza uprawnienia użytkownika (integracja z NAS/AD, tokeny JWT),
• loguje zapytania i odpowiedzi (z zachowaniem polityki prywatności) na potrzeby audytu i debugowania.

Przy konfiguracji reverse proxy warto korzystać z TLS (certyfikat z Let’s Encrypt lub wewnętrznego CA) i wymagać logowania przed dopuszczeniem do panelu. Na domowym NAS-ie często wygodnie jest użyć SSO (Single Sign-On) – użytkownik zalogowany do DSM/portalu NAS ma od razu sesję w aplikacji AI.

Integracje: rozszerzenia przeglądarki, pluginy do edytorów

Dla części użytkowników panel webowy to za dużo klikania. Ciekawą opcją jest prosty plugin do przeglądarki, który:

• wysyła zaznaczony tekst lub aktualną stronę jako kontekst do API na NAS-ie,
• odbiera odpowiedź LLM i wstrzykuje ją obok treści,
• identyfikuje użytkownika na podstawie tokenu wygenerowanego w panelu AI.

Podobnie można zintegrować prywatną chmurę z edytorem (VS Code, Office/LibreOffice): dodatki wywołujące lokalne API z tekstem aktualnego dokumentu lub fragmentem kodu. Dzięki temu użytkownik pracuje w znajomym narzędziu, a AI tylko „podpowiada” lub streszcza fragmenty dokumentów, nie wyciągając danych poza Twoją sieć.

Integracja z komunikatorami i narzędziami zespołowymi

Jeśli w firmie dominują komunikatory (Slack, Mattermost, Microsoft Teams), sensowne jest wystawienie bota, który spina się z Twoim API na NAS-ie. Użytkownik pisze na kanale „@asystent znajdź ostatnią procedurę awaryjnego restartu CRM”, bot przekłada to na zapytanie RAG, odpytuje lokalny LLM i odsyła streszczenie z linkami do konkretnych dokumentów na NAS-ie. Z punktu widzenia bezpieczeństwa nic nie wychodzi poza sieć – komunikator gada z prywatnym API, a nie z chmurą publiczną.

Bota można zbudować jako osobny kontener z małym webhookiem: komunikator wywołuje URL na NAS-ie, przekazuje treść wiadomości i identyfikator autora, kontener sprawdza uprawnienia, robi zapytanie do bazy wektorowej, woła kontener LLM i generuje odpowiedź. Integracja z AD/LDAP pozwala od razu mapować użytkowników z komunikatora na ich role w systemie plików NAS, co upraszcza kontrolę dostępu do dokumentów. Dobrą praktyką jest blokowanie komend typu „podsumuj wszystko” i wymuszanie wąskich, filtrowanych zapytań (np. tylko dany projekt lub dział).

Analogiczny schemat sprawdza się w narzędziach do zarządzania zadaniami (Jira, Redmine, GitLab Issues). Prostą wtyczką można dodać przycisk „zapytaj AI o kontekst zgłoszenia”, który wyśle opis ticketa, odnajdzie powiązane dokumenty projektowe na NAS-ie i złoży z nich zwięzłe streszczenie. Dla zespołów technicznych bardzo wygodne jest też przeszukiwanie logów i dokumentacji serwisowej bezpośrednio z interfejsu ticketów, bez ręcznego grzebania po udziałach sieciowych.

Bezpieczeństwo, prywatność i segmentacja dostępu

Model zaufania: co może wyciec i gdzie

Prywatna chmura z AI nie ma sensu, jeśli krytyczne dane mogą wypłynąć na zewnątrz przez nieprzemyślaną integrację. Każdy komponent powinien mieć zdefiniowany model zaufania:

• kontener LLM – nie łączy się samodzielnie z Internetem, przyjmuje wyłącznie żądania z sieci lokalnej/VPN,
• kontener RAG/backend – wie o uprawnieniach użytkownika, ale nie ma dostępu do całego systemu plików NAS (tylko do API indeksu i ograniczonych zasobów),
• worker przetwarzający dokumenty – widzi udziały sieciowe, ale nie udostępnia żadnego publicznego API,
• baza wektorowa – stoi za firewallem, nasłuchuje tylko na prywatnym interfejsie lub sieci dockerowej.

Całość dobrze jest narysować w postaci prostego diagramu sieci (nawet na kartce) i zaznaczyć, które porty są otwarte na LAN, a które tylko wewnątrz klastra kontenerów. W środowiskach produkcyjnych dobry efekt przynosi podsieć tylko dla „warstwy AI” i ruch do niej przepuszczany wyłącznie przez reverse proxy.

Mapowanie uprawnień plików na uprawnienia w RAG

Największy zgrzyt powstaje zwykle przy pytaniu: „co, jeśli użytkownik nie ma prawa otworzyć danego pliku na NAS-ie, ale AI mogłaby go użyć do odpowiedzi?”. Technicznie AI może mieć szerszy wgląd, ale biznesowo i prawnie to droga do kłopotów. Bezpieczna zasada:

• model może korzystać tylko z tych dokumentów, do których użytkownik miałby normalnie dostęp przez SMB/NFS/WebDAV,
• worker indeksujący dokumenty pobiera listę ACL (uprawnień) i zapisuje ją razem z metadanymi chunka,
• baza wektorowa filtruje wyniki po identyfikatorach grup/rol użytkownika.

Przykład: dokument na udziale NASHRUmowy dostępny tylko dla grupy HR. Worker przy indeksacji wyciąga z NAS/AD listę SID-ów/ID grup i zapisuje je w polu allowed_groups. Przy wyszukiwaniu backend przekazuje do indeksu wektorowego listę grup zalogowanego użytkownika – rekordy bez przecięcia zbiorów są odrzucane jeszcze przed etapem liczenia podobieństwa.

Tip: jeżeli NAS nie udostępnia wygodnego API do ACL, można okresowo zrzucać je skryptem (PowerShell/bash) do pliku JSON/CSV i ładować do bazy metadanych. Ważne, żeby proces nie był jednorazowy – po zmianach uprawnień trzeba ponownie zsynchronizować mapę.

Izolacja kontenerów i minimalne uprawnienia

Kontenery dla AI kuszą, żeby dawać im pełny dostęp do hosta („bo będzie łatwiej debugować”). To prosta droga do sytuacji, w której wyciek z jednego serwisu oznacza wgląd w cały NAS. Zamiast tego:

• uruchamiaj kontenery z użytkownikiem nieuprzywilejowanym (bez root w środku),
• montuj tylko te katalogi, które są niezbędne (np. /data/queue zamiast całego /volume1),
• stosuj sieci dockerowe zamiast wystawiania każdego serwisu na port hosta,
• włącz ograniczenia zasobów (CPU/memory) – atakujący nie zablokuje całego NAS-u jednym kontenerem.

Uwaga: na NAS-ach z gotowymi pakietami Dockera często domyślna konfiguracja jest bardzo liberalna. Warto ręcznie przejrzeć pliki docker-compose.yml i aplikacje z GUI producenta – szczególnie opcje typu „pełny dostęp do /dev” i „przywilejowany kontener”.

Monitoring, logowanie i utrzymanie środowiska AI

Co logować, żeby mieć kontrolę, a nie inwigilację

Logi będą Twoim głównym narzędziem przy debugowaniu i audycie, ale łatwo nimi przesadzić. Sensowny kompromis:

• w kontenerze LLM – czas odpowiedzi, długość promptu/odpowiedzi, podstawowe metryki (zużycie pamięci, liczba równoległych zapytań),
• w backendzie RAG – identyfikator użytkownika, timestamp, słowa kluczowe zapytania (np. po prostym stemmingu), ID użytych dokumentów źródłowych,
• w workerach – czas przetwarzania dokumentu, błędy OCR, stan kolejki.

Treści pytań i pełnych odpowiedzi lepiej nie przechowywać długoterminowo – szczególnie w firmach z wrażliwymi danymi. Pomaga hashowanie fragmentów (np. zapytań) lub krótkie okna retencji (kilka dni) tylko na potrzeby debugowania.

Prosty monitoring zasobów na NAS-ie

NAS jako baza pod AI łatwo „zadławić” – indeksowanie tysięcy dokumentów i jednoczesne zapytania do LLM potrafią zjeść CPU i RAM. Minimalny zestaw:

• monitor CPU/RAM/dysku NAS-a (wbudowane narzędzia QNAP/Synology/TrueNAS),
• metryki z kontenerów (docker stats, cAdvisor/Prometheus + prosty dashboard w Grafanie),
• alarmy przy zapełnieniu przestrzeni dyskowej powyżej określonego progu.

Praktyczny trik: w godzinach szczytu (np. 9–15) ogranicz liczbę workerów indeksujących, żeby nie walczyły o IOPS z użytkownikami NAS-a. W nocy lub w weekendy możesz zwiększyć równoległość przetwarzania i „nadgonić” kolejkę.

Strategia aktualizacji modeli i kontenerów

Modele i biblioteki ML starzeją się szybciej niż typowe oprogramowanie serwerowe. Żeby nie wpaść w paraliż aktualizacyjny:

• buduj własne obrazy bazowe (Dockerfile) dla LLM/embeddingów zamiast używać „latest” z losowych repozytoriów,
• oznaczaj wersje modeli w konfiguracji (np. embedding_model=v1.2 w bazie metadanych),
• testuj nowe wersje w osobnej przestrzeni indeksu (np. umowy_v2) równolegle ze starą,
• przełącz frontend na nowy indeks dopiero po krótkim okresie porównawczym.

Przy większych zmianach architektury modelu dobrze jest zaplanować pełne przeliczenie embeddingów. To czasochłonne, ale mieszanie wektorów z różnych modeli w jednej kolekcji kończy się zwykle chaotycznymi wynikami wyszukiwania.

Skalowanie: od domowego NAS-a do małego klastra

Jak rozdzielić role między kilka maszyn

Gdy jeden NAS przestaje wystarczać, najprostsze skalowanie poziome polega na rozdzieleniu ról:

• NAS A – główne udziały plików, kolejka zadań, logi,
• NAS/serwer B – kontenery OCR/ekstrakcji tekstu i workerów,
• serwer C (najlepiej z GPU) – kontenery LLM i embeddingów, baza wektorowa.

Komunikacja między maszynami idzie po prywatnej podsieci (VLAN) lub tunelu VPN site-to-site. Kluczowe, by ruchem zarządzać w jednym miejscu – np. przez frontowe reverse proxy (nginx/Traefik) na NAS-ie A, które wystawia tylko kilka endpointów do sieci firmowej, cała reszta dzieje się „za nim”.

Skalowanie kolejki i workerów

Przetwarzanie dokumentów jest naturalnie asynchroniczne, więc świetnie skaluje się przez zwiększanie liczby workerów. Typowy wzorzec:

1. Endpoint HTTP na backendzie wrzuca ścieżkę pliku i metadane do kolejki (Redis/RabbitMQ/SQLite+folder).
2. Jeden lub więcej workerów OCR/ekstrakcji konsumentuje zadania i zapisuje „czysty” tekst.
3. Kolejny zestaw workerów chunkuje tekst i wysyła batchowo do embeddingów.
4. Worker indeksujący zapisuje wektory do bazy wektorowej.

Wąskim gardłem bywa zwykle OCR i embeddingi. Jeśli LLM ma GPU, można rozbić kontenery: jeden serwis na GPU dla embeddingów, drugi CPU-only do samego generowania odpowiedzi (o ile model na to pozwala) – albo odwrotnie, w zależności od profilu użycia.

Drugie życie dla starszego sprzętu

Domowe/pracownicze „graty” (stare desktopowe i5/i7, miniPC) świetnie nadają się na nody workerów. Wystarczy zainstalować lekkie Linuxy, dołączyć do prywatnego VPN lub VLAN-u i uruchomić na nich:

• kontenery OCR/ekstrakcji,
• proste worker-scripty do chunkowania i wysyłania do głównej bazy wektorowej na NAS-ie.

Taki węzeł nie musi trzymać żadnych danych „na stałe” – po zakończeniu przetwarzania wszystko ląduje na centralnym NAS-ie. W razie awarii po prostu znika trochę mocy obliczeniowej, ale system jako całość działa dalej.

Wybór i hosting modeli AI w środowisku prywatnym

Modele LLM: lekkie, średnie, cięższe

Na prywatnym sprzęcie przydają się raczej modele oszczędne niż „największe możliwe”. Przykładowy podział:

Jeśli interesują Cię konkrety i przykłady, rzuć okiem na: NAS czy chmura? Porównanie kosztów i bezpieczeństwa kopii zapasowych.

• lekkie (1–4 GB VRAM / kilka GB RAM) – do prostych podpowiedzi, krótkich streszczeń, integracji z edytorami; często w wersjach quantized (4-bit/8-bit);
• średnie (6–12 GB VRAM) – główny koń pociągowy do RAG, analizy dokumentów, krótkich konsultacji „eksperckich”,
• cięższe (16 GB+ VRAM) – tylko jeśli masz mocny GPU i chcesz robić bardziej złożone wnioskowanie, generację kodu itp.

Jeśli NAS nie ma GPU, pozostaje CPU lub mały serwer obok. Warto wtedy używać modeli zoptymalizowanych pod CPU (np. z backendem GGUF/llama.cpp) i ograniczyć długość kontekstu. Przy RAG część „inteligencji” zapewnia sama baza wiedzy, więc nie trzeba gonić za najwyższą liczbą parametrów.

Modele embeddingów dostosowane do języka i domeny

Embeddingi to fundament wyszukiwania, dlatego opłaca się wybrać model, który:

• dobrze radzi sobie z polskim i innymi używanymi językami,
• jest trenowany lub tunowany pod zadania semantycznego wyszukiwania (niekoniecznie klasyfikacji),
• pozwala na wygodną batchową inferencję (przetwarzanie wielu chunków naraz).

Praktyczny kompromis: mniejszy model embeddingów (szybszy, mniej pamięciożerny) + nieco bardziej rozbudowanie warstwy logiki w backendzie (np. reranking, kilka zapytań per pytanie użytkownika). Daje to bardziej elastyczne strojenie jakości niż ślepe zwiększanie rozmiaru modelu.

Separacja modeli: osobne kontenery, osobne zasoby

Modele LLM, embeddingów i ewentualne modele specjalistyczne (np. klasyfikacja rodzaju dokumentu) dobrze jest trzymać w osobnych kontenerach/API:

• łatwiejsza wymiana pojedynczego modelu bez tykania reszty,
• możliwość przydziału różnych zasobów (np. embeddingi na GPU, klasyfikacja na CPU),
• prostsze pilnowanie, jakie dane trafiają do którego modelu.

Warstwa orkiestrowania (backend RAG) łączy to w całość: najpierw klasyfikacja lub normalizacja pytania, potem wyszukiwanie wektorowe, a na końcu LLM do generacji odpowiedzi.

Typowe problemy i pułapki przy wdrażaniu prywatnej chmury AI

„Halucynacje” mimo RAG i jak je ograniczać

Nawet lokalny model, karmiony dobrym kontekstem, potrafi „dopowiadać” fakty. Z technicznej strony dobrze działają:

• prompty wymuszające cytowanie źródeł (np. „odpowiedz tylko, jeśli potrafisz wskazać fragmenty dokumentów; inaczej napisz, że brak danych”),
• post-processing po stronie backendu – jeśli model nie podał żadnych referencji do dokumentów, odpowiedź można zakwalifikować jako niepewną i oznaczyć wizualnie w UI,
• surowsze filtrowanie wyników wyszukiwania (lepiej 3 bardzo trafne chunki niż 15 luźno powiązanych).

Dobrym nawykiem jest też dodawanie przycisku „pokaż tylko dokumenty”, który zamiast generowania odpowiedzi wyświetli same znalezione fragmenty. Użytkownicy szybko uczą się „czuć”, kiedy zaufać automatycznemu streszczeniu, a kiedy wejść głębiej w materiały źródłowe.

Bałagan w dokumentach = bałagan w wynikach

Jeżeli udziały NAS-a przypominają „szufladę wszystkiego”, AI jedynie to uwidoczni. Kilka prostych reguł porządku:

• jasne drzewo katalogów odzwierciedlające strukturę firmy/projektów,
• konsekwentne nazewnictwo plików (prefiksy typu 2024-03-, kody projektów),
• oznaczanie wersji dokumentów (w samej treści i w nazwie pliku, np. _v3),
• oddzielne miejsca na „śmietnik” (szkice, materiały robocze) nieindeksowane przez AI.

• uzgodnione tagowanie (np. [KLIENT_X], [OFERTA], [UMOWA] w nazwach lub metadanych), co bardzo ułatwia filtrowanie po stronie RAG.

Dobrze działa też prosty „bufor akceptacji”: nowo wrzucone pliki lądują najpierw w katalogu roboczym, który indeksuje się osobno. Ktoś z zespołu co jakiś czas przerzuca dopiero zweryfikowane dokumenty do „właściwego” drzewa, które bierze udział w głównym wyszukiwaniu. Unika się w ten sposób sytuacji, w której jednorazowy zrzut śmieci z pendrive’a zatruwa indeks produkcyjny na wiele miesięcy.

Kiedy środowisko zaczyna rosnąć, przydaje się automatyzacja porządków. Prosty skrypt lub kontener „sprzątający” może:

• przenosić stare wersje plików do archiwum (na podstawie sufiksów _old, _vX i dat modyfikacji),
• oznaczać katalogi z materiałami tymczasowymi metadanymi noindex, których backend użyje do wykluczenia z RAG,
• wykrywać duplikaty po hashach i zgłaszać listę kandydatów do ręcznego scalenia.

W praktyce nawet taki półautomatyczny „zarządca bałaganu” szybko zwraca się czasem zespołu – mniej losowych plików w indeksie oznacza stabilniejsze odpowiedzi modelu i mniejszą liczbę „dziwnych” podpowiedzi, których źródła nikt nie potrafi później odnaleźć.

Bezpieczeństwo, prywatność i kontrola dostępu w prywatnej chmurze AI

Model zaufania: kto widzi jakie dane i jak przez AI

Przy wdrażaniu RAG-a w firmie problemem nie jest tylko „czy ktoś ma dostęp do folderu”, ale też:

• czy AI może pośrednio ujawnić komuś treści, do których formalnie nie ma praw,
• czy backend prawidłowo filtruje kontekst pod kątem uprawnień użytkownika,
• co zostaje w logach i cache’u po zakończeniu rozmowy.

Najprostszy i zwykle wystarczający model to „RAG honoruje ACL-e z NAS-a”. Czyli: jeśli użytkownik nie ma prawa odczytu danego udziału/katalogu, to:

• ani wyszukiwarka wektorowa nie powinna z tego zbioru zwracać wyników,
• ani LLM nie może dostać chunków pochodzących z tych dokumentów.

Technicznie sprowadza się to do tego, że każdy dokument w indeksie ma przypisane:

• ścieżkę na NAS-ie lub identyfikator zasobu,
• listę grup/rolę uprawnień (np. z LDAP/AD lub prostego mapowania z NAS-a),
• opcjonalnie „tag widoczności” (np. private_hr, board_only).

Przy każdym zapytaniu RAG backend pobiera profil użytkownika (ID, role, grupy) i przekazuje to do warstwy wyszukiwarki wektorowej jako filtr. W praktyce: „daj mi 10 najbliższych wektorów, ale tylko z dokumentów oznaczonych jako widoczne dla roli X lub grup Y/Z”.

Synchronizacja uprawnień z NAS-em

Z czasem ACL-e na NAS-ie będą się zmieniać: ktoś dochodzi do zespołu, ktoś odchodzi, katalog z ofertami zostaje zamknięty dla części użytkowników. Wyszukiwarka i RAG muszą za tym nadążyć, inaczej dojdzie do rozjazdu między tym, co widać w eksploratorze plików, a tym, co „podpowiada AI”.

Typowy mechanizm synchronizacji:

1. Indekser dokumentów co jakiś czas (lub przy zmianie) pyta NAS-a / AD o aktualne uprawnienia do danej ścieżki.
2. Dla każdego dokumentu aktualizuje pola: grupy/role, flagi widoczności.
3. Jeżeli dokument został przestawiony na „tylko dla wąskiej grupy”, indeks nie usuwa go globalnie – zmienia wyłącznie jego listę uprawnionych.

Uwaga: unikanie pełnego przeliczenia indeksu przy każdej zmianie ACL-a jest kluczowe. Lepiej trzymać uprawnienia w osobnej tabeli/kolumnie i aktualizować je inkrementalnie. Przy większej liczbie dokumentów oszczędza to nocne okna utrzymaniowe.

Izolacja ruchu sieciowego i ograniczenie powierzchni ataku

NAS i serwery AI zazwyczaj stoją głęboko w sieci wewnętrznej. Problem zaczyna się tam, gdzie trzeba „dokroić” im dostęp z laptopów zdalnych pracowników, fili czy partnerów. Kilka praktycznych warstw obrony:

• dedykowany VLAN lub podsieć dla serwerów AI, do której nie ma bezpośredniego routingu z sieci gościnnej / Wi-Fi,
• VPN z granularnymi regułami (np. WireGuard/OpenVPN) – użytkownik widzi tylko reverse proxy i ewentualnie udział SMB, nie pełną podsieć,
• firewall sprzętowy lub na routerze domowym/firmowym, który blokuje ruch „w bok” (lateral movement) między maszynami.

Dobrą praktyką jest też przypisanie osobnych kont usługowych dla:

• indeksera i workerów OCR,
• backendu RAG,
• warstwy UI/API.

Każde konto ma tylko takie prawa, jakich potrzebuje: indeksowanie odczytuje katalogi, ale nie kasuje plików, UI nie ma dostępu do surowych udziałów, a LLM API widzi wyłącznie ruch HTTP z backendu. Kiedy któryś element zostanie skompromitowany, atakujący nie przechodzi od razu na pełny dostęp do danych.

Szyfrowanie danych w spoczynku i w ruchu

Jeżeli NAS trzyma dane wrażliwe (umowy, wyniki badań, dane klientów), sens ma:

• szyfrowanie wolumenów dyskowych na poziomie NAS-a (np. LUKS/eCryptfs w tle, zależnie od producenta),
• przymusowe TLS dla wszystkich połączeń HTTP/WS między frontendem, backendem i serwisami AI,
• uniknięcie gołego NFS/SMB w sieciach „niezaufanych” (VPN, szyfrowanie transportu).

Przy lokalnych klastrach często kusi, by odpuścić TLS „bo to przecież tylko LAN”. Do czasu, aż ktoś wpięty w „zły” port switcha zacznie podsłuchiwać ruch. Warto wówczas przynajmniej odseparować ruch z serwerów AI na osobny VLAN i używać stałych, weryfikowanych certyfikatów (może być własne CA z krótkim okresem ważności).

Monitorowanie, logowanie i obserwowalność prywatnej chmury AI

Minimalny zestaw metryk, który ratuje skórę

Gdy system się rozrasta, zgłoszenia „AI dziś działa wolniej” zaczną się pojawiać częściej niż „AI nie działa wcale”. Bez metryk trudno stwierdzić, czy winny jest:

• przeciążony NAS (IOPS/latencja),
• brak RAM-u lub swap na węźle z embeddingami,
• kolejka zadań, która zaczęła rosnąć bez końca.

Sensowne minimum:

• CPU, RAM, dysk (IOPS/latency) dla NAS-a i wszystkich serwerów workerów,
• długość kolejek (OCR, embeddingi, indeksowanie),
• średni czas odpowiedzi LLM i wyszukiwarki wektorowej,
• liczba błędów 5xx w backendzie RAG.

Do tego wystarczy prosty stack typu Prometheus + Grafana, uruchomiony nawet na tym samym NAS-ie (w osobnych kontenerach). Każdy węzeł dostaje małego eksportera (node_exporter), a kolejki i backendy wystawiają swoje metryki na HTTP.

Logi aplikacyjne i „czarne skrzynki” zapytań

Poza metrykami potrzebne są logi, które pozwolą odpowiedzieć na dwa pytania:

1. Dlaczego to zapytanie było wolne lub zwróciło błąd?
2. Dlaczego model udzielił takiej, a nie innej odpowiedzi?

W praktyce backend RAG może logować dla każdego zapytania:

• ID użytkownika lub pseudonim (anonimizowany, jeśli polityka prywatności tego wymaga),
• treść pytania w formie zredukowanej (np. zhashowane + kilka pierwszych słów) – tak, by dało się rozpoznać typ problemu, ale nie pełne dane,
• listę dokumentów/chunków użytych jako kontekst (ID, ścieżki, score podobieństwa),
• czas poszczególnych etapów: wyszukiwanie, reranking, wywołanie LLM, post-processing.

Tip: przy debugowaniu „dziwnych” odpowiedzi pomocne jest chwilowe uruchomienie trybu „pełnego śledzenia” dla wybranego użytkownika lub requestu – backend zapisuje wtedy pełny prompt i odpowiedź, ale tylko dla tej sesji. Chroni to prywatność przy normalnym ruchu, a daje pełne dane przy diagnozie trudnych przypadków.

Alerty i progi bezpieczeństwa

Nawet w małym środowisku przydają się proste alerty:

• kolejka embeddingów > X zadań przez > Y minut,
• czas odpowiedzi LLM > Z sekund średnio w ciągu 5 minut,
• wolne miejsce na głównym wolumenie NAS-a < 10%,
• liczba błędów 5xx na backendzie > N/min.

Powiadomienia e-mail, Matrix/Slack/Teams czy nawet webhook na własną apkę – ważne, żeby ktoś faktycznie je czytał. Lepiej dostać jeden sygnał „coś przytyka się przy OCR-ze” niż w piątek wieczorem odkryć, że system od rana stoi, bo katalog „tmp” na NAS-ie zapełnił ostatni wolny gigabajt.

Automatyzacja operacji: CI/CD, aktualizacje i rollback

Jak aktualizować kontenery bez przerw w pracy

Serwer NAS pełni tu rolę małego „data center”, ale operacyjnie najlepiej traktować go jak każdy inny klaster: zmiany powinny być:

Do kompletu polecam jeszcze: Jak wdrożyć OCR z AI do faktur: pipeline, walidacja i obsługa błędów — znajdziesz tam dodatkowe wskazówki.

• zdefiniowane jako kod (pliki docker-compose.yml, manifesty K8s, skrypty),
• wersjonowane w Git,
• wdrażane przewidywalnym procesem (CI/CD lub choćby półautomatycznym skryptem).

Prosty przepływ:

1. Commit zmian w konfiguracji (np. nowa wersja obrazu LLM, zmiana zmiennych środowiskowych).
2. CI buduje obrazy (jeśli trzeba), uruchamia szybkie testy funkcjonalne (czy API startuje, czy zwraca odpowiedni kod statusu na prostym zapytaniu).
3. Na środowisku produkcyjnym skrypt „deploy”:
   • pobiera najnowsze obrazy,
   • odświeża kontenery według ustalonej kolejności (np. najpierw embeddingi, potem backend),
   • wykonuje health-checki.

Przy jednym węźle trudno o prawdziwy rolling update, ale da się zminimalizować przerwy, np. utrzymując dwa równoległe kontenery LLM (stary i nowy) i przełączając ruch w reverse proxy po pozytywnych testach nowego.

Wersjonowanie modeli i konfiguracji RAG

Zmiana modelu lub głębsza modyfikacja promptów może mocno zmienić zachowanie systemu. Żeby uniknąć „magicznych” zmian, które nikt nie potrafi później odkręcić, przydaje się:

• wersjonowanie modeli (np. llm-v1.2, embed-pl-v0.9),
• trzymanie promptów i parametrów (temperature, max_tokens, k/N dla wyszukiwarki) w plikach konfiguracyjnych w repozytorium,
• oznaczanie w logach zapytań, z jaką wersją modelu i konfiguracji były obsłużone.

Przy wymianie modelu embeddingów dobrze jest uruchomić system w trybie „dualnej inferencji” dla nowo przetwarzanych dokumentów: stary i nowy model liczą wektory równolegle, ale w produkcji używany jest jeszcze stary indeks. Po porównaniu jakości na kilkunastu realnych zapytaniach można zdecydować, czy przeliczać całość. Taka faza przejściowa oszczędza kosztów „pełnego rollbacku” później.

Plan awaryjny: co zrobić, gdy model lub indeks „siada”

Awaria nie musi oznaczać totalnego blackoutu. Można przygotować kilka poziomów degradacji:

• jeśli padnie indeks wektorowy – system przełącza się na klasyczne wyszukiwanie pełnotekstowe (np. Elastic/Lucene/SQLite FTS) i oferuje prostsze odpowiedzi lub tylko listę dokumentów,
• jeśli LLM jest niedostępny – UI nadal działa jako wyszukiwarka dokumentów, bez generacji streszczeń,
• jeśli embeddingi są przeciążone – kolejka przycina batch-size lub odrzuca mniej ważne zadania (np. indeksowanie katalogu „śmietnikowego”).

Technicznie warto w backendzie przewidzieć flagi trybów pracy (np. rag_mode=full/vector_only/fulltext_fallback) i osobny endpoint lub zmienną konfiguracyjną, która pozwala ręcznie przełączyć system w tryb degradacji. W sytuacji kryzysowej nie ma czasu na przeklikiwanie się przez dziesięć kontenerów i ich logi.

Interfejs użytkownika i integracja z codziennymi narzędziami

Warstwa UI nad prywatną chmurą AI

Sama infrastruktura NIC nie zmieni, jeśli używanie jej będzie upierdliwe. Interfejs powinien:

• umożliwiać proste zadawanie pytań „po ludzku” (chat/okno zapytań),
• pozwalać na wyszukiwanie dokumentów po filtrach (tagi, data, typ pliku, klient/projekt),
• wyraźnie pokazywać, z jakich źródeł pochodzi odpowiedź (listy dokumentów, cytaty).

Przykładowy schemat:

1. Lewy panel: filtry i drzewo kategorii (projekty, klienci, działy).
2. Środek: okno dialogu z AI + odpowiedzi z cytatami.
3. Prawy panel: lista fragmentów dokumentów, które trafiły do kontekstu – z linkami do oryginałów na NAS-ie.

Tip: dobrze działa widok „podwójny” – odpowiedź modelu u góry, a poniżej tabelka z nazwami plików, ścieżkami i krótkimi snippetami tekstu. Wiele osób woli kliknąć w plik i przeczytać kontekst samodzielnie, a AI traktować jak lepszą wyszukiwarkę.

Wtyczki do przeglądarki, pakietu biurowego i komunikatorów

Z punktu widzenia wygody najcenniejsze są integracje z miejscami, gdzie użytkownicy i tak siedzą:

• wtyczka do przeglądarki – zaznacz fragment strony lub dokumentu online, wyślij do prywatnego LLM z pytaniem „porównaj z naszym wzorcem umowy z klientem X”,
• wtyczka do pakietu biurowego – zaznacz fragment w Word/LibreOffice i zadaj pytanie „streść to pod kątem ryzyk prawnych”, „przepisz w stylu naszego szablonu ofertowego”,
• bot w komunikatorze (Slack/Teams/Matrix) – kanał „pytania-do-AI”, który wysyła zapytania do prywatnego RAG-a i zwraca odpowiedzi z linkami do dokumentów na NAS-ie,
• integracja z systemem ticketowym (Jira/GLPI/Redmine) – komentarz typu „@ai opisz historię awarii związaną z tym serwerem na podstawie logów i dokumentacji”,
• skrót klawiaturowy w systemie (np. mała appka desktopowa) – zaznaczasz tekst w dowolnej aplikacji, wciskasz kombinację klawiszy, a okienko klienta AI odpala zapytanie do prywatnej chmury.

Kluczowy szczegół: wszystkie te integracje komunikują się z jednym, dobrze zdefiniowanym API backendu RAG, najlepiej za reverse proxy (HTTPS, uwierzytelnianie, throttling). Dzięki temu „klejenie” kolejnych wtyczek to zwykle tylko kwestia frontu, a nie ruszania silnika pod spodem. Ogranicza to też ryzyko, że ktoś przypadkiem wystawi model lub indeks bezpośrednio na świat.

Dobrym kompromisem między wygodą a bezpieczeństwem jest cienki klient webowy hostowany na tym samym NAS-ie, z którego korzystają i wtyczki, i boty. Wtyczka przeglądarkowa nie musi wtedy znać żadnych tokenów dostępowych – po prostu otwiera zasoby w zalogowanej sesji przeglądarki. Mniej sekretów w konfiguracjach oznacza mniej „niespodzianek” po wycieku laptopa czy konta.

Personalizacja i kontrola nad wiedzą użytkownika

Prywatna chmura z AI ma sens tylko wtedy, gdy respektuje kontekst użytkownika: dział, projekt, poziom dostępu. Warstwa aplikacyjna powinna łączyć się z istniejącym źródłem tożsamości (NAS, LDAP, AD, SSO) i na tej podstawie:

• ograniczać widoczność dokumentów i wyników (filtr ACL już w warstwie wyszukiwania, nie tylko w UI),
• personalizować podpowiedzi – np. inny „prompt systemowy” dla księgowości, inny dla zespołu devops,
• zapamiętywać kontekst sesji: projekt, klient, typ zadania, żeby kolejne pytania nie wymagały powtarzania całego opisu.

Uwaga: filtrów dostępu nie można zostawiać wyłącznie po stronie UI. Jeśli backend zwraca „zaszytą” wiedzę o dokumencie, do którego użytkownik nie ma praw, model może niechcący wyciec jego fragment w odpowiedzi. Bezpieczniej jest przefiltrować listę potencjalnych dokumentów już na etapie query do indeksu (RAG pyta tylko o te zasoby, do których użytkownik ma dostęp).

W praktyce przydają się też proste przełączniki w UI, np. „odpowiadaj tylko na podstawie dokumentów z działu X” lub „ignoruj maile, skup się na umowach”. Zmniejsza to ilość szumu w kontekście i ogranicza pokusę modelu, by „dopowiadać” sobie na podstawie niepełnej wiedzy. Użytkownik ma też poczucie, że panuje nad tym, z jakimi danymi pracuje algorytm.

Źródła

• Ogólne rozporządzenie o ochronie danych (RODO). Parlament Europejski i Rada UE (2016) – Podstawy prawne przetwarzania danych osobowych i wymogi bezpieczeństwa
• NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management. National Institute of Standards and Technology (2020) – Zarządzanie ryzykiem prywatności i kontrola nad danymi
• ISO/IEC 27040: Information technology — Security techniques — Storage security. International Organization for Standardization (2015) – Wytyczne bezpieczeństwa dla systemów przechowywania danych
• Synology NAS User’s Guide. Synology Inc. – Architektura NAS, RAID, snapshoty, kontenery i aplikacje chmurowe
• QNAP Turbo NAS Hardware Manual. QNAP Systems, Inc. – Informacje o sprzęcie NAS, RAID, sieci i obsłudze wirtualizacji
• Docker Overview and Engine Documentation. Docker, Inc. – Podstawy konteneryzacji, obrazy, sieci i wolumeny dla usług AI
• Kubernetes Documentation. Cloud Native Computing Foundation – Orkiestracja kontenerów, wdrażanie usług i skalowanie aplikacji
• TrueNAS SCALE Documentation. iXsystems, Inc. – System NAS z obsługą kontenerów i aplikacji, konfiguracja i zarządzanie
• RAID: High-Performance, Reliable Secondary Storage. ACM Computing Surveys (1994) – Klasyczna publikacja opisująca poziomy RAID i ich właściwości
• Attention Is All You Need. Neural Information Processing Systems Foundation (2017) – Architektura transformerów wykorzystywana w nowoczesnych modelach LLM