Sådan skriver du en kravspecifikation til en intern AI-chatbot (RAG): krav, data, sikkerhed og KPI’er

Når en intern AI-chatbot skal kunne svare på spørgsmål med afsæt i virksomhedens egne dokumenter, er det sjældent teknologien alene, der afgør resultatet. Det afgørende ligger ofte i det dokument, der kommer før udviklingen: kravspecifikationen.

Det gælder især for en RAG-chatbot, hvor kvaliteten afhænger af samspillet mellem data, søgning, prompting, adgangskontrol og måling af effekt. Hvis kravene er uklare, får man let en løsning, der lyder overbevisende, men svarer upræcist, viser forkerte kilder eller giver adgang til indhold, som brugeren slet ikke burde se.

Hvorfor en kravspecifikation til en RAG-chatbot er afgørende

En klassisk chatbot kan ofte beskrives med relativt enkle funktioner: modtag spørgsmål, svar tilbage, eskalér ved behov. En intern RAG-chatbot er mere krævende. Her skal systemet både finde relevant viden, sammensætte kontekst, formulere et svar og respektere virksomhedens regler for sikkerhed og databrug.

Det betyder, at kravspecifikationen skal fungere som fælles arbejdsdokument for ledelse, fagejere, IT, sikkerhed, jura og udvikling. Den skal være præcis nok til, at løsningen kan bygges og testes, men også læsbar nok til, at forretningen kan godkende den.

En stærk kravspecifikation skaber værdi på flere niveauer:

• tydeligt scope
• færre misforståelser
• bedre datakvalitet
• hurtigere test og godkendelse
• mere realistiske KPI’er
• lavere risiko for fejl i drift

Hvis dokumentet er godt, bliver det lettere at tage små, sikre skridt. Det er som regel en bedre vej end at forsøge at dække hele organisationens viden fra dag ét.

Hvilke krav en intern RAG-chatbot bør indeholde

En kravspecifikation bør starte med det forretningsmæssige formål. Hvem er brugerne? Hvilke spørgsmål skal chatbotten besvare? Hvilke opgaver skal den ikke løse? Mange projekter går i stå, fordi man beskriver teknologien før man beskriver behovet.

Når formålet er fastlagt, bør kravene deles op i funktionelle og ikke-funktionelle krav. Den opdeling gør dokumentet langt mere brugbart, fordi det skaber klarhed om både adfærd og kvalitetsniveau.

De vigtigste funktionelle krav kan beskrives sådan:

• Spørgsmålsforståelse: Chatbotten skal kunne modtage fritekst, følge op på tidligere spørgsmål og håndtere almindelige omskrivninger.
• Retrieval: Systemet skal finde relevante dokumentuddrag fra godkendte interne kilder.
• Svargenerering: Svaret skal bygge på hentet kontekst og følge en fast promptlogik.
• Kildehenvisning: Brugeren skal kunne se, hvilke dokumenter eller afsnit svaret bygger på.
• Fallback: Chatbotten skal kunne sige, at den ikke ved det, eller sende brugeren videre.
• Integrationer: Løsningen skal kunne kobles til relevante systemer som intranet, SharePoint, CRM eller HR-platforme.

De ikke-funktionelle krav er lige så vigtige. Det er her, man fastlægger svartid, oppetid, samtidige brugere, vedligeholdelse, tilgængelighed og sikkerhed. En chatbot, der svarer korrekt, men er for langsom eller ustabil, bliver sjældent taget i brug i praksis.

Sådan beskriver du RAG-workflow i kravspecifikationen

Mange kravspecifikationer fejler, fordi de beskriver AI-svaret som en sort boks. Det er en svaghed. En RAG-chatbot bør beskrives som en sekvens af trin, så både forretning og teknik kan forstå, hvad der faktisk sker.

Det kan gøres enkelt og konkret. Først modtager systemet brugerens spørgsmål. Derefter omsættes spørgsmålet til et søgesignal, typisk via embeddings, nøgleord eller en kombination. Så hentes de mest relevante tekststykker fra vidensgrundlaget. De tekststykker samles i en prompt, og modellen instrueres til kun at svare ud fra det materiale. Til sidst vises svaret, ofte sammen med kilder.

Denne del af kravspecifikationen bør også gøre plads til designvalg. Skal der bruges hybrid search? Hvor mange tekststykker må komme med i prompten? Skal svar rangeres igen med en reranker? Skal chatbotten kunne håndtere opfølgende spørgsmål i samme kontekst?

En enkel tabel gør det nemt at fastholde overblikket:

Tabellen er ikke dokumentet i sig selv. Den er en struktur, som gør det lettere at udfylde de dele, der ellers bliver glemt.

Data og vidensgrundlag i en kravspecifikation til RAG-chatbot

Data er kernen i enhver RAG-løsning. En intern chatbot bliver ikke bedre end det vidensgrundlag, den søger i. Derfor skal kravspecifikationen være meget mere konkret her, end mange forventer.

Det er ikke nok at skrive, at chatbotten skal bruge “interne dokumenter”. Dokumenterne skal navngives som datakategorier, deres kvalitet skal vurderes, og ejerskabet skal placeres. Hvem har ansvar for indholdet? Hvor ofte opdateres det? Hvilke formater findes det i? Hvilke kilder er autoritative, hvis to dokumenter siger noget forskelligt?

Et godt datakapitel bør som minimum beskrive:

• dokumenttyper og systemer
• opdateringsfrekvens
• sprog og formater
• metadata og versionering
• dataejere og godkendelsesproces

Her bør man også skrive, hvordan indholdet forbehandles. Det er centralt i en RAG-chatbot. Dokumenter skal renses, opdeles i meningsfulde bidder og mærkes med metadata. Hvis chunking er for grov, mister man præcision. Hvis den er for fin, mister man sammenhæng.

Det er også her, mange organisationer opdager, at deres egentlige opgave ikke er at bygge en chatbot, men at rydde op i viden. Det er ikke et problem. Tværtimod. En præcis kravspecifikation gør det synligt tidligt i forløbet.

Sikkerhed, adgangskontrol og compliance for intern AI-chatbot

Når chatbotten arbejder med interne data, er sikkerhed ikke bare et teknisk krav. Det er et designprincip. En medarbejder må kun kunne få svar ud fra indhold, vedkommende allerede har ret til at se.

Derfor bør sikkerhed have sit eget afsnit i kravspecifikationen, også selv om noget af det overlapper med ikke-funktionelle krav. Det gør ansvaret tydeligere, og det hjælper både sikkerhedsansvarlige og udviklere.

Et sikkert minimum ser typisk sådan ud:

• Identitetsstyring: Login via virksomhedens SSO eller anden central identitetsløsning.
• Adgangskontrol: Retrieval skal filtrere på brugerens rolle, afdeling eller rettighedsniveau.
• Kryptering: Data i transit og data i hvile skal være beskyttet efter virksomhedens standarder.
• Logning: Alle væsentlige hændelser skal kunne spores uden at skabe unødig datarisiko.
• Dataplacering: Det skal være klart, hvor data behandles og opbevares.
• Slettepolitik: Samtalelog og brugerdata skal have definerede opbevaringsperioder.

Compliance bør ikke stå som en løs note bagerst i dokumentet. Hvis personoplysninger kan indgå i data eller chatforløb, skal kravspecifikationen sige, hvordan reglerne håndteres i praksis. Det gælder både behandlingsgrundlag, information til brugere og håndtering af indsigt eller sletning.

Der bør også stå noget om guardrails. Ikke kun mod skadeligt indhold, men mod fejlagtig adfærd. Chatbotten bør eksempelvis instrueres til at afstå fra gæt, markere usikkerhed og henvise til et menneske, når kilderne ikke er tilstrækkelige.

KPI’er og acceptkriterier for en RAG-chatbot

Hvis en chatbot kun vurderes på, om den “virker godt”, ender diskussionen hurtigt i mavefornemmelser. Derfor skal kravspecifikationen indeholde konkrete KPI’er og acceptkriterier.

Det er en god idé at skelne mellem fire niveauer: retrieval-kvalitet, svarkvalitet, driftskvalitet og forretningsværdi. På den måde måler man ikke kun modellens formuleringsevne, men hele løsningen.

KPI’er kan skrives meget operationelt:

• Svarnøjagtighed: Andel svar, der vurderes korrekte i et testdatasæt.
• Precision@k: Hvor stor en andel af de hentede tekststykker der faktisk er relevante.
• Citation rate: Hvor ofte chatbotten viser valide kilder sammen med svaret.
• Latenstid: Median og P95 svartid under normal belastning.
• Fallback-rate: Hvor ofte chatbotten ikke kan svare.
• Adoption: Hvor stor en del af målgruppen der bruger løsningen uge for uge.

Acceptkriterier skal knyttes til de vigtigste krav. Hvis chatbotten skal bruges til HR-politikker, bør der findes konkrete testspørgsmål med facit. Hvis løsningen skal give kildehenvisninger, bør det testes eksplicit. Hvis der kræves adgangsbegrænsning, bør test også omfatte forsøg på at hente indhold uden rettighed.

Det giver et langt stærkere projekt, når krav og målinger hænger tæt sammen. Så bliver evaluering ikke en særskilt fase, men en naturlig del af designet.

Roller, ansvar og governance i kravspecifikationen

Selv den bedste tekniske løsning mister værdi, hvis ingen ejer data, kvalitet og forbedringer. Derfor bør kravspecifikationen beskrive roller og ansvar med samme omhu som arkitekturen.

Det gælder både i opbygning og drift. Hvem godkender nye kilder? Hvem håndterer fejl i svar? Hvem følger op på KPI’er? Hvem må ændre promptskabeloner eller retrieval-indstillinger?

En enkel governance-model kan omfatte:

• forretningsejer
• dataejer
• sikkerhedsansvarlig
• teknisk ansvarlig
• indholdsansvarlige i de enkelte fagområder

Det er også nyttigt at angive en rytme for opfølgning. Ikke som en tung styreproces, men som en fast praksis. Månedlige reviews af logs, kvartalsvis revision af datakilder og løbende analyse af brugerfeedback giver ofte langt mere værdi end store sjældne omlægninger.

En praktisk måde at skrive første version af kravspecifikationen

Den første version behøver ikke være perfekt. Den skal være skarp nok til, at teamet kan træffe beslutninger. Start med én afgrænset use case, ét prioriteret datagrundlag og et lille sæt KPI’er.

Skriv dokumentet i et sprog, som både forretning og teknik kan arbejde med. Brug korte kravformuleringer, målbare kriterier og klare afgrænsninger. Hvis noget er usikkert, så skriv det som en antagelse eller et åbent punkt. Det er langt bedre end at skjule tvivl bag brede formuleringer.

En god kravspecifikation til en intern RAG-chatbot gør tre ting på én gang: Den beskytter projektet mod uklarhed, den skaber retning for udviklingen, og den giver organisationen et fælles billede af, hvad ansvarlig AI faktisk kræver i praksis.