Agenci AI na własnym serwerze: jak działają bez wysyłania danych firmowych do chmury?

Agent AI na własnym serwerze pobiera dane z Twojego CRM, czyta e-maile, sprawdza stany w ERP i generuje odpowiedzi bez wysyłania czegokolwiek do zewnętrznych API. Model językowy działa lokalnie, na sprzęcie stojącym w Twojej serwerowni albo w prywatnej sieci firmy. Dla firm przetwarzających dane klientów, dokumenty objęte tajemnicą handlową lub dane pracownicze to nie jest kwestia wygody, lecz konkretny wymóg wynikający z RODO i umów z partnerami.

Jak agent chmurowy wysyła dane, o których możesz nie wiedzieć?

Kiedy korzystasz z agenta w modelu chmurowym, zapytanie użytkownika to tylko początek przepływu danych. Agent, żeby cokolwiek zrobić, musi pobrać kontekst: przeczytać wątek e-mailowy, sprawdzić kartę klienta w CRM, wyciągnąć zamówienie z ERP. Każdy z tych kroków to tzw. wywołanie narzędzia (tool call).

Typowy przepływ wygląda tak. Pracownik wpisuje: "Sprawdź, czy klient Kowalski zapłacił za fakturę FV/2024/0431 i przypomnij mu mailowo." Agent wtedy odpytuje CRM po nazwisku, pobiera dane faktury z systemu finansowego, sprawdza status płatności, generuje treść e-maila z imieniem klienta i kwotą, po czym wysyła wiadomość. Każdy z tych fragmentów danych, imię, adres, kwota, numer faktury, historia kontaktu, trafia jako część kontekstu do zewnętrznego API modelu językowego. Dane fizycznie wyjeżdżają z Twojej sieci, są przetwarzane na serwerach dostawcy, a potem wracają jako odpowiedź.

Przy jednorazowym zapytaniu to bywa niezauważalne. Ale agent obsługujący kilkaset spraw dziennie generuje kilkaset takich transakcji danych na zewnątrz. Platformy takie jak DZ Agency, Agent ZEN czy Supermoce.ai działają właśnie w tym modelu: zadania realizowane przez OpenAI API, dane klientów przepływają przez zewnętrzną infrastrukturę.

Co to znaczy, że model i dane zostają na Twoim serwerze?

Architektura agenta on-premise opiera się na trzech elementach: modelu językowym zainstalowanym lokalnie, zestawie narzędzi podłączonych do systemów firmowych oraz silniku agentowym, który zarządza przepływem zadań.

Model językowy to najczęściej Llama 3 (Meta), Mistral, Qwen lub Gemma, uruchomiony przez Ollama albo vLLM na serwerze z kartą graficzną. Wszystkie zapytania i odpowiedzi trafiają wyłącznie do tego modelu. Żadne dane nie wychodzą poza serwer.

Narzędzia agenta to konektory do systemów wewnętrznych: API CRM, baza danych ERP, skrzynka e-mail przez IMAP/SMTP, katalog plików sieciowych, system kadrowy. Jeśli te systemy też działają w sieci wewnętrznej, cały ruch zostaje w Twojej infrastrukturze.

Silnik agentowy to warstwa logiki decydująca, które narzędzie wywołać i w jakiej kolejności. Może to być LangGraph, AutoGen albo własny orkiestrator napisany pod konkretny proces. Tam definiuje się, co agent może robić, a czego nie: do jakich tabel ma dostęp, jakie akcje może wykonać samodzielnie, a które wymagają zatwierdzenia przez człowieka.

Efekt: agent czyta fakturę z folderu sieciowego, sprawdza dekret w Comarch ERP XL, odpowiada na pytanie pracownika i zapisuje notatkę w CRM, a żaden bajt danych klienta nie opuszcza Twojej sieci.

Jakie zadania agenci AI na własnym serwerze robią w polskich firmach?

Zakres zadań on-premise nie różni się od tego, co robią agenci w chmurze. Różni się tylko to, gdzie przetwarzane są dane. U klientów widzimy przede wszystkim:

• Obsługa e-mail z OCR: agent pobiera załączniki (faktury, CMR, umowy), rozpoznaje tekst, przypisuje dokumenty do kontrahenta w systemie i archiwizuje bez udziału człowieka.
• Pytania do CRM w języku naturalnym: "Kiedy ostatni raz kontaktowaliśmy się z firmą Nowak Logistyka i co ustaliliśmy?" Agent pobiera historię kontaktów i odpowiada od razu.
• Monitoring należności: agent codziennie sprawdza przeterminowane płatności w ERP, generuje listę priorytetów i przygotowuje projekty przypomnień do zatwierdzenia przez handlowca.
• Pytania kadrowe: "Ile urlopu zostało Kowalskiemu?" albo "Kiedy mija umowa z Malinowskim?" Agent odpytuje system kadrowy i odpowiada bez angażowania działu HR w proste sprawdzenie.
• Zlecenia produkcyjne: agent sprawdza zlecenie, porównuje z normami surowców i zgłasza odchylenia do kierownika zmiany.

U jednego z klientów z branży dystrybucji agent on-premise obsługuje pytania do bazy kontrahentów, które wcześniej wymagały logowania do trzech różnych systemów. Pracownicy handlowi zadają pytania przez Teams, odpowiedź dostają w kilka sekund. Dane kontrahentów, historia zamówień i warunki handlowe nigdy nie opuszczają serwera klienta.

Agenci AI, własny serwer, RODO: kiedy lokalny model naprawdę zmienia sytuację prawną?

RODO nie zakazuje wprost przetwarzania danych osobowych przez zewnętrznych dostawców AI. Wymaga jednak umowy powierzenia (art. 28 RODO) i wiedzy administratora o tym, gdzie dane trafiają, jak długo są przechowywane i kto ma do nich dostęp. OpenAI w modelu API udostępnia umowę powierzenia. To realny dokument, nie fikcja prawna.

Problem pojawia się gdzie indziej. Po pierwsze: dane przetwarzane są na serwerach poza Polską. Dla danych wrażliwych (dane zdrowotne, dane sądowe, szczegółowe dane kadrowe powiązane z tożsamością) to może być niewystarczające dla audytora, klienta instytucjonalnego albo partnera wymagającego ISO 27001.

Po drugie: część platform agentowych używa modeli przez pośredników. Twoje dane mogą przechodzić przez dwa lub trzy podmioty, zanim wrócą jako odpowiedź. Każdy z nich powinien mieć umowę powierzenia, ale w praktyce nie zawsze da się to zweryfikować w rozsądnym czasie.

Po trzecie: jeśli agent przetwarza umowy, raporty finansowe, dane pracowników albo informacje objęte tajemnicą handlową, każde zewnętrzne API to kolejna pozycja w rejestrze czynności przetwarzania, którą trzeba udokumentować i uzasadnić.

Agent na własnym serwerze eliminuje te pytania. Dane nie wychodzą z sieci, więc nie ma podmiotu przetwarzającego, nie ma transferu do państwa trzeciego, nie ma konieczności uzupełniania rejestru o nowe pozycje związane z AI. Dla firm z sektora finansowego, medycznego, prawniczego albo obronnego bywa to argument decydujący. Dla małej spółki handlowej bez zewnętrznych audytów, której agent odpowiada tylko na pytania o procedury wewnętrzne, chmura może całkowicie wystarczyć.

Chmura kontra serwer lokalny: konkretne pytania, które pomagają wybrać

Nie ma jednej odpowiedzi dla wszystkich firm. Są za to pytania, które warto zadać przed wyborem architektury.

Lokalny serwer ma sens, gdy:

• firma przetwarza dane osobowe klientów indywidualnych w dużej liczbie (ubezpieczenia, ochrona zdrowia, e-commerce z rejestracją konta),
• klienci lub partnerzy biznesowi pytają wprost, gdzie są przetwarzane ich dane,
• firma ma certyfikat ISO 27001 lub przechodzi regularne audyty bezpieczeństwa,
• wewnętrzny dział IT chce pełnej kontroli nad konfiguracją modelu i logami zapytań,
• wolumen zapytań jest na tyle duży, że miesięczny koszt zewnętrznego API byłby wyższy niż koszt utrzymania własnego serwera.

Chmura może wystarczyć, gdy:

• agent odpowiada tylko na pytania o wewnętrzne procedury i FAQ, bez dostępu do danych osobowych klientów,
• firma jest małą spółką bez zewnętrznych audytów i umów narzucających szczegółowe wymagania co do lokalizacji danych,
• projekt jest w fazie pilotażu i szybkość uruchomienia ma znaczenie.

Często spotykamy się z sytuacją pośrednią: agent w chmurze do zadań, które nie dotykają danych osobowych, i agent lokalny do procesów, przez które przepływają umowy, dane klientów albo dane kadrowe. To podejście hybrydowe pozwala zacząć szybko i stopniowo przenosić wrażliwe procesy na serwer lokalny.

Od czego zaczynamy, gdy firma decyduje się na agenta on-premise?

Pierwsze pytanie, które zadajemy, dotyczy sprzętu. Modele w przedziale 7B-13B parametrów, wystarczające do większości zadań biurowych, potrzebują serwera z kartą graficzną o odpowiedniej ilości pamięci VRAM. Jeśli firma ma już serwer wirtualizacyjny lub sprzęt z GPU kupiony do innych celów, często możemy na nim uruchomić pierwszego agenta bez dodatkowych zakupów.

Drugie pytanie: do jakich systemów agent ma mieć dostęp? Robimy mapę integracji: CRM, ERP, skrzynka e-mail, folder sieciowy z dokumentami, system kadrowy. Każda integracja to oddzielne narzędzie w silniku agentowym, z oddzielnym zestawem uprawnień. Żaden agent nie dostaje dostępu do wszystkiego na raz.

Trzecie pytanie: kto zatwierdza decyzje agenta? Dobrze zaprojektowany agent on-premise nie działa autonomicznie w sprawach z finansowymi lub prawnymi konsekwencjami. Generuje projekt e-maila do zatwierdzenia przez handlowca, proponuje dekret księgowy do akceptacji przez FK, przygotowuje projekt aneksu zamiast wysyłać go samodzielnie. Zakres autonomii ustalamy przed wdrożeniem, nie po.

Jeśli chcesz sprawdzić, czy Twoje procesy nadają się do wdrożenia agenta na własnym serwerze, zacznij od bezpłatnego audytu. Możesz też zobaczyć, jak to wygląda w praktyce u innych firm, w realnych wdrożeniach, gdzie opisujemy konkretne zadania i to, jakie dane zostały w firmie.