Skip to main content

Stikkord: Infrastruktur

Fremtidsby der biler navigerer ved hjelp av digitale kart og sensorer

En fremtid uten trafikkskilt?

Skrevet av Franch Hagerup den . Publisert i Teknologi.

Kartet i bilen ser stadig mer levende ut. Fartsgrenser, kø, omkjøringer og stengte veier kan oppdateres mens vi kjører. Samtidig blir biler flinkere til å lese omgivelsene med kameraer, radar og andre sensorer. Betyr det at trafikkskiltene en dag kan fjernes?

En helt skiltløs fremtid er lite sannsynlig med det første. Utviklingen peker heller mot et dobbelt system: informasjonen finnes både fysisk langs veien og digitalt i kjøretøyet. Det kan gi tryggere transport, men gjør også kvaliteten på kartdata og kontrollen over den digitale infrastrukturen langt viktigere enn før.

Kartet er ikke lenger bare et bilde

Et papirkart fryser verden på et bestemt tidspunkt. Det kan være nyttig uten strøm eller dekning, men blir gradvis mindre presist når veier, adresser og kjøremønstre endres.

Et digitalt kart fungerer annerledes. Det kan kobles til trafikkmeldinger, posisjonsdata og informasjon fra veieiere. I Norge er Nasjonal vegdatabank (NVDB) en sentral offentlig kilde. Databasen inneholder blant annet fartsgrenser, skiltplater og en digital representasjon av det fysiske veinettet. På samme måte som presise måledata danner en digital grunnmur i bygg og anlegg, blir oppdaterte veidata en grunnmur for automatisert transport.

Dermed har kartet gått fra å være en veiviser til å bli en del av infrastrukturen. Når informasjonen er riktig og oppdatert, kan bilen varsle om en ny fartsgrense før føreren rekker å oppdage skiltet. Når dataene er gamle eller feil, kan systemet gi et misvisende bilde av virkeligheten.

Dagens biler leser både skilt og kart

Det er lett å omtale nye biler som selvkjørende, men de fleste systemene som selges til vanlige forbrukere er fortsatt førerassistenter. Føreren må følge med og ha ansvar for kjøringen. Amerikanske NHTSA understreker også at fullt automatiserte biler som kan kjøre overalt og under alle forhold, ikke er tilgjengelige for vanlig kjøp i dag.

Samtidig har bilen allerede fått flere digitale øyne. Kameraer kan lese fartsgrenseskilt og veimerking. Navigasjonssystemet kan ha lagret fartsgrenser og veiklasser. Andre sensorer følger avstand, kjørefelt og objekter rundt bilen.

EUs regler for intelligent fartsassistanse viser hvorfor flere kilder brukes samtidig. Reglene beskriver kombinasjonen av kamera, satellittbasert posisjonering og oppdaterte digitale kart som den mest robuste løsningen. Et synlig fartsgrenseskilt skal likevel veie tungt når systemet møter motstridende informasjon.

På kort sikt gjør automatiseringen derfor ikke trafikkskiltene overflødige. Den øker behovet for at skiltene er tydelige, riktig plassert og lesbare for både mennesker og maskiner.

Hvorfor fysiske skilt fortsatt har en rolle

Trafikken består ikke bare av nye biler med oppdatert programvare. Fotgjengere, syklister, motorsyklister, eldre kjøretøy, utrykningspersonell og tilreisende må også forstå veimiljøet. Statens vegvesens skiltnormal beskriver trafikkskiltene som en viktig del av systemet som informerer, varsler, leder og styrer trafikantene.

Fysiske skilt har flere fordeler som er lette å undervurdere:

  • De kan leses uten abonnement, mobildekning eller innlogging.
  • De gir samme beskjed til alle som befinner seg på stedet.
  • De fungerer som en synlig kontroll når kartet eller bilen viser noe annet.
  • De gjør regler og farer forståelige også for trafikanter uten digitale hjelpemidler.
  • De gir redundans hvis strøm, nettverk, satellittposisjonering eller en leverandørtjeneste svikter.

En vei som bare kan tolkes av maskiner, vil derfor være mindre tilgjengelig for mennesker. Den vil også bli mer sårbar for feil i datasett, programvare og kommunikasjon.

Skiltene kan bli færre uten å forsvinne

At alle skilt ikke forsvinner, betyr ikke at veimiljøet vil se likt ut om tjue år. En del informasjon kan bli mer dynamisk. Variable skilt brukes allerede til å vise hastighet, stengte felt og andre forhold som endrer seg. I fremtiden kan den samme beskjeden sendes direkte til kjøretøyet samtidig.

Noen steder kan også overflødige eller gjentatte skilt fjernes når informasjonen formidles bedre på andre måter. Men det er noe annet enn å erstatte hele det synlige systemet. I blandet trafikk vil en fysisk grunnmur fortsatt være nødvendig, mens det digitale laget gir mer presisjon og tidligere varsling.

Den mest realistiske utviklingen er derfor ikke «skilt eller kart», men skilt og kart i samspill.

Hvem kontrollerer det digitale veikartet?

Når bilen bruker kartet til mer enn navigasjon, blir eierskap og oppdateringsansvar viktige spørsmål. Hvem avgjør at en fartsgrense er endret? Hvor raskt når en midlertidig omkjøring fram til kjøretøyene? Hva skjer hvis en privat karttjeneste og den offentlige veiinformasjonen er uenige?

Her er det en vesentlig forskjell mellom et offentlig veidatasett og en kommersiell navigasjonstjeneste. Offentlige data kan gi et felles, etterprøvbart grunnlag. Private tjenester kan tilføre bedre brukeropplevelse og raskere trafikkberegning, men de bør ikke være den eneste kilden til regler som gjelder i det fysiske rommet.

Den norske NVDB-modellen viser hvor krevende dette er. Veieierne har ansvar for å oppdatere data om sine egne veier, og det digitale veinettet må holdes så ajour som mulig. Et automatisk kjøretøy trenger ikke bare et detaljert kart. Det trenger et kart man kan stole på.

En skiltløs by er også et samfunnsspørsmål

En by uten synlige trafikkskilt kan se ryddig og moderne ut. Samtidig flyttes informasjon fra det offentlige rommet til skjermer, sensorer og programvare som ikke alle har tilgang til.

Da oppstår spørsmål som er større enn selve bilen:

  • Skal grunnleggende trafikkinformasjon være synlig for alle?
  • Hvordan sikres navigasjon hvis digitale tjenester faller bort?
  • Hvem har ansvar når fysisk skilt og digital beskjed ikke stemmer?
  • Hvordan hindrer vi at bevegelse i byen blir avhengig av noen få teknologileverandører?

Teknologi kan gjøre transporten mer presis og mindre belastende. Men en god infrastruktur må også være forståelig, tilgjengelig og robust når noe går galt.

Fremtiden er trolig hybrid

Digitale kart vil få større betydning, og biler vil tolke stadig mer av veimiljøet selv. Enkelte skilt kan bli færre, smartere eller mer dynamiske. Likevel er det vanskelig å se for seg at all fysisk trafikkinformasjon forsvinner så lenge mennesker og svært ulike kjøretøy deler veien.

Det viktigste spørsmålet er derfor ikke om det siste trafikkskiltet blir skrudd ned. Det er hvordan vi bygger et system der fysiske skilt, offentlige veidata og kjøretøyenes sensorer kontrollerer og utfyller hverandre.

Da kan kartet bli mer enn en veiviser uten at veien blir uforståelig når skjermen blir svart.

Kilder og videre lesing

Illustrasjon som viser forskjellen mellom skylagring og egen serverinfrastruktur

Cloud vs egen server – hva lønner seg?

Skrevet av Svein Tore den . Publisert i IT-sikkerhet. Ingen kommentarer til Cloud vs egen server – hva lønner seg?

Cloud lønner seg ofte når virksomheten ønsker rask oppstart, fleksibel kapasitet og minst mulig ansvar for underliggende infrastruktur. Egen eller dedikert server kan lønne seg når behovet er stabilt, kontrollkravene er tydelige og virksomheten har kompetanse til å drifte miljøet forsvarlig. Ingen av modellene er automatisk billigst, sikrest eller mest kontrollerbar.

Den riktige sammenligningen må omfatte samme funksjoner, samme sikkerhetsnivå og samme tidsperiode. Lisenspris i skyen kan ikke sammenlignes direkte med innkjøpsprisen på en server. Drift, strøm, datasenter, kompetanse, overvåking, backup, gjenoppretting, nedetid, migrering og leverandørbytte må regnes med på begge sider.

Cloud og egen server er ikke to entydige produkter

«Cloud» kan være en ferdig programvaretjeneste, en plattform eller leid infrastruktur. «Egen server» kan være maskinvare i virksomhetens lokaler, en dedikert server i et datasenter eller et miljø som driftes av en ekstern partner.

NIST skiller mellom SaaS, PaaS og IaaS. Kunden har minst ansvar for underliggende teknologi i en ferdig SaaS-tjeneste og mer ansvar i IaaS. NIST skiller også mellom offentlig, privat og hybrid sky. En privat sky kan driftes av en tredjepart og stå utenfor virksomhetens lokaler.

Det første steget er derfor å beskrive de faktiske alternativene:

  • Hvilke applikasjoner og data omfattes?
  • Hvem drifter operativsystem, applikasjon, nettverk og backup?
  • Hvor står infrastrukturen, og hvem har administrativ tilgang?
  • Hvilket tjenestenivå og hvilken support følger med?

Sammenligning i korte trekk

Område Offentlig skytjeneste Egen eller dedikert server
Oppstart Ofte rask og med lav startinvestering Krever anskaffelse, oppsett og kapasitet
Skalering Kapasitet kan ofte endres raskt Krever planlegging og eventuelt ny maskinvare
Kostnadsmodell Løpende lisens- eller forbrukspris Investering eller leie, pluss løpende drift
Teknisk ansvar Fordeles mellom kunde og leverandør Mer ansvar hos virksomheten eller driftspartneren
Kontroll Innenfor leverandørens plattform og avtale Kan gi større teknisk kontroll
Exit Avhenger av eksport, formater og integrasjoner Avhenger av dokumentasjon, kompetanse og erstatningsmiljø

Tabellen viser typiske forskjeller, ikke garantier. En dårlig driftet server kan være både dyrere og mindre sikker enn en skytjeneste. En dårlig konfigurert skytjeneste kan på sin side gi brede tilganger, ukontrollert deling og uforutsigbare kostnader.

Hva koster alternativene over hele levetiden?

Cloud flytter ofte kostnaden fra investering til løpende drift. Det kan gi lavere terskel, men også en regning som følger brukere, lagring, trafikk og tilleggsfunksjoner. Egen server gir en større startkostnad eller fast leie, men trenger fortsatt løpende administrasjon, oppdateringer og utskifting.

Ta med disse postene i begge modeller:

  • lisenser, abonnement, kapasitet og datatrafikk
  • maskinvare, datasenter, strøm og nettverk der det er relevant
  • innføring, datamigrering og parallelldrift
  • administrasjon, oppdateringer, overvåking og support
  • sikkerhetsfunksjoner, logging, backup og gjenoppretting
  • planlagt utskifting, eksport og framtidig migrering
  • forventet kostnad ved nedetid og tapt arbeid

Bruk lavt, forventet og høyt scenario over en periode som passer beslutningen. Ikke bruk generelle markedspriser som fasit. Artikkelen Hva koster egentlig skylagring for bedrifter? viser en konkret treårskalkyle uten udaterte prisanslag.

Sikkerhet avhenger av ansvarsdelingen

Store skyleverandører kan ha sikkerhetsmiljøer, redundans og revisjoner som er vanskelige for en liten virksomhet å bygge alene. Det betyr ikke at kunden er fritatt for ansvar. Kontoer, flerfaktorautentisering, tilgangsroller, innstillinger, dataklassifisering og ofte backup ligger fortsatt helt eller delvis hos kunden.

Med egen eller dedikert server kan virksomheten styre flere detaljer, men må også sikre kompetanse og kapasitet til:

  • sikker konfigurasjon og raske oppdateringer
  • nettverksbeskyttelse og segmentering
  • logging, overvåking og hendelseshåndtering
  • fysisk sikkerhet og strøm
  • backup, testet gjenoppretting og utskifting

NSM anbefaler at virksomheten gjør verdi- og risikovurderingen før den velger en konkret løsning. Vurderingen bør omfatte konfidensialitet, integritet og tilgjengelighet, ikke bare hvem som kan lese data.

Kontroll over data består av flere spørsmål

Kontroll betyr mer enn fysisk plassering. Virksomheten bør kjenne:

  • hvem som eier leverandøren og infrastrukturen
  • hvor data, kopier og logger behandles
  • hvor drift- og supportpersonell befinner seg
  • hvilke underleverandører som brukes
  • hvem som kan gi administrativ tilgang
  • hvordan data eksporteres og slettes

NSMs Risiko 2026 peker på at bruk av utenlandske skytjenester kan redusere kontrollen over infrastruktur, systemer og data. Det betyr ikke at alle utenlandske skytjenester er feil valg, men at avhengigheten må forstås og håndteres.

Egen server gir heller ikke full uavhengighet. Maskinvare, operativsystem, programvare, sikkerhetsoppdateringer, internett, strøm og driftstjenester kommer fortsatt fra leverandørkjeder.

Tilgjengelighet må måles fra brukerens side

En skytjeneste kan være operativ mens virksomhetens internettlinje, identitetsløsning eller integrasjon er nede. En server i eget lokale kan være tilgjengelig internt under et internettbrudd, men sårbar for strømfeil, brann eller lokal maskinvarefeil.

Definer hvor lenge virksomheten kan være uten hver arbeidsprosess, og hvor mye data den kan tåle å miste. Vurder deretter:

  • redundant strøm, nettverk og maskinvare
  • reserveforbindelse og alternativ kommunikasjon
  • offline arbeidsmåte eller manuell nødrutine
  • gjenoppretting til et annet miljø
  • kontakt- og eskaleringsvei ved hendelser

En oppetidsgaranti er bare én del av dette. Den viser ikke nødvendigvis hvor raskt data og arbeidsflyter kan gjenopprettes etter en alvorlig hendelse.

Backup må vurderes uavhengig av driftsmodellen

Skyleverandørens redundans er ikke automatisk en uavhengig sikkerhetskopi. Egen server er heller ikke sikker fordi den har flere disker. Feilsletting, ransomware, kompromitterte administratorer og feilkonfigurasjon kan ramme flere kopier samtidig.

Avklar hvilke data som sikkerhetskopieres, hvor kopiene oppbevares, hvem som kan slette dem og hvor raskt hele tjenesten kan bygges opp igjen. Bruk 3-2-1-prinsippet som utgangspunkt og gjennomfør en test av full gjenoppretting.

Leverandøravhengighet finnes i begge modeller

I en skytjeneste kan avhengigheten ligge i dataformater, integrasjoner, identiteter, arbeidsflyter og løpende lisensvilkår. På egen server kan den ligge i spesialtilpasninger, manglende dokumentasjon eller kompetanse som bare én leverandør eller ansatt har.

En exit-plan bør minst beskrive:

  • hvordan data, metadata, rettigheter og logger eksporteres
  • hvilke integrasjoner som må erstattes
  • hvilken dokumentasjon og hvilke nøkler virksomheten trenger
  • hvor lenge gammel og ny løsning må kjøre parallelt
  • hvordan sletting eller avhending bekreftes

NSM anbefaler oversikt og kontroll gjennom hele livsløpet. Utflytting bør testes eller i det minste prøvekjøres med et representativt datasett før virksomheten blir fullstendig avhengig av løsningen.

Når offentlig sky ofte passer godt

En ferdig skytjeneste er ofte et godt valg når virksomheten:

  • vil komme raskt i gang uten å bygge et driftsmiljø
  • har varierende antall brukere eller kapasitetsbehov
  • trenger standardiserte samarbeids- og integrasjonsfunksjoner
  • ikke har kompetanse til å vedlikeholde infrastrukturen alene
  • kan akseptere leverandørens kontrakt, driftsmodell og kontrollnivå

Gevinsten forutsetter at tjenesten konfigureres og forvaltes. Ubrukte kontoer, brede delinger og manglende MFA blir ikke løst av leverandørens datasenter.

Når egen, dedikert eller privat løsning kan passe

Mer kundestyrt infrastruktur kan være aktuelt når virksomheten:

  • har spesielle applikasjoner eller integrasjoner
  • trenger detaljert kontroll over konfigurasjon og endringer
  • har stabilt kapasitetsbehov og kan utnytte ressursene over tid
  • har krav til plassering, isolasjon eller administrativ tilgang
  • har en intern eller ekstern driftsorganisasjon som kan følge opp hele livsløpet

Mer kontroll er bare en fordel når noen faktisk bruker kontrollen til sikker drift, dokumentasjon og beredskap.

Hybrid kan være riktig, men er ikke et gratis kompromiss

En hybridmodell kan plassere ulike arbeidslaster der de passer best. Den kan også gi flere identitetsløsninger, nettverk, backupregimer, avtaler og feilkilder. Hybrid bør velges fordi arbeidsprosessene krever det, ikke fordi virksomheten vil utsette en tydelig beslutning.

Avklar hvordan identitet, logging, sikkerhet, dataflyt og hendelseshåndtering fungerer på tvers. Kompleksiteten må inngå i både risiko- og kostnadsberegningen.

En beslutningsprosess i seks trinn

  1. Beskriv arbeidsprosesser, data og krav til tilgjengelighet.
  2. Definer to eller tre konkrete driftsalternativer med tydelig ansvar.
  3. Gjør risiko- og personvernvurdering for hvert alternativ.
  4. Beregn sammenlignbar totalkostnad over flere år.
  5. Test sikkerhet, gjenoppretting, eksport og kritiske integrasjoner.
  6. Dokumenter beslutningen, restrisikoen og når den skal vurderes på nytt.

Den mer detaljerte guiden Hvordan velge riktig skyløsning for bedriften inneholder åtte vurderingsområder og en beslutningsmatrise.

Ofte stilte spørsmål

Er cloud billigere enn egen server?

Det avhenger av brukere, datamengde, kapasitetsvariasjon, funksjoner, drift, support og tidsperiode. Cloud kan redusere startinvesteringen. Egen eller dedikert server kan ha en annen kostnadsprofil, men drift og utskifting må regnes med.

Er cloud sikrere?

Ikke automatisk. En profesjonell skytjeneste kan gi sterke mekanismer og robust drift, mens virksomheten fortsatt må sikre kontoer, tilganger, konfigurasjon og data. Egen drift kan være sikker når den har tilstrekkelig kompetanse, kapasitet og kontroll.

Er server i eget lokale det samme som privat sky?

Nei. Privat sky beskriver et skymiljø avsatt til én virksomhet og kan driftes internt eller eksternt. En tradisjonell lokal server har ikke nødvendigvis egenskapene som kjennetegner en skytjeneste.

Kan en liten bedrift bruke en hybridmodell?

Ja, men den ekstra kompleksiteten må være begrunnet. Ansvar, identitet, logging, backup og dataflyt må fungere på tvers av miljøene.

Kilder og videre lesning

Artikkelen ble faglig oppdatert 19. september 2026. Udokumenterte prisintervaller og generelle konklusjoner er erstattet med en balansert sammenligning av ansvar, kostnad, sikkerhet, kontroll, tilgjengelighet og exit.

Illustrasjon av bedrift som velger mellom ulike skyløsninger

Hvordan velge riktig skyløsning for bedriften

Skrevet av Svein Tore den . Publisert i Teknologi. Ingen kommentarer til Hvordan velge riktig skyløsning for bedriften

Riktig skyløsning er den som dekker virksomhetens behov med akseptabel risiko, tydelig ansvar og en realistisk vei ut igjen. Pris og funksjoner er viktige, men valget bør også vurderes ut fra data, sikkerhet, tilgjengelighet, leverandøravhengighet, kompetanse og gjenoppretting.

En stor offentlig skytjeneste kan være tryggere og enklere å drifte enn en liten lokal installasjon. En privat eller driftet løsning kan samtidig gi større kontroll i enkelte situasjoner. Etiketten «sky», «privat» eller «norsk» avgjør ikke sikkerheten alene. Det avgjørende er hvordan tjenesten er bygget, avtalt, konfigurert, brukt og fulgt opp.

Start med behovet, ikke leverandøren

NSM anbefaler at verdi- og risikovurderingen gjøres før konkrete løsninger vurderes. En demonstrasjon kan være overbevisende, men den sier lite om hvor godt tjenesten passer virksomhetens kritiske arbeidsprosesser.

Beskriv først hva løsningen skal brukes til:

  • hvilke arbeidsprosesser den skal støtte
  • hvilke data den skal lagre eller behandle
  • hvor mange brukere, enheter og eksterne samarbeidspartnere den skal betjene
  • hvor lenge virksomheten kan være uten tjenesten
  • hvor mye data virksomheten kan tåle å miste
  • hvilke integrasjoner og eksportformater som må fungere

Dette gir kriterier som kan kontrolleres i stedet for en vag jakt på «den beste skyen».

Hva betyr offentlig, privat og hybrid sky?

NISTs definisjon av skytjenester skiller mellom tjenestemodeller og leveransemodeller. Begrepene beskriver ulike ting:

  • SaaS: Kunden bruker leverandørens ferdige applikasjon, for eksempel e-post eller dokumentbehandling.
  • PaaS: Kunden kjører egne applikasjoner på en plattform leverandøren drifter.
  • IaaS: Kunden får infrastruktur som prosessering, lagring og nettverk, men har mer ansvar for operativsystemer og applikasjoner.

En offentlig sky tilbys til mange kunder av en skyleverandør. En privat sky er avsatt til én virksomhet, men kan stå både hos virksomheten og hos en ekstern driftsleverandør. En hybrid sky kombinerer flere separate miljøer med en form for data- eller applikasjonsflyt mellom dem.

«Self-hosted» betyr vanligvis at virksomheten eller dens driftspartner kontrollerer applikasjonen og ofte mer av infrastrukturen. Det er ikke det samme som at løsningen står fysisk på kontoret. Plassering, eierskap og driftsansvar må undersøkes hver for seg.

1. Kartlegg data og regulatoriske krav

Finn ut hvilke personopplysninger, forretningshemmeligheter, regnskapsdata og andre verdier tjenesten skal håndtere. Vurder konfidensialitet, integritet og tilgjengelighet: Hvem kan få innsyn, hva skjer ved feilaktige endringer, og hva er konsekvensen av nedetid?

Databehandlerrollen må avklares når en leverandør behandler personopplysninger på vegne av virksomheten. Datatilsynet bruker lagring av kundeopplysninger i en annen virksomhets skytjeneste som eksempel på når databehandleravtale er nødvendig.

Kontroller hvor data behandles, hvilke underleverandører som benyttes, hvordan supporttilgang styres og hvilke overføringsmekanismer som gjelder dersom personopplysninger kan behandles utenfor EØS. Fysisk lagring i Europa svarer ikke alene på alle disse spørsmålene.

2. Avklar hvem som har ansvar for hva

Skyleverandøren og kunden deler ansvaret, men grensen flytter seg med tjenestemodellen. I en SaaS-tjeneste drifter leverandøren mer av teknologien, mens kunden fortsatt må håndtere brukere, tilganger, datakvalitet, innstillinger og ofte sikkerhetskopiering. I IaaS har kunden normalt et langt større ansvar for operativsystem, applikasjoner, nettverk og oppdatering.

Lag en ansvarsmatrise for minst disse oppgavene:

  • identiteter, flerfaktorautentisering og administratorroller
  • sikker konfigurasjon og oppdateringer
  • logging, varsling og hendelseshåndtering
  • sikkerhetskopi og gjenoppretting
  • dataklassifisering, sletting og eksport
  • oppfølging av underleverandører og avtaleendringer

Uklare mellomrom er farligere enn en modell med mer eller mindre kundekontroll. Det som ikke inngår i leveransen må ha en annen eier.

3. Vurder sikkerhetsmekanismene som faktisk er tilgjengelige

Be om dokumentasjon på sikkerhetsstyring, uavhengige revisjoner og relevante sertifiseringer, men ikke behandle et sertifikat som bevis på at deres bruk av tjenesten er sikker. Kontroller hvilke funksjoner som følger med abonnementet, hvilke som koster ekstra, og hvilke virksomheten må etablere selv.

Vurder blant annet:

  • phishing-resistent eller sterk flerfaktorautentisering
  • rollebasert tilgang og separate administratorkontoer
  • kryptering under overføring og lagring
  • kunde- eller leverandørstyrte nøkler når det er relevant
  • logger som kan eksporteres til uavhengig overvåking
  • varsling ved uvanlige innlogginger og administrative endringer
  • beskyttelse mot sletting og endring av data og sikkerhetskopier

Det britiske NCSC har fjorten prinsipper for vurdering av skyleverandører, blant annet databeskyttelse, sikker sletting, driftsmotstand, leverandørstyring, identitet og sikker bruk av tjenesten.

4. Mål tilgjengelighet i virksomhetens egen sammenheng

En oppetidsgaranti sier ikke nødvendigvis hvor raskt virksomheten er tilbake i arbeid. Tjenesten kan være tilgjengelig mens en konto, integrasjon, internettlinje eller lokal enhet er ute av drift. Undersøk også vedlikeholdsvinduer, støtte, statusinformasjon og hvordan leverandøren varsler hendelser.

Definer to praktiske mål:

  • Gjenopprettingstid: Hvor lenge kan prosessen være utilgjengelig?
  • Datatap: Hvor mye arbeid eller data kan virksomheten akseptere å miste?

Vurder deretter om virksomheten trenger offline arbeidsmåte, alternativ kommunikasjon, reserveforbindelse eller en manuell rutine mens tjenesten er nede.

5. Skill versjonshistorikk, redundans og backup

Redundans holder tjenesten tilgjengelig når utstyr feiler. Versjonshistorikk kan gjøre det mulig å hente en tidligere fil. Ingen av delene er automatisk en uavhengig sikkerhetskopi som beskytter mot kompromitterte administratorer, feilkonfigurasjon eller hendelser hos leverandøren.

Avklar hva leverandøren sikkerhetskopierer, hvor lenge kopiene beholdes, hvem som kan slette dem og hvordan en gjenoppretting bestilles. Virksomheten kan trenge en separat kopi utenfor tjenestens vanlige administrasjonsflate. 3-2-1-prinsippet hjelper med å spre risikoen, mens en gjenopprettingstest viser om kopiene faktisk kan brukes.

6. Test om virksomheten kan bytte leverandør

En exit-plan bør lages før avtalen signeres. Det er da virksomheten har best mulighet til å stille krav om eksport, bistand, frister og sletting.

Be om svar på disse spørsmålene:

  • Kan alle data, metadata, rettigheter og logger eksporteres?
  • Er eksportformatet dokumentert og lesbart av andre løsninger?
  • Hva skjer med integrasjoner, arbeidsflyter og automatiseringer?
  • Hvor lang tid tar en full eksport, og hva koster den?
  • Hvor lenge er data tilgjengelige etter oppsigelse?
  • Hvordan bekreftes sletting hos leverandør og underleverandører?

En liten prøveeksport er mer verdifull enn et generelt løfte om at data «kan tas ut». NSM anbefaler oversikt og kontroll gjennom hele livsløpet, sammen med bestillerkompetanse, risikovurdering og tydelige krav.

7. Beregn totalkostnaden over flere år

Sammenlign mer enn lisenspris. Ta med innføring, datamigrering, brukeradministrasjon, sikkerhetsfunksjoner, backup, integrasjoner, lagring, support, opplæring og framtidig utflytting. For infrastruktur kan også dataoverføring, trafikk og ressursforbruk påvirke regningen.

En egen eller privat løsning må på sin side inkludere maskinvare, datasenter, strøm, overvåking, oppdatering, beredskap og kompetanse. Kostnaden ved nedetid og manglende sikkerhet bør vurderes i begge modeller. Billigst per måned er ikke nødvendigvis lavest total risiko eller total kostnad.

8. Vurder kompetansen som kreves etter kjøpet

En tjeneste blir ikke ferdig forvaltet fordi den er skybasert. Virksomheten trenger fortsatt noen som administrerer brukere, følger opp varsler, gjennomgår tilganger, håndterer endringer og kontrollerer leverandøren.

Mer kontroll krever vanligvis mer driftskompetanse. Hvis virksomheten velger privat sky eller egen applikasjonsdrift, må ansvar for sikkerhetsoppdatering, kapasitet, logging, backup og hendelser være reelt bemannet. Hvis en driftspartner gjør arbeidet, bør leveransen være konkret og etterprøvbar.

En beslutningsmatrise som kan brukes i praksis

Gi hver kandidat en dokumentert vurdering for disse områdene:

  1. funksjonell dekning og brukervennlighet
  2. data, personvern og kontraktskrav
  3. identitet, logging og tekniske sikkerhetsmekanismer
  4. tilgjengelighet, støtte og beredskap
  5. backup og testet gjenoppretting
  6. integrasjoner, eksport og exit
  7. kompetanse og driftsansvar
  8. totalkostnad over avtaleperioden

Vekt områdene etter virksomhetens behov. En løsning som er best for en liten prosjektbedrift kan være feil for en virksomhet med lange oppbevaringskrav, sensitive data eller svært lav toleranse for nedetid.

Ofte stilte spørsmål

Er offentlig sky mindre sikker enn privat sky?

Ikke nødvendigvis. Store leverandører kan ha betydelig sikkerhetskompetanse og robuste driftsmiljøer. Privat sky kan gi mer kontroll, men kontroll må følges av kompetanse, vedlikehold og overvåking. Risikoen avgjøres av tjenesten, bruken og ansvarsdelingen.

Er data trygge hvis de lagres i Norge?

Norsk lagringssted kan være relevant, men svarer ikke alene på hvem som eier leverandøren, hvem som har administrativ tilgang, hvilke underleverandører som brukes, hvordan data sikres eller hvilke avtaler og regler som gjelder.

Må en bedrift ha egen backup av en SaaS-tjeneste?

Det avhenger av leverandørens gjenopprettingsmuligheter og virksomhetens krav. Avklar hva som inngår, hvilke hendelser som dekkes og om kopiene er tilstrekkelig uavhengige. Test gjenoppretting og eksport før en hendelse.

Hva er det viktigste kontrollspørsmålet?

Spør hva virksomheten selv fortsatt har ansvar for. Svaret avdekker ofte hull i tilgangsstyring, backup, overvåking og beredskap som ellers blir synlige først etter en hendelse.

Kilder og videre lesning

Artikkelen ble faglig oppdatert 18. september 2026. Begreper, ansvarsdeling, sikkerhet, gjenoppretting, exit og beslutningskriterier er presisert, og uferdige henvisninger er fjernet.

E-post som passerer tre kontroller for avsender, signatur og domene-policy.

SPF, DKIM og DMARC: e-postsikkerhet uten mystikk

Skrevet av Svein Tore den . Publisert i IT-sikkerhet. Ingen kommentarer til SPF, DKIM og DMARC: e-postsikkerhet uten mystikk

Oppdatert 8. september 2026.

`r`n`r`n

E-post er fortsatt en av de viktigste arbeidsflatene i små virksomheter. Den brukes til tilbud, fakturaer, kundehenvendelser, passordreset, møter, dokumenter og intern avklaring. Derfor blir e-post også misbrukt.

Et vanlig problem er at en svindler prøver å sende e-post som ser ut til å komme fra et kjent domene. Det kan være et forsøk på phishing, fakturasvindel eller innloggingstyveri. SPF, DKIM og DMARC er tre tekniske tiltak som gjør dette vanskeligere.

De løser ikke all e-postsikkerhet alene. De stopper ikke alle falske meldinger, og de erstatter ikke tofaktor, opplæring eller godt spamfilter. Men de gir mottakende e-postsystemer bedre grunnlag for å vurdere om en melding faktisk er sendt på vegne av domenet ditt.

Først: avsenderfeltet i e-post kan lyve

E-post ble ikke opprinnelig laget med sterk identitetskontroll. En melding kan vise en avsenderadresse som ser riktig ut, selv om meldingen teknisk kommer fra et annet sted.

Det betyr ikke at alle e-poster er upålitelige. Det betyr at domenet trenger noen ekstra kontroller. De viktigste er:

  • SPF: hvilke systemer har lov til å sende e-post for domenet?
  • DKIM: er meldingen signert av et system som har nøkkel for domenet?
  • DMARC: hva skal mottakere gjøre når SPF eller DKIM ikke stemmer med avsenderdomenet?

Tenk på dette som tre lag. SPF peker på godkjente sendekilder. DKIM signerer meldingen. DMARC knytter kontrollene til domenet mottakeren faktisk ser i Fra-feltet.

SPF: en liste over godkjente sendekilder

SPF står for Sender Policy Framework. I praksis er det en DNS-post som forteller hvilke servere eller tjenester som kan sende e-post for domenet.

For en virksomhet som bruker Microsoft 365, vil SPF ofte inneholde Microsoft sin e-postplattform. Hvis virksomheten også sender fra et nyhetsbrevverktøy, et regnskapssystem, en nettbutikk eller et kontaktskjema, må det vurderes om disse også er legitime sendekilder.

SPF handler derfor ikke bare om å lime inn en standardtekst. Det handler om å vite hvor e-post faktisk sendes fra.

Vanlige feil med SPF er:

  • domenet har ingen SPF-post
  • domenet har flere SPF-poster i stedet for én samlet
  • gamle tjenester står fortsatt som godkjente
  • nye tjenester mangler og får leveringsproblemer
  • hoveddomenet brukes til mange tredjepartstjenester uten ryddig oversikt

SPF er nyttig, men ikke komplett. Blant annet sjekker SPF den tekniske konvoluttavsenderen, ikke nødvendigvis domenet brukeren ser i Fra-feltet. Derfor trengs også DKIM og DMARC.

DKIM: en signatur på meldingen

DKIM står for DomainKeys Identified Mail. Med DKIM signeres utgående e-post kryptografisk. Mottakeren kan kontrollere signaturen mot en offentlig nøkkel som ligger i DNS.

Poenget er å vise at meldingen er sendt gjennom en løsning som har lov til å signere for domenet, og at viktige deler av meldingen ikke er endret underveis.

I Microsoft 365 krever DKIM for eget domene vanligvis at det legges inn CNAME-poster i DNS, og at DKIM aktiveres i riktig administrasjonsportal. Andre e-postleverandører har egne fremgangsmåter.

DKIM er spesielt nyttig fordi det tåler enkelte situasjoner bedre enn SPF, for eksempel når e-post videresendes. Men DKIM alene er heller ikke nok. En angriper kan signere e-post med et annet domene og likevel vise et annet navn i meldingen. DMARC hjelper med å kontrollere sammenhengen.

DMARC: policyen som binder det sammen

DMARC står for Domain-based Message Authentication, Reporting and Conformance. Det er også en DNS-post.

DMARC gjør to viktige ting:

  • den kontrollerer at domenet i SPF eller DKIM henger sammen med domenet mottakeren ser som avsender
  • den sier hva mottakende systemer bør gjøre når kontrollene feiler

DMARC kan settes opp gradvis. Mange starter med p=none, som gir rapportering uten at meldinger blokkeres. Når man har oversikt over legitime sendekilder, kan policyen strammes inn til quarantine eller reject.

For små virksomheter er dette viktig: ikke gå rett til streng blokkering hvis dere ikke vet hvilke systemer som faktisk sender e-post. Da kan kontaktskjema, fakturasystem, booking, nettbutikk eller gamle varsler plutselig slutte å levere.

Strengere krav fra store mottakere

E-postautentisering er ikke lenger bare en anbefalt forbedring for store utsendere. Googles krav til avsendere sier at alle som sender til personlige Gmail-kontoer må bruke SPF eller DKIM. Domener som sender mer enn 5 000 meldinger per dag til Gmail-kontoer, må bruke SPF, DKIM og DMARC, og minst SPF- eller DKIM-domenet må samsvare med domenet i Fra-feltet.

Microsoft innførte tilsvarende krav for domener som sender mer enn 5 000 meldinger per dag til forbrukeradresser hos Outlook, Hotmail og Live. Kravene omfatter SPF, DKIM og DMARC, med minst p=none for DMARC.

Disse tersklene gjelder store utsendelser til bestemte mottakertjenester. De betyr ikke at mindre virksomheter kan hoppe over autentisering. SPF, DKIM og DMARC beskytter også små domener mot etterligning og gjør feilsøking av leveringsproblemer enklere.

Hvorfor dette betyr noe for små virksomheter

Små virksomheter tenker ofte at dette er et problem for store selskaper. Det stemmer ikke. Et lite domene kan være attraktivt nettopp fordi mottakere stoler på det lokalt.

Hvis domenet misbrukes i falsk e-post, kan konsekvensen bli:

  • kunder får svindelmeldinger som ser ut til å komme fra virksomheten
  • ansatte blir lurt av meldinger som ser interne ut
  • e-post havner oftere i søppelpost
  • leverandører og kunder mister tillit
  • oppryddingen tar tid selv om virksomheten ikke ble teknisk kompromittert

God e-postautentisering handler derfor både om sikkerhet og om leveringskvalitet. Det hjelper andre e-postsystemer å skille legitim e-post fra misbruk.

Start med kartlegging, ikke DNS-endring

Den tryggeste starten er å lage en enkel liste over alle steder virksomheten sender e-post fra.

Sjekk særlig:

  • Microsoft 365, Google Workspace eller annen primær e-postløsning
  • webhotell eller gammel mailserver
  • kontaktskjema på nettsiden
  • WordPress, WooCommerce eller andre publiseringssystemer
  • regnskap, faktura og betalingsløsninger
  • nyhetsbrev og markedsføringsverktøy
  • CRM, supportsystem og booking
  • skrivere, skannere, overvåking og varsling

For hvert punkt bør dere spørre:

  • sender systemet e-post med vårt domene som avsender?
  • sender det direkte, via Microsoft 365, via webhotellet eller via en tredjepart?
  • finnes det dokumentasjon fra leverandøren om SPF, DKIM eller DMARC?
  • kan tjenesten heller sende fra et eget underdomene?

Denne kartleggingen er ofte mer verdifull enn selve DNS-endringen. Den viser også hvor det finnes gamle løsninger ingen lenger eier tydelig.

Ikke bruk hoveddomenet ukritisk til alt

Hvis mange tredjepartstjenester sender som firma.no, blir SPF og DMARC fort vanskeligere å kontrollere. For nyhetsbrev, kampanjer eller systemutsending kan det være bedre å bruke et underdomene, for eksempel nyheter.firma.no eller post.firma.no.

Det beskytter hoveddomenet bedre. Hvis en ekstern utsending feiler, påvirker det ikke nødvendigvis den vanlige e-posten fra ansatte like mye.

Dette må planlegges. Et underdomene som sender e-post trenger også riktig SPF, DKIM og DMARC. Poenget er ikke å skjule noe, men å skille ulike typer e-post tydeligere.

Vær forsiktig med gamle og doble DNS-poster

E-postproblemer oppstår ofte fordi DNS har blitt endret mange ganger over flere år. En virksomhet kan ha byttet webhotell, flyttet e-post til Microsoft 365, beholdt et kontaktskjema, lagt til et nyhetsbrevverktøy og senere glemt hva som fortsatt er i bruk.

Typiske faresignaler er:

  • flere TXT-poster som starter med v=spf1
  • SPF-poster med gamle leverandører ingen kjenner igjen
  • DMARC satt til p=none uten at noen leser rapportene
  • manglende DKIM for eget domene
  • tjenester som sender e-post uten å være dokumentert
  • ingen vet hvor DNS faktisk administreres

Rydding bør gjøres kontrollert. Ta vare på nåværende verdier før endring, og test sending fra viktige systemer etterpå.

En praktisk rekkefølge

For en liten virksomhet er en god rekkefølge ofte:

  1. Finn hvor DNS administreres.
  2. Lag liste over alle systemer som sender e-post.
  3. Kontroller eksisterende MX, SPF, DKIM og DMARC.
  4. Rett åpenbare feil, men ikke fjern ukjente sendekilder før de er vurdert.
  5. Aktiver eller kontroller DKIM hos primær e-postleverandør.
  6. Sett opp DMARC med rapportering.
  7. Følg med på rapporter og leveringsproblemer.
  8. Stram inn DMARC-policyen gradvis når legitime sendere er kartlagt.
  9. Dokumenter hvem som har ansvar for fremtidige endringer.

Dette er ikke et engangsprosjekt som aldri må sees på igjen. Hver gang virksomheten tar i bruk et nytt system som sender e-post, bør e-postautentisering vurderes.

Hva bør ikke gjøres i blinde?

Unngå disse snarveiene:

  • ikke kopier SPF fra en tilfeldig guide uten å vite egne sendekilder
  • ikke legg inn flere SPF-poster
  • ikke sett DMARC rett til reject uten kartlegging
  • ikke fjern gamle DNS-poster før du vet om de fortsatt brukes
  • ikke anta at webhotell, DNS og e-post ligger hos samme leverandør
  • ikke glem kontaktskjema, fakturasystem, nettbutikk og skannere

Det er også lurt å skille mellom e-postautentisering og innholdssikkerhet. SPF, DKIM og DMARC gjør domenemisbruk vanskeligere, men de garanterer ikke at en melding er trygg. En legitim konto kan fortsatt bli misbrukt hvis passordet er stjålet.

Kort oppsummert

SPF, DKIM og DMARC er grunnmuren for tryggere e-postdomener.

SPF sier hvilke systemer som kan sende. DKIM signerer meldinger. DMARC binder kontrollene til avsenderdomenet og gir en policy for hva mottakere bør gjøre når noe ikke stemmer.

For små virksomheter er beste start å kartlegge alle sendekilder, rydde gamle DNS-poster forsiktig, aktivere DKIM hos e-postleverandøren og bruke DMARC gradvis. Da blir domenet vanskeligere å misbruke, samtidig som legitim e-post får bedre sjanse til å komme frem.

Videre lesing

Illustrasjon av et finansbord med diagrammer, strømnett, datasenter og serverrack.

AI-boomen har en strømregning, og noen må betale den

Skrevet av Kasper Volden den . Publisert i Økonomi. Ingen kommentarer til AI-boomen har en strømregning, og noen må betale den

AI-markedet liker å snakke om modeller, agenter, produktivitet og fremtidige marginer. Det er forståelig. Det høres bedre ut enn transformatorstasjoner, kjølevann, nettleie, serverrack og kapitalbinding. Men regningen kommer ikke i form av et poetisk whitepaper. Den kommer i megawatt, leverandørkontrakter, avskrivninger og kraftpriser.

Det betyr ikke at AI-boomen er falsk. Tvert imot. Noe av grunnen til at den er interessant, er nettopp at den ikke bare er programvare. Den bygger fysisk kapasitet i stor skala. Men det betyr også at investorer, virksomheter og politikere bør slutte å late som AI først og fremst er en app med litt bedre autofullføring.

AI er blitt industri.

Og industri har kostnader.

Brikkene er bare starten

Nvidia er fortsatt det tydeligste symbolet på AI-kappløpet. Selskapet meldte i mai 2026 om svært sterk vekst i datasentersegmentet i sin rapport for første kvartal i regnskapsåret 2027. Markedet liker slike tall fordi de gjør AI-fortellingen konkret. Noen kjøper faktisk kapasitet. Noen bygger faktisk datasentre. Noen betaler faktisk for brikkene.

Men brikker alene er ikke AI-infrastruktur. De må installeres, kobles sammen, mates med strøm, kjøles, sikres, vedlikeholdes og finansieres. Kunnskapsrom har tidligere skrevet om Nvidia, chips og AI-infrastruktur. Hovedpoenget er fortsatt undervurdert: AI-boomen er et forsyningskappløp.

Hvis én del av kjeden stopper, hjelper det lite at presentasjonen fortsatt har fine gradienter.

Strøm er ikke en detalj

Det internasjonale energibyrået IEA har i rapporten Energy and AI pekt på hvordan datasentre og AI kan bli en betydelig ny belastning i kraftsystemet. Det betyr ikke at AI alene kommer til å spise hele strømnettet, slik noen overskrifter liker å late som. Men det betyr at kraft, nett, kjøling og lokalisering blir en del av AI-regnestykket.

For investorer er dette viktig. En AI-satsing kan se ut som en programvarecase, men ha kostnadsbase som en industribedrift. Capex, strømavtaler, datasenterleie, nedkjøling, nettverksutstyr og maskinvareoppgraderinger kan spise av marginene.

Det er en litt kjedelig observasjon. Markedet liker ikke kjedelige observasjoner. Derfor er de ofte nyttige.

Kapitalen følger fortellingen

Kapitalmarkedet elsker store fortellinger. Før var det sky. Så var det krypto. Nå er det AI. Fortellingen er ikke nødvendigvis feil, men den kan bli for enkel. Når alle ser samme vekstkurve, er det lett å glemme at vekstkurver har baksider.

Kunnskapsrom har tidligere skrevet om hvordan AI åpner IPO-vinduet, og hvorfor børsnoteringer i AI ikke bare handler om hype, men også om kapitalbehov. Det er et viktig skille. AI-selskaper trenger ofte penger fordi de skal vokse. Men de trenger også penger fordi infrastrukturen er dyr.

Da bør investorene spørre mer presist. Er inntektene skalerbare på samme måte som kostnadene? Har selskapet langsiktige kraftavtaler? Hvem eier datasenterkapasiteten? Hvor raskt blir maskinvaren utdatert? Hvor stor del av veksten er reell kundeadopsjon, og hvor mye er kapasitet som bygges fordi alle tror alle andre trenger mer kapasitet?

Dette er ikke kynisme. Det er analyse uten konfetti.

Norge kan få en rar rolle

Norge har kraft, kjølig klima, kompetanse og politisk interesse for digital infrastruktur. Det gjør oss relevante i datasenterdiskusjonen. Men det betyr ikke at alle datasenterprosjekter automatisk er samfunnsnyttige.

Hvis kraft er knapp lokalt, må man spørre hva den brukes til. Industri? Boliger? Elektrifisering? Datasentre? AI-trening? Kryptomining? Eksport av digitale tjenester? Hver bruk kan være legitim, men de konkurrerer likevel om kapasitet.

Artikkelen om AI, datasentre, strøm og vann tar opp nettopp dette. AI er ikke løsrevet fra naturressurser. Den er koblet til areal, vann, strømnett og politiske prioriteringer.

Når teknologiselskaper snakker om skyen, høres det nesten vektløst ut. Men skyen står på tomter, trekker kabler og sender fakturaer.

Kundene bør også følge med

Dette angår ikke bare investorer. Norske virksomheter som kjøper AI-tjenester, bør forstå at leverandørenes kostnadsstruktur kan påvirke pris, tilgjengelighet og binding.

Hvis AI-kapasitet er dyr, vil kostnaden komme et sted. Kanskje i abonnementet. Kanskje i begrensninger. Kanskje i databruk. Kanskje i at leverandøren optimaliserer hardere for å holde marginene oppe. Kundene bør derfor spørre hva de egentlig kjøper: modelltilgang, datalagring, analyse, prosessering, support, sikkerhet og integrasjoner er ikke samme ting.

Dette henger også sammen med kontrollspørsmålet. Når en virksomhet gjør seg avhengig av AI-verktøy i drift, kundeservice, analyse eller utvikling, blir leverandørens infrastruktur en del av virksomhetens egen risiko. Det er litt mindre glamorøst enn å si "vi har tatt i bruk AI". Men det er mer nyttig.

Fortellingen er sterk, men ikke gratis

AI kan godt være en ekte teknologisk transformasjon. Det betyr ikke at alle AI-investeringer er gode, eller at alle kostnader forsvinner fordi modellen svarer pent i demoen.

Markedet bør klare to tanker samtidig: AI kan skape stor verdi, og AI kan være overinvestert i enkelte lag. Begge deler kan være sant. Det er ofte der de interessante analysene ligger.

Så når noen sier at AI er fremtiden, er det greit å spørre: Hvilken del av fremtiden? Hvem eier kapasiteten? Hvor kommer strømmen fra? Hvor raskt må maskinvaren byttes? Og hvem betaler når regningen kommer?

Digital magi er fint. Men også magi trenger strøm.

Videre lesing

Illustrasjon av et datasenter koblet til strømnett, vann og AI-infrastruktur.

AI har fått et strømproblem: datasentre, vann og den fysiske prisen for kunstig intelligens

Skrevet av Svein Tore den . Publisert i Teknologi. Ingen kommentarer til AI har fått et strømproblem: datasentre, vann og den fysiske prisen for kunstig intelligens

Kunstig intelligens blir ofte beskrevet som noe lett, digitalt og nesten kroppsløst. Vi snakker om modeller, agenter, chatvinduer, API-er, søk, automatisering og produktivitet. Men bak alt dette står en mer jordnær virkelighet: servere, brikker, strøm, kjøling, vann, fiber, transformatorer, tomter, byggeprosesser og lokale kraftnett.

AI er ikke bare programvare. AI er infrastruktur.

Det er derfor datasentre plutselig er blitt en av de viktigste teknologihistoriene. Når flere virksomheter tar i bruk AI, øker behovet for beregning. Når behovet for beregning øker, bygges flere datasentre. Når flere datasentre bygges, møter AI-sektoren den fysiske verden: energikapasitet, lokale nettkøer, vannressurser, varme, støy, arealkonflikter og politiske prioriteringer.

Dette betyr ikke at AI er "for dyrt" eller "for skadelig" i seg selv. Den typen enkel dom hjelper lite. Spørsmålet er heller hva vi får igjen for ressursbruken, hvem som kontrollerer infrastrukturen, hvor dataene behandles, og om samfunnet er ærlig nok om kostnadene før det lar AI bli et altoverskyggende argument.

For Norge er dette spesielt relevant. Vi har relativt ren kraft, kjølig klima, fiberforbindelser, datasenterambisjoner og et sterkt behov for digital suverenitet. Samtidig har vi også kraftkonflikter, naturhensyn, industri som trenger elektrifisering, og offentlige tjenester som ikke kan overlate alle data og prosesser til globale plattformer uten kritiske spørsmål.

Det nye AI-kappløpet starter i strømnettet

Det er fristende å tenke på AI-kapasitet som noe man bare kan kjøpe i skyen. Man trykker på en knapp, får tilgang til en modell, og betaler for bruk. Men skyen er ikke et sted uten friksjon. Den er en samling fysiske datasentre som må mates med strøm og kjøles kontinuerlig.

IEA har beskrevet sammenhengen brutalt enkelt: Det finnes ingen AI uten energi, særlig strøm til datasentre. I rapporten *Energy and AI* peker IEA på at datasentre allerede er en tydelig del av global strømvekst fram mot 2030. Selv om datasentre fortsatt bare er én del av det totale energibildet, kan veksten bli svært merkbar lokalt fordi belastningen konsentreres i bestemte regioner, byer og nettnoder.

Dette er en viktig nyanse. Globalt kan datasentre fortsatt være mindre enn mange andre strømforbrukere. Lokalt kan de likevel være enorme. Et datasenterprosjekt på flere hundre megawatt kan være større enn mye eksisterende industri i området. Det kan utløse behov for nettforsterkning, nye kraftavtaler, reservekraft og politiske beslutninger om hvem som skal få tilgang først.

AI skjerper dette fordi moderne AI-bruk ikke bare handler om lagring og webtrafikk. Store modeller krever tung trening, og like viktig: stadig mer inferens. Inferens er når modellen faktisk brukes. Hver gang noen ber en modell analysere en kontrakt, skrive kode, oppsummere et møte eller svare i et søk, kjøres beregninger. Når AI bygges inn i kontorprogrammer, nettlesere, søk, kundeservice, produksjon, sikkerhet og økonomisystemer, blir strømbehovet en del av normal digital drift.

Det er derfor artikkelen om Nvidia, chips og AI-infrastruktur ikke kan leses isolert. Brikker er bare første del av kjeden. Når brikkene leveres, må de settes inn i datasentre. Når datasentrene bygges, må kraft og kjøling følge etter.

Kjøling er ikke en detalj

En server som regner tungt, lager varme. En hel hall full av AI-servere lager svært mye varme. Den varmen må bort. Hvis ikke faller ytelsen, maskinvaren slites, eller systemene stopper.

Tradisjonelle datasentre har ofte brukt luftkjøling, men tettere AI-rack og kraftigere GPU-klynger skyver bransjen mot mer avansert væske- og hybridkjøling. Dette kan være mer effektivt, men det gjør ikke ressursdiskusjonen irrelevant. Noen løsninger bruker mindre vann, men mer strøm. Andre bruker mer vann for å spare energi. Noen kan bruke lukkede kretsløp. Andre er avhengige av lokale vannressurser eller fordampningskjøling.

IEA peker på at kjølesystemer kan utgjøre en betydelig del av datasentrenes strømforbruk, med store forskjeller mellom effektive hyperskala-anlegg og eldre eller mindre effektive anlegg. Det betyr at datasentre ikke er like. To datasentre med samme IT-kapasitet kan ha svært ulik påvirkning på strøm, vann og lokale ressurser.

For en kommune eller region er dette avgjørende. Det holder ikke å spørre hvor stort datasenteret er. Man må spørre hvordan det kjøles, hvor mye vann det trenger, om overskuddsvarme kan brukes, hvor fleksibelt forbruket er, og hva som skjer i tørkeperioder eller ved kraftknapphet.

Her er det lett å drukne i tekniske forkortelser. PUE måler forholdet mellom total energibruk og IT-energi. WUE måler vannbruk per IT-energi. Begge kan være nyttige, men de kan også skjule viktige forhold hvis de brukes ukritisk. Lav PUE er ikke automatisk lav miljøbelastning hvis kraften er fossil eller vannbruken er høy i et vannstresset område. Lav WUE er ikke automatisk best hvis løsningen flytter belastningen over på strømnettet i et område med knapp kapasitet.

Det viktigste spørsmålet er derfor ikke om datasenteret har fine effektivitetstall. Det viktigste er om tallene gir mening i den lokale virkeligheten.

Vannspørsmålet kommer til å bli mer politisk

Strøm får mest oppmerksomhet, men vann kan bli den mest konfliktfylte ressursen i enkelte områder. Datasentre kan bruke vann direkte til kjøling, indirekte gjennom kraftproduksjon, og indirekte gjennom produksjon av maskinvare. Det betyr at vannfotavtrykket ikke alltid er synlig på tomten der datasenteret står.

I områder med god vanntilgang er dette mindre dramatisk enn i tørre regioner. Men vann er ikke bare et globalt gjennomsnitt. Det er lokalt. Et datasenter som er uproblematisk ett sted, kan være politisk uholdbart et annet sted.

Dette er grunnen til at rapportering og åpenhet blir viktig. Lokalsamfunn bør få vite hvor mye vann som brukes, hvilke perioder som er mest belastende, hvilke kilder som brukes, og om anlegget konkurrerer med husholdninger, landbruk eller annen industri. Uten slike data blir debatten fort preget av enten skremsel eller glansbilder.

Vannspørsmålet er også et eksempel på hvorfor AI ikke bør behandles som en unntakskategori. Det at et datasenter brukes til AI, gjør ikke automatisk prosjektet mer samfunnsnyttig enn andre kraft- og vannkrevende formål. En AI-klynge som støtter forskning, helse, sikkerhet, språkmodeller og industri kan ha høy samfunnsverdi. En like stor klynge brukt til aggressiv annonseoptimalisering, spekulativ handel eller datadrevet manipulasjon har en annen verdi.

Ressursbruken bør vurderes opp mot bruken. Det høres selvfølgelig ut, men i praksis blir "AI" ofte brukt som et magisk ord som gjør prioriteringen uklar.

Norge har fordeler, men ikke gratis kapasitet

Norge har flere egenskaper som gjør landet interessant for datasentre. Vi har mye fornybar kraft sammenlignet med mange andre land, kjøligere klima, politisk stabilitet og god digital infrastruktur. I tillegg har vi et legitimt behov for mer kontroll over data, særlig i offentlig sektor, forskning, helse og kritisk infrastruktur.

Men Norge har ikke ubegrenset strøm. Kraftsystemet er allerede gjenstand for konflikt. Industri, elektrifisering, transport, husholdninger, batteriproduksjon, hydrogen, datasentre og nye grønne prosjekter konkurrerer om kapasitet, nett og politisk oppmerksomhet.

Derfor bør norske datasenterprosjekter vurderes konkret. Hvilken type kapasitet bygges? Hvem er kundene? Hvor mye lokal verdiskaping gir prosjektet? Gir det arbeidsplasser og kompetanse, eller bare store bygg med lav bemanning? Kan overskuddsvarme brukes? Belaster det nettkapasitet som andre samfunnsformål trenger? Er det transparent nok til at lokalsamfunnet kan vurdere fordeler og ulemper?

Et norsk datasenter kan være en del av en god strategi for digital suverenitet. Men det er ikke automatisk suverent bare fordi det ligger i Norge. Eierskap, driftsmodell, underleverandører, programvarelag, tilgangskontroll og juridiske avtaler betyr også noe. Hvis et datasenter i Norge i praksis styres av en global plattform, med uklare dataveier og avhengigheter til tredjeland, er bildet mer komplisert.

Dette er samme grunnproblem som i tidligere Kunnskapsrom-artikler om datasuverenitet, private skyer og self-hosted skylagring. Fysisk plassering er viktig, men ikke nok.

Datadeling er den skjulte infrastrukturen

Når en virksomhet bruker AI, er det lett å se strømforbruket som datasenterets problem og datadeling som IT-avdelingens problem. I virkeligheten henger de sammen. Valget av AI-leverandør bestemmer ofte både hvor beregningen skjer og hvor dataene flyter.

Hvis ansatte bruker en ekstern AI-tjeneste til dokumentanalyse, kundesaker, kode, økonomirapporter eller interne strategier, sendes data ut av virksomheten. Spørsmålet er ikke bare om modellen er god. Spørsmålet er hvor dataene behandles, om de logges, om de brukes til trening eller forbedring, hvilke underleverandører som inngår, og hvilke lands lover som kan komme til anvendelse.

Dette blir mer kritisk når AI-verktøy blir agentiske. En enkel chatbot får gjerne ett spørsmål og ett svar. En agent kan lese mapper, analysere kildekode, hente logger, kjøre kommandoer, koble seg til systemer og produsere endringer. Det er kraftig. Det er også en mye dypere form for datatilgang.

AI-datasentre er derfor ikke bare et spørsmål om strøm og vann. De er også et spørsmål om kontroll. Når mer arbeid flyttes til AI-systemer, flyttes også mer informasjon til infrastrukturen bak. Det kan være helt greit når dataene er offentlige eller ufarlige. Det kan være uforsvarlig når dataene er sensitive, personlige, konkurransekritiske eller knyttet til sikkerhet.

En god AI-strategi bør derfor koble tre ting: energibruk, datakontroll og verdi. Hva brukes AI-en til? Hvilke data krever den? Hvilken infrastruktur kjører den på? Hvilken samfunnsnytte eller forretningsnytte rettferdiggjør ressursbruken?

AI kan også hjelpe energisystemet

Det er viktig å ikke gjøre dette til en ensidig dom over AI. AI kan også bidra positivt i energisystemet. Bedre prognoser, mer fleksibelt forbruk, prediktivt vedlikehold, styring av bygg, optimalisering av nett og mer effektiv industri kan redusere sløsing. IEA peker også på at AI kan ha betydelig potensial for effektivisering i bygg og kraftsystemer.

Men det positive potensialet fritar ikke datasentre fra krav. En teknologi kan både være nyttig og ressurskrevende samtidig. Nettopp derfor må den styres godt.

Det mest interessante spørsmålet er ikke om AI bruker strøm. Alt digitalt bruker strøm. Spørsmålet er om AI-bruken gir nok verdi til å forsvare ressursene, og om de mest ressurskrevende bruksområdene faktisk er de viktigste.

Her bør offentlige innkjøpere, store virksomheter og datasenteraktører ta mer ansvar. Det bør være mulig å stille krav til energieffektivitet, vannrapportering, regionvalg, overskuddsvarme, databehandling, underleverandører og beredskap uten at det oppfattes som teknologifiendtlighet.

Hva virksomheter bør gjøre nå

Det første virksomheter bør gjøre, er å kartlegge AI-bruken. Hvilke tjenester brukes allerede? Hvilke data sendes inn? Hvilke leverandører ligger bak? Hvilke regioner behandles data i? Hvilke funksjoner er bare pilot, og hvilke har blitt kritisk drift?

Det andre er å klassifisere data. Offentlig informasjon, interne rutiner, personopplysninger, kundedata, sikkerhetslogger, kildekode og forretningshemmeligheter kan ikke behandles likt. En tjeneste som er grei for åpne tekster, kan være uegnet for kundedata.

Det tredje er å stille krav til leverandører. Spør om datalagring, logging, modelltrening, underleverandører, region, sletting, revisjon og hendelseshåndtering. Spør også om energibruk og bærekraftsrapportering der det er relevant. Ikke fordi alle kunder skal bli datasenterrevisorer, men fordi leverandører må merke at kontroll betyr noe.

Det fjerde er å vurdere lokale eller mer kontrollerte alternativer for sensitive arbeidsflyter. Det betyr ikke at alt må kjøres på egne servere. Det betyr at virksomheten bør ha flere nivåer: åpne data kan bruke én type løsning, sensitive data en annen, og virksomhetskritiske prosesser en tredje.

Det femte er å unngå å gjøre AI til standardvalg uten nyttevurdering. Noen oppgaver trenger ikke en stor modell. Noen kan løses med en mindre modell, en regelmotor, et søk, et script eller bedre informasjonsarkitektur. Den mest bærekraftige AI-bruken er ofte den som er presis nok, ikke størst mulig.

En enkel prioriteringsmodell for AI-kapasitet

For å gjøre diskusjonen mer praktisk kan virksomheter og offentlige aktører sortere AI-bruk i fire nivåer.

Første nivå er lavrisiko og lav ressursbruk. Det kan være åpne tekster, generell idéutvikling, språkvask, enkle oppsummeringer og eksperimenter uten sensitive data. Her er det ofte fornuftig å bruke standardverktøy, så lenge ansatte forstår hva som ikke skal deles.

Andre nivå er intern produktivitet. Her brukes AI på dokumenter, møteoppsummeringer, interne rutiner, kodeforklaring eller analyse. Verdien kan være stor, men datadeling blir mer alvorlig. Virksomheten bør vite om data lagres, om de kan brukes til modellforbedring, og hvilke underleverandører som inngår.

Tredje nivå er sensitiv fagbruk. Det kan være helse, juridiske vurderinger, sikkerhetslogger, kundedata, offentlige saksdokumenter eller konkurransesensitiv informasjon. Her bør man vurdere kontrollerte miljøer, streng tilgangsstyring, logging, dataminimering og klare ansvarsforhold.

Fjerde nivå er kritisk automatisering. Da får AI-systemer påvirke drift, beslutninger, produksjon, økonomi, sikkerhet eller infrastruktur. Her er det ikke nok at modellen er god. Hele systemet må kunne revideres, stoppes, forklares og drives videre hvis leverandøren endrer vilkår eller kapasitet forsvinner.

Denne typen sortering gjør det lettere å koble ressursbruk til verdi. En stor ekstern modell kan være helt grei for enkelte åpne oppgaver, men feil valg for sensitive prosesser. En lokal eller privat løsning kan være unødvendig dyr for enkle oppgaver, men riktig for data som ikke bør forlate virksomhetens kontroll.

Offentlig sektor bør være ekstra tydelig

Offentlig sektor har et særskilt ansvar fordi den forvalter både innbyggerdata og samfunnstillit. Når AI tas i bruk i kommuner, helse, utdanning, politi, skatt, NAV-lignende tjenester eller saksbehandling, blir datadeling og infrastrukturvalg demokratiske spørsmål, ikke bare tekniske.

En kommune som bruker AI til å effektivisere interne rutiner, kan få reell nytte. Men dersom dokumenter med personopplysninger eller sårbare livssituasjoner sendes til uklare tredjepartsløsninger, kan effektiviseringen bli dyr på en annen måte. Det samme gjelder skole og helse, der data ofte er både sensitive og vanskelige å anonymisere godt nok.

Offentlig sektor bør derfor ikke bare spørre om en AI-tjeneste har europeisk datasenter. Den bør spørre om hele behandlingskjeden: modell, logging, support, underleverandører, tilgangsstyring, sikkerhetskopier, sletting, revisjon og juridisk kontroll. Et datasenter i riktig region hjelper lite hvis støttepersonell, analyseverktøy eller treningsprosesser trekker data videre.

Dette er ikke et argument mot offentlig AI-bruk. Det er et argument for å bygge den på infrastruktur som tåler innsyn. Hvis innbyggerne skal stole på AI i offentlig sektor, må de kunne stole på at dataene ikke blir en skjult råvare i globale plattformer.

Hva kommuner og myndigheter bør spørre om

Når et datasenterprosjekt kommer til en kommune, bør spørsmålene være konkrete. Hvor mye effekt krever prosjektet? Når på døgnet er belastningen størst? Hvordan kjøles anlegget? Hvor mye vann brukes, og fra hvilken kilde? Hva skjer ved tørke, kraftknapphet eller beredskapssituasjoner? Hvilken lokal verdi skapes? Kan overskuddsvarme brukes? Hvem eier og drifter anlegget? Hvilke kunder er aktuelle? Finnes det sikkerhets- og beredskapsmessige hensyn?

Kommunen trenger ikke vite alt om AI for å stille gode spørsmål. Den trenger å vite at datasentre er industriell infrastruktur, ikke bare "digital næring". De bør behandles med samme alvor som andre store kraft- og arealkrevende prosjekter.

For staten handler det om prioritering. Hvis AI skal være en del av norsk konkurransekraft, forskning, språk, helse og offentlig sektor, trenger vi infrastruktur. Men hvis all kapasitet kontrolleres av globale aktører, blir suvereniteten svak. Hvis alle prosjekter får ja uten prioritering, blir kraftpolitikken svak. Begge deler kan være problematisk.

Konklusjon: AI må ned på bakken

AI-debatten trenger mindre magi og mer infrastrukturforståelse. Kunstig intelligens er ikke bare modeller og apper. Det er datasentre, strøm, vann, kjøling, nett, brikker, leverandørkjeder og databehandling.

Det betyr ikke at AI-boomen bør stoppes. Det betyr at den bør styres. Vi bør bygge kapasitet der den gir reell verdi, med åpenhet om ressursbruk og streng kontroll med data. Vi bør skille mellom AI som styrker forskning, industri og samfunn, og AI som bare øker datainnsamling, avhengighet og energiforbruk uten klar nytte.

For Norge kan dette bli en mulighet. Men bare hvis vi er ærlige om at AI har en fysisk pris, og at den prisen må vurderes før strøm, vann og data låses inn i andres infrastruktur.

Videre lesing

Illustrasjon av en AI-brikke koblet til serverrack og leverandørledd.

Nvidia, chips og AI-infrastruktur: hvorfor AI-boomen er blitt et forsyningskappløp

Skrevet av Svein Tore den . Publisert i Teknologi. Ingen kommentarer til Nvidia, chips og AI-infrastruktur: hvorfor AI-boomen er blitt et forsyningskappløp

Nvidia er blitt mer enn et teknologiselskap. Det er blitt en målestokk for hvor hardt verden bygger ut kunstig intelligens. Når Nvidia rapporterer rekordsalg, tolkes det ikke bare som en bedriftsnyhet. Det leses som et signal om hvor mye kapital, strøm, datasenterplass og optimisme som fortsatt strømmer inn i AI-økonomien.

I mai 2026 rapporterte Nvidia 81,6 milliarder dollar i kvartalsomsetning for første kvartal i regnskapsåret 2027, opp 85 prosent fra året før. Datasenterinntektene var 75,2 milliarder dollar, opp 92 prosent fra året før. Dette er tall som nesten er vanskelige å plassere i en normal teknologifortelling. De viser at AI ikke lenger bare er et programvaretema. Det er et industriprosjekt.

Men Nvidia-historien blir lett for smal. Den reduseres ofte til aksjekurs, markedsverdi og spørsmålet om man "burde kjøpe Nvidia". Det er en overflatisk vinkel. Den dypere historien er at AI-boomen har gjort datakraft til en knapp ressurs. Det handler om GPU-er, høybåndbredde-minne, avansert pakking, fabrikkapasitet, nettverk, strøm, kjøling, datasentre og leverandørmakt.

For norske lesere er dette ikke bare interessant for investorer. Det påvirker prisen på skytjenester, tilgangen til AI-verktøy, bygging av datasentre, nasjonal forskningsinfrastruktur og muligheten til å drive AI mer lokalt. Den som forstår AI som ren programvare, ser bare halvparten av bildet.

AI trenger maskiner før den trenger magi

Det er lett å snakke om AI som om det er et abstrakt intellekt i skyen. I praksis er det enorme mengder matematikk kjørt på fysisk maskinvare. Modeller trenes og kjøres på brikker. Brikkene står i servere. Serverne står i datasentre. Datasentrene trenger strøm, kjøling, nettverk, tomt, avtaler, kapital og mennesker.

Nvidia har lykkes fordi selskapet lenge bygde et økosystem rundt GPU-er, programvareverktøy, bibliotek, nettverk og akselerert databehandling. Da generativ AI eksploderte, var Nvidia allerede plassert midt i verdikjeden. Mange AI-aktører trengte ikke bare en brikke. De trengte et fungerende system for å trene og kjøre modeller i stor skala.

Dette er grunnen til at Nvidia kan ha en så dominerende posisjon selv om konkurrenter finnes. Det er vanskelig å bytte når hele verktøykjeden, kompetansen og infrastrukturen er bygget rundt én plattform. Det er ikke umulig, men det tar tid.

Samtidig gjør dominansen markedet sårbart. Når mange vil ha de samme brikkene, de samme serverne og den samme produksjonskapasiteten, oppstår flaskehalser. Etterspørselen kan være reell, men leveringen kan likevel bli begrenset.

Chips er bare ett lag i kjeden

En AI-chip alene skaper ikke AI-kapasitet. Den må settes inn i et system. Det systemet trenger minne med ekstrem båndbredde, rask internkommunikasjon, nettverk mellom noder, effektiv kjøling og programvare som utnytter maskinvaren. Hvis ett lag mangler, hjelper det ikke at resten er klart.

Høybåndbredde-minne er et godt eksempel. Store AI-modeller flytter enorme datamengder mellom beregning og minne. Hvis minnet ikke leverer raskt nok, står dyre beregningsenheter og venter. Derfor er minneleverandører som SK Hynix, Samsung og Micron viktige i AI-økonomien, selv om Nvidia får de største overskriftene.

Avansert brikkeproduksjon er et annet lag. Nvidia designer mye selv, men produksjonen er avhengig av leverandører som TSMC og et helt økosystem av utstyr, materialer og pakkingsteknologi. Dette gjør AI-boomen til en geopolitisk historie. Taiwan, USA, Sør-Korea, Japan, Nederland og andre land er koblet inn i samme strategiske verdikjede.

Nettverk er et tredje lag. Når tusenvis av GPU-er skal jobbe sammen, er intern kommunikasjon avgjørende. Forsinkelser, flaskehalser og ustabilitet kan redusere verdien av dyr maskinvare. Derfor handler AI-infrastruktur ikke bare om "flest mulig chips", men om helhetlige systemer.

Dette er en viktig korreksjon til den enkle fortellingen. Nvidia er viktig, men Nvidia alene er ikke AI. AI-kapasitet oppstår når hele den fysiske og digitale infrastrukturen fungerer sammen.

Datasenterinntektene sier hvor markedet egentlig er

Nvidias datasentertall viser at AI-bølgen først og fremst drives av store kunder med enorme infrastrukturbehov. Hyperskalere, AI-laboratorier, datasenteraktører, forskningsmiljøer, industrielle aktører og stater kjøper ikke grafikkort for hobbybruk. De bygger kapasitet.

Når datasenterinntektene er størstedelen av omsetningen, betyr det at AI-markedet har beveget seg fra demonstrasjoner til drift. Modeller skal trenes, finjusteres, tilbys som API, brukes i søk, kode, dokumentbehandling, kundeservice, analyse, robotikk og forskning. Alt dette krever kapasitet.

Men veksten reiser også et spørsmål: Hvor mye av etterspørselen er langsiktig produktivitet, og hvor mye er kappløp? Store aktører kjøper kapasitet fordi de trenger den, men også fordi de ikke har råd til å stå uten. I AI-markedet kan mangel på beregning bety lavere modellkvalitet, tregere produktutvikling og svakere posisjon i markedet.

Dette kan skape en selvforsterkende dynamikk. Når én aktør bygger mer, må andre bygge mer. Når modeller blir større eller mer agentiske, trengs mer inferenskapasitet. Når brukerne får nye AI-funksjoner i søk, kontorprogrammer, kodeverktøy og telefoner, øker grunnlasten.

Det betyr ikke at veksten kan fortsette uendelig. Men det forklarer hvorfor AI-infrastruktur foreløpig ser mer ut som et industrielt utbyggingskappløp enn en vanlig programvaretrend.

Hva skjer hvis Nvidia ikke kan levere nok?

Når etterspørselen er større enn leveringskapasiteten, oppstår tre mulige reaksjoner. Den første er prispress. Kunder betaler mer for kapasitet, og kostnaden kan etter hvert sendes videre til brukere av AI-tjenester. Gratis eller billige AI-verktøy kan bli dyrere, mer begrenset eller pakket inn i abonnementer.

Den andre reaksjonen er prioritering. Store kunder med store kontrakter kan få tilgang først. Mindre aktører kan bli stående lenger bak i køen. Dette kan gjøre AI-markedet mer konsentrert, fordi de som allerede har kapital og volum, får bedre tilgang til kapasitet.

Den tredje reaksjonen er diversifisering. Google har TPU-er, Amazon har egne Trainium- og Inferentia-brikker, Microsoft investerer i egne og partnerbaserte løsninger, og flere selskaper bygger spesialiserte akseleratorer. Kundene ønsker alternativer, ikke nødvendigvis fordi Nvidia er dårlig, men fordi én dominerende leverandør er en strategisk risiko.

Likevel er det vanskelig å bryte ut av et etablert økosystem. Programvare, modeller, optimalisering og kompetanse er ofte bygget rundt Nvidia. Derfor kan alternativer vokse samtidig som Nvidia fortsatt dominerer.

For virksomheter som kjøper AI-tjenester indirekte, er dette relevant. Hvis leverandøren deres er avhengig av én type infrastruktur, kan pris, ytelse og tilgjengelighet påvirkes av samme flaskehals. AI i skyen føles elastisk, men er fortsatt bundet til fysiske begrensninger.

Norsk vinkel: superdatamaskiner og suveren kapasitet

Norge er ikke Nvidia, TSMC eller Silicon Valley. Men Norge trenger likevel AI-infrastruktur. Forskning, industri, helse, offentlig sektor, energi og språkmodeller for norske forhold krever datakraft. Hvis all kapasitet må kjøpes fra globale skyleverandører, får vi både kostnads-, kontroll- og datadelingsspørsmål.

Sigma2s superdatamaskin Olivia med Nvidia Grace Hopper-brikker viser at behovet også finnes her. Norsk forskning trenger moderne GPU-kapasitet for simulering, maskinlæring, klimamodellering, biovitenskap, materialforskning og andre beregningstunge områder. Slike investeringer er ikke bare tekniske oppgraderinger. De handler om hvor mye avansert forskning som kan gjøres lokalt.

Dette kobler AI-infrastruktur til datasuverenitet. Hvis norske virksomheter og forskningsmiljøer alltid må sende data og beregning til globale plattformer, blir kontrollspørsmålet mer krevende. Hvor behandles data? Hvem har tilgang? Hvilke avtaler gjelder? Hvilke jurisdiksjoner kan gripe inn?

Kunnskapsrom har tidligere skrevet om datasuverenitet og private skyer. AI gjør disse temaene mer aktuelle. Det er ikke nok å spørre om man har tilgang til en modell. Man må også spørre hvor modellen kjører, hvor data flyter, og om man kan kontrollere infrastrukturen når kravene skjerpes.

Chips, energi og datasentre henger sammen

AI-infrastruktur stopper ikke ved brikken. Når flere GPU-er kjøpes, må flere servere bygges. Når flere servere bygges, trengs mer strøm, kjøling, fiber, reservekraft og fysisk plass. Derfor henger Nvidia-historien tett sammen med datasenter- og energihistorien.

IEA peker på at datasentrenes strømbehov kan vokse kraftig fram mot 2030. Det betyr at AI ikke bare konkurrerer om brikker, men også om energi. Et datasenter med verdens beste GPU-er er lite verdt uten stabil kraft og kjøling.

Dette skaper nye geografiske muligheter. Steder med stabil kraft, kaldt klima, god fiber og politisk forutsigbarhet kan bli mer attraktive. Norge har noen av disse egenskapene. Men det betyr ikke at alle datasenterprosjekter automatisk er gode. De må vurderes mot kraftbalanse, naturinngrep, lokal nytte, arbeidsplasser, varmegjenvinning og beredskap.

AI-kappløpet kan altså gi Norge muligheter, men også konflikter. Skal kraft brukes til datasentre, industri, elektrifisering eller husholdninger? Hvem får verdien? Hvor mye lokal kontroll finnes? Hva skjer med vann- og arealbruk? Disse spørsmålene bør stilles før man lar "AI" bli et magisk ord som overstyrer alt annet.

Datadeling og skyleverandører

Når AI-kapasitet er knapp, kan virksomheter bli fristet til å bruke den løsningen som er lettest tilgjengelig. Det kan være en global AI-plattform, en skytjeneste, en API-leverandør eller et ferdig produkt. Det er forståelig. Men datadeling må fortsatt vurderes.

Hvis en virksomhet bruker ekstern AI-infrastruktur til kundedata, dokumenter, kode, logger eller interne analyser, må den vite hva som skjer med dataene. Brukes de til modellforbedring? Lagres de? Hvem er underleverandør? Hvilket land behandles dataene i? Kan virksomheten slette dem? Er tjenesten egnet for personopplysninger?

Dette er særlig viktig for AI-kodeagenter, analyseverktøy og dokumentverktøy. De kan gi stor nytte, men de fungerer ofte best når de får mye kontekst. Mye kontekst betyr også mye data. I en travel organisasjon kan terskelen for å laste opp "bare denne filen" bli lav. Det er der risikoen ligger.

En god regel er å behandle AI-infrastruktur som en ekstern databehandler, ikke som et nøytralt regneverktøy. Hvis dataene ikke ville blitt sendt ukritisk til en tilfeldig konsulent, bør de heller ikke sendes ukritisk til en AI-tjeneste.

Hva bør norske virksomheter følge med på?

Det første er pris og tilgjengelighet på AI-tjenester. Hvis beregningskostnaden fortsetter å være høy, vil leverandørene lete etter måter å prise bruken mer presist. Det kan bety grenser, kredittsystemer, høyere abonnementer eller prioriterte bedriftsplaner.

Det andre er leverandørenes regioner og databehandling. Spør hvor AI-tjenesten kjører, hvilke regioner som brukes, og om det finnes europeiske eller norske alternativer når dataene krever det.

Det tredje er modellvalg. Den beste modellen er ikke alltid nødvendig. Mange oppgaver kan løses med mindre modeller, lokale modeller eller mer avgrensede systemer. Det kan spare kostnad, redusere datadeling og gi bedre kontroll.

Det fjerde er intern kompetanse. Virksomheter bør ikke outsource all forståelse av AI-infrastruktur til leverandøren. De trenger nok kompetanse til å stille riktige spørsmål om kapasitet, kostnad, sikkerhet og data.

Det femte er beredskap. Hva skjer hvis en AI-tjeneste blir dyrere, tregere eller utilgjengelig? Har man en alternativ arbeidsflyt? Kan kritiske prosesser kjøres uten AI? Hvilke data ligger allerede i leverandørens systemer?

Anskaffelser blir et strategisk spørsmål

For virksomheter som skal kjøpe AI-kapasitet, er den viktigste endringen at anskaffelsen ikke lenger bare handler om pris per bruker eller pris per API-kall. Den handler om kontroll over en hel kjede. Det gjelder hvor data sendes, hvilke underleverandører som kan få tilgang, hvor logging skjer, hvilke modeller som brukes, hvordan trening og finjustering håndteres, og hvor lett det er å flytte seg senere.

Dette er særlig viktig når AI brukes på interne dokumenter, kildekode, kundedata, avvik, sikkerhetshendelser eller forretningskritisk kunnskap. Det hjelper lite at en leverandør har verdens beste GPU-er hvis kontrakten åpner for uklar viderebruk av data, uoversiktlige tredjepartsledd eller manglende kontroll med jurisdiksjon. AI-infrastruktur kan gi stor verdi, men den kan også bli en ny kanal for dataeksponering.

En moden anskaffelse bør skille mellom minst fire behov. Det første er eksperimentering med offentlig eller ufarlig informasjon. Det andre er produktivitetsverktøy for ansatte. Det tredje er analyse av interne eller sensitive data. Det fjerde er virksomhetskritisk automatisering. Disse behovene kan ikke behandles likt. De har ulik risikoprofil, ulike krav til databehandleravtaler og ulik toleranse for leverandørlås.

For mange norske virksomheter vil en hybrid strategi være mest realistisk. Offentlige skytjenester kan brukes der risikoen er lav og gevinstene er raske. Private eller mer kontrollerte løsninger bør vurderes der dataene er sensitive, der regulatoriske krav er strenge, eller der virksomheten ikke vil gjøre seg helt avhengig av én global AI-leverandør. Dette er samme grunnlogikk som i diskusjonen om privat sky for bedrifter og datasuverenitet.

Leverandørlås er mer enn en teknisk irritasjon

Når AI-infrastruktur bygges rundt én plattform, kan flyttekostnaden bli høy. Det gjelder ikke bare Nvidia. Det gjelder også modell-API-er, skyarkitektur, vektordatabaser, orkestreringsverktøy, sikkerhetslag og observability-løsninger. Hver liten avhengighet kan være fornuftig isolert sett. Samlet kan de likevel gjøre virksomheten tung å flytte.

Leverandørlås betyr ikke at man alltid skal unngå de beste leverandørene. Det betyr at man må vite hva man bytter bort. En virksomhet kan legitimt velge en dominerende plattform fordi den gir kvalitet, stabilitet og fart. Men valget bør tas med åpne øyne. Hvis hele AI-strategien forutsetter én leverandørs API, én brikkefamilie, én skyregion og én prismodell, har man ikke bare kjøpt teknologi. Man har tatt et strategisk avhengighetsvalg.

Derfor bør virksomheter stille noen praktiske spørsmål tidlig. Kan data eksporteres i åpne formater? Kan arbeidsflyten kjøres mot flere modeller? Kan sensitive deler holdes utenfor eksterne tjenester? Kan logging skrus av eller begrenses? Finnes det en plan for hva som skjer hvis prisene endres, en region stenges, eller vilkårene for databruk endres?

Dette er normal driftshygiene i en tid der AI-verktøy flytter raskt inn i kjerneprosessene. Jo mer nyttig AI blir, desto viktigere blir kontrollen rundt den.

Investorer bør se bredere enn Nvidia

For investorer er Nvidia fortsatt en nøkkelaksje i AI-fortellingen, men den bør ikke være hele analysen. AI-infrastruktur består av mange lag: brikker, minne, produksjonsutstyr, nettverk, datasentre, kraft, kjøling, programvare, sikkerhet og applikasjoner.

Noen selskaper tjener på selve brikkene. Andre tjener på serverbygging, kraftavtaler, fiber, minne, eiendom, kjøling eller programvare. Noen kan få sterk vekst, men også store kapitalkrav. Andre kan få mer stabile marginer fordi de selger nødvendige støttefunksjoner.

Det er også risiko for overbygging. Hvis alle bygger datasenterkapasitet basert på svært optimistiske AI-prognoser, kan markedet senere få overskudd i enkelte regioner eller segmenter. Samtidig kan det være knapphet i andre deler, som strømtilgang eller minne. AI-infrastruktur er derfor ikke én enkel kurve oppover. Det er et komplekst investeringslandskap.

Den viktigste investeringslærdommen er kanskje den samme som for teknologiinnkjøp: Se på flaskehalsene. Der det finnes knapphet, finnes ofte prisingsmakt. Der det finnes avhengighet, finnes risiko.

Konklusjon: AI er blitt fysisk

Nvidia viser hvor kraftig AI-boomen er, men også hvor fysisk den er. Kunstig intelligens er ikke bare modeller, apper og chatvinduer. Det er chips, minne, nettverk, datasentre, strøm, kjøling og leverandørkjeder.

For norske virksomheter betyr dette at AI-strategi ikke kan stoppe ved "hvilket verktøy skal vi bruke?" Den må også handle om datadeling, leverandøravhengighet, kostnad, region, sikkerhet og beredskap. For samfunnet betyr det at AI-politikk også blir energipolitikk, industripolitikk og infrastrukturpolitikk.

Nvidia er en hovedperson i historien. Men den virkelige historien er større: Verden bygger en ny beregningsindustri i høyt tempo. Den som vil forstå AI i 2026, må forstå maskinene bak.

Det er også derfor små valg i dag kan bli store bindinger senere. Hvilken sky man bruker, hvilken modellplattform man bygger rundt, og hvilke data man tillater inn i verktøyene, former handlingsrommet neste år. AI-infrastruktur bør derfor behandles som et langsiktig styringsvalg, ikke som et raskt innkjøp av kapasitet.

Videre lesing

Illustrasjon av datasentre og digitale nettverk som viser kontroll over data og datasuverenitet

Hva er datasuverenitet?

Skrevet av Svein Tore den . Publisert i IT-sikkerhet. 2 kommentarer til Hva er datasuverenitet?

Datasuverenitet handler om hvilke rettslige, organisatoriske og tekniske rammer som styrer data. Begrepet brukes ofte om hvor data lagres, men lagringssted alene gir ikke et fullstendig svar. Virksomheten må også vite hvem som driver infrastrukturen, hvem som kan administrere tjenesten, hvilke underleverandører som brukes, hvilket lovverk leverandøren er underlagt, og om data faktisk kan flyttes eller slettes.

Datasuverenitet er derfor ikke en sertifisering eller én bestemt teknisk løsning. Det er en måte å undersøke kontroll på gjennom hele datalivsløpet, fra innsamling og bruk til eksport, arkivering og sletting.

Datasuverenitet, datalagring og datalokalisering er ikke det samme

Tre begreper brukes ofte om hverandre:

  • Datalagring eller data residency: den geografiske regionen eller landet der bestemte data lagres.
  • Datalokalisering: et krav om at bestemte data skal lagres eller behandles innenfor et geografisk område.
  • Datasuverenitet: hvilke lover, aktører, avtaler og tekniske kontrollmuligheter som påvirker dataene.

En tjeneste kan lagre kundedata i Norge, men fortsatt bruke utenlandske underleverandører, fjernadministrasjon eller et morselskap underlagt et annet lands lovgivning. Motsatt kan behandling i et annet EØS-land være lovlig og godt sikret. Derfor må den faktiske dataflyten undersøkes.

Fem kontrollspørsmål

1. Hvor lagres og behandles dataene?

Kartlegg regioner og land for aktive data, replikaer, sikkerhetskopier, logger, diagnostikk og supportdata. Be leverandøren skille mellom data i ro og data som behandles midlertidig. Et regionnavn i et administrasjonspanel må leses sammen med produktvilkårene.

2. Hvem kontrollerer leverandøren og infrastrukturen?

Eierstruktur og selskapskontroll kan ha betydning fordi leverandøren kan være underlagt flere lands lover. Samtidig er det for enkelt å anta at utenlandsk eierskap automatisk gjør en tjeneste ulovlig eller usikker. Vurderingen må bygge på konkrete data, avtaler, lovgrunnlag og risiko.

3. Hvem har teknisk tilgang?

Undersøk administratorroller, supporttilgang, underleverandører og hvordan tilgang logges og godkjennes. Kryptering reduserer risiko, men effekten avhenger blant annet av hvem som kontrollerer nøklene og om leverandøren kan få tilgang under behandling eller support.

4. Kan virksomheten dokumentere og revidere kontrollen?

Avtalen bør beskrive datalokasjoner, underleverandører, sikkerhetstiltak, avvik, revisjonsmuligheter, varsling ved endringer og sletting ved opphør. Standardvilkår må vurderes opp mot virksomhetens egne krav.

5. Kan data og tjenester flyttes?

Kontroll omfatter også muligheten til å avslutte. Virksomheten bør kjenne eksportformat, metadata, integrasjoner, tidsbruk, kostnader og hvilke funksjoner som går tapt ved leverandørbytte. En exit-plan som aldri er testet, er bare en antakelse.

Personopplysninger og overføring ut av EØS

For personopplysninger er det viktig å skille mellom lagringssted og tredjelandsoverføring. Datatilsynet forklarer at behandling i EØS i utgangspunktet ikke er en overføring ut av EØS. Likevel kan fjernaksess, underleverandører eller tredjelands lovgivning gjøre det nødvendig med en grundigere analyse.

All overføring av personopplysninger ut av EØS krever et gyldig grunnlag. Virksomheten må kontrollere om grunnlaget virker i praksis og om tilleggstiltak er nødvendige. Datatilsynets veiledning om overføring ut av EØS beskriver kravene og eksemplene nærmere.

Datasuverenitet er bredere enn personvern. En virksomhet kan også ha krav knyttet til sikkerhetsloven, kontrakter, bransjeregler, taushetsplikt, beredskap eller forretningskritisk tilgjengelighet. Hvilke krav som gjelder, avhenger av virksomheten og dataene.

CLOUD Act og andre lands lovgivning

CLOUD Act brukes ofte som eksempel på at fysisk plassering ikke alltid avgjør hvem som kan fremme et rettslig krav mot en leverandør. Loven kan under bestemte vilkår brukes til å kreve data fra amerikanske tjenesteleverandører også når data lagres utenfor USA.

Det betyr ikke at amerikanske myndigheter har fri eller automatisk tilgang til alle data hos amerikanske selskaper. Rettslige krav må følge prosesser og vilkår, og leverandøren kan ha mulighet eller plikt til å vurdere og bestride kravet. Les den mer detaljerte forklaringen av CLOUD Act og amerikanske skytjenester.

Nasjonal kontroll er et strengere behov

For enkelte samfunnskritiske eller sikkerhetssensitive tjenester er spørsmålet større enn ordinær etterlevelse av personvernreglene. NSM bruker begrepet nasjonal kontroll om evnen norske myndigheter og virksomheter har til å styre, beskytte og opprettholde viktige IKT-tjenester.

NSM understreker at personell som driver underliggende infrastruktur kan ha teknisk kontroll selv om serveren står i Norge. Behovet for nasjonal kontroll må derfor vurderes på tvers av eierskap, kompetanse, drift, leverandørkjede, tilgjengelighet og muligheten til å opprettholde tjenesten i en krise. Dette er beskrevet i NSMs rapport om nasjonal kontroll av IKT-tjenester.

Ikke alle virksomheter trenger samme kontrollnivå. Kravet må følge verdien av dataene, konsekvensen av bortfall og relevante lover og avtaler.

Self-hosted er ikke automatisk mer suverent

En self-hosted løsning kan gi større kontroll over plassering, konfigurasjon og tilgang. Men virksomheten overtar også ansvar for oppdateringer, overvåking, sårbarheter, kapasitet, backup og gjenoppretting. Dersom driften fortsatt avhenger av én leverandør, proprietære komponenter eller kompetanse virksomheten ikke har, kan kontrollen være mindre enn den ser ut.

Artikkelen om hva self-hosted skylagring betyr forklarer ansvarsdelingen. Sammenlign også cloud og egen server på sikkerhet, ansvar, kostnad og exit-mulighet før dere velger modell.

EU Data Act styrker muligheten til å bytte skytjeneste

EUs Data Act gjelder i EU fra 12. september 2025. Reglene skal blant annet redusere tekniske, kontraktsmessige og kommersielle hindringer ved bytte mellom databehandlingstjenester eller tilbakeføring til egen infrastruktur.

Dette gir ikke automatisk full portabilitet mellom alle produkter. Komplekse applikasjoner, integrasjoner og leverandørspesifikke funksjoner kan fortsatt gjøre et bytte krevende. Men reglene styrker forventningen om tydelige avtalevilkår, eksport av relevante data og bistand i overgangsprosessen. EU-kommisjonens forklaring av Data Act beskriver reglene for skytjenestebytte.

En praktisk vurdering i åtte trinn

  1. Klassifiser dataene. Dokumenter følsomhet, kritikalitet, eiere og formål.
  2. Kartlegg dataflyten. Ta med lagring, behandling, support, logger, backup og underleverandører.
  3. Identifiser lovkrav. Vurder personvern, sikkerhet, bransjeregler, avtaler og taushetsplikt.
  4. Undersøk leverandørkjeden. Se på eierskap, driftssteder, administratorer og rettslig tilknytning.
  5. Kontroller nøklene. Avklar hvem som kan dekryptere data og hvordan nøklene forvaltes.
  6. Les avtalen. Kontroller endringsvarsling, revisjon, sletting, underleverandører og hendelseshåndtering.
  7. Test eksport og gjenoppretting. Bekreft at data, metadata og nødvendige konfigurasjoner kan brukes utenfor tjenesten.
  8. Revurder ved endringer. Gjenta vurderingen når leverandør, tjeneste, dataflyt eller regelverk endres.

NSM anbefaler oversikt og kontroll gjennom hele livsløpet, god bestillerkompetanse og risikovurdering før valg av løsning. Veiledningen om tjenesteutsetting og skytjenester er et nyttig utgangspunkt for krav og oppfølging.

Vanlige spørsmål

Er data suverene hvis de lagres i Norge?

Ikke nødvendigvis. Norsk lagringssted kan være et viktig krav, men eierskap, driftstilgang, underleverandører, krypteringsnøkler, lovgivning og exit-mulighet må også vurderes.

Er en norsk leverandør alltid det tryggeste valget?

Nei. En norsk leverandør kan gi kortere leverandørkjede og enklere jurisdiksjon, men sikkerheten avhenger fortsatt av kompetanse, arkitektur, avtaler og drift. Store internasjonale tjenester kan samtidig ha sterke sikkerhetsmiljøer. Valget må bygge på risiko og krav.

Er datasuverenitet det samme som GDPR?

Nei. GDPR regulerer behandling av personopplysninger. Datasuverenitet brukes bredere om rettslig, teknisk og organisatorisk kontroll over data, også når informasjonen ikke er personopplysninger.

Kan virksomheten kjøpe full datasuverenitet?

Ingen produktetikett gir full kontroll alene. Reell kontroll krever dokumentert dataflyt, tydelige avtaler, tekniske tiltak, kompetanse, revisjon og en fungerende exit-plan.

Konklusjon

Datasuverenitet handler om mer enn serverens adresse. Virksomheten må forstå hvor data flyter, hvem som kan kontrollere tjenesten, hvilke lover som kan gjelde og om den kan gjenopprette eller flytte data når behovet oppstår.

Den riktige løsningen er derfor ikke alltid den mest lokale eller den største. Det er løsningen som møter dokumenterte krav til konfidensialitet, integritet, tilgjengelighet, etterlevelse og handlefrihet gjennom hele livsløpet.

Illustrasjon av self-hosted skyløsning der en virksomhet kontrollerer egne servere og lagring.

Fordeler og ulemper med self-hosted skyløsninger

Skrevet av Svein Tore den . Publisert i IT-sikkerhet. Ingen kommentarer til Fordeler og ulemper med self-hosted skyløsninger

Self-hosted skyløsninger kan gi virksomheten større innflytelse over hvor data lagres, hvordan løsningen settes opp og når endringer gjennomføres. Men kontrollen kommer ikke av installasjonsformen alene. Den må bygges med tydelig ansvar, riktig kompetanse, gode driftsrutiner og en plan som også virker når noe går galt.

Det riktige spørsmålet er derfor ikke bare om virksomheten skal velge «egen server eller sky». Spør heller: Hvem skal ha ansvar for hvert lag i løsningen, hvilke krav må oppfylles, og kan vi dokumentere at løsningen faktisk kan driftes og gjenopprettes?

Hva betyr self-hosted i praksis?

En self-hosted løsning er programvare som virksomheten selv, eller en valgt driftspartner, installerer og forvalter. Den kan kjøre på servere i egne lokaler, i et norsk datasenter eller på virtuelle servere hos en skyleverandør. Self-hosted betyr altså ikke nødvendigvis at maskinvaren står på kontoret.

Det avgjørende er hvor mye virksomheten kan styre selv: programvareversjoner, administratorer, nettverk, sikkerhetskopier, krypteringsnøkler, datalagring og eksport. Les også vår forklaring av hva self-hosted skylagring betyr.

Fordel 1: Mer påvirkning på arkitektur og datalagring

Med self-hosting kan virksomheten i større grad velge hvor data og sikkerhetskopier skal ligge, hvilke administratorer som skal ha tilgang, og hvordan systemet skal kobles til andre tjenester. Det kan være viktig når virksomheten har særskilte krav til datalokalisering, integrasjoner eller segmentering av nettverket.

Dette er likevel ikke det samme som «full kontroll». En ekstern driftspartner, datasenterleverandør, programvareleverandør og underleverandører kan fortsatt ha teknisk eller kontraktsmessig innflytelse. Kartlegg derfor alle lag, ikke bare landet serveren står i. Artikkelen om datasuverenitet forklarer forskjellen mellom lagringssted, lovverk og faktisk tilgang.

Fordel 2: Større frihet til å tilpasse

Self-hosted programvare gir ofte flere muligheter til å velge oppdateringstidspunkt, integrere mot interne systemer og tilpasse arbeidsflyter. Det kan være verdifullt når en standardisert abonnementstjeneste ikke dekker behovet.

Tilpasning har samtidig en kostnad. Egne utvidelser må testes ved oppgraderinger, dokumenteres og vedlikeholdes. Jo mer løsningen avviker fra standardoppsettet, desto større blir risikoen for at neste versjon krever ekstra arbeid.

Fordel 3: Bedre mulighet for en reell exit-plan

Åpne filformater, dokumenterte grensesnitt og tilgang til komplette eksporter kan gjøre det enklere å flytte data og tjenester. Men self-hosting fjerner ikke automatisk leverandøravhengighet. Virksomheten kan bli avhengig av en bestemt driftsplattform, konsulent, programvareutvidelse eller kompetanse som få personer har.

Test derfor flyttbarheten i praksis: Kan data eksporteres med nødvendige metadata? Kan en ny leverandør lese eksporten? Hvor lang tid tar det å bygge opp tjenesten et annet sted? NSM anbefaler en klar exit-strategi og peker på åpne, standardbaserte løsninger som et middel mot uønsket leverandørlåsing.

Ulempe 1: Driftsansvaret blir tydeligere og større

Self-hosted flytter ansvar. Noen må overvåke tjenesten, installere sikkerhetsoppdateringer, fornye sertifikater, styre tilganger, følge med på lagringskapasitet og håndtere hendelser. Dette gjelder også når løsningen kjører på en virtuell server hos en ekstern leverandør.

NSM understreker at sikkerhetstiltak er nødvendige uavhengig av hvem som forvalter tjenesten. Ved tjenesteutsetting endres grensen mellom interne og eksterne oppgaver, men virksomhetens behov for risikovurdering, bestillerkompetanse og livsløpskontroll forsvinner ikke.

Ulempe 2: Backup er ikke det samme som gjenoppretting

En sikkerhetskopi har liten verdi før virksomheten vet at den kan leses tilbake. En robust løsning trenger separate kopier, beskyttelse mot at samme administrator eller angrep kan slette både produksjonsdata og backup, og jevnlige gjenopprettingstester.

Avklar også målene på forhånd: Hvor mye data kan virksomheten tåle å miste, og hvor lenge kan tjenesten være utilgjengelig? Svarene avgjør hvor ofte det må tas kopier, hvor raskt reservekapasitet må være tilgjengelig og hva driftsavtalen faktisk må dekke. Se vår praktiske veiledning om backup som beredskap.

Ulempe 3: Kostnaden ligger i hele livsløpet

Lisensen er bare én del av regnestykket. Ta med server- eller skykapasitet, overvåking, oppdateringer, backup, testmiljø, hendelseshåndtering, kompetanse, dokumentasjon og utskifting av maskinvare. En løsning kan være rimelig ved oppstart og kostbar når den skal være tilgjengelig hele døgnet.

For stabile arbeidsmengder og et kompetent driftsmiljø kan self-hosting gi forutsigbarhet. For små miljøer uten tilgjengelig driftskompetanse kan en standardisert skytjeneste være både sikrere og mer økonomisk. Sammenlign alternativene i Cloud vs. egen server.

Ulempe 4: Etterlevelse blir ikke automatisk enklere

Valg av serverplassering løser ikke alene spørsmål om personvern, tilgang, databehandlere, logging, sletting eller beredskap. Virksomheten må vite hvilke data som behandles, hvorfor de behandles, hvem som har tilgang og hvordan kravene dokumenteres.

Det samme gjelder sikkerhet. En self-hosted løsning kan være godt sikret når den forvaltes systematisk, men den kan også bli stående med gamle versjoner og svak overvåking. NSM påpeker at virksomheten har sikkerhetsansvaret uansett hvor tjenesten kjører, og at ansvar mellom kunde og leverandør må avklares konkret.

En beslutningsmatrise i seks punkter

Før virksomheten velger løsning, bør den dokumentere svar på disse spørsmålene:

  1. Data og krav: Hvilke opplysninger skal behandles, hvor sensitive er de, og finnes det krav til lagringssted, tilgang eller sletting?
  2. Ansvar: Hvem oppdaterer operativsystem, applikasjon og utvidelser? Hvem overvåker, og hvem svarer ved en hendelse?
  3. Tilgjengelighet: Hvor lenge kan tjenesten være nede, og hvor mye data kan gå tapt uten alvorlige konsekvenser?
  4. Gjenoppretting: Finnes det adskilte sikkerhetskopier, dokumentert prosedyre og en nylig vellykket gjenopprettingstest?
  5. Total kostnad: Er drift, kompetanse, overvåking, testmiljø og beredskap regnet inn, ikke bare lisens og server?
  6. Exit: Kan data, konfigurasjon og nødvendige metadata flyttes til en annen plattform eller leverandør innen akseptabel tid?

Gi hvert punkt en ansvarlig person, et dokumentert krav og en måte å kontrollere resultatet på. Da blir vurderingen sammenlignbar, og beslutningen hviler ikke på generelle påstander om at én driftsmodell alltid er sikrest.

En driftspartner kan være et mellomvalg

Virksomheten trenger ikke velge mellom å gjøre alt selv og å kjøpe en helt standardisert abonnementstjeneste. En driftspartner kan forvalte en self-hosted løsning i et valgt datasenter, mens virksomheten beholder avtalte rettigheter til data, eksport og endringskontroll.

Dette mellomvalget fungerer bare når avtalen er konkret. Den bør beskrive oppdateringsfrister, overvåking, backup, gjenoppretting, responstid, administratorroller, underleverandører og bistand ved flytting. Be også om dokumentasjon og testresultater, ikke bare en formulering om at leverandøren «tar backup».

Konklusjon

Self-hosted skyløsninger passer best når virksomheten har et tydelig behov for kontroll eller tilpasning, og samtidig kan finansiere og organisere hele driftsansvaret. Løsningen er ikke automatisk sikrere, billigere eller fri for leverandøravhengighet.

Ta beslutningen ut fra data, risiko, tilgjengelighetskrav, kompetanse og en testet exit-plan. Da blir self-hosting et bevisst arkitekturvalg i stedet for et løfte om kontroll som ingen har kapasitet til å følge opp.

Illustrasjon av self-hosted skylagring der en virksomhet kontrollerer egne servere og datalagring

Self-hosted skylagring – hva betyr det egentlig?

Skrevet av Svein Tore den . Publisert i Teknologi. Ingen kommentarer til Self-hosted skylagring – hva betyr det egentlig?

Mange virksomheter lagrer i dag dokumenter, bilder og interne filer i tjenester som Google Drive, Dropbox eller Microsoft 365. Det fungerer enkelt: du oppretter en konto, laster opp filene dine, og alt ligger tilgjengelig på nettet.

Men noen virksomheter velger en helt annen modell. De bruker såkalt self-hosted skylagring. Da ligger ikke dataene i infrastrukturen til en global leverandør – de ligger i en løsning virksomheten selv kontrollerer.

Hva betyr egentlig self-hosted skylagring i praksis, og hvorfor velger noen virksomheter dette?

Hva betyr self-hosted skylagring?

Self-hosted skylagring betyr ganske enkelt at skyløsningen driftes på servere du selv kontrollerer.

Det kan være:

  • en server i egne lokaler
  • en server i et norsk datasenter
  • en privat sky driftet av en leverandør på vegne av virksomheten

Forskjellen fra tradisjonelle skyløsninger er at infrastrukturen ikke eies av en global plattformleverandør.

Virksomheten bestemmer selv:

  • hvor dataene lagres
  • hvem som har tilgang
  • hvordan systemet driftes
  • hvilke sikkerhetsregler som gjelder

Teknologien kan fortsatt fungere som en moderne skyløsning. Brukerne kan synkronisere filer mellom PC, mobil og nettleser akkurat som i andre skylagringstjenester.

Forskjellen ligger i hvem som kontrollerer infrastrukturen bak løsningen.

Forskjellen på self-hosted og vanlig skylagring

For å forstå konseptet bedre, er det nyttig å sammenligne modellene.

Tradisjonell skylagring

I tjenester som Google Drive eller Microsoft OneDrive lagres filene i datasentrene til leverandøren. Hele infrastrukturen – servere, nettverk og programvare – kontrolleres av plattformleverandøren.

Virksomheten får tilgang til systemet gjennom abonnement.

Fordelen er at alt er ferdig satt opp. Det krever lite teknisk arbeid.

Ulempen er at kontrollen over infrastrukturen i praksis ligger hos leverandøren.

Self-hosted skylagring

I en self-hosted løsning installeres skylagringsplattformen på en server virksomheten kontrollerer.

Programvaren kan være for eksempel:

  • Nextcloud
  • ownCloud
  • Seafile

Her fungerer programvaren som selve skylagringstjenesten, men infrastrukturen er under egen kontroll.

Brukerne opplever ofte løsningen på samme måte som andre skylagringstjenester: filer kan deles, synkroniseres og åpnes fra ulike enheter.

Forskjellen er at dataene ligger i en løsning virksomheten selv styrer.

Hvorfor velger noen virksomheter self-hosted skylagring?

Valget handler sjelden om teknologi alene. Det handler ofte om kontroll.

Mange virksomheter oppdager etter hvert at skyløsninger ikke bare handler om lagringsplass. De handler også om eierskap til infrastrukturen dataene ligger i.

Når data lagres hos en global leverandør, er det leverandøren som kontrollerer:

  • datasentre
  • lagringssystemer
  • tilgangsstruktur
  • teknisk plattform

I en self-hosted modell flyttes denne kontrollen nærmere virksomheten.

Dette kan være viktig for organisasjoner som jobber med:

  • sensitive dokumenter
  • forskningsdata
  • kundedata
  • interne strategidokumenter

Det betyr ikke nødvendigvis at self-hosted alltid er mer sikkert, men det gir virksomheten større kontroll over hvordan sikkerheten bygges opp.

Datasuverenitet og jurisdiksjon

Et begrep som ofte dukker opp i denne diskusjonen er datasuverenitet.

Det handler om hvem som i praksis har juridisk tilgang til dataene dine.

Når data lagres hos globale leverandører, kan flere juridiske forhold påvirke situasjonen. Blant annet:

  • nasjonal lovgivning
  • internasjonale avtaler
  • myndighetskrav til datatilgang

Dette er en av grunnene til at noen virksomheter ønsker løsninger hvor infrastrukturen er plassert i et bestemt land eller under en bestemt jurisdiksjon.

Self-hosted skylagring gjør dette mulig fordi virksomheten selv bestemmer hvor serverne står.

Hvordan fungerer self-hosted skylagring i praksis?

Teknisk sett fungerer løsningen ofte ganske likt andre skylagringstjenester.

Et typisk oppsett kan se slik ut:

  1. En server installeres i et datasenter eller lokalt.
  2. Skylagringsprogramvaren installeres på serveren.
  3. Brukere opprettes med egne kontoer.
  4. Klientprogrammer installeres på PC og mobil.

Når dette er gjort, kan brukerne:

  • laste opp filer
  • synkronisere mapper
  • dele dokumenter
  • samarbeide om filer

Alt skjer gjennom den samme typen grensesnitt som man kjenner fra vanlige skyløsninger.

Forskjellen er at systemet drives i en infrastruktur virksomheten selv kontrollerer.

Er self-hosted skylagring riktig for alle?

Selv om self-hosted kan gi mer kontroll, betyr ikke det at det alltid er riktig valg.

Det finnes klare fordeler med ferdige skyløsninger:

  • rask oppstart
  • minimal drift
  • ferdige integrasjoner
  • høy brukervennlighet

For små virksomheter uten tekniske ressurser kan dette være den mest praktiske løsningen.

Self-hosted løsninger krever vanligvis mer planlegging. Man må blant annet ta stilling til:

  • drift av servere
  • sikkerhetsoppdateringer
  • backup
  • overvåkning

I praksis velger mange virksomheter en mellomløsning hvor infrastrukturen fortsatt er under egen kontroll, men driften håndteres av en leverandør.

Et eksempel: Nextcloud

En av de mest brukte plattformene for self-hosted skylagring er Nextcloud.

Nextcloud er en open source-plattform som gir funksjoner som:

  • filsynkronisering
  • dokumentdeling
  • samarbeidsverktøy
  • kalender og kontakter

Systemet kan installeres på egne servere eller i et privat datasenter.

For brukerne oppleves løsningen ofte svært lik andre skylagringstjenester. Forskjellen ligger i hvem som kontrollerer infrastrukturen.

Et spørsmål mange virksomheter overser

Diskusjonen om skylagring handler ofte om funksjoner, pris og brukervennlighet.

Men et annet spørsmål er minst like viktig:

Hvem kontrollerer egentlig infrastrukturen dataene dine ligger i?

Når en virksomhet velger en skyløsning, velger den samtidig hvem som har kontroll over lagringsplattformen.

Det er nettopp dette spørsmålet hovedartikkelen vår tar for seg i detalj.

Hvis du vil forstå de strategiske konsekvensene av ulike skyløsninger, bør du lese videre her:

Hvem kontrollerer egentlig dataene dine?