Digital suveränitet börjar i ert ledningssystem

SVT:s nyhet om EU:s plan för att minska beroendet av amerikanska techjättar är lätt att läsa som geopolitik. Datacenter. Moln. AI. Chips. Open source.

För företag börjar frågan i vardagen. Vilka system är ni beroende av? Vilken data passerar dem? Vem äger risken? Kan ni visa varför ni accepterar ett beroende, eller vad ni gör för att minska det?

Suveränitet betyder i grunden förmågan att bestämma själv. För ett land handlar det om politisk självständighet. För ett företag är betydelsen mer praktisk: att kunna förstå, styra och ompröva de beroenden som verksamheten vilar på.

Digital suveränitet är därför kontroll över data, system, leverantörer och AI-beslut. Kontroll nog för att veta vad ni accepterar, vad ni kan ändra och vad ni gör om förutsättningarna flyttar sig.

Vad betyder digital suveränitet för ett företag?

SVT beskriver EU-kommissionens paket som ett sätt att minska Europas beroende av amerikanska techjättar. Paketet omfattar bland annat datacenterkapacitet, moln och AI, open source och Chips Act 2.0.¹

Kommissionens egen definition är användbar här. Tech sovereignty beskrivs som Europas förmåga att agera självständigt i den digitala världen genom att utveckla och kontrollera nyckelteknik, data och infrastruktur, samtidigt som beroendet av icke-EU-leverantörer minskar.²

Översatt till företagsnivå handlar det om kontrollnivå. Ett lönesystem, en identitetsplattform, en driftpartner och ett AI-verktyg behöver inte samma svar. De behöver en medveten bedömning av hur kritiskt beroendet är, vem som ansvarar för det och vilka alternativ som finns.

Cloud and AI Development Act beskriver suveränitet i nivåer: var data behandlas, oberoende från tredjeländer, transparens i mjukvaruleveranskedjan, ägande och kontroll över leverantören, och i den högsta nivån full transparens och kontroll över mjukvaruleveranskedjan utan påverkan från tredjeland.³

EU:s Open Source Strategy pekar åt samma håll: mer kontroll, mindre lock-in, starkare säkerhet och återanvändbara byggblock.⁴

Poängen för ledningen blir enkel: vilken kontroll behöver vi för just det här beroendet?

Problemet är osynliga beroenden

När beroenden gör ont beror det ofta på att ingen kan beskriva dem innan de måste försvaras.

Vilka system är kritiska? Vilken data ligger där? Vem kan ändra villkor? Hur snabbt kan ni byta? Vad händer om tjänsten ligger nere? Vilka kunder, processer eller lagkrav påverkas? Vem i ledningen har accepterat risken?

I moln- och SaaS-beroenden återkommer samma praktiska frågor:

• var data ligger och flyttas,
• hur krav och ansvar ser ut i avtalet,
• hur leverantören följs upp,
• vad exit från tjänsten kräver,
• vad som händer vid störning eller avbrott.

I AI-beroenden tillkommer fler frågor. Vad får verktyget användas till? Vilka data används? Vilka loggar finns om något går fel? Hur fördelas ansvaret mellan er, leverantören och andra tredje parter? Hur bedömer ni påverkan på människor och verksamhet när användningen ändras?

Det här är ledningens kontroll över verksamheten, med teknik som en av flera beroendeytor.

ISO 27001 gör beroendet synligt

ISO/IEC 27001:2022 börjar i organisationens sammanhang.

Kapitel 4 kräver att organisationen bestämmer externa och interna frågor, relevanta intressenter och deras krav. Standarden kräver också att ni tar hänsyn till gränssnitt och beroenden mellan sådant organisationen gör själv och sådant andra organisationer gör åt den.⁵

Här blir digital suveränitet praktisk. Moln, identitet, driftpartner och kritiska leverantörer behöver vara synliga i ledningssystemet om ni ska kunna styra dem.

Kapitel 6.1.2 kräver en riskbedömningsprocess som identifierar risker för konfidentialitet, riktighet och tillgänglighet, utser riskägare, bedömer konsekvens och sannolikhet och prioriterar vad som ska behandlas.⁵

Kapitel 6.1.3 kräver att ni väljer nödvändiga säkerhetsåtgärder, jämför dem med Bilaga A och tar fram en Statement of Applicability. Den ska visa vilka kontroller som behövs, varför de ingår, om de är införda och varför eventuella Bilaga A-kontroller har valts bort.⁵

Det gör SoA till mer än en revisionslista. Den blir ert beslutspapper för beroenden.

Flera kontroller i Bilaga A ligger nära suveränitetsfrågan: leverantörsrelationer, säkerhetskrav i leverantörsavtal, IKT-leveranskedjan, uppföljning av leverantörstjänster, anskaffning och exit för molntjänster, informationssäkerhet vid störning och IKT-beredskap för kontinuitet.⁶

ISO 27001 väljer inte leverantör åt er och gör er inte automatiskt digitalt suveräna. Standarden ger däremot en tydlig arbetsgång: synliggör beroendet, välj kontroller och dokumentera varför ni accepterar eller minskar risken.

ISO 42001 gör AI-beroendet styrbart

ISO/IEC 42001:2023 tar samma ledningslogik till AI-system och AI-användning.

Standarden kräver att risker och möjligheter bestäms utifrån domän, användningskontext, avsedd användning och organisationens externa och interna sammanhang. Den kräver också AI-riskbedömning, AI-riskbehandling och en konsekvensbedömning som tar hänsyn till driftsättning, avsedd användning och rimligt förutsebar felanvändning.⁷

Kapitel 8 gör detta löpande. Riskbedömningar, riskbehandlingar och konsekvensbedömningar ska göras vid planerade intervall eller när betydande förändringar föreslås eller inträffar.⁷

Det är viktigt för företag som “bara använder” AI. ISO 42001 är inte reserverad för organisationer som tränar egna modeller. Standarden säger också att externt tillhandahållna processer, produkter eller tjänster som är relevanta för AI-ledningssystemet ska styras.⁷

Bilaga A gör AI-beroendet konkret. Den behandlar bland annat AI-policy, roller och ansvar, konsekvensbedömning, drift, övervakning, loggar, datainhämtning, datakvalitet, dataproveniens, avsedd användning och ansvarsfördelning med leverantörer och kunder.⁸

Därför passar ISO 42001 frågor om Copilot, ChatGPT, specialiserade AI-verktyg och AI-funktioner som byggs in i andra plattformar. Även när ni inte bygger modellen själva behöver ni kunna styra användningen, datat, rollerna, loggarna och leverantörsrelationen.

ISO 42001 löser inte AI Act, geopolitik eller leverantörsrisk automatiskt. Den gör däremot AI lättare att behandla som en del av ledningssystemet, inte som ett sidospår.

En enkel suveränitetscheck för ledningen

Börja med era egna beroenden.

Lista de system och AI-verktyg som är avgörande för verksamheten. Ta inte bara med de stora plattformarna. Lägg också till identitet, integrationer, supportvägar, databaser, beslutsstöd och AI-verktyg som används i vardagen.

Sätt en ägare per beroende. Någon ska kunna svara för användning, risknivå, leverantörsrelation och nästa steg om förutsättningarna ändras.

Skriv ner vad ni accepterar och varför. För informationssäkerhet hör det hemma i riskbehandling och SoA. För AI hör det hemma i AI-policy, riskbehandling och konsekvensbedömning.⁵⁷

Kontrollera att ni har en väg ut eller en plan för störning. Exit, alternativ drift, reservrutiner och uppföljning är inte detaljfrågor när beroendet är kritiskt.⁶

Gör om bedömningen när leverantören, modellen, datat, användningen eller omvärlden ändras. Både ISO 27001 och ISO 42001 bygger på att risker och behandlingar följs upp när förutsättningarna flyttar sig.⁵⁷

Digital suveränitet är ett uppföljningsarbete. Beslutet behöver hålla även när leverantören, tekniken eller omvärlden ändras.

Där AmpliFlow passar in

Det här är svårt om besluten ligger i spridda dokument, kalkylblad och mejltrådar.

I AmpliFlow för ISO 27001 kan risker, SoA, kontrollstatus, åtgärder och revisionsunderlag hänga ihop i samma plattform. ISO 42001-stödet bygger på samma idé för AI: godkända verktyg, risker, konsekvensbedömningar, åtgärder och dokumentation samlas i ett AI-ledningssystem.

Ett system gör er inte suveräna av sig självt. Värdet ligger i att risker, leverantörer, kontroller, ansvar och uppföljning sitter ihop.

För de flesta företag börjar digital suveränitet där: i ledningssystemet.

Footnotes

1. SVT Nyheter, “EU:s plan: Frigöra sig från USA:s techdominans”, publicerad 2026-06-03 och uppdaterad 2026-06-04. Artikeln beskriver EU-kommissionens paket som ett svar på beroendet av amerikanska techjättar och nämner datacenterkapacitet, moln och AI, open source och Chips Act 2.0. Original URL. ↩

2. European Commission, “Strengthening Europe’s Tech Sovereignty”. Sidan definierar tech sovereignty som Europas förmåga att agera självständigt i den digitala världen genom att utveckla och kontrollera nyckelteknik, data och infrastruktur, samtidigt som beroendet av icke-EU-leverantörer minskar. Den listar också paketets huvuddelar. Original URL. ↩

3. European Commission, “Cloud and AI Development Act”. Sidan beskriver CADA som en del av AI Continent Action Plan, med fokus på kapacitet, autonomi, ett EU-gemensamt suveränitetsramverk och fyra nivåer för cloud and AI sovereignty. Original URL. ↩

4. European Commission, “EU Open Source Strategy”. Sidan beskriver open source som ett verktyg för tech sovereignty genom mer kontroll, mindre lock-in, starkare säkerhet, återanvändbara byggblock och europeiska alternativ. Original URL. ↩

5. ISO/IEC 27001:2022, clauses 4.1, 4.2, 4.3 c), 6.1.2 and 6.1.3. De här delarna täcker kontext, intressenter, beroenden till andra organisationer, riskbedömning, riskbehandling och Statement of Applicability. ↩ ↩² ↩³ ↩⁴ ↩⁵

6. ISO/IEC 27001:2022, Annex A controls 5.19, 5.20, 5.21, 5.22, 5.23, 5.29, 5.30 and 5.31. De här kontrollerna täcker leverantörsrelationer, leverantörsavtal, IKT-leveranskedjan, uppföljning av leverantörstjänster, molntjänster, störningar, kontinuitet och relevanta krav. ↩ ↩²

7. ISO/IEC 42001:2023, clauses 6.1.1, 6.1.2, 6.1.3, 6.1.4, 8.1, 8.2, 8.3 and 8.4. De här delarna täcker AI-risk, AI-riskbehandling, konsekvensbedömning, styrning av externa tjänster och återkommande uppföljning vid förändring. ↩ ↩² ↩³ ↩⁴ ↩⁵

8. ISO/IEC 42001:2023, Annex A controls A.2.2, A.3.2, A.5.2-A.5.5, A.6.2.6, A.6.2.8, A.7.3-A.7.5, A.8.5, A.9.2, A.9.4, A.10.2 and A.10.3. De här kontrollerna täcker AI-policy, roller, konsekvensbedömning, drift, loggar, data, information till intressenter, avsedd användning och leverantörsansvar. ↩