Det vigtigste AI-system er måske det, ingen ser.

Modellen er det synlige lag. Europas reelle AI-formåen afhænger af chipsene, regnekraften, netværkene, dataene, kontrakterne og menneskene under det.

Det vigtigste AI-system er måske det, ingen ser.

Maskinen bag svaret

Europas første exascale-supercomputer er ikke en metafor. JUPITER er et reelt system på Forschungszentrum Jülich, drevet af Jülich Supercomputing Centre. EuroHPC Joint Undertaking beskriver dens direkte væskekølede BullSequana-arkitektur, en 20-petabyte ultrahurtig flash-partition og et design beregnet til krævende simuleringer og computerintensiv kunstig intelligens. Beskrivelsen er fuld af de detaljer, der gør et system muligt: en processorarkitektur, et lagringsniveau, en kølemetode, en driftsinstitution og en adgangsvej. Modellen, der måske en dag kører oven på det, er kun en del af sætningen.

Den skelnen er let at miste af syne, fordi den synlige del af AI er et svar. En person stiller et spørgsmål, en model returnerer tekst, og skærmen giver indtryk af, at intelligensen ankom i én pakke. Det skjulte arbejde er mindre spektakulært. Elektricitet skal nå bygningen. Komponenter skal ankomme i den rette stand. Et firmware-image skal være pålideligt. Netværk skal transportere data mellem processorer og lagring. Identitet skal fastslå, hvilken person eller hvilken tjeneste der må bruge hvilken ressource. En planlægger skal finde kapacitet. Et register skal fortælle en operatør, hvilken model, hvilken container og hvilken dataudgivelse der er i brug. Overvågning skal opdage, at systemet har ændret sig. Nogen skal stadig vide, hvordan man reparerer det en våd tirsdag, når leverandørens dokumentation har fået et nyt versionsnummer, og den eneste, der forstod det gamle, er på ferie.

Det vigtige AI-system kan derfor være det, ingen ser. Det er forsyningskæden, strømaftalen, netværksstrukturen, vedligeholdsplanen, softwareafhængighedstræet, indkøbsbeslutningen og den institutionelle hukommelse, der gør det muligt at bruge en model uden at lade, som om modellen er hele tjenesten. Når det skjulte system er svagt, gør en mere kapabel model ikke tjenesten stærkere. Den giver det svage system en mere imponerende måde at fejle på.

Dette er ikke et argument mod modeller eller store offentlige computerprogrammer. Det er et argument for at beskrive dem ærligt. Europa opbygger kapacitet gennem Chips Act, EuroHPC og AI Factories-programmet. Kommissionens politiksider taler om strategiske afhængigheder, modstandsdygtighed i forsyningskæden, adgang for mindre virksomheder og den infrastruktur, der kræves for pålidelig AI. Det er infrastrukturspørgsmål, ikke branding-spørgsmål. Hvis kontinentet vil have nyttig kapacitet frem for en samling imponerende demonstrationer, må det behandle de stille lag som en del af kapaciteten.

Svaret er det øverste lag. Tjenesten afhænger af hvert lag under det.

En model er en komponent, ikke et land

Offentlig debat bruger ofte en model som en forkortelse for en hel kapacitet. Et land har en model, en virksomhed har en model, en afdeling har en model, og modellen behandles, som om den bar sin egen forsyningskæde. Det gør den ikke. En model har en fil, parametre, en runtime og et sæt antagelser om det arbejde, den forventes at udføre. Tjenesten omkring den bærer resten af forpligtelserne.

Overvej et beskedent system, der klassificerer indkommende dokumenter, før et menneskeligt team gennemgår dem. Det har brug for en indtagskanal, en kø, en parser, lagring, adgangskontrol, en model-runtime, en resultatopbevaring, en notifikationssti, en måde at rulle en udgivelse tilbage på og en registrering af, hvad der skete. Klassificereren kan være præcis på sit testsæt og stadig være ubrugelig, hvis parseren taber et felt, hvis identitetssystemet tildeler den forkerte rolle, hvis modelcontaineren ikke kan hentes, eller hvis operatøren ikke kan se, hvilken version der lavede en anbefaling. Ingen af disse fejl er modelhallucinationer. Det er fejl i tjenesten, der gjorde modellen betydningsfuld.

Den modsatte fejl er lige så almindelig. Teams beskriver en hel tjeneste som robust, fordi modellen er blevet evalueret, mens de efterlader afhængighederne uden for evalueringsgrænsen. En modeltest kan kontrollere output for en udvalgt arbejdsbyrde. Den kontrollerer sjældent, om et certifikat udløber på samme tid, som et softwarerepository ændrer sin signeringsnøgle, om en lagringstier har nok kapacitet til et længere end normalt dokument, eller om en person kan hente kildeoptegnelsen, efter at en leverandør ændrer en applikationsprogrammeringsgrænseflade. Disse bekymringer hører til det operationelle system. De er stadig en del af, hvad en bruger oplever som AI.

Det nyttige spørgsmål er ikke, om en model er god i isolation. Det er, hvilke andre ting der skal være sande, før modellens output kan stoles på, og hvem der har autoritet til at reparere disse ting. Det spørgsmål flytter samtalen fra en modelkatalog til en systemgrænse. Det skaber også en mindre smigrende, men mere nyttig opgørelse.

  • Hvilke fysiske ressourcer skal forblive tilgængelige?
  • Hvilke software- og firmwarekomponenter skal ankomme intakte og forblive understøttede?
  • Hvilke identitets-, netværks-, lagrings- og registreringstjenester skal svare?
  • Hvilken organisation er ansvarlig, når afhængigheden ændres?
  • Hvilke beviser gør det muligt for en anden person at kontrollere svaret senere?
  • Forslag til Chips Act 2.0, Europa-Kommissionen, 3. juni 2026.

Disse spørgsmål er ikke teoretiske. De er forskellen mellem en kapacitet, der kan drives, og en kapacitet, der kan demonstreres én gang. Demonstrationer er behagelige. Væsentlige tjenester skal overleve det næste vedligeholdelsesvindue.

Forsyningskæder er inden for systemgrænsen

ENISA's arbejde med forsyningskædeintegritet begynder med en uglamourøs observation: regeringer, organisationer, virksomheder og forbrugere er i stigende grad afhængige af IKT-produkter og -tjenester og dermed af de forsyningskæder, der leverer dem. Dens rapport nævner trusler, der spænder fra manipulation under udvikling, distribution eller drift til substitution med forfalskede eller klonede komponenter. Pointen er bredere end en sikkerhedstjekliste. Det, der leveres, er ikke kun en boks. Det er en sekvens af mennesker, kode, komponenter, kontrakter og beslutninger, gennem hvilke boksen bliver tilstrækkeligt betroet til at blive brugt.

En AI-tjeneste arver den sekvens. En træningskørsel afhænger af et basisbillede, en compiler, en driver, en kerne, en scheduler og et kildedatasæt. En inferenstjeneste afhænger af de samme lag plus en serveringsruntime, et indeks, en politikport og en grænseflade, der kan fortsætte med at fungere, når trafikken ikke ligner testsættet. En offentlig institution kan købe en tjeneste frem for nogen af disse dele, men den skjulte kæde forsvinder ikke, fordi kontrakten kalder det en platform.

ENISA's 2024 foresight update puts software supply-chain compromise at the top of its list of cybersecurity threats for 2030. It also places skill shortages, human error in cyber-physical ecosystems, cross-border ICT service providers as a single point of failure and the physical impact of environmental disruption on critical digital infrastructure among the leading concerns. These are not claims that every AI project will encounter all of them. They are a reminder that the threat surface is made of relationships. A patch, a supplier, a person and a flood can all affect the same service, even though they appear in different risk registers.

The same report's language is useful because it resists the fantasy that cyber risk belongs only to the security team. A dependency can be compromised in software, but its consequences can arrive through a physical process, a procurement choice or a missing skill. A service can become a single point of failure because its provider is technically excellent and widely used. Concentration is not the same as incompetence. It is a property of the network around a service.

This creates a practical boundary problem. If an organisation evaluates only the model and its immediate runtime, the result may be accurate for the boundary it chose and misleading for the service it operates. If it evaluates every supplier with equal intensity, it will produce a spreadsheet that nobody can maintain. The answer is a dependency map that follows consequence. Identify what can alter an output, interrupt a service, erase evidence, widen authority or prevent recovery. Then ask whether the dependency is visible enough to monitor and whether another route exists.

That map should include ordinary materials. A server requires memory, storage devices, power conversion, cooling equipment and replacement parts. A network requires optical components, switches, routing software and people who know the topology. A software supply chain requires maintainers, build infrastructure, package registries, signing keys and release procedures. None of these becomes less important because the product brochure says artificial intelligence.

It is tempting to respond with a larger supplier questionnaire. A questionnaire can be useful, but it is not a dependency map. It records what a supplier says at one moment. The operational question is whether the buyer can notice a change, interpret it, and take a proportionate action. A list of certificates is not a substitute for knowing which component would stop the service if it disappeared tomorrow morning. European organisations are admirably good at collecting documents. The harder craft is making the documents point to a decision.

Chips make the invisible physical

The European Chips Act states a fact that should be obvious and still needs stating: semiconductors are building blocks for electronic products and central to sectors from communications and data processing to healthcare, energy, transport and industrial automation. The Act entered into force in September 2023 and sets out objectives that include strengthening research and technological leadership, reinforcing capacity for design, manufacturing and packaging, addressing skills shortages and developing a deeper understanding of the global semiconductor supply chain.

That list matters for AI because compute capacity is not made by a cloud logo. It is made by a chain of designs, wafers, equipment, packaging, testing, power delivery, cooling, networking and maintenance. A shortage or delay in one part can change what a data centre can deliver even when the model files are ready. If a component has a long lead time, an operator cannot fix the problem with a clever prompt. If a firmware dependency cannot be updated safely, the choice may be between a controlled reduction in service and an unsafe attempt to keep everything running.

Kommissionens oversigt beskriver Chips Act'ens tre søjler. Den første understøtter kapacitetsopbygning og innovation, herunder pilotlinjer og kompetencecentre. Den anden adresserer forsyningssikkerhed og modstandsdygtighed gennem fremstilling, avanceret emballering, test og samling. Den tredje skaber mekanismer til overvågning og krisehåndtering, herunder et europæisk halvlederråd, der kortlægger og overvåger værdikæden og koordinerer reaktioner på halvlederkriser. Den institutionelle udformning er en nyttig korrektion til idéen om, at suverænitet betyder at producere alle komponenter indenlandsk. Modstandsdygtighed handler delvist om kapacitet, delvist om synlighed og delvist om evnen til at reagere, når en afhængighed flytter sig.

Siden giver også konkrete eksempler på godkendte first-of-a-kind-faciliteter i Catania, Crolles, Dresden, Novara, Premstätten, Milano og andre europæiske lokationer. Disse poster er ikke bevis på, at Europa har løst halvlederproblemet. De er bevis på, at værdikæden har fysiske steder, teknologier og investeringsbeslutninger, der kan navngives. At navngive dem ændrer samtalen. Det gør det muligt at spørge, hvilken kapacitet hver facilitet tilføjer, hvilke input den stadig er afhængig af, hvilke kompetencer den har brug for, og hvordan den ville blive understøttet under en forstyrrelse.

Kommissionens forslag til en Chips Act 2.0, offentliggjort i juni 2026, siger, at Unionen fortsat er afhængig af tredjelande på centrale områder som avanceret chipfremstilling og halvlederdesign. For en artikel fra 31. juli er dette en aktuel politisk erklæring, ikke en forudsigelse om et fremtidigt lovforslag. Den praktiske konsekvens er ligetil: en europæisk tjeneste kan være hostet i Europa og stadig være afhængig af en global kæde, hvor de vigtigste beslutninger træffes andre steder. Fysisk placering er værdifuld. Det er ikke det samme som kontrol.

AI-politik kan blive mere seriøs, når den låner dette fysiske vokabular. I stedet for at spørge, om en model er europæisk, så spørg, hvilke dele af tjenesten der kan repareres, udskiftes, inspiceres og sættes på pause inden for europæiske institutioner. I stedet for at spørge, om en udbyder har en europæisk region, så spørg, hvordan hardware, firmware, softwareafhængigheder og driftsautoritet bevæger sig gennem tjenesten. Svaret vil være rodet. Godt. Rodede kort er ofte de første ærlige.

Compute er en offentlig kapacitet

EuroHPC er et nyttigt eksempel, fordi det gør computerinfrastruktur synlig uden at gøre den til et forbrugerprodukt. Den offentlige liste siger, at Joint Undertaking har indkøbt tolv state-of-the-art-supercomputere i hele Europa. Listen navngiver systemer og værter: JUPITER i Jülich i Tyskland, LUMI i Kajaani, Leonardo i Bologna, MareNostrum 5 i Barcelona, Karolina i Ostrava og Arrhenius på Linköpings Universitet, blandt andre. Placeringerne betyder mindre som en rangliste end som en påmindelse om, at compute er forankret i institutioner, bygninger, personale, strømsystemer, lagring og forskningsprogrammer.

JUPITER beskrives som Europas første exascale-supercomputer med en direkte væskekølet arkitektur, en 20-petabyte flash-partition og et klyngemodul, der bruger SiPearl Rhea1-processoren sammen med en GPU-accelereret booster. LUMI's side beskriver separate CPU-, GPU-, dataanalyse- og container-cloud-partitioner med et lagringssystem, der kombinerer flash, et parallelt filsystem og en datahåndteringstjeneste. Disse detaljer er ikke kun trivia for ingeniører. De fortæller en politisk læser, at en supercomputer er et sæt af forskelligt formede ressourcer. En arbejdsbyrde, der passer til én partition, passer måske ikke til en anden. Adgang, planlægning og dataflytning er en del af kapaciteten.

MareNostrum 5, som er hostet af Barcelona Supercomputing Center, og Arrhenius, som installeres på Linköpings universitet og drives af den nationale akademiske infrastruktur for supercomputing i Sverige, illustrerer det samme punkt på forskellige måder. En distribueret europæisk kapacitet er ikke én kæmpe maskine. Det er et sæt af systemer med forskellige processorer, lageropsætninger, operatører, adgangsregler og videnskabelige fællesskaber. Netværket mellem dem betyder noget, men det gør samlingerne også.

Kommissionens AI Factories-politik beskriver et program bygget på den virkelighed. AI Factories bruger EuroHPC-supercomputerkapacitet til at udvikle avanceret generativ AI og forbinder computercentre, universiteter, små og mellemstore virksomheder, industri og finansielle aktører. Siden siger, at der på tidspunktet for opdateringen i april 2026 var nitten AI Factories og tretten antenner i drift, og at der var planlagt mindst ni nye AI-optimerede supercomputere. Den beskriver også en langsigtet investering på ti milliarder euro gennem EuroHPC i perioden 2021 til 2027. Det er institutionelle ordninger, ikke en garanti for, at hvert projekt får den kapacitet, det ønsker, eller at hver model vil være pålidelig.

Værdien af sådanne ordninger er ikke kun hastighed. Offentlig computerkraft kan skabe et sted, hvor europæiske forskere og virksomheder kan køre arbejdsbelastninger under regler og adgangsordninger, der er synlige for offentlige institutioner. Det kan understøtte eksperimenter, som ellers ville være prissat ud, og det kan gøre noget viden reproducerbar på tværs af steder. Det kan også introducere nye afhængigheder, hvis et program er afhængigt af et lille antal leverandører, en enkelt softwarestak eller en arbejdsstyrke, der ikke kan erstattes. Offentligt ejerskab af en facilitet fjerner ikke det operationelle arbejde. Det gør ansvaret sværere at skjule, hvilket er sundere.

Når computerkraft bliver offentlig kapacitet, bør dens succes måles ud over topydelse. Kan en mindre forskningsgruppe få adgang? Kan en følsom arbejdsbelastning adskilles fra en generel? Kan en operatør vise, hvilken software og hardware der blev brugt? Kan et team flytte en arbejdsbelastning, når en partition er fuld, eller en afhængighed er udfaset? Kan en offentlig myndighed forklare betingelserne for, hvordan en model blev trænet? En hurtig maskine, der ikke kan besvare disse spørgsmål, er stadig nyttig til noget videnskab, men den er endnu ikke et komplet fundament for offentlig AI.

Netværk, lagring og identitet gør det stille arbejde

De vigtigste lag er ofte dem, der ikke optræder i et AI-diagram. Et diagram tegner en model mellem en input og en output. En operatør ser en kæde af netværksstier, lagringsklasser, identitetsbekræftelser, køer, certifikater, registre, hemmeligheder, observerbarhedspipelines og ændringskontroller. Diagrammet er ikke forkert. Det er ufuldstændigt på præcis den måde, der producerer dyre overraskelser.

Start med netværket. En stor modeltjeneste kan flytte data mellem acceleratorer, hukommelse, lagring og andre tjenester. En offentlig forskningsarbejdsbelastning kan flytte datasæt til en supercomputer og resultater tilbage til et universitet. En produktionsarbejdsgang kan krydse en politikgrænse, før den når en model, og en anden grænse, før den returnerer en beslutning. Latens, pakketab, routingændringer og vedligeholdelse kan ændre adfærden for hele tjenesten uden at ændre en enkelt parameter i modellen. En timeout kan blive til en gentagelse, en gentagelse kan blive til dobbeltarbejde, og dobbeltarbejde kan blive til en forkert registrering. Modellen besluttede ikke at gentage. Det gjorde det omkringliggende system.

Lagring har sin egen skjulte grammatik. Der er kildeposten, den transformerede post, indekset, cachen, loggen, sikkerhedskopien, sletningsmarkøren og beviset for, hvilken version der blev brugt. En tjeneste kan måske besvare et spørgsmål, men stadig ikke kunne bevise, hvilke data der gjorde svaret muligt. Opbevaring og genfinding er ikke spejlbilleder af hinanden. At beholde alt for evigt kan overtræde en formålsbegrænsning; at slette kilden, mens man efterlader et afledt produkt eller en cache, kan skabe et andet problem. En seriøs datagrænse angiver, hvad der lagres, hvor længe, af hvem, og hvordan en senere kontrollant kan se, at grænsen blev overholdt.

Identitet er ikke en login-skærm. Det er den mekanisme, der giver en person, en tjeneste eller en agent autoritet til at udføre en handling. Hvis et inferens-endepunkt kan kalde et værktøj, skal systemet vide, hvilken principal der spurgte, hvilken politik der tillod kaldet, og hvad værktøjet måtte røre. Hvis et register tillader, at en container forfremmes, skal det vide, hvem der kan godkende forfremmelsen, og hvilke beviser der kræves. Hvis et certifikat fornyes automatisk, skal tjenesten stadig have en måde at opdage, at identitetsforholdet har ændret sig. En hemmelighed, der forbliver gyldig, efter at den person, der anmodede om den, er gået, er et vedligeholdelsesproblem med en sikkerhedsmæssig konsekvens.

Registre er hukommelsen i et system i bevægelse. Et modelregister kan indeholde versioner og metadata. Et artefaktregister kan indeholde containere, pakker eller signerede udgivelser. Et dataregister kan beskrive skemaer og ejerskab. En hardwareinventarliste kan identificere et board, en firmwareudgivelse og udskiftningsstatus. Pointen er ikke at oprette ét register til alt. Pointen er at gøre den autoritative kilde for hver påstand eksplicit. Hvis intet system kan svare på, hvilken model, driver, dataudgivelse og politikversion der var aktive, er en senere gennemgang tvunget til at udlede historikken fra de logfiler, der overlevede.

Observabilitet lukker kredsløbet. Målinger fortæller en operatør, at en kø er vokset, eller at en enhed er varm. Spor viser stien, en anmodning tog. Logfiler bærer kontekst, selvom de er lette at misforstå. Hændelser og attesteringer kan bevare beslutninger og ændringer. Disse objekter har forskellige opgaver. At behandle dem som udskiftelige giver enten støj eller en falsk følelse af bevis. Designspørgsmålet er, hvad en person skal vide, når tjenesten er forsinket, forkert, utilgængelig eller omstridt, og hvilken post der kan besvare det spørgsmål uden en rekonstruktionsøvelse.

Man kan beskrive dette som kedelig teknik. Det er ikke en fornærmelse. Kedelig teknik er den del, der fortsætter med at virke, efter at lanceringsopslaget er rykket ned på forsiden. Det er også den del, der afgør, om en ny model kan tages i brug uden at omskrive institutionen omkring den.

Vedligeholdelse er en kapacitet, ikke en udgiftspost

Infrastrukturhistorier kan godt lide at slutte ved implementering. Det er, når arbejdet bliver en tjeneste. En model udgives, et cluster tages i brug, en fabrik åbner, en kontrakt underskrives, og fortællingen går videre til den næste meddelelse. Selve systemet fortsætter gennem patches, hardwareudskiftning, træning, adgangsgennemgange, opgraderinger, udfasninger, håndtering af hændelser og den gradvise forsvinden af mennesker, der husker, hvorfor en indstilling blev valgt.

ENISA's trusselsbillede placerer kvalifikationsmangel tæt på toppen af sine langsigtede bekymringer. Dette er ikke kun et arbejdsmarkedsproblem. Det er et modstandsdygtighedsproblem. En tjeneste, hvis afhængigheder ikke kan forstås af mere end én person, har et skjult enkeltpunkt for fejl. En organisation kan have ekstra maskiner og stadig mangle evnen til at bruge dem sikkert, fordi runbook'en, byggeprocessen eller datakontrakten lever i én ingeniørs hukommelse. At købe support kan reducere risikoen, men køberen skal stadig forstå nok til at udfordre leverandøren og beslutte, hvornår man skal stoppe.

Vedligeholdelse ændrer også, hvad et præstationsløfte betyder. En benchmark kørt på en udgivelse siger noget om den udgivelse under de angivne betingelser. Den siger ikke, at systemet vil have samme adfærd efter en driveropdatering, en compilerændring, en ny scheduler, en anden lagringssti eller en ny arbejdsbyrde. En nyttig tjeneste holder fast i betingelserne for sine løfter. Den registrerer versioner, input, hardware, politikker og ændringer, så nogen kan gentage en test eller forklare, hvorfor gentagelse ikke længere er mulig.

Der er en menneskelig pris ved at lade som om, vedligeholdelse er et lavere prioriteret anliggende. Operatører udsætter opgraderinger, fordi afhængighedsgrafen er uklar. Sikkerhedsteams kæmper med at afgøre, hvilken pakke der faktisk er i produktion. Indkøb fornyer en kontrakt, fordi ingen har øvet en exit. Forskere kan ikke reproducere et resultat, fordi miljøet har ændret sig. Brugere oplever intermitterende fejl, som tilskrives modellen, fordi tjenesten ikke har et fælles sprog for de underliggende lag. Resultatet er ikke en enkelt dramatisk fejl. Det er en langsom reduktion af tillid.

En vedligeholdelsesplan bør derfor indeholde mere end patchdatoer. Den bør indeholde ejerskabsgennemgange, adgangsudløb, certifikat- og nøglerotation, test af backupgendannelse, gennemgang af afhængigheder, hardwarelivscyklus, leverandørændringsmeddelelser, modelpensionering og den dokumentation, der er nødvendig for hver enkelt. Nogle af disse opgaver kan automatiseres. Ansvaret kan ikke automatiseres væk. Nogen skal beslutte, hvad der tæller som en væsentlig ændring, hvem der modtager signalet, og hvilken myndighed der kan sætte tjenesten på pause.

Den europæiske tilbøjelighed til at nedsætte et udvalg for et vanskeligt problem bliver til tider latterliggjort, ofte uretfærdigt. Et udvalg, der ejer et afhængighedskort, en ændringsregel og en eskaleringsvej, er mere nyttigt end et dashboard, som ingen ejer. Problemet er ikke governance. Problemet er governance, der ikke kan nå maskinen.

Indkøb er, hvor afhængigheder bliver forpligtelser

Kontrakter gør en afhængighed til en forpligtelse. En køber vælger en leverandør, en komponent, en supportordning, en dataplacering, en fornyelsesperiode og en exitbetingelse. Beslutningen kan beskrives som køb af en AI-tjeneste, men køberen køber også leverandørens opdateringsproces, håndtering af hændelser, identitetsmodel, grænsefladestabilitet, dokumentation og evne til at forblive i drift. Det er ikke sekundære funktioner. De afgør, hvor meget myndighed køberen bevarer.

ENISA's advisory group-papir fra 2025 om NIS2-gennemførelse er usædvanligt direkte om dette. Det bemærker, at mindre virksomheder kan falde ind i NIS2-overholdelsesarbejde, fordi de leverer til enheder, der er i scope. Det argumenterer for en europæisk ramme for forsyningskædesikkerhed og indkøb med en basislinje af foranstaltninger og en fælles due diligence-metode. Det opfordrer også til en indkøbsbasislinje med minimumskrav til kontrakter, standardklausuler, tilgange til sikkerhedstest og en enkel måde for en kunde at vurdere leverandører på. Papiret er en rådgivende udtalelse, ikke en regulering. Dets værdi her er, at det navngiver den operationelle friktion, der opstår, når hver køber opfinder en anden version af diligence.

Indkøbsteams behøver ikke at kræve, at enhver leverandør oplyser alle interne detaljer. De skal stille spørgsmål, der forbinder til konsekvens. Hvilke komponenter er essentielle for tjenesten? Hvordan kommunikeres ændringer? Hvordan kan køberen verificere den software og firmware, der er i brug? Hvad sker der, hvis en leverandør eller underleverandør ikke kan levere en komponent? Hvilke data og hvilken dokumentation kan eksporteres? Hvor længe fortsætter supporten, efter en udgivelse er pensioneret? Hvem kan sætte en operation på pause, og hvad sker der med arbejde, der allerede er i gang?

Disse spørgsmål er mindre glamourøse end en demonstration. De er også sværere at forfalske. En leverandør kan vise et flydende svar på ti minutter. Det er sværere at vise en komplet afhængighedsoversigt, en testet gendannelse, en migrationsvej og en person, der er bemyndiget til at sige nej på det rigtige tidspunkt. Køberen bør ikke behandle denne vanskelighed som en grund til at undgå spørgsmålene. Det er grunden til at stille dem, før tjenesten bliver svær at erstatte.

Risikoen ved koncentration fortjener omhyggeligt sprog. En udbredt leverandør er ikke automatisk usikker, og en lille leverandør er ikke automatisk modstandsdygtig. Koncentration bliver en risiko, når én leverandør, softwarepakke, geografisk rute, identitetsmyndighed eller vedligeholdelsesteam bærer større konsekvens, end organisationen kan absorbere. ENISA's fremsynsrapport beskriver grænseoverskridende ICT-tjenesteudbydere som et potentielt enkelt fejlpunkt. Den passende reaktion er ikke at lade som om, koncentration kan elimineres. Det er at identificere, hvor den findes, fastsætte en acceptabel afhængighed og øve, hvad der sker, hvis ruten er utilgængelig.

Exit-klausuler er ofte skrevet som juridisk møblement. En ægte exit-klausul har en teknisk form. Den navngiver formater, grænseflader, hentningsrettigheder, nøgler, logfiler, beviser, support under overgangen, sletningsbekræftelse og den minimale information, der er nødvendig for at genopbygge en tjeneste et andet sted. Den er stærkere, når den er blevet testet på en lille arbejdsbyrde. Testen behøver ikke være teatralsk. En kontrolleret eksport, en gendannelse i et uafhængigt miljø og en sammenligning af den resulterende adfærd kan afsløre mere end flere sider med forsikringer.

Kritisk infrastruktur er et netværk af afhængigheder

Direktivet om kritiske enheders modstandsdygtighed gør et lignende træk på niveauet for væsentlige tjenester. Det definerer modstandsdygtighed som en enheds evne til at forebygge, beskytte mod, reagere på, modstå, afbøde, absorbere, tilpasse sig og komme sig efter en hændelse. Det beskriver kritisk infrastruktur som et aktiv, en facilitet, udstyr, et netværk eller et system, der er nødvendigt for en væsentlig tjeneste. Ordlyden er bevidst bredere end en bygning. Den behandler en tjeneste som et forhold mellem aktiver, mennesker og funktioner.

Direktivet siger, at medlemsstaterne bør overveje tværsektorielle og grænseoverskridende risici, og det peger på voksende indbyrdes afhængigheder mellem infrastruktur og sektorer. Det siger også, at forsyningskædeeffekter bør overvejes, når man vurderer betydningen af en forstyrrende hændelse. Det er vigtigt for AI-infrastruktur, fordi den relevante tjeneste måske slet ikke er mærket som kunstig intelligens. Et datalink, et strømsystem, en identitetstjeneste, et hospitalsjournalsystem eller et forskningsnetværk kan være det lag, der gør en AI-aktiveret tjeneste mulig.

Direktivet er ikke en AI-driftsmanual. Det klassificerer ikke enhver modeltjeneste som kritisk, og det erstatter ikke sektorspecifikke regler. Det leverer en måde at tænke på konsekvens. Hvis et system understøtter en væsentlig tjeneste, er spørgsmålet ikke kun, om modellen har bestået en evaluering. Det er, om enheden kan fortsætte med at levere den væsentlige tjeneste, når en komponent, facilitet, leverandør, netværk eller ekstern betingelse ændrer sig.

NIS2 ligger side om side med dette fysiske og organisatoriske syn med forpligtelser til cybersikkerhedsrisikostyring og hændelsesindberetning for relevante enheder. Det juridiske samspil er specifikt og afhænger af enheden og sektoren. Den generelle lektie er ikke, at et enkelt direktiv løser modstandsdygtighed. Det er, at cyber- og fysiske afhængigheder skal koordineres. Et netværk kan være sikkert mod én type angreb og stadig fejle, når køling ikke er tilgængelig. En facilitet kan have redundant strøm og stadig ikke være i stand til at godkende operatører. En leverandør kan anmelde en softwarehændelse, mens køberen mangler de optegnelser, der er nødvendige for at forstå dens virkning.

Resiliens kræver derfor et ordforråd til forringet service, ikke kun til total nedbrud. Kan systemet acceptere færre forespørgsler? Kan det deaktivere en højrisikofunktion, mens en lavrisikofunktion bevares? Kan det skifte til en mindre model eller en manuel vej? Kan det fortsætte, mens en kø tømmes, og en kilde verificeres? Kan det bevise, hvilket arbejde der blev forsinket eller behandlet igen? Det er operationelle beslutninger. De afgør også, om borgere, forskere og virksomheder oplever en kontrolleret begrænsning eller et mystisk svar, der ankommer, efter at institutionen har mistet konteksten til at gennemgå det.

Det nyttige billede er et netværk, hvis knudepunkter har ejere, og hvis kanter har betingelser. En kant kan være en strømforbindelse, en softwareafhængighed, en kontrakt, en dataoverførsel eller en autoritetsrelation. Et resilient design antager ikke, at hver kant forbliver tilgængelig. Det registrerer kanten, overvåger den betingelse, der betyder noget, og definerer en reaktion, før presset ankommer.

Et illustrativt sammensat eksempel, ikke en hændelsesrapport

Det hjælper at gøre afhængighedsproblemet konkret uden at opfinde et reelt nedbrud. Det følgende er et illustrativt sammensat eksempel. Det beskriver ingen navngiven organisation, leverandør, facilitet, person, dato eller begivenhed. Det er et tankeeksperiment samlet ud fra almindelige infrastrukturrelationer.

Forestil dig en offentlig forskningstjeneste, der lader autoriserede teams indsende et dokument, køre en klassificeringsworkflow og modtage et resultat til menneskelig gennemgang. Tjenesten er hostet på europæisk infrastruktur. Dens model er gemt i et artefaktregister. Kildedokumenterne ligger i et lagringsniveau, og indekset i et andet. En gateway kontrollerer identitet og videresender arbejde til en kø. Arbejdere bruger et containerimage og en hardwaredriver. Resultater skrives til en postbutik og en evidensstrøm. Et dashboard fortæller operationsteamet, om systemet er sundt.

Intet her er usædvanligt. Det er pointen. Skift nu én betingelse ad gangen. Registret ændrer sin signeringspolitik. Driveropdateringen kræver en ny containerruntime. Et certifikat udløber for den tjeneste, der skriver evidens, mens resultatbutikken fortsat accepterer skrivninger. En lagringskvote nås for et afledt indeks, men ikke for kildedokumenterne. En leverandør ændrer en grænseflade, og køforbrugeren forsøger igen en operation, der ikke var designet til at blive gentaget. En dygtig operatør forlader, og runbooken beskriver stadig den tidligere implementering. Ingen af disse ændringer kræver, at en model producerer en falsk sætning. Hver kan ændre tjenestens pålidelighed eller dens evne til at forklare sig selv.

En organisation, der kun overvåger modelnøjagtighed, ser måske ingen advarsel. Testsættet består stadig. En organisation, der overvåger hele tjenesten, vil se forskellige signaler: en verifikationsfejl, et stigende antal forsøg, et hul i evidensstrømmen, en lagringstærskel, en ikke-gennemgået ændring eller en ejerskabsalarm. Signalerne er ikke ækvivalente, og de kræver ikke alle et nedbrud. De kræver en regel om, hvem der beslutter, hvad der sker derefter.

Antag, at teamet vælger at reducere kapaciteten, mens det kontrollerer afhængigheden. Det er ikke et tegn på, at tjenesten har svigtet sit formål. Det kan være et tegn på, at tjenesten har et formål, der er større end gennemløb. Hvis systemet kan bevare kildeoptegnelsen, markere det forsinkede arbejde, forhindre uautoriserede forsøg og give et menneske en klar vej til at inspicere de berørte sager, er det forringet på en kontrolleret måde. Hvis det fortsætter med at producere polerede svar, mens dets evidenssti er brudt, har det bevaret udseendet af service på bekostning af tillid.

Kompositten er bevidst almindelig, fordi spektakulære hændelser gør lektionen for let. Alle forstår, at en oversvømmelse kan afbryde en facilitet. Det sværere arbejde er at erkende, at et udløbet certifikat, en registry uden ejer, en ændret leverandørkontrakt eller en manglende gendannelsestest også kan flytte en tjeneste uden for dens sikre driftsgrænse. Kedelige afhængigheder er ikke mindre årsagsmæssige, fordi de mangler et dramatisk fotografi.

Fejl forplanter sig gennem relationer

Et fejlforplantningskort bør følge relationer frem for teknologietiketter. Start med tjenesteløftet. Hvad forventer brugeren skal ske, og hvad skal forblive sandt for, at den forventning kan indfries? Spor derefter baglæns gennem modellen, runtime, policy gate, identitet, netværk, lagring, hardware, energi, leverandør og institution. Spørg på hvert trin, hvordan fejl ser ud, hvordan den opdages, hvem der ejer håndteringen, og hvilke beviser der er tilbage.

Dette lyder lineært, men rigtige systemer forgrener sig. En model kan være tilgængelig, mens en policy-tjeneste er utilgængelig. En policy kan tillade et kald, mens en identitetspost er forældet. En anmodning kan accepteres, mens en kø ikke kan tømmes. Et resultat kan returneres, mens den post, der er nødvendig for at bestride det, mangler. Et infrastrukturteam kan genoprette tjenesten, mens en dataejer stadig skal beslutte, om det berørte arbejde kan stoles på. Forplantningskortet bør vise disse forgreninger, fordi en enkelt grøn statuslampe ikke kan.

En nyttig måde at tegne kortet på er at adskille fire slags konsekvenser. Tilgængelighed spørger, om arbejdet kan ske. Integritet spørger, om arbejdet og dets poster er uændrede og komplette. Autoritet spørger, om aktøren havde tilladelse til at udføre arbejdet. Gendannelse spørger, om tjenesten kan vende tilbage til en kendt tilstand og forklare, hvad der skete. En afhængighed kan være acceptabel for én dimension og uacceptabel for en anden. En cache kan forbedre tilgængeligheden, mens den er uegnet som den autoritative post. En tredjeparts identitetstjeneste kan være praktisk, mens den gør autoritet svær at inspicere under en forstyrrelse.

Kortet bør også vise tid. Nogle afhængigheder fejler med det samme. Andre driver. En model kan forblive tilgængelig, mens dens understøttende data bliver forældede. En hardwarekomponent kan fungere, mens reservedele bliver umulige at skaffe. En kontrakt kan forblive gyldig, mens en udbyders ændringspolitik langsomt fjerner det interface, som køberen stolede på. Jo senere et signal ankommer, desto dyrere er det at fortolke. Tid er en del af afhængigheden, ikke en note i hændelsesrapporten.

Driftsteams kalder ofte dette for observerbarhed. Det ord er kun nyttigt, når det peger på en handling. En graf, der ser sund ud, fortæller ikke nogen, hvilken autoritet de har, hvilken ændring der fik grafen til at bevæge sig, eller hvilke beviser der bør bevares. Formålet med et fejlkort er at gøre en beslutning mulig. Hvis bevisstrømmen er ufuldstændig, så sæt den berørte handling på pause. Hvis modelregistret ikke kan verificere en artefakt, så fremmér den ikke. Hvis en leverandør ændrer en komponent uden for den testede grænse, så gentag den relevante evaluering. Hvis en gendannelsestest ikke kan gendanne posten, så kald ikke sikkerhedskopien for en gendannelsesplan.

Der er ingen universel tærskel for disse beslutninger. Et forskningseksperiment, en offentlig tjeneste og en sikkerhedskritisk arbejdsgang har forskellige tolerancer. Det vigtige er, at tærsklen tilhører tjenestejeren, er synlig for operatører og kan revideres, når beviser ændrer sig. Ellers vil tærsklen blive sat af den første person, der opdager fejlen, hvilket er en bemærkelsesværdig demokratisk måde at drive et system på og en dårlig måde at styre et på.

En afhængighed behøver ikke at ødelægge modellen for at ændre, hvad tjenesten sikkert kan hævde.

Mål kapacitet uden at skjule nævneren

Infrastruktur indbyder til imponerende tal. Exaflops, petabyte, processortal, investeringsbeløb og antallet af faciliteter i et program beskriver alle noget reelt. Ingen af dem er tjenesten i sig selv. Et tal bliver nyttigt, når dets nævner og betingelser er synlige.

Peak computing-ydelse fortæller ikke en forsker, hvor hurtigt en bestemt arbejdsbyrde vil få en partition, flytte sine data, fuldføre en kørsel eller hente resultatet. Antallet af AI Factories fortæller ikke en lille virksomhed, om dens applikation vil få adgang under de betingelser, den har brug for. Et halvlederinvesteringsbeløb fortæller ikke en operatør, hvilken komponent der vil være tilgængelig under en mangel. En høj tilgængelighedsprocent fortæller ikke en offentlig institution, om den kan hente evidensen for en omstridt beslutning.

En ansvarlig kapacitetsbeskrivelse parrer derfor overskriften med stien bag den. Navngiv hardware- og softwaregrænsen. Angiv, om tallet er peak, vedvarende, planlagt eller observeret. Beskriv arbejdsbyrden, adgangsmodellen og undtagelserne. Sig, hvilke afhængigheder der er uden for målingen. Hold kravet knyttet til den frigivelse, hardware, datasæt og politik, som det blev fremsat under. Målet er ikke at gøre hver side ulæselig. Det er at gøre de vigtige sider kontrollerbare.

Denne disciplin forbedrer også den offentlige argumentation. Europa behøver ikke at vælge mellem ambition og forsigtighed. Det kan bygge store faciliteter, finansiere ambitiøs forskning og stadig sige, hvor evidensen stopper. Et offentligt system, der navngiver sine begrænsninger, er mere troværdigt end et, der præsenterer et rent tal uden nogen vej til at inspicere det. Begrænsningen kan være en kø, en grænseflade, en leverandør, et kompetencegab, en strømgrænse eller en juridisk grænse. At navngive den gør ikke kapaciteten mindre. Det fortæller folk, hvilken slags kapacitet det er.

Usikkerhed er ikke en indrømmelse af nederlag. Det er et vedligeholdelsessignal. Hvis ingen ved, hvordan en leverandørs ændring vil påvirke en arbejdsbyrde, er næste skridt en test eller en eksplicit antagelse, ikke et større adjektiv. Hvis et register ikke kan skelne en modelfrigivelse fra en serveringskonfiguration, er næste skridt en bedre optegnelse. Hvis en institution ikke kan sige, hvilken person der kan stoppe en operation, er næste skridt et autoritetskort. Præcision er en måde at beslutte, hvad der skal repareres.

De stille lag er hvor suverænitet bliver praktisk

Europæisk suverænitet diskuteres nogle gange, som om det var et flag, der er placeret oven på et datacenter. En tjeneste kan være placeret inden for Unionen og stadig afhænge af eksterne komponenter, udenlandsk juridisk rækkevidde, proprietære grænseflader, knappe kompetencer eller en leverandør, hvis ændringsbeslutninger ikke kan udfordres. Placering er ét input til en suverænitetsvurdering. Praktisk kontrol afhænger af hele kæden.

Chips Act'ens fokus på at forstå den globale halvlederforsyningskæde, CER-direktivets opmærksomhed på tværsektorielle afhængigheder og ENISA's advarsler om softwareafhængigheder og enkeltpunkter, der kan svigte, peger alle i samme retning. Suverænitet er ikke en enkelt kontakt. Det er evnen til at forstå, hvad en tjeneste afhænger af, at beslutte, hvilken afhængighed der er acceptabel, at erstatte eller begrænse den, når det er nødvendigt, og at bevare tilstrækkelig dokumentation til at forsvare beslutningen.

Den evne kan bygges op på små måder. En offentlig forskningsgruppe kan føre en fortegnelse over den runtime, driver og dataudgivelse, der blev brugt til et resultat. Et indkøbsteam kan kræve en testet eksportvej frem for et løfte om portabilitet. Et driftsteam kan definere en nedgraderet tilstand og øve sig i den. En tilsynsmyndighed kan spørge, hvilke registreringer der ville være tilgængelige efter et leverandørskifte. En leverandør kan offentliggøre grænsen for sin support og betingelserne for, hvornår en opdatering ændrer adfærd. Ingen af disse handlinger gør et system autonomt. De gør det mindre mystisk.

Hos Dweve er dette den snævre grund til, at vi bekymrer os om åbne fundamenter og de stille dele omkring dem. Projekter som Core og Mesh er kun nyttige, når de befinder sig inden for en ærlig operationel grænse med klare registreringer, autoritet og begrænsninger. De er ikke en erstatning for europæisk infrastruktur, offentlige institutioner eller forsyningskædepolitik, og denne artikel hævder ikke, at de løser disse problemer. Positionen er mindre: en åben komponent er lettere at inspicere, erstatte og undervise i, når dens kontrakter er eksplicitte. Det er én mursten, ikke hele bygningen.

Bygningen betyder noget, fordi folk møder den øverste etage og lever med fundamentet. Svaret på skærmen kan være flydende, men tjenestens reelle karakter bestemmes af de lag, der afgør, hvor svaret kom fra, hvem der kunne ændre det, hvad der sker, når en afhængighed flytter sig, og om nogen kan forklare resultatet senere.

Byg det system, folk stadig kan se

Det vigtigste AI-system kan være det, ingen ser, fordi det er distribueret på tværs af steder, der aldrig er blevet kaldt AI. Det er chipfaciliteten og kølesløjfen. Det er supercomputeren og planlæggeren. Det er pakkeregistret, identitetsudbyderen, lagringspolitikken, netværksruten og vedligeholdelsesplanen. Det er kontrakten, der siger, hvad der sker, når en leverandør ændrer en komponent. Det er institutionen, der kan sætte en arbejdsgang på pause, før et svagt signal bliver en offentlig fejl.

Intet af dette reducerer vigtigheden af modelkvalitet. Det giver modelkvalitet et sted at have betydning. En model kan kun tjene et menneske gennem et system, der kan modtage inputtet, udføre arbejdet, bevare den relevante registrering og returnere resultatet med tilstrækkelig kontekst til, at nogen kan stole på eller udfordre det. Modellen er en vigtig komponent i det system. Den er ikke et land, en forsyningskæde, en genopretningsplan eller en person med autoritet til at reparere de dele, den ikke kan se.

Europas infrastrukturprogrammer er en mulighed for at gøre disse afhængigheder synlige, mens kapaciteten bygges op. Muligheden er praktisk. Offentliggør grænseflader og driftsgrænser. Finansier vedligeholdelse og kompetencer sammen med udstyr. Behandl indkøb som en designbeslutning. Forbind cybersikkerhed med fysisk modstandsdygtighed. Giv mindre organisationer en vej til at bruge offentlig infrastruktur uden at tvinge dem til at blive specialister i hvert lag. Mål adgang, genopretning og dokumentation lige så omhyggeligt som topydelse.

Der er en særlig europæisk glæde ved at opdage, at svaret på et stort teknologispørgsmål er en fortegnelse, en driftsmanual og en person, der har lov til at standse maskinen. Det er ikke glamourøst, men det har den fordel, at det overlever kontakt med tirsdag. Når det skjulte system er synligt nok til at blive inspiceret, kan modellen udføre sit arbejde uden at bære en myte, som den aldrig var bygget til at bære.

Kilder