Det viktigaste AI-systemet kan vara det ingen ser

Modellen är det synliga lagret. Europas verkliga AI-förmåga beror på chippen, beräkningskraften, nätverken, registren, kontrakten och människorna under den.

Det viktigaste AI-systemet kan vara det ingen ser

Maskinen bakom svaret

Europas första exascal-superdator är ingen metafor. JUPITER är ett verkligt system vid Forschungszentrum Jülich, som drivs av Jülich Supercomputing Centre. EuroHPC Joint Undertaking beskriver dess direktvätskekylda BullSequana-arkitektur, en 20-petabyte ultrasnabb flashpartition och en design avsedd för krävande simuleringar och beräkningsintensiv artificiell intelligens. Beskrivningen är full av de detaljer som gör ett system möjligt: en processorarkitektur, en lagringsnivå, en kylmetod, en driftorganisation och en åtkomstväg. Modellen som så småningom kan köras ovanpå är bara en del av meningen.

Den distinktionen är lätt att tappa bort eftersom den synliga delen av AI är ett svar. En person ställer en fråga, en modell returnerar text och skärmen ger intrycket att intelligensen anlände i ett enda paket. Det dolda arbetet är mindre filmiskt. Elektricitet måste nå byggnaden. Komponenter måste anlända i rätt skick. En firmware-avbildning måste vara betrodd. Nätverk måste bära data mellan processorer och lagring. Identitet måste fastställa vilken person eller tjänst som får använda vilken resurs. En schemaläggare måste hitta kapacitet. Ett register måste berätta för en operatör vilken modell, vilken container och vilken datarelease som används. Övervakning måste märka att systemet har förändrats. Någon måste fortfarande veta hur man reparerar det en regnig tisdag när leverantörsdokumentationen har fått ett nytt versionsnummer och den enda person som förstod det gamla är på semester.

Det viktiga AI-systemet kan därför vara det som ingen ser. Det är leveranskedjan, elkontraktet, nätverksväven, underhållsplanen, beroendeträdet för programvara, inköpsbeslutet och det institutionella minnet som gör att en modell kan användas utan att man låtsas att modellen är hela tjänsten. När det dolda systemet är svagt gör inte en mer kapabel modell tjänsten starkare. Det ger det svaga systemet ett mer imponerande sätt att misslyckas.

Detta är inte ett argument mot modeller eller stora offentliga datorprogram. Det är ett argument för att beskriva dem ärligt. Europa bygger kapacitet genom Chips Act, EuroHPC och AI Factories-programmet. Kommissionens policy-sidor talar om strategiska beroenden, motståndskraft i leveranskedjan, tillgång för mindre företag och den infrastruktur som krävs för tillförlitlig AI. Det är infrastrukturfrågor, inte varumärkesfrågor. Om kontinenten vill ha användbar kapacitet snarare än en samling imponerande demonstrationer måste den behandla de tysta lagren som en del av kapaciteten.

Svaret är det översta lagret. Tjänsten är beroende av varje lager under det.

En modell är en komponent, inte ett land

Offentlig diskussion använder ofta en modell som en synonym för en hel förmåga. Ett land har en modell, ett företag har en modell, en avdelning har en modell, och modellen behandlas som om den bar med sig sin egen leveranskedja. Det gör den inte. En modell har en fil, parametrar, en körningsmiljö och en uppsättning antaganden om det arbete den förväntas utföra. Tjänsten runt omkring bär resten av förpliktelserna.

Betrakta ett enkelt system som klassificerar inkommande dokument innan ett team av människor granskar dem. Det behöver en ingångskanal, en kö, en parser, lagring, åtkomstkontroll, en körningsmiljö för modellen, en lagringsplats för resultat, en väg för aviseringar, ett sätt att rulla tillbaka en version och en logg över vad som hände. Klassificeraren kan vara träffsäker på sin testuppsättning och ändå vara oanvändbar om parsern tappar ett fält, om identitetssystemet ger fel roll, om modellcontainern inte kan hämtas, eller om operatören inte kan avgöra vilken version som låg bakom en rekommendation. Ingen av dessa brister är modellhallucinationer. Det är brister i tjänsten som gjorde modellen relevant.

Det motsatta felet är lika vanligt. Team beskriver en hel tjänst som motståndskraftig för att modellen har utvärderats, medan beroendena lämnas utanför utvärderingens gränser. Ett modelltest kan kontrollera utdata för en utvald arbetsbelastning. Det kontrollerar sällan om ett certifikat löper ut samtidigt som ett mjukvaruregister ändrar sin signeringsnyckel, om en lagringsnivå har tillräcklig kapacitet för ett ovanligt långt dokument, eller om en person kan hämta källposten efter att en leverantör ändrar ett applikationsprogrammeringsgränssnitt. Dessa frågor hör till det operativa systemet. De är ändå en del av vad en användare upplever som AI.

Den användbara frågan är inte om en modell är bra i isolering. Det är vilka andra saker som måste stämma innan modellens utdata kan litas på, och vem som har befogenhet att åtgärda dessa saker. Den frågan flyttar samtalet från en modellkatalog till en systemgräns. Den skapar också en mindre smickrande men mer användbar inventering.

  • Vilka fysiska resurser måste förbli tillgängliga?
  • Vilka program- och fastvarukomponenter måste anlända intakta och förbli understödda?
  • Vilka identitets-, nätverks-, lagrings- och registertjänster måste svara?
  • Vilken organisation är ansvarig när beroendet ändras?
  • Vilka bevis låter en annan person kontrollera svaret senare?
  • Proposal for the Chips Act 2.0, Europeiska kommissionen, 3 juni 2026.

Dessa frågor är inte teoretiska. De är skillnaden mellan en förmåga som kan drivas och en förmåga som kan demonstreras en gång. Demonstrationer är trevliga. Viktiga tjänster måste överleva nästa underhållsfönster.

Leveranskedjor finns inom systemgränsen

ENISA:s arbete med leveranskedjans integritet börjar med en föga smickrande iakttagelse: regeringar, organisationer, företag och konsumenter är i allt högre grad beroende av IKT-produkter och tjänster, och därmed av de leveranskedjor som levererar dem. Dess rapport namnger hot som sträcker sig från manipulering under utveckling, distribution eller drift till ersättning med förfalskade eller klonade komponenter. Poängen är bredare än en säkerhetschecklista. Det som levereras är inte bara en låda. Det är en sekvens av människor, kod, komponenter, kontrakt och beslut genom vilka lådan blir tillräckligt betrodd för att användas.

En AI-tjänst ärver den sekvensen. En träningskörning beror på en basavbild, en kompilator, en drivrutin, en kärna, en schemaläggare och en källdatauppsättning. En inferenstjänst beror på samma lager plus en serveringsmiljö, ett index, en policygrind och ett gränssnitt som kan fortsätta fungera när trafiken inte liknar testuppsättningen. En offentlig institution kan köpa en tjänst snarare än någon av dessa delar, men den dolda kedjan försvinner inte för att kontraktet kallar den en plattform.

ENISA:s framtidsrapport från 2024 placerar kompromettering av programvaruleveranskedjan högst på listan över cybersäkerhetshot inför 2030. Rapporten lyfter också kompetensbrist, mänskliga fel i cyberfysiska ekosystem, gränsöverskridande IKT-leverantörer som en enda felpunkt samt den fysiska påverkan som miljöstörningar kan ha på kritisk digital infrastruktur bland de främsta orosmomenten. Detta är inte påståenden om att varje AI-projekt kommer att drabbas av alltihop. Det är en påminnelse om att hotytan består av relationer. En patch, en leverantör, en person och en översvämning kan alla påverka samma tjänst, även om de förekommer i olika riskregister.

Samma rapports språkbruk är användbart eftersom det motsätter sig fantasin att cyberrisk bara tillhör säkerhetsteamet. En beroende kan komprometteras i programvara, men konsekvenserna kan komma genom en fysisk process, ett inköpsval eller en kompetensbrist. En tjänst kan bli en enda felpunkt för att dess leverantör är tekniskt utmärkt och allmänt använd. Koncentration är inte detsamma som inkompetens. Det är en egenskap hos nätverket kring en tjänst.

Detta skapar ett praktiskt avgränsningsproblem. Om en organisation bara utvärderar modellen och dess omedelbara körtidsmiljö kan resultatet vara korrekt för den valda avgränsningen men missvisande för den tjänst som faktiskt drivs. Om den utvärderar varje leverantör med samma intensitet blir resultatet ett kalkylblad som ingen kan underhålla. Svaret är en beroendekarta som följer konsekvenserna. Identifiera vad som kan förändra en utdata, avbryta en tjänst, radera bevis, utöka behörighet eller förhindra återställning. Fråga sedan om beroendet är tillräckligt synligt för att övervakas och om det finns en annan väg.

Den kartan bör inkludera vanliga material. En server kräver minne, lagringsenheter, strömomvandling, kylutrustning och reservdelar. Ett nätverk kräver optiska komponenter, switchar, routingprogramvara och personer som känner till topologin. En programvaruleveranskedja kräver underhållare, bygginfrastruktur, paketregister, signeringsnycklar och releaseprocesser. Inget av detta blir mindre viktigt för att produktbroschyren säger artificiell intelligens.

Det är frestande att svara med en längre leverantörsenkät. En enkät kan vara användbar, men den är inte en beroendekarta. Den registrerar vad en leverantör säger vid en tidpunkt. Den operativa frågan är om köparen kan märka en förändring, tolka den och vidta en proportionerlig åtgärd. En lista över certifikat är inte en ersättning för att veta vilken komponent som skulle stoppa tjänsten om den försvann i morgon bitti. Europeiska organisationer är beundransvärt bra på att samla in dokument. Den svårare konsten är att få dokumenten att peka mot ett beslut.

Kretsar gör det osynliga fysiskt

Den europeiska kretsförordningen slår fast ett faktum som borde vara självklart men ändå behöver sägas: halvledare är byggstenar för elektroniska produkter och centrala för sektorer från kommunikation och databehandling till hälsovård, energi, transport och industriell automation. Förordningen trädde i kraft i september 2023 och anger mål som att stärka forskning och tekniskt ledarskap, förstärka kapaciteten för design, tillverkning och paketering, åtgärda kompetensbrist och utveckla en djupare förståelse för den globala halvledarleveranskedjan.

Den listan är viktig för AI eftersom beräkningskapacitet inte skapas av en molnlogotyp. Den skapas av en kedja av designer, skivor, utrustning, paketering, testning, strömförsörjning, kylning, nätverk och underhåll. En brist eller försening i en del kan förändra vad ett datacenter kan leverera även när modellfilerna är klara. Om en komponent har lång ledtid kan operatören inte lösa problemet med en smart prompt. Om ett fastvaruberoende inte kan uppdateras säkert kan valet stå mellan en kontrollerad nedtrappning av tjänsten och ett osäkert försök att hålla allt igång.

Kommissionens översikt redovisar Chipsaktens tre pelare. Den första stöder kapacitetsuppbyggnad och innovation, inklusive pilotlinjer och kompetenscentrum. Den andra rör försörjningstrygghet och motståndskraft genom tillverkning, avancerad paketering, testning och montering. Den tredje skapar mekanismer för övervakning och krishantering, inklusive en europeisk halvledarstyrelse som kartlägger och övervakar värdekedjan och samordnar insatser vid halvledarkriser. Den institutionella utformningen är en välkommen korrigering av föreställningen att suveränitet innebär att man tillverkar varje komponent inom landet. Motståndskraft handlar dels om kapacitet, dels om synlighet, dels om förmågan att agera när ett beroende förändras.

Sidan ger också konkreta exempel på godkända anläggningar av sitt slag i Catania, Crolles, Dresden, Novara, Premstätten, Milano och andra europeiska orter. Dessa poster är inte bevis för att Europa har löst halvledarproblemet. De är bevis för att värdekedjan har fysiska platser, tekniker och investeringsbeslut som kan namnges. Att namnge dem förändrar samtalet. Det gör det möjligt att fråga vilken förmåga varje anläggning tillför, vilka insatsvaror den fortfarande är beroende av, vilka kompetenser den behöver och hur den skulle stödjas vid en störning.

Kommissionens förslag till en Chipsakt 2.0, som publicerades i juni 2026, anger att unionen fortfarande är beroende av tredjeländer inom viktiga områden som avancerad chiptillverkning och halvledardesign. För en artikel daterad den 31 juli är detta ett aktuellt policyuttalande, inte en förutsägelse om ett framtida lagförslag. Den praktiska innebörden är enkel: en europeisk tjänst kan vara värd i Europa och ändå vara beroende av en global kedja där de viktigaste besluten fattas någon annanstans. Fysisk placering är värdefull. Den är inte detsamma som kontroll.

AI-politik kan bli mer seriös om den lånar detta fysiska ordförråd. Fråga inte om en modell är europeisk, fråga i stället vilka delar av tjänsten som kan repareras, bytas ut, inspekteras och pausas inom europeiska institutioner. Fråga inte om en leverantör har en europeisk region, fråga i stället hur hårdvara, firmware, programvaruberoenden och operativ behörighet rör sig genom tjänsten. Svaret kommer att vara stökigt. Det är bra. Stökiga kartor är ofta de första ärliga.

Beräkningskraft är en offentlig förmåga

EuroHPC är ett användbart exempel eftersom det gör beräkningsinfrastruktur synlig utan att göra den till en konsumentprodukt. Den offentliga listan anger att det gemensamma företaget har upphandlat tolv toppmoderna superdatorer runt om i Europa. Listan namnger system och värdar: JUPITER på Forschungszentrum Jülich i Tyskland, LUMI i Kajaani, Leonardo i Bologna, MareNostrum 5 i Barcelona, Karolina i Ostrava och Arrhenius vid Linköpings universitet, bland andra. Platserna är mindre intressanta som en rankinglista än som en påminnelse om att beräkningskraft är inbäddad i institutioner, byggnader, personal, elsystem, lagring och forskningsprogram.

JUPITER beskrivs som Europas första exaskala-superdator, med en direktvätskekyld arkitektur, en flashpartition på 20 petabyte och en klustermodul som använder SiPearl Rhea1-processorn tillsammans med en GPU-accelererad booster. LUMI:s sida beskriver separata partitioner för CPU, GPU, dataanalys och container-moln, med ett lagringssystem som kombinerar flash, ett parallellt filsystem och en datahanteringstjänst. Dessa detaljer är inte bara trivia för ingenjörer. De säger en policyläsare att en superdator är en uppsättning resurser med olika former. En arbetsbelastning som passar en partition passar inte nödvändigtvis en annan. Åtkomst, schemaläggning och dataförflyttning är en del av förmågan.

MareNostrum 5, som drivs av Barcelona Supercomputing Center, och Arrhenius, som installeras vid Linköpings universitet och drivs av Nationell akademisk infrastruktur för superdatorer i Sverige, visar samma sak på olika sätt. En distribuerad europeisk kapacitet är inte en enda gigantisk maskin. Det är en uppsättning system med olika processorer, lagringslösningar, operatörer, åtkomstregler och forskarsamhällen. Nätverket mellan dem spelar roll, men det gör även skarvarna.

Kommissionens politik för AI-fabriker beskriver ett program som bygger på den verkligheten. AI-fabriker använder EuroHPC:s superdatorkapacitet för att utveckla avancerad generativ AI och kopplar samman beräkningscentrum, universitet, små och medelstora företag, industri och finansiella aktörer. Sidan säger att vid tidpunkten för uppdateringen i april 2026 var nitton AI-fabriker och tretton antenner i drift, med minst nio nya AI-optimerade superdatorer planerade. Den beskriver också en långsiktig investering på tio miljarder euro genom EuroHPC under 2021 till 2027. Detta är institutionella arrangemang, inte en garanti för att varje projekt får den kapacitet det vill ha eller att varje modell är tillförlitlig.

Värdet av sådana arrangemang handlar inte bara om hastighet. Offentlig beräkningskapacitet kan skapa en plats där europeiska forskare och företag kan köra arbetsbelastningar under regler och åtkomstarrangemang som är synliga för offentliga institutioner. Det kan stödja experiment som annars skulle prissättas bortom räckhåll, och det kan göra viss kunskap reproducerbar mellan olika platser. Det kan också introducera nya beroenden om ett program förlitar sig på ett litet antal leverantörer, en enda programvarustack eller en arbetskraft som inte kan ersättas. Offentligt ägande av en anläggning tar inte bort det operativa arbetet. Det gör ansvaret svårare att dölja, vilket är hälsosammare.

När beräkningskapacitet blir offentlig förmåga bör dess framgång mätas bortom topprestanda. Kan en mindre forskargrupp få åtkomst? Kan en känslig arbetsbelastning separeras från en generell? Kan en operatör visa vilken programvara och hårdvara som användes? Kan ett team flytta en arbetsbelastning när en partition är full eller ett beroende avvecklas? Kan en offentlig myndighet förklara under vilka villkor en modell tränades? En snabb maskin som inte kan svara på dessa frågor är fortfarande användbar för viss vetenskap, men den är ännu inte en komplett grund för offentlig AI.

Nätverk, lagring och identitet gör det tysta arbetet

De viktigaste lagren är ofta de som inte syns i ett AI-diagram. Ett diagram ritar en modell mellan en inmatning och en utmatning. En operatör ser en kedja av nätverksvägar, lagringsklasser, identitetsbekräftelser, köer, certifikat, register, hemligheter, observerbarhetspipelines och ändringskontroller. Diagrammet är inte fel. Det är ofullständigt på precis det sätt som ger dyra överraskningar.

Börja med nätverket. En stor modelltjänst kan flytta data mellan acceleratorer, minne, lagring och andra tjänster. En offentlig forskningsarbetsbelastning kan flytta datamängder till en superdator och resultat tillbaka till ett universitet. Ett produktionsflöde kan korsa en policygräns innan det når en modell och en annan gräns innan det returnerar ett beslut. Latens, paketförlust, routingändringar och underhåll kan förändra hela tjänstens beteende utan att en enda parameter i modellen ändras. En timeout kan bli ett nytt försök, ett nytt försök kan bli dubbelt arbete, och dubbelt arbete kan bli en felaktig post. Modellen bestämde sig inte för att försöka igen. Det gjorde det omgivande systemet.

Lagring har sin egen dolda grammatik. Det finns källposten, den transformerade posten, indexet, cachen, loggen, säkerhetskopian, raderingsmarkeringen och beviset som visar vilken version som användes. En tjänst kan kanske besvara en fråga men ändå inte kunna bevisa vilka data som gjorde svaret möjligt. Bevarande och återhämtning är inte spegelbilder av varandra. Att behålla allt för evigt kan strida mot en ändamålsbegränsning; att radera källan men lämna kvar ett derivat eller en cache kan skapa ett annat problem. En seriös datagräns anger vad som lagras, hur länge, av vem och hur en senare granskare kan se att gränsen har respekterats.

Identitet är inte en inloggningsskärm. Det är mekanismen som ger en person, tjänst eller agent behörighet att utföra en åtgärd. Om en inferensslutpunkt kan anropa ett verktyg måste systemet veta vilken huvudman som frågade, vilken policy som tillät anropet och vad verktyget fick röra. Om ett register tillåter att en container befordras måste det veta vem som kan godkänna befordran och vilka bevis som krävs. Om ett certifikat förnyas automatiskt måste tjänsten ändå ha ett sätt att upptäcka att identitetsrelationen har förändrats. En hemlighet som förblir giltig efter att personen som begärde den har slutat är ett underhållsproblem med en säkerhetskonsekvens.

Register är minnet av ett rörligt system. Ett modellregister kan innehålla versioner och metadata. Ett artefaktregister kan innehålla containrar, paket eller signerade releaser. Ett dataregister kan beskriva scheman och ägarskap. En hårdvaruinventering kan identifiera ett kort, firmwareversion och utbytesstatus. Poängen är inte att skapa ett register för allt. Poängen är att göra den auktoritativa källan för varje påstående explicit. Om inget system kan svara på vilken modell, drivrutin, dataversion och policyversion som var aktiva, tvingas en senare granskning att sluta sig till historien utifrån de loggar som överlevde.

Observerbarhet sluter cirkeln. Mätvärden talar om för en operatör att en kö har vuxit eller att en enhet är varm. Spår visar vilken väg en begäran tog. Loggar bär kontext, även om de är lätta att missförstå. Händelser och attesteringar kan bevara beslut och förändringar. Dessa objekt har olika uppgifter. Att behandla dem som utbytbara ger antingen brus eller en falsk känsla av bevis. Designfrågan är vad en person måste veta när tjänsten är sen, felaktig, otillgänglig eller ifrågasatt, och vilken post som kan besvara den frågan utan ett rekonstruktionsarbete.

Man kan beskriva detta som tråkig ingenjörskonst. Det är ingen förolämpning. Tråkig ingenjörskonst är den del som fortsätter att fungera efter att lanseringsinlägget har flyttats ner på startsidan. Det är också den del som avgör om en ny modell kan införas utan att skriva om institutionen runt den.

Underhåll är en förmåga, inte en kostnadspost

Infrastrukturberättelser slutar gärna vid driftsättningen. Det är då arbetet blir en tjänst. En modell släpps, ett kluster tas i drift, en fabrik öppnar, ett kontrakt skrivs under och berättelsen går vidare till nästa tillkännagivande. Själva systemet fortsätter genom uppdateringar, hårdvarubyten, utbildning, åtkomstgranskningar, uppgraderingar, avvecklingar, incidenthantering och den gradvisa försvinnandet av personer som minns varför en inställning valdes.

ENISA:s hotbild placerar kompetensbrist nära toppen av sina långsiktiga farhågor. Detta är inte bara en arbetsmarknadsfråga. Det är en motståndskraftsfråga. En tjänst vars beroenden inte kan förstås av mer än en person har en dold enskild felpunkt. En organisation kan ha reservmaskiner men ändå sakna förmågan att använda dem säkert, eftersom runbooken, byggprocessen eller datakontraktet lever i en enda ingenjörs minne. Att köpa support kan minska risken, men köparen behöver ändå tillräcklig förståelse för att kunna utmana leverantören och besluta när det är dags att sluta.

Underhåll förändrar också vad ett prestandapåstående innebär. En benchmark som körs på en viss version säger något om just den versionen under de angivna förhållandena. Den säger inte att systemet kommer att uppföra sig på samma sätt efter en drivrutinsuppdatering, en kompilatorändring, en ny schemaläggare, en annan lagringsväg eller en ny arbetsbelastning. En användbar tjänst upprätthåller villkoren för sina påståenden. Den registrerar versioner, indata, hårdvara, policyer och ändringar så att någon kan upprepa ett test eller förklara varför upprepning inte längre är möjlig.

Det finns en mänsklig kostnad i att låtsas att underhåll är en fråga av lägre ordning. Operatörer skjuter upp uppgraderingar eftersom beroendegrafen är otydlig. Säkerhetsteam har svårt att avgöra vilket paket som faktiskt är i produktion. Inköp förnyar ett avtal eftersom ingen har övat på ett utträde. Forskare kan inte reproducera ett resultat eftersom miljön har drivit. Användare stöter på intermittenta fel som skylls på modellen eftersom tjänsten saknar ett gemensamt språk för lagren under den. Resultatet är inte ett enda dramatiskt misslyckande. Det är en långsam minskning av förtroendet.

En underhållsplan bör därför omfatta mer än patchdatum. Den bör omfatta ägarskapsgranskningar, utgångna behörigheter, certifikat- och nyckelrotation, tester av återställning från säkerhetskopior, beroendegranskning, hårdvarans livscykel, leverantörsändringsmeddelanden, modellpensionering och den dokumentation som behövs för varje del. Vissa av dessa uppgifter kan automatiseras. Ansvaret kan inte automatiseras bort. Någon måste besluta vad som räknas som en väsentlig ändring, vem som tar emot signalen och vilken instans som kan pausa tjänsten.

Den europeiska instinkten att skapa en kommitté för ett svårt problem hånas ibland, ofta oförtjänt. En kommitté som äger en beroendekarta, en ändringsregel och en eskaleringsväg är mer användbar än en instrumentpanel som ingen äger. Problemet är inte styrning. Problemet är styrning som inte når maskinen.

Inköp är där beroenden blir åtaganden

Kontrakt förvandlar ett beroende till ett åtagande. En köpare väljer leverantör, komponent, supportavtal, dataplats, förnyelseperiod och utträdesvillkor. Beslutet kan beskrivas som att köpa en AI-tjänst, men köparen köper också leverantörens uppdateringsprocess, incidenthantering, identitetsmodell, gränssnittsstabilitet, dokumentation och förmåga att förbli i verksamhet. Det är inte sekundära funktioner. De avgör hur mycket kontroll köparen behåller.

ENISA:s rådgivande grupp från 2025 om NIS2-genomförandet är ovanligt rakt på sak i denna fråga. Den noterar att mindre företag kan hamna i NIS2-efterlevnadsarbete eftersom de levererar till enheter som omfattas. Den argumenterar för ett europeiskt ramverk för leveranskedjesäkerhet och inköp med en baslinje av åtgärder och en gemensam metod för due diligence. Den efterlyser också en inköpsbaslinje med minimikrav på kontrakt, standardklausuler, metoder för säkerhetstestning och ett enkelt sätt för kunder att bedöma leverantörer. Dokumentet är ett rådgivande yttrande, inte en förordning. Dess värde här är att det namnger den operativa friktion som uppstår när varje köpare uppfinner en egen version av due diligence.

Inköpsavdelningar behöver inte kräva att varje leverantör avslöjar alla interna detaljer. De behöver ställa frågor som kopplar till konsekvens. Vilka komponenter är nödvändiga för tjänsten? Hur kommuniceras ändringar? Hur kan köparen verifiera programvaran och fast programvara som används? Vad händer om en leverantör eller underleverantör inte kan tillhandahålla en komponent? Vilka data och vilken dokumentation kan exporteras? Hur länge fortsätter supporten efter att en version har pensionerats? Vem kan pausa en operation, och vad händer med arbete som redan pågår?

Dessa frågor är mindre glamorösa än en demonstration. De är också svårare att fejka. En leverantör kan visa ett flytande svar på tio minuter. Det är svårare att visa en komplett beroendeinventering, en testad återställning, en migreringsväg och en person som är behörig att säga nej vid rätt tillfälle. Köparen bör inte behandla denna svårighet som ett skäl att undvika frågorna. Det är skälet till att ställa dem innan tjänsten blir svår att ersätta.

Risken med koncentration förtjänar ett noggrant språkbruk. En allmänt använd leverantör är inte automatiskt osäker, och en liten leverantör är inte automatiskt motståndskraftig. Koncentration blir en risk när en leverantör, programvaruregister, geografisk väg, identitetsutfärdare eller underhållsteam bär mer konsekvens än organisationen kan absorbera. ENISA:s framsynsrapport beskriver gränsöverskridande IKT-tjänsteleverantörer som en potentiell enda felpunkt. Det lämpliga svaret är inte att låtsas att koncentration kan elimineras. Det är att identifiera var den finns, fastställa en acceptabel beroendenivå och öva på vad som händer om vägen inte är tillgänglig.

Utgångsklausuler skrivs ofta som juridisk möbel. En verklig utgångsklausul har en teknisk form. Den namnger format, gränssnitt, hämtningsrättigheter, nycklar, loggar, bevis, stöd under övergången, raderingsbekräftelse och den minimiinformation som behövs för att återuppbygga en tjänst på annan plats. Den är starkare när den har testats på en liten arbetsbelastning. Testet behöver inte vara teatraliskt. En kontrollerad export, en återställning i en oberoende miljö och en jämförelse av det resulterande beteendet kan avslöja mer än flera sidor av försäkringar.

Kritisk infrastruktur är ett nätverk av beroenden

Direktivet om kritiska entiteters resiliens gör ett liknande drag på nivån för samhällsviktiga tjänster. Det definierar resiliens som en entitets förmåga att förebygga, skydda mot, bemöta, motstå, mildra, absorbera, anpassa sig till och återhämta sig från en incident. Det beskriver kritisk infrastruktur som en tillgång, anläggning, utrustning, nätverk eller system som är nödvändigt för en samhällsviktig tjänst. Formuleringen är medvetet bredare än en byggnad. Den behandlar en tjänst som en relation mellan tillgångar, människor och funktioner.

Direktivet säger att medlemsstaterna bör beakta sektorsövergripande och gränsöverskridande risker, och det pekar på växande ömsesidiga beroenden mellan infrastruktur och sektorer. Det säger också att effekter på leveranskedjan bör beaktas när man bedömer betydelsen av en störande incident. Detta är relevant för AI-infrastruktur eftersom den relevanta tjänsten kanske inte alls är märkt som artificiell intelligens. En datalänk, kraftsystem, identitetstjänst, sjukhusjournalsystem eller forskningsnätverk kan vara det lager som gör en AI-aktiverad tjänst möjlig.

Direktivet är inte en AI-driftsmanual. Det klassificerar inte varje modelltjänst som kritisk, och det ersätter inte sektorsspecifika regler. Det tillhandahåller ett sätt att tänka kring konsekvens. Om ett system stödjer en samhällsviktig tjänst är frågan inte bara om modellen har klarat en utvärdering. Det är om entiteten kan fortsätta att tillhandahålla den samhällsviktiga tjänsten när en komponent, anläggning, leverantör, nätverk eller extern förutsättning förändras.

NIS2 ligger vid sidan av denna fysiska och organisatoriska syn med skyldigheter avseende cybersäkerhetsriskhantering och incidentrapportering för relevanta entiteter. Det rättsliga samspelet är specifikt och beror på entiteten och sektorn. Den allmänna lärdomen är inte att ett enda direktiv löser resiliens. Det är att cyber- och fysiska beroenden måste samordnas. Ett nätverk kan vara säkert mot en typ av attack och ändå misslyckas när kylning inte är tillgänglig. En anläggning kan ha redundant kraft och ändå inte kunna autentisera operatörer. En leverantör kan meddela en programvaruincident medan köparen saknar de register som behövs för att förstå dess effekt.

Resiliens behöver därför ett ordförråd för försämrad service, inte bara för totala avbrott. Kan systemet acceptera färre förfrågningar? Kan det stänga av en högriskfunktion samtidigt som en lågriskfunktion bevaras? Kan det växla till en mindre modell eller en manuell väg? Kan det fortsätta medan en kö töms och en källa verifieras? Kan det bevisa vilket arbete som försenades eller behandlades om? Detta är operativa beslut. De avgör också om medborgare, forskare och företag upplever en kontrollerad begränsning eller ett gåtfullt svar som kommer efter att institutionen har förlorat sammanhanget för att granska det.

Den användbara bilden är ett nätverk vars noder har ägare och vars kanter har villkor. En kant kan vara en elanslutning, ett programvaruberoende, ett avtal, en dataöverföring eller en auktoritetsrelation. En resilient design förutsätter inte att varje kant förblir tillgänglig. Den registrerar kanten, övervakar det villkor som är viktigt och definierar ett svar innan trycket kommer.

Ett illustrativt sammansatt exempel, inte en incidentrapport

Det hjälper att göra beroendeproblemet konkret utan att uppfinna ett verkligt avbrott. Det följande är ett illustrativt sammansatt exempel. Det beskriver ingen namngiven organisation, leverantör, anläggning, person, datum eller händelse. Det är ett tankeexperiment sammansatt av vanliga infrastrukturrelationer.

Tänk dig en offentlig forskningstjänst som låter behöriga team skicka in ett dokument, köra ett klassificeringsflöde och få ett resultat för mänsklig granskning. Tjänsten är värd på europeisk infrastruktur. Dess modell lagras i ett artefaktregister. Källdokumenten finns i en lagringsnivå och indexet i en annan. En gateway kontrollerar identitet och vidarebefordrar arbete till en kö. Arbetare använder en containeravbildning och en hårdvarudrivrutin. Resultat skrivs till en postbutik och en bevisström. En instrumentpanel visar driftteamet om systemet är hälsosamt.

Ingenting här är ovanligt. Det är poängen. Ändra nu ett villkor i taget. Registret ändrar sin signeringspolicy. Drivrutinsuppdateringen kräver en ny containerkörning. Ett certifikat upphör att gälla för tjänsten som skriver bevis, medan resultatbutiken fortsätter att acceptera skrivningar. En lagringskvot nås för ett derivatindex men inte för källdokumenten. En leverantör ändrar ett gränssnitt och kökonsumenten försöker igen med en operation som inte var utformad för att upprepas. En skicklig operatör slutar och runbooken beskriver fortfarande den tidigare driftsättningen. Ingen av dessa ändringar kräver att en modell producerar en falsk mening. Var och en kan ändra tjänstens tillförlitlighet eller dess förmåga att förklara sig själv.

En organisation som bara övervakar modellens noggrannhet kanske inte ser någon varning. Testuppsättningen klarar sig fortfarande. En organisation som övervakar hela tjänsten kommer att se olika signaler: ett verifieringsfel, ett ökande antal återförsök, en lucka i bevisströmmen, en lagringströskel, en ogranskad ändring eller ett ägarskapslarm. Signalerna är inte likvärdiga, och de kräver inte alla ett avbrott. De kräver en regel om vem som beslutar vad som händer härnäst.

Anta att teamet väljer att minska kapaciteten medan det kontrollerar beroendet. Det är inte ett tecken på att tjänsten har misslyckats med sitt syfte. Det kan vara ett tecken på att tjänsten har ett syfte som är större än genomströmning. Om systemet kan bevara källposten, markera det försenade arbetet, förhindra obehöriga återförsök och ge en människa en tydlig väg att granska de berörda fallen, har det försämrats på ett kontrollerat sätt. Om det fortsätter att producera polerade svar medan dess bevisväg är bruten, har det bevarat skenet av service på bekostnad av förtroende.

Kompositen är medvetet alldaglig, eftersom spektakulära incidenter gör läxan för lätt. Alla förstår att en översvämning kan störa en anläggning. Det svårare arbetet är att inse att ett utgånget certifikat, ett register utan ägare, ett ändrat leverantörsavtal eller en saknad återställningstest också kan flytta en tjänst utanför dess säkra driftgräns. Tråkiga beroenden är inte mindre orsaksmässiga för att de saknar ett dramatiskt fotografi.

Fel fortplantas genom relationer

En karta över felfortplantning bör följa relationer snarare än tekniketiketter. Börja med tjänstelöftet. Vad förväntar sig användaren ska hända, och vad måste vara sant för att den förväntningen ska uppfyllas? Spåra sedan bakåt genom modell, körning, policygrind, identitet, nätverk, lagring, hårdvara, energi, leverantör och institution. Fråga vid varje steg hur ett fel ser ut, hur det upptäcks, vem som äger åtgärden och vilka bevis som finns kvar.

Detta låter linjärt, men verkliga system förgrenar sig. En modell kan vara tillgänglig medan en policytjänst är otillgänglig. En policy kan tillåta ett anrop medan en identitetspost är inaktuell. En begäran kan accepteras medan en kö inte kan tömmas. Ett resultat kan returneras medan posten som behövs för att bestrida det saknas. Ett infrastrukturteam kan återställa tjänsten medan en dataägare fortfarande måste besluta om det påverkade arbetet kan litas på. Fortplantningskartan bör visa dessa förgreningar, eftersom en enda grön statuslampa inte kan.

Ett användbart sätt att rita kartan är att skilja mellan fyra typer av konsekvenser. Tillgänglighet frågar om arbetet kan utföras. Integritet frågar om arbetet och dess poster är oförändrade och fullständiga. Auktoritet frågar om aktören hade tillstånd att utföra arbetet. Återställningsbarhet frågar om tjänsten kan återgå till ett känt tillstånd och förklara vad som inträffat. Ett beroende kan vara acceptabelt för en dimension och oacceptabelt för en annan. En cache kan förbättra tillgängligheten samtidigt som den är olämplig som auktoritativ post. En tredjepartsidentitetstjänst kan vara bekväm samtidigt som den gör auktoritet svår att granska under en störning.

Kartan bör också visa tid. Vissa beroenden misslyckas omedelbart. Andra driver. En modell kan förbli tillgänglig medan dess stöddata blir inaktuella. En hårdvarukomponent kan fungera medan ersättningslager blir omöjligt att få tag på. Ett avtal kan förbli giltigt medan en leverantörs ändringspolicy långsamt tar bort det gränssnitt köparen förlitade sig på. Ju senare en signal anländer, desto dyrare är den att tolka. Tid är en del av beroendet, inte en notering i incidentrapporten.

Driftteam kallar ofta detta för observerbarhet. Det ordet är användbart bara när det pekar på en åtgärd. En graf som ser frisk ut berättar inte för någon vilken auktoritet de har, vilken ändring som fick grafen att röra sig eller vilka bevis som bör bevaras. Syftet med en felkarta är att göra ett beslut möjligt. Om bevisströmmen är ofullständig, pausa den påverkade åtgärden. Om modellregistret inte kan verifiera en artefakt, främja den inte. Om en leverantör ändrar en komponent utanför den testade gränsen, upprepa den relevanta utvärderingen. Om ett återställningstest inte kan återställa posten, kalla inte säkerhetskopian för en återställningsplan.

Det finns ingen universell tröskel för dessa beslut. Ett forskningsexperiment, en publik tjänst och ett säkerhetskritiskt arbetsflöde har olika toleranser. Det viktiga är att tröskeln tillhör tjänsteägaren, är synlig för operatörer och kan revideras när bevis förändras. Annars kommer tröskeln att sättas av den första person som märker felet, vilket är ett anmärkningsvärt demokratiskt sätt att driva ett system och ett dåligt sätt att styra ett.

Ett beroende behöver inte förstöra modellen för att ändra vad tjänsten säkert kan hävda.

Mät förmåga utan att dölja nämnaren

Infrastruktur uppmuntrar imponerande siffror. Exaflops, petabyte, processantal, investeringssummor och antalet anläggningar i ett program beskriver alla något verkligt. Ingen av dem är tjänsten i sig. En siffra blir användbar när dess nämnare och villkor är synliga.

Topprestanda för beräkningar säger inte en forskare hur snabbt en viss arbetsbelastning får en partition, flyttar sina data, slutför en körning eller hämtar resultatet. Antalet AI Factories säger inte ett litet företag om dess applikation får åtkomst under de villkor det behöver. En investeringssumma i halvledare säger inte en operatör vilken komponent som kommer att finnas tillgänglig under en brist. En hög tillgänglighetsprocent säger inte en offentlig institution om den kan hämta bevisen för ett omtvistat beslut.

En ansvarsfull beskrivning av förmåga parar därför rubriken med vägen bakom den. Namnge gränsen mellan hårdvara och programvara. Ange om siffran är topp, ihållande, planerad eller observerad. Beskriv arbetsbelastningen, åtkomstmodellen och undantagen. Säg vilka beroenden som ligger utanför mätningen. Håll påståendet knutet till releasen, hårdvaran, datasetet och policyn under vilken det gjordes. Målet är inte att göra varje sida oläslig. Det är att göra de viktiga sidorna kontrollerbara.

Denna disciplin förbättrar också den offentliga argumentationen. Europa behöver inte välja mellan ambition och försiktighet. Det kan bygga stora anläggningar, finansiera ambitiös forskning och ändå säga var bevisen slutar. Ett offentligt system som namnger sina begränsningar är mer trovärdigt än ett som presenterar en ren siffra utan någon väg att inspektera den. Begränsningen kan vara en kö, ett gränssnitt, en leverantör, en kompetensbrist, en effektgräns eller en juridisk gräns. Att namnge den gör inte förmågan mindre. Det berättar för människor vilken typ av förmåga det är.

Osäkerhet är inte ett erkännande av nederlag. Det är en underhållssignal. Om ingen vet hur en leverantörs förändring kommer att påverka en arbetsbelastning, är nästa steg ett test eller ett explicit antagande, inte ett större adjektiv. Om ett register inte kan skilja en modellrelease från en serveringskonfiguration, är nästa steg en bättre post. Om en institution inte kan avgöra vilken person som kan stoppa en operation, är nästa steg en auktoritetskarta. Precision är ett sätt att besluta vad som ska repareras.

De tysta lagren är där suveräniteten blir praktisk

Europeisk suveränitet diskuteras ibland som om den vore en flagga som placerats ovanpå ett datacenter. En tjänst kan vara placerad inom unionen och ändå vara beroende av externa komponenter, utländsk juridisk räckvidd, proprietära gränssnitt, bristfälliga kompetenser eller en leverantör vars ändringsbeslut inte kan ifrågasättas. Platsen är en faktor i en suveränitetsbedömning. Praktisk kontroll beror på hela kedjan.

Chiplagens fokus på att förstå den globala halvledarförsörjningskedjan, CER-direktivets uppmärksamhet på tvärsektoriella beroenden och ENISA:s varningar om mjukvaruberoenden och enskilda felpunkter pekar alla i samma riktning. Suveränitet är inte en enda strömbrytare. Det är förmågan att förstå vad en tjänst är beroende av, att avgöra vilket beroende som är acceptabelt, att ersätta eller begränsa det när det behövs och att behålla tillräckliga bevis för att försvara beslutet.

Den förmågan kan byggas på små sätt. En offentlig forskargrupp kan föra en förteckning över den körning, drivrutin och datarelease som använts för ett resultat. En upphandlingsgrupp kan kräva en testad exportväg snarare än ett löfte om portabilitet. En driftgrupp kan definiera ett degraderat läge och öva på det. En tillsynsmyndighet kan fråga vilka register som skulle finnas tillgängliga efter ett leverantörsbyte. En leverantör kan publicera gränsen för sitt stöd och villkoren under vilka en uppdatering ändrar beteendet. Ingen av dessa åtgärder gör ett system autonomt. De gör det mindre gåtfullt.

På Dweve är detta den snäva anledningen till att vi bryr oss om öppna grunder och de tysta delarna runt dem. Projekt som Core och Mesh är användbara bara när de finns inom en ärlig operativ gräns, med tydliga register, befogenheter och begränsningar. De är inte en ersättning för europeisk infrastruktur, offentliga institutioner eller försörjningskedjepolitik, och denna artikel hävdar inte att de löser dessa problem. Ståndpunkten är mindre: en öppen komponent är lättare att granska, ersätta och undervisa om när dess kontrakt är explicita. Det är en tegelsten, inte hela byggnaden.

Byggnaden spelar roll eftersom människor möter översta våningen och lever med grunderna. Svaret på skärmen kan vara flytande, men tjänstens verkliga karaktär avgörs av de lager som bestämmer var svaret kom ifrån, vem som kunde ändra det, vad som händer när ett beroende flyttas och om någon kan förklara resultatet senare.

Bygg systemet som människor fortfarande kan se

Det viktigaste AI-systemet kan vara det ingen ser, eftersom det är distribuerat över platser som aldrig kallats AI. Det är chiptillverkningsanläggningen och kylslingan. Det är superdatorn och schemaläggaren. Det är paketregistret, identitetsleverantören, lagringspolicyn, nätverksvägen och underhållslistan. Det är kontraktet som säger vad som händer när en leverantör ändrar en komponent. Det är institutionen som kan pausa ett arbetsflöde innan en svag signal blir ett offentligt misslyckande.

Inget av detta minskar vikten av modellkvalitet. Det ger modellkvalitet en plats att spela roll på. En modell kan bara tjäna en människa genom ett system som kan ta emot indata, utföra arbetet, bevara relevanta register och returnera resultatet med tillräckligt sammanhang för att någon ska kunna lita på eller ifrågasätta det. Modellen är en viktig komponent i det systemet. Den är inte ett land, en försörjningskedja, en återhämtningsplan eller en person med befogenhet att reparera de delar den inte kan se.

Europas infrastrukturprogram är en möjlighet att göra dessa beroenden synliga medan kapaciteten byggs. Möjligheten är praktisk. Publicera gränssnitt och operativa gränser. Finansiera underhåll och kompetens tillsammans med utrustning. Behandla upphandling som ett designbeslut. Koppla cybersäkerhet till fysisk motståndskraft. Ge mindre organisationer en väg att använda offentlig infrastruktur utan att tvinga dem att bli specialister på varje lager. Mät åtkomst, återhämtning och bevis lika noggrant som topprestanda.

Det finns ett visst europeiskt nöje i att upptäcka att svaret på en storslagen teknikfråga är en inventering, en runbook och en person som har rätt att stanna maskinen. Det är inte glamoröst, men det har fördelen att det överlever kontakt med en vanlig tisdag. När det dolda systemet är tillräckligt synligt för att kunna inspekteras kan modellen göra sitt arbete utan att bära på en myt som den aldrig byggdes för att bära.

Källor