Integrér AI i jeres nuværende systemer i stedet for at genbygge
Der er en ny nøgternhed på vej i AI. Ikke flere greenfield-projekter for enhver pris. For langt de fleste små og mellemstore virksomheder er den hurtigste vej til værdi at integrere AI direkte i de systemer, der allerede bærer driften. Towards AI-artiklen “Integrating AI Into Existing Business Software” (22.09.2026) beskriver et praktisk mønster, der går igen: brug asynkrone køer, berig i baggrunden, og skriv kun valideret struktureret output tilbage i databasen. En opskrift, ikke en vision.
Konklusionen støttes af en kortfattet manualbrief, der peger på lag med hurtig ROI: målrettet prompting, embeddings, RAG, API‑orkestrering og ETL oven på ERP‑ og CRM‑data. Ingen romantik om bespoke neurale netværk. Bare håndværk. Og så et enterprise‑eksempel fra AWS, hvor EXL’s Medical IDP kobler intelligent dokumentprocessering med domænespecifikke LLM’er og reducerer manuelt review i sundhedsclaims. Ifølge AWS’ blogindlæg bruger claims adjusters over 100 minutter pr. sag. Det illustrerer potentialet ved at lægge AI oven på eksisterende processer – ikke ved at rive dem ned.
Hvorfor bespoke modeller sjældent er svaret
De fleste SMV’er har ikke datamængder, økonomi eller regulatorisk appetit til at udvikle og drifte egne modeller. Towards AI-artiklen siger det klart: man får hurtigere værdi ved at bruge pålidelige model‑API’er og koble dem på de systemer, der allerede findes. Det matcher, hvad mange ingeniørteams ender med efter første POC: de integrerer i stedet for at genopfinde.
Argumentet er driftsøkonomi. Eksisterende CRM’er og ERP’er rummer regler, brugerrettigheder og kendte dataflows. Ved at lægge AI‑lag ovenpå får man automatisering og beslutningsstøtte uden at forstyrre forretningen unødigt. Går noget galt, kan integrationen rulles tilbage uden at tage hele huset med.
Der er også governance – ofte fraværende i fritstående AI‑projekter. At bygge ved siden af forretningssystemerne skaber let skygge‑IT og dobbelt sandhed. Integrationssporet tvinger mod auditlogs, prompt‑versionering og centrale dataflows, fordi man arbejder inde i den eksisterende platform. Klog tvang.
Hvad virksomheder allerede kører på
Standardbilledet er en stak forretningskritiske systemer, der virker: CRM med kundehistorik, lagerdatabase, faktureringsportal og en sej, men ældre supportløsning. Towards AI peger netop på disse som oplagte steder for AI‑integration. Det er hverdagen i mange virksomheder.
Pointen: Når der allerede findes relationelle skemaer, felter og valideringsregler, kan AI udfylde eller forberede felter – ikke erstatte hele workflowet. Den beriger data og foreslår næste skridt, mens UI og tilladelser forbliver de samme.
Første særhed: Chatbots er fristende, men ofte unødvendige. Towards AI advarer mod chat, når en simpel knap gør arbejdet hurtigere og mere sikkert. Det er brugerhygiejne.
Produktionsmønsteret der virker
Opskriften i Towards AI: Modtag input, skriv rådata til databasen, læg en besked på en asynkron kø, og lad baggrundsarbejdere berige sagen via LLM‑API’er. Frontenden svarer brugeren med det samme, fordi intet blokerer. Når baggrunden er færdig, skrives kun valideret struktureret output tilbage.
Det lyder simpelt. Netop derfor holder det. Asynkronitet gør systemet robust over for API‑forsinkelser og nedetid. En kø kan skalere op og ned. Og fejler noget, håndterer man det med retries eller dead‑letter‑køer uden at ødelægge brugeroplevelsen.
Mønstret er kendt fra e‑mail‑udsendelse, rapportgenerering eller billedbehandling. AI‑berigelse er blot endnu en baggrundsopgave. Forskellen: vær streng med, hvad der skrives tilbage i databasen.
Valideret JSON betyder hårde kanter
Struktureret output er ikke pynt – det er sikkerhedsnettet. Towards AI foreslår, at modellen returnerer JSON efter et eksplicit schema. Derefter kører backenden schema‑validering, inden noget persisteres. Fejler validering, skrives intet. Punktum.
Hvordan gøres det konkret? Definér felter, typer, obligatoriske nøgler og tilladte værdier. Tilføj evt. regex for formater, længdegrænser og enum‑lister. Output parses kun, hvis alt består. Ellers sendes en fejlbesked til køen – måske med retry eller menneskelig eskalering.
Fejltilstande er uundgåelige: tomt output, halvt JSON, hallucinerede nøgler, for mange tokens. Derfor skal valideringen være kynisk. Hellere sende 5 procent til menneskelig gennemgang end at forurene databasen. Det føles hårdt første gang. Det er billigere anden gang.
Eksempel i virkeligheden: ticket‑triage
Et af de mest håndgribelige eksempler fra Towards AI er automatiseret triage af supporttickets. Modellen returnerer felter som urgency, department, summary og et human_review‑flag. Kedeligt på den rigtige måde. Kedeligt betyder drift.
En mulig prompt‑struktur: kontekst om produktområder, et par annoterede eksempler på korrekt klassificering, en tydelig instruks om kun at svare i JSON, samt et schema med feltnavne, tilladte værdier og korte beskrivelser. Tilføj maksimal længde for summary og en pæn fejlbesked, hvis triage er usikker.
Schemaet kan kræve en urgency i enum [low, medium, high], et department i en lille liste, en summary på maks 200 tegn og human_review som bool. Nøglen er en confidence‑tærskel, der afgør, om human_review sættes til true. Når tærsklen ikke nås, lander sagen i den menneskelige bakke.
Drift og robusthed, når verden driller
Robusthed begynder med input. Begræns tokens ved at trimme signaturer, autosvar og historik, og fjern HTML‑støj før kaldet. Towards AI nævner netop input‑sanitering og truncation som første værn mod omkostningsskred og uforudsigelige svar. Det er drift, ikke modelmagi.
Når modellen svarer, bør der være confidence‑checks og menneskelig fallback, når svaret er for tyndt. Simpelt regelsæt for tærskler, retries og eskalering. Og dead‑letter‑køer til beskeder, der ikke kan leveres efter X forsøg. Samme mønster som ved integrationsfejl mod tredjeparts‑API’er.
Vigtige småting: log alt med korrelations‑ID’er, gem råinput før berigelse, og behold versionsnumre for prompts. Ændrer et svar pludselig form, skal man kunne se præcis hvilken prompt‑version og hvilket model‑kald der gjorde det. Ellers er fejlfinding gætværk.
Sikkerhed og compliance uden nervetræk
Her er der huller i kilderne. Towards AI og manualbriefen har stærke arkitekturråd, men går let forbi sikkerhedsdetaljer. Basale praksiskrav bør være på plads fra start: opbevar API‑nøgler i en secrets manager, aldrig i klientkode. Brug short‑lived tokens mellem services. Giv baggrundsarbejdere mindst mulige rettigheder.
PII‑redaction er en anden blind vinkel. Behandles persondata, så filtrér eller maskér felter før kald til eksterne API’er, og fasthold auditspor for hvem der tilgik hvad, hvornår. Embeddings‑stores bør have adgangskontrol på dataset‑niveau og helst kundespecifik isolering. Ofte glemt i skyndingen.
Logning skal tænkes igennem. Hvis prompts og outputs logges, kan de indeholde PII eller følsomme forretningsoplysninger. Krypter hviledata, sæt retention‑principper, og adskil operationslogs fra revisionsspor. Kilderne nævner det ikke – men hullet skal lukkes i enhver produktionsplan.
Faldgruber og antimønstre
Tre klassikere fra Towards AI fortjener opslag på væggen: Brug ikke chatbots, hvor en knap er bedre. Eksponér ikke credentials. Over‑arkitér ikke med tunge frameworks, før noget virker. Enig i alle tre.
Over‑arkitektur er den stille dræber: for mange services, for få brugere og en brændt platform. Start med kø, baggrundsarbejder og en lille schema‑validator. Resten kan komme senere, hvis data kalder på det.
Hvornår integration giver mening – og hvornår den ikke gør
Kilderne peger på positive indikatorer: store mængder ustruktureret tekst, gentagen dataindtastning og klare relationelle skemaer. Her kan AI berige, strukturere og foreslå næste skridt uden at overtage beslutningerne. Fornuftig gevinst pr. investeret udviklertid.
Hold igen, hvis opgaven kræver deterministisk præcision, eller der mangler brugbare API’er og datagrænseflader at koble sig på. Så bliver AI‑kald en kilde til ustabilitet – ikke værdi. Hellere regelmotor eller lille speciallogik, når fejltolerance er lav.
Gråzonen er svær: halvstrukturerede dokumenter, moderate volumener og blandet datakvalitet. Her kan en lille RAG‑løsning være rigtig, men kun med tydelig governance og målepunkter. Ellers drukner man i justeringer.
Høj‑ROI‑lagene der faktisk bruges
Manualbriefen er klar: høj værdi kommer typisk fra fem lag. Prompt‑engineering (præcis opgave), embeddings (hurtig søgning og match), RAG (svar forankret i egne kilder), API‑orkestrering (systemer taler sammen) og ETL (rene, pålidelige data).
Lagene lægger sig oven på ERP, CRM og BI uden at vælte noget. De kan måles, styres og rulles tilbage. Og de tvinger teams til at beskrive domænet i skemaer og regler, før der kodes videre. Det føles kedeligt. Det er meningen.
Skepsis om domæneforståelse er fair. Men RAG og embeddings afhjælper meget, fordi svar forankres i egne dokumenter og felter. Mindre hallucination, mens struktureret output holder databasen ren.
Enterprise‑bekræftelse fra AWS‑casen
AWS beskriver EXL’s Medical IDP som en kombination af intelligent dokumentprocessering og domænespecifikke LLM’er, der kan udtrække, sammenfatte og muliggøre søgning i medicinske informationer i stor skala. Ifølge AWS bruger insurance claims adjusters over 100 minutter pr. sag på manuelt review. Det sætter tal på en kendt smerte.
Casen er enterprise, ikke SMV. Mekanikken er dog den samme: dokumenter ind, automatisk strukturering, domæneforankret berigelse og målrettede forespørgsler mod et nu søgbart datasæt. Integration med eksisterende arbejdsgange – ikke en erstatning.
Der er ikke fuld information om governance og change management i den offentlige beskrivelse. Det er et generelt hul på tværs af kilderne: Hvem ejer datavalidering, hvem versionerer prompts, og hvordan føres audit‑logs? Åbne spørgsmål – men ikke valgfrie i produktion.
Beslutningsguide fra prototype til produktion
Et praktisk forløb: begynd med en snæver POC i en asynkron pipeline, der kun skriver til en testtabel. Definér på forhånd gate‑kriterier for præcision, gennemløbstid og omkostning pr. sag. Når de rammes, udvid felter – ikke features. Rul derefter ud til enkelte brugere med A/B‑test mod det eksisterende workflow.
Testdata er ikke kun historiske sager. Byg et eval‑sæt med kanttilfælde, forurenede inputs og grænseværdier på schemaer. Mål drop‑rate til human fallback, valideringsfejl pr. 100 sager og tid til første brugbare forslag. Når tallene er stabile, parallelkør i produktion med feature‑flags.
Involvér drift, sikkerhed, compliance og faktiske slutbrugere tidligt – i korte feedbackloops. Det er her ændringen lykkes. Eller glider ud mellem fingrene.
Hvad kilderne siger – og hvad de ikke siger
Høj konsistens mellem Towards AI og manualbriefen om strategi: integrér frem for at genbygge, brug asynkrone mønstre, valideret JSON og fokuser på lavthængende frugter som triage og data‑berigelse. AWS‑casen bekræfter, at samme mekanik skalerer i enterprise, hvor gevinster kan måles i tid sparet pr. sag.
Hvor kilderne er tavse: governance, audit, prompt‑versionering og ejerskab af eval‑sæt. Samt detaljer om kryptering af mellemlag, adgangskontrol i embeddings‑stores og PII‑redaction. Netop de punkter vælter ellers velfungerende tekniske løsninger.
En mindre uenighed er tempoet fra POC til produktion. Towards AI lægger op til en direkte vej, mens en mere forsigtig tilgang med skarpe gates er sund i regulerede domæner. Ikke en modsigelse – blot forskellig risikovægtning.
Fakta
Kilde 1: Towards AI, “Integrating AI Into Existing Business Software”, publiceret 22.09.2026. Kilde 2: Manualbrief med anbefalinger om integrationslag som prompt‑engineering, embeddings, RAG, API‑orkestrering og ETL. Kilde 3: AWS Blog, “Reducing medical claims review time with AI on AWS: The EXL Medical IDP solution”, med estimat om over 100 minutters manuelt review pr. sag for claims adjusters.
Alle tre kilder er konsistente om integrationssporet som den hurtigste vej til værdi i de fleste organisationer. Hvor de er tavse, er især governance, compliance og sikkerhedsdetaljer. De bør adresseres i enhver implementeringsplan, før der kaldes produktion.
Hvis noget skurrer, er det snarere de steder, hvor projekter i praksis snubler: for brede mål, for tidlig chatbot‑fascination og for sene beslutninger om schema og validering. Det er ikke teori. Det er daglig kost i softwaredrift.
Tjekliste til ledere og produktteams
- Start med én use case i en asynkron pipeline. Gem råinput først.
- Definér et stramt JSON‑schema og kør hård validering før DB‑opdatering.
- Sæt klare gates: præcision, gennemløbstid, omkostning pr. sag, fallback‑rate.
- Indfør prompt‑versionering, audit‑logs og korrelations‑ID fra dag ét.
- Håndter sikkerhed: secrets manager, short‑lived tokens, PII‑redaction.
- Planlæg drift: retries, backoff, dead‑letter‑køer, overvågning af token‑forbrug.
- Undgå chat, når en knap gør det bedre. Hold UI’et enkelt og hurtigt.
Til sidst: Det her er ikke glamourøst. Det lugter lidt af serverrum og feltskemaer. Netop derfor virker det i hverdagen. Forskellen mærkes først, når man sidder med det i hænderne.
