En god kravspecifikation til et AI-projekt beskriver, hvad systemet skal kunne, hvor godt det skal fungere, hvilke data det skal bruge, og hvordan resultatet måles. Fordi en AI-løsning ikke altid giver det samme svar, skal "virker / virker ikke" erstattes af acceptkriterier, der måles på et testsæt af rigtige eksempler – ellers kan I hverken sammenligne tilbud eller afgøre, om leverancen er godkendt.
Skabelonen kan bruges både til et formelt udbud og til en enklere forespørgsel til to-tre leverandører.
Artiklen er en skabelon til projektledere, IT-chefer og indkøbere, der skal beskrive et AI-projekt over for leverandører. Den handler om selve specifikationen; hvordan man planlægger og afgrænser en pilot, står i vores guide til AI-pilotprojekter.
Kort fortalt
- Et acceptkriterium er en målbar betingelse for, at en leverance godkendes; i AI-projekter måles det typisk som en andel korrekte svar på et aftalt testsæt.
- Et testsæt bør bestå af rigtige eksempler fra hverdagen med det forventede resultat skrevet ned på forhånd.
- Gem en del af testsættet til den endelige accepttest, så leverandøren ikke har udviklet direkte efter den.
- Specifikationen bør angive, om der behandles personoplysninger, og hvor løsningen placerer sig i AI-forordningen; højrisikoreglerne for bilag III-systemer gælder fra 2. december 2027 (pr. oktober 2026).
- Uden et afsnit om, hvad der er uden for scope, bliver faste priser hurtigt urealistiske.
Hvad gør en kravspecifikation til et AI-projekt anderledes?
I et traditionelt projekt kan man skrive "systemet skal beregne moms korrekt" og teste det. En sprogmodel – den type AI-model, der læser og skriver tekst – kan svare rigtigt på 95 spørgsmål og forkert på fem, og svaret kan variere en smule fra gang til gang. Det giver tre konsekvenser:
- Kvalitet måles på et testsæt, ikke på et enkelt krav.
- Fejlhåndtering skal specificeres: hvad løsningen gør ved tvivl, hvem der godkender, og hvordan der rettes.
- Data er en del af kravene og skal beskrives lige så præcist som funktionerne.
Skabelonen – ti afsnit
| Afsnit | Indhold | Eksempel |
|---|---|---|
| 1. Formål og use case | Én sætning om, hvem der gør hvad, og hvorfor | "Kundeservice skal finde svar i 400 produktark med kildehenvisning" |
| 2. Brugere og arbejdsgang | Hvem bruger løsningen, hvor, og hvad sker før og efter | Medarbejdere i helpdesken; svar godkendes manuelt |
| 3. Data | Kilder, mængde, format, kvalitet, opdatering, persondata | PDF- og Word-filer, opdateres månedligt, ingen persondata |
| 4. Funktionelle krav | Hvad løsningen skal og ikke skal gøre | Svar med kilde; sig "ved ikke" uden kilde |
| 5. Acceptkriterier | Testsæt, målepunkter og grænseværdier | 100 spørgsmål; aftalt andel korrekte med korrekt kilde |
| 6. Integrationer | Systemer, API'er, læse- eller skriveadgang | Læseadgang til produktdatabasen via API |
| 7. Sikkerhed og compliance | Adgangsstyring, hosting, logning, GDPR, AI-forordningen | EU-hosting, single sign-on, logs i 90 dage |
| 8. Drift og omkostninger | Svartid, oppetid, volumen, løbende udgifter | 2.000 spørgsmål pr. måned; estimat for modeludgifter |
| 9. Ejerskab og exit | Kode, prompts, testsæt, dokumentation | Koden i vores repository fra dag ét |
| 10. Uden for scope | Det, der bevidst ikke er med | Mobilapp, flere sprog, ERP-integration |
Et API er en programmeringsgrænseflade, som andre systemer kan hente data igennem. Prompts er de instruktioner, sprogmodellen får.
Afsnit 8 bliver ofte glemt. Angiv forventet volumen – antal spørgsmål, dokumenter eller sager pr. måned – og bed leverandøren estimere de løbende udgifter til sprogmodel og hosting ved den volumen. Prisen for at kalde en sprogmodel afhænger af, hvor meget tekst der sendes ind og ud, så en løsning, der sender hele dokumenter med i hvert kald, kan blive langt dyrere i drift end en, der kun sender de relevante afsnit.
Acceptkriterier, der kan testes
Sådan kan afsnit 5 formuleres i praksis:
- Kriterium 1: "På et testsæt med 100 rigtige spørgsmål skal mindst en aftalt andel af svarene være korrekte og henvise til den rigtige kilde, bedømt af to medarbejdere fra kundeservice."
- Kriterium 2: "Ved spørgsmål uden svar i produktarkene skal løsningen sige, at den ikke ved det, i alle testtilfælde."
- Kriterium 3: "Svartiden skal ligge under en aftalt grænse ved normal belastning."
Et par tekniske råd om selve testsættet: Versionér det som kode, så det er tydeligt, hvilken version en leverance er målt mod. Sørg for, at det dækker de svære tilfælde – tvetydige spørgsmål, dokumenter med tabeller, stavefejl og spørgsmål uden svar – og ikke kun de lette. Beslut, hvem der bedømmer, og skriv bedømmelseskriterierne ned, før de første svar kommer; ellers flytter målstregen sig undervejs. Og del testsættet i en udviklingsdel, som leverandøren må arbejde med, og en skjult del, som kun bruges til accepttesten.
Grænseværdien fastsætter I selv ud fra opgaven: Et internt søgeværktøj kan leve med flere fejl end en kundevendt chatbot, der svarer på vilkår. Kender I ikke det realistiske niveau, er det et argument for at måle det i en kort pilot, før kravet låses.
Et eksempel på, hvordan en målbar nøjagtighed ser ud i en færdig leverance: For en amerikansk fintechvirksomhed byggede vi på 14 uger en løsning til dokumentforståelse med store sprogmodeller. Ifølge den publicerede case nåede den 95 % nøjagtighed, behandlingstiden faldt med 80 %, og den årlige besparelse er opgjort til USD 200.000. Den publicerede case oplyser 95 % nøjagtighed, men beskriver ikke målegrundlaget her. Aftal derfor selv testsæt og bedømmelse, før I bruger et sådant tal som acceptkriterium.
Persondata, AI-forordningen og hosting
Tre spørgsmål hører hjemme i specifikationen, ikke i kontrakten bagefter:
- Behandles der personoplysninger? I så fald skal leverandøren have en databehandleraftale og, hvis udviklerne sidder uden for EU, et overførselsgrundlag. Se Datatilsynet om rollefordelingen mellem dataansvarlig og databehandler.
- Hvor ligger løsningen i AI-forordningen? Visse anvendelser, fx i ansættelse og kreditvurdering, er højrisiko efter bilag III i AI-forordningen. Efter AI Omnibus gælder reglerne for dem fra 2. december 2027; gennemsigtighedskravene for bl.a. chatbots gælder fra 2. august 2026 (pr. oktober 2026).
- Hvor ligger data og logs? Angiv region for hosting, sprogmodel, logs og vektorindeks, og om modeludbyderen må gemme input.
Dette er generel information, ikke juridisk rådgivning.
Faldgruber – og hvad leverandørens spørgsmål afslører
- "Et AI-system til hele virksomheden" er en vision, ikke en specifikation. Skær ned til én use case.
- Ingen dataeksempler betyder, at leverandørerne gætter – tilbuddene bliver enten for dyre eller for optimistiske.
- Funktionskrav uden kvalitetskrav siger intet om, hvor godt løsningen skal virke.
- Glemte løbende udgifter til sprogmodel, hosting og vedligehold.
- Uklart ejerskab til kode, prompts og testsæt.
- Ingen ændringsproces. Aftal, hvordan ændringer prissættes og godkendes, før arbejdet starter.
Læg også mærke til, hvad leverandørerne spørger om. En leverandør, der spørger ind til jeres data, testsættet og tilfældene, hvor løsningen skal sige "ved ikke", har forstået opgaven. Et tilbud med fast pris og leveringsdato, før nogen har set data, er et advarselstegn.
NKKTech Global, en AI-udviklingsvirksomhed med udviklere i Hanoi, Vietnam, giver fast pris ud fra en specifikation som denne. Er acceptkriterierne endnu usikre, kan de måles i NKKTechs AI Pilot: én use case som fungerende pilot på jeres egne data på 3–4 uger, til fast pris på USD 3.000–15.000 (vejledende ca. DKK 20.000–101.000 ved vores referencekurs, pr. oktober 2026), og koden er jeres. Se priser, vores side for danske virksomheder eller kontakt os med jeres udkast.
Ofte stillede spørgsmål
Hvad skal en kravspecifikation til et AI-projekt indeholde? Formål og use case, brugere og arbejdsgang, beskrivelse af data, funktionelle krav, acceptkriterier med testsæt, integrationer, sikkerhed og compliance, drift og løbende omkostninger, ejerskab og exit samt en liste over, hvad der er uden for scope.
Hvordan skriver man acceptkriterier for AI? Byg et testsæt af rigtige eksempler med de korrekte svar, beslut hvordan svarene bedømmes, og fastsæt en grænseværdi for andelen af korrekte svar. Gem en del af testsættet til den endelige accepttest.
Kan man få fast pris på et AI-projekt? Ja, når scope, data og acceptkriterier er beskrevet konkret. Jo mere præcis specifikationen er, jo lettere er det for leverandøren at give en fast pris, og ændringer undervejs bør prissættes og godkendes, før arbejdet på dem starter.
Næste skridt
Har I et udkast til en kravspecifikation eller kun en idé og en stak eksempler? Send det til NKKTech, så får I konkrete kommentarer til use case, data og acceptkriterier, før specifikationen går i udbud.
Erfarne udviklere i Vietnam, en klart afgrænset opgave og et skriftligt tilbud inden for 3 arbejdsdage.

10 years of experience working with Japanese companies — two of those years based in Japan. Has run the business since 2018 (as NKKTech since 2025) with a senior-only engineering model.