Hvordan kan en virksomhed som Trafikstyrelsen "styre" sine prompts og andre AI-ting?

 Jeg fik lavet en rapport i ChatGPT om, hvordan en virksomhed kunne organisere sine prompts, GPT'er og Projekter i ChatGPT, og her er resultatet. Der er en masse gode idéer, som jeg tror kan tjene til inspiration for mange.

Mvh Mogens

Organisering og styring af standardprompts i Trafikstyrelsen

Samlet konklusion

Ja, der findes en hel branche af værktøjer til at oprette, organisere, versionsstyre, teste og distribuere prompts.

Men Trafikstyrelsen bør efter min vurdering ikke begynde med at købe et særskilt promptbibliotek. I har allerede en stor ChatGPT Enterprise-installation, og en væsentlig del af behovet kan løses med:

1. Et centralt katalog over godkendte AI-arbejdsgange.

2. Delte, afdelingsspecifikke GPT’er i ChatGPT.

3. Faste ejere, versionsstyring og testeksempler.

4. En egentlig API-løsning til de få arbejdsgange, hvor høj ensartethed og dokumentation er afgørende.

Den vigtigste sondring er denne:

En prompt er tekst, som medarbejderen selv indsætter. En konfigureret GPT er en standardiseret arbejdsmetode, hvor instruktioner, hjælpetekster, dokumenter og værktøjer ligger fast bag brugerens spørgsmål.

Til de vigtigste tilbagevendende opgaver bør I derfor ikke alene dele tekstprompts. I bør gøre dem til interne GPT’er eller kontrollerede arbejdsprocesser.

---

1. Hukommelsesproblemet er reelt – men kan i vidt omfang løses

I en almindelig ChatGPT-samtale kan svaret være påvirket af:

• brugerens gemte memories,

• tidligere samtaler,

• brugerens personlige instruktioner,

• den igangværende chats historik,

• valget af model og ræsonneringsniveau,

• vedhæftede filer og aktiverede værktøjer.

OpenAI oplyser, at memories er individuelle og ikke deles mellem medlemmer af et arbejdsområde. Workspace-ejeren kan slå memory fra for hele arbejdsområdet, men så slettes de eksisterende memories i arbejdsområdet.

Det er efter min vurdering ikke nødvendigt at slå memory fra for alle 500–600 brugere blot for at standardisere nogle arbejdsgange.

Den oplagte løsning: interne GPT’er

En GPT kan indeholde:

• faste instruktioner,

• samtalestartere,

• referencefiler,

• valgte funktioner og værktøjer,

• apps eller handlinger mod eksterne systemer.

Det særligt interessante er, at OpenAI udtrykkeligt oplyser:

GPT’er anvender ikke brugerens gemte memory, personlige instruktioner eller tidligere samtaler. Hver samtale starter forfra.

Det betyder, at en jurist i Luftfart og en administrativ medarbejder i en anden enhed kan åbne den samme interne GPT med de samme dokumenter og instruktioner uden at tage deres personlige ChatGPT-historik med ind.

En vigtig undtagelse

På web kan man nævne en GPT med @ midt i en eksisterende almindelig samtale. I så fald bevares konteksten fra den eksisterende samtale.

Hvis ensartethed er vigtig, bør instruktionen derfor være:

Åbn altid den godkendte GPT i en ny samtale. Indkald den ikke med @ i en gammel samtale.

---

2. Samme GPT betyder ikke fuldstændig identiske svar

Selv med samme GPT, samme dokument og samme spørgsmål kan to svar være lidt forskellige.

Sprogmodeller er ikke almindelige deterministiske programmer. De kan vælge forskellige formuleringer, eksempler og argumentationsrækkefølger. Derudover bliver modeller i ChatGPT løbende opdateret. Hvis en model, som en GPT er konfigureret til, udgår, kan GPT’en automatisk blive flyttet til en tilsvarende aktuel model.

Det realistiske mål bør derfor være:

• samme opgaveforståelse,

• samme faktuelle grundlag,

• samme obligatoriske afsnit,

• samme juridiske eller faglige kriterier,

• samme outputformat,

• nogenlunde samme detaljeringsniveau,

• samme krav til kildehenvisninger og usikkerhed.

Det er mindre realistisk at kræve ordret samme svar.

Hvis et output skal kunne indlæses automatisk i et fagsystem, kan en API-løsning anvende Structured Outputs, som tvinger svaret til at følge et bestemt JSON-skema.

---

3. Fire forskellige former for »promptbibliotek«

Niveau 1: Et almindeligt katalog over prompts

Dette kan bygges i eksempelvis:

• SharePoint,

• Confluence,

• en SharePoint List,

• et dokumentbibliotek,

• en simpel intern webside.

Kataloget bruges til at finde, læse og kopiere prompts.

Det er billigt og overskueligt, men har klare begrænsninger:

• Brugeren kan ændre prompten.

• Brugeren kan indsætte den i en gammel samtale.

• Brugerens memory og personlige instruktioner kan påvirke svaret.

• Der er ingen egentlig kontrol med model eller output.

• Det er svært at vide, om prompten fortsat virker efter modelændringer.

Denne form er glimrende til inspiration og lavrisikoopgaver, men ikke til standardiserede fagprocesser.

Niveau 2: En intern GPT

Her gemmes den centrale instruktion inde i GPT’en. Brugeren ser typisk kun en kort beskrivelse og nogle samtalestartere.

Eksempel:

Navn: Høringssvar – første analyse
Beskrivelse: Analyserer et høringssvar efter Trafikstyrelsens fælles metode.
Samtalestarter: Vedhæft høringssvaret og skriv, hvilket regelområde det vedrører.

GPT’en kan derefter have skjulte instruktioner om:

• hvilke punkter der altid skal undersøges,

• hvordan argumenter skal kategoriseres,

• hvordan tvivl skal markeres,

• hvilket format svaret skal have,

• at modellen aldrig må opfinde lovhenvisninger,

• at vurderinger skal holdes adskilt fra dokumenterede oplysninger.

Interne GPT’er kan deles med bestemte medarbejdere, grupper eller arbejdsområdet. Enterprise-administratorer kan styre, hvem der må oprette og redigere GPT’er, hvilke delingsformer der er tilladt, og om tredjeparts-GPT’er må anvendes.

GPT’er har desuden versionshistorik, så en tidligere version kan gendannes.

Dette bør efter min vurdering være Trafikstyrelsens primære mekanisme til standardiserede medarbejderopgaver.

Niveau 3: Et delt projekt

Et delt ChatGPT-projekt kan indeholde:

• projektinstruktioner,

• fælles filer,

• fælles samtaler,

• løbende kontekst fra teamets arbejde.

Når et projekt deles, får det automatisk project-only memory. Det kan ikke se deltagernes individuelle memories, personlige instruktioner eller samtaler uden for projektet.

Men projektet kan anvende andre samtaler inde i projektet. Derfor vil konteksten udvikle sig, efterhånden som gruppen arbejder i det.

Et delt projekt er derfor godt til:

• et konkret projektforløb,

• en fælles analyse,

• en arbejdsgruppe,

• onboarding,

• opsamling af erfaringer,

• fælles dokumentarbejde.

Det er mindre egnet som en uforanderlig standardproces. OpenAI beskriver selv GPT’er som statisk, ekspertkurateret indhold til genbrug på tværs af organisationen, mens delte projekter er levende kontekstrum, der udvikler sig gennem deltagernes bidrag.

Niveau 4: En kontrolleret API-applikation

Ved særligt vigtige arbejdsgange kan Trafikstyrelsen bygge en formular eller en app, hvor medarbejderen udfylder bestemte felter.

Eksempel:

Dokumenttype:           Høringssvar
Regelområde:            Luftfart
Afsender:               [felt]
Dokument:                [upload]
Ønsket detaljeringsgrad: Kort / normal / grundig

Bagved ligger:

• en fast systeminstruktion,

• en bestemt modelversion,

• faste parametre,

• et fast outputskema,

• logning,

• adgangskontrol,

• automatiske tests.

OpenAIs API har såkaldte modelsnapshots, som kan låse en bestemt modelversion for at bevare mere ensartet adfærd.

Det bør bruges til arbejdsgange, hvor resultatet:

• får betydning for myndighedsafgørelser,

• sendes direkte til borgere eller virksomheder,

• overføres til andre systemer,

• indeholder faste klassifikationer,

• skal kunne auditeres,

• anvendes i stort antal.

---

4. Hvilke eksterne værktøjer findes?

Markedet kan opdeles i to hovedgrupper.

A. Værktøjer til medarbejdere og teams

Eksempler er:

• PromptDrive,

• Team-GPT,

• TeamPrompt,

• AIPRM,

• forskellige browserudvidelser og promptdatabaser.

PromptDrive markedsføres eksempelvis som et fælles arbejdsområde, hvor teams kan organisere og dele prompts til blandt andet ChatGPT, Claude og Gemini.

Team-GPT har et katalog med kategoriserede prompts, og TeamAI tilbyder et centralt bibliotek med både indbyggede og organisationsoprettede prompts.

Disse værktøjer kan være udmærkede, men de indebærer typisk, at:

• endnu en leverandør får adgang til prompts eller brugerdata,

• medarbejderne skal anvende endnu en brugerflade,

• der skal foretages sikkerheds-, GDPR- og leverandørvurdering,

• løsningen skal integreres med organisationens identitetsstyring,

• der kan opstå uklarhed om, hvor den officielle prompt befinder sig.

For en statslig styrelse med ChatGPT Enterprise ville jeg ikke vælge en browserudvidelse som den primære løsning.

B. Professionelle prompt management- og LLMOps-platforme

Her findes blandt andet:

• LangSmith,

• PromptLayer,

• Humanloop,

• Vellum,

• Braintrust,

• Portkey.

De er primært rettet mod organisationer, som selv bygger AI-applikationer gennem API’er.

De kan blandt andet tilbyde:

• promptskabeloner med variable,

• versionshistorik,

• udviklings-, test- og produktionsversioner,

• sammenligning af versioner,

• automatiske evalueringer,

• testdatasæt,

• godkendelsesforløb,

• logning og overvågning,

• A/B-test,

• rollback.

LangSmith understøtter oprettelse, versionsstyring, test og samarbejde om prompts og anvender tags som stabile henvisninger til bestemte versioner.

PromptLayer har promptregister, versionshistorik, release labels, evalueringsfunktioner og mulighed for godkendelse af produktionsversioner.

Humanloop og Vellum kombinerer ligeledes versionsstyring med testdatasæt og evaluering af forskellige promptversioner.

Disse produkter er relevante, når Trafikstyrelsen begynder at udvikle egentlige API-baserede AI-løsninger. De er sandsynligvis for tunge som første løsning på spørgsmålet »Hvordan deler vi gode prompts med medarbejderne?«.

---

5. Den model jeg vil anbefale Trafikstyrelsen

Tre kategorier i stedet for ét stort bibliotek

Kategori A – Inspiration

Almindelige, redigerbare prompts til lavrisikoopgaver:

• forbedring af tekst,

• ideudvikling,

• mødeforberedelse,

• forslag til disposition,

• forklaring af fagstof,

• generering af spørgsmål.

De kan ligge i et almindeligt søgbart promptkatalog.

Kategori B – Godkendte arbejdsmetoder

Interne GPT’er til tilbagevendende opgaver:

• referater efter en bestemt struktur,

• første analyse af høringssvar,

• klarsprogsrevision,

• kontrol af et dokument mod en tjekliste,

• udarbejdelse af procesbeskrivelser,

• analyse af interviewtransskriptioner,

• klassifikation af henvendelser,

• forberedelse af sagsoversigter.

Her bør brugeren ikke selv kopiere den centrale prompt. Brugeren åbner den officielle GPT.

Kategori C – Kontrollerede AI-processer

API-løsninger til opgaver, hvor format, logning og korrekthed er kritiske:

• struktureret dataudtræk,

• massebehandling,

• automatiske klassifikationer,

• udfyldelse af faste skemaer,

• integration til fagsystem,

• afgørelsesnære processer.

---

6. Forslag til organisering

Central funktion

En mindre central AI-funktion bør:

• fastlægge standardskabelonen,

• administrere ChatGPT-workspace-indstillinger,

• godkende organisationsdækkende GPT’er,

• drive kataloget,

• definere risikoniveauer,

• følge brug og fejl,

• koordinere test efter større modelændringer.

ChatGPT Enterprise-administratorer kan allerede styre modeladgang, GPT-oprettelse og -deling, projekter, memory, apps og andre funktioner gennem workspace-indstillinger og rollebaseret adgangskontrol.

Decentrale promptansvarlige

Hver afdeling eller hvert større fagområde bør have én eller to promptansvarlige, som:

• indsamler gode anvendelser,

• beskriver den faglige metode,

• udarbejder testeksempler,

• modtager feedback,

• foreslår ændringer,

• sikrer, at indholdet fortsat er fagligt korrekt.

Det er afgørende, at den faglige ejer ikke nødvendigvis er den tekniske GPT-bygger.

Eksempel:

Rolle	Ansvar
Faglig ejer	Bestemmer metode, fagligt indhold og acceptkriterier
GPT-redaktør	Omsætter metoden til instruktioner og eksempler
Tester	Afprøver på realistiske og vanskelige sager
Godkender	Godkender publicering og væsentlige ændringer
Workspace-admin	Styrer adgang, ejerskab og deling

---

7. Hvad skal registreres om hver prompt eller GPT?

En prompt bør ikke blot bestå af selve teksten.

Jeg foreslår følgende promptkort:

Identifikation

• Prompt-ID

• Titel

• Afdeling og team

• Faglig ejer

• GPT-redaktør

• Status

• Versionsnummer

• Dato for seneste godkendelse

• Næste revisionsdato

Formål

• Hvilken opgave løses?

• Hvem må anvende den?

• Hvad må resultatet bruges til?

• Hvad må det ikke bruges til?

Input

• Hvilke oplysninger skal brugeren levere?

• Hvilke filer kan eller skal vedhæftes?

• Hvilke oplysninger må ikke indtastes?

• Hvilke forudsætninger gælder?

Output

• Obligatoriske afsnit

• Format

• Længde

• Sprog og tone

• Krav om kildehenvisninger

• Krav om markering af usikkerhed

• Krav om menneskelig kontrol

Teknisk konfiguration

• GPT eller almindelig prompt

• Tilladte modeller

• Tilladte værktøjer

• Websøgning til eller fra

• Referencefiler

• Apps eller handlinger

• Eventuelle adgangsgrupper

Kvalitet

• Testcases

• Forventede egenskaber ved svaret

• Kendte svagheder

• Fejlscenarier

• Minimumskrav for godkendelse

• Kontaktpunkt for fejl og forslag

---

8. En god standardskabelon til selve instruktionen

Prompts bør skrives som små specifikationer – ikke som litterære trylleformularer.

FORMÅL
Du skal hjælpe medarbejdere med at ...

ANVENDELSESOMRÅDE
Opgaven omfatter ...
Opgaven omfatter ikke ...

INPUT
Brugeren skal levere:
1. ...
2. ...
3. ...

ARBEJDSGANG
1. Identificér ...
2. Kontrollér ...
3. Sammenhold ...
4. Markér oplysninger, der mangler.
5. Udarbejd resultatet.

FAGLIGE REGLER
- Anvend følgende definition ...
- Skeln mellem ...
- Foretag ikke ...
- Gæt aldrig på ...

OUTPUTFORMAT
Returnér:
1. Kort konklusion
2. Faktuelle oplysninger
3. Vurdering
4. Usikkerheder
5. Forslag til næste skridt

KILDER OG DOKUMENTATION
Henvis til dokument, side eller afsnit for alle centrale oplysninger.

KVALITETSKONTROL
Kontrollér inden aflevering:
- at alle obligatoriske punkter er dækket,
- at vurderinger er adskilt fra fakta,
- at ingen manglende oplysninger er opfundet,
- at konklusionen kan føres tilbage til kilderne.

HÅNDTERING AF MANGLER
Hvis nødvendige oplysninger mangler, skal du tydeligt beskrive, hvad der mangler,
i stedet for at udfylde hullerne selv.

OpenAI anbefaler tilsvarende, at instruktioner til GPT’er opdeles i tydelige trin, at positive og konkrete instruktioner foretrækkes, og at eksempler anvendes ved særlige definitioner eller klassifikationer.

---

9. Test er vigtigere end formuleringens elegance

En prompt er ikke god, fordi tre erfarne medarbejdere synes, den ser fornuftig ud.

Den er god, hvis den fungerer på et repræsentativt udvalg af virkelige opgaver.

For hver vigtig GPT bør der opbygges et lille testdatasæt med eksempelvis:

• fem almindelige sager,

• tre vanskelige sager,

• to sager med manglende oplysninger,

• to sager med modstridende oplysninger,

• en sag, der ligger uden for anvendelsesområdet,

• en sag, hvor modellen bør afvise at konkludere.

For hvert eksempel beskrives ikke nødvendigvis et ordret facit, men kriterier som:

• Har den fundet alle centrale oplysninger?

• Har den undladt at opfinde noget?

• Er fakta og vurderinger adskilt?

• Følger den den krævede struktur?

• Er usikkerhed markeret?

• Er svaret fagligt anvendeligt?

• Er kilderne korrekte?

OpenAI anbefaler at have repræsentative testeksempler, tests og evalueringer, før produktionsprompts ændres.

Promptfølsomhed er veldokumenteret. Et ICLR-studie viste meget store præstationsforskelle mellem betydningsmæssigt ens prompts med forskellige formater i de undersøgte modeller. Resultatet kan ikke direkte overføres til alle aktuelle ChatGPT-modeller, men det illustrerer, hvorfor prompts skal testes og ikke blot diskuteres sprogligt.

---

10. Livscyklus for en Trafikstyrelsen-prompt

Jeg foreslår følgende statusser:

Idé
  ↓
Udkast
  ↓
Fagligt testet
  ↓
Pilot
  ↓
Godkendt
  ↓
Under revision
  ↓
Udfaset
  ↓
Arkiveret

En ændring bør altid medføre:

• nyt versionsnummer,

• kort ændringsbeskrivelse,

• genkørsel af relevante testcases,

• godkendelse fra den faglige ejer,

• publiceringsdato,

• mulighed for rollback.

GPT’ernes indbyggede versionshistorik kan bruges til selve konfigurationen, men kataloget bør stadig indeholde den faglige begrundelse for ændringen.

---

11. Hvad bør I måle?

Et promptbibliotek bør ikke måles på, hvor mange prompts det indeholder.

Mere relevante mål er:

• antal aktive brugere pr. GPT,

• gentagen anvendelse,

• andel af svar, der kan anvendes uden større omskrivning,

• rapporterede fejl,

• tidsbesparelse,

• antal arbejdsgange med dokumenterede testcases,

• antal forældede prompts,

• svartid på fejlmeldinger,

• medarbejdernes oplevelse af faglig nytte.

Workspace Analytics i ChatGPT Enterprise kan blandt andet vise GPT-brug og overordnede anvendelsesmønstre.

---

12. Den relevante litteratur

Praktisk prompting

The Prompt Report: A Systematic Survey of Prompting Techniques

En omfattende kortlægning med en fælles terminologi og en taksonomi over 58 tekstbaserede promptingteknikker. Den er velegnet som opslagsværk, men ikke som en færdig organisationsmodel.

A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT

Behandler prompts som genanvendelige mønstre, omtrent som design patterns i softwareudvikling. Den tankegang er særdeles relevant for et organisatorisk promptkatalog: Man bør registrere problemet, konteksten, løsningen og kendte konsekvenser – ikke blot promptteksten.

OpenAIs vejledninger om GPT-instruktioner og prompting

De officielle vejledninger er naturligvis produktspecifikke, men bør være den primære tekniske reference, når Trafikstyrelsen bygger GPT’er i ChatGPT.

Mennesker og organisatorisk anvendelse

Why Johnny Can’t Prompt

Et CHI-studie af ikke-eksperters vanskeligheder ved at udvikle prompts. Studiet understøtter, at man ikke bør overlade det til hver enkelt medarbejder at genopfinde komplicerede arbejdsinstruktioner.

Quantifying Language Models’ Sensitivity to Spurious Features in Prompt Design

Viser, at selv tilsyneladende uvæsentlige formateringsændringer kan ændre modellers resultater. Det understøtter behovet for versionsstyring og regressionstest.

Governance

NIST AI Risk Management Framework og GenAI Profile

Disse dokumenter handler ikke specifikt om promptbiblioteker, men giver en stærk ramme for organisering efter funktionerne:

• Govern

• Map

• Measure

• Manage

NIST lægger vægt på styring gennem hele AI-livscyklussen, dokumentation, test, evaluering og løbende risikohåndtering.

---

13. Et konkret forslag til Trafikstyrelsen

Fase 1: Fælles katalog

Opret et simpelt katalog i SharePoint eller Confluence med promptkort, søgning, afdeling, fagområde, ejer og status.

Indsaml ikke straks alle prompts, som nogen har skrevet. Start med tilbagevendende opgaver, som:

• udføres af flere medarbejdere,

• tager mærkbar tid,

• har en nogenlunde fast metode,

• har et output, man kan kvalitetsbedømme.

Fase 2: Ti interne GPT’er

Udvælg eksempelvis ti tværgående eller afdelingsspecifikke arbejdsgange og byg dem som interne GPT’er.

Hver GPT skal:

• have en faglig ejer,

• starte i ny chat,

• ignorere personlig memory og instruktioner,

• have faste outputkrav,

• være testet på virkelige eksempler,

• have versionsnummer og revisionsdato,

• have en tydelig feedbackvej.

Fase 3: Promptnetværk

Udpeg promptansvarlige i afdelingerne og hold et kort månedligt møde, hvor man:

• demonstrerer nye arbejdsgange,

• gennemgår fejl,

• deler testmetoder,

• samler overlappende GPT’er,

• beslutter, hvad der skal udfases.

Fase 4: Kontrollerede løsninger

Flyt de mest værdifulde og risikofyldte arbejdsgange fra almindelige GPT’er til API-løsninger med:

• faste inputfelter,

• strukturerede outputs,

• modelsnapshot,

• logning,

• adgangsstyring,

• automatiske evalueringer.

---

Min endelige anbefaling

Trafikstyrelsen bør ikke etablere en stor digital reol med hundredvis af prompts, som medarbejderne kopierer ind i vilkårlige chats.

I bør etablere et katalog over AI-arbejdsgange:

Kataloget fortæller, hvad der findes.
GPT’en udfører den standardiserede arbejdsmetode.
Testpakken viser, om den fortsat virker.
Ejeren har ansvaret for fagligheden.
Versionshistorikken viser, hvad der er ændret.
API-løsningen overtager, når der kræves egentlig proceskontrol.

Den særligt gode nyhed i forhold til dit spørgsmål om memory er:

En korrekt bygget intern GPT, som åbnes i en ny samtale, tager ikke den enkelte medarbejders memory, personlige instruktioner eller tidligere samtaler med sig.

Det gør interne GPT’er til et langt bedre udgangspunkt end at sende den samme lange prompt rundt som tekst.