Kan vi använda Claude Code med kundkod och kunddata?

Claude Code kan läsa en kodbas, analysera filer, föreslå och genomföra ändringar, köra kommandon och arbeta tillsammans med andra utvecklingsverktyg. Det gör verktyget betydligt mer användbart än en fristående chatbot. Det gör också frågan om kunddata mer intressant. För ett SaaS-bolag eller en teknikleverantör är svaret sällan så enkelt som att “Claude tränar inte på vår kod” eller att “vi har ett enterprise-avtal”.

Den relevanta frågan är i stället: Vilken information kan Claude Code komma åt, vilken information lämnar vår miljö och är den användningen förenlig med våra säkerhetskrav och kundåtaganden? Det är där CTO, arkitekt, Security och ibland Legal behöver mötas. Denna artikel går igenom hur.

1. Börja med dataflödet – inte med AI-policyn

Claude Code körs i utvecklarens miljö. Anthropic anger att källfiler läses lokalt och att de delar som behövs för den aktuella uppgiften skickas till API:t för att generera ett svar.

Det är en viktig utgångspunkt.

Men det betyder också att frågan inte kan reduceras till:

“Laddar Claude upp hela vårt repository?”

För bedömningen spelar det större roll vilken information som faktiskt kan bli relevant kontext för agentens uppgift.

Det kan exempelvis vara:

källkod,
konfigurationsfiler,
dokumentation,
felmeddelanden,
loggar,
testdata,
API-svar,
information från tickets,
databasscheman,
miljövariabler, eller
information från anslutna verktyg och MCP-servrar.

En utvecklare kan alltså arbeta med en koduppgift utan att aktivt skriva någon kundinformation i en prompt – och kundrelaterad information kan ändå bli relevant för uppgiften.

Det är därför arkitekturen och arbetsflödet behöver förstås innan den juridiska bedömningen blir meningsfull.

2. “Kunddata” är bredare än produktionsdatabasen

När företag diskuterar AI och kunddata hamnar fokus ofta på produktionsdata.

Det är för snävt – relevanta frågor är oftare:

Kundinformation kan dyka upp i utvecklingsorganisationen på många andra sätt.
Ett supportärende kan innehålla namn, e-postadresser eller interna kundidentifierare.
En logg kan innehålla API-anrop eller information från en enskild kunds användning.
En utvecklare kan kopiera ett felmeddelande från produktion för att felsöka.
Testdata kan vara pseudonymiserad men fortfarande gå att koppla till en individ.
Dokumentation kan beskriva en kundspecifik integration eller säkerhetslösning.

Det praktiska arbetet bör därför börja med frågan: Var i vår utvecklings- och supportkedja kan kundinformation förekomma?

Inte bara: Har utvecklarna tillgång till produktionsdatabasen?

3. Vilket Claude-konto använder utvecklaren?

Anthropic skiljer mellan sina konsumenttjänster och kommersiella produkter, vilket är centralt. För kommersiella produkter som Claude Team, Enterprise och Anthropic API anger Anthropic att kundens data som utgångspunkt inte används för modellträning, om kunden inte frivilligt deltar i företagets Development Partner Program.

För konsumentplaner som Free, Pro och Max gäller andra villkor. Claude Code som används genom sådana konton omfattas av konsumentvillkoren, där användaren bland annat kan välja om data får användas för modellförbättring. Det innebär att två utvecklare som tekniskt använder samma produktnamn – Claude Code – kan ha en väsentligt olika avtals- och dataskyddsposition.

För en organisation bör därför första kontrollen vara mycket konkret:

Använder utvecklarna organisationens godkända enterprise-/commercial setup eller sina egna konton?

En policy som säger “Claude Code är godkänt” är annars ofullständig.

4. “Data används inte för träning” löser inte hela frågan

Att en AI-leverantör inte använder kundens data för modellträning betyder inte att data inte behandlas. Information behöver fortfarande överföras och behandlas för att tjänsten ska fungera.

Det kan också finnas frågor om:

lagring,
loggning,
supportåtkomst,
incidenthantering,
underleverantörer,
internationella överföringar, och
hur information raderas.

Anthropic anger exempelvis att Enterprise-kunder kan konfigurera egna retentionstider för organisationsdata. Samtidigt finns särskilda modellkategorier där Anthropic kräver minst 30 dagars retention för säkerhetsarbete, även i vissa miljöer som annars använder zero data retention.

Det illustrerar varför den relevanta frågan inte bara är:

Tränar leverantören på vår information?

Utan:

Hur behandlas informationen i den konfiguration och med de modeller som vi faktiskt använder?

För ett SaaS-bolag är detta ofta nästa steg. Anta att ni behandlar personuppgifter för en kund och därmed agerar som personuppgiftsbiträde.

Om kundens personuppgifter därefter behandlas av en AI-leverantör för att tillhandahålla utvecklingstjänsten kan frågan om underbiträde aktualiseras. Det behöver bedömas utifrån den faktiska behandlingen och avtalsrelationen.

För Anthropics kommersiella produkter anger Anthropic att företaget agerar som personuppgiftsbiträde för den information kunden lämnar inom tjänsten. Anthropic uppger också att dess DPA, inklusive standardavtalsklausuler, ingår i företagets Commercial Terms.

Men det är inte slutet på analysen. Om ni själva behandlar personuppgifter som biträde åt en kund behöver ni också kontrollera vad ert eget personuppgiftsbiträdesavtal tillåter.

Det kan exempelvis finnas krav på:

godkännande av underbiträden,
information före ändringar,
var behandling får ske,
säkerhetsåtgärder, eller
specifika begränsningar för kundens data.

Den kommersiella relationen mellan er och AI-leverantören kan därför vara korrekt samtidigt som ert avtal med kunden skapar ytterligare krav.

Det här missas ofta.

“Kunddata” behöver inte vara personuppgifter för att vara känslig.

Källkod, affärsinformation, teknisk dokumentation, kundspecifik konfiguration och säkerhetsinformation kan omfattas av sekretess eller särskilda avtalskrav utan att GDPR över huvud taget är relevant.

Enterprise- och offentligsektorkunder kan exempelvis ha avtalat om:

vilka underleverantörer som får användas,
var information får behandlas,
användning av kundmaterial,
säkerhetskrav,
åtkomstbegränsningar,
informationsklassificering,
incidentrapportering, eller
särskilda krav på utvecklingsmiljön.

För en teknikleverantör bör frågan därför vara:

Vad har vi lovat kunden om deras information?

Inte bara:

Är detta tillåtet enligt GDPR?

Det kan mycket väl vara kundavtalet eller säkerhetsbilagan som sätter den snävaste gränsen.

7. Kundkod och kunddata är inte samma risk

Det är också användbart att skilja på olika typer av information.

Egen produktkod

Ni äger och kontrollerar normalt själva koden, men behöver fortfarande bedöma sekretess, informationssäkerhet och leverantörens villkor.

Kod som kunden äger

Här kan det finnas avtalsbegränsningar för hur koden får behandlas och vilka tredje parter som får få tillgång till den.

Kundspecifik konfiguration

Den kan avslöja affärslogik, infrastruktur eller säkerhetslösningar även om den inte innehåller personuppgifter.

Kunddata

Här kan både sekretess, kundavtal, GDPR och sektorspecifika krav aktualiseras.

Produktionsdata och autentiseringsuppgifter

Här bör tröskeln för exponering normalt vara betydligt högre eftersom konsekvenserna av felaktig åtkomst kan bli större.

Det är därför sällan optimalt att ha en enda regel som säger:

“AI får användas med kod” eller “AI får inte användas med kunddata”.

Organisationen behöver mer användbara kategorier.

8. Den större frågan är vad agenten får göra

Med traditionella generativa AI-verktyg låg mycket av fokus på vilken information som skickades till modellen. Med coding agents räcker inte det perspektivet. Claude Code kan arbeta lokalt med filer och verktyg och utföra handlingar i utvecklingsmiljön. Agentiska lösningar kan dessutom ges tillgång till ytterligare system.

Anthropic beskriver själv säkerhetsfrågan för agentiska system som en fråga om att begränsa agentens möjliga “blast radius” när dess åtkomst och kapacitet ökar. För en arkitekt blir därför några andra frågor minst lika viktiga som datalagringen:

Vilka kataloger får agenten läsa?
Vilka repositories kan den arbeta med?
Får den köra kommandon?
Vilka credentials är tillgängliga i miljön?
Får den göra nätverksanrop?
Vilka MCP-servrar får den ansluta till?
Kan den skapa eller ändra kod utan ytterligare godkännande?
Kan den påverka CI/CD eller produktionsnära system?
Vilka handlingar loggas?

Detta är i grunden klassiska principer om least privilege, separation of duties och spårbarhet, applicerade på en ny typ av aktör i utvecklingsmiljön.

9. Behörighet är inte bara en användarfråga längre

Traditionellt har organisationen bedömt vilka rättigheter en utvecklare behöver. Med AI-agenter behöver samma resonemang appliceras ytterligare en nivå. En utvecklare kan exempelvis ha legitim tillgång till tio interna system. Det innebär inte automatiskt att en AI-agent som utvecklaren kör bör kunna agera mot alla tio.

Det är därför värdefullt att skilja mellan:

vad användaren får göra

och

vad agenten får göra för användarens räkning.

Det blir särskilt viktigt när agenten får mer autonomi eller kan kombinera information från flera system.

10. Vad behöver CTO och arkitekt kunna svara på?

Innan Claude Code används bredare med proprietär kod eller kundrelaterad information bör organisationen åtminstone kunna svara på följande:

1. Vilken Claude-plan och vilket konto använder våra utvecklare?

2. Vilken kod, vilka filer och vilka system kan Claude Code komma åt?

3. Vilken information kan skickas till Anthropic när en uppgift utförs?

4. Kan kunddata eller personuppgifter förekomma i utvecklingsflödet?

5. Vilka retention- och dataanvändningsregler gäller för den valda tjänsten och modellen?

6. Är användningen förenlig med våra kundavtal, DPA:er och säkerhetsåtaganden?

7. Vilka kommandon, verktyg och externa system får agenten använda?

8. Vilka åtgärder kräver mänsklig granskning eller godkännande?

9. Hur loggar och följer vi upp användningen?

10. Vem får besluta om nya modeller, integrationer och undantag?

Om svaren kräver fem olika personer inom Engineering, Security, Procurement och Legal är det inte nödvändigtvis ett problem. Men någon behöver sammanföra dem till ett beslut som utvecklingsteamet faktiskt kan arbeta efter.

Behöver kunddata förbjudas helt?

Inte nödvändigtvis.

Ett generellt förbud kan vara enkelt att formulera men svårt att följa när AI-verktyget blir integrerat i det dagliga utvecklingsarbetet. Det kan också vara mer restriktivt än vad den faktiska risken kräver.

En mer hållbar modell är normalt att definiera:

vilka verktyg som är godkända,
vilka konton och enterprise-konfigurationer som ska användas,
vilka informationskategorier som får behandlas,
vilka system agenten får komma åt,
vilka typer av arbete som kräver ytterligare kontroll, och
vilka användningsfall som inte är tillåtna.

Då går det att skilja mellan exempelvis att generera enhetstester för er egen produktkod och att låta en agent felsöka ett produktionsproblem där kundinformation finns i loggarna. Båda är “Claude Code”. Det betyder inte att de bör ha samma regler.

Från “är Claude Code säkert?” till en bättre fråga

Det finns därför inget särskilt användbart generellt svar på frågan: Är Claude Code säkert med kunddata?

En bättre fråga är: Är vår valda Claude Code-konfiguration, med dessa data, dessa behörigheter och dessa kundåtaganden tillräckligt kontrollerad för det här användningsfallet?

Det är en fråga en CTO eller arkitekt faktiskt kan fatta beslut om. Och när den första modellen väl finns på plats blir det betydligt enklare att bedöma nästa verktyg. För nästa månad kanske frågan inte gäller Claude Code. Den kanske gäller Codex, Copilot, Cursor, en ny MCP-server eller en intern agent.

Målet bör därför inte vara en särskild Claude Code-policy. Målet bör vara en teknisk och organisatorisk beslutsmodell som fungerar även när verktygen förändras.

Läs också: AI-agenter i utvecklingen – 7 frågor CTO och CISO behöver ha kontroll på.

*Om ni använder eller planerar att införa Claude Code, Copilot, Codex eller andra AI-verktyg i utvecklingsmiljön kan ni läsa mer om Sharp Cookie Advisors stöd för AI-verktyg och AI-agenter i utvecklingen.