Skabeloner til effektive prompts er faste instruktioner, der gør AI-opgaver mere ensartede, kontrollerbare og lettere at forbedre. De bør angive formål, kontekst, input, begrænsninger og outputformat, men de skal stadig testes, versioneres og kvalitetssikres, før de bruges i vigtige arbejdsgange.
Skabeloner til effektive prompts gør gentagne AI-opgaver mere ensartede ved at samle formål, kontekst, input, begrænsninger og outputformat. De bør bruges som kontrollerede arbejdsredskaber med test, versionsstyring og menneskelig kvalitetssikring, ikke som garanti for korrekte eller sikre svar.
Hvad er en skabelon til AI-instruktioner?
En skabelon til AI-instruktioner er en genbrugelig ramme for, hvordan en bruger beskriver en opgave til en generativ AI-model. Den kan være en kort tekst med udfyldningsfelter eller en mere detaljeret arbejdsbeskrivelse med regler, eksempler, datakrav og kontrolpunkter.
Formålet er ikke at gøre alle svar ens, men at gøre processen mere forudsigelig. Når opgave, målgruppe, datagrundlag og format står samme sted hver gang, bliver det lettere at finde ud af, hvorfor et svar lykkes eller fejler. Skabelonen bliver dermed et lille stykke procesdesign, ikke bare en formulering.
En god skabelon forklarer også, hvad modellen ikke skal gøre. Den kan for eksempel forbyde antagelser uden kilde, afgrænse svaret til et bestemt dokument eller kræve, at usikkerhed markeres tydeligt. Det gør den mere nyttig i teams, hvor flere brugere ellers ville skrive opgaverne på meget forskellige måder.
Hvornår giver skabeloner mest værdi?
Skabeloner giver mest værdi, når den samme type opgave gentages, og når variation i svarene skaber ekstra arbejde. Det kan være kundesvar, referater, researchnoter, indholdskladder, kodegennemgang, risikovurderinger eller interne beslutningsoplæg.
Hvis opgaven kun udføres én gang, kan en almindelig instruktion være nok. Hvis opgaven udføres ofte, af flere personer eller med krav om ensartet kvalitet, bør den beskrives som en skabelon. Det gør fejl lettere at opdage, fordi alle brugere arbejder ud fra samme struktur.
Skabeloner er særligt nyttige, når output skal indgå i en videre proces. Et mødenotat skal måske kunne overføres til projektstyring. En produktanalyse skal måske kunne sammenlignes med tidligere vurderinger. Et kundesvar skal måske godkendes, før det sendes. I den type workflow er format og kontrol lige så vigtigt som selve svaret.
Hvilke faste felter bør en skabelon indeholde?
De bedste skabeloner gør inputfelter synlige. Brugeren skal kunne se, hvad der skal udfyldes, og hvad der er faste regler. Hvis alt står som én lang tekst, bliver skabelonen svær at tilpasse og svær at fejlfinde.
| Felt | Formål | Eksempel på afgrænsning |
|---|---|---|
| Opgave | Fortæller hvad modellen skal producere | Skriv et kort beslutningsoplæg, ikke en fuld rapport |
| Målgruppe | Styrer sprog, detaljer og forklaringsniveau | Skriv til projektledere uden teknisk specialistviden |
| Datagrundlag | Angiver hvilke oplysninger der må bruges | Brug kun de vedhæftede noter og marker manglende fakta |
| Begrænsninger | Reducerer uønskede antagelser og irrelevante svar | Opfind ikke tal, datoer eller navngivne kilder |
| Outputformat | Gør svaret lettere at læse, validere eller genbruge | Returner en tabel med risiko, begrundelse og næste handling |
Felterne bør være konkrete nok til at guide brugeren, men ikke så detaljerede, at skabelonen kun virker i én smal situation. Hvis et felt ofte ikke kan udfyldes, er det et tegn på, at skabelonen bør deles i flere versioner.
Hvordan bruger du eksempler uden at gøre skabelonen stiv?
Eksempler kan være mere præcise end abstrakte regler. De viser modellen, hvilken tone, længde, struktur og detaljeringsgrad der forventes. Officielle vejledninger fra flere modeludbydere peger på eksempler som en måde at gøre svar mere konsistente på.
Eksempler kan dog også gøre skabelonen for snæver. Hvis eksemplet kun passer til én type kunde, ét fagområde eller én risikoprofil, kan modellen overføre mønstret til opgaver, hvor det ikke passer. Derfor bør eksempler ledsages af korte regler, der forklarer, hvad modellen skal efterligne.
- Brug eksempler, der dækker almindelige og vanskelige tilfælde.
- Forklar, hvilke dele af eksemplet der er vigtige: format, rækkefølge, tone eller begrundelse.
- Undgå eksempler med opdigtede fakta, hvis skabelonen skal bruges til kildebaserede opgaver.
- Test skabelonen på nye input, ikke kun på de cases, den blev skrevet ud fra.
For tekstproduktion kan eksempler være nyttige, men de bør ikke blive en skjult stilguide uden faglige krav. Artiklen om AI-assisteret copywriting viser, hvorfor målgruppe, tone og kontrol stadig skal beskrives tydeligt.
Hvordan beskriver du outputformatet præcist?
Outputformatet er en af de mest praktiske dele af en skabelon. Det fortæller modellen, om svaret skal være en kort konklusion, en tabel, en trinvis proces, et referat eller en klassifikation. Et tydeligt format gør svaret lettere at kontrollere.
Hvis output skal bruges af mennesker, kan formatkravet handle om læsbarhed: korte afsnit, få punkter, tydelige forbehold og en konklusion først. Hvis output skal bruges af et system, skal formatkravet være mere teknisk. Her bør skabelonen ikke være den eneste kontrol; struktureret output, skemavalidering eller kode bør sikre, at resultatet faktisk kan læses maskinelt.
En god regel er at beskrive formatet med både form og indhold. Det er mere præcist at bede om “en tabel med kolonnerne fund, betydning og anbefalet kontrol” end blot at bede om “en tabel”. Dermed ved modellen, hvilke dele der skal med, og brugeren kan hurtigere se, om noget mangler.
Hvordan bør skabeloner håndtere kilder og fakta?
Skabeloner bør tydeligt skelne mellem oplysninger, modellen må bruge, og oplysninger den ikke må antage. Hvis opgaven kræver faktuel nøjagtighed, skal skabelonen angive kilder, datagrundlag eller krav om at markere usikkerhed. Den bør også instruere modellen i at sige fra, når kilderne ikke dækker spørgsmålet.
Det er især relevant ved research, markedsnotater, produktinformation, sikkerhed og regulering. En model kan formulere et overbevisende svar uden at have adgang til aktuelle eller korrekte oplysninger. Skabelonen bør derfor kræve, at tal, datoer, navne og tekniske påstande enten dokumenteres eller skrives som usikre.
Når et workflow bygger på eksterne kilder, kan grounding af AI-modeller eller Retrieval-Augmented Generation være relevant. Skabelonen styrer, hvordan materialet skal bruges, men kvaliteten afhænger også af, om det rigtige materiale bliver hentet.
Hvordan bygger du en skabelon trin for trin?
En skabelon bør bygges ud fra en konkret opgave, ikke ud fra en generel idé om at bruge AI. Start med at beskrive den arbejdsgang, hvor skabelonen skal indgå. Hvem bruger den, hvilket input har de, hvilket output skal de bruge, og hvem godkender resultatet?
- Vælg én gentagen opgave med tydeligt formål.
- Beskriv nødvendige inputfelter og faste regler.
- Angiv ønsket outputformat og kvalitetskriterier.
- Tilføj et eller to repræsentative eksempler, hvis opgaven kræver ensartet stil.
- Test skabelonen på realistiske cases med både almindelige og vanskelige input.
- Ret skabelonen ud fra fejl, ikke ud fra enkeltstående smag.
- Giv skabelonen ejer, versionsnummer og dato for seneste ændring.
Det sidste trin er ofte overset. Når en skabelon virker godt, bliver den hurtigt kopieret. Uden ejer og versionsstyring kan flere udgaver cirkulere samtidig, og ingen ved, hvilken der faktisk er godkendt.
Hvordan tester du om en skabelon virker?
En skabelon virker ikke, bare fordi den giver et pænt svar. Den virker, når den løser den rigtige opgave stabilt på flere input. Testen bør derfor omfatte både normale cases, uklare input, manglende oplysninger og eksempler, hvor modellen bør stoppe eller stille et opklarende spørgsmål.
Test bør måle konkrete kriterier: svarer modellen på opgaven, følger den formatet, opfinder den fakta, markerer den usikkerhed, og holder den sig til datagrundlaget? Hvis testen kun vurderer sproglig kvalitet, kan en skabelon se bedre ud, end den er.
Ved opgaver med konsekvens bør testen også omfatte menneskelig godkendelse. En skabelon til mødenoter kan måske godkendes med stikprøver, mens en skabelon til risikovurdering bør gennemgås mere systematisk. AI-mødereferater er et eksempel på en lavere risikotype, hvor struktur og efterkontrol stadig betyder noget.
Hvilke fejl gør skabeloner mindre effektive?
Den mest almindelige fejl er at gøre skabelonen for generel. Hvis den kan bruges til alt, styrer den næsten ingenting. En anden fejl er at skrive for mange regler uden at forklare prioritet. Når kravene strider mod hinanden, vælger modellen selv, hvad der vægtes højest.
En tredje fejl er at blande faste regler og brugerinput sammen. Hvis brugeren skal udfylde et felt, bør det stå tydeligt. Hvis en regel altid gælder, bør den ikke kunne overskrives ved et uheld. Denne adskillelse er særlig vigtig, når skabelonen kopieres mellem værktøjer eller deles i et team.
- For bred opgave, hvor modellen selv skal gætte formålet.
- Manglende datakrav, så modellen fylder huller med antagelser.
- Uklart format, så svarene bliver svære at sammenligne.
- Eksempler, der ikke passer til nye situationer.
- Ingen test, ejer eller versionshistorik.
Fejlene er ofte procesfejl snarere end sprogfejl. Derfor bør skabeloner forbedres ud fra observationer i brug: hvor opstod misforståelsen, hvilket input manglede, og hvilket kontrolpunkt ville have fanget fejlen?
Hvordan bør teams dele og vedligeholde skabeloner?
Når skabeloner bruges i teams, bør de ligge ét sted med tydelige versioner. Det kan være et dokumentbibliotek, et internt værktøj eller en kontrolleret skabelonsamling. Pointen er, at brugerne ved, hvilken version der er gældende, og hvem der kan ændre den.
Vedligeholdelse bør knyttes til erfaringer fra brug. Hvis en skabelon ofte giver for lange svar, mangler kilder eller skaber uklare konklusioner, bør problemet skrives ind i næste version. Det er bedre end at hver bruger laver sin egen private rettelse.
Skabeloner bør også have en udløbsdato eller et planlagt review. AI-værktøjer ændrer sig, interne krav ændrer sig, og nye datakilder kan gøre gamle instruktioner forældede. For projektarbejde kan AI til projektledelse give en nærliggende ramme for, hvordan skabeloner kan kobles til ansvar, opgaver og opfølgning.
Hvordan beskytter du skabeloner mod usikker brug?
Skabeloner kan reducere fejl, men de kan ikke alene beskytte et AI-system. Hvis modellen får eksterne dokumenter, webindhold eller værktøjsadgang, kan uønskede instruktioner i materialet påvirke svaret. OWASP beskriver denne type angreb som en central risiko for LLM-applikationer.
En sikker skabelon bør derfor indeholde regler for datagrundlag, værktøjsbrug og godkendelse. Den bør forklare, at eksternt indhold er materiale, ikke instruktioner fra en betroet afsender. Den bør også kræve, at handlinger med konsekvens godkendes af et menneske, hvis systemet kan sende, ændre, slette eller offentliggøre noget.
Tekniske kontroller er lige så vigtige som tekstlige regler. Begræns rettigheder, log handlinger, valider output og adskil brugerinput fra faste instruktioner, hvor værktøjet tillader det. Artiklen om AI-sikkerhed mod jailbreaking uddyber, hvorfor pænt formulerede instruktioner ikke bør stå alene.
Hvornår bør du ikke bruge en standardiseret skabelon?
En standardiseret skabelon er mindre egnet, når opgaven er ny, uklar eller afhænger af høj faglig vurdering. Hvis du endnu ikke ved, hvilke oplysninger der er relevante, kan en fast ramme give falsk sikkerhed. Her er det bedre at starte med eksplorativ analyse og først lave skabelon, når opgaven er forstået.
Skabeloner bør heller ikke bruges til at omgå ansvar. Hvis en opgave kræver juridisk, medicinsk, økonomisk eller sikkerhedsmæssig vurdering, kan AI hjælpe med struktur og udkast, men skabelonen må ikke erstatte faglig godkendelse. Det samme gælder, hvis input indeholder følsomme oplysninger eller fortrolige data.
En nyttig tommelfingerregel er at spørge, om fejlen kan accepteres. Hvis et forkert svar kun giver lidt ekstra redigering, kan skabelonen være tilstrækkelig. Hvis et forkert svar kan skade mennesker, økonomi, sikkerhed eller rettigheder, skal skabelonen indgå i en bredere kontrolproces.
Hvordan måler du forbedringer over tid?
Skabeloner bør forbedres ud fra observationer, ikke mavefornemmelser. Mål for eksempel hvor ofte output følger formatet, hvor mange svar der kræver omskrivning, hvor mange faktafejl der opdages, og hvilke felter brugerne ofte udfylder forkert. Små målinger kan gøre forbedringer mere konkrete.
Du kan også samle fejltyper i kategorier: manglende kilde, forkert målgruppe, for langt svar, utydelig konklusion eller brud på format. Når fejlene gentager sig, er det skabelonen, ikke kun brugeren, der bør justeres.
For organisationer passer dette til en bredere risikotænkning. NISTs AI Risk Management Framework beskriver AI-risikostyring som aktiviteter på tværs af livscyklus, styring, måling og håndtering. Overført til skabeloner betyder det, at gode AI-instruktioner bør have ejer, test, revision og dokumenteret anvendelsesområde.
Hvilke kilder ligger til grund?
Artiklen bygger især på OpenAIs dokumentation om tekstgenerering, Google AI Developers’ strategier for prompting og Anthropics dokumentation om Claude. Sikkerheds- og governanceafsnit bygger desuden på OWASP Top 10 for LLM Applications og NISTs AI Risk Management Framework.