ChatGPT tilpasses en virksomhed ved at kombinere klare arbejdsinstruktioner, sikre datagrænser, interne referencefiler, adgangsstyring og løbende test. Den praktiske opgave er at vælge det laveste tilpasningsniveau, der løser behovet: brugerregler, en custom GPT, et datagrundet chatbotmiljø, API-integration eller egentlig modeloptimering.
ChatGPT bør tilpasses med klare opgavegrænser, sikre dataregler og løbende test, før virksomheden bygger tungere integrationer. Virksomheden får overblik over custom GPTs, interne referencefiler, egne data, systemkoblinger, modeloptimering og de governance-spørgsmål, som skal afklares før bred brug.
Hvordan bør en virksomhed begynde tilpasningen?
Tilpasning bør begynde med en konkret arbejdsopgave, ikke med et ønske om at gøre ChatGPT mere generel. En god start er at vælge en tilbagevendende opgave, hvor kvaliteten kan vurderes: kundesvar, intern videnssøgning, referater, udkast til produkttekster, kodehjælp, datafortolkning eller support til medarbejdere.
Beskriv derefter, hvem der skal bruge løsningen, hvilke oplysninger den må arbejde med, og hvilket resultat der er acceptabelt. En tilpasset ChatGPT-løsning er ikke kun et sprogligt lag. Den består af regler, datagrænser, adgang, testeksempler og en plan for, hvem der retter den, når arbejdsprocessen ændrer sig.
Den mest robuste rækkefølge er at starte smalt. Først afprøves faste instruktioner og eksempler. Derefter kan virksomheden tilføje referencefiler, bygge en custom GPT, koble til interne systemer eller udvikle en løsning med API. Kun når disse muligheder ikke er nok, giver egentlig modeloptimering mening.
Hvilke tilpasningsniveauer findes i ChatGPT?
ChatGPT kan tilpasses på flere niveauer. Niveauerne løser forskellige problemer, og de bør ikke blandes sammen. En intern skriveregel hjælper med tone og struktur. En custom GPT hjælper med en fast rolle, udvalgte referencefiler og bestemte funktioner. En chatbot med egne data hjælper, når svar skal forankres i et kontrolleret vidensgrundlag. En API-løsning hjælper, når ChatGPT skal indgå i et produkt, en portal eller en automatiseret arbejdsgang.
| Niveau | Hvad tilpasses? | Hvornår er det relevant? |
|---|---|---|
| Faste brugerregler | Tone, format, afgrænsninger og eksempler | Når medarbejdere skal arbejde mere ensartet i samme type opgaver |
| Custom GPT | Instruktioner, referencefiler, funktioner og deling | Når et team har brug for en fælles assistent til en defineret opgave |
| Chatbot med egne data | Søgning i kontrollerede dokumenter, svarafgrænsning og kildebrug | Når svar skal bygge på virksomhedens egne materialer |
| API-integration | Systemflow, adgang, datafelter, logning og brugergrænseflade | Når AI skal indgå i et produkt eller en intern applikation |
| Modeloptimering | Modeladfærd baseret på trænings- eller evalueringsdata | Når opgaven kræver meget stabil adfærd på et veldefineret datasæt |
Hvornår er en custom GPT nok?
En custom GPT er ofte nok, når virksomheden har en afgrænset opgave, et begrænset sæt regler og et mindre vidensgrundlag, som kan holdes ajour. OpenAI beskriver GPT-editoren som et sted, hvor man kan konfigurere navn, beskrivelse, instruktioner, referencefiler, funktioner, apps, actions, test og versionering. Den type tilpasning passer især til teamopgaver, hvor brugerne skal have samme udgangspunkt hver gang.
Eksempler kan være en intern assistent til at omskrive tekniske tekster til kundesprog, en hjælper til at kontrollere supportudkast mod en toneguide eller et værktøj til at finde relevante afsnit i håndbøger. En custom GPT bør have et smalt formål, klare grænser og eksempler på både gode og uacceptable svar.
En custom GPT er derimod ikke en fuld erstatning for et fagsystem. Hvis den skal hente live-data, ændre ordrer, oprette sager, skrive i CRM eller udløse en handling i et eksternt system, kræver det en kontrolleret integration. Hvis den skal svare på store, hyppigt ændrede dokumentmængder, kan et egentligt søge- og retrieval-setup være mere egnet.
Hvordan bruges interne referencefiler sikkert?
Referencefiler kan gøre ChatGPT mere relevant, fordi modellen får adgang til virksomhedsinterne beskrivelser, retningslinjer, produktark eller procesdokumenter. OpenAI angiver for GPT-knowledge, at der kan vedhæftes op til 20 filer, hver op til 512 MB, men filstørrelse er ikke det samme som anvendelighed. Klare, teksttunge dokumenter fungerer bedre end komplekse layoutfiler, lange præsentationer eller blandede bilag.
Filer bør behandles som et kontrolleret vidensgrundlag. Slet forældede versioner, fjern følsomme oplysninger, og skriv tydeligt, hvornår filen gælder. Hvis et dokument både indeholder regler, eksempler og historiske noter, bør virksomheden dele det op, så ChatGPT ikke forveksler baggrundsmateriale med gældende procedure.
Interne data bør ikke uploades ukritisk. En artikel om sikkerhed og privatliv i ChatGPT er relevant, fordi tilpasning ofte flytter problemet fra selve modellen til datahåndteringen: hvem må lægge filer ind, hvem kan se svarene, hvor længe gemmes indholdet, og hvilke oplysninger må aldrig indgå?
Hvornår bør ChatGPT forbindes til andre systemer?
Systemkoblinger giver mening, når ChatGPT ikke kun skal formulere svar, men også hente oplysninger, kontrollere status eller starte en handling. OpenAI beskriver capabilities, apps og actions som muligheder, der kan udvide en GPT med blandt andet webinformation, dataanalyse, eksterne tjenester og API-kald. Tilgængeligheden afhænger dog af konto, workspace, region og de tilladelser, som organisationen har sat.
Før en integration bygges, bør virksomheden skelne mellem tre typer adgang:
- Læseadgang, hvor ChatGPT kun henter information fra et system.
- Forslagsadgang, hvor ChatGPT udarbejder et udkast, som et menneske godkender.
- Handlingsadgang, hvor ChatGPT kan oprette, ændre eller sende noget i et andet system.
Handlingsadgang kræver de stærkeste kontroller. Der bør være brugerbekræftelse, logning, klare fejlbeskeder og mulighed for at stoppe handlinger. En GPT, der kan hente produktdata, er en anden risikotype end en GPT, der kan sende en kundemail eller oprette en refusion.
Hvordan adskiller ChatGPT-tilpasning sig fra en AI-chatbot med egne data?
En tilpasset ChatGPT og en chatbot med egne data kan ligne hinanden for brugeren, men de løser ikke helt samme problem. ChatGPT-tilpasning handler ofte om adfærd: tone, format, rolle, opgavegrænser og bestemte arbejdsrutiner. En chatbot med egne data handler mere om svargrundlag: den skal finde relevante oplysninger i et kontrolleret datalager og bruge dem i svaret.
Hvis virksomheden har mange dokumenter, som ofte ændrer sig, er retrieval augmented generation ofte mere realistisk end at lægge alt ind som statiske filer. Retrieval augmented generation betyder, at systemet først søger efter relevante tekststykker og derefter bruger dem som grundlag for svaret. Det gør det lettere at opdatere vidensgrundlaget uden at ændre selve modellen.
En AI-chatbot med egne data bør derfor vurderes på søgekvalitet, adgangsstyring, kildevisning og fejlretning. En custom GPT bør vurderes på, om den følger instruktioner, bruger de rigtige referencefiler og svarer i et format, som passer til opgaven.
Hvornår giver modeloptimering mening?
Modeloptimering giver mening, når problemet ikke kan løses tilfredsstillende med bedre instruktioner, bedre eksempler, retrieval eller en klarere arbejdsgang. OpenAIs API-dokumentation beskriver modeloptimering som et område med evaluerings- og finjusteringsarbejde, hvor udviklere må måle og justere kvalitet, fordi store sprogmodeller ikke er deterministiske, og modeladfærd kan ændre sig mellem modelversioner.
I praksis bør modeloptimering kun vælges, når virksomheden kan opstille et tydeligt evalueringssæt. Det kan være hundredevis eller tusindvis af eksempler på ønsket output, kendte fejltyper og målbare kriterier. Uden et evalueringssæt bliver modeloptimering let en dyrere måde at skjule et uklart problem på.
Modeloptimering bør heller ikke forveksles med personliggørelse. Hvis ønsket er bestemt tone, faste svarafsnit eller genbrug af interne regler, er en custom GPT eller en API-løsning med klare instruktioner ofte mere overskuelig. Hvis ønsket er stabil klassifikation, specialiseret fagsprog eller meget ensartet output i en produktionsproces, kan modeloptimering være relevant.
Hvilke datagrænser bør fastlægges?
Datagrænser bør fastlægges før løsningen deles bredt. OpenAI skriver i sin enterprise privacy-dokumentation, at business data som udgangspunkt ikke bruges til modeltræning, og at organisationer ejer og kontrollerer deres input og output, hvor loven tillader det. Det ændrer dog ikke behovet for interne regler. En leverandørs standardvilkår fjerner ikke automatisk virksomhedens ansvar for dataklassifikation, adgang og brug af fortrolige oplysninger.
En praktisk datagrænse kan opdeles i fire felter:
- Grønne data, som må bruges frit i løsningen.
- Gule data, som må bruges efter anonymisering eller godkendelse.
- Røde data, som aldrig må lægges i ChatGPT eller referencefiler.
- Logdata, som kun må gemmes med et tydeligt formål og en fast slettefrist.
For ChatGPT Business og Enterprise beskriver OpenAI også admin-kontrol med workspace, adgang, interne kilder og retention. Det bør oversættes til konkrete driftsregler: hvem må oprette GPTs, hvem må dele dem, hvilke apps må aktiveres, og hvem kontrollerer, at datagrænserne stadig følges?
Hvordan testes kvaliteten før bred brug?
Test bør ske med realistiske opgaver, ikke kun med pæne demoforespørgsler. Vælg eksempler fra den faktiske arbejdsdag: uklare kundehenvendelser, korte interne noter, lange dokumenter, fejlbehæftede data, modstridende krav og sager, hvor svaret bør være “jeg har ikke nok grundlag”. En god test viser både, hvad ChatGPT kan, og hvor menneskelig kontrol stadig er nødvendig.
Testen bør vurdere mindst fem forhold:
- Følger løsningen de aftalte instruktioner og svarformater?
- Bruger den kun de datakilder, den må bruge?
- Markerer den usikkerhed, når dokumentationen ikke rækker?
- Bevarer den faglige kvalitet på dansk fagsprog og interne begreber?
- Kan en medarbejder se, hvorfor et svar bør godkendes, rettes eller afvises?
Test bør gentages, når referencefiler skiftes, når en integration ændres, eller når OpenAI ændrer modeludvalg. En tilpasset løsning er ikke færdig, fordi den virker i den første samtale. Den er først klar, når den kan fejle på en kontrollerbar måde.
Hvad betyder tilpasning for organisationer i Danmark?
For organisationer i Danmark er tilpasning af ChatGPT især et spørgsmål om styring. Løsningen skal passe til lokale arbejdsprocesser, dansk sprog, databeskyttelse, leverandørkrav og de situationer, hvor AI må eller ikke må indgå i beslutninger. Det gælder både private virksomheder, offentlige arbejdspladser, skoler og vidensmiljøer.
EU’s AI Act bruger en risikobaseret tilgang. Kommissionen beskriver blandt andet forbudte praksisser, højrisikoområder, gennemsigtighedsregler og regler for general-purpose AI-modeller. Regler for AI-literacy og forbudte praksisser trådte i anvendelse i februar 2025, mens gennemsigtighedsregler efter Kommissionens oversigt kommer i anvendelse i august 2026. Det betyder ikke, at enhver intern ChatGPT-assistent er højrisiko, men brug i HR, uddannelse, adgang til ydelser eller andre følsomme processer kræver en anden vurdering end tekstudkast og intern videnssøgning.
Begrebet enterprise AI er nyttigt her, fordi det flytter fokus fra enkeltbrugeren til organisationen: adgang, datakvalitet, dokumentation, ansvar, vedligeholdelse og sporbarhed. En tilpasset ChatGPT-løsning bør derfor have en ejer, en brugspolitik og et sted, hvor fejl og forbedringsforslag registreres.
Hvilke fejl gør tilpasningen skrøbelig?
Den mest almindelige fejl er at gøre løsningen for bred. En GPT, der både skal skrive marketingtekster, hjælpe support, analysere regneark og svare på HR-spørgsmål, får uklare grænser. Den bliver svær at teste, svær at vedligeholde og svær at placere ansvar for.
En anden fejl er at gemme regler i referencefiler, når de bør ligge i instruktionerne. OpenAI skelner selv mellem instruktioner, som styrer adfærd, og knowledge, som giver referenceindhold. Hvis virksomhedens tone, forbud, eskaleringsregler og kontrolpunkter kun ligger i et uploadet dokument, kan de blive behandlet som almindelig baggrundsviden i stedet for bindende rammer.
En tredje fejl er at springe menneskelig godkendelse over, fordi en intern løsning føles mere troværdig end en åben chat. Tilpasning øger relevansen, men den fjerner ikke risikoen for forkerte svar, forældede kilder eller misforståede instruktioner. Jo tættere løsningen kommer på kunder, borgere, økonomi eller personaleprocesser, desto tydeligere bør godkendelsespunktet være.
Hvordan vedligeholdes en tilpasset ChatGPT-løsning?
Vedligeholdelse bør planlægges som en almindelig driftsopgave. En tilpasset ChatGPT-løsning har dokumenter, regler, adgangsrettigheder, brugere og fejltyper. Alle fem kan ændre sig. Hvis ingen ejer vedligeholdelsen, ender løsningen ofte med gamle filer, uens praksis og brugere, der laver deres egne uofficielle varianter.
En enkel vedligeholdelsesrytme kan være månedlig kontrol af referencefiler, kvartalsvis test mod faste cases og hurtig revision ved større ændringer i produkt, lovkrav eller leverandørvilkår. Versionshistorik i GPT-editoren kan bruges til at gendanne tidligere opsætninger, men den erstatter ikke en kort intern ændringslog, hvor formål, dato og ansvarlig fremgår.
Tilpasningen bør også have en frakoblingsplan. Hvis en integration fejler, en datakilde bliver usikker, eller en opgave ændrer karakter, skal medarbejdere vide, om løsningen skal sættes på pause, begrænses til læseadgang eller erstattes af manuel behandling. Det gør ChatGPT-tilpasning mere praktisk og mindre afhængig af enkeltpersoners hukommelse.
Hvilke kilder ligger til grund?
Artiklen bygger på OpenAIs dokumentation om oprettelse og redigering af GPTs, især instruktioner, knowledge, capabilities, apps, actions og versionering. OpenAIs side om enterprise privacy er brugt til afsnittene om business data, adgangskontrol, retention og sikkerhed. OpenAIs API-dokumentation om modeloptimering er brugt til afgrænsningen mellem almindelig tilpasning og modelarbejde. EU-Kommissionens oversigt over AI Act er brugt til de europæiske governance- og risikoforbehold.