AI og produktutviklingHafsteinn Runarsson · AI Konsulent16 Aug 2026 · 10 min

Velg riktig AI-byrå for AI-agenter i Norge

Velg et AI-byrå ut fra hvordan teamet forstår arbeidsflyten deres, avgrenser agentens ansvar og følger løsningen fra test til drift. Be om konkrete svar på hva agenten får gjøre, hvilke data den bruker, hvordan kvalitet måles og når et menneske må godkjenne.

Et AI-byrå kan levere alt fra rådgivning til et komplett digitalt produkt. Derfor er det mer nyttig å sammenligne ansvar, metode og leveranser enn å sammenligne hvor «AI-drevne» byråene sier at de er. Denne guiden gir deg en kortliste, ti vurderingskriterier og spørsmål du kan bruke i møtene.

Hva er et AI-byrå?

Et AI-byrå hjelper virksomheter med å finne, bygge eller innføre løsninger som bruker kunstig intelligens. Leveransen kan være strategi, opplæring, automatisering, en copilot, en AI-agent eller et produkt der AI er én del av systemet.

Byråene har ulike tyngdepunkter:

• rådgivning og prioritering av bruksområder
• innhold, søk og markedsføring
• automatisering og integrasjoner
• design, utvikling, testing og drift av digitale produkter

Trenger dere først og fremst én ekstern fagperson, kan guiden om å velge AI-konsulent være mer presis. Skal leverandøren ta ansvar for en hel løsning, bør dere vurdere team, produktarbeid og drift samlet.

Velg type partner før du velger navn

Start med oppgaven. Et rådgivningsmiljø kan passe når dere må prioritere muligheter og lage et beslutningsgrunnlag. En produksjonsklar tjeneste krever vanligvis flere roller og et tydelig ansvar for integrasjoner, testing, sikkerhet, innføring og drift.

Et markedsføringsbyrå med AI-kompetanse kan være riktig for innhold og synlighet. Det er ikke automatisk riktig team for en agent som skal lese interne data, oppdatere et fagsystem eller utløse en handling med konsekvenser. Tilsvarende kan et utviklingsteam bygge programvaren uten å ha ansvar for nye arbeidsrutiner og opplæring.

Be hver leverandør svare på tre spørsmål:

1. Hvilken del av oppgaven tar dere ansvar for?
2. Hvilke roller og navngitte personer skal gjøre arbeidet?
3. Hva må kunden eller en annen leverandør eie?

Når oppgaven er en AI-agent

En AI-agent arbeider mot et mål og kan bruke avtalte verktøy eller systemer i flere steg. En copilot lager et forslag som en person vurderer. Vanlig automasjon følger en fast sekvens. Disse løsningene kan ligne i grensesnittet, men de trenger ikke samme arkitektur eller kontroll.

Be byrået begrunne hvorfor oppgaven trenger en agent. En fast og forutsigbar prosess kan være enklere å bygge som vanlig automasjon. Hvis systemet skal velge mellom handlinger, trenger dere tydelige grenser for tilganger, stoppunkter og godkjenning.

NISTs rammeverk for risikostyring av AI legger opp til at hensyn til pålitelighet tas inn i design, utvikling, bruk og evaluering av AI-systemer. Det gir en nyttig kontroll for byråvalget: Teamet bør kunne forklare hvordan risiko håndteres gjennom hele leveransen, ikke bare vise et godt svar i en demo.

For en agent bør leverandøren beskrive:

• målet og kriteriene for at oppgaven er løst
• datakilder, verktøy og systemtilganger
• handlinger agenten kan utføre selv
• handlinger som krever godkjenning
• forhold som skal få agenten til å stoppe eller eskalere
• logging, feilhåndtering og mulighet for tilbakeføring

Før dere lager en kortliste

Skriv et beslutningsgrunnlag på én eller to sider. Det skal beskrive problemet godt nok til at leverandørene kan stille presise spørsmål. Det trenger ikke være en komplett kravspesifikasjon.

Ta med:

1. Hvem som utfører arbeidet i dag.
2. Hvilken oppgave eller beslutning som bør bli bedre.
3. Arbeidsflyten fra start til slutt.
4. Systemene og datakildene som er involvert.
5. Hva et nyttig resultat betyr for brukeren.
6. Hvilke feil som kan få alvorlige følger.
7. Hvem internt som kan ta produkt- og risikobeslutninger.

Unngå å begynne med «vi trenger en chatbot». Det er et løsningsforslag. En avgrenset MVP eller pilot bør i stedet teste den viktigste antakelsen med en komplett, forsvarlig arbeidsflyt.

Ti kriterier for å vurdere et AI-byrå

1. Byrået forstår arbeidsflyten

Den første samtalen bør handle om brukere, oppgaver, data, unntak og ønsket endring. Be teamet tegne hva som skjer før og etter AI-steget. Da ser dere også hvilke deler som bør være regelstyrte eller utføres av mennesker.

Vær forsiktig hvis leverandøren anbefaler en bestemt modell eller agentplattform før prosessen er forstått.

2. Erfaringen er relevant og etterprøvbar

Be om noen få eksempler som ligner på problemet deres. En kundelogo er ikke nok. Leverandøren bør kunne forklare hva brukeren prøvde å få gjort, hva teamet leverte, hvordan løsningen ble testet og hvilke begrensninger som dukket opp.

Konfidensielle oppdrag kan beskrives uten kundenavn. Metode, ansvar og tekniske avveininger bør likevel være konkrete.

3. Data og integrasjoner kartlegges tidlig

Be byrået kartlegge hvor nødvendige data finnes, hvem som eier dem, hvordan de oppdateres og hvilke tilganger løsningen trenger. Spør også hva systemet skal gjøre når opplysninger mangler eller er motstridende.

Hvis agenten skal skrive til andre systemer, må teamet avklare hvilke handlinger som kan reverseres. Hvis den bruker dokumenter som kunnskapsgrunnlag, bør dere få vite hvordan dokumentene velges, oppdateres og spores.

4. Arkitekturen kan forklares på vanlig norsk

Et godt svar skiller mellom språkmodell, regler, integrasjoner, lagring og brukergrensesnitt. Be byrået vise hva som skjer når en ekstern tjeneste er nede, en modell gir et dårlig svar eller en kostnadsgrense nås.

Dere trenger ikke velge modell selv. Dere bør forstå avhengighetene og hvor vanskelig det vil være å bytte modell eller leverandør senere.

5. Evalueringen er avtalt før demoen

Avtal representative oppgaver og akseptansekriterier før byggingen starter. Testsettet bør dekke vanlige oppgaver, manglende informasjon, uønskede instruksjoner, integrasjonsfeil og handlinger som skal stoppe ved et godkjenningspunkt.

NISTs AI RMF Playbook anbefaler blant annet å dokumentere målinger og vurdere ytelse før og etter produksjonssetting. I veiledningen om måling av AI-risiko inngår også overvåking etter lansering og jevnlig vurdering av om målene fortsatt virker. Be derfor byrået beskrive hvem som eier testene, når de kjøres og hva som skjer når resultatene svekkes.

6. Menneskelig kontroll følger konsekvensen

Krev mer kontroll når en feil kan utløse betaling, slette data, endre en kundesak eller sende en ekstern melding. Det kan bety at systemet bare lager et forslag, at en person må godkjenne handlingen, eller at enkelte beslutninger ikke delegeres.

Be om å få se hvordan agenten stopper, eskalerer og viser grunnlaget for handlingen. «Menneske i loopen» er for uklart uten navngitt ansvar og et synlig godkjenningspunkt.

7. Personvern og sikkerhet behandles som designkrav

Avklar hvilke personopplysninger som behandles, hvor de sendes, hvem som får tilgang og hvor lenge de lagres. Datatilsynet beskriver en vurdering av personvernkonsekvenser (DPIA) som en prosess for å beskrive behandlingen, vurdere nødvendighet og proporsjonalitet og fastsette risikoreduserende tiltak. Be leverandøren forklare hvem som gjør denne vurderingen når løsningen innebærer høy personvernrisiko.

En agent med systemtilgang trenger også avgrensede rettigheter og kontroll mot misbruk. OWASPs oversikt over trusler og tiltak for agentiske AI-systemer er et nyttig utgangspunkt når dere ber byrået presentere en konkret trusselmodell, ikke bare en generell sikkerhetserklæring.

8. Teamet bygger for drift

Be byrået beskrive tilgangsstyring, logging, overvåking, kostnadsgrenser, varsling, versjoner og tilbakeføring. Bruk et realistisk feilscenario: Hva skjer når modellen ikke svarer eller en integrasjon feiler? Hvem får varsel, og hva kan brukeren gjøre mens feilen pågår?

Svarene bør vise hvem som har driftsansvar etter piloten, og hvilke deler kunden må overta.

9. Innføringen har en eier

Utpek en intern eier som kan prioritere, skaffe tilgang til fagpersoner og avgjøre hvordan arbeidsrutiner skal endres. Be byrået involvere de faktiske brukerne i testing og avklare hvordan tilbakemeldinger, opplæring og endringer skal håndteres.

Hvis tiltaket påvirker flere roller og systemer, kan en praktisk plan for digital transformasjon hjelpe dere å avklare eierskap, arbeidsflyt og innføring før teknologien får styre prosjektet.

10. Pris, tilgang og overlevering er tydelig

Tilbudet bør vise hva som inngår, hvilke forutsetninger estimatet bygger på og hvordan endringer håndteres. Skill mellom avklaring, bygging, produksjonssetting og løpende drift. Be også om forventede kostnader til modellbruk, skytjenester, overvåking og lisenser.

Avtalen bør beskrive eierskap og tilgang til kode, data, kontoer, konfigurasjon, testsett og dokumentasjon. Et annet team bør kunne forstå og videreføre løsningen på avtalte vilkår.

Test samarbeidet med en avgrenset første fase

Den første fasen bør redusere den største usikkerheten. Det kan være en datakartlegging, en teknisk konsepttest eller en liten arbeidsflyt med reelle brukere. Avtal på forhånd hva fasen skal lære og hvilken beslutning resultatet skal støtte.

En nyttig første fase har:

• ett tydelig problem og en avgrenset brukergruppe
• nødvendige og tillatte data
• representative oppgaver og feiltilfeller
• et definert punkt for menneskelig kontroll
• synlige resultater og begrensninger
• et beslutningspunkt for stopp, endring eller videre bygging

Be teamet skille mellom det som er demonstrert, det som er testet og det som er klart for drift.

Spørsmål du bør stille finalistene

Still de samme spørsmålene til alle:

1. Hvilken del av problemet bør ikke løses med AI?
2. Hvilke data og tilganger trenger dere?
3. Hvorfor passer en agent bedre enn en copilot eller vanlig automasjon?
4. Hvilke antakelser tester dere først?
5. Hvordan bygger og vedlikeholder dere evalueringene?
6. Hvilke handlinger krever menneskelig godkjenning?
7. Hvordan håndteres uønskede instruksjoner og integrasjonsfeil?
8. Hvilke personopplysninger behandles, og hvem er ansvarlig for vurderingene?
9. Hvordan logger dere svar, kilder og handlinger?
10. Hva skjer hvis en modell eller ekstern tjeneste feiler?
11. Hvem jobber på oppdraget, og hvilket ansvar har hver person?
12. Hvilke underleverandører og modelltilbydere brukes?
13. Hva inngår ikke i estimatet?
14. Hvem kontrollerer kode, kontoer, data og testsett underveis?
15. Hvordan kan kunden eller en ny leverandør overta løsningen?

Gode svar er knyttet til deres situasjon. Byrået trenger ikke kjenne alle svar i første møte, men bør kunne beskrive hvordan de skal finne dem.

En enkel poengmodell

Gi hver finalist en poengsum fra 1 til 5 på kriteriene under. Skriv en kort begrunnelse og vekt kriteriene etter risikoen i prosjektet.

• problemforståelse og avgrensning
• data og integrasjoner
• evaluering og løpende kvalitetskontroll
• kontroll, personvern og sikkerhet
• produksjon og drift
• team, samarbeid og innføring
• pris, eierskap og overlevering

Poengsummen skal støtte samtalen. Et kritisk hull i sikkerhet, rettigheter eller eierskap bør behandles som et eget stoppunkt, selv om gjennomsnittet er høyt.

Hva koster et AI-byrå?

Prisen avhenger av omfanget, datagrunnlaget, integrasjonene, brukerrollene og kravene til testing og drift. Be leverandøren vise forutsetningene bak estimatet i stedet for å love ett presist tall før oppgaven er undersøkt.

Vanlige prismodeller er en avgrenset fastpris, løpende timer eller et dedikert team. Fastpris passer best når mål og akseptansekriterier er tydelige. Løpende arbeid gir rom for læring underveis, men trenger en økonomisk ramme og hyppige prioriteringer.

Be om å få skilt mellom:

• kartlegging og design
• bygging og integrasjoner
• testing og produksjonssetting
• modell- og skykostnader
• vedlikehold, overvåking og videreutvikling

Må AI-byrået være norsk?

Velg norsk tilstedeværelse når språk, workshops, arbeidstid eller lokale avtaler reduserer en konkret risiko. Geografi alene sier lite om leveransekvalitet.

Undersøk i stedet:

• språket i produktet, møtene og dokumentasjonen
• hvor data behandles og lagres
• hvilke selskaper og underleverandører som deltar
• hvilke arbeidstider som overlapper
• hvem som har ansvar når noe feiler
• hvilket lands lov og avtalevilkår som gjelder

Røde flagg

Vær forsiktig dersom et AI-byrå:

• lover gevinst før dagens situasjon er målt
• anbefaler verktøy før oppgaven og dataene er forstått
• viser en demo uten å forklare evalueringen
• er uklart om hvor data sendes eller hvilke modeller som brukes
• vil gi en agent brede rettigheter uten godkjenning og logging
• omtaler en pilot som produksjonsklar uten en driftsplan
• skjuler leveranseteamet bak selgere eller underleverandører
• mangler en plan for eierskap, tilgang og overlevering
• lover pris, tid eller resultat uten tydelige forutsetninger

Flere uklare svar på de samme temaene er et godt grunnlag for å velge en annen finalist.

Hva bør et byrå for AI-agenter kunne vise?

Byrået bør kunne demonstrere hvordan agenten bruker data og verktøy, hvordan handlingene evalueres og hvor menneskelig godkjenning er bygget inn. Be også om et feilscenario der agenten stopper eller går over i en tryggere arbeidsmåte.

Hva er forskjellen på en AI-agent og vanlig automasjon?

Vanlig automasjon følger en fast arbeidsflyt. En AI-agent kan velge mellom avtalte handlinger ut fra mål og kontekst. Hvis oppgaven kan løses pålitelig med regler og en fast sekvens, bør byrået kunne forklare hvorfor en agent likevel er nødvendig.

Trenger vi intern AI-kompetanse?

Dere trenger ikke et fullt AI-team, men dere trenger en intern eier. Denne personen må kunne prioritere, skaffe tilgang til fagpersoner og data og ta beslutninger om risiko og arbeidsflyt. Byrået kan levere kompetanse, men virksomheten må eie sine egne mål og avveininger.

Hvordan vet vi om piloten virker?

Definer representative oppgaver, akseptansekriterier og alvorlige feil før testen starter. Sammenlign resultatene med dagens arbeidsmåte. Registrer kvalitet, tidsbruk, korrigeringer og tilfeller der systemet skal avstå eller eskalere.

Kort oppsummert

Velg et AI-byrå ut fra hvordan det håndterer problemet, dataene, risikoen og veien til drift. Be om konkrete svar om evaluering, menneskelig kontroll, sikkerhet og overlevering. Sammenlign finalistene med de samme spørsmålene, og start med en fase som reduserer den viktigste usikkerheten.

Daia er et AI-produktstudio i Bergen, etablert i 2019. Vi arbeider med AI-agenter og copiloter, full-stack-produkter, vekstsystemer og automatisering. Arbeidet avgrenses og prises før oppstart. Timing, tilgang, eierskap, levering og overlevering avtales for hvert oppdrag. Start en samtale hvis du vil diskutere en AI-løsning eller produksjonsleveranse.