Sovereign AI - dlaczego teraz

Przez dekadę domyślny scenariusz „dodajmy AI do produktu" brzmiał: zakładasz konto u amerykańskiego hyperscalera, pompujesz dane, płacisz od tokenu, dowozisz. Dla FinTech, MedTech, GovTech i każdej firmy pracującej z regulowanymi danymi w UE - ten scenariusz umarł.

Nie „jest pod presją". Nie „staje się trudniejszy". Umarł.

Zabiły go trzy rzeczy, i stało się to szybciej niż zauważyła większość działów zakupowych.

W skrócie. Chmurowe API modeli językowych przestało być bezpiecznym domyślnym wyborem dla firm z regulowanymi danymi w UE, bo zamykają je razem AI Act (logowanie), NIS2 (24 godziny na zgłoszenie incydentu u dostawcy) i DORA (ocena ryzyka stron trzecich). Zastępuje je inferencja na własnym sprzęcie z otwartymi wagami, kontekstem z grafu i logami zgodności.

1 · Regulacyjna triada

AI Act (Rozporządzenie 2024/1689) klasyfikuje większość business-critical AI jako wysokiego ryzyka. Systemy wysokiego ryzyka wymagają oceny zgodności, post-market monitoringu i - co kluczowe - logowania, które udowadnia co system zrobił, kiedy i w czyim imieniu. Chmurowe API LLM tego domyślnie nie dają. Dostajesz rate-limited REST endpoint i dashboard z użyciem.

NIS2 (Dyrektywa 2022/2555) rozszerzyła obowiązki krytycznej infrastruktury na znacznie większy zbiór operatorów. Usługi finansowe, zdrowie, infrastruktura cyfrowa, administracja publiczna - wszystko w zakresie. Bezpieczeństwo łańcucha dostaw jest wymienione wprost: jeśli Twój dostawca AI ma naruszenie, regulator chce wiedzieć w 24 godziny. Powodzenia w egzekwowaniu takiego SLA przez portal wsparcia hyperscalera.

DORA (Rozporządzenie 2022/2554) jest dedykowane sektorowi finansowemu, żyje od stycznia 2025. Wymaga zarządzania ryzykiem ICT, raportowania incydentów i oceny ryzyka stron trzecich - z kontraktowym zębem. „Dostawca LLM ma SOC2" nie spełnia art. 28 DORA. Potrzebujesz udokumentowanych dowodów, że cała ścieżka AI - razem z inferencją - jest pod Twoim reżimem ryzyka ICT.

Każde z osobna byłoby do przejścia. Razem - zamykają kategorię cloud AI dla każdego, kto traktuje compliance poważnie.

2 · Drzwi data residency

Klienci już pytają, nawet jeśli uprzejmie: „gdzie fizycznie znajdują się nasze dane i kto ma do nich dostęp?"

Rok temu wystarczała odpowiedź „region UE, zaszyfrowane, SOC2". Już nie wystarcza - nie dla trzech klas klienta:

• Banki - bo ich własny regulator już pyta.
• Szpitale i medyczny SaaS - bo dane pacjenta plus jurysdykcja USA plus RODO to trójwęzeł, którego nikt nie chce rozplątywać w sądzie.
• Sektor publiczny - bo ramy zakupowe zacieśniły się wokół wymogów „sovereign cloud" w Niemczech, Francji, Polsce i na północy Europy.

„Region UE" było twierdzeniem marketingowym. „Na sprzęcie, który posiadamy, w colo, które fizycznie kontrolujemy" to twierdzenie inżynieryjne. To drugie zamyka deale.

3 · Problem danych treningowych, o którym nikt nie mówi

Za każdym razem, gdy deweloper kopiuje funkcję do ChatGPT albo Claude.ai, żeby „szybko zapytać", przekazuje Twoją wewnętrzną logikę do cudzego zbioru treningowego - albo przynajmniej do ich logu retencji.

Tak, taryfy enterprise mówią „nie trenujemy na Twoich danych". Przeczytaj DPA uważnie: okna retencji, wyjątki dla monitoringu nadużyć, zgodność z wezwaniami sądowymi. Żadne z tego nie brzmi „dane nigdy nie opuściły Twojej kontroli". To brzmi „dostawca obiecuje być ostrożny z danymi, które już wyszły spod Twojej kontroli".

Dla kodu FinTech, algorytmów medycznych, integracji rządowych - „ostrożna opieka przez stronę trzecią" nie jest tym samym co „nigdy nie opuściły budynku". Twój CTO to wie. Twój compliance officer to wie. Pytanie brzmi, czy Twoja praktyka inżynierska nadgoniła.

Co zastępuje cloud AI

Trzy wymagania, w tej kolejności:

1. Inferencja on-prem. Open-weights modele (Qwen, Llama, Mistral) serwowane na Twoim sprzęcie przez vLLM. Skwantyzowane (AWQ albo GPTQ, 4-bit), żeby zmieścić się na pojedynczym enterprise GPU - NVIDIA RTX PRO 5000 Blackwell 48GB, AMD Radeon Pro W7900 48GB, albo na węźle H100 dla wdrożeń flotowych. Zero egress, pełna powierzchnia audytu.
2. Kontekst wzbogacony grafem. RAG z graf-bazą znającą kod (my używamy ArcadeDB), żeby model miał dostęp do realnej struktury Twojego repo - nie tylko do chunku z promptu. Halucynacje mierzalnie spadają.
3. Logi zgodności jako obywatel pierwszej kategorii. Każdy prompt, response, fix, wywołanie toola - zalogowane pod schemę, o którą zapyta Twój audytor. Nie zrzuty PDF. Machine-readable, schema-stable, eksportowalne.

Taki jest stack. Więcej pracy niż curl https://api.openai.com/.... I jedyny stack, który przeżywa audyt DORA.

Co budować, już teraz, jeśli jesteś w tej łódce

• Zrób triage obecnego użycia AI. Dokąd idzie kod źródłowy? Dokąd idą dane klientów? Które z tych przepływów mają DPA, które realnie przeczytałeś?
• Policz koszt uczciwie. Sprzęt (pojedynczy node H100) plus ops nie jest tani, ale jest przewidywalny i się amortyzuje - inaczej niż rachunki per-token, które rosną z sukcesem produktu.
• Planuj multi-agent, nie single-prompt. Generacja kodu, przegląd bezpieczeństwa, generacja testów, logowanie zgodności - oddzielne agenty z oddzielnymi promptami sprawiają, że system da się audytować. Jeden mega-prompt do chmurowego LLM - nie da się.

To właśnie buduję jako SADP - samodzielnie finansowaną, suwerenną platformę AI do wytwarzania kodu dla regulowanych MŚP. Jeśli cokolwiek z powyższego opisuje Twój 2026 - pogadajmy.