Niemieckie sekrety w chmurze Google: Jak bardzo niesuwerenna jest planowana chmura ND?

Offline, ale zależny? Ryzykowna cena technologii Google dla niemieckich serwisów informacyjnych

Chmura Google’a dla niemieckich służb wywiadowczych: Co się stanie, jeśli dostawca zawiedzie?

Usługa chmurowa odizolowana od internetu może skutecznie chronić informacje niejawne – ale może również prowadzić do długotrwałego uzależnienia od dostawcy technologii. Planowana chmura ND dla Federalnej Służby Wywiadowczej (BND), Federalnego Urzędu Ochrony Konstytucji (BfV) i Służby Kontrwywiadu Wojskowego (MAD) funkcjonuje właśnie w tym kontekście. Ma ona umożliwić bezpieczną wymianę wysoce poufnych informacji bez bezpośredniego połączenia z publicznym internetem. Jednak ta tzw. „oddzielna przestrzeń powietrzna” nie odpowiada na wszystkie pytania: Kto może utrzymywać, aktualizować i dalej rozwijać platformę na przestrzeni lat? I jakie opcje pozostają państwu w przypadku zmiany sytuacji technicznej lub politycznej?

W przypadku projektu o publicznie deklarowanym budżecie co najmniej 500 milionów euro, stawką jest coś więcej niż tylko lokalizacja serwerów i środki bezpieczeństwa. Kluczowe pytanie brzmi, czy Niemcy będą w stanie kontrolować platformę w perspektywie długoterminowej i w razie potrzeby przejść na inną. Wymaga to uwzględnienia nie tylko ochrony danych, ale także dostępności oprogramowania, wiedzy specjalistycznej, kosztów migracji i potencjalnych alternatyw. Planowana chmura obliczeniowa może stanowić ważny krok w kierunku modernizacji – ale prawdziwa suwerenność cyfrowa zostanie osiągnięta tylko wtedy, gdy państwo nie tylko będzie kontrolować bieżące operacje, ale także będzie miało realne możliwości na przyszłość.

W związku z tym:

• Współpraca niemieckich sił zbrojnych z Google: Jak dużą część suwerenności Niemcy tak naprawdę oddają w zamian za Google Cloud?

Tajemnice Niemiec, technologia Google’a: cena suwerenności cyfrowej

Tryb offline jest daleki od niezależności

Usługa chmurowa odizolowana od internetu może skutecznie chronić informacje niejawne, a jednocześnie tworzyć długoterminową zależność od dostawcy technologii. Planowana wspólna platforma danych Federalnej Służby Wywiadowczej, Federalnego Urzędu Ochrony Konstytucji i Służby Kontrwywiadu Wojskowego wpisuje się właśnie w to napięcie: planowana izolacja techniczna rozwiązuje kwestię dostępu do sieci zewnętrznych, ale jeszcze nie kwestię trwałej swobody działania w sferze technologicznej.

Decydującym pytaniem ekonomicznym nie jest zatem to, czy na platformie pojawi się logo amerykańskiej, czy europejskiej firmy. Liczy się to, kto określa warunki dalszego rozwoju, rozwiązywania problemów, eksploatacji i potencjalnej migracji w całym cyklu życia platformy. Przekonująca strategia suwerenności musi łączyć wydajność, wymogi bezpieczeństwa i długoterminową swobodę wyboru, a nie brać pod uwagę wyłącznie lokalizacji serwerów.

Platforma danych o znaczeniu strategicznym

Zgodnie z publicznie dostępnym stanem planowania na dzień 28 października 2026 r., tzw. ND Cloud ma umożliwić elektroniczną wymianę informacji do poziomu klauzuli TAJNE między trzema federalnymi służbami wywiadowczymi; w późniejszym terminie może ona również objąć krajowe urzędy ochrony konstytucji. Podstawą techniczną ma być najwyraźniej Google Distributed Cloud w bezpiecznej konfiguracji, z informacjami przechowywanymi w Niemczech i bez bezpośredniego dostępu Google do danych.

Nie chodzi tu o przechowywanie tajemnic rządowych w ramach zwykłej usługi internetowej. Chodzi raczej o odrębną infrastrukturę, która może działać bez bezpośredniego połączenia z publicznym internetem lub ogólną usługą Google Cloud. To rozróżnienie jest kluczowe, ponieważ zmienia obraz zagrożeń: technicznie odizolowaną sieć zarządzaną na poziomie krajowym należy oceniać inaczej niż standardową usługę chmurową administrowaną z zewnątrz.

Publicznie podawana kwota wynosi co najmniej 500 milionów euro; jest to szacunek, a nie pełne zestawienie kosztów. Premiera pierwotnie planowana na pierwszy kwartał 2027 roku prawdopodobnie ulegnie opóźnieniu, a kluczowe szczegóły dotyczące architektury, zakresu usług i kosztów bieżących nie są publicznie dostępne. Na podstawie tych informacji nie można obliczyć wiarygodnego zwrotu z inwestycji ani jednoznacznie stwierdzić, że konkretna alternatywa byłaby o ustalony procent tańsza.

Jednak sama skala projektu dowodzi, że platforma będzie czymś więcej niż zwykłym systemem informatycznym. Będzie ona kształtować przepływy pracy, modele danych i kwalifikacje na lata. Im więcej agencji rządowych dostosuje swoje specjalistyczne procedury do współdzielonych usług technicznych, tym większe znaczenie strategiczne będą miały decyzje, które początkowo wydają się dotyczyć wyłącznie kwestii infrastrukturalnych.

Dlaczego współdzielona infrastruktura może mieć sens ekonomiczny

Potrzeba modernizacji jest zasadniczo uzasadniona: wymiana informacji wysokiego poziomu między chronionymi systemami rządowymi jest obecnie uciążliwa, a jednocześnie rosną wymagania dotyczące pamięci masowej i zautomatyzowanej analizy. Wspólna platforma może uprościć przesyłanie danych, zapewnić standardowe narzędzia i przyspieszyć współpracę, pod warunkiem jasnego zdefiniowania uprawnień i obowiązków.

Z ekonomicznego punktu widzenia potencjalne korzyści wynikają z ekonomii skali. Jeśli moc obliczeniowa, tworzenie kopii zapasowych danych, monitorowanie i procesy bezpieczeństwa są dostarczane łącznie, nie wszystkie organy administracji publicznej muszą równolegle rozwijać te same możliwości. Może to poprawić wykorzystanie zasobów i odciążyć ograniczony, wykwalifikowany personel; BWI opisuje standaryzowaną i zautomatyzowaną infrastrukturę chmurową jako sposób na osiągnięcie bardziej elastycznych i wydajnych usług IT.

Do tego dochodzi korzyść płynąca z szybszego przetwarzania informacji. Wysokowydajne środowisko techniczne może zapobiec zbyt późnemu udostępnianiu istniejących danych wywiadowczych z powodu uciążliwych procesów. Korzyści te są trudne do oszacowania w euro dla służb wywiadowczych, ale nie są one zatem nieistotne ekonomicznie. Jednakże, prawdopodobny zysk w zakresie bezpieczeństwa nie może być wykorzystywany jako arbitralnie elastyczny argument uzasadniający z mocą wsteczną jakąkolwiek zależność technologiczną.

Właściwe porównanie nie dotyczy zatem nowoczesnej chmury obliczeniowej i istniejącej, pozbawionej ryzyka infrastruktury. Rozdrobnione, starsze systemy również generują koszty i zagrożenia bezpieczeństwa, na przykład z powodu skomplikowanej konserwacji i procesów manualnych. Właściwa ocena musi uwzględniać zarówno ryzyko związane z migracją, jak i koszty zaniechania; jednak sama potrzeba modernizacji nie dowodzi, że każda platforma oferowana w tym celu jest ekonomicznie opłacalna w dłuższej perspektywie.

Szczelina powietrzna rozwiązuje tylko część problemu

Termin „odcięcie powietrzne” odnosi się tutaj do oddzielenia od publicznego internetu i innych sieci zewnętrznych, niekoniecznie do całkowitej izolacji każdego komputera od siebie. W ramach chronionej sieci rządowej systemy mogą nadal ze sobą współpracować, przy jednoczesnym zachowaniu ścisłych granic dostępu zewnętrznego. Google wyraźnie opisuje platformę jako stale działającą bez połączenia z publiczną chmurą Google.

Ta cecha stanowi istotną zaletę w zakresie bezpieczeństwa i nie należy jej lekceważyć. Brak połączeń zewnętrznych ogranicza niektóre wektory ataków i stwarza lepsze warunki do kontrolowanego działania. Nie oznacza to jednak, że platforma może być bezpiecznie utrzymywana lub funkcjonalnie rozbudowywana w nieskończoność bez dodatkowych usług ze strony producenta; niezależność techniczna od sieci i niezależność od oprogramowania to odrębne cechy.

Można to zilustrować, porównując zakład produkcyjny zlokalizowany w całości na terenie niemieckiej fabryki. Lokalizacja ta chroni fizyczną kontrolę, ale nie gwarantuje ciągłej dostępności części zamiennych, oprogramowania sterującego i specjalistycznej wiedzy. To, że ktoś zarządza zakładem, nie oznacza, że ​​może go samodzielnie rozwijać. Ta sama logika ekonomiczna ma zastosowanie w przypadku wysoce złożonego środowiska chmurowego.

Suwerenność nie jest zatem kwestią jednego przełącznika. Suwerenność danych, kontrola administracyjna, pewność prawa, przejrzystość łańcucha dostaw i adaptacyjność technologiczna muszą być rozpatrywane oddzielnie. Platforma może charakteryzować się silnymi cechami w niektórych z tych wymiarów, a w innych wykazywać znaczące zależności; to właśnie to rozróżnienie umożliwia rzetelną ocenę.

Aktualizacje jako interfejs władzy ekonomicznej

Dokumentacja bezpieczeństwa Google opisuje kontrolowany proces aktualizacji: producent podpisuje pakiety oprogramowania, operator infrastruktury je weryfikuje, a następnie wdraża w odizolowanym środowisku. Proces ten obejmuje nie tylko oprogramowanie chmurowe, ale także systemy operacyjne, oprogramowanie sprzętowe i inne komponenty istotne z punktu widzenia bezpieczeństwa. Automatyczne połączenie internetowe nie jest wymagane, ale bieżąca współpraca w zakresie dostaw technicznych pozostaje w mocy.

Początkowo jest to normalny element profesjonalnego działania oprogramowania i nie świadczy o nadużyciach producenta. Sytuacja staje się problematyczna, gdy tylko jeden dostawca jest w stanie dostarczać niezawodne aktualizacje w odpowiednim czasie. W takich przypadkach praktyczne bezpieczeństwo systemu zależy nie tylko od operatora krajowego, ale także od zewnętrznej organizacji programistycznej oraz jej prawnych i ekonomicznych podstaw.

Zakres tych zależności potwierdzają publicznie dostępne standardowe warunki korzystania z usługi Google Distributed Cloud Air-gapped. Stanowią one, że nowe wersje muszą zostać zainstalowane w ciągu 30 dni od powiadomienia; zawierają również zasady dotyczące zakończenia prac konserwacyjnych i zakończenia użytkowania oprogramowania po wygaśnięciu okresu licencji. Nie należy jednak utożsamiać tych ogólnych warunków z nieznanymi, szczególnymi postanowieniami planowanej platformy komunikacyjnej.

To rozróżnienie jest kluczowe. Nie można publicznie zweryfikować, jakie indywidualne uprawnienia operacyjne, okresy audytów ani dodatkowe środki bezpieczeństwa obowiązują w przypadku chmury ND. Podobnie, nieuzasadnione byłoby wnioskowanie z ciągłego uzależnienia od aktualizacji o istnieniu tajnego dostępu zdalnego lub technicznego mechanizmu wyłączania. Udokumentowana jest stała rola producenta w dostarczaniu oprogramowania, a nie arbitralny dostęp z zewnątrz.

Niebezpieczna różnica między czasem wykonania a bezpieczeństwem

W przypadku przerwy w świadczeniu pomocy technicznej przez producenta należy rozważyć kilka scenariuszy. Zainstalowany system może początkowo funkcjonować technicznie, podczas gdy nowo odkryte luki w zabezpieczeniach nie będą już łatane. Jednocześnie prawa użytkowania, dostępność części zamiennych i wsparcie dla aplikacji zależnych mogą zostać ograniczone. Dlatego pytanie o to, jak długo komputery pozostaną włączone, ma mniejsze znaczenie niż pytanie o to, jak długo będzie możliwe ich prawidłowe działanie.

Nie da się na tej podstawie wywnioskować stałego, ogólnego okresu użytkowania. Zależałby on między innymi od istniejących luk w zabezpieczeniach, lokalnych opcji naprawy, korzystania z dodatkowych usług oraz dostępności wykwalifikowanego personelu. Ogólnikowe stwierdzenie, że odizolowana chmura nieuchronnie staje się bezużyteczna po upływie określonej liczby miesięcy, byłoby równie nieprecyzyjne, jak twierdzenie o nieograniczonej niezależności.

Z ekonomicznego punktu widzenia stwarza to problem opcji: państwo potrzebuje nie tylko bieżącej funkcjonalności, ale także możliwości działania w przypadku zmiany okoliczności. Ta opcja ma wartość, nawet jeśli pozostaje niewykorzystana przez lata. Jej finansowanie przypomina ubezpieczenie od rzadkiej, ale potencjalnie bardzo kosztownej utraty możliwości podejmowania decyzji technologicznych.

Solidny plan awaryjny musiałby zatem rozróżniać między ograniczoną ciągłością działania, pełnym przywróceniem działania i migracją na inną platformę. Dla każdego z tych scenariuszy konieczne byłoby przeanalizowanie odrębnych warunków wstępnych. Na przykład, prosta kopia zapasowa danych jest mało pomocna, jeśli brakuje programów niezbędnych do efektywnego przetwarzania informacji i egzekwowania odpowiednich reguł dostępu.

Zależność wzrasta wraz z każdą specjalistyczną procedurą

Często używany termin „lock-in” opisuje sytuację, w której zmiana dostawcy jest teoretycznie możliwa, ale w praktyce staje się coraz bardziej złożona. W systemach chmurowych takie „lock-in” wynika z wzajemnego oddziaływania funkcji platformy, interfejsów, struktur danych i ugruntowanych procesów operacyjnych. Im bardziej wyspecjalizowane aplikacje wymagają konkretnych usług od konkretnego dostawcy, tym większego nakładu pracy wymaga powielenie równoważnej funkcjonalności w innym miejscu.

Nie każde zastosowanie zastrzeżonej technologii jest nieekonomiczne. Specjalistyczne narzędzie może zapewnić znaczną przewagę w zakresie produktywności. Problem polega na tym, że krótkoterminowe korzyści są często oczywiste, podczas gdy przyszłe koszty przejścia na nowe rozwiązanie pozostają niepewne. Grozi to powstaniem systematycznej nierównowagi: obecna wygoda jest w pełni uwzględniana, a przyszłe uzależnienie jest jedynie wspominane w kategoriach abstrakcyjnych.

Powiązanie na poziomie aplikacji jest szczególnie istotne. Maszynę wirtualną można przenieść stosunkowo łatwo, podczas gdy złożona aplikacja biznesowa z usługami baz danych, tożsamości i analityki specyficznymi dla danego dostawcy nie jest możliwa. Dlatego fakt, że platforma obsługuje kontenery, nie jest wystarczającym dowodem jej zamienności. Kluczowym czynnikiem jest to, czy całą funkcjonalność biznesową można wdrożyć w innym środowisku przy rozsądnym nakładzie pracy.

Spójna architektura musiałaby uwzględniać korzyści płynące z poszczególnych usług platformy w zestawieniu z wynikającymi z tego barierami utrudniającymi przejście na nową platformę. Celem nie byłaby całkowita jednolitość techniczna, lecz celowe zróżnicowanie: standardowe funkcje podstawowe powinny pozostać w jak największym stopniu zamienne, podczas gdy kluczowe funkcje specjalistyczne byłyby analizowane oddzielnie pod kątem ich wartości dodanej i zależności.

Problemy rynku europejskiego zaczynają się od jego skali

Wyzwanie strukturalne wykracza daleko poza niemieckie służby wywiadowcze. Europejski rynek usług infrastruktury chmurowej osiągnął wartość około 61 miliardów euro w 2024 roku, czyli około sześć razy więcej niż w 2017 roku; kwota ta obejmuje usługi infrastrukturalne i platformowe, a także hostowane chmury prywatne, ale nie cały rynek oprogramowania. Europejscy dostawcy w tym okresie ponad trzykrotnie zwiększyli swoje przychody regionalne, ale mimo to stracili względny udział w rynku.

Ich łączny udział spadł z 29% w 2017 r. do około 15% w 2022 r., a następnie utrzymał się na mniej więcej tym samym poziomie; Amazon, Microsoft i Google łącznie odpowiadały za około 70% w badaniu rynku opublikowanym w połowie 2025 r. Dane te odnoszą się do rynku europejskiego i nie należy ich utożsamiać z rynkiem ograniczonym wyłącznie do UE ani z konkretnym segmentem zamkniętych systemów wywiadowczych.

Ten rozwój sytuacji pokazuje, dlaczego sam wzrost przychodów nie gwarantuje niezależności technologicznej. Europejskie firmy mogą odnosić większe sukcesy, jednocześnie pozostając w tyle za największymi platformami. Wiodący dostawcy rozkładają koszty rozwoju i inwestycji na bardzo duże bazy klientów; w związku z tym skalowalność i długoterminowe finansowanie inwestycji odgrywają kluczową rolę na europejskim rynku infrastruktury.

Realistyczna strategia europejska nie musiałaby zatem kopiować każdej funkcji największych hiperskalerów. Bardziej prawdopodobne byłoby opracowanie solidnych alternatyw dla szczególnie krytycznych obszarów zastosowań i wspólne rozwijanie ugruntowanych podstaw technicznych. Niszowy rynek zorientowany na bezpieczeństwo może mieć inne czynniki sukcesu niż rynek masowy oferujący znormalizowaną moc obliczeniową. Ogólna pozycja lidera rynkowego korporacji nie przekłada się automatycznie na jej przewagę w każdym zastosowaniu rządowym.

Państwo jako siła napędowa krzywych uczenia się technologii

Gdy wiele instytucji publicznych ma podobne wymagania dotyczące suwerenności danych i bezpiecznej współpracy, wspólne standardy mogą stworzyć większy i bardziej niezawodny rynek. Firmy zyskują wówczas lepszą podstawę do inwestowania w dokumentację, audyty bezpieczeństwa i profesjonalne operacje. Ekosystem openDesk, z licznymi partnerami w zakresie oprogramowania i operacji, pokazuje, że takie podejście oparte na współpracy jest już wdrażane w praktyce.

Stanowi to argument ekonomiczny przemawiający za celowym wykorzystaniem odpowiednich rozwiązań europejskich. Ich korzyści nie ograniczają się do konkretnego miejsca pracy, ale mogą obejmować późniejsze zastosowania i inne obiekty. Wielokrotnego użytku komponenty, wykwalifikowany personel i sprawdzone modele operacyjne potencjalnie obniżają koszty początkowe dla kolejnych użytkowników. Te dodatkowe efekty można łatwo przecenić, biorąc pod uwagę jedynie początkowe wdrożenie.

Jednocześnie nie może to dawać prawa do trwałej ochrony. Europejscy dostawcy również muszą wykazać się wydajnością, niezawodnością i opłacalnością ekonomiczną. Polityka chroniąca każde lokalne rozwiązanie, niezależnie od jego jakości, mogłaby generować wysokie koszty i nowe zależności. Kluczem nie jest eliminacja konkurencji, lecz stworzenie realnych alternatyw technicznych i ekonomicznych.

Kluczowe jest również zapobieżenie zastąpieniu międzynarodowego monopolu przez ledwo weryfikowalną zależność krajową. Otwarte interfejsy, transferowalna wiedza operacyjna i wielu wykwalifikowanych dostawców usług są zatem równie ważne, jak siedziba firmy. Ostatecznie suwerenność powinna zwiększać możliwości działania użytkownika, a nie jedynie zmieniać pochodzenie jego najważniejszego dostawcy.

Centrum Bezpieczeństwa i Obrony – Zdjęcie: Xpert.Digital

Centrum Bezpieczeństwa i Obrony oferuje fachowe doradztwo i aktualne informacje, aby skutecznie wspierać firmy i organizacje we wzmacnianiu ich roli w europejskiej polityce bezpieczeństwa i obrony. Współpracując ściśle z Grupą Roboczą SME Connect Defence, Centrum w szczególności promuje małe i średnie przedsiębiorstwa (MŚP), które chcą dalej rozwijać swoje zdolności innowacyjne i konkurencyjność w sektorze obronnym. Jako centralny punkt kontaktowy, Centrum tworzy w ten sposób kluczowy pomost między MŚP a europejską strategią obronną.

W związku z tym:

• Grupa robocza SME Connect Defence – Wzmacnianie MŚP w europejskiej obronności

OpenDesk jest istotny, ale nie zastąpi w pełni chmury

Pakiet biurowy i do współpracy openDesk został uruchomiony w październiku 2024 roku i, według Centrum Suwerenności Cyfrowej, do października 2026 roku został zainstalowany na około 100 000 stanowisk administracyjnych. Liczba ta przedstawia deklarowany wskaźnik adopcji, a nie dowód na 100 000 aktywnych użytkowników dziennie ani odpowiadającą temu liczbę wysoce poufnych stanowisk roboczych. Niemniej jednak pokazuje ona, że ​​europejska współpraca open source już dawno wykroczyła poza małe projekty demonstracyjne.

Z technicznego punktu widzenia porównanie musi pozostać precyzyjne. OpenDesk łączy w sobie aplikacje do pracy biurowej i współpracy, podczas gdy Google Distributed Cloud to znacznie szersza platforma infrastrukturalno-usługowa. Pakiet do współpracy nie zastępuje automatycznie architektury pamięci masowej, baz danych, zasobów obliczeniowych i specjalistycznych usług całego środowiska inteligentnego. Każdy, kto przedstawia obie oferty jako bezpośrednio zamienne, kompletne rozwiązania, myli różne poziomy techniczne.

Niemniej jednak, OpenDesk jest istotny dla tej debaty, ponieważ nie każda codzienna współpraca musi wymagać konsekwentnie zastrzeżonej platformy. Tam, gdzie organy publiczne wspólnie edytują dokumenty, koordynują projekty lub komunikują się, otwarte aplikacje mogą oferować konkretne alternatywy. To może przynajmniej częściowo zmniejszyć zależność, nawet jeśli nadal wykorzystywane są różne infrastruktury.

W październiku 2026 roku zademonstrowano i przetestowano działanie openDesk w całkowicie odizolowanych środowiskach; jednocześnie skoncentrowano się na zabezpieczeniu go do poziomu „VS-NUR FÜR DEN DIENSTGEBRAUCH” (Zastrzeżone – Tylko do użytku biurowego). Nie należy tego interpretować jako dowodu gotowości operacyjnej dla wszystkich zadań przetwarzania do poziomu „GEHEIM” (Tajne), ponieważ te klasyfikacje są wyraźnie różne. Działająca demonstracja offline jest ważnym krokiem technicznym, ale nie stanowi całkowitego dowodu przydatności do wszystkich wysoce wrażliwych przypadków użycia.

Matryca ukazuje korzyści płynące z otwartej komunikacji

Element i otwarty protokół Matrix również stanowią praktyczne punkty wyjścia. BwMessenger opiera się na tych komponentach i jest obsługiwany przez BWI w centrach danych Bundeswehry; BundesMessenger przenosi to podejście do administracji publicznej. W ten sposób istnieją już konkretne doświadczenia z komunikacją kontrolowaną przez państwo na otwartej bazie technicznej.

Ekonomiczna zaleta takich fundamentów leży w fundamentalnej rozdzielności oprogramowania, eksploatacji i usług. Jeśli organ publiczny zarządza własną infrastrukturą lub może wybierać między odpowiednimi operatorami, powstają lepsze warunki konkurencji. Kontrola nad bieżącą usługą nie musi wówczas pozostawać w rękach pierwotnego producenta oprogramowania.

Jednak nawet komunikator nie jest kompletną platformą analityczną. Bezpieczne przesyłanie wiadomości, wspólna edycja dokumentów i przetwarzanie dużych zbiorów danych to odrębne zadania. Co więcej, każda konkretna konfiguracja musi spełniać niezbędne wymogi bezpieczeństwa; użytkowanie przez instytucje rządowe nie oznacza automatycznie przydatności dla każdego poziomu klasyfikacji bezpieczeństwa. Otwarta komunikacja jest zatem ważnym elementem suwerennej architektury, ale nie stanowi uniwersalnego rozwiązania wszystkich problemów infrastrukturalnych.

Otwartość nie zastępuje własnych kompetencji

Oprogramowanie open source może rozszerzyć możliwości kontroli, ponieważ jego struktura jest przejrzysta, a dalszy rozwój może być w zasadzie rozłożony na wielu interesariuszy. Jednak ta możliwość rozwija swój pełny potencjał tylko wtedy, gdy dostępni są prawdziwie wykwalifikowani specjaliści, odpowiednie narzędzia programistyczne i zrównoważone finansowanie odpowiedzialności. Sama przejrzystość kodu źródłowego nie eliminuje automatycznie luk w zabezpieczeniach ani problematycznych zależności.

Zwłaszcza w przypadku złożonych systemów, nie wystarczy teoretyczna możliwość modyfikacji poszczególnych programów. Potrzebna jest wiedza o ich wzajemnych interakcjach, tworzenie niezawodnych pakietów instalacyjnych i testowanie nowych wersji. Skupienie się na utwardzonych komponentach podstawowych i bezpiecznych łańcuchach dostaw w rządowym ekosystemie open source pokazuje, jak istotny jest ten poziom organizacyjny.

Otwartość jest zatem raczej warunkiem wstępnym dla dodatkowych działań niż bezpłatną gwarancją. Jej korzyści ekonomiczne polegają na tym, że inwestycje w wiedzę i rozwój można łatwiej ponownie wykorzystać między instytucjami. Aby to się udało, adaptacje powinny być w idealnym przypadku przekazywane z powrotem do wspólnie utrzymywanych fundamentów. Z drugiej strony, wiele trwale oddzielnych, wyspecjalizowanych wersji zwiększyłoby koszty utrzymania i ryzyko bezpieczeństwa.

Niedobory kadrowe należy również realistycznie rozwiązać. Agencja nie staje się suwerenna, przejmując całą pracę samodzielnie. Bardziej rozsądnym modelem jest taki, w którym państwo posiada wystarczające uprawnienia do wewnętrznej oceny i kontroli, a jednocześnie może korzystać z usług kilku profesjonalnych dostawców usług. Nie eliminuje to całkowicie zależności, ale ułatwia ich weryfikację i zarządzanie.

Niemieckie Siły Zbrojne prezentują bardziej złożony obraz

Dla kontekstualizacji chmury ND, prywatna chmura niemieckich sił zbrojnych jest istotna, ponieważ również wykorzystuje technologię Google, a BWI odgrywa w niej kluczową rolę. Platforma ta nie jest jednak synonimem pojedynczej chmury Google: niemieckie siły zbrojne stosują podejście wykorzystujące kilka technologicznie odrębnych środowisk, w tym VMware, Google i oprogramowanie open source.

Pierwszy etap wdrożenia rozpoczął się w 2025 roku; rozwój i integracja stosu Google miały rozpocząć się w 2026 roku, a ich zakończenie zaplanowano na koniec 2027 roku. Platforma SAP Business Technology Platform została wymieniona jako konkretny przypadek użycia, natomiast planowane są dwa oddzielne środowiska dla informacji jawnych i niejawnych (VS-NfD). Opublikowanego harmonogramu nie należy interpretować jako ostatecznego stanu operacyjnego.

Ten przykład ilustruje, że fundamentalne decyzje dotyczące oprogramowania mogą prowadzić do dalszych decyzji infrastrukturalnych. Jeśli potrzebna jest specjalistyczna platforma, której obsługiwane środowiska operacyjne są ściśle zdefiniowane, rzeczywisty wybór zawęża się jeszcze przed uwzględnieniem poszczególnych dostawców chmury. Analiza suwerenności musi zatem obejmować cały łańcuch techniczny i nie może kończyć się na widocznym znaczniku infrastruktury.

Jednak wiele platform zapewnia prawdziwą skalowalność tylko wtedy, gdy kluczowe aplikacje można faktycznie przenosić między nimi. Trzy oddzielne środowiska, każde z własnymi, ściśle powiązanymi procedurami, początkowo oznaczają różnorodność, ale jeszcze nie wzajemną wymienność. BWI wyraźnie wskazuje na redukcję zależności od dostawców i łatwą migrację aplikacji jako cele swojego podejścia.

Ryzyko prawne wymaga precyzji technicznej

Debaty na temat amerykańskiej technologii często odwołują się do ustawy CLOUD Act. Jej przesłanką prawną jest to, że firmy podlegające prawu amerykańskiemu mogą być zobowiązane do ujawnienia danych, które są w ich posiadaniu, pod ich opieką lub kontrolą, niezależnie od miejsca ich przechowywania. Dlatego samo posiadanie siedziby w Niemczech nie eliminuje automatycznie wszystkich ryzyk prawnych.

Z drugiej strony, ustawowe prawo do ujawnienia danych nie tworzy technicznego dostępu, który wcześniej nie istniał. Jeśli dostawca faktycznie nie ma dostępu do danych ani kontroli nad niezbędnymi kluczami, architektura ta musi zostać uwzględniona w ocenie prawnej. Dlatego też odizolowanej platformy nie można po prostu utożsamiać z konwencjonalną, obsługiwaną przez producenta usługą internetową.

W przypadku ND Cloud kluczowe pozostają szczegóły, które nie są publicznie znane: jakie role są dostępne lokalnie, jak działają procedury dostępu awaryjnego, jakie informacje są potrzebne do analizy błędów i kto kontroluje klucze kryptograficzne? Ogólna dokumentacja Google opisuje oddzielne role operacyjne i konkretne procedury awaryjne, ale nie opisuje to automatycznie ostatecznej implementacji w Niemczech. Całkowite otwarcie dostępu byłoby zatem równie nieodpowiednie, jak bezpodstawne twierdzenie o automatycznym dostępie do danych w Ameryce.

Należy odróżnić to od ryzyka zakłóceń w świadczeniu usług. Nawet jeśli dostęp do danych jest technicznie niemożliwy, konflikty prawne lub geopolityczne mogą mieć wpływ na usługi takie jak konserwacja i wsparcie oprogramowania. Kompleksowa ocena suwerenności musi zatem uwzględniać zarówno kontrolę nad informacjami, jak i ciągłość świadczenia kluczowych usług.

Co powinna zawierać uczciwa kalkulacja kosztów

Kompleksowa analiza ekonomiczna musiałaby obejmować więcej niż tylko koszty sprzętu i oprogramowania. Musi również uwzględniać integrację, personel, energię, szkolenia, monitorowanie bezpieczeństwa, tworzenie kopii zapasowych danych, możliwości ponownego uruchamiania oraz ciągłą adaptację wyspecjalizowanych procesów. W przypadku chmury obliczeniowej ND brakuje publicznie dostępnych szczegółowych danych, które pozwoliłyby na wiarygodną ocenę ilościową tych komponentów; znany szacunek wynoszący co najmniej 500 milionów euro nie zastępuje tego zestawienia.

Dodatkowo należy uwzględnić koszty, które powstają wyłącznie podczas migracji. Należą do nich transfer danych, adaptacja programu, tymczasowa praca równoległa oraz ponowne audyty bezpieczeństwa. W związku z tym europejskie przepisy dotyczące migracji do chmury rozróżniają kilka etapów technicznych, od ekstrakcji danych po migrację do środowiska docelowego. Migracja o dużym znaczeniu finansowym wymaga zatem znacznie więcej niż tylko pobrania archiwum plików.

Ważne jest również rozróżnienie między kosztami gospodarstw domowych a efektami makroekonomicznymi. Usługi świadczone przez niemieckie centra danych i dostawców usług mogą generować lokalną wartość dodaną, nawet jeśli oprogramowanie bazowe pochodzi od międzynarodowej korporacji. Z drugiej strony, europejski dostawca nie jest wolny od zależności od globalnego łańcucha dostaw. Rzetelna analiza musiałaby zatem uwzględniać rzeczywisty rozkład wiedzy i przychodów, a nie tylko przypisywać wszystkie wydatki do jednego kraju pochodzenia.

Ostatecznie, różne scenariusze kryzysowe wymagałyby oddzielnej oceny. Krótkotrwała przerwa w świadczeniu pomocy technicznej, dłuższe wstrzymanie aktualizacji i krótkotrwała zmiana platformy miałyby różne konsekwencje. Zamiast generować pozornie precyzyjną wartość dla wszystkich ryzyk, bardziej odpowiednie byłoby przejrzyste przedstawienie przepustowości, założeń i szczególnie poważnych konsekwencji. Obecnie brakuje wystarczających publicznie dostępnych danych projektowych, aby określić takie wartości.

Mierzalna autonomia zamiast uspokajających etykietek

Wraz z Kryteriami umożliwiającymi autonomię przetwarzania w chmurze, opublikowanymi w kwietniu 2026 r., niemiecki Federalny Urząd Bezpieczeństwa Informacji (BSI) przedstawił ramy mające na celu bardziej systematyczną ocenę samostanowienia w korzystaniu z usług chmurowych. Kryteria te uzupełniają zorientowane na bezpieczeństwo wymogi C5, ale same w sobie nie mają wpływu regulacyjnego. Bezpieczeństwo i suwerenność są zatem traktowane jako powiązane, choć odrębne, kwestie oceny.

Ramy te rozróżniają aspekty strategiczne, prawne, związane z danymi, operacyjne, związane z łańcuchem dostaw i technologiczne. Istotne są tu konkretne wskaźniki testowe, takie jak przenoszalność wiedzy operacyjnej, dostępność niezależnej konserwacji oraz możliwość kontynuowania działalności w przypadku awarii strony trzeciej. Takie cechy są bardziej istotne dla platformy o wysokim poziomie bezpieczeństwa niż ogólny samookreślenie jako suwerennej.

W praktyce szczególnie cenna byłaby regularnie testowana procedura restartu. Pozwoliłaby ona wykazać, czy istniejące kopie zapasowe, dokumentacja i wiedza specjalistyczna są wystarczające do przywrócenia podstawowych funkcji w jasno określonych warunkach awarii. Umożliwiłaby również sprawdzenie, które dane i aplikacje są faktycznie użyteczne w środowisku zapasowym. Udany test byłby skuteczniejszy niż czysto teoretyczna opcja przełączania.

Nawet postęp regulacyjny nie zmienia tego technicznego wyzwania. Ustawa o danych zakazuje pobierania opłat za zmianę dostawcy w przypadku objętych nią usług przetwarzania danych od 12 stycznia 2027 r. Nie oznacza to jednak automatycznie, że każde konkretne środowisko wywiadowcze podlega temu zakazowi, ani nie eliminuje wewnętrznych kosztów migracji, rozwoju i bezpieczeństwa. Bezpłatna zmiana dostawcy i faktyczna techniczna zamienność to nie to samo.

Większa moc obliczeniowa wymaga jasnych granic dostępu

Wspólna platforma może ułatwiać współpracę, ale nie może wyrównywać szans poprzez uproszczenie aspektów technicznych i minimalizowanie różnic w zakresie odpowiedzialności prawnej i praw do danych. Wspólna infrastruktura nie daje automatycznie wszystkim stronom pełnego pozwolenia na swobodne korzystanie ze wszystkich zawartych w niej informacji. Szczególnie w przypadku wymiany informacji między służbami wywiadowczymi a policją obowiązują zaostrzone wymogi konstytucyjne, których nie należy mylić z zwykłą wymianą informacji między służbami wywiadowczymi.

Dla architektury oznacza to, że role, cele, pochodzenie i dozwolone udostępnianie danych muszą być odpowiednio zmapowane. Platformy techniczne mogą obsługiwać szczegółowe reguły dostępu i śledzenie rejestrowania; dokumentacja Google opisuje uprawnienia oparte na rolach i atrybutach, a także rejestrowanie dostępu. Jednak zgodne z prawem, praktyczne zastosowanie pozostaje wyłączną odpowiedzialnością stron odpowiedzialnych.

Ponadto istnieje ryzyko koncentracji. Wspólna infrastruktura może gromadzić wiedzę specjalistyczną w zakresie bezpieczeństwa, ale jednocześnie poważne zakłócenia mogą wpłynąć na wiele agencji. Dlatego logiczna separacja, odzyskiwanie danych i niezależne mechanizmy kontroli muszą być rozpatrywane łącznie. Ocena ekonomiczna nie powinna zależeć wyłącznie od wykorzystania centrum danych, ale również od tego, jak dobrze utrzymane są funkcje krytyczne podczas częściowych zakłóceń.

Sztuczna inteligencja przenosi zależność na poziom modelu

Automatyczne tłumaczenie, podsumowywanie i analiza dużych zbiorów danych to potencjalne zastosowania dla zamkniętej chmury; Google oferuje odpowiednie funkcje sztucznej inteligencji dla tej rodziny produktów. Pozwala to na integrację techniczną wykraczającą poza infrastrukturę, obejmującą modele, interfejsy i organizację przepływów pracy analitycznej. Im bardziej wyspecjalizowane procesy są powiązane z konkretnymi usługami sztucznej inteligencji, tym ważniejsza staje się ich wymienność.

Model obsługiwany lokalnie nie jest jednak automatycznie suwerenny. Istotne są również prawa użytkowania, możliwość aktualizacji, dostępne komponenty modelu oraz możliwość dalszego korzystania z narzędzia po zmianie warunków; ogólne warunki produktu wyraźnie rozróżniają różne modele i formy użytkowania. Na podstawie ogólnej dostępności produktu nie można wnioskować, czy konkretne rozwiązania AI są rzeczywiście przeznaczone dla chmury ND.

Z ekonomicznego punktu widzenia, sztuczna inteligencja powinna być zatem oceniana na podstawie jakości jej wyników, a nie tylko liczby przetworzonych dokumentów. Dodatkowe wydatki mogą być cenne, jeśli przyspieszają analizę i ułatwiają wyszukiwanie istotnych spostrzeżeń. Mogą jednak również generować dodatkowe działania, jeśli konieczne będzie sprawdzenie błędnych podsumowań lub nieprawidłowych linków; dostawca zazwyczaj wskazuje potencjalne błędy w wynikach systemów generatywnych.

Strategicznie solidna konstrukcja pozwoliłaby zatem na jak najczystsze oddzielenie pamięci masowej, modeli i interfejsów użytkownika. Umożliwiłoby to aktualizację poszczególnych narzędzi analitycznych bez konieczności wymiany całej platformy. Zwłaszcza w obliczu szybko rozwijających się technologii sztucznej inteligencji (AI), możliwość wdrażania kontrolowanych aktualizacji jest korzyścią ekonomiczną, a nie jedynie wymogiem politycznym.

Współpraca międzynarodowa bez stałej zależności od rdzenia

Wymiana z usługami partnerskimi może wymagać kompatybilnych procedur technicznych. Nie oznacza to jednak, że wszystkie wewnętrzne procesy robocze muszą odbywać się na tej samej platformie. Niemieckie Siły Zbrojne (Bundeswehra) wymieniają międzynarodową interoperacyjność jako kluczowy cel swojej strategii wieloplatformowej i wyraźnie wiążą ją ze zmniejszeniem zależności od dostawców.

Rozsądnym podejściem byłoby rozróżnienie między podstawowymi operacjami krajowymi a jasno określonymi funkcjami wymiany. Specjalistyczne interfejsy i zatwierdzone procedury transferu mogłyby być wykorzystywane do współpracy międzynarodowej, podczas gdy centralne repozytoria danych i podstawowa współpraca pozostałyby niezależne. Zaangażowanie międzynarodowego dostawcy technologii byłoby zatem decyzją o ograniczonym zakresie funkcjonalnym i nie stanowiłoby automatycznie podstawy dla wszystkich procesów wewnętrznych.

Interfejsy nie rozwiązują jednak wszystkich problemów. Różne poziomy poufności, modele danych i reguły udostępniania generują dodatkowe obciążenie. Bardziej odseparowana architektura może być zatem początkowo droższa i bardziej złożona. Jej zaletą jest to, że poszczególne funkcje współpracy można modyfikować bez wpływu na krajowe operacje bazowe. To, czy ta zaleta uzasadnia dodatkowe koszty, należałoby zbadać w oparciu o konkretne wymagania.

Najważniejszą umiejętnością jest zdolność do przełączania

Z technicznego punktu widzenia najbardziej przekonująca perspektywa nie leży ani w całkowitym odrzuceniu amerykańskiej technologii, ani w założeniu, że techniczna separacja sieci rozwiązuje wszelkie problemy z suwerennością. Planowana chmura ND mogłaby rozwiązać rzeczywiste problemy z wydajnością; jednak jej izolowana architektura i ciągłe uzależnienie od zewnętrznego oprogramowania muszą być oceniane oddzielnie.

W przypadku ogólnej współpracy odpowiednie otwarte rozwiązania wymagają systematycznej oceny, ponieważ usługi oparte na platformie OpenDesk i Matrix są już praktycznie wdrożonymi elementami składowymi. W przypadku wysoko wyspecjalizowanego przetwarzania mogą obowiązywać różne wymagania techniczne. Co istotne, uzasadnione wyjątki nie powinny być rozszerzane do postaci ogólnej, trwałej zależności, a pozostałe ryzyka powinny być wyraźnie zidentyfikowane.

Solidna strategia wymagałaby zatem połączenia wewnętrznego doświadczenia w zakresie oceny, przejrzystych procesów aktualizacji oraz sprawdzonych planów awaryjnych. Nie każda aplikacja wymaga w pełni funkcjonalnej i natychmiast dostępnej platformy pomocniczej. Jednak kluczowe funkcje powinny być zaprojektowane w taki sposób, aby zewnętrzna awaria wydajności nie prowadziła koniecznie do utraty zdolności administracyjnych. Wymaga to zabezpieczeń technicznych, a także wykwalifikowanego personelu i długoterminowego finansowania.

Prawdziwy test suwerenności nie następuje podczas nieprzerwanej, normalnej pracy. Zaczyna się w momencie zmiany warunków przez dostawcę, awarii wsparcia lub zmiany ram politycznych. Wysokowydajna chmura jest cenna dla państwa. Staje się strategicznie zarządzalna dopiero wtedy, gdy państwo nie tylko kontroluje swoją bieżącą działalność, ale także ma realne możliwości na przyszłość.

Markus Becker

Chętnie będę pełnić rolę Twojego osobistego doradcy.

Szef Rozwoju Biznesu

Przewodniczący grupy roboczej SME Connect Defense

LinkedIn

Konrad Wolfenstein

Chętnie będę pełnić rolę Twojego osobistego doradcy.

Możesz się ze mną skontaktować pod adresem wolfenstein∂xpert.digital lub

Po prostu zadzwoń do mnie pod numer +49 7348 4088 965 .

LinkedIn