Hvad er din custom ChatGPT-strategi? Her nogle råd og rammer

Mange kommunikationsafdelinger bygger custom chatgpts i øjeblikket. Og mange af dem er glemt igen seks måneder senere.

Årsagen er sjældent teknisk. Den er organisatorisk. Ingen bestemte sig for, hvad de egentlig byggede, hvem der ejede det, og hvad der skulle ske med det over tid.

Denne guide handler om de valg, du skal træffe, inden du begynder.

Fire typer. Ikke flere.

Der er grundlæggende fire typer custom chatgpts, og de stiller fundamentalt forskellige krav.

Opgavebotten løser en konkret, afgrænset opgave. Skriv et høringssvar. Udkast til en pressemeddelelse. Lav et Q&A til ledelsen. Den er den mest robuste af de fire, fordi afgrænsningen er dens styrke. Jo mere gentagelig opgaven er, jo bedre fungerer den. Svaghed: den er ufleksibel. Brug den til det, du løser mange gange i samme format.

Rollebotten er en funktion. En presserådgiver. En krisekommunikatør. En devil's advocate der altid udfordrer budskabet. Styrken er, at den kan give dig en sparringspartner, du ellers ikke har adgang til. Svaghed: den kræver, at du præcist forstår den rolle, du beder den spille. Ellers får du en karikatur. En "erfaren kommunikationschef" der altid siger det oplagte og aldrig det ubehagelige. God prompt-engineering og konkrete eksempler reducerer den effekt, men aldrig helt.

Domænebotten er en specialiseret videnskilde. Den kender organisationens positionspapirer, historiske pressemeddelelser, branchespecifikke regler, lovtekster. Styrken er dybden og konsistensen. Svaghed: vedligeholdelse. Viden forældes, og en bot der refererer til forældet lovgivning eller en strategi der er to generationer gammel, er farligere end ingen bot. Domænebotten kræver en ejer og en vedligeholdelsesplan. Uden dem er den kun god de første måneder.

Procesbotten er den mest ambitiøse af de fire. Den styrer et helt workflow fra ende til anden. Fra lovudkast til konsekvensanalyse til færdigt høringssvar. Fra briefingnotat til talmanuskript til Q&A. Styrken er, at den kan reducere den samlede tid på komplekse, flerledede opgaver markant, fordi hvert trin bygger videre på det forrige i samme bot. Svaghed: kompleksiteten er tilsvarende høj. Fejler ét led, forplanter fejlen sig videre. Procesbotten kræver grundig test, klare fallback-instruktioner og et menneske der kender hele workflowet godt nok til at spotte, når noget er gået skævt undervejs.

Hybridmodellen kombinerer to eller flere typer. En opgavebot i et domæne er den mest oplagte kombination. Det er oftest her man får mest for pengene. Men kompleksiteten stiger med hvert ben du tilføjer, og jo flere kombinationer, jo sværere er det at debugge, når botten opfører sig uventet.

Start med et konkret smertepunkt

Inden du overhovedet åbner GPT-builder, skal du besvare ét spørgsmål: Hvad er det problem alle kender og hader?

Ikke "vi skal digitalisere kommunikationsafdelingen." Ikke "AI vil transformere vores arbejde." Men: hvad er den konkrete opgave der suger tid, sænker humøret og gentager sig ugen efter ugen? En kommunikationsafdeling der starter med det spørgsmål, bygger botter der faktisk bruges. En der starter med teknologien, bygger botter der ser imponerende ud i præsentationen og dør stille i praksis.

Det lyder enkelt. Det er det ikke, fordi det kræver at man tager sig tid til at kortlægge arbejdsgangene systematisk inden man begynder at bygge.

Det organisatoriske valg ingen tager eksplicit

Der er to principielt forskellige tilgange til, hvordan en afdeling styrer udviklingen af custom chatgpts. Begge har reelle fordele. De fleste afdelinger vælger den ene ubevidst ved ikke at beslutte noget.

Lad tusinde blomster blomstre. Alle kan bygge det, de har brug for. Ingen central godkendelse. Ingen fælles standard.

Fordele: Innovation sker tæt på de faktiske arbejdsopgaver. Den der bygger botten, bygger den til noget hun selv mangler. Ejerskabet er ægte, og erfaringen med at bygge og fejle er i sig selv værdifuld. Det er her den tidlige organisatoriske læring opstår.

Ulemper: Botter bliver ikke vedligeholdt. De bliver ikke delt. Kvaliteten varierer voldsomt, og ingen ved hvad der faktisk eksisterer. Efter 12 måneder har afdelingen måske 15 botter, hvoraf tre bruges og ingen er opdaterede. Det er præcis den bot sprawl der langsomt æder tilliden til hele tilgangen.

Central styring. En koordinerende funktion godkender, dokumenterer og vedligeholder. Kun endorsede botter må bruges i arbejdet.

Fordele: Konsistens og kvalitetssikring. Klart ansvar. Vedligeholdelse er en del af processen, ikke en eftertanke.

Ulemper: Langsom. Bureaukratisk. Fjerner ejerskabet fra den der faktisk bruger botten. Bliver let et IT-projekt frem for et arbejdsredskab.

Hybridmodellen er det, der virker i praksis. Fri udvikling til personlig brug, men med en mulighed for at løfte de bedste botter til delte ressourcer med formel godkendelse, navngiven ejer og fast opdateringscyklus. Tænk på det som to niveauer: et uformelt laboratorium og et formelt bibliotek. Det kræver at nogen aktivt forvalter biblioteket, og at det er en eksplicit opgave, ikke en god intention.

Kend dine medarbejdere inden du ruller ud

Enhver afdeling rummer fire typer mennesker i mødet med ny teknologi. Og en kommunikationsstrategi der behandler dem ens, fejler.

De begejstrede er 15 til 20 procent af medarbejderne. De bruger allerede AI i smug. De er karriereacceleratorer der ser mulighederne. Brug dem. Giv dem tidlig adgang, anerkendelse og scene til at vise kollegerne hvad de har fundet ud af. Brem dem ikke med for mange regler.

De rolige følgere er majoriteten, 50 til 60 procent. De venter på instruktioner. De gør hvad der bliver sagt. De har brug for how-to guides, konkrete skabeloner og tryghed. Abstrakt snak om transformation og disruption rammer forbi. Vis dem præcis hvad de skal gøre og garantér at de ikke kan gøre noget forkert ved at prøve.

De ambivalente er 15 til 20 procent. Højt kompetente, fagligt engagerede, men skeptiske. De stiller de svære spørgsmål om bias, datakvalitet og etik. Den hyppigste fejl er at behandle dem som modstandere der skal overvindes. De er organisationens immunforsvar, og de kan blive dens mest troværdige fortalere. Involvér dem i governance. Gør dem til red teamers der tester systemet for fejl. Hvis du kan overbevise en ambivalent, overbeviser de alle andre.

Modstanderne er 10 til 15 procent. De føler sig truet. De ser AI som en fjende af fagligheden eller deres eksistensgrundlag. De har brug for empati, ærlighed og konkrete omskolingsmuligheder. Isolér dem ikke. Lad ikke deres frygt smitte uimodsagt. Men lov dem heller ikke at intet ændrer sig.

Og på tværs af alle fire typer gælder et grundlæggende skel: der er piloter og der er passagerer. Piloterne bruger AI til at forstærke deres kreativitet og har et formål med brugen. Passagererne bruger det for at undgå arbejde og producerer workslop. Samme træningsprogram giver vidt forskelligt resultat. Målet er at flytte folk mod pilotmentalitet, og det sker ikke gennem flere værktøjer. Det sker gennem oplevelsen af kontrol og succes. Små sejre skaber handlekraft. Handlekraft skaber optimisme. Optimisme skaber piloter.

Styringsmodel efter risiko, ikke efter afdeling

En fælles godkendelsesproces for alle botter er en dårlig idé. Den dræber innovation i den lave ende og giver falsk tryghed i den høje.

Opdel i stedet godkendelserne i tre niveauer efter risiko.

Lavrisiko-botter til intern brainstorming, opsummering og udkast kræver ingen formel godkendelse. Self-service. Brugeren er selv ansvarlig for outputtet.

Mellemrisiko-botter, der tilgår interne data eller er koblet til workflows via integrationer, kræver et let gennemsyn fra en central funktion. Ikke en tung godkendelsesproces, men en dokumenteret vurdering.

Højrisiko-botter, der er kundevendte, finansielt eller regulatorisk følsomme, kræver fuld godkendelse fra compliance, jura og IT-sikkerhed. Her er menneskelig kontrol ikke et fravalg.

En simpel trafiklysmodel for data hører til i samme pakke. Rød: personfølsomme data og forretningshemmeligheder må aldrig tastes ind i offentlige AI-modeller. Gul: interne notater og generelle processer må bruges i lukkede Enterprise-instanser. Grøn: offentligt tilgængelig information må bruges frit. Del modellen bredt. Gør den nem at huske. Uklarhed om regler skaber enten paralyse eller farlig Shadow AI-adfærd, og begge dele er dyrere end klare retningslinjer.

Prioritér idéerne, inden I bygger

Ikke alle GPT-idéer er lige gode. Vurder hver idé på tre parametre. Hvad er forretningsværdien: tidsbesparelse, kvalitetsforbedring, færre fejl? Hvad er den tekniske gennemførlighed: har I de rette data, og er integrationen realistisk? Og hvad er risikoprofilen: er det et reguleret område, hvor en hallucination kan få konsekvenser?

Start med høj værdi og lav kompleksitet. Spar de teknisk ambitiøse projekter til, når I har lært at arbejde systematisk med de enkle. Det undgår AI-teater: projekter der ser imponerende ud i præsentationen og dør stille i praksis.

Find vinderen og investér i den

Bag enhver portefølje af custom chatgpts gemmer der sig en skæv fordeling. Nogle botter bruges dagligt af mange. Andre bruges af én person en gang om måneden. De fleste bruges slet ikke. Det er ikke et problem der skal løses med mere information eller bedre onboarding. Det er et signal der skal handles på.

De botter der tidligt finder et rigtigt problem og løser det godt, tiltrækker brug. Brug genererer feedback. Feedback forbedrer prompten og vidensbasen. Forbedring tiltrækker mere brug. De botter der ikke finder fodfæste i de første måneder, finder det sjældent senere, uanset hvor meget energi der investeres i dem.

Ressourcerne skal følge brugsmønstrene. Identificér løbende, hvilke botter der faktisk bruges og løser rigtige opgaver. Dem investerer I i: bedre træningsdata, skarpere prompts, bredere udrulning, formel vedligeholdelse. De øvrige nedprioriteres aktivt. Byg en simpel udvælgelsesproces ind fra starten. Mål brug kvartalsvis. Klassificér botter i tre kategorier: aktive og voksende, stagnerende, inaktive. Investér i den første. Giv den anden en begrænset rehabiliteringsfrist. Luk den tredje.

Udrulning i faser

Den hyppigste fejl ved udrulning er at gøre det hele på én gang. Sæt tempoet ned og lær undervejs.

Fase 1: Grundlæggende virkning. Start smalt. To til tre konkrete use cases, tre til fem nøglepersoner, lav teknisk kompleksitet. Det handler om at finde ud af, om denne bot, med disse instruktioner, løser denne opgave godt nok til at det er værd at fortsætte. Hold øje med fejltyper. Hallucinerer den? Misforstår den opgaven systematisk? Finder I det her, er det billigt at rette. Finder I det i fase tre, er det dyrt.

Fase 2: Effekt og justering. Udvid til en kontrolleret brugergruppe. Ti til femten personer der bruger botten på rigtige opgaver over fire til seks uger. Mål tidsforbruget før og efter. Kig på brugsdata: hvilke prompts virker, hvilke giver dårligt output, hvilke opgaver løser folk aldrig med botten alligevel. Justér prompt-designet på baggrund af faktisk brug, ikke forventninger. Mange GPT'er ser fantastiske ud i demo og middelmådige ud i drift. Det er fase 2 der afslører forskellen.

Fase 3: Skalering med overvågning. Kun når fase 2 har vist dokumenteret positiv effekt, ruller I bredere ud. Opret et fælles prompt-bibliotek. Implementér integrationer, men read-only til at begynde med. Og behold overvågningen. En GPT der virker i uge et behøver ikke virke i måned seks, når vidensbasen er forældet og brugsmønstrene har ændret sig. Følg brugsdata aktivt. Høj adoption er ikke i sig selv et succeskriterium. Det interessante er, om de der bruger den løser opgaverne hurtigere og bedre.

Fase 4: Løbende vedligeholdelse. Udrulningen er ikke slutpunktet. Kvartalsvis gennemgang af porteføljen. Bruges botten stadig? Er vidensbasen opdateret? En bot der ikke er opdateret siden udrulningen er ikke et aktiv. Det er en risiko der venter på at blive opdaget. Koncentrér ressourcerne om det der virker. Og vær villig til at lukke det der ikke gør.

Træningsdata: kvalitet, aktualitet og omfang

En custom chatgpt er præcis så god som det, den er trænet på. Det lyder banalt. Det overses alligevel konsekvent.

Mange GPT'er bygges med for lidt data, forkert data eller forældet data. Resultatet er en bot der svarer med selvtillid på et grundlag der ikke holder. Det er ikke bedre end ingen bot. Det er værre, fordi folk stoler på den.

Lav en træningsdatastrategi, inden I uploader noget som helst. Det er det trin de fleste springer over. Man åbner GPT-builder, man uploader hvad man har, og man begynder at prompte. Det er den forkerte rækkefølge. En træningsdatastrategi er ikke en teknisk øvelse. Det er en redaktionel og organisatorisk beslutning: hvad skal botten vide, hvorfor, hvem beslutter det, og hvem holder det ved lige?

Strategien skal besvare seks spørgsmål. Hvad er bottens primære vidensdomæne, og hvad falder uden for? Hvilke dokumenttyper er autoritative kilder, og hvilke er støjkilder? Hvem i organisationen har mandat til at beslutte, hvad der er ind og hvad der er ud? Hvad er opdateringskadencen, og hvem ejer den opgave? Hvordan håndteres det, når organisationens position ændrer sig, og den gamle position stadig ligger i vidensbasen? Og hvornår er vidensbasen stor nok til at botten generaliserer korrekt frem for at memorere enkelttilfælde?

Kvalitet slår kvantitet. Ti stærke, aktuelle, repræsentative dokumenter er mere værd end hundrede tilfældige. Vær redaktionel.

Sortér efter formål. Til tone of voice vil I have tekster I er stolte af. Til en domænebot vil I have faktanære, autoritative dokumenter. Bland dem ikke. En bot der er trænet på begge dele på én gang ved ikke, hvornår den skal prioritere faktanøjagtighed og hvornår den skal prioritere stil.

Aktualitet er ikke et éngangsvalg. En vidensbase fastfryses i det øjeblik, I uploader den. Fra den dag forældes den. Sæt en fast kadence: månedlig gennemgang for domænebotter i regulerede områder, kvartalvis for de øvrige. Vær særlig opmærksom på det der forsvinder. Nye dokumenter tilføjes. Gamle fjernes sjældent. Over tid akkumuleres en vidensbase der rummer modsætninger. Botten harmoniserer ikke modsætningerne. Den præsenterer dem skiftevis afhængigt af, hvordan spørgsmålet er formuleret.

Systematisk opdatering i levetiden. En holdbar løsning kræver tre ting: et navngivent ejerskab, en kalender der specificerer hvornår vidensbasen gennemgås og af hvem, og et feed der løbende identificerer kandidater til ny træningsdata. Når en medarbejder producerer en tekst der er bedre end hvad botten ville have leveret, er den en kandidat. Når en ekstern rapport eller ny lovtekst lander, er det en kandidat. Når botten gentagne gange svarer forkert på et bestemt spørgsmål, er det et signal om at noget mangler.

Det tredje spørgsmål i den kvartalsvise gennemgang er det vigtigste og mest oversete: hvad i den eksisterende vidensbase er nu forældet og bør fjernes? En vidensbase der kun vokser, bliver med tiden en kilde til inkonsistens frem for klarhed. Fjernelse er en redaktionel handling på linje med tilføjelse.

Gode råd til udvikling

Definér tone of voice med eksempler, ikke adjektiver. Upload de ti bedste tekster, I selv har skrevet. Fortæl botten hvem målgruppen er, hvilke værdier I kommunikerer ud fra, og hvilke ord I aldrig bruger. Konkrete eksempler slår abstrakte principper hver gang.

Lav en fælles prompt-guide til teamet. En custom chatgpt er kun så god som de prompts der sendes ind i den. Lav en kort guide der samler afdelingens standarder: tone of voice, ord I altid eller aldrig bruger, og en skabelon for hvad en god prompt indeholder.

Match temperaturen med risikoprofilen. Til compliance-tekster og faktatunge pressemeddelelser skal kreativiteten ned, 0.0 til 0.3, for at minimere hallucinationer. Til brainstorming og SoMe-idéer er variation en fordel, 0.6 til 1.0. Dobbelttjek faktapåstande uanset hvad.

Byg fallback-instruktioner ind fra starten. Skriv det direkte i system-prompten: hvis botten mangler kilder eller information, skal den producere en spørgeliste frem for at gætte. Og hvis brugeren taster fortrolige oplysninger ind, skal den stoppe og bede om at få teksten anonymiseret først.

Test med kendte facitter, inden I ruller ud. Tag 20 til 30 historiske opgaver og test om botten rammer rigtigt. Forsøg også bevidst at snyde den. Find svaghederne, inden brugerne gør det.

Brug den som ghostwriter, ikke som forfatter. Den mest produktive brug er at strukturere tanker, generere overskriftsvarianter, skrive første udkast der kan redigeres, og bryde skriveblokeringen. AI'en brainstormer strukturen, du skriver første draft, AI'en analyserer argumenterne, du tænker hvordan de styrkes. Det er augmentation. Den anden vej, "AI, skriv artikel om X, du læser og trykker publicer", er atrofi. Du har trænet intet.

Byg platform-agnostisk. Hold prompt-biblioteker, data-pipelines og integrationer uafhængige af den specifikke model, så I kan skifte, hvis compliance-kravene ændrer sig. Europæiske alternativer som Mistral og Aleph Alpha er relevante at kende til, særlig for organisationer der håndterer følsomme data under GDPR.

Del det der virker. Opret et enkelt sted, et intranet-afsnit eller en delt mappe, hvor medarbejderne kan finde godkendte prompts, retningslinjer og eksempler på use cases der har virket. Det spreder adoption hurtigere end noget kursus.

Find jeres ambassadører og gør dem til legender

Ingen GPT-strategi overlever på governance alene. Den overlever, hvis der er mennesker i organisationen der brænder for det og trækker andre med sig.

I enhver kommunikationsafdeling sidder der én eller to personer der allerede behandler deres custom chatgpt som et personligt projekt. De tweaker prompten om aftenen. De viser kollegerne output med en stolthed der minder om forældre der viser billeder af deres børn. De er jeres ambassadører. Problemet er, at de sjældent ved det selv, og organisationen gør ingenting for at løfte dem frem.

Opret et ambassadørkorps. Identificér de medarbejdere der bruger og bygger custom chatgpts aktivt og godt. Giv dem et navn der signalerer ejerskab og ekspertise, ikke supportfunktion. Inkludér både de begejstrede og de ambivalente. Bredden giver troværdighed.

Giv dem synlighed. Præsentér de bedste botter internt, ikke som IT-projekter men som faglige bedrifter. Fortæl historien bag bottens udvikling på samme måde, som I ville fortælle historien bag en god kampagne. Anerkendelsen skal være offentlig og konkret.

Giv dem status med et award-system. Kvartalsvis synliggørelse af de bedste botter i porteføljen. Hvem har bygget den bot der har sparet mest tid? Hvem har vedligeholdt deres bot bedst over tid? Hvem har identificeret en use case ingen andre havde set? Kategorierne skal afspejle det I faktisk vil belønne: kvalitet, vedligeholdelse og innovation.

Brug gamification med omtanke. Point for at bygge en ny bot der godkendes til det fælles bibliotek. Point for at opdatere vidensbasen til tiden. Point for at bidrage med en ny prompt til den fælles guide. Den slags mekanik virker, men kun hvis gevinsten er synlighed og faglig anerkendelse.

Skab et community, ikke en støttefunktion. Ambassadørerne skal kende hinanden og lære af hinanden. Et månedligt møde på 45 minutter, fysisk eller online, med to faste spørgsmål: hvad virker, og hvad virker ikke? Det er her den uformelle viden om, hvordan man bygger gode botter, spreder sig i organisationen hurtigere end nogen guide nogensinde kan gøre det.

Giv ambassadørerne et playbook: de 20 mest stillede spørgsmål og svar, et slide-deck til teammøder, et prompt-bibliotek med skabeloner og eksempler, og en eskaleringsguide over hvem der ved hvad. Og giv dem beholde ejerskabet, også efter botten er løftet op i det fælles bibliotek.

Faldgruber

Brug den aldrig til kompleks, relationel kommunikation. En bot kan skrive et pressesvar i standardsituationen. Den kan ikke navigere den specifikke relation til journalisten der har gravet i sagen i tre måneder. Strategisk tunge og relationelt nuancerede budskaber kræver mennesker.

Kopier aldrig outputtet ukritisk. Holder man op med at redigere, holder man op med at tænke. Kognitiv atrofi er ikke en metafor. MIT Media Lab har målt op til 55 procent reduceret hjerneaktivitet i områder for hukommelse, kreativitet og opmærksomhed hos medarbejdere der ukritisk overlader tankearbejdet til chatbots, og effekten vedvarer efter de har lagt værktøjet fra sig. Byg produktiv friktion ind i arbejdsgangene. Kræv at medarbejderen eksplicit vurderer AI'ens output inden det godkendes. Og overvej bevidst at indsætte kendte fejl i AI-udkast uforudsigeligt, så brugerne ikke tillader sig at slappe af.

Ubetingede mandater skaber workslop. "Brug AI overalt hele tiden" er ikke en strategi. Det er en opskrift på AI-genereret indhold der maskerer sig som godt arbejde men mangler substans. Differentierede retningslinjer baseret på opgavetype er det eneste der virker.

En custom chatgpt er ikke en ekstern chatbot. OpenAI's GPT'er kræver et ChatGPT-abonnement for at bruges. Internt arbejdsredskab, ja. Ekstern kundesupport på hjemmesiden, nej.

Pas på fortrolige data. Fortrolig CRM-data, kundeoplysninger og ikke-offentliggjorte strategiske planer hører ikke hjemme i en standard ChatGPT-prompt, medmindre I har en Enterprise-aftale der garanterer at jeres data ikke bruges til at træne offentlige modeller.

Hold styr på jeres portefølje. EU's AI Act kræver at organisationer dokumenterer deres AI-systemer. Opret et centralt register over jeres GPT'er med formål, datakilder, ejer og risikokategori. Det er den dokumentation I kommer til at savne, den dag nogen spørger.

Deklarér aldrig sejr for tidligt. Der er ingen slutlinje med AI. Uden vedvarende fokus atroferer adoptionen. Skift sprog fra "implementering" til "kontinuerlig evolution."

Tre spørgsmål inden du bygger

Uanset type og styringsmodel: besvar disse tre spørgsmål, før du åbner GPT-builder.

Hvad er den konkrete opgave, og løser vi den mindst ti gange om måneden? Hvis svaret er sjældent eller uklart, er det for tidligt.

Hvem ejer den, og hvem opdaterer vidensbasen hvornår? Ingen ejer, ingen bot.

Hvad er succeskriterierne om seks måneder? Ikke "den bruges", men: hvilken konkret adfærdsændring skal den skabe?

Mange projekter falder allerede her. Det er ikke et problem. Det er en besparelse.