Fra måneder til dage: Et casestudie i hurtig AI-integration
Detaljeret gennemgang af, hvordan vi integrerede AI-funktioner i tre produktionsapplikationer - DocubotAI, My Family Recipes og vores interne admin-platform - på dage i stedet for måneder. Inklusive tekniske valg, arkitekturmønstre og reelle omkostninger.
Indholdsfortegnelse
Derfor tager AI-integration måneder (og derfor burde den ikke)
Et velkendt scenarie: En virksomhed vil tilføje AI-funktioner til sit produkt. De kontakter et bureau. Bureauet foreslår et 6-måneders projekt med et dedikeret AI/ML-team, datapipeline-infrastruktur, modeltræning og et sekscifret budget. Virksomheden betaler enten prisen eller lægger idéen på hylden.
Det sker, fordi de fleste bureauer griber AI-integration an, som om de skal bygge en machine learning-platform fra bunden. I 2025 er det næsten aldrig tilfældet. Foundation-modellerne fra OpenAI, Google og Anthropic er ekstremt kapable direkte fra hylden. Den reelle ingeniøropgave er ikke at bygge AI - det er at integrere den gennemtænkt i et produkt, der løser et konkret brugerproblem.
Her bruger traditionelle AI-projekter tiden:
- Leverandørevaluering (4-8 uger): Sammenligning af utallige udbydere, POC'er og kontraktforhandlinger
- Træning af egne modeller (8-16 uger): Dataindsamling, labeling, træning og evaluering - ofte unødvendigt med moderne foundation-modeller
- Opbygning af infrastruktur (4-8 uger): GPU-klynger, MLOps-pipelines og model-serving - irrelevant, når man bruger API-baserede modeller
- Godkendelser i udvalg (2-6 uger): Sikkerhedsgennemgange, arkitekturboards og stakeholder-godkendelser i hvert eneste trin
Hos TwinCurrent springer vi de fleste af disse trin over - ikke fordi vi skyder genvej, men fordi landskabet har ændret sig. Foundation-model-API'er har gjort træning af egne modeller unødvendig for de fleste forretningsapplikationer. Det reelle arbejde ligger i prompt engineering, fejlhåndtering og design af brugeroplevelsen omkring AI'ens output.
Vores tilgang: AI som en feature, ikke et produkt
Den centrale indsigt bag vores hurtige AI-integration er at behandle AI som en feature i et produkt - ikke som et produkt i sig selv. Det ændrer hele den tekniske tilgang.
Start med brugerens problem
Vi starter aldrig med "lad os tilføje AI". Vi starter med et konkret brugerproblem: "Brugerne skal kunne udtrække data fra kvitteringer uden manuel indtastning." AI'en er implementeringsdetaljen, ikke målet. Det fokus eliminerer scope creep og holder integrationen stramt afgrænset.
Vælg den rigtige model til opgaven
Ikke alle opgaver kræver GPT-4. Til DocubotAI bruger vi OpenAI på grund af den stærke dokumentforståelse. Til kvitteringsscanning i vores admin-platform er Google Gemini fremragende til struktureret dataudtræk fra billeder. Til opskriftsscanning håndterer vision-modeller genkendelse af håndskrift. Ved at matche modellernes styrker til opgaverne sparer vi både omkostninger og svartid.
Byg robuste fallbacks
AI-output er probabilistisk, ikke deterministisk. Hver eneste AI-feature, vi bygger, har en manuel fallback. Hvis kvitteringsscanneren ikke kan udtrække beløbet med høj sikkerhed, udfylder den det, den kan, og fremhæver usikre felter til menneskelig gennemgang. Brugeren sidder aldrig fast.
Lancér først, finpuds bagefter
Prompt engineering i produktion slår prompt engineering i et laboratorium. Rigtige brugerdata afslører edge cases, som syntetiske testdata aldrig finder. Vi lancerer en fungerende AI-feature hurtigt og forfiner derefter vores prompts ud fra de faktiske brugsmønstre. Den tilgang giver konsekvent bedre resultater end måneders finjustering før lancering.
Case 1: DocubotAI.app - samtalebaseret dokumentintelligens
DocubotAI er en SaaS-platform, hvor brugere kan uploade dokumenter (PDF'er, Word-filer, tekstfiler) og derefter føre en samtale med dem. Brugerne stiller spørgsmål i naturligt sprog og får svar med kildehenvisninger, der peger tilbage på de konkrete afsnit i kildedokumentet.
Den tekniske udfordring
Kerneproblemet var ikke bare at kalde OpenAI's API - det var at bygge en pålidelig pipeline, der håndterer dokumenter af varierende længde, format og kvalitet. En PDF på 200 sider kan ikke sendes til API'en i ét kald. Systemet skal opdele dokumenterne intelligent, bevare konteksten på tværs af tekstbidderne og levere præcise kildehenvisninger.
Vores arkitektur
- Dokumentindlæsning: Uploadede filer parses, teksten udtrækkes og opdeles i overlappende bidder på cirka 1.500 tokens med 200 tokens overlap, så konteksten bevares
- Embeddings og fremsøgning: Hver tekstbid embeddes med OpenAI's embeddings og gemmes i en vektordatabase. Brugerens forespørgsler embeddes og matches mod de mest relevante bidder via cosinus-similaritet
- Samtalekæde: De 5-8 mest relevante tekstbidder indsættes i systemprompten sammen med brugerens spørgsmål. GPT-4 genererer et svar, der er afgrænset til den leverede kontekst
- Kildehenvisninger: Hver tekstbid bærer metadata (sidetal, afsnitstitel). Systemprompten instruerer modellen i at citere kilder, og vi mapper henvisningerne tilbage til de konkrete steder i dokumentet
- Streaming af svar: Svar streames til brugeren i realtid via Server-Sent Events, så de ser svaret blive bygget op ord for ord i stedet for at vente på hele svaret
Tidslinje
Den afgørende accelerator var, at vi ikke skrev noget ML-kode overhovedet. Intelligensen kommer udelukkende fra OpenAI's API. Vores ingeniørarbejde gik til retrieval-pipelinen, brugeroplevelsen og at gøre AI'ens output pålideligt og brugbart. Et bureau, der byggede en "skræddersyet AI-løsning", ville have brugt måneder på infrastruktur, vi ganske enkelt ikke havde brug for.
Case 2: My Family Recipes - AI-scanning af opskrifter
My Family Recipes er en mobilapp (iOS og Android) bygget med React Native. Kernefunktionen er enkel: Fotografér et håndskrevet opskriftskort eller en side fra en kogebog, og AI'en udtrækker en struktureret opskrift med titel, ingredienser (med mængder og enheder), trinvise instruktioner og tilberedningstid.
Den tekniske udfordring
Genkendelse af håndskrift er markant sværere end OCR på trykt tekst. Mormors opskriftskort findes i alle håndskriftsstile - ofte med overstregede ord, noter i marginen og forkortelser for ingredienser ("1 tsk" for teskefuld, "dl" for deciliter). AI'en skal kunne håndtere alt dette og levere rent, struktureret output.
Vores arkitektur
- Billedoptagelse: Kameraintegration i React Native med automatisk beskæring, der indrammer opskriftsområdet. Billederne komprimeres for at reducere API-svartiden uden at forringe tekstens læsbarhed
- Vision-API-kald: Billedet sendes til vision-modellen med en struktureret prompt, der beder om JSON-output med bestemte felter: titel, antal portioner, forberedelsestid, tilberedningstid, ingredienser (array af objekter med navn, mængde og enhed) og trin (ordnet array)
- Validering af svar: Vi validerer JSON-svaret mod et Zod-skema. Hvis der mangler felter, eller de er fejlbehæftede, prøver vi igen med en justeret prompt, før vi falder tilbage til manuel indtastning
- Brugerens gennemgang: Den udtrukne opskrift vises i en redigérbar formular. Brugerne kan rette fejllæste ingredienser eller instruktioner, før de gemmer. Denne feedback-loop forbedrer indirekte vores prompts over tid
Detaljer om prompt engineering
Prompten til opskriftsudtræk gennemgik 14 iterationer under udviklingen. De vigtigste forbedringer var:
- Eksplicitte instruktioner for danske måleenheder (dl, tsk, spsk, stk) ud over metriske og imperiale enheder
- Few-shot-eksempler på håndskrevne opskriftskort med de forventede output
- Instruktion til modellen om at adskille "en knivspids" og "efter smag" fra afmålte mængder
- Confidence-scores for hvert udtrukket felt, så UI'et kan fremhæve usikre elementer
Hele AI-featuren - fra kameraoptagelse til struktureret opskrift i databasen - tog 5 dage af de i alt 18 dages byggetid. Resten var almindelig mobiludvikling: navigation, lagring af opskrifter, søgning, deling og indsendelse til App Store/Play Store.
Case 3: Intern admin-platform - AI-behandling af kvitteringer
Vores egen interne admin-platform håndterer udgiftsstyring for TwinCurrent. AI-featuren: Upload et foto af en kvittering, hvorefter systemet automatisk udtrækker forretningens navn, totalbeløb, moms (25 %) og dato - og foreslår en udgiftskategori. De udtrukne data udfylder udgiftsformularen på forhånd.
Hvorfor Google Gemini
Vi valgte Gemini til netop denne opgave på grund af modellens multimodale egenskaber og stærke resultater med struktureret dataudtræk fra billeder. Ved kvitteringsbehandling er kravet ikke kreativ tekstgenerering - det er præcist udtræk af bestemte felter (tal, datoer, navne) fra et visuelt dokument. Geminis vision-egenskaber klarer det pålideligt og til en lavere pris pr. kald end GPT-4 Vision i netop dette use case.
Håndtering af dansk moms
En kritisk detalje for danske virksomheder: AI'en udtrækker totalbeløbet, hvorefter systemet beregner momsandelen. Danske kvitteringer viser typisk totalen inklusive 25 % moms. Udtræksprompten instruerer Gemini i at identificere, om det viste beløb er inklusive eller eksklusive moms - og i at udtrække momsbeløbet separat, hvis det står på kvitteringen.
Kategorisering af udgifter
Ud over selve udtrækket foreslår Gemini også en udgiftskategori baseret på forretningens navn og de købte varer. Systemet vedligeholder en mapping over tidligere kategoriserede udgifter, så gentagne køb hos samme forretning kategoriseres med det samme uden et API-kald. AI'en aktiveres kun ved nye eller tvetydige forretninger.
Denne feature sparer vores team for cirka 2-3 timers manuel indtastning om ugen. Med vores timepriser har AI-API-omkostningerne (omkring 150-200 DKK om måneden) tjent sig hjem inden for den første dag i hver måned.
Genbrugelige mønstre til hurtig AI-integration
På tværs af alle tre projekter udkrystalliserede der sig en række mønstre, som vi i dag anvender i alle AI-integrationer. Det er de mønstre, der udgør forskellen mellem et 6-måneders projekt og en feature på 2 uger.
Mønster 1: Struktureret output i prompts
Bed altid om JSON-output med et defineret skema. Det gør parsing af svarene deterministisk og valideringen ligetil. Vi bruger Zod-skemaer både på prompt-siden (til at generere beskrivelsen af det forventede format) og på valideringssiden.
// Definér den forventede struktur
const ReceiptSchema = z.object({
merchant: z.string(),
amount: z.number(),
currency: z.string().default('DKK'),
vat: z.number().optional(),
date: z.string(),
category: z.string(),
confidence: z.number().min(0).max(1)
})
// Validér AI'ens svar
const parsed = ReceiptSchema.safeParse(aiResponse)
if (!parsed.success) {
// Fald tilbage til manuel indtastning
}Mønster 2: Confidence-baseret UI
Bed modellen om en confidence-score for hvert udtrukket felt. Brug den til at styre UI'et: Felter med høj sikkerhed udfyldes på forhånd og nedtones, felter med middel sikkerhed udfyldes men fremhæves til gennemgang, og felter med lav sikkerhed efterlades tomme til manuel indtastning.
Mønster 3: Progressiv forbedring
Alle AI-features fungerer uden AI. Kvitteringsformularen fungerer med manuel indtastning. Opskriftsformularen fungerer med indtastet tekst. Dokument-Q&A fungerer med fritekstsøgning. AI forbedrer oplevelsen, men er aldrig et single point of failure.
Mønster 4: API-forbrug med omkostningsloft
Implementér omkostningslofter pr. bruger og pr. projekt. Mål tokenforbruget pr. kald, aggregér det månedlige forbrug, og send advarsler, før budgetgrænserne rammes. Det forhindrer, at en enkelt bruger eller en prompt injection kører en enorm API-regning op.
Analyse af omkostninger og tidsforbrug
Her er en direkte sammenligning af, hvordan en traditionel bureautilgang og vores tilgang adskiller sig på tidsforbrug og indsats for en typisk AI-feature-integration:
Månedlige AI-API-omkostninger (faktiske)
Disse omkostninger er ubetydelige sammenlignet med den sparede udviklingstid. Alene admin-platformens kvitteringsbehandling sparer 8-12 timers manuel indtastning om måneden. Med enhver rimelig timepris har de 175 DKK i månedlige API-omkostninger tjent sig hjem inden frokost den første dag.
Konklusion: AI-integration er et løst problem
Flaskehalsen i AI-integration er ikke længere selve AI'en. Foundation-modellerne fra OpenAI, Google og andre er bemærkelsesværdigt kapable direkte fra hylden. Det reelle ingeniørarbejde er produktdesign: at forstå, hvad brugeren har brug for, vælge den rigtige model til opgaven, bygge robust fejlhåndtering og skabe en brugeroplevelse, der håndterer AI-outputtets probabilistiske natur elegant.
De vigtigste pointer
- I har ikke brug for en skræddersyet ML-model til de fleste forretnings-AI-features - foundation-model-API'er dækker 95 % af alle use cases
- Match modellen til opgaven: GPT-4 til dokumentanalyse, Gemini til struktureret udtræk, vision-modeller til billedbehandling
- Byg altid manuelle fallbacks - AI skal forbedre arbejdsgangen, men må aldrig blokere den
- Lancér tidligt, og iterér på jeres prompts ud fra reel brug - produktionsdata er jeres bedste træningssæt
- De månedlige API-omkostninger for de fleste forretningsfeatures er ubetydelige i forhold til den værdi, de skaber
Hvis nogen fortæller jer, at det er et 6-måneders, sekscifret projekt at tilføje AI til jeres produkt, bygger de enten noget reelt banebrydende (selvkørende biler, udvikling af lægemidler) - eller også overkomplicerer de en løsning, der burde tage uger. For langt de fleste forretningsapplikationer er hurtig AI-integration ikke bare mulig - det er den ansvarlige tilgang.
Vil I have AI i jeres produkt?
Vi kan afgrænse en AI-integration til jeres produkt i én enkelt samtale. De fleste features er i produktion på under tre uger.