KÄLLKOD OCH IP
Exempel för ingenjörer
När en ingenjör förklarar en teknisk avvikelse för kollegor utanför specialistgruppen är huvudfrågan inte om AI kan skriva texten, utan vilka uppgifter, beslut och ansvar som får hanteras. Dokumentera dataklass, vem som granskar och vilket underlag som måste verifieras.
Källkod är ofta organisationens viktigaste immateriella tillgång
Att skicka källkod till ett externt AI-system innebär att koden lämnar din organisations kontrollerade miljö. Beroende på vilket AI-verktyg du använder och vilket avtal din organisation har, kan den koden potentiellt lagras, analyseras eller i värsta fall bli en del av träningsdata.
Det är en avvägning som måste göras medvetet — inte av slentrian.
Kod och data som aldrig matas in i icke-godkända system
- Affärskritisk proprietär kod. Algoritmer, affärslogik och kärnkomponenter som utgör er konkurrensfördel.
- Säkerhetskritisk kod. Autentisering, krypteringsimplementationer, säkerhetspolicyer och behörighetslogik.
- API-nycklar och hemligheter. Aldrig i klartext i en prompt. Ersätt med platshållare som `API_KEY_HERE` innan du klistrar in kod.
- Personuppgifter i koden. Testdata, loggfiler eller databasscheman som innehåller verkliga personuppgifter.
- Kod under NDA. Om du arbetar med en kunds kodbas under sekretessavtal täcker det sekretessen även när du ber om AI-hjälp.
AI-genererad kod och immateriella rättigheter
AI-genererad kod skapar juridiska frågor som inte är fullt ut avgjorda. Några saker att vara medveten om:
- Äganderätt. Leverantörsvillkor kan fördela avtalsrättigheter till output, men ett sådant villkor skapar inte automatiskt upphovsrätt. Kontrollera både avtalet och vilka rättigheter som faktiskt kan finnas enligt tillämplig lag.
- Licensrisker. Output kan i vissa fall ligga nära skyddad källkod. Om en identifierbar matchning används kan upphovsrätt och licensvillkor aktualiseras. Granska ursprung och likhet, använd matchningsfilter där de finns och utred licensen innan matchande kod tas in.
- Upphovsrätt till AI-output. I Sverige kräver upphovsrätt en mänsklig skapare och fria kreativa val. Helt maskinframställd output får därför inte automatiskt skydd, medan AI-assisterad kod kan innehålla mänskliga bidrag som måste bedömas i det enskilda fallet. Andra länder kan göra andra bedömningar.
Bedöm miljön och avtalet — inte varumärket
- Avtal och återanvändning: kontrollera vem som behandlar indata och output, om material får användas för modellträning eller produktförbättring och vilka undantag som gäller för exempelvis feedback.
- Lagring och åtkomst: dokumentera lagringstid, region, underleverantörer, administratörers åtkomst, anslutna tjänster och möjligheten att radera eller exportera data.
- Lokal eller egenhostad körning: verifiera med nätverks- och lagringsprov att promptar, loggar, telemetri, modeller och tillägg faktiskt stannar inom den beslutade gränsen. Ordet ”lokal” är inte i sig ett bevis.
- Godkännandet gäller användningsfallet: en företagsplan eller teknisk kontroll gör inte all kod tillåten. Dataklass, sekretess, kundavtal, behörighet och ändamål måste fortfarande stämma.
En snabb kontroll innan AI-kod går vidare
- Kontrollera licensrisken: särskilt om lösningen liknar kod du själv inte skulle ha skrivit på det sättet.
- Kontrollera säkerheten: validering, autentisering, felhantering och loggning måste granskas manuellt.
- Kontrollera versionspassning: AI föreslår ofta syntax eller API-anrop som inte matchar din faktiska stack.
- Kontrollera datakällan: ingen hemlig testdata, riktiga nycklar eller känsliga loggar ska finnas kvar.
- Kontrollera ägarskapet: om det råder tvekan om avtal, NDA eller kundkod ska frågan lyftas innan något checkas in.
NIS2, CER och säkerhetskritiska system
NIS2-direktivet (EU 2022/2555) genomförs delvis i Sverige genom cybersäkerhetslagen (2025:1506), som trädde i kraft den 15 januari 2026. Reglerna gäller verksamhetsutövare i bland annat energi, transport, hälsa, vattenförsörjning, digital infrastruktur och flera andra sektorer. CER-direktivet (EU 2022/2557) ligger nära samma verklighet men fokuserar på kritiska entiteters motståndskraft, inte bara cybersäkerhet. Om du arbetar med system i dessa sektorer är följande relevant. Lagen omfattar inte automatiskt varje organisation i en uppräknad sektor; kontrollera verksamhetstyp, etablering, storlek och undantag:
- Riskhantering för AI-verktyg. En verksamhetsutövare som omfattas måste ha processer för riskhantering. Att introducera AI-genererad kod i kritiska system utan tillräcklig granskning kan strida mot dessa krav. Ett externt AI-verktyg eller ett modell-API kan vara ett beroende eller en leverantör i den egna riskbilden. Lagen kräver bland annat säkerhet i leveranskedjan och säkerhet vid utveckling och underhåll — den säger inte att varje AI-verktyg automatiskt har en viss juridisk leverantörsroll.
- Incidentrapportering. Säkerhetshändelser kopplade till AI-verktyg — t.ex. en prompt injection som lett till dataintrång — kan vara en betydande incident enligt lagen och då rapporteras till CSIRT-enheten vid Nationellt cybersäkerhetscenter. Först lämnas en upplysning senast inom 24 timmar. Därefter lämnar de flesta verksamhetsutövare en incidentanmälan senast inom 72 timmar; för betrodda tjänster gäller 24 timmar. Slutrapport lämnas normalt senast en månad efter incidentanmälan. Använd den aktuella rapporteringstjänsten.
- CER och beroenden utanför koden. För en organisation som har identifierats som kritisk entitet kan ett AI-stött ändringsförslag påverka mer än mjukvaran: driftkontinuitet, fysisk säkerhet, leverantörer, reservrutiner och återställningsförmåga. Kontrollera därför AI-förslag mot både cybersäkerhetskrav och organisationens kontinuitets- och resiliensarbete.
- Proprietär kod och IP-äganderätt. Leverantörens villkor och den lagstadgade upphovsrätten är två olika frågor. Dokumentera människans kreativa bidrag, kontrollera om output matchar skyddat material och granska anställningsavtal, kundavtal och leverantörsvillkor innan rättigheter påstås eller kod återanvänds.
Primärkällor för regler som påverkar AI för ingenjörer och utvecklare
- EUR-Lex — AI-förordningen (EU) 2024/1689 (öppnas i ny flik)
- Sveriges riksdag — cybersäkerhetslag (2025:1506) (öppnas i ny flik)
- Sveriges riksdag — cybersäkerhetsförordning (2025:1507), CSIRT-enhet och mottagare (öppnas i ny flik)
- CERT-SE och Nationellt cybersäkerhetscenter — mottagare av incidentrapporter enligt cybersäkerhetslagen (öppnas i ny flik)
- Integritetsskyddsmyndigheten (IMY) — inbyggt dataskydd och dataskydd som standard (öppnas i ny flik)
- Patent- och registreringsverket (PRV) — mänskliga kreativa val och AI-output (öppnas i ny flik)
- EUR-Lex — NIS2-direktivet (EU) 2022/2555 (öppnas i ny flik)
- EUR-Lex — CER-direktivet (EU) 2022/2557 (öppnas i ny flik)
Källorna kontrollerades den 10 september 2026. Granska sidan igen senast den 10 oktober 2026, eller direkt om cybersäkerhetslagen, cybersäkerhetsförordningen, rapporteringsrutinen eller en godkänd AI-tjänsts datavillkor ändras.
Etik och juridik
Får jag klistra in proprietär kod i AI-verktyg?
Bara i en miljö som organisationen har godkänt för den aktuella dataklassen och där avtal, lagring, åtkomst, underleverantörer och eventuell återanvändning är kontrollerade. Ett privat konsumentkonto är inte ett sådant godkännande. Lägg aldrig in hemligheter eller autentiseringsuppgifter.
Hur ansvarar jag för säkerhetshål som AI har genererat?
Teamet och organisationen ansvarar för vad som byggs och tas i drift. AI-genererad kod ska därför gå igenom samma hotmodellering, testning, beroendekontroll och sakkunniga granskning som annan kod med motsvarande risk.
Vad gäller för AI och öppen källkod?
Output kan i vissa fall likna skyddad kod. Granska ursprung och likhet, använd leverantörens matchningsfilter där sådana finns och utred licensvillkoren innan kod som matchar en identifierbar källa används.
Redaktionellt ansvar
Innehållet är redaktionellt framtaget av AI på svenska som praktiskt stöd. Det ska användas tillsammans med professionellt omdöme, lokal policy och aktuell lagstiftning.
Nästa: Verktyg
Välj rätt AI-miljö för uppgiften och risknivån.