Make or Buy: Tekniske beslutningsfaktorer for AI-komponenter – Den systematiske guide for mellemstore virksomheder

Du står over for en af de vigtigste strategiske beslutninger i de kommende år: Hvilke KI-komponenter udvikler I selv, og hvilke skal I købe eksternt?

Svaret afgør millionbeløb, flere års udviklingstid – og i sidste ende jeres konkurrencefordel. De fleste virksomheder vælger dog på mavefornemmelsen – en dyr fejltagelse.

Erfaringen viser: Virksomheder, der systematisk vurderer mellem egenudvikling og indkøb, realiserer ofte deres KI-projekter hurtigere og til lavere samlede omkostninger.

Beslutningen er kompleks, fordi KI ikke er én teknologi. En kundesupport-chatbot stiller helt andre krav end et machine learning-system til produktionsoptimering.

Denne artikel giver dig det nødvendige beslutningsgrundlag – struktureret, praksisnært og uden marketingfloskler.

Hvad betyder Make or Buy for KI-komponenter?

Make or Buy dækker i KI-sammenhæng meget mere end det klassiske spørgsmål om “egenudvikling eller indkøb”.

I KI-systemer afgør du på flere arkitekturniveauer: Foundation model, applikationslogik, datainfrastruktur og brugergrænseflade.

De fire beslutningsniveauer

Foundation Models: Her er beslutningen for det meste klar – du køber. Uanset om det er GPT-4, Claude eller Gemini: At træne egne Large Language Models koster millioner og giver sjældent mening for de fleste virksomheder.

Applikationslogik: Det centrale i jeres KI-løsning. Det er her, systemet enten dækker standardprocesser eller skaber reel differentiering.

Datainfrastruktur: Vektordatabaser, ETL-pipelines, overvågningssystemer. Ofte undervurderet, men afgørende for skalerbarhed og performance.

User Interface: Der findes et hav af chatinterfaces. Specielle indtastningsmasker til præcis jeres workflow er dog en sjældenhed.

Hybride tilgange som standard

Praksis viser: Rene make- eller buy-beslutninger er sjældent optimale. Succesfulde virksomheder kombinerer klogt.

De bruger eksterne API’er til basis-KI-funktioner, men udvikler den specifikke applikationslogik selv. Resultatet: Hurtig time-to-market og fuld kontrol over differentiering.

Men pas på hybris-effekten: Mange teams overvurderer egne evner og undervurderer kompleksiteten. En ChatGPT-wrapper er ikke en KI-strategi.

Tekniske beslutningsfaktorer i detaljer

Eksisterende IT-infrastruktur

Jeres nuværende it-infrastruktur er den største cost driver – eller besparelse – i KI-projekter.

On-premise-systemer kræver ofte omfattende integration. Cloud-native virksomheder kan hurtigt skalere. Men: Legacy-systemer er ikke nødvendigvis et showstopper for egenudvikling.

Den afgørende faktor er API-egnetheden af jeres eksisterende systemer. Moderne API’er muliggør elegant integration – forældede grænseflader tvinger jer til dyre workaround-løsninger.

Vurder interne kompetencer ærligt

Har I de rette folk? Det afgør, om I lykkes eller fejler.

KI-udvikling kræver mere end Python-kundskaber. I har brug for data scientists, ML engineers, DevOps-specialister og domee-eksperter – en sjælden kombination.

Realitetstjek: Kan I finansiere et komplet KI-team i mindst to år? Hvis ikke, taler meget for eksterne partnere eller færdige løsninger.

Sikkerhed og compliance

Databeskyttelse er ikke til forhandling – men behøver heller ikke at dræbe innovationen.

GDPR og branchespecifikke regulativer sætter klare rammer. Cloud-løsninger har ofte højere sikkerhedsstandarder end interne systemer – forudsat at de er korrekt konfigureret.

Det afgørende er dataklassificering: Hvilke data må behandles i eksterne systemer? Hvilke skal forblive interne? Denne adskillelse bestemmer jeres arkitekturvalg.

Skalérbarhed og performance

KI-workloads er uforudsigelige. En viral chatbot kan overbelaste din infrastruktur på timer.

Cloud-services tilbyder elastisk skalering – mod de tilsvarende omkostninger. Egen drift giver kontrol, men kræver gennemtænkt kapacitetsplanlægning.

Tommelfingerregel: Ved uforudsigelige lasttoppe er cloud-API’er overlegne. Ved konstant, stort volumen betaler det sig ofte med egne systemer.

Økonomiske vurderingskriterier

Beregn Total Cost of Ownership korrekt

De reelle omkostninger skjuler sig ofte i detaljer, som din CFO først opdager senere.

Udviklingsudgifter er kun begyndelsen. Drift, opdateringer, compliance, monitorering og support øger TCO betydeligt. Med cloud-services betaler du løbende, mens egne løsninger typisk får eksploderende følgeomkostninger.

Et realistisk eksempel: En intern chatbot koster 150.000 euro at udvikle, men 80.000 euro om året for drift og videreudvikling. Efter tre år: 390.000 euro – uden garanti for opdateringer eller nye funktioner.

Gør Return on Investment målelig

KI-ROI er målbar, hvis du fastsætter de rigtige metrikker.

Undgå bløde nøgletal som “forbedret brugeroplevelse”. Fokuser på hårde fakta: sparede arbejdstimer, reduceret ekspeditionstid, øget konvertering.

Et eksempel fra maskinindustrien: Automatiseret tilbudsudarbejdelse reducerer tidsforbruget fra 8 til 2 timer per tilbud. Ved 200 årlige tilbud svarer det til 1.200 sparede timer – og med en intern timeløn på 80 euro giver det 96.000 euro i besparelse årligt.

Risikofordeling mellem Make og Buy

Begge tilgange indebærer forskellige risici – kender du din tolerance?

Make-risici: Teknologisk forældelse, personaleudfald, budgetoverskridelser, sikkerhedshuller. Til gengæld: fuld kontrol og uafhængighed.

Buy-risici: Vendor lock-in, prisstigninger, serviceudfald, databrudsproblemer. Til gengæld: forudsigelige omkostninger og professionel support.

Den kloge strategi: Diversificér risko. Udvikl kritiske kernefunktioner selv, outsourc standardprocesser.

Finansieringsmodeller og budgetplanlægning

KI-projekter fejler ofte på grund af ufleksibel budgetlægning.

Egenudvikling kræver høje forudinvesteringer. Cloud-services fungerer som et abonnement. Hybride modeller kombinerer begge tilgange.

For mellemstore virksomheder anbefales ofte “Start small, scale smart”: Start med cloud-services, saml erfaring og besluts om egenudvikling senere.

Brancherelaterede særegenheder

Maskinindustri og Industri 4.0

I industrien afgør domænespecifikke behov ofte valget mellem make og buy.

Produktionsoptimering stiller krav om dyb procesindsigt. Standard-KI-værktøjer forstår ikke, hvorfor jeres CNC-maskine reagerer anderledes ved bestemte materialer. Her kan egenudvikling betale sig.

Automatisering af dokumenter kan derimod standardiseres. Tilbud, kravspecifikationer og servicerapporter følger ens mønstre – uanset producent.

SaaS og digitale tjenesteudbydere

SaaS-virksomheder har ofte de bedste forudsætninger for KI-egenudvikling: Cloud-native infrastruktur, agile teams og datadrevet kultur.

Men husk: Jeres kernekompetence ligger i produktet, ikke i KI-forskning. Brug eksisterende API’er til standardfunktioner, og udvikl kun det, der giver reel differentiering.

Et tip fra praksis: A/B-tests med forskellige KI-tjenester kan hjælpe. Hvad fungerer bedst – GPT-4 eller Claude til netop jeres anvendelse?

Traditionelle servicevirksomheder

Rådgivere, advokatkontorer og bureauer står over for særlige udfordringer: Legacy-systemer, regulatoriske krav og forsigtige ledelseslag.

Her er den trinvise tilgang ofte optimal. Start med sikre, afgrænsede use cases. En intern chatbot for virksomhedsviden indebærer færre risici end automatiseret kundesupport.

Praksisafprøvede beslutningsscenarier

Scenarie 1: Automatisering af kundesupport

Thomas fra maskinindustrien vil automatisere reservedelssupporten. 80 procent af henvendelserne er standardspørgsmål til leveringstider og kompatibilitet.

Make-variant: Internt udviklet RAG-system med egen reservedelsdatabase. Omkostninger: 200.000 euro, 8 måneders udvikling.

Buy-variant: Chatbot-as-a-Service med API-integration. Omkostninger: 1.500 euro pr. måned, 4 uger til opsætning.

Anbefaling: Start med buy, udvikl selv videre til avancerede funktioner. Chatbotten indsamler først data om de typiske forespørgsler – disse indsigter styrker senere egenudviklingen.

Scenarie 2: Automatisering af dokumenter

Anna fra SaaS-branchen ønsker at personalisere onboarding-materiale automatisk. Hver ny kunde får en skræddersyet guide.

Make-variant: Template-motor med LLM-integration og kunde-data-pipeline. Omkostninger: 120.000 euro, 5 måneder.

Buy-variant: Document-generation API med egne templates. Omkostninger: 800 euro pr. måned per 1000 dokumenter.

Anbefaling: Hybridtilgang. Standardtemplates via eksterne API’er, specifikke tilpasninger udvikles internt.

Scenarie 3: Predictive Maintenance

Markus vil forudsige nedbrud i it-infrastrukturen. Udfordringen: 15 forskellige legacy-systemer med forskellige dataformater.

Make-variant: Eget ML-system med integration til alle legacy-systemer. Omkostning: 350.000 euro, 12 måneder.

Buy-variant: Enterprise monitoring med KI-funktioner. Omkostning: 3.000 euro pr. måned, 6 ugers integration.

Anbefaling: Trinvis tilgang. Implementér standardovervågning med det samme, byg custom ML til de kritiske systemer senere.

Framework for det rigtige valg

Brixon beslutningstræ

Systematiske beslutninger kræver strukturerede frameworks. Denne tjekliste hjælper til en objektiv vurdering:

1. Strategisk relevans: Er denne KI-funktion kerneforretning eller commodity?
2. Differentieringspotentiale: Giver egenudvikling reel konkurrencefordel?
3. Interne kompetencer: Har I de nødvendige færdigheder, eller kan de hurtigt opbygges?
4. Tidspres: Hvor hurtigt skal I levere?
5. Budgetfleksibilitet: Kan I håndtere store forhåndsinvesteringer?
6. Dataejerskab: Skal følsomme data forblive internt?
7. Skaleringskrav: Er belastningstoppe forudsigelige?

Anvendelse af vurderingsmatrix

Vurder hver faktor fra 1 til 5. En score over 25 taler for make, under 15 for buy, og midten for hybride tilgange.

Men pas på falsk præcision: Frameworket giver retning – ikke endelig sandhed. Mavefornemmelse og erfaring er fortsat afgørende.

Timing af beslutningen

Mange virksomheder beslutter for tidligt eller for sent. Det optimale tidspunkt er efter proof-of-concept-fasen.

Først når I forstår, hvad jeres KI-løsning faktisk skal kunne, kan I vælge fornuftigt mellem make og buy. Teoretiske vurderinger fører ofte på afveje.

Konklusion og anbefalinger

Make-or-buy-beslutningen for KI er mere kompleks end ved traditionel software – men kan også løses systematisk.

Succesfulde virksomheder arbejder i etaper: De starter med cloud-services, samler erfaring og udvikler derefter strategisk vigtige komponenter selv.

Denne strategi minimerer risiko og maksimerer læringseffekter. Du undgår både vendor lock-in-fælden og overmod inden for egenudvikling.

Næste skridt: Identificér en konkret use case, og gennemgå beslutningsframeworket. Få rådgivning fra eksperter – men beslut selv.

KI er for vigtig for din forretning til at overlade beslutningen til tilfældigheder.

Ofte stillede spørgsmål