Bielik i lokalne modele AI — kiedy dane naprawdę nie mogą opuścić firmy

Bielik to rodzina otwartych dużych modeli językowych, którą rozwija fundacja SpeakLeash, a trenuje na zasobach Akademickiego Centrum Komputerowego Cyfronet AGH (SpeakLeash, ACK Cyfronet AGH). Modele powstawały na superkomputerach Athena i Helios, w ramach grantów obliczeniowych PLGrid — czyli na publicznej infrastrukturze utrzymywanej w Polsce. Od razu powiedzmy, co o tym sądzimy: polskie pochodzenie modelu nie jest samo w sobie argumentem zakupowym i odradzamy budowanie na nim uzasadnienia wdrożenia, bo o zgodności z RODO czy z tajemnicą zawodową decyduje to, gdzie fizycznie liczą się dane i kto ma do nich dostęp, a nie narodowość zespołu, który model wytrenował. Argument, który naprawdę waży, jest inny: wagi modeli są publicznie dostępne, więc można je pobrać i uruchomić na własnym serwerze, bez wysyłania jednego znaku do zewnętrznego dostawcy. Model językowy przestaje być usługą, do której się łączysz, a staje się plikiem, który leży na twoim dysku i liczy się na twoim sprzęcie.

Bielik jest udostępniany na licencji Apache 2.0 (SpeakLeash), czyli w modelu pełnej otwartości, dopuszczającym również zastosowania komercyjne. W praktyce oznacza to trzy rzeczy. Po pierwsze, nie płacisz za zapytanie ani za token — koszt przenosi się z abonamentu na sprzęt i prąd. Po drugie, model można modyfikować i dostrajać do własnych dokumentów bez pytania kogokolwiek o zgodę. Po trzecie, i to bywa pomijane, licencja nie zwalnia z niczego innego: RODO, tajemnica zawodowa i umowy z klientami obowiązują tak samo, niezależnie od tego, gdzie model działa. Najpowszechniejsze nieporozumienie wokół otwartych modeli brzmi „otwarte, czyli darmowe” i uważamy je za kosztowne w skutkach: bezpłatna jest licencja i nic poza nią, bo serwer, prąd, miejsce w szafie, czas osoby, która to utrzyma, i przestój, gdy coś padnie, kosztują niezależnie od zapisu w pliku LICENSE. Otwartość dotyczy prawa do użycia modelu, a nie prawa do przetwarzania danych ani kosztu jego uruchomienia.

Osobną pozycją w tej rodzinie jest Bielik Guard ze stycznia 2026 r. (SpeakLeash) — klasyfikator bezpieczeństwa dla języka polskiego, dostępny w wariantach 0,1B i 0,5B. To nie jest model do rozmowy, tylko filtr: mały, szybki komponent, który ocenia treść wchodzącą do systemu i wychodzącą z niego. W firmowym wdrożeniu uważamy taki element za równie ważny jak model generujący odpowiedzi, bo bez niego między tym, co pracownik wklei, a tym, co system przetworzy i wypuści dalej, nie ma żadnego mechanicznego progu — zostaje wyłącznie zaufanie do ludzi, a zaufanie nie zostawia wpisu w logu.

Samego modelu nie radzimy natomiast wybierać z rankingu ani z tabeli w ofercie — i konsekwentnie nie znajdziesz tu naszego rankingu. Nie podajemy wyników testów Bielika, bo nie przeprowadziliśmy ich na własnych danych i nie zweryfikowaliśmy cudzych, a przepisanie liczby, której się nie sprawdziło, jest podaniem dalej czyjejś tezy jako własnej ekspertyzy. Jedyny sprawdzian, który naszym zdaniem cokolwiek rozstrzyga, to kilkadziesiąt realnych pytań waszych pracowników zadanych na waszych dokumentach: wynik takiego testu jest nieprzenoszalny na inną firmę i właśnie dlatego jest wiarygodny. Jeśli ktoś obiecuje wam wybór modelu bez tego etapu, sprzedaje wam decyzję, której nie sprawdził.

Model lokalny to model, którego wagi znajdują się na sprzęcie kontrolowanym przez firmę i który liczy odpowiedzi na tym sprzęcie, bez wysyłania treści do zewnętrznej usługi. Model w chmurze działa odwrotnie: dokument, pytanie i kontekst opuszczają twoją sieć, trafiają na serwery dostawcy, tam są przetwarzane i wracają jako odpowiedź. Różnica nie leży w jakości odpowiedzi, tylko w tym, kto ma dostęp do danych wejściowych i kto odpowiada za ich bezpieczeństwo. To rozróżnienie trzeba robić precyzyjnie, bo w rozmowach handlowych słowo „lokalnie” bywa rozciągane aż do utraty znaczenia — serwer w wynajętej serwerowni albo wydzielona instancja u dostawcy chmury to wciąż cudza infrastruktura, choć zwykle łatwiejsza do opisania w rejestrze czynności przetwarzania. Proponujemy jeden test tego słowa: czy potrafisz wskazać w umowie podmiot, który ma fizyczny dostęp do dysku z danymi? Jeśli odpowiedź brzmi „ktoś inny niż my”, to jest wdrożenie hostowane — może bardzo dobre, ale naszym zdaniem nie wolno nazywać go lokalnym w dokumentacji, którą pokażesz audytorowi, bo to jedyne zdanie z tej dokumentacji, które ktoś naprawdę sprawdzi.

• Dane wejściowe: lokalnie zostają w sieci firmy, w chmurze trafiają do dostawcy usługi.
• Koszt: lokalnie to wydatek na sprzęt plus utrzymanie, w chmurze — opłata zależna od zużycia.
• Dostępność: chmura skaluje się natychmiast, serwer lokalny ma stałą, z góry znaną wydajność.
• Aktualizacje: w chmurze dostawca podmienia model sam, lokalnie decydujesz i wykonujesz to samodzielnie.
• Odpowiedzialność: lokalnie kopie zapasowe, poprawki bezpieczeństwa i awarie są po twojej stronie.
• Zgodność: lokalnie łatwiej wykazać, że dane nie opuściły organizacji ani Europejskiego Obszaru Gospodarczego.

Najważniejsze zdanie tego tekstu brzmi tak: model lokalny nie jest oszczędnością, tylko przeniesieniem kosztu. Znika faktura od dostawcy modelu, a w jej miejsce pojawiają się trzy pozycje, których nikt nie wystawia w jednym dokumencie — sprzęt z akceleratorem wraz z prądem i miejscem w szafie, kompetencja osoby, która to postawi, zaktualizuje i naprawi, oraz odpowiedzialność, której nie da się scedować na regulamin usługi. Uważamy, że kto nie policzy tych trzech pozycji przed decyzją, policzy je po pierwszej awarii i będzie zaskoczony — nie dlatego, że ktoś go oszukał, tylko dlatego, że porównywał miesięczny abonament z ceną zakupu serwera zamiast z pełnym kosztem posiadania rozłożonym na kilka lat. Dlatego odradzamy uzasadnianie projektu lokalnego oszczędnością, nawet jeśli tak najłatwiej przeprowadzić go przez zarząd: jedyne uzasadnienie, które wytrzymuje rok pracy, to wymóg, którego chmurą nie da się spełnić.

Warto też uczciwie oszacować, ile zapytań dziennie realnie pojawi się w firmie. Model lokalny ma wydajność ustaloną raz — dokładnie taką, na jaką pozwala kupiony sprzęt — więc w godzinach szczytu użytkownicy czekają w kolejce, a poza nimi maszyna stoi bezczynnie. Chmura zachowuje się odwrotnie: rośnie i maleje razem z ruchem, a płaci się za faktyczne zużycie. Przy kilku zapytaniach dziennie odradzamy własny serwer wprost, bez owijania w „to zależy” — cały koszt sprzętu i utrzymania rozkłada się wtedy na garść zapytań miesięcznie, więc wychodzi z tego najdroższy znany nam sposób na streszczanie e-maili. Przy stałym, dużym obciążeniu i twardym wymogu poufności proporcje się odwracają i to abonament zaczyna wyglądać na kosztowną dzierżawę cudzej infrastruktury; wtedy wybieramy lokalnie i mówimy to równie wprost.

Drugie nieporozumienie, równie kosztowne, brzmi „lokalnie, czyli bezpiecznie”. Uruchomienie modelu na własnym serwerze usuwa jedno ryzyko — przekazania treści na zewnątrz — i nie usuwa żadnego innego. Jeśli do lokalnego asystenta ma dostęp każdy pracownik, a system indeksuje wszystkie foldery bez rozróżnienia uprawnień, to właśnie powstała wygodna wyszukiwarka danych, do których część zespołu nie powinna zaglądać. Naszym zdaniem to najczęstszy sposób, w jaki projekt robiony „dla bezpieczeństwa” bezpieczeństwo pogarsza: wcześniej dostępu do akt pilnował chaos katalogów i nieporęczne nazwy plików, a po wdrożeniu pilnuje go już wyłącznie poprawnie ustawiona kontrola uprawnień, o której na etapie zakupu sprzętu nikt nie rozmawiał. Lokalny model wymaga tego samego co każdy inny system informatyczny: kontroli dostępu, rejestrowania zdarzeń, kopii zapasowych i jasnej odpowiedzi na pytanie, kto i co może przez niego zobaczyć. Bez tego zmienia się tylko adres, pod którym pojawi się problem.

Rzadziej, niż się o tym mówi. Naszym zdaniem większość firm, które powtarzają „nasze dane nie mogą wyjść na zewnątrz”, nigdy tego zdania nie sprawdziła — to zwykle domysł zarządu albo ostrożność działu IT, a nie zapis w polityce bezpieczeństwa, klauzula w umowie z klientem czy przepis. Dane naprawdę nie mogą opuścić firmy wtedy, gdy zabrania tego przepis, tajemnica zawodowa albo konkretne postanowienie konkretnej umowy, i to rozróżnienie decyduje o całym budżecie: model lokalny kupiony z domysłu potrafi kosztować wielokrotnie więcej od rozwiązania chmurowego, nie dając w zamian ani jednej korzyści, której dałoby się bronić przed audytorem. Dlatego pierwszym krokiem, który polecamy przed jakąkolwiek rozmową o sprzęcie, jest sprawdzenie tego na piśmie: wyciągnięcie umów z największymi klientami i przeczytanie klauzul poufności, przejrzenie własnej polityki bezpieczeństwa, a przy tajemnicy zawodowej — ustalenie z prawnikiem, co dokładnie ona obejmuje. To kilka godzin pracy i najtańsza część całego projektu; wszystko, co robi się przed nią, jest zgadywaniem za cudze pieniądze.

Warto od razu spisać kategorie dokumentów: które są objęte przepisem, które umową, a które niczym poza przyzwyczajeniem. Zwykle okazuje się, że twarde ograniczenia dotyczą mniejszości materiałów, a reszta to korespondencja, oferty i treści, które spokojnie mogą być przetwarzane w chmurze na standardowych warunkach. Antywzorzec jest tu prosty do nazwania i kosztowny w skutkach: najpierw zapada decyzja „wszystko lokalnie”, potem szuka się sprzętu, a klasyfikacja nie powstaje nigdy — bo skoro wszystko idzie lokalnie, to pozornie nie ma czego dzielić. Efekt jest zawsze ten sam i uważamy go za najdroższy błąd w tej kategorii projektów: serwer wyceniony pod najbardziej wrażliwy dokument w firmie, obsługujący w większości pliki, których poufność nikogo nie obchodzi.

• Kancelarie prawne — tajemnica adwokacka i radcowska obejmuje wszystko, czego prawnik dowiedział się w związku ze sprawą.
• Biura rachunkowe — dokumentacja finansowa klientów, dane pracowników, wynagrodzenia i rozliczenia.
• Podmioty medyczne — dane o zdrowiu należą do szczególnych kategorii danych osobowych, z osobnym reżimem ochrony.
• Produkcja i prace badawczo-rozwojowe — receptury, dokumentacja techniczna, wyceny i warunki handlowe objęte tajemnicą przedsiębiorstwa.
• Umowy z klientem korporacyjnym — klauzule poufności bywają węższe niż przepisy i zabraniają przekazywania danych podwykonawcom.

Jest jednak druga strona i nie chcemy, żeby powyższe zabrzmiało jak zachęta do szukania furtek. W części sytuacji z tej listy „dane nie mogą wyjść” nie jest domysłem, tylko twardym warunkiem: tajemnica adwokacka i radcowska obejmuje wszystko, czego prawnik dowiedział się w związku ze sprawą, dane o zdrowiu należą do szczególnych kategorii danych osobowych z osobnym reżimem ochrony, a klauzula poufności z umowy korporacyjnej potrafi być węższa niż sam przepis i zabraniać przekazywania danych podwykonawcom. Tam odradzamy chmurowe skróty niezależnie od tego, jak bardzo są wygodne i o ile taniej wychodzą w arkuszu — konsekwencją naruszenia nie jest wyższy rachunek, tylko odpowiedzialność zawodowa, ryzyko utraty uprawnień albo zerwana umowa, a tego nie odrabia się kolejnym wdrożeniem. Nie polecamy też traktowania anonimizacji jako obejścia tego warunku: dopóki nikt nie sprawdził, czy z tekstu pozbawionego nazwisk nie da się odtworzyć sprawy po kwotach, datach i nazwach firm, jest to zabezpieczenie na słowo honoru, a nie zabezpieczenie.

W księgowości granica bywa nieoczywista, bo część danych i tak wychodzi z firmy z mocy prawa. Obowiązek wystawiania faktur w Krajowym Systemie e-Faktur objął od 1 lutego 2026 r. przedsiębiorców, których sprzedaż z VAT przekroczyła w 2025 r. 200 mln zł, a od 1 kwietnia 2026 r. — pozostałych przedsiębiorców, w tym MSP (Ministerstwo Finansów). Do 31 grudnia 2026 r. trwa okres przejściowy: faktury można wystawiać poza KSeF, o ile miesięczna sprzedaż z takich dokumentów nie przekracza 10 000 zł brutto, a po przekroczeniu progu obowiązek zaczyna działać od faktury, która go przekroczyła (Ministerstwo Finansów). Sama faktura trafia więc do systemu państwowego niezależnie od tego, jakiego modelu AI używa biuro. Wyciągamy z tego wniosek, którego biura rachunkowe zwykle nie chcą słyszeć: budowanie lokalnego modelu po to, żeby „faktury nie wychodziły z firmy”, jest wydatkiem bez przedmiotu, bo one już z niej wychodzą. O potrzebie modelu lokalnego w biurze decydują umowy, korespondencja z klientem, dokumentacja płacowa i notatki ze spraw — dokumenty, których nikt nigdzie nie raportuje — i to na nich radzimy skupić całą rozmowę o poufności.

Spis kategorii przydaje się też później, w rozmowie z klientem lub audytorem. Odpowiedź „tych akt nie wysyłamy nigdzie poza własny serwer” jest sprawdzalna tylko wtedy, gdy ktoś wcześniej ustalił, o które akta chodzi. Bez klasyfikacji zostaje deklaracja, której nie da się poprzeć ani dokumentem, ani logiem — a naszym zdaniem deklaracja bez logu jest w audycie warta dokładnie tyle samo, co jej brak, bo audytor nie ocenia intencji zarządu, tylko dowody, które mu położysz na stole.

Odradzanie bywa uczciwsze niż doradzanie, więc zacznijmy od strony, na której nie zarabiamy. Modelu lokalnego nie polecamy firmom, które nie potrafią wskazać dokumentu zakazującego wysyłania danych na zewnątrz — kupują wtedy niezależność, której nikt od nich nie wymaga, i płacą za nią sprzętem oraz czasem ludzi. Nie polecamy go też tam, gdzie zapytań jest kilkanaście dziennie, gdzie w firmie nie ma nikogo od serwerów i gdzie projekt ma ruszyć „na próbę”, bo próba na własnym sprzęcie kosztuje mniej więcej tyle, ile pełne wdrożenie, a więc przestaje być próbą. Poniższa lista to nasze wypowiedziane wprost „nie” wraz z powodem — wolimy powiedzieć to na pierwszym spotkaniu, nawet jeśli oznacza to mniejszy projekt, niż tłumaczyć się z tego po roku.

• Nie polecamy modelu lokalnego, gdy nie istnieje pisemny zakaz przekazywania danych — bez niego wydajesz pieniądze na ryzyko, którego nikt w firmie nie zdefiniował.
• Nie polecamy go, gdy nie ma osoby ani firmy odpowiedzialnej za serwer — model bez właściciela technicznego przestaje być aktualizowany w kilka miesięcy i zamienia się w otwartą podatność we własnej sieci.
• Nie polecamy go przy kilku lub kilkunastu zapytaniach dziennie — koszt stały rozkłada się wtedy na tak małą liczbę użyć, że każdy inny wariant wypada taniej przy identycznym efekcie.
• Nie polecamy go jako pierwszego projektu AI w firmie — zanim kupisz sprzęt, warto sprawdzić na czymś prostszym, czy zespół w ogóle zacznie z asystenta korzystać, bo najczęstszą przyczyną porażki nie jest model, tylko brak użytkowników.
• Odwrotnie: odradzamy chmurę tam, gdzie obowiązuje tajemnica zawodowa albo klauzula zabraniająca przekazywania danych podwykonawcom — tam wygoda nie jest argumentem, bo stawką jest uprawnienie do wykonywania zawodu albo sama umowa.
• Odradzamy też wariant pośredni oparty na obietnicy: „nie wklejamy wrażliwych rzeczy do czatu” nie jest zabezpieczeniem, tylko prośbą — reguła, której system nie wymusza, zostanie złamana w pierwszym gorszym tygodniu.

Jest jeszcze przypadek, w którym nie umiemy odpowiedzieć, i mówimy to wprost, zamiast improwizować: firmy z pogranicza, gdzie umowa zabrania „przekazywania danych podmiotom trzecim”, ale nie precyzuje, czy dostawca usługi przetwarzającej dane w Europejskim Obszarze Gospodarczym jest takim podmiotem. Nie jesteśmy kancelarią i nie rozstrzygamy takich zapisów — w takiej sytuacji odsyłamy do prawnika klienta, zanim zaproponujemy jakąkolwiek architekturę, bo pomyłka w interpretacji jednej klauzuli kosztuje więcej niż całe wdrożenie. Uważamy zresztą, że dostawca IT, który interpretuje cudze umowy o poufności, wychodzi poza swoje kompetencje i robi klientowi niedźwiedzią przysługę: bierze na siebie rolę, której nie uniesie, a odpowiedzialność i tak zostaje po stronie klienta.

Do uruchomienia modelu we własnej infrastrukturze potrzebne są trzy rzeczy naraz: sprzęt z akceleratorem obliczeniowym, osoba, która to środowisko postawi i utrzyma, oraz procedura mówiąca, co się dzieje przy aktualizacji i przy awarii. Wymagania sprzętowe zależą od wybranego wariantu — mniejszy model, taki jak Bielik 4.5B v3, jest znacznie mniej wymagający niż wariant 11B (SpeakLeash) — a konkretnych progów pamięci świadomie tu nie podajemy, bo nie zmierzyliśmy ich na docelowym sprzęcie i przy docelowej liczbie równoczesnych użytkowników. Uważamy, że tabela z wymaganiami wklejona w artykuł jest w tym miejscu szkodliwa: wygląda jak wiedza, a jest wróżeniem, i to na jej podstawie ludzie zamawiają sprzęt, którego potem nie da się zwrócić. Sama instalacja jest przy tym najkrótszym etapem projektu — dłużej trwa doprowadzenie do stanu, w którym model odpowiada na pytania o firmowe dokumenty, a nie o świat w ogóle, i to właśnie tam znika budżet, którego nikt nie przewidział.

1. 01Klasyfikacja danychSpis kategorii dokumentów z odpowiedzią, które z nich są objęte przepisem, tajemnicą zawodową albo umową. Odmawiamy zaczynania projektu od innego kroku — nie z zasady, tylko dlatego, że każdy inny start prowadzi do kupowania sprzętu pod dokument, który być może wcale nie musi zostać w firmie.
2. 02Wybór wariantu modeluMniejszy model wystarcza do wyszukiwania i streszczania firmowych dokumentów, większy radzi sobie z trudniejszymi poleceniami. Decyzję podejmujemy po testach na waszych własnych pytaniach; rankingi traktujemy jako ciekawostkę, bo mierzą coś innego niż wasza praca.
3. 03Środowisko uruchomienioweSerwer z akceleratorem, oprogramowanie serwujące model, kontrola dostępu i logi. Na tym etapie ustala się też, ilu użytkowników ma korzystać z systemu równocześnie i w jakich godzinach — pominięcie tego pytania jest najczęstszą przyczyną kupienia maszyny o połowę za dużej albo o połowę za małej.
4. 04Połączenie z danymi firmyModel sam z siebie nie zna waszych dokumentów. Trzeba zbudować warstwę wyszukiwania po firmowych zasobach z zachowaniem uprawnień: pracownik ma widzieć przez asystenta dokładnie to, co widzi bez niego. Uważamy ten krok za najczęściej niedoszacowany w całym projekcie, bo to on, a nie wybór modelu, decyduje, czy asystent nie stanie się obejściem uprawnień.
5. 05UtrzymanieAktualizacje modelu i oprogramowania, monitoring, kopie zapasowe, okresowy przegląd jakości odpowiedzi. To praca stała, nie jednorazowa. Jeśli w tym miejscu nie da się wskazać nazwiska albo umowy serwisowej, odradzamy start — model bez opiekuna nie psuje się głośno, tylko cicho traci jakość, a nikt tego nie zauważa.

Uczciwie: własna infrastruktura to własne utrzymanie. Serwer trzeba kupić lub wynająć, aktualizować, monitorować i naprawiać, gdy zepsuje się w piątek po południu. Nowa wersja modelu nie pojawi się sama — ktoś musi ją pobrać, przetestować na waszych pytaniach i podmienić. Poprawki bezpieczeństwa, kopie zapasowe, kontrola dostępu i logi to nie dodatek, tylko warunek, żeby całość dało się obronić przed audytorem albo klientem. W chmurze część tej pracy kupuje się w abonamencie, lokalnie kupuje się niezależność i płaci za nią czasem zespołu albo stałą umową serwisową. Naszym zdaniem to jest ten moment, w którym najczęściej pęka biznesplan lokalnego wdrożenia: koszt sprzętu policzył każdy, koszt czyjejś stałej uwagi przez najbliższe trzy lata — prawie nikt.

Część tego wydatku bywa do sfinansowania ze środków publicznych. Grant Dig.IT prowadzony przez ARP obejmuje 150 000–850 000 zł, do 50% kosztów kwalifikowalnych w formule de minimis, i kierowany jest do MSP z sektora przemysłu oraz usług dla przemysłu (ARP). Firmy z województwa łódzkiego mogą sięgnąć po działanie Przemysł 4.0 w programie Fundusze Europejskie dla Łódzkiego: do 85% dla wydatków objętych de minimis, minimum 300 000 zł kosztów kwalifikowalnych i maksymalnie 1 000 000 zł dofinansowania (Fundusze Europejskie dla Łódzkiego). Dla projektów z komponentem badawczo-rozwojowym w Ścieżce SMART nabór modułu B+R dla pojedynczych MSP trwa od 29 października do 29 grudnia 2026 r., a poziom dofinansowania zależy od modułu i wielkości firmy (PARP). W każdym z tych programów o kwalifikowalności decyduje regulamin konkretnego naboru, więc zakres projektu warto ułożyć razem z osobą, która przygotowuje wniosek, zanim zapadnie decyzja o zakupie sprzętu. Jedno zastrzeżenie mówimy jednak wprost: odradzamy układanie projektu pod dotację. Grant obniża wyłącznie koszt wdrożenia, a utrzymanie, aktualizacje i prąd zostają po stronie firmy na kolejne lata — projekt, który bez dofinansowania nie miał sensu, po dofinansowaniu ma go dokładnie tyle samo, tylko zaczyna boleć później.

Wariant mieszany polega na tym, że dzieli się dane według wrażliwości, a nie system według dostawcy: dokumenty objęte tajemnicą przetwarza model lokalny, a zadania neutralne — redakcję ofert, tłumaczenia materiałów marketingowych, obsługę pytań ze strony internetowej — obsługuje model w chmurze. To wariant, który wybieramy jako domyślny punkt startu w większości rozmów, i powód jest prozaiczny: pozwala uruchomić lokalnie tylko tę część, którą trzeba, więc sprzęt kupuje się pod zmierzoną potrzebę, a nie pod najgorszy wyobrażalny scenariusz. Warunek jest jeden i tu nie idziemy na kompromis: reguła decydująca o skierowaniu danych musi być zapisana w kodzie i możliwa do sprawdzenia w logu, a nie zostawiona uznaniu użytkownika. Jeśli o trasie dokumentu decyduje to, co pracownik akurat wklei do okna czatu, podział istnieje wyłącznie w prezentacji dla zarządu — i dokładnie tak zostanie oceniony przy pierwszym incydencie.

• Lokalnie: akta spraw, dokumentacja finansowa klientów, dane osobowe pracowników, dokumentacja techniczna i wyceny.
• W chmurze: teksty marketingowe, materiały publiczne, wsparcie przy kodowaniu, wstępna redakcja dokumentów bez danych klienta.
• Zawsze lokalnie: warstwa decydująca o skierowaniu danych oraz logi tych decyzji.
• Do ustalenia osobno: dane zanonimizowane — anonimizacja bywa pozorna, jeśli w tekście zostaną nazwy firm i kwoty.

Przy warstwie, która te dane rozdziela, mamy konkretną preferencję i nie ukrywamy jej za „to zależy”. Gdy warunek brzmi „treść nie opuszcza sieci”, wybieramy n8n, bo można go uruchomić na własnym serwerze obok modelu i cała trasa dokumentu zostaje w tej samej sieci co on — a to jedyna rzecz, którą da się później pokazać w rejestrze czynności przetwarzania. Narzędzia dostępne jako usługa w chmurze, takie jak Make czy Zapier, zostawiamy do procesów, w których dane i tak są jawne: to nie jest zarzut wobec ich jakości, bo w swoich zastosowaniach bywają wygodniejsze i szybsze do uruchomienia, tylko wniosek z architektury, w której przepływ przechodzi przez cudzą infrastrukturę. Naszym zdaniem to jedyna sensowna kolejność wyboru narzędzi automatyzacji: najpierw wymóg dotyczący danych, potem lista narzędzi, które go spełniają, i dopiero na końcu wygoda. Odwrotna kolejność kończy się integracją, którą trzeba przepisać od zera, gdy pierwszy poważny klient przyśle ankietę bezpieczeństwa.

Kolejność pracy przy takim projekcie jest zawsze ta sama: najpierw klasyfikacja danych, potem wybór trasy dla każdej kategorii, a dopiero na końcu zakup sprzętu. Odwrócenie tej kolejności kończy się serwerem, który stoi i czeka, aż ktoś zdecyduje, co właściwie ma na nim działać. Trzymamy się tej sekwencji nawet wtedy, gdy klient ma już wybrany sprzęt i prosi tylko o uruchomienie — bo jeśli klasyfikacja wykaże, że lokalnie musi zostać jedna czwarta dokumentów, lepiej dowiedzieć się o tym przed konfiguracją niż po niej.

Czterech rzeczy, o które ten temat prosi się najbardziej — i uważamy, że powiedzenie tego wprost jest warte więcej niż zapełnienie luk czymkolwiek. Nie ma tu wyników testów Bielika ani porównań z innymi modelami, bo nie zweryfikowaliśmy żadnego z publikowanych zestawień, a przepisanie cudzej tabeli bez sprawdzenia byłoby podaniem dalej czyjejś tezy jako własnej. Nie ma wymagań sprzętowych w gigabajtach ani nazw konkretnych kart, bo nie zmierzyliśmy ich na docelowej konfiguracji, a liczba wpisana „mniej więcej” wraca potem do nas jako zamówienie na sprzęt. Nie ma rocznego porównania kosztu modelu lokalnego z abonamentem chmurowym, choć byłby to najmocniejszy argument w całym tekście — nie mamy do niego zweryfikowanych cen sprzętu ani stawek dostawców na sierpień 2026 r., a wymyślona tabela wyglądałaby dokładnie tak samo przekonująco jak prawdziwa i właśnie dlatego jej nie ma. I nie ma opisu naszego wdrożenia lokalnego modelu, bo nie mamy opublikowanej takiej realizacji; kiedy pierwszy projekt się zamknie i klient zgodzi się na publikację, opiszemy go z rachunkiem, a nie z przymiotnikami.

Wolimy taki tekst od kompletnego, bo w tej kategorii treści „kompletny” zwykle oznacza, że ktoś uzupełnił własne braki cudzymi liczbami. Polecamy przy okazji prosty test, który warto stosować do każdego artykułu o AI, łącznie z tym: policz, ile zdań mówi, co autor wybiera i czego odradza, a ile tylko opisuje, jak działa świat. Tekst, pod którym mogłaby się podpisać dowolna agencja w Polsce, nie kosztował autora nic — a skoro nic nie kosztował, to niczego nie gwarantuje.

Jeśli szukasz punktu wyjścia, proponujemy najtańszy z możliwych: godzina na sprawdzenie, czy „nasze dane nie mogą wyjść” jest u was zapisem w umowie i polityce bezpieczeństwa, czy domysłem. Dopiero potem rozmowa o modelu. W Wataha Media wdrożenia rozwiązań AI wyceniamy od 10 000 zł, a stałą opiekę techniczną w pakietach Wataha Care za 100, 200 lub 300 zł miesięcznie; koszt sprzętu, jeśli projekt ma działać lokalnie, jest po stronie klienta i radzimy policzyć go na samym początku, razem z ewentualnym wnioskiem o dofinansowanie. Pracujemy zdalnie w całej Polsce, a na spotkania dojeżdżamy w promieniu około 40 km od Radomska — najprościej zacząć od krótkiej rozmowy pod numerem +48 788 727 823 albo wiadomości na media.wataha@gmail.com, jeszcze zanim pojawi się pytanie o konkretny model. Jeśli po tej rozmowie okaże się, że model lokalny jest wam niepotrzebny, powiemy to wprost i uznamy rozmowę za udaną — bo wdrożenie, którego nikt nie potrzebował, wraca do nas jako problem, a nie jako referencja.