Teknisk fordypning30. august 2026

Lokal AI som testpartner: Finn feil i egen kode uten å gi modellen nøklene

Nyere lokale modeller kan lese kode, forklare logger og foreslå tester. Det gir verdi når de brukes som testpartner i egne, autoriserte miljøer — ikke som en usynlig administrator i produksjon.

Utvikler i et nordisk arbeidsmiljø bruker en lokal datamaskin og skjerm med teststatus og teknisk oversikt.

AI kan nå bidra langt mer i teknisk arbeid enn å skrive et par linjer med kode. En god lokal modell kan lese et avgrenset prosjekt, forklare en feilmelding, finne mulige selvmotsigelser i konfigurasjon, foreslå enhetstester og gjøre dokumentasjon mer komplett. For mange utviklings- og IT-team er det en interessant mulighet: mer kapasitet til å finne feil før de blir dyre.

Men den riktige rollen er testpartner, ikke en agent som får nøklene til produksjon. Det er forskjellen på å la AI peke på noe en fagperson bør undersøke, og å la den endre et system den ikke forstår konsekvensene av.

Bruk lokal AI til å gjøre den første, grundige gjennomgangen raskere. Behold eierskap, godkjenning og endringer hos menneskene som kjenner systemet.

Hva en lokal AI-testpartner faktisk kan gjøre

I et system dere selv eier eller har uttrykkelig tillatelse til å teste, kan en lokal modell være nyttig på fire måter:

Oppgave	Hva AI-en kan bidra med	Hva et menneske fortsatt må gjøre
Kodegjennomgang	Peke på utydelig logikk, duplisert kode, manglende feilhåndtering eller deler som trenger nærmere review.	Vurdere arkitektur, sikkerhetskonsekvenser og om forslaget passer i produktet.
Tester	Foreslå enhetstester, kanttilfeller og testdata basert på tydelig avgrenset kode.	Kjøre testene, vurdere dekning og godkjenne endringer.
Feilsøking	Forklare logger og stack traces, sortere hypoteser og foreslå hva som bør undersøkes først.	Bekrefte årsak, prioritere tiltak og gjøre reparasjonen.
Egne sikkerhetsgjennomganger	Finne mulige svake mønstre, uavklarte rettigheter, gamle avhengigheter eller konfigurasjoner som bør undersøkes.	Bekrefte funnet med ordinære sikkerhetsverktøy og vurdere risiko og tiltak.
Historiske dokumenter	Søke gjennom godkjente arkiv, sammenholde versjoner og samle relevante spor fra gamle rutiner, e-poster eller prosjektdokumenter.	Kontrollere kildene, skille fakta fra tolkning og avgjøre hva som kan brukes videre.
Infrastruktur	Lese godkjente konfigurasjonsutdrag og beskrive inkonsekvenser, manglende dokumentasjon eller spørsmål som bør avklares.	Validere forslagene med ordinære sikkerhets- og driftsverktøy før noe endres.

Dette er ikke en erstatning for SAST, avhengighetsskanning, tester, overvåking eller menneskelig review. Det er et ekstra lag som kan få teamet raskere frem til de riktige spørsmålene.

Når AI-en kan lete videre i stedet for å stoppe ved første hinder

Den interessante forskjellen med et godt oppsett er ikke bare at modellen kan «lese en fil». Den kan få en avgrenset undersøkelsesoppgave: gå gjennom flere mapper, sammenligne gamle versjoner, samle spor på tvers av dokumenter og markere hva som fortsatt er uavklart. Hvis én kilde mangler eller en logg peker i flere retninger, kan den be om en alternativ, godkjent kilde eller lage en liste over hva som må undersøkes videre.

For eksempel kan den samle alle historiske omtaler av en bestemt teknisk beslutning fra et godkjent prosjektarkiv; forklare hvilke dokumenter som motsier hverandre; eller lage en prioritert liste over konfigurasjoner i en egen testkopi som fortjener sikkerhetsgjennomgang. Da blir den ikke en sannhetsmaskin. Den blir en utholdende forskningsassistent som dokumenterer spor, hull og antakelser.

Det krever imidlertid tydelige stoppekriterier. Den skal ikke prøve stadig nye tilganger, hente fra systemer den ikke er autorisert for eller kjøre ubegrensede løkker i bakgrunnen. Den skal avslutte når kildene i oppdraget er gjennomgått, når den mangler godkjent tilgang eller når den har nådd budsjettet og tidsrammen dere har satt. NIST fremhever identitet og autorisering som sentrale temaer for sikre agenter, mens OWASP anbefaler minst mulige rettigheter, logging, menneskelig kontroll og vern mot innhold som forsøker å styre agenten. [6] [7]

To gode oppdrag å starte med

Oppdrag	Hva AI-en kan gjøre i et lukket miljø	Hva dere må definere på forhånd
Finn mulige sikkerhetshull i eget system	Lese en avgrenset kopi av kildekode, godkjente konfigurasjonsutdrag, avhengighetslister og testlogger; peke på ting som trenger verifisering.	Eierskap eller eksplisitt tillatelse, hvilke filer den kan se, ingen hemmeligheter i konteksten, leseadgang og hvilke testverktøy som avgjør om et funn er reelt.
Finn historisk dokumentasjon	Søke i et godkjent, indeksert arkiv og samle dokumenter, versjoner og sitater rundt et spørsmål som «hvorfor ble denne prosessen endret?»	Dataklassifisering, autoriserte arkiv, tidsavgrensning, hvem som kvalitetssikrer svaret og hvordan usikre eller motstridende kilder skal merkes.

Start med et autorisert testmiljø

Ikke begynn med en kopi av hele produksjonen. Begynn med én avgrenset oppgave i et isolert miljø. Bruk anonymiserte eller syntetiske testdata når det er mulig, fjern hemmeligheter og API-nøkler fra filer, og gi modellen leseadgang først.

En enkel arbeidsflyt kan se slik ut:

Velg én godkjent undersøkelse. For eksempel «finn manglende testtilfeller i denne modulen», «pek på mulige sikkerhetssvakheter som trenger verifisering» eller «samle historiske dokumenter som forklarer hvorfor denne prosessen ble endret».
Avgrens konteksten. Gi bare de filene, konfigurasjonene, arkivene og loggutdragene som er nødvendige for oppgaven.
Be om sporbar leting, ikke endring. Be modellen oppgi hvilke kilder den har gjennomgått, hva som mangler, hvilke hypoteser den har og når den stopper. Den kan gå videre til neste godkjente kilde, men ikke utvide sin egen tilgang.
Verifiser med vanlige kontroller. Kjør tester, linting, sårbarhetsskanning og faglig review uavhengig av hva modellen sier. Et AI-funn er en hypotese til det er bekreftet.
Gjør endringer gjennom ordinær prosess. Pull request, godkjenning, logging og rollback-plan gjelder fortsatt.

OWASP anbefaler at virksomheter dokumenterer hvilke AI-verktøy som er godkjent, hvilke data som kan brukes som input, og hvilke sikkerhetsporter som fortsatt er obligatoriske gjennom utvikling, test, deploy og overvåking. [1] NISTs Secure Software Development Framework er et nyttig rammeverk for å plassere AI i en eksisterende sikker utviklingsprosess, heller enn ved siden av den. [2]

Bruk 4D for å planlegge hva modellen skal gjøre

Før dere gir en lokal modell tilgang til kode eller infrastruktur, bør dere skrive ned oppgaven. 4D-rammeverket gir et praktisk språk for dette:

4D	Slik brukes det for lokal AI-testing
Delegering	Velg en støtteoppgave som kan avgrenses, for eksempel å foreslå tester eller forklare feil. Ikke deleger tilgangsstyring, deploy eller godkjenning.
Beskrivelse	Definer hvilke mapper, logger og testdata modellen kan se, hvilke verktøy den får bruke og hva et nyttig svar skal inneholde.
Dømmekraft	Sammenlign modellens forslag med testresultater og en erfaren utviklers vurdering. Mål om den finner relevante feil, ikke om svaret høres overbevisende ut.
Aktsomhet	Loggfør bruken, begrens tilganger, ha stoppekriterier og én tydelig eier av arbeidsflyten.

Dette er også grunnen til at et godt harness betyr mye. En modell alene er bare språk og mønstergjenkjenning. Med riktig kontekst, lesetilgang til et fåtall relevante filer, faste testkommandoer og en kontrollsløyfe blir den langt mer nyttig. Les mer i artikkelen om AI-orkestrering.

Moderne lokale modeller er kraftige — men miljøet er fortsatt en del av løsningen

Nyere åpne modeller og kvantiserte varianter gjør det lettere å kjøre avansert analyse lokalt enn for bare kort tid siden. Det gjelder særlig kodeforståelse, testforslag, logganalyse og dokumentasjonsarbeid. Men kapasiteten avhenger av langt mer enn modellnavn: tilgjengelig minne, modellformat, inferensmotor, kontekststørrelse og oppgavens utforming avgjør hva som fungerer i praksis.

Videoen om FreeToken viser nettopp at måten en MoE-modell kjøres på kan påvirke praktisk ytelse på en kodeoppgave. [3] Samtidig må ny modellstøtte testes. vLLM har en åpen endring for GLM-5.3-Flash og skriver at bare første commit er fullt verifisert. [4] Se derfor på nye modeller og runtime-verktøy som noe dere evaluerer kontrollert, ikke som et løfte om stabil drift i alle miljøer.

Offline AI-artikkelen forklarer når lokal behandling, sky eller hybrid ofte passer best. For en innføring i nyere Qwen-modeller kan dere også lese Qwen-artikkelen.

Hva med «uncensored» eller «abliterated» modeller?

Du vil møte modellvarianter som markedsføres som «uncensored» eller «abliterated». Den delte Qwen3.8 Flash Next-kolleksjonen er ett eksempel på at slike varianter finnes i flere formater. [5] Betegnelsene betyr i praksis at leverandørens sikkerhetsatferd er endret eller redusert. Det gjør dem ikke mer pålitelige, sikre eller egnede for arbeidsoppgaver med kunder, personopplysninger eller produksjonssystemer.

For et team som arbeider defensivt med egne, autoriserte testmiljøer kan det være relevant å forstå modellandskapet. Men bruk aldri en slik variant som en snarvei rundt egen styring. Den skal ikke få hemmeligheter, reelle persondata, administrative rettigheter eller autonom tilgang til nettverk. Vanlige sikkerhetsverktøy, tilgangskontroll og menneskelig godkjenning er fortsatt fundamentet.

Et godt første forsøk denne uken

Velg én lukket kodebase eller testmodul som ikke inneholder kundedata eller nøkler. Be en lokal modell om å foreslå fem manglende testtilfeller, forklare hvilke antakelser den har gjort og peke på filer den er usikker på. La deretter en utvikler kjøre de ordinære testene og vurdere forslagene.

Målet er ikke å «bevise at AI kan kode». Målet er å finne ut om dere oppdager relevante feil raskere, uten å svekke kontrollen over kode, data eller drift. Hvis svaret er ja, kan dere gradvis utvide til flere avgrensede oppgaver.