AI-udvikler, dataingeniør eller ML-ingeniør: hvem skal bygge dine AI-funktioner?

En AI-udvikler bygger funktioner oven på færdige sprogmodeller fra fx OpenAI, Anthropic eller Google, en dataingeniør bygger de rør der samler og renser dine data, og en ML-ingeniør træner og driver egne modeller. For de fleste mindre virksomheder er AI-udvikleren svaret, fordi en chatbot på din dokumentation, sortering af henvendelser eller udtræk fra fakturaer i praksis er integrationsarbejde via API'er. Dataingeniøren bliver relevant når spredte data er det der står i vejen, og ML-ingeniøren når du har store mængder egne data og et problem som færdige modeller ikke løser godt nok.

Jeg er selv fullstack-udvikler og bygger den slags integrationer, så læs med det forbehold. Til gengæld har jeg skrevet ærligt om hvornår du skal bruge en af de to andre.

Den korte version: hvem bygger hvad?

Min tommelfingerregel er enkel. Kan opgaven beskrives som "læs det her og gør noget med det", fx mails, dokumenter, kundesager eller billeder, starter du med en AI-udvikler. Er problemet at dine data ligger spredt og ikke kan stoles på, er det en dataingeniør. Skal en model lære mønstre i dine egne tal som ingen færdig model kender, er det en ML-ingeniør.

De tre roller er kun en del af billedet. Vil du se hvor de passer ind blandt frontend-, backend- og appudviklere, har jeg samlet de forskellige typer udviklere i én oversigt.

AI-udvikleren: bygger med færdige modeller

En AI-udvikler træner ikke sin egen model. Udvikleren bruger en model som OpenAI, Anthropic eller Google allerede har trænet, og kobler den på dine systemer gennem et API (en grænseflade som systemer bruger til at tale sammen). Det minder om at bygge betaling ind i en webshop: du opfinder ikke selv kortbetaling, du kobler dig på en udbyder og bygger alt det rundt om.

Typiske opgaver i en mindre virksomhed eller et SaaS-produkt:

• En chatbot eller søgning der svarer ud fra din egen dokumentation, dine vilkår eller din vidensbase.
• Sortering og prioritering af indkomne mails og supportsager.
• Udtræk af data fra fakturaer, ordrer eller kontrakter, så ingen skal taste dem ind.
• Opsummering af lange kundesager eller mødenoter.
• Udkast til produkttekster, svar eller oversættelser som et menneske godkender.

Chatbotten på din dokumentation kaldes ofte RAG (retrieval-augmented generation). Det lyder avanceret, men princippet er enkelt: systemet finder de relevante afsnit i dine dokumenter og sender dem med til modellen sammen med spørgsmålet. Ingen model bliver trænet.

Titlen "AI-udvikler" er ny og bruges bredt. I praksis er det ofte en fullstack- eller backend-udvikler som har bygget sprogmodeller ind i rigtige systemer. Det er en fordel, for de svære dele af opgaven ligger sjældent i selve AI'en. Hvornår én udvikler kan klare både brugerflade, backend og integrationer, har jeg skrevet om i guiden til hvornår én fullstack-udvikler er nok.

Hvorfor de fleste AI-funktioner er integrationsarbejde

Selve kaldet til en sprogmodel er ofte få linjer kode. Det er alt det rundt om der tager tiden. Tag automatisk udtræk af data fra indkomne fakturaer som eksempel. Arbejdet består groft sagt af syv dele:

1. Adgang til data. Hent fakturaerne fra en mailboks eller et økonomisystem, og send resultatet tilbage det rigtige sted.
2. Instruktion og format. Skriv instruktionen (prompten), og bestem præcis hvilket format svaret skal have, så resten af systemet kan bruge det.
3. Test på rigtige eksempler. Saml et testsæt af rigtige fakturaer, og mål hvor ofte modellen rammer rigtigt. Den slags faste testsæt kaldes evals.
4. Fejlhåndtering. Hvad sker der når udbyderen er nede, svaret er forkert, eller fakturaen er et uskarpt foto?
5. Rettigheder og GDPR. Hvem må se hvad, og hvilke persondata må sendes til en udbyder?
6. Brugerflade og godkendelse. Et sted hvor en medarbejder ser forslaget og retter det før det bogføres.
7. Overvågning. Hold øje med forbrug, pris pr. kald og om kvaliteten falder når udbyderen opdaterer modellen.

Kun punkt 2 og 3 er egentligt AI-arbejde. Resten er almindelig softwareudvikling: integrationer, databaser, køer, adgangsstyring og brugerflader. Derfor mener jeg at en fullstack-udvikler med erfaring i sprogmodeller passer bedre til de fleste SMV'er end en ML-specialist. Specialisten kan træne modeller, men det er sjældent dét der mangler.

OpenAI anbefaler selv samme rækkefølge i sin guide til modeloptimering: byg testsæt, arbejd med instruktionerne, og overvej først derefter at finjustere en model. Hvordan sådan en integration bygges med kø, logning og en plan for nedbrud, har jeg beskrevet i guiden til at integrere OpenAI eller Claude i dit system.

Dataingeniøren: når dine data er problemet

En dataingeniør bygger de rør der flytter data fra dine systemer til ét sted hvor de er rensede, ensartede og til at stole på. Det kaldes en datapipeline, og målet er typisk et datavarehus (en database bygget til analyse og rapporter) i fx BigQuery eller Snowflake.

Du har brug for en dataingeniør når dine data ligger spredt i mange systemer, og det er dét der står i vejen. Salg ligger i webshoppen, kunder i CRM'et og lager i ERP-systemet, ingen tal passer sammen, og rapporterne bygges i hånden i regneark hver måned. Dataingeniøren er også forudsætningen for en ML-ingeniør, for en model bliver aldrig bedre end de data den trænes på.

I en mindre virksomhed er opgaven dog ofte mindre end titlen antyder. At synkronisere to systemer eller samle tal til et dashboard kan en erfaren webudvikler sagtens bygge. Den egentlige dataingeniør bliver relevant når der er mange kilder, store datamængder, krav til historik og flere afdelinger der skal bruge de samme tal.

En AI-chatbot på din dokumentation kræver i øvrigt ikke en dataingeniør. Den kræver at dokumentationen er opdateret og dækker de spørgsmål kunderne stiller. Det er en redaktionel opgave, ikke en teknisk.

ML-ingeniøren: når du skal have din egen model

En ML-ingeniør (machine learning) træner, tester og driver modeller bygget på dine egne data. Det er relevant når opgaven handler om mønstre i tal og hændelser som ingen færdig sprogmodel kender: prognoser for efterspørgsel, prissætning, risikovurdering, svindeldetektion eller genkendelse af særlige fejl på billeder fra en produktion.

Arbejdet slutter ikke når modellen er trænet. Den skal sættes i drift, overvåges og trænes igen når virkeligheden ændrer sig, fx når kundernes adfærd skifter. Den del kaldes MLOps, og den fylder ofte mere end selve træningen.

Det kræver tre ting af dig: store mængder historiske data, data der er markeret med det rigtige svar (fx hvilke ordrer der faktisk var svindel), og et præcist mål for hvornår modellen er god nok. Mangler én af dem, har en ML-ingeniør ikke noget at arbejde med.

Mange tror at de skal bruge en ML-ingeniør for at "træne AI'en på deres egne data". Til tekstopgaver er det sjældent nødvendigt, for det løses typisk ved at sende de relevante data med i hvert kald. Finjustering af sprogmodeller er også blevet en smallere vej. Da jeg skrev indlægget i oktober 2026, oplyste OpenAIs dokumentation om fine-tuning at platformen til fine-tuning var ved at blive udfaset og ikke længere tog imod nye brugere.

Hvornår hver type ikke passer

Når en AI-udvikler ikke er nok

• Når opgaven er forudsigelser ud fra dine egne tal, fx lager, priser eller churn (kunder der opsiger). Sprogmodeller er stærke til tekst, ikke til mønstre i tusindvis af transaktioner.
• Når AI-funktionen er selve produktet, og præcisionen afgør om kunderne betaler. Så skal nogen kunne måle og forbedre modellen systematisk.
• Når data er så følsomme at de ikke må forlade dine egne servere. At køre en åben model selv kræver mere specialiseret driftsviden end et API-kald.

Når en dataingeniør er for tidligt

• Når du har to-tre systemer og en håndfuld rapporter. Så er en integration eller et rapportværktøj billigere.
• Når ingen har formuleret hvilke spørgsmål data skal svare på. Et datavarehus uden spørgsmål bliver et dyrt arkiv.

Når en ML-ingeniør er det forkerte valg

• Når du har nogle hundrede eksempler og ikke titusinder. Så er der ikke nok at træne på.
• Når en færdig sprogmodel med gode instruktioner løser det meste af opgaven. Start der, og vurder bagefter om resten er en specialist værd.
• Når der ikke er en plan for drift. En model der ikke overvåges og gentrænes, bliver dårligere over tid uden at nogen opdager det.

Er du i tvivl om hvilken type projektet overhovedet kræver, så start med min beslutningsguide til hvilken udvikler du har brug for. Skal AI være en strategisk del af dit produkt, kan en fractional CTO hjælpe med at lægge retningen før du hyrer specialister.

Næste skridt: test idéen på færdige modeller først

Den billigste måde at finde ud af hvem du skal bruge, er at teste idéen på færdige modeller med dine egne data. Så ved du om opgaven kan løses som en integration, og hvis ikke, ved du præcis hvad en specialist skal løse.

1. Beskriv opgaven med rigtige eksempler. Find 20-50 mails, dokumenter eller sager, og skriv hvad det rigtige resultat ville være for hver af dem.
2. Find ud af hvor data ligger. Hvilke systemer, hvilke formater, og hvem har adgang?
3. Byg en lille prototype. Kobl en færdig model på dine eksempler, og mål hvor ofte den rammer rigtigt.
4. Beslut ud fra resultatet. Rammer den godt nok, bygger du den færdige integration. Rammer den ikke, kan du se om problemet er data eller model, og dermed om næste skridt er en dataingeniør eller en ML-ingeniør.

Jeg bygger selv den slags integrationer med Laravel og React, også i systemer der allerede kører. Større opgaver starter med et betalt forprojekt til fast pris, så omfang og pris er afklaret før der bygges, og du ejer koden fra første dag. Se hvordan jeg griber det an på siden om webapps og platforme.

Ofte stillede spørgsmål

Hvad er forskellen på en data scientist og en ML-ingeniør?+

En data scientist analyserer data og bygger modeller for at finde svar, mens en ML-ingeniør sørger for at modellerne kører stabilt i et produkt. Data scientisten spørger hvad data kan fortælle, ML-ingeniøren hvordan modellen holder i drift. I små teams glider rollerne ofte sammen. Har du brug for analyser og rapporter frem for en model i et produkt, er en data scientist eller dataanalytiker det rette valg.

Kan jeg skifte AI-udbyder senere?+

Ja, hvis integrationen er bygget til det. Læg kaldene til modellen bag ét lag i din egen kode, så resten af systemet ikke ved om svaret kommer fra OpenAI, Anthropic eller Google. Så kan du skifte udbyder eller model når priser og kvalitet ændrer sig. Gem også dine testeksempler, så du kan måle om den nye model er lige så god som den gamle.

Er det sikkert at sende kundedata til OpenAI eller Claude?+

Det kan det være, men du skal tage stilling før du sender noget. De store udbydere tilbyder typisk databehandleraftaler og erhvervsvilkår hvor data ikke bruges til træning, og nogle tilbyder databehandling i EU. Send kun de data opgaven kræver, og fjern persondata hvor det er muligt. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du behandler følsomme oplysninger.

Skal jeg ansætte en AI-udvikler fast?+

Sjældent til de første AI-funktioner. En afgrænset funktion kan bygges og testes af en ekstern udvikler, og bagefter handler det mest om vedligehold og justeringer. En fast ansættelse er fornuftig når AI er kernen i dit produkt, og der skal udvikles på det hver dag i flere år. Så er viden om dine data og kunder i huset mere værd end fleksibiliteten.