Anvendelse af kunstig intelligens i udviklingsarbejde: sådan gør du det sikkert og effektivt

Kort overblik: sådan bør du bruge AI i udviklingsarbejde

Kunstig intelligens kan gøre dit udviklingsarbejde hurtigere og skarpere, hvis du bruger det som en assisterende kollega: til research, udkast, kodeforslag, dokumentation og kvalitetstjek. Nøglen er et tydeligt workflow, hvor du styrer data, sætter klare prompts, kontrollerer output systematisk og dokumenterer, hvad der er lavet med AI. AI må aldrig stå alene med følsomme data eller kritiske beslutninger.

Hvad er kunstig intelligens i praksis?

Kunstig intelligens er software, der kan efterligne menneskelig tænkning ved at genkende mønstre, foreslå løsninger og generere svar. I udviklingsarbejde bruges den typisk til at accelerere opgaver som analyse, skrivearbejde, kodehjælp og dokumentation – men resultatet skal altid kontrolleres af et menneske.

I praksis bygger meget moderne AI på machine learning, hvor modeller (ofte neurale netværk) trænes på store mængder data til at løse bestemte typer opgaver: klassificere, forudsige, oversætte, generere tekst, osv. Når du arbejder med tekstbaserede værktøjer, taler man ofte om sprogmodeller eller LLM’er (Large Language Models).

De vigtigste egenskaber i en udviklerhverdag:

• De er gode til mønstergenkendelse: se ligheder i kode, tekster, logs.
• De er stærke til at samle og omskrive: opsummere issues, skrive forslag til dokumentation, formulere mails.
• De kan generere nye forslag: eksempel-kode, testcases, alternative løsninger.
• De arbejder sandsynlighedsbaseret: de gætter på, hvad der statistisk set passer – ikke på, hvad der er “sandhed”.

Det sidste punkt er centralt: AI kan virke meget sikker i sin formulering, selv når svaret er forkert. Derfor er kontrol og kvalitetssikring en fast del af et ansvarligt AI-setup.

Generativ AI: hvornår giver den mening i udvikling?

Generativ AI er bedst, når du har brug for hurtige udkast, opsummeringer eller forslag, men ikke når du har brug for en endelig sandhed uden kontrol. I udviklingsarbejde er den derfor mest nyttig som assistent, ikke som beslutningstager.

Generativ AI er modeller, der kan skabe nyt indhold: tekst, kode, billeder, osv., baseret på et prompt (din instruktion). De mest udbredte til udvikling er sprogmodeller, der kan:

• foreslå kodeudsnit
• forklare eksisterende kode
• skrive tests eller dokumentation
• opsummere krav, issues eller logs
>

Modellerne svarer ud fra sandsynlighed, ikke regler. Det giver fleksibilitet, men også risiko for hallucinationer – svar, der lyder plausible, men er forkerte eller opdigtede.

Brug generativ AI, når du fx:

• har brug for et første udkast til noget, du alligevel selv gennemgår og retter
• vil undersøge muligheder: flere arkitekturretninger, edge cases, API-designs
• vil forklare noget kendt (din egen kode, kendte teknologier) i et nyt format

Brug den ikke som eneste kilde, når:

• svaret skal være juridisk, sikkerhedsmæssigt eller forretningskritisk korrekt
• du arbejder med følsomme data eller særlig lovregulering
• du har brug for fuld forklarbarhed over, hvordan en konklusion er nået

Hvis du vil dykke mere ned i selve prompt-teknikken, er der separate guides til både hvad et prompt er og hvordan du skriver prompts til kodning og debugging.

Hvad kan AI konkret bruges til i udviklingsarbejde?

AI er mest nyttig i udviklingsarbejde til opgaver, der kræver tempo og mønstergenkendelse, som research, idéudkast, dokumentation og første kodeforslag. Den er mindre egnet som eneste kilde til arkitekturvalg, sikkerhedsvurderinger og endelige beslutninger.

Typiske opgaver, hvor AI giver god mening:

• Research og opsummering
  Fx: “Opsummer de vigtigste forskelle mellem OAuth2 og OpenID Connect til et kort notat.”
• Idéudvikling og designforslag
  Fx: generere forslag til API-endpoints, data-modeller eller UI-tekster.
• Kodeassistance
  Fx: foreslå boilerplate-kode, en simpel algoritme eller en alternativ implementering.
• Forklaring og læring
  Fx: få en forklaring på et regex, en SQL-forespørgsel eller et design pattern.
• Test-idéer og edge cases
  Fx: “Giv 10 realistiske edge cases for denne funktion, der håndterer uploads.”
• Dokumentation og kommunikation
  Fx: generere første udkast til README, release-notes eller en teknisk beslutningsbeskrivelse.

Opgaver, hvor AI kun bør være støtte (og aldrig beslutningstager):

• Arkitekturvalg til større systemer
• Sikkerhedsdesign og trusselsmodellering
• Performancekritiske optimeringer, hvor små fejl har store konsekvenser
• Compliance-relaterede løsninger, fx behandling af særligt følsomme persondata

Hvis du bruger AI til kode, er det ekstra vigtigt at have en stærk praksis for tests, code review og sikkerhed – ellers risikerer du at bygge teknisk gæld og bugs direkte ind i koden. Her er artiklen stop med bare at copy-paste AI-kode en god reality check.

Et praktisk AI-workflow til udviklingsarbejde

Et sikkert AI-workflow i udviklingsarbejde bør altid gå fra problem og data til prompt, kontrol, godkendelse og dokumentation. Den vigtigste regel er, at AI kan hjælpe med udkast, men et menneske skal eje både kvalitet og beslutning.

Nedenfor er et workflow, du kan tilpasse til dit team. Tænk det som en slags “mini-proces” hver gang du bringer AI i spil.

Trin 1: Afklar problemet og risikoniveauet

Start med at svare kort på:

• Hvad er opgaven? (fx “første udkast til tests for modul X”)
• Hvad er risikoniveauet? (lav, middel, høj, afhængig af konsekvens ved fejl)
• Hvilke data skal bruges? (offentlig viden, intern kode, kundedata osv.)

Hvis opgaven berører følsomme data eller høje konsekvenser, skal du være ekstra konservativ med, hvilken AI du bruger, og hvordan du bruger den. Mere om det i afsnittet om regler og data.

Trin 2: Vælg værktøj og kontekst

Vælg AI-værktøj ud fra:

• Type opgave (kode, tekst, analyse)
• Datahensyn (må data sendes ud af huset?)
• Integration (IDE-plugin, chatinterface, intern model)

Til generel sparring og tekst er en chat-baseret LLM fin. Til kode arbejde kan integrerede værktøjer som Copilot eller IDE-plugins være mere effektive. Se fx udviklerguiden til Microsoft Copilot eller sammenlign modeller i Codex vs. Claude Code.

Trin 3: Forbered input og skriv et præcist prompt

Et godt prompt beskriver:

• Rolle (“du er senior backend-udvikler på et .NET API-projekt”)
• Opgave (“foreslå unit tests for denne funktion”)
• Kontekst (relevante brudstykker af kode, krav, constraints)
• Output-format (fx “giv kun tests i pytest-format, ingen forklaring”)

Brug kun den kontekst, der er nødvendig, og vær meget forsigtig med følsomme oplysninger. Hvis du er i tvivl om selve prompt-teknikken, er guiden sådan skriver du AI-prompts til kodning og debugging værd at tage en tur igennem.

Trin 4: Generér output og marker det som udkast

Når du får svar, skal du bevidst behandle det som et “første udkast”:

• Gem det adskilt fra din endelige kode/dokumentation til at starte med.
• Notér kort, hvad du har brugt AI til (fx i commit-besked eller issue-kommentar).
• Vurder, om svaret overhovedet er i nærheden af brugbart, før du investerer mere tid.

Trin 5: Kvalitetstjek og menneskelig godkendelse

Brug et simpelt kontrolflow:

• Læse- og fornuftstjek: Giver det mening? Passer det til konteksten?
• Teknisk verifikation: Kør tests, statisk analyse, linters, CI/CD.
• Second opinion: Tjek tvivlsomme ting mod dokumentation, officielle kilder eller en anden AI-model.
• Menneskelig sign-off: En ansvarlig udvikler godkender det endelige resultat.

Til kode bør du kombinere AI med eksisterende kvalitetssikring: pull requests, code review og automatiserede tests. Hvis du vil se, hvordan AI kan fungere som medprogrammør uden at tage styringen, er der en længere gennemgang i artiklen AI som medprogrammør.

Trin 6: Dokumentation og sporbarhed

For at sikre sporbarhed (revisionsspor) er det en god vane at dokumentere:

• Hvad AI er brugt til (fx “test-idéer genereret med AI”)
• Hvordan output er blevet kontrolleret og tilpasset
• Hvem der har godkendt det endelige resultat

Det kan være i README, arkitektur-dokumenter eller issue-kommentarer. En god introduktion til nyttig dokumentation er artiklen skriv en README der faktisk bliver læst.

Trin 7: Evaluér og juster workflowet

Efter nogle uger eller et projektforløb:

• Vurder, hvor AI faktisk har sparet tid eller forbedret kvalitet.
• Identificer situationer, hvor AI skabte mere arbejde (fx pga. fejl eller misforståelser).
• Opdater teamets retningslinjer og eksempelsamling af gode prompts.

Pointen er at se AI som et værktøj, der løbende skal trimmes ind i jeres proces, ikke som noget, der “bare bruges”.

Hvad siger reglerne om AI i arbejdsgangen?

Når AI bruges i udviklingsarbejde, er den vigtigste regel, at følsomme data, kundedata og kode med fortrolighedskrav ikke bare må sendes til et hvilket som helst værktøj. Brug kræver en vurdering af data, ansvar, rettigheder og interne politikker.

I Danmark spiller flere regelsæt sammen, når du bruger AI i arbejdet:

• GDPR og databeskyttelseslovgivningen, når der er personoplysninger.
• EU’s AI-forordning (AI Act), som regulerer brug og udvikling af visse AI-systemer.
• Interne politikker i din organisation om brug af sky-tjenester, kode og data.

Digitaliseringsstyrelsen har rollen som national koordinerende tilsynsmyndighed for AI-forordningen, og Datatilsynet fører tilsyn med databeskyttelse. Det betyder, at ansvaret i sidste ende ligger hos din organisation – ikke hos AI-værktøjet.

Data du skal være særligt forsigtig med

Som tommelfingerregel bør du ikke sende følgende til åbne, tredjeparts AI-tjenester uden en tydelig aftale og godkendelse:

• Personoplysninger (navne, e-mails, CPR, helbredsoplysninger, løn osv.)
• Følsomme interne dokumenter (strategi, økonomi, forhandlingsmateriale)
• Kundekode eller -data omfattet af NDA eller særlige kontraktvilkår
• Secrets som API-nøgler, adgangstokens, certifikater eller passwords

Til sidstnævnte findes der en hel lille verden af best practice, som du kan læse mere om i fx 7 små regler for secrets og artiklen stop med at gemme tokens tilfældigt i din webapp.

En enkel compliance-tjekliste til udviklingsteams

Brug denne mini-tjekliste, før du sender noget til en AI-tjeneste:

• Indeholder mit input personoplysninger eller andre følsomme data?
• Er koden eller dokumentet omfattet af fortrolighed eller kundekontrakter?
• Er værktøjet godkendt af vores organisation til denne type data?
• Ved jeg, hvor data gemmes, og om de bruges til at træne modellen?
• Er der en aftalt ansvarlig for, hvordan vi bruger AI i teamet (produkt-/tech lead, sikkerhedsansvarlig)?

Hvis du bliver i tvivl ved et af punkterne, er den sikre løsning at:

• anonymisere eller minimere data (tag kun de nødvendige bidder med)
• bruge en intern eller selv-hostet model, hvis muligt
• spørge en data- eller compliance-ansvarlig, før du går videre

Ved meget følsomme eller regulerede områder er det ofte nødvendigt at få en egentlig specialistvurdering, før AI bygges ind i løsningen.

Hvordan sikrer du kvaliteten af AI-output?

AI-output skal altid behandles som et første udkast, ikke som en endelig sandhed. Kvalitet sikres ved at sammenholde svaret med flere kilder, teste det mod faglig viden og lade et menneske godkende det før brug.

Her er en konkret model, du kan bruge hver gang du får et svar fra AI:

1. Fornuftstjek og rød-flag scanning

• Læs svaret langsomt igennem.
• Marker alt, der virker uklart, upræcist eller for godt til at være sandt.
• Spørg dig selv: “Hvis en junior-kollega gav mig dette, ville jeg så godkende det uden mere snak?”

2. Kilde- og dokumentationstjek

For tekst og fakta:

• Tjek påstande mod officielle kilder (dokumentation, standarder, myndighedssider).
• Bed modellen om at vise, hvilke antagelser svaret bygger på.
• Hvis modellen giver referencer, så tjek at de faktisk eksisterer og passer.

3. Brug flere modeller til vigtige svar

For svar med større betydning kan du med fordel:

• Stille det samme spørgsmål til to forskellige modeller.
• Sammenligne svarene: er de enige på de vigtige punkter?
• Ved uenighed: tag det som et signal om, at du selv skal grave dybere.

IDA peger netop på, at enighed mellem flere modeller øger troværdigheden – men den fjerner aldrig behovet for dit eget faglige blik.

4. Test og verifikation af kode

AI-genereret kode skal testes og gennemgås. Minimum:

• Kør alle relevante tests og tilføj nye tests for AI-koden.
• Brug statisk analyse, linters og sikkerhedsscannere.
• Lad en erfaren udvikler lave et grundigt code review.

Hvis koden integreres i et større system, skal hele kæden gennem din normale CI/CD-pipeline, så du ikke får “særlige undtagelser” for AI-kode.

5. Stop-regler: hvornår du ikke bør bruge svaret

Aftal nogle klare “stop-regler” i teamet, fx:

• Hvis svaret er inkonsistent eller selvmodsigende.
• Hvis du ikke kan forklare, hvordan løsningen virker, efter at have læst svaret.
• Hvis verifikation kræver mere tid end at løse opgaven uden AI.
• Hvis svaret peger mod løsninger, der strider mod interne standarder eller sikkerhedspraksis.

I de tilfælde er det ofte hurtigere og mere sikkert at lukke chatten og løse opgaven “manuelt”.

Hvornår er AI egnet – og hvornår er den ikke?

AI er egnet til opgaver med tydelige mønstre, lave konsekvenser og behov for tempo. Den er uegnet som eneste beslutningsgrundlag, når data er følsomme, konsekvenserne er høje, eller svaret skal være fuldt forklarbart.

Som huskeregel kan du tænke i to dimensioner: risiko og forklarbarhedskrav.

Egnet til

• Idégenerering (features, tests, backlog-struktur)
• Formuleringer (tekster, mails, dokumentation)
• Boilerplate-kode og simple funktioner
• Refaktorering, når du selv forstår koden i forvejen
• Sparring om fejlsøgning, hvor du selv styrer testen af forslagene

Uegnet som eneste løsning til

• Sikkerhedskritiske funktioner (autentifikation, autorisation, kryptering)
• Data-behandling med følsomme personoplysninger
• Automatiserede afgørelser, der påvirker mennesker direkte (ansættelse, kredit, sanktioner)
• Arkitektur- og teknologi-valg med store konsekvenser for drift og økonomi

I de uegnede scenarier kan AI stadig have en rolle som inspiration eller second opinion, men den endelige beslutning og løsning skal udarbejdes og begrundes af mennesker.

Hvordan bruger man AI til at arbejde smartere – uden at sænke kvaliteten?

AI kan gøre udviklingsarbejde hurtigere, hvis den bruges til forarbejde, struktur og udkast. Den skaber først reel værdi, når den indgår i et kontrolleret workflow, hvor kvalitet og ansvar stadig ligger hos mennesker.

Nogle enkle måder at bruge AI til at arbejde smartere:

• Forberedelse før møder
  Lad AI hjælpe med at opsummere issues, pull requests eller brugerfeedback, så du går ind i møder med et fælles overblik.
• Strukturering af opgaver
  Brug AI til at foreslå delopgaver, når du får en større user story. Du prioriterer selv bagefter.
• Automatisering af kedelige skriveopgaver
  Lad AI lave første udkast til changelogs, interne notater og simple vejledninger, som du bagefter retter til.
• Læring on-the-fly
  Brug AI som forklaringsmakker på nye biblioteker eller frameworks, så du hurtigere kommer i gang – og brug dokumentationen til den endelige sandhed.

For at sikre, at AI faktisk gør jer mere effektive, kan du løbende holde øje med:

• Hvor ofte AI-forslag bruges direkte vs. kasseres.
• Om fejlrate og bug-tickets stiger eller falder i områder med meget AI-kode.
• Om review-tiden pr. ændring bliver kortere eller længere.

Hvis AI konsekvent giver mere oprydningsarbejde end hjælp, skal workflowet strammes op – typisk ved at begrænse brugen til mere lavrisiko-opgaver eller forbedre prompts og kvalitetstjek.

Hvilke risici skal du kende, før du bruger AI?

De største risici ved AI i udviklingsarbejde er fejlagtige svar, bias, datalæk og falsk sikkerhed. Risikoen falder markant, når output kontrolleres, data begrænses, og AI aldrig får lov at stå alene med kritiske beslutninger.

De vigtigste risikokategorier:

• Fejlagtige eller opdigtede svar (hallucinationer)
  AI kan give svar, der lyder korrekte, men er direkte forkerte. Det gælder både tekst og kode.
• Bias og skævheder
  Modellen kan være trænet på data, der indeholder fordomme eller skæve repræsentationer, som påvirker dens forslag.
• Datalæk og fortrolighedsbrud
  Input kan blive gemt eller brugt til at træne modellen, afhængig af tjenestens vilkår. Det kan lække internt indhold til en ekstern leverandør.
• Teknisk gæld
  Hvis du hurtigt accepterer AI-kode uden at forstå den, kan du bygge komplekse, uigennemsigtige løsninger, som er svære at vedligeholde.
• Falsk sikkerhed
  “AI sagde det” kan blive en ubevidst autoritet, der skubber din egen faglige dømmekraft i baggrunden.

Modforanstaltningerne er i høj grad de samme, vi allerede har været igennem:

• Begræns og anonymiser data, der sendes til AI.
• Brug AI som udkastgenerator, ikke sandhedsvidne.
• Test og review AI-kode mindst lige så grundigt som menneskeskrevet kode.
• Dokumentér brugen af AI, så beslutninger kan efterprøves.
• Bevar en klar ansvarsfordeling: mennesker har ansvaret, ikke modellen.

Hvis du samtidig har styr på sikker basal udviklingshygiejne – fx korrekt håndtering af secrets, sikre integrationspunkter og fornuftig logging – står du langt stærkere, når AI bliver en del af din arkitektur. Her kan du bl.a. hente inspiration i artikler som secrets skal være kedelige, ikke spændende, logs vs. mavefornemmelse og webhook endpoints der overlever virkeligheden.

Sådan kommer du videre med ansvarlig AI i dit team

Hvis du skal opsummere en ansvarlig anvendelse af kunstig intelligens i udviklingsarbejde, kan du bruge denne korte huskeliste:

• Brug AI som assistent, ikke som beslutningstager.
• Hold følsomme data ude af uafklarede tredjeparts-tjenester.
• Behandl hvert svar som et udkast, der skal testes og reviewes.
• Dokumentér, hvor og hvordan AI er brugt i projektet.
• Evaluér løbende, om AI faktisk forbedrer jeres kvalitet og tempo.

Når de grundregler sidder fast, kan du gradvist udvide brugen til flere opgaver – og justere workflowet, efterhånden som både værktøjer og regler udvikler sig.