Czy warto wdrożyć lokalne AI w małej firmie?
Koszty, sprzęt i realne zastosowania na przykładzie ERP

AI w małej i średniej firmie bardzo szybko przestaje być eksperymentem. Sprzedaż, księgowość i zarząd zaczynają zadawać bardzo konkretne pytania.

I wtedy pojawia się pomysł:

Brzmi prosto. W rzeczywistości model językowy jest prawdopodobnie najłatwiejszą częścią całego projektu. O tym, gdzie AI realnie pomaga w codziennej pracy IT, piszemy w artykule AI w administracji IT: 7 obszarów, które warto automatyzować. Tutaj skupiamy się na czymś węższym: asystencie, który odpowiada na pytania o dane z ERP. Znacznie trudniejsze niż uruchomienie modelu jest ustalenie:

Można kupić bardzo mocną kartę GPU i nadal otrzymywać błędne odpowiedzi. Bo większy model nie naprawi złej definicji danych.

Najpierw dane i pytania. Dopiero później GPU

Najczęstszy błąd wygląda tak:

W pierwszym wariancie dopiero po uruchomieniu wszystkiego pojawia się dyskusja:

Kiedy lokalne AI ma sens?

Nie istnieje jeden warunek typu "dane są wrażliwe, więc musi być on-prem". Lokalny model może mieć sens z kilku różnych powodów.

1. Chcemy ograniczyć wysyłanie danych poza firmę

Dotyczy to szczególnie:

Lokalny model pozwala utrzymać większą część procesu we własnym środowisku. Nie oznacza to automatycznie zgodności z RODO ani bezpieczeństwa. Nadal potrzebujemy:

Szerzej o danych wysyłanych do modeli, shadow AI i kontroli dostępu piszemy w artykule AI w cyberbezpieczeństwie firmy.

2. Chcemy pracować bez zależności od zewnętrznego API

Może to mieć znaczenie:

• › przy ograniczonym dostępie do Internetu,
• › w środowiskach izolowanych,
• › przy wymaganiach kontraktowych,
• › przy krytycznych procesach wewnętrznych.

3. Chcemy mieć przewidywalną infrastrukturę i koszt

Przy dużej, regularnej liczbie zapytań własny serwer może być atrakcyjny. Ale nie zakładałbym tego z góry. Trzeba policzyć pełny koszt i porównać go z kosztem API:

Ta sama logika dotyczy każdej decyzji infrastrukturalnej, co opisujemy w artykule chmura czy własny serwer.

4. Chcemy pełnej kontroli nad integracją

Lokalny model może być wygodny, gdy ma współpracować z:

To szczególnie interesujące, gdy całość ma działać jako jeden firmowy system.

Kiedy nie zaczynałbym od lokalnego AI?

Jeżeli firma nie potrafi odpowiedzieć na pytanie:

nie kupowałbym jeszcze GPU. Podobnie, jeśli:

W takim przypadku problemem nie jest brak LLM. Problemem jest brak przygotowanej warstwy danych.

Najważniejsza zasada: LLM nie jest źródłem liczb

Załóżmy, że użytkownik pyta: "Jaki był przychód w sierpniu?". Model nie powinien odpowiadać na podstawie:

Prawidłowy przebieg wygląda tak:

Model może powiedzieć: "Przychód w sierpniu wyniósł 123 456,78 PLN." Ale 123 456,78 PLN musi pochodzić z narzędzia. Nie z modelu. To jedna z najważniejszych zasad całej architektury:

Tool calling zamiast dowolnego SQL

Istnieją dwa bardzo różne modele integracji AI z bazą danych.

Pierwsze rozwiązanie wygląda efektownie podczas demonstracji. Użytkownik może zapytać prawie o wszystko. Problem w tym, że model musi samodzielnie znać schemat, dobierać JOIN-y, interpretować pola, rozumieć znaczenie dokumentów i wiedzieć, jak traktować korekty. W systemie ERP jest to bardzo ryzykowny model.

W drugim modelu podział odpowiedzialności jest jasny:

Ta druga decyzja została podjęta wcześniej przez człowieka, przetestowana i porównana z raportem systemu ERP. Dla większości wdrożeń biznesowych zacząłbym właśnie od tego modelu.

Przykład narzędzi

Na początku wcale nie potrzeba ich setek. Można zacząć od czterech:

Każde ma jasno określony kontrakt. Model wywołuje narzędzie z parametrami:

{
  "tool": "get_revenue",
  "parameters": {
    "date_from": "2026-08-01",
    "date_to": "2026-09-01"
  }
}

Backend wykonuje kontrolowane zapytanie. Model dostaje wynik i przygotowuje zdanie:

{
  "revenue_pln": 1234567.89,
  "date_from": "2026-08-01",
  "date_to": "2026-09-01"
}

Warstwa kanoniczna zamiast bezpośredniego "rozumienia ERP"

W Comarch ERP XL istnieje bogaty model danych i wiele zależności biznesowych. Nie chciałbym, żeby model językowy sam dochodził, które kolumny w CDN.* oznaczają dokładnie to, o co pyta użytkownik. Lepiej zbudować warstwę pośrednią:

LLM nie musi znać całej struktury ERP. Potrzebuje wiedzieć tylko, że istnieje narzędzie get_revenue. To znacznie prostszy i bezpieczniejszy kontrakt.

Konto tylko do odczytu to dopiero początek

Osobne konto dla aplikacji jest bardzo dobrym pomysłem. Nie dawałbym mu jednak SELECT na całej bazie tylko dlatego, że to "tylko SELECT". Microsoft w dokumentacji SQL Server zaleca zasadę najmniejszych uprawnień i pozwala nadawać dostęp na poziomie pojedynczych obiektów albo konkretnego schematu. Lepszy układ:

GRANT SELECT ON SCHEMA::ai_reporting TO ai_reader;

gdzie ai_reporting zawiera wyłącznie kontrolowane widoki potrzebne aplikacji. To daje dodatkowe granice:

Ta sama zasada, którą stosujemy wobec administratorów i kont technicznych. Dlaczego modelowi nie przekazuje się credentiali, opisujemy w artykule 10 rzeczy, których administrator IT nie powinien oddawać AI bez kontroli.

SELECT-only również może zrobić problem

To często pomijany temat. Zapytanie nie musi niczego modyfikować, żeby zaszkodzić wydajności. Może:

Dlatego warto stosować również:

SQL Server obsługuje timeout wykonywania ustawiany po stronie klienta. Po jego przekroczeniu aplikacja może anulować zapytanie. W większych środowiskach można również rozważyć osobny workload raportowy lub mechanizmy ograniczające zużycie zasobów. Jak wolne zapytania wpływają na cały ERP, pokazujemy w artykule dlaczego SQL Server zwalnia.

Najlepszy wariant, jeśli architektura na to pozwala:

Wtedy zapytania analityczne nie konkurują bezpośrednio z użytkownikami ERP. Nie zawsze jest to jednak możliwe lub ekonomicznie uzasadnione w małej firmie.

Przykład bezpieczniejszego narzędzia

Jeżeli stosujemy katalog gotowych funkcji, kod może wyglądać bardzo prosto:

def get_revenue(cursor, date_from, date_to):
    sql = """
        SELECT
            SUM(revenue_pln) AS revenue_pln
        FROM ai_reporting.revenue
        WHERE doc_date >= ?
          AND doc_date < ?
    """

    cursor.execute(sql, (date_from, date_to))
    row = cursor.fetchone()

    return {
        "revenue_pln": row[0],
        "date_from": date_from.isoformat(),
        "date_to": date_to.isoformat(),
    }

Nie budujemy zapytania w ten sposób:

sql = f"""
SELECT ...
WHERE date = '{user_input}'
"""

Czy parser SQL jest potrzebny?

Może być dodatkową warstwą zabezpieczenia. Ale jeżeli stosujemy wyłącznie gotowe narzędzia z wcześniej przygotowanym SQL, jego rola jest znacznie mniejsza. Nie budowałbym bezpieczeństwa w taki sposób:

Parser nie rozumie wszystkich konsekwencji biznesowych zapytania. Znacznie mocniejsze zabezpieczenia to:

Parser może być ósmą warstwą. Nie pierwszą.

Jak powinna wyglądać architektura?

Dla lokalnego asystenta ERP rozsądna architektura może wyglądać tak:

UŻYTKOWNIK
    |
    v
WEB / FRONTEND
    |
    v
BACKEND
FastAPI / inna aplikacja
    |
    +----------------------+
    |                      |
    v                      v
RBAC / AUDIT          LLM / OLLAMA
                           |
                           v
                    wybór narzędzia
                           |
                           v
                  KATALOG NARZĘDZI
                           |
                           v
                       AI_READER
                           |
                           v
                  WARSTWA RAPORTOWA
                           |
                           v
                        ERP XL

Backend udostępnia mu określony katalog funkcji. Nic więcej.

Co właściwie robi LLM?

W takim systemie jego zadania są stosunkowo proste.

{
  "period_a": "2026-07",
  "period_b": "2026-08"
}

{
  "july": 918000,
  "august": 1043000,
  "change_percent": 13.62
}

Model nie wykonał księgowości. Model wykonał interfejs językowy do wcześniej zdefiniowanej księgowości. To bardzo ważna różnica.

Co jeśli narzędzie nie odpowie?

Załóżmy, że zapytanie kończy się błędem MSSQL timeout.

To kolejna fundamentalna zasada:

To samo dotyczy awarii samego serwera z modelem. Asystent ERP to kolejna usługa, która powinna mieć monitoring, alerty i procedurę postępowania. Jak podejść do incydentu z pomocą AI, opisujemy w artykule AI podczas awarii: pierwsze 30 minut incydentu.

Audit

Dla każdego zapytania warto móc odtworzyć:

Nie oznacza to koniecznie przechowywania wszystkich danych zwróconych przez ERP. Audit również powinien respektować zasadę minimalizacji danych. Przykładowo:

{
  "user": "user123",
  "tool": "get_revenue",
  "parameters": {
    "period": "2026-08"
  },
  "duration_ms": 142,
  "status": "success"
}

To często wystarczy do analizy działania systemu. Takie logi dobrze jest trzymać w tym samym miejscu co resztę telemetrii, o czym piszemy w artykule AI w analizie logów Linux.

Lokalny model, API czy rozwiązanie hybrydowe?

Nie traktowałbym tego jako wyboru tylko "chmura vs on-prem". W praktyce istnieją co najmniej trzy warianty.

Wariant hybrydowy jest szczególnie interesujący. ERP nigdy nie opuszcza firmy. Zapytanie wykonywane jest lokalnie. Model zewnętrzny może ewentualnie dostać tylko:

{
  "metric": "revenue",
  "period": "2026-08",
  "value": 1043000,
  "currency": "PLN"
}

i jedynie przygotować odpowiedź. Czy nawet taka liczba może być poufna? Oczywiście. Dlatego nadal potrzebna jest decyzja organizacji. Ale zakres danych jest nieporównywalnie mniejszy niż przy przesłaniu fragmentu bazy ERP.

Czy lokalny model automatycznie rozwiązuje problem RODO?

Nie. Lokalność ogranicza jeden rodzaj ryzyka: przekazywanie danych zewnętrznemu dostawcy. Nadal pozostają:

Jaki sprzęt jest potrzebny?

Tutaj nie podawałbym jednej konfiguracji jako "minimalnej". Wymagania zależą od:

Ollama czy vLLM?

Dla małego wdrożenia Ollama jest wygodnym sposobem na szybkie uruchomienie lokalnego modelu i wystawienie API. W większym środowisku, gdzie liczy się większa liczba jednoczesnych zapytań, throughput i zarządzanie serwowaniem modelu, można rozważyć również inne rozwiązania, na przykład vLLM.

Aplikacja powinna traktować model jako wymienny endpoint. Nie budować się wokół jednej konkretnej nazwy modelu. Przykład konfiguracji:

LLM_BASE_URL=http://llm01.internal:11434
LLM_MODEL=<model>

Zmiana modelu nie powinna wymagać przepisywania integracji z ERP.

Nie kupuj GPU przed benchmarkiem

To jedna z najprostszych metod oszczędzenia pieniędzy. Najpierw przygotuj:

Następnie przetestuj kilka modeli. Mierz:

Dopiero wtedy wiadomo, czy potrzebujesz modelu 8B, 14B czy większego, oraz jakiego sprzętu.

Model większy nie zawsze znaczy lepszy projekt

Jeżeli zadanie LLM wygląda tak:

niekoniecznie potrzebujemy największego modelu, jaki da się uruchomić. Mniejszy model może być szybszy, tańszy, łatwiejszy w utrzymaniu i całkowicie wystarczający. Największy wzrost jakości projektu często da lepsze narzędzie i lepsza definicja danych, a nie większy LLM.

Co naprawdę składa się na TCO?

Karta GPU jest najbardziej widocznym kosztem. Nie zawsze największym.

Host z modelem to kolejny serwer, który trzeba regularnie przeglądać. Warto dopisać go do comiesięcznej checklisty utrzymania IT razem z resztą infrastruktury.

Czy trzeba backupować modele?

Nie zawsze. Jeżeli używamy publicznie dostępnego modelu, często wystarczy mieć:

• › przypiętą wersję i identyfikator modelu,
• › konfigurację,
• › procedurę ponownego pobrania.

Inaczej wygląda sytuacja, jeżeli model jest fine-tunowany, własny, używany w środowisku air-gapped albo niedostępny publicznie. Wtedy artefakty modelu rzeczywiście stają się elementem strategii backupu. To dobry przykład kosztu, którego nie warto automatycznie doliczać do każdego wdrożenia. Znacznie ważniejszy pozostaje backup samego ERP, o czym piszemy w artykule backup systemu ERP.

Rozsądna ścieżka projektu

Jak testować taki system?

Nie pytaniem "czy odpowiedź wygląda dobrze?". Potrzebujemy testów. Przykładowy zestaw:

Osobno testujemy dwie warstwy:

To bardzo ułatwia diagnostykę.

Co jeśli model wybierze złe narzędzie?

Na przykład użytkownik pyta "Ile klienci są nam winni?", a model wybiera get_revenue. To błąd LLM. Nie błąd ERP. Dzięki rozdzieleniu warstw dokładnie wiemy, gdzie szukać problemu. To kolejny argument przeciwko rozwiązaniu "LLM generuje wszystko od początku do końca".

Jak rozszerzać system później?

Dopiero po stabilizacji pierwszych narzędzi można dodawać kolejne. Na przykład:

Każde przechodzi tę samą drogę:

W ten sposób system rośnie powoli, ale przewidywalnie.

A co z dowolnymi pytaniami do danych?

Prędzej czy później użytkownik zapyta:

Nie da się przygotować wcześniej każdego możliwego narzędzia. To moment, w którym można rozważyć bardziej dynamiczną analitykę. Ale nie zaczynałbym od niej. Jeżeli firma chce wdrożyć text-to-SQL, lepszym miejscem jest replika, hurtownia, baza raportowa albo sandbox analityczny, a nie produkcyjna baza ERP. Do tego:

To jest etap późniejszy. Nie MVP.

Najczęstsze błędy

Kiedy lokalne AI nie ma ekonomicznego sensu?

Nie rozstrzyga tego moda. Rozstrzyga TCO i wymagania.

Jak podchodzimy do takiego projektu w PRO-Admin?

Nie zaczynamy od wyboru modelu. Najpierw odpowiadamy na sześć pytań:

Dopiero później dobieramy architekturę, model, CPU lub GPU, sposób uruchomienia i integrację. Rola człowieka się tu nie kończy: ktoś musi zatwierdzać definicje, pilnować testów i odpowiadać za wynik, o czym szerzej w artykule czy AI zastąpi administratora systemów.

W projekcie opartym o Comarch ERP XL szczególnie ważne jest oddzielenie trzech warstw:

Model powinien być ostatnią warstwą. Nie pierwszą.

FAQ - lokalne AI w firmie

Podsumowanie

Lokalny LLM może mieć bardzo dużo sensu w małej i średniej firmie. Ale nie dlatego, że "AI musi być u nas na serwerze". Sens pojawia się wtedy, gdy rozwiązanie:

W przypadku ERP najważniejsza architektura wygląda tak:

Najważniejszym elementem takiego systemu nie jest więc GPU. Nie jest nim nawet model. Jest nim zasada:

Jeżeli pytamy o przychód, model nie może go wymyślić. Jeżeli pytamy o saldo klienta, odpowiedź musi pochodzić z danych. Jeżeli ERP nie odpowiada, AI również nie zna odpowiedzi.

To właśnie odróżnia użyteczny firmowy system AI od bardzo przekonującego chatbota.