Trzy drogi wdrożenia: od air-gap po chmurę

Większość firm, z którymi rozmawiam, myśli o sovereign AI jako o wyborze binarnym: on-prem albo nic. Albo kupujesz serwer GPU i odpalasz modele open-weights we własnym racku, albo rezygnujesz z compliance i pompujesz wszystko do chmurowego API w USA.

Ta ramka jest błędna. I droga.

Są trzy tory deploymentu, nie dwa. Drugi tor to miejsce, w którym większość regulowanych MŚP realnie wyląduje. Ten artykuł mapuje wszystkie trzy, z głębokim wejściem w tor, który firmy najczęściej pomijają: Azure OpenAI z unijną granicą danych.

W skrócie. Wdrożenie AI w regulowanym MŚP to nie wybór między on-prem a chmurą w USA, tylko trzy tory: A (pełna suwerenność, air-gap), B1 (hybryda) i B2 (API chmurowe z unijną granicą danych, np. Azure OpenAI). Tor wybiera klasa danych, więc pierwszym krokiem jest klasyfikacja danych i mapa wdrożenia.

Fałszywy wybór binarny

"Chmura = niekompatybilne" kontra "on-prem = drogie" to zła rozmowa. Dobra rozmowa zaczyna się od prostszego pytania: o jakiej klasie danych mówimy?

Szkic wpisu blogowego Twojego działu marketingu nie potrzebuje tej samej granicy deploymentu co kod źródłowy klienta. Publiczny chatbot odpowiadający na pytania z publicznego FAQ nie potrzebuje tej samej granicy co wewnętrzne narzędzie czytające umowy klientów. Inne klasy danych, inne tory deploymentu, inne profile kosztowe.

Gdy podzielisz problem według klas danych, binarność się rozpada. Większość firm ma co najmniej trzy różne klasy. Większość firm będzie używać co najmniej dwóch z poniższych torów.

Tor A: Pełna suwerenność (air-gap)

To tor, o którym wszyscy myślą w pierwszej kolejności. Sprzęt on-prem, model open-weights (Qwen, Llama, Mistral), inferencja przez vLLM na własnym GPU. Zero egressu. Pełna powierzchnia audytu.

Szczegóły sprzętowe opisałem w kwietniowym poście o modelach kodowania. W skrócie: pojedyncza stacja NVIDIA RTX PRO 5000 Blackwell 48 GB odpala Qwen3-Coder-30B-A3B na AWQ 4-bit, 45-60 tok/s przy 64 K kontekstu. CapEx to około 40-60 tys. zł za maszynę. OpEx jest bliski zeru poza prądem i chłodzeniem - żadnych rachunków za zużycie od strony trzeciej, żadnych kluczy API dostawcy, żadnych dashboardów użycia, które kontroluje ktoś inny.

Tor A to właściwa odpowiedź, gdy klasa danych jest realnie wrażliwa. Kod źródłowy FinTech objęty Rekomendacją D KNF. Dokumentacja medyczna pod RODO. Dokumenty prawne objęte tajemnicą adwokacką. Wnioski grantowe klientów. Materiały due diligence M&A. Wszelkie dane, gdzie zdanie "opuściło budynek" jest niedopuszczalne w rozmowie o compliance.

Trade-off jest realny. Tor A daje najwyższą kontrolę i najpełniejszą powierzchnię compliance. DORA art. 28? Pokryty, bo nie ma zewnętrznego procesora. AI Act art. 12 - logowanie? Logi są Twoje, schemat jest Twój, retencja jest Twoja. Ścieżka audytu od promptu do odpowiedzi? Deterministyczny hash każdego szablonu promptu, każdego wywołania narzędzia, każdej odpowiedzi.

Daje też najwyższy koszt początkowy i wymaga kompetencji ops po Twojej stronie. Ktoś musi utrzymywać maszynę, aktualizować wersję vLLM, rotować wagi modelu gdy pojawi się nowy checkpoint. W pięcioosobowym fintechu ten "ktoś" to zwykle CTO w drugim kapeluszu.

Tor B1: Hybryda

Tor B1 rozdziela obciążenie. Wrażliwa inferencja zostaje on-prem (Tor A). Zadania niewrażliwe idą do API chmurowego (Tor B2, poniżej).

Kluczowa kompetencja to nie infrastruktura. To klasyfikacja danych. Potrzebujesz jasnej, pisemnej odpowiedzi na pytanie: które prompty zawierają dane regulowane, a które nie?

Konkretny przykład. Warszawski software house budujący integracje dla banku spółdzielczego ma trzy różne obciążenia: (1) generacja kodu pod kod integracyjny klienta, dotykająca wewnętrznych schematów API klienta i fixture'ów testowych z danymi produkcyjnymi; (2) szkicowanie wewnętrznych dokumentów HR, zawierających dane osobowe pracowników; (3) copy marketingowe i treści blogowe na własną stronę.

Obciążenie 1 idzie na Tor A. Obciążenie 2 idzie na Tor A lub B1, zależnie od wrażliwości PII i istniejącej granicy danych systemu HR. Obciążenie 3 idzie na Tor B2, bo najgorsza możliwa ekspozycja compliance przy publicznych treściach marketingowych wynosi w przybliżeniu zero.

Profil kosztowy jest umiarkowany: trochę CapEx na maszynę on-prem plus umiarkowany OpEx za użycie API chmurowego. Profil compliance wymaga dwóch osobnych polityk, czytelnych diagramów przepływu danych pokazujących które dane trafiają na który tor, i najlepiej macierzy decyzyjnej, którą zespół może stosować bez dzwonienia do CTO za każdym razem.

Tor B2: API chmurowe z unijną granicą danych (Azure OpenAI - głębokie wejście)

To tor, który firmy najczęściej pomijają, i to o niego dostaję najwięcej pytań. Oto pełna odpowiedź.

Czy regulowane MŚP może używać Azure OpenAI i pozostać compliant? Tak, pod określonymi warunkami. Nie domyślnie. Nie "od ręki". Ale tak, jeśli skonfigurujesz to poprawnie.

Oto co pokazuje research.

Co Azure OpenAI realnie oferuje MŚP

Nie potrzebujesz umowy enterprise. Azure OpenAI jest dostępne w modelu pay-as-you-go. Zakładasz subskrypcję Azure, wnioskujesz o dostęp do Azure OpenAI Service (krótki formularz, nie negocjacje zakupowe) i dostajesz provisioning w ciągu kilku dni.

Cennik to właściwa historia. Azure OpenAI działa w modelu pay-as-you-go - płacisz za to, co zużyjesz, bez stałej opłaty miesięcznej ani minimalnego zobowiązania. Microsoft publikuje szczegółowe stawki na swojej stronie (cennik Azure OpenAI).

Dla kontekstu: przy typowym użyciu przez dział marketingu - powiedzmy, szkicowanie pięćdziesięciu postów na blog i dwustu aktualizacji w social media miesięcznie - całkowity koszt jest zwykle niewielki; policz go na aktualnym cenniku Microsoftu.

Kalkulacja jest transparentna. Strona z cennikiem jest publiczna, a matematyka jest prosta.

EU Data Boundary: ustawienie, które naprawdę ma znaczenie

Azure OpenAI oferuje dwie opcje przetwarzania danych: Global Standard i Data Zone Standard.

Global Standard oznacza, że Microsoft może przetwarzać Twoje dane w dowolnym regionie Azure na świecie. Prompty i odpowiedzi mogą przechodzić przez infrastrukturę w USA. Dla regulowanych obciążeń w UE Global Standard odpada.

Data Zone Standard (EUR) oznacza, że przetwarzanie zostaje w granicy danych UE. Microsoft zobowiązuje się, że dane w spoczynku i w tranzycie pozostają w regionach UE. To jest ustawienie, którego potrzebujesz.

Haczyk: Poland Central nie ma Azure OpenAI. Usługa Azure OpenAI jest dostępna w podzbiorze regionów Azure, a Poland Central nie jest jednym z nich. Najbliższe regiony UE z dostępnością Azure OpenAI to Sweden Central i Germany West Central (Frankfurt). Oba są w granicy danych UE. Oba są technicznie poprawne dla polskich MŚP przy obecnych wytycznych regulacyjnych. Ale musisz to wiedzieć zanim otworzysz portal Azure i zaczniesz się zastanawiać dlaczego Polska nie pojawia się w dropdownie.

AI Act compliance: odpowiedzialność dzielona

To jest część, którą marketing Microsoftu pomija.

Microsoft zapewnia compliance infrastruktury. Azure OpenAI w ramach Data Zone EUR spełnia wymóg fizycznej rezydencji danych. SOC 2 Microsoftu, ISO 27001 i dokumentacja Azure EU Data Boundary dają Ci dowody po stronie dostawcy do Twojego własnego dossier compliance.

Czego Microsoft nie zapewnia: compliance AI Act dla Twojego przypadku użycia. Obowiązki AI Act spadają na wdrażającego (Ciebie), nie na dostawcę infrastruktury. Konkretnie:

• Art. 50 (transparentność): Jeśli wdrażasz chatbota, musisz poinformować użytkowników, że wchodzą w interakcję z systemem AI. To Twoja odpowiedzialność. Microsoft tego za Ciebie nie robi.
• Art. 12 (logowanie): Systemy AI wysokiego ryzyka muszą automatycznie logować zdarzenia podczas działania. Azure OpenAI daje Ci logi diagnostyczne przez Azure Monitor. Ale logi są surowe - musisz skonfigurować, które zdarzenia przechwytywać, jak długo je przechowywać i w jakim schemacie. Domyślny deployment Azure OpenAI loguje tyle, ile trzeba do rozliczeń, nie tyle, ile trzeba do audytu DORA.
• Kary: AI Act przewiduje grzywny do €15 mln lub 3% rocznego światowego obrotu za naruszenie obowiązków dostawców, wdrażających i innych podmiotów, w tym obowiązków przejrzystości z art. 50, oraz do €35 mln lub 7% za zakazane praktyki (art. 99); w obu przypadkach obowiązuje wyższa z kwot, a dla MŚP niższa. Kary dotyczą podmiotu, który naruszył własne obowiązki.

Model odpowiedzialności dzielonej: Microsoft obsługuje warstwę infrastruktury (bezpieczeństwo fizyczne, izolacja sieciowa, rezydencja danych). Ty obsługujesz warstwę aplikacyjną (klasyfikacja przypadku użycia, powiadomienia o transparentności, logowanie audytowe, ocena zgodności).

Kiedy Tor B2 jest właściwym wyborem

Tor B2 pasuje do klas danych publicznych lub niskiej wrażliwości:

• Treści publicznej strony internetowej, szkice blogowe, copy SEO, posty w mediach społecznościowych
• Chatboty dla klientów odpowiadające z publicznego FAQ lub publicznej dokumentacji
• Wewnętrzne szkice niezawierające danych klientów, PII ani treści regulowanych
• Materiały marketingowe, szablony outreachu sprzedażowego, opisy wydarzeń
• Dokumenty regulacyjne już publiczne (opublikowane wytyczne, publiczne specyfikacje przetargowe)

Nie pasuje do: kodu źródłowego pod NDA klienta, dokumentacji medycznej, danych transakcji finansowych, wewnętrznych opinii prawnych, odpowiedzi na RFP zawierających dane klienta, jakichkolwiek dokumentów objętych tajemnicą zawodową.

Uczciwe wady

Trzy rzeczy, które powinieneś wiedzieć zanim zwiążesz się z Torem B2.

Brak gwarancji cenowej. Azure OpenAI to PAYG. Stawki za zużycie konsekwentnie spadają w całej branży, ale Microsoft może zmienić cennik. Dla produktu, który skaluje się do milionów zapytań, ryzyko jest realne i powinieneś je modelować.

Wycofywanie modeli. Azure OpenAI wycofuje starsze wersje modeli. GPT-4o-mini nie będzie najtańszym modelem wiecznie. Gdy Microsoft wygasza model, masz okno na migrację; jego długość sprawdź w aktualnej polityce wycofywania modeli. To wykonalne, ale oznacza, że graf zależności Twojej aplikacji zawiera wersję modelu, a ta wersja ma datę ważności, którą ktoś musi śledzić.

Vendor lock-in jest umiarkowany, ale realny. Schemat API OpenAI jest szeroko zaimplementowany (open-source'owy vLLM go wspiera, większość bibliotek inferencyjnych go obsługuje). Przełączenie z Azure OpenAI na self-hostowany endpoint vLLM z tym samym interfejsem API jest technicznie proste. Ale operacyjny koszt przełączenia - przekonfigurowanie sieci, retesty, recertyfikacja dokumentacji compliance - nie jest zerowy. Buduj z warstwą abstrakcji od pierwszego dnia, a lock-in kurczy się do weekendowej migracji. Buduj bezpośrednio pod Azure SDK bez abstrakcji, a lock-in jest taki, jaki sobie zrobiłeś.

Który tor dla której klasy danych

Prosta macierz decyzyjna, wyprowadzona z obowiązków regulacyjnych typowego polskiego regulowanego MŚP:

• Umowy klientów, kod źródłowy, dokumentacja medyczna, dokumenty prawne, materiały M&A → Tor A. Klasa danych jest wrażliwa, ekspozycja regulacyjna jest wysoka, a koszt naruszenia compliance przekracza CapEx stacji GPU o rzędy wielkości.
• Wewnętrzne dokumenty HR, prognozy finansowe, wewnętrzne notatki strategiczne → Tor A lub B1. Jeśli Twój system HR ma już silną granicę danych, B1 może wystarczyć. Jeśli nie, domyślnie A.
• Treści publicznej strony, marketing, SEO, media społecznościowe, materiały eventowe → Tor B2. Dane są publiczne. Najgorsza możliwa ekspozycja to ktoś czytający szkic Twojego wpisu blogowego. Użyj najtańszej, najszybszej opcji.
• Obsługa klienta na podstawie publicznych dokumentów, chatboty FAQ → Tor B2. Materiał źródłowy jest publiczny. Prompty zawierają pytania użytkowników o publiczne informacje. Żadne dane regulowane nie przechodzą przez sieć.
• Odpowiedzi na RFP zawierające dane klientów, odpowiedzi due diligence, projekty pism regulacyjnych → Tor A lub B1. Jeśli odpowiedź odnosi się do infrastruktury lub danych konkretnego klienta, Tor A. Jeśli to ogólny opis możliwości, B2.

Prawdziwa robota

Większość regulowanych MŚP nie potrzebuje doktoratu z LLM-ów. Potrzebuje ćwiczenia z klasyfikacji danych i mapy deploymentu.

To właśnie dostarcza Audyt AI Readiness: sklasyfikowane zasoby danych, dopasowane tory deploymentu i checklistę compliance zmapowaną do regulacji, które dotyczą Twojego sektora. Zajmuje to około dwóch tygodni zaangażowania w niepełnym wymiarze i kosztuje od 4 900 zł netto.

Wzorzec, który widzę wielokrotnie: firmy przeinwestowują w Tor A dla obciążeń, które powinny być na Torze B2, jednocześnie niedoinwestowując Toru A tam, gdzie realnie ma znaczenie. Kupują serwer GPU za 50 tys. zł do generowania copy marketingowego, ale wysyłają analizę umów klientów do publicznego API. Koszt jest odwrócony i ryzyko jest odwrócone.

Najpierw popraw klasyfikację. Tory deploymentu wynikną z niej naturalnie.

---

Jeśli nie masz jeszcze bazowej klasyfikacji danych, najszybszym sposobem, by ją zdobyć, jest konsultacja „Czy AI ma sens w Twoim procesie?”: 60 minut online, 299 zł brutto, z krótkim pisemnym podsumowaniem do 3 dni roboczych. Omawiamy jeden proces i ustalamy, co sprawdzić dalej. Opłatę odliczam od audytu zamówionego w ciągu 30 dni.