Samtalen foregår i mødelokaler og på Slack-kanaler over hele landet lige nu: "Vi skal have AI ind i forretningen - vi har nok brug for en Python-udvikler." Det lyder fornuftigt. Det føles teknisk kompetent. Og det er næsten altid den forkerte konklusion.
Misforståelsen er ikke dum - den har en forklaring. Men den koster virksomheder tid, penge og momentum, fordi den fører til ansættelser og projekter der aldrig rigtig forbindes med den forretning de skulle understøtte. Inden du skriver en jobannonce eller booker en konsulent, er der én distinktion du skal have på plads.
To helt forskellige discipliner med samme navn
Når folk siger "AI-udvikling", mener de som regel to vidt forskellige ting - og det er her forvirringen starter.
Den ene disciplin er at bygge AI: træne modeller, finjustere dem på specifikke datasæt, bygge ML-pipelines, eksperimentere med arkitekturer og evaluere modelpræstation. Det er forskning og ingeniørkunst på samme tid. Det kræver dyb matematisk forståelse, kendskab til frameworks som PyTorch og TensorFlow, og det er et fuldtidsfag i sig selv. Her er Python ikke bare et valg - det er standardsproget, fordi hele forskningsøkosystemet er bygget op omkring det.
Den anden disciplin er at bruge AI: kalde en model der allerede eksisterer - OpenAI's GPT, Anthropic's Claude, Google's Gemini eller en hvilken som helst anden - og koble den ind i et eksisterende system så den løser et konkret forretningsproblem. Det er integration. Det er API-kald. Det er den opgave langt de fleste danske virksomheder faktisk har foran sig.
Disse to discipliner forveksles konstant, og det er ikke en uskyldig fejl.
Hvorfor Python dominerer i modeludvikling - og hvorfor det ikke er relevant for dig
Pythons dominans i AI-verdenen er reel og velbegrundet. Biblioteker som NumPy, Pandas, scikit-learn og PyTorch er skrevet til Python, og Hugging Faces primære bibliotek er ligeledes Python-baseret. Forskningsartikler leveres med Python-eksempelkode. Datavidenskabsmiljøet har standardiseret sig på sproget over det seneste årti.
Men det er forskningsmiljøets valg - ikke et krav der automatisk nedarves til enhver virksomhed der vil bruge AI i sin forretning. Fordi den model du vil bruge, er allerede bygget. Den er allerede trænet. Den sidder bag et API og venter på at blive kaldt.
Et API-kald er et API-kald. Det er HTTP. Det har eksisteret i tyve år, og alle moderne programmeringssprog kan gøre det.
Hvad AI-implementering faktisk er
Lad os være konkrete. Vil du have AI til at opsummere kundehenvendelser inden de lander hos en supportmedarbejder? Det er et API-kald til en sprogmodel med en tekststreng som input og en opsummering som output. Vil du generere produktbeskrivelser baseret på specifikationer fra dit PIM-system? Samme mekanisme. Vil du have en chatbot der kan svare på spørgsmål om jeres egne dokumenter? Det er en kombination af et søgekald og et API-kald - stadig integration, ikke modeltræning.
Den relevante kompetence her er ikke kendskab til Python. Den relevante kompetence er at forstå:
Hvilke systemer AI'en skal forbindes til - dit CRM, dit ERP, din webshop, dit CMS - og hvordan data flyder mellem dem. En udvikler der aldrig har set jeres stack er ikke et godt udgangspunkt, uanset hvad de ved om Python.
Hvordan man designer en integration der holder - fejlhåndtering, timeouts, fallback-logik, logging, og hvad der sker når modellen returnerer noget uventet. Det er software engineering, ikke datavidenskab.
Hvad forretningen faktisk har brug for - hvilken adfærd der skal ændres, hvilken proces der skal forbedres, og hvordan succes måles. Det kræver forretningsforståelse, ikke sprogkendskab.
PHP kan kalde OpenAI's API. C# kan. JavaScript kan. Java kan. Go kan. Ruby kan. Sproget er ligegyldigt for denne opgave.
Hvad misforståelsen koster i praksis
Når en virksomhed ansætter en Python-udvikler til "AI-projektet" uden at have tænkt over hvad projektet egentlig er, sker der typisk et af to ting.
Det første scenarie: Python-udvikleren er dygtig til modeltræning og dataanalyse, men har aldrig integreret med et Dynamics 365-system, et WooCommerce-setup eller et legacy-ERP fra 2008. De bygger en løsning der virker isoleret - en microservice der teknisk set kalder en AI-model korrekt - men som aldrig rigtig kobles til de systemer den skulle forbedre. Den lever i sin egen boble, ingen andre i teamet forstår den, og om et år er den forældet og uvedligeholdt.
Det andet scenarie: Python-udvikleren er faktisk en ML-ingeniør der begynder at tale om finjustering, embeddings og vektordatabaser. Det er fascinerende. Det er også sandsynligvis et svar på et spørgsmål ingen stillede, fordi forretningsproblemet kunne løses med tre API-kald og en fornuftig prompt.
Begge scenarier har det til fælles at de starter med teknologien i stedet for problemet - og det er altid en dyr rækkefølge.
Hvornår Python faktisk er det rigtige svar
Der er tilfælde hvor Python-kompetencen er præcis det I har brug for, og det er værd at være ærlig om dem.
Hvis I har compliance-krav der betyder at data ikke må forlade jeres egne servere, har I brug for at køre en model lokalt. Det kræver Python-kendskab til at sætte op og vedligeholde. Hvis I har så store mængder domænespecifikke data at en generisk model ikke er præcis nok, og I vil finjustere en model på jeres egne data, er det et reelt ML-projekt - og så er Python det rigtige valg. Hvis I bygger et produkt hvor selve AI-modellen er kernen i forretningsværdien, ikke blot et værktøj i en eksisterende proces, er I i gang med at bygge AI, ikke implementere det.
Men de fleste danske SMV'er og mellemstore virksomheder er ikke i nogen af disse situationer. De har et konkret problem de vil løse med AI, og løsningen er at koble en eksisterende model ind i deres eksisterende systemer.
De spørgsmål der giver bedre beslutninger
Inden I hyrer nogen til jeres AI-projekt, er der tre spørgsmål der er mere værd end ethvert teknisk krav i en jobannonce:
Hvor skal AI'en leve i vores forretning? Ikke "hvad skal den kunne" - men præcist hvilken proces, hvilket system, hvilken brugerrejse skal den indgå i? Hvis I ikke kan svare på det, er I ikke klar til at hyre nogen endnu.
Hvilke systemer skal den forbindes til? AI'en i sig selv er ligegyldig hvis den ikke kan tale med det der allerede eksisterer. Den der skal implementere løsningen, skal kende eller hurtigt kunne lære de systemer I allerede bruger.
Hvem vedligeholder det om et år? AI-modeller opdateres, API'er ændres, forretningsbehov udvikler sig. En løsning ingen internt forstår er en teknisk gæld der vokser stille og roligt indtil den eksploderer.
Den rigtige rækkefølge
Start med forretningsproblemet. Beskriv præcist hvilken adfærd eller proces I vil ændre, og hvad der ville se anderledes ud hvis det lykkes. Kortlæg derefter hvilke systemer der er involveret - hvorfra kommer data, hvortil skal resultater, hvem skal bruge det og hvordan.
Når det billede er klart, ved I hvilke tekniske kompetencer der faktisk er nødvendige. Og ni ud af ti gange er svaret ikke "en der er god til Python" - det er "en der kender vores systemer og ved hvordan man designer en integration der holder."
Det kan være en automatiseringsplatform der løser halvdelen af det uden en eneste linje kode. Det kan være en webudvikler der allerede kender jeres stack og kan tilføje et API-kald til en eksisterende løsning. Hvis I overvejer automatisering og integrationer mere bredt, er AI sjældent et separat projekt - det er et ekstra lag ovenpå det I allerede har.
Den udvikler der allerede kender jeres systemer er ofte det bedste udgangspunkt for et AI-projekt. Og hvis den kompetence ikke findes internt, er det integrationserfaring I skal købe - ikke et bestemt kodesprog. Sproget er en implementeringsdetalje. Forretningsforståelsen og systemkendskabet er det der afgør om projektet faktisk lykkes.
Stil bedre spørgsmål til din næste udviklerkontakt. "Har du erfaring med Python?" er det forkerte spørgsmål. "Kender du de systemer vi allerede bruger, og har du bygget integrationer der lever i produktion et år efter?" - det er spørgsmål der afslører om vedkommende kan løse jeres problem.
