Zapytanie ofertowe na system RAG coraz rzadziej zaczyna się od listy funkcji. Zaczyna się od pytań działu IT o to, gdzie fizycznie leżą dane i co je opuszcza. To dobra zmiana, bo odpowiedzi na te pytania są sprawdzalne, a lista funkcji nie.
Poniżej dziesięć pytań, które dostajemy najczęściej, z odpowiedziami. Rozdzielamy przy tym dwie rzeczy, które w materiałach dostawców bywają zlewane: co działa dziś i co jest w planach. To łatwo sprawdzić, a rozjazd między deklaracją a stanem faktycznym wychodzi zawsze w najgorszym momencie, czyli przy due diligence.
1. Gdzie fizycznie przechowywane są dane
Tam, gdzie zainstalujesz system. Ragen jest self-hosted: dokumenty, baza danych, indeks wektorowy, historia rozmów, kopie zapasowe i klucze szyfrujące leżą na infrastrukturze, którą kontrolujesz. Nie utrzymujemy kopii po swojej stronie i nie ma kanału telemetrycznego, który wysyłałby cokolwiek do nas.
Przechowywanie to jednak nie całe pytanie. To, czy treść dokumentów jest gdzieś przesyłana w trakcie przetwarzania, zależy od konfiguracji warstwy modelu (piszemy o tym w punkcie trzecim). Wdrożenie może trzymać wszystko lokalnie i mimo to wysyłać tekst do zewnętrznego API, żeby uzyskać odpowiedź.
2. Czy rozwiązanie działa on-premise lub w chmurze prywatnej
Tak, i to jest domyślny sposób działania, a nie wariant. Przechowywanie plików, zarządzanie kluczami, kolejkowanie zadań, wyszukiwanie i parsowanie dokumentów działają lokalnie.
Poza warstwą modelu system potrzebuje z zewnątrz dwóch rzeczy: serwera poczty do powiadomień (może być Twój wewnętrzny) oraz jednorazowego pobrania obrazów kontenerów przy instalacji. Potem ruch wychodzący można odciąć, a aktualizacje dostarczać jako paczki do wewnętrznego rejestru obrazów.
3. Czy dane trafiają do zewnętrznych modeli AI
To najważniejsze pytanie z całej listy i jedyne, na które uczciwa odpowiedź brzmi „to zależy od konfiguracji”.
Wszystkie wywołania modeli idą przez proxy, które również uruchamiasz u siebie. To ono decyduje, który backend odpowiada, i dlatego warstwa modelu jest wymienna.
| Konfiguracja | Co opuszcza Twoją sieć |
|---|---|
| Model uruchomiony lokalnie | Nic w normalnej pracy |
| Model komercyjny | Treść zapytania i fragmenty dokumentów potrzebne do odpowiedzi |
Dwie rzeczy, zanim uznasz system za odcięty:
Parsowanie dokumentów jest domyślnie lokalne, ale ma fallback. Dokumenty są przetwarzane na Twoim sprzęcie: analiza układu strony, wyciąganie tabel i OCR skanów działają w kontenerze, który stoi u Ciebie. Jeśli jednak lokalny parser zawiedzie, system domyślnie schodzi do zapasowej ścieżki, która wysyła PDF do zewnętrznego modelu. Dla wdrożenia, które nie może tego zrobić, jest przełącznik wymuszający błąd zamiast fallbacku. Nie jest opcjonalny. Bez niego awaria parsera wysłałaby dokument na zewnątrz dokładnie wtedy, gdy lokalne przetwarzanie jest niedostępne.
Pełne odcięcie to praca wdrożeniowa, nie flaga w konfiguracji. Architektura to przewiduje, ale uruchomienie sensownego modelu na własnym sprzęcie oznacza moc GPU, a modele lokalne odpowiadają dziś słabiej niż komercyjne. To, o ile słabiej, zależy od Twoich dokumentów i Twoich pytań. To jest mierzalne i uważamy, że powinieneś to zobaczyć na własnym materiale, zanim wybierzesz wariant.
4. Czy dokumenty służą do trenowania modeli
Nie. Nie trenujemy ani nie dostrajamy modeli na danych klientów i nie wykorzystujemy Twoich dokumentów do rozwoju produktu. W systemie nie ma potoku treningowego: nie istnieje kod, który mógłby to zrobić.
Jeśli kierujesz ruch do modelu komercyjnego, obowiązują warunki jego dostawcy. Wersje enterprise dużych dostawców oferują zerową retencję; potwierdź warunki dla swojego planu. Jeśli to pytanie ma być nie tyle odpowiedziane, co niemożliwe do zadania, uruchom model lokalnie.
5. Jakie stosujemy szyfrowanie
W spoczynku. Treść wiadomości szyfrujemy algorytmem AES-256-GCM w schemacie kopertowym: każdy wątek rozmowy ma własny klucz, a ten klucz jest zaszyfrowany kluczem głównym, który leży w Twoim module zarządzania kluczami. Obsługujemy trzy warianty dostawcy klucza, w tym klucz lokalny pod kontrolą Twojego administratora.
Jedna rzecz wymaga świadomej konfiguracji: szyfrowanie jest opcjonalne i domyślnie wyłączone, żeby środowisko deweloperskie działało bez modułu kluczy. Instalacja produkcyjna musi jawnie wskazać dostawcę klucza. Sprawdzisz to w bazie i lepiej zrobić to na starcie niż przy audycie.
Tytuły wątków celowo zostają jawne, żeby działało po nich wyszukiwanie. To świadomy kompromis, nie przeoczenie.
W transporcie. TLS na połączeniach z aplikacją. Ruch między komponentami zostaje w Twojej sieci i jest dodatkowo uwierzytelniany podpisem kryptograficznym, więc nie da się podszyć pod komponent od środka.
6. Jak zabezpieczony jest dostęp do dokumentów
Dwie niezależne hierarchie ról: poziom aplikacji i poziom organizacji. Na to nakładają się uprawnienia do folderów i pojedynczych plików, nadawane osobom i zespołom. Dostęp programistyczny wyłącznie przez klucze API przechowywane w formie nieodwracalnej.
Pytanie, które odsiewa dostawców: czy uprawnienia działają na poziomie wyszukiwania, czy tylko interfejsu.
U nas każdy zaindeksowany fragment dokumentu niesie listę uprawnionych, a zapytanie użytkownika bez roli administratora nakłada ten filtr przed wyszukiwaniem wektorowym. Treść, do której użytkownik nie ma dostępu, nie może więc pojawić się ani w odpowiedzi, ani w cytowanym źródle.
To ma znaczenie, bo częsty błąd w innych wdrożeniach wygląda tak: filtr uprawnień działa na liście plików, ale wyszukiwanie przeszukuje cały zasób. Użytkownik nigdy nie zobaczy dokumentu, a mimo to dostanie odpowiedź zbudowaną na jego treści. Proponujemy sprawdzić to testem na Twoich rolach, zanim cokolwiek trafi na produkcję.
Izolację między organizacjami egzekwujemy osobno. Każda organizacja dostaje własną kolekcję w bazie wektorowej, a automatyczny mechanizm kontrolny wykrywa zapytania bez filtra organizacji.
7. Czy administrator ma pełną kontrolę nad danymi
Nośniki, kopie zapasowe, klucze i baza są Twoje, więc operator z dostępem do bazy i dysku ma pełną kontrolę nad przechowywanymi danymi z definicji.
To, co oferuje sama aplikacja, jest węższe i lepiej wiedzieć to zawczasu niż odkryć w trakcie audytu:
- właściciele i administratorzy organizacji usuwają pliki i odbierają uprawnienia w obrębie swojej organizacji oraz zarządzają użytkownikami, modelami i limitami
- eksport dotyczy pojedynczego wątku i wymaga własności lub roli administratora organizacji; nie ma trasy „eksportuj wszystko”
- usuwanie dokumentu czyści też wpisy w indeksie wektorowym, ale ta operacja może zawieść niezależnie od usunięcia z bazy, więc przy operacjach masowych trzeba weryfikować, a nie zakładać
- wyłączenie systemu to działanie operatora infrastruktury, nie przycisk w panelu
Nie mamy stałego dostępu do Twojego wdrożenia. Każdy dostęp, który mamy, jest nadany imiennie i odwoływalny.
8. Jak dane są chronione w transmisji i spoczynku
Odpowiedź w punkcie piątym. Dochodzą do tego trzy mechanizmy, o które klienci zwykle nie pytają wprost, a które mają znaczenie przy dokumentacji technicznej:
- kontrola wczytywanych dokumentów pod kątem ukrytych instrukcji, które mogłyby wpłynąć na zachowanie systemu
- traktowanie treści dokumentów jako danych, nie poleceń, z regresyjnym zestawem testów, który sprawdza, czy asystent nie da się namówić na ujawnienie własnej instrukcji systemowej
- wykrywanie danych osobowych z obsługą polskich identyfikatorów (PESEL, NIP, REGON, dowód, IBAN). To funkcja opcjonalna, domyślnie wyłączona, bo wymaga dodatkowych komponentów. Włącza się jednym ustawieniem
9. Jakie są mechanizmy audytu i logowania
Dwa rozdzielne dzienniki.
Dziennik operacyjny rejestruje, kto, co i kiedy zrobił, ze stanem przed zmianą i po niej: wczytanie i usunięcie dokumentu, zmianę uprawnień i ról, utworzenie i odebranie klucza API.
Dziennik bezpieczeństwa obejmuje 21 typów zdarzeń w trzystopniowej skali krytyczności i ze statusem obsługi: nieudane logowania i próby siłowe, próbę dostępu do zasobów innej organizacji, wykrytą próbę manipulacji zapytaniem, wykryte dane osobowe, przekroczenie limitów. Każdy wpis zawiera adres IP, identyfikator żądania i przeglądarkę.
Uczciwie: żaden z dzienników nie ma polityki retencji ani automatycznego usuwania. Wpisy rosną w bazie, dopóki ich nie usuniesz. Obie tabele zawierają dane osobowe, więc retencję definiuje operator i powinno to trafić do procedury od pierwszego dnia.
10. Czy da się całkowicie odizolować system od publicznych usług AI
Tak, konstrukcja to przewiduje, bo warstwa modelu jest oddzielona od reszty systemu. Zastrzeżenia z punktu trzeciego pozostają w mocy: to praca wdrożeniowa, wymaga GPU, a różnicę w jakości odpowiedzi trzeba zmierzyć na własnym materiale.
Własność danych
Twoje dokumenty, zbudowany na nich indeks oraz wygenerowane odpowiedzi pozostają Twoją własnością. Nie nabywamy do nich praw, nie wykorzystujemy ich do rozwoju produktu i nie udostępniamy nikomu.
Co działa dziś, a co jest w planach
Ta tabela jest w tym wpisie celowo. Materiały dostawców zwykle mieszają jedno z drugim, a przy poważnym wdrożeniu to właśnie ta różnica decyduje o harmonogramie.
| Obszar | Stan |
|---|---|
| Self-hosting, brak telemetrii do dostawcy | Działa |
| Lokalne parsowanie dokumentów i OCR | Działa (domyślnie) |
| Szyfrowanie kopertowe AES-256-GCM, klucz per rozmowa | Działa (wymaga konfiguracji dostawcy klucza) |
| Uprawnienia egzekwowane na poziomie wyszukiwania | Działa |
| Izolacja między organizacjami | Działa |
| Dziennik operacyjny ze stanem przed/po | Działa |
| Dziennik bezpieczeństwa, 21 typów zdarzeń | Działa |
| Wykrywanie danych osobowych (polskie identyfikatory) | Działa (opcjonalne) |
| Cytowanie źródeł z odwołaniem do pliku i sekcji | Działa |
| Logowanie jednokrotne (SSO): SAML, Entra ID, SCIM | Planowane |
| Uwierzytelnianie dwuskładnikowe i klucze passkey | Planowane |
| Eksport dzienników do systemu SIEM | Planowane |
| Gotowa, przetestowana konfiguracja w pełni odcięta | Planowane |
| Polityka retencji dzienników | Planowane |
Pozycje oznaczone jako planowane są w naszym backlogu. Jeśli któraś jest dla Ciebie warunkiem wdrożenia, powiedz o tym na etapie rozmowy. To realnie wpływa na kolejność prac, a my wolimy powiedzieć „jeszcze nie” niż tłumaczyć się z tego później.
Jak to zweryfikować
Nie musisz nam wierzyć na słowo i nie powinieneś. Ragen jest oprogramowaniem open source na licencji Apache 2.0: decyzje architektoniczne, kod odpowiadający za izolację i szyfrowanie oraz zestawy testów mierzące jakość odpowiedzi są jawne.
Najlepsze, co możesz zrobić przed decyzją, to kontrolowany test na własnych dokumentach, własnych rolach i własnych pytaniach. Wolimy, żebyś to zmierzył, niż uwierzył w tabelkę. Również naszą.
Jeśli przygotowujesz zapytanie ofertowe na system RAG, chętnie przejdziemy przez te dziesięć punktów pod kątem Twojego środowiska: polityki ruchu wychodzącego, dostępnego sprzętu i tego, jakie pytania system ma naprawdę obsłużyć. Odezwij się.