Build vs. buy vs. partner: Skal I udvikle AI selv eller købe en løsning? (krav, governance og total cost)

Mange organisationer stiller stadig det samme spørgsmål, når AI rykker fra pilot til drift: Skal vi udvikle selv, købe en færdig løsning eller indgå et partnerskab? Det lyder som et teknologivalg, men i praksis er det en beslutning om forretning, ansvar, risici og kapitalbinding.

Den stærkeste beslutning opstår sjældent ud fra entusiasme alene. Den opstår, når use case, datagrundlag, governance og totalomkostninger bliver vurderet samlet.

Tre veje til den samme ambition

Når AI skal skabe reel værdi, er der grundlæggende tre modeller. Man kan bygge internt, købe en standardløsning eller arbejde sammen med en partner om at udvikle og drive løsningen. Hver model kan være den rigtige, afhængigt af hvor tæt AI ligger på virksomhedens kerne, og hvor meget kontrol man har brug for.

Det afgørende er, at valget ikke må blive ideologisk. Nogle teams foretrækker at bygge, fordi det føles strategisk. Andre køber hurtigt, fordi markedet bevæger sig. Begge tilgange kan være fornuftige, og begge kan blive dyre, hvis de vælges på et svagt grundlag.

Her er en enkel måde at skelne modellerne på:

• Build: Egen arkitektur, egne workflows, større kontrol
• Buy: Hurtigere implementering, standardiseret funktionalitet
• Partner: Delt udvikling, ekstern specialistviden, fælles leveranceansvar

En god tommelfingerregel er enkel: Jo mere unik jeres data og forretningslogik er, desto stærkere argument er der for at bygge helt eller delvist selv.

Start med forretningsværdien

Før teknik, før kontrakter, før modelvalg: Hvad er den konkrete værdi? Hvis AI-løsningen understøtter en standardfunktion, som mange virksomheder har brug for, er køb ofte rationelt. Det gælder blandt andet supportbots, dokumentklassifikation, generelle forecast-funktioner og dele af HR- og marketingarbejde.

Hvis løsningen derimod bliver en del af jeres konkurrencekraft, ser billedet anderledes ud. Det gælder især, når I råder over egne data, som markedet ikke har adgang til, eller når beslutningslogikken er tæt knyttet til jeres processer, kunder eller regulerede domæneviden.

Det er her, mange fejl bliver dyre.

Mange AI-projekter bliver vurderet ud fra, hvad der er teknisk muligt, ikke hvad der er strategisk vigtigt. Resultatet er ofte en imponerende demo uden varig effekt, eller en licensbaseret løsning, som løser noget generisk, men ikke det problem, der faktisk betyder mest.

Tre spørgsmål skaber ofte klarhed:

• Er dette en støttefunktion eller en differentierende kapabilitet?
• Har vi data, som giver en unik model- eller procesfordel?
• Er tid til marked vigtigere end maksimal kontrol det næste år?

Hvis svaret er “støttefunktion”, “nej” og “ja”, peger pilen ofte mod køb. Hvis svarene går den anden vej, bør intern udvikling eller partnerskab mindst være på bordet.

Kravene bestemmer mere, end mange tror

Valget mellem build, buy og partner bliver hurtigt formet af krav, som ikke står i salgsmaterialet. Databeskyttelse, informationssikkerhed, integrationsbehov og dokumentation vejer tungt, især i brancher med persondata, følsomme oplysninger eller skærpet tilsyn.

Ved intern udvikling får man større kontrol over dataflow, modelvalg og immaterielle rettigheder. Til gengæld følger et større ansvar. Man skal selv håndtere adgangsstyring, logging, sikkerhedsarkitektur, modelovervågning og ofte også dokumentation til interne og eksterne auditprocesser.

Ved køb flytter noget af den tekniske byrde ud til leverandøren, men ikke det juridiske ansvar. Hvis løsningen behandler personoplysninger, er virksomheden stadig ansvarlig for behandlingsgrundlag, dataminimering, transparens og passende sikkerhed. En databehandleraftale løser ikke alt. Den skal understøttes af reel leverandørkontrol, tydelige kontraktvilkår og en klar forståelse af, hvordan data bruges til drift, træning og support.

Partnerskabsmodellen ligger midt imellem. Den kan give højere hastighed og adgang til specialister, uden at man giver helt afkald på påvirkning af arkitektur og governance. Til gengæld stiller den store krav til IP-aftaler, rollefordeling og beslutningsprocesser.

Tabellen viser noget vigtigt: Der findes ingen gratis vej. Man bytter ikke kompleksitet væk. Man flytter den.

Governance er en driftsdisciplin

AI-governance bliver nogle gange behandlet som en slags ekstra lag, der kommer på senere. Det er en fejl. Governance er selve rammen for, om løsningen kan tåle at blive skaleret, revideret og brugt med tillid.

I praksis bør governance dække mindst fire områder: ansvar, dokumentation, risikostyring og menneskelig kontrol. Det gælder både for egenudviklede løsninger og indkøbte platforme. Kravene ændrer form, men de forsvinder ikke.

Hvis en model påvirker mennesker direkte, som ved rekruttering, kreditvurdering, sundhed, personaleledelse eller prioritering af sager, bør man tidligt afklare, om løsningen falder ind under skærpede krav i EU’s AI-forordning eller udløser en konsekvensanalyse efter GDPR. Det gælder også, når AI kun er en komponent i en større proces.

Et enkelt governance-minimum kan se sådan ud:

• Ejerskab: Navngiven forretningsejer, teknisk ejer og juridisk ansvarlig
• Risikoklassifikation: Vurdering af use case, datatyper, påvirkning og kritikalitet
• Dokumentation: Beskrivelse af model, datakilder, test, begrænsninger og beslutningslogik
• Kontrolmekanismer: Human-in-the-loop, audit trail, fallback-procedurer
• Leverandørstyring: SLA, sikkerhedskrav, revisionsadgang og exit-plan

Det lyder måske tungt. Det behøver det ikke være. En moden governance-model kan bygges trinvist, så krav og dokumentation følger løsningens risikoniveau.

Total cost of ownership er mere end licenser og løn

Mange vurderer AI-projekter ud fra de synlige poster: udviklingstimer, abonnementer og implementeringsomkostninger. Det er et for snævert billede. TCO bliver først retvisende, når man regner hele levetiden med.

Ved build er startomkostningerne ofte tydelige. Der skal bruges udviklere, dataingeniører, måske MLOps-kompetencer, testmiljøer, cloudkapacitet og tid til at opbygge en sikker og stabil drift. Den største økonomiske risiko ligger sjældent i første sprint, men i vedligeholdelsen: retræning, monitorering, opdatering af afhængigheder, sikkerhedsarbejde og personaleudskiftning.

Ved buy er fælden en anden. Tidsgevinsten kan være stor, men de løbende omkostninger kan vokse markant med brug, flere teams, API-kald, premium support, integrationer og tilkøb. En løsning, som er billig ved 20 brugere, kan se helt anderledes ud ved 2.000.

Partner-modellen kan være økonomisk attraktiv, når man vil undgå at opbygge alt selv, men stadig ønsker indflydelse på det, der skaber værdi. Den kræver dog tydelig økonomistyring. Ellers vokser projektet i omfang, uden at ansvar og gevinster følger med.

Når TCO skal vurderes seriøst, bør man medtage:

• rekruttering og oplæring
• integrationsarbejde
• informationssikkerhed og compliance
• support og incident-håndtering
• modelmonitorering og kvalitetskontrol
• skifteomkostninger ved exit eller ny leverandør
• tabt værdi ved forsinkelser

Opportunity cost bliver ofte overset. Hvis en intern løsning først er klar om 12 måneder, men markedet kræver handling nu, kan den tabte forretningsværdi være større end hele licensprisen på en ekstern løsning. Omvendt kan en hurtig standardløsning koste strategisk, hvis den låser jer til en generisk proces, som konkurrenterne også kan købe.

Hvornår giver partnerskab mest mening?

Partnerskab er ikke bare en mellemvej. I mange tilfælde er det den mest realistiske model, især når organisationen vil hurtigt i gang, men ikke vil afgive for meget kontrol over data, design og fremtidig videreudvikling.

Det ses ofte i tre situationer. Den første er, når virksomheden har stærk domæneviden, men mangler AI-specialister. Den anden er, når use casen er vigtig, men endnu ikke moden nok til, at en fuld intern platform kan forsvares. Den tredje er, når man vil bygge oven på en eksisterende foundation model eller ekstern AI-tjeneste, men selv eje proceslaget, kvalitetssikringen og de forretningskritiske regler.

Det er også her, kontrakter bliver strategiske dokumenter, ikke bare juridiske bilag.

Et godt partnerskab kræver, at følgende er afklaret tidligt:

• IP-rettigheder: Hvem ejer kode, prompts, workflows, træningsdata og afledte artefakter?
• Dataanvendelse: Må partneren bruge jeres data til træning, support eller produktforbedring?
• Exit-mulighed: Hvordan flyttes data, modeller og dokumentation ved ophør?
• Ansvar: Hvem håndterer fejl, bias, brud og regulatoriske spørgsmål?

Jo tydeligere disse punkter er, desto større frihed får virksomheden senere.

En praktisk beslutningsramme

Den bedste beslutning kommer sjældent fra en stor generel AI-strategi alene. Den kommer fra en disciplineret vurdering af hver enkelt use case. En kundevendt chatbot, et internt analyseværktøj og en risikomodel bør ikke nødvendigvis have samme leverancemodel.

En enkel beslutningsramme kan bruges på tværs af funktioner og brancher:

1. Definér use casens forretningsværdi og risikoniveau.
2. Kortlæg datagrundlag, datakvalitet og regulatoriske krav.
3. Vurdér behovet for tilpasning, forklarbarhed og integration.
4. Beregn TCO over mindst to til tre år, inklusive skjulte poster.
5. Test leverancemodellen i et afgrænset pilotforløb med klare succeskriterier.

Det giver et langt bedre beslutningsgrundlag end at spørge, om man “tror mest på” at bygge eller købe.

For mange organisationer bliver den stærkeste model en kombination: køb af standardkapabiliteter, partnerskab om specialiserede lag og intern udvikling dér, hvor data, ansvar og forretningsværdi virkelig gør forskellen. Det er ikke et kompromis. Det er ofte et tegn på moden AI-ledelse.