# Sovereign AI - dlaczego teraz

> Trzy unijne regulacje z 2025 roku pochowały domyślny scenariusz cloud AI dla regulowanych MŚP. Co go zastępuje i co warto zbudować.

- URL: https://artcode.software/pl/blog/sovereign-ai-dlaczego-teraz
- Author: Artur Kluz, Founder, AI architect (https://www.linkedin.com/in/arturkluz/)
- Published: 2026-04-18
- Updated: 2026-10-15
- Language: pl
- Tags: sovereign-ai, regulacje, strategia
- Publisher: ArtCode Software (https://artcode.software)

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](/pl#kontakt).