Teorier om teknologi: verktøy eller verdi?

september 16, 2025

Når man jobber i sjiktet mellom juss og teknologi kan det være en utfordring å faktisk vite hva man snakker om, og også være sikker på at den du prater med har samme forståelse av begrepet teknologi. Det er kanskje grunnen til at vi forvaltningsinformatikere er særskilt glade i definisjoner.

Derfor er det sentralt i denne teksten å ha definert begrepet teknologi. Her har jeg en mistanke om at mange fort tenker på moderne teknologi som informasjonsteknologi og mekaniske innretninger, men teknologi er langt mer enn det.

Hva er teknologi?

Teknologi er praktisk anvendelse av kunnskap for å løse en oppgave, gjerne knyttet til et spesifikt område.[i] Teknologi kan både være en fysisk gjenstand eller en metode basert på eksisterende kunnskap. Teknologi er langt mer en mekanikk: En kopp er teknologi, ryggsekken din er teknologi – som benytter teknologi som gjør den vannresistent, tåler vekt og lett å bære – bøker er teknologi, binde- og trykkekunsten er teknologi, skriftspråket som formidler språket er teknologi og språk i seg selv kan også bli sett som en teknologi.

Perspektiver på teknologi

Figuren er basert på figur 3.1 i kapittel tre av Technology and society. Social networks, power and inequality (2016) av Anabel Quan-Haase, s. 45

Figuren over viser an modell som skiller mellom forskjellige tankesett innenfor teknologi. Den viser hvordan til to dimensjoner: hvorvidt teknologi er autonom (har kontroll over mennesker) vs. om teknologi er kontrollert av mennesker, og hvorvidt teknologien er nøytral eller har innebygd verdi.

De fire hovedteoriene vil ha noe overlapp mellom seg, men i korte trekk kan hver beskrives slik:

Teknologisk/sosial determinisme – Teknologisk determinisme er et perspektiv der teknologien driver samfunnsmessig utvikling, mens sosial determinisme er der samfunnet som er drivkraft for teknologisk utvikling. Innenfor begge perspektivene er teknologien sett på som en nøytral driver.

Instrumentalisme – Teknologi er til for å oppnå brukerens mål der mennesket er i full kontroll og bærer det fulle ansvar for konsekvensen av bruken. Teknologien kan heller ikke påvirke mennesker.

Substantivisme – Teknologien har innebygde trekk og effekt på samfunnet som former menneskers liv. Den er autonom og former mennesker rundt iboende mål.

Kritisk teori – Baserer seg på samme tilnærming som annen kritisk teori.[i] Teorien ser på hvordan maktstrukturer påvirker både samfunn og teknologiutvikling. Mennesket styrer teknologiutviklingen som igjen påvirker og understøtter eksisterende maktforhold i samfunnet. Dette en teori som ser på hvordan makt, samfunn og teknologi

De forskjellige teoriene vil kunne påvirke argumentasjon knyttet til samspillet mellom samfunn og teknologi.

Er det sosiale medier som skaper konflikt eller er det mennesket?

Dette er en diskusjon problemstilling som ofte dukker opp i sammenheng med debatten om regulering av sosiale medier. Diskusjonen blir ladet ved at noen av de som argumenterer mot restriksjoner rundt bruken av sosiale medier, bruker argumentet at det ikke er plattformene som blusser opp til konflikt, men mennesket som bruker dem, og at det derfor ikke er noen hensikt i å begrense tilgang til disse mediene.

En litt mindre dramatisk sammenligning er å si at det ikke er en hammer som velger å slå inn en spiker, det er mennesket som holder den som velger hvordan verktøyet skal brukes. Teknologien er kun et middel for å nå menneskets mål med den. I disse to ytterpunktene kan man se klare linjer til teoriene om instrumentalisme og substantivisme. Disse synspunktene kan sammenlignes med substantivisme (målet til sosiale medier er å skape konflikt) og instrumentalisme (sosiale medier er kun et verktøy mennesker har full kontroll over og ikke påvirker samfunnet).

Likevel er det vel ikke så enkelt?

Skal man slå ned en spiker velger de fleste en hammer fremfor en skrutrekker. Skal du sitte er nok en stol eller sofa førstevalget, selv om en seng, skjenk i rett høyde eller til og med en liten veikant kan duge i nød.

Dette er fordi disse teknologiene har tilbydeligheter (affordances) som gjør dem egnet til den oppgaven de er designet til å gjøre.[ii] En tilbydelighet er egenskaper ved gjenstander som styrer forholdet mellom mennesket og gjenstanden. For eksempel har en kopp en konkav form og en bunn som gjør at man kan helle væske i den uten at det renner ut, videre kan den ha en hank som gjør det lettere å ha varm drikke i den uten at man brenner seg mens man drikker. Tilbydeligheter antyder handlinger mennesker kan gjøre med gjenstander.

Man kan se på det slik at teknologien har et manus (script).[iii] Manuset er det som legger opp til at en handling gjennomføres med teknologien. Tilbydeligheter er den delen av manus som legger opp til handlingen. En benk kan tåle vekt og er i rett høyde, dermed er det i dens manus å legge opp til at noen setter seg på den. Noen kan også legge seg til å sove på en benk hvis den har tilbydeligheter som legger opp til behagelig nok søvn.

Justere på manus for å realisere regler

Manus kan skrives om for å justere handlinger. Hvis vi ser tilbake på eksempelet med en benk noen bestemmer seg for å sove på, er det mulig å justere på tilbydelighetene til benken for å gjøre denne handlingen mindre fristende. For eksempel ved å legge helling på benken, eller introdusere armlener midt på benken, eller gjøre den mindre behagelig å sitte eller ligge på over lengre tid, har man redusert tilbydeligheten til en benk for å introdusere en regel om at man ikke skal ligge på denne benken. Denne måten å designe benker på kalles fiendtlig arkitektur (hostile architecture), og er et eksempel på at man gjør teknologien mindre god til jobben sin for å oppnå et tilleggsmål. Her er teknologien menneskestyrt og med en iboende verdi. Teknologien har en innebygd moral som sier: «Noen mennesker er ikke velkomne».

Hvordan kan vi få alt til å handle om innbygd personvern?

Teknologi har moral og verdier kodet inn i manuset. Er en ikke klar over hvilke tilbydeligheter man legger inn i manuset risikerer man å lage et manus som er umoralsk. Samtidig vil det å være klar over tilbydeligheter og hvilket manus man ønsker for teknologien man bygger gjøre det lettere å styre det inn i en retning der man får innebygd etikk. Teknologi, alt fra gjenstander, software, metode og til og med språk kan designes for bedre personvern, sikkerhet eller andre rettigheter og krav.

Hvilke handlinger legger teknologien som bygges opp til?

Hva kan vi endre så den legger opp til en annen type handling?

Jeg mener dette er særlig viktig å tenke over når man skal benytte KI på måter som påvirker mennesker. Eksisterende maktforhold i samfunnet kan påvirke manuset til teknologien slik at den blir formet uten at vi nødvendigvis er klar over det, og det vil kunne gjøre selv velment teknologi uetisk.

 

 

[i] Technology | Definition, Examples, Types, & Facts | Britannica

[ii] Kritisk teori – Store norske leksikon

[iii] Norman, Donald A The design of everyday things

[iii] Verbeek, Peter-Paul Design ethics and the morality of everyday artifacts, Kapittel i Philosophy and design (1) 2008, s. 93.

Marianne Bang

Rådgiver

marianne.bang@decisive.no

Decision Intelligence – Bank og finans

september 10, 2025

I takt med at datamengden vokser og forretningsprosessene blir stadig mer komplekse, øker behovet for beslutningsstøtte som er rask, presis og skalerbar. Dette gjelder særlig innen områder med høy risiko og krav til nøyaktighet, som svindelhåndtering, compliance, innkreving og lånebehandling.

Utfordringer og løsning

Decision Intelligence plattformen SMARTS automatiserer og håndterer komplekse beslutninger knyttet opp til ulike fagområder.

Plattformen er bygget opp som en low-code/no-code løsning som bygger bro mellom forretningssiden og IT. Dette åpner opp for at ulike fagområder aktivt kan delta i beslutningslogikken via en felles plattform for modeller og regler.

Viktige problemstillinger

 

Svindelmetoder blir mer sofistikerte og volumet av transaksjoner gjør manuell overvåking umulig.

SMARTS kan oppdage mistenkelige transaksjoner og mønstre i store mengder data ved bruk av prediktive analyser og maskinlæring. Dette gjør at nye svindelmetoder oppdages og håndteres raskere.

Banker må forholde seg til stadig strengere krav fra myndigheter som for eksempel GDPR, Basel III, AML, ESG. 

SMARTS gir full oversikt og synlighet innen compliance og risikostyring. Beslutninger kan automatiseres med innebygd sporbarhet og revisjonshistorikk. Det gir full oversikt over beslutningsgrunnlag ved tilsyn og forenkler dokumentasjon og rapportering.

Presise, rettferdige og datadrevne vurderinger er avgjørende for moderne bank- og finansvirksomheter.

Med SMARTS kan organisasjoner kombinere prediktive modeller med beslutningsregler for å automatisere og forbedre vurderinger knyttet til kreditt og lån. Forretningssiden kan selv simulere effekten av nye strategier, som for eksempel endringer i scoringsmodeller, risikokriterier eller lånebetingelser, før de implementeres.

I tillegg gir SMARTS mulighet til å overvåke og justere beslutningslogikken i sanntid, slik at man kontinuerlig kan optimalisere prosessene, redusere risiko og sikre rettferdig behandling av kunder.

Raskt skiftende marked krever rask omstilling og innovasjon.

Med SMARTS kan forretningssiden selv utvikle, teste og justere beslutningsstrategier uten å være avhengig av IT-personell. Dette gir forretningssiden mer kontroll ettersom alt av beslutninger og beslutningslogikk gjøres i et low-code/no-code miljø.

Man kan simulere ulike prisstrategier og se effekten i sanntid, sette opp regler for prising basert på kundedata, teste nye strategier gjennom Champion/Challenger metoden, overvåke KPI-er og justere logikken løpende basert på resultater. Dette gir kortere tid fra idé til marked og mer treffsikre beslutninger som gir økt lønnsomhet og kundetilfredshet.

Tobias Eritsland

Ta kontakt om du vil høre mer

+47 905 85 568

tobias.eritsland@decisive.no

Javazone 2025

september 9, 2025

JavaZone er et høydepunkt for oss hvert år. Det er en møteplass for utviklere og teknologer fra hele landet.

I etterkant av konferansen har vi snakket med tre av våre utviklere, Bengt Olav, Tosif og Scott om hva de lærte, hvilke foredrag som gjorde mest inntrykk, og hva de likte best med å være på JavaZone.

Bengt Olav sitter hos NAV på Infotrygd

1. Hva lært du på Javazone 2025?

«Jeg gikk ikke på så mange rene «how-to» sesjoner, men føler jeg lærte en god del likevel, ved å høre på kloke mennesker med mye mye erfaring og gode idéer. Det mest konkrete læringsutbyttet fikk jeg nok på innledningen om de vanligste design-fellene å gjøre i REST-APIer. Å lære av andres feil skal man ikke undervurdere!»

2. Beste forelesningen du var på?

«Det var som vanlig mange gode innledninger på JavaZone i år og jeg var veldig godt fornøyd med samtlige av de jeg gikk på. Jeg vil kanskje spesielt trekke frem tidligere teknologiprinsipal i NAV, Truls Jørgensen. Ikke bare holdt han et veldig godt og inspirerende innlegg om hva vi bør lære av gode applikasjonsplattformer, men han fikk også ordet under innlegget til sine tidligere kollegaer Audun Fauchald Strand og Trond Arve Wasskog om «software vi kan leve med». Der fikk han komme med det gode poenget at det er bedre for organisasjonen din at du som utvikler motstår den naturlige trangen til å skrive kode som er så kort, elegant, smart og intrikat som mulig. For alle de utviklerne som skal inn og gjøre endringer i koden din i mange år fremover er det bedre at du heller skriver kode som er lett å lese og tyde og gjøre endringer i.»

3. Generelt, hvordan syns du det var å være på Javazone og hva likte du best?

«Jeg syntes det var veldig fint å få gå på JavaZone igjen, for det er mange år siden sist. Jeg synes de har en fin miks av ting å se og gjøre og lære. Det var mange gode innledninger og jeg hadde mange hyggelige og interessante samtaler med folk på de forskjellige partnerstandene. Fremfor alt var det hyggelig å se igjen så mange gamle kjente kollegaer og få en oppdatering på hvor de er, og hva de jobber med nå. Og så var det mye god mat der, selvfølgelig!»

Tosif er en del av turnusteamet i Decisive

1. Hva lært du på Javazone 2025?
«Jeg lærte mye om AI, MCP-servere og risikovurdering i infrastruktur og kode. Fikk nyttig innsikt i hvordan man designer gode REST API-er. I tillegg lærte jeg hvordan man kan redusere byggetider og få hot reload i Java med Quarkus.»

2. Beste forelesningen du var på?
«Den beste forelesningen var «Top 10 REST API Design Pitfalls» med Victor Rentea. Han var en dyktig foredragsholder, og jeg kommer definitivt til å bruke flere av tipsene hans i mitt API-arbeid.»

3. Generelt, hvordan syns du det var å være på Javazone og hva likte du best?
«Det var min første gang på JavaZone, og jeg syntes det var veldig lærerikt. Det var hyggelig å møte både nye og kjente fjes. Jeg er spent på å se foredragene jeg gikk glipp av.»

Scott sitter hos NAV på Starte Pensjon teamet

1. Hva lært du på Javazone 2025?»
«Jeg lærte mye om en strategi for å sikre seg at data i frontend er oppdatert; server side events (SSE).»

2. Beste forelesningen du var på?
«Mange gode forelesninger, den jeg likte best var Husbanken sin forelesning «State Management er noe drit», der de snakker om sin strategi og utfordringer rundt det å sikre at data er oppdatert på tvers av klienter i saksbehandlingsløsningen deres når det er flere brukere. «Writing code for the human brain: Optimize code for cognitive bottlenecks» var også veldig bra!»

3. Generelt, hvordan syns du det var å være på Javazone og hva likte du best?
«Det jeg likte best var å innse hvor lite IT Norge egentlig er, selv om det er masse folk der møter man konstant noen man kjenner, av og til folk man ikke har sett på mange år.»

 

Hva er Decision Intelligence?

august 18, 2025

Decision Intelligence (DI), eller beslutningsintelligens på godt norsk, er et fagfelt som oppstod som svar på den økende kompleksiteten i moderne beslutningstaking – spesielt i større organisasjoner. Tradisjonelle metoder som dataanalyse og ekspertvurderinger er ofte ikke tilstrekkelige alene. DI tilbyr i stedet en helhetlig og systematisk tilnærming til beslutninger, basert på: 

  • Klart definerte beslutningsmål, oversatt til formelle krav og spesifikasjoner 
  • En gjentakendebeslutningsprosess som kombinerer data, fagkunnskap og teknologi 
  • Endringskontroll, kvalitetssikring og compliance/sikkerhet for beslutninger på enterprise-nivå 
  • Visuell fremstilling av beslutningslogikk, som gir transparens og sporbarhet av beslutninger 

Gartner definerer Decision Intelligence som: 

«En praktisk disiplin som forbedrer beslutningstaking ved å forstå og designe hvordan beslutninger tas, og hvordan resultater evalueres, styres og forbedres gjennom tilbakemelding.» 

Hva er en Decision Intelligence Plattform? 

Mens DI er et tankesett og en metodikk, er Decision Intelligence Platforms (DIP) de teknologiske løsningene som gjør det mulig å sette dette tankesettet ut i produksjon. 

En DIP gir organisasjoner det de trenger for å modellere, automatisere og overvåke operasjonelle beslutninger – og dermed forbedre beslutningskvaliteten og ikke minst effektiviteten av beslutninger. 

Kjernefunksjoner i en DIP inkluderer: 

  • Modellering av beslutninger (f.eks. beslutningstrær, simuleringer, AI-modeller som Maskinlæring & Prediktive modeller samt ekspertmodeller)
  • Utførelse av beslutninger (f.eks. automatisering av beslutningsprosesser) 
  • Overvåking og evaluering (f.eks. knyttet opp mot KPI-er, dashboards) 

Ved å bruke en DIP kan organisasjoner skape et beslutningsøkosystem som både forsterker og – i de fleste tilfeller – automatiserer beslutninger. Resultatet gir en raskere responstid, høyere beslutningskvalitet og økt skalerbarhet av forretningskritiske beslutninger. 

Hvordan hjelper Decisive organisasjoner med å bli Decision driven? 

Hos Decisive har vi spesialisert oss på å hjelpe store og mellomstore organisasjoner som ønsker å ta steget inn i fremtidens beslutningstaking. Vi tilbyr: 

  • Teknologisk støtte for å implementere og skalere Decision Intelligence konseptet internt 
  • SMARTS-plattformen – som eneste leverandør i Norden av Sparkling Logic sin ledende Decision Intelligence-plattform 

Med SMARTS får våre kunder tilgang til en robust og fleksibel løsning for modellering, automatisering og overvåking av beslutninger. Kombinasjonen av faglig tyngde og teknologisk kapasitet gjør Decisive til en komplett partner for organisasjoner som ønsker å ta bedre, raskere og mer transparente beslutninger. 

Les om IMDi sitt effektive og brukevennlige beslutningsstøttesystem.

Luis Pinzon

Kommersiell direktør

luis.pinzon@decisive.no

Deceptive Patterns

august 12, 2025

I en ideell verden brukes teknologi for å hjelpe oss – gjøre livet enklere, mer effektivt, mer transparent.  Vi som utviklere vet at måten vi designer løsninger på, har stor betydning. Noen ganger brukes designet bevisst mot brukeren. Det er her deceptive patterns kommer inn.  

Dette handler ikke om dårlig design eller en bug. 
Det er rett og slett designet sånn med vilje. 

Har du opplevd noen av disse eksemplene på nett?

1. Skjulte avhukinger i vilkår

Når du godkjenner Terms & Conditions, er det ofte andre bokser allerede krysset av – som samtykke til markedsføring, nyhetsbrev eller datadeling. Alt presenteres som én handling, men du har egentlig samtykket til langt mer enn du tror.

2. Cookie-dialoger uten “Avvis alle”

Tidligere kunne du enkelt trykke “Godta” eller “Avslå”. Nå er “Godta” grønn og stor, mens “Tilpass” ofte fører deg inn i et labyrintisk klikk-mareritt. Mange sider gjør det også umulig å avvise alle med ett klikk. 

3. Roach Motel – lett å komme inn, vanskelig å komme ut

Å registrere seg tar 20 sekunder. Men skal du avslutte? Da må du sende e-post, vente x antall dager, og kanskje til og med ta en telefon. Det er designet for at du skal gi opp. Det kan også være ganske vanskelig å finne ut av hvor/hvordan man skal si opp. 

4. Confirmshaming

«Vil du avslå dette fantastiske tilbudet?» – med en nei-knapp som sier: 
«Nei takk, jeg liker å betale full pris.»
Det spiller på skyld og sosiale normer for å få deg til å si ja. 

5. Gjemte kostnader

Du tror du er ferdig med en booking, men på siste steg dukker det plutselig opp et “behandlingsgebyr” eller “avgift” som aldri ble nevnt. Du betaler det – fordi du ikke orker å begynne på nytt. 

6. Fear of missing out

Et annet vanlig deceptive pattern er å utnytte frykten for å gå glipp av noe, også kjent som FOMO. Dette skjer når nettbutikker sier ting som:  

«KUN 1 igjen på lager!»  

«25 andre ser på denne varen nå.»  

«Holdt av varen i 5 minutter» med en nedtellingsklokke.»

Disse taktikkene skaper en følelse av knapphet og hastverk som får deg til å handle raskt, ofte uten å tenke deg ordentlig om. Selv om det noen ganger kan være ekte, er det mange tilfeller hvor disse tallene er kunstig generert eller overdrevet for å manipulere deg.  

⚖️ Når deceptive patterns koster milliarder

Dette er ikke bare dårlig stil. Det er ofte ulovlig. Flere selskaper har fått svi for å bruke manipulerende design: Amazon ble saksøkt av Federal Trade Commission i 2023. Amerikanske myndigheter mente Amazon gjorde det unødvendig vanskelig å si opp Prime. De kalte det en “roach motel”-strategi og tok dem til retten. (Sarnoff, 2023) 

I 2022 fikk Google en bot på rundt 1,5 milliard kroner av CNIL fordi det var enklere å akseptere enn å avslå cookies. Dette brøt med prinsippet om frivillig samtykke. Klassisk cookie-deceptive-pattern. (Milmo, 2022) 

Meta har hatt flere GDPR-brudd som har medført milliardbøter fra EU. Nylig i 2024 introduserte Meta en «Consent or Pay» modell der brukere måtte velge mellom å akseptere omfattende datadeling for målrettet reklame eller betale for en annonsefri tjeneste. EU kommisjonen fant at dette brøt Digital Markets Act fordi brukerne ikke fikk et reelt valg om en mindre datakrevende, men likeverdig gratis tjeneste (European Commission, 2025). 

Med andre ord så er det ikke bare brukerne som taper, men selskapene risikerer også store bøter. 

 

🎯 Hva er poenget med dette fagblogginnlegget?

Blir vi kvitt deceptive patterns? Sansynligvis ikke. De funker. Listen over eksempler er lang og det er umulig å nevne alle. Det viktigste er å være bevisst på dem.  

Vi må forstå når design brukes mot oss – og tørre å si ifra. Som utviklere har vi makt over detaljene, og ansvar for å forme løsninger som respekterer brukerne. Som brukere har vi rett til å være skeptiske, stille krav og kreve bedre løsninger.  

 

 

 

 

​​Bibliography

Deceptive Design. (n.d.). Deceptive Design. Retrieved from https://www.deceptive.design/

European Commission. (2025, 4 23). Commission finds Apple and Meta in breach of the Digital Markets Act. Retrieved from European Commission: https://ec.europa.eu/commission/presscorner/detail/en/ip_25_1085 

Milmo, D. (2022, 1 6). The Guardian. Retrieved from France fines Google and Facebook €210m over user tracking: https://www.theguardian.com/technology/2022/jan/06/france-fines-google-and-facebook-210m-over-user-tracking-cookies 

Sarnoff, M. (2023, 6 22). Feds accuse Amazon of using ‘dark patterns’ and ‘roach motel’ techniques to trick customers into auto-renewing Prime memberships. Retrieved from Law & Crime: https://lawandcrime.com/lawsuit/feds-accuse-amazon-of-using-dark-patterns-and-roach-motel-techniques-to-trick-customers-into-auto-renewing-prime-memberships/ 

Tosif Bhatti

Utvikler

tosif.bhatti@decisive.no

Ansvarlig bruk av kunstig intelligens – hvordan sikre trygg og etisk utvikling?

juni 19, 2025

Et av innsatsområdene i digitaliseringsstrategien «Fremtidens digitale Norge» er at vi skal utnytte mulighetene i kunstig intelligens. Regjeringen har en ambisjon om at Norge skal være i front på etisk og trygg bruk av KI, og at innen år 2030 skal 100 prosent av offentlige virksomheter ha tatt i bruk KI.

Det fremgår av strategien at utvikling og bruk av KI må skje på en ansvarlig måte – noe som indikerer at KI ikke skal tas i bruk for enhver pris. Det handler i stor grad om å finne gode brukstilfeller hvor det er hensiktsmessig og forsvarlig å bruke KI, for å utvikle bedre tjenester og løse oppgaver mer effektivt. Dette gjelder både i tilfeller hvor vi utvikler KI-baserte løsninger selv, men også i de tilfellene vi tar i bruk KI-funksjonalitet som er integrert i IT-løsninger vi allerede bruker i dag, slik som eksempelvis M365 Copilot. Slik funksjonalitet har vi i mye mindre grad mulighet til å skreddersy selv, da verktøyet leveres «ferdig» fra leverandøren.

Hvordan kan vi sikre at leverandørene av disse løsningene har utviklet de på en måte som understøtter etisk og trygg bruk?

Inga Strümke skriver i boken «Maskiner som tenker» om et eksperiment kalt The Moral Machine, utviklet av forskere ved Massachusetts Institute of Technology (MIT). Eksperimentet går i korte trekk ut på å undersøke hvordan mennesker fra forskjellige deler av verden ville prioritert hvilket liv som skulle reddes i situasjoner med selvkjørende biler. Funnene fra eksperimentet viser at moralske preferanser varierer mellom ulike kulturer og regioner (1). Hun skriver videre at folkegrupper med ulike kulturelle bakgrunner og verdigrunnlag har ulike etiske preferanser, noe som igjen vil føre til at teknologi utviklet i ulike deler av verden sannsynligvis vil baseres på ulike etiske avveininger (2).

Jeg tenker at dette er viktig å ha i bakhodet når vi vurderer å ta i bruk løsninger med kunstig intelligens fra ulike (særlig ikke-europeiske) leverandører. Det siste året har store deler av min arbeidshverdag gått med til å utrede og vurdere funksjonaliteten i verktøyet M365 Copilot, som leveres av Microsoft. Derfor har jeg også valgt å bruke M365 Copilot og Microsoft som eksempel i dette blogginnlegget. For å gjøre en samvittighetsfull vurdering av om dette er et verktøy man bør ta i bruk, er det nødvendig å se på hvordan utviklingen av verktøyet har foregått. Er verktøyet utviklet på ansvarlig måte som legger til rette for etisk og trygg bruk?

For å vurdere dette har det vært naturlig å ta utgangspunkt i rammeverket Microsoft Responsible AI Standard. Microsofts tilnærming til utvikling av ansvarlig kunstig intelligens er forankret i seks kjerneprinsipper, som er konkretisert og omgjort til praktisk veiledning i dette rammeverket. De seks kjerneprinsippene er som følger:

  • Fairness
    – AI systems should treat all people fairly
  • Reliability and safety
    – AI systems should perform reliably and safely
  • Privacy and security
    – AI systems should be secure and respect privacy
  • Inclusiveness
    – AI systems should empower everyone and engage people
  • Transparency
    – AI systems should be understandable.
  • Accountability
    – People should be accountable for AI systems.

Ved første øyekast ser det ut til at prinsippene som legges til grunn i Microsoft Responsible AI Standard i stor grad samsvarer med de syv etiske prinsippene for ansvarlig og pålitelig KI i kapittel 5.2 i Nasjonal strategi for kunstig intelligens fra 2020. Her heter det at KI-baserte løsninger skal respektere menneskets selvbestemmelse og kontroll, være sikre og teknisk robuste, ta hensyn til personvernet, være gjennomsiktige, legge til rette for inkludering, mangfold og likebehandling og være nyttig for samfunn og miljø. Det stilles også et krav til ansvarlighet.

Betyr dette at vi umiddelbart kan konkludere med at verktøy som er utviklet etter Microsoft Responsible AI Standard legger til rette for etisk og trygg bruk av KI?

Prinsippet om at KI-baserte løsninger skal ta hensyn til personvernet (som vi finner i Nasjonal strategi for kunstig intelligens) innebærer at kunstig intelligens som bygger på personopplysninger skal følge personvernforordningen. Dette vil eksempelvis innebære at hvis det inngår personopplysninger i det enorme datagrunnlaget språkmodellen i M365 Copilot er trent på, skal behandling av disse personopplysningene til det formål å trene språkmodellen ha et rettslig grunnlag for å være lovlig.

Vi vet ikke så alt for mye om det datagrunnlaget språkmodellen i M365 Copilot er trent på, men vi vet at dette består av enorme mengder tekst – millioner av bøker, artikler og nettsider. Jeg er sikker på at vi kan legge til grunn at det inngår personopplysninger i dette datagrunnlaget. I Norge og andre land innenfor EU/EØS gjelder personvernreglene også for personopplysninger som ligger åpent på nett. Hvordan dette fungerer i USA er jeg derimot usikker på. Med forbehold om at jeg ikke har inngående kunnskap om amerikansk personvernlovgivning, oppfatter jeg det slik at USA ikke har én overgripende personvernregulering slik vi har innenfor EU/EØS, men heller mindre, fragmenterte reguleringer på nasjonalt, statlig og lokalt nivå. Slik jeg ser det vil ikke dette være forenelig med sentrale prinsipper som ligger til grunn for europeisk personvernlovgivning, slik som prinsippet om forutberegnelighet – selv om et av de grunnleggende prinsippene i Microsoft sitt rammeverk er at utviklingen av KI skal respektere personvern («AI systems should be secure and respect privacy»).

Jeg antar også at datagrunnlaget språkmodellen er trent på i hovedsak er et amerikansk datagrunnlag, som dermed også gjenspeiler et amerikanske verdisett og kultur. Amerikanske verdisett og kultur vil ikke nødvendigvis harmonere med de verdisettene og den kulturen vi har i Norge. I vår nasjonale KI-strategi finner vi prinsippet om at KI-systemer skal legge til rette for inkludering, mangfold og likebehandling, og selv om to av kjerneprinsippene som ligger til grunn for Microsoft sitt rammeverk («Fairness» og «Inclusiveness») ser ut til å harmonere med det norske prinsippet, er det viktig å huske på at verdigrunnlaget som ligger til grunn for prinsippene kan være ulikt.

Disse problemstillingene gjelder selvfølgelig ikke kun ved bruk av KI-verktøy fra amerikanske leverandører, selv om jeg brukte Microsoft som eksempel i dette blogginnlegget. Jeg tenker at dette er relevant å ha i bakhodet uavhengig av hvilken leverandør du velger å kjøpe KI-løsninger fra – for å sikre at disse er utviklet på en ansvarlig måte.

(1) «Maskiner som tenker» s. 195

(2) «Maskiner som tenker» s. 196

Pernille Nilsen

Rådgiver

pernille.nilsen@decisive.no

Intervju med riksarkivar Inga Bolstad om ny arkivlov

juni 3, 2025

Decisive har besøkt Arkivverket på Sognsvann for å snakke med riksarkivar Inga Bolstad om den nye arkivloven, som nå er til første behandling i Stortinget (mai 2025). Den nye arkivloven er høyaktuell og vil få betydning for alle Decisives kunder i offentlig sektor.

Intervjuet er gjort av Tobias Vigmostad, sjefskonsulent og leder for rådgiveravdelingene i Decisive.

 

Om riksarkivaren 

Riksarkivaren er direktør og øverste leder for Arkivverket. Embetet ble opprettet i 1840. Nåværende riksarkivar er Inga Bolstad, som tiltrådte 1. oktober 2014 – og er den første kvinnen i denne rollen.

Som riksarkivar leder hun Arkivverket, representerer etaten utad og har også et sektorovergripende ansvar for hele arkivfeltet. Riksarkivarens myndighet er forankret i arkivloven og arkivforskriften.

 

Om Arkiverket 

Inga Bolstad forteller at Arkivverkets samfunnsoppdrag er å sikre og bidra til en effektiv dokumentasjonsforvaltning, gjennom langtidsbevaring av et rikt og mangfoldig utvalg av samfunnets arkiver.

«Vi skal ta vare på dem og gjøre dem tilgjengelige i minst 1000 år. Vi er på en måte nasjonens hukommelse,» sier Bolstad.

Arkivverket har en utviklingsrolle for hele arkivsektoren, i tillegg til en myndighetsrolle som innebærer å avgjøre hva som skal bevares og hva som kan kasseres. Arkivverket fungerer også som statens arkivmagasin.

Tobias Vigmostad

Sjefskonsulent og teamleder

tobias.vigmostad@decisive.no

Hvorfor du bør velge Kotlin over Java?

mai 21, 2025

5 gode grunner for backend-utviklere

Java har vært et av de største språkene i backend-utvikling i nærmere 25 år. Stabilt, modent og med et enormt økosystem, men med det kommer det kanskje mindre innovasjon. Kotlin er et moderne alternativ på JVM-plattformen som har vokst raskt frem og nå foretrekkes av mange. Språket kombinerer Java-kompatibilitet med nye funksjoner som kan øke lesbarheten og feilsikkerheten. Her er fem enkle grunner til hvorfor du bør velge Kotlin fremfor Java – uten at du trenger å gjøre drastiske omskrivinger.

 

  1. Null-sikkerhet

En feil mange utviklere er godt kjent med er «NullPointerExceptions». Dette er feil som forekommer når et objekts verdi ikke har blitt satt og håndteringen av dette ikke blir tatt høyde for. Alle verdier i Java tillater som standard en null-verdi, som betyr at det er lovlig med fravær av verdi.

Kotlin derimot skiller eksplisitt mellom nullable- og non-nullable-typer. Alt er non-null som standard, og ønsker du å tillate null, må du deklarere variabelen med ? (f.eks. String?). Kompilatoren tvinger deg til å håndtere alle null-tilfeller med safe calls (?.), Elvis-operatorer (?:) eller eksplisitte sjekker. Mange “NullPointerExceptions” fanges allerede ved kompilering, ikke i produksjon.

Dette gjør også koden lettere å lese, da man eksplisitt vet at en verdi er tillatt å inneholde null i Kotlin, hvor det i Java kan være usikkerhet rundt om dette er tiltenkt eller ikke. I Java er det ikke uvanlig at man bruker kommentarer eller annotasjoner (som @NotNull) for å markere at en funksjon eller et objekt ikke skal kunne returnere null, men dette har ingen praktisk effekt.

 

  1. Konsis syntaks, mindre boilerplate, string-templates

Kotlin fjerner mye av den gjentakende “seremonikoden” (boilerplate) som Java krever. Semikolon er valgfrie, typeinferens gjør at du sjelden skriver f.eks String flere ganger, og standardgettere/settere genereres automatisk. Dette fører til at du sparer linjer på klassedefinisjoner, konstruktører og enkle funksjoner. Smart casting og inline-funksjoner bidrar også til konsis kode.

Kotlins data-klasser gir også mye gratis kode. Med kun én linje;

får du automatisk toString(), equals(), hashCode() og copy(), uten at det tar visuelt plass eller tid å manuelt kode disse. Det finnes selvsagt biblioteker som tar dette inn for Java, men å slippe enda en avhengighet er også et pluss i boka.

String-templates i Kotlin er også merkbart bedre støttet, enklere å bruke og enklere å lese enn alternativene i Java. Hvor man i Java må bruke formatteringsfunksjoner eller +-operasjoner er det i Kotlin enkelt å skrive en full flerlinjet tekst uten kunstige stopp. Det er også en smal sak å bruke variabler i teksten med interpolasjonsuttrykk ($variabel). Dette er spesielt nyttig i loggmeldinger og feilmeldinger.

Resultatet er kortere, mer lesbar kode som er enklere å vedlikeholde.

 

  1. Extension-funksjoner

Kotlin lar deg “utvide” eksisterende klasser med egne metoder uten arv eller statiske hjelpeklasser. I Java må du for eksempel lage en egen statisk metode.

Hvis du vil lage en funksjon som for eksempel gir stor forbokstav i alle ord i en String vil du i Java være nødt til å lage en enkeltstående metode du kaller på.

Du vil også gjerne legge hjelpefunksjonen i sin egen klasse, noe jeg ikke har gjort i eksempelet nedenfor, som vil gjøre kallet lenger. (Typ StringFunksjoner.storForbokstav)

I Kotlin derimot vil du kunne utvide selve String-klassen og bruke denne hvor du vil, gitt at definisjonen ligger i samme pakke eller er importert:

Dette gir en mer objektorientert og lesbart API. Personlig har jeg hatt god nytte av dette for validering med utvidelsesfunksjoner som erGyldigEpostAdresse, erGyldigFødselsnummer, eller lignende.

4. Uttømmende when

When-uttrykket er en personlig favoritt. Dette er et godt alternativ til Java sin switch. Det kan matche på verdi, type, tilstand og brukes som uttrykk som returnerer verdier. I skjermbildet nedenfor ser dere et eksempel på dette:

Her ville man i Java kanskje brukt en lengre else-if som er langt mindre konsist og effektivt.

En annen fordel er hvordan when brukes med enums eller sealed classes (som heller ikke finnes i Java). I disse tilfellene tvinges man til å dekke alle tilfeller før kompilering. Det hindrer glemte verdier, tvinger oppdatering av when når enumen utvides i fremtiden og hindrer at feil verdi forsvinner i en generisk «else». Ikke minst gir det god lesbarhet, da du vet at alle alternativer er dekket når det finnes en when uten else.

  1. Java-kompatibel

Sitter du med følelsen av at du har lyst til å prøve Kotlin, men ikke har tid til å skrive om hele kodebasen som allerede er i Java så har jeg en god nyhet til deg. Kotlin er 100 % kompatibelt med Java. Du kan kalle Java-biblioteker rett fra Kotlin-kode og omvendt. Klasser kan skrives om hverandre, og det er ikke noe i veien for at neste klasse du lager er skrevet i Kotlin. Dette gjør det mulig å migrere én modul av gangen, skrive ny funksjonalitet i Kotlin og la resten av applikasjonen forbli Java. Om du skulle ønske å konvertere kode så har IDE-ene, i hvert fall IntelliJ innebygd verktøy som automatisk kan konvertere Java-filer til Kotlin. Oversettelsen blir ikke perfekt, men det gir et godt utgangspunkt. For team som allerede bruker Spring eller andre JVM-rammeverk, er det ingen hinder for å gradvis innføre Kotlin.

Hvis IntelliJ er din foretrukne IDE er det et pluss i boka, da det er JetBrains som står bak IntelliJ IDEA og Kotlin, noe som sørger for meget god verktøystøtte.

 

Konklusjon

Det er flere grunner til å velge Kotlin utenom de fem jeg har nevnt i dette blogginnlegget. Mange langt mer tekniske, for eksempel asynkrone korutiner. Dette var ment som en fordøyelig smakebit, og dersom du ble interessert anbefaler jeg deg å sjekke hvilke andre fordeler du kan få av å bytte til Kotlin.

Kotlin kombinerer null-sikkerhet, konsis syntaks, kraftige språkfunksjoner med full Java-kompatibilitet og god verktøystøtte. For backend-utviklere betyr dette økt produktivitet, færre runtime-feil og mer lesbar kode – uten at du trenger å kaste ut hele den eksisterende Java-kodebasen. Vil du redusere bug-raten, skrive renere kode og ha det litt mer moro som utvikler? Prøv Kotlin i ditt neste prosjekt, eller bare din neste klasse. Du vil raskt se hvorfor så mange har byttet fra Java!

Asgeir Aanonsen

Utvikler

asgeir.aanonsen@decisive.no

Hvordan skrive forretningregler på norsk

april 22, 2025

En guide til klare og presise forretningsregler med RuleSpeak®

Forretningsregler er avgjørende for å sikre at organisasjoner opererer i samsvar med lover, retningslinjer og interne prosedyrer. Dessverre blir slike regler ofte formulert på en måte som skaper forvirring, misforståelser og inkonsistente tolkninger.

I denne artikkelen skal vi se på hvordan RuleSpeak®, en metode for å uttrykke forretningsregler på naturlig språk, hjelper oss med å skrive regler som er klare, presise og utvetydige.


Hva er RuleSpeak®?

RuleSpeak® er en samling retningslinjer for å uttrykke forretningsregler på en strukturert og entydig måte. Retningslinjene er utviklet for å:

Forbedre kommunikasjon mellom forretningsfolk, analytikere og IT-utviklere
Sikre at regler er praktiserbare, uten å være for tekniske
Bygge bro mellom forretningslogikk og IT-systemer
Unngå vanlige feil, som tvetydighet eller unødvendig kompleksitet


5 grunnprinsipper for gode forretningsregler

1️⃣ Forretningsregler skal være deklarative, ikke prosessuelle

Dårlig regel (prosedyre-fokusert):
Hvis en kunde legger inn en ordre, sjekk om kunden eier en konto. Hvis ikke, avvis ordren.

God regel (deklarativ):
En kunde kan bare legge inn en ordre gitt at kunden eier en konto.

👉 Unngå regler som beskriver steg-for-steg-prosesser. Fokuser heller på hva som er tillatt eller ikke.


2️⃣ Bruk «skal» og «bare» for å gjøre reglene entydige

Dårlig regel:
En leietaker tillates ikke å delta i sameiets styre.

God regel:
En leietaker skal ikke delta i sameiets styre.

👉 Alle forretningsregler må inneholde enten «skal» (obligatorisk krav) eller «bare» (begrenset mulighet).


3️⃣ Unngå upresise uttrykk og overflødige ord

Dårlig regel:
En leveranse skal alltid ha en status.

God regel:
En leveranse skal ha en status.

👉 Ord som «alltid», «uten unntak» eller «på noe som helst tidspunkt» er ofte overflødige. Fjern dem med mindre de tilfører spesifikk betydning.


4️⃣ 🄰 Bruk presise subjekter og unngå flertall

4️⃣ 🄱 “Kan” uten “bare” er ikke bra

Dårlig regel:
Kunder kan kjøpe plantevernmidler hvis leverandøren har dem på lager.

God regel:
En kunde kan bare kjøpe et plantevernmiddel gitt at plantevernmiddelet finnes på leverandørens lager.

👉 Bruk entallsform og unngå generelle uttrykk som kan føre til tvetydighet. Forretningsregler gjelder for enkeltforekomster. Visse typer tvetydighet kan lett unngås ved å plassere subjektet i setningen i entallsform.

👉 Ordet “bare” innskrenker handlingsrommet, og uttrykket blir dermed en forretningsregel.


5️⃣ Aktører som subjekt er ofte ikke bra

Dårlig regel:
En kunde kan gjøre et uttak bare hvis kontoen er aktiv.

God regel:
Et uttak fra en konto kan bare gjennomføres gitt at konten er aktiv.

👉 En forretningsregel som indikerer en aktør som subjekt bør granskes nøye. Gjelder virkelig forretningsregelen bare for denne aktøren? Ofte er svaret nei. I så fall bør aktøren erstattes med et subjekt som ikke er en typisk aktør (f.eks. uttak, som ovenfor).

⁉️ Spør: Bare kunden?

↪ Hva med autoriserte tredjeparter?
↪ Hva om banken selv?
↪ Hva med andre aktører?


Oppsummering

Ved å bruke RuleSpeak kan vi skrive forretningsregler som er presise, klare og enkle å forstå. Husk disse 5 prinsippene:

🔹 Unngå prosessuelle regler – fokuser på hva som gjelder
🔹 Bruk «skal» og «bare» for entydighet
🔹 Fjern overflødige ord
🔹 Bruk entallsform og presise subjekter og unngå “kan” uten “bare”
🔹 Aktører som subjekt er ofte ikke bra

Ved å følge disse prinsippene sikrer vi at forretningsreglene blir forstått riktig, både av mennesker og systemer!


Ønsker du å lære mer? Sjekk ut RuleSpeak-veiledningene for flere detaljer om hvordan du kan uttrykke forretningsregler på en optimal måte.

RuleSpeak® har blitt utviklet av Ronald G. Ross siden 1996. Siden den gang har RuleSpeak blitt brukt i hundrevis av prosjekter av blant annet oss i Decisive og Business Rule Solutions, LLC (BRS). RuleSpeak har vært tilgjengelig på BRS nettsiden siden slutten av 1990-tallet.

Hva synes du om denne tilnærmingen? Har du eksempler på uklare forretningsregler fra din bedrift? Del gjerne dine erfaringer i kommentarfeltet under innlegget vårt på LinkedIn! 🚀

Alf-Kenneth Aabel

CTO, Arkitekt, Utvikler

alf-kenneth.aabel@decisive.no

Tobias Vigmostad

Teamleder og Rådgiver

tobias.vigmostad@decisive.no

Asfalt og krøtterstier

mars 26, 2025

Det er vår i luften, været blir varmere og snøen er endelig i ferd med å forsvinne! I dag bestemte jeg meg for å ikke ta t-banen hele veien til jobb, slik jeg må innrømme at jeg har gjort i hele vinter, men i stedet gå av noen stasjoner tidligere og gå resten av veien. En av fordelene med å jobbe i byen er at man kan gå på asfaltert vei og dermed komme seg tørrskodd på jobb, selv om vårløsninga er i gang. På akkurat den veien jeg går forutsetter det at jeg må gå en omvei rundt en gressplen. I likhet med de fleste andre gjorde jeg ikke det, og det er godt synlig…

Dette fikk meg til å reflektere litt over et begrep jeg kom over for noen år siden. På engelsk heter det «desire path». Det finnes ikke et veletablert begrep på norsk, men la oss kalle det for en «krøttersti». En krøttersti er en sti som oppstår der folk eller dyr ønsker å gå, og ikke der hvor by- eller landskapsplanleggere ønsker at man skal gå. En krøttersti kan for eksempel være en snarvei gjennom et hull i gjerdet, et hjørne som kuttes i et veikryss, eller sånn som på veien til jobb, en gjørmete sti som deler en ellers fin plen i to.

Krøtterstier er lett synlige i terrenget og oppleves ofte som skjemmende. Oppstår det en krøttersti settes det gjerne opp et skilt som sier «Ikke trå på plenen», eller kanskje det dukker opp et gjerde (som de fleste likevel klatrer over). Krøtterstier blir ofte gjenstand for en kamp mellom folk flest og frustrerte anleggsgartnere.

Som en analogi er krøtterstien svært treffende i mitt fag, som er programvareutvikling. Vi som er arkitekter og utviklere er planleggerne som har idéer og meninger om hvordan brukerne skal agere. Menyer, datafelter og informasjon blir plassert og organisert slik våre idealistiske planer og ønsker dikterer. Alt skal se flott og ordnet ut, og hvis brukerne bare gjør slik som vi ønsker, så blir alt helt tipptopp.

Men brukere er som folk flest, og vil gå der de selv ønsker. I møtet mellom programvare og bruker finner vi fort ut hvor krøtterstiene i programmene våre går. Vi, som tross alt er eksperter på slike ting, responderer helst med å forsøke å tvinge gjennom at programvaren skal brukes slik vi har bestemt. Vi må sette opp gjerder og skilt for å hindre uønsket adferd. Vi kaller det gjerne «patching» eller «bugfixing».

Når jeg i morges traverserte den nå litt blaute krøtterstien på vei til jobb, tenkte jeg at det hadde jammen vært fint om noen kunne asfaltert dette stykket over plenen, slik at jeg slapp å bli gjørmete på skoene. Jeg tenker at vi som utviklere kan lære to viktige ting av dette:

  1. Et godt forarbeid, der man kartlegger brukernes behov og ønsker, reduserer behovet deres for å tråkke opp egne stier i programvaren.
  2. Et godt etterarbeid identifiser krøtterstiene som unektelig oppstår, slik at de kan endres, tilpasses og asfalteres etter brukernes ønsker og behov.

Bengt Olav Olsen

Utvikler

bengt.olav.olsen@decisive.no