Własny serwer czy chmura: gdzie postawić system AI w firmie

System AI dla firmy zatrudniającej 10–50 osób można utrzymać na własnym serwerze wirtualnym za około 45 zł netto miesięcznie albo w usługach zarządzanych za około 180 zł. Różnica w rachunku to mniej więcej półtora tysiąca złotych rocznie. Wybór rozstrzyga coś innego: kto ma dostęp do konsoli serwera, kto aktualizuje system i kto odbierze telefon, gdy aplikacja przestanie odpowiadać. Poniżej rozbicie kosztów i nasze dwa wdrożenia, które poszły w przeciwne strony.

Z czego składa się rachunek za infrastrukturę

8,49 euro. Tyle od 15 czerwca 2026 kosztuje miesięcznie serwer Hetzner CX33 z czterema rdzeniami i 8 GB pamięci, według komunikatu Hetznera o zmianie cen. Wcześniej płaciło się 6,49 euro. Na takiej maszynie stoi cały system kadrowy jednego z naszych klientów: baza danych, silnik automatyzacji, generator dokumentów i aplikacja, z której korzystają trzy osoby.

Sam serwer to najmniejsza pozycja. Pełny rachunek ma pięć składników.

Maszyna i kopie zapasowe

Automatyczne kopie zapasowe Hetzner liczy jako 20 procent ceny serwera, co podaje FAQ rozliczeń w dokumentacji Hetznera. Za tę kwotę dostajecie siedem ostatnich kopii. Przy CX33 daje to razem około 10,20 euro, czyli w przybliżeniu 45 zł netto miesięcznie. Domena kosztuje kilkadziesiąt złotych rocznie. Certyfikaty SSL z Let's Encrypt są darmowe i odnawiają się same.

Usługi zarządzane, jeśli nie chcecie własnej maszyny

Te same klocki można wynająć gotowe. Baza Supabase w planie Pro kosztuje od 25 dolarów miesięcznie, z 8 GB miejsca na bazę i 100 GB na pliki, jak podaje cennik Supabase w wersji z września 2026. Chmurowe n8n zaczyna się od 20 euro miesięcznie przy rozliczeniu rocznym i 2 500 uruchomień procesów, według cennika n8n. Razem wychodzi około 180 zł. Za tę kwotę aktualizacje, kopie i bezpieczeństwo samej platformy leżą po stronie dostawcy.

Czas człowieka

Tu kryje się większość kosztu. Własny serwer trzeba zabezpieczyć przed uruchomieniem czegokolwiek, aktualizować, pilnować miejsca na dysku i reagować na awarie. W spokojnym miesiącu to u nas około godziny pracy. W miesiącu z awarią kilka godzin, często wieczorem. To nasz szacunek z dwóch maszyn, bez stopera.

Koszt przestoju

Tej pozycji nie ma na żadnej fakturze. Jeśli system generuje dokumenty kadrowe, godzina bez niego oznacza pracownika, który czeka na umowę. Jeśli obsługuje fakturowanie, oznacza przesunięty termin wysyłki do KSeF. Policzcie ją osobno dla swojego procesu, bo od niej zależy, ile warto dopłacić za cudzą odpowiedzialność.

Rozbicie kosztów: własny serwer i usługi zarządzane

Składnik	Własny serwer (VPS)	Usługi zarządzane	Od czego zależy
Maszyna lub abonament	ok. 36 zł netto (CX33)	ok. 180 zł (Supabase Pro i n8n Starter)	liczba użytkowników, rozmiar plików, liczba uruchomień
Kopie zapasowe	20% ceny serwera	w cenie planu	czy potrzebujecie kopii starszych niż tydzień
Aktualizacje i zabezpieczenia	po Waszej stronie albo wykonawcy	platformy po stronie dostawcy, aplikacji po Waszej	czy ktoś ma to w obowiązkach
Dostęp awaryjny	konsola u właściciela konta	panel dostawcy i jego wsparcie	kto trzyma login do konta
Miejsce danych	wybieracie centrum danych, np. Niemcy lub Finlandia	wybieracie region przy zakładaniu projektu	wymagania RODO i klientów
Przejęcie systemu przez firmę	proste, jeśli konto od początku jest Wasze	wymaga migracji między kontami	na czyim koncie system stoi od pierwszego dnia

Tabela pokazuje, że rachunek za maszynę rzadko przesądza sprawę. Przy systemie, który oszczędza kilkanaście godzin pracy miesięcznie, 135 zł różnicy nie zmienia decyzji. Zmienia ją to, kto odpowiada za każdy z wierszy od trzeciego w dół. Jak porównać ten koszt z całym budżetem wdrożenia, pokazujemy w artykule o realnych cenach wdrożenia AI.

Co podbija koszt własnego serwera: nasza historia

Lipiec 2026. Informatyk firmy delegującej pracowników do Szwecji sam zaproponował, żeby system stanął na serwerze wykupionym na koncie firmy. Postawiliśmy go 28 lipca. Konto należy do klienta, a my mamy do maszyny dostęp roboczy. Ten jeden wybór zdjął z projektu całą późniejszą migrację, bo system od pierwszego dnia jest własnością klienta.

Pierwszego dnia maszyna dostała wyłącznie zabezpieczenia. Zablokowane konto administratora, zapora z trzema otwartymi portami, fail2ban na próby logowania, automatyczne łatki bezpieczeństwa. Aplikację wgraliśmy osobnym krokiem. Kolejność ma znaczenie, bo automaty skanujące sieć zaczęły pukać pod nowy adres w ciągu pierwszej godziny.

Luka, której nie widać z zewnątrz

Dwa dni później zrobiliśmy audyt bezpieczeństwa przed pokazaniem systemu klientce. Znaleźliśmy błąd krytyczny. Folder z wygenerowanymi dokumentami pracowników był publiczny, więc każdy, kto znał adres pliku, mógł pobrać umowę z numerem PESEL i numerem konta. Sprawdziliśmy to realnym pobraniem bez logowania. Poprawka zajęła jedną sesję: folder zamknięty, a linki do plików ważne przez godzinę i generowane tylko dla zalogowanej osoby.

Usługa zarządzana nie ochroniłaby przed tym błędem. Ustawienia dostępu do plików konfiguruje ten, kto buduje aplikację, niezależnie od tego, gdzie ona stoi. Dlatego audyt bezpieczeństwa należy do wdrożenia w obu wariantach.

Wieczór, w którym serwer zniknął

24 sierpnia około 19:45 system przestał odpowiadać. Na ponad godzinę. Maszyna działała bez przerwy od sześciu dni, wszystkie usługi żyły, a mimo to nikt nie mógł się połączyć. Serwer zgubił adres sieciowy, bo wygasła mu dzierżawa adresu, a systemowa usługa sieciowa nie odnowiła jej sama.

Naprawa wymagała wejścia przez konsolę w panelu Hetznera. Konsola była na koncie klienta, więc dostęp miał jego informatyk. Po tym wieczorze dołożyliśmy dwie rzeczy: ustawienie, które zatrzymuje adres mimo utraty dzierżawy, oraz skrypt sprawdzający sieć co pięć minut i podnoszący ją bez udziału człowieka.

Z tej historii wynika najważniejsza pozycja rachunku. Serwer na koncie klienta to czysta własność i zero migracji. Ceną jest zależność od osoby, która trzyma login do konsoli, w chwili, gdy coś pada. Tę cenę trzeba ustalić na piśmie przed startem: kto ma dostęp awaryjny, w jakich godzinach i jak szybko reaguje.

Kiedy własny serwer się nie opłaca

Drugie wdrożenie poszło odwrotnie. W lipcu prezes agencji nieruchomości zatrzymał rozmowy jednym zdaniem: „Nie kupujcie serwera, mamy inny plan na to”. Poprosiliśmy o maszynę i login za wcześnie, zanim ktokolwiek po stronie klienta zobaczył działający system. Dla małej firmy zakup serwera oznacza nową pozycję w budżecie i decyzję właściciela. Pokaz wypadł dobrze, a mimo to prośba o infrastrukturę zatrzymała sprawę.

Pilot przenieśliśmy na naszą infrastrukturę, na realnych danych i bez żadnych wymagań po stronie klienta. Gdy klient poprosił o przerwę do końca sierpnia, usunęliśmy maszynę, żeby nie płacić za nieużywany serwer. Zostawiliśmy obraz dysku i zarezerwowany adres, więc powrót to odtworzenie z kopii, a stawianie od zera odpada.

Z obu przypadków wychodzą trzy sytuacje, w których własny serwer przegrywa:

Pilot, który ma pokazać wartość w cztery tygodnie. Każdy zakup po stronie klienta wydłuża start, więc system powinien ruszyć na infrastrukturze wykonawcy albo w usługach zarządzanych.
Brak osoby, która przejmie serwer po wykonawcy. Maszyna bez opiekuna starzeje się co miesiąc: przestarzałe pakiety, pełny dysk, wygasłe certyfikaty.
Mała liczba uruchomień i danych. Przy kilkudziesięciu dokumentach miesięcznie plan zarządzany kosztuje niewiele więcej, a odpowiedzialność za platformę przechodzi na dostawcę.

Uwaga na darmowe plany. Supabase usypia darmowe projekty po tygodniu bez aktywności. Pilot, do którego nikt nie zajrzał przez urlop, rano zwyczajnie nie działa. Takie potknięcia opisujemy szerzej w tekście o błędach wdrożenia AI.

Własny serwer wygrywa w odwrotnej sytuacji. System działa już produkcyjnie, firma ma informatyka albo umowę utrzymaniową z wykonawcą, a dane są wrażliwe i klient chce wiedzieć, na jakiej maszynie leżą. Tak jest przy kartotekach z numerami PESEL i dokumentach kadrowych.

Jedno zastrzeżenie. Pracujemy na serwerach wirtualnych w europejskich centrach danych i na usługach zarządzanych. Nie wdrażaliśmy systemu na fizycznym serwerze w biurze klienta, więc o tym wariancie nie piszemy z praktyki.

Jak sprawdzić własną liczbę w tydzień

Wystarczą cztery pytania i jedno spotkanie z osobą, która zna Wasze systemy.

Pierwsze: ile kosztuje godzina przestoju procesu, który chcecie automatyzować? Weźcie ostatni dzień, w którym ten proces stanął, i policzcie, kto czekał i na co. Jeśli wychodzi kilkaset złotych, dopłata do usług zarządzanych zwraca się przy pierwszej awarii.

Drugie: kto w firmie ma login do konta u dostawcy serwera? Imię i nazwisko. Jeśli to jedna osoba bez zastępstwa, macie odpowiedź na pytanie o dostęp awaryjny.

Trzecie: czy wykonawca odda system na Wasze konto? Zapytajcie o to przed podpisaniem umowy. System postawiony od pierwszego dnia na koncie firmy przechodzi na nią bez migracji. System na koncie wykonawcy wymaga przeniesienia, które też ktoś wyceni.

Czwarte: kto aktualizuje serwer po zakończeniu wdrożenia? Jeśli nikt, wybierzcie usługi zarządzane albo utrzymanie u wykonawcy. Jak policzyć, czy cały system się zwraca, opisujemy w artykule o liczeniu oszczędności z AI.

Z tych odpowiedzi rysuje się decyzja. Pilot i brak opiekuna wskazują chmurę zarządzaną. System produkcyjny z danymi wrażliwymi i opiekunem wskazuje własny serwer na koncie firmy.

Najczęstsze pytania

Ile kosztuje miesięcznie serwer dla systemu AI w małej firmie?

Serwer wirtualny dla systemu AI w firmie zatrudniającej 10–50 osób kosztuje od około 45 zł netto miesięcznie razem z kopiami zapasowymi, na przykład Hetzner CX33 z czterema rdzeniami i 8 GB pamięci. Wariant w usługach zarządzanych, czyli Supabase Pro i chmurowe n8n, kosztuje około 180 zł. Do obu kwot trzeba doliczyć czas osoby, która pilnuje systemu.

Czy system AI z danymi pracowników może stać w chmurze zgodnie z RODO?

System AI z danymi pracowników może stać w chmurze, jeśli dane leżą w centrum danych na terenie Unii Europejskiej, a firma ma z dostawcą umowę powierzenia przetwarzania danych. Hetzner oferuje centra danych w Niemczech i Finlandii, Supabase pozwala wybrać region europejski przy zakładaniu projektu. O zgodności decydują też ustawienia dostępu do plików w samej aplikacji.

Na czyim koncie powinien stać serwer z systemem wdrożonym przez zewnętrzną firmę?

Serwer z systemem wdrożonym przez zewnętrzną firmę najlepiej od pierwszego dnia postawić na koncie klienta, z dostępem roboczym dla wykonawcy. Klient jest wtedy właścicielem danych i infrastruktury, a zakończenie współpracy nie wymaga migracji. Wyjątkiem jest krótki pilot, który szybciej rusza na infrastrukturze wykonawcy i przechodzi na konto klienta po decyzji o wdrożeniu.

Co się dzieje, gdy serwer z systemem AI przestanie odpowiadać wieczorem?

Gdy serwer z systemem AI przestanie odpowiadać, naprawa często wymaga konsoli w panelu dostawcy, do której dostęp ma właściciel konta. Dlatego przed startem trzeba ustalić na piśmie, kto ma dostęp awaryjny i w jakich godzinach reaguje. Automatyczny skrypt sprawdzający sieć co kilka minut usuwa część awarii bez udziału człowieka.

Sprawdźcie, który wariant pasuje do Waszych procesów. Bezpłatny audyt kończy się dokumentem z mapą procesów i rachunkiem kosztów ręcznej roboty.