AI sikkerhetstesting: 38 hull i pasientjournaler

Nøkkelpunkter per 14. oktober 2026:

38 kritiske sårbarheter ble funnet i journalplattformen OpenEMR av en autonom AI-analysator, to av dem med toppscore 10.0 på CVSS (markets.businessinsider.com, 2026).
Epic satte mesteparten av produktutviklingen på pause og kjørte en sikkerhetsrevisjon på seks uker etter at en AI-modell avdekket hull i programvaren (TechCrunch, 2026).
Enkelte kundekonfigurasjoner av MyChart kunne gi utenforstående tilgang til pasientjournaler uten at tilgangen ble loggført, ifølge Epics sikkerhetssjef (New York Times, 2026).
Tre selskaper står for nesten 75 prosent av det amerikanske journalmarkedet, noe som gjør ett konfigurasjonsvalg til et sektorproblem (wpr.org).
Norsk relevans er direkte: Epic leverer programvaren til Helseplattformen, og Hemit har regelmessig dialog med selskapet om sikkerhet (Teknisk Ukeblad).

Hva AI-drevet sikkerhetstesting faktisk er

Høsten 2026 skjedde to ting i helseteknologi som peker samme vei. USAs største leverandør av elektronisk pasientjournal satte mesteparten av produktutviklingen på pause for å tette sikkerhetshull som en AI-modell hadde funnet (TechCrunch, 2026). Samtidig offentliggjorde et sikkerhetsselskap 38 kritiske sårbarheter i en åpen journalplattform, funnet av en autonom analysator (markets.businessinsider.com, 2026). Ingen av sakene handler om et nytt angrep. Begge handler om at det ble mye billigere å finne feilene.

Det er det som gjør dette til en lederoppgave og ikke bare en IT-oppgave. Når kostnaden ved å finne sårbarheter faller, flyttes balansen mellom dem som bygger systemer og dem som vil inn i dem. Du må anta at noen andre kjører samme type analyse på din kodebase, uten å spørre først.

Fra signaturskanning til agenter som leser kode

Klassisk sårbarhetsskanning leter etter kjente mønstre: en bibliotekversjon med kjent feil, en port som står åpen, en konfigurasjon som bryter en regel. Det er nyttig, men metoden finner i praksis bare det noen har beskrevet før. AI-drevet sikkerhetstesting jobber annerledes: modellen leser kode og konfigurasjon, bygger en forståelse av hvordan dataflyten faktisk går, og foreslår hvor tilliten mellom komponenter kan brytes. Den finner logiske feil, ikke bare utdaterte pakker.

Forskjellen er hastighet og dekning. En professor i datavitenskap som har fulgt Epic-saken, Rahul Gomes, peker på at AI har gjort prosessen med å finne sårbarheter mye raskere (wpr.org). Det er en nøytral observasjon, ikke en salgsargumentasjon: samme hastighetsøkning gjelder for den som forsvarer og den som angriper. Asymmetrien er at forsvareren må finne alt, mens angriperen trenger ett hull.

For en norsk SMB-leder betyr dette at sikkerhetstesting ikke lenger er en engangsøvelse du kjøper annethvert år. Analysen kan kjøres kontinuerlig, på hver endring, i samme tempo som utviklingen. Det endrer hvor i prosessen testingen hører hjemme.

Hva Epic brukte verktøyet til

Epic brukte Anthropics AI-agent Claude Mythos til å stressteste sine egne systemer, og funnene førte til at selskapet stanset utviklingen av enkelte produktlinjer mens ingeniørene jobbet i et sprint for å tette hull (New York Times, 2026). Dette er ikke et tilfelle der en ekstern aktør avslørte et selskap. Leverandøren kjørte verktøyet mot seg selv og publiserte resultatet.

Det er den delen norske ledere bør merke seg. Epic valgte å ta kostnaden med å finne feilene selv, før noen andre gjorde det. Alura mener at sikkerhetstesting med AI hører til før lansering, ikke som en krisesprint etterpå, og Epic-saken er et godt argument for hvorfor: når arbeidet kommer sent, må alt annet stoppe mens det gjøres.

Det AI ikke overtar

Et AI-verktøy produserer kandidater, ikke dommer. Noen funn er reelle, noen er teoretiske, og noen er riktige i koden men irrelevante i din konfigurasjon. Triagen, altså vurderingen av hvilke funn som faktisk utgjør risiko for pasientdata hos dere, er fortsatt menneskearbeid. Det samme gjelder prioriteringen mot drift: en sårbarhet som krever nedetid i et akuttsystem er en annen beslutning enn samme sårbarhet i et planleggingsverktøy.

Gomes peker på en begrensning som er spesifikk for sektoren: helsevesenet kan ikke stenge systemer for oppdateringer slik en bank kan (wpr.org). Et sykehus har ikke et vindu klokka tre om natten der ingen trenger journalen. Det betyr at funn må kunne patches uten full nedetid, og at testing før lansering er verdt mer her enn i nesten alle andre bransjer.

Epic-saken kort fortalt

Epic Systems er en amerikansk helseteknologigigant som leverer elektronisk pasientjournal til sykehus over hele verden, og i Norge er selskapet mest kjent for å stå bak programvaren til Helseplattformen (Digi.no). Omfanget forklarer hvorfor saken fikk oppmerksomhet: Epic oppbevarer journaler for 325 millioner pasienter (New York Times, 2026).

Saken er verdt å lese nøyaktig, ikke dramatisk. Det er ikke rapportert noe innbrudd. Det som skjedde er at leverandøren fant svakheter, vurderte dem som alvorlige nok til å stoppe annet arbeid, og sa det offentlig.

Tidslinjen fra konferanse til pause

Epic-grunnlegger og toppsjef Judith Faulkner fortalte på en bransjekonferanse i slutten av september at mesteparten av produktutviklingen er satt på pause, og at selskapet har iverksatt en sikkerhetsrevisjon på seks uker der ressurser omdisponeres for å identifisere og rette sårbarheter (Teknisk Ukeblad). Pausen gjaldt ikke drift av eksisterende systemer, men utviklingen av nytt.

Faulkner presenterte både sårbarheten og seksukersplanen fra scenen (New York Times, 2026). Rekkefølgen er interessant: funnet kom først, så beslutningen om å stoppe, så offentliggjøringen. Mange selskaper ville valgt motsatt rekkefølge, eller ingen offentliggjøring i det hele tatt.

Konfigurasjonsvalget i MyChart

Den konkrete svakheten er mer presis enn overskriftene antyder. Epics sikkerhetssjef Stirling Martin har uttalt at enkelte kundekonfigurasjoner av MyChart kan gi utenforstående tilgang til pasientjournaler uten at det loggføres (TechCrunch, 2026). MyChart er pasientportalen, altså flaten der pasienten selv logger inn.

To ting følger av formuleringen «enkelte kundekonfigurasjoner». Det første er at feilen ikke nødvendigvis ligger i produktet som levert, men i hvordan den enkelte helseaktøren har satt det opp. Det andre er at ingen vet hvilke aktører det gjelder før noen sjekker. MyChart-programvaren brukes til å vedlikeholde over 320 millioner pasientjournaler i USA, så antallet oppsett som må gjennomgås er stort.

Hvorfor en pause er et signal

Det er uvanlig at et selskap stanser utviklingen for å fikse sikkerhetsfeil, men AI-verktøy som raskt finner sårbarheter skaper bekymring (TechCrunch, 2026). Når en leverandør med denne markedsposisjonen velger å ta kostnaden, er det et signal om hvor høyt de vurderte risikoen.

Faulkner uttrykte samtidig bekymring for at nye sårbarheter vil dukke opp i en aldri avsluttende syklus (New York Times, 2026). Det er den realistiske lesningen. Du kommer ikke til et punkt der systemet er ferdig sikret. Du kommer til et punkt der du finner feilene før andre gjør det, og retter dem raskere enn de kan utnyttes.

De 38 hullene i OpenEMR og hva CVSS 10.0 betyr

Parallelt med Epic-saken kom en sak som er teknisk tydeligere, fordi kodebasen er åpen. AISLEs autonome analysator oppdaget 38 kritiske sikkerhetssårbarheter i OpenEMR, en utbredt åpen kildekode-plattform for elektronisk pasientjournal (markets.businessinsider.com, 2026). Her finnes både funnene, alvorlighetsgraden og rettingene dokumentert offentlig.

Dimensjon	Epic / MyChart	OpenEMR
Hvem fant det	Leverandøren selv, med AI-agenten Claude Mythos	Ekstern aktør, med autonom analysator
Hva som ble funnet	Konfigurasjoner som kan gi tilgang uten loggføring	38 kritiske sårbarheter, to med CVSS 10.0
Omfang	Journaler for 325 millioner pasienter	Over 100 000 leverandører, over 200 millioner pasienter
Tiltak	Produktutvikling satt på pause, seks ukers revisjon	Alle advisories patchet av vedlikeholderne
Varig endring	Intern sikkerhetssprint	AI-analyse lagt inn før produksjon, som PR-kommentarer

Hva den autonome analysatoren fant

AISLE offentliggjorde 39 GitHub Security Advisory-sårbarheter, alle patchet av OpenEMR-vedlikeholderne, og 38 av de 39 sikkerhetsproblemene fikk CVE-betegnelser (markets.businessinsider.com, 2026). At nesten alle funnene fikk et offisielt CVE-nummer er et kvalitetstegn: det betyr at en uavhengig prosess har godtatt dem som reelle sårbarheter, ikke som støy fra et verktøy.

Skalaen på brukersiden er det som løfter dette fra teknisk kuriositet til sektorsak. OpenEMR brukes av over 100 000 medisinske leverandører og betjener over 200 millioner pasienter på 34 språk. Et funn i en slik kodebase er ikke et problem for en kunde, men for alle som kjører den versjonen.

Hva CVSS 10.0 betyr i praksis

CVSS er industristandarden for å sette alvorlighetsgrad på en sårbarhet, og skalaen stopper på 10.0. To av sårbarhetene i OpenEMR fikk den scoren, og kunne utnyttes til å få tilgang til og endre pasient- og leverandørdata (markets.businessinsider.com, 2026). Toppscore betyr grovt sagt: utnyttbar over nettverk, uten innlogging, uten brukerinteraksjon, med full effekt på konfidensialitet, integritet og tilgjengelighet.

Legg vekt på ordet endre. Diskusjonen om pasientdata handler nesten alltid om lekkasje, altså at noen leser noe de ikke skal. Men en sårbarhet som også tillater endring treffer selve behandlingsgrunnlaget. En journal som er lest av feil person er et personvernbrudd. En journal som er endret av feil person er et pasientsikkerhetsproblem.

Når du leser en sikkerhetsrapport internt, be derfor alltid om to kolonner, ikke en: hva kunne leses, og hva kunne skrives. De to krever ulike tiltak og ulik hastighet.

Åpen kildekode gjør funnene offentlige

OpenEMR-saken ser verre ut enn Epic-saken fordi den er mer dokumentert. Det er en lesefeil du bør være bevisst på. Lukket programvare har ikke færre feil, bare færre offentlige CVE-numre. Den åpne modellen gir deg noe konkret å forholde deg til: en liste, en versjon, en patch.

Det mest interessante er hva OpenEMR gjorde etterpå. Vedlikeholderne bruker nå AI-plattformen til å oppdage, triagere og fikse sårbarheter automatisk, og kjører analysatoren for å løse sikkerhetsproblemer før produksjon, med fikser levert som pull request-kommentarer i GitHub (markets.businessinsider.com, 2026). Det er flyttingen fra hendelse til prosess, og det er den delen som er verdt å kopiere.

Et rammeverk for stresstesting før lansering

Hvis du leder et prosjekt som skal ta i bruk eller videreutvikle et pasientsystem, trenger du ikke en sikkerhetsstrategi på tjue sider. Du trenger fire porter som en lansering ikke kan passere uten å ha svart. Porter fungerer bedre enn sjekklister fordi de har en eier og et stoppkriterium.

Port	Spørsmålet som må besvares	Eier	Stoppkriterium
Kartlegging	Hvilke komponenter rører pasientdata, og hvem har tilgang til hver av dem?	Produktansvarlig	Udokumenterte integrasjoner mot journal
Konfigurasjon	Er vårt oppsett testet, eller bare leverandørens standardoppsett?	Teknisk ansvarlig	Tilgangsregler satt uten begrunnelse
Sporbarhet	Kan vi i ettertid vise hvem som så hvilken journal, og når?	Personvernombud	Tilgangsvei uten logg
Retting	Hvor raskt kan vi patche uten nedetid i akuttkritiske flater?	Driftsansvarlig	Ingen testet rettevei

Portene som faktisk stopper en lansering

Den første porten er kjedelig og avgjørende: en liste over alt som rører pasientdata. I de fleste virksomheter er listen lengre enn ledelsen tror, fordi integrasjoner, rapportuttrekk, testmiljøer og eksportfiler har en tendens til å leve sitt eget liv. Du kan ikke teste det du ikke vet at finnes.

Den andre porten er konfigurasjon, og den er den mest undervurderte. Epic-saken handler nettopp om at oppsettet hos kunden, ikke produktet i seg selv, åpnet tilgangen (TechCrunch, 2026). En leverandørs sikkerhetsgodkjenning dekker produktet slik det ble sertifisert, ikke de valgene dere gjorde under innføringen.

Den tredje porten er sporbarhet, og den behandles i et eget kapittel lenger ned fordi den er sektorens egentlige svakhet. Den fjerde er rettevei: evnen til å faktisk installere en patch. Et funn du ikke kan rette før neste planlagte vedlikeholdsvindu er i praksis en åpen dør med kjent adresse.

Hvem eier hver port

Porter uten navngitt eier blir ikke lukket. I en SMB med knappe ressurser er det bedre at en person eier to porter enn at fire porter eies av «teamet». Eierskapet må også ligge der beslutningsmyndigheten er: en utvikler kan dokumentere en tilgangsvei, men bare den som eier tjenesten kan beslutte at lanseringen utsettes.

Gi hver port et skriftlig svar, ikke et muntlig. Et halvsides notat per port, med dato og navn, er nok. Verdien er todelt: det tvinger frem konkrete svar underveis, og det gir dere dokumentasjon dersom Datatilsynet eller en revisor senere spør hva dere vurderte og når.

Praktisk gjennomføring: første uke med AI-assistert sikkerhetstesting

Rammeverket over er beslutningsstrukturen. Dette er arbeidet du kan starte på mandag, uten innkjøpsprosess og uten ny stillingshjemmel. Målet den første uken er ikke å finne alle sårbarheter, men å få et ærlig bilde av hvor du står og en rangert liste.

Når	Oppgave	Leveranse ved slutten
Tidlig i uken	Tegn dataflyten for pasientdata, inkludert test- og rapportmiljøer	Et kart alle er enige om
Tidlig i uken	Hent ut faktisk tilgangsliste fra journalsystemet, ikke den tiltenkte	Avvik mellom tiltenkt og faktisk tilgang
Midt i uken	Kjør AI-assistert analyse mot egen kode og egne konfigurasjonsfiler	Rå funnliste med alvorlighetsgrad
Midt i uken	Triager funnene mot egen konfigurasjon, skill reelt fra teoretisk	Rangert liste med eier per funn
Sent i uken	Test om tilgang til en journal faktisk gir en loggoppføring	Ja eller nei, skriftlig
Sent i uken	Still leverandøren de åpne spørsmålene i skriftlig form	Sendt henvendelse med frist

Dag for dag

Begynn med kartet, og tegn det med folk i rommet som faktisk jobber i systemene. Spør spesielt etter de uglamorøse tilgangsveiene: databasekopier til analyse, eksportfiler til kvalitetsregistre, testmiljøer med produksjonsdata. Erfaringsmessig er det her gapene ligger, ikke i hovedapplikasjonen som alle har sett på.

Deretter henter du ut den faktiske tilgangslisten. Forskjellen mellom hvem som skal ha tilgang og hvem som har det, er et av de få tallene du kan måle før og etter. Legg inn roller som har vokst over tid, vikarer som aldri ble deaktivert, og systembrukere uten eier.

Midtveis i uken kjører du analysen. Et AI-verktøy kan lese kode og konfigurasjon raskere enn et menneske, men funnene må gjennom triage samme dag de kommer, ellers blir listen en kirkegård. Avslutt uken med den viktigste enkelttesten: åpne en journal gjennom hver tilgangsvei og sjekk om handlingen etterlater et spor.

Hva som må være på plass før du begynner

Tre forutsetninger. Du må ha skriftlig tillatelse til å teste, fra den som eier systemet, med omfang og tidsrom definert. Du må ha et testmiljø som likner produksjon nok til at funnene er relevante, men uten ekte pasientdata der det kan unngås. Og du må ha en avtalt kanal for funn som ikke er e-post til en felles postkasse.

Ett punkt som ofte glemmes: avklar på forhånd hva som skjer dersom dere finner noe alvorlig midt i uken. Hvem varsler ledelsen, hvem vurderer om det er et avvik, og hvem tar beslutningen om å stenge en tilgangsvei. Den avklaringen tar ti minutter før testen og tre dager etter.

Tre feller i uke en

Den første fellen er å teste det som er enkelt å teste. Nettsiden og påloggingsflaten får all oppmerksomhet, mens integrasjonene mot laboratorie- og bildesystemer står urørt fordi de er vanskelige å forstå. Angrepsflaten følger ikke hva som er hyggelig å jobbe med.

Den andre fellen er å måle antall funn som om det var et resultat. Et verktøy som produserer hundrevis av treff har ikke nødvendigvis gjort en god jobb. Mål heller andelen funn som er triagert, og tiden fra funn til beslutning.

Den tredje fellen er å gjøre første uke til en engangsøvelse. OpenEMR-vedlikeholderne la analysen inn i utviklingsløpet som pull request-kommentarer, altså der utvikleren allerede jobber (markets.businessinsider.com, 2026). Det er forskjellen mellom en revisjon og en vane.

Ansvarsfordeling mellom leverandør og helseaktør

Her ligger den mest ubehagelige delen av Epic-saken for norske kunder. Epic oppgir at selskapet ikke har tilgang til kundenes medisinske data, og at ansvaret ligger hos helseleverandørene (TechCrunch, 2026). Det er en juridisk korrekt og driftsmessig krevende posisjon på samme tid.

Alura mener at ansvaret for pasientdata ikke kan outsources til leverandøren, selv når leverandøren finner hullet først. Det er en hyggelig tanke at en stor leverandør med stort sikkerhetsteam bærer risikoen for deg. Avtalene sier noe annet, og tilsynene gjør det også.

Leverandørens grense

Grensen går typisk ved konfigurasjon. Leverandøren svarer for at produktet er bygget forsvarlig og for at kjente feil rettes. Kunden svarer for hvilke valg som er gjort i oppsettet, hvem som har fått tilgang, og om loggingen er skrudd på. Når sikkerhetssjefen hos Epic sier at det er enkelte kundekonfigurasjoner som åpner tilgang, plasserer det ansvaret presist (New York Times, 2026).

Praktisk konsekvens: en leverandørerklæring om at produktet er sikkert er ikke et svar på om deres installasjon er sikker. De to spørsmålene må stilles separat, og det andre må stilles av dere.

Hva avtalen må si

Gå gjennom databehandleravtalen og se etter fire punkter. Hvor raskt skal leverandøren varsle dere om sårbarheter de selv har funnet, og gjelder fristen også funn som ikke er utnyttet? Har dere rett til å få konfigurasjonsspesifikke sikkerhetsvurderinger, ikke bare generelle produkterklæringer? Har dere rett til å teste egen installasjon, og under hvilke vilkår? Og hvem bærer kostnaden når en patch krever nedetid i en klinisk flate?

Det fjerde punktet er det som oftest mangler. En leverandør kan levere en patch raskt og likevel skape et problem, fordi installasjonen krever et driftsvindu dere ikke har. Avklar i avtalen hvem som planlegger og betaler for dette, før det haster.

Loggføring som den egentlige svakheten

Av alt som kom fram i Epic-saken er en setning viktigere enn resten: tilgangen kunne skje uten at det loggføres (TechCrunch, 2026). Det samme poenget er beskrevet som risiko for at hackere får uoppdaget tilgang til pasientdata (New York Times, 2026).

Alura mener at et funn ikke er et avvik i seg selv, men at mangel på logg over hvem som har sett journalen er det. En sårbarhet som er funnet og rettet er normal programvareutvikling. En tilgangsvei uten spor gjør det umulig å svare på det eneste spørsmålet som betyr noe for pasienten: har noen sett journalen min?

Tilgang uten spor

Tenk gjennom hva det innebærer operativt. Uten logg kan dere ikke avgrense et eventuelt brudd, ikke varsle de berørte, ikke dokumentere overfor tilsynet hva som skjedde, og ikke avkrefte mistanke. Dere står igjen med å måtte anta det verste eller håpe på det beste, og ingen av dem er en forsvarlig posisjon.

Logg er derfor ikke en etterlevelsesdetalj, men en forutsetning for å kunne håndtere en hendelse. Et system med en kjent sårbarhet og fullstendig logg er i mange tilfeller i bedre stand enn et system uten kjente sårbarheter og uten logg. Det første kan rettes og etterprøves. Det andre kan bare tros på.

Når et funn blir et avvik

Lag et skriftlig skille i internkontrollen. Et funn uten utnyttelse, med intakt logg som viser at ingen urettmessig tilgang har skjedd, håndteres som en teknisk feil med frist. Et funn der loggen mangler eller er ufullstendig, håndteres som et mulig avvik med varslingsvurdering. Skillet må settes før dere trenger det, ellers blir det satt under press.

I praksis betyr dette tre krav til loggen: hver tilgang til en journal gir en oppføring, oppføringen inneholder identitet og tidspunkt, og loggen kan ikke endres av den som utløste den. Test disse tre, en etter en, gjennom hver tilgangsvei i kartet deres. Det er den enkleste testen i hele artikkelen og den som oftest ikke er gjort.

Norsk kontekst: Helseplattformen, Hemit og leverandørdialogen

Epic-saken er ikke amerikansk utenrikspolitikk for norske lesere. Epic står bak programvaren til Helseplattformen, og Hemit, som drifter og forvalter infrastrukturen, har regelmessig dialog med Epic om sikkerhet og utviklingen av løsningen, ifølge Hemit-leder Trond Utne (Teknisk Ukeblad).

Det er et fornuftig utgangspunkt og samtidig et minimum. Regelmessig dialog er ikke det samme som dokumentert gjennomgang av egen konfigurasjon.

Hemit og leverandørdialogen

Den norske varianten av dette problemet har en egen vri: når en leverandør dekker en stor del av sektoren, blir ikke dialogen bare en kunderelasjon, men en del av sektorens sikkerhetsarkitektur. Alura mener at når samme leverandør dekker en stor del av markedet, blir ett sårbart konfigurasjonsvalg et sektorproblem og bør følges opp i leverandørdialogen.

Konkret betyr det at spørsmålene bør stilles skriftlig, med frist, og at svarene bør deles mellom aktører som kjører samme løsning. Det finnes ingen konkurransefordel i å sitte alene på informasjon om et konfigurasjonsvalg som alle har gjort likt (Digi.no).

Helsedirektoratets AI-plan treffer samme systemer

Mens sikkerhetssaken pågår, går innføringen av AI i norsk helsevesen videre. Helsedirektoratet arbeider med en plan for å implementere AI i helse- og omsorgssektoren, med mål om å effektivisere tjenestene og redusere ventetidene (kode24). Helsedirektør Bjørn Guldvog peker på at AI kan avlaste helsepersonell og er en del av løsningen på personellmangel og ventetider.

Det finnes konkrete resultater å vise til. I Vestre Viken har bruk av AI i røntgenanalyse bidratt til å redusere ventetiden betraktelig, og i Møre og Romsdal er tidsrommet mellom planlegging og gjennomføring av strålebehandlinger redusert (kode24). Guldvog understreker samtidig at teknologien fortsatt er relativt ny og umoden.

Poenget for en beslutningstaker er koblingen: de nye AI-tjenestene leser og skriver i de samme journalsystemene som nå stresstestes. Hver ny modell som får tilgang til pasientdata er en ny tilgangsvei som må inn i kartet, med samme krav til logg som et menneske har.

Spørsmålene du bør ta inn i neste leverandørmøte

Fem spørsmål, i denne rekkefølgen. Har dere kjørt AI-assistert sikkerhetsanalyse mot den versjonen vi faktisk bruker, og når? Finnes det konfigurasjonsvalg i vårt oppsett som kan gi tilgang til journal uten loggoppføring? Hvilke av disse valgene er satt av oss og hvilke er satt som standard fra dere? Hvor lang tid tar det fra dere finner en kritisk sårbarhet til vi får varsel? Og hvordan patches en kritisk feil i en flate vi ikke kan ta ned?

Be om svar skriftlig. Ikke fordi leverandøren er uærlig, men fordi skriftlige svar tvinger frem presisjon og gir dere et spor i egen internkontroll. Bevilgningene til sektoren illustrerer forøvrig at dette er dyre systemer å drifte: St. Olavs hospital fikk 100 millioner kroner ekstra driftsstøtte, og Helseplattformen 80 ekstra millioner (kode24).

Kostnaden ved å utsette

Argumentet mot sikkerhetstesting før lansering er alltid det samme: det forsinker leveransen. Epic-saken gir et uvanlig tydelig motregnestykke, fordi kostnaden ble synlig som en pause i produktutviklingen for hele selskapet (Digi.no).

Kostnadslinje	Testing før lansering	Opprydding etter lansering
Utviklingstid	Planlagt, fordelt over løpet	Alt annet stopper, som hos Epic
Retting	Endring i kode som ikke er i drift	Patch i produksjon, krever driftsvindu
Varsling	Ingen, funnet før data var utsatt	Mulig varsling til tilsyn og pasienter
Omdømme	Dokumentert aktsomhet	Saken settes av andre enn dere
Leverandørforhold	Spørsmål stilt i rolig fase	Forhandling under tidspress

Seks uker uten produktutvikling

Epic jobbet i seks uker nesten utelukkende med å sikre programvaren (New York Times, 2026). Regn det om til din egen virksomhet. Hva koster det å sette hele utviklingskapasiteten på en sikkerhetssprint, med alle forpliktelser til kunder, interne frister og roadmap-løfter som følger med?

Den sanne kostnaden er ikke bare lønnskronene i perioden. Det er funksjonene som ikke ble levert, kundene som ventet, og tilliten som ble satt på prøve underveis. En leverandør av Epics størrelse har råd til et slikt stopp. En norsk SMB som leverer en pasientrettet tjeneste har ikke nødvendigvis det.

Kostnaden når det går galt

Den andre enden av skalaen er dokumentert i amerikansk statistikk. Et ransomware-angrep mot Change Healthcare i 2024 lot hackere stjele helsedata om over 192 millioner mennesker, og amerikanske helsemyndigheter lister for tiden et innbrudd hos tannforsikringsselskapet DentaQuest, som rammet 15 millioner mennesker, som det største helserelaterte datainnbruddet så langt i 2026 (TechCrunch, 2026).

Tallene er amerikanske, men mekanismen er ikke. Norske virksomheter har mindre datasett og tilsvarende konsentrasjon av dem. Når helsedata først er ute, kan de ikke kalles tilbake, byttes eller sperres slik et kortnummer kan. Det er grunnen til at kost-nytte-regnestykket for pasientdata ser annerledes ut enn for de fleste andre datatyper.

Markedsobservasjon: når tre leverandører dekker nesten 75 prosent

Et strukturelt forhold forklarer hvorfor en enkelt konfigurasjonsfeil kan bli en sektorhendelse. Tre selskaper står for nesten 75 prosent av det amerikanske markedet for elektronisk pasientjournal, og Epic alene hadde nesten 44 prosent av markedet for akuttmedisinske journaler i fjor (wpr.org).

Konsentrasjonen har reelle fordeler: felles standarder, raskere utrulling av rettinger, ett kompetent sikkerhetsteam i stedet for hundre halvgode. Gomes peker samtidig på at konsentrasjonen av få leverandører skaper cybersikkerhetsmessige avveininger (wpr.org). Det er en avveining, ikke en dom.

Konsentrasjon som sikkerhetsfaktor

I en monokultur er enhver feil korrelert. Et funn som ellers ville rammet en håndfull kunder rammer i stedet en stor andel av sektoren samtidig, og alle må patche i samme vindu med samme leverandørs kapasitet. Det er motsatsen til risikospredning, og det er grunnen til at tilsynsmyndigheter i andre bransjer har begynt å snakke om leverandørkonsentrasjon som systemrisiko.

Samtidig gjelder det omvendte for forsvaret: når leverandøren kjører en AI-analyse mot sin egen kodebase, får alle kundene nytten av det på en gang. Epic-saken er faktisk et eksempel på konsentrasjonens oppside. Spørsmålet for deg som kunde er ikke om konsentrasjon er bra eller dårlig, men om du har innsyn nok til å vite hvilken side av avveiningen du er på.

Hva det betyr for norsk anskaffelse

Tre konkrete grep i neste anskaffelse eller kontraktsfornyelse. Krev innsyn i leverandørens testregime, inkludert om og hvordan AI-assistert analyse brukes mot den versjonen du kjøper. Krev varslingsfrister som gjelder funn, ikke bare bekreftede brudd. Og sørg for at du eier dine egne logger teknisk, så du kan undersøke en hendelse uten å måtte bestille data fra leverandøren.

Det fjerde grepet er organisatorisk: samarbeid med andre norske aktører som bruker samme løsning. Når markedet er konsentrert, er det ingen mening i at hver kunde skal oppdage samme konfigurasjonsproblem på egen hånd.

Vanlige feil når sikkerhetsarbeid legges etter lansering

Feilene under er de vi ser oftest i prosjekter som har satt sikkerhet på slutten av planen. De er ikke tegn på dårlig kompetanse, men på rekkefølgen arbeidet er lagt i.

Feil	Konsekvens	Hva du gjør i stedet
Tester produktet, ikke egen konfigurasjon	Du godkjenner leverandørens oppsett, ikke ditt	Test installasjonen som den står i drift
Antar at logging er på	Ingen sporbarhet den dagen noe skjer	Verifiser logg gjennom hver tilgangsvei
Måler antall funn	Lange lister, få lukkede saker	Mål tid fra funn til beslutning
Behandler alle funn likt	Kritiske saker drukner i støy	Skill lese- og skrivetilgang i triagen
Venter på leverandørens vurdering	Ansvar skyves, tiden går	Gjør egen vurdering parallelt
Sikkerhet som prosjekt, ikke prosess	Gapet åpner seg igjen etter neste release	Legg analysen inn i utviklingsløpet

Feilene som koster mest

Den dyreste feilen er å anta at logging er skrudd på fordi systemet har en loggfunksjon. Epic-saken viser at en tilgangsvei kan omgå loggen selv i et modent produkt med stort sikkerhetsteam (New York Times, 2026). Antakelsen koster ingenting å gjøre og alt å ta feil på.

Den nest dyreste er å ikke skille mellom lesing og endring i triagen. Når du bare rangerer etter alvorlighetsgrad, forsvinner skillet mellom en lekkasje og en mulig endring av behandlingsgrunnlag. De to utløser helt ulike plikter, og den ene handler om pasientsikkerhet.

Organisatoriske feil

Den vanligste organisatoriske feilen er at sikkerhetsarbeidet eies av et team uten myndighet til å utsette en lansering. Da blir funnene råd, ikke porter, og råd taper mot en lanseringsdato. Koblingen mellom funn og beslutningsmyndighet må være eksplisitt i mandatet.

Den andre er at ledelsen får rapportert status som farge og ikke som innhold. Grønn status på sikkerhet betyr sjelden noe. Be i stedet om tre linjer per rapporteringsperiode: hvilke tilgangsveier er testet, hvilke funn er åpne, og hvilke av dem mangler logg. Da ser du faktisk hvor dere står.

Spørsmål og svar om AI sikkerhetstesting i helsesektoren

Spørsmålene under er dem vi får oftest fra ledere og produktansvarlige i virksomheter som jobber med pasientdata.

Erstatter AI-testing tradisjonell penetrasjonstesting?

Nei. AI-drevet analyse dekker bredde: den leser mer kode og flere konfigurasjonsfiler enn et menneske kan gjøre innenfor et budsjett. Manuell penetrasjonstesting dekker dybde og kreativitet, særlig i sammensatte angrepskjeder på tvers av systemer. Den praktiske arbeidsdelingen er at AI-analysen kjører kontinuerlig i utviklingsløpet, mens manuell testing settes inn mot de mest kritiske flatene før lansering.

Hvor mye trenger vi å investere for å komme i gang?

Mindre enn de fleste tror på verktøysiden og mer enn de fleste tror på arbeidsflyten. Selve analysen er tilgjengelig som skytjeneste og kan kjøres mot en kodebase uten store oppsettskostnader. Det som koster er triagen, eierskapet og rettingen: noen må vurdere funnene, noen må beslutte, og noen må patche i et miljø som ikke tåler nedetid. Legg budsjettet på de tre, ikke på lisensen.

Vi bruker en standard journalløsning, er ikke sikkerhet leverandørens ansvar?

Delvis, og nettopp derfor er dette farlig. Epic oppgir at selskapet ikke har tilgang til kundenes medisinske data og at ansvaret ligger hos helseleverandørene (TechCrunch, 2026). Leverandøren svarer for produktet, du svarer for oppsettet, tilgangene og loggingen. Når feilen beskrives som knyttet til kundekonfigurasjoner, er det din side av grensen.

Hva gjør vi hvis vi finner et hull etter at systemet er i drift?

Første spørsmål er alltid loggen, ikke patchen. Kan dere dokumentere hvem som har hatt tilgang via den aktuelle veien? Hvis ja, avgrens, vurder om noe urettmessig har skjedd, og håndter det som en teknisk feil med frist. Hvis nei, behandle det som et mulig avvik med varslingsvurdering, og få en uavhengig vurdering av om pasienter må informeres. Parallelt stenger dere tilgangsveien hvis det er mulig uten klinisk skade.

Hvor ofte bør vi kjøre denne typen testing?

Så ofte dere endrer noe. Modellen OpenEMR-vedlikeholderne gikk over til, der analysen kjører før produksjon og funnene kommer som kommentarer i utviklingsflyten, er mer effektiv enn periodiske revisjoner (markets.businessinsider.com, 2026). Behold likevel en grundigere gjennomgang med jevne mellomrom, og en obligatorisk før hver større lansering. Faulkner har selv påpekt at nye sårbarheter vil dukke opp i en vedvarende syklus (New York Times, 2026).

Oppsummering og neste steg for norske helseaktører

To saker fra samme høst, to ulike veier til samme konklusjon. En leverandør med journaler for 325 millioner pasienter stoppet produktutviklingen for å tette hull en AI-modell hadde funnet. En åpen journalplattform brukt av over 100 000 leverandører fikk 38 kritiske sårbarheter rettet etter en autonom analyse. I begge tilfeller var det verktøyet, ikke angriperen, som kom først.

Det er den gode nyheten, og den har en kort frist. Samme kapasitet er tilgjengelig for begge sider av bordet. Spørsmålet er bare om du bruker den før eller etter at systemet er i drift.

Rekkefølgen på en side

Kartlegg hva som rører pasientdata, inkludert test- og rapportmiljøer. Hent ut faktisk tilgangsliste og sammenlign med tiltenkt. Kjør AI-assistert analyse mot egen kode og egen konfigurasjon, og triager funnene samme uke. Verifiser at hver tilgangsvei gir en loggoppføring som ikke kan endres av den som utløste den. Still leverandøren de fem spørsmålene skriftlig, med frist.

Deretter gjør du det om til en vane: analysen inn i utviklingsløpet, logg som del av akseptansekriteriene, og en port som faktisk kan stoppe en lansering. Det er hele forskjellen mellom å eie risikoen og å oppdage den.

Neste steg

Start med loggtesten. Den tar en ettermiddag, krever ingen innkjøp, og gir deg det eneste svaret du ikke kan improvisere senere: kan dere vise hvem som har sett journalen? Alt annet i denne artikkelen kan vente en uke. Det svaret kan ikke.

Og hold øye med leverandørsiden. Når den største aktøren i sektoren beskriver dette som en vedvarende syklus (New York Times, 2026), er det ikke en invitasjon til panikk, men til å bygge en prosess som tåler at det kommer nye funn. Norske aktører har en fordel her: innføringen av AI i helsetjenesten er fortsatt i en fase der sikkerhetskravene kan skrives inn fra starten (kode24).

I Alura jobber vi med norske bedrifter på tvers av bransjer: finans, helse, bygg, e-handel, industri. Vi vet hva som fungerer i din sektor og hva som ikke gjør det, fordi vi har bygget løsninger der allerede.

Bestill en bransje-vurdering: vi presenterer hva andre i din sektor faktisk gjør med AI, hva som gir avkastning, og hvor du har uutnyttede muligheter. Uforpliktende.

Kilder

markets.businessinsider.com (2026). AISLE Discovers 38 Critical Security Vulnerabilities in Healthcare Software Used by 100,000 Providers | Markets Insider
TechCrunch (2026). Medical records giant Epic pauses product development to fix security bugs that risk patients' data | TechCrunch
New York Times (2026). Medical Records Firm Uses AI Tool to Expose Flaws that Threaten Patient Privacy - The New York Times
wpr.org. Epic used AI to find potential security flaws that could expose patient health records - WPR
Teknisk Ukeblad. Epic stanser utvikling etter KI-funn
Digi.no. Epic stanser utvikling etter KI-funn
kode24. Nå skal norsk helsevesen bruke AI: – Kan bidra til få ned ...