I bygg og anlegg bransjen avgjøres lønnsomheten i mange kritiske øyeblikk, men tre av dem går igjen på tvers av selskaper vi snakker med: når entreprenører skal avgjøre hvilke prosjekter de skal regne på, når endringsordrer oppstår i felt, og når underleverandører skal kvalifiseres. Alle tre tas under tidspress, og konsekvensene av feil beslutninger slår direkte inn på margin, fremdrift og risiko. 

Felles for beslutningene er at kunnskapen ofte finnes, men den sitter hos enkeltpersoner, i regneark og i fragmenterte systemer. Det gjør vurderingene personavhengige og praksisen blir ujevn fra prosjekt til prosjekt. Decision Intelligence-plattformen SMARTS™ strukturerer disse beslutningene og gjør selskapets egne kriterier og prioriteringer kjørbare på tvers av organisasjonen. 

Bruksområder i bygg- og anleggsbransjen

Prosjektseleksjon og tilbudsvurdering

Entreprenørselskaper får ofte langt flere tilbudsforespørsler enn de har kapasitet til å regne på. I mange selskaper tas prioriteringen manuelt, basert på erfaring og splittede regneark. Det er en tidkrevende prosess som gir inkonsistente vurderinger, og som fører til at ressurser brukes på prosjekter med feil profil for selskapet, eller at det selges inn kompetanse som senere viser seg å ikke være tilgjengelig når prosjektet starter. 

SMARTS™ kombinerer regelbasert beslutningsstøtte med datadrevet innsikt og automatiserer prosjektvurderinger basert på selskapets egne kriterier og strategiske prioriteringer. Matriser og regneark blir omgjort til kjørbare regler, der plattformen bygger scoringsmodeller som rangerer prosjekter ut ifra lønnsomhet, strategisk verdi, risiko, geografisk plassering, kompetansebehov og faktisk tilgjengelig kapasitet. 

Resultatet er konsistente og sporbare vurderinger, frigjort tid for kalkulasjons- og prosjektteam, og at selskapet byr på riktige prosjekter med riktig kompetanse før kostbare timer brukes på å regne på feil tilbud. 

Risiko og endringshåndtering

Endringsordrer er en av de største kildene til tapte marginer, tvister og forsinkelser i bygg- og anleggsprosjekter. Vurderingen av hva som utgjør en endring, og hvilken risiko den medfører, gjøres ofte av personer ute i prosjektene. Resultatet blir ujevn praksis, tapte tilleggskrav og omkamper med byggherre. 

SMARTS™ operasjonaliserer risikovurderingen direkte i arbeidsflyten. Plattformen klassifiserer hendelser etter risikograd og i henhold til riktig regelsett. Beslutningslogikken kan tilpasses selskapets matriser og justeres av fagpersonell uten involvering fra IT. 

Resultatet er full kontroll på risikoeksponering, færre tapte tilleggskrav og en standardisert prosess som sikrer at selskapets kontraktsrettigheter ivaretas – også når prosjektene presser på tid og ressurser.   

Leverandør- og underleverandørkvalifisering

Bygg- og anlegg er en bransje av underleverandører og kvaliteten på sluttproduktet er sjelden bedre enn det svakeste leddet i kjeden. Krav til HMS-dokumentasjon, økonomisk soliditet, sertifiseringer, seriøsitetskrav og bærekraftrapportering gjør kvalifiseringsprosessen både omfattende og tidkrevende. I tillegg kommer skjerpede krav fra det offentlige som byggherrer, og fra åpenhetsloven. 

Med SMARTS™ kan kvalifiseringen av leverandører og underleverandører automatiseres. Plattformen vurderer om en aktør oppfyller gitte krav, kombinerer interne og eksterne datakilder (for eksempel offentlige registre, sentrale godkjenningsregistre og økonomiske nøkkeltall), og gir en transparent vurdering av risiko og egnethet. Beslutningsgrunnlaget dokumenteres automatisk, slik at kvalifiseringen er sporbar og reproduserbar – også flere år frem i tid ved revisjon eller tvist. 

Resultatet er raskere onboarding av nye leverandører, redusert risiko i prosjektgjennomføringen, og en standardisert prosess som kan skaleres uten at compliance-kostnadene øker tilsvarende. 

Nederst på denne siden finner du en liten boks med et bilde av meg. Under bildet og navnet mitt står det «Utvikler». Iblant tenker jeg at det heller burde stått «Avvikler».

Jeg jobber nemlig med avvikling av eldre IT-systemer, som skal erstattes med nye, moderne applikasjoner. At utvikling av nye IT-systemer kan være utfordrende er nokså godt kjent. At avvikling av gamle systemer kan by på sine helt egne utfordringer er noe det dessverre ikke snakkes like mye om.

Jobben med å erstatte systemet jeg jobber med startet en gang på 90-tallet og holder på fremdeles. Det er en lang og spennende historie, men det er ikke den jeg har tenkt å fortelle her. Jeg vil derimot si litt om hvorfor det er behov for å snakke mer om systemavvikling, hvilke vanskeligheter og utfordringer som er vanlig å møte når man forsøker å erstatte noe gammelt med noe nytt, og hvilke lærdommer vi bør ta med oss videre.

Hvorfor er systemavvikling et viktig tema? Er det ikke bare å skru av det gamle systemet når det nye er ferdig bygget?
Som regel er det ikke så enkelt. Overraskende nok kan avviklingen av det gamle systemet være mer komplisert enn utviklingen av det nye.

Må man bygge nye systemer når man allerede har noe som fungerer?
Kanskje et banalt spørsmål, men som jeg likevel mener er verdt å spørre seg. Hvis det eksisterende systemet fungerer bra, og det ligger an til å fungere greit i overskuelig fremtid, mener jeg at det er bedre å heller se på muligheter for å modernisere det systemet man har, fremfor å bygge og ta i bruk noe nytt. Det kan godt hende at det er mulig å bygge et nytt og moderne presentasjonslag over et aldrende, men stabilt og velfungerende system i bunnen.

Hvorfor må man avvikle gamle systemer?
Noen ganger vil man, etter en nøye vurdering, se seg nødt til å avvikle et gammelt system og bygge noe nytt. Ofte dreier det seg om:

• Kostnaden ved å drifte gammel teknologi videre
• Kompetansemangel og alderen på de som jobber med og kjenner systemet og teknologien
• Nye krav og økt kompleksitet som det gamle systemet ikke kan oppfylle
• End-of-life/end-of-support på sentrale komponenter

Drift- og lisenskostnader på en del eldre teknologier kan være betydelige og desto færre som er igjen på gammel teknologi, jo dyrere blir det gjerne. Leverandørene må fordele sine kostnader på færre kunder, eller de rett og slett ser sitt snitt til å håve inn mest mulig penger på de kundene som «sitter fast» på deres teknologiske plattform – fram til programvaren eller plattformen ikke supporteres eller lisensieres lenger. Det kan også være kostbart å skaffe nødvendig kompetanse, hvis det i det hele tatt er mulig, etter hvert som ekspertisen når pensjonsalder.

Samfunnet står heller ikke stille, og nye krav, forventninger, lover og reguleringer, organisasjonsendringer, endrede brukermønster, oppskaleringsbehov og økt kompleksitet kan ofte være faktorer som over tid gjør et ellers robust og godt system utilstrekkelig.

Hva er hovedutfordringene ved systemavvikling?
Det er mange ulike utfordringer, og hvert system er unikt, så det er umulig å svare generelt på dette. Jeg sorterer de vanligste utfordringene inn i følgende hovedområder:

• Økonomi
• Teknologi
• Kompetanse
• Tid
• Kompleksitet

Når man først har bestemt seg for å bytte ut et gammelt system med et nytt, vil fokuset og investeringene alltid være på utvikling av det nye systemet. I den grad man i det hele tatt tenker på avvikling av det gamle, så er det noe man alltids bare kan skyve på inn i fremtiden og som man ønsker å bruke så lite penger på som mulig. Så lenge det fremdeles fungerer og ikke skaper noen store problemer, så er det få som tenker på det.

Nyutvikling er komplisert, tidkrevende og kostbart. Det er to hovedstrategier man må velge mellom. Den første strategien går ut på å rulle ut det nye systemet fortløpende og at det tar over funksjonalitet gradvis. Dette krever at man må drifte både det nye og det gamle systemet i parallell. Dette kan være en svært krevende øvelse for organisasjonen, og noe jeg kaller for «den teknologiske spagaten».

Den andre strategien er mer velkjent. «Big Bang» går ut på at det nye systemet bygges mer eller mindre fullstendig ferdig før det settes i produksjon, og tar da helt og holdent over for det gamle systemet i sin helhet. Dette er iblant nødvendig, men som regel også svært risikabelt. Skulle man være så uheldig at det går fullstendig galt, sitter man tilbake med et ubrukelig nytt og kostbart system. Og enda verre, en fortsatt avhengighet til et gammelt system som sannsynligvis er i enda dårligere forfatning enn det var etter å ha blitt nedprioritert i budsjettene til fordel for en kostbar nyutvikling.

Systemavvikling er sjelden ett enkelt øyeblikk der man «slår av lyset» og går videre, men oftest en lang, krevende og risikofylt prosess som krever planlegging, kompetanse og tilstrekkelig investering.

Likevel behandles avvikling ofte som noe sekundært – et problem man kan ta senere, når det nye systemet endelig er på plass. Det er dette som gjør avvikling mer kostbart, langvarig og smertefullt enn det kunne vært.

Avvikling bør heller ikke være noe man først begynner å tenke på når et system nærmer seg slutten av levetiden. Det burde være en kontinuerlig aktivitet gjennom hele systemets livsløp. Håndtering av teknisk gjeld og fjerning av komponenter som ikke lenger brukes blir sjelden prioritert, fordi det ikke gir noen umiddelbar og målbar verdi. Det vil derimot gi potensielt store gevinster i avviklingsfasen

Gamle systemer forsvinner ikke av seg selv. De fortsetter å koste penger, binde kompetanse, skape risiko og legge føringer for hvordan organisasjonen kan utvikle seg videre. Skal man lykkes med modernisering, må avvikling sees som en integrert del av løsningen – ikke som en ettertanke.

Spørsmålet er derfor ikke om man har råd til å prioritere systemavvikling – men om man har råd til å la være.

Jeg tror AI endrer mer enn hvor raskt vi skriver kode. Den endrer også økonomien i alt limarbeidet rundt verktøyene våre. Et konkret eksempel er sikkerhetsskanning i CI/CD. Tidligere var det ofte fristende å velge den enkleste veien: bruke plattformens ferdige byggesteiner, ferdige actions eller ferdige pipeline-komponenter. Ikke nødvendigvis fordi det var den beste arkitekturen, men fordi alternativet kostet for mye tid å bygge og teste.

Nylig jobbet jeg med et oppsett for OWASP-relevant sikkerhetsskanning i Bitbucket. Målet var ikke bare å få skanningen til å kjøre. Målet var å gjøre løsningen mest mulig plattformuavhengig.

I praksis betyr det:

• skannelogikken skal bo i repositoryet
• pipelinen skal være et tynt orkestreringslag
• det skal være mulig å teste det samme lokalt som i CI
• ekstra installasjon og eksperimentering skal ikke forurense utviklingsmiljøet

Det høres kanskje trivielt ut, men det er nettopp her mange team tidligere har endt opp med sterk avhengighet til én CI/CD-plattform.

Hva var problemet?

Hvis man vil kjøre sikkerhetsskanning i en pipeline, finnes det ofte to veier:

1. Bruk en plattformspesifikk integrasjon
2. Bygg logikken selv med skript og verktøy du kontrollerer

Den første varianten er raskest å komme i gang med. Den andre varianten er ofte bedre på lang sikt, men har tradisjonelt kostet mer. Du må selv håndtere installasjon, miljøvariabler, rapportfiler, exit codes, lokal testing og drift av små detaljer som ellers er skjult bak en ferdig komponent. Det er nettopp denne kostnaden AI begynner å spise opp.

Hva ble løsningen?

I stedet for å legge skannelogikken inn i selve Bitbucket-pipelinen, ble den flyttet ned i egne skript.

Konseptuelt ser det slik ut:

Poenget er enkelt:

• Bitbucket eier ikke skannelogikken
• Docker Compose eier ikke skannelogikken
• Skriptene eier skannelogikken

Det gjør at samme oppførsel kan brukes både lokalt og i CI.

Et mer konkret eksempel

I stedet for å gjøre pipelinen tung og full av spesiallogikk, kan pipeline-steget være relativt tynt:

bash cli/scripts/run-scan.sh findsecbugs
[...]
bash cli/scripts/run-scan.sh osv

Det interessante her er ansvarsdelingen. I praksis det eneste pipeline gjør er å kjøre scriptet og publisere rapportene. Resten ligger i repositoryet.

Hvorfor Docker Compose fortsatt er viktig

Selv om pipelinen kaller skriptene direkte, er Docker Compose fortsatt svært nyttig som lokal harness.

Da kan man teste skanneoppsettet uten å:

• installere ekstra verktøy permanent på vertsmaskinen
• risikere å forurense eget utviklingsmiljø
• pushe små pipeline-endringer bare for å se om noe virker

Lokalt kan man tenke omtrent slik:

docker compose -f cli/docker-compose.yml run --rm findsecbugs
docker compose -f cli/docker-compose.yml run --rm osv-scan

Det gir et kontrollert miljø for prøving og feiling. Hvis noe går galt, kastes containeren. Hvis noe må endres, bygges den opp igjen.

Dette er også et nyttig sikkerhetsnett når man bruker AI-assistenter. Hvis arbeidsregelen er at AI kun får teste gjennom en isolert harness, reduseres risikoen for at den gjør uønskede endringer direkte i utviklingsmiljøet.

Hvorfor dette er lettere nå enn før

Det avgjørende poenget for meg er ikke at dette er mulig. Det har det egentlig alltid vært. Det nye er at det er blitt billigere å gjøre det skikkelig.

Tidligere var slike oppsett ofte i kategorien: «Ja, dette hadde vært ryddigere, men det tar for lang tid.»

Nå er vi nærmere: «Dette er ryddigere, og AI gjør det raskt nok til at det faktisk er verdt det.»

AI hjelper ikke bare med å skrive applikasjonskode. Den hjelper også med:

• skript
• konfigurasjon
• feilsøking
• små integrasjonslag
• iterasjon på tekniske detaljer

Det gjør at oppgaver som før var for små til å få prioritet, eller for kjedelige til å bli gjort ordentlig, faktisk kan løses på en mer robust måte.

En enkel illustrasjon av flyten

Det er dette som gir verdi:

• én logikk
• to kjøremiljøer
• mindre duplisering
• mindre plattformbinding

Det større poenget

For meg peker dette på noe større enn bare OWASP-skanning; Verdien av innebygde plattformbyggesteiner er i ferd med å falle.

Det som tidligere var en viktig del av forskjellen mellom én CI/CD-plattform og en annen, er ikke lenger en like sterk differensiator som før. Hvis AI reduserer kostnaden ved å bygge det som mangler selv, blir den strategiske verdien av ferdige plattformkomponenter mindre.

Det gjelder sannsynligvis ikke bare CI/CD.

Det kan også gjelde andre tradisjonelle programvareverktøy. Når AI gjør det billigere å lage avanserte interne verktøy, kan flere team velge å bygge det de faktisk trenger, i stedet for å tilpasse seg begrensningene i standardprodukter.

Men det kommer med en viktig forutsetning. Du må fortsatt vite hva du vil bygge. AI reduserer implementasjonskostnaden, men erstatter ikke arkitektonisk klarhet, teknisk dømmekraft eller evnen til å definere det riktige problemet.

Det er kanskje den viktigste lærdommen: AI gjør ikke nødvendigvis standardverktøy irrelevante. Men den flytter grensen for når det er verdt å bygge noe bedre selv.

Organisasjoner får stadig mer data som skal analyseres, samtidig som prosessene blir mer komplekse. En løsning på dette kan være Decision Intelligence.

En Decision Intelligence plattform gjør det mulig å koble data, regler og AI sammen for å ta presise og automatiserte beslutninger. Med Decision Intelligence ser virksomheter fremover, får konkrete anbefalinger for hva de bør gjøre, og kan kontinuerlig endre, forbedre og skalere beslutningsprosessene sine etter behov.

Under finner du ti av de vanligste spørsmålene vi får om Decision Intelligence. De handler om hvordan teknologien fungerer, hvem som bruker den, og hvordan Decision Intelligence, og plattformer som SMARTS, skaper verdi i alt fra operativ drift til strategisk styring.

FAQ om Decision Intelligence

1. Hva er Decision Intelligence?

Enkelt forklart handler Decision Intelligence om å hjelpe virksomheter å ta bedre beslutninger. Decision Intelligence kombinerer data, analyser, regler, modeller, kunnskapsgrafer, AI‑teknikker og domenekunnskap for å modellere og forbedre beslutninger på tvers av organisasjonen.

Gartner beskriver Decision Intelligence som en praktisk disiplin som forbedrer beslutningstaking ved å forstå og bevisst designe hvordan beslutninger tas, og hvordan resultater evalueres, styres og forbedres gjennom tilbakemeldinger. (1)

2. Hva er forskjellen på Decision Intelligence (DI) og Business Intelligence (BI)?

Business Intelligence forklarer hva som har skjedd gjennom rapporter som mennesker må tolke. Decision Intelligence går lenger ved å bruke data, forretningsregler og AI/ML til å anbefale, eller i noen tilfeller automatisk utføre, neste steg.

Business Intelligence er innsikt, mens Decision Intelligence er handling.

3. I hvilke industrier brukes Decision Intelligence? /Hvilke bransjer bruker Decision Intelligence?

Decision Intelligence brukes i industrier som håndterer store datamengder og komplekse beslutninger.

Det gjør den særlig relevant i bransjer som olje og energi, offentlig sektor, bank og finans, og forsikring. Løsninger som SMARTS gjør det mulig å automatisere beslutninger, redusere risiko og sikre mer presise prosesser på tvers av virksomheten.

Olje og energi

Offentlig sektor

Bank og finans

Forsikring

4. Hvem bruker en Decision Intelligence plattform?

Forretningsanalytikere, dataanalytikere, fagpersoner og forretningsledere er blant de mest sentrale brukerne av Decision Intelligence‑plattformer, sammen med ledere og operative roller som saksbehandlere.

Forretningsanalytikere beskriver og modellerer beslutningsprosesser på tvers av virksomheten. De identifiserer hvor forbedringer og automatisering kan gi størst effekt.

Dataanalytikere kombinerer data, bygger modeller, tester scenarioer og setter opp beslutningsflyt som kan optimaliseres og automatiseres over tid.

Fagpersoner definerer regler, kriterier og den faglige logikken plattformen skal følge. De sikrer kvalitet, likebehandling og etterlevelse av regelverk.

Forretningsledere får innsikt i hvordan beslutninger tas, hvilke regler som ligger til grunn og hvorfor utfallet blir som det blir, noe som gir bedre styring, transparens og kontinuerlig forbedring.

5. Når bør du, og når bør du ikke automatisere forretningsbeslutninger?

Automatisering av beslutninger passer best når virksomheten håndterer et større volum av vurderinger som gjentas ofte. Når logikk og regler endres og konsekvent behandling er viktig gir en Decision Intelligence Plattform som SMARTS stor gevinst. 

Strategiske og langsiktige beslutninger som tas færre ganger i løpet av samme periode bør ikke automatiseres. Disse krever gjerne menneskelig vurdering, dialog og konteksforståelse som ikke egner seg for regel og modellbasert automatisering. 

6. Hvordan kan SMARTS, en Decision Intelligence plattform, implementeres med eksisterende arkitektur?

Plattformen legges “på toppen” av eksistrende arkitektur. Plattformen håndterer alt av forretningslogikk og beslutninger og kan integreres opp mot organisasjonens enterprise økosystem via åpen API integrasjoner.

Ved å skille forretningsregler fra kjernesystemer gjennom SMARTS kan virksomheter raskt oppdatere regler og beslutningslogikk raskt ved endringer og behov.

7. Hvordan fungerer forretningsregler i Decision Intelligence?

Decision Intelligence kobler forretningsregler direkte opp mot data og virksomhetens beslutningslogikk. Reglene blir dermed ikke stående som statiske dokumenter, men vil kunne evalueres kontinuerlig i sanntid for å sikre presise og etterprøvbare beslutninger.

Dette gir transparens, sporbarhet og reduserer manuelle feil samtidig som komplekse beslutningsprosesser kan bygges opp av flere regler som filtrerer, prioriterer og beskriver ønsket handling.

8. Hvordan henger Decision Intelligence sammen med data analytics og AI?

Decision Intelligence bygger bro mellom data analytics og AI ved å bruke innsikt fra begge for å ta bedre beslutninger. Data Analytics forklarer hva som har skjedd og AI/ML kan forutsi hva som kan skje. Predikasjoner fra ML modeller kombineres med regler og datasett for å sikre at beslutningene er riktige, konsekvente og compliant. Når dette gjøres opp mot sanntidsdata blir beslutningene alltid oppdatert i tråd med med situasjonen og ikke basert på historikk alene. Dette gjør virksomheten mer presis, responsiv og datadrevet.

9. Hva er explainable og understandable decisions innen decision governance?

Etter hvert som flere beslutninger styres av data og algoritmer øker behovet for kontroll, transparens og etterprøvbarhet. Explainable decisions betyr at virksomheten kan vise hvorfor en beslutning ble tatt og hvilke regler og modeller som påvirker utfallet.

SMARTS har en “play-by-play» funksjon som viser beslutningen steg for steg. Det gjør det enkelt å forstå, justere og dokumentere logikken.

10. Hvordan støtter Decision Intelligence opp ledelsen?

Decision Intelligence hjelper C-levels med å omsette strategi til konsekvente, målbare og kontrollerbare beslutninger på tvers av organisasjonen. I stedet for at kritiske vurderinger avhenger av enkeltpersoner eller fragmenterte prosesser, sikrer Decision Intelligence at beslutningene alltid følger gjeldende strategi og regelverk. Dette reduserer operasjonell risiko og unødvendige kostnader ved å forhindre menneskelige feil og uønskede avvik i forretningsprosesser.

Strukturerte beslutningsmodeller gjør at endringer kan implementeres raskt og kontrollert, ofte på minutter i stedet for uker. Med SMARTS får organisasjonen en felles plattform der både forretning og IT jobber etter samme beslutningslogikk. Fagpersoner kan selv konfigurere og vedlikeholde beslutningene, uten å være avhengige av utviklere, noe som gir raskere tilpasning, tryggere styring og bedre forankring. Dette reduserer risiko, feil og uønsket variasjon i prosesser, samtidig som det styrker kvalitet, effektivitet og virksomhetens omdømme.

Med Decision Intelligence får ledere bedre innsikt i hva som påvirker beslutningene, hvor prosesser stopper opp og hvor flaskehalsene finnes, slik at strategiarbeidet blir mer datadrevet og presist. Resultatet er en organisasjon som blir betydelig mer smidig og endringsdyktig, uten å gå på bekostning av stabilitet eller kontroll.

Kilder

(1) Turning Gartner’s Decision Intelligence Definition into Action: A Conceptual Guide for Strategic Decision Makers | LinkedIn

I en tid der avanserte algoritmer og kunstig intelligens automatiserer stadig flere beslutninger blir forklarbarhet, evnen til å forstå og forklare hvordan en beslutning ble tatt, stadig viktigere. Dette handler ikke bare om teknikk; det er en forutsetning for tillit, transparens og etterlevelse av regelverk i mange bransjer. Enten det gjelder en bank som automatisk avslår en lånesøknad, eller en offentlig etat som fatter vedtak ved hjelp av AI, så vil både kundene, de ansatte og tilsynsmyndighetene vite: Hvorfor landet systemet på akkurat den beslutningen? 

Vi i Decisive jobber med slike spørsmål gjennom plattformen SMARTS™, en beslutningsplattform som kombinerer forretningsregler og maskinlæring. I dette innlegget ser vi nærmere på hva forklarbarhet innebærer, hvorfor det er kritisk for compliance (etterlevelse av lover og regler), og hvordan SMARTS™ støtter opp under forklarbar og forståelig beslutningslogikk. 

Hva mener vi med forklarbarhet?

Forklarbarhet (engelsk: explainability) er evnen til å gjøre det klart for mennesker hvorfor et AI-system eller en algoritme kom frem til et bestemt resultat eller en beslutning. Ofte nevnes også tolkbarhet (interpretability) i denne sammenhengen, evnen til å beskrive hvordan systemet kom frem til resultatet. Begge begrepene adresserer utfordringen med såkalte “black box”-modeller innen maskinlæring, der beslutningsgrunnlaget kan være ugjennomsiktig. Uten innsyn i logikken bak, kan automatiserte avgjørelser oppleves som mystiske eller urettferdige, og mangel på transparens fører til mistillit og øker risikoen for utilsiktet skjevhet i utfallet.

I både forskning og praksis har det vokst frem et eget felt kalt XAI (Explainable AI), som utvikler metoder for å åpne disse “black boxene”. Forklaringer kan være globale (gi innsikt i modellen som helhet) eller lokale (forklare hvorfor akkurat denne saken fikk dette utfallet).
To velkjente eksempler er:

SHAP (SHapley Additive exPlanations): En teknikk basert på kooperativ spillteori som tilordner hvert input-felt i modellen et betydningstall. SHAP kan brukes på alle typer ML-modeller og kvantifiserer hvor mye hvert faktor bidro, positivt eller negativt, til prediksjonen. (1)

LIME (Local Interpretable Model-Agnostic Explanations): En metode som bygger en forenklet, ”glassboks”-modell i nærheten av én gitt prediksjon. LIME tester små variasjoner av input og ser hvordan det påvirker utfallet, for å lære opp en enklere modell som imiterer den originale lokalt. Dette gir en menneskelig forståelig forklaring på hvorfor den opprinnelige modellen gjorde som den gjorde.

Disse metodene, og mange flere, hjelper data scientists å begrunne hva algoritmene driver med. Men i en virksomhetssammenheng er det ikke nok at ekspertene forstår modellene; forklaringene må være tilgjengelige for alle relevante interessenter. Beslutningstakere, fagansvarlige, revisorer og kunder har ulike behov for innsyn. Målet er derfor ikke bare forklarbar AI, men forståelig AI – at beslutningene er så åpne og dokumenterte at man kan ha tillit til dem.

Hvorfor er forklarbare beslutninger viktig for compliance?

For virksomheter i dag handler ikke dette bare om å “føle seg trygg” på AI – det handler om å oppfylle konkrete regulative krav. Vi ser en tydelig trend der myndigheter og bransjestandarder krever mer åpenhet i algoritmiske avgjørelser: 

• Finans: Bank- og kredittsektoren har lenge vært pålagt å kunne begrunne vedtak, f.eks. hvorfor en kunde får avslag på lån. Innfører man maskinlæring i kredittscoring, må man fortsatt kunne peke på faktorene som påvirket scoren. Retningslinjer fra EUs banktilsyn og nasjonale finansmyndigheter vektlegger “rett til forklaring” for kunder, og fraråder black boxes i kredittrisikomodeller. 

• Offentlig forvaltning: Etter blant annet forvaltningsloven i Norge har man krav på en begrunnelse ved individuelle vedtak. Når NAV, Skatteetaten eller UDI automatiserer vedtaksprosesser, må systemene kunne vise hvilke regler og data som ligger til grunn – enten det er eksplisitte regler eller en maskinlæringsmodell som har gjort en vurdering. Dette er nødvendig for rettssikkerheten og for tilliten til forvaltningen. 

• AI-forordningen (kommende): EUs AI Act, som trer i kraft i norsk rett sensommeren 2026, vil pålegge omfattende krav til dokumentasjon, risikovurdering og menneskelig tilsyn for AI-systemer. Et kjerneelement er evnen til å forklare og forstå AI-beslutninger som påvirker mennesker. Blant annet spesifiseres krav om at høyrisiko AI skal være transparent og forklarlig, og brukere skal informeres om at de kommuniserer med en maskin. Slike regler forsterker behovet for at virksomheter har stålkontroll på forklarbarheten i sine automatiserte beslutninger.  

Samlet sett betyr dette at forklarbarhet ikke lenger er valgfritt. Det er blitt et krav for compliance og god virksomhetsstyring. Hos Decisive merker vi dette på etterspørselen: mange av våre kunder, særlig i sterkt regulerte sektorer, ber oss om løsninger der “innebygd transparens” og etterprøvbarhet er på plass fra dag én. Vi har derfor lagt stor vekt på at SMARTS plattformen understøtter disse prinsippene ut av boksen. 

I SMARTS skilles beslutningslogikk fra øvrige systemer allerede i arkitekturen (ingen-hard-koding inne i applikasjonskoden), slik at reglene og modellene kan inspiseres separat. Alt som skjer i beslutningsmotoren loggføres og versjonshåndteres, slik at man kan gå tilbake og se nøyaktig hvilke regler eller hvilken modellversjon som førte til et gitt utfall. Sagt enkelt: hver automatiserte beslutning etterlater seg et spor man kan følge. Dette gir virksomheter trygghet om at de kan dokumentere overfor revisjon eller tilsyn hvordan beslutninger tas – et grunnlag for både intern kvalitetskontroll og ekstern compliance.  

Fra forklarbarhet til forståelige beslutninger

Det er verdt å innse at forklarbarhet alene ikke løser alle utfordringer. Selv med god teknisk innsikt i en model, må den settes i kontekst og kommuniseres godt for at alle involverte skal forstå beslutningene.

I praksis betyr dette å bygge beslutningssystemer som er transparente fra ende til annen. Det starter med design: Beslutningslogikken bør modelleres på en måte som mennesker finner intuitiv – for eksempel gjennom beslutningsdiagrammer, visuelle regler eller oversettbare forklaringer. Videre må alle automatiske beslutninger kunne spores tilbake til kilden: Hvilket datasett? Hvilke regler? Hvilken modellversjon? Og til slutt handler det om å dele informasjonen: Riktige forklaringer må kunne leveres til riktige mottakere – enten det er en saksbehandler som trenger detaljer for å overprøve en avgjørelse, eller en kunde som fortjener en enkel begrunnelse i et vedtaksbrev.

Tillit og ansvarlig AI kommer når denne kjeden er på plass. Forklarbare og forståelige beslutninger gjør at man kan utnytte kraften i AI og komplekse beslutningssystemer uten å miste oversikten og kontrollen. For ledere gir det trygghet at virksomheten opptrer i tråd med regelverk og etiske normer. For teknikere og analytikere gir det verdifull innsikt for å forbedre systemene kontinuerlig. Og for brukere og kunder gir det en helt nødvendig følelse av forutsigbarhet og rettferdighet.

Med stadig strengere krav til algoritme-ansvarlighet – fra EU, myndigheter og ikke minst markedet selv – vil forståelige beslutninger bli et konkurransefortrinn. De organisasjonene som lykkes med dette, vil lettere oppnå tillit hos sine kunder og samarbeidspartnere, og kunne ta i bruk avansert beslutningsstøtte på en bærekraftig måte.

Kilder

(1) https://www.sparklinglogic.com/explainability-in-decision-management/

Det er usikre tider for de som jobber med personvern og skytjenester. For å være mer presis, så er det er usikre tider for de som jobber med personvern og amerikanske skytjenester. Vi har vel alle fått med oss den noe usikre geopolitiske situasjonen i verden akkurat nå, noe som fører til at temaer som digital suverenitet, uavhengighet og «vendor lock-in» blir høyaktuelle. For hva skjer hvis disse tjenestene vi har gjort oss så avhengige av, plutselig blir utilgjengelige for oss, eller ulovlig å bruke?

Hvorfor påvirker dette oss?

Store deler av offentlige virksomheter og private aktører i Norge er i større eller mindre grad avhengig av infrastruktur, plattform eller programvare levert av amerikanske teknologigiganter. Om det så er virtuelle servere eller lagring, utviklingsverktøy og ferdige miljøer, eller applikasjoner som er klare til bruk. Disse skyløsningene understøtter kanskje ikke alltid kritisk infrastruktur eller kritiske samfunnsfunksjoner, men vil like fullt være systemer mange er avhengige av for å eksempelvis kommunisere eller samhandle internt i en virksomhet.

Hvis jeg plutselig ikke kunne kommunisert med mine kollegaer på e-post eller på Teams, ville jeg blitt relativt handlingslammet.

At e-post plutselig skulle blitt utilgjengelig virker nok usannsynlig for de fleste, kanskje også for sjefsaktor Karim Khan i Den internasjonale straffedomstolen i Haag, før han fikk sin Outlook-konto stengt av Microsoft (1). Man kan jo bare spekulere i hva bakgrunnen for deaktiveringen av Outlook-kontoen var, men i forkant av nedstengningen innførte den amerikanske presidenten og USA sanksjoner mot Den internasjonale straffedomstolen i Haag, og mot sjefsaktoren Karim Khan.

Selv om bakgrunnen for deaktiveringen av kontoen fortsatt er ukjent, har det i etterkant av dette blitt stilt spørsmål ved om europeiske myndigheter og borgere faktisk kan stole på amerikanske leverandører av skytjenester.

Usikkerhet knyttet til overføring av personopplysninger

En ting er at sentrale tjenester vi er avhengige av potensielt kan bli utilgjengelig for oss, noe som skaper en viss usikkerhet. På toppen av dette er allerede overføringsrammeverket EU-US Data Privacy Framework under press, da Trump-administrasjonen det siste året har gjennomført flere endringer som kan sies å undergrave beskyttelsesnivået for personopplysninger som overføres til USA ved bruk av skytjenester.

I starten av 2025 ble tre demokratiske medlemmer av Privacy and Civil Liberties Oversight Board (PCLOB) avsatt (disse medlemmene fikk for øvrig også sine e-post-kontoer stengt). PCLOB er et uavhengig klageorgan som spiller en kritisk rolle i å sikre at amerikanske etterretningsmyndigheter ikke krenker enkeltpersoners rettigheter, og det ble stilt spørsmål ved om det i realiteten vil være noen uavhengig kontroll av etterretningsaktivitet i USA (2). To av de avsatte medlemmene ble imidlertid gjeninnsatt (3).

I tillegg til dette har Trump-administrasjonen også innført presidentordren «Ensuring Accountability for All Agencies», som kan påvirke uavhengigheten til føderale organer som Federal Trade Commission (FTC). FTC skal fungere som et uavhengig tilsynsorgan for amerikanske virksomheter som mottar personopplysninger fra EU, noe som er en sentral forutsetning for overføringsrammeverket mellom EU og USA (4).

Til tross for disse endringene er overføring av personopplysninger til USA fortsatt lovlig, og EU-kommisjonen har enda ikke gått tilbake på sin vurdering av at amerikansk lovgivning og praksis ikke undergraver beskyttelsesnivået til personopplysningene som overføres. Det er likevel viktig å følge med på utviklingen og være klare til å tilpasse seg mulige endringer på kort varsel. Hvis adekvansbeslutningen fra EU-kommisjonen faller bort som overføringsgrunnlag, vil det være nødvendig å undersøke om det finnes andre aktuelle grunnlag som gjør overføring lovlig, f.eks Standard Contractual Clauses (SCC).

Hva gjør vi nå?

For å sikre kontinuitet i situasjoner hvor tjenester plutselig blir utilgjengelige eller ulovlig å bruke påpeker flere at det er avgjørende å ha en robust exit-strategi på plass. Jeg ser absolutt viktigheten i dette, men jeg tror samtidig at det vil være krevende å gjennomføre i praksis. Det vil kreve både tid, kompetanse og tilstrekkelig med ressurser for å migrere flere år med data, struktur, applikasjoner og tjenester fra én skytjeneste til en annen, eller tilbake til egen drift. I tillegg er det sikkert flere som har utviklet løsninger for å integrere skytjenesten med egne fagsystemer, noe som vil ta tid å bygge opp igjen.

Det er imidlertid ikke umulig. Danmarks to største kommuner, København og Aarhus, har byttet ut amerikanske skyleverandører til fordel for europeiske alternativer (5).

I påvente av oppdaterte reguleringer fra EU-kommisjonen eller føringer fra norske organer får vi følge utviklingen i USA tett, og sørge for at vi har oppdaterte risikovurderinger og oversikt over alle overføringer av personopplysninger til USA. Samtidig får vi håpe at de tjenestene vi er avhengige av ikke blir utilgjengelige for oss, eller ulovlig å bruke.

(1) Trump trua med bøter og fengsel – Microsoft kutta epost for ICC-aktor
(2) US Cloud soon illegal? Trump punches first hole in EU-US Data Deal
(3) Court Reinstates Fired Civil Liberties Oversight Board Members – MeriTalk
(4) EU-US Data Transfers: Time to prepare for more trouble to come
(5) København og Aarhus kutter Microsoft – skylder på Trump

Datamengdene vokser, beslutninger blir mer komplekse – og rom for menneskelig feil blir stadig større. For virksomheter som vil ta raske, presise og rettferdige avgjørelser, holder det ikke lenger med tradisjonelle regelbaserte systemer. Det er her Decision Intelligence kommer inn. 

Hos Decisive leverer vi plattformen SMARTS™, som gjør det mulig å bygge Decisioning Agents. I denne bloggen ser vi på hva en Decisioning Agent er, hvordan den brukes, og hvorfor den kan effektivisere prosesser som boliglånsbehandling. 

En undersøkelse fra MIT Technology Review og EY viser at 70 % av banker allerede bruker agentbasert AI, enten i pilotprosjekter eller i drift. (1) Decisioning Agents gjør boliglånsprosessen mer effektiv ved å bruke dokumentasjon, kredittscore og betalingshistorikk til å ta presise beslutninger. 

Hva er en Decisioning Agent?

Decisioning-agenter analyserer komplekse data, forutser behov og kan både ta autonome beslutninger i sanntid og forsterke menneskelig dømmekraft der full automatisering ikke er mulig eller ønskelig. Dette kalles ofte “human-in-the-loop”, en tilnærming som sikrer kontroll og kvalitet i kritiske beslutninger. I motsetning til tradisjonelle systemer med faste hvis-så-regler, bruker Decisioning Agents maskinlæring og avansert resonnering for å ta datadrevne beslutninger som tilpasser seg endrede forhold. 

Bruksområder for Decisioning Agents
 

• Bank og finans: Brukes til kredittvurdering, sikre compliance og svindelforebygging for å redusere risiko og øke lønnsomhet.  

• Olje og energi: Sørger for prediktivt vedlikehold og automatisering av ingeniørstandard for å redusere kostnader og minimere manuelle feil.

• Offentlig sektor: Automatiserer saksbehandling, kontrollerer regelverk og planlegger ressurser for mer effektive tjenester.

Slik lykkes du med Decisioning Agents

1. Start med et tydelig bruksområde
   Velg en operasjonell beslutning som skjer ofte og i stort volum, og som egner seg for automatisering. For eksempel:– Bør en kunde innvilges boliglån basert på innsendt dokumentasjon, kredittscore og tidligere betalingshistorikk?
    
2. Bruk en beslutningsplattform
   Når det gjelder boliglånsbehandling kan SMARTS hente inn relevant dokumentasjon, kjøre modeller for risikovurdering og bruke regelmotoren til å avgjøre om søknaden skal gå videre til manuell behandling eller godkjennes automatisk. Når de fleste søknader kan godkjennes automatisk kan saksbehandlere bruke tiden på andre arbeidsoppgaver som krever menneskelig vurdering.

3. Bevar menneskelig kompetanse
   Decisioning-agenter bør forsterke, ikke erstatte, menneskelig dømmekraft. La saksbehandlere håndtere unntak, som for eksempel søkere med uvanlig inntektsstruktur eller spesielle livssituasjoner som ikke fanges opp av modellen.

4. Rull ut gradvis
   Start med lavrisiko-scenarier og skaler etter hvert som du validerer ytelse og nøyaktighet. Når det gjelder vurdering av boliglån kan man begynne med automatisering av søknader med høy kredittscore og stabil inntekt, og utvide til mer komplekse vurderinger etter hvert.

5. Planlegg for kontinuerlig forbedring
   Design tilbakemeldingssløyfer og triggere for retrening og prosessforbedring. For eksempel kan du oppdage at kunder med lavere inntekt og flere barn likevel har lav misligholdsrate. Dette kan tyde på at modellen overser viktige faktorer, og bør justeres. Kanskje bør du inkludere nye variabler – som antall forsørgede, type bolig, geografisk område eller stabilitet i arbeidsforhold – eller revurdere vektingen av eksisterende data. La oss si at du ser at kunder som har bodd lenge på samme adresse har lav misligholdsrate, selv om andre faktorer gir lav score. Da kan det være nyttig å inkludere «botid» som en variabel i modellen. 

Decisioning Agents gir mer tilpasningsdyktige beslutningssystemer. Med en plattform som SMARTS kan du enkelt endre, forbedre og automatisere beslutninger. Du får en løsning som er fleksibel og skalerbar, slik at virksomheten kan reagere raskt på endrede markedsforhold og redusere risiko.

Nysgjerrig på hvordan dette fungerer i praksis? Kontakt oss for en demo. 

Kilde 

1. Reimagining the future of banking with agentic AI | MIT Technology Review 

Mye av infrastrukturen i norsk olje- og energisektor er eldre enn planlagt levetid. Plattformer, strømnett og operativt som egentlig skulle vært skiftet ut, må nå driftes videre i mange år – ofte med begrensede ressurser og økende krav til effektivitet og sikkerhet. Dette krever kontinuerlig vedlikehold og bedre beslutningsprosesser.

Decision Intelligence Plattformen SMARTS™ hjelper olje- og energibedrifter med prediktivt vedlikehold for å redusere nedetid, automatisering av ingeniørstandarder for å unngå manuelle feil og forsinkelser, og dokumentert compliance for å møte stadig strengere krav til sikkerhet og bærekraft. Plattformen har verktøy for å modellere, automatisere og dokumentere beslutningslogikk – slik at driften blir tryggere, mer effektiv og fullt sporbar.
 

Bruksområder i olje- og energibransjen

Prediktivt vedlikehold og operasjonell effektivitet

Uforutsette nedetider og høye vedlikeholdskostnader gjør det avgjørende for olje- og energibransjen å forutsi feil før de oppstår. Det er et stort behov for å digitalisere vedlikeholdssystemer for å redusere kostnader og øke oppetid – enten det gjelder oljeplattformer, kraftnett eller andre kritiske anlegg. 

SMARTS™ bruker sensordata og IoT til å modellere beslutninger som gjør vedlikehold mer smidig og effektiv. For eksempel kan oljeplattformer overvåke tilstanden på pumper, kompressorer og maskineri – og oppdage avvik tidlig, slik at vedlikehold kan planlegges i forkant. 

Sanntidsinnsikt i utstyrstilstand gjør det mulig å optimalisere vedlikeholdsplanlegging og redusere nedetid. Når nettutbygging tar tid, eller plattformer må holdes i drift med begrensede ressurser, blir det avgjørende å hente ut maksimal verdi fra eksisterende infrastruktur – gjennom datadrevne og dokumenterte beslutninger. 

Automatisering av ingeniørstandard

Olje- og energibransjen må følge strenge krav som ATEX-direktivet, TR2000-spesifikasjoner og trykkdirektiver for å sikre sikkerhet og compliance. I tillegg kommer det stadig nye reguleringer, som gjør det avgjørende for organisasjoner å kunne tilpasse seg raskt.

Dette er enklere med en Decision Intelligence-plattform som SMARTS™. Mange av dagens prosesser er fortsatt manuelle og tidkrevende, noe som øker risikoen for menneskelige feil – med potensielle konsekvenser som forsinkelser og økte kostnader.

Eksempler: 

• Skal en leverandør sende en ny tank til en plattform i Nordsjøen, må den oppfylle kravene i TR2000 og ATEX før den kan installeres. 

• Når et kraftselskap skal bytte en transformator i strømnettet, må den følge trykkdirektiver og funksjonskrav fra Statnett og NVE. (1) 

Med SMARTS™ kan bedrifter automatisere kontrollen mot ingeniørstandarder. Plattformen gir dynamiske svar, reduserer manuelle feil og gjør det enklere å skalere og bevare kompetanse når teamet endres. Over tid kan løsningen ved hjelp av maskinlæring identifisere mønstre hvor avvik oppstår og hvor man må bruke flere ressurser for å rette opp feilen.

Resultatet er raskere beslutninger, mindre menneskelige feil og en mer robust organisasjon som møter kravene til sikkerhet og dokumentasjon, uten unødvendige flaskehalser. 

Compliance og beslutningssporbarhet

Strengere krav til dokumentasjon, sikkerhet og bærekraft – fra regelverk som NIS2, GDPR og CSRD – gjør det avgjørende å ha kontroll på beslutningslogikk og etterlevelse. 

Olje- og energibransjen møter komplekse reguleringer, høye compliance-kostnader og betydelig risiko. Det krever systemer som håndterer rapportering, versjonshåndtering og risikostyring.

Med SMARTS™ implementeres beslutningslogikk direkte i plattformen. Vurderinger dokumenteres automatisk med full sporbarhet og versjonshåndtering. Plattformen evaluerer praksis opp mot regelverk, identifiserer gap og foreslår tiltak basert på historiske data. Ved avvik varsles virksomheten umiddelbart – slik at de kan handle raskt og presist. 

Olje- og energiselskaper som investerer i beslutningsautomatisering får en plattform som styrker drift, sikrer compliance og bevarer kritisk kompetanse. Med SMARTS™ blir det mulig å møte fremtidens krav med dagens ressurser. 

(1) NVF 2024 

På LinkedIn har vi delt fire råd fra våre utviklere og rådgivere de siste ukene og alle rådene er samlet i denne fagbloggen.

Først ut er Tobias som er teamleder for våre rådgivere og selv er rådgiver hos Bane NOR. Han leder arbeidet med utviklingen av nye prosesser for bygging og produksjon av ERTMS og TMS. Prosessene bidrar til økt effektivitet, bedre utnyttelse av Bane NORs egen kompetanse, samsvar med RAMS og en smidigere overgang til fremtidens digitale jernbane. Hans råd er knyttet til informasjonssikkerhet.

Tren på kontekstspesifikke phishing angrep

Eksempel:
Våre adgangskort må fornyes til å møte nye sikkerhetskrav i den nye DFF-forordningen og ditt nøkkelkort har fått utløpsdato 31.desember. Kontakt oss her for å fornye. Hilsen sikkerhetsansvarlig i resepsjonen (virksomhetens gateadresse).

Enkle grep kan gi store gevinster: Angrepene blir lettere oppdaget og stoppet før de får konsekvenser.

Beskytt verdier og omdømmetap: En bevisst organisasjon er bedre rustet til å håndtere sikkerhetshendelser.

Få innsikt i sårbarheter: Bruk simuleringer og opplæring til å identifisere hvor det er behov for forbedring.

Bygg trygghet: Gi ansatte og konsulenter opplæring i hvordan digitale trusler ser ut – og hvordan de skal håndteres. Del konkrete eksempler med ansatte.

Nestemann er Gabriel, han sitter hos NAV i Helserefusjonsteamet som fullstackutvikler. Han jobber med alt fra frontend for saksbehandlere til API-utvikling og databasehåndtering. Han er med på å fornye og vedlikeholde frikortløsningen – en viktig del av helsesystemet som mange er avhengig av.

Refaktorer jevnlig

Som utvikler, ser jeg at det er viktig å refaktorere jevnlig for å unngå at teknisk gjeld bygger seg opp over tid. Det gjør koden enklere å vedlikeholde og reduserer risikoen for feil når vi skal legge til ny funksjonalitet.

Det tredje rådet kommer fra Pernille som sitter hos Statens vegvesen som rådgiver og ivaretar personvern og informasjonssikkerhet ved bruk av store skyplattformer som Microsoft 365.

«Å ha god kontroll på hvilke personopplysninger man tillater å dele med leverandørene av disse plattformene er alltid viktig, men dette aktualiseres ytterligere i en tid med et urolig geopolitisk landskap.»

Nødvendige og valgfrie diagnosedata

Nødvendige diagnosedata er minimumsmengden av data leverandøren trenger å samle inn for å holde produktet sikkert, oppdatert og for at det skal yte som forventet.

Valgfrie diagnosedata derimot, er tilleggsdata som hjelper leverandøren med å forbedre produkter og tjenester, ved for eksempel å bruke aggregerte diagnosedata til å trene og forbedre funksjonalitet drevet av maskinlæring.

Siden diagnosedata inneholder pseudonymiserte personopplysninger, må vi forholde oss til kravene som stilles i personvernforordningen når vi behandler denne typen data.

Jeg anbefaler å kun tillate bruk av nødvendige diagnosedata, slik at vi minimerer hvilke personopplysninger vi utleverer til leverandøren.

Det fjerde og siste rådet for denne gang kommer fra Benjamin som sitter hos NAV sammen med Gabriel. Han er en del av Helserefusjonsteamet, hvor hverdagen går i utvikling, drifting, og forvaltning av systemer for frikortløsningen.

3 tips for å skrive bedre kode

1) Husk at noen andre skal lese og endre koden du skriver i dag en gang i fremtiden.

2) Finn den enkleste løsningen. Det er fristende å bruke mer kompleks funksjonalitet i koden for å finne en «perfekt løsning». Dette er ikke nødvendigvis en god ting da det fort kan bli mer komplekst og mindre endringsvennlig.

3) Skriv kode som forklarer seg selv. Man kommer langt med for eksempel godt beskrivende variabelnavn og funksjonsnavn.

Vi håper du får bruk for noen av disse tipsene!

Oktober er sikkerhetsmåneden, og det er en god anledning til å tenke på noe som kanskje kan være misforståelser om IT-sikkerhet. Som sikkerhetsansvarlig i en relativt liten bedrift med rundt 30 ansatte ser jeg daglig hvordan disse feilaktige oppfatningene kan skape falsk trygghet – og åpne dører for angrep vi kunne ha unngått.

Feilaktig oppfatninger om sikkerhet

«Vi er for små til å bli angrepet»

Mange små og mellomstore bedrifter tror at cyberkriminelle kun jakter på de store fiskene.

Realiteten er at moderne cyberangrep i stor grad er automatiserte. Angripere bruker verktøy som skanner hele internett etter sårbarheter, og bryr seg ikke nødvendigvis om målet er en bedrift med 10 eller 10 000 ansatte. Mindre bedrifter kan være attraktive mål fordi de ofte har mindre ressurser til forsvar, men fortsatt har verdifulle data.

«Sterke passord er nok»

Vi har alle lært at passord må være sterke nok: minst 12 tegn, kombinasjon av store og små bokstaver, tall og spesialtegn. Men er det nok?

Selv det sterkeste passordet kan kompromitteres på måter som ikke har noe med styrken å gjøre. Phishing-angrep, keyloggere, databaselekkasjer hos tredjepart, eller rett og slett at noen ser over skulderen din når du skriver det inn. Derfor er multifaktorautentisering (MFA) en viktig ekstra barriere som øker sikkerheten betydelig.

«Vår IT-partner håndterer all sikkerhet»

Mange bedrifter har outsourcet IT-driften til profesjonelle leverandører. Det gir en falsk følelse av at «noen andre tar seg av sikkerheten».

IT-partneren deres sikrer infrastrukturen – servere, nettverk, oppdateringer og backups. Men de kan ikke forhindre at en ansatt klikker på en phishing-lenke, deler påloggingsinformasjon over telefon, eller laster ned en infisert fil. Mennesket er fortsatt det viktigste sikkerhetslaget.

«Antivirus beskytter oss mot alt»

Antivirus har vært ryggraden i IT-sikkerhet i flere tiår. Men verden har endret seg.

Moderne trusler er langt mer sofistikerte enn de klassiske virusene som antivirus-programvare ble designet for å stoppe. Zero-day sårbarheter, målrettede angrep og sosial manipulering går ofte helt forbi antivirus-beskyttelse. Antivirus er fortsatt et nødvendig lag, men det må kombineres med andre tiltak.

«Jeg gjenkjenner phishing når jeg ser det»

Mange av oss tror vi er immune mot phishing. Vi har hørt om nigerianske prinser og dårlig stavede e-poster.

Moderne phishing-angrep er skremmende overbevisende. Angripere bruker AI til å lage perfekt formulerte meldinger, de kopierer design fra ekte bedrifter, og de vet hvordan de skal skape tidspress som får deg til å handle før du tenker. Spear phishing kan inkludere detaljer om din jobb og kolleger hentet fra LinkedIn. Selv erfarne personer kan bli lurt – det handler ikke om intelligens, men om menneskelig psykologi. Jeg har selv måtte ta en telefon til sjefen min for å sjekke om en epost jeg hadde mottatt var reell eller ikke.

«Mac og Linux er immune mot malware»

Det har vært en oppfatning at kun Windows-brukere trenger å bekymre seg for virus og malware.

Ingen plattform er immune. Mens Windows historisk har vært det operativsystemet som har blitt angrepet oftest, ser vi en økning i malware rettet mot macOS og Linux. Etter hvert som Mac blir mer populær i bedriftsmarkedet, investerer angripere mer i Mac-malware. Og uansett plattform: phishing og utnyttelse av dårlige passordvaner fungerer overalt.

«Sikkerhetsbrudd skjer bare hos store selskaper»

Når vi leser om sikkerhetsbrudd i media, er det stort sett de store navnene som får oppmerksomhet.

Små og mellomstore bedrifter rammes også hyppig. Forskjellen er at de store har kommunikasjonsavdelinger som håndterer krisen offentlig. Når en lokal bedrift med 30 ansatte blir rammet av ransomware, havner det sjelden i avisene. Erfaring viser at mange små bedrifter som opplever et alvorlig sikkerhetsbrudd får betydelige utfordringer etterpå.

«Sikkerhet hemmer produktivitet»

Dette er en vanlig innvending: «Hvis vi gjør alt for sikkert, blir det for tungvint å jobbe.»

Dårlig designet sikkerhet hemmer produktivitet. God sikkerhet kan faktisk gjøre det motsatte. Single Sign-On (SSO) betyr at ansatte slipper å huske mange forskjellige passord. Passkeys og biometrisk autentisering er både sikrere og raskere enn tradisjonelle passord. Når sikkerhet bygges inn i verktøyene vi bruker daglig – i stedet for å legges på som et ekstra steg – blir det en naturlig del av arbeidsflyten.

«Vi har backup, så ransomware er ikke farlig»

Backup er en kritisk del av ethvert sikkerhetsprogram. Mange tenker: «Hvis vi blir rammet, bare gjenoppretter vi fra backup.»

Moderne ransomware-grupper bruker dobbel utpressing. Først stjeler de alle dataene til bedriften – kundeinformasjon, forretningshemmeligheter og ansattes personopplysninger. Deretter krypterer de systemene. Selv om bedriften har god backup og kan gjenopprette alt, truer angriperne med å publisere alle dataene de stjal hvis bedriften ikke betaler. I tillegg oppdager mange for sent at backupen ikke fungerer som den skal.

Konklusjon: Sikkerhet er en holdning, ikke en sjekkliste

Det disse oppfatningene har til felles er at de skaper falsk trygghet. De får oss til å tro at sikkerhet er noe vi kan «bli ferdig med».

Realiteten er at sikkerhet er en kontinuerlig prosess. Trusselbildet endrer seg, teknologien utvikler seg, og vi må hele tiden lære og tilpasse oss. I en bedrift som vår, med rundt 30 ansatte, er hver enkelt person en viktig brikke i sikkerhetspuslespillet. Når vi alle forstår truslene, kan gjenkjenne angrep, og vet hvordan vi skal reagere, blir vi kollektivt mye sterkere.

Bruk sikkerhetsmåneden til å snakke om disse mytene med kollegene dine. Jo mer åpent vi kan snakke om sikkerhet, jo bedre blir vi til å beskytte bedriften vår sammen!