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.

1. Vilken kod och information kan AI-verktyget faktiskt komma åt?

Det första steget är inte juridiskt. Det är tekniskt.

• Vilka repositories kan verktyget läsa?
• Kan det se konfigurationsfiler, API-nycklar, loggar, testdata eller dokumentation?
• Kan agenten bara föreslå kod eller kan den också ändra filer, köra terminalkommandon, skapa pull requests eller anropa externa verktyg?

Skillnaden mellan en AI-assistent som genererar ett kodförslag och en agent med tillgång till repository, terminal och interna system är betydande. Organisationen bör därför kartlägga den faktiska åtkomsten, inte bara vilket AI-verktyg som används.

Det är också här traditionell behörighetsstyrning blir central. En AI-agent bör inte få större faktisk åtkomst än den användare eller funktion som har behov av den.

2. Vad lämnar vår miljö?

Nästa fråga är vad som faktiskt skickas till AI-leverantören. Det kan vara mer än den prompt utvecklaren själv skriver. Beroende på verktyg och konfiguration kan det exempelvis handla om:

• kod och kodfragment,
• filer som läses in som kontext,
• loggar och felmeddelanden,
• metadata,
• telemetri,
• information från anslutna verktyg,
• feedback som lämnas till leverantören.

Det är därför sällan tillräckligt att konstatera att leverantören erbjuder en enterprise-version eller att kommunikationen är krypterad.

Den relevanta frågan är: Vilka dataflöden uppstår i just vår konfiguration och vad får leverantören göra med informationen?

Det kräver normalt både en teknisk och avtalsmässig kontroll. För organisationer som vill gå från enskild användning till en kontrollerad utrullning erbjuder Sharp Cookie Advisors stöd för AI-verktyg och AI-agenter i utvecklingen.

3. Vad händer när AI-agenten får tillgång till andra system?

Det här blir särskilt viktigt när AI-agenter kopplas till fler verktyg. MCP och liknande integrationsmodeller gör det möjligt för en agent att kommunicera med exempelvis utvecklingsverktyg, databaser, dokumentationssystem och andra interna eller externa tjänster. Det skapar stora möjligheter. Men det förändrar också riskbilden.

En agent som kan läsa dokumentation är en sak. En agent som också kan ändra kod, anropa ett produktionsnära system eller agera med användarens behörighet är något annat.

Organisationen behöver därför ta ställning till bland annat:

• vilka verktyg en agent får ansluta till,
• vilka rättigheter den får,
• hur autentisering och auktorisation fungerar,
• vilka åtgärder som kräver mänskligt godkännande,
• vad som loggas,
• hur felaktiga eller manipulerade instruktioner hanteras.

Att ett verktyg tekniskt kan anslutas innebär inte att det bör anslutas utan ytterligare kontroll.

4. Kan kunddata eller personuppgifter hamna i verktyget?

För SaaS- och teknikleverantörer är detta ofta en av de viktigaste frågorna. Utvecklingsmiljöer är sällan helt isolerade från verksamhetsdata. Felsökning, support, loggar, testmiljöer och produktionsincidenter innebär att kundrelaterad information kan förekomma även där organisationen egentligen arbetar med kod.

Om personuppgifter eller annan kundinformation skickas till en extern AI-leverantör kan det få konsekvenser för bland annat:

• personuppgiftsbiträdesavtal,
• underbiträden,
• tredjelandsöverföringar,
• informationsklassning,
• kundspecifika säkerhetskrav,
• sekretessåtaganden.

Att informationen är maskerad eller pseudonymiserad innebär inte automatiskt att den faller utanför dataskyddsregleringen. Det viktiga är därför inte bara vad organisationens policy säger att utvecklare får göra, utan vad som faktiskt kan förekomma i utvecklingsflödet.

5. Vad har vi redan lovat våra kunder?

Detta är den fråga som ofta förbises. Organisationen kan ha en tekniskt rimlig AI-lösning och ändå skapa problem genom sina befintliga kundåtaganden.

Enterprise- och offentligsektorkunder ställer ofta krav på exempelvis:

• var data får behandlas,
• vilka underleverantörer som får användas,
• hur kod och kunddata får användas,
• säkerhetsåtgärder,
• incidenthantering,
• förändringar i leverantörskedjan,
• åtkomst till kundinformation.

Om en utvecklingsorganisation börjar använda en extern AI-tjänst kan dessa åtaganden därför bli relevanta även om AI-verktyget aldrig är synligt för slutkunden. Det är särskilt viktigt för leverantörer som behandlar kunddata eller arbetar i reglerade miljöer.

Frågan bör därför inte bara vara: Tillåter våra interna regler det här?

utan också: Är detta förenligt med vad vi redan har lovat våra kunder?

6. Vilka regulatoriska krav påverkar användningen?

Det finns sällan ett enda regelverk som ger hela svaret. Beroende på organisation, sektor och användning kan bland annat GDPR, NIS2/cybersäkerhetsreglering, AI-förordningen och organisationens befintliga informationssäkerhetsstyrning bli relevanta. För organisationer som arbetar enligt ISO 27001 kan mycket av grundstrukturen redan finnas. Det handlar då inte nödvändigtvis om att skapa ett separat kontrollsystem för varje AI-verktyg.

En bättre utgångspunkt är ofta att integrera AI-användningen i befintliga processer för exempelvis:

• riskbedömning,
• leverantörsbedömning,
• access management,
• informationsklassning,
• incidenthantering,
• change management,
• utvecklingssäkerhet.

ISO/IEC 42001 kan på motsvarande sätt ge struktur för organisationer som vill bygga en mer formaliserad styrmodell för AI.

Men standarder och regelverk bör inte bli ett självändamål. För CTO och CISO är den centrala frågan fortfarande vilken kontrollnivå verksamheten faktiskt behöver.

7. Vilka guardrails behöver finnas innan vi skalar?

Det sista steget är att översätta analysen till praktiska spelregler. Det behöver inte börja med ett omfattande AI governance-program. För många organisationer är ett mindre antal tydliga beslut mer värdefulla.

Exempelvis:

Godkända verktyg och planer
Vilka AI-tjänster får användas och under vilka enterprise-inställningar?

Godkända användningsfall
Vilka typer av utvecklingsarbete kan genomföras med AI och vilka kräver ytterligare kontroll?

Dataregler
Vilken information får respektive får inte skickas till AI-tjänsten?

Behörigheter
Vilka repositories, system och verktyg får AI-agenten komma åt?

Mänsklig kontroll
Vilka typer av förändringar måste granskas innan de genomförs eller går vidare till produktion?

Leverantörskontroll
Hur bedöms AI-leverantören, dess avtalsvillkor och eventuella underleverantörer?

Loggning och spårbarhet
Kan organisationen i efterhand förstå vad agenten haft tillgång till och vad den gjort?Det är ofta här skillnaden ligger mellan en generell AI-policy och faktisk styrning.

Målet är inte att bromsa Engineering

Fel angreppssätt är att försöka hantera varje nytt AI-verktyg som ett separat juridiskt projekt. Utvecklingsverktygen förändras för snabbt för det.

En bättre modell är att skapa en beslutsram som gör det möjligt att bedöma nya verktyg och användningsfall på ett konsekvent sätt. Det ger Engineering större handlingsutrymme samtidigt som Security, Legal och ledningen vet vilka gränser som gäller.

Den relevanta frågan blir då inte: ”Får vi använda AI?”

utan: ”Vilka användningar kan vi tillåta, under vilka förutsättningar och med vilka kontroller?”

Det är en betydligt mer praktisk utgångspunkt för organisationer som vill använda AI på riktigt.

En praktisk första kontroll

Om ni redan använder eller planerar att införa Claude Code, GitHub Copilot, Codex, Cursor eller andra AI-agenter i utvecklingsmiljön bör ni åtminstone kunna svara på följande:

• Vilka AI-verktyg används faktiskt i organisationen?
• Vilka repositories och system kan de komma åt?
• Vilken kod och information skickas till leverantören?
• Kan kunddata eller personuppgifter förekomma?
• Vilka rättigheter har agenten att agera i miljön?
• Vilka enterprise-inställningar är aktiverade?
• Vad säger leverantörens avtal om data och användning?
• Är användningen förenlig med våra kundavtal?
• Hur passar användningen in i vår befintliga säkerhetsstyrning?
• Vem i organisationen äger beslutet?

Om svaren finns utspridda mellan Engineering, Security, Legal och Procurement är det inte ovanligt.

Det är ofta just där arbetet behöver börja.

Sharp Cookie Advisors hjälper teknik- och SaaS-bolag att bedöma och införa AI-verktyg i utvecklingsmiljöer med fokus på teknik, säkerhet, kundåtaganden och regulatoriska krav. Arbetet kan genomföras som en avgränsad AI Engineering Readiness Review eller som stöd vid införande och löpande styrning.