Fra AI-prototype til driftsikker løsning: Det tog vi med til NextStep Randers

Fra AI-prototype til driftsikker løsning: Det tog vi med til NextStep Randers

Jeg var inviteret til at holde oplæg på NextStep Randers om springet fra AI-prototype til driftsikker løsning. Inden jeg gik i gang med slides, spurgte jeg mit netværk på LinkedIn, hvad de helst ville høre om. Svaret var tydeligt: Vis os det, der går galt i virkeligheden. Men send os ikke hjem med skrækhistorier alene – giv os noget, vi kan bruge bagefter.

Det blev opskriften på oplægget. Og det er også opskriften på dette blogindlæg. Først en opsummering af, hvad jeg fortalte. Bagefter en introduktion til den gratis guide, vi har lavet til alle, der bygger software med AI.

👉 Gå direkte til guiden: Fra AI-prototype til sikker drift

AI kan bygge prototypen. Det er ikke længere spørgsmålet

Jeg har udviklet apps, siden jeg i 2010 var med til at bygge Danske Banks mobilbank. Senere var jeg også med på MobilePay. Hvis man har været med til at bygge noget, som millioner af mennesker bruger hver dag, lærer man én ting: Det svære er ikke at få det til at virke. Det svære er at få det til at blive ved med at virke.

I dag kan næsten alle bygge en overbevisende prototype med Lovable, Replit, Cursor eller Claude Code. Det er fantastisk. Men det interessante spørgsmål er, hvad der sker, når prototypen møder rigtige brugere, rigtige data, eksisterende systemer og en rigtig forretning.

Tre historier fra virkeligheden

1. Agenten, der slettede databasen. I 2025 brugte Jason Lemkin Replits AI-agent til at bygge en løsning. Midt i en periode, hvor ingen måtte røre systemet, slettede agenten produktionsdatabasen med oplysninger om knap 1.200 virksomheder. Det skete, selv om den havde fået besked på ikke at røre de rigtige data. En prompt er ikke en sikkerhedsmekanisme.

2. Et login uden vægge bagved. Samme år gennemgik forskere knap 1.700 apps bygget med Lovable. Over 10 % havde utilstrækkelig adgangskontrol: Der var en login-side, der så rigtig ud, men en bruger kunne potentielt se andre brugeres data.

Vi har selv mødt det hos en kunde. Direktøren havde bygget et imponerende system med AI, som samlede hele virksomheden ét sted – inklusive firmaets mails. AI’en havde forsikret ham om, at sikkerheden var i orden. Da vi kiggede på koden, viste det sig, at alle kald til serveren kunne foretages uden at være logget ind. Der var en låst hoveddør i brugerfladen. Der var bare ingen vægge bagved. Et login er ikke det samme som adgangskontrol.

3. Problemet i stor skala. I maj 2026 undersøgte RedAccess offentligt tilgængelige AI-byggede apps. Kun lidt over 1 % så ud til at have meget svag eller manglende adgangskontrol – men det svarede til mere end 5.000 systemer (WIRED har beskrevet sagen). Og det er kun dem, vi kan se.

Hvorfor sker det? Tidligere sad en juniorudvikler sjældent alene og byggede noget, virksomheden var afhængig af. I dag kan dem, der kender forretningen bedst, selv bygge noget, der ser rigtig godt ud. Det er en kæmpe gevinst. Men beder man AI om en login-side, så får man en login-side – ikke nødvendigvis sikkerheden bagved.

Fem barrierer, der ville have gjort en forskel

Problemet i de tre historier er ikke, at AI’en lavede fejl. Det gør mennesker også. Problemet er, at intet stoppede fejlen, før den ramte rigtige data og rigtige mennesker.

1. Kun nødvendig adgang. Rengøringsfirmaet får en nøgle til kontoret – ikke koden til pengeskabet. Skal en AI-agent skrive kode, behøver den ikke kunne slette produktionsdatabasen.
2. Udvikling og produktion er adskilt. Udviklingsmiljøet er kladden. Produktionsmiljøet er mailen, der er sendt.
3. Adgang håndhæves i serveren og databasen. Det er ikke nok, at brugerfladen skjuler noget.
4. Test sikkerheden aktivt. Log ind som bruger A, og prøv at se bruger B’s data.
5. Backup og restore. En backup er først noget værd, når du har prøvet at gendanne den.

Eller sagt kort: En prompt er en seddel. En rettighed er en lås. Prompten fortæller agenten, hvad den bør gøre. Rettighederne bestemmer, hvad den kan gøre.

“Det virker” – men på hvilket niveau?

Når nogen fortæller mig, at deres løsning virker, er mit næste spørgsmål altid: På hvilket niveau? Jeg deler det op i tre:

AI har gjort niveau 1 meget lettere. Niveau 2 og 3 kræver stadig omtanke, systematik og ansvar. Niveauerne er ikke tre vandtætte kasser – man skal ikke vente med sikkerheden, til prototypen er færdig – men tre forskellige spørgsmål til den samme løsning.

Niveau 2: Klar til rigtige brugere

• Sikkerhed: Brugere kan kun se deres egne data, og nøgler og passwords ligger ikke, hvor andre kan finde dem.
• Data og GDPR: Ved vi, hvad vi gemmer, hvor det ligger, hvem der modtager det – og kan vi slette det igen?
• Tests: Kritiske flows skal testes. AI’ens egne grønne flueben betyder kun, at testene består – ikke at de tester det rigtige.
• Fejlhåndtering: Hvad sker der, når en ekstern tjeneste er nede, eller nogen trykker to gange på betal-knappen?
• Performance og forbrug: Hvad sker der med hundrede samtidige brugere – og hvad koster AI-kaldene ved tusind?
• Deployment: Nye versioner afprøves et sikkert sted først og kan rulles tilbage.

Niveau 3: Klar til daglig drift

• Logging: Kan vi se, hvad der skete i går klokken tre – uden at gemme passwords og personoplysninger i loggen?
• Monitoring og alarmer: Et rigtigt menneske skal have besked ved nedbrud, fejl og unormalt forbrug.
• Dokumentation: Kan en anden overtage, hvis den person, der byggede løsningen, er syg eller på ferie?
• Driftsberedskab: Hvem rykker ud, og hvem informerer kunderne? Planen skal laves, før det brænder.
• Opdateringer: Hvem holder byggeklodserne opdateret og reagerer, når der kommer en kritisk sikkerhedsrettelse?

Det danske CPR-databrud i oktober 2026 er et godt eksempel på, hvorfor alarmer betyder noget. Oplysninger om omkring 8,8 millioner personer blev hentet gennem misbrug af en lovlig adgang over cirka ti dage – og det blev opdaget på grund af en usædvanligt dyr faktura, ikke en automatisk alarm. Unormal aktivitet skal udløse en alarm, før fakturaen gør.

Hvis jeg skal koge det ned til én pointe, er det denne: AI har gjort det meget lettere at få et system til at virke. Men det er kun det første spørgsmål. De næste er:

• Opdage: Kan vi opdage, at det ikke virker?
• Forstå: Kan vi forstå, hvorfor det ikke virker?
• Genoprette: Kan vi få normal drift tilbage – hurtigt og kontrolleret?

Min egen tilbudsgenerator, der aldrig blev færdig

Der er noget ved AI-udvikling, jeg selv har oplevet mange gange. Det går så hurtigt, at man næsten ikke kan lade være med at få nye idéer. Kan du ikke også lige…? Og AI svarer nærmest altid ja. Ti minutter senere har man en ny funktion. Så en mere. Og en mere. Pludselig har man bygget noget langt mere komplekst end planlagt, uden at nogen har taget stilling til helheden. Sådan opstår teknisk gæld.

Det skete også for mig. Hos Holion bruger vi meget tid på at skrive gode tilbud, så jeg fik en idé: Vi optager kundemødet, samtalen bliver transskriberet, AI skriver tilbuddet, og til sidst bliver det til et flot dokument. Fra kundemøde til færdigt tilbud. Automatisk.

De første dele kom hurtigt til at virke. Men et skræddersyet tilbud handler ikke kun om at skrive ned, hvad kunden har sagt. Vi skal forstå behovet, vurdere hvad der teknisk kan lade sig gøre, estimere tid og risiko – og nogle gange udfordre kundens eget forslag. Det kan man ikke udlede af ét møde.

I stedet for at stoppe op, byggede jeg videre. Hver gang jeg fandt en begrænsning, svarede jeg med en ny funktion. Til sidst var projektet noget rod, og vi har valgt at fokusere på andre ting. Ikke fordi AI gjorde noget forkert. Det var mig, der ikke fik afgrænset problemet.

Det vigtigste spørgsmål stillede jeg først bagefter: Er det her overhovedet noget, vi skal automatisere? Et skræddersyet tilbud er en del af kernen i vores forretning. Det er dér, kunden mærker, at vi har lyttet. Brug AI til det, der stjæler tid fra kernen i jeres forretning – ikke til at erstatte den. Når alt er nemt at bygge, kræver det ledelse at vælge det væsentlige og sige nej til resten.

Du behøver ikke forstå koden – men du skal forstå risikoen

Du behøver ikke være udvikler for at tage ansvar for et softwareprojekt. Ligesom du ikke behøver være revisor for at styre virksomhedens økonomi. Men du skal kunne stille de rigtige spørgsmål:

1. Hvad er egentlig færdigt – og hvad mangler stadig?
2. Hvordan ved vi, at løsningen er testet?
3. Hvad sker der, hvis noget går galt?
4. Hvad koster det, hvis vi pludselig får tusind brugere?
5. Hvem har ansvaret for driften?

Havde jeg stillet de spørgsmål til min tilbudsgenerator undervejs, havde de fleste svar været: Det ved jeg faktisk ikke.

Tag dit AI-projekt til eksamen

Vi kan også bruge AI til at finde de problemer, som den hurtige AI-udvikling skaber. Hvis du har bygget noget med Claude Code, Cursor, Lovable eller et andet værktøj, så prøv at gøre noget andet end at bede om endnu en funktion:

1. Gennemgå. Bed AI om at undersøge projektet kritisk – ikke om at fortælle dig, hvor godt det er, men om at finde fejl og mangler.
2. Prioritér. Bed om de kritiske problemer først, dokumentation for hvert fund og en konkret rækkefølge.
3. Kontrollér. Siger AI, at adgangskontrollen er rettet, så test den. Siger den, at der er backup, så prøv at gendanne den. Siger den, at der kommer en alarm, så udløs en fejl og se, om nogen får besked.

Guiden: Fra AI-prototype til sikker drift

For at gøre det konkret har vi lavet en gratis onlineguide, som publikum på NextStep fik med hjem via en QR-kode. Nu er den også til dig.

Åbn guiden på slides.holion.dk/nextstep-randers/guide

Guiden har to indgange:

• Jeg har allerede bygget noget – Kopiér vores universelle prompt ind i Claude Code, Cursor eller et tilsvarende værktøj med dit projekt åbent. Du får en prioriteret rapport, hvor hvert område er markeret som rødt, gult, grønt eller “kan ikke vurderes”. Prompten arbejder kun read-only, kræver konkrete beviser fra projektet og forklarer fundene på almindeligt dansk.
• Jeg er ved at bygge noget – Følg korte guider til hvert emne på de tre niveauer, fra formål og afgrænsning over adgangskontrol og GDPR til backup, gendannelse og driftsberedskab.

Hvert emne i guiden er bygget op på samme måde:

• Et virkelighedsnært scenarie, der viser, hvad der kan gå galt.
• Minimumskrav, der skal være på plads.
• Hvad AI skal undersøge i dit projekt – med en prompt, du kan kopiere direkte.
• Hvordan du selv kontrollerer resultatet i praksis, i stedet for blot at spørge AI’en, om det er i orden.
• Hvornår du bør få professionel hjælp, fx ved følsomme data, betalinger eller store konsekvenser ved fejl.

Bruger dit produkt selv AI, er der et særskilt modul om blandt andet hallucinationer, prompt injection, begrænsning af AI’ens rettigheder, menneskelig godkendelse af kritiske handlinger og kontrol med forbruget.

Til sidst er der en go/no-go-tjekliste til tiden lige før lanceringen. Den skelner mellem det, der blokerer en lancering – fx at brugere kun kan se egne data, at gendannelse er testet, og at en navngiven person har driftsansvaret – og det, der kan planlægges bagefter.

En vigtig pointe: AI’s rapport er ikke en sikkerhedsgodkendelse. AI kan overse fejl – også i sin egen kode – og den kan lyde meget sikker, når den tager fejl. Derfor skal fund dokumenteres og løsninger kontrolleres. Ved kritiske systemer er der stadig brug for en erfaren udvikler eller sikkerhedsspecialist.

Byg hurtigt. Test grundigt. Tag ansvar.

Jeg er kæmpe tilhænger af at bruge AI til softwareudvikling. Vi bruger det selv hver dag hos Holion, og vi kan bygge ting i dag, som tidligere krævede langt større budgetter og meget mere tid. Det skal vi udnytte. Men vi skal passe på, at vi ikke bliver så begejstrede for hastigheden, at vi glemmer kvaliteten.

Så mit råd er enkelt: Byg hurtigt. Test grundigt. Og tag ansvar. AI har gjort det nemmere end nogensinde at bygge software. Men det er stadig os mennesker, der har ansvaret for det, vi sender ud i verden.

Tak til NextStep Randers for invitationen, og tak til alle, der kom og lyttede – og til mit netværk på LinkedIn, der var med til at forme oplægget.

Har du bygget noget med AI, som du gerne vil have taget til eksamen af en erfaren udvikler? Så ring til os på 82 30 34 20, eller book et uforpligtende møde.