AI-bygget app: fem ting at tjekke, før den går live

I artiklen 11 afsnit

1. Hvorfor er AI-byggede apps særligt udsatte?
2. Fem tjek før en AI-bygget app går live
3. Tjek 1: Hvad kan regningen blive?
4. Tjek 2: Hvem kan læse jeres data?
5. Tjek 3: Skal appen være tilgængelig?
6. Tjek 4: Må I sende markedsføring?
7. Tjek 5: Hvem har ansvaret for persondata?
8. Hvad sker der, hvis I ikke tjekker?
9. Hvordan kan jeg hjælpe?
10. Hvad kan I gøre nu?
11. Ofte stillede spørgsmål

Hvorfor er AI-byggede apps særligt udsatte?

Med et AI-værktøj kan en app være bygget på en weekend. Værktøjet vælger database, adgangsregler og tjenester for jer, og det virker ofte. Men fart betyder, at ingen har kigget på det, som først bliver synligt, når appen bruges: hvem der kan læse data, hvad forbruget koster, og hvilke regler der gælder. Det gør ikke AI-værktøjer dårlige. Det betyder, at tjekket skal flyttes til ejeren af appen.

Artiklen her er en tjekliste, ikke en juridisk vurdering. Jeg er ikke jurist. Er I i tvivl om en regel, så spørg en jurist eller myndigheden. Bygger I generelt med AI, så læs også hvad I skal vide, når I bruger AI til at udvikle systemer.

Fem tjek før en AI-bygget app går live

Modellen hedder Fem tjek før en AI-bygget app går live. Den er min egen tjekliste, ikke en standard. Tabellen viser tjekkene, og afsnittene herunder går dem igennem.

Tjek 1: Hvad kan regningen blive?

Uden et loft kan forbrug vokse uden, at nogen ser det: en bot, et script, der kalder jeres API igen og igen, eller en fejl i appen. OWASP, som samler de mest almindelige sårbarheder i API'er, har det som en egen post, og nævner blandt andet manglende grænser, herunder for udgifter til tredjepart, og manglende rate limiting, altså grænser for, hvor ofte en bruger kan kalde API'et (OWASP API Security Top 10, 2023).

Tjek, hvad jeres udbydere tilbyder. Supabase har for eksempel et Spend Cap, men kun på Pro-planen. Er det slået til, afvises brug af en post, når kvoten er nået, i stedet for at blive faktureret; compute, egne domæner og punkt-for-punkt-gendannelse er ikke dækket (Supabase, dokumentation om Spend Cap). Sæt derfor også en alarm ved et beløb, og følg forbruget fra lanceringsdagen.

Tjek 2: Hvem kan læse jeres data?

Row Level Security (RLS) er en regel i databasen om, hvem der må læse og skrive hvilke rækker. Supabase skriver, at en tabel i et eksponeret skema uden RLS kan læses og skrives af enhver rolle med adgang, og at man bør slå RLS til på hver tabel (Supabase, dokumentation om Row Level Security).

Det er ikke teori. I National Vulnerability Database står CVE-2025-48757: "An insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites." Posten er vurderet til 9,3 af 10 (kritisk) og er udgivet 30. maj 2025. Samme post oplyser, at leverandøren bestrider den, fordi hver kunde selv har ansvaret for at beskytte appens data (National Vulnerability Database, 2025). Ansvaret ligger altså hos den, der driver appen.

• Slå adgangsregler til på hver tabel med data, der ikke skal være offentlige.
• Test reglerne som en bruger uden login og som en bruger med en anden rolle. At en regel findes, betyder ikke, at den virker.
• Hold hemmelige nøgler ude af browseren. Supabase: "Never use a secret key in the browser or expose it to customers."

Tjek 3: Skal appen være tilgængelig?

Ikke alle apps skal være tilgængelige efter loven. Ifølge Erhvervsstyrelsens og Digitaliseringsstyrelsens oplæg gælder tilgængelighedsloven fra 28. juni 2025 og omfatter blandt andet e-handelstjenester, altså hjemmesider og apps, hvor der kan indgås forbrugeraftaler. En mikrovirksomhed er en virksomhed med færre end 10 ansatte og en årlig omsætning eller balance på under 2 mio. euro, og dens tjenester er helt undtaget (Erhvervsstyrelsen og Digitaliseringsstyrelsen, oplæg om tilgængelighedsloven, 16. juni 2026).

Oplægget oplyser, at tilsynet tager udgangspunkt i EN 301 549 og WCAG 2.2, og at loven giver mulighed for at politianmelde og indstille til bøde. Er appen omfattet, så test med tastatur og skærmlæser, ikke kun med et værktøj. Er den et internt B2B-værktøj uden forbrugeraftaler, er den normalt ikke omfattet, men tilgængelighed er stadig god praksis.

Tjek 4: Må I sende markedsføring?

Skal appen sende nyhedsbreve, tilbud eller sms'er, gælder markedsføringsloven. Ifølge § 10, stk. 1, må en erhvervsdrivende ikke rette henvendelse til nogen med elektronisk post uden forudgående samtykke (markedsføringsloven § 10). Forbrugerombudsmandens vejledning viser det for e-mail og sms, med en begrænset undtagelse for tidligere kunder om egne tilsvarende produkter (Forbrugerombudsmanden, Hvornår må en erhvervsdrivende henvende sig). Loven kræver også en adresse, modtageren kan bruge til at få henvendelserne standset.

Praktisk betyder det: ingen forudkrydsede bokse, gem tidspunkt og formulering for hvert samtykke, giv en tydelig afmelding, og hold besked om en ordre adskilt fra markedsføring. De sidste er mine anbefalinger, ikke lovtekst.

Tjek 5: Hvem har ansvaret for persondata?

Gemmer appen oplysninger om personer, skal I vide, hvor de ligger, og hvem der er ansvarlig. Behandler I dem for en kunde, er I databehandler og skal have en aftale. Har I bygget appen med en tjeneste, der sender data til en AI-model, så tjek hvilke data der sendes hvorhen. Se seks ting, før AI bygger noget, og hvad I skal dokumentere.

Hvad sker der, hvis I ikke tjekker?

Fejlene bliver dyrere at rette efter lancering end før: data kan være hentet af andre, en regning er betalt, en henvendelse er sendt uden samtykke, eller en myndighed har stillet spørgsmål. Hvem der ejer appen og kan rette den, er svært at finde ud af, når ingen har dokumenteret det. Se hvad der skal leve videre efter go-live.

Hvordan kan jeg hjælpe?

Jeg gennemgår en AI-bygget app mod de fem tjek, før den går live, og siger, hvad der skal rettes først. Jeg arbejder i denne rækkefølge: forstå processen → udvikle løsningen → integrere den → hjælpe med drift og videreudvikling. Se mine systemer og løsninger. Jeg giver ikke juridisk rådgivning og garanterer ikke compliance. Når appen kører, kan SPOR holde styr på, hvad der findes, og hvem der ejer det.

Hvad kan I gøre nu?

Gør dette:

1. Find ud af, hvilken udbyder og database appen bruger, og sæt et forbrugsloft og en alarm.
2. Tjek adgangsreglerne på hver tabel, og test som en bruger uden login.
3. Afklar, om appen er omfattet af tilgængelighedskrav.
4. Gennemgå, hvordan samtykke indhentes og logges, hvis appen sender markedsføring.
5. Skriv ned, hvor persondata ligger, og hvem der ejer appen.

Kort sagt: Brug en time pr. tjek, før appen går live. Det er meget billigere end at rette bagefter.

Ofte stillede spørgsmål

Hvad er Row Level Security?

Row Level Security (RLS) er en database-regel, der bestemmer, hvilke rækker en bruger må se og ændre. Er den slået fra på en tabel, der kan nås udefra, kan enhver med adgang til API'et læse og skrive i tabellen. Supabase anbefaler at slå den til på hver tabel i et eksponeret skema.

Skal min AI-byggede app leve op til tilgængelighedskrav?

Det afhænger af, hvad appen bruges til og hvem der driver den. Ifølge Erhvervsstyrelsen gælder tilgængelighedsloven for e-handelstjenester, altså hjemmesider og apps, hvor der kan indgås forbrugeraftaler, og tjenester fra mikrovirksomheder er undtaget. Et internt værktøj uden forbrugeraftaler er normalt ikke omfattet. Er I i tvivl, så spørg Erhvervsstyrelsen.

Må jeg sende nyhedsbreve og sms'er til alle, jeg har en e-mailadresse på?

Nej. Markedsføringsloven forbyder at rette henvendelse til nogen med elektronisk post uden forudgående samtykke, med en begrænset undtagelse for tidligere kunder om egne tilsvarende produkter. Forbrugerombudsmandens vejledning forklarer reglerne.

Hvem har ansvaret, hvis en AI-bygget app lækker data?

Den, der driver appen. Selv i sagen om Lovable, hvor databasereglerne var for svage, oplyser National Vulnerability Database, at leverandøren bestrider sårbarheden med henvisning til, at hver kunde selv har ansvaret for at beskytte appens data. Tjek derfor selv adgangsreglerne.

Artiklen er generel vejledning og ikke juridisk rådgivning. Udgivet 4. oktober 2026.