Hvad er machine learning og hvordan fungerer det?

Machine learning er blevet et af de ord, der dukker op i alt fra kundeservice og marketing til drift og økonomi. For mange føles det stadig som noget, der hører hjemme hos datafolkene, mens projekterne bare skal “implementere en AI-løsning”. Det er en opskrift på uklare krav, skuffede forventninger og modeller, der aldrig kommer i stabil drift.

Når man ser machine learning som en praktisk metode til at løse afgrænsede problemer med data, bliver det langt mere håndgribeligt. Og så bliver det også tydeligt, hvad der faktisk skal styres i et ML-projekt: data, mål, kvalitet, risici, governance og forankring i forretningen.

Machine learning som del af kunstig intelligens

Kunstig intelligens (AI) er en paraplybetegnelse for systemer, der kan udføre opgaver, man normalt forbinder med menneskelig “intelligens”: genkendelse, sprog, planlægning, beslutninger. Machine learning (ML) er en del af AI og dækker de metoder, hvor et system lærer mønstre fra data frem for at følge faste, menneskeskrevne regler.

Et klassisk eksempel: Et regelbaseret system til at fange spam kan have regler som “hvis emnelinjen indeholder X, så er det spam”. Et ML-baseret spamfilter lærer i stedet statistiske mønstre i mange mails og deres labels (spam/ikke spam). Det gør løsningen mere robust over tid, men også mere afhængig af træningsdata og løbende vedligehold.

ML handler derfor mindre om “magi” og mere om sandsynligheder: Modellen giver et kvalificeret gæt baseret på erfaringer i data.

Hvad betyder det, at en model “lærer”?

En ML-model lærer ved at justere sine interne parametre, så den bliver bedre til en opgave målt på en konkret målemetode. “Bedre” kan være højere træfsikkerhed, færre falske alarmer, lavere fejl i en prisprognose eller hurtigere beslutninger med samme kvalitet.

Læring kræver tre ting:

1. et mål (hvad er et godt resultat?)
2. data (hvad kan modellen lære af?)
3. feedback (hvordan finder vi ud af, om den rammer rigtigt?)

Når de tre ting er uklare, ender man ofte med en model, der ser imponerende ud i en demo, men falder igennem i drift.

Tre hovedtyper af machine learning

De fleste ML-opgaver kan placeres i én af tre kategorier. Det er nyttigt i projektarbejde, fordi kategorien ofte afgør både dataarbejdet, teststrategien og hvordan man måler effekt.

Type	Hvad får modellen?	Typiske opgaver	Eksempel i praksis	Projektmæssig konsekvens
Superviseret læring	Data med facit (labels)	Klassifikation, regression	“Er denne transaktion svindel?” / “Hvad bliver efterspørgslen?”	Kræver historik med korrekt facit og klar definition af label
Uovervåget læring	Data uden facit	Segmentering, mønstre, afvigelser	Kundesegmenter baseret på adfærd	Output skal fortolkes og valideres med domæneviden
Forstærkende læring	Belønning for handlinger	Optimering over tid	Agent der lærer en strategi i et miljø	Kræver simuleret eller kontrolleret miljø og stærk sikkerhed

I almindelige forretningsprojekter i Danmark er superviseret læring klart mest udbredt, fordi mange organisationer allerede har historiske sager, hændelser eller transaktioner, der kan bruges som træningsgrundlag.

Sådan ser en ML-løsning ud i praksis (uden matematik)

Det hjælper at tænke i en pipeline:

Data ind → forbehandling → model → output → handling → måling → ny læring.

Forbehandling er ofte det største arbejde. Data skal renses, samles, og man skal sikre, at felter betyder det samme på tværs af kilder. Nogle gange skal data også “oversættes” til features, som modellen kan bruge: fx antal køb sidste 30 dage, tid siden sidste login, eller variation i en sensors temperatur.

Selve modellen kan være alt fra et beslutningstræ til et neuralt netværk. Valget afhænger af problemtype, krav til forklarlighed, datamængde og hvor hurtigt man skal kunne opdatere modellen.

Et enkelt, men vigtigt princip: En ML-model er ikke “færdig”, når den er sat i drift. Den skal overvåges, fordi virkeligheden ændrer sig. Kundeadfærd, produkter, processer og datakilder driver, og så driver modellens kvalitet også.

Typiske algoritmer du vil støde på

Mange projekter behøver ikke en dyb teknisk gennemgang, men projektlederen har gavn af at kende de mest almindelige byggesten og deres tradeoffs.

• Beslutningstræer og Random Forest: ofte gode som robuste baseline-modeller, relativt nemme at forklare.
• Gradient boosting (fx XGBoost/LightGBM): stærke på tabulære forretningsdata, kræver omhyggelig tuning.
• Neurale netværk (deep learning): stærke på billeder, lyd og tekst, kræver typisk flere data og mere compute.
• Clustering (fx k-means): bruges til at gruppere uden facit, kræver fortolkning og stabilitets-check.

Det vigtige er ikke at kunne vælge algoritmen alene, men at kunne stille de rigtige spørgsmål om krav, risiko og drift.

Hvornår giver machine learning mening i et projekt?

ML er oplagt, når regler enten bliver for komplekse, eller når der er så mange undtagelser, at vedligehold af regler bliver dyrt. ML er mindre oplagt, når problemet i virkeligheden handler om procesdesign, datakvalitet eller manglende beslutningskompetence.

Efter en kort afklaring med forretning og datafolk kan man ofte spotte et godt ML-case ved følgende tegn:

• Hurtigt skiftende mønstre
• Mange datapunkter, få klare regler
• Gentagende beslutninger med stor volumen
• Historik med nogenlunde stabilt facit
• Høj værdi pr. forbedring: små procentpoint betyder meget i kroner, tid eller risiko
• Tydeligt beslutningspunkt: hvem gør hvad, når modellen giver et output?
• Mulighed for læring over tid: der kommer løbende nye data, som kan bruges til gen-træning

Bemærk, at “vi har en masse data” ikke er det samme som “vi har data, der kan bruges”. Brugbarhed handler om definitioner, dækning, bias, rettigheder og kvalitet.

Machine learning i brancher og funktioner: hvad ser man oftest?

I finans ser man ofte kreditvurdering, svindeldetektion og automatiseret dokumentklassifikation. I sundhed og life science handler det ofte om billedanalyse, triage og beslutningsstøtte. I marketing og salg er det typisk churn-modeller, segmenter og anbefalinger. I produktion og logistik er det prognoser, ruteoptimering og prediktivt vedligehold.

Fællesnævneren er ikke branchen, men at der findes et gentagende beslutningsmønster og data, der afspejler virkeligheden godt nok.

Et ML-projekt starter derfor ofte med at skrive “beslutningen” ned i almindeligt sprog: “Vi vil prioritere de 5 procent af sager, der mest sandsynligt bliver eskaleret” eller “Vi vil forudsige efterspørgsel pr. vare pr. uge, så vi kan planlægge indkøb”.

Fra idé til drift: et projektforløb der virker

Mange ML-indsatser fejler, fordi man planlægger dem som klassisk systemudvikling: kravspecifikation, byg, test, release. ML kræver et mere eksperimentelt forløb, hvor læring og målinger styrer prioriteringerne.

En praktisk måde at køre det på er at fastholde få, tydelige faser med konkrete leverancer:

1. Problem og succeskriterier: Definér beslutningen, KPI’er og fejltyper der gør mest ondt.
2. Data-afklaring: Identificér kilder, datakvalitet, rettigheder, og hvordan “facit” ser ud.
3. Baseline og proof of value: Byg en enkel model og sammenlign med nuværende praksis.
4. Pilot i proces: Sæt output ind i en rigtig arbejdsgang, men med kontrolleret risiko.
5. **Drift og MLOps: Overvågning, gen-træning, versionsstyring, adgang og incident-håndtering.
6. Skalering: Udvid til flere enheder, flere datakilder eller flere beslægtede use cases.

Det lyder lineært, men man hopper ofte tilbage, især mellem data-afklaring og baseline. Det er normalt. Planen skal kunne rumme iteration.

Det projektlederen typisk undervurderer: data, ejerskab og adfærd

Det største tekniske problem i ML er sjældent selve modellen. Det er dataflowet og stabiliteten: at de samme felter findes i morgen, at definitioner ikke ændrer sig lydløst, og at man kan spore, hvorfor modellen gav et bestemt output.

Det største organisatoriske problem er adoption: Hvis brugerne ikke stoler på output, bliver det ignoreret eller omgået. Hvis output ikke passer ind i en beslutningsproces, ender det som et dashboard, ingen åbner efter tre uger.

Nogle organisationer lykkes ved at starte med “human-in-the-loop”: Modellen foreslår, mennesket beslutter, og feedback bliver gemt. Det giver læring og tillid, før man automatiserer mere.

Kvalitet, bias og ansvar: risici du skal styre aktivt

ML kan gøre beslutninger hurtigere, men kan også gøre fejl hurtigere. En model kan være præcis i gennemsnit og stadig være uacceptabel i kritiske situationer, fx hvis den overser få, men vigtige tilfælde (falske negativer).

Bias er en anden klassiker: Hvis historiske data afspejler skævheder, kan modellen gentage dem. Det kan ramme både compliance, omdømme og reelt forretningsresultat.

Derfor giver det mening at etablere en enkel governance-ramme, som er til at bruge i hverdagen:

• Datakontrakter: aftal faste definitioner, ejerskab og ændringsstyring af de vigtigste felter
• Modelovervågning: mål drift i inputdata og fald i performance over tid
• Forklarbarhed: vælg forklaringsniveau efter risiko, og dokumentér hvad der kan forklares
• GDPR og sikkerhed: afklar formål, hjemmel, adgang, logning og opbevaring før pilot
• Roller og ansvar: beslut hvem der ejer modellen, hvem der godkender ændringer, og hvem der responderer på incidents

Det er klassisk projektledelse, bare anvendt på et produkt, der ændrer sig over tid.

Spørgsmål du kan stille, når nogen siger “vi bruger AI”

Det er fristende at acceptere AI som en sort boks, men et par konkrete spørgsmål kan hurtigt afklare modenhed og risiko.

Start med “Hvad er outputtet?” og “Hvad gør vi anderledes på baggrund af det?”. Gå så videre til “Hvilke data træner I på, og hvordan ved I, at facit er korrekt?”. Spørg også “Hvordan opdager vi, at modellen bliver dårligere?” og “Hvad er planen for gen-træning?”.

Et sidste spørgsmål, der ofte afslører meget: “Hvad er baseline, og hvor meget bedre bliver det end det, vi gør i dag?”. Hvis ingen kan svare, er det svært at styre et projekt mod en målbar gevinst.

Machine learning bliver først en styrke i en organisation, når det behandles som en disciplin med tydelige mål, tydelig drift og tydelige beslutninger, ikke som et enkeltstående IT-indkøb. BlivProjektleder.dk arbejder netop med at gøre den slags teknologier konkrete i projektarbejdet, så både forretning og teknik kan mødes om det, der betyder noget: effekt, risiko og en løsning der faktisk bliver brugt.