In the construction industry, profitability is determined at many critical moments, but three of them are common across the companies we speak with: when contractors decide which projects to bid on, when change orders arise on-site, and when subcontractors are to be qualified. All three occur under time pressure, and the consequences of wrong decisions directly impact margins, progress, and risk. 

A common thread among these decisions is that the necessary knowledge often exists, but it is held by individuals, stored in spreadsheets, and scattered across fragmented systems. This makes assessments dependent on specific individuals, and practices vary from project to project. The SMARTS™ Decision Intelligence platform structures these decisions and ensures that the company’s own criteria and priorities can be consistently applied across the organization. 

Applications in the construction industry

Project Selection and Bid Evaluation

Construction companies often receive far more requests for proposals than they have the capacity to evaluate. In many companies, prioritization is done manually, based on experience and scattered spreadsheets. It is a time-consuming process that results in inconsistent assessments, leading to resources being allocated to projects that are a poor fit for the company, or to expertise being sold on that later turns out to be unavailable when the project begins. 

SMARTS™ combines rule-based decision support with data-driven insights and automates project evaluations based on the company’s own criteria and strategic priorities. Matrices and spreadsheets are converted into executable rules, where the platform builds scoring models that rank projects based on profitability, strategic value, risk, geographic location, skill requirements, and actual available capacity. 

The result is consistent and traceable assessments, freeing up time for the costing and project teams, and ensuring that the company bids on the right projects with the right expertise before costly hours are spent calculating incorrect bids. 

Risk and Change Management

Change orders are one of the main causes of lost margins, disputes, and delays in construction projects. The assessment of what constitutes a change—and the risks it entails—is often made by people working directly on the projects. This results in inconsistent practices, lost claims for additional compensation, and disputes with the client. 

SMARTS™ integrates risk assessment directly into the workflow. The platform classifies incidents by risk level and according to the appropriate set of rules. The decision-making logic can be customized to the company’s matrices and adjusted by subject matter experts without the need for IT involvement. 

The result is full control over risk exposure, fewer lost additional claims, and a standardized process that ensures the company’s contractual rights are protected—even when projects are putting pressure on time and resources.   

Supplier and Subcontractor Qualification

The construction industry is made up of subcontractors, and the quality of the final product is rarely better than the weakest link in the chain. Requirements for HSE documentation, financial stability, certifications, integrity standards, and sustainability reporting make the qualification process both extensive and time-consuming. In addition, there are stricter requirements from public entities such as building owners and from the Transparency Act. 

With SMARTS™, the qualification of suppliers and subcontractors can be automated. The platform assesses whether a supplier meets specific requirements, combines internal and external data sources (such as public registries, central approval registries, and key financial indicators), and provides a transparent assessment of risk and suitability. The basis for the decision is automatically documented, ensuring that the qualification is traceable and reproducible—even years later in the event of an audit or dispute. 

The result is faster onboarding of new suppliers, reduced risk during project implementation, and a standardized process that can be scaled without a corresponding increase in compliance costs. 

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.

Oil and Energy

Public sector

Banking and Finance

Insurance

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/

These are uncertain times for those working in the fields of privacy and cloud services. To be more precise, these are uncertain times for those working in the fields of privacy and U.S. cloud services. We’re all well aware of the somewhat uncertain geopolitical situation in the world right now, which makes issues like digital sovereignty, independence, and “vendor lock-in” highly relevant. Because what happens if these services we’ve become so dependent on suddenly become unavailable to us, or illegal to use?

Why does this affect us?

Large parts of the public sector and private sector in Norway are, to a greater or lesser extent, dependent on infrastructure, platforms, or software provided by American tech giants. Whether it be virtual servers or storage, development tools and pre-configured environments, or ready-to-use applications. These cloud solutions may not always support critical infrastructure or critical societal functions, but they are nonetheless systems that many rely on for purposes such as communicating or collaborating internally within an organization.

If I suddenly couldn't communicate with my colleagues via email or Teams, I would be pretty much paralyzed.

The idea that email might suddenly become unavailable probably seems unlikely to most people—perhaps even to Chief Prosecutor Karim Khan of the International Criminal Court in The Hague—before Microsoft shut down his Outlook account (1). One can only speculate as to the reason behind the deactivation of the Outlook account, but prior to the shutdown, the U.S. president and the United States imposed sanctions against the International Criminal Court in The Hague and against Chief Prosecutor Karim Khan.

Although the reason for the account’s deactivation remains unknown, this incident has raised questions about whether European authorities and citizens can actually trust U.S. cloud service providers.

Uncertainty regarding the transfer of personal data

One issue is that key services we rely on could potentially become unavailable to us, which creates a certain degree of uncertainty. On top of this, the EU-US Data Privacy Framework is already under pressure, as the Trump administration has implemented several changes over the past year that could be said to undermine the level of protection for personal data transferred to the US through the use of cloud services.

In early 2025, three Democratic members of the Privacy and Civil Liberties Oversight Board (PCLOB) were removed from office (these members also had their email accounts shut down). The PCLOB is an independent oversight body that plays a critical role in ensuring that U.S. intelligence agencies do not violate individuals’ rights, and questions were raised as to whether there would in fact be any independent oversight of intelligence activities in the United States (2). However, two of the dismissed members were reinstated (3).

In addition to this, the Trump administration has also issued the executive order “Ensuring Accountability for All Agencies,” which could affect the independence of federal agencies such as the Federal Trade Commission (FTC). The FTC is to serve as an independent supervisory body for U.S. companies that receive personal data from the EU, which is a key requirement of the EU-U.S. data transfer framework (4).

Despite these changes, the transfer of personal data to the United States remains lawful, and the European Commission has not yet reversed its assessment that U.S. laws and practices do not undermine the level of protection afforded to the personal data being transferred. It is nevertheless important to monitor developments and be prepared to adapt to potential changes at short notice. If the adequacy decision from the European Commission is no longer valid as a basis for transfer, it will be necessary to investigate whether there are other applicable bases that make the transfer lawful, such as Standard Contractual Clauses (SCC).

What do we do now?

To ensure continuity in situations where services suddenly become unavailable or illegal to use, many point out that it is crucial to have a robust exit strategy in place. I certainly see the importance of this, but at the same time, I believe it will be challenging to implement in practice. It will require time, expertise, and sufficient resources to migrate several years’ worth of data, structure, applications, and services from one cloud service to another, or back to in-house operations. Additionally, many have likely developed solutions to integrate the cloud service with their own line-of-business systems, which will take time to rebuild.

However, it is not impossible. Denmark’s two largest municipalities, Copenhagen and Aarhus, have switched from American cloud providers to European alternatives (5).

While awaiting updated regulations from the European Commission or guidance from Norwegian authorities, we will closely monitor developments in the United States and ensure that we have up-to-date risk assessments and an overview of all transfers of personal data to the United States. At the same time, we can only hope that the services we rely on do not become unavailable to us or illegal to use.

(1) Trump threatens fines and jail time – Microsoft cuts off email access for ICC prosecutor
(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) Copenhagen and Aarhus Cut Ties with Microsoft – Blame 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!