Jesteś dyrektorem IT w niemieckim ubezpieczycielu zdrowotnym podlegającym DORA i nadzorowi BaFin. Twój zarząd właśnie przesłał Ci ogłoszenie Komisji Europejskiej o Pakiecie Suwerenności Technologicznej, przyjętym we wtorek 3 czerwca 2026, z jednym zdaniem: co to oznacza dla naszych zamówień chmurowych na 2027? Postępowanie opiewa na 18 milionów euro w okresie pięciu lat. Twój CIO chce jednostronicowej notatki na piątek.

Proponowany Akt Rozwoju Chmury i AI (CADA) jest częścią pakietu, która najbardziej bezpośrednio dotyka Twoich zamówień. Sklasyfikuje on dostawców chmurowych w czterech poziomach suwerenności. Najwyższego poziomu — z prawnej logiki wniosku — nie mogą osiągnąć dostawcy z siedzibą w USA, ponieważ CLOUD Act tworzy strukturalny konflikt. Dane finansowe, sądowe i zdrowotne rządów oraz organizacji sektora publicznego będą musiały działać na infrastrukturze na najwyższym poziomie suwerenności. Wniosek jest rozporządzeniem na podstawie art. 114 TFUE, które produkuje bezpośrednio stosowany skutek rynku wewnętrznego. Jeśli przejdzie nienaruszony, państwa członkowskie nie mogą indywidualnie osłabić jego stosowania.

Nie przejdzie nienaruszony i nie przejdzie do 2027. Trilog zajmie 18 do 24 miesięcy. Pierwszym praktycznym skutkiem dla Twoich zamówień nie jest samo rozporządzenie; jest nim język zamówieniowy, który sprytni oferenci już teraz przygotowują. Twój przetarg na 18 milionów euro, zamykany jesienią 2026, będzie czytany przez oferentów pozycjonujących się pod klasyfikację CADA, którą zakładają na 2028 lub 2029. Odpowiedzi oferentów powiedzą Ci, kto traktuje przyszłą regulację poważnie, a kto nie.

Ten artykuł to audyt tego, co proponuje CADA, czego faktycznie wymagają cztery poziomy, co Twoje akta zamówieniowe powinny już zakładać o kierunku regulacji, i konkretnego pytania, na które jednostronicowa notatka Twojego CIO musi odpowiedzieć, zanim zamknie się runda budżetowa.

Co proponuje pakiet

Pakiet Suwerenności Technologicznej zawiera cztery instrumenty. Pierwszy to Akt Rozwoju Chmury i AI (CADA) z ramami klasyfikacji suwerenności. Drugi to Chips Act 2.0, aktualizujący ustawę z 2023, by podnieść docelowy udział UE w globalnej produkcji chipów. Trzeci to Strategia Open Source, formalizująca open source jako strukturalny element polityki cyfrowej UE. Czwarty to Strategiczna Mapa Drogowa Cyfryzacji i AI w Energetyce, do której dołączył na podium komisarz Dan Jørgensen obok komisarz Henny Virkkunen.

Ramowanie pakietu przez Virkkunen na konferencji prasowej: “We want to be sure nobody has a kill switch.” („Chcemy mieć pewność, że nikt nie ma kill switcha."). Ursula von der Leyen owinęła politykę: “We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure.” („Nie możemy sobie pozwolić na zależność od innych w technologiach, które utrzymują nasze szpitale w ruchu, naszą sieć energetyczną stabilną i nasze usługi bezpiecznymi."). Polityczne ramowanie to suwerenność. Ramowanie zamówieniowe — z którym musi się zmierzyć Twój przetarg — to klasyfikacja, obowiązkowe wymagania poziomowe i podstawa prawna na mocy art. 114 TFUE, która daje rozporządzeniu bezpośrednio stosowany skutek rynku wewnętrznego.

Komponent chmurowy jest najbardziej merytoryczny dla dzisiejszych decyzji zamówieniowych. Czteropoziomowy schemat CADA jest stopniową drabiną strukturalnej separacji od kontroli spoza UE: Poziom 1 obejmuje minimalne deklaracje rezydencji danych; Poziom 2 ustanawia niezależność operacyjną od kontroli spoza UE; Poziom 3 wymaga pełnej architektonicznej separacji od zależności spoza UE; Poziom 4 deklaruje weryfikowalną ciągłość w warunkach wrogości geopolitycznej. Wymóg obowiązkowego Poziomu 3 dla rządowych danych finansowych, sądowych i zdrowotnych to część bezpośrednio wpływająca na Twoje zamówienia. Egzekwować będą krajowe wyznaczone organy.

Czego faktycznie wymagają cztery poziomy, językiem operacyjnym

Tekst wniosku Komisji opisuje poziomy językiem regulacyjnym. Operacyjne tłumaczenie jest tym, czego potrzebuje Twój zespół architektoniczny.

Poziom 1 to deklaracja rezydencji danych. Twój dostawca zobowiązuje się umownie do trzymania danych na terytorium UE. To deklarują dziś większość europejskich ofert suwerennej chmury — Microsoft Azure Sovereign Cloud, AWS European Sovereign Cloud, Google Cloud Sovereign — i to większość z tych ofert dostarcza. Poziom 1 jest spójny z funkcjonowaniem dostawcy z siedzibą w USA. Większość istniejących umów M365, z klauzulami rezydencji danych już na miejscu, spełniłaby Poziom 1 bez zmiany architektonicznej.

Poziom 2 dodaje niezależność operacyjną od kontroli spoza UE. Twój dostawca zobowiązuje się nie tylko do rezydencji w UE, ale i do decyzji operacyjnych podejmowanych przez podmioty z siedzibą w UE. To poziom, na którym warianty suwerennej chmury dostawców z siedzibą w USA albo kwalifikują się, albo nie kwalifikują, zależnie od struktury umownej. Obecna architektura Microsoft Sovereign Cloud jest zaprojektowana, by kwalifikować się do Poziomu 2 przez strukturyzowanie kontroli operacyjnej przez irlandzką spółkę zależną Microsoftu z polską opcją rezydencji danych. Czy taka kwalifikacja przetrwa interpretację „niezależności operacyjnej" przez trilog — to jedno z otwartych pytań.

Poziom 3 wymaga pełnej architektonicznej separacji od zależności spoza UE. To poziom, z którego prawna logika wniosku wyklucza dostawców z siedzibą w USA. CLOUD Act tworzy strukturalny konflikt, którego żadna struktura umowna nie wyeliminuje. Poziom 3 to domena OVHcloud, Outscale, StackIT należącego do Schwarz Digits, IONOS, T-Systems Open Telekom Cloud i federalnej platformy KIPITZ. Dla Twoich zamówień ubezpieczyciela zdrowotnego Poziom 3 jest merytorycznym ograniczeniem: obciążenia danymi finansowymi i zdrowotnymi będą, w obecnym wniosku, musiały tam działać.

Poziom 4 deklaruje weryfikowalną ciągłość w warunkach wrogości geopolitycznej. Kryteria Poziomu 4 nie są jeszcze wyliczone w publicznym wniosku. Ciągłość w warunkach wrogości to właściwość, którą organizacja ma, gdy może kontynuować działanie, jeśli jakikolwiek pojedynczy dostawca, w tym jej główny, stanie się niedostępny. Operacyjnie Poziom 4 wymaga wieloprowayderowej przenośności, infrastruktury lustrzanej dla zależności dystrybucji źródłowej poza UE oraz przećwiczonego planu ciągłości. Według roboczej definicji sugerowanej przez tekst wniosku, Poziom 4 jest właściwością, której żaden obecny europejski dostawca nie może jeszcze wiarygodnie deklarować. Definicja kryteriów będzie jednym z najbardziej spornych elementów trilogu.

Co Twoje akta zamówieniowe powinny zakładać w 2026

Twój przetarg na 18 milionów euro, zamykany jesienią 2026, zostanie udzielony w środowisko regulacyjne, które jeszcze nie istnieje. Trzy założenia, wpisane do przetargu i do akt zamówieniowych, rozstrzygną, czy kontrakt udzielony w 2026 przetrwa CADA, gdy CADA wejdzie w życie.

Zakładaj Poziom 3 dla obciążeń danymi zdrowotnymi i finansowymi. Nawet jeśli CADA zostanie zmiękczone w trilogu, niemiecka federalna warstwa zamówieniowa, warstwa nadzorcza BaFin i ramy DORA zbiegają się w założeniu, że wrażliwe dane finansowe i zdrowotne nie powinny działać na infrastrukturze chmurowej z siedzibą w USA. Zamówienie z 2026, które zamyka Twoje kluczowe systemy ubezpieczenia zdrowotnego w ofercie Poziomu 1 dostawcy z USA na pięć lat, do 2028 będzie działać w ramach regulacyjnych, które chcą jego migracji. Wbuduj opcjonalność migracji w kontrakt z 2026; taniej jest negocjować klauzule wyjścia przy podpisie niż przy aneksie.

Wymagaj od oferentów ujawnienia roadmapy CADA. Twój przetarg powinien pytać każdego oferenta, formalnie, do którego poziomu CADA prognozuje się certyfikować do 2028 i jakie zmiany architektoniczne zobowiązał się wprowadzić, by ten poziom osiągnąć. Oferenci z poważną roadmapą odpowiedzą na piśmie nazwanymi zmianami technicznymi. Oferenci z odpowiedzią pozycjonującą dadzą język marketingowy. Różnica jest najbardziej informatywną daną, jaką Twój proces zamówieniowy wydobędzie.

Wbuduj odwołania do EVB-IT i §58 VgV Nr. 4 do przetargu już teraz. Federalna warstwa prawa zamówieniowego już wspiera język, którego będziesz potrzebować, gdy CADA wejdzie w życie. Przywołanie §58 VgV Nr. 4 i warunków umownych EVB-IT dla open source w przetargu 2026 robi dwie rzeczy: ustanawia precedens w Twoich aktach zamówieniowych i sygnalizuje oferentom, że Twoje biuro zamówień angażuje się z federalną warstwą suwerenności, a nie reaguje na nią.

Czego CADA nie adresuje

Cztery poziomy obejmują infrastrukturę chmurową i pewne kategorie danych rządowych. W obecnym wniosku nie adresują warstw poniżej chmury.

Infrastruktura hostingu kodu pozostaje przeważnie hostowana w USA. Kod źródłowy europejskiego stosu suwerenności żyje na GitHubie — własności Microsoftu. Wymóg architektonicznej separacji od zależności spoza UE z Poziomu 3 CADA nie rozciąga się, na ścisłą lekturę tekstu wniosku, na infrastrukturę budowy i dystrybucji komponentów open source, na których działa chmura. To ta sama luka, którą uwidacznia gdzie indziej uruchomienie Euro-Office, a CADA jej obecnie nie zamyka.

Kryptograficzne łańcuchy zaufania. Urzędy certyfikacji i operacje serwerów rootowych DNS pozostają zdominowane przez USA. Poziomy suwerenności CADA nie wyliczają wprost kryteriów łańcucha zaufania. Dostawca sklasyfikowany na Poziomie 3 może nadal zależeć od urzędów certyfikacji, których klucze rootowe są kontrolowane przez USA.

CI/CD i dystrybucja pakietów. GitHub Actions, npm, PyPI, Docker Hub, Maven Central — infrastruktura budowy, pakietów i dystrybucji, od której wszystko zależy, pozostaje przeważnie hostowana w USA. Dostawca może być Poziomem 3 na wymiarze runtime’u i Poziomem 1 na wymiarze łańcucha dostaw. CADA obecnie tego nie rozróżnia.

To nie krytyka zaprojektowanego zakresu. To obserwacja, że CADA sam z siebie nie dostarcza suwerenności łańcucha dostaw w warstwach poniżej infrastruktury chmurowej. Twoje akta zamówieniowe powinny wprost przyznać tę granicę. Czytelnik świętujący CADA jako dopełnienie europejskiego projektu suwerenności będzie czytać coś, czego wniosek nie deklaruje — i czego Twojemu CIO opłaca się nazwać na piśmie przed następnym cyklem regulacyjnym.

Czym ten artykuł nie jest

To nie jest twierdzenie, że CADA przejdzie w wersji zredagowanej — trilog zmodyfikuje wniosek; pytaniem jest, jak bardzo. To nie jest twierdzenie, że Strategia Open Source jest pusta — ramuje OSS strukturalnie; czy wyprodukuje budżet, to osobne pytanie rozstrzygane w następnym cyklu Wieloletnich Ram Finansowych, a nie w czerwcu 2026. To nie jest twierdzenie, że europejska suwerenność jest rozstrzygnięta przez pakiet. Pakiet adresuje jedną warstwę zależności, zostawia inne nietknięte i zależy od procesu legislacyjnego, który ciągnie się do 2027 lub 2028.

Notatka, której Twój CIO potrzebuje na piątek

Jednostronicowa notatka powinna sformułować trzy twierdzenia i zarekomendować dwa działania.

Trzy twierdzenia: CADA będzie prawem do 2028 lub 2029; najprawdopodobniejszy wymóg Poziomu 3 dla obciążeń finansowych i zdrowotnych przetrwa trilog w merytorycznie zaproponowanej formie; warstwa łańcucha dostaw nie zostanie zaadresowana przez CADA w tym cyklu i będzie wymagać osobnej uwagi zamówieniowej.

Dwa rekomendowane działania: napisać przetarg jesieni 2026 z obowiązkowym ujawnieniem przez oferenta roadmapy CADA i harmonogramu architektonicznej separacji; zbudować audyt łańcucha dostaw i lustrzaną infrastrukturę Codeberg-lub-równoważną po stronie klienta, niezależnie od ostatecznego dostawcy, bo ta praca jest wymagana niezależnie od tego, do jakiego poziomu CADA dostawca ostatecznie się certyfikuje.

Notatka, która formułuje te twierdzenia i rekomenduje te działania, czyta się na poziomie zarządu jako zaangażowanie z kierunkiem regulacyjnym. Notatka mówiąca „sytuacja ewoluuje i będziemy monitorować" czyta się jako rodzaj przygotowania, który nie przetrwa audytu zgodności BaFin w 2029. Przetarg jesieni 2026 to akta, które zostaną przywołane w tym audycie, jeśli wszystko pójdzie dobrze, albo opisane w prasie regulacyjnej, jeśli nie.

Źródła

Przegląd tematu: Suwerenność cyfrowa w Europie Powiązane artykuły: Jak cytować §58 VgV Nr. 4, Dostawca napisał test