DeepSeek och datasäkerhet för företag – checklista före användning

När ett företag börjar använda DeepSeek eller någon annan extern AI-tjänst är den första frågan inte bara hur bra modellen svarar. Minst lika viktigt är vilken information som skickas in, vem som får använda tjänsten och hur användningen kontrolleras.
Den här sidan är en praktisk säkerhetsguide för organisationer. Den gör inga antaganden om att en viss leverantör alltid har samma lagring, avtal eller tekniska funktioner. Sådana villkor kan ändras och behöver kontrolleras i den aktuella tjänsten före användning.
Börja med dataklassning
Innan personal får använda en extern AI-tjänst bör företaget bestämma vilka datatyper som får skickas till den.
En enkel modell är:
| Dataklass | Exempel | Extern AI som standard? |
|---|---|---|
| Offentlig | Publicerad webbtext, pressmaterial | Ofta lägre risk |
| Intern | Rutiner, interna sammanfattningar | Kräver policybedömning |
| Konfidentiell | Kunddata, priser, affärsplaner | Bör normalt inte skickas utan godkänt upplägg |
| Särskilt känslig | Lösenord, nycklar, personuppgifter med hög risk, säkerhetsdata | Blockera i vanliga publika AI-flöden |
Poängen är att användaren inte ska behöva göra en juridisk och teknisk helhetsbedömning varje gång en prompt skrivs.
Skicka aldrig hemligheter i en prompt
Följande ska normalt behandlas som förbjudet i en publik eller ej särskilt godkänd AI-tjänst:
- lösenord
- API-nycklar
- privata certifikat
- access tokens
- kunders inloggningsuppgifter
- fullständiga betalningsuppgifter
- säkerhetsfrågor
- interna sårbarhetsdetaljer som inte är avsedda för extern part
- produktionsdatabasdump
En hemlighet som har skickats fel bör hanteras som en möjlig informationsincident. Rotera nyckeln eller lösenordet i stället för att bara radera chatten och anta att problemet är löst.
Personuppgifter kräver ett separat beslut
Att texten kan klistras in tekniskt betyder inte att företaget bör göra det. Innan personuppgifter används behöver organisationen förstå:
- varför uppgifterna behövs
- vilka kategorier av personer och data som berörs
- vilken leverantör som behandlar informationen
- var och hur informationen hanteras
- vilka avtals- och integritetsvillkor som gäller
- hur länge data och loggar kan finnas kvar
- vem som har tillgång
- hur registrerades rättigheter och incidenter hanteras
Anonymisering eller pseudonymisering kan minska risk, men endast om informationen faktiskt inte enkelt kan kopplas tillbaka till en person genom resten av prompten.
Gör en leverantörsgranskning före produktion
AI ska bedömas som andra externa IT-leverantörer. Ett pilotkonto skapar inte automatiskt ett godkänt produktionssystem.
Kontrollera minst:
- användarvillkor
- integritetspolicy
- säkerhetsdokumentation
- datalagring och retention
- om kunddata används för modellförbättring och vilka val som finns
- underleverantörer
- geografisk behandling
- incidentprocess
- export och radering
- organisationskonton och administratörsfunktioner
- autentisering och åtkomstkontroll
Dokumentera vilket datum granskningen gjordes. AI-tjänster förändras snabbt och en bedömning från förra året kan vara inaktuell.
Personligt konto eller företagskonto?
Ett privat konto som medarbetaren skapat själv ger organisationen mindre kontroll.
| Fråga | Personligt konto | Centralt företagsupplägg |
|---|---|---|
| Vem äger kontot? | Medarbetaren | Organisationen |
| Åtkomst vid avslutad anställning | Svårare | Kan hanteras centralt |
| Policy och behörigheter | Begränsade | Lättare att styra |
| Loggning | Ofta splittrad | Kan bli mer samlad |
| Kostnader | Spridda | Centralt hanterade |
| Incidenthantering | Svårare | Tydligare ansvar |
För återkommande företagsanvändning är ett kontrollerat upplägg normalt lättare att förvalta än många privata konton.
Minimera informationen i prompten
Skicka endast den information som krävs för uppgiften.
I stället för:
“Här är hela kunddatabasen. Hitta vilka kunder vi bör kontakta.”
kan arbetsflödet först skapa en intern, reducerad datamängd med endast de fält som behövs och utan direkta identifierare.
Samma princip gäller kod. Om du behöver hjälp med en funktion behöver du sällan skicka hela privata kodbasen, `.env`-filen, deployment-konfigurationen och produktionsloggarna.
Säker kodanvändning
Utvecklare använder AI för kodförslag, felsökning och tester. Då bör policyn tydligt skilja mellan:
- publik/open-source-kod
- egen proprietär kod
- säkerhetskritiska komponenter
- autentisering och betalningar
- produktionsloggar
- hemligheter och konfiguration
AI-genererad kod ska granskas som kod från en extern källa. Kontrollera:
- behörighetskontroller
- inputvalidering
- SQL- och kommandoinjektion
- XSS och CSRF
- felhantering
- loggning av känslig information
- beroenden och licenser
- tester
Kopiera inte kod direkt till produktion bara för att den kompilerar.
Prompt injection och externa dokument
En AI-assistent kan påverkas av instruktioner som ligger inbäddade i dokument, webbsidor eller data som modellen ombeds analysera. Detta blir särskilt viktigt när en agent har åtkomst till verktyg eller företagsdata.
Separera därför:
- användarens instruktion
- extern information som ska analyseras
- systemets behörigheter
- åtgärder som får köras automatiskt
En text i ett dokument ska inte kunna ge modellen högre behörighet, skicka data till en ny mottagare eller utföra en betalning.
Begränsa vad AI får göra automatiskt
Ju större verktygsåtkomst en AI har, desto större blir konsekvensen av fel.
Använd exempelvis olika nivåer:
| Nivå | Tillåten användning |
|---|---|
| 1 | Svara och sammanfatta utan systemåtkomst |
| 2 | Läsa godkända dokument |
| 3 | Skapa utkast i interna system |
| 4 | Föreslå förändringar som människa godkänner |
| 5 | Utföra begränsade automatiska åtgärder med loggning |
Kritiska åtgärder som betalningar, radering, behörighetsändringar och publicering bör ha extra kontroll och tydlig revisionslogg.
Human-in-the-loop för viktiga beslut
AI-resultat kan vara felaktiga även när svaret låter säkert. Därför bör mänsklig kontroll krävas för exempelvis:
- juridiska beslut
- personalärenden
- kreditbeslut
- säkerhetsincidenter
- offentlig kommunikation med stor konsekvens
- medicinska eller andra högriskbeslut
- ändringar i produktionssystem
Använd AI som beslutsstöd, inte som ensam ansvarig aktör där fel kan få stora konsekvenser.
Loggning utan att skapa ett nytt integritetsproblem
Företaget behöver kunna följa upp missbruk och incidenter, men en fullständig logg över varje prompt kan i sig bli ett känsligt register.
Bestäm därför:
- vad som loggas
- varför det loggas
- vem som får läsa loggarna
- hur länge de sparas
- om känsliga fält maskeras
- hur loggar raderas
Säkerhetsloggning ska hjälpa, inte skapa en andra kopia av all konfidentiell information.
En enkel godkännandeprocess
En organisation kan använda följande flöde innan en AI-tjänst öppnas för bred användning:
- Ägare för användningsfallet utses.
- Dataklasser identifieras.
- Juridik/integritet granskar relevanta villkor.
- IT-säkerhet granskar åtkomst, lagring och incidentprocess.
- Tillåtna och förbjudna användningar dokumenteras.
- Pilot körs med icke-känslig data.
- Resultat och risker utvärderas.
- Företagskonto och behörigheter konfigureras.
- Personal får kort utbildning.
- Ny granskning sker vid större ändring av tjänsten.
Policytext som medarbetare faktiskt kan följa
En AI-policy behöver inte börja med 30 sidor juridik. Den första sidan bör svara på:
- Vilka AI-verktyg är godkända?
- Vilken data får användas?
- Vilken data är förbjuden?
- När krävs mänsklig granskning?
- Vem kontaktas vid fel?
- Hur rapporteras en felaktigt delad hemlighet?
Mer detaljerad juridisk och teknisk dokumentation kan finnas bakom policyn.
Checklista före DeepSeek eller annan extern AI
- [ ] Har tjänsten en namngiven intern ägare?
- [ ] Är dataklasser definierade?
- [ ] Är personuppgiftsbehandling bedömd?
- [ ] Är säkerhets- och integritetsvillkor granskade i aktuell version?
- [ ] Är privata konton blockerade eller reglerade där det behövs?
- [ ] Är hemligheter uttryckligen förbjudna i prompts?
- [ ] Finns process för incident och nyckelrotation?
- [ ] Kräver viktiga beslut mänsklig kontroll?
- [ ] Finns loggning och rimlig retention?
- [ ] Är en omgranskning planerad när tjänsten ändras?
Huvudguiden om DeepSeek
Vår generella DeepSeek-artikel finns på DeepSeek: AI och datasäkerhet. Den här sidan fokuserar specifikt på företagsstyrning och säker användning och undviker därmed att konkurrera om samma sökintention.
Vanliga frågor
Kan företag använda DeepSeek med konfidentiell data?
Det bör inte göras utan ett uttryckligen godkänt upplägg där leverantör, avtal, databehandling och säkerhetskrav har granskats. Standardregeln bör vara att konfidentiell data inte skickas till ej godkända externa AI-tjänster.
Räcker det att radera chatten efteråt?
Nej. Om en hemlighet eller känslig uppgift har skickats fel behöver organisationen bedöma incidenten och exempelvis rotera nycklar där det är relevant.
Är AI-genererad kod säker?
Inte automatiskt. Den måste granskas, testas och säkerhetsbedömas på samma sätt som annan extern kod.
Vad är den viktigaste första åtgärden?
Bestäm vilka data som får och inte får skickas till verktyget och gör regeln enkel för medarbetare att följa.
Måste villkoren kontrolleras igen?
Ja. Leverantörers modeller, funktioner och datahantering kan ändras. Dokumentera kontrolltid och gör ny bedömning vid större förändringar.

Kommentarer
Diskutera artikeln i tråden nedan.