A legfontosabb AI-rendszer lehet, hogy az, amelyet senki sem lát

A modell csak a látható réteg. Európa valódi AI-képessége a mögötte álló chipeken, számítási kapacitáson, hálózatokon, adatokon, szerződéseken és embereken...

A legfontosabb AI-rendszer lehet, hogy az, amelyet senki sem lát

A gép a válasz mögött

Európa első exaszkálás szuperszámítógépe nem metafora. A JUPITER valódi rendszer a Forschungszentrum Jülichben, amelyet a Jülich Supercomputing Centre üzemeltet. Az EuroHPC Közös Vállalkozás leírja a közvetlen folyadékhűtéses BullSequana architektúrát, egy 20 petabájtos ultragyors flash-partíciót, valamint egy olyan kialakítást, amelyet igényes szimulációkra és számításigényes mesterséges intelligenciára terveztek. A leírás tele van azokkal a részletekkel, amelyek lehetővé teszik egy rendszer működését: processzorarchitektúra, tárolási szint, hűtési módszer, üzemeltető intézmény és hozzáférési út. A modell, amely esetleg majd a tetején fut, csak egy része a mondatnak.

Ezt a különbségtételt könnyű elfelejteni, mert az MI látható része egy válasz. Az ember feltesz egy kérdést, a modell szöveget ad vissza, és a képernyő azt a benyomást kelti, hogy az intelligencia egyetlen csomagban érkezett meg. A rejtett munka kevésbé filmszerű. Az áramnak el kell jutnia az épületbe. Az alkatrészeknek megfelelő állapotban kell megérkezniük. A firmware-képnek megbízhatónak kell lennie. A hálózatoknak adatot kell szállítaniuk a processzorok és a tárolók között. Az identitásnak meg kell határoznia, hogy melyik személy vagy szolgáltatás melyik erőforrást használhatja. Az ütemezőnek kapacitást kell találnia. A nyilvántartásnak meg kell mondania az üzemeltetőnek, hogy melyik modell, konténer és adatkiadás van használatban. A felügyeletnek észre kell vennie, hogy a rendszer megváltozott. Valakinek még mindig tudnia kell, hogyan javítsa meg egy esős kedden, amikor a gyártói dokumentáció új verziószámot kapott, és az egyetlen ember, aki értette a régit, szabadságon van.

A fontos MI-rendszer ezért lehet az, amelyet senki sem lát. Ez az ellátási lánc, az áramszerződés, a hálózati szövet, a karbantartási terv, a szoftverfüggőségi fa, a beszerzési döntés és az intézményi emlékezet, amely lehetővé teszi egy modell használatát anélkül, hogy úgy tennénk, mintha a modell lenne a teljes szolgáltatás. Ha ez a rejtett rendszer gyenge, egy képzettebb modell nem teszi erősebbé a szolgáltatást. Csak látványosabb módot ad a gyenge rendszernek a kudarcra.

Ez nem érv a modellek vagy a nagy nyilvános számítástechnikai programok ellen. Ez érv amellett, hogy őszintén írjuk le őket. Európa kapacitást épít a Chips Act, az EuroHPC és az AI Factories program révén. A Bizottság szakpolitikai oldalai stratégiai függőségekről, az ellátási lánc ellenálló képességéről, a kisebb vállalkozások hozzáféréséről és a megbízható MI-hez szükséges infrastruktúráról beszélnek. Ezek infrastrukturális kérdések, nem márkaépítési kérdések. Ha a kontinens hasznos képességet akar, nem pedig lenyűgöző bemutatók gyűjteményét, akkor a csendes rétegeket a képesség részének kell tekintenie.

A válasz a legfelső réteg. A szolgáltatás minden alatta lévő rétegtől függ.

A modell alkotóelem, nem ország

Public discussion often uses a model as a shorthand for an entire capability. A country has a model, a company has a model, a department has a model, and the model is treated as if it carried its own supply chain. It does not. A model has a file, parameters, a runtime and a set of assumptions about the work it is expected to do. The service around it carries the rest of the obligations.

Consider a modest system that classifies incoming documents before a human team reviews them. It needs an intake channel, a queue, a parser, storage, access control, a model runtime, a result store, a notification path, a way to roll back a release and a record of what happened. The classifier can be accurate on its test set and still be unusable if the parser drops a field, if the identity system grants the wrong role, if the model container cannot be retrieved, or if the operator cannot tell which version made a recommendation. None of these failures are model hallucinations. They are failures in the service that made the model consequential.

The opposite error is just as common. Teams describe an entire service as resilient because the model has been evaluated, while leaving the dependencies outside the evaluation boundary. A model test may check outputs for a selected workload. It rarely checks whether a certificate expires at the same time as a software repository changes its signing key, whether a storage tier has enough capacity for a longer-than-usual document, or whether a person can retrieve the source record after a supplier changes an application programming interface. Those concerns belong to the operational system. They are still part of what a user experiences as AI.

The useful question is not whether a model is good in isolation. It is which other things must be true before the model's output can be relied on, and who has the authority to repair those things. That question moves the conversation from a model catalogue to a system boundary. It also creates a less flattering but more useful inventory.

  • What physical resources must remain available?
  • Which software and firmware components must arrive intact and remain supported?
  • Which identity, network, storage and registry services must answer?
  • Which organisation is responsible when the dependency changes?
  • What evidence lets another person check the answer later?
  • Proposal for the Chips Act 2.0, European Commission, June 3, 2026.

These questions are not theoretical. They are the difference between a capability that can be operated and a capability that can be demonstrated once. Demonstrations are pleasant. Essential services have to survive the next maintenance window.

Supply chains are inside the system boundary

ENISA's work on supply-chain integrity begins with an unglamorous observation: governments, organisations, companies and consumers increasingly depend on ICT products and services, and therefore on the supply chains that deliver them. Its report names threats that range from tampering during development, distribution or operation to substitution with counterfeit or cloned components. The point is broader than a security checklist. The thing being supplied is not only a box. It is a sequence of people, code, components, contracts and decisions through which the box becomes trusted enough to use.

An AI service inherits that sequence. A training run depends on a base image, a compiler, a driver, a kernel, a scheduler and a source dataset. An inference service depends on the same layers plus a serving runtime, an index, a policy gate and an interface that can keep working when traffic is not shaped like the test set. A public institution may buy a service rather than any of those parts, but the hidden chain does not disappear because the contract calls it a platform.

Az ENISA 2024-es előretekintő frissítése a szoftverellátási lánc kompromittálódását helyezi a 2030-ra várható kiberbiztonsági fenyegetések listájának élére. Emellett a vezető aggodalmak közé sorolja a szakemberhiányt, az emberi hibákat a kiberfizikai ökoszisztémákban, a határokon átnyúló infokommunikációs szolgáltatókat mint egyetlen meghibásodási pontot, valamint a környezeti zavarok fizikai hatását a kritikus digitális infrastruktúrára. Ezek nem azt állítják, hogy minden mesterségesintelligencia-projekt mindegyikkel szembesül majd. Inkább arra emlékeztetnek, hogy a fenyegetési felület kapcsolatokból épül fel. Egy javítás, egy beszállító, egy ember és egy árvíz mind ugyanazt a szolgáltatást érintheti, még akkor is, ha különböző kockázati nyilvántartásokban szerepelnek.

Ugyanezen jelentés nyelvezete azért hasznos, mert ellenáll annak a téveszmének, hogy a kiberkockázat kizárólag a biztonsági csapatra tartozik. Egy függőség szoftveresen kompromittálódhat, de a következményei fizikai folyamaton, beszerzési döntésen vagy hiányzó szakértelemen keresztül érkezhetnek meg. Egy szolgáltatás azért válhat egyetlen meghibásodási ponttá, mert a szolgáltatója technikailag kiváló és széles körben használt. A koncentráció nem azonos az alkalmatlansággal. Ez a szolgáltatás körüli hálózat tulajdonsága.

Ez gyakorlati határproblémát teremt. Ha egy szervezet csak a modellt és annak közvetlen futási környezetét értékeli, az eredmény pontos lehet az általa választott határra, de félrevezető az általa üzemeltetett szolgáltatásra nézve. Ha minden beszállítót azonos intenzitással értékel, olyan táblázatot készít, amelyet senki sem tud karbantartani. A megoldás egy olyan függőségi térkép, amely a következményeket követi. Határozza meg, mi változtathat meg egy kimenetet, szakíthat meg egy szolgáltatást, törölhet bizonyítékot, bővítheti a jogosultságokat vagy akadályozhatja a helyreállítást. Ezután kérdezze meg, hogy a függőség elég látható-e a megfigyeléshez, és létezik-e másik útvonal.

Ennek a térképnek tartalmaznia kell a hétköznapi anyagokat is. Egy szerverhez memória, tárolóeszközök, áramátalakítás, hűtőberendezések és pótalkatrészek szükségesek. Egy hálózathoz optikai alkatrészek, kapcsolók, útválasztó szoftver és olyan emberek kellenek, akik ismerik a topológiát. Egy szoftverellátási lánchoz karbantartók, build-infrastruktúra, csomagregiszterek, aláírókulcsok és kiadási eljárások szükségesek. Egyik sem válik kevésbé fontossá attól, hogy a termékismertető mesterséges intelligenciát említ.

Csábító lehet egy nagyobb beszállítói kérdőívvel válaszolni. A kérdőív hasznos lehet, de nem függőségi térkép. Azt rögzíti, amit a beszállító egy adott pillanatban állít. A működési kérdés az, hogy a vevő észre tudja-e venni a változást, értelmezni tudja-e, és arányos intézkedést tud-e tenni. A tanúsítványok listája nem helyettesíti annak ismeretét, hogy melyik összetevő állítaná le a szolgáltatást, ha holnap reggel eltűnne. Az európai szervezetek elismerésre méltóan jók a dokumentumok gyűjtésében. A nehezebb feladat az, hogy a dokumentumok döntésre mutassanak.

A chipek fizikailag láthatóvá teszik a láthatatlant

Az európai chiptörvény olyan tényt állapít meg, amely nyilvánvalónak tűnhet, mégis ki kell mondani: a félvezetők az elektronikai termékek építőkövei, és központi szerepet játszanak az olyan ágazatokban, mint a kommunikáció és az adatfeldolgozás, az egészségügy, az energia, a közlekedés és az ipari automatizálás. A rendelet 2023 szeptemberében lépett hatályba, és olyan célokat tűz ki, mint a kutatás és a technológiai vezető szerep erősítése, a tervezési, gyártási és csomagolási kapacitás megerősítése, a szakemberhiány kezelése, valamint a globális félvezetőellátási lánc mélyebb megértésének kialakítása.

Ez a lista azért fontos a mesterséges intelligencia szempontjából, mert a számítási kapacitást nem egy felhőlogó hozza létre. Hanem tervek, ostyák, berendezések, csomagolás, tesztelés, áramellátás, hűtés, hálózatépítés és karbantartás láncolata. Az egyik rész hiánya vagy késése megváltoztathatja azt, amit egy adatközpont képes nyújtani, még akkor is, ha a modellfájlok készen állnak. Ha egy összetevőnek hosszú az átfutási ideje, az üzemeltető nem tudja okos prompttal megoldani a problémát. Ha egy firmware-függőség nem frissíthető biztonságosan, a választás a szolgáltatás ellenőrzött csökkentése és a minden működésben tartásának kockázatos kísérlete között lehet.

A Bizottság áttekintése a Chips Act három pillérét ismerteti. Az első a kapacitásépítést és az innovációt támogatja, beleértve a kísérleti gyártósorokat és a kompetenciaközpontokat. A második az ellátás biztonságával és rezilienciájával foglalkozik a gyártás, a fejlett csomagolás, a tesztelés és az összeszerelés révén. A harmadik monitoring- és válságkezelési mechanizmusokat hoz létre, köztük egy Európai Félvezető Testületet, amely feltérképezi és nyomon követi az értékláncot, valamint összehangolja a félvezető-válságokra adott válaszokat. Az intézményi felépítés hasznos kiigazítása annak a gondolatnak, hogy a szuverenitás azt jelenti, hogy minden alkatrészt hazai gyártásban állítunk elő. A reziliencia részben kapacitásról, részben átláthatóságról, részben pedig arról szól, hogy képesek vagyunk reagálni, amikor egy függőség áthelyeződik.

Az oldal konkrét példákat is hoz jóváhagyott, első ilyen jellegű létesítményekre Cataniában, Crolles-ban, Drezdában, Novarában, Premstättenben, Milánóban és más európai helyszíneken. Ezek a tételek nem bizonyíték arra, hogy Európa megoldotta a félvezető-problémát. Azt bizonyítják, hogy az értékláncnak vannak megnevezhető fizikai helyszínei, technológiái és beruházási döntései. A megnevezés megváltoztatja a diskurzust. Lehetővé teszi, hogy valaki megkérdezze, milyen képességet ad hozzá az egyes létesítmények, milyen inputokra támaszkodnak még, milyen készségekre van szükségük, és hogyan kapnának támogatást egy zavar idején.

A Bizottság Chips Act 2.0-ra vonatkozó javaslata, amelyet 2026 júniusában tettek közzé, kimondja, hogy az Unió kulcsfontosságú területeken, például a fejlett chipgyártás és a félvezető-tervezés terén továbbra is harmadik országoktól függ. Egy július 31-i cikkhez képest ez aktuális szakpolitikai nyilatkozat, nem pedig egy jövőbeli jogszabályra vonatkozó előrejelzés. Gyakorlati következménye egyértelmű: egy európai szolgáltatás működhet Európában, és mégis függhet egy globális lánctól, amelynek legfontosabb döntései máshol születnek. A fizikai elhelyezkedés értékes. Nem ugyanaz, mint az ellenőrzés.

Az MI-szakpolitika komolyabbá válhat, ha átveszi ezt a fizikai szókincset. Ahelyett, hogy azt kérdeznénk, európai-e egy modell, inkább azt kérdezzük, hogy a szolgáltatás mely részei javíthatók, cserélhetők, ellenőrizhetők és állíthatók le európai intézményeken belül. Ahelyett, hogy azt kérdeznénk, van-e a szolgáltatónak európai régiója, inkább azt kérdezzük, hogyan mozognak a hardver-, firmware- és szoftverfüggőségek, valamint az üzemeltetési jogosultságok a szolgáltatáson belül. A válasz rendezetlen lesz. Ez így van jól. A rendezetlen térképek gyakran az első őszinték.

A számítási kapacitás közszolgáltatás

Az EuroHPC hasznos példa, mert láthatóvá teszi a számítási infrastruktúrát anélkül, hogy fogyasztói termékké alakítaná. A nyilvános listája szerint a közös vállalkozás tizenkét csúcskategóriás szuperszámítógépet szerzett be Európa-szerte. A lista megnevezi a rendszereket és a gazdagépeket: a JUPITER a németországi Jülichben, a LUMI Kajaaniban, a Leonardo Bolognában, a MareNostrum 5 Barcelonában, a Karolina Ostravában és az Arrhenius a Linköpingi Egyetemen, többek között. A helyszínek kevésbé rangsorként fontosak, mint inkább annak emlékeztetőjeként, hogy a számítási kapacitás intézményekbe, épületekbe, munkatársakba, energiaellátó rendszerekbe, tárolókapacitásba és kutatási programokba ágyazódik.

A JUPITER-t Európa első exaskálás szuperszámítógépeként írják le, közvetlen folyadékhűtéses architektúrával, 20 petabájtos flash-partícióval és egy klasztermodullal, amely a SiPearl Rhea1 processzort használ GPU-gyorsítós booster mellett. A LUMI oldala külön CPU-, GPU-, adatelemzési és konténerfelhő-partíciókat ír le, olyan tárolórendszerrel, amely egyesíti a flash-tárolót, a párhuzamos fájlrendszert és az adatkezelési szolgáltatást. Ezek a részletek nem csak mérnököknek szóló apróságok. Azt mondják el a szakpolitikai olvasónak, hogy egy szuperszámítógép különböző alakú erőforrások halmaza. Egy adott munkaterhelés, amely illeszkedik az egyik partícióhoz, nem feltétlenül illeszkedik egy másikhoz. A hozzáférés, az ütemezés és az adatmozgatás a képesség részét képezik.

MareNostrum 5, amelyet a Barcelonai Szuperkomputációs Központ üzemeltet, és az Arrhenius, amelyet a Linköpingi Egyetemen telepítenek és a Svéd Nemzeti Szuperkomputációs Akadémiai Infrastruktúra működtet, ugyanazt a pontot bizonyítja különböző módokon. Egy elosztott európai kapacitás nem egyetlen óriásgép. Hanem rendszerek halmaza, amelyek különböző processzorokkal, tárolási megoldásokkal, üzemeltetőkkel, hozzáférési szabályokkal és tudományos közösségekkel rendelkeznek. A köztük lévő hálózat számít, de a határvonalak is.

Az Európai Bizottság AI Factories politikája egy olyan programot ír le, amely erre a valóságra épül. Az AI Factories az EuroHPC szuperkomputációs kapacitását használja fejlett generatív mesterséges intelligencia fejlesztésére, és összeköti a számítási központokat, egyetemeket, kis- és középvállalkozásokat, ipari szereplőket és pénzügyi intézményeket. Az oldal szerint a 2026. áprilisi frissítés időpontjában tizenkilenc AI Factory és tizenhárom antenna működött, és legalább kilenc új, MI-re optimalizált szuperkomputert terveznek. Emellett hosszú távú, tízmilliárd eurós beruházást ír le az EuroHPC-n keresztül 2021 és 2027 között. Ezek intézményi keretek, nem pedig garancia arra, hogy minden projekt megkapja a kívánt kapacitást, vagy hogy minden modell megbízható lesz.

Az ilyen keretek értéke nem csak a sebességben rejlik. A nyilvános számítási kapacitás olyan teret teremthet, ahol az európai kutatók és vállalatok olyan szabályok és hozzáférési feltételek mellett futtathatnak feladatokat, amelyek láthatóak a közintézmények számára. Támogathat olyan kísérletezést, amelyet egyébként az árak kizárnának, és lehetővé teheti, hogy bizonyos tudás reprodukálható legyen különböző helyszíneken. Ugyanakkor új függőségeket is bevezethet, ha egy program kevés beszállítóra, egyetlen szoftververemre vagy nem pótolható munkaerőre támaszkodik. Egy létesítmény köztulajdona nem szünteti meg az üzemeltetési munkát. Csak nehezebbé teszi a felelősség elrejtését, ami egészségesebb.

Amikor a számítási kapacitás közszolgáltatássá válik, sikerét nem csak a csúcsteljesítmény alapján kell mérni. Hozzáférhet-e egy kisebb kutatócsoport? El lehet-e különíteni egy érzékeny feladatot az általánostól? Be tudja-e mutatni az üzemeltető, hogy milyen szoftvert és hardvert használtak? Át tud-e helyezni egy csapat egy feladatot, ha egy partíció megtelik vagy egy függőség elavul? El tudja-e magyarázni egy közhatóság, hogy milyen feltételek mellett tanítottak egy modellt? Egy gyors gép, amely nem tud válaszolni ezekre a kérdésekre, még hasznos lehet bizonyos tudományos célokra, de még nem teljes alapja a nyilvános MI-nek.

A hálózatok, a tárolás és az azonosítás végzik a csendes munkát

A legfontosabb rétegek gyakran azok, amelyek nem jelennek meg egy MI-diagramon. Egy diagram egy modellt rajzol egy bemenet és egy kimenet közé. Egy üzemeltető hálózati útvonalak, tárolási osztályok, azonosítási állítások, sorok, tanúsítványok, nyilvántartások, titkok, megfigyelhetőségi folyamatok és változáskezelési szabályok láncát látja. A diagram nem hibás. Csak éppen olyan módon hiányos, ami drága meglepetésekhez vezet.

Kezdjük a hálózattal. Egy nagy modellszolgáltatás adatokat mozgathat gyorsítók, memória, tárolás és más szolgáltatások között. Egy nyilvános kutatási feladat adatkészleteket vihet egy szuperkomputerre, és eredményeket küldhet vissza egy egyetemre. Egy éles munkafolyamat átléphet egy szabályzati határt, mielőtt elérne egy modellt, és egy másik határt, mielőtt visszaküldene egy döntést. A késleltetés, a csomagvesztés, az útválasztási változások és a karbantartás megváltoztathatja az egész szolgáltatás viselkedését anélkül, hogy a modellben egyetlen paraméter is változna. Egy időtúllépésből újrapróbálkozás lehet, az újrapróbálkozásból ismételt munka, az ismételt munkából pedig hibás rekord. A modell nem döntött az újrapróbálkozásról. A környező rendszer tette.

Storage has its own hidden grammar. There is the source record, the transformed record, the index, the cache, the log, the backup, the deletion marker and the evidence that says which version was used. A service may be able to answer a question while still being unable to prove which data made the answer possible. Retention and retrieval are not mirror images. Keeping everything forever may violate a purpose limitation; deleting the source while leaving a derivative or a cache may produce a different problem. A serious data boundary names what is stored, for how long, by whom, and how a later reviewer can tell that the boundary was respected.

Identity is not a login screen. It is the mechanism that gives a person, service or agent authority to perform an action. If an inference endpoint can call a tool, the system must know which principal asked, which policy permitted the call, and what the tool was allowed to touch. If a registry allows a container to be promoted, it must know who can approve the promotion and what evidence is required. If a certificate is renewed automatically, the service must still have a way to notice that the identity relationship has changed. A secret that remains valid after the person who requested it leaves is a maintenance issue with a security consequence.

Registries are the memory of a moving system. A model registry may hold versions and metadata. An artefact registry may hold containers, packages or signed releases. A data registry may describe schemas and ownership. A hardware inventory may identify a board, firmware release and replacement status. The point is not to create one registry for everything. The point is to make the authoritative source for each claim explicit. If no system can answer which model, driver, data release and policy version were active, then a later review is forced to infer history from whatever logs survived.

Observability closes the loop. Metrics tell an operator that a queue has grown or a device is hot. Traces show the path taken by a request. Logs carry context, though they remain easy to misunderstand. Events and attestations can preserve decisions and changes. These objects have different jobs. Treating them as interchangeable produces either noise or a false sense of proof. The design question is what a person must know when the service is late, wrong, unavailable or contested, and which record can answer that question without a reconstruction exercise.

One can describe this as boring engineering. That is not an insult. Boring engineering is the part that continues to work after the launch post has moved down the home page. It is also the part that determines whether a new model can be adopted without rewriting the institution around it.

Maintenance is a capability, not an expense line

Infrastructure stories like to end at deployment. That is when the work becomes a service. A model is released, a cluster is commissioned, a factory opens, a contract is signed, and the narrative moves on to the next announcement. The system itself continues through patches, hardware replacement, training, access reviews, upgrades, deprecations, incident response and the gradual disappearance of people who remember why a setting was chosen.

ENISA's threat outlook places skill shortages near the top of its long-term concerns. This is not only a labour-market issue. It is a resilience issue. A service whose dependencies cannot be understood by more than one person has a hidden single point of failure. An organisation may have spare machines and still lack the ability to use them safely because the runbook, build process or data contract lives in one engineer's memory. Buying support can reduce the risk, but the buyer still needs enough understanding to challenge the supplier and decide when to stop.

Maintenance also changes what a performance claim means. A benchmark run on one release says something about that release under the stated conditions. It does not say that the system will have the same behaviour after a driver update, a compiler change, a new scheduler, a different storage path or a new workload. A useful service keeps the conditions of its claims. It records versions, inputs, hardware, policies and changes so that someone can repeat a test or explain why repetition is no longer possible.

There is a human cost to pretending maintenance is a lower-order concern. Operators delay upgrades because the dependency graph is unclear. Security teams struggle to tell which package is actually in production. Procurement renews a contract because nobody has rehearsed an exit. Researchers cannot reproduce a result because the environment has drifted. Users encounter intermittent errors that are blamed on the model because the service has no shared language for the layers underneath it. The result is not a single dramatic failure. It is a slow reduction in confidence.

A maintenance schedule should therefore include more than patch dates. It should include ownership reviews, access expiry, certificate and key rotation, backup restoration tests, dependency review, hardware lifecycle, supplier change notices, model retirement and the evidence needed for each. Some of these tasks can be automated. The responsibility cannot be automated away. Someone must decide what counts as a material change, who receives the signal and which authority can pause the service.

The European instinct to create a committee for a difficult problem is occasionally mocked, often unfairly. A committee that owns a dependency map, a change rule and an escalation path is more useful than a dashboard that belongs to nobody. The problem is not governance. The problem is governance that cannot reach the machine.

Procurement is where dependencies become commitments

Contracts turn a dependency into a commitment. A buyer chooses a supplier, a component, a support arrangement, a data location, a renewal period and an exit condition. The decision may be described as purchasing an AI service, but the buyer is also purchasing the supplier's update process, incident response, identity model, interface stability, documentation and ability to remain in business. Those are not secondary features. They determine how much authority the buyer retains.

ENISA's 2025 advisory group paper on NIS2 implementation is unusually direct about this. It notes that smaller companies may fall into NIS2 compliance work because they supply entities that are in scope. It argues for a European supply-chain security and procurement framework with a baseline of measures and a common due-diligence method. It also calls for a procurement baseline with minimum contract requirements, standard clauses, security testing approaches and a simple way for a customer to assess suppliers. The paper is an advisory opinion, not a regulation. Its value here is that it names the operational friction produced when every buyer invents a different version of diligence.

Procurement teams do not need to demand that every supplier disclose every internal detail. They do need to ask questions that connect to consequence. Which components are essential to the service? How are changes communicated? How can the buyer verify the software and firmware in use? What happens if a supplier or sub-supplier cannot provide a component? Which data and evidence can be exported? How long does support continue after a release is retired? Who can pause an operation, and what happens to work already in flight?

Ezek a kérdések kevésbé látványosak, mint egy bemutató. Ugyanakkor nehezebb is megjátszani őket. Egy szolgáltató tíz perc alatt képes folyékony választ adni. Nehezebb felmutatni egy teljes függőségi leltárt, egy letesztelt visszaállítást, egy migrációs utat és egy olyan személyt, aki jogosult a megfelelő pillanatban nemet mondani. A vevő ne tekintse ezt a nehézséget a kérdések elkerülésére oknak. Ez az ok arra, hogy feltegye őket, mielőtt a szolgáltatás nehezen helyettesíthetővé válik.

A koncentráció kockázata megfontolt megfogalmazást igényel. Egy széles körben használt szolgáltató nem automatikusan veszélytelen, és egy kis szolgáltató sem automatikusan ellenálló. A koncentráció akkor válik kockázattá, amikor egyetlen szolgáltató, szoftver-tárhely, földrajzi útvonal, azonosítási hatóság vagy karbantartó csapat nagyobb következménnyel bír, mint amennyit a szervezet el tud viselni. Az ENISA előretekintő jelentése a határokon átnyúló IKT-szolgáltatókat az egyetlen meghibásodási pont lehetséges forrásaként írja le. A megfelelő válasz nem az, hogy úgy tegyünk, mintha a koncentráció kiküszöbölhető lenne. Hanem az, hogy azonosítsuk, hol létezik, határozzunk meg elfogadható függőséget, és gyakoroljuk be, mi történik, ha az útvonal nem elérhető.

A kilépési záradékokat gyakran jogi berendezési tárgyként írják meg. Egy valódi kilépési záradéknak technikai alakja van. Megnevezi a formátumokat, interfészeket, hozzáférési jogokat, kulcsokat, naplókat, bizonyítékokat, az átállás alatti támogatást, a törlés visszaigazolását és a minimális információt, amely egy szolgáltatás máshol történő újraépítéséhez szükséges. Erősebb, ha kis munkaterhelésen tesztelték. A tesztnek nem kell színpadiasnak lennie. Egy ellenőrzött export, egy független környezetben történő visszaállítás és az ebből adódó viselkedés összehasonlítása többet elárulhat, mint több oldalnyi biztosíték.

A kritikus infrastruktúra a függőségek hálózata

A Kritikus Entitások Ellenálló Képességéről szóló irányelv hasonló lépést tesz az alapvető szolgáltatások szintjén. Az ellenálló képességet egy entitás azon képességeként határozza meg, hogy megelőzze, védje magát, reagáljon, ellenálljon, mérsékelje, elnyelje, alkalmazkodjon egy incidenshez, és felépüljön belőle. A kritikus infrastruktúrát eszközként, létesítményként, berendezésként, hálózatként vagy rendszerként írja le, amely egy alapvető szolgáltatáshoz szükséges. A megfogalmazás szándékosan tágabb, mint egy épület. A szolgáltatást az eszközök, emberek és funkciók közötti kapcsolatként kezeli.

Az irányelv kimondja, hogy a tagállamoknak figyelembe kell venniük az ágazatok közötti és a határokon átnyúló kockázatokat, és rámutat az infrastruktúra és az ágazatok közötti növekvő kölcsönös függőségekre. Azt is kimondja, hogy az ellátási lánc hatásait figyelembe kell venni egy zavaró incidens jelentőségének értékelésekor. Ez azért fontos az AI-infrastruktúra szempontjából, mert az érintett szolgáltatás egyáltalán nem feltétlenül mesterséges intelligenciaként van megjelölve. Egy adatkapcsolat, energiaellátó rendszer, azonosítási szolgáltatás, kórházi nyilvántartó rendszer vagy kutatási hálózat lehet az a réteg, amely lehetővé tesz egy AI-alapú szolgáltatást.

Az irányelv nem AI-üzemeltetési kézikönyv. Nem minősít minden modellszolgáltatást kritikusnak, és nem helyettesíti az ágazatspecifikus szabályokat. Egy módot kínál a következmények átgondolására. Ha egy rendszer alapvető szolgáltatást támogat, a kérdés nem csak az, hogy a modell átment-e egy értékelésen. Hanem az, hogy az entitás képes-e továbbra is biztosítani az alapvető szolgáltatást, amikor egy összetevő, létesítmény, beszállító, hálózat vagy külső körülmény megváltozik.

A NIS2 e fizikai és szervezeti szemlélet mellett kiberbiztonsági kockázatkezelési és incidensbejelentési kötelezettségeket ír elő az érintett entitások számára. A jogi kölcsönhatás konkrét, és az entitástól és az ágazattól függ. Az általános tanulság nem az, hogy egyetlen irányelv megoldja az ellenálló képességet. Hanem az, hogy a kiber- és fizikai függőségeket össze kell hangolni. Egy hálózat biztonságos lehet egyfajta támadás ellen, és mégis meghibásodhat, ha a hűtés nem elérhető. Egy létesítmény rendelkezhet tartalék áramellátással, és mégis képtelen lehet hitelesíteni az üzemeltetőket. Egy szállító bejelenthet egy szoftverincidenst, miközben a vevő nem rendelkezik a hatás megértéséhez szükséges nyilvántartásokkal.

A rugalmasságnak ezért szüksége van egy szókészletre a romlott szolgáltatásra, nem csak a teljes leállásra. Képes-e a rendszer kevesebb kérést fogadni? Képes-e letiltani egy nagy kockázatú funkciót, miközben egy alacsony kockázatút megtart? Képes-e átváltani egy kisebb modellre vagy egy manuális útvonalra? Képes-e tovább működni, amíg egy sor kiürül és egy forrás ellenőrzésre kerül? Képes-e bizonyítani, hogy mely munka késleltetett vagy lett újrafeldolgozva? Ezek működési döntések. Az is eldönti, hogy a polgárok, kutatók és vállalkozások egy ellenőrzött korlátozást tapasztalnak-e, vagy egy rejtélyes választ, amely azután érkezik meg, hogy az intézmény elveszítette a kontextust annak felülvizsgálatához.

A hasznos kép egy hálózat, amelynek csomópontjainak tulajdonosai vannak, és amelynek éleinek feltételei vannak. Egy él lehet áramellátási kapcsolat, szoftverfüggőség, szerződés, adatátvitel vagy felügyeleti kapcsolat. A rugalmas tervezés nem feltételezi, hogy minden él elérhető marad. Rögzíti az élt, figyeli a számító feltételt, és meghatároz egy választ, mielőtt a nyomás megérkezik.

Egy szemléltető összeállítás, nem incidensjelentés

Segít kézzelfoghatóvá tenni a függőségi problémát anélkül, hogy valódi leállást találnánk ki. A következő egy szemléltető összeállítás. Nem ír le nevesített szervezetet, beszállítót, létesítményt, személyt, dátumot vagy eseményt. Ez egy gondolatkísérlet, amelyet hétköznapi infrastrukturális kapcsolatokból állítottak össze.

Képzeljünk el egy nyilvános kutatási szolgáltatást, amely lehetővé teszi jogosult csapatoknak, hogy dokumentumot nyújtsanak be, osztályozási munkafolyamatot futtassanak, és eredményt kapjanak emberi felülvizsgálatra. A szolgáltatás európai infrastruktúrán fut. A modellje egy artefaktumregiszterben van tárolva. A forrásdokumentumok az egyik tárolási szinten élnek, az index pedig egy másikban. Egy átjáró ellenőrzi az azonosságot, és továbbítja a munkát egy sorba. A dolgozók egy konténerképet és egy hardverillesztőt használnak. Az eredményeket egy rekordtárba és egy bizonyítékfolyamba írják. Egy műszerfal megmutatja az üzemeltetési csapatnak, hogy a rendszer egészséges-e.

Itt semmi sem szokatlan. Ez a lényeg. Most változtassunk meg egy feltételt egyszerre. A regiszter megváltoztatja az aláírási szabályzatát. Az illesztőprogram-frissítés új konténerfuttató környezetet igényel. Egy tanúsítvány lejár a bizonyítékot író szolgáltatásnál, miközben az eredménytár továbbra is fogad írásokat. Egy tárolási kvóta elérődik egy származtatott indexnél, de a forrásdokumentumoknál nem. Egy beszállító megváltoztat egy interfészt, és a sor fogyasztója újrapróbál egy olyan műveletet, amelyet nem ismétlésre terveztek. Egy képzett üzemeltető távozik, és a runbook még mindig a korábbi telepítést írja le. Egyik változás sem követeli meg, hogy egy modell hamis mondatot állítson elő. Mindegyik megváltoztathatja a szolgáltatás megbízhatóságát vagy annak képességét, hogy megmagyarázza magát.

Egy szervezet, amely csak a modell pontosságát figyeli, nem lát figyelmeztetést. A tesztkészlet még mindig átmegy. Egy szervezet, amely az egész szolgáltatást figyeli, különböző jeleket lát: ellenőrzési hibát, növekvő újrapróbálási számot, rést a bizonyítékfolyamban, tárolási küszöböt, felül nem vizsgált változást vagy tulajdonosi riasztást. A jelek nem egyenértékűek, és nem mindegyik igényel leállást. Szabályt igényelnek arról, hogy ki dönti el, mi történik ezután.

Tegyük fel, hogy a csapat úgy dönt, hogy csökkenti a kapacitást, miközben ellenőrzi a függőséget. Ez nem annak a jele, hogy a szolgáltatás nem teljesítette a célját. Lehet annak a jele, hogy a szolgáltatásnak nagyobb célja van, mint az átviteli sebesség. Ha a rendszer meg tudja őrizni a forrásrekordot, megjelöli a késleltetett munkát, megakadályozza a jogosulatlan újrapróbálásokat, és egyértelmű utat ad egy embernek az érintett esetek megvizsgálásához, akkor ellenőrzött módon romlott le. Ha továbbra is csiszolt válaszokat állít elő, miközben a bizonyítékútja megszakadt, akkor a szolgáltatás látszatát őrizte meg a bizalom rovására.

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.

Egy függőségnek nem kell tönkretennie a modellt ahhoz, hogy megváltoztassa, mit állíthat biztonsággal a szolgáltatás.

Mérjük a képességet anélkül, hogy elrejtenénk a nevezőt

Az infrastruktúra lenyűgöző számokra csábít. Az exaflopok, a petabájtok, a processzorszámok, a beruházási összegek és a programban szereplő létesítmények száma mind valós dolgot ír le. Egyik sem maga a szolgáltatás. Egy szám akkor válik hasznossá, ha a nevezője és a feltételei láthatók.

A csúcsteljesítmény nem mondja meg egy kutatónak, hogy egy adott feladat milyen gyorsan kap partíciót, mozgatja az adatait, fejezi be a futtatást vagy kéri le az eredményt. Az AI-gyárak száma nem mondja meg egy kisvállalatnak, hogy az alkalmazása hozzáférést kap-e a számára szükséges feltételek mellett. Egy félvezető-beruházási összeg nem mondja meg egy üzemeltetőnek, hogy melyik összetevő lesz elérhető hiány idején. A magas rendelkezésre állási százalék nem mondja meg egy közintézménynek, hogy vissza tudja-e szerezni a vitatott döntés bizonyítékait.

A felelős képességleírás ezért a főcímet a mögötte húzódó úttal párosítja. Nevezze meg a hardver- és szoftverhatárt. Mondja ki, hogy az adat csúcs-, tartós, tervezett vagy megfigyelt érték-e. Írja le a feladatot, a hozzáférési modellt és a kizárásokat. Mondja meg, mely függőségek esnek a mérésen kívül. Tartsa a állítást ahhoz a kiadáshoz, hardverhez, adatkészlethez és szabályzathoz kötve, amely alapján megszületett. A cél nem az, hogy minden oldal olvashatatlan legyen. Az, hogy a fontos oldalak ellenőrizhetők legyenek.

Ez a fegyelem a közbeszédet is javítja. Európának nem kell választania az ambíció és az óvatosság között. Építhet nagy létesítményeket, finanszírozhat ambiciózus kutatást, és közben megmondhatja, hol ér véget a bizonyíték. Egy közrendszer, amely megnevezi a korlátait, hitelesebb, mint amelyik egy tiszta számot mutat anélkül, hogy bármilyen mód lenne annak ellenőrzésére. A korlát lehet egy várakozási sor, egy interfész, egy beszállító, egy készséghiány, egy teljesítménykorlát vagy egy jogi határ. A megnevezése nem teszi kisebbé a képességet. Megmondja az embereknek, hogy milyen képességről van szó.

A bizonytalanság nem a vereség beismerése. Ez egy karbantartási jelzés. Ha senki sem tudja, hogyan befolyásolja egy beszállító változása a feladatot, a következő lépés egy teszt vagy egy kifejezett feltételezés, nem pedig egy nagyobb jelző. Ha egy nyilvántartás nem tud különbséget tenni egy modellkiadás és egy kiszolgálási konfiguráció között, a következő lépés egy jobb feljegyzés. Ha egy intézmény nem tudja megmondani, melyik személy állíthat meg egy műveletet, a következő lépés egy tekintélytérkép. A pontosság egy módja annak, hogy eldöntsük, mit kell megjavítani.

A csendes rétegekben válik a szuverenitás gyakorlativá

Az európai szuverenitásról néha úgy beszélnek, mintha egy adatközpont tetejére kitűzött zászló lenne. Egy szolgáltatás lehet az Unión belül, és mégis függhet külső összetevőktől, külföldi joghatóságtól, zárt felületektől, ritka szaktudástól vagy olyan beszállítótól, akinek a változtatási döntéseit nem lehet megkérdőjelezni. A földrajzi elhelyezkedés csak egy tényező a szuverenitás értékelésében. A gyakorlati ellenőrzés a teljes lánctól függ.

A Chips Act fókusza a globális félvezető-ellátási lánc megértésére, a CER-irányelv figyelme az ágazatok közötti függőségekre, valamint az ENISA figyelmeztetései a szoftverfüggőségekről és az egyetlen hibapontokról mind ugyanabba az irányba mutatnak. A szuverenitás nem egyetlen kapcsoló. Ez annak a képessége, hogy megértsük, mitől függ egy szolgáltatás, eldöntsük, melyik függőség elfogadható, szükség esetén kicseréljük vagy korlátozzuk, és elegendő bizonyítékot őrizzünk meg a döntés védelméhez.

Ez a képesség apró lépésekben is felépíthető. Egy állami kutatócsoport nyilvántarthatja az eredményhez használt futási környezetet, illesztőprogramot és adatkiadást. Egy beszerzési csapat megkövetelhet egy tesztelt exportálási útvonalat a hordozhatóság ígérete helyett. Egy üzemeltetési csapat meghatározhat egy korlátozott működési módot, és begyakorolhatja azt. Egy szabályozó megkérdezheti, hogy mely nyilvántartások állnának rendelkezésre egy beszállítóváltás után. Egy beszállító közzéteheti támogatásának határait és azokat a feltételeket, amelyek mellett egy frissítés megváltoztatja a viselkedést. Egyik intézkedés sem teszi autonómmá a rendszert. Kevésbé rejtélyessé teszik.

A Dweve-nél ez az a szűk ok, amiért törődünk a nyílt alapokkal és a körülöttük lévő csendes elemekkel. Az olyan projektek, mint a Core és a Mesh, csak akkor hasznosak, ha egy őszinte működési határon belül helyezkednek el, egyértelmű nyilvántartásokkal, felhatalmazással és korlátokkal. Nem helyettesítik az európai infrastruktúrát, a közintézményeket vagy az ellátásilánc-politikát, és ez a cikk nem is állítja, hogy megoldják ezeket a problémákat. Az álláspont szerényebb: egy nyílt összetevőt könnyebb ellenőrizni, kicserélni és tanítani, ha a szerződései egyértelműek. Ez egy tégla, nem az egész épület.

Az épület azért számít, mert az emberek a legfelső emelettel találkoznak, de az alapokkal élnek együtt. A képernyőn megjelenő válasz lehet gördülékeny, de a szolgáltatás valódi jellemét azok a rétegek határozzák meg, amelyek eldöntik, honnan származik a válasz, ki módosíthatja, mi történik, ha egy függőség megváltozik, és hogy valaki később meg tudja-e magyarázni az eredményt.

Olyan rendszert építs, amelyet az emberek még látnak

A legfontosabb MI-rendszer lehet, hogy az, amelyet senki sem lát, mert olyan helyeken oszlik el, amelyeket soha nem neveztek MI-nek. Ez a chipgyártó létesítmény és a hűtési kör. Ez a szuperszámítógép és az ütemező. Ez a csomagregiszter, az identitásszolgáltató, a tárolási szabályzat, a hálózati útvonal és a karbantartási beosztás. Ez a szerződés, amely meghatározza, mi történik, ha egy beszállító megváltoztat egy összetevőt. Ez az intézmény, amely szüneteltetheti a munkafolyamatot, mielőtt egy gyenge jel nyilvános kudarccá válna.

Egyik sem csökkenti a modellminőség fontosságát. Helyet ad a modellminőségnek, ahol számít. Egy modell csak olyan rendszeren keresztül szolgálhat ki egy embert, amely fogadni tudja a bemenetet, elvégzi a munkát, megőrzi a releváns nyilvántartást, és visszaadja az eredményt elegendő kontextussal ahhoz, hogy valaki megbízzon benne vagy megkérdőjelezze. A modell fontos összetevője ennek a rendszernek. Nem ország, nem ellátási lánc, nem helyreállítási terv, és nem is olyan személy, akinek felhatalmazása van megjavítani azokat a részeket, amelyeket nem lát.

Európa infrastrukturális programjai lehetőséget kínálnak arra, hogy ezek a függőségek láthatóvá váljanak, amíg a kapacitás épül. A lehetőség gyakorlati. Tegyék közzé a felületeket és a működési határokat. Finanszírozzák a karbantartást és a szaktudást a berendezések mellett. Kezeljék a beszerzést tervezési döntésként. Kapcsolják össze a kiberbiztonságot a fizikai ellenálló képességgel. Adjunk a kisebb szervezeteknek utat a nyilvános infrastruktúra használatához anélkül, hogy minden réteg szakértőivé kellene válniuk. Mérjék a hozzáférést, a helyreállítást és a bizonyítékokat ugyanolyan gondosan, mint a csúcsteljesítményt.

Van valami sajátosan európai abban a felismerésben, hogy egy nagy technológiai kérdésre a válasz egy leltár, egy üzemeltetési kézikönyv és egy ember, akinek joga van leállítani a gépet. Ez nem látványos, de megvan az az előnye, hogy túléli a hétköznapok próbáját. Amikor a rejtett rendszer elég látható ahhoz, hogy megvizsgálható legyen, a modell elvégezheti a dolgát anélkül, hogy olyan mítoszt cipelne, amelynek hordozására soha nem építették.

Források