AI-automatisering for små og mellemstore virksomheder: hvor starter man?

“AI-automatisering til virksomheder” er en søgning uden et brugbart svar på overordnet niveau, fordi det ærlige svar er “det kommer an på, hvilke tre timer af nogens uge I gerne vil have tilbage.” De virksomheder, der reelt får værdi ud af AI-automatisering, startede ikke med teknologien. De startede med en konkret, gentagen, kedelig opgave og arbejdede baglæns derfra.

Start med opgaven, ikke teknologien

Det fejlmønster vi ser oftest, er hverken en dårlig model eller en dårlig prompt — det er at starte med “vi burde gøre noget med AI” og først bagefter lede efter et problem at hægte det på. Det giver en demo, ikke et system, der virker, og demoer overlever sjældent mødet med rigtige data.

Et bedre startspørgsmål: hvad gør en medarbejder hver uge, som er gentaget, regelstyret nok til at beskrive, og kedeligt nok til at automatisering rent faktisk ville blive budt velkommen frem for modstået? Kategorisering af indgående supporthenvendelser. Udkast til førstesvar på gængse forespørgselstyper. Udtrækning af strukturerede data fra PDF’er, der ankommer på mail. Besvarelse af “hvor er min ordre” ud fra en vidensbase i stedet for en persons hukommelse. Det er ikke glamourøst, og det er præcis der, automatisering tjener sig selv ind.

Hvad et pilotprojekt faktisk skal bevise

Vi kører de fleste AI-projekter som et fast, flerugers pilotprojekt, der ender med en fungerende prototype og reelle tal — ikke en slide, der lover, hvad AI teoretisk kunne gøre, men et system testet mod jeres egne data, med et målt svar på “virker det godt nok til at kunne stoles på.”

Et pilotprojekt, man kan stole på, besvarer tre spørgsmål.

Hvor ofte har det ret? Ikke “virker det i demoen” — hvor ofte producerer det et korrekt eller acceptabelt resultat på tværs af et reelt udsnit af jeres faktiske sager, inklusive de rodede.

Hvad sker der, når det tager fejl? Enhver automatisering har en fejlrate over nul. Spørgsmålet er, om et forkert svar bliver fanget, før det når en kunde, og hvad en menneskelig gennemgang ser, når sagen skal vurderes igen.

Sparer det reel tid? Automatisering, der kræver lige så meget gennemgang, som opgaven tog at lave i hånden, har ikke sparet noget — den har flyttet arbejdet til siden.

Datahåndtering er en del af pilotprojektet, ikke en eftertanke

For enhver virksomhed, der opererer under GDPR (i kraft siden maj 2018), er “hvilken model, og hvor ender dataene” ikke et sidespørgsmål — det er en designbetingelse fra dag ét, ligesom alt andet vi bygger. Vi bruger API-udbydere med vilkår om ingen træning på kundedata, eller EU-hostede modeller, netop så jeres data ikke fodrer nogens næste træningsrunde. Den beslutning skal træffes, før pilotprojektet starter, ikke revideres bagefter.

Spørgsmål	Hvorfor det betyder noget
Hvor rejser dataene fysisk hen	GDPR / datalokalitet
Bliver de brugt til modeltræning	Udbyderens vilkår, ikke en antagelse
Hvad er faldbacken ved lav sikkerhed	Afgør gennemgangsbyrden
Hvem gennemgår flagede sager	Bemanding, ikke kun værktøj
Hvordan måles nøjagtighed	Gør “det virker” til et tal

Retrieval slår som regel en større model

Et almindeligt instinkt er at ty til en kraftigere model, når resultaterne skuffer. Ofte ligger det egentlige hul i retrieval — systemet finder ikke de rette interne dokumenter, sager eller poster at basere svaret på, og ingen mængde modelkvalitet retter det. RAG (retrieval-augmented generation) og vektorsøgning findes netop fordi en models generelle viden ikke er det samme som jeres virksomheds specifikke viden, og det er som regel det sidste, der mangler. At få retrieval rigtigt er mindre glamourøst end at skifte model, og det er der, størstedelen af nøjagtigheden faktisk kommer fra.

Workflow-automatisering kræver ikke altid en model

Meget af det, der føles som “vi har brug for AI,” er i virkeligheden et rørlægningsproblem. Data, der ligger i ét system, skal udløse en handling i et andet, på et skema eller en trigger, uden nogen skønsmæssig vurdering involveret. Det er almindeligt workflow-automatisering og integrationsarbejde, og det er ofte hurtigere at bygge, billigere at drive og mere pålideligt end at sende en deterministisk opgave gennem en sprogmodel, fordi ordet “AI” stod i briefet.

Skalering efter pilotprojektet

Hvis pilotprojektet holder, handler skalering mindre om modellen og mere om den samme driftsdisciplin, ethvert produktionssystem har brug for: overvågning af, om nøjagtigheden driver over tid, en klar ejer af køen med flagede sager, så den ikke stille hober sig op, og en dokumenteret fallback for, hvornår automatiseringen skal give stafetten videre til et menneske frem for at gætte. Springer man den disciplin over, er det sådan et pilotprojekt, der virkede i test, stille forringes i produktion, uden at nogen bemærker det, før en kunde gør.

Det er også værd at beslutte på forhånd, hvad “færdig” betyder for selve pilotprojektet — et fast forløb på 3-5 uger virker, fordi det har en slutdato og et leverable, ikke en åben udforskning, der aldrig helt giver et tal, man kan handle på.

Hvor vi faktisk ville starte med jer

Vi beder om den konkrete opgave, et udsnit af rigtige (anonymiserede, hvor nødvendigt) data, og hvad “godt nok” betyder i tal, I allerede følger — svartid, fejlrate, timer brugt. Derfra beviser et kort pilotprojekt enten sagen med reelle tal eller udelukker den, før I har forpligtet reelt budget. Vores egne produkter, beskrevet på work-siden, er bygget efter samme instinkt: automatisér det kedelige, gentagne, og lad mennesker tage skønsmæssige beslutninger.

Pilotprojektets opgave er ikke at imponere jer. Den er at fortælle jer, med et tal, om det er værd at skalere.

Har I en konkret opgave i tankerne, er en samtale via kontaktformularen en hurtigere måde at teste ideen på end endnu en artikel om, hvad AI generelt kan.