AI-assistert utvikling gir 581 sårbarheter per kodebase

Hva AI-assistert utvikling faktisk betyr i åpen kildekode

AI-assistert utvikling betyr at utviklere bruker språkmodeller til å foreslå, fullføre, gjennomgå og feilsøke kode, i stedet for å skrive alt for hånd. En systematisk litteraturgjennomgang av AIs påvirkning på åpen kildekode beskriver hvordan verktøyene både driver frem nye prosjekter og endrer praksis for kodegjennomgang og repository-håndtering. Poenget for en leder er enkelt: dette er ikke lenger et eksperiment i utkanten av utviklingsavdelingen, det er blitt standardarbeidsflyten. Spørsmålet er ikke om teamet bruker AI, men hvor godt det som genereres blir styrt.

Det meste av denne aktiviteten skjer oppå åpen kildekode. 89% av organisasjoner som har tatt i bruk AI, bruker åpen kildekode AI i en eller annen form, og 90% av organisasjoner verden over bruker åpne teknologier et sted i stakken. Når vi snakker om risikoen ved AI-kode, snakker vi derfor om risiko i den koden nesten alle allerede kjører.

Definisjonen bak begrepet

Åpen kildekode AI er ifølge definisjonen systemer som er fritt tilgjengelige for bruk, studium, endring og deling. Open Source Initiative publiserte sin Open Source AI Definition 1.0 i 2024 etter to års konsultasjon, og definisjonen bygger på fire grunnleggende friheter. Kravet er strengt: ekte åpen kildekode AI må gi tilgang til kode, data og modeller, ikke bare vektene.

Skillet er verdt å holde fast ved, for det er ikke akademisk. Metas Llama-modeller har blitt beskrevet som åpen kildekode av Meta, men det er omstridt på grunn av lisensbegrensninger. For et team betyr det at etiketten «åpen» kan dekke alt fra fullt reproduserbare modeller til vekter med bruksrestriksjoner, og at du må lese lisensen før du bygger produksjonskode på den.

Hvorfor åpen kildekode ble AI-motoren

Veksten er dokumentert i tallene. GitHub registrerte 70 000 nye offentlige AI-prosjekter i 2024 og en økning på 98% i bidrag til AI-prosjekter. Stanford teller 5,6 millioner åpen kildekode AI-prosjekter, og 36 millioner nye utviklere ble med på GitHub i 2025, der 60% av årets raskest voksende prosjekter var AI-fokuserte.

Argumentet for åpenhet er praktisk. Åpen kildekode AI gir mer kontroll, klarhet og rom til å bygge slik du vil, og senker terskelen for små team. Verktøyene gir mer tilpasning enn lukkede alternativer og frihet fra leverandørlåsing. Det er den samme åpenheten som gjør det billig å komme i gang, og som samtidig sprer sårbar kode raskere enn noe team rekker å gjennomgå.

Skillet mot lukket kildekode

Forskjellen på åpent og lukket handler om innsyn. Lukkede modeller utvikles bak kulissene, og det indre virket er utilgjengelig, mens åpen kildekode AI er bygget rundt åpenhet, samarbeid og delt eierskap. Åpenheten gir mer transparens sammenlignet med lukkede alternativer, noe som er en fordel når du skal revidere hva modellen faktisk gjør.

Åpenheten koster også. Åpne modeller har færre måter å forhindre ondsinnet bruk på, og fleksibiliteten kommer med avveininger. Denne artikkelen handler mest om den ene avveiningen som treffer bunnlinjen hardest: sikkerheten og kvaliteten i koden AI hjelper deg å produsere.

Produktivitetsgevinsten og der den sprekker

Gevinsten er reell og godt målt. 85% av utviklere bruker AI-verktøy regelmessig, og over 80% bruker AI i arbeidsflyten sin. Verktøy som Copilot kan øke produktiviteten med opptil 94%, og AI-baserte kodeassistenter reduserer manuell kodetid med 30 til 50%. På papiret er saken avgjort.

Aluras erfaring er at AI-assistert utvikling gir reell fart, men at gevinsten forsvinner uten verifisering og styring av det som genereres. Fartsgevinsten er lett å måle på demoen. Kostnaden dukker opp senere, i gjennomgang, feilretting og sikkerhetsarbeid, og den vises ikke i produktivitetstallene fra første uke.

Hva tallene lover

Bruken er bred på tvers av organisasjonen. 88% av organisasjoner bruker AI i minst en forretningsfunksjon, og bedrifter som tar i bruk automasjon rapporterer opptil 40% produktivitetsøkning. IBM beskriver hvordan AI brukes som en «rubber duck» som hjelper utviklere å resonnere seg frem til løsninger, hvordan den automatisk kan generere enhetstester og skrive dokumentasjon som kommentarer i koden.

For åpen kildekode spesielt er inntoget merkbart. En stor andel av vedlikeholderne av åpen kildekode bruker AI-baserte kodeverktøy, med høyere bruk blant de under 26 år. Bruken konsentrerer seg om de som bygger AI-funksjonalitet: 79% av utviklerne som legger til AI-funksjonalitet, bruker åpne modeller.

Tillitsgapet

Utviklerne som bruker verktøyene mest, stoler minst på dem. Kun 29% av utviklere stoler på AI-verktøy, et tall som ligger i samme leie som de 43% som stoler på resultatene fra AI-verktøy og de 31% som forblir skeptiske. Dette er ikke teknologimotstand, det er praktikere som har sett hva som kommer ut når man ikke sjekker.

Skepsisen har grunnlag i hvordan modellene feiler. IBM peker på at AI mangler kontekst for åpen kildekode-prosjekter og kan generere pull requests som ser korrekte ut, men bryter kodebasen. Vedlikeholderne merker det på volumet: lavkvalitets «AI slop» og hallusinerte sikkerhetsrapporter overbelaster dem.

Når fart blir friksjon

Det tydeligste motbeviset mot rene produktivitetstall kommer fra et kontrollert forsøk. I en randomisert studie ble erfarne utviklere 19% tregere med AI-verktøy. Gevinsten er altså ikke gitt, den avhenger av oppgave, erfaring og hvor mye tid som går med til å rette opp det modellen leverer.

Gapet mellom eksperiment og drift bekrefter dette. Kun 16% av bedrifter har skalert AI på tvers av hele organisasjonen. Verktøyet kommer inn på et øyeblikk, men å gjøre gevinsten varig og trygg er en helt annen jobb enn å ta den i bruk.

Sikkerhetsregnestykket bak AI-generert kode

Her ligger den harde nyheten. Black Ducks 2026 OSSRA-rapport viser at AI-assistert utvikling har gitt større, mer komplekse og mer sårbare kodebaser. Gjennomsnittlig antall åpen kildekode-sårbarheter per kodebase er nå 581, mer enn doblet fra året før. Samtidig har gjennomsnittlig kodebase passert 84 000 filer, mer enn firedoblet på fem år. Når koden vokser raskere enn gjennomgangskapasiteten, vokser også risikoen som ikke blir sett.

Metrikk	Verdi	Utvikling
Sårbarheter per kodebase	581	Mer enn doblet fra året før
Filer per kodebase	84 000	Mer enn firedoblet på fem år
Sårbarheter i AI-generert kode	Markant flere	Sammenlignet med menneskeskrevet kode
Kodebaser med lisenskonflikter	To tredjedeler	Av gjennomgåtte kodebaser
Kodebaser med utdaterte eller forlatte komponenter	De aller fleste	Betydelig utdatert eller år bak
Forsyningskjedeangrep siste 12 måneder	65%	Av organisasjonene

581 sårbarheter og hva som driver tallet

Tallet 581 er ikke tilfeldig. Det følger direkte av at kodebasene blir større og settes sammen raskere. Når filantallet eller antall filer per kodebase er mer enn firedoblet på fem år, øker angrepsflaten tilsvarende. AI-verktøy gjør det trivielt å dra inn avhengigheter og generere store mengder kode, men de gjør ingenting for å redusere volumet som må sikres etterpå.

Litteraturen er delt om nettoeffekten. Den akademiske gjennomgangen konkluderer med at AI forsterker både kvaliteten og sikkerheten i prosjekter samtidig som den reiser viktige etiske spørsmål, og at verktøyene både kan utfordre og forbedre prosesser som kodegjennomgang. Utfallet avgjøres ikke av modellen, men av hva teamet gjør med det den produserer.

Kode som ser riktig ut

Det farligste med AI-kode er ikke at den er åpenbart feil, men at den ser riktig ut. AI-generert kode inneholder markant flere sårbarheter enn koden den erstatter. Kombinert med at pull requests kan se korrekte ut men bryte kodebasen, betyr det at feilene glir lettere gjennom en overflatisk gjennomgang.

Dette er kjernen i hvorfor verifisering ikke kan være valgfritt. IBM understreker at selv om AI automatisk kan generere enhetstester, må utviklere fortsatt verifisere arbeidet. En modell som skriver både koden og testene, kan reprodusere sin egen feilantakelse i begge.

Forsyningskjeden og lisensene

Sårbarhetene er bare en av tre fronter OSSRA peker på. To tredjedeler av gjennomgåtte kodebaser inneholder lisenskonflikter, og de aller fleste kodebaser inneholder komponenter som er betydelig utdaterte, forlatt av vedlikeholdere, eller år bak gjeldende versjon. Utdaterte komponenter er der de kjente sårbarhetene bor.

Forsyningskjeden er blitt et eget angrepsområde. 65% av organisasjonene rapporterte å ha opplevd et programvareforsyningskjedeangrep de siste 12 månedene. Når AI gjør det lettere å trekke inn flere avhengigheter raskere, er dette tallet en direkte konsekvens av arbeidsflyten, ikke en bakgrunnsrisiko. Lisenssiden av dette er tett knyttet til opphavsrett, som vi utdyper i vår gjennomgang av juridiske utfordringer med AI-generert innhold i Norge.

Rammeverk for å styre AI i utviklingsløpet

Styring er unntaket, ikke regelen. Kun rundt 21% av selskaper har moden styring av agenter, mens 88% allerede bruker AI i minst en forretningsfunksjon. Det betyr at de fleste team har tatt i bruk teknologien uten å ha kontrollene på plass.

Aluras posisjon er tydelig: governance rundt AI-kode bør på plass før skalering, ikke etterpå. Å bygge styring i etterkant betyr å rydde opp i 581 sårbarheter per kodebase i stedet for å hindre at de kommer inn. Rammeverket under skiller mellom faser i utviklingsløpet, slik at kontrollen henger på riktig sted.

Fra fritt eksperiment til styrt løp

Poenget med et rammeverk er å gjøre verifisering til en del av flyten, ikke en ekstra oppgave noen glemmer. AI kan både utfordre og forbedre kodegjennomgang og repository-håndtering, og forskjellen ligger i om teamet har definert hvor mennesket kommer inn. Uten definerte porter blir gjennomgangen tilfeldig, og tilfeldig gjennomgang er nettopp det som slipper de ekstra sårbarhetene i AI-generert kode forbi.

Fase	Hva som skjer	Kontroll som må stå
Generering	AI foreslår kode og avhengigheter	Krav om at forslag merkes og spores
Gjennomgang	Kode leses av menneske	Obligatorisk review, ikke selvgodkjenning
Verifisering	Tester og skanning kjøres	Sårbarhets- og lisensskanning før merge
Avhengigheter	Komponenter trekkes inn	Kontroll av alder, vedlikehold og lisens
Drift	Kode kjører i produksjon	Overvåking og oppdatering av komponenter

Verifiseringsporten

Verifiseringsporten er der de fleste gevinstene enten realiseres eller går tapt. Prinsippet er enkelt: ingen AI-generert kode når hovedgrenen uten at et menneske har lest den og en maskin har skannet den. Siden utviklere fortsatt må verifisere arbeidet selv når AI genererer testene, kan ikke teststatus alene være grønt lys.

For norske team betyr det å bygge dette inn i verktøykjeden fremfor å be folk huske det. Vår guide til GitHub Copilot for utviklere går nærmere inn på hvordan slike assistenter kan settes opp med gjennomgang som en fast del av arbeidsflyten, ikke et etterpåklokt tillegg.

Governance-modenhet i praksis

Modenhet handler om avstanden mellom bruk og kontroll. Med rundt 21% som har moden styring og bare 16% som har skalert AI på tvers av hele organisasjonen, er de fleste selskaper i en fase der de enten styrer for lite eller skalerer for tidlig. Det trygge er å la styringen lede skaleringen, ikke motsatt.

Praktisk starter dette med at ledelsen definerer hva som må være sant før bruk utvides: hvilke porter som gjelder, hvem som eier gjennomgangen, og hvordan avvik måles. Det er billigere å sette disse rammene mens teamet er lite, enn å innføre dem etter at AI-kode allerede er spredt gjennom hele kodebasen.

Praktisk: dette gjør du på mandag morgen

Rammeverk er lite verdt uten konkrete første steg. Under er fire grep et team kan iverksette umiddelbart, uten stort budsjett eller ny plattform. Målet er å lukke gapet mellom hvor fort AI produserer kode og hvor fort dere klarer å verifisere den.

Sett en verifiseringsstandard for AI-kode

Bestem at all AI-generert kode behandles som ekstern kode: den skal leses, testes og forklares før den slås sammen. Fordi AI-generert kode har flere sårbarheter og kan se korrekt ut men bryte kodebasen, må gjennomgangen se etter det som ikke synes ved første øyekast. Skriv ned standarden, ikke la den være underforstått.

Bruk AI også på forsvarssiden. AI-drevne sårbarhetsskannere kan redusere sikkerhetsrisikoer med 30 til 60%, men det forutsetter at skanningen faktisk kjøres på det AI produserer, ikke bare på det menneskene skriver.

Skann avhengigheter og lisenser

Sett opp automatisk skanning av komponenter for sårbarheter, alder og lisens. Med de aller fleste kodebaser som inneholder utdaterte eller forlatte komponenter og to tredjedeler med lisenskonflikter, er dette lavthengende frukt. En skanning som kjører på hver merge, fanger opp problemene mens de er små.

Behandle forsyningskjeden som en angrepsvektor. Når 65% av organisasjonene har opplevd et forsyningskjedeangrep siste 12 måneder, er en oppdatert oversikt over hva som faktisk kjører i produksjon, en sikkerhetskontroll og ikke bare god ryddighet.

Håndter skygge-AI åpent

Ikke lat som verktøyene ikke brukes. OSSRA viser at 76% av organisasjoner som forbyr AI-assistert utvikling, rapporterer at det likevel blir brukt mot policy. Et forbud flytter bare bruken ut av syne, der ingen gjennomgang eller skanning når den. Bedre å tillate bruk innenfor tydelige rammer, og gjøre den trygge veien til den enkleste.

Konkret betyr det å gi teamet godkjente verktøy, en klar standard for gjennomgang, og et sted å spørre når noe er uklart. Da flytter du bruken fra skyggen og inn i noe du kan styre.

Markedet for åpne modeller og hvem som tar dem i produksjon

Åpne modeller har tatt igjen de lukkede på kapabilitet, men ikke på faktisk bruk i drift. Kapabilitetsgapet mot lukkede modeller på Chatbot Arena var 3,3% per mars 2026, og åpne modeller når omtrent 90% av ytelsen til lukkede ved lansering. Likevel henger de fortsatt etter på resonnering og agentiske oppgaver, som er nettopp der utviklingsarbeid stiller høyest krav.

Dimensjon	Åpne modeller	Lukkede modeller
Kapabilitetsgap på Chatbot Arena (mars 2026)	3,3% bak	Referanse
Ytelse ved lansering	Omtrent 90%	Referanse
Andel av faktisk modellbruk	Resten av bruken	Omtrent 80%
Team som når produksjon	51%	63%

Paritet på papiret

Paritetshistorien er ekte, men snever. Gapet på 3,3% på Chatbot Arena gjelder brede oppgaver. På resonnering og agentiske oppgaver ligger åpne modeller fortsatt bak, og det er der en kodeassistent lever eller dør. En modell som er nesten like god på samtale, kan være merkbart svakere når den skal planlegge og gjennomføre en flertrinns endring i en stor kodebase.

Konkurransen har dessuten flyttet seg fra modellen alene. Orkestreringslaget, den agentiske harnessen, er det nye konkurranseområdet, og lukkede labber integrerer harness med modell for å skape lock-in. Det betyr at valget mellom åpent og lukket ikke lenger bare handler om vekter, men om hele verktøykjeden rundt.

Produksjonsgapet

Det viktigste tallet for en leder er ikke benchmark, men driftsrate. Kun 51% av team som bruker åpne modeller når produksjon, mot 63% for lukkede modeller. Og selv om åpne modeller er teknisk sterke, går omtrent 80% av faktisk modellbruk fortsatt til lukkede modeller. Avstanden mellom kapabilitet og bruk er driftsgapet i tall.

Det samme mønsteret vises i faktiske deploymenter. Botpress, det mest utbredte åpen kildekode-rammeverket i produksjon, er påvist på 1 558 domener, mens OpenAI API er påvist på 52 682 domener. Åpne prosjekter er mange, men lukkede API-er dominerer der koden faktisk kjører.

Hvem leder an

Kommersielt er de åpne aktørene tunge. DeepSeek nådde rundt 220 millioner dollar i årlig gjentakende inntekt og hentet inn et milliardbeløp til en verdivurdering over 50 milliarder dollar. Databricks har en årlig inntektsrate i milliardklassen, og Mistral AI har rundt 400 millioner dollar i årlige gjentakende inntekter. Dette er ikke lenger et hobbymiljø.

Tyngdepunktet forskyver seg geografisk. Kinesiske open-weight-modeller utgjorde over 45% av ukentlig trafikk på OpenRouter innen april 2026, og på Hugging Face utgjorde kinesiske modeller 41% av nedlastingene det siste året, der Kina har passert USA i både månedlige og totale nedlastinger. Aluras posisjon her er edruelig: åpne modeller kutter lisenskostnad og lock-in, men driftsgapet fra prototype til produksjon er den egentlige jobben.

Kostnad: fra lisensavgift til driftsgap

Kostnadsargumentet for åpen kildekode er sterkt og reelt. Kombinasjonen av AI og åpen kildekode kan redusere kostnader med opptil 40% sammenlignet med proprietære løsninger, blant annet fordi åpen kildekode fjerner lisensavgifter. Men lisens er den delen av regnestykket som er lett å se. Drift er den delen som avgjør om prosjektet lønner seg.

Kostnadspost	Proprietær SaaS	AI og åpen kildekode
Lisenskostnad	Over 50 000 dollar per år	0 dollar
Samlet kostnadsreduksjon	Referanse	Opptil 40%
Manuell kodetid	Referanse	Redusert 30 til 50%
Inferens per 1M tokens (GPT-4-klasse)	Referanse	0,40 dollar
Tid til målbar ROI	Varierer	6 til 12 måneder

Lisenskostnaden som forsvinner

Den direkte besparelsen er konkret. Lisenskostnaden for AI og åpen kildekode er 0 dollar, sammenlignet med over 50 000 dollar per år for proprietær SaaS, og mange bedrifter rapporterer målbar ROI innen 6 til 12 måneder på grunn av reduserte avgifter og raskere gjennomføring. Kombinert med at åpen kildekode gir frihet fra leverandørlåsing, er argumentet solid på inntektssiden av regnestykket.

Merk at disse tallene kommer fra leverandører med interesse i å fremme åpen kildekode, og bør leses som overkant snarere enn garanti. Besparelsen er reell, men den forutsetter at teamet faktisk klarer å drifte løsningen selv.

Inferens blir billig

Prisfallet på modellkjøring er dramatisk. Kostnaden for GPT-4-klasse inferens falt 50 ganger på 36 måneder, fra 20 dollar til 0,40 dollar per 1M tokens. Det senker terskelen for å bygge AI-funksjonalitet betydelig, og forklarer hvorfor så mange team nå kan eksperimentere uten stort budsjett.

Treningen forblir dyr og konsentrert. Llama 3.1 krevde 16 000 Nvidia H100-GPU-er og kostet 640 millioner dollar å trene. Åpne vekter betyr at de fleste slipper å bære den kostnaden, men det betyr også at du er avhengig av at noen andre fortsetter å trene modellene du bygger på.

Driftsgapet er den egentlige regningen

Den skjulte kostnaden er avstanden fra prototype til produksjon. At bare 51% av team med åpne modeller når produksjon, betyr at en stor del av innsatsen stanser før den gir verdi. Den tapte tiden vises ikke på lisensfakturaen, men den er den dyreste posten i regnestykket.

Regn derfor drift inn fra start: hosting, overvåking, oppdatering av komponenter, og sikkerhetsarbeidet som følger av 581 sårbarheter per kodebase. En løsning som er gratis i lisens, men krever et team for å holdes trygg i produksjon, er ikke gratis. Den er bare priset annerledes.

EU AI Act og det åpen kildekode-unntaket ikke dekker

Reguleringen er ikke lenger fremtidig. EU AI Act er verdens første omfattende rammeverk for regulering av kunstig intelligens, og den trådte i kraft 1. august 2024. Loven har ekstraterritoriell rekkevidde, så norske selskaper som retter seg mot EU-markedet, er omfattet selv om Norge ikke er EU-medlem.

Dato	Hva trer i kraft
1. august 2024	Loven trådte i kraft
2. februar 2025	Forbud mot AI-systemer med uakseptabel risiko
2. mai 2025	Endelig Code of Practice publiseres
2. august 2025	Forpliktelser for leverandører av GPAI-modeller
2. august 2026	Forpliktelser for høyrisikosystemer
2. august 2027	Slutt på fasen implementering

Fire risikonivå og hvor koden din havner

Loven sorterer systemer etter risiko. AI Act grupperer AI-systemer i fire risikokategorier: uakseptabel, høy, begrenset og minimal risiko. Det avgjørende er at loven ikke gjør unntak for åpen kildekode når det gjelder forbud mot uakseptabel risiko og restriksjoner på høyrisikosystemer. Bruker du en åpen modell i et høyrisiko-bruksområde, gjelder kravene uansett lisens.

For de fleste utviklingsteam vil verktøyene selv falle i de lavere kategoriene, men bruksområdet kan løfte dem opp. En kodeassistent er noe for seg, en modell som tar beslutninger om mennesker i ansettelse eller kreditt er noe helt annet.

Unntaket som ikke er en blankofullmakt

Åpen kildekode-unntaket er smalere enn mange tror. Unntakene for åpen kildekode er ingen blankofullmakt, og leverandører av åpne GPAI-modeller med systemisk risiko er ikke fritatt fra noen forpliktelser. For å kvalifisere til unntak må modellen være helt gratis og ikke direkte kommersialisert, og unntaket gjelder bare hvis tredjeparter ikke tjener penger på produktene sine.

Terskelen for systemisk risiko er teknisk definert. Grensen inkluderer modeller som bruker mer enn 10^25 FLOPs under trening, en vilkårlig terskel. Det betyr at de mest kapable åpne modellene, nettopp de teamene helst vil bruke, er de som lettest faller utenfor unntaket. Definisjonen av åpen kildekode i loven er dessuten uklar, noe som i seg selv skaper etterlevelsesrisiko.

Treningsdata, openwashing og bøtenivået

Noen krav gjelder alle. Alle GPAI-modeller må offentliggjøre informasjon om treningsdata og respektere EUs opphavsrett. For åpne modeller under fri lisens reduserer loven kravene til kun opphavsrett og en oppsummering av treningsdata. Faren er openwashing, der en modell merkes som åpen uten å tilby reell åpenhet eller gjenbruk. Til hjelp identifiserer Model Openness Framework 17 nøkkelkomponenter i modellutviklingens livssyklus.

Bøtenivået gjør etterlevelse til et styresaksanliggende. Maksimal bot for alvorlige brudd er opptil 7% av global omsetning, og manglende overholdelse av forbud kan gi bøter opptil 35 millioner euro. Loven unntar riktignok systemer utviklet utelukkende for vitenskapelig forskning, men det hjelper lite for et kommersielt produkt. Det opphavsrettslige laget er behandlet nærmere i vår artikkel om AI og opphavsrett i Norge.

Markedsobservasjon: små team leder an i praksis

Et tydelig mønster i tallene: åpen kildekode i produksjon drives i stor grad av små, tekniske team. Blant selskaper som kjører Botpress i produksjon, har 64% ti eller færre ansatte, 81% færre enn 50 ansatte, og bare 5% er bedrifter med over 1000 ansatte. Det er de små som tar teknologien i drift først.

Hvem som faktisk kjører åpen kildekode i produksjon

Størrelsesfordelingen er ikke tilfeldig. Åpen kildekode AI senker terskelen for små team, som har mindre å tape på å bytte verktøy og mer å vinne på å slippe lisensavgifter. 899 selskaper ble matchet til en aktiv Botpress-deployment, med en match rate på 57,7%, noe som gir et konkret bilde av hvem som faktisk står bak driften.

For større selskaper er dette både en mulighet og en advarsel. Mulighet fordi de kan lære av de små som allerede har løst driften. Advarsel fordi lav adopsjon i store organisasjoner nettopp reflekterer at governance og drift blir tyngre jo større du er.

Geografien og bransjene

Bruken er geografisk spredt. Av Botpress-deploymenter ligger 23% i USA, 6,9% i Spania, 6% i India, 4,5% i Storbritannia og 3% i Tyskland. Fordelingen viser at åpen kildekode ikke er et fenomen bundet til ett marked.

På bransjesiden leder tjenesteytende sektorer. 8,4% av deploymentene er i IT-tjenester og konsulentbransjen, 6,9% i teknologi og internett, og 4,4% i programvareutvikling. Det er teknologinære miljøer som har kompetansen til å drifte åpen kildekode selv.

Verktøyene utviklerne samler seg om

Noen få prosjekter samler enorm oppmerksomhet. Ollama har over 174 000 GitHub-stjerner, Open WebUI 142 000, vLLM 83 300 og CrewAI 53 900. På infrastruktursiden holder de etablerte rammeverkene stand, med over 180 000 stjerner for TensorFlow og over 80 000 for PyTorch.

Bak toppene er halen lang og kald. En stor andel av modellene på Hugging Face har mindre enn 200 nedlastinger totalt, mens de 200 mest nedlastede utgjør 49,6% av alle nedlastinger. Og oppmerksomheten er kortvarig: gjennomsnittlig engasjementstid for åpne modeller er seks uker. For et team betyr det å velge verktøy med aktivt vedlikehold, ikke bare høy stjernetelling.

Vanlige feil norske team gjør med AI-kode

De fleste feilene er ikke tekniske, de er organisatoriske. Under er de tre som gjentar seg oftest, og som hver for seg kan gjøre en fartsgevinst om til en sikkerhetsgjeld.

Å skalere før verifisering er på plass

Den dyreste feilen er å utvide bruken før kontrollene står. Med 88% som allerede bruker AI i minst en funksjon, men bare rundt 21% med moden styring, er dette regelen snarere enn unntaket. Resultatet er 581 sårbarheter per kodebase som ingen rakk å planlegge for.

Aluras posisjon er at governance rundt AI-kode bør på plass før skalering, ikke etterpå. Å innføre porter og gjennomgang mens teamet er lite koster lite. Å rydde opp etterpå koster mye mer, og noe av gjelden lar seg aldri fullt ut betale ned.

Å stole blindt på generert kode

Den andre feilen er å behandle AI-output som ferdig arbeid. Selv om bare 29% av utviklere stoler på AI-verktøy, presser leveransetempo ofte gjennomgangen ned til et gummistempel. Da forsvinner nettopp forsvaret mot at pull requests ser korrekte ut men bryter kodebasen.

Motgiften er å gjøre skepsis til rutine, ikke holdning. Utviklere må verifisere arbeidet selv når AI genererer testene, og den regelen må stå i verktøykjeden, ikke bare i hodene til de mest erfarne.

Å forby i stedet for å styre

Den tredje feilen er å tro at et forbud løser problemet. 76% av organisasjoner som forbyr AI-assistert utvikling, rapporterer at det likevel brukes mot policy. Forbudet flytter bare bruken til skyggen, der verken gjennomgang eller skanning når den, og gjør risikoen usynlig i stedet for å fjerne den.

Alternativet er å styre åpent: godkjente verktøy, tydelige porter, og et miljø der utviklere spør fremfor å skjule. Da beholder du fartsgevinsten uten å gi slipp på kontrollen.

Ofte stilte spørsmål om AI-assistert utvikling

Her er de spørsmålene ledere, CTO-er og produktansvarlige oftest stiller når de vurderer å skalere AI-assistert utvikling, med svar forankret i tallene.

Er AI-generert kode mindre sikker enn menneskeskrevet kode?

Ja, i utgangspunktet. AI-generert kode inneholder markant flere sårbarheter, og OSSRA knytter veksten til 581 sårbarheter per kodebase, mer enn doblet fra året før. Men risikoen er håndterbar: samme AI-drevne sårbarhetsskannere kan redusere sikkerhetsrisikoer med 30 til 60% når de faktisk kjøres på det som genereres.

Bør vi forby AI-verktøy i utviklingsteamet?

Nei, forbud virker ikke. 76% av organisasjoner som forbyr AI-assistert utvikling, opplever at det brukes mot policy uansett. Et forbud fjerner innsynet, ikke bruken. Styr heller bruken gjennom godkjente verktøy og obligatorisk gjennomgang, slik at koden som produseres, faktisk blir sett.

Oppsummering og neste steg

Regnestykket er tydelig. AI-assistert utvikling gir fart som er godt dokumentert, med 85% av utviklere som bruker verktøyene og 30 til 50% redusert manuell kodetid. Men gevinsten kommer med en regning: 581 sårbarheter per kodebase, markant flere sårbarheter i AI-generert kode, og de aller fleste kodebaser med utdaterte komponenter. Aluras posisjon oppsummerer det: farten er reell, men den forsvinner uten verifisering og styring av det som genereres.

Neste steg er ikke å velge mellom fart og trygghet, men å sette rammene som gjør begge mulig samtidig. Start med en verifiseringsstandard for AI-kode, sett opp skanning av avhengigheter og lisenser, håndter skygge-AI åpent i stedet for å forby den, og la governance lede skaleringen. Åpne modeller kutter lisenskostnad med opptil 40%, men driftsgapet fra prototype til produksjon er den egentlige jobben, og bare 51% av teamene kommer helt frem. De som setter styringen først, havner i den halvdelen. De som skalerer først og styrer etterpå, betaler differansen i sårbarheter, lisenskonflikter og regulatorisk risiko.

I Alura bygger vi AI-infrastruktur for norske virksomheter, fra dataplattformer til agentiske systemer i produksjon. Vi er ikke en SaaS-leverandør. Vi er håndverkere som setter sammen byggesteinene som faktisk fungerer for din situasjon.

Bestill en arkitektur-samtale: vi går gjennom din nåværende infrastruktur, identifiserer integrasjonspunkter, og foreslår en pragmatisk vei videre. Uforpliktende, 45 minutter.