Brugergenererede prompts er de instruktioner, spørgsmål, eksempler og data, som en bruger selv indtaster i et AI-system. De former svaret direkte, men de kan også indeholde følsomme oplysninger, usikre antagelser eller skjulte instruktioner. Derfor skal prompts behandles som både arbejdsinput, datakilde og risikofaktor.
Brugergenererede prompts er både instruktioner, datakilder og risikopunkter i AI-systemer. Overblikket viser, hvordan brugerinput påvirker svar, hvilke oplysninger der kan blive delt, og hvordan teams kan arbejde mere sikkert med dataminimering, strukturerede input, kvalitetskontrol og klare interne regler.
Hvad betyder brugergenererede prompts i AI-systemer?
Brugergenererede prompts er de frie eller delvist strukturerede beskeder, som mennesker skriver til en sprogmodel, chatbot, billedmodel, agent eller anden generativ AI-løsning. De kan bestå af et spørgsmål, en kommando, en tekst, en fil, et datasæt, en rollebeskrivelse, et eksempel eller en kombination af flere elementer.
Begrebet er bredere end en enkelt formulering i et chatfelt. I en organisation kan brugergenererede prompts være kundetekster, medarbejdernoter, mødeudskrifter, produktkrav, undervisningsopgaver, kodeudsnit, kontraktudkast, supporthenvendelser eller billedbeskrivelser. Fællespunktet er, at brugeren tilfører indhold, som modellen bruger til at beregne et svar.
Det gør prompts til et centralt grænsefelt mellem mennesker og AI. Kvaliteten af brugerinput påvirker outputtet, men inputtet kan også afsløre oplysninger, styre modellen i en forkert retning eller skabe sikkerhedsrisici. Derfor bør de ikke kun ses som skrivehjælp. De bør ses som en del af systemets databehandling og kontrolmiljø.
Hvorfor påvirker brugerinput modellens svar så meget?
En generativ AI-model beregner et svar ud fra den kontekst, den får. Brugerens tekst er en del af den kontekst sammen med systeminstruktioner, værktøjsresultater, uploadede filer, hukommelsesfunktioner og eventuelle regler i applikationen. Jo mere præcist inputtet beskriver mål, afgrænsning og materiale, desto bedre grundlag har modellen for at svare relevant.
Det betyder ikke, at et godt input garanterer et korrekt svar. En sprogmodel kan stadig misforstå opgaven, udlede for meget, overse usikkerheder eller formulere et plausibelt svar uden solid kilde. Det er samme grundproblem, som kendes fra AI-hallucinationer: modellen producerer tekst ud fra sandsynlige mønstre, ikke ud fra en automatisk sandhedstest.
Praktisk handler det derfor om at give modellen den rigtige opgave og derefter kontrollere resultatet. Et godt brugerinput angiver formål, målgruppe, format, relevante data, begrænsninger og ønsket usikkerhedsniveau. Et dårligt input blander mål, antagelser og materiale sammen, så svaret bliver svært at validere.
Hvad er forskellen på frie instruktioner og strukturerede input?
Frie instruktioner er åbne tekster, hvor brugeren selv bestemmer formulering, rækkefølge og detaljer. De er fleksible og hurtige, men de giver også større variation i output. To brugere kan bede om næsten det samme og få meget forskellige svar, fordi de beskriver kontekst, krav og begrænsninger forskelligt.
Strukturerede input bruger derimod faste felter, skabeloner eller formularer. De kan bede brugeren udfylde mål, baggrund, datakilde, ønsket format, forbehold og kontrolkrav hver for sig. Det gør input mere ensartet og lettere at gennemgå. Det gør også logning og kvalitetssikring mere praktisk, fordi man kan se, hvilke oplysninger der lå til grund for outputtet.
| Inputtype | Styrke | Typisk risiko |
|---|---|---|
| Fri instruktion | Hurtig, fleksibel og god til ideudvikling | Uens kvalitet, uklare krav og større fortolkningsrum |
| Struktureret formular | Ensartet, lettere at validere og bedre til gentagne opgaver | Kan blive for snæver, hvis opgaven kræver nuancer |
| Uploadet materiale | Giver modellen konkret kontekst og mere relevant indhold | Kan indeholde persondata, fortrolige oplysninger eller skjulte instruktioner |
Hvilke data kan brugere komme til at afgive?
Brugere kan afgive langt mere end selve spørgsmålet. De kan indsætte personoplysninger, interne dokumenter, kundedata, kildekode, billeder, lyd, video, kontrakter, regneark, sundhedsoplysninger eller fortrolige strategier. De kan også afgive metadata indirekte, for eksempel gennem filer, integrationer, lokation, kontooplysninger eller samtalehistorik.
OpenAIs europæiske privatlivspolitik beskriver eksempelvis brugerindhold som indhold, der gives i input til tjenester, herunder prompts og uploadet materiale, og beskriver datakontroller for brug, hukommelse, eksport og sletning. Den konkrete behandling afhænger af tjeneste, kontotype, indstillinger, aftale og lovgrundlag. Andre leverandører kan have andre vilkår.
Den praktiske konsekvens er enkel: Du bør ikke skrive noget i et AI-system, som du ikke har vurderet som egnet til den konkrete tjeneste. Hvis inputtet indeholder persondata, kundedata eller fortrolige oplysninger, skal det først afklares, om formålet, behandlingsgrundlaget, sikkerheden og leverandørens vilkår kan bære brugen.
Hvordan bør private oplysninger og fortroligt materiale håndteres?
Private og fortrolige oplysninger bør minimeres, før de bruges i AI. Ofte kan du erstatte navne, kunde-id’er, adresser, nøgletal, interne kodenavne og andre identifikatorer med neutrale markører. Hvis den præcise oplysning ikke er nødvendig for opgaven, bør den ikke indgå i brugerinputtet.
En organisation bør skelne mellem åbne opgaver, interne opgaver og følsomme opgaver. Åbne opgaver kan være generelle ideer eller omskrivninger uden fortrolige oplysninger. Interne opgaver kan kræve godkendte værktøjer og klare regler. Følsomme opgaver bør kun gennemføres, hvis databehandling, adgangsstyring, logning, opbevaring og sletning er afklaret på forhånd.
En intern AI-politik bør derfor beskrive, hvilke oplysninger medarbejdere må bruge i prompts, hvilke værktøjer der er godkendt, hvordan data skal anonymiseres, og hvornår en opgave kræver ekstra vurdering. Uden klare regler bliver kvaliteten afhængig af den enkelte brugers dømmekraft i øjeblikket.
Hvordan opstår sikkerhedsrisici fra brugerinput?
Sikkerhedsrisici opstår, når et AI-system behandler brugerinput eller eksternt indhold som instruktioner, der kan ændre systemets adfærd. I en simpel chat kan det føre til et uønsket svar. I en agent, der kan læse filer, søge på nettet, sende beskeder eller kalde værktøjer, kan konsekvensen være mere alvorlig, fordi output kan udløse handlinger.
OWASP Top 10 for LLM Applications 2025 fremhæver, at LLM-applikationer har særlige sårbarheder, efterhånden som de indlejres dybere i kundedialog, interne processer og automatiserede systemer. Brugergenererede prompts bør derfor behandles som ikke-tillidsværdigt input, på samme måde som formularfelter og uploadede filer i klassisk applikationssikkerhed.
Forskellen er, at naturligt sprog kan være både data og instruktion på samme tid. En uploaded tekst kan ligne almindeligt materiale, men indeholde en ordre til modellen om at ignorere regler eller lække information. Det kan ikke løses fuldt ud med høfligere formuleringer. Det kræver afgrænsede rettigheder, filtrering, test, logging og menneskelig kontrol ved kritiske handlinger.
Hvordan kan en organisation designe en mere sikker inputproces?
En sikker inputproces starter før modellen modtager teksten. Brugeren bør først vælge opgavetype, dataklasse og ønsket output. Systemet kan derefter give relevante felter, advarsler og begrænsninger. Det er mere robust end et tomt chatfelt, hvor brugeren skal huske alle regler selv.
En praktisk proces kan bestå af fem trin:
- Klassificer opgaven som åben, intern, fortrolig eller følsom.
- Fjern oplysninger, der ikke er nødvendige for svaret.
- Brug faste felter for mål, kontekst, datakilde, format og forbehold.
- Lad systemet blokere eller advare ved risikable datatyper og handlinger.
- Kræv menneskelig godkendelse, før output bruges i beslutninger, kundedialog eller automatiserede handlinger.
Google beskriver for Gemini API, at sikkerhedsindstillinger kan justeres efter kategori og sandsynlighed for usikkert indhold. Det viser et vigtigt princip: sikkerhed er ikke en enkelt knap. Filtre, politikker, rettighedsstyring og faglig kontrol skal tilpasses brugssituationen.
Hvornår er fælles skabeloner nyttige?
Fælles skabeloner er nyttige, når mange brugere løser samme type opgave, og organisationen vil have ensartet kvalitet. Det kan være kundesvar, mødereferater, analyseoplæg, kodegennemgang, undervisningsfeedback eller juridisk-administrative sammendrag. Skabelonen hjælper brugeren med at give de oplysninger, modellen skal bruge, uden at tilføje unødvendige data.
En god skabelon bør ikke kun være en tekst, som kopieres ind. Den bør afspejle arbejdsgangen: Hvad er målet? Hvilke kilder må bruges? Hvad må modellen ikke antage? Hvilket outputformat ønskes? Hvilke dele skal efterkontrolleres? Når de elementer er faste, bliver output lettere at sammenligne og forbedre.
Skabeloner kan dog give falsk tryghed, hvis de bruges mekanisk. De bør testes med realistiske eksempler, fejlscenarier og svære grænsetilfælde. Hvis brugere ofte omskriver skabelonen, er det et signal om, at den ikke passer til opgaven, eller at opgaven bør deles op i mindre trin.
Hvordan vurderer du kvaliteten af AI-svar fra brugernes input?
Kvaliteten bør vurderes ud fra opgaven, ikke ud fra om svaret lyder flydende. Et svar kan være velskrevet og stadig være forkert, ufuldstændigt eller uegnet til brug. Kontrollér derfor både relevans, faktuel dækning, kildegrundlag, usikkerheder, tone, databrug og eventuelle handlinger, som svaret lægger op til.
Du kan bruge fire kontrolspørgsmål: Svarer modellen på den rigtige opgave? Bygger svaret på det materiale, der faktisk blev givet? Skelner svaret mellem fakta, antagelser og forslag? Kan en anden person gennemskue, hvorfor svaret blev valgt? Hvis svaret skal bruges eksternt, bør du også kontrollere rettigheder, persondata og afsenderansvar.
For gentagne arbejdsprocesser bør kvalitet måles over flere eksempler. Enkelte gode svar siger ikke meget om robusthed. Test med korte input, lange input, uklare input, fejlbehæftede data og kritiske grænsetilfælde. På den måde bliver prompts en del af en kontrolleret metode, ikke en personlig skrivevane.
Hvordan hænger brugergenererede prompts sammen med AI-governance?
AI-governance handler om at styre ansvar, risiko, data, kvalitet og kontrol i brugen af AI. Brugergenererede prompts er relevante, fordi de ofte er det sted, hvor politik bliver til praksis. Hvis brugere frit kan sende hvad som helst til et system, kan selv en god model blive brugt på en måde, der bryder interne regler eller skaber uventet risiko.
NIST AI Risk Management Framework beskriver risikostyring som noget, der skal indarbejde troværdighed i design, udvikling, brug og evaluering af AI-systemer. Det passer direkte på prompts: organisationen bør kunne forklare, hvilke input der accepteres, hvordan de kontrolleres, hvilke output der må bruges, og hvem der er ansvarlig for efterkontrol.
AI-governance bliver derfor konkret, når den omsættes til felter, adgangsrettigheder, dataklassifikation, logning, review og træning af brugere. Uden den oversættelse ender governance let som et dokument ved siden af den faktiske AI-brug.
Hvilke regler og platformsvilkår bør du kende?
Regler og vilkår afhænger af system, rolle, data og anvendelse. EU’s AI-forordning 2024/1689 er relevant for AI-systemer i EU, herunder gennemsigtighed og krav til visse risikokategorier. Forordningen er trådt i kraft, men mange regler anvendes gradvist, og hovedanvendelsen er fra 2. august 2026.
Derudover skal databeskyttelse, ophavsret, tavshedspligt, ansættelsesretlige regler, kundeaftaler og leverandørvilkår vurderes efter situationen. En chatbot til åbne spørgsmål har ikke samme risikoprofil som et internt værktøj, der behandler kundesager eller HR-oplysninger. AI-chatbots og lovkrav bør derfor vurderes ud fra konkret brug, ikke ud fra værktøjsnavnet alene.
Platformsvilkår er særligt vigtige, fordi de bestemmer datalagring, modeltræning, adgang for administratorer, sikkerhedslogning, sletning og deling med underleverandører. OpenAIs privatlivspolitik er ét eksempel på, at indhold, kontroller og formål beskrives særskilt. En organisation bør læse den aktuelle aftale for det konkrete produkt, ikke antage at alle AI-tjenester behandler input ens.
Hvordan kan undervisere og teams arbejde praktisk med prompts?
Undervisere og teams kan arbejde med prompts som en faglig metode: først formulere opgaven, derefter teste flere variationer, sammenligne output og til sidst dokumentere, hvad der virkede. Det gør processen mere lærerig end blot at gemme en enkelt tekst, der gav et godt svar én gang.
I undervisning kan brugere lære at adskille mål, materiale og vurderingskriterier. I teams kan samme princip bruges til at forbedre arbejdsgange: en gruppe kan teste, hvilke inputfelter der giver mest pålidelige svar, hvilke data der skaber risiko, og hvor menneskelig kontrol er nødvendig. Det skaber både bedre output og bedre forståelse af modellens begrænsninger.
Den mest robuste praksis er at behandle prompts som versionerede arbejdskomponenter. Gem gode eksempler, men gem også fejl, undtagelser og kontrolnoter. På den måde kan prompts forbedres over tid og kobles til AI-sikkerhed mod jailbreaking, dataminimering og kvalitetskontrol.
Hvilke kilder ligger til grund?
Artiklen bygger især på NIST AI Risk Management Framework, OWASP Top 10 for LLM Applications 2025, OpenAIs europæiske privatlivspolitik, Googles dokumentation for Gemini API safety settings og EU’s AI-forordning 2024/1689.