# Suwerenny IDP: exit-by-design jako architektura

> Suwerenność to nie miejsce przechowywania danych, lecz przenośność workflowów. Jak everything-as-code i GitOps zamieniają strategię wyjścia z dokumentu w funkcję techniczną.

URL: https://eiac.dev/blog/suwerenny-idp-exit-by-design
Filar: Infrastructure-as-Code
Data: 2026-03-30
Tagi: platform-engineering, sovereignty, gitops, iac, eu

---

W [wprowadzeniu](/blog/platform-engineering-normalizacja-pracy) platforma była sposobem na uspójnienie pracy. Tu dochodzi drugi wymiar, równie strukturalny: **suwerenność** — zdolność organizacji do działania niezależnie od nacisków prawnych, handlowych czy geopolitycznych. Teza, którą rozwijam, jest prosta i niewygodna: o suwerenności nie decyduje to, *gdzie* leżą dane, lecz *czy potrafisz przenieść swoje workflowy* gdzie indziej, gdy przyjdzie potrzeba. Brzmi abstrakcyjnie? Do czasu, aż dostawca zmieni cennik albo licencję i nagle „gdzie leżą dane" przestaje być Twoim największym problemem.

<div class="callout">
<strong>Teza</strong>
<p>Data residency to nie to samo co suwerenność. Suwerenność jest własnością przenośności procesu, a jej technicznym nośnikiem jest „everything-as-code" — przesunięcie źródła zaufania z vendora do Twoich repozytoriów Git.</p>
</div>

## Legal sandwich: dlaczego residency nie wystarcza

Współczesne przedsiębiorstwo działa w „prawnej kanapce": sprzeczne jurysdykcje potrafią się wykluczać. Klasyczny przykład to napięcie między amerykańskim [CLOUD Act](https://en.wikipedia.org/wiki/CLOUD_Act) (który może zmusić firmę z USA do wydania danych niezależnie od tego, gdzie fizycznie leżą) a unijnym [RODO](https://eur-lex.europa.eu/eli/reg/2016/679/oj) (które takiego transferu zakazuje). Dostawca z USA przechowujący dane w Paryżu czy Frankfurcie i tak jest „w środku" — a wraz z nim jego klient.

Z tego płynie wniosek, który zmienia projektowanie platform: jeśli VCS, orkiestrator wdrożeń, dostawca tożsamości i asystent AI podlegają obcej jurysdykcji, to infrastruktura spełniająca data residency daje **tylko częściową suwerenność**. Każdy komponent platformy trzeba poddać tej samej ocenie, co warstwę infrastruktury.

## Pięć planes: architektura zamiast warstw

Suwerenny IDP projektuje się jako **planes** (płaszczyzny) — wymienne, komponowalne zdolności łączone przez standardowe API — a nie sztywne warstwy o monolitycznej zależności. Ta komponowalność jest fundamentem strategii wyjścia.

- **Developer Control Plane** — portal, IDE/CDE i suwerenne AI; punkt wejścia ukrywający złożoność.
- **Integration & Delivery Plane** — silnik mechaniczny: VCS ([Gitea](/katalog/gitea)/Forgejo), CI runners, orkiestrator i GitOps ([Argo CD](/katalog/argo-cd)/[Flux](/katalog/flux)).
- **Resource Plane** — compute/sieć/storage u dostawców suwerennych i globalnych (świadomie pofragmentowane, by ograniczyć ryzyko jednego dostawcy).
- **Security Plane** — lokalna tożsamość, sekrety i polityki (rozwijamy w [Security Plane](/blog/security-plane-sekrety-tozsamosc-policy)).
- **Observability Plane** — metryki, logi, tracing oraz FinOps/GreenOps.

Każda płaszczyzna jest wymienna — to czyni „exit" wykonalnym, a nie życzeniowym.

## Everything-as-code + GitOps = exit-by-design

Sercem podejścia jest bezkompromisowe egzekwowanie „everything-as-code". Definiując całą infrastrukturę — od load balancerów u dostawcy suwerennego po bucket S3 u globalnego — w deklaratywnym kodzie, traktujesz ją jako jednorazową i odtwarzalną. Wybór narzędzia ma tu znaczenie: ze względu na ryzyko zmian licencyjnych warto trzymać się silnika otwartego i fundacyjnego, jak [OpenTofu](/katalog/opentofu) (drop-in zamiennik [Terraform](/katalog/terraform) pod Linux Foundation) — wątek licencji rozwijamy w [Open source ≠ suwerenność](/blog/open-source-a-suwerennosc).

GitOps jest operacyjną ramą, która to spina: self-hostowany VCS jest jedynym źródłem prawdy dla kodu aplikacji **i** konfiguracji infrastruktury, a kontroler (np. Argo CD) nieustannie uzgadnia stan rzeczywisty z zadeklarowanym.

```yaml
# Argo CD: aplikacja, której źródłem prawdy jest repo na Gitei
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: web, namespace: argocd }
spec:
  project: default
  source:
    repoURL: https://git.eiac.dev/eiac/deploy.git
    path: clusters/sovereign-eu/web
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated: { prune: true, selfHeal: true }
```

Konsekwencja jest mocna: skoro cały stan biznesu jest opisany jako kod w repo, to **disaster recovery (i exit) sprowadza się do wskazania kontrolerowi nowego klastra** u innego, suwerennego dostawcy i pozwolenia mu odtworzyć środowisko od zera. Strategia wyjścia przestaje być dokumentem w segregatorze, a staje się rutynowo wykonywaną operacją.

## Air-gapped: ostateczny test suwerenności

Dla obronności i części finansów połączenie z jakimkolwiek publicznym internetem (nawet suwerennym) bywa wykluczone. Zdolność do działania w pełni odizolowanym środowisku air-gapped to najtwardszy sprawdzian: jeśli platforma opiera się na self-hostowanych control planes, własnym rejestrze obrazów i otwartej orkiestracji, całość da się postawić w odciętym data center. To samo, co daje suwerenność, daje też odporność na odcięcie.

## Macierz walidacji: jak sprawdzić, czy jesteś suwerenny

Praktyczny test sprowadza się do trzech domen i kilku pytań, na które trzeba odpowiedzieć „tak":

| Domena | Pytanie kontrolne |
|---|---|
| Infrastruktura i dane | Czy IaC jest otwarte i wolne od restrykcyjnych licencji (OpenTofu vs proprietary)? Czy dane leżą wyłącznie w wybranej jurysdykcji, a dostawca jest odporny na eksterytorialne żądania? |
| Tooling i control plane | Czy VCS jest self-hostowany? Czy orkiestrator jest framework-agnostyczny (wdraża i do suwerennych, i globalnych bez vendor-specyficznych wtyczek)? Czy sekrety/IAM są self-hostowane, nie w natywnym KMS chmury? |
| AI i własność intelektualna | Czy asystenci AI/LLM są hostowani lokalnie/suwerennie? Czy masz gwarancję, że kod i telemetria nie zasilają obcych modeli? (rozwijamy w [Suwerenne AI](/blog/suwerenne-ai-open-weight)) |

## Kontekst UE: nie tylko RODO

Ruch w stronę suwerenności napędzają konkretne ramy: **[NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive)** (cyberbezpieczeństwo w 18 sektorach krytycznych), **[EU Data Act](https://digital-strategy.ec.europa.eu/en/policies/data-act)**, inicjatywy jak [SecNumCloud](https://cyber.gouv.fr/enjeux-technologiques/cloud/) (Francja), [Gaia-X](https://gaia-x.eu/) czy [EU Cloud Rulebook](https://digital-strategy.ec.europa.eu/en/policies/cloud-computing). Najtwardsze wymogi techniczne stawia jednak **[DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)** wobec sektora finansowego — mapowanie zależności ICT, unikanie nadmiernej koncentracji u jednego dostawcy i utrzymywanie *przetestowanych* strategii wyjścia. Temu poświęcamy osobną część: [DORA w praktyce platformy](/blog/dora-w-praktyce-platformy).

## Podsumowanie

Suwerenny IDP to nie „chmura w UE", lecz architektura, w której każda płaszczyzna jest wymienna, a cały stan żyje jako kod w repozytorium pod Twoją kontrolą. Wtedy „exit" przestaje być ryzykiem do opisania w dokumencie, a staje się właściwością systemu — wykonywaną tak samo, jak każde inne wdrożenie. To również fundament, na którym da się spełnić wymogi DORA i bezpiecznie osadzić AI — co rozwijam w kolejnych częściach serii. Zrób sobie ten jeden test: gdyby jutro trzeba było przenieść wszystko do innego dostawcy, ile z tego pojedzie jednym `apply`? Odpowiedź mówi o Twojej suwerenności więcej niż jakikolwiek certyfikat.