Suwerenność cyfrowa nie jest pytaniem o to, czyje są serwery

Polski region Azure pod Warszawą, miliardy złotych inwestycji, a w tle CLOUD Act i argument części CIO, że „dane krytyczne trzymamy we Frankfurcie, bo mamy 500 km granicy z wojną”. W rozmowie z Business Growth Review Krzysztof Malesa, dyrektor ds. strategii bezpieczeństwa w Microsoft, rozkłada suwerenność cyfrową na konkretne trzy warstwy, wyjaśnia zakres CLOUD Act, pokazuje, gdzie kończy się odpowiedzialność hyperscalera, a gdzie zaczyna obowiązek klienta. Daje też średniej firmie konkretną listę: trzy rzeczy do wdrożenia w 12 miesięcy oraz trzy, których nie robić mimo szumu rynkowego.

Suwerenność ma trzy warstwy, a nie jedną. Jest suwerenność danych (gdzie są przechowywane), operacyjna (kto i kiedy ma dostęp administracyjny, np. przez Customer Lockbox) oraz technologiczna (zdolność do działania w modelu hybrydowym, prywatnym lub izolowanym). Granicę między nimi wyznacza analiza ryzyka konkretnego procesu, a nie deklaracja polityczna
CLOUD Act nie oznacza automatycznego dostępu do danych. Jego zakres jest w praktyce ograniczony do poważnych przestępstw i zagrożeń bezpieczeństwa narodowego, Microsoft kontraktowo zobowiązuje się przekierowywać żądania do klienta, a sprzeczne z prawem UE — kwestionować, w tym sądowo. Forrester wskazał Microsoft jako lidera platform sovereign cloud
Zgodność regulacyjna nie „przychodzi razem z usługą”. W modelu współdzielonej odpowiedzialności Microsoft odpowiada za bezpieczeństwo warstwy chmurowej, certyfikacje i zobowiązania DPA/SLA. Klient — za klasyfikację danych, konfigurację, tożsamość, dostępy oraz sposób, w jaki używa AI (szczególnie krytyczne przy AI Act i procesach decyzyjnych wysokiego ryzyka)
Copilot działa w granicach EU Data Boundary. Prompty użytkowników i odpowiedzi pozostają w granicach usługi Microsoft 365, dostęp do danych jest reglamentowany uprawnieniami zalogowanego użytkownika przez Microsoft Graph, a prompty oraz odpowiedzi nie są wykorzystywane do trenowania modeli

Rozwijaj swoją markę osobistą. Dołącz do programu BGR Expert Network

Suwerenność cyfrowa przestała być debatą akademicką. Dla polskich CIO w 2026 roku to konkretna kategoria ryzyka i kosztu: gdzie przetwarzane są dane, kto ma do nich dostęp operacyjny i czy organizacja zachowuje kontrolę także wtedy, gdy otoczenie staje się nieprzewidywalne. Pod ciśnieniem NIS2, DORA, AI Act i polskiej ustawy o KSC — a jednocześnie 500 km od granicy z wojną — zarządy zadają coraz trudniejsze pytania swoim dostawcom chmury.
Microsoft uruchomił polski region Azure i zainwestował miliardy w lokalną infrastrukturę. Jednocześnie pozostaje firmą amerykańską i część rynku zakłada, że spółka sprzedaje „dobrze opakowaną zależność”. Krzysztof Malesa, dyrektor ds. strategii bezpieczeństwa w Microsoft, w rozmowie z Business Growth Review rozkłada suwerenność na trzy warstwy, wyjaśnia zakres CLOUD Act i EU Data Boundary, pokazuje granicę między odpowiedzialnością hyperscalera a obowiązkiem klienta — oraz mówi, co prezes średniej firmy powinien wdrożyć w 12 miesięcy, a czego nie robić mimo szumu rynkowego.

Grzegorz Kubera, Business Growth Review: Czym dla Microsoftu jest suwerenność technologiczna polskiej firmy w 2026 roku i gdzie przebiega granica między suwerennością danych, operacyjną i „cyfrową”?

Krzysztof Malesa, dyrektor ds. strategii bezpieczeństwa w Microsoft: Suwerenność cyfrowa to bezpieczne i niezależne funkcjonowanie w cyfrowej gospodarce. Dla Microsoft oznacza to przede wszystkim kontrolę po stronie klienta: możliwość podejmowania decyzji na własnych warunkach, z wolnością wyboru technologii, gwarancją prywatności i bezpieczeństwa oraz odpornością usług nawet wtedy, gdy otoczenie staje się nieprzewidywalne. W praktyce sprowadza się to do trzech pytań: gdzie przetwarzane są dane, kto i na jakich zasadach ma dostęp operacyjny oraz w jakim modelu wdrożenia (chmura, hybryda, lokalnie) organizacja może bezpiecznie działać.

Żeby zrozumieć, jakie są granice pomiędzy suwerennością danych, operacyjną i cyfrową, należy spojrzeć na suwerenność jako możliwość kontrolowania określonych rodzajów ryzyka, które można pogrupować w trzy kategorie.

Po pierwsze, suwerenność danych to kontrola nad tym, gdzie dane są przechowywane i przetwarzane. W tym obszarze punktem odniesienia jest m.in. EU Data Boundary – granice, w których europejscy klienci mogą przechowywać i przetwarzać dane na infrastrukturze w UE/EFTA dla kluczowych usług chmurowych.

Po drugie, suwerenność operacyjna to ścisły nadzór nad tym, kto i kiedy może wykonywać operacje administracyjne, np. w ramach wsparcia technicznego. Dla klienta oznacza to transparentność i możliwość zatwierdzania dostępu – tak, aby działania uprzywilejowane nie odbywały się „w tle”. Przykładowo Customer Lockbox pozwala kontrolować i audytować zdalny dostęp do danych w sytuacjach wymagających interwencji inżynierów.

Po trzecie, suwerenność technologiczna (technological independence) to zdolność organizacji do działania także wtedy, gdy potrzebuje większej autonomii: w modelu hybrydowym, prywatnym lub w skrajnym przypadku, w środowisku izolowanym. To ważne zwłaszcza dla procesów krytycznych, gdzie profil ryzyka wymaga, by część obciążeń mogła działać przy ograniczonej łączności lub lokalnie. Innymi słowy, klient wybiera taki model wdrożenia, który daje mu właściwy poziom kontroli w konkretnym procesie.

Microsoft uruchomił polski region chmurowy pod Warszawą, inwestując miliardy złotych. Jednocześnie część CIO w Polsce mówi: „dane krytyczne trzymamy we Frankfurcie albo Dublinie, bo mamy 500 km granicy z wojną”. Jak Państwo odpowiadają na ten argument i czy sami rekomendują klientom replikację poza Polskę jako standard, a nie wyjątek?

To pytanie dotyka odporności i ciągłości działania, a te powinny wynikać z analizy ryzyka, a nie z uniwersalnych rekomendacji. Na odporność wpływa nie tylko rezydencja danych, ale też architektura regionów i stref oraz procedury awaryjne na wypadek materializacji ryzyka.

Po pierwsze, Azure Poland to region chmurowy, czyli zestaw wielu niezależnych lokalizacji centrów danych, a nie „jeden budynek”. Po drugie, standardem nie jest „zawsze replikacja poza Polską”, tylko „zawsze zgodnie z wymaganiami RTO/RPO dla danego procesu i wynikiem analizy ryzyka”. Po trzecie, w chmurze obowiązuje model współdzielonej odpowiedzialności: Microsoft zapewnia odporność platformy, a klient projektuje odporność własnego rozwiązania (np. dobór stref, regionów, kopii i procedur odtworzeniowych). Klient ma tu realny wybór architektury, a my dostarczamy regiony, narzędzia i mechanizmy, które pozwalają ten wybór wdrożyć i obronić w kontekście audytowym.

Jeżeli organizacja decyduje się na dodatkową replikację poza krajem, najczęściej robi to w obrębie UE/EOG, żeby połączyć odporność z europejskim reżimem prawnym i wymaganiami audytu. Nasza praktyczna rekomendacja jest prosta: najpierw projektuj odporność na podstawie ryzyka i krytyczności procesu, a dopiero potem dobieraj lokalizację danych.

Sprawdź też: Raport i unikalne badanie nt. przygotowania firm do NIS2

Co trzeba wiedzieć o CLOUD Act

CLOUD Act: polska firma trzyma dane w regionie Azure w Polsce, dane fizycznie nie opuszczają UE, ale Microsoft jako podmiot amerykański podlega żądaniom organów USA. Jak tłumaczycie klientom, że to akceptowalne ryzyko i co konkretnie zmienia Microsoft Cloud for Sovereignty oraz EU Data Boundary?

To ważny temat i warto go uporządkować faktami. Microsoft jest organizacją globalną, a w Europie działamy pod europejskimi zasadami: jeśli jakiekolwiek decyzje administracji kraju pochodzenia firmy byłyby sprzeczne z prawem UE, naszymi zasadami lub zapisami umownymi, korzystamy z dostępnych środków prawnych, w tym drogi sądowej, aby chronić dane klientów, co jest zagwarantowane w zawieranych przez nas umowach.

Ponadto zakres CLOUD Act jest w praktyce ograniczony: może dotyczyć wyłącznie danych związanych z poważnymi przestępstwami lub zagrożeniami dla bezpieczeństwa narodowego (np. terroryzm, cyberprzestępczość, szpiegostwo). Nie oznacza to automatycznego i nieograniczonego dostępu do danych klientów.

Gdy pojawia się wniosek organu państwowego, działamy w sposób, który maksymalizuje kontrolę klienta i zgodność z prawem UE: w pierwszej kolejności, w granicach prawa, przekierowujemy organ do klienta, a następnie wykorzystujemy dostępne środki prawne, aby ograniczyć zakres żądania i zakwestionować je, gdy mamy ku temu podstawę. Analogicznie, zobowiązujemy się stanowczo kwestionować każdy nakaz dotyczący zawieszenia lub zaprzestania działania usług chmurowych w Europie, wykorzystując dostępne środki prawne, w tym drogę sądową.

Jesteśmy w Europie od ponad 40 lat, a nasze zobowiązania idą w parze z długofalowymi inwestycjami w rozwój regionu. W ostatnich miesiącach ogłosiliśmy nowe wielomiliardowe inwestycje w Portugalii, Norwegii i Wielkiej Brytanii, a także zwiększone inwestycje w Danii, Niemczech, Francji, Włoszech, Szwecji, Hiszpanii, Polsce i Szwajcarii. Uruchomiliśmy też nowe regiony chmurowe w Austrii, Danii i Belgii.

W tym kontekście kluczowe są ogłoszone rok temu Europejskie Zobowiązania Cyfrowe, w których publicznie zobowiązaliśmy się do ochrony europejskich danych, wzmacniania cyberbezpieczeństwa i odporności cyfrowej niezależnie od zmiennych warunków geopolitycznych. To jest spójne z prostą zasadą: europejscy klienci mają móc korzystać z globalnej technologii według europejskich reguł i pod europejską kontrolą.

Równolegle rozwijamy rozwiązania, które zwiększają kontrolę, transparentność i zgodność – tak, aby klient mógł dobrać właściwy poziom suwerenności do swoich wymagań prawnych i profilu ryzyka. W praktyce oznacza to m.in. szerokie portfolio opcji suwerennej chmury (publicznej, prywatnej i partnerskiej), rozszerzenie EU Data Boundary także na usługi oparte o AI oraz dodatkowe mechanizmy nadzoru operacyjnego. To podejście skutkuje wysoką oceną przez niezależnych analityków – w ostatniej analizie Forrester wskazał Microsoft jako lidera platform sovereign cloud.

*Na zdjęciu: Krzysztof Malesa, dyrektor ds. strategii bezpieczeństwa w Microsoft / Fot. Mat. prasowe*

NIS2, DORA, AI Act, a w tle polska ustawa o KSC – zgodność regulacyjna stała się osobną kategorią kosztu. Gdzie widzi Pan największe praktyczne pułapki dla polskich firm wdrażających chmurę i w których obszarach Microsoft bierze odpowiedzialność kontraktową za compliance, a w których to nadal „shared responsibility”?

Rzeczywiście, zgodność regulacyjna przestała być dodatkiem – dziś jest osobną kategorią kosztu i ryzyka zarządczego. Największą praktyczną pułapką dla polskich firm wdrażających chmurę jest przekonanie, że „zgodność przychodzi razem z usługą”. Nie przychodzi. Chmura obniża próg wejścia, ale nie przejmuje całej odpowiedzialności regulacyjnej.

Pierwszą pułapką jest zderzenie kilku regulacji naraz i próba wdrażania zgodności „silosowo”. W finansach DORA dominuje nad NIS2 w obszarze ICT risk, a obowiązki z AI Act – jeśli organizacja korzysta z systemów wysokiego ryzyka – funkcjonują równolegle. Jeśli compliance nie jest projektowane spójnie, łatwo o dublowanie procesów i chaos w raportowaniu. My traktujemy te wymagania globalnie i konsekwentnie w naszych standardach oraz dokumentacji, ale część pracy – mapowanie obowiązków do procesów i konfiguracji – zawsze pozostaje po stronie klienta.

Drugą pułapką może być mylenie odpowiedzialności technicznej z odpowiedzialnością regulacyjną. Microsoft bierze kontraktową odpowiedzialność za bezpieczeństwo i zgodność warstwy chmurowej, ale nie za sposób, w jaki klient konfiguruje, zarządza i wykorzystuje tę chmurę. To klasyczny model współdzielonej odpowiedzialności: infrastruktura fizyczna, centra danych, podstawowe mechanizmy bezpieczeństwa i certyfikacje (ISO, SOC, DORA scope controls) są po stronie Microsoftu, natomiast to klient odpowiada za klasyfikację danych, konfigurację polityk, zarządzanie tożsamościami, reakcję na incydenty i spełnienie krajowych obowiązków np. KSC.

Trzecią pułapką może być nieuwzględnienie lub niedoszacowanie znaczenia AI. Tu istotne są zasady, które wprowadza AI Act: nawet przy korzystaniu z gotowych usług – takich jak Copilot czy Azure OpenAI – odpowiedzialność za kontekst użycia, dane wejściowe, sposób nadzoru i wpływ na procesy biznesowe pozostaje po stronie organizacji. Microsoft kontraktowo odpowiada za bezpieczeństwo modeli, infrastrukturę, mechanizmy „odpowiedzialnej AI” i zabezpieczenia platformowe, ale nie przejmuje odpowiedzialności za to, czy klient używa sztucznej inteligencji w sposób zgodny z AI Act, np. w procesach decyzyjnych wysokiego ryzyka bez właściwego nadzoru człowieka.

Jako Microsoft po pierwsze gwarantujemy, że nasza technologia umożliwia spełnienie wymagań regulacyjnych, po drugie ze swojej strony bierzemy odpowiedzialność kontraktową za świadczenie usługi, bezpieczeństwo i zobowiązania opisane w umowach (DPA/Product Terms/SLA) oraz za własne procesy zgodności w zakresie, w jakim prawo ma zastosowanie wobec dostawcy. Natomiast klient zawsze zachowuje odpowiedzialność za klasyfikację danych, konfigurację, tożsamość i dostęp, swoje stacje robocze oraz to, jak usługa jest używana w procesie biznesowym.

Dobrze opakowana zależność, czy suwerenność?

Kontrargument wobec hyperscalerów brzmi: „to nie jest suwerenność, to dobrze opakowana zależność”. Co powiedziałby Pan CIO, który porównuje Azure z OVHcloud, Atende czy ofertą T‑Systems i pyta, dlaczego ma powierzyć infrastrukturę krytyczną firmie, której nie kontroluje żaden europejski rząd?

Wróćmy do definicji. Jeśli ktoś rozumie suwerenność jako całkowity brak zależności od kogokolwiek, to myśli kategoriami utopii. Szanujemy naszą konkurencję i jej rynkową ofertę, ale szafowanie tezami o wyższości niektórych podmiotów wyłącznie ze względu na ich nadwiślański czy europejski rodowód jest dużym uproszczeniem.

O jakości rozwiązania powinny decydować konkretne kryteria: bezpieczeństwo, odporność, zgodność z regulacjami, przejrzystość operacyjna, doświadczenie i realna kontrola klienta nad danymi. Suwerenność cyfrowa to nie pytanie „czyje są serwery”, tylko czy organizacja ma dowody kontroli: gdzie są dane, kto ma do nich dostęp i jak działa nadzór.

Realna suwerenność w 2026 roku to zdolność do wykazania kontroli: gdzie są dane, kto ma dostęp operacyjny, jak wygląda nadzór oraz czy klient może stosować własne polityki, szyfrowanie i model nadzoru. Dlatego rozwijamy podejście suwerennej chmury, które dokłada mechanizmy przejrzystości i kontroli (np. EU Data Boundary dla rezydencji danych oraz rozwiązania wzmacniające nadzór operacyjny). A gdy profil ryzyka wymaga większej niezależności technologicznej, rozmowa naturalnie przechodzi na model hybrydowy lub prywatny. Wtedy spór „USA vs UE” przestaje być osią decyzji – liczy się to, czy wybrany model daje właściwą kontrolę dla konkretnego procesu krytycznego.

A co z Copilot i AI: gdzie faktycznie trafiają prompty pracowników, gdzie są przetwarzane, czy są wykorzystywane do trenowania modeli i co z językiem polskim?

W przypadku rozwiązań dla firm, takich jak Microsoft 365 Copilot, kluczowe jest to, że jest to usługa zintegrowana z Microsoft 365 i objęta tymi samymi zobowiązaniami w zakresie bezpieczeństwa, prywatności i zgodności, które klienci znają z usług takich jak Exchange, SharePoint czy Teams.

Prompty użytkowników, odpowiedzi Copilota oraz dane, do których Copilot uzyskuje dostęp, na przykład dokumenty, wiadomości, spotkania czy czaty, do których dany pracownik ma uprawnienia, pozostają w granicach usługi Microsoft 365 i są przetwarzane zgodnie ze zobowiązaniami kontraktowymi.

Przepływ danych jest więc klarowny: użytkownik wpisuje prompt, Copilot na podstawie prompta orkiestruje zapytanie (przetwarza prompt na logiczną sekwencję poleceń) i wysyła je do Microsoft Graph, który jest pojedynczą bramą do danych z kalendarza, Teamsów, Outlook, Sharepointa i innych aplikacji. MS Graph weryfikuje kto jest autorem prompta, czy ma dostęp do danych i jeśli tak, to udostępnia do modelu dane źródłowe, w niezbędnym zakresie. Model generuje odpowiedź i zwraca ją do Copilota.

Ważne jest to, że Copilot działa wewnątrz granicy usług Microsoft 365. Podkreślmy jeszcze raz: dostęp Copilota do danych firmowych jest reglamentowany zgodnie z uprawnieniami zalogowanego użytkownika. Prompty, odpowiedzi i dane dostępne przez Microsoft Graph nie są używane do trenowania modeli.

Z perspektywy europejskiej istotne jest także to, że Microsoft 365 Copilot jest zgodny z zobowiązaniami EU Data Boundary – przetwarzanie danych klientów może odbywać się w Europie w ramach tych zasad.

Copilot obsługuje język polski, ale jego przewaga nie polega tylko na tłumaczeniu czy rozmowie w tym języku. Najważniejsze jest to, że potrafi pracować na firmowym kontekście: dokumentach, procedurach i słowniku organizacji. Wtedy o jakości odpowiedzi decyduje przede wszystkim jakość danych i porządek informacyjny w firmie.

Czy można łatwo zmienić dostawcę?

Jak w przypadku usług Microsoftu wygląda strategia exit i co wdrożyć przed startem, żeby uniknąć vendor lock‑in?

Poważnie traktujemy gwarantowaną klientom przez unijne prawo bezpieczną możliwość zakończenia korzystania z usługi chmurowej – bez utraty danych, ciągłości działania i zgodności regulacyjnej. Podejście Microsoft do exit strategy opiera się na umożliwieniu klientowi realnego wyjścia z chmury poprzez standardowe formaty eksportu danych, dokumentowane procedury zakończenia usługi, brak barier kontraktowych (zgodnie z EU Data Act) oraz wsparcie interoperacyjności i przenośności – przy czym odpowiedzialność za zaplanowanie i przetestowanie wyjścia spoczywa na kliencie.

Co klient powinien wdrożyć przed startem, by uniknąć vendor lock‑in: jasno zdefiniowaną strategię exit (scenariusze migracji do innej chmury lub rozwiązań on‑prem), architekturę opartą na standardach i automatyzacji (IaC, kontenery, API‑agnostyczność), testy odzysku danych i migracji oraz umowy uwzględniające prawo do portowania danych, wsparcie przy wyjściu i brak opłat egressowych w horyzoncie Data Act/DORA.

Stawiamy na standardy i interoperacyjność (API, konteneryzacja, IaC), żeby klient mógł przenosić aplikacje i systemy tam, gdzie potrzebuje.

Co powinny wiedzieć MŚP

Gdyby miał Pan wskazać prezesowi średniej firmy (200–1000 pracowników) trzy rzeczy „do wdrożenia w ciągu 12 miesięcy” oraz trzy rzeczy „czego nie robić mimo szumu rynkowego” – co by to było?

Trzy rzeczy „do zrobienia”:

(1) Uporządkować dane i uprawnienia, bo Copilot i automatyzacje działają w granicach dostępów, a ryzyko zwykle wynika z nadmiarowych uprawnień, nie z „trenowania na danych”.

(2) Ustawić rezydencję danych i zasady transferów jako polityki oraz dowody audytowe – najlepiej w odniesieniu do EU Data Boundary.

(3) Połączyć odporność i exit strategy w jeden projekt: zaprojektować architekturę, procedury i testy tak, by przeniesienie lub odtworzenie aplikacji i systemów było realne i przećwiczone.

Trzy rzeczy, których „nie robić”:

(1) Nie obiecywać sobie „pełnej suwerenności bez jurysdykcji” – dojrzała suwerenność to kontrola i dowody, a nie mit absolutnej niezależności.

(2) Nie budować procesów krytycznych w schemacie „single‑region only” z powodów politycznych; odporność to decyzja architektoniczna i element współdzielonej odpowiedzialności.

(3) Nie wdrażać AI „na skróty” bez zasad prywatności, nadzoru i źródeł danych (np. web‑grounding), bo koszt zgodności z wymogami prawnymi, regulacyjnymi i organizacyjnymi po fakcie jest zwykle najwyższy.

— Rozmawiał Grzegorz Kubera

Krzysztof Malesa odpowiada za wspieranie organizacji w osiąganiu celów transformacji cyfrowej poprzez wdrażanie najwyższych standardóww cyberbezpieczeństwa. Krzysztof Malesa dołączył do polskiego oddziału firmy Microsoft w październiku 2021 r. Przez blisko 12 lat pracował w Rządowym Centrum Bezpieczeństwa (RCB), najpierw w roli szefa Krajowego Centrum Zarządzania Kryzysowego, a od 2012 roku jako zastępca dyrektora RCB, powołany przez Prezesa Rady Ministrów. W ramach tej funkcji był m.in. odpowiedzialny za planowanie cywilne oraz ochronę infrastruktury krytycznej, w szczególności w sektorze energetycznym. Do obszarów jego odpowiedzialności należało cyberbezpieczeństwo, zarządzanie ryzykiem i ciągłość działania organizacji. Był również zaangażowany w prace Komitetu Planowania Cywilnego NATO (CEPC), głównie w kontekście zagrożeń hybrydowych i odporności na te zagrożenia.