Sovereign cloud dla solo-dev

Korpo ma 12 prawników, którzy czytają T&C AWS-a w detalach. Solo-dev ma siebie i ten artykuł.

Trzy zagrożenia, których nie widzisz

1. CLOUD Act (US)

Klauzula z 2018 roku mówi: każda firma z biurem w USA może być zmuszona przez sąd do wydania danych klientów — niezależnie od tego, gdzie te dane fizycznie leżą. AWS Frankfurt, Azure Polska, GCP Warszawa — wszystkie podlegają.

Co to znaczy w praktyce: jeśli amerykański sąd wystawi nakaz, Microsoft musi wydać Twoje dane z Azure Poland Central. Polski sąd nie ma tu nic do gadania, RODO też nie pomaga (Schrems II rozjaśnił to definitywnie w 2020).

2. AI training scraping

Większość hyperscalerów rezerwuje sobie prawo do „użycia anonimizowanych metadanych operacyjnych w celu poprawy usług". W praktyce: trening modeli ML.

Twoje query patterny, struktura ruchu, request/response timings — wszystko to „dane operacyjne". Czy to wycieka jako bezpośredni training input do GPT-X? Oficjalnie NIE. Nieoficjalnie — granica jest pofalowana, a definicja „anonimizowanego" jest elastyczna.

3. Subprocesory

Wybrałeś AWS Frankfurt = „EU only". Ale CDN routes przez CloudFront edge w Singapurze. Logi agreguje się w us-east-1. Anti-DDoS protection działa via Cloudflare's network globally.

Każdy subprocesor = nowa jurysdykcja. Większość T&C ma listę subprocesorów na 3 stronach drobnego druczku, którego nikt nie czyta.

Test 5 pytań

Zanim wybierzesz hosting dla aplikacji, która coś znaczy, odpowiedz sobie:

1. Gdzie fizycznie są moje dane? (region nazwą, datacenter nazwą, najlepiej adres)
2. Pod jaką jurysdykcją podlegają? (kraj firmy-rodzica się liczy, nie kraj DC)
3. Co provider może z nimi zrobić? (cytuj klauzule T&C, nie marketingowe ulotki)
4. Kto jeszcze ma do nich dostęp? (subprocesorzy, governmental access requests, audit log retention)
5. Co się dzieje, gdy przestanę płacić? (kasują od razu? trzymają 30 dni? backup do „skarbnicy"?)

Jeśli któreś z tych pytań nie ma jasnej odpowiedzi w T&C — szukaj dalej.

Sovereign cloud — co to dokładnie oznacza

„Sovereign cloud" to termin marketingowy z konkretną definicją techniczną:

Cloud, w którym dane są 100% kontrolowane, zarządzane i monitorowane przez właściciela, znajdują się fizycznie na lokalnej ziemi i podlegają wyłącznie lokalnemu prawu dotyczącemu prywatności i przechowywania.

Trzy słowa kluczowe:

• Local soil — fizyczny serwer w Twoim kraju
• Local law only — żadnej zewnętrznej jurysdykcji (bye CLOUD Act)
• Self-controlled — żaden trzeci nie ma dostępu, nawet provider

Polskie sovereign cloudy, które realnie spełniają definicję:

• whitesky.cloud Poland (na której stoi SimpleCloud)
• Atman Cloud
• Beyond.pl
• Polcom

OVHcloud Warsaw, GCP Warsaw, Azure Poland Central — NIE są sovereign mimo polskiego DC, bo firmy-matki są zagraniczne (FR, US, US) i podlegają jurysdykcji swojego kraju.

Co solo-dev powinien zrobić jutro

1. Wypisz dane, które przetwarzasz — jeśli to PII (e-maile, hasła, treść konwersacji) — masz problem GDPR/RODO
2. Sprawdź T&C obecnego hostingu — szukaj klauzul: scan, monitor, improve service, anonymized
3. Zrób migration plan — nawet jeśli nie migrujesz teraz, miej plan na 48h
4. Zapisz w README projektu: „Hosting: X. Sovereignty: poziom Y. Migration cost: Z dni"

Bez tego, gdy przyjdzie pierwszy enterprise klient z Vendor Risk Assessment, nie będziesz miał odpowiedzi.

Kiedy NIE potrzebujesz sovereign

Bądźmy szczerzy — jeśli Twoja aplikacja to:

• Hobby projekt bez prawdziwych użytkowników
• Cache CDN dla statycznych zasobów
• Serwer dla gier ze znajomymi

…to sovereign jest zbędny. Hetzner Cloud za 17 zł będzie OK. Sovereignty kosztuje (trochę) więcej i ma sens dopiero gdy przetwarzasz cudze dane albo masz pomysł, którego ktoś chciałby ukraść.

SimpleCloud sign-off

Stoimy na sovereign cloud (whitesky.cloud Poland). Klauzula no-use w umowie. Możemy też postawić u Ciebie fizycznie. Faktura w PLN, wsparcie po polsku, prawnie pod jurysdykcją RP.

Nikt poza Tobą nie ma prawa czytać Twoich danych — nie dlatego że my tak twierdzimy, ale dlatego że tak mamy w umowie z infrastrukturą.