AI-anskaffelserHafsteinn Runarsson · AI Konsulent15 Sept 2026 · 9 min

Kravspesifikasjon for AI-løsning: mal for leverandørvalg

En god kravspesifikasjon for en AI-løsning beskriver hva leverandøren skal levere, hvordan leveransen skal dokumenteres, og hvordan kunden avgjør om den er godkjent. Den bør ikke starte med produktnavn som «copilot» eller «agent». Start med oppgaven, resultatet, grensene og ansvaret.

Denne malen er for innkjøpere, prosjektledere og beslutningstakere som skal sende en forespørsel, sammenligne tilbud eller forberede en kontrakt. Den handler om anskaffelse og leverandørvalg. For forklaring av hvordan KI-agenter fungerer, aktuelle arbeidsflyter og pilotering, se guiden om KI-agenter.

Beskriv leveransen før dere beskriver teknologien

Leveransen må kunne forstås og prises uten et bestemt produktnavn. Skriv én setning som angir startpunkt, sluttresultat, arbeidsflate og kundens ansvar.

Bruk denne formen:

Løsningen skal [støtte eller utføre et avgrenset arbeid] fra [startpunkt] til [sluttresultat] i [system], mens [rolle] beholder ansvar for [beslutning eller handling].

Et eksempel er: «Løsningen skal lage et svarutkast i sakssystemet med godkjent kundekontekst, mens saksbehandleren vurderer og sender svaret.»

Formuleringer som «effektiviser kundeservice» eller «innfør en digital medarbeider» gir ikke tilbyderne samme beregningsgrunnlag. Beskriv først den kjøpbare leveransen. La deretter leverandørene forklare hvilken løsningsform som dekker den.

Legg ved et oppgavekort på én side

Oppgavekortet gir alle tilbyderne samme utgangspunkt. Det skal være kort nok til å brukes i dialogen, men presist nok til å avdekke ulike forutsetninger.

Ta med:

1. Startpunkt: Hendelsen, forespørselen eller brukerhandlingen som starter arbeidet.
2. Sluttresultat: Resultatet virksomheten skal motta, og hvor det skal ligge.
3. Arbeidsflate: Systemene der arbeidet begynner, behandles og leveres.
4. Brukerens del: Vurderinger, beslutninger og handlinger som blir hos kunden.
5. Leverandørens del: Oppsett, integrasjoner, støtte og drift som inngår.
6. Volum: Forventet antall brukere, saker eller kjøringer i avtaleperioden.
7. Prosesseier: Rollen som kan godkjenne krav, test og endringer.
8. Avgrensning: Det løsningen uttrykkelig ikke skal gjøre.

Be leverandøren svare mot oppgavekortet. En generell produktpresentasjon er ikke et svar på behovet.

Bygg kravmatrisen i seks deler

En kravmatrise gjør tilbudene sammenlignbare når hvert krav har én tydelig plass og én forventet svarform. Helsedirektoratets veiledning skiller blant annet mellom generelle, funksjonelle, tekniske og sikkerhetsmessige krav i en KI-anskaffelse. For en bred virksomhetsanskaffelse er det også nyttig å skille ut data, drift og kommersielle forhold.

1. Funksjonelle krav

Beskriv hva brukeren eller prosessen skal kunne oppnå:

• hvilken hendelse som starter arbeidet
• hvilke resultater løsningen skal levere
• hvilke steg som krever menneskelig vurdering
• hvordan unntak og manglende grunnlag håndteres
• hvordan resultatet presenteres i arbeidsflaten
• hvilke handlinger løsningen aldri skal utføre

Kravene bør beskrive observerbar atferd. «Brukervennlig» er vanskelig å teste. «En saksbehandler skal kunne se grunnlaget, endre utkastet og godkjenne det i samme arbeidsflate» kan demonstreres og aksepteres.

2. Tekniske krav

Beskriv koblingene og driftsmiljøet uten å låse unødvendig til én leverandør:

• systemer, grensesnitt og dataformater
• identitet, roller og tilgangsstyring
• test-, produksjons- og eventuelle utviklingsmiljøer
• forventet kapasitet og responstid
• logging, overvåking og feilhåndtering
• eksport og integrasjoner ved avslutning

Be leverandøren merke hva som er standard, konfigurasjon, spesialutvikling eller tredjepart.

3. Data, personvern og sikkerhet

Beskriv hvilke data løsningen kan bruke og hvilke grenser som gjelder. Digdir anbefaler at krav ved KI-anskaffelser dekker blant annet personvern, sikkerhet, datakvalitet, forklarbarhet, logging, testing og menneskelig kontroll.

Kravlisten bør avklare:

• hvilke datakilder som er tillatt
• hvor data behandles og lagres
• hvilke roller som kan lese, foreslå og endre
• hvordan hendelser og avvik logges
• hvordan kunden kan trekke tilbake tilganger
• hvordan data eksporteres og slettes
• hvilken dokumentasjon leverandøren skal overlevere

Be om konkrete beskrivelser. «Sikkerhet ivaretas» er ikke et etterprøvbart svar.

4. Kvalitet og testing

Definer hva som er godt nok før kontrakten signeres:

• hvilke testtilfeller som skal brukes
• forventet resultat for hvert tilfelle
• hvilke feil som er kritiske
• hvor mange avvik som kan stå åpne ved godkjenning
• hvem som gjennomfører og godkjenner testen
• hvordan ny test skjer etter retting eller endring

Testgrunnlaget bør inneholde vanlige saker, krevende unntak og tilfeller løsningen skal avvise eller sende videre.

5. Drift og forvaltning

Avklar hvem som gjør hva etter overlevering:

• overvåking og hendelseshåndtering
• brukerstøtte og responstider
• oppdatering av instrukser, regler og integrasjoner
• testing ved endring av modell, datakilde eller systemkobling
• rapportering av kvalitet, bruk og avvik
• ansvar for opplæring og dokumentasjon

En løsning er ikke ferdig anskaffet hvis ingen har ansvar for å følge den opp.

6. Kommersielle krav

Bruk samme avtaleperiode og volum i alle tilbud. Be om pris for:

1. Etablering: Kartlegging, konfigurasjon, integrasjoner, migrering, test og opplæring.
2. Løpende bruk: Lisenser, brukere, modellbruk, transaksjoner og tredjepartstjenester.
3. Forvaltning: Støtte, overvåking, feilretting, rapportering og avtalte endringer.
4. Avslutning: Eksport, sletting, dokumentoverføring og bistand ved leverandørbytte.

Be også om et scenario med høyere volum. Da blir prismodeller med ulike forutsetninger lettere å sammenligne.

Krev samme svarformat fra alle leverandører

Svarformatet er like viktig som kravlisten. Hvis hver leverandør svarer på sin egen måte, må kunden gjette hva som er inkludert.

Be om én linje per krav med:

• krav-ID
• svar: oppfylt, delvis oppfylt eller avvik
• leveransemåte: standard, konfigurasjon, spesialutvikling eller tredjepart
• hva som er inkludert i prisen
• arbeid eller data kunden må stille med
• dokumentasjon eller demonstrasjon som beviser svaret
• foreslått akseptansekriterium
• eventuelle forutsetninger og avhengigheter

Et «ja» uten leveransebeskrivelse eller bevis bør ikke gi full uttelling.

Bruk arbeidsdeling i stedet for produktetiketter

Arbeidsdelingen viser hva dere faktisk kjøper, uansett hva leverandøren kaller løsningen. Be tilbyderen føre opp hvert steg fra start til godkjent resultat og merke det som:

• utføres av bruker
• utføres av kundens eksisterende system
• utføres av leverandørens løsning
• krever godkjenning hos kunden
• ligger utenfor leveransen

For hvert steg skal tilbudet angi nødvendig tilgang, forventet resultat, logging og ansvar ved avvik. Hvis én brukerflate skjuler flere komponenter, skal komponentene fortsatt ha tydelige leveransegrenser.

Det gjør det mulig å sammenligne et tilbud som kalles copilot med et tilbud som kalles agent uten å gjøre begrepene til evalueringskriterier.

Gjør demonstrasjonen etterprøvbar

En styrt demonstrasjon tester kravene; en fri produktdemo tester presentasjonsevnen. Send samme demoskript og samme eksempeldata til alle leverandører.

Be dem vise:

1. hvordan oppgaven starter
2. hvilket godkjent grunnlag løsningen bruker
3. hvilke steg brukeren og løsningen utfører
4. hvordan et mangelfullt eller tvetydig tilfelle håndteres
5. hvordan resultatet havner i avtalt arbeidsflate
6. hva som logges når et steg stopper eller feiler
7. hvordan en administrator finner dokumentasjon og historikk
8. hvordan tilgang kan trekkes tilbake

Registrer hva som faktisk ble vist. Fremtidig funksjonalitet skal merkes som planlagt, ikke vurderes som levert.

Knytt akseptanse til testbare resultater

Akseptanseplanen avgjør når etableringen er ferdig og hva som utløser betaling. Den bør angi:

• hvilke resultater som skal kontrolleres
• testdata og forventet resultat
• tillatte og kritiske avvik
• ansvarlig godkjenner
• frist og prosess for retting
• krav til dokumentasjon og tilganger
• betalingspunktet som følger godkjenningen

Hvis leveransen består av flere deler, gi dem egne akseptansekriterier. En god brukerflate skal ikke kunne skjule at integrasjon, logging eller eksport mangler.

Bruk et poengkort som tåler innsyn

Skill mellom minstekrav og poengkrav før tilbudene åpnes. Minstekrav avgjør om tilbudet kan godtas. Poengkrav rangerer tilbud som består.

Et kort evalueringskort kan bruke:

• Treff på oppgaven: Svarer tilbudet på oppgavekortet?
• Kravdekning: Er avvik og forutsetninger tydelige?
• Leveransegrense: Er kundens og leverandørens arbeid fordelt?
• Dokumentasjon: Kan tilbudets påstander etterprøves?
• Totalpris: Er alle kostnadstyper beregnet for samme periode og volum?
• Akseptanse: Kan kunden avgjøre om leveransen er ferdig?
• Forvaltning: Er drift, endringer og avvikshåndtering definert?
• Byttbarhet: Kan data, dokumentasjon og konfigurasjon tas med videre?

Bruk samme skala og skriv en kort begrunnelse for hvert poeng. Et brudd på et minstekrav skal ikke forsvinne i en høy totalscore.

Avtal endringer og leverandørbytte fra start

Kontrakten bør beskrive normal videreutvikling og en ryddig avslutning før avhengigheten oppstår. Avklar:

• hvem som eier oppgavebeskrivelser, instrukser og testgrunnlag
• hvordan pris beregnes ved ny datakilde, nytt arbeidssteg eller endret integrasjon
• hva som må testes på nytt ved endringer
• hvilke data, resultater og historikk som kan eksporteres
• hvilke formater og frister som gjelder
• hvordan tilganger fjernes og data slettes
• hvor lenge leverandøren bistår ved overgang
• hva avslutning og overgang koster

Be om en avslutningsplan som kontraktsvedlegg, ikke bare en generell setning om at kunden eier dataene.

Beslutningspakken ledelsen skal få

Beslutningen bør vise hva virksomheten kjøper, hva den selv må levere, og hva som fortsatt er uavklart. Pakken bør inneholde:

• oppgavekort og avgrensning
• kravmatrise med avvik
• arbeidsdelingsliste
• dokumentert demonstrasjon
• normalisert totalpris
• poengkort med begrunnelser
• akseptanseplan
• plan for drift, endring og avslutning
• åpne forutsetninger før oppstart

Da blir leverandørvalget knyttet til en avgrenset og testbar leveranse, ikke til hvilket produktnavn som høres mest avansert ut.

Må vi velge mellom copilot og agent før forespørselen sendes?

Nei. Beskriv oppgaven, grensene og akseptansekriteriene først. Be leverandørene foreslå løsningsform og forklare konsekvensene for arbeidsdeling, pris, dokumentasjon og risiko.

Hvordan sammenligner vi tilbud med ulike prismodeller?

Bruk samme avtaleperiode, basisvolum og scenario for høyere volum. Summer etablering, løpende bruk, forvaltning og avslutning. Synliggjør også arbeid kunden må utføre selv.

Hva bør kreves som dokumentasjon?

Krev minst system- og dataflyt, roller og tilganger, konfigurasjon kunden skal eie, testgrunnlag, rutiner for drift og avvik, samt eksport- og avslutningsplan. Be om et eksempel før leverandørvalget.

Når bør et avvik avvise tilbudet?

Bestem minstekravene før evalueringen. Avvik som gjør leveransen ulovlig, utestbar, utrygg eller uforenlig med nødvendig infrastruktur bør ikke kunne kompenseres med poeng på andre områder. Den konkrete vurderingen må gjøres av virksomhetens ansvarlige fag-, sikkerhets-, personvern- og innkjøpsroller.

Fra behov til kjøpbar AI-leveranse

Daia bygger AI-agenter og copiloter, fullstack-produkter, vekstsystemer og løsninger for automasjon og drift. Vi avklarer behov, leveransegrense og akseptanse før arbeidet starter. Omfang, pris, tilgang, eierskap, levering og overlevering avtales for hvert oppdrag.

Skal dere utforme en forespørsel eller sammenligne tilbud? Start en samtale med oppgavekortet eller kravlisten. Vi kan hjelpe dere å gjøre behovet om til en avgrenset, testbar leveranse.