W wprowadzeniu 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.
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.
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 (który może zmusić firmę z USA do wydania danych niezależnie od tego, gdzie fizycznie leżą) a unijnym RODO (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/Forgejo), CI runners, orkiestrator i GitOps (Argo CD/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).
- 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 (drop-in zamiennik Terraform pod Linux Foundation) — wątek licencji rozwijamy w Open source ≠ suwerenność.
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.
# 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) |
Kontekst UE: nie tylko RODO
Ruch w stronę suwerenności napędzają konkretne ramy: NIS2 (cyberbezpieczeństwo w 18 sektorach krytycznych), EU Data Act, inicjatywy jak SecNumCloud (Francja), Gaia-X czy EU Cloud Rulebook. Najtwardsze wymogi techniczne stawia jednak DORA 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.
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.