Wybór „własny model LLM czy Custom GPT” sprowadza się do dwóch pytań: gdzie mogą trafić Twoje dane i jak szybko chcesz zacząć. Własny model open-weight na serwerach firmy daje pełną kontrolę nad danymi, ale wymaga sprzętu i ludzi do jego utrzymania. Custom GPT skonfigurujesz bez programowania, ale dane przetwarza OpenAI, a to, co się z nimi dzieje, zależy od planu ChatGPT.

Stan na październik 2026: OpenAI planuje wycofać niestandardowe GPT i zastąpić je wtyczkami (plugins). Standardowy termin wycofania to 11 grudnia 2026 r., a dla przestrzeni Enterprise z zatwierdzonym odroczeniem 11 lutego 2027 r. Na kontach osobistych (Free, Go, Plus, Pro) nie da się już tworzyć nowych GPT (FAQ OpenAI o wycofaniu GPT, GPTs in ChatGPT). Jeśli dziś budujesz Custom GPT, planuj od razu migrację.

Oś sporu: pełna kontrola czy szybkość i prostota

Własny model LLM to model open-weight, czyli z publicznie udostępnionymi wagami, uruchomiony na Twoich serwerach albo w Twojej prywatnej chmurze. Zapytania i dokumenty nie opuszczają Twojej infrastruktury, o ile tak ją skonfigurujesz. Model może działać nawet w sieci fizycznie odciętej od internetu (air-gapped). Wagi to plik na Twoim dysku, więc wersja modelu zmienia się tylko wtedy, gdy Ty ją podmienisz.

Custom GPT to wersja ChatGPT skonfigurowana do konkretnego zadania: instrukcje, pliki wiedzy, wybrane funkcje (np. wyszukiwanie w sieci) oraz połączenia z zewnętrznymi usługami przez aplikacje albo akcje (GPTs in ChatGPT). Nie kupujesz serwerów i nie piszesz kodu. Ograniczenie: GPT działa tylko wewnątrz ChatGPT, a użytkownik musi być zalogowany. OpenAI pisze wprost, że GPT nie osadzisz na stronie ani w aplikacji; do tego służy API.

Pytanie brzmi więc: czy w tym projekcie ważniejsza jest pełna kontrola nad danymi i modelem, czy szybki start bez własnej infrastruktury?

Czym w praktyce jest LLM w firmie

Duży model językowy (LLM) to model wytrenowany na ogromnych zbiorach tekstu, który generuje odpowiedź token po tokenie. W firmie działa zwykle w jednym z trzech układów: jako czat dla pracowników, jako element aplikacji wywoływany przez API albo jako system odpowiadający na pytania na podstawie dokumentów firmy.

„Własny model na danych firmowych” prawie nigdy nie oznacza trenowania modelu od zera. W praktyce bierzesz gotowy model open-weight i dajesz mu dostęp do dokumentów w chwili zapytania (RAG: system wyszukuje pasujące fragmenty i dołącza je do promptu) albo douczasz go na własnych przykładach (fine-tuning). W obu przypadkach o bezpieczeństwie decyduje to, gdzie działa model i kto ma dostęp do danych, które do niego trafiają.

Lokalny model: AI pod własnym dachem

Lokalne wdrożenie zaczyna się od infrastruktury: serwer z GPU albo klaster, często zarządzany przez Kubernetes, który pozwala skalować model na wiele maszyn we własnym centrum danych. Klaster produkcyjny może działać w wydzielonym segmencie sieci, a model nie dostaje dostępu do niczego ponad to, czego potrzebuje.

Zasada minimalnych uprawnień obowiązuje niezależnie od silnika: model widzi tylko wskazane bazy, foldery i API. Dane, które do niego trafiają, przechodzą wcześniej oczyszczenie z danych osobowych i identyfikatorów, które nie są potrzebne do zadania.

Inaczej wyglądają też koszty. Płacisz za sprzęt (zakup albo wynajem GPU), energię i czas zespołu, a nie za każdy token. Przy dużym i stałym wolumenie zapytań daje to przewidywalny budżet; przy małym sprzęt stoi bezczynnie, a płacisz za niego tak samo. Za pomocą naszego Kalkulatora Build vs Buy porównasz TCO budowy własnego rozwiązania z zakupem gotowego (np. subskrypcji AI), Kalkulator Budżetu AI w Firmie pomoże oszacować roczny budżet na AI, a Kalkulator tokenów AI policzy koszt wariantu z API. Dlaczego cena za token w cenniku nie mówi wszystkiego o rachunku, pokazujemy w tekście Ile naprawdę kosztuje model AI.

Wskazówka: zaplanuj od razu środowisko testowe (sandbox). Błędy i ryzyka łatwiej wyłapać w zamkniętej piaskownicy niż na produkcji.

Jak uruchomić własny model LLM na serwerach firmy

Uruchomienie sprowadza się do czterech decyzji: model, silnik, sprzęt i dostęp.

1. Wybierz model open-weight i sprawdź licencję

„Open-weight” nie zawsze znaczy „open source”: licencje różnią się warunkami. Przykłady, stan na październik 2026, dane z kart modeli:

Model Parametry Licencja Na co zwrócić uwagę
gpt-oss-20b i gpt-oss-120b (OpenAI) 21 mld i 117 mld (aktywne 3,6 mld i 5,1 mld, architektura MoE) Apache 2.0 120b mieści się na jednym GPU 80 GB, 20b działa w 16 GB pamięci
Qwen3-8B (Qwen) 8,2 mld Apache 2.0 kontekst 32 768 tokenów natywnie
Mistral Small 3.2 (Mistral AI) 24 mld Apache 2.0 ok. 55 GB pamięci GPU w bf16 lub fp16
Bielik-11B-v2.6-Instruct (SpeakLeash, ACK Cyfronet AGH) 11 mld Apache 2.0 polski jako główny język modelu
Llama 3.3 70B (Meta) 70 mld Llama 3.3 Community License powyżej 700 mln aktywnych użytkowników miesięcznie potrzebna osobna licencja; przy dystrybucji oznaczenie „Built with Llama”
Llama 4 Scout (Meta) 109 mld (17 mld aktywnych) Llama 4 Community License modele Llama 4 są multimodalne, a zasady użytkowania nie przyznają praw z sekcji 1(a) licencji osobom i firmom z główną siedzibą w UE (zastrzeżenie nie dotyczy użytkowników końcowych gotowego produktu)

Przed wdrożeniem Llamy 4 w firmie z siedzibą w Polsce skonsultuj ten zapis z prawnikiem. Modele na Apache 2.0 nie mają takich ograniczeń geograficznych.

2. Wybierz silnik do uruchamiania modelu

  • Ollama: najprostszy start na jednym serwerze. Model pobierasz i uruchamiasz jedną komendą (ollama run qwen3:8b), a aplikacje łączą się z nim przez API zgodne z częścią API OpenAI pod adresem http://localhost:11434/v1/ (dokumentacja). Domyślnie Ollama nasłuchuje tylko na 127.0.0.1, port 11434; udostępnienie w sieci wymaga zmiany zmiennej OLLAMA_HOST (FAQ Ollama). Ollama oferuje też modele chmurowe, w których prompty są przetwarzane poza Twoim serwerem, więc przy wrażliwych danych korzystaj tylko z modeli lokalnych.
  • llama.cpp: silnik w C/C++ na licencji MIT. Działa na CPU, Apple Silicon, kartach NVIDIA (CUDA) i AMD (HIP), a także przez Vulkan i SYCL. Obsługuje kwantyzację od 1,5 do 8 bitów i ma serwer z API zgodnym z OpenAI. Sprawdza się, gdy nie masz mocnego GPU.
  • vLLM: serwer do obsługi wielu użytkowników naraz na GPU. Komenda vllm serve Qwen/Qwen3-8B uruchamia serwer implementujący protokół API OpenAI (domyślnie http://localhost:8000), parametr --api-key włącza wymaganie klucza, a --tensor-parallel-size dzieli model na kilka kart (argumenty silnika).

Zgodność z API OpenAI ułatwia architekturę hybrydową: aplikację napisaną pod API OpenAI często przełączysz na własny serwer, zmieniając adres bazowy. Ollama obsługuje tylko część tego API, więc przetestuj funkcje, których używasz.

3. Policz pamięć GPU

O wymaganiach sprzętowych decydują trzy rzeczy:

  • rozmiar modelu: pamięć na wagi to w przybliżeniu liczba parametrów × liczba bajtów na parametr;
  • kwantyzacja: w BF16 i FP16 parametr zajmuje 2 bajty, w 8 bitach około 1 bajta, w 4 bitach około 0,5 bajta plus narzut formatu;
  • pamięć podręczna KV (KV cache): rośnie z długością kontekstu i liczbą równoległych rozmów.

Przykład dla Qwen3-8B. Założenia z pliku konfiguracyjnego modelu: 8,2 mld parametrów, 36 warstw, 8 głowic KV, wymiar głowicy 128, KV cache przechowywany w FP16 (2 bajty).

  • Wagi w BF16: 8,2 mld × 2 B ≈ 16,4 GB. Ollama podaje dla tego modelu 16 GB w fp16, 8,9 GB w q8_0 i 5,2 GB w 4-bitowym q4_K_M.
  • KV cache na jeden token: 2 (klucz i wartość) × 36 warstw × 8 głowic × 128 × 2 B = 147 456 B, czyli ok. 0,15 MB.
  • Pełny natywny kontekst 32 768 tokenów (jedna długa rozmowa albo cztery rozmowy po 8 192 tokeny): 32 768 × 147 456 B ≈ 4,8 GB.
  • Razem: ok. 10 GB w wersji 4-bitowej (5,2 + 4,8) i ok. 21 GB w BF16 (16,4 + 4,8), plus zapas na samo środowisko uruchomieniowe.

Wniosek: 4-bitowy Qwen3-8B z takim kontekstem powinien zmieścić się na karcie 16 GB, a wersja BF16 potrzebuje karty co najmniej 24 GB i pracuje na niej blisko limitu. Ollama domyślnie ustawia kontekst na 4096 tokenów, a KV cache trzyma w f16; przełączenie cache na q8_0 (przy włączonym Flash Attention) zmniejsza go mniej więcej o połowę (FAQ Ollama). Ten sam rachunek zgadza się dla większych modeli: Mistral Small 3.2 ma 24 mld parametrów, czyli 48 GB samych wag w bf16, a karta modelu podaje ok. 55 GB pamięci GPU.

4. Zamknij dostęp

Model wystaw w sieci firmowej tylko za warstwą z uwierzytelnianiem (SSO albo klucze API), z logowaniem zapytań do SIEM i limitami użycia. Zaplanuj tę warstwę osobno, przed silnikiem (np. reverse proxy), zamiast polegać na ustawieniach samego silnika.

Czy własny model LLM na danych firmowych jest bezpieczny?

Może być bezpieczniejszy niż usługa chmurowa, bo całe przetwarzanie zostaje w Twojej sieci, a w środowisku air-gapped dane nie mają fizycznej drogi na zewnątrz. Lokalny model integruje się z mechanizmami, które firma już ma: szyfrowaniem, IAM, SIEM i DLP.

W praktyce:

  • wagi modelu to plik na Twoim dysku; jego integralność kontrolujesz jak każdego innego artefaktu (sumy kontrolne, kontrola zmian);
  • polityki dostępu do danych używanych przy douczaniu i przy zapytaniach ustawiasz sam, zgodnie z wewnętrznymi standardami (np. ISO/IEC 27001) i wymaganiami RODO;
  • DLP może blokować przesyłanie danych osobowych czy finansowych do modelu, zarówno z aplikacji, jak i z przeglądarki pracownika.

Uwaga: sam fakt „on-prem” niczego nie gwarantuje. O poziomie ochrony decyduje konfiguracja: segmentacja sieci, zarządzanie kluczami, rotacja uprawnień, monitoring. Lokalny serwer z modelem otwartym na całą sieć firmową chroni dane słabiej niż dobrze skonfigurowany plan firmowy w chmurze.

Dochodzi do tego niezależność operacyjna: dostawca nie podmieni Ci modelu, cennika ani warunków w trakcie projektu.

Custom GPT: co naprawdę dzieje się z danymi?

Custom GPT nie ma własnych zasad ochrony danych. Dziedziczy je z planu ChatGPT, w którym działa. Stan na październik 2026 według dokumentacji OpenAI:

Plan Trenowanie modeli na Twoich danych Retencja Rezydencja danych w Europie
Free, Go, Plus, Pro (konta osobiste) domyślnie mogą być używane; wyłączasz w Ustawieniach > Kontrola danych („Improve the model for everyone”) czat zostaje do usunięcia; usunięty znika z systemów w ciągu 30 dni, chyba że OpenAI musi go zachować z powodów prawnych lub bezpieczeństwa; czat tymczasowy do 30 dni nie dotyczy (opcja dla planów firmowych i API)
Business domyślnie nie czas przechowywania kontroluje administrator; usunięte i niezapisane rozmowy znikają w ciągu 30 dni wdrażana stopniowo i tylko dla przechowywania; logi monitoringu nadużyć oraz czasowa kopia promptów i odpowiedzi trafiają do USA
Enterprise, Edu domyślnie nie czas przechowywania ustala administrator; usunięte rozmowy znikają w ciągu 30 dni Europa (EOG + Szwajcaria) dla nowych przestrzeni roboczych; opcjonalnie także inferencja na GPU w regionie
API domyślnie nie (od 1 marca 2023 r.) logi monitoringu nadużyć do 30 dni; Responses API domyślnie przechowuje stan aplikacji 30 dni; pliki do czasu usunięcia projekt z regionem Europa (eu.api.openai.com) po zatwierdzeniu kontroli retencji, np. Zero Data Retention; dla modeli wydanych od 5 marca 2026 r. stawka wyższa o 10%

Źródła: Enterprise privacy, How your data is used to improve model performance, Data controls in ChatGPT, Chat and file retention in ChatGPT, Data residency for ChatGPT, Where your ChatGPT Business content is stored, Data controls in the OpenAI API.

Szczegóły, o które pytają zespoły prawne i IT:

  • Ocena odpowiedzi na kontach osobistych. Kliknięcie kciuka w górę lub w dół pozwala OpenAI użyć do trenowania całej rozmowy, nawet po wyłączeniu trenowania. W planach Business, Enterprise i Edu ocena nie daje takiej zgody.
  • Twórca GPT nie widzi rozmów użytkowników ze swoim GPT.
  • Pliki wiedzy są przechowywane do usunięcia GPT, a potem usuwane w ciągu 30 dni. GPT odpowiada na ich podstawie, więc każdy, kto ma dostęp do GPT, może w rozmowie wydobyć ich treść. Nie wgrywaj tam niczego, czego ta osoba nie powinna zobaczyć.
  • Akcje i aplikacje wysyłają fragmenty rozmowy do zewnętrznych usług. OpenAI zaznacza, że nie audytuje ani nie kontroluje, jak te usługi używają danych i jak je przechowują.
  • Rezydencja danych nie obejmuje GPT innych twórców, a w przestrzeni z rezydencją nie udostępnisz GPT „każdemu”.
  • Szyfrowanie i audyty: AES-256 dla danych w spoczynku, TLS 1.2+ w transmisji; Business, Enterprise i API przeszły audyt SOC 2 Type 2. Dla Business, Enterprise i API OpenAI podpisuje umowę powierzenia przetwarzania danych (DPA).
  • Zero Data Retention to nie „brak trenowania”. Dane z API i tak domyślnie nie służą do trenowania. ZDR wyłącza zapisywanie treści w logach monitoringu nadużyć i wymusza store=false w Responses i Chat Completions, a OpenAI przyznaje ją po zatwierdzeniu wniosku.

Na tej podstawie ustal zasady korzystania:

  • tylko plan firmowy (Business lub Enterprise), nie prywatne konta pracowników, bo na kontach osobistych rozmowy domyślnie mogą trafiać do trenowania;
  • polityka, jakie dane mogą trafić do GPT: tylko niepoufne lub zanonimizowane;
  • logowanie przez SSO (SAML) i centralne zarządzanie użytkownikami;
  • wgląd w aktywność: w Enterprise administratorzy mają dostęp do dziennika rozmów i GPT przez Compliance API, w Business administrator może przeglądać, eksportować i usuwać rozmowy w przestrzeni roboczej;
  • przy pracownikach pierwszej linii także DLP, które blokuje np. wklejanie numerów PESEL czy danych kart płatniczych.

Wskazówka: zasada „minimum danych, maksimum efektu”. Wiele procesów da się obsłużyć szablonami, schematami i danymi technicznymi, bez wgrywania surowych, wrażliwych dokumentów.

Gdzie Custom GPT niesie dodatkowe ryzyka

Pierwsze to ataki prompt injection i jailbreak, czyli próby „namówienia” modelu do złamania własnych reguł, także przez treść stron i plików, które model czyta. Ryzyko rośnie, gdy GPT ma akcje lub aplikacje, bo udany atak może wtedy uruchomić działanie w zewnętrznym systemie. To samo dotyczy modeli lokalnych podłączonych do narzędzi.

Zanim model trafi do wdrożenia, w chmurze czy lokalnie, przetestuj go zamiast opierać się na deklaracjach producenta. Benchmark b3 (backbone breaker benchmark), opisany w pracy Breaking Agent Backbones, mierzy podatność modeli używanych w agentach AI na konkretne klasy ataków. Autorzy sprawdzili 34 modele na ponad 194 tys. ataków zebranych od ludzi: lepsze rozumowanie poprawiało bezpieczeństwo, a rozmiar modelu nie korelował z bezpieczeństwem.

Drugie ryzyko jest operacyjne: zmiany po stronie dostawcy. OpenAI aktualizuje i wycofuje modele, a gdy model przestaje być dostępny, GPT automatycznie przechodzi na podobny bieżący model (GPTs in ChatGPT). Wycofanie samych Custom GPT pokazuje, że to samo może spotkać całe narzędzie.

Kiedy postawić na własny model LLM

Własny, self-hosted LLM ma sens, gdy:

  • firma pracuje na bardzo wrażliwych danych (finanse, medycyna, sektor publiczny, infrastruktura krytyczna),
  • system musi działać w środowisku air-gapped albo przepisy i umowy ograniczają, gdzie dane mogą być przetwarzane,
  • AI ma być mocno zintegrowana z wewnętrznymi systemami, a wolumen zapytań jest duży i stały.

Przykład: w energetyce system obsługujący dokumentację techniczną, procedury bezpieczeństwa i opisy awarii może nie mieć prawa do żadnego połączenia z internetem, nawet pośredniego. Usługa chmurowa wtedy odpada. Zostaje model na serwerach w strefie o najwyższych zabezpieczeniach.

Zyskujesz:

  • kontrolę nad tym, gdzie fizycznie są dane i jaka wersja modelu działa,
  • koszt sprzętu zamiast opłat za tokeny, co przy dużym wolumenie daje przewidywalny budżet,
  • niezależność od zmian w ofercie i zasadach dostawcy.

Ceną jest dłuższy czas wdrożenia, większa złożoność projektu i zespół, który to środowisko utrzyma.

Kiedy zacząć od Custom GPT

Asystent w ChatGPT to dobry start, gdy:

  • chcesz szybko sprawdzić use case na prawdziwej pracy zespołu,
  • dane nie są krytyczne (FAQ, materiały marketingowe, publiczne specyfikacje, opisy produktów),
  • nie masz infrastruktury GPU ani ludzi do jej utrzymania.

Dwie zasady na październik 2026. Po pierwsze, korzystaj z planu Business lub Enterprise: tylko w planach firmowych dane domyślnie nie trafiają do trenowania, a na kontach osobistych nowych GPT i tak już nie utworzysz. Po drugie, buduj z myślą o migracji do wtyczek. Instrukcje GPT staną się umiejętnością (skill) we wtyczce, pliki wiedzy plikami referencyjnymi, ale akcje niestandardowe nie przenoszą się automatycznie i trzeba je odtworzyć, np. przez serwer MCP (FAQ migracji, Plugins in ChatGPT and Codex).

Jeśli asystent ma obsługiwać klientów na Twojej stronie, Custom GPT się nie nada, bo nie da się go osadzić poza ChatGPT. Pilotaż buduje się wtedy na API (koszt policzysz w Kalkulatorze tokenów AI) albo od razu na własnym modelu.

Typowa ścieżka: asystent w ChatGPT pomaga zespołowi sprzedaży przygotowywać oferty, a gdy rośnie skala i wrażliwość danych, do analizy umów i danych z CRM dochodzi lokalny model. Pilotaż w chmurze służy wtedy do przetestowania use case’ów i promptów przed zaprojektowaniem docelowej architektury.

Własny LLM vs Custom GPT - porównanie w pigułce

Cecha Własny model LLM (self-hosted) Custom GPT (ChatGPT)
Koszt sprzęt GPU (zakup lub wynajem), energia, czas zespołu; brak opłat za token, ale potrzebna pamięć GPU rośnie z liczbą równoległych rozmów i długością kontekstu abonament za użytkownika miesięcznie w planie Business (od 2 użytkowników) albo Enterprise (cena ustalana z działem sprzedaży), cennik ChatGPT
Kontrola danych dane i wagi w Twojej infrastrukturze, możliwa praca bez internetu dane przetwarza OpenAI; w planach firmowych domyślnie bez trenowania, retencja i rezydencja zależne od planu
Czas startu pilotaż na jednym serwerze: jedna komenda w Ollama; produkcja: dodatkowo integracje, uprawnienia, monitoring i testy konfiguracja w edytorze bez kodu, ale nowe GPT tylko w przestrzeniach firmowych, a docelowo wtyczki
Utrzymanie po Twojej stronie: sprzęt, aktualizacje modelu i silnika, bezpieczeństwo infrastruktura po stronie OpenAI; Ty utrzymujesz instrukcje, pliki i uprawnienia, a model i funkcje zmieniają się po stronie dostawcy (migracja GPT do wtyczek przed 11 grudnia 2026 r.)
Gdzie działa w dowolnej aplikacji przez własne API (Ollama, llama.cpp i vLLM udostępniają API zgodne z OpenAI) tylko w ChatGPT, dla zalogowanych użytkowników; na stronę lub do aplikacji potrzebne jest API

Decyzja rzadko jest zero-jedynkowa. Możliwa jest architektura hybrydowa: lokalny model do danych wrażliwych i krytycznych procesów wewnętrznych, a usługa chmurowa do mniej wrażliwych zadań, gdzie liczy się szybkość i wygoda.

Jak domknąć temat bezpieczeństwa w projektach AI

Niezależnie od wariantu zacznij od rozrysowania całego przepływu danych: od użytkownika, przez aplikację, po model i logi. Sam model to tylko jeden z klocków. Typowe elementy systemu:

  • ścisła kontrola dostępu: model widzi tylko to, co powinien, a użytkownicy są autoryzowani centralnie (SSO, role, uprawnienia),
  • audyt logów: użycia modelu i zmian konfiguracji, z integracją z istniejącym SIEM,
  • wykrywanie anomalii, np. nagłego wzrostu liczby zapytań o konkretny typ danych,
  • DLP: blokowanie wycieków na poziomie treści, także w interfejsach czatu.

Przy lokalnym LLM te mechanizmy łatwo spiąć z istniejącymi procesami bezpieczeństwa. Przy Custom GPT dobierasz je tak, by jak najwięcej kontroli zostało po stronie firmy, mimo że model działa poza firmową infrastrukturą.

Open-weight vs modele komercyjne: kto jest bezpieczniejszy?

Opinia „modele otwarte są bardziej ryzykowne, bo są otwarte” to tylko część prawdy. Dostawcy komercyjni mają zespoły bezpieczeństwa, zewnętrzne audyty i programy bug bounty. Modele open-weight możesz za to sam audytować, testować i wdrożyć w dokładnie takiej architekturze, jakiej potrzebujesz, a ich rozmiar nie przesądza o odporności na ataki (patrz benchmark b3 wyżej).

Różnica leży głównie w tym, kto i jak wdraża model. Ta sama Llama czy ten sam Mistral może być niebezpieczny w źle skonfigurowanym środowisku i bezpieczny w infrastrukturze z DLP, segmentacją sieci i regularnymi testami.

Jak przygotować organizację do wyboru ścieżki

Zanim firma zdecyduje „robimy własny LLM” albo „idziemy w Custom GPT”, potrzebna jest krótka analiza z udziałem IT, bezpieczeństwa i działu prawnego:

  • jakimi danymi będzie karmiony model: tylko publicznymi, mieszanymi czy wysoko wrażliwymi,
  • jak wygląda obecna infrastruktura: czy są serwery GPU, czy jest gotowość na klaster pod LLM,
  • jakie są kompetencje IT, DevOps i data: kto utrzyma system w ruchu,
  • jakie regulacje dotyczą firmy i gdzie są największe ryzyka prawne.

Wynik bywa różny. W firmie przemysłowej na start może wystarczyć asystent w chmurze na danych technicznych, a lokalny model ma sens dopiero przy analizie danych produkcyjnych. W banku wynik bywa odwrotny: żadnej chmury na wrażliwych danych, start od własnego modelu.

Najczęstsze pytania

Czy lokalny LLM jest bezpieczniejszy od chmurowego typu Custom GPT?

Jeśli jest dobrze zaprojektowany, tak: dane nie wychodzą poza Twoją infrastrukturę, a sieć, uprawnienia, DLP i monitoring ustawiasz sam. Źle skonfigurowany lokalny serwer może jednak chronić dane słabiej niż plan firmowy w chmurze.

Jak uruchomić własny model LLM na serwerach firmy?

Wybierz model open-weight z licencją pasującą do firmy (na Apache 2.0 są np. Qwen3, Mistral Small 3.2, gpt-oss i polski Bielik), uruchom go w Ollama na pilotaż albo w vLLM dla wielu użytkowników, policz pamięć GPU (wagi plus KV cache) i wystaw API tylko w sieci firmowej, za uwierzytelnianiem. Przykład: 4-bitowy Qwen3-8B z kontekstem 32 768 tokenów potrzebuje ok. 10 GB pamięci GPU.

Czy OpenAI trenuje modele na danych z Custom GPT?

Zależy od planu. W ChatGPT Business, Enterprise i Edu domyślnie nie. Na kontach osobistych (Free, Go, Plus, Pro) rozmowy domyślnie mogą być używane do trenowania, dopóki nie wyłączysz opcji „Improve the model for everyone”.

Kiedy naprawdę opłaca się wdrożyć własny model LLM?

Przy danych o wysokim stopniu poufności, w branży silnie regulowanej, w środowisku air-gapped albo przy głębokiej integracji z wewnętrznymi systemami i dużym, stałym wolumenie zapytań.

Kiedy lepiej wejść w Custom GPT?

Gdy chcesz szybko sprawdzić korzyści z AI na mało wrażliwych lub zanonimizowanych danych i nie masz jeszcze infrastruktury GPU. Korzystaj wtedy z planu firmowego i licz się z migracją GPT do wtyczek przed 11 grudnia 2026 r.