Sådan integrerer du ChatGPT eller Claude i dit eksisterende system

Når du vil integrere ChatGPT i dit system, er den sikre vej at lade din egen server kalde OpenAI's eller Anthropics API gennem et afgrænset lag med kø, logning, grænser og en plan for hvad der sker når AI'en fejler. Selve API-kaldet kan en udvikler skrive på en eftermiddag, men det er alt det rundt om kaldet der afgør om funktionen holder, når rigtige brugere og rigtige data rammer den.

ChatGPT er OpenAI's app. Når du bygger noget ind i dit eget system, bruger du i stedet deres API, som giver adgang til de samme modeller. Opbygningen nedenfor er den samme for Claude, og den er skrevet til dig der skal træffe beslutningen, ikke til den der skriver koden.

Den korte version: seks byggeklodser

En sikker AI-integration består af seks dele. En lille intern funktion kan starte uden nogle af dem, men du bør vide hvilke du springer over, og hvorfor.

Min tommelfingerregel: jo tættere AI-funktionen ligger på penge, kunder eller data du ikke må miste, jo flere af de seks skal være på plads før lancering. En intern opsummering kan klare sig med AI-lag, logning og et forbrugsloft. En funktion dine kunder bruger, skal have det hele.

Guiden handler om at bygge AI ind i et system du allerede har. Er hele din app bygget med et AI-værktøj som Lovable eller Cursor, og skal den i drift, så start med guiden til at gøre en AI-prototype klar til rigtige brugere.

Hvad der går galt med et direkte API-kald

Den hurtigste integration er et kald direkte fra den kode der viser siden: brugeren klikker, systemet spørger modellen og venter. Det virker i en demo. I drift støder det typisk ind i fem problemer.

• Det er langsomt. Et svar tager ofte flere sekunder, og imens hænger siden.
• Udbyderen siger nej. Alle API'er har grænser for hvor mange kald og tokens (tekstenheder) du må bruge pr. minut.
• Udbyderen er nede. Det sker for alle store tjenester en gang imellem, og så er din funktion nede samtidig.
• Prisen løber løbsk. En fejl der kalder modellen igen og igen, kan koste mere på en nat end du havde regnet med for en måned.
• Svaret varierer. Det samme spørgsmål kan give forskellige svar og en gang imellem et format din kode ikke forventer.

Ingen af dem er grunde til at lade være. De er grunde til at bygge et lille lag rundt om kaldet.

Sådan integrerer du AI trin for trin

Jeg arbejder selv i denne rækkefølge. De to første trin er afklaring uden kode, men de afgør resten.

1. Vælg én afgrænset opgave

Start med én opgave hvor du kan se om svaret er godt eller dårligt. Gode første kandidater er at opsummere en sag, foreslå et svar til kundeservice, sortere indkomne henvendelser eller trække felter ud af et dokument. "Gør systemet klogere" er ikke en opgave.

Saml derefter et par dusin rigtige eksempler fra dit eget system sammen med det svar du ville have været tilfreds med. De bliver din testpakke: når du skifter model eller ændrer instruktionerne, kører du eksemplerne igen og ser om kvaliteten holder. Beslut også fra starten om et menneske skal godkende svaret, før det bliver brugt. Mangler du idéer til opgaven, har jeg samlet 12 måder at bruge AI i en SaaS eller platform.

2. Afklar hvilke data der må sendes

Alt du sender til modellen, forlader dit system og bliver behandlet hos udbyderen. Indeholder det persondata, er udbyderen din databehandler, og så skal GDPR-delen være på plads: databehandleraftale, hvor data behandles, og hvor længe de gemmes.

Udgangspunktet er bedre end mange tror. OpenAI skriver at data sendt til deres API ikke bruges til at træne modellerne, medmindre du selv vælger det til, og at logs til misbrugsovervågning gemmes i op til 30 dage. Nye projekter kan efter godkendelse få dataophold i Europa. Anthropic lover tilsvarende ikke at træne på dine data uden tilladelse.

Min regel er at sende det mindste der løser opgaven. Fjern CPR-numre, kontonumre og navne, hvis modellen ikke har brug for dem. Det her er ikke juridisk rådgivning, og guiden om GDPR og AI går mere i dybden.

3. Byg et AI-lag på serveren

Alle kald til modellen skal gå gennem ét sted i din kode: et lille modul der kender API-nøglen, instruktionerne (prompts), modelvalget og tidsgrænserne. Resten af systemet beder bare modulet om "en opsummering af sag 1234" og ved ikke hvilken udbyder der svarer.

Det giver dig tre ting. API-nøglen ligger kun på serveren i miljøvariabler, aldrig i browseren, hvor alle der åbner udviklerværktøjerne kan finde den og bruge løs på din regning. Du kan skifte fra OpenAI til Claude, eller bruge begge, ved at ændre ét sted. Og prompts bliver behandlet som kode: de ligger i versionsstyring, har et versionsnummer og bliver testet mod eksemplerne fra trin 1, før en ændring går i drift.

4. Læg kaldene i en kø

En kø lader systemet svare "modtaget" med det samme og lave det tunge arbejde i baggrunden. Brugeren ser en status som "behandles", og resultatet dukker op på siden eller i en mail, når det er klar. Laravel har køer indbygget, og de fleste andre frameworks har noget tilsvarende.

Køen er også stedet hvor du håndterer fejl. Rammer du udbyderens grænse, skal jobbet vente og prøve igen. OpenAI anbefaler at følge Retry-After og bruge eksponentiel backoff: vent så længe udbyderen beder om, og hold ellers længere og lidt tilfældige pauser for hvert nyt forsøg. Sæt også et loft over hvor mange AI-job der kører samtidig.

I en chat venter brugeren aktivt, så her bruger man i stedet streaming, hvor svaret vises ord for ord mens det bliver skrevet. Tidsgrænsen og fejlhåndteringen skal stadig være der.

5. Genbrug svar hvor du kan

Mange AI-funktioner bliver kaldt med det samme input igen og igen. En produkttekst, en opsummering af en sag eller en kategorisering skal kun laves én gang og gemmes i databasen, indtil indholdet ændrer sig. Det er hurtigere for brugeren og billigere for dig.

Gem hvert svar sammen med input, promptversion og model, så nye instruktioner automatisk giver nye svar. Og del aldrig gemte svar på tværs af brugere, hvis svaret bygger på personlige oplysninger. Så risikerer du at vise én kundes data til en anden.

Både OpenAI og Anthropic har desuden deres egen caching, så lange instruktioner der går igen i hvert kald, bliver billigere. Det kræver at den faste del af prompten står først og den skiftende del til sidst.

6. Log hvert kald

Uden logning er AI-funktionen en sort boks. For hvert kald bør du gemme tidspunkt, funktion, bruger, model, promptversion, tokens ind og ud, beregnet pris, svartid og udfald: gik det godt, fejlede det, eller blev fallback brugt. Kan brugerne give svaret tommel op eller ned, så gem det også.

Med de data kan du svare på de spørgsmål der altid kommer: hvad koster funktionen om måneden, og hvorfor fik sag 1234 et mærkeligt svar i tirsdags. Sæt alarmer op på fejlrate og dagligt forbrug. Har du ikke overvågning i forvejen, er min gennemgang af værktøjer til overvågning af din webapp et godt sted at starte.

Vær varsom med selve teksterne, for logger du hele prompten, logger du også persondataene i den. Gem altid metadata, og gem kun fuld tekst i en begrænset periode.

7. Bestem hvad der sker når AI'en fejler

Fallback er planen for de dage hvor modellen er nede, langsom eller svarer forkert. Der findes tre niveauer:

1. Genforsøg i køen, som dækker korte forstyrrelser.
2. En reservemodel: fejler OpenAI, går kaldet til Claude eller omvendt. Det kræver AI-laget fra trin 3, og at prompten er testet på begge modeller.
3. En manuel vej, hvor sagen lander hos en medarbejder, eller hvor AI-knappen forsvinder midlertidigt, mens resten af systemet kører videre.

Grundreglen er at dit system skal kunne fungere uden AI. Fejler udbyderen mange gange i træk, skal systemet holde pause med at kalde den. Udviklere kalder det en circuit breaker (en slags automatsikring), og den forhindrer at et nedbrud hos udbyderen også fylder dine køer op.

8. Valider svaret og begræns hvad modellen må

Behandl alt hvad modellen svarer, som input fra en fremmed. Bed om svar i et fast format, fx JSON med bestemte felter, og lad din kode tjekke format og værdier før noget bliver gemt. Begge udbydere kan tvinge svaret ind i et skema, men tjekket i din egen kode skal stadig være der.

Den største sikkerhedsrisiko hedder prompt injection: tekst i en mail, et dokument eller en besked der får modellen til at gøre noget andet end tiltænkt. OWASP har den som nummer ét blandt risici i LLM-applikationer og anbefaler blandt andet minimale rettigheder og menneskelig godkendelse af privilegerede handlinger. I praksis må modellen gerne foreslå en refusion, men et menneske eller en fast regel i koden godkender den.

Sæt til sidst grænser for svarlængde, antal kald pr. bruger og månedligt forbrug. Taler dine kunder direkte med AI'en, så fortæl dem det tydeligt. EU's AI-forordning har også regler om den slags gennemsigtighed.

Hvad det koster at bygge og drive

Udgiften falder i to dele: udviklingen af integrationen og det løbende forbrug hos udbyderen.

Udviklingen afhænger mere af dit eksisterende system end af AI'en. Har systemet allerede kø, logning og en fornuftig struktur, er en første afgrænset funktion et overskueligt projekt. Mangler de ting, skal fundamentet bygges først, og det er ofte der de fleste timer går. Mit råd er at afklare det i et lille betalt forprojekt, før du beder om en fast pris.

Forbruget betaler du pr. token, og prisen pr. kald er som regel lille. Det er mængden der gør det dyrt: mange brugere, lange dokumenter eller en stor model til en simpel opgave. Du har fire håndtag:

• Brug den mindste model der klarer dine testeksempler.
• Genbrug svar og faste instruktioner som beskrevet i trin 5.
• Kør opgaver der ikke haster, som batch. Både OpenAI og Anthropic giver 50 % rabat på batchkørsler, og hos Anthropic er de fleste færdige inden for en time.
• Sæt et forbrugsloft. Hos Anthropic kan du selv sætte en månedlig grænse under din kontos loft, og din egen budgetalarm fra trin 6 fanger resten.

Vil du regne på dit eget forbrug, gennemgår guiden til hvad AI koster i drift token-priser og budgettering i detaljer.

Hvornår du ikke skal bygge en integration

En integration bygget til dit system er ikke altid svaret. Her er de situationer hvor jeg selv ville anbefale noget andet.

Skal medarbejderne bare skrive, opsummere og oversætte hurtigere, så køb et erhvervsabonnement på ChatGPT eller Claude. Det er som regel billigere end udvikling.

Bruger du et standardsystem til CRM, webshop eller økonomi, så tjek om det allerede har AI-funktioner eller apps i sin markedsplads, før du bygger noget leverandøren måske selv er i gang med.

Er det en lille intern arbejdsgang med få kald om dagen, kan et automatiseringsværktøj som Zapier eller Make med et AI-trin være nok, i hvert fald til at teste idéen. Og skal du bare have en chatbot på hjemmesiden, findes der færdige produkter. Jeg har sammenlignet mulighederne i byg selv eller køb en AI-chatbot.

Hvis ingen tør røre ved dit eksisterende system, fordi noget går i stykker ved hver ændring, er AI ikke det første problem at løse. Så skal systemet stabiliseres først.

En integration er det rigtige valg når AI'en skal arbejde med dine egne data inde i dine egne arbejdsgange, og når du vil have kontrol over hvad der sendes, hvad det koster, og hvad der sker når det fejler.

Næste skridt: fra idé til første AI-funktion i drift

Start småt: én opgave, ét system, én udbyder og et lag der gør det let at skifte senere. Gå tjeklisten igennem før lancering, og brug den igen før du åbner funktionen for flere brugere.

Har du et system som AI skal bygges ind i, kan du se hvordan jeg arbejder med udvikling af webapps og platforme. Du har direkte kontakt med mig som udvikler, og koden er din fra første dag.

Ofte stillede spørgsmål

Kan jeg bruge mit ChatGPT-abonnement i stedet for API'et?+

Nej, ikke til en integration. Et abonnement på ChatGPT giver adgang til selve appen for de personer der har en konto. Når dit system skal kalde modellen, skal du bruge OpenAI's API, som afregnes separat efter forbrug. Det samme gælder Claude, hvor abonnement og API-adgang også er to forskellige ting med hver sin betaling.

Skal jeg vælge OpenAI eller Claude?+

Vælg ud fra en test med dine egne eksempler, ikke ud fra omtale. Til de fleste forretningsopgaver kan begge løse opgaven, og forskellene viser sig først på dine data. Tænk også på hvor din infrastruktur ligger i forvejen: Claude kan bruges gennem AWS, Google Cloud og Microsoft Foundry, og OpenAI's modeller gennem Microsoft Azure. Byg integrationen så du kan skifte, så er valget ikke låst.

Hvad sker der når udbyderen udfaser en model?+

Så skal du skifte til en nyere model inden en fastsat dato. Både OpenAI og Anthropic udfaser ældre modeller løbende og varsler det på forhånd. Lås derfor din integration til en bestemt modelversion i stedet for altid den nyeste, og test den nye model mod dine eksempler, før du skifter. Logningen viser bagefter om svartid, pris eller kvalitet har ændret sig.

Kan AI'en hente data fra mit system?+

Ja, gennem det udbyderne kalder tool use eller function calling. Modellen beder om data, fx en kundes seneste ordrer, og din kode afgør om den må få dem, og henter dem. Rettighederne håndhæves altså af dit system, ikke af modellen. Start med adgang der kun kan læse, og giv først adgang til at ændre data når logning og godkendelse er på plads.