On-premise vs. chmura UE dla agentów AI: macierz decyzyjna dla firm w Europie

Sześć kryteriów w szczegółach: wrażliwość danych i zgodność z przepisami (RODO, przepisy branżowe), koszty (CapEx/OpEx, ekonomia GPU kontra ekonomia tokenów), latencja, skalowanie, nakład operacyjny i know-how oraz dostępność modeli. Ten artykuł zawiera macierz decyzyjną i konkretne rekomendacje dla każdego scenariusza.

Rezydencja danych a suwerenność danych: kluczowe rozróżnienie

Najczęstsze nieporozumienie pojęciowe w rozmowach z klientami w regionie DACH (Niemcy, Austria, Szwajcaria) dotyczy dwóch terminów, które nie oznaczają tego samego. Rezydencja danych to fizyczne miejsce, w którym dane są przechowywane i przetwarzane. Suwerenność danych to jurysdykcja prawna, której dane podlegają, łącznie z zasięgiem eksterytorialnym, takim jak amerykański CLOUD Act z 2018 r. Suwerenna chmura spełnia oba warunki: operator, infrastruktura i kontrola prawna znajdują się w wybranej jurysdykcji. Rezydencja jest więc konieczna, ale niewystarczająca.

W praktyce oznacza to, że nawet jeśli dane znajdują się wyłącznie we Frankfurcie, operator amerykańskiego hiperskalera pozostaje amerykańską osobą prawną podlegającą CLOUD Act. Suwerenność w ścisłym sensie wymaga jednego z trzech modeli: dedykowanej suwerennej chmury hiperskalera (na przykład dostępnej od stycznia 2026 r. AWS European Sovereign Cloud w Brandenburgii albo Microsoft Sovereign Cloud), stosu obsługiwanego przez partnera (T-Systems z Google, Bleu z Microsoftem we Francji) albo dostawcy spoza USA. Suwerenne chmury hiperskalerów przenoszą obsługę i dostęp do UE, ale ich ochrona przed CLOUD Act pozostaje prawnie sporna. Microsoft France przyznał 10 czerwca 2025 r. pod przysięgą przed francuskim Senatem, że nie może zagwarantować, iż dane nigdy nie trafią na polecenie do amerykańskich organów.

Do tego dochodzi specyfika regionu DACH: w sektorze MŚP on-premise rzadko oznacza serwer w biurze, a zwykle dedykowane środowisko w neutralnym operatorsko centrum danych kolokacyjnym w Niemczech, Austrii lub Szwajcarii (Equinix Frankfurt, Interxion, Digital Realty Zürich, NTT Vienna). Prawdziwy bare metal będący własnością klienta pozostaje istotny dla dużych grup przemysłowych, organizacji powiązanych z obronnością oraz klientów BFSI z wyraźnym poleceniem organu nadzoru.

Sześć kryteriów decyzyjnych

1. Wrażliwość danych i zgodność z przepisami

Dane podstawowe klientów, dane pracowników, dokumentacja medyczna czy własność intelektualna objęta kontrolą eksportu przesuwają architekturę w stronę rozwiązań suwerennych lub on-premise. Oprócz RODO i szwajcarskiej FADP/revDSG (obowiązującej od 1 września 2023 r.) zastosowanie mają przepisy branżowe: BaFin/FINMA dla BFSI, KRITIS/NIS2 dla infrastruktury krytycznej, TISAX dla motoryzacji oraz DigiG i § 393 SGB V dla danych medycznych. Konkretna, wiążąca data: od 1 lipca 2025 r. BSI C5 Typ 2 jest obowiązkowy przy przetwarzaniu danych pacjentów w chmurze. Niektóre usługi hiperskalerów nie mają jeszcze tej atestacji, co trzeba sprawdzić przy zakupie. Ta uwaga nie zastępuje porady prawnej.

2. Koszty: CapEx/OpEx, GPU kontra tokeny

Self-hosting przy stałym obciążeniu jest tańszy w przeliczeniu na token, a zarządzane API są tańsze przy skokowych, eksploracyjnych obciążeniach. Bezczynny GPU to najdroższy CapEx. Architektoniczne czynniki kosztowe on-premise to amortyzacja serwerów GPU (zwykle 3-4 lata), energia (taryfy przemysłowe w regionie DACH około 0,18-0,35 EUR/kWh), chłodzenie (PUE 1,2-1,4 w nowoczesnych centrach danych w regionie DACH), łączność, eksploatacja i licencje na oprogramowanie. Pojedyncza szafa rack 130 kW pobiera przy pełnym obciążeniu rzędu 1,1 GWh rocznie.

3. Latencja

Inferencja kolokowana (silnik w tym samym regionie co orkiestracja agentów) zapewnia latencję sieci rzędu kilku milisekund. Wywołania transatlantyckie kosztują około 80-120 ms w obie strony plus handshake TLS, a przy wieloetapowych agentach wywołujących narzędzia ten koszt się mnoży. Dla porównania: dla 30 dni do 30 lipca 2026 r. Microsoft podaje medianę 94 ms w obie strony między Germany West Central (Frankfurt) a East US (statystyki latencji Azure). Przy UX z odpowiedzią poniżej sekundy i kilku rundach wywołań narzędzi wywołania transatlantyckie są niepraktyczne.

4. Skalowanie

Zarządzane API skalują się elastycznie bez planowania pojemności. Stosy self-hosted wymagają rezerw: o sprzęcie decyduje rachunek pamięci GPU. Model 70 B potrzebuje w BF16 około 140 GB na same wagi, w FP8 około 70 GB, a w AWQ-INT4 około 35 GB. Przy niskiej współbieżności wystarczy 1x H200 (141 GB); przy produkcyjnych rozmiarach batcha zwykle potrzeba 2x H100 lub 2x MI300X. Modele klasy 405 B wymagają równoległości tensorowej na wielu GPU (na przykład 8x H200 lub węzeł GB200 NVL72). Modele z bilionami parametrów wykraczają poza możliwości niemal wszystkich MŚP w regionie DACH, tu droga prowadzi przez zarządzane API lub suwerenny bursting GPU.

5. Nakład operacyjny i know-how

Utrzymanie vLLM, SGLang, Triton lub NVIDIA NIM w skali produkcyjnej wymaga głębokich kompetencji z zakresu platform engineeringu, których większość MŚP w regionie DACH nie ma we własnym zespole. Zespół dyżurny 24x7, który radzi sobie z zawieszeniami NCCL i trybami awarii GPU, jest w regionie DACH trudno dostępny. Uwaga dotycząca wyboru silnika inferencji: Hugging Face 11 grudnia 2025 r. przeniósł TGI w tryb utrzymaniowy i kieruje nowe wdrożenia do vLLM lub SGLang (stan na 2026 r.).

6. Dostępność modeli

Zarządzane API wygrywają, gdy różnorodność modeli ma kluczowe znaczenie. Samo Azure AI Foundry dodało w 2025 r. między innymi DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5 i Llama 4. Suwerenne API (IONOS AI Model Hub, Open Telekom Cloud AI Foundation Services, Swisscom Swiss AI Platform, Infomaniak) obsługują modele open source, takie jak Teuken-7B, Llama 3/4, Mistral, DeepSeek oraz otwarty szwajcarski Apertus (EPFL/ETH/CSCS, opublikowany 2 września 2025 r.). Jeśli potrzebny jest konkretny model jako permisywny open weight, można go uruchamiać identycznie w kontenerach NIM lub OCI w różnych chmurach i on-premise.

Macierz decyzyjna: kryterium a model operacyjny

Uzupełniająca heurystyka do decyzji szczegółowej: za zarządzanymi API przemawiają dane publiczne/wewnętrzne, skokowe obciążenie, duża różnorodność modeli i brak zespołu platformowego. Za self-hostingiem przemawiają dane poufne/regulowane, wysokie stałe obciążenie, latencja ogonowa poniżej 500 ms i ścisła suwerenność.

Konkretny przykład obliczeniowy: próg opłacalności

Praktyczna reguła krążąca w zespołach platformowych w regionie DACH ułatwia podjęcie decyzji (stan na 2026 r.): przy stałym obciążeniu inferencyjnym rzędu 8-12 GPU odpowiadających H100 self-hosting w suwerennej chmurze lub on-premise zwykle staje się tańszy w przeliczeniu na token niż ekonomia zarządzanych API. Powyżej około 30 ekwiwalentów H100 różnica szybko rośnie.

Migracja z zarządzanego API na self-hosting ma sens, gdy spełnione są co najmniej dwa z poniższych warunków:

• Miesięczne wydatki na zarządzane API przekraczają koszt bieżący (run rate) około 10 H100 w suwerennej chmurze.
• Nowe polecenie organu nadzoru (BaFin/FINMA/BSI) wymaga wykazywalnej kontroli, której nie można delegować.
• Model, na którym opiera się Twój agent, staje się dostępny jako permisywny open weight (Llama, Mistral, Apertus).
• Roadmapa wymaga fine-tuningu, który nie jest możliwy w zarządzanym API.
• Przegląd prawny klasyfikuje dostawcę jako ryzyko koncentracji (DORA).

Zaplanuj wtedy migrację z wyprzedzeniem około 6-9 miesięcy.

Poniżej progu opłacalności wynoszącego 8-12 H100 zarządzane API wygrywają pod względem TCO. Konkretne ceny tokenów i rachunek H100 kontra H200 kontra B200 wymagają osobnej analizy FinOps.

Rekomendacja według scenariusza

MŚP (200-2000 pracowników, mieszana wrażliwość danych, środowisko M365, brak zespołu platformy ML): z doświadczenia model hybrydowy obejmuje ponad 70 procent projektów greenfield MŚP w regionie DACH. Rekomendacja: Azure West Europe lub Germany West Central z Azure OpenAI we wdrożeniu Data Zone EUR, warstwa RAG on-premise lub w kolokacji z bazą wektorową dla poufnych dokumentów, podłączona przez ExpressRoute i Private Endpoint. Poufne fragmenty nigdy nie opuszczają Niemiec, do promptu LLM trafiają wyłącznie już zanonimizowane wycinki. Warstwa bramy LiteLLM hostowana we własnym zakresie steruje budżetami i umożliwia fallback na europejską platformę, taką jak Mistral La Plateforme. Nie nadaje się do systemów core BFSI, niejawnej własności intelektualnej ani danych pacjentów po 1 lipca 2025 r.

Branża regulowana (BFSI, ochrona zdrowia, sektor publiczny, sektor zbliżony do obronności, pełna suwerenność): suwerenna chmura jako główna droga. Rekomendacja: STACKIT lub Open Telekom Cloud / T Cloud Public z umową z niemieckim podmiotem prawnym i kontrolą operatora. LLM przez PhariaAI-as-a-Service na STACKIT lub otwarte modele (Llama 3/4, Mistral, Teuken-7B, Apertus) przez vLLM/NIM na dedykowanych instancjach GPU. Baza wektorowa (Weaviate, Qdrant, pgvector) w tej samej suwerennej chmurze, sekrety w HashiCorp Vault z HSM seal na HSM Utimaco, ruch wychodzący domyślnie blokowany z allowlistą. Dla najwyższej klasy danych opcjonalnie inferencja on-premise przez NVIDIA NIM na Red Hat OpenShift AI w centrum danych klienta. Realny kompromis: wciąż istniejąca luka funkcjonalna wobec hiperskalerów, którą T-Systems chce zamknąć do końca 2026 r. (zobowiązanie z roadmapy).

Korporacja (DAX 40, SMI 20, ATX prime, formalna polityka wyjścia z chmury zgodnie z DORA/MaRisk/FINMA): odporność multi-cloud z suwerenną warstwą. Główna chmura (Azure Niemcy/UE) dla większości obciążeń, chmura zapasowa (AWS lub Google) dla odporności, a API modeli abstrahowane przez bramę AI. Przenośność modeli dzięki otwartym modelom (Llama 4, Mistral, Apertus, Teuken) w postaci kontenerów NIM/OCI, które działają identycznie we wszystkich chmurach i on-premise. Opcjonalna suwerenna warstwa (STACKIT lub T Cloud Public) dla najbardziej wrażliwych obciążeń, z udokumentowanymi ścieżkami migracji. Najwyższa klasa kosztów, prawie nigdy nie pasuje do MŚP.

Uwaga dotycząca Szwajcarii: FADP/revDSG to nie RODO i nie wolno ich mieszać. Zaostrzenie stanowiska szwajcarskiego nadzoru („privatim”) z listopada 2025 r. zaleca podmiotom publicznym korzystanie z międzynarodowych usług SaaS dla danych wrażliwych wyłącznie przy szyfrowaniu end-to-end i kluczach przechowywanych przez klienta. Ekspozycja na CLOUD Act pozostaje w przypadku dostawców z USA nawet przy rezydencji danych w Szwajcarii.

Dla agencji i decydentów B2B

Wybór między on-premise, chmurą UE a hybrydą nie jest wyłącznie kwestią IT, lecz decyzją biznesową i dotyczącą compliance, która zapada na wczesnym etapie projektu i na lata kształtuje architekturę, koszty oraz zdolność sprzedażową. Dla agencji, które budują agentów AI dla klientów w Europie, jasne rozróżnienie rezydencji i suwerenności danych to najmocniejszy argument w negocjacjach z działem zakupów i działem prawnym.

Blck Alpaca wspiera firmy B2B w całej Europie od macierzy decyzyjnej aż po produkcyjny stos z rezydencją danych w UE i wykazywalną suwerennością. W ramach kompaktowego proof of concept wyjaśniamy na Twoim rzeczywistym przypadku użycia klasy danych, budżet latencji, próg opłacalności i odpowiedni model operacyjny, zanim zainwestujesz w infrastrukturę. Odezwij się do nas w sprawie PoC B2B.