Temporary unstable
Temporary unstable
Compliance ved vibe coding og AI-assisteret softwareudvikling
Vibe coding har gjort det muligt for én person at udvikle software, som tidligere ville have krævet et mindre udviklingsteam. Med AI-værktøjer kan en freelancer udvikle en prototype, opbygge brugergrænseflader, skrive dokumentation, generere tests, finde fejl og i nogle tilfælde få et helt fungerende program på ganske kort tid.
Det ændrer imidlertid ikke på ansvaret for det færdige produkt.
Hvis man udgiver et Windows-program, en Android-app, en webapplikation eller et AI-baseret værktøj, er spørgsmålet ikke kun: Virker programmet?
Man bør også spørge: Ved jeg, hvad programmet gør, hvorfor det gør det, hvilke data det behandler, hvilke komponenter det bruger, hvilke risici der findes, og kan jeg dokumentere, at jeg har forsøgt at gøre det ordentligt?
Compliance behøver ikke betyde et stort bureaukrati. For en freelancer handler det snarere om at etablere en proportionel og dokumenterbar udviklingspraksis.
AI må gerne skrive kode. AI må ikke overtage udviklerens ansvar.
1. Juridisk compliance
Software eksisterer ikke uden for lovgivningen. Hvilke regler der gælder, afhænger blandt andet af produktet, brugerne, markedet og de data, der behandles. En simpel sprogapp uden brugerregistrering har eksempelvis en anden risikoprofil end et system, der behandler kundedata, e-mails, helbredsoplysninger eller oplysninger om børn.
☐ Har jeg beskrevet, hvad produktet faktisk gør?
☐ Har jeg identificeret, hvem brugerne er?
☐ Har jeg undersøgt, hvilke lande produktet tilbydes i?
☐ Har jeg undersøgt, om GDPR er relevant?
☐ Ved jeg, hvilke personoplysninger produktet behandler?
☐ Har jeg et lovligt grundlag for behandlingen?
☐ Har jeg beskrevet formålet med dataindsamlingen?
☐ Indsamler jeg kun nødvendige data?
☐ Kan brugeren få sine data slettet, hvor det kræves?
☐ Har jeg fastlagt, hvor længe data opbevares?
☐ Ved jeg, hvor data fysisk eller organisatorisk behandles?
☐ Anvender jeg eksterne databehandlere eller cloudtjenester?
☐ Er nødvendige databehandleraftaler på plads?
☐ Har produktet en passende privatlivspolitik?
☐ Anvender produktet cookies, analytics eller tracking?
☐ Er regler omkring børn relevante?
☐ Er forbrugerregler relevante?
☐ Er tilgængelighedskrav relevante?
☐ Er EU's AI-regulering relevant?
☐ Har jeg identificeret områder, hvor juridisk rådgivning er nødvendig?
2. Privacy og databeskyttelse
Privacy bør være en del af designet. En nyttig tilgang er privacy by design og data minimisation: Hvis programmet ikke behøver en oplysning, bør man overveje slet ikke at indsamle den. Jo færre følsomme data en solo-udvikler opbevarer, desto mindre bliver både sikkerhedsarbejdet og konsekvenserne af et eventuelt databrud.
☐ Har jeg lavet en liste over alle data, programmet indsamler?
☐ Ved jeg, hvorfor hver datatype er nødvendig?
☐ Kan noget af dataindsamlingen fjernes?
☐ Kan data behandles lokalt i stedet for i skyen?
☐ Ved brugeren, hvilke oplysninger der indsamles?
☐ Ved brugeren, hvorfor oplysningerne indsamles?
☐ Ved brugeren, om data sendes til tredjeparter?
☐ Sender programmet data til AI-tjenester?
☐ Har jeg undersøgt AI-leverandørens behandling af data?
☐ Indeholder logs personoplysninger?
☐ Kan logs anonymiseres?
☐ Har jeg defineret opbevaringstider?
☐ Kan data slettes?
☐ Kan nødvendige data eksporteres?
☐ Er backup omfattet af slettepolitikken?
☐ Er testdata fri for unødvendige personoplysninger?
☐ Undgår jeg produktionsdata i udviklingsmiljøet?
☐ Er privatlivsindstillinger forståelige?
☐ Har jeg dokumenteret dataflowet?
☐ Har jeg gennemgået privacy før release?
3. Software- og sikkerhedscompliance
AI kan generere fungerende kode, som samtidig indeholder sikkerhedsproblemer. Det gælder især authentication, filhåndtering, databaser, API'er, netværkskommunikation og brugerinput. AI-genereret kode bør forstås, gennemgås og testes.
☐ Ligger API-nøgler uden for kildekoden?
☐ Er passwords og tokens beskyttet?
☐ Er .env og tilsvarende filer udelukket fra Git?
☐ Har jeg kontrolleret repository for gamle secrets?
☐ Valideres brugerinput?
☐ Er filuploads begrænset og kontrolleret?
☐ Anvendes sikre forbindelser?
☐ Er authentication implementeret korrekt?
☐ Er authorization adskilt fra authentication?
☐ Har brugere kun de nødvendige rettigheder?
☐ Håndteres fejl uden at afsløre følsomme oplysninger?
☐ Indeholder logs passwords, tokens eller andre secrets?
☐ Er databasen beskyttet?
☐ Findes der backup, hvis produktet kræver det?
☐ Er restore blevet afprøvet?
☐ Er dependencies opdaterede?
☐ Scannes dependencies for kendte sårbarheder?
☐ Er debug-funktioner fjernet fra produktion?
☐ Har jeg foretaget en sikkerhedsgennemgang før release?
☐ Ved jeg, hvad jeg gør, hvis en sikkerhedsfejl opdages?
4. Dependencies, open source og licenser
Et program består sjældent kun af ens egen kode. Selv et lille projekt kan benytte mange biblioteker, frameworks, fonts, billeder, ikoner, databaser, API'er og AI-tjenester. Vibe coding kan gøre dette mindre gennemskueligt, fordi AI hurtigt kan installere en dependency uden et bevidst valg.
☐ Har jeg en liste over væsentlige dependencies?
☐ Ved jeg, hvorfor de enkelte dependencies anvendes?
☐ Er unødvendige dependencies fjernet?
☐ Kender jeg deres licenser?
☐ Må de anvendes kommercielt?
☐ Kræver nogen licenser attribution?
☐ Kræver licensen offentliggørelse af kildekode?
☐ Har jeg dokumenteret tredjepartskomponenter?
☐ Ved jeg, hvor billeder kommer fra?
☐ Ved jeg, hvor ikoner kommer fra?
☐ Ved jeg, hvor fonts kommer fra?
☐ Har jeg rettigheder til testdata?
☐ Har jeg rettigheder til trænings- eller eksempeltekster?
☐ Er eksterne API'ers vilkår undersøgt?
☐ Er AI-tjenesternes vilkår undersøgt?
☐ Er versionsnumre registreret?
☐ Kan projektets dependencies reproduceres?
☐ Har jeg kontrolleret kendte sårbarheder?
☐ Kan problematiske komponenter udskiftes?
☐ Kan jeg forklare, hvilke væsentlige tredjepartskomponenter produktet bygger på?
5. En dokumenteret udviklingsproces
Her ligger en væsentlig forskel mellem eksperimentel vibe coding og professionel AI-assisteret udvikling. Der er intet galt i at begynde med en prototype. Problemet opstår, hvis prototypen bliver produktionssoftware uden et tidspunkt, hvor projektet går fra eksperiment til kontrolleret udvikling.
☐ Findes der en beskrivelse af produktets formål?
☐ Findes der funktionelle krav?
☐ Findes der ikke-funktionelle krav?
☐ Er projektets scope defineret?
☐ Er arkitekturen beskrevet?
☐ Er centrale designbeslutninger dokumenteret?
☐ Bruges versionsstyring?
☐ Er commits meningsfulde?
☐ Anvendes branches, når det er relevant?
☐ Kan en tidligere version genskabes?
☐ Findes der versionsnumre?
☐ Findes der release-noter eller changelog?
☐ Er større ændringer dokumenteret?
☐ Er kendte begrænsninger dokumenteret?
☐ Er væsentlige bugs registreret?
☐ Er dokumentationen opdateret sammen med koden?
☐ Er build-processen dokumenteret?
☐ Kan projektet bygges fra en ren installation?
☐ Kan en anden teknisk person forstå projektets grundstruktur?
☐ Er der et klart kriterium for, hvornår en version er klar til release?
6. Test, validering og kvalitetssikring
At et program starter uden fejl betyder ikke, at det er testet. Test skal undersøge, om programmet gør det, kravene siger, og om det reagerer fornuftigt, når noget går galt. AI kan hjælpe med tests, men menneskelig validering er fortsat vigtig.
☐ Findes der en teststrategi?
☐ Er centrale funktioner testet?
☐ Findes unit tests, hvor de giver mening?
☐ Findes integrationstests, hvor de giver mening?
☐ Er brugerflows testet?
☐ Er ugyldigt input testet?
☐ Er tomme værdier testet?
☐ Er grænseværdier testet?
☐ Er fejlscenarier testet?
☐ Er manglende internetforbindelse testet, hvis relevant?
☐ Er manglende filer eller ressourcer testet?
☐ Er permissions testet?
☐ Er installation testet?
☐ Er opgradering fra tidligere version testet?
☐ Er afinstallation testet, hvis relevant?
☐ Er relevante enheder eller skærmstørrelser testet?
☐ Er regressionstest gennemført efter større ændringer?
☐ Dokumenteres testresultater?
☐ Er kritiske fejl rettet før release?
☐ Er den endelige pakkede version testet og ikke kun udviklingsversionen?
7. AI som udviklingsværktøj
Der er en vigtig forskel mellem software udviklet ved hjælp af AI og software, der selv anvender AI. Hvis Codex eller et andet værktøj hjælper med kode, betyder det ikke i sig selv, at slutproduktet er et AI-system. Men AI-brugen bør stadig håndteres professionelt.
☐ Ved jeg, hvilke AI-værktøjer der anvendes?
☐ Ved jeg, hvilke dele af processen AI assisterer?
☐ Sender jeg fortrolige oplysninger til AI?
☐ Sender jeg persondata til AI?
☐ Sender jeg kunders kildekode eller dokumenter til AI?
☐ Har jeg ret til at gøre det?
☐ Gennemgås AI-genereret kode?
☐ Testes AI-genereret kode?
☐ Kontrolleres AI-genererede dependencies?
☐ Kontrolleres foreslåede API'er og funktioner?
☐ Kontrolleres sikkerhedskritisk kode særskilt?
☐ Accepteres større refaktoreringer kun efter review?
☐ Kan jeg forklare programmets centrale funktioner uden AI?
☐ Dokumenteres væsentlige arkitekturbeslutninger?
☐ Kontrolleres AI-genereret dokumentation?
☐ Kontrolleres AI-genererede juridiske påstande særskilt?
☐ Kontrolleres fakta frem for blot formulering?
☐ Er menneskelig godkendelse nødvendig før release?
☐ Kan projektet fortsættes uden den konkrete AI-session?
☐ Er det tydeligt, at ansvaret for produktet ligger hos udvikleren?
8. Når AI er en del af selve produktet
Hvis produktet selv bruger en sprogmodel, billedmodel, klassifikationsmodel eller anden AI, kommer yderligere spørgsmål til. Brugeren bør kunne forstå, hvornår AI anvendes, hvad den bruges til, og hvilke væsentlige begrænsninger der findes.
☐ Er det dokumenteret, hvor produktet anvender AI?
☐ Ved brugeren, når AI har væsentlig betydning for output?
☐ Er AI's funktion klart beskrevet?
☐ Er modellens leverandør kendt?
☐ Er relevante modelversioner registreret?
☐ Ved jeg, hvilke data der sendes til modellen?
☐ Er persondata beskyttet?
☐ Kan følsomme oplysninger undgås?
☐ Er risikoen for hallucinationer vurderet?
☐ Er væsentlige AI-output valideret?
☐ Er der human oversight, hvor konsekvenserne kræver det?
☐ Kan brugeren rette eller tilsidesætte AI-resultatet?
☐ Er automatiske beslutninger identificeret?
☐ Er bias eller diskriminationsrisici vurderet?
☐ Er misbrugsscenarier overvejet?
☐ Er relevante begrænsninger kommunikeret?
☐ Er AI Act-relevansen vurderet?
☐ Er risikoklassifikationen undersøgt, hvis relevant?
☐ Kan AI-funktionen deaktiveres, hvis det er nødvendigt?
☐ Findes der en procedure for fejlbehæftede eller skadelige AI-resultater?
9. Etik ud over compliance
Lovlig software er ikke nødvendigvis god software. Compliance fastlægger ofte minimumskrav. Etik stiller spørgsmålet: Bør vi gøre det, bare fordi vi kan gøre det? Det er især relevant med AI, overvågning, adfærdsanalyse, børn, personalisering og store datamængder.
☐ Løser produktet et reelt problem?
☐ Er produktets egentlige formål tydeligt for brugeren?
☐ Indsamler jeg oplysninger, blot fordi det teknisk er muligt?
☐ Respekterer designet brugerens privatliv?
☐ Er brugerens valg reelt frivilligt?
☐ Undgår jeg manipulerende dark patterns?
☐ Er det let at sige nej?
☐ Er det let at fortryde?
☐ Kan brugeren forstå konsekvenserne af sine valg?
☐ Er børn eller sårbare personer involveret?
☐ Kan produktet bruges til overvågning?
☐ Kan produktet misbruges?
☐ Har jeg overvejet utilsigtede konsekvenser?
☐ Kan algoritmer stille bestemte grupper dårligere?
☐ Er automatiske vurderinger rimelige?
☐ Gør jeg AI mere autoritativ, end den reelt er?
☐ Kan brugeren se forskel på fakta og AI-genererede vurderinger?
☐ Respekterer produktet brugerens autonomi?
☐ Ville jeg selv acceptere den samme databehandling som bruger?
☐ Kan jeg offentligt forklare og forsvare produktets grundlæggende designvalg?
Transparens betyder ikke, at al kildekode skal offentliggøres. Det betyder, at man ikke skjuler væsentlige forhold for brugeren, f.eks. dataindsamling, AI-anvendelse, eksterne tjenester eller væsentlige begrænsninger.
☐ Er udvikleren eller virksomheden identificerbar?
☐ Findes kontaktoplysninger?
☐ Er produktets formål beskrevet?
☐ Er centrale funktioner beskrevet korrekt?
☐ Undgår markedsføringen overdrevne påstande?
☐ Er væsentlige begrænsninger beskrevet?
☐ Er AI-anvendelse oplyst, når det er relevant?
☐ Er dataindsamling forklaret?
☐ Er tredjepartsbehandling forklaret?
☐ Er brugerens rettigheder forståelige?
☐ Findes versionsnummer?
☐ Findes ændringshistorik, hvor det er relevant?
☐ Er kendte alvorlige problemer dokumenteret?
☐ Kan brugeren rapportere fejl?
☐ Kan brugeren stille spørgsmål om privacy?
☐ Kan brugeren identificere AI-genereret indhold, når det er nødvendigt?
☐ Er automatiske beslutninger forklaret, hvor det kræves?
☐ Er dokumentationen skrevet i forståeligt sprog?
☐ Er tekniske og juridiske påstande korrekte?
☐ Kan jeg dokumentere de vigtigste påstande, jeg fremsætter om produktet?
En solo-udvikler kan ikke efterligne en stor virksomheds complianceorganisation, og det bør heller ikke være målet. Compliance bør være proportionel med risikoen. Et lokalt desktopværktøj uden internet og persondata kræver normalt ikke samme governance som en cloudtjeneste med store mængder personoplysninger.
☐ Har jeg klassificeret projektets risikoniveau?
☐ Ved jeg, hvilke områder jeg selv kan håndtere?
☐ Ved jeg, hvornår jeg skal hente ekstern ekspertise?
☐ Har jeg adskilt prototype og produktionsversion?
☐ Har jeg backup af projektet?
☐ Er repository sikret?
☐ Er adgang til udviklingssystemerne beskyttet?
☐ Er kundedata adskilt fra testdata?
☐ Har jeg en enkel releaseprocedure?
☐ Har jeg en testcheckliste før release?
☐ Har jeg en sikkerhedscheckliste før release?
☐ Har jeg en privacy-checkliste før release?
☐ Har jeg en licenscheckliste før release?
☐ Har jeg dokumenteret væsentlige AI-værktøjer?
☐ Har jeg styr på abonnementer og eksterne tjenester, produktet afhænger af?
☐ Ved jeg, hvad der sker med brugerne, hvis jeg stopper produktet?
☐ Kan data eksporteres eller afleveres, hvis nødvendigt?
☐ Har jeg en procedure for alvorlige fejl?
☐ Har jeg en procedure for sikkerhedshændelser?
☐ Kan jeg dokumentere, hvorfor jeg vurderede produktet som forsvarligt at udgive?
Et lille projekt behøver ikke et kvalitetssystem på tusind sider. En praktisk løsning er en /docs-mappe i projektets repository med f.eks. README.md, REQUIREMENTS.md, ARCHITECTURE.md, DATA-FLOW.md, PRIVACY.md, SECURITY.md, DEPENDENCIES.md, AI-USAGE.md, TESTING.md, RELEASE-CHECKLIST.md og CHANGELOG.md.
Ti korte og opdaterede dokumenter er mere værd end et compliance-system på 200 sider, som ingen vedligeholder.
☐ Kravene til denne version er defineret.
☐ Den korrekte kode er committed.
☐ Repository er clean.
☐ Den korrekte version er tagget eller identificeret.
☐ Projektet kan bygges reproducerbart.
☐ Automatiske tests består.
☐ Kritiske brugerflows er manuelt testet.
☐ Den færdige installer, APK eller pakke er testet.
☐ Kendte kritiske bugs er lukket.
☐ Dependencies er kontrolleret.
☐ Licenser er kontrolleret.
☐ Secrets er kontrolleret.
☐ Sikkerhed er gennemgået.
☐ Privacy er gennemgået.
☐ AI-funktioner er gennemgået.
☐ Etiske risici er vurderet.
☐ Dokumentationen svarer til den faktiske version.
☐ Changelog er opdateret.
☐ Backup eller rollback er mulig.
☐ Udvikleren har eksplicit godkendt releasen.
Vibe coding er ikke nødvendigvis modsætningen til professionel softwareudvikling. Det kan være begyndelsen på den.
AI gør det muligt for en enkelt freelancer at eksperimentere hurtigere og udvikle software, som tidligere ville have krævet langt større ressourcer. Men netop fordi produktiviteten bliver så meget større, bliver det nødvendigt at etablere kontrolpunkter.
Idé → vibe coding → prototype → krav → struktureret udvikling → test → compliance-kontrol → release → vedligeholdelse
Man behøver ikke dokumentere hvert prompt eller hvert forsøg. Men når en eksperimentel prototype begynder at blive til et produkt, bør krav, arkitektur, sikkerhed, privacy, dependencies og tests gradvist formaliseres.
AI kan hjælpe med næsten alle disse opgaver. Den kan skrive testcases, lede efter sikkerhedsproblemer, vedligeholde dokumentation, analysere dependencies, kontrollere en release mod en checkliste og sammenligne implementeringen med kravspecifikationen.
Men der er én opgave, som ikke bør delegeres: Beslutningen om, at produktet er forsvarligt at udgive.
For en freelancer er målet derfor ikke enterprise-compliance i miniature. Målet er en dokumenteret, proportionel og reproducerbar proces, der gør det muligt at vise, at produktet ikke bare blev genereret, men blev forstået, kontrolleret, testet og godkendt.