Najważniejszy system AI może być tym, którego nikt nie widzi

Model to widoczna warstwa. Prawdziwa siła europejskiej AI zależy od chipów, mocy obliczeniowej, sieci, danych, kontraktów i ludzi pod spodem.

Najważniejszy system AI może być tym, którego nikt nie widzi

Maszyna stojąca za odpowiedzią

Pierwszy eksaskalowy superkomputer w Europie nie jest metaforą. JUPITER to realny system w Forschungszentrum Jülich, obsługiwany przez Jülich Supercomputing Centre. EuroHPC Joint Undertaking opisuje jego architekturę BullSequana z bezpośrednim chłodzeniem cieczą, partycję flash o pojemności 20 petabajtów o ekstremalnej szybkości oraz konstrukcję przeznaczoną do wymagających symulacji i obliczeniowo intensywnej sztucznej inteligencji. Opis pełen jest szczegółów, które umożliwiają działanie systemu: architektura procesora, warstwa pamięci masowej, metoda chłodzenia, instytucja prowadząca i ścieżka dostępu. Model, który kiedyś może na nim działać, jest tylko jednym elementem tego zdania.

To rozróżnienie łatwo zatracić, ponieważ widoczna część sztucznej inteligencji to odpowiedź. Człowiek zadaje pytanie, model zwraca tekst, a ekran sprawia wrażenie, że inteligencja dotarła w jednej paczce. Ukryta praca jest mniej efektowna. Energia elektryczna musi dotrzeć do budynku. Komponenty muszą dotrzeć w odpowiednim stanie. Obraz oprogramowania układowego musi być zaufany. Sieci muszą przenosić dane między procesorami a pamięcią masową. Tożsamość musi ustalić, która osoba lub usługa może korzystać z którego zasobu. Planista musi znaleźć moc obliczeniową. Rejestr musi informować operatora, który model, kontener i wersja danych są w użyciu. Monitoring musi zauważyć, że system się zmienił. Ktoś musi nadal umieć go naprawić w deszczowy wtorek, gdy dokumentacja producenta otrzyma nowy numer wersji, a jedyna osoba, która rozumiała starą, jest na urlopie.

W związku z tym ważny system sztucznej inteligencji może być tym, którego nikt nie widzi. To łańcuch dostaw, umowa na energię, struktura sieci, plan konserwacji, drzewo zależności oprogramowania, decyzja o zakupie i pamięć instytucjonalna, które pozwalają korzystać z modelu bez udawania, że model jest całą usługą. Gdy ten ukryty system jest słaby, bardziej zaawansowany model nie wzmacnia usługi. Daje słabemu systemowi bardziej imponujący sposób na porażkę.

To nie jest argument przeciwko modelom ani dużym publicznym programom obliczeniowym. To argument za ich uczciwym opisywaniem. Europa buduje zdolności poprzez Chips Act, EuroHPC i program AI Factories. Strony polityczne Komisji mówią o zależnościach strategicznych, odporności łańcucha dostaw, dostępie dla mniejszych firm i infrastrukturze wymaganej do godnej zaufania sztucznej inteligencji. To pytania o infrastrukturę, a nie o markę. Jeśli kontynent chce użytecznych zdolności, a nie kolekcji imponujących pokazów, musi traktować ciche warstwy jako część tych zdolności.

Odpowiedź to górna warstwa. Usługa zależy od każdej warstwy pod nią.

Model to komponent, a nie kraj

W dyskusji publicznej model bywa używany jako skrót na określenie całej zdolności. Kraj ma model, firma ma model, departament ma model, a model traktuje się tak, jakby niósł ze sobą własny łańcuch dostaw. Nie niesie. Model ma plik, parametry, środowisko uruchomieniowe i zestaw założeń co do pracy, którą ma wykonać. Resztę obowiązków bierze na siebie usługa wokół niego.

Weźmy skromny system, który klasyfikuje przychodzące dokumenty, zanim przejrzy je zespół ludzi. Potrzebuje kanału przyjmowania, kolejki, parsera, pamięci masowej, kontroli dostępu, środowiska uruchomieniowego modelu, magazynu wyników, ścieżki powiadomień, sposobu wycofania wydania i zapisu tego, co się stało. Klasyfikator może być dokładny na swoim zestawie testowym i nadal bezużyteczny, jeśli parser pominie pole, jeśli system tożsamości przyzna niewłaściwą rolę, jeśli kontener modelu nie da się pobrać albo jeśli operator nie potrafi stwierdzić, która wersja wydała rekomendację. Żadna z tych awarii nie jest halucynacją modelu. To awarie usługi, która uczyniła model istotnym.

Odwrotny błąd jest równie częsty. Zespoły opisują całą usługę jako odporną, bo model został poddany ewaluacji, a zależności pozostawiają poza granicą ewaluacji. Test modelu może sprawdzać wyniki dla wybranego obciążenia. Rzadko sprawdza, czy certyfikat nie wygasa w tym samym czasie, gdy repozytorium oprogramowania zmienia klucz podpisywania, czy warstwa pamięci masowej ma dość pojemności na dłuższy niż zwykle dokument albo czy człowiek może odzyskać rekord źródłowy po tym, jak dostawca zmieni interfejs programowania aplikacji. Te kwestie należą do systemu operacyjnego. Nadal są częścią tego, co użytkownik odbiera jako AI.

Użyteczne pytanie nie brzmi, czy model jest dobry w izolacji. Chodzi o to, które inne rzeczy muszą być prawdziwe, zanim będzie można polegać na wyniku modelu, i kto ma uprawnienia, by te rzeczy naprawić. To pytanie przenosi rozmowę z katalogu modeli na granicę systemu. Tworzy też mniej pochlebny, ale bardziej użyteczny inwentarz.

  • Jakie zasoby fizyczne muszą pozostać dostępne?
  • Które komponenty oprogramowania i oprogramowania układowego muszą dotrzeć w nienaruszonym stanie i pozostać wspierane?
  • Które usługi tożsamości, sieci, pamięci masowej i rejestru muszą odpowiadać?
  • Która organizacja odpowiada, gdy zmienia się zależność?
  • Jakie dowody pozwolą innej osobie później sprawdzić odpowiedź?
  • Proposal for the Chips Act 2.0, Komisja Europejska, 3 czerwca 2026.

Te pytania nie są teoretyczne. Stanowią różnicę między zdolnością, którą można eksploatować, a zdolnością, którą można raz zademonstrować. Demonstracje są przyjemne. Usługi kluczowe muszą przetrwać następne okno konserwacyjne.

Łańcuchy dostaw są wewnątrz granicy systemu

Prace ENISA nad integralnością łańcucha dostaw zaczynają się od nieefektownej obserwacji: rządy, organizacje, firmy i konsumenci w coraz większym stopniu polegają na produktach i usługach ICT, a więc na łańcuchach dostaw, które je dostarczają. W raporcie wymieniono zagrożenia od manipulacji podczas rozwoju, dystrybucji lub eksploatacji po podmianę na podrobione lub sklonowane komponenty. Sedno wykracza poza listę kontrolną bezpieczeństwa. Dostarczana rzecz to nie tylko pudełko. To ciąg ludzi, kodu, komponentów, umów i decyzji, dzięki którym pudełko staje się na tyle zaufane, by go używać.

Usługa AI dziedziczy ten ciąg. Uruchomienie treningu zależy od obrazu bazowego, kompilatora, sterownika, jądra, planisty i źródłowego zbioru danych. Usługa wnioskowania zależy od tych samych warstw plus środowiska serwującego, indeksu, bramy zasad i interfejsu, który może działać, gdy ruch nie przypomina zestawu testowego. Instytucja publiczna może kupić usługę zamiast któregokolwiek z tych elementów, ale ukryty łańcuch nie znika dlatego, że umowa nazywa go platformą.

Aktualizacja prognoz ENISA na 2024 rok stawia kompromitację łańcucha dostaw oprogramowania na szczycie listy zagrożeń cyberbezpieczeństwa na rok 2030. Wśród głównych obaw wymienia również niedobory umiejętności, błędy ludzkie w ekosystemach cyberfizycznych, transgranicznych dostawców usług ICT jako pojedynczy punkt awarii oraz fizyczny wpływ zakłóceń środowiskowych na krytyczną infrastrukturę cyfrową. To nie są twierdzenia, że każdy projekt AI spotka się ze wszystkimi z nich. To przypomnienie, że powierzchnia zagrożenia składa się z relacji. Łatka, dostawca, człowiek i powódź mogą wpłynąć na tę samą usługę, nawet jeśli pojawiają się w różnych rejestrach ryzyka.

Język tego samego raportu jest użyteczny, ponieważ opiera się fantazji, że ryzyko cybernetyczne należy wyłącznie do zespołu ds. bezpieczeństwa. Zależność może zostać naruszona w oprogramowaniu, ale jej konsekwencje mogą nadejść poprzez proces fizyczny, wybór zaopatrzeniowy lub brakującą umiejętność. Usługa może stać się pojedynczym punktem awarii, ponieważ jej dostawca jest technicznie doskonały i powszechnie używany. Koncentracja nie jest tym samym co niekompetencja. Jest to właściwość sieci wokół usługi.

Stwarza to praktyczny problem graniczny. Jeśli organizacja ocenia tylko model i jego bezpośrednie środowisko wykonawcze, wynik może być dokładny dla wybranej granicy i mylący dla usługi, którą prowadzi. Jeśli ocenia każdego dostawcę z równą intensywnością, wyprodukuje arkusz kalkulacyjny, którego nikt nie będzie w stanie utrzymać. Odpowiedzią jest mapa zależności, która podąża za konsekwencjami. Zidentyfikuj, co może zmienić wynik, przerwać usługę, wymazać dowody, rozszerzyć uprawnienia lub uniemożliwić odzyskanie. Następnie zapytaj, czy zależność jest na tyle widoczna, aby ją monitorować, i czy istnieje inna ścieżka.

Ta mapa powinna obejmować zwykłe materiały. Serwer wymaga pamięci, urządzeń do przechowywania danych, konwersji zasilania, sprzętu chłodzącego i części zamiennych. Sieć wymaga komponentów optycznych, przełączników, oprogramowania do routingu i ludzi, którzy znają topologię. Łańcuch dostaw oprogramowania wymaga opiekunów, infrastruktury budowania, rejestrów pakietów, kluczy podpisywania i procedur wydawniczych. Żadne z tych elementów nie staje się mniej ważne, ponieważ broszura produktowa mówi o sztucznej inteligencji.

Kuszone jest odpowiedzią w postaci większego kwestionariusza dla dostawców. Kwestionariusz może być użyteczny, ale nie jest mapą zależności. Rejestruje to, co dostawca mówi w jednym momencie. Pytanie operacyjne brzmi, czy nabywca może zauważyć zmianę, zinterpretować ją i podjąć proporcjonalne działanie. Lista certyfikatów nie zastępuje wiedzy o tym, który komponent zatrzymałby usługę, gdyby zniknął jutro rano. Europejskie organizacje są godne podziwu w zbieraniu dokumentów. Trudniejszą sztuką jest sprawienie, aby dokumenty wskazywały na decyzję.

Układy scalone czynią niewidzialne fizycznym

Europejska ustawa o chipach stwierdza fakt, który powinien być oczywisty, a mimo to wymaga stwierdzenia: półprzewodniki są elementami składowymi produktów elektronicznych i mają kluczowe znaczenie dla sektorów od komunikacji i przetwarzania danych po opiekę zdrowotną, energetykę, transport i automatyzację przemysłową. Ustawa weszła w życie we wrześniu 2023 roku i określa cele obejmujące wzmocnienie badań i przywództwa technologicznego, wzmocnienie zdolności w zakresie projektowania, produkcji i pakowania, rozwiązanie problemu niedoborów umiejętności oraz pogłębienie zrozumienia globalnego łańcucha dostaw półprzewodników.

Ta lista ma znaczenie dla AI, ponieważ moc obliczeniowa nie powstaje dzięki logo chmury. Powstaje dzięki łańcuchowi projektów, płytek, sprzętu, pakowania, testowania, dostarczania zasilania, chłodzenia, sieciowania i konserwacji. Niedobór lub opóźnienie w jednej części może zmienić to, co centrum danych może dostarczyć, nawet gdy pliki modelu są gotowe. Jeśli komponent ma długi czas realizacji, operator nie może rozwiązać problemu sprytnym monitem. Jeśli zależność oprogramowania układowego nie może być bezpiecznie zaktualizowana, wybór może być między kontrolowanym ograniczeniem usługi a niebezpieczną próbą utrzymania wszystkiego w działaniu.

Przegląd Komisji opisuje trzy filary aktu o chipach. Pierwszy wspiera budowę potencjału i innowacje, w tym linie pilotażowe i centra kompetencji. Drugi dotyczy bezpieczeństwa dostaw i odporności poprzez produkcję, zaawansowane techniki pakowania, testowanie i montaż. Trzeci tworzy mechanizmy monitorowania i reagowania na kryzysy, w tym Europejską Radę ds. Półprzewodników, która mapuje i monitoruje łańcuch wartości oraz koordynuje reakcje na kryzysy w sektorze półprzewodników. Taka konstrukcja instytucjonalna stanowi pożyteczną korektę poglądu, że suwerenność oznacza wytwarzanie każdego komponentu w kraju. Odporność zależy po części od potencjału, po części od widoczności, a po części od zdolności reagowania, gdy zależność się przesuwa.

Na stronie znajdują się też konkretne przykłady zatwierdzonych obiektów pierwszego rodzaju w Katanii, Crolles, Dreźnie, Novarze, Premstätten, Mediolanie i innych europejskich lokalizacjach. Te wpisy nie są dowodem na to, że Europa rozwiązała problem półprzewodników. Są dowodem na to, że łańcuch wartości ma fizyczne miejsca, technologie i decyzje inwestycyjne, które można nazwać po imieniu. Nazwanie ich zmienia rozmowę. Pozwala zapytać, jakie możliwości wnosi dany obiekt, na jakich wejściach wciąż polega, jakich umiejętności wymaga i jak byłby wspierany w razie zakłóceń.

Wniosek Komisji dotyczący aktu o chipach 2.0, opublikowany w czerwcu 2026 r., stwierdza, że Unia pozostaje zależna od państw trzecich w kluczowych obszarach, takich jak zaawansowana produkcja chipów i projektowanie półprzewodników. W artykule z 31 lipca jest to aktualne oświadczenie polityczne, a nie prognoza dotycząca przyszłego projektu ustawy. Jego praktyczne znaczenie jest proste: europejska usługa może być hostowana w Europie i nadal zależeć od globalnego łańcucha, którego najważniejsze decyzje zapadają gdzie indziej. Fizyczna lokalizacja jest cenna. Nie jest tym samym co kontrola.

Polityka dotycząca sztucznej inteligencji może stać się poważniejsza, jeśli zapożyczy ten fizyczny język. Zamiast pytać, czy model jest europejski, warto zapytać, które części usługi można naprawić, wymienić, sprawdzić i wstrzymać w ramach instytucji europejskich. Zamiast pytać, czy dostawca ma region europejski, warto zapytać, jak sprzęt, oprogramowanie układowe, zależności programowe i władza operacyjna przemieszczają się przez usługę. Odpowiedź będzie nieuporządkowana. Dobrze. Nieuporządkowane mapy często bywają pierwszymi uczciwymi.

Moc obliczeniowa to dobro publiczne

EuroHPC stanowi użyteczny przykład, ponieważ uwidacznia infrastrukturę obliczeniową, nie zamieniając jej w produkt konsumencki. Z publicznej listy wynika, że wspólne przedsięwzięcie zakupiło dwanaście superkomputerów najnowszej generacji w całej Europie. Lista wymienia systemy i ich gospodarzy: JUPITER w Jülich w Niemczech, LUMI w Kajaani, Leonardo w Bolonii, MareNostrum 5 w Barcelonie, Karolinę w Ostrawie i Arrhenius na Uniwersytecie w Linköping, między innymi. Lokalizacje mniej liczą się jako tabela rankingowa, a bardziej jako przypomnienie, że moc obliczeniowa jest osadzona w instytucjach, budynkach, personelu, systemach zasilania, magazynach i programach badawczych.

JUPITER jest opisywany jako pierwszy superkomputer ekaskalowy w Europie, z architekturą chłodzoną bezpośrednio cieczą, partycją flash o pojemności 20 petabajtów i modułem klastrowym wykorzystującym procesor SiPearl Rhea1 wraz z akceleratorem GPU. Strona LUMI opisuje osobne partycje CPU, GPU, analityki danych i chmury kontenerowej, z systemem przechowywania łączącym pamięć flash, równoległy system plików i usługę zarządzania danymi. Te szczegóły to nie tylko ciekawostki dla inżynierów. Mówią czytelnikowi zajmującemu się polityką, że superkomputer to zbiór zasobów o różnym charakterze. Obciążenie, które pasuje do jednej partycji, może nie pasować do innej. Dostęp, planowanie i przepływ danych są częścią tej możliwości.

MareNostrum 5, hosted by the Barcelona Supercomputing Center, and Arrhenius, being installed at Linköping University and operated by the National Academic Infrastructure for Supercomputing in Sweden, make the same point in different ways. A distributed European capacity is not one giant machine. It is a set of systems with different processors, storage arrangements, operators, access rules and scientific communities. The network between them matters, but so do the seams.

The Commission's AI Factories policy describes a programme built on that reality. AI Factories use EuroHPC supercomputing capacity to develop advanced generative AI and connect computing centres, universities, small and medium-sized enterprises, industry and financial actors. The page says that, at the time of its April 2026 update, nineteen AI Factories and thirteen antennas were operational, with at least nine new AI-optimised supercomputers planned. It also describes a long-term investment of ten billion euros through EuroHPC during 2021 to 2027. These are institutional arrangements, not a guarantee that every project will receive the capacity it wants or that every model will be trustworthy.

The value of such arrangements is not only speed. Public compute can create a place where European researchers and companies can run workloads under rules and access arrangements that are visible to public institutions. It can support experimentation that would otherwise be priced out, and it can make some knowledge reproducible across sites. It can also introduce new dependencies if a programme relies on a small number of suppliers, a single software stack or a workforce that cannot be replaced. Public ownership of a facility does not remove operational work. It makes the responsibility harder to hide, which is healthier.

When compute becomes public capability, its success should be measured beyond peak performance. Can a smaller research group obtain access? Can a sensitive workload be separated from a general one? Can an operator show which software and hardware were used? Can a team move a workload when a partition is full or a dependency is retired? Can a public authority explain the conditions under which a model was trained? A fast machine that cannot answer these questions is still useful for some science, but it is not yet a complete foundation for public AI.

Networks, storage and identity do the quiet work

The most important layers are often the ones that do not appear in an AI diagram. A diagram draws a model between an input and an output. An operator sees a chain of network paths, storage classes, identity assertions, queues, certificates, registries, secrets, observability pipelines and change controls. The diagram is not wrong. It is incomplete in exactly the way that produces expensive surprises.

Start with the network. A large model service may move data between accelerators, memory, storage and other services. A public research workload may move datasets to a supercomputer and results back to a university. A production workflow may cross a policy boundary before it reaches a model and another boundary before it returns a decision. Latency, packet loss, routing changes and maintenance can alter the behaviour of the whole service without changing a single parameter in the model. A timeout may become a retry, a retry may become duplicate work, and duplicate work may become an incorrect record. The model did not decide to retry. The surrounding system did.

Przechowywanie danych ma swoją ukrytą gramatykę. Jest rekord źródłowy, rekord przekształcony, indeks, pamięć podręczna, dziennik, kopia zapasowa, znacznik usunięcia oraz dowód wskazujący, która wersja została użyta. Usługa może być w stanie odpowiedzieć na pytanie, a jednocześnie nie być w stanie udowodnić, które dane umożliwiły udzielenie tej odpowiedzi. Przechowywanie i wyszukiwanie nie są swoim lustrzanym odbiciem. Przechowywanie wszystkiego bezterminowo może naruszać ograniczenie celu przetwarzania; usunięcie źródła przy pozostawieniu pochodnej lub pamięci podręcznej może stworzyć inny problem. Poważna granica danych określa, co jest przechowywane, jak długo, przez kogo i w jaki sposób późniejszy audytor może stwierdzić, że granica została zachowana.

Tożsamość to nie ekran logowania. To mechanizm, który nadaje osobie, usłudze lub agentowi uprawnienia do wykonania działania. Jeśli punkt końcowy wnioskowania może wywołać narzędzie, system musi wiedzieć, który podmiot złożył żądanie, która polityka zezwoliła na wywołanie i do czego narzędzie mogło uzyskać dostęp. Jeśli rejestr umożliwia promocję kontenera, musi wiedzieć, kto może zatwierdzić promocję i jakie dowody są wymagane. Jeśli certyfikat jest odnawiany automatycznie, usługa musi nadal mieć sposób na zauważenie, że relacja tożsamości się zmieniła. Sekret, który pozostaje ważny po odejściu osoby, która go zażądała, to problem utrzymaniowy z konsekwencjami dla bezpieczeństwa.

Rejestry to pamięć zmieniającego się systemu. Rejestr modeli może przechowywać wersje i metadane. Rejestr artefaktów może przechowywać kontenery, pakiety lub podpisane wydania. Rejestr danych może opisywać schematy i własność. Inwentaryzacja sprzętu może identyfikować płytę, wersję oprogramowania układowego i status wymiany. Nie chodzi o to, by stworzyć jeden rejestr dla wszystkiego. Chodzi o to, by uczynić autorytatywne źródło dla każdego twierdzenia jawnym. Jeśli żaden system nie może odpowiedzieć, który model, sterownik, wydanie danych i wersja polityki były aktywne, późniejszy przegląd będzie zmuszony do wnioskowania o historii na podstawie tego, co przetrwało w dziennikach.

Obserwowalność domyka pętlę. Metryki informują operatora, że kolejka urosła lub urządzenie się przegrzewa. Trace pokazują ścieżkę przebiegu żądania. Dzienniki niosą kontekst, choć łatwo je źle zrozumieć. Zdarzenia i poświadczenia mogą zachowywać decyzje i zmiany. Te obiekty mają różne zadania. Traktowanie ich jako wymiennych prowadzi albo do szumu, albo do fałszywego poczucia dowodu. Pytaniem projektowym jest to, co osoba musi wiedzieć, gdy usługa działa z opóźnieniem, działa błędnie, jest niedostępna lub kwestionowana, oraz który rekord może odpowiedzieć na to pytanie bez ćwiczenia z rekonstrukcji.

Można to opisać jako nudną inżynierię. To nie jest obelga. Nudna inżynieria to ta część, która działa nadal, gdy wpis o premierze zsunął się już ze strony głównej. To także część, która decyduje, czy nowy model można wdrożyć bez przepisywania instytucji wokół niego.

Utrzymanie to zdolność, a nie pozycja kosztowa

Historie o infrastrukturze lubią kończyć się na wdrożeniu. To wtedy praca staje się usługą. Model zostaje wydany, klaster zostaje oddany do użytku, fabryka zostaje otwarta, umowa zostaje podpisana, a narracja przechodzi do kolejnego ogłoszenia. Sam system trwa przez łatki, wymianę sprzętu, szkolenia, przeglądy dostępu, aktualizacje, wycofywanie, reagowanie na incydenty i stopniowe znikanie ludzi, którzy pamiętają, dlaczego wybrano dane ustawienie.

Raport ENISA o zagrożeniach umieszcza niedobór umiejętności wśród najważniejszych długoterminowych obaw. To nie tylko problem rynku pracy. To problem odporności. Usługa, której zależności rozumie więcej niż jedna osoba, ma ukryty pojedynczy punkt awarii. Organizacja może mieć zapasowe maszyny i nadal nie mieć możliwości bezpiecznego ich użycia, ponieważ podręcznik operacyjny, proces budowania lub umowa dotycząca danych żyją w pamięci jednego inżyniera. Zakup wsparcia może zmniejszyć ryzyko, ale kupujący nadal musi mieć wystarczające zrozumienie, aby kwestionować dostawcę i zdecydować, kiedy przestać.

Utrzymanie zmienia również znaczenie deklaracji o wydajności. Wynik testu porównawczego dla jednej wersji mówi coś o tej wersji w określonych warunkach. Nie oznacza, że system będzie zachowywał się tak samo po aktualizacji sterownika, zmianie kompilatora, nowym planiście zadań, innej ścieżce przechowywania danych czy nowym obciążeniu. Użyteczna usługa dba o warunki swoich deklaracji. Rejestruje wersje, dane wejściowe, sprzęt, zasady i zmiany, aby można było powtórzyć test lub wyjaśnić, dlaczego powtórzenie nie jest już możliwe.

Udawanie, że utrzymanie jest sprawą drugorzędną, ma swoją cenę w ludziach. Operatorzy odkładają aktualizacje, bo graf zależności jest niejasny. Zespoły ds. bezpieczeństwa mają trudności z ustaleniem, który pakiet faktycznie działa w produkcji. Dział zakupów odnawia umowę, bo nikt nie przećwiczył wyjścia z niej. Naukowcy nie mogą odtworzyć wyników, bo środowisko się zmieniło. Użytkownicy napotykają sporadyczne błędy, które przypisuje się modelowi, bo usługa nie ma wspólnego języka dla leżących pod nią warstw. Efektem nie jest jeden spektakularny błąd, ale powolny spadek zaufania.

Harmonogram utrzymania powinien zatem obejmować coś więcej niż tylko daty poprawek. Powinien obejmować przeglądy własności, wygasanie uprawnień dostępu, rotację certyfikatów i kluczy, testy przywracania kopii zapasowych, przegląd zależności, cykl życia sprzętu, powiadomienia o zmianach u dostawców, wycofywanie modeli oraz dowody potrzebne do każdego z tych działań. Część tych zadań można zautomatyzować. Odpowiedzialności nie da się zautomatyzować. Ktoś musi zdecydować, co stanowi istotną zmianę, kto otrzymuje sygnał i który organ może wstrzymać usługę.

Europejska skłonność do powoływania komitetu do rozwiązania trudnego problemu bywa wyśmiewana, często niesłusznie. Komitet, który jest właścicielem mapy zależności, reguły zmian i ścieżki eskalacji, jest bardziej użyteczny niż pulpit nawigacyjny, który nie należy do nikogo. Problemem nie jest zarządzanie. Problemem jest zarządzanie, które nie dociera do maszyny.

Zakupy to moment, w którym zależności stają się zobowiązaniami

Umowy zamieniają zależność w zobowiązanie. Kupujący wybiera dostawcę, komponent, warunki wsparcia, lokalizację danych, okres odnowienia i warunki wyjścia. Decyzję można opisać jako zakup usługi AI, ale kupujący nabywa również proces aktualizacji dostawcy, reagowanie na incydenty, model tożsamości, stabilność interfejsu, dokumentację i zdolność do pozostania na rynku. To nie są cechy drugorzędne. To one decydują o tym, ile władzy zachowuje kupujący.

Dokument grupy doradczej ENISA z 2025 r. dotyczący wdrażania NIS2 jest pod tym względem niezwykle bezpośredni. Zauważono w nim, że mniejsze firmy mogą zostać objęte obowiązkami wynikającymi z NIS2, ponieważ dostarczają produkty podmiotom, które wchodzą w zakres tych przepisów. Dokument opowiada się za europejskimi ramami bezpieczeństwa łańcucha dostaw i zamówień z podstawowym zestawem środków oraz wspólną metodą należytej staranności. Wzywa również do stworzenia podstawy zamówień obejmującej minimalne wymagania umowne, standardowe klauzule, metody testowania bezpieczeństwa i prosty sposób oceny dostawców przez klienta. Dokument jest opinią doradczą, a nie rozporządzeniem. Jego wartość polega na tym, że wskazuje operacyjne tarcia powstające, gdy każdy kupujący wymyśla własną wersję należytej staranności.

Zespoły zakupowe nie muszą wymagać od każdego dostawcy ujawniania wszystkich wewnętrznych szczegółów. Muszą jednak zadawać pytania, które mają związek z konsekwencjami. Które komponenty są niezbędne dla usługi? Jak komunikowane są zmiany? Jak kupujący może zweryfikować używane oprogramowanie i oprogramowanie układowe? Co się stanie, jeśli dostawca lub poddostawca nie będzie w stanie dostarczyć komponentu? Które dane i dowody można wyeksportować? Jak długo trwa wsparcie po wycofaniu wersji? Kto może wstrzymać operację i co dzieje się z pracą już w toku?

Te pytania są mniej efektowne niż pokaz działania. Trudniej też je sfałszować. Dostawca może w dziesięć minut zaprezentować płynną odpowiedź. Znacznie trudniej pokazać pełny inwentarz zależności, przetestowane przywracanie, ścieżkę migracji oraz osobę upoważnioną do odmowy we właściwym momencie. Kupujący nie powinien traktować tej trudności jako powodu do unikania pytań. To właśnie powód, aby je zadać, zanim usługa stanie się trudna do zastąpienia.

Ryzyko koncentracji wymaga starannego języka. Powszechnie używany dostawca nie jest automatycznie niebezpieczny, a mały dostawca nie jest automatycznie odporny. Koncentracja staje się ryzykiem, gdy jeden dostawca, repozytorium oprogramowania, trasa geograficzna, organ tożsamości lub zespół utrzymaniowy niesie więcej konsekwencji, niż organizacja jest w stanie pochłonąć. Raport prognostyczny ENISA opisuje transgranicznych dostawców usług ICT jako potencjalny pojedynczy punkt awarii. Właściwa reakcja nie polega na udawaniu, że koncentrację można wyeliminować. Chodzi o zidentyfikowanie, gdzie występuje, ustalenie akceptowalnej zależności i przećwiczenie, co się stanie, gdy trasa będzie niedostępna.

Klauzule wyjścia są często pisane jako prawnicze ozdobniki. Prawdziwa klauzula wyjścia ma kształt techniczny. Wymienia formaty, interfejsy, prawa do pobierania danych, klucze, logi, dowody, wsparcie w trakcie przejścia, potwierdzenie usunięcia oraz minimalne informacje potrzebne do odbudowania usługi gdzie indziej. Jest silniejsza, gdy została przetestowana na niewielkim obciążeniu. Test nie musi być teatralny. Kontrolowany eksport, przywrócenie w niezależnym środowisku i porównanie wynikowego zachowania mogą ujawnić więcej niż kilka stron zapewnień.

Infrastruktura krytyczna to sieć zależności

Dyrektywa w sprawie odporności podmiotów krytycznych podejmuje podobny krok na poziomie usług kluczowych. Definiuje odporność jako zdolność podmiotu do zapobiegania, ochrony przed, reagowania na, opierania się, łagodzenia, absorbowania, przystosowywania się do incydentu oraz odzyskiwania sprawności po nim. Opisuje infrastrukturę krytyczną jako zasób, obiekt, sprzęt, sieć lub system niezbędny dla usługi kluczowej. Sformułowanie jest celowo szersze niż budynek. Traktuje usługę jako relację między zasobami, ludźmi i funkcjami.

Dyrektywa stanowi, że państwa członkowskie powinny uwzględniać ryzyka międzysektorowe i transgraniczne, oraz wskazuje na rosnące współzależności między infrastrukturą a sektorami. Mówi również, że skutki dla łańcucha dostaw należy uwzględniać przy ocenie znaczenia incydentu zakłócającego. Ma to znaczenie dla infrastruktury AI, ponieważ istotna usługa może wcale nie być oznaczona jako sztuczna inteligencja. Łącze danych, system zasilania, usługa tożsamości, system dokumentacji szpitalnej czy sieć badawcza mogą być warstwą, która umożliwia działanie usługi opartej na AI.

Dyrektywa nie jest podręcznikiem operacji AI. Nie klasyfikuje każdej usługi modelowej jako krytycznej i nie zastępuje przepisów sektorowych. Dostarcza sposobu myślenia o konsekwencjach. Jeśli system wspiera usługę kluczową, pytanie nie brzmi tylko, czy model przeszedł ocenę. Chodzi o to, czy podmiot może nadal świadczyć usługę kluczową, gdy zmieni się komponent, obiekt, dostawca, sieć lub warunki zewnętrzne.

NIS2 uzupełnia ten fizyczny i organizacyjny obraz o obowiązki w zakresie zarządzania ryzykiem cyberbezpieczeństwa i zgłaszania incydentów dla odpowiednich podmiotów. Wzajemne oddziaływanie prawne jest szczegółowe i zależy od podmiotu oraz sektora. Ogólna lekcja nie jest taka, że pojedyncza dyrektywa rozwiązuje kwestię odporności. Chodzi o to, że zależności cybernetyczne i fizyczne muszą być skoordynowane. Sieć może być bezpieczna przed jednym rodzajem ataku, a mimo to zawieść, gdy brakuje chłodzenia. Obiekt może mieć redundantne zasilanie, a mimo to nie być w stanie uwierzytelnić operatorów. Dostawca może zgłosić incydent oprogramowania, podczas gdy kupujący nie ma zapisów potrzebnych do zrozumienia jego skutku.

Odporność wymaga więc słownictwa dla usługi zdegradowanej, a nie tylko całkowitej awarii. Czy system może przyjąć mniej żądań? Czy może wyłączyć funkcję wysokiego ryzyka, zachowując tę o niskim ryzyku? Czy może przełączyć się na mniejszy model lub ścieżkę ręczną? Czy może działać dalej, gdy kolejka jest opróżniana, a źródło weryfikowane? Czy może udowodnić, które prace zostały opóźnione lub przetworzone ponownie? To decyzje operacyjne. Decydują też o tym, czy obywatele, badacze i przedsiębiorcy doświadczą kontrolowanego ograniczenia, czy tajemniczej odpowiedzi, która pojawia się po tym, jak instytucja utraciła kontekst niezbędny do jej oceny.

Najbardziej użyteczny obraz to sieć, w której węzły mają właścicieli, a krawędzie warunki. Krawędzią może być połączenie energetyczne, zależność programowa, umowa, transfer danych lub relacja władzy. Odporny projekt nie zakłada, że każda krawędź pozostanie dostępna. Rejestruje krawędź, monitoruje istotny warunek i definiuje reakcję, zanim nadejdzie presja.

Ilustracyjna kompozycja, nie raport o incydencie

Warto skonkretyzować problem zależności bez wymyślania prawdziwej awarii. Poniższy opis to ilustracyjna kompozycja. Nie wymienia żadnej nazwanej organizacji, dostawcy, obiektu, osoby, daty ani zdarzenia. To eksperyment myślowy złożony ze zwykłych relacji infrastrukturalnych.

Wyobraźmy sobie publiczną usługę badawczą, która pozwala upoważnionym zespołom przesłać dokument, uruchomić przepływ klasyfikacji i otrzymać wynik do przeglądu przez człowieka. Usługa jest hostowana na infrastrukturze europejskiej. Jej model jest przechowywany w rejestrze artefaktów. Dokumenty źródłowe znajdują się w jednej warstwie przechowywania, a indeks w innej. Brama sprawdza tożsamość i przekazuje prace do kolejki. Pracownicy korzystają z obrazu kontenera i sterownika sprzętowego. Wyniki są zapisywane w magazynie rekordów i strumieniu dowodów. Pulpit nawigacyjny informuje zespół operacyjny, czy system jest zdrowy.

Nic tu nie jest niezwykłe. O to właśnie chodzi. Teraz zmieńmy jeden warunek na raz. Rejestr zmienia politykę podpisywania. Aktualizacja sterownika wymaga nowego środowiska uruchomieniowego kontenera. Certyfikat wygasa dla usługi zapisującej dowody, podczas gdy magazyn wyników nadal przyjmuje zapisy. Limit przechowywania zostaje osiągnięty dla indeksu pochodnego, ale nie dla dokumentów źródłowych. Dostawca zmienia interfejs, a konsument kolejki ponawia operację, która nie została zaprojektowana do powtarzania. Doświadczony operator odchodzi, a podręcznik operacyjny nadal opisuje poprzednie wdrożenie. Żadna z tych zmian nie wymaga, aby model wygenerował fałszywe zdanie. Każda z nich może zmienić niezawodność usługi lub jej zdolność do wyjaśnienia siebie.

Organizacja, która obserwuje wyłącznie dokładność modelu, może nie zobaczyć żadnego ostrzeżenia. Zestaw testowy nadal przechodzi. Organizacja, która obserwuje całą usługę, zobaczy inne sygnały: błąd weryfikacji, rosnącą liczbę ponowień, lukę w strumieniu dowodów, przekroczenie progu przechowywania, nieprzejrzaną zmianę lub alarm o własności. Sygnały te nie są równoważne i nie wszystkie wymagają awarii. Wymagają reguły określającej, kto decyduje o tym, co dzieje się dalej.

Zespół może zdecydować się na ograniczenie wydajności podczas sprawdzania zależności. To nie oznacza, że usługa nie spełnia swojego celu. Może to oznaczać, że usługa ma cel szerszy niż przepustowość. Jeśli system potrafi zachować rekord źródłowy, oznaczyć opóźnione prace, zapobiec nieautoryzowanym ponowieniom i zapewnić człowiekowi jasną ścieżkę do sprawdzenia dotkniętych przypadków, uległ degradacji w sposób kontrolowany. Jeśli nadal produkuje dopracowane odpowiedzi, podczas gdy jego ścieżka dowodów jest zerwana, zachował pozory działania kosztem zaufania.

The composite is deliberately ordinary because spectacular incidents make the lesson too easy. Everyone understands that a flood can interrupt a facility. The harder work is recognising that an expired certificate, an unowned registry, a changed supplier contract or a missing recovery test can also move a service outside its safe operating boundary. Boring dependencies are not less causal because they lack a dramatic photograph.

Failure propagates through relationships

A failure-propagation map should follow relationships rather than technology labels. Start with the service promise. What does the user expect to happen, and what must remain true for that expectation to be met? Then trace backwards through the model, runtime, policy gate, identity, network, storage, hardware, energy, supplier and institution. At each step, ask what failure looks like, how it is detected, who owns the response and what evidence remains.

This sounds linear, but real systems branch. A model can be available while a policy service is unavailable. A policy can permit a call while an identity record is stale. A request can be accepted while a queue is unable to drain. A result can be returned while the record needed to contest it is missing. An infrastructure team can restore the service while a data owner still has to decide whether the affected work can be trusted. The propagation map should show these branches because a single green status light cannot.

One useful way to draw the map is to separate four kinds of consequence. Availability asks whether the work can happen. Integrity asks whether the work and its records are unchanged and complete. Authority asks whether the actor was allowed to perform the work. Recoverability asks whether the service can return to a known state and explain what occurred. A dependency may be acceptable for one dimension and unacceptable for another. A cache can improve availability while being unsuitable as the authoritative record. A third-party identity service can be convenient while making authority hard to inspect during a disruption.

The map should also show time. Some dependencies fail immediately. Others drift. A model can remain available while its supporting data grows stale. A hardware component can work while replacement stock becomes impossible to obtain. A contract can remain valid while a provider's change policy slowly removes the interface the buyer relied on. The later a signal arrives, the more expensive it is to interpret. Time is part of the dependency, not a note in the incident report.

Operations teams often call this observability. That word is useful only when it points to an action. A graph that looks healthy does not tell anyone what authority they have, which change caused the graph to move or what evidence should be preserved. The point of a failure map is to make a decision possible. If the evidence stream is incomplete, pause the affected action. If the model registry cannot verify an artefact, do not promote it. If a supplier changes a component outside the tested boundary, repeat the relevant evaluation. If a recovery test cannot restore the record, do not call the backup a recovery plan.

There is no universal threshold for these decisions. A research experiment, a public-facing service and a safety-critical workflow have different tolerances. The important thing is that the threshold belongs to the service owner, is visible to operators and can be revised when evidence changes. Otherwise the threshold will be set by the first person who notices the failure, which is a remarkably democratic way to run a system and a poor way to govern one.

Zależność nie musi zniszczyć modelu, aby zmienić to, co usługa może bezpiecznie twierdzić.

Mierz możliwości, nie ukrywając mianownika

Infrastruktura zachęca do imponujących liczb. Eksaflopsy, petabajty, liczba procesorów, sumy inwestycji i liczba obiektów w programie opisują coś realnego. Żadna z nich sama w sobie nie jest usługą. Liczba staje się użyteczna, gdy jej mianownik i warunki są widoczne.

Szczytowa wydajność obliczeniowa nie mówi badaczowi, jak szybko konkretne obciążenie uzyska partycję, przeniesie swoje dane, ukończy uruchomienie lub pobierze wynik. Liczba AI Factories nie mówi małej firmie, czy jej aplikacja otrzyma dostęp na warunkach, których potrzebuje. Suma inwestycji w półprzewodniki nie mówi operatorowi, który komponent będzie dostępny podczas niedoboru. Wysoki procent dostępności nie mówi instytucji publicznej, czy może pobrać dowody w spornej decyzji.

Odpowiedzialny opis możliwości łączy zatem nagłówek ze ścieżką za nim. Podaj granicę sprzętu i oprogramowania. Określ, czy wartość jest szczytowa, ciągła, planowana czy obserwowana. Opisz obciążenie, model dostępu i wyłączenia. Powiedz, które zależności są poza pomiarem. Trzymaj twierdzenie związane z wydaniem, sprzętem, zbiorem danych i polityką, w ramach których zostało sformułowane. Celem nie jest uczynienie każdej strony nieczytelną. Chodzi o to, aby ważne strony można było sprawdzić.

Ta dyscyplina poprawia również publiczną argumentację. Europa nie musi wybierać między ambicją a ostrożnością. Może budować duże obiekty, finansować ambitne badania i nadal mówić, gdzie kończą się dowody. System publiczny, który nazywa swoje ograniczenia, jest bardziej wiarygodny niż ten, który przedstawia czystą liczbę bez możliwości jej sprawdzenia. Ograniczeniem może być kolejka, interfejs, dostawca, luka kompetencyjna, limit mocy lub granica prawna. Nazwanie go nie pomniejsza możliwości. Mówi ludziom, jakiego rodzaju jest to możliwość.

Niepewność nie jest przyznaniem się do porażki. To sygnał do konserwacji. Jeśli nikt nie wie, jak zmiana dostawcy wpłynie na obciążenie, następnym krokiem jest test lub jawne założenie, a nie większy przymiotnik. Jeśli rejestr nie może odróżnić wydania modelu od konfiguracji serwowania, następnym krokiem jest lepszy zapis. Jeśli instytucja nie może określić, która osoba może zatrzymać operację, następnym krokiem jest mapa autorytetów. Precyzja to sposób na podjęcie decyzji, co naprawić.

Ciche warstwy to miejsce, gdzie suwerenność staje się praktyczna

Europejska suwerenność bywa czasem omawiana tak, jakby była flagą umieszczoną na szczycie centrum danych. Usługa może znajdować się wewnątrz Unii, a mimo to zależeć od zewnętrznych komponentów, obcego zasięgu prawnego, zastrzeżonych interfejsów, deficytu kompetencji czy dostawcy, którego decyzji o zmianach nie można zakwestionować. Lokalizacja to jeden z elementów oceny suwerenności. Praktyczna kontrola zależy od całego łańcucha.

Ustawa o chipach, która koncentruje się na zrozumieniu globalnego łańcucha dostaw półprzewodników, dyrektywa CER zwracająca uwagę na zależności międzysektorowe oraz ostrzeżenia ENISA dotyczące zależności programowych i pojedynczych punktów awarii wskazują w tym samym kierunku. Suwerenność nie jest pojedynczym przełącznikiem. To zdolność do zrozumienia, od czego zależy usługa, do zdecydowania, która zależność jest akceptowalna, do zastąpienia jej lub ograniczenia, gdy to konieczne, oraz do zachowania wystarczających dowodów, by obronić tę decyzję.

Tę zdolność można budować w drobny sposób. Publiczna grupa badawcza może prowadzić inwentaryzację środowiska uruchomieniowego, sterowników i wersji danych wykorzystanych do uzyskania wyniku. Zespół ds. zamówień może wymagać przetestowanej ścieżki eksportu zamiast obietnicy przenośności. Zespół operacyjny może zdefiniować tryb ograniczonej funkcjonalności i przećwiczyć go. Regulator może zapytać, jakie rekordy będą dostępne po zmianie dostawcy. Dostawca może opublikować granice swojego wsparcia oraz warunki, w jakich aktualizacja zmienia zachowanie. Żadne z tych działań nie czyni systemu autonomicznym. Czynią go mniej tajemniczym.

W Dweve to właśnie jest wąski powód, dla którego zależy nam na otwartych fundamentach i cichych elementach wokół nich. Projekty takie jak Core i Mesh są użyteczne tylko wtedy, gdy znajdują się w uczciwych granicach operacyjnych, z jasnymi rekordami, uprawnieniami i ograniczeniami. Nie zastępują europejskiej infrastruktury, instytucji publicznych ani polityki łańcucha dostaw, a ten artykuł nie twierdzi, że rozwiązują te problemy. Stanowisko jest skromniejsze: otwarty komponent łatwiej jest zbadać, zastąpić i nauczyć się go, gdy jego kontrakty są jawne. To jedna cegła, nie cały budynek.

Budynek ma znaczenie, ponieważ ludzie spotykają się na najwyższym piętrze, a żyją z fundamentami. Odpowiedź na ekranie może być płynna, ale prawdziwy charakter usługi określają warstwy, które decydują o tym, skąd pochodzi odpowiedź, kto mógł ją zmienić, co się dzieje, gdy zależność się przesuwa, i czy ktokolwiek będzie mógł później wyjaśnić wynik.

Buduj system, który ludzie wciąż mogą zobaczyć

Najważniejszy system AI może być tym, którego nikt nie widzi, ponieważ jest rozproszony w miejscach, których nigdy nie nazwano AI. To zakład produkcyjny chipów i pętla chłodzenia. To superkomputer i harmonogram zadań. To rejestr pakietów, dostawca tożsamości, polityka przechowywania, trasa sieciowa i harmonogram konserwacji. To umowa, która określa, co się dzieje, gdy dostawca zmienia komponent. To instytucja, która może wstrzymać przepływ pracy, zanim słaby sygnał stanie się publiczną porażką.

Żadne z tych rzeczy nie umniejsza znaczenia jakości modelu. Daje jakości modelu miejsce, w którym może mieć znaczenie. Model może służyć człowiekowi tylko poprzez system, który potrafi przyjąć dane wejściowe, wykonać pracę, zachować odpowiedni rekord i zwrócić wynik z wystarczającym kontekstem, by ktoś mógł mu zaufać lub go zakwestionować. Model jest ważnym komponentem tego systemu. Nie jest krajem, łańcuchem dostaw, planem odzyskiwania ani osobą z uprawnieniami do naprawy części, których nie widzi.

Europejskie programy infrastrukturalne to okazja, by uczynić te zależności widocznymi, podczas gdy budowane są moce. Okazja ma charakter praktyczny. Publikuj interfejsy i granice operacyjne. Finansuj utrzymanie i kompetencje wraz ze sprzętem. Traktuj zamówienia jako decyzję projektową. Łącz cyberbezpieczeństwo z odpornością fizyczną. Daj mniejszym organizacjom ścieżkę do korzystania z publicznej infrastruktury bez zmuszania ich do stania się specjalistami w każdej warstwie. Mierz dostęp, odzyskiwanie i dowody tak starannie, jak szczytową wydajność.

Istnieje pewna europejska przyjemność w odkryciu, że odpowiedzią na wielkie pytanie technologiczne jest inwentarz, instrukcja obsługi i osoba, która ma prawo zatrzymać maszynę. To nic efektownego, ale ma tę zaletę, że przetrwa kontakt z wtorkiem. Gdy ukryty system jest na tyle widoczny, że można go zbadać, model może wykonywać swoją pracę bez dźwigania mitu, do którego niesienia nigdy nie został zbudowany.

Źródła