En systeminstruks er den styrende besked, som en AI-model får før brugerens input. Den fastlægger rolle, tone, grænser og prioritering, så et værktøj kan svare mere ensartet, afvise uønskede handlinger og skelne mellem udviklerens regler og brugerens konkrete opgave.
En systeminstruks styrer, hvordan en AI-model skal opføre sig før den svarer på brugerens konkrete opgave. Du får overblik over instruktionshierarki, sikkerhedsgrænser, datakrav og praktiske testpunkter, så løsningen kan give mere stabile svar uden at skjule regler, rettigheder eller ansvar.
Hvad betyder en systeminstruks i en AI-samtale?
En systeminstruks er en del af den samlede kontekst, som en sprogmodel bruger til at danne sit svar. Den kan beskrive, hvem modellen skal agere som, hvilken opgave den skal understøtte, hvilke oplysninger den må bruge, og hvilken form svaret skal have.
Den ændrer ikke modellens træning. Den er en kørselsnær instruks, som påvirker den konkrete samtale eller den konkrete forespørgsel. Derfor kan den gøre en chatbot mere forudsigelig, men den gør ikke modellen fejlfri.
I praksis bruges den til at placere faste regler over brugerens besked. En kundeserviceassistent kan for eksempel få en systeminstruks om at svare kort, bruge et bestemt vidensgrundlag og sende usikre sager videre til et menneske. Brugeren kan stadig stille mange forskellige spørgsmål, men svarene bliver behandlet inden for den ramme.
Hvor ligger den i instruktionshierarkiet?
Moderne AI-systemer arbejder typisk med flere instruktionsniveauer. OpenAIs Model Spec beskriver et hierarki, hvor grundregler, systemniveau, udviklerinstrukser og brugerens beskeder ikke har samme autoritet. En lavere besked bør ikke kunne tilsidesætte en højere regel.
Det er grunden til, at en bruger normalt ikke bør kunne skrive en besked, der får systemet til at ignorere faste sikkerhedsregler, afsløre skjulte instrukser eller ændre produktets grundlæggende rolle. Hvis niveauerne blandes sammen, bliver svarene lettere at manipulere.
Hierarkiet er især relevant i applikationer, hvor en model både modtager brugerinput, dokumenter, værktøjsresultater og interne regler. Den styrende instruks skal gøre det klart, hvilke dele der er regler, og hvilke dele der kun er data, som skal behandles med skepsis.
Hvordan adskiller den sig fra brugerens besked?
Brugerens besked angiver den konkrete opgave: et spørgsmål, en kommando, en tekst der skal vurderes, eller et valg der skal forklares. Systeminstruksen angiver derimod arbejdsformen: hvordan opgaven skal behandles, hvilke grænser der gælder, og hvordan modellen skal håndtere konflikter.
| Element | Typisk formål | Eksempel på indhold |
|---|---|---|
| Systeminstruks | Fast ramme for adfærd, rolle og sikkerhed | Svar neutralt, brug kun godkendte kilder, og afvis handlinger uden for opgaven |
| Udviklerinstruks | Produktlogik og forretningsregler i en applikation | Returner et bestemt format, brug en bestemt database, eller følg en eskalationsregel |
| Brugerbesked | Den konkrete opgave i samtalen | Forklar et begreb, opsummer et dokument, eller find en fejl i et udkast |
Forskellen kan sammenlignes med en funktion i programmering. Den faste instruks beskriver, hvordan funktionen skal virke. Brugerens besked er de argumenter, funktionen skal anvende.
Hvilke opgaver bør den løse?
En god systeminstruks løser ikke alle problemer på én gang. Den bør først gøre modellens rolle klar. Skal systemet forklare, sortere, skrive, klassificere, kontrollere, stille opfølgende spørgsmål eller kalde værktøjer?
Derefter bør den angive de faste grænser. Det kan være krav til datakilder, sprog, format, tone, behandling af usikkerhed, privat information, opgaver uden for scope og situationer, hvor systemet skal stoppe eller bede om menneskelig vurdering.
- Rolle: hvad modellen er sat til at hjælpe med.
- Prioritet: hvilke regler der går forud for brugerens ønsker.
- Datagrænse: hvilke kilder, filer eller felter modellen må bruge.
- Outputkrav: format, længde, sprog og struktur.
- Afvisning og eskalation: hvornår modellen skal sige nej eller sende sagen videre.
Jo mere kritisk arbejdsgangen er, desto mere bør instruktionen beskrive kontrolpunkter frem for personlighed. Et system, der hjælper med interne dokumenter, har mere brug for kildekrav, rettighedsgrænser og usikkerhedshåndtering end for en lang beskrivelse af tone.
Hvor detaljeret bør den være?
Detaljegraden afhænger af risiko og opgave. En simpel skriveassistent kan ofte nøjes med få regler om sprog, målgruppe og format. En applikation, der bruger virksomhedsdata, eksterne værktøjer eller automatiske handlinger, bør have mere præcise instrukser.
En lang instruks er ikke automatisk bedre. Lange regelsæt kan skabe konflikter, gentagelser og uklar prioritering. Korte regler kan til gengæld blive for åbne, så modellen gætter på format, ansvar eller datagrundlag.
En praktisk metode er at skrive systeminstruksen som et sæt beslutningsregler. Først rollen, derefter datagrænser, derefter svarformat, derefter sikkerhed og til sidst konkrete eksempler på ønsket og uønsket adfærd. Eksempler hjælper især, når svaret skal have fast struktur.
Hvordan bruges den i en applikation?
I en API-baseret løsning ligger systeminstruksen normalt i applikationslaget, ikke i brugerfladen. Brugeren ser sin egen besked og modellens svar, men ikke nødvendigvis de faste regler, der styrer samtalen. Det gør instruktionen til en del af produktdesignet.
OpenAIs dokumentation for tekstgenerering beskriver, at high-level instructions kan sættes via en parameter og gennem beskedroller. Den dokumentation skelner også mellem udviklerens regler og brugerens input, hvor udviklerens regler prioriteres foran brugerens besked.
Det har en praktisk konsekvens: systeminstruksen bør versioneres, testes og gennemgås som anden produktlogik. Hvis en ændring påvirker en GPT-model i drift, kan den ændre svar, afvisninger, kildebrug og format i mange brugerforløb.
I nogle API-design gælder den styrende instruks kun for den aktuelle generering, hvis samtaletilstanden styres via tidligere svar-id’er. Derfor bør udviklere kontrollere, om faste regler faktisk sendes med i de relevante kald, og om de stadig gælder efter genoptagelse af en samtale.
Hvilke sikkerhedsgrænser kan den ikke løse alene?
En systeminstruks kan reducere risiko, men den er ikke en fuld sikkerhedsbarriere. En model kan møde skjulte instrukser i dokumenter, websider, e-mails eller værktøjsresultater. Hvis systemet behandler den slags data som autoritative regler, kan en angriber forsøge at styre modellens svar eller handlinger.
OWASP Top 10 for LLMs beskriver flere risikokategorier for generative AI-applikationer, herunder manipulerede instrukser, lækage af følsomme oplysninger, overdreven handlefrihed og misinformation. De risici kræver tekniske kontroller ved siden af den styrende instruks.
En robust løsning kombinerer instruktionen med adgangsstyring, værktøjsbegrænsninger, logning, outputkontrol, testdata og menneskelig godkendelse ved følsomme handlinger. En AI-model bør ikke kunne sende data, ændre systemer eller foretage bindende handlinger alene, bare fordi en bruger formulerer det overbevisende.
Det gælder især agentløsninger, hvor modellen kan kalde værktøjer. En sikkerhedsudfordring ved generativ AI er netop, at naturligt sprog både kan være data og instruktion. Systemdesignet skal hjælpe modellen med at holde de to ting adskilt.
Hvordan bør den håndtere data og kilder?
Systeminstruksen bør angive, hvilke kilder modellen må bruge, hvordan den skal markere usikkerhed, og hvad den skal gøre, når datagrundlaget ikke er nok. Hvis den ikke får disse regler, kan den udfylde huller med sandsynlige, men forkerte formuleringer.
En kildebaseret løsning kan for eksempel kræve, at modellen kun svarer ud fra vedlagte dokumenter eller bestemte databaser. Hvis svaret mangler grundlag, skal modellen sige det tydeligt i stedet for at opfinde en forklaring. Det mindsker risikoen for AI-hallucinationer, men fjerner den ikke.
Instruksen bør også undgå hemmeligheder. API-nøgler, interne adgangskoder, private kundedata og detaljer om sikkerhedskontroller hører ikke hjemme i en styrende tekst, som modellen behandler. Brug konfiguration, rettighedssystemer og serverlogik til den type oplysninger.
Hvad betyder den for virksomheder og offentlige arbejdspladser?
For organisationer i Danmark er systeminstruksen en del af styringen af AI-løsningen. Den påvirker, hvordan værktøjet svarer på dansk, hvilke datakilder det bruger, hvordan det markerer usikkerhed, og hvornår en sag skal sendes videre til en medarbejder.
Den bør derfor kobles til almindelig drift: ansvar, databehandleraftaler, adgangsrettigheder, logning, test og ændringsstyring. Hvis en afdeling bruger AI til HR, borgerservice, support eller analyse, bør faste instrukser ikke være en løs tekst, som kun én medarbejder kender.
AI-governance handler om de rammer, der bestemmer, hvem der må bruge AI, til hvilke formål, med hvilke data og under hvilken kontrol. En systeminstruks kan understøtte AI-governance, men den kan ikke erstatte beslutninger om ansvar, dokumentation og tilsyn.
Hvordan tester du om den virker?
Test bør dække mere end pæne standardsvar. Du skal kontrollere, om modellen følger instruktionen, når brugerens besked er uklar, modstridende, for lang, følelsesladet, skadelig eller uden for opgaven. Testen bør også dække dokumenter, der indeholder instrukser, som modellen ikke skal følge.
Et enkelt testforløb kan begynde med almindelige brugeropgaver og derefter tilføje modspørgsmål, formatkrav, konflikter og forsøg på at få systemet til at afsløre eller ignorere faste regler. Resultaterne bør vurderes efter konkrete kriterier, ikke efter om svaret virker venligt.
- Skriv fem normale opgaver, som systemet skal løse.
- Skriv fem opgaver, der ligger uden for systemets formål.
- Tilføj eksempler med usikre eller manglende data.
- Tilføj eksterne tekststykker, der forsøger at give modellen nye regler.
- Kontrollér, om svarene følger rolle, datagrænse, format og afvisningsregler.
Testen bør gentages, når modellen, værktøjerne, datakilderne eller systeminstruksen ændres. Små ændringer kan ændre svarmønstre, især hvis flere regler peger i forskellige retninger.
Hvilke fejl giver ustabile svar?
Den mest almindelige fejl er at blande mål, tone, sikkerhed og format i en lang, uordnet tekst. Modellen får da mange signaler, men ingen klar prioritering. Resultatet kan være svar, der skifter mellem at være hjælpsomme, forsigtige, lange, korte eller uventet afvisende.
En anden fejl er at skrive regler, der afhænger af ord som “altid” og “aldrig”, uden at beskrive undtagelser. Hvis systemet både skal besvare alle spørgsmål og samtidig aldrig gætte, opstår der konflikt, når data mangler.
En tredje fejl er at lægge for meget ansvar på modellen. Hvis et værktøj kun må vise oplysninger, som brugeren har adgang til, skal adgangen kontrolleres teknisk. Systeminstruksen kan sige, at modellen skal respektere rettigheder, men den bør ikke være den eneste kontrol.
Hvordan hænger den sammen med andre AI-begreber?
Systeminstruksen er beslægtet med kontekst, finjustering, retrieval, værktøjsbrug og evaluering, men den er ikke det samme. Kontekst er de oplysninger, modellen ser i den aktuelle forespørgsel. Finjustering ændrer modellens vægte gennem træning. Retrieval henter relevante dokumenter ind i samtalen. Evaluering måler, om løsningen virker.
Den styrende instruks ligger mellem produktdesign og modelkald. Den fortæller modellen, hvordan de øvrige dele skal behandles. Hvis retrieval henter et dokument, kan instruktionen for eksempel sige, at dokumentet er datagrundlag, ikke en regelbog.
Det gør begrebet centralt i praktisk AI-udvikling. En velformuleret instruks kan forbedre konsistens, men gode resultater kræver også relevante data, korrekt modelvalg, test, brugeroplevelse og sikkerhedslag uden for modellen.
Hvilke kilder ligger til grund?
Artiklen bygger især på OpenAIs Model Spec, OpenAIs dokumentation for tekstgenerering og OWASP Top 10 for LLMs. Kilderne er brugt til at kontrollere rollehierarki, instruktionsniveauer, API-adfærd og sikkerhedsrisici i generative AI-applikationer.