RAG dla firm: jak AI czyta wasze dokumenty i czy dane naprawdę zostają w firmie?

RAG pozwala waszemu asystentowi AI odpowiadać na pytania na podstawie dokumentów firmowych, a nie tylko ogólnej wiedzy modelu. Przy architekturze opartej na własnym serwerze dane fizycznie nie opuszczają waszej infrastruktury: ani procedury, ani umowy, ani faktury nie trafiają do chmury zewnętrznego dostawcy. Różnica między tym a podejściem przez API OpenAI nie jest akademicka, jest po prostu architektoniczna i ma bezpośrednie konsekwencje dla RODO.

Czym jest RAG i co tak naprawdę robi z waszymi dokumentami?

Skrót RAG oznacza Retrieval-Augmented Generation. Brzmi jak akademicki żargon. W praktyce: przed każdym pytaniem system najpierw wyszukuje odpowiedni fragment z bazy dokumentów, a dopiero potem podaje ten fragment modelowi jako kontekst do odpowiedzi. Model nie zapamiętuje dokumentów na stałe. Czyta je "na żądanie", przy każdym pytaniu od nowa.

Typowy scenariusz: pracownik pyta "Jakie są warunki reklamacji w umowie z Kowalski sp. z o.o.?" System szuka w bazie fragmentów tej konkretnej umowy, wyciąga klauzule reklamacyjne i podaje je modelowi. Model formułuje odpowiedź po polsku, w jednym zdaniu. Pracownik nie musi otwierać Dokumentów Google ani przeglądać folderu z umowami.

Co ważne: model nie "zna" waszych dokumentów. On dostaje fragment przy każdym zapytaniu i na tej podstawie odpowiada. Kiedy sesja się kończy, ten fragment "znika". To nie jest trening modelu na waszych danych, to jest czytanie ze ściągą.

Gdzie fizycznie trafiają dane, kiedy RAG działa przez API?

Tutaj zaczyna się różnica, która ma znaczenie dla działu prawnego i dla RODO.

Jeśli RAG używa API OpenAI, Anthropic lub innego zewnętrznego dostawcy modeli, każde zapytanie wraz z fragmentem dokumentu wędruje na serwery tego dostawcy. Dostawca przetwarza zapytanie i odsyła odpowiedź. Fizycznie fragment waszej umowy z klientem, fragment procedury HR albo dane z faktury trafiają na serwer poza waszą kontrolą. OpenAI i Anthropic deklarują, że nie trenują na danych przesyłanych przez API w wersjach enterprise, ale transfer danych i tak zachodzi. A te serwery stoją poza Unią Europejską.

Przy własnym serwerze z lokalnym modelem przepływ wygląda inaczej:

• pytanie pracownika trafia na wasz serwer (lub serwer podwykonawcy w Polsce/UE)
• system wyszukuje fragment w waszej lokalnej bazie wektorowej
• lokalny model przetwarza zapytanie i fragment
• odpowiedź wraca do pracownika

Zero transferu poza waszą infrastrukturę. Zero zapytań do zewnętrznych API. Umowa z klientem, skan faktury, regulamin zakupów, procedura onboardingu: zostają tam, gdzie je trzymacie.

Jakie dokumenty RAG może przeczytać i jak je "wgrywa"?

Wgrywanie dokumentów do RAG to operacja jednorazowa przy starcie, potem aktualizowana przyrostowo przy nowych plikach. System dzieli dokumenty na fragmenty (tzw. chunki), przetwarza każdy fragment na liczbowy "odcisk" (embedding) i zapisuje go w lokalnej bazie wektorowej. To jest właśnie ten indeks, po którym system szuka odpowiedzi.

Formaty, które obsługujemy standardowo:

• PDF (skany też, pod warunkiem dobrej jakości OCR)
• DOCX, XLSX, TXT, CSV
• dane z systemów ERP lub CRM przez API lub eksport
• strony wewnętrznego wiki lub bazy wiedzy
• transkrypty rozmów z klientami, jeśli firma je archiwizuje

U jednego z naszych klientów z branży budowlanej wgrywaliśmy kosztorysy, warunki handlowe podwykonawców i wewnętrzne procedury BHP. Łącznie kilkaset dokumentów. Wgrywanie trwało kilka godzin. Od następnego dnia kierownicy budów mogli pytać o stawki konkretnych podwykonawców wprost przez Teams, bez szukania w folderach.

RAG przez API kontra RAG na własnym serwerze: konkretna różnica

Łatwo to porównać przez pytanie: co się dzieje, gdy pracownik pyta o numer konta bankowego klienta zapisany w umowie?

Wariant API: fragment umowy z numerem konta trafia na serwer OpenAI lub innego dostawcy. Dostajecie odpowiedź. Dane wróciły, ale po drodze przeszły przez infrastrukturę, której nie kontrolujecie.

Wariant własny serwer: fragment umowy zostaje na waszym serwerze. Model lokalny go czyta. Odpowiedź wraca do pracownika. Nikt poza waszą infrastrukturą tych danych nie widział.

Różnica nie jest tylko prawna. Jest też praktyczna przy audytach. Kiedy klient albo urząd pyta "gdzie i jak przetwarzacie nasze dane", odpowiedź "na naszym serwerze w Polsce" jest dużo łatwiejsza do obrony niż "przez API, ale dostawca deklaruje, że nie trenuje".

Co RAG potrafi, a czego nie potrafi bez dodatkowych narzędzi?

RAG dobrze działa przy pytaniach faktograficznych: "Co mówi umowa X o karach umownych?", "Jaka jest procedura zwrotu towaru?", "Ile zostało na stanie magazynowym według ostatniego raportu?"

Gorzej radzi sobie z pytaniami wymagającymi wnioskowania przez wiele dokumentów naraz albo z porównaniami dużych zbiorów danych. Jeśli pytacie "Porównaj warunki płatności ze wszystkich 300 umów", to RAG sam z siebie tego nie wykona dobrze. Do takich zadań potrzeba dodatkowej warstwy: agentów AI albo dedykowanych zapytań do bazy.

RAG nie "rozumie" dokumentów w ludzkim sensie. Dopasowuje pytanie do fragmentów, które są statystycznie podobne. Dlatego jakość bazy dokumentów ma ogromne znaczenie: skany w złej jakości, tabele zamienione na obraz albo pliki bez struktury to słabszy wynik wyszukiwania i słabsza odpowiedź.

Od czego zaczynamy wdrożenie RAG w firmie?

Pierwsze pytanie, które zawsze zadajemy klientowi: jakie pytania pracownicy zadają sobie nawzajem albo szukają godzinami w folderach? To jest punkt wyjścia, nie technologia.

Typowy start wygląda tak:

• wybieramy jeden konkretny przypadek użycia, np. "odpowiedzi na pytania o warunki umów z klientami"
• zbieramy dokumenty do tego zakresu: umowy, aneksy, wzorce
• stawiamy lokalny serwer z modelem i bazą wektorową
• wgrywamy dokumenty, testujemy pytania, kalibrujemy chunking i prompt
• po 2-3 tygodniach pilot z małą grupą użytkowników
• ocena: które pytania działają dobrze, które wymagają poprawki bazy

Dopiero po pilotażu rozszerzamy zakres: kolejne typy dokumentów, kolejne działy. Nie wgrywamy wszystkiego na raz, bo to sprawia, że wyszukiwanie staje się mniej precyzyjne.

Własny serwer nie wymaga zakupu sprzętu. Działamy w modelu abonamentowym: serwer jest zarządzany przez nas, stoi w Polsce, dane klienta nie wychodzą poza tę infrastrukturę. Bez CAPEX, bez działu IT do utrzymania, z umową DPA zgodną z RODO.

Jeśli zastanawiacie się, czy RAG ma sens przy waszych dokumentach i ile to realnie zajmuje: umówimy się na bezpłatny audyt, przejdziemy przez wasze dokumenty i powiemy wprost, co da się zautomatyzować w pierwszym miesiącu. Możecie też sprawdzić, jak to wygląda u firm z podobnym profilem, w realnych wdrożeniach. Pierwsze 30 dni na własnym serwerze, bez zobowiązania na CAPEX.