Implementering af generativ AI i en virksomhed betyder at omsætte modeller, data, arbejdsprocesser og ansvar til en kontrolleret løsning i drift. Den praktiske opgave er ikke først at vælge model, men at vælge et afgrænset problem, måle kvaliteten, beskytte data og beslutte, hvornår mennesker skal godkende resultatet.
Implementering af generativ AI kræver et afgrænset forretningsproblem, kontrollerede data, målbar kvalitet og tydeligt ansvar. Overblikket hjælper med at vurdere use cases, vælge teknisk løsning, styre sikkerhed og gå fra pilot til drift uden at gøre modelvalget til første beslutning.
Hvad betyder implementering af generativ AI i en virksomhed?
Generativ AI kan skrive, sammenfatte, klassificere, omskrive, udarbejde forslag, analysere ustruktureret materiale og hjælpe med kode, billeder eller andre indholdsformer afhængigt af den valgte model. I en virksomhed er teknologien først nyttig, når den indgår i en konkret arbejdsgang med kendte input, kendte brugere, definerede kvalitetskrav og tydeligt ansvar.
Implementering handler derfor om mere end adgang til et chatværktøj. Det handler om at forbinde teknologien med forretningens mål, datagrundlag, sikkerhedsniveau, brugerkompetencer og målemetoder. En løsning kan være enkel, for eksempel en intern assistent til udkast og opsummeringer. Den kan også være teknisk integreret, hvor en model arbejder sammen med dokumentarkiver, sagsdata eller et fagsystem via et API.
Den mest holdbare tilgang begynder med et spørgsmål: Hvilken beslutning, tekst, proces eller service skal blive bedre? Før det spørgsmål er besvaret, kan et modelvalg let blive for tidligt. En dyr eller avanceret model løser ikke en uklar arbejdsgang, og en enkel løsning kan være nok, hvis opgaven er klart afgrænset.
Hvor begynder en realistisk use case?
En god første use case ligger typisk dér, hvor arbejdet er gentaget ofte, men stadig kræver faglig vurdering. Det kan være sortering af kundehenvendelser, udarbejdelse af første udkast, sammenfatning af møder, søgning i interne dokumenter, kvalitetstjek af tekster eller støtte til udviklere. Opgaven skal have nok volumen til at betyde noget, men ikke være så kritisk, at en fejl straks kan skade kunder, borgere, medarbejdere eller forretningen.
Start med at beskrive opgaven uden AI. Hvem udfører den i dag? Hvilke data bruges? Hvad er et acceptabelt resultat? Hvor ofte opstår fejl? Hvor meget tid bruges der? Hvilke dele kræver menneskelig dømmekraft? Når den nuværende proces er synlig, bliver det lettere at se, hvor generativ AI faktisk kan støtte arbejdet.
En praktisk prioritering kan dele mulige use cases i tre grupper:
- Høj værdi og lav risiko: egnede til en tidlig pilot, hvis data kan håndteres sikkert.
- Høj værdi og høj risiko: kræver stærkere styring, tydelig godkendelse og ofte længere test.
- Lav værdi og høj kompleksitet: bør som regel vente, fordi implementeringen kan blive dyrere end gevinsten.
Denne rækkefølge knytter AI-arbejdet til generativ AI som en del af forretningsstrategien, frem for at teknologien bliver et isoleret eksperiment.
Hvordan afgrænser du en pilot, der kan måles?
En pilot skal være lille nok til at kunne styres og stor nok til at give viden. Den bør have en tydelig start, et konkret datagrundlag, et begrænset antal brugere, en ansvarlig ejer og en beslutning om, hvad der sker efter testen. En pilot uden målepunkt bliver let en demonstration i stedet for et beslutningsgrundlag.
Definér først succeskriterierne. Det kan være kortere svartid, færre manuelle trin, bedre ensartethed, hurtigere informationssøgning eller færre fejl i bestemte teksttyper. Brug både kvantitative og kvalitative mål. Tidsbesparelse siger ikke meget alene, hvis kvaliteten falder, eller hvis brugerne bruger ekstra tid på at rette modellen.
Beskriv også, hvad piloten ikke må gøre. Den må måske ikke træffe afgørelser, sende svar uden menneskelig godkendelse, behandle særlige kategorier af personoplysninger eller bruge materiale uden dokumenteret brugsret. Grænserne er ikke et bureaukratisk tillæg. De gør testen mere realistisk, fordi brugerne ved, hvordan løsningen må anvendes.
En god pilot afsluttes med en go/no-go-beslutning. Den beslutning bør bygge på dokumenterede resultater, ikke kun på begejstring fra de mest teknologivante brugere.
Hvilken teknisk løsning passer til opgaven?
Generativ AI kan implementeres på flere niveauer. Nogle opgaver kræver kun et godkendt standardværktøj med klare brugsvilkår. Andre kræver integration med interne systemer, søgning i egne dokumenter eller specialiseret tilpasning. Valget bør afhænge af opgaven, datakravene og behovet for kontrol.
| Løsningstype | Egner sig til | Kontrolpunkt |
|---|---|---|
| Godkendt chatværktøj | Udkast, ideer, opsummeringer og individuel produktivitet | Datavilkår, brugertræning og regler for følsomt indhold |
| Model via API | Automatiserede trin i egne applikationer | Adgangsstyring, logning, omkostningskontrol og outputkontrol |
| Retrieval-augmented generation | Svar baseret på interne dokumenter eller vidensbaser | Dokumentkvalitet, kildehenvisninger og opdateringsproces |
| Finjustering | Snævre opgaver med mange eksempler og stabilt format | Træningsdata, evaluering, driftsovervågning og ændringsstyring |
Retrieval-augmented generation, ofte forkortet RAG, betyder at modellen får relevante uddrag fra en godkendt vidensbase med i konteksten, når den svarer. Det kan mindske afstanden mellem generel modelviden og virksomhedens konkrete materiale, men det fjerner ikke behovet for kildekontrol. Hvis dokumenterne er forældede, uklare eller forkert indekseret, kan svaret stadig blive misvisende.
Hvordan skal data gøres klar før brug?
Dataarbejdet bør begynde før den første tekniske integration. Generativ AI kan kun støtte en arbejdsgang ansvarligt, hvis organisationen ved, hvilke data der indgår, hvor de kommer fra, hvem der må bruge dem, og hvordan de skal slettes eller opdateres. Det gælder både dokumenter, kundedata, interne retningslinjer, produktinformation og historiske sager.
Del data i kategorier. Offentligt materiale, interne retningslinjer, fortrolige forretningsoplysninger, personoplysninger og særligt følsomme oplysninger bør ikke behandles ens. Hver kategori kræver egne regler for adgang, lagring, deling, logning og brug i eksterne tjenester. Arbejdet hænger tæt sammen med generativ AI og datafortrolighed.
Datakvalitet er lige så vigtig som datasikkerhed. En intern AI-assistent, der søger i gamle procedurer, dubletter og uafklarede dokumentversioner, kan give brugerne et professionelt formuleret, men forkert svar. Derfor bør dokumenter have ejere, versionsdatoer og en oprydningsproces, før de bruges som vidensgrundlag.
Hvis personoplysninger indgår, skal organisationen også afklare roller, behandlingsgrundlag, databehandlerforhold, opbevaring og adgang. Det er ikke nok at spørge, om værktøjet er sikkert i almindelig forstand. Spørgsmålet er, om den konkrete brug passer til organisationens dataansvar og risikoniveau.
Hvordan håndteres sikkerhed, adgang og leverandører?
Generativ AI skaber andre sikkerhedsspørgsmål end almindelige tekstfelter og søgefunktioner. Brugere kan indsætte fortrolige oplysninger, modellen kan returnere følsomt indhold, og en integreret løsning kan få adgang til værktøjer eller data, som den ikke bør bruge i alle situationer. Sikkerhed skal derfor bygges ind i arkitekturen, ikke kun i en brugsvejledning.
Et praktisk sikkerhedsdesign bør omfatte rollebaseret adgang, mindst mulige rettigheder, logning, klare grænser for automatiske handlinger og kontrol af output, før det sendes videre til kunder, systemer eller offentlige kanaler. Hvis løsningen kan oprette sager, sende beskeder eller ændre data, skal den have langt stærkere styring end en intern skriveassistent.
Leverandørstyring er en del af sikkerheden. Kontrakter og tekniske bilag bør beskrive databehandling, brugsrettigheder, sikkerhedskrav, logning, hændelsesrapportering, modelændringer og mulighed for audit. NISTs generative AI-profil peger netop på kontrakter, leverandørrisiko og løbende monitorering som centrale elementer i styring af generativ AI.
Risikoen bør også testes aktivt. OWASPs liste over LLM-risici fremhæver blandt andet instruktionsangreb, følsom informationslækage, utilstrækkelig outputhåndtering, for stor handlefrihed, svagheder i vektor- og embeddingssystemer samt ubegrænset ressourceforbrug. De risici bliver især relevante, når en model forbindes med interne data eller får lov til at handle på brugerens vegne.
Hvordan måler du kvalitet og forretningsværdi?
Måling bør begynde med en baseline. Hvis organisationen ikke ved, hvor lang tid en proces tager i dag, hvor ofte der opstår fejl, eller hvad brugerne oplever som svært, bliver det vanskeligt at vurdere AI-løsningens virkning. En baseline kan være enkel: tidsregistrering på udvalgte opgaver, stikprøver af kvalitet eller en manuel gennemgang af fejltyper.
Generativ AI bør måles på flere dimensioner. Hastighed er kun én. Kvalitet, korrekthed, ensartethed, brugeraccept, sikkerhedshændelser, behov for efterredigering og omkostninger pr. opgave er ofte mere afgørende. Hvis en løsning sparer fem minutter, men kræver usynlig kontrol i andre led, er gevinsten mindre end den ser ud.
Et realistisk evalueringssæt kan bestå af tidligere sager, typiske dokumenter, svære kanttilfælde og eksempler, hvor modellen bør afvise at hjælpe. Resultaterne bør vurderes af fagpersoner, ikke kun af tekniske test. På den måde kan organisationen skelne mellem et svar, der lyder godt, og et svar, der faktisk er brugbart.
Der skal også måles efter lancering. Modeller, dokumenter, brugeradfærd og leverandørvilkår kan ændre sig. Løbende feedback og stikprøver gør det muligt at opdage faldende kvalitet, nye fejlmønstre og utilsigtet brug, før løsningen bliver en skjult driftsrisiko.
Hvilke roller skal indgå i implementeringen?
Generativ AI lykkes sjældent som et rent IT-projekt. En driftsklar løsning kræver både faglig viden, teknisk forståelse, dataansvar, sikkerhed, ledelsesprioritering og brugerfeedback. Hvis én gruppe ejer hele projektet alene, bliver vigtige hensyn let overset.
Den faglige ejer beskriver opgaven, kvalitetskravene og de situationer, hvor mennesker skal træffe den endelige beslutning. IT eller udvikling håndterer integration, adgang, logning, drift og tekniske kontroller. Sikkerheds- og dataansvarlige vurderer risici, leverandørvilkår og datakategorier. Brugerne tester, om løsningen passer til den faktiske arbejdsdag.
Ledelsen skal ikke godkende hver teknisk detalje, men den skal beslutte risikotolerance, prioritet og ansvar. En organisation kan ikke styre generativ AI effektivt, hvis ingen kan afgøre, hvornår en løsning må sættes i drift, hvornår den skal stoppes, eller hvilke fejl der skal rapporteres som hændelser.
ISO/IEC 42001 beskriver et AI-ledelsessystem som politikker, mål og processer for ansvarlig udvikling, levering eller brug af AI-systemer. Det gør standarden relevant som ramme, også for organisationer der ikke søger certificering.
Hvordan påvirker EU-regler og standarder arbejdet?
For organisationer i Danmark er regulering og standarder en praktisk del af implementeringen, ikke kun et juridisk bagtæppe. GDPR, kontraktkrav, informationssikkerhed, arbejdsmiljø, ophavsret og EU’s AI Act kan alle få betydning afhængigt af use case, data og sektor.
EU’s AI Act trådte i kraft 1. august 2024 og anvendes trinvist. Europa-Kommissionens tidslinje angiver blandt andet, at regler om forbudte AI-praksisser og AI-literacy begyndte at gælde fra 2. februar 2025, at regler for general-purpose AI-modeller begyndte at gælde fra 2. august 2025, og at forordningen som udgangspunkt anvendes fra 2. august 2026 med undtagelser og overgangsperioder.
Den praktiske konsekvens er, at en virksomhed bør klassificere sin AI-brug tidligt. Et værktøj til intern tekstredigering har normalt en anden risikoprofil end AI i rekruttering, kreditvurdering, uddannelse, kritisk infrastruktur eller andre områder, hvor fejl kan påvirke menneskers rettigheder, muligheder eller sikkerhed.
Standarder kan gøre arbejdet mere operationelt. NIST AI RMF bruger funktionerne Govern, Map, Measure og Manage til at strukturere risikostyring. ISO/IEC 42001 giver en ledelsessystemramme for politikker, processer, ansvar og løbende forbedring. Interne processer for risikostyring i AI-implementeringer bør derfor hænge sammen med de eksisterende processer for sikkerhed, kvalitet og compliance.
Hvornår er generativ AI ikke den rigtige løsning?
Generativ AI er ikke velegnet til alle problemer. Hvis opgaven kræver deterministiske beregninger, fuld sporbarhed i hvert trin eller afgørelser med meget lav fejltolerance, kan almindelig software, regler, databaser eller statistiske modeller være bedre. Generativ AI er stærkest, når opgaven handler om sprog, mønstre, forslag og bearbejdning af ustruktureret materiale.
Teknologien bør heller ikke sættes i drift, hvis organisationen ikke kan forklare datagrundlaget, ikke kan måle kvaliteten eller ikke ved, hvem der ejer resultatet. En model kan formulere et overbevisende svar uden at have ret. Det fænomen kaldes ofte AI-hallucination, og det er især problematisk, når svaret bruges som beslutningsgrundlag.
Der bør være klare stopkriterier:
- Løsningen bruger data, som ikke må behandles i den valgte tjeneste.
- Fagpersoner kan ikke opnå stabil kvalitet i realistiske test.
- Brugerne forstår ikke begrænsningerne eller springer nødvendig kontrol over.
- Leverandøren kan ikke dokumentere tilstrækkelige vilkår for sikkerhed, data og ændringer.
- Modellen får handlemuligheder, der er bredere end opgavens behov.
Et nej kan være et godt resultat af en pilot. Det frigør tid og budget til de anvendelser, hvor generativ AI passer bedre.
Hvordan går du fra pilot til drift?
Overgangen fra pilot til drift er ofte sværere end den første test. I piloten kan engagerede brugere kompensere for manglende processer. I drift skal løsningen fungere for flere brugere, med support, dokumentation, rettighedsstyring, hændelseshåndtering og ændringskontrol.
Før udrulning bør organisationen beslutte, hvem der kan bruge løsningen, hvilke opgaver den må bruges til, hvilke data der er tilladt, hvordan fejl rapporteres, og hvordan nye versioner testes. Brugervejledning skal være kort og konkret. Den bør forklare de tilladte anvendelser, typiske fejltyper og krav til menneskelig kontrol.
Teknisk drift kræver også omkostningsstyring. API-baserede løsninger kan få variable omkostninger, især hvis brugerne sender lange dokumenter, gentager forespørgsler eller lader modellen arbejde i flere trin. Sæt grænser for forbrug, overvåg svartider og gem de logs, der er nødvendige for fejlfinding uden at opbevare mere følsomt indhold end nødvendigt.
Skalering bør ske trinvist. Udvid først til nærliggende opgaver, når den første løsning har dokumenteret stabil kvalitet. En løsning, der virker i kundeservice, kan ikke automatisk overføres til HR, jura, økonomi eller teknisk support uden nyt datatjek og ny risikovurdering.
Hvordan holder du løsningen stabil efter lancering?
Generativ AI skal behandles som en levende driftsløsning. Modeller kan blive opdateret, leverandørvilkår kan ændre sig, interne dokumenter kan forældes, og brugere kan finde nye anvendelser, som ikke var tænkt ind fra starten. Stabilitet kræver derfor regelmæssig kontrol.
En enkel driftsrytme kan bestå af månedlige stikprøver, kvartalsvis gennemgang af datakilder, årlig risikovurdering og hurtig behandling af fejlrapporter. Ved større modelskift, nye datakilder eller nye brugergrupper bør løsningen testes igen, før ændringen sættes i drift.
Brugerfeedback er en del af kvalitetssystemet. Brugere skal kunne rapportere forkerte svar, mærkelige mønstre, sikkerhedsproblemer og situationer, hvor løsningen ikke passer til arbejdsgangen. Feedback bør samles struktureret, så den kan føre til konkrete ændringer i data, instruktioner, adgang eller proces.
Den langsigtede værdi opstår, når organisationen lærer af driften. En vellykket implementering er ikke en enkelt lancering, men en kontrolleret arbejdsgang, hvor generativ AI løbende vurderes efter nytte, risiko, kvalitet og ansvar.
Hvilke kilder ligger til grund?
Artiklen bygger især på NISTs AI Risk Management Framework og den generative AI-profil NIST AI 600-1. EU-relevansen er kontrolleret mod Europa-Kommissionens side om AI Act, mens styringsperspektivet er holdt op mod ISO/IEC 42001:2023. Sikkerhedsafsnittet er desuden sammenholdt med OWASP Top 10 for LLM Applications 2025.