Europæiske forsvarsfolk advarer mod at gøre digital suverænitet til et krav om at undvære amerikansk teknologi. Konsekvensen kan ifølge dem blive dårligere it og større sårbarhed over for cyberangreb. Samtidig forsøger EU at mindske afhængigheden af amerikanske teknologivirksomheder.
Den spænding, som Computerworld beskriver, er relevant langt ud over forsvaret. I risikerer at overse den, hvis jeres diskussion om digital suverænitet reduceres til et valg mellem europæisk og amerikansk, lokalt og cloud eller åbent og proprietært.
I bliver ikke suveræne af leverandørens nationalitet eller af at drive alt selv. I bliver suveræne, når I vælger en afhængighed bevidst, forstår dens konsekvenser og kan fortsætte driften, når vilkårene ændrer sig.
Det gør digital suverænitet til et porteføljevalg. Ikke alle systemer kræver samme grad af kontrol, og ikke alle afhængigheder er lige farlige.
Jeres teknologistak bliver aldrig uafhængig
I kan flytte en AI-model til et europæisk datacenter og stadig være afhængige af amerikanske chips, udenlandske softwarebiblioteker, én bestemt cloudarkitektur eller en enkelt intern specialist. Omvendt kan I bruge en amerikansk tjeneste uden at gøre alle jeres kritiske funktioner afhængige af den.
I har afhængigheder under alle omstændigheder. Den relevante beslutning er, hvilke konsekvenser I vil acceptere, hvis en leverandør ændrer pris, vilkår, adgang, model eller geografisk tilgængelighed.
En renhedstest kan få jer til at fravælge en bedre løsning på grund af oprindelsesland. Den kan også skabe falsk tryghed omkring en lokal løsning, som ingen hos jer reelt kan vedligeholde, sikre eller erstatte.
Jeres valg står derfor ikke mellem “udenlandsk” og “suveræn”. I skal beslutte, hvor I vil acceptere en ensidig afhængighed, og hvad der skal være på plads, før I gør det.
Del porteføljen efter konsekvens
Begynd med arbejdets betydning, ikke med leverandørens navn.
Kritiske funktioner skal kunne fortsætte. Når et bortfald kan stoppe driften, påvirke væsentlige beslutninger eller blokere adgangen til jeres egne data, skal I vide, hvordan I fortsætter. Reservevejen skal have en ejer, og I skal have besluttet, hvor længe reduceret drift er acceptabel.
Vigtige arbejdsgange skal have en tidsbestemt alternativ vej. I behøver ikke drive to fulde løsninger hver dag. Men I skal kende tid, pris og serviceniveau, hvis den primære leverandør falder bort.
Reversible forsøg må gerne være afhængige. Hvis konsekvensen ved et leverandørstop er lille, og I kan genskabe arbejdet uden væsentligt tab, kan den bedste eksterne tjeneste være det rigtige valg. Her kan en reservevej koste mere end den risiko, den fjerner.
Klassifikationen skal følge brugen. Når et eksperiment bliver en del af jeres daglige drift, ændrer kravene sig. Det skifte skal være synligt, før afhængigheden bliver kritisk.
Se på arkitekturen, ikke kun kontrakten
I en gennemgang af AI-agentplatforme peger Nate B. Jones på tre valg, der former kontrollen: Hvor agenten kører, hvem der orkestrerer modellerne, og hvilken grænseflade I binder arbejdet til.
- Kørselsstedet afgør blandt andet, hvem der driver infrastrukturen, og hvor meget I selv skal kunne sikre og overvåge.
- Orkestreringen afgør, om I kan bruge en anden model, eller om logikken er bygget ind i én leverandørs tjeneste.
- Grænsefladen afgør, om medarbejdernes arbejde kan flyttes, eller om viden og rutiner kun eksisterer inde i én bestemt brugerflade.
Det er ikke et argument for altid at vælge lokale eller åbne løsninger. Jones fremhæver også bytteforholdet: Mere egen kontrol giver jer et større sikkerheds- og driftsansvar. En løsning, I selv hoster, er ikke robust, hvis opdateringer, adgangsstyring og hændelser afhænger af én travl medarbejder.
Den samme pointe gælder AI-agenter. Som vi tidligere har beskrevet i sagen om OpenAIs testagent og Hugging Face, består kontrollen ikke kun i modellen. Infrastruktur, værktøjer, netværksadgang og stopmuligheder er en del af systemet. Det er ikke nok at eje en komponent, hvis ingen ejer helheden.
Den største afhængighed kan ligge på tværs
Når I gennemgår leverandører én kontrakt ad gangen, kan I overse risikoen på tværs. Systemer med forskellige navne kan bruge samme cloud, identitetstjeneste, modeludbyder eller netværksforbindelse og derfor falde samtidig.
Jeres suverænitetsdiskussion skal gøre den koncentration synlig og veje handlefrihed mod kvalitet, hastighed og pris.
Tag som minimum fem spørgsmål med i porteføljegennemgangen:
- Hvor mange af jeres kritiske arbejdsgange kan bortfalde ved den samme hændelse?
- Hvilke fælles afhængigheder gemmer sig bag forskellige leverandørnavne?
- Hvor mister I uforholdsmæssigt meget kvalitet eller kapacitet ved at kræve en lokal løsning?
- Hvor har I faktisk kompetence til at bære mere drift og sikkerhed selv?
- Hvem må acceptere den resterende afhængighed på forretningens vegne?
Jeres svar kan føre til, at en kritisk funktion får en dyr reservevej, mens en anden bevidst bliver liggende hos den stærkeste udenlandske leverandør. Det er ikke inkonsekvent. Det er risikostyring. Problemet opstår, hvis begge valg får samme standardsvar eller slet ikke bliver truffet.
Digitalmedarbejders guide til valg af AI-agentplatform gennemgår de praktiske lag: runtime, orkestrering, gateway, governance og brugerflade. De er nyttige som indkøbskriterier, men også som et kort over de steder, hvor en afhængighed kan gemme sig.
Bestyrelsen skal godkende afhængigheden, ikke mærket
I behøver ikke gennemgå alle softwarekomponenter. Men I skal sørge for, at de væsentlige afhængigheder bliver synlige og behandlet forskelligt efter konsekvens.
Et enkelt porteføljekort kan være nok. For hver væsentlig AI-arbejdsgang registrerer I den accepterede afhængighed, konsekvensen ved bortfald, målet for genetablering og den navngivne risikoejer. Kortet skal også samle fælles underleverandører på tværs. Så kan I vurdere et krav om lokal drift eller en europæisk leverandør konkret: Reducerer det en farlig koncentration, eller flytter det blot afhængigheden til et mindre synligt sted?
Forsvarsfolkenes advarsel viser modargumentet til en mekanisk europæisk strategi: Teknologisk uafhængighed kan koste kapacitet og sikkerhed. Det modargument bør tages alvorligt. Men det ophæver ikke behovet for suverænitet. Det præciserer det.
I bliver ikke suveræne ved at undgå alle stærke leverandører. I bliver suveræne, når I ved, hvilke leverandører I er afhængige af, hvorfor afhængigheden er acceptabel, og hvad I gør, når den ikke længere er det.