Svarbiausia dirbtinio intelekto sistema gali būti ta, kurios niekas nemato.

The model is the visible layer. Europe’s real AI capability depends on the chips, compute, networks, records, contracts and people beneath it.

Svarbiausia dirbtinio intelekto sistema gali būti ta, kurios niekas nemato.

Mašina, slypinti už atsakymo

Pirmasis Europos egzaskalės superkompiuteris nėra metafora. JUPITER yra reali sistema Forschungszentrum Jülich centre, kurią eksploatuoja Jülich superkompiuterių centras. EuroHPC bendroji įmonė aprašo tiesiogiai skysčiu aušinamą „BullSequana“ architektūrą, 20 petabaitų itin spartų „flash“ skaidinį ir dizainą, skirtą sudėtingoms simuliacijoms ir skaičiavimais intensyviam dirbtiniam intelektui. Aprašyme gausu detalių, dėl kurių sistema tampa įmanoma: procesoriaus architektūra, saugyklos pakopa, aušinimo būdas, eksploatuojanti institucija ir prieigos kelias. Modelis, kuris kada nors galėtų veikti jos pagrindu, yra tik viena sakinio dalis.

Tą skirtumą lengva pamiršti, nes matoma dirbtinio intelekto dalis yra atsakymas. Žmogus užduoda klausimą, modelis grąžina tekstą, o ekranas sudaro įspūdį, kad intelektas atkeliavo vienu paketu. Paslėptas darbas ne toks kinematografiškas. Elektra turi pasiekti pastatą. Komponentai turi atvykti tinkamos būklės. Programinės įrangos vaizdu (firmware) turi būti pasitikima. Tinklai turi perduoti duomenis tarp procesorių ir saugyklų. Tapatybė turi nustatyti, kuris asmuo ar paslauga gali naudotis kuriais ištekliais. Planuoklis turi rasti pajėgumų. Registras turi pasakyti operatoriui, kuris modelis, konteineris ir duomenų leidimas yra naudojami. Stebėsena turi pastebėti, kad sistema pasikeitė. Kažkas vis tiek turi mokėti ją sutaisyti lietingą antradienį, kai pardavėjo dokumentacija įgijo naują versijos numerį, o vienintelis žmogus, supratęs senąją, atostogauja.

Svarbi dirbtinio intelekto sistema todėl gali būti ta, kurios niekas nemato. Tai tiekimo grandinė, elektros energijos sutartis, tinklo audinys, priežiūros planas, programinės įrangos priklausomybių medis, viešųjų pirkimų sprendimas ir institucinė atmintis, leidžianti naudoti modelį neapsimetant, kad modelis yra visa paslauga. Kai ta paslėpta sistema silpna, pajėgesnis modelis nepadaro paslaugos stipresnės. Jis suteikia silpnai sistemai įspūdingesnį būdą žlugti.

Tai ne argumentas prieš modelius ar dideles viešąsias skaičiavimo programas. Tai argumentas už sąžiningą jų apibūdinimą. Europa kuria pajėgumus per Lustų aktą (Chips Act), EuroHPC ir dirbtinio intelekto gamyklų programą. Komisijos politikos puslapiuose kalbama apie strategines priklausomybes, tiekimo grandinės atsparumą, prieigą mažesnėms įmonėms ir infrastruktūrą, reikalingą patikimam dirbtiniam intelektui. Tai infrastruktūros klausimai, o ne prekės ženklo klausimai. Jei žemynas nori naudingų pajėgumų, o ne rinkinio įspūdingų demonstracijų, jis turi traktuoti tylųjį sluoksnį kaip pajėgumų dalį.

Atsakymas yra viršutinis sluoksnis. Paslauga priklauso nuo kiekvieno žemiau esančio sluoksnio.

Modelis yra komponentas, o ne šalis

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.

ENISA 2024 m. ateities atnaujinimas programinės įrangos tiekimo grandinės pažeidžiamumą iškelia į savo 2030 m. kibernetinio saugumo grėsmių sąrašo viršų. Jame taip pat įvardijami įgūdžių trūkumas, žmogiškosios klaidos kibernetinėse-fizinėse ekosistemose, tarptautiniai IRT paslaugų teikėjai kaip vienintelis gedimo taškas ir aplinkos sutrikimų fizinis poveikis kritinei skaitmeninei infrastruktūrai. Tai nėra teiginiai, kad kiekvienas dirbtinio intelekto projektas susidurs su visais šiais iššūkiais. Tai priminimas, kad grėsmių paviršius sudarytas iš tarpusavio ryšių. Pataisa, tiekėjas, žmogus ir potvynis gali paveikti tą pačią paslaugą, net jei jie įtraukti į skirtingus rizikos registrus.

Tos pačios ataskaitos kalba naudinga, nes ji atmeta fantaziją, kad kibernetinė rizika priklauso tik saugumo komandai. Priklausomybė gali būti pažeista programinėje įrangoje, tačiau jos pasekmės gali pasireikšti per fizinį procesą, pirkimo sprendimą arba trūkstamą įgūdį. Paslauga gali tapti vieninteliu gedimo tašku, nes jos teikėjas yra techniškai puikus ir plačiai naudojamas. Koncentracija nėra tas pats, kas nekompetencija. Tai yra tinklo aplink paslaugą savybė.

Tai sukuria praktinę ribų problemą. Jei organizacija vertina tik modelį ir jo tiesioginę vykdymo aplinką, rezultatas gali būti tikslus pasirinktoms riboms, bet klaidinantis jos teikiamai paslaugai. Jei ji vertina kiekvieną tiekėją vienodai intensyviai, gaus skaičiuoklę, kurios niekas negali prižiūrėti. Atsakymas yra priklausomybių žemėlapis, kuris seka pasekmes. Nustatykite, kas gali pakeisti rezultatą, nutraukti paslaugą, ištrinti įrodymus, išplėsti įgaliojimus arba užkirsti kelią atkūrimui. Tada paklauskite, ar priklausomybė yra pakankamai matoma, kad būtų galima ją stebėti, ir ar egzistuoja alternatyvus kelias.

Tas žemėlapis turėtų apimti įprastas medžiagas. Serveriui reikia atminties, saugojimo įrenginių, energijos konversijos, aušinimo įrangos ir atsarginių dalių. Tinklui reikia optinių komponentų, jungiklių, maršrutizavimo programinės įrangos ir žmonių, išmanančių topologiją. Programinės įrangos tiekimo grandinei reikia prižiūrėtojų, kūrimo infrastruktūros, paketų registrų, pasirašymo raktų ir leidimo procedūrų. Nė vienas iš šių dalykų netampa mažiau svarbus vien todėl, kad produkto brošiūroje rašoma dirbtinis intelektas.

Viliuojasi atsakyti didesne tiekėjų apklausa. Apklausa gali būti naudinga, bet tai nėra priklausomybių žemėlapis. Ji užfiksuoja tai, ką tiekėjas sako vienu momentu. Veiklos klausimas yra tai, ar pirkėjas gali pastebėti pokytį, jį interpretuoti ir imtis proporcingų veiksmų. Sertifikatų sąrašas nepakeičia žinojimo, kuris komponentas sustabdytų paslaugą, jei jis dingtų rytoj rytą. Europos organizacijos yra nuostabiai geros renkant dokumentus. Sunkesnis amatas yra priversti dokumentus nukreipti į sprendimą.

Lustai daro nematomą fiziniu

Europos lustų aktas konstatuoja faktą, kuris turėtų būti akivaizdus ir vis tiek turi būti konstatuojamas: puslaidininkiai yra elektroninių gaminių statybiniai blokai ir yra svarbūs sektoriams nuo ryšių ir duomenų apdorojimo iki sveikatos priežiūros, energetikos, transporto ir pramoninės automatikos. Aktas įsigaliojo 2023 m. rugsėjį ir nustato tikslus, įskaitant mokslinių tyrimų ir technologinės lyderystės stiprinimą, projektavimo, gamybos ir pakavimo pajėgumų didinimą, įgūdžių trūkumo sprendimą ir gilesnio pasaulinės puslaidininkių tiekimo grandinės supratimo ugdymą.

Tas sąrašas svarbus dirbtiniam intelektui, nes skaičiavimo galia nėra sukuriama debesijos logotipo. Ją sukuria grandinė, sudaryta iš projektų, plokštelių, įrangos, pakavimo, testavimo, energijos tiekimo, aušinimo, tinklų ir priežiūros. Vienos dalies trūkumas ar vėlavimas gali pakeisti tai, ką duomenų centras gali pristatyti, net kai modelio failai yra paruošti. Jei komponento gamybos laikas ilgas, operatorius negali išspręsti problemos išmaniu raginimu. Jei programinės įrangos priklausomybės negalima saugiai atnaujinti, gali tekti rinktis tarp kontroliuojamo paslaugos sumažinimo ir nesaugaus bandymo išlaikyti viską veikiantį.

The Commission's overview records the Chips Act's three pillars. The first supports capacity building and innovation, including pilot lines and competence centres. The second addresses security of supply and resilience through manufacturing, advanced packaging, testing and assembly. The third creates monitoring and crisis-response mechanisms, including a European Semiconductor Board that maps and monitors the value chain and coordinates responses to semiconductor crises. The institutional design is a useful correction to the idea that sovereignty means producing every component domestically. Resilience is partly about capacity, partly about visibility, and partly about the ability to respond when a dependency moves.

The page also gives concrete examples of approved first-of-a-kind facilities in Catania, Crolles, Dresden, Novara, Premstätten, Milan and other European locations. Those entries are not proof that Europe has solved the semiconductor problem. They are proof that the value chain has physical places, technologies and investment decisions that can be named. Naming them changes the conversation. It allows someone to ask what capability each facility adds, which inputs it still relies on, which skills it needs and how it would be supported during a disruption.

The Commission's proposal for a Chips Act 2.0, published in June 2026, says that the Union remains dependent on third countries in key areas such as advanced chip manufacturing and semiconductor design. For a July 31 article, this is a current policy statement, not a prediction about a future bill. Its practical implication is straightforward: a European service can be hosted in Europe and still depend on a global chain whose most important decisions happen elsewhere. Physical location is valuable. It is not the same as control.

AI policy can become more serious when it borrows this physical vocabulary. Instead of asking whether a model is European, ask which parts of the service can be repaired, replaced, inspected and paused within European institutions. Instead of asking whether a provider has a European region, ask how hardware, firmware, software dependencies and operating authority move through the service. The answer will be untidy. Good. Untidy maps are often the first honest ones.

Compute is a public capability

EuroHPC offers a useful case because it makes computing infrastructure visible without turning it into a consumer product. Its public list says that the Joint Undertaking has procured twelve state-of-the-art supercomputers across Europe. The list names systems and hosts: JUPITER at Jülich in Germany, LUMI in Kajaani, Leonardo in Bologna, MareNostrum 5 in Barcelona, Karolina in Ostrava and Arrhenius at Linköping University, among others. The locations matter less as a league table than as a reminder that compute is embedded in institutions, buildings, staff, power systems, storage and research programmes.

JUPITER is described as Europe's first exascale supercomputer, with a direct-liquid-cooled architecture, a 20-petabyte flash partition and a cluster module using the SiPearl Rhea1 processor alongside a GPU-accelerated booster. LUMI's page describes separate CPU, GPU, data-analytics and container-cloud partitions, with a storage system that combines flash, a parallel filesystem and a data-management service. These details are not trivia for engineers alone. They tell a policy reader that a supercomputer is a set of differently shaped resources. A workload that fits one partition may not fit another. Access, scheduling and data movement are part of the capability.

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.

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.

Techninė priežiūra taip pat keičia tai, ką reiškia našumo teiginys. Etaloninis bandymas, atliktas su viena versija, ką nors sako apie tą versiją nurodytomis sąlygomis. Jis neteigia, kad sistema elgsis taip pat po tvarkyklės atnaujinimo, kompiliatoriaus pakeitimo, naujo planuoklio, kitokio saugyklos kelio ar naujo darbo krūvio. Naudinga paslauga išlaiko savo teiginių sąlygas. Ji įrašo versijas, įvestis, aparatinę įrangą, politikas ir pakeitimus, kad kas nors galėtų pakartoti testą arba paaiškinti, kodėl pakartojimas nebeįmanomas.

Yra žmogiškoji kaina, kai apsimetama, kad techninė priežiūra yra antraeilis rūpestis. Operatoriai atidėlioja atnaujinimus, nes priklausomybių grafikas neaiškus. Saugumo komandoms sunku pasakyti, kuris paketas iš tikrųjų veikia gamyboje. Pirkimų skyrius pratęsia sutartį, nes niekas nebuvo repetavęs pasitraukimo. Tyrėjai negali pakartoti rezultato, nes aplinka nukrypo. Vartotojai susiduria su protarpinėmis klaidomis, dėl kurių kaltinamas modelis, nes paslauga neturi bendros kalbos apie po ja esančius sluoksnius. Rezultatas nėra vienas dramatiškas gedimas. Tai lėtas pasitikėjimo mažėjimas.

Techninės priežiūros grafikas todėl turėtų apimti daugiau nei pataisų datas. Jis turėtų apimti nuosavybės peržiūras, prieigos galiojimo pabaigą, sertifikatų ir raktų rotaciją, atsarginių kopijų atkūrimo testus, priklausomybių peržiūrą, aparatinės įrangos gyvavimo ciklą, tiekėjo pakeitimų pranešimus, modelio išėmimą ir kiekvienam reikalingus įrodymus. Kai kurias iš šių užduočių galima automatizuoti. Atsakomybės automatizuoti negalima. Kažkas turi nuspręsti, kas laikoma esminiu pakeitimu, kas gauna signalą ir kuri institucija gali sustabdyti paslaugą.

Europos įprotis sunkiai problemai spręsti sukurti komitetą kartais yra išjuokiamas, dažnai nesąžiningai. Komitetas, kuris valdo priklausomybių žemėlapį, pakeitimų taisyklę ir eskalavimo kelią, yra naudingesnis nei prietaisų skydelis, kuris niekam nepriklauso. Problema ne valdymas. Problema yra valdymas, kuris negali pasiekti mašinos.

Pirkimai yra vieta, kur priklausomybės tampa įsipareigojimais

Sutartys paverčia priklausomybę įsipareigojimu. Pirkėjas pasirenka tiekėją, komponentą, palaikymo susitarimą, duomenų vietą, atnaujinimo laikotarpį ir pasitraukimo sąlygą. Sprendimas gali būti apibūdinamas kaip AI paslaugos pirkimas, tačiau pirkėjas taip pat perka tiekėjo atnaujinimo procesą, incidentų reagavimą, tapatybės modelį, sąsajos stabilumą, dokumentaciją ir gebėjimą išlikti versle. Tai nėra antrinės funkcijos. Jos lemia, kiek autoriteto išlaiko pirkėjas.

ENISA 2025 m. patariamosios grupės dokumentas apie NIS2 įgyvendinimą yra neįprastai tiesmukas šiuo klausimu. Jame pažymima, kad mažesnės įmonės gali patekti į NIS2 atitikties darbus, nes jos tiekia subjektus, kuriems taikoma apimtis. Jame argumentuojama už Europos tiekimo grandinės saugumo ir pirkimų sistemą su pagrindinių priemonių rinkiniu ir bendru išsamaus patikrinimo metodu. Jame taip pat raginama nustatyti pirkimų pagrindą su minimaliais sutarties reikalavimais, standartinėmis sąlygomis, saugumo testavimo metodais ir paprastu būdu klientui įvertinti tiekėjus. Dokumentas yra patariamoji nuomonė, o ne reglamentas. Jo vertė čia yra ta, kad jis įvardija veiklos trintį, kuri atsiranda, kai kiekvienas pirkėjas sugalvoja skirtingą išsamaus patikrinimo versiją.

Pirkimų komandoms nereikia reikalauti, kad kiekvienas tiekėjas atskleistų kiekvieną vidinę detalę. Jos turi užduoti klausimus, kurie susiję su pasekmėmis. Kurie komponentai yra būtini paslaugai? Kaip perduodami pakeitimai? Kaip pirkėjas gali patikrinti naudojamą programinę įrangą ir programinės aparatinės įrangos kodą? Kas atsitinka, jei tiekėjas ar subtiekėjas negali pateikti komponento? Kokie duomenys ir įrodymai gali būti eksportuojami? Kiek laiko tęsiasi palaikymas po versijos išėmimo? Kas gali sustabdyti operaciją ir kas atsitinka su jau vykdomu darbu?

Šie klausimai nėra tokie patrauklūs kaip demonstracija. Juos taip pat sunkiau suklastoti. Tiekėjas gali per dešimt minučių parodyti sklandų atsakymą. Sunkiau pateikti išsamų priklausomybių sąrašą, išbandytą atkūrimą, migracijos kelią ir asmenį, įgaliotą tinkamu metu pasakyti „ne“. Pirkėjas neturėtų vertinti šio sudėtingumo kaip priežasties vengti klausimų. Tai priežastis juos užduoti, kol paslaugą dar nėra sunku pakeisti.

Apie susitelkimo riziką verta kalbėti atsargiai. Plačiai naudojamas tiekėjas nėra automatiškai nesaugus, o mažas tiekėjas nėra automatiškai atsparus. Susitelkimas tampa rizika, kai vienas tiekėjas, programinės įrangos saugykla, geografinis maršrutas, tapatybės institucija ar priežiūros komanda turi didesnę reikšmę, nei organizacija gali atlaikyti. ENISA perspektyvų ataskaitoje tarpvalstybiniai IRT paslaugų teikėjai apibūdinami kaip galimas vienintelis gedimo taškas. Tinkamas atsakas nėra apsimesti, kad susitelkimą galima panaikinti. Reikia nustatyti, kur jis egzistuoja, apibrėžti priimtiną priklausomybę ir išbandyti, kas nutiktų, jei maršrutas taptų nepasiekiamas.

Išėjimo sąlygos dažnai rašomos kaip teisinė dekoracija. Tikra išėjimo sąlyga turi techninę formą. Ji apima formatus, sąsajas, atgavimo teises, raktus, žurnalus, įrodymus, pagalbą pereinamuoju laikotarpiu, ištrynimo patvirtinimą ir mažiausią informaciją, reikalingą paslaugai atkurti kitur. Ji yra tvirtesnė, kai išbandyta su nedideliu darbo krūviu. Testas neturi būti teatrališkas. Kontroliuojamas eksportas, atkūrimas nepriklausomoje aplinkoje ir gauto rezultato palyginimas gali atskleisti daugiau nei keli puslapiai garantijų.

Kritinė infrastruktūra yra priklausomybių tinklas

Kritinių subjektų atsparumo direktyva daro panašų žingsnį esminių paslaugų lygmeniu. Ji apibrėžia atsparumą kaip subjekto gebėjimą užkirsti kelią incidentui, apsisaugoti nuo jo, į jį reaguoti, jam priešintis, sušvelninti jo padarinius, juos absorbuoti, prisitaikyti prie jų ir atsigauti po incidento. Joje kritinė infrastruktūra apibūdinama kaip turtas, įrenginys, įranga, tinklas ar sistema, būtini esminei paslaugai. Formuluotė sąmoningai platesnė nei pastatas. Paslauga traktuojama kaip turto, žmonių ir funkcijų tarpusavio ryšys.

Direktyvoje nurodyta, kad valstybės narės turėtų įvertinti tarpsektorinę ir tarpvalstybinę riziką, ir atkreipiamas dėmesys į didėjančią infrastruktūros ir sektorių tarpusavio priklausomybę. Joje taip pat teigiama, kad vertinant trikdančio incidento reikšmę reikėtų atsižvelgti į tiekimo grandinės padarinius. Tai svarbu DI infrastruktūrai, nes atitinkama paslauga gali iš viso nebūti pažymėta kaip dirbtinis intelektas. Duomenų ryšys, elektros sistema, tapatybės paslauga, ligoninės įrašų sistema ar mokslinių tyrimų tinklas gali būti sluoksnis, dėl kurio veikia DI paslauga.

Direktyva nėra DI veiklos vadovas. Ji nepriskiria kiekvienos modelio paslaugos prie kritinių ir nepakeičia sektoriui skirtų taisyklių. Ji suteikia būdą mąstyti apie padarinius. Jei sistema palaiko esminę paslaugą, klausimas yra ne tik tai, ar modelis išlaikė vertinimą. Klausimas, ar subjektas gali toliau teikti esminę paslaugą, kai pasikeičia komponentas, įrenginys, tiekėjas, tinklas ar išorinės sąlygos.

NIS2 šalia šio fizinio ir organizacinio požiūrio nustato kibernetinio saugumo rizikos valdymo ir incidentų pranešimo pareigas atitinkamiems subjektams. Teisinė sąveika yra konkreti ir priklauso nuo subjekto bei sektoriaus. Bendra pamoka nėra ta, kad viena direktyva išsprendžia atsparumo klausimą. Esmė ta, kad kibernetinės ir fizinės priklausomybės turi būti koordinuojamos. Tinklas gali būti saugus nuo vienos rūšies atakos ir vis tiek sugesti, kai nėra aušinimo. Įrenginys gali turėti atsarginį maitinimą ir vis tiek negalėti autentifikuoti operatorių. Tiekėjas gali pranešti apie programinės įrangos incidentą, o pirkėjas neturėti įrašų, reikalingų jo poveikiui suprasti.

Atsparumas todėl turi turėti žodyną apribotam aptarnavimui, o ne tik visiškam sutrikimui. Ar sistema gali priimti mažiau užklausų? Ar ji gali išjungti didelės rizikos funkciją, išsaugodama mažos rizikos funkciją? Ar ji gali pereiti prie mažesnio modelio arba rankinio kelio? Ar ji gali veikti toliau, kol eilė ištuštinama ir šaltinis patikrinamas? Ar ji gali įrodyti, kurie darbai buvo atidėti arba perdirbti? Tai operaciniai sprendimai. Jie taip pat lemia, ar piliečiai, tyrėjai ir įmonės patiria kontroliuojamą apribojimą, ar paslaptingą atsakymą, kuris gaunamas po to, kai institucija prarado kontekstą jam peržiūrėti.

Naudingas vaizdinys yra tinklas, kurio mazgai turi savininkus, o jungtys turi sąlygas. Jungtis gali būti elektros ryšys, programinės įrangos priklausomybė, sutartis, duomenų perdavimas arba įgaliojimų santykis. Atsparus dizainas nelaiko savaime suprantamu, kad kiekviena jungtis išliks prieinama. Jis užfiksuoja jungtį, stebi svarbią sąlygą ir apibrėžia atsaką dar prieš atsirandant spaudimui.

Iliustratyvus apibendrinimas, o ne incidento ataskaita

Padeda priklausomybių problemą padaryti konkrečią neišgalvojant tikro sutrikimo. Toliau pateikiamas iliustratyvus apibendrinimas. Jis neaprašo jokios įvardytos organizacijos, tiekėjo, įstaigos, asmens, datos ar įvykio. Tai minties eksperimentas, sudarytas iš įprastų infrastruktūros santykių.

Įsivaizduokite viešąją mokslinių tyrimų paslaugą, kuri leidžia įgaliotoms komandoms pateikti dokumentą, paleisti klasifikavimo darbo eigą ir gauti rezultatą žmogaus peržiūrai. Paslauga talpinama Europos infrastruktūroje. Jos modelis saugomas artefaktų registre. Šaltinio dokumentai yra vienoje saugyklos pakopoje, o indeksas kitoje. Tinklų vartai tikrina tapatybę ir perduoda darbą į eilę. Darbuotojai naudoja konteinerio atvaizdį ir aparatinės įrangos tvarkyklę. Rezultatai įrašomi į įrašų saugyklą ir įrodymų srautą. Skydelis operacijų komandai parodo, ar sistema yra sveika.

Čia nėra nieko neįprasto. Tai ir yra esmė. Dabar keiskite po vieną sąlygą vienu metu. Registras keičia savo pasirašymo politiką. Tvarkyklės naujinimas reikalauja naujos konteinerio vykdymo aplinkos. Sertifikatas, skirtas paslaugai, kuri įrašo įrodymus, nustoja galioti, o rezultatų saugykla ir toliau priima įrašus. Išvestiniam indeksui pasiekiama saugyklos kvota, bet šaltinio dokumentams ne. Tiekėjas pakeičia sąsają, o eilės vartotojas bando pakartoti operaciją, kuri nebuvo sukurta kartojimui. Patyręs operatorius išeina, o veiksmų vadovas vis dar aprašo ankstesnį diegimą. Nė vienas iš šių pakeitimų nereikalauja, kad modelis sukurtų klaidingą sakinį. Kiekvienas iš jų gali pakeisti paslaugos patikimumą arba jos gebėjimą paaiškinti save.

Organizacija, kuri stebi tik modelio tikslumą, gali nepamatyti jokio įspėjimo. Testų rinkinys vis tiek išlaikomas. Organizacija, kuri stebi visą paslaugą, matys skirtingus signalus: patikros nesėkmę, didėjantį pakartojimų skaičių, įrodymų srauto spragą, saugyklos slenkstį, neperžiūrėtą pakeitimą arba nuosavybės pavojaus signalą. Signalai nėra lygiaverčiai ir ne visi reikalauja sutrikimo. Jie reikalauja taisyklės, kas nusprendžia, kas vyksta toliau.

Tarkime, komanda nusprendžia sumažinti pajėgumą, kol tikrina priklausomybę. Tai nėra ženklas, kad paslauga neįvykdė savo tikslo. Tai gali būti ženklas, kad paslauga turi tikslą, didesnį už pralaidumą. Jei sistema gali išsaugoti šaltinio įrašą, pažymėti atidėtą darbą, užkirsti kelią neleistiniems pakartojimams ir suteikti žmogui aiškų kelią apžiūrėti paveiktus atvejus, ji sugedo kontroliuojamai. Jei ji ir toliau pateikia išpuoselėtus atsakymus, kai jos įrodymų kelias yra nutrūkęs, ji išsaugojo aptarnavimo išvaizdą pasitikėjimo sąskaita.

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.

Priklausomybei nebūtina sunaikinti modelio, kad pakeistų tai, ką paslauga gali atsakingai teigti.

Matuokite pajėgumą neslėpdami vardiklio

Infrastruktūra skatina įspūdingus skaičius. Eksaflopsai, petabaitai, procesorių skaičiai, investicijų sumos ir objektų skaičius programoje apibūdina kažką realaus. Tačiau nė vienas iš jų nėra pati paslauga. Skaičius tampa naudingas, kai matomi jo vardiklis ir sąlygos.

Didžiausias skaičiavimo našumas tyrėjui nepasako, kaip greitai konkretus darbo krūvis gaus dalį, perkels savo duomenis, užbaigs vykdymą ar atgaus rezultatą. AI gamyklų skaičius mažai įmonei nepasako, ar jos programa gaus prieigą jai reikalingomis sąlygomis. Puslaidininkių investicijų suma operatoriui nepasako, kuris komponentas bus prieinamas trūkumo metu. Aukštas prieinamumo procentas viešajai įstaigai nepasako, ar ji gali atgauti įrodymus dėl ginčijamo sprendimo.

Todėl atsakingas pajėgumo aprašymas antraštę susieja su už jos esančiu keliu. Įvardykite aparatinės ir programinės įrangos ribą. Nurodykite, ar skaičius yra didžiausias, nuolatinis, planuotas ar stebėtas. Apibūdinkite darbo krūvį, prieigos modelį ir išimtis. Pasakykite, kurios priklausomybės nepatenka į matavimą. Susiekite teiginį su leidimu, aparatine įranga, duomenų rinkiniu ir politika, pagal kuriuos jis buvo pateiktas. Tikslas nėra padaryti kiekvieną puslapį neskaitytinu. Tikslas yra padaryti svarbius puslapius patikrinamus.

Ši disciplina taip pat gerina viešąjį argumentą. Europa neturi rinktis tarp ambicijų ir atsargumo. Ji gali statyti didelius objektus, finansuoti ambicingus tyrimus ir vis tiek pasakyti, kur baigiasi įrodymai. Viešoji sistema, kuri įvardija savo apribojimus, yra patikimesnė nei ta, kuri pateikia švarų skaičių be jokio būdo jį patikrinti. Apribojimas gali būti eilė, sąsaja, tiekėjas, įgūdžių spraga, galios riba ar teisinė riba. Jo įvardijimas nesumažina pajėgumo. Jis pasako žmonėms, koks tai pajėgumas.

Neapibrėžtumas nėra pralaimėjimo pripažinimas. Tai priežiūros signalas. Jei niekas nežino, kaip tiekėjo pakeitimas paveiks darbo krūvį, kitas žingsnis yra testas arba aiški prielaida, o ne didesnis būdvardis. Jei registras negali atskirti modelio leidimo nuo aptarnavimo konfigūracijos, kitas žingsnis yra geresnis įrašas. Jei įstaiga negali pasakyti, kuris asmuo gali sustabdyti operaciją, kitas žingsnis yra autoritetų žemėlapis. Tikslumas yra būdas nuspręsti, ką taisyti.

Tylūs sluoksniai yra ten, kur suverenumas tampa praktiškas

European sovereignty is sometimes discussed as if it were a flag placed on top of a data centre. A service can be located inside the Union and still depend on external components, foreign legal reach, proprietary interfaces, scarce skills or a supplier whose change decisions cannot be challenged. Location is one input to a sovereignty assessment. Practical control depends on the complete chain.

The Chips Act's focus on understanding the global semiconductor supply chain, the CER Directive's attention to cross-sector interdependencies and ENISA's warnings about software dependencies and single points of failure all point in the same direction. Sovereignty is not a single switch. It is the ability to understand what a service depends on, to decide which dependency is acceptable, to replace or constrain it when necessary and to retain enough evidence to defend the decision.

That ability can be built in small ways. A public research group can keep an inventory of the runtime, driver and data release used for a result. A procurement team can require a tested export path rather than a promise of portability. An operations team can define a degraded mode and rehearse it. A regulator can ask which records would be available after a supplier change. A supplier can publish the boundary of its support and the conditions under which an update changes behaviour. None of these actions makes a system autonomous. They make it less mysterious.

At Dweve, this is the narrow reason we care about open foundations and the quiet pieces around them. Projects such as Core and Mesh are useful only when they sit inside an honest operational boundary, with clear records, authority and limits. They are not a substitute for European infrastructure, public institutions or supply-chain policy, and this article does not claim that they solve those problems. The position is smaller: an open component is easier to inspect, replace and teach when its contracts are explicit. That is one brick, not the whole building.

The building matters because people meet the top floor and live with the foundations. The answer on the screen may be fluent, but the service's real character is decided by the layers that determine where the answer came from, who could change it, what happens when a dependency moves and whether anyone can explain the result later.

Build the system people can still see

The most important AI system may be the one nobody sees because it is distributed across places that have never been called AI. It is the chip facility and the cooling loop. It is the supercomputer and the scheduler. It is the package registry, the identity provider, the storage policy, the network route and the maintenance roster. It is the contract that says what happens when a supplier changes a component. It is the institution that can pause a workflow before a weak signal becomes a public failure.

None of this reduces the importance of model quality. It gives model quality a place to matter. A model can only serve a person through a system that can receive the input, perform the work, preserve the relevant record and return the result with enough context for someone to trust or challenge it. The model is an important component of that system. It is not a country, a supply chain, a recovery plan or a person with authority to repair the parts it cannot see.

Europe's infrastructure programmes are an opportunity to make these dependencies visible while the capacity is being built. The opportunity is practical. Publish interfaces and operating boundaries. Fund maintenance and skills alongside equipment. Treat procurement as a design decision. Connect cybersecurity with physical resilience. Give smaller organisations a path to use public infrastructure without forcing them to become specialists in every layer. Measure access, recovery and evidence as carefully as peak performance.

Yra tam tikras europietiškas malonumas atrasti, kad atsakymas į didelį technologijos klausimą yra inventorius, veiksmų planas ir žmogus, kuriam leista sustabdyti mašiną. Tai nėra įspūdinga, tačiau turi pranašumą išlikti gyvybinga susidūrus su antradieniu. Kai paslėpta sistema yra pakankamai matoma, kad ją būtų galima apžiūrėti, modelis gali atlikti savo darbą nenešiodamas mito, kuriam nebuvo sukurtas.

Šaltiniai