Claude Code med kunddata – vad behöver ni kontrollera?

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.

Read more

AI-agenter i utvecklingen: 7 frågor CTO och CISO bör ha kontroll på kring kod, data, säkerhet, GDPR och NIS2.

Claude Code, GitHub Copilot, Codex, Cursor och andra AI-baserade utvecklingsverktyg håller snabbt på att bli en del av den vanliga utvecklingsmiljön. För många organisationer är frågan därför inte längre om utvecklare ska få använda AI. Frågan är hur användningen kan ske med tillräcklig kontroll över kod, data, behörigheter, leverantörer och kundåtaganden. Det är en annan typ av fråga än den klassiska diskussionen om en AI-policy.

När AI-verktyget kan läsa ett repository, ändra kod, köra kommandon, interagera med andra system eller få tillgång till verktyg via exempelvis MCP blir det en del av organisationens tekniska miljö. Då behöver styrningen också flytta närmare arkitektur, säkerhet och utvecklingsprocess.

För CTO, CISO och ansvariga för Engineering finns åtminstone sju frågor som bör kunna besvaras. Vi går igenom dessa i denna artikel.

Read more

NIS2 och GDPR – effektiv incidenthantering för säkerhetsincidenter och personuppgiftsincidenter

När kraven på cybersäkerhetsrapportering ökar behöver svenska IT-leverantörer samtidigt bli bättre på att skilja mellan sårbarheter, säkerhetsincidenter och personuppgiftsincidenter. Annars riskerar ökad transparens att leda till onödiga krisorganisationer hos både leverantör och kund.

För CIO, CISO och DPO är detta en central insikt: NIS2 kräver mer och tidigare informationsdelning – men inte att varje säkerhetshändelse hanteras som en personuppgiftsincident. Rätt klassificering och tydliga eskaleringsspår gör incidenthanteringen mer träffsäker, minskar onödig akuthantering och stärker både kundförtroende och operativ skalbarhet. Lästid: cirka 5 minuter.

Read more

Reflektioner DPO

IT-bolag inom hälsa befinner sig ofta i ett av de mest krävande gränslanden som finns: mellan snabb produktutveckling, vårdens höga förtroendekrav, kommersiell skalning och ett regelverk som inte tillåter genvägar. Som extern dataskyddsombudsfunktion för bolag i den miljön ser vi återkommande samma mönster. De bolag som lyckas bäst är sällan de som försöker göra allt på en gång. Det är de som prioriterar hårt, bygger dataskyddskapacitet steg för steg och kopplar compliancearbetet till produkt, försäljning, drift och ledning.

För ledningsgrupper i e-hälsa, healthtech, vård-SaaS och digitala omsorgstjänster är detta en central insikt: dataskydd är inte bara en juridisk kontrollpunkt. Rätt hanterat blir det en del av bolagets operativa kvalitet, kundförtroende och skalbarhet. Lästid: cirka 7 minuter.

Read more

esc

Svensk avtalsrätt bygger på principen om pacta sunt servanda, dvs. att avtal ska hållas. Det innebär även att ett avtal står fast även då omständigheter förändras. För många techbolag, SaaS-leverantörer, konsultbolag och tillväxtföretag är det just här problemet uppstår. Ett avtal som såg rimligt ut när det skrevs kan bli kommersiellt obalanserat när förutsättningarna ändras: nya regulatoriska krav, kraftigt höjda underleverantörskostnader, valutaförändringar, exportrestriktioner, energipriser, säkerhetskrav eller plötsliga förändringar i kundens behov.

En hardshipklausul är ett sätt att hantera risken innan den blir en konflikt.  Lästid: 4 min.

Read more

riskfördelning i SaaS avtal

SaaS-avtal handlar inte bara om pris, funktioner och servicenivåer. Ett av de mest affärskritiska områdena är riskfördelning: vem ansvarar för vad om något går fel?

För svenska och nordiska SaaS- och IT-bolag blir detta ofta tydligt när bolaget börjar sälja till större kunder. Kunden vill ha trygghet. Inköp vill pressa risk. Legal vill ha breda garantier. IT och security vill ha tydliga åtaganden. Privacy och compliance vill ha kontroll på data, underbiträden, incidenter och revision.

Leverantören behöver samtidigt skydda sin affärsmodell. Om varje kundavtal innehåller höga, obegränsade eller kundspecifika ansvarsåtaganden blir SaaS-modellen svår att skala. En välbalanserad ansvarsbegränsning är därför inte ett juridiskt sidospår. Den är en central del av bolagets kommersiella riskstyrning.

Lästid: cirka 6 minuter.

Read more

Närbild på tangentbordstangent med utropstecken och siffran 1.

En uppförandekod är ett centralt styrdokument för hur ett bolag ska agera ansvarsfullt i affärer, organisation och leverantörsled. För leverantörer blir den särskilt viktig när kundens uppförandekod görs till en del av avtalet för en IT-tjänst, SaaS-lösning eller konsultleverans. Rätt hanterad kan den vara ett rimligt compliance-krav. Fel hanterad kan den skapa otydligt scope, utökade garantier, felansvar och avtalsbrottsrisk.

Det blir allt vanligare att både större och mindre bolag tar fram egna uppförandekoder. Drivkrafterna är tydliga: kundkrav, investerarkrav, hållbarhetsrapportering, regulatorisk utveckling, krav från offentliga upphandlingar och ökad granskning av leverantörskedjor.

Men en uppförandekod väcker också juridiska frågor. Är den bindande? Kan den användas mot leverantörer? Vad gäller internt mot anställda? Och när kan högt ställda hållbarhetslöften bli en marknadsrättslig risk?

Lästid: 5 minuter.

Read more