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

Kravspesifikasjon for AI-løsning: mal for anskaffelse

En kravspesifikasjon for en AI-løsning skal gjøre tre ting: avgrense hva som kjøpes, gjøre tilbudene sammenlignbare og beskrive hvordan leveransen skal godkjennes. Start derfor med oppgaven, resultatet, dataene, grensene og ansvaret. Produktnavn og løsningsetiketter kommer etterpå.

Denne malen er for innkjøpere, prosjektledere og beslutningstakere som skal sende en forespørsel, vurdere leverandører eller forberede en kontrakt. Den handler bare om anskaffelse og leverandørvalg. For en teknisk innføring i hvordan KI-agenter fungerer, aktuelle arbeidsflyter og pilotering, se guiden om KI-agenter.

Dette skal kravspesifikasjonen dekke

En brukbar kravspesifikasjon beskriver leveransen, ikke bare teknologien. Den skal gjøre det mulig å prise samme oppgave, dokumentere avvik og avgjøre om resultatet kan godkjennes.

Ta med seks kravområder:

• funksjonen løsningen skal utføre
• systemer, integrasjoner og teknisk miljø
• data, personvern og sikkerhet
• kvalitet, test og akseptanse
• drift, forvaltning og endringer
• pris, avtaleperiode og avslutning

Malen nedenfor går fra et kort oppgavekort til kravmatrise, demoskript, poengkort og akseptanseplan. Den vurderer ikke om virksomheten bør velge en agent eller copilot; det er et eget teknologivalg.

Start med et oppgavekort på én side

Oppgavekortet gir alle leverandører samme problem å prise og løse. Det bør være kort nok til å brukes i tilbudsdialogen, 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.

Formuler leveransen slik:

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.»

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, én forventet svarform og ett beviskrav. Helsedirektoratets veiledning om kravspesifikasjoner for KI-systemer skiller blant annet mellom generelle, funksjonelle, tekniske og sikkerhetsmessige krav. For et sammenlignbart leverandørvalg bør matrisen også dekke kvalitet, drift og kommersielle forhold.

1. Funksjonelle krav

Beskriv observerbar atferd, ikke løse egenskaper:

• hvilken hendelse som starter arbeidet
• hvilke resultater løsningen skal levere
• hvor resultatet skal vises eller lagres
• hvilke steg som krever vurdering hos kunden
• hvordan manglende grunnlag og unntak håndteres
• hvilke handlinger løsningen aldri skal utføre

«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 hver del som standard, konfigurasjon, spesialutvikling eller tredjepart. Da blir både pris og avhengigheter synlige.

3. Data, personvern og sikkerhet

Datakravene skal vise hvilke opplysninger løsningen kan bruke, hvor de behandles og hvem som har tilgang. Digdirs veiledning for KI-anskaffelser peker blant annet på personvern, sikkerhet, datakvalitet, forklarbarhet, logging, testing og menneskelig kontroll som relevante kravområder.

Kravlisten bør avklare:

• tillatte datakilder og formål
• lagringssted og behandlingssted
• roller med lese-, endrings- og godkjenningsrett
• logging av hendelser og avvik
• tilbaketrekking av tilganger
• eksport, oppbevaring og sletting
• dokumentasjon som skal overleveres

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

4. Kvalitet og testing

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

• testtilfeller og testdata
• forventet resultat for hvert tilfelle
• kritiske og mindre alvorlige avvik
• antall åpne avvik som kan godtas
• ansvarlig for gjennomføring og godkjenning
• ny test etter retting eller endring

Testgrunnlaget bør inneholde normalsaker, 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 avtalte 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

Krev en navngitt ansvarstype hos både kunden og leverandøren. En løsning kan ikke forvaltes hvis oppfølgingen bare beskrives som «løpende samarbeid».

6. Kommersielle krav

Bruk samme avtaleperiode og volum i alle tilbud. Be om pris fordelt på:

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 pris for et avtalt scenario med høyere volum. Da kan ulike prismodeller vurderes mot samme forutsetninger.

Krev samme svarformat fra alle leverandører

Svarformatet avgjør om tilbudene faktisk kan sammenlignes. 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, data eller beslutninger kunden må stille med
• dokumentasjon eller demonstrasjon som beviser svaret
• foreslått akseptansekriterium
• forutsetninger og avhengigheter

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

Legg ved en ansvarsmatrise for hele arbeidsflyten

Ansvarsmatrisen viser leveransegrensen steg for steg. Be leverandøren føre opp hvert steg fra start til godkjent resultat og angi:

• hvem som utfører steget
• hvilken tilgang steget krever
• hvilket resultat steget skal gi
• hvem som kontrollerer resultatet
• hva som logges
• hvem som håndterer avvik
• om steget ligger innenfor eller utenfor prisen

Hvis én brukerflate skjuler flere komponenter, skal komponentene fortsatt ha tydelige leveransegrenser. Matrisen gjør det vanskeligere å prise en sentral del som «kundens ansvar» etter at tilbudet er valgt.

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. hvordan ansvar fordeles gjennom flyten
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. Planlagt 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:

• 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.

Sammenlign totalpris, ikke bare etableringspris

Tilbudene må normaliseres før prisene kan rangeres. Summer etablering, løpende bruk, forvaltning og avslutning for samme periode og samme volum.

Synliggjør også:

• timer eller roller kunden må stille med
• tredjepartskostnader som faktureres separat
• prisvirkning ved høyere volum
• pris for endringer og ny testing
• kostnad ved eksport og leverandørbytte

En lav etableringspris er ikke nødvendigvis et rimelig tilbud hvis drift, endringer eller uttrekk er utelatt.

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 på samme grunnlag?
• 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 videreutvikling og 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
• formater og frister for uttrekk
• 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. En generell setning om at kunden eier dataene forklarer ikke hvordan et faktisk uttrekk eller bytte skal gjennomføres.

Beslutningspakken ledelsen skal få

Beslutningsgrunnlaget 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
• ansvarsmatrise
• 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 hvilken presentasjon som virket mest overbevisende.

Hva er det viktigste kravet i en AI-anskaffelse?

Det viktigste er en presis leveransegrense: hva løsningen skal produsere, hvilket grunnlag den kan bruke, hvem som godkjenner resultatet og hvilke handlinger som ligger utenfor leveransen. Resten av kravmatrisen bør støtte denne grensen.

Hvor detaljert bør kravspesifikasjonen være?

Den bør være detaljert nok til at leverandørene kan prise samme oppgave og at kunden kan teste resultatet. Beskriv behov og akseptansekriterier presist, men unngå å foreskrive tekniske valg som ikke er nødvendige for sikkerhet, integrasjon eller drift.

Hvilken dokumentasjon bør kreves?

Krev minst system- og dataflyt, roller og tilganger, konfigurasjon kunden skal forvalte, testgrunnlag, drifts- og avviksrutiner samt eksport- og avslutningsplan. Be om eksempler før leverandørvalget.

Hvordan sammenlignes 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.

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, full-stack-produkter, vekstsystemer og løsninger for automasjon og drift. Vi avklarer behov, leveransegrense og akseptanse før arbeidet starter. Omfang, pris, tidsplan, 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.