AI og produktutviklingHafsteinn Runarsson · AI Konsulent18 Sept 2026 · 10 min

Hvordan lage en AI-løsning: steg for steg

Å lage en AI-løsning handler sjelden om å trene en helt ny modell. For de fleste prosjekter er den beste veien å definere én tydelig oppgave, koble en eksisterende modell til riktige data og verktøy, teste resultatet systematisk og først deretter bygge for produksjon.

Denne guiden viser hele løpet — fra idé og valg av tilnærming til testing, lansering og løpende forbedring.

Kort svar: Slik lager du en AI-løsning

Start med problemet, ikke modellen. En praktisk prosess består av åtte steg:

1. Velg én konkret oppgave AI-en skal løse.
2. Beskriv brukerne, arbeidsflyten og hva et godt svar er.
3. Velg mellom en ferdig modell, en tilpasset modell eller en modell trent fra bunnen.
4. Klargjør dataene og bestem hvilke kilder løsningen får bruke.
5. Bygg en avgrenset prototype.
6. Test kvalitet, sikkerhet, kostnad og responstid med realistiske eksempler.
7. Koble løsningen til systemene den trenger, med tydelige tilgangsgrenser.
8. Lanser kontrollert og følg med på feil, tilbakemeldinger og endringer i datagrunnlaget.

Denne rekkefølgen reduserer risikoen for at teamet bygger avansert teknologi før det vet om løsningen faktisk hjelper brukeren.

Bestem hva slags AI du faktisk skal lage

Det første valget er ikke hvilken modell du skal bruke, men hvilken type løsning oppgaven krever. «En AI» kan bety flere forskjellige ting:

• En AI-funksjon i et produkt: for eksempel oppsummering, klassifisering, søk eller forslag til neste handling.
• En copilot: hjelper en bruker med å utføre en oppgave, men lar brukeren ta den endelige beslutningen.
• En AI-agent: planlegger og utfører flere trinn ved hjelp av avgrensede verktøy og tilganger.
• En prediktiv modell: anslår en kategori eller verdi fra strukturerte data.
• En generativ modell: lager tekst, bilder, lyd eller kode.

Skriv én setning som avgrenser løsningen: «Løsningen skal hjelpe denne brukeren med denne oppgaven ved å bruke disse kildene, mens disse beslutningene fortsatt tas av et menneske.»

Hvis setningen blir lang, inneholder flere brukergrupper eller prøver å løse mange prosesser samtidig, er første versjon for bred.

Velg mellom eksisterende modell og egen modell

Bruk en eksisterende modell når konkurransefortrinnet ligger i arbeidsflyten, dataene eller brukeropplevelsen — ikke i selve grunnmodellen. Det gir tre realistiske nivåer:

• Bygg med en eksisterende modell: Kall modellen gjennom et API eller en administrert plattform. Dette er ofte riktig for tekst, bilde, tale og generell resonnering.
• Tilpass en eksisterende modell: Bruk instruksjoner, egne eksempler, søk i godkjente kilder eller finjustering når standardmodellen ikke følger oppgaven godt nok.
• Tren en modell fra bunnen: Aktuelt når oppgaven krever en særskilt modellarkitektur, et eget datasett og kompetanse til å trene, evaluere og drifte modellen.

Google AI viser et bredt skille mellom ferdige modeller, utviklerverktøy og rammeverk for modelltrening. Poenget er å velge det enkleste nivået som kan oppfylle kravene — ikke det mest teknisk imponerende.

Steg 1: Definer problem og suksesskriterier

En AI-løsning kan bare vurderes hvis teamet på forhånd har definert hva den skal gjøre godt. Beskriv:

• hvem som bruker løsningen
• hvilken situasjon som utløser bruken
• hvilke data som er tilgjengelige
• hvilket resultat brukeren trenger
• hvilke feil som er uakseptable
• når et menneske må godkjenne eller overta

Gjør suksesskriteriene konkrete. For en løsning som sorterer henvendelser kan du teste om den velger riktig kategori. For en copilot kan du vurdere om svaret er korrekt, relevant, sporbart til en kilde og nyttig for neste handling.

Skill mellom modellkvalitet og produkteffekt. Et teknisk godt svar er ikke nok hvis brukeren ikke forstår det, ikke stoler på det eller ikke kan bruke det i arbeidsflyten.

Steg 2: Kartlegg data og kunnskapskilder

Datakvalitet og tilgangsgrenser bør avklares før prototypen får ekte informasjon. Lag en enkel oversikt over:

• hvilke kilder løsningen trenger
• hvem som eier hver kilde
• hvor ofte innholdet endres
• hvilke opplysninger som er sensitive
• hvem som skal få se hvilke svar
• hvordan feil eller utdaterte data kan rettes

En generativ løsning trenger ikke alltid modelltrening for å bruke virksomhetens kunnskap. Den kan hente relevante utdrag fra godkjente dokumenter når brukeren stiller et spørsmål. Da kan kildene oppdateres uten at hele modellen trenes på nytt.

Ikke koble til «alt» i første versjon. Begynn med et lite, kontrollert kildesett som er representativt for oppgaven. Det gjør feil enklere å finne og svar enklere å kontrollere.

Steg 3: Velg modell, verktøy og arkitektur

Velg teknologien etter kravene til oppgaven, ikke etter hva som er mest omtalt. Vurder følgende:

• Modalitet: Skal løsningen forstå tekst, tabeller, bilder, lyd eller en kombinasjon?
• Kvalitet: Hvor komplekse instruksjoner og faglige vurderinger må modellen håndtere?
• Responstid: Må svaret komme mens brukeren venter, eller kan oppgaven kjøre i bakgrunnen?
• Kostnad: Hvor mange forespørsler, hvor mye kontekst og hvor lange svar forventes?
• Personvern: Hvilke data kan sendes til en ekstern tjeneste, og hvilke må behandles i et kontrollert miljø?
• Drift: Hvem følger opp versjoner, feil, leverandørendringer og kapasitet?

For tradisjonell maskinlæring er TensorFlow og PyTorch eksempler på rammeverk for å bygge og trene modeller. For en generativ app kan et modell-API og en enkel applikasjonsarkitektur være nok til å teste hypotesen.

Steg 4: Bygg en avgrenset prototype

Prototypen skal besvare de største usikkerhetene, ikke etterligne et ferdig produkt. Bygg den minste sammenhengende flyten:

1. Brukeren gir nødvendig input.
2. Systemet henter bare tillatte data.
3. Modellen får en tydelig instruksjon og relevant kontekst.
4. Svaret valideres eller merkes for menneskelig kontroll.
5. Resultatet vises på en måte som gjør neste handling tydelig.

Det er mulig å lage tidlige konsepter med lite kode. Google Cloud beskriver en iterativ utviklingssløyfe der man beskriver appen, prøver resultatet, gir tilbakemelding og forbedrer løsningen. En slik bygger kan være nyttig for å utforske en idé, men produksjonskravene forsvinner ikke: dataflyt, tilgangsstyring, testing og drift må fortsatt være tydelige.

Hold modellkallet adskilt fra forretningsreglene. Regler om hvem som får gjøre hva, hvilke felter som er påkrevd og når en handling kan utføres, bør håndheves av applikasjonen — ikke overlates til en språkmodell.

Steg 5: Lag et realistisk testsett

Testsettet er fasiten teamet bruker for å avgjøre om neste versjon faktisk er bedre. Samle realistiske eksempler før dere finjusterer instruksjoner og flyt.

Testsettet bør inneholde:

• vanlige oppgaver
• tvetydige formuleringer
• manglende informasjon
• motstridende kilder
• spørsmål løsningen ikke skal svare på
• forsøk på å få tilgang til data brukeren ikke har rett til å se
• situasjoner der løsningen skal be om godkjenning

Vurder hvert eksempel med kriterier som passer oppgaven. Det kan være korrekthet, kildegrunnlag, fullstendighet, format, sikkerhet og om riktig neste handling ble valgt. Logg også hvorfor et svar feilet. Da kan dere skille mellom problemer i data, instruksjon, modell, integrasjon og brukergrensesnitt.

Steg 6: Bygg sikkerhetsgrenser rundt modellen

Modellen bør få minst mulig tilgang og aldri være den eneste kontrollen før en viktig handling. Bruk blant annet:

• rollebaserte tilganger
• godkjente verktøy med smale funksjoner
• validering av inndata og utdata
• tydelig bekreftelse før handlinger med konsekvenser
• logging uten unødvendige personopplysninger
• grenser for kostnad, antall kall og kjøretid
• en definert vei til menneskelig overtakelse

En AI-agent som kan lese kalenderen trenger ikke automatisk rett til å sende e-post. En copilot som foreslår en endring trenger ikke rett til å publisere den. Del lese-, foreslå- og utføretilganger i separate nivåer.

Planlegg også for usikkerhet. Løsningen må kunne si at grunnlaget er utilstrekkelig, be om mer informasjon eller stoppe en handling. Et tydelig avslag er bedre enn et selvsikkert, men feil resultat.

Steg 7: Gå fra prototype til produksjon

Produksjonssetting er et eget arbeidstrinn, ikke en knapp på slutten av prototypen. Før lansering bør teamet avklare:

• identitet og tilgangsstyring
• lagring og sletting av data
• feilhåndtering og reserveflyt
• versjonering av modell, instruksjoner og kunnskapskilder
• overvåking av kvalitet, responstid og kostnad
• ansvar for hendelser og brukerhenvendelser
• hvordan løsningen kan deaktiveres uten å stoppe resten av produktet

Start med en begrenset brukergruppe og en tydelig oppgave. Sammenlign faktiske resultater med testsettet og suksesskriteriene. Utvid først når teamet kan forklare hvilke feil som oppstår, hvordan de oppdages og hvem som følger dem opp.

Steg 8: Overvåk og forbedre

En AI-løsning er ikke ferdig når den er lansert, fordi bruksmønstre, datakilder og modeller endrer seg. Følg med på:

• hvilke oppgaver brukerne prøver å løse
• hvor ofte løsningen ber om hjelp eller blir overstyrt
• hvilke kilder som mangler eller er utdaterte
• hvilke testeksempler som begynner å feile
• endringer i kostnad og responstid
• nye risikoer når funksjoner eller tilganger utvides

Gjør feileksempler om til nye testtilfeller. Kjør testsettet på nytt når dere endrer modell, instruksjon, datakilde eller integrasjon. Da blir forbedring en kontrollert prosess i stedet for tilfeldig justering.

Vanlige feil når man lager AI

De dyreste feilene skyldes som regel uklare rammer, ikke manglende modellkapasitet. Unngå særlig disse:

• For omfattende førsteversjon: Løs én arbeidsflyt før løsningen får flere roller.
• Uklart kvalitetsmål: Bestem hvordan gode og dårlige svar skilles før dere optimaliserer.
• Ukontrollert datatilgang: Gi tilgang kilde for kilde og rolle for rolle.
• Testing med bare enkle eksempler: Inkluder tvetydighet, avslag og reelle feiltilfeller.
• For mye ansvar hos modellen: Hold regler, validering og autorisasjon i applikasjonen.
• Ingen plan for drift: Avklar overvåking, eierskap og avstenging før lansering.
• Trening fra bunnen for tidlig: Bekreft først at en eksisterende modell ikke kan løse oppgaven med riktig kontekst og produktdesign.

Hva koster det å lage en AI?

Kostnaden styres mer av omfang, data, integrasjoner og risikonivå enn av ordet «AI». En enkel prototype med en eksisterende modell kan kreve lite infrastruktur. En produksjonsløsning med flere datakilder, strenge tilgangskrav og handlinger i andre systemer krever mer produktutvikling, testing og drift.

Del estimatet i konkrete poster:

• produktavklaring og design
• datarydding og integrasjoner
• modellbruk eller modelltrening
• evaluering og sikkerhetstesting
• applikasjon, brukergrensesnitt og tilgangsstyring
• overvåking, brukerstøtte og løpende forbedring

Be om et estimat for en avgrenset første leveranse med tydelige forutsetninger. Da blir det enklere å sammenligne alternativer og stoppe før en kostbar utvidelse hvis hypotesen ikke holder.

Kan jeg lage AI uten å kunne programmere?

Ja, du kan lage en prototype uten mye kode, men en robust produksjonsløsning krever fortsatt tekniske vurderinger. Visuelle byggere og AI-baserte utviklingsverktøy kan hjelpe med idé, flyt og et tidlig grensesnitt. Integrasjoner, tilgangsstyring, databehandling, testing og drift må likevel utformes og kontrolleres.

Må jeg trene min egen AI-modell?

Nei, ikke hvis en eksisterende modell kan løse oppgaven med gode instruksjoner, riktige kilder og tydelige verktøy. Vurder tilpasning eller egen trening først når testresultatene viser et konkret gap som ikke kan løses enklere.

Hvilket programmeringsspråk er best for AI?

Python er et vanlig valg for modellarbeid, mens selve produktet kan bygges i språket som passer resten av systemet. Velg ut fra teamets kompetanse, integrasjonene, driftsmiljøet og bibliotekene dere faktisk trenger. En AI-funksjon må ikke tvinge hele produktet over på en ny teknologistakk.

Hvor lang tid tar det å lage en AI-løsning?

Tidsbruken avhenger av hvor tydelig oppgaven er, hvor tilgjengelige dataene er og hvilke krav som gjelder for integrasjon og sikkerhet. Skill mellom en prototype som tester en hypotese og en produksjonsløsning som skal forvaltes over tid. Be om en plan med milepæler og avklarte leveranser fremfor ett løst tidsanslag.

Hva bør jeg bygge først?

Bygg den minste flyten som løser én reell oppgave fra start til slutt. Velg en oppgave med tydelig input, et vurderbart resultat og begrenset konsekvens hvis løsningen tar feil. Det gir bedre læring enn en generell chatbot uten klart ansvar.

Fra idé til et avgrenset AI-prosjekt

Et godt AI-prosjekt begynner med avgrensning og slutter med målbar drift. Hvis du kan beskrive brukeren, oppgaven, kildene, kvalitetskravene og tilgangsgrensene, har du et grunnlag for å velge riktig modell og bygge en realistisk første versjon.

Vil du avklare omfang, arkitektur og neste steg for en AI-agent eller copilot? Start en samtale.