BykiAtt låta en AI skriva koden till en app eller ett internt verktyg har fått ett eget namn: vibe coding. Du beskriver vad du vill ha, AI:n bygger, och du provar tills det känns rätt. Det går snabbt, och för en prototyp kan det räcka.
Men en app som ska användas av riktiga människor, med riktiga inloggningar och riktiga uppgifter, behöver mer än att den känns rätt. Säkerhet är det man inte ser när man provar. Får AI:n inga krav, gissar den. Ibland gissar den bra, ibland inte.
Ett förslag som sprids är att skriva fem korta dokument innan AI:n får börja. Tanken är att man inte ska vibe-koda utan dem. Att just dessa fem är rätt uppsättning är en åsikt, inte en etablerad standard. Men uppdelningen är tydlig och lätt att börja med.
1. Grundreglerna
Det första dokumentet är reglerna AI:n alltid ska följa. Två saker hör hit från början:
- Allt som användaren skriver in ska behandlas som opålitligt. Det ska kontrolleras innan det sparas eller används, annars kan någon smyga in kod eller kommandon via ett vanligt formulär.
- Lösenord och API-nycklar hör inte hemma i koden. De ska ligga separat, så att de inte följer med när koden delas, laddas upp eller visas för någon annan.
2. Inloggning och behörighet
Nästa dokument beskriver hur användare loggar in, hur länge de förblir inloggade och vad var och en får komma åt.
Det sista är det viktigaste. Att någon är inloggad betyder inte att den får se allt. En kund ska se sina egna fakturor, inte grannens. Den kontrollen måste göras på servern, inte bara i det som visas på skärmen, för det som visas på skärmen går att kringgå.
3. Känsliga uppgifter
Det tredje dokumentet handlar om vilka känsliga uppgifter appen samlar in, hur de skyddas och när de ska raderas.
För ett svenskt företag är det här inte bara god sed, det är GDPR. Du ska kunna svara på vad du sparar, varför, och hur länge. Skriv ner det innan appen byggs, så att AI:n inte samlar in mer än det som behövs.
4. Hotbilden
Det fjärde dokumentet kallas ofta hotmodell. Det beskriver var någon skulle kunna ta sig in och vad som kan gå fel. Inloggningen, formulären, filuppladdningen, kopplingar till andra tjänster.
Syftet är att planera skydden innan problemen når riktiga användare. Du behöver inte vara säkerhetsexpert för att börja. Fråga dig själv: om jag ville missbruka den här appen, var skulle jag börja?
5. Checklistan
Det femte dokumentet gör om kraven ovan till kontroller som körs innan appen lanseras. Är nycklarna borta ur koden? Kan en användare se en annan användares uppgifter? Raderas det som ska raderas?
Det här är enligt oss det viktigaste av de fem. De andra fyra talar om för AI:n vad den ska göra. Checklistan är det enda som visar om den faktiskt gjorde det.
Ett dokument är ingen garanti
Att en AI pålitligt följer säkerhetsregler i en textfil är inte bevisat, och det är inget vi skulle lita på utan kontroll. AI:n kan missa en regel, tolka den fel eller glömma den halvvägs genom ett stort bygge. Dokumenten minskar risken, men de ersätter inte att någon granskar och testar.
Vi arbetar själva efter samma grundtanke: kraven skrivs ner först, och inget släpps innan en säkerhetskontroll är gjord och godkänd. Det är det sista steget som gör de andra värda något.
Börja här
- Skriv en halv sida med grundregler: opålitlig indata, inga nycklar i koden.
- Beskriv vem som får se vad.
- Lista de känsliga uppgifterna och hur länge de sparas.
- Fråga dig var du själv skulle angripa appen.
- Gör en checklista, och kör den innan någon utanför företaget får tillgång.
Bygger du något med AI och vill ha en andra blick på säkerheten kan du boka ett kostnadsfritt samtal på 30 minuter med oss.