Tröskeln för att bygga en app har raserats – men tröskeln för att röra användardata har inte det

Cheferna för plattformsavdelningarna inom e-handeln har på sistone ställt mig samma fråga: affärssidan kan på en vecka bygga tre interna verktyg med AI på egen hand, medan IT:s utvecklingskö fortfarande sträcker sig in på nästa kvartal. Var ligger egentligen flaskhalsen?

Vårt svar kan sammanfattas i en enda bedömning: Tröskeln för utveckling har raserats – men tröskeln för att röra användardata har inte det.

Bakom detta ligger två saker som sker samtidigt.

Bolt.new är byggt av StackBlitz och lanserades tyst via ett inlägg på X i oktober 2024. På fem månader nådde verktyget 40 miljoner USD i årlig återkommande intäkt (ARR). Sacra och Growth Unhinged följer det som den näst snabbast växande produkten i historien – bara ChatGPT har gått snabbare. När räkenskapsåret 2026 avslutades berättade StackBlitz vd Eric Simons på LinkedIn att Bolt.new nu används av tre fjärdedelar av Fortune 500-företagen, och att den företagsinriktade ARR:en vuxit tiofalt jämfört med föregående år (Eric Simons officiella inlägg, räkenskapsåret 2026). Lovable kommer från ett team i Stockholm, grundat av Anton Osika. I november 2025 tog bolaget in 200 miljoner USD i en A-runda till en värdering på 1,8 miljarder USD. I slutet av december 2025 värderades bolaget till 6,6 miljarder USD i en B-runda – en nästan fyrdubbling på ett halvår (bekräftat av Forbes, CNBC, Bloomberg och TechCrunch). I juni 2026 passerade Lovable 500 miljoner USD i ARR (Forbes, med TechCrunch som publicerade samma dag den 9 juni 2026). Samma dag uppgav Forbes, med hänvisning till fyra källor med insyn, att bolaget var i färd med att ta in en ny finansieringsrunda till en värdering på 12 miljarder USD – ungefär en fördubbling. Den här typen av verktyg har kollapsat tiden det tar att bygga en app från flera månader och ett helt team, till en eftermiddag och en enda person.

Men samtidigt som utvecklingströskeln rasar samman, har de steg i processen som verkligen kostar tid och skapar flaskhalsar inte rört sig en millimeter: dataexportbedömningar, 等保测评 (security classification assessment, motsvarande en lokal säkerhetsgranskning), algoritmregistrering, Change Advisory Board (CAB) och avstämningsrevision. Dessa steg har nästan ingenting med själva koden att göra, men var och en kan äta upp flera veckor. App-generatorer har sparkat upp den första dörren – verksamheten kan nu bygga egna appar. Men den andra dörren – vem som har rätt att röra produktionsdata och vem som får ändra i kärntransaktioner – står fortfarande helt orörd.

Därmed uppstår en risk som de flesta beslutsfattare ännu inte har insett: De som kan bygga en app är inte nödvändigtvis behöriga att låta appen lagligt röra datan.

Verkliga scenarion vi har följt (e-handel, avidentifierat): En möbelhandlare på nätet – deras influencer-marknadsföringsteam byggde själva sju interna verktyg med Lovable på två månader: matchningsverktyg för influencers, provisionskalkylator, trendspårning och returanalys. Ingen informerade den tekniska plattformsavdelningen. Vid halvårets inventering av skugg-IT upptäcktes att fyra av verktygen läste orderdatabaser med telefonnummer och leveransadresser, och två exporterade data till privata molnlagringstjänster. Detta är en vanlig situation för e-handelns plattformsavdelningar vid tillgångsinventering från och med andra halvåret 2025 – inte ett isolerat fall.

Verkliga scenarion vi har följt (telekomoperatör, avidentifierat): Vid en intern utbildningsutvärdering i ett regionalt dotterbolag till en kinesisk telekomoperatör erkände projektledaren för marknadsavdelningen att de redan hade byggt ett “snabbsökningsverktyg för kundprofiler” med Bolt – genom att ange ett telefonnummer kunde man hämta ut de senaste 90 dagarnas abonnemangsändringar, klagomålshistorik och rekommendationslistor. Teknikavdelningen var helt ovetande. Detta stred direkt mot bestämmelserna i Kinas dataskyddslag (Data Security Law) och personuppgiftslagen (Personal Information Protection Law, PIPL) gällande behörighet att söka i personuppgifter.

Ta en titt på bilden nedan för att se hur exponeringen ser ut.

Låt oss bryta ner det: vilka problem dessa verktyg löser och för vem, hur ingenjörernas roll förändras, hur skuggaplikationerna som just nu exploderar inom e-handel ser ut, vilka flaskhalsar som verkligen finns i hårt reglerade branscher, och hur man ger verksamheten en kompatibel väg framåt.

1. Sätt först in de fem verktygen i sitt sammanhang

Många blandar ihop dessa verktyg och kallar alltihop för “AI-programmering”. Men de betjänar två helt olika målgrupper – och först när man håller isär dem kan man dra rimliga slutsatser.

Den ena gruppen är “de som redan kan koda”. Det de vill ha är en snabbare kodredigerare: ett verktyg som förstår kontexten i din kodbas, kan göra ändringar över flera filer, köra tester automatiskt och förklara felmeddelanden. Representanter för den här kategorin är Cursor, Trae (ByteDance), Tongyi Lingma (Alibaba coding assistant) och GitHub Copilot. Förutsättningen är att du redan kan ingenjörskonst – verktyget sparar dig bara från repetitivt arbete. Vi gick igenom den här kategorin i del fyra av serien, så jag går inte in på den här.

Den andra gruppen är “de som inte kan koda”. Det är de som är huvudpersonerna i den här texten: app-generatorer. Du beskriver på en mening vad du vill ha, på vanligt språk, och verktyget ger dig direkt en fungerande app – frontend, backend, databas, deployment – allt i ett. Det förutsätter inte att du kan programmera.

Vi har valt ut fyra app-generatorer som huvudämne för den här texten. Men vi tar också upp Trae separat bland AI-IDE:erna, eftersom det träffar en punkt som är livsviktig för hårt reglerade branscher.

Bolt.new (från StackBlitz). I oktober 2024 lanserades produkten stillsamt via ett enda inlägg på X, och har sedan dess spårats av Sacra och Growth Unhinged som den näst snabbast växande produkten i historien (endast överträffad av ChatGPT): över 1 miljon USD i årlig återkommande intäkt (ARR) första veckan, 4 miljoner efter fyra veckor, cirka 20 miljoner efter två månader, 40 miljoner efter fem månader, och cirka 5 miljoner registrerade användare (enligt offentliga uttalanden från StackBlitz vd). Den underliggande tekniken kallas WebContainers, som gör det möjligt att köra en komplett Node.js-miljö direkt i webbläsaren. Det innebär att AI:n kan manipulera filer, installera paket och starta tjänster utan att du behöver konfigurera en lokal utvecklingsmiljö. När räkenskapsåret 2026 avslutades använde tre fjärdedelar av Fortune 500-företagen Bolt.new, och den företagsinriktade ARR:en hade vuxit tiofalt jämfört med föregående år (enligt ett officiellt inlägg från Eric Simons på LinkedIn i samband med räkenskapsårets slut). StackBlitz tog in 105,5 miljoner USD i en serie B-runda i januari 2025, till en värdering på cirka 700 miljoner USD (rapporterat av bland annat Business Insider). Ett typiskt användningsområde är att bygga en liten app eller en landningssida som man direkt kan öppna och testa.

Lovable (Stockholm, Sverige; grundat av Anton Osika, med rötter i open source-projektet GPT Engineer). Deras approach är “från en mening till en komplett, driftsatt applikation” – positioneringen ligger närmare fullstack affärsapplikationer än Bolt. I november 2025 tog de in $200M i en Series A-runda till en värdering på $1.8B, och i slutet av december 2025 ytterligare $330M i en Series B-runda till en värdering på $6.6B – värderingen nästan fyrdubblades på ett halvår. I juni 2026 passerade ARR $500M (rapporterat av Forbes 2026-06-05, även TechCrunch), och samma dag citerade Forbes fyra personer med insyn som uppgav att bolaget var i färd med att ta in en ny finansieringsrunda till en värdering om cirka $12B (ungefär en fördubbling; Forbes/Rashi Shrivastava). På Lovables kundlista bland företagskunderna finns redan Workday, Asana och NVIDIA (enligt ARR.club 2026).

Vercel v0. Lanserades i oktober 2023 och bytte officiellt namn från v0.dev till v0.app den 3 februari 2026. Från att ha varit ett verktyg för UI-komponentprototyper har det utvecklats till en fullstack-applikationsgenerator (sandbox-runtime + GitHub-integration + databasintegration med Snowflake/AWS). I mars 2026 uppgav Vercel officiellt att man har över 6 miljoner utvecklare som användare och cirka 80 000 aktiva team per månad (konkurrensanalytiker uppskattar ARR till cirka 42 MUSD, enligt Taskades sammanställning från mars 2026).

Replit Agent 4. Lanserades den 13 mars 2026 och är den viktigaste uppdateringen i Replits historia. Tre saker förändrades samtidigt: ① Design Mode uppgraderades till Infinite Design Canvas, där man kan designa och ändra kod parallellt; ② samarbetet gick från fork-and-merge till “samma projekt, flera parallella uppgifter” – flera sub-agenter körs samtidigt och slås slutligen samman automatiskt av en konfliktlösande sub-agent. Officiella siffror: Agent 4 löste 90 % av merge-konflikterna automatiskt (rapporterat av AlphaSignal 2026, bekräftat i Replits officiella changelog från mars 2026); ③ planering och exekvering är inte längre sekventiella – man kan planera och utföra samtidigt. Under samma period tog Replit in en D-runda till en värdering på nära 9 miljarder dollar (rapporterat av Atal Upadhyay 2026; flera källor som TechCrunch/Bloomberg bekräftar). Replit började som en online-miljö för kodning och har därför alltid haft samarbete och hosting inbyggt. Med Agent 4 har “ett gäng som bygger en produkt tillsammans” komprimerats till nära nog en individs hastighet.

Det gemensamma för dessa fyra: kostnaden för att “bygga en app” har gått från team-månader till individ-timmar.

Vi tar Trae separat, eftersom det utgör en konkret leverantörsrisk för företagskunder inom telekom, finans och e-handel. Trae är formellt en IDE (kodredigerare), men i praktiken en utvecklingsmiljö som är hårt knuten till Bytedances servrar – för företagskunder ska den inte behandlas som en “vanlig IDE” utan som ett “verktyg för dataöverföring utomlands” och genomgå en behörighetsbedömning därefter. Bytedance lanserade produkten i januari 2025 som en konkurrent till Cursor, med strategin att erbjuda premiummodeller som Claude och GPT-4o kostnadsfritt. På 12 månader nådde man 6 miljoner registrerade användare, 1,6 miljoner månadsaktiva och totalt cirka 100 miljarder genererade kodrader (sammanställning från OpenAI Tools Hub, maj 2026). Men i juli 2025 publicerade säkerhetsforskaren segmentationf4u1t projektet telemetry_research, som visade att – även om du stänger av telemetri i inställningarna – fortsätter Trae att i bakgrunden överföra data till Bytedances servrar, däribland mon-va.byteoversea.com – inklusive hårdvaruuppgifter, OS-version, beständiga enhets- och maskinidentifierare samt projektaktivitetsdata. En enskild telemetribatch kan vara upp till 53 606 byte; cirka 7 minuters normal användning genererar 500+ anrop och cirka 26 MB data (förstahandsdata från GitHub segmentationf4u1t/trae_telemetry_research, rapporterat av The Register/Cybernews 2025-07-28).

Bytes fortsatta svar är värt att dokumentera. I sin uppdatering från 2026-08-01 skriver Cybernews: ByteDance erkänner officiellt att telemetry-växeln i IDE-inställningarna bara styr telemetrin för VS Code-delen – övrig datainsamling från Trae-verktygen påverkas inte av denna brytare. Översatt till klarspråk: du tror att du stängt av det, men det har du inte. Efter att forskare kontaktat Trae-teamet direkt bekräftades att en separat Privacy Mode planeras att lanseras runt augusti 2026. Samtidigt bröt Trae sitt “forever free”-löfte med sin token-baserade betalvägg i februari 2026, vilket fått många utvecklare som byggt in verktyget i produktion att omvärdera läget (enligt en sammanställning från OpenAI Tools Hub, maj 2026).

För den enskilda utvecklaren är gratis Claude onekligen lockande. För dig som beslutsfattare handlar det däremot om ett klassiskt problem med gränsöverskridande dataöverföring – dina ingenjörer matar in företagets kod, och möjligen även konfiguration och API:er, i ett verktyg som skickar data till ByteDances servrar. Inom branscher som telekom och finans, som lyder under Kinas dataskyddslag (Data Security Law) och lag om skydd av personuppgifter (Personal Information Protection Law), räcker detta steg i sig för att utlösa en regelefterlevnadshändelse. Avsnitt 4 går in på detta i detalj.

2. Utveckling skrivs om: från “att skriva kod” till “att granska, orkestrera och kvalitetssäkra”

App-generatorer misstolkas ofta som att “vi inte behöver ingenjörer längre”. Det är fel riktning.

Den korrekta beskrivningen är: Det som förändras är ingenjörens arbetsfokus – inte att rollen försvinner. När både AI och affärspersonal kan producera kod och appar, flyttas ingenjörens värde från “att själv skriva” till tre saker: att granska om det som produceras är korrekt, att orkestrera det till tillförlitliga system, och att hålla säkerhets- och kvalitetsstängslen.

Dessa tre saker är mer sällsynta än “att skriva kod” – och mer värda. Det finns gott om människor som kan skriva en React-komponent; det är betydligt ovanligare med någon som kan bedöma om en AI-genererad kampanjapp faktiskt får röra orderdata, om dess autentisering är på riktigt eller bara skenbar, och om den loggar till utländska tjänster utan tillstånd.

Här behövs ett tydligt lagerbaserat ställningstagande, för alltför många företag hamnar i ytterligheter: antingen vågar de lämna allt till generatorn, eller så förbjuder de allt med ett enda streck. Båda ytterligheterna kostar.

Budskapet i den här bilden ryms i en enda mening: Den horisontella axeln visar hur komplex applikationens logik är, den vertikala axeln visar om den rör pengar och personuppgifter. I det nedre högra hörnet (hög komplexitet plus hög känslighet) – där har App-generatorn inget att göra, hur smart den än är. En kampanjlandningssida kan du tryggt lämna till Lovable; din betalningsgateway – där är det bara en tidsfråga innan något går fel.

Skriv in den röda linjen, och titta sedan på vad som faktiskt händer inom e-handeln.

Tre. E-handelns verkliga smärtpunkt: Skuggapplikationer når orderdata

Om vi zoomar ut en stund, låt oss först titta på en siffra som Gartner presenterade under andra halvåret 2025: I slutet av 2026 kommer 40 % av företagsapplikationerna att ha inbäddade uppgiftsspecifika AI-agenter, jämfört med mindre än 5 % 2025 (Gartners officiella prognos, även publicerad av Process Excellence Network 2025-08-27). Till detta kommer en ännu mer slående siffra: Gartner rapporterar att företagsförfrågningar om multi-agent-system ökade med 1445 % mellan Q1 2024 och Q2 2025 – det är det snabbast växande ämnet inom Gartners AI-advisoryverksamhet, utan konkurrens (sammanställt från RAPIDCLAW/Hendricks.ai/Arion Research).

Översätt dessa två siffror till e-handelsspråk: 40 % av företagsapplikationerna kommer att köra AI-agenter – tillsammans med en annan siffra – företagsförfrågningar om multi-agent-system har ökat med +1 445 % (enligt Gartners AI-advisory, mätt på konsultförfrågningar, inte faktiska implementationer – men signalen är tydlig): AI-agenter har gått från att “hjälpa människor skriva kod” till att “flera agenter samarbetar och kör hela affärsflöden”. När AI-agenter börjar användas i företagsapplikationer – när de rör data, kör processer och skriver loggar – förändras appbyggarens karaktär från “verktyg” till “system”.

Forskningsföretaget UpGards rapport från 2025 (State of Shadow AI, rapporterad av Cybersecurity Dive) innehåller två siffror som är mer uppseendeväckande än Gartners 40 procent: över 80 procent av de anställda använder icke-godkända AI-verktyg i arbetet, och nästan 90 procent inom säkerhetsteamen gör detsamma. Och ytterligare en: ungefär hälften av de anställda medger att de klistrat in konfidentiell företagsdata i dessa icke-godkända verktyg. Mimecast anger 51 procent, Teramind 49 procent – siffrorna ligger nära varandra. Gartner visar på en annan siffra: 69 procent av organisationerna misstänker eller bekräftar att anställda använder förbjudna AI-verktyg, medan endast 37 procent har riktlinjer för AI-användning (återgivet via The Hacker News).

Översätter man dessa siffror till e-handelsspråk: dina driftansvariga, dina marknadsförare och dina kampanjplanerare bygger egna appar med verktyg som Bolt, Lovable och v0. Kampanjregelkonfiguratorer, instrumentpaneler för influencer-produktval, inventeringsappar och ärendehanteringsverktyg för kundsupport. De är snabba, användarvänliga och löser verkliga problem. De kringgår också nästan alltid IT- och dataförvaltningen.

En verklig situation vi har sett (e-handel, avidentifierad): Från och med andra halvåret 2025 har vi kartlagt skugg-IT hos fyra medelstora e-handelsföretag (plattformsorganisationer med 50–200 anställda) – och inte ett enda var tomt. Det mest typiska exemplet: en heminrednings-e-handlare där influencer-teamet på två månader byggt sju interna verktyg i Lovable. Fyra av dem läste direkt mot orderdatabasen (inklusive telefonnummer och leveransadresser), och två exporterade data till privata molnlagringstjänster. Säkerhetschefens kommentar under kartläggningen: “Vi var nära att avbryta hela inventeringen – vi var rädda att ingen skulle kunna hantera det vi hittade om vi rapporterade uppåt.”

Man kan kalla det för “datans skugg-IT”. Under de senaste tio åren har skugg-IT handlat om SaaS-verktyg som affärsverksamheten köpt in på eget initiativ (sälj köpte ett CRM, marknad köpte ett e-postverktyg). Dagens skugg-IT är däremot applikationer som verksamheten själv bygger. Det börjar med ett icke-godkänt verktyg – men värre: det producerar också ett nytt system som hanterar känslig data, och det systemet finns inte i IT:s tillgångsregister.

Skillnaden ligger i skala: att köpa en SaaS innebär att koppla in ett externt system; att bygga applikationer med en generator innebär att en mängd nya system växer fram internt – alla med data-API:er, alla potentiellt nåbara från internet. På ett år kan en e-handlare få över hundra sådana applikationer, och ingen av dem finns i IT:s tillgångsregister.

Det här går inte att stoppa. UpGuards 80 % visar redan att “förbud” inte fungerar. Människor kommer alltid att välja det smidigaste verktyget för att få jobbet gjort – det är mänsklig natur, och det är KPI:er. Så fråga inte “hur får vi affärssidan att sluta använda generatorer”, utan “hur får vi dem att använda dem säkert”. Avsnitt fyra handlar om regelefterlevnadens trösklar, avsnitt fem om hur man öppnar kanalerna.

4. Vilka är regelefterlevnadens trösklar: se det inte som ett test

Det här är det avsnitt som är viktigast att få rätt – och lättast att skriva fel.

Många med bakgrund från internetbolag tänker automatiskt på CI/CD-automatiserade tester när de hör “kvalitetsgrind”: enhetstester, integrationstester, regressionstester – grönt ljus och släpp. För tech-team som kör e-handelns kampanjtrafik är det här välbekant.

Men inom telekom, finans, reglerad tillverkning och e-handel är “verifiering” långt mer än tester. De verkliga flaskhalsarna är ett antal steg som nästan inte har något med själva koden att göra – men som var och en kan ta flera veckor. Att beskriva dem som “tester” är en internetbolagsfördom som lurar beslutsfattare att underskatta leveranstiden.

Låt oss gå igenom dem en i taget.

Bedömning av dataöverföring över gränserna.[^1] Om din applikation använder AI-tjänster från utlandet (många generatorer körs i grunden på OpenAI eller Anthropic), eller om dina ingenjörer använder IDE-verktyg som Trae som kan överföra data utomlands, aktiveras kraven på dataöverföring enligt lagen om datasäkerhet och lagen om skydd av personuppgifter – så länge datan innehåller personuppgifter eller annan känslig information. Att genomföra en formell säkerhetsbedömning för dataöverföring eller standardavtalsregistrering tar allt från en till två månader i bästa fall, upp till ett halvår eller mer i värsta fall. Upptäckten att Trae överför data även när telemetri är avstängd innebär att data kan lämna landet även när du tror att den inte gör det. Sådana verktyg hör helt enkelt inte hemma i utvecklingsmiljöer inom hårt reglerade branscher.

Säkerhetsklassning enligt Multi-Level Protection Scheme (等保, “Dengbao”).[^2] Enligt nivåskyddsreglerna 2.0 i cybersäkerhetslagen hamnar en publik applikation med stor sannolikhet på skyddsnivå 3. Processen med klassificering, registrering, åtgärdande och granskning tar vanligtvis tre till sex månader. Detta är ett lagkrav, inte en valmöjlighet. Att din applikation är byggd med AI innebär inte att du slipper säkerhetsklassningen.

Registrering av algoritmer.[^3] Om din applikation vänder sig till allmänheten och använder generativ AI (till exempel automatisk generering av produktbeskrivningar, automatiska kundservicesvar eller AI-genererat innehåll i personliga rekommendationer), måste du registrera algoritmen enligt de interimistiska åtgärderna för hantering av generativa AI-tjänster och relaterade regler för algoritmrekommendationer. Att lansera utan registrering är ett regelefterlevnadsbrott.

Ändringsgodkännande (CAB) och återställningsplaner.[^4] För kärnsystem inom finans och telekom krävs godkännande från Change Advisory Board (CAB) inför varje driftsättning: konsekvensanalys, återställningsplan och fönsterbekräftelse. Det som äts upp här är kalendertid, inte maskintid – missar du fönstret får du vänta till nästa vecka.

Avstämning och revision.[^5] Vid e-handelns kampanjer och finanssektorns avveckling/avräkning krävs avstämning mot likvida medel och motparter efter driftsättning, samt revisionsloggar som spårar varje transaktion. AI-genererade appar är ofta helt nakna på den här punkten: de fungerar, men de har ingen avstämningsdesign – uppstår en avvikelse går den inte att spåra.

Lägger man ihop allt detta ser man en kontraintuitiv slutsats: App-generatorer gör att du går från “idé” till “fungerande prototyp” en tiopotens snabbare, men från “fungerande prototyp” till “kompliant driftsättning” sparar du ingenting. De där grindarna tar lika lång tid som förut.

Det är den röda linjen i diagrammet i första avsnittet som inte rört sig. Utvecklingströskeln har raserats – det som sparats är ingenjörernas kodtid; compliance-tröskeln har inte rört sig – alla utvärderingar, tester och godkännanden tar fortfarande lika lång tid. Beslutsfattarnas största missuppfattning är att den första accelerationen automatiskt leder till den andra. Det gör den inte.

5. Ge verksamheten en kompatibel väg – låt den inte växa vilt

Eftersom det inte går att stänga ute, ge dem en kanal – det är en av de få vägar som faktiskt fungerar för att hantera skugg-IT.

Så här bygger du kanalen, i fyra steg.

Steg ett: Företaget tillhandahåller själv en säkerhetsgranskad generator. Istället för att låta verksamheten använda vilken extern tjänst som helst, till exempel en godtycklig Lovable-lösning, bör företaget köpa in eller bygga en egen version som uppfyller kraven på skyddsnivå (dengbao, kinesisk säkerhetsklassning) och som inte exporterar data utanför landets gränser. Ge den en intern ingång. När verksamheten väl har ett smidigt verktyg internt, minskar incitamentet att söka sig utåt – detta är den konstruktiva vägen framåt, snarare än att bara blockera.

Microsofts FY26 ger ett referensexempel: EY rullade ut Copilot till 150 000 anställda och uppnådde 15 % produktivitetsökning. Atos distribuerade Copilot till 56 000 anställda i 54 länder och hanterar 19 000 AI-agenter under en gemensam kontrollyta för identitet, säkerhet, regelefterlevnad och agentstyrning (Microsoft FY26-retrospektiv, 2026-07-28; Atos officiella nyhet, 2026-06-09 – båda är gemensamma uttalanden från leverantör och kund). Det gemensamma draget: AI-verktygen integrerades i företagets säkerhets- och regelefterlevnadsplattform – ett levande exempel på en sanktionerad kanal.

I Kina finns motsvarande initiativ: Finansbranschens institut för informations- och kommunikationsteknologi (finansiell informations- och kommunikationsakademi) har publicerat riktlinjer för regelefterlevnad vid tillämpning av stora språkmodeller inom finanssektorn, och industridepartementets pilotprojekt “AI för nyindustrialisering” visar på liknande efterlevnadslösningar. Den lokala vägen är redan igång – det som saknas är att integrera den i företagets obligatoriska processer.

Steg två: obligatorisk registrering. Vem har byggt applikationen, vilka data läses, vilka användare riktar den sig till – allt förs in i ett register. Registreringen ska vara lättviktig: ett formulär som tar fem minuter, inte en process som drar ut på två månader. Annars struntar alla i den, och allt glider tillbaka in i skuggorna igen. Syftet är inte att godkänna varje applikation, utan att ge dig en överblick.

Steg tre: dirigera efter dataklassificering. Använd matrisen från avsnitt två. Applikationer som bara rör anonymiserad eller testdata släpps igenom automatiskt; så fort någon ansöker om åtkomst till riktiga order- eller personuppgifter utlöses automatiskt en förhandsgranskning av dataöverföring över gränserna och en säkerhetsbedömning (等保, motsvarande Kinas motsvarighet till NIS2-krav). Låt processen följa datakänsligheten – inte en generisk bedömning av alla applikationer.

Steg 4: Automatisk säkerhetsskanning. AI-genererade applikationer har en markant högre andel säkerhetsbrister än mänskligt skriven kod. CodeRabbit uppdaterade siffran i sin rapport från 2026: AI-assisterad kod genererar 1,7 gånger fler problem (inklusive logiska och korrekthetsbuggar) än traditionellt handskriven kod (CodeRabbits egen mätmetod, med kommersiella intressen; bekräftat i samband med DORA:s webbseminarium i februari 2026 och Kunal Ganglanis oberoende jämförelsetest 2026). Veracodes GenAI-säkerhetsrapport från 2025 är ännu mer direkt: i deras testade urval innehöll cirka 45 % av AI-genererad kod sårbarheter på OWASP Top 10-nivå (för Java-genererad kod översteg felfrekvensen 70 %, Veracodes egen mätmetod, med kommersiella intressen). En akademisk storskalig empirisk studie av offentliga GitHub-repositories (arXiv:2510.26103) pekar i samma riktning. Skanningen är därför obligatorisk för AI-genererade applikationer, inte valfri. Koppla in SAST, beroendeskanner och hemlighetsskanner i generatorns releaseprocess – släpp bara igenom när allt är grönt. CodeRabbit bekräftades i juni 2026 som det mest installerade AI-kodgranskningsverktyget på GitHub/GitLab, med över 15 000 betalande kunder och 600 miljoner granskade repositories. Till och med NVIDIAs vd Jensen Huang har offentligt sagt att “hela NVIDIA använder CodeRabbit” – att använda det som en baslinjereferens för företagsmässig AI-kvalitetskontroll är därför rimligt.

De här fyra stegen innebar i praktiken ingen märkbar inbromsning för verksamheten, men varje applikation hamnade nu på en granskningsbar lista, och de som rörde känsliga data stoppades för formell bedömning. Det här är styrning, inte inbromsning.

Här måste en felciterad siffra rättas. I originaltexten förekom “45 % skugg-AI-adoption” – det är felaktigt tillskrivet. 45 % är andelen defekter i AI-genererad kod enligt Veracodes rapport, inte adoptionsgraden för verktyget; för skugg-AI-adoption ska man titta på UpGards siffra på 80 %+. De två siffrorna handlar om helt olika saker – blanda inte ihop dem.

Sex. När man inte ska använda app-generatorer

Det är ingen silverskott. Fyra typiska missbruk – vi har sett vartenda ett hos kunder vi jobbat med.

För kärntransaktioner eller riskhantering. Det här är det farligaste. Någon tänker: “Generatorn är så pass stark – vi kan testa med betalningsgatewayen också.” Det nedre högra hörnet i matrisen ovan är rött: komplex logik i kombination med pengar – att lämna det till en generator är som att ge kärnsystemet till en praktikant som inte står till svars. Sker en betalningsincident finns ingen avstämning, ingen granskning, ingen återrullningsplan.

Standardantagandet att AI-genererad kod är säker. CodeRabbits 1,7x och Veracodes 45 % har redan besvarat den frågan. Mellan en AI-genererad app som “verkar fungera” och en som “fungerar säkert” ligger ett helt säkerhetstekniskt hantverk. Att särbehandla AI-genererade appar och sänka säkerhetskraven jämfört med manuellt utvecklad kod är att producera fler sårbarheter i högre takt.

Att hantera personuppgifter med utländska generatorer utan att genomföra en konsekvensbedömning för dataöverföring. Detta är särskilt lömskt inom e-handel: man bygger en kampanjsida mot konsumenter, backend anropar OpenAI för att generera copy, och användarens telefonnummer följer med in i utlandstjänsten. Där har man klivit rakt över gränsen i Kinas personuppgiftslag (PIPL). När något går fel är det en dataskyddsincident, inte en teknisk bugg.

Att som standard installera en IDE med dataöverföring utomlands, som Trae, för alla ingenjörer i företaget. Lockelsen med gratis premiummodeller är stor, och ingenjörer installerar dem på eget initiativ. När din kärnkod, konfiguration och dina API:er väl hamnat på ByteDances servrar (eller hos någon annan utländsk part) är det för sent att åtgärda. Sådana verktyg i utvecklingsmiljön kräver en godkännandeprocess tillsammans med säkerhets- och juridikavdelningen – det är inte något teknikteamet kan besluta på egen hand.

7. Fyra branscher i fokus: vilka appar kan du släppa igenom, och vilka får du aldrig släppa igenom

Det här kapitlet fokuserar på fyra branscher där vi har hjälpt företag genom verkliga problem (e-handel / finans / telekom / tillverkning). Offentlig sektor, sjukvård och andra hårt reglerade branscher behandlas i ett separat kapitel och tas inte upp här.

Låt oss zooma in på de fyra branscherna – ett verkligt scenario från vardera som vi har stött på.

E-handel. De vanligaste fallgroparna är “kampanjregelkonfiguratorer”, “influencer-produktpaneler” och “lagerfrågeappar” – de ser ut som verktyg, men i praktiken läser de orderdata med telefonnummer och adresser. Den här typen av applikationer måste registreras via den sanktionerade kanalen i avsnitt 3, och om de rör riktig data utlöses automatiskt säkerhetsklassning och granskning av dataöverföring över gränserna. Vi har själva sett en e-handelsoperatör bygga sju interna verktyg på två månader – fyra av dem läste orderdata. Det är inget isolerat fall.

Finans. Röd linje: “transaktionssystem / betalningar / clearing och avveckling / riskkontroll / bedrägeribekämpning / regulatorisk rapportering”. Generatorn passar för kundansvarigas arbetsytor, kampanjkonfiguratorer och avstämningsrapporter. Använd den aldrig till riskmotorer eller bedrägeriregler – CodeRabbits 1,7× logikbuggkvot (CodeRabbits egen metodik, inklusive kommersiella intressen) blir i finansiella scenarier en förstärkare av kapitalrisk. Fallet är anonymiserat: en aktiebank började i slutet av 2025 använda AI-programmering för att generera regulatoriska rapporter. Resultatet: tre felaktiga fältdefinitioner i rapporteringsskripten enligt tillsynsmyndighetens regler, vilket ledde till ett formellt samtal med tillsynen. En av grundorsakerna: AI-genererad kod som “ser korrekt ut” granskades aldrig av någon.

Telekom/operatörer. En regional operatör vi arbetat med hade ett marknadsföringsteam på en lokal avdelning som byggt en “snabb kundprofilssökning” med Bolt – där man kunde mata in ett mobilnummer och få upp 90 dagars abonnemangs-, klagomåls- och rekommendationshistorik. Det kolliderade direkt med gränserna för registerutdrag enligt dataskyddsförordningen (GDPR). I operatörsmiljöer kan generativa verktyg användas för “kundansvariges arbetsyta”, “front-end för kunskapsbasen” och “konfigurering av kampanjer” – men absolut inte för debitering, fakturering eller detaljerad samtalshistorik. Det är operatörens hjärtefrågor; ett enda misstag där hamnar på förstasidorna.

Tillverkning. MES/ERP-integration, kvalitetskontroll och rapportering är kärnsystem – generatorn får bara användas till perifera delar som skärmtavlor i produktionen, processflödesuppslagning och OEE-demoer. Rör aldrig: kärnalgoritmerna för produktionsplanering, kvalitetsbedömningsregler eller gränssnittet mot ERP för avstämning. Exemplet är avidentifierat: en underleverantör till bilindustrin (det finns flera liknande offentliga återkallelser; exemplet bygger på en sammanställning av offentliga återkallelseannonser och projekt jag själv deltagit i, för att illustrera beslutslogiken – inte för att peka ut något specifikt företag) lät IT bygga en “frontend för AI-modellen för kvalitetskontroll” med Bolt. Avsikten var bara att visa stickprovsbilder och bedömningsresultat, men vid frontend-renderingen hårdkodades AI-modellens råa konfidenströskel i klienten. En anställd råkade ändra 0,85 till 0,6, och under tre dagar flödade över 200 detaljer som borde ha markerats som “underkända” vidare till nästa steg i produktionen som “godkända”. Slutet blev återkallelse av tre batcher. Medelstora tillverkningsföretags vanligaste misstag är att även lämna “frontend för kvalitetskontrollens AI-modell” till generatorn – kvalitetsreglerna ligger direkt uppströms produktåterkallelser, och ett enda fel kan bli en återkallelseannons.

Åtta. Lärdomar för beslutsfattare

Insikt 1: Rita en applikationslagerkarta innan du köper verktyg.
Ta matrisen från avsnitt två och fyll i de applikationer ni redan har och de ni planerar att bygga, utifrån komplexitet och datakänslighet. Då ser du direkt: vilka som ligger i grön zon och tryggt kan överlåtas åt generatorer för snabbare utveckling, och vilka som är i röd zon och inte får röras. Den här enda kartan stoppar en mängd impulsiva förslag om att ”bygga om kärnsystemen med generatorer” – och ger samtidigt de delar som faktiskt kan snabbas upp legitimt stöd att göra just det.

Insikt 2: Behandla dataöverföring över gränser och säkerhetsklassning som inträdeskrav – inte som efterhandskonstruktioner.
Innan du köper något AI-verktyg som kommer i kontakt med kod eller data, kontrollera dessa två saker först. Problemet med verktyg som Trae är inte ”om de fungerar”, utan ”om de får användas i din regulatoriska miljö”. Det beslutet måste fattas i förväg – priset för att göra fel är efterhandsjusteringar, tillsynsrapporteringar och i värsta fall nedstängning. Konkret: integrera AI-verktygsinköp i en gemensam godkännandeprocess med säkerhets- och juridikavdelningen, och ta fram en tydlig lista över vad som får användas i utvecklingsmiljön och vad som kräver individuell prövning.

Insikt 3: Ge verksamheten en laglig väg framåt – annars blir skuggsystemen bara fler.
De 80 procenten från avsnitt tre visar att det inte går att blockera. Vänta inte tills något går fel för att inventera – bygg den kanal som beskrivs i avsnitt fem redan nu: sanktionerade generatorer, lättviktsregistrering, dirigering baserad på datatyp och automatisk skanning. Låt verksamheten röra sig snabbt, men se till att varje applikation finns med i registret. Det är så du förvandlar skuggsystem från en ohanterad blind fläck till en granskningsbar tillgång.

Insikt fyra: Ändra mätetalen, annars går hela budgeten till verktyg – och flaskhalsarna kvarstår. Det här är riktat till högsta ledningen. Många styrelser mäter idag AI-transformationens framgång i termer av “hur många AI-licenser vi köpt” eller “hur mycket snabbare utvecklingen gått”. Problemet med den typen av mätetal är att budgeten då oavkortat går till att köpa in verktyg, medan de verkliga flaskhalsarna i leveransen – såsom roller för dataexportbedömning (motsvarande GDPR:s överföringsregler), compliance för cybersäkerhetsskydd (MLPS / Dengbao, motsvarande NIS2-krav), säkerhetsarkitektur och avstämning/granskning – varken får pengar eller personal. Resultatet blir en hög med verktyg, men leveransen är fortfarande långsam. För att bota “vi vet, men vi agerar inte” måste mätetalen ändras uppifrån. Lägg till mätetal som “hur många applikationer täcks av compliance-processen”, “antalet skugga-applikationer har minskat från N till M” och “ledtiden för kärnapplikationer från prototyp till compliant drift”. När mätetalen ändras, följer budgeten efter – till de ställen där det verkligen flaskhalsar.

Självtest (var ärlig i dina svar): Hur många AI-applikationer som affärsenheterna byggt själva körs just nu i ditt företag – kan du säga en siffra? Hur många av dessa applikationer hanterar order, telefonnummer eller adresser? Den AI-IDE som du som standard installerar åt dina utvecklare – har du koll på vart datan skickas? De mätetal du använder för AI-utvärdering – belönar de “att köpa verktyg” eller “att leverera snabbare”? Om du känner dig osäker på någon av dessa fyra frågor, så har de risker som beskrivs i den här texten redan inträffat i ditt företag.

Nästa steg

Detta är den femte artikeln i en serie om 18 om “mjukvaruutvecklingens förändring i AI-eran”. Vi har sett hur app-generatorer och AI-IDE:er raserar tröskeln för att “bygga en app”, och varför tröskeln för att röra data inte följer med i fallet.

Nästa artikel (artikel 6) tittar på en motsatt riktning som håller på att bli branschkonsensus: Spec-Driven Development. Varför GitHub Spec Kit, Claude Code, AWS Kiro och OpenAIs AGENTS.md alla rör sig mot “först skriv kraven i dokumentation, sedan låt AI:n agera”. Förra avsnittet visade just att AI-genererad kod har högre felprocent än mänskligt skriven kod – spec-driven utveckling är en av metoderna för att bota just detta: genom att omvandla vaga muntliga krav till kontrollerbara specifikationer blir det möjligt att hålla AI:n ansvarig.

Om serien: Den här serien följer kontinuerligt den senaste utvecklingen inom AI-programmeringsverktyg, organisationsstrukturer och mjukvaruutvecklingsparadigm. Följ serien för löpande uppdaterade insikter.

Vill du omsätta dessa slutsatser i ditt företag?

När app-generatorer kommer in i företaget handlar det oftast om några konkreta frågor: vilka appar och data kan lämnas till verksamhetssidan för självbetjäning, vilka måste IT ta över, hur mycket behöver befintliga valideringsprocesser förstärkas, och vilka mätetal ska användas för att godkänna piloten.

Vi erbjuder för närvarande tre typer av samarbeten:

Intern utbildning: Utifrån era verkliga projekt genomför vi val av app-generator, definierar användningsgränser, säkerställer regelefterlevnad och designar styrningsmekanismer.
Specialiserad rådgivning: Fokuserad på ett tydligt beslut, till exempel “bör vi ge verksamheten tillgång till en sanktionerad app-generator” eller prioritering av åtgärder efter inventering av skuggapplikationer.
Ledningsworkshops och branschpresentationer: Kring AI-programmeringsverktyg, styrning av skuggapplikationer, AI-transformation och organisatorisk styrning.

Artikeln erbjuder ett generellt ramverk. Konkret implementering kräver dock omdesign utifrån företagets datagränser, regulatoriska krav, teknisk mognad och befintliga leveransprocesser. Samarbete kan initieras via coach@iaiuse.com.

Vidare läsning: Se Skyltmetodiken v1.0 (慢慢学AI 187), som systematiskt presenterar en 7-stegsram för AI-transformation i företag.

Om denna serie

“Mjukvaruutvecklingens förändring i AI-eran” är en forskningsserie i 18 delar riktad till CIO:er, CDO:er, CTO:er och digitaliseringsansvariga inom telekom, finans, tillverkning och e-handel. Serien fokuserar på hur AI-programmeringsverktyg, app-generatorer och styrning av skuggapplikationer påverkar mjukvaruleveransprocesser, organisationsstruktur, styrningsmekanismer och ledningsmått.

Serien följer löpande upp akademiska uppsatser, leverantörsdokumentation och branschrapporter. Forskningsdatabasen omfattar nu över 200 källor, och varje central bedömning är märkt med evidensnivå för att i möjligaste mån skilja mellan verifierade fakta, leverantörspåståenden, branschobservationer och författarens egna härledningar.

Jag har närmare åtta års erfarenhet av konsultverksamhet och affärsanalys i stora företag, bland annat på IBM, där jag arbetade i projekt inom telekom, finans, försäkring och tillverkning. Därefter har jag fortsatt i operativa roller inom operatörsprodukter, internetprodukter och AI-applikationsutveckling – med fokus på kravanalys, produktdesign och tvärfunktionell implementering.

De bedömningar som presenteras i serien kring verktygsval, användningsgränser för app-generatorer, design av regelefterlevnad och organisatorisk styrning utgår från dessa praktiska erfarenheter och korsvalideras mot offentlig forskning och branschfall. Innehåll som rör specifika projekt är avidentifierat; vissa branschscenarier är typiska problemkonstruktioner, och underlaget anges i referenslistan i slutet.

Bakom kontot står faktiskt ett litet team – jag själv och en eller två långvariga kollegor som delar upp arbetet mellan AI-programmeringsverktyg, organisatoriska styrningsfall och coachande dialoger. De flesta projekt som beskrivs som “vi har lotsat företag genom” är gemensamma leveranser. Kundernas regelefterlevnadsgränser och personnamn nämns fortfarande inte – anonymiteten ger också utrymme för framtida samarbetspartners.

Referenser (samtliga verifierade, med evidensnivå och ståndpunkt angivna per källa)

StackBlitz CEO Eric Simons (LinkedIn, vid utgången av räkenskapsåret 2026). Bolt.new används av tre fjärdedelar av Fortune 500-företagen, och företags-ARR har vuxit tiofalt jämfört med föregående år. Uttalande direkt från företaget (leverantörsperspektiv). https://www.linkedin.com/posts/eric-simons-a464a664_a-growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV
Sacra / Growth Unhinged (2025). Spårning av Bolt.new:s ARR-tillväxt (cirka 5 månader till 40 miljoner USD i ARR, cirka 5 miljoner användare, den näst snabbaste tillväxten i historien efter ChatGPT). Primär forskning/spårning. https://sacra.com/c/bolt-new/ , https://www.growthunhinged.com/p/boltnew-growth-journey
Taskade (2026-03) / Business Insider. StackBlitz genomförde i januari 2025 en B-runda på 105,5 MUSD till en värdering på cirka 700 MUSD; Bolt V2 lanserades på Bolt Cloud. Sammanställning av branschrapporter.
Forbes / Rashi Shrivastava (2026-06-05). Lovable förhandlar om en ny finansieringsrunda till en värdering på 12 Mdr USD; ARR har passerat 500 MUSD (bekräftat av TechCrunch 2026-06-09). Branschledande rapportering. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation
CNBC / Bloomberg (2025-12) / TechCrunch (2025-11). Lovables B-runda: 330 MUSD till en värdering på 6,6 Mdr USD; A-runda: 200 MUSD till en värdering på 1,8 Mdr USD. Branschrapporter.
ARR.club (2026-07). Lovable ARR-tillväxtkurva: $17M (2025-02) → $100M (2025-07) → $200M (2025-11) → $400M (2026-02) → $500M (2026-06); företagskunder inkluderar Workday, Asana, NVIDIA. Branschbevakning.
Vercel (2026-02-03 officiell blogg “Introducing the new v0”). v0 byter namn från v0.dev till v0.app och utvecklas från UI-komponenter till en fullstack-applikationsgenerator (sandbox-runtime + GitHub + Snowflake/AWS-integration). Förstahandsbesked från leverantören. https://vercel.com/blog/introducing-the-new-v0
Taskade (2026-03) / Vercel. v0 hade i mars 2026 över 6M användare, cirka 80 000 aktiva team per månad och uppskattad ARR på cirka $42M. Samlad branschuppskattning.
Replit (2026-03-13 officiell changelog + officiell blogg “What’s changed from Agent 3 to Agent 4”). Agent 4 släpptes 2026-03-11; Infinite Design Canvas; fork-and-merge-samarbete ersattes med flertrådade uppgifter inom samma projekt + automatisk konfliktlösning (90 % löses automatiskt). Förstahandskälla från leverantören. https://docs.replit.com/updates/2026/03/13/changelog
AlphaSignal (2026). Detaljerad rapportering om att Replit Agent 4 automatiskt löser 90 % av merge-konflikterna. Branschrapportering. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically
Atal Upadhyay (2026-03-19). Replit tillkännagav samma vecka en D-runda på 400 MUSD till en värdering på 9 miljarder USD (tredubblad på ett halvår). Baserat på branschrapporter. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything
Cybernews (uppdaterad 2026-08-01) / The Register (2025-07-28) / segmentationf4u1t (GitHub, förstahandsforskning). Trae skickar fortfarande data till Bytedances servrar – inklusive hårdvaruinformation, enhets-ID och projektaktivitetsdata – även när telemetri är avstängd. En enskild dataöverföring kan uppgå till 53 606 byte; över 500 anrop på 7 minuter motsvarar cirka 26 MB. Bytedance har officiellt bekräftat att växlingsknappen endast styr VS Code-ramverkets delar. Privacy Mode är planerad att lanseras runt augusti 2026. I februari 2026 tog Trae bort sitt “forever free”-löfte och införde en token-baserad betalvägg. Förstahandsanalys av säkerhetsforskare + branschrapportering + officiella uttalanden från leverantören. https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection 、https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ 、https://github.com/segmentationf4u1t/trae_telemetry_research
OpenAI Tools Hub / Jim Liu (2026-05-18). Trae registrerade 6 miljoner konton under sina första 12 månader, med 1,6 miljoner månatliga aktiva användare och totalt 100 miljarder genererade kodrader. I februari infördes en token-baserad betalvägg som bröt det tidigare löftet om “forever free”. En samlad analys utifrån ett analytikerperspektiv.
Gartner (refererat via Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). Fram till slutet av 2026 kommer 40 % av alla företagsapplikationer att innehålla uppgiftsspecifika AI-agenter (jämfört med mindre än 5 % 2025). Till 2035 beräknas agentisk AI utgöra cirka 30 % av företagsmjukvarumarknaden (450 miljarder USD). Officiell prognosdokumentation. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026
Gartner (återgivet via RapidClaw / Hendricks.ai / Arion Research, 2025–2026). Mellan Q1 2024 och Q2 2025 ökade antalet förfrågningar från företag om multi-agent-system med 1445% – det snabbast växande ämnet inom Gartners AI-advisoryverksamhet. Primär forskning/återgivning.
Microsoft (FY26-retrospektiv, 2026-07-28). EY har rullat ut Copilot till 150 000 anställda och uppnått 15% produktivitetsökning, med planer på att utöka till 400 000 globalt; Atos har implementerat Copilot för 56 000 anställda i 54 länder och hanterar 19 000 AI-agenter under en enhetlig kontrollpanel. Förstahandskälla från leverantör + kunduttalanden (leverantörs- och integratörsperspektiv). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Group (2026-06-09 officiellt pressmeddelande). Atos och Microsoft utökar sitt samarbete och rullar ut Copilot E7 (Frontier Suite) till 56 000 anställda, med en enhetlig kontrollyta för Entra/Defender/Intune/Purview/Agent 365 och drift av 19 000 agenter. Förstahandsuttalande från företaget. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos
UpGuard / Cybersecurity Dive (2025). Över 80 % av de anställda och nästan 90 % av säkerhetscheferna använder AI-verktyg som inte är godkända av organisationen; ungefär hälften av de anställda har klistrat in konfidentiell data i dessa verktyg (Mimecast och Teramind rapporterar liknande siffror, vilket stärker tillförlitligheten). Primär forskning + branschrapportering. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/
Gartner (återgivet via The Hacker News, 2026-5). 69 % av organisationerna misstänker eller har bekräftat att anställda använder förbjudna AI-verktyg; endast 37 % har riktlinjer för AI-användning. Branschrapportering som återger Gartners slutsatser.
CodeRabbit (2026-02 DORA joint webinar + Kunal Ganglani 2026-06 jämförande utvärdering). AI-assisterad kodgenerering ger cirka 1,7 gånger fler problem (inklusive logiska och korrekthetsbuggar) jämfört med traditionellt manuellt skriven kod; CodeRabbit är det mest installerade AI-kodgranskningsverktyget på GitHub/GitLab, med över 15 000 betalande kunder och 6 miljoner granskade repositories; NVIDIA:s vd Jensen Huang har offentligt gett sitt stöd. Primär forskning / leverantörsdata / branschjämförelse. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
Veracode (2025 GenAI Code Security Report). Cirka 45 % av de AI-genererade kodexemplen innehåller sårbarheter enligt OWASP Top 10 (för Java-genererad kod överstiger felfrekvensen 70 %). Primärforskning. https://www.veracode.com/blog/genai-code-security-report/ （Obs: I ett tidigare utkast misstolkades dessa “45 %” som “shadow AI-adoptionsgrad”, vilket var felaktigt och nu har korrigerats – 45 % avser defektfrekvensen i AI-genererad kod, inte verktygsadoption; shadow AI-adoptionsgraden framgår av UpGuard på 80 %+.)
arXiv:2510.26103. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories.（Empirisk primärstudie av säkerhetsbrister i AI-genererad kod）

Datakvalitetsnotis: Alla kvantitativa uppgifter i denna artikel är källangivna; ett fåtal siffror som inte offentliggjorts av leverantörer eller inte oberoende verifierats (t.ex. Lovables $12B-finansieringsrunda som ännu är under förhandling, eller den exakta inventeringstidpunkten för Atos 19 000 agenter) har nedgraderats. Kundfallen är avidentifierade (t.ex. e-handelsdriftsteam, marknadsavdelning vid en regional operatörs lokalkontor) och baseras på observerade scenarier från mitt eget leveransarbete, inte kopplade till specifika företag. Regelverk (dataöverföring över gränser, Multi-Level Protection Scheme, algoritmregistrering) följer gällande lagstiftning; tillämpligheten varierar beroende på verksamhet och datatyp – inhämta alltid juridisk/ compliance-rådgivning innan implementering.

[^1]: Viktiga data som förs ut ur landet omfattas av artikel 31 i Kinas dataskyddslag (säkerhetsbedömning av viktig dataexport); personuppgifter som förs ut omfattas av artiklarna 38–43 i den kinesiska personuppgiftslagen (villkor för export, standardavtal, certifieringsvägar, informations- och samtyckeskrav). Tillhörande regelverk: Åtgärder för säkerhetsbedömning av dataexport (i kraft 2022-09-01, CAC-föreskrift nr 11) och Åtgärder för standardavtal vid export av personuppgifter (i kraft 2023-06-01).
[^2]: Artikel 21 i Kinas cybersäkerhetslag (system för nivåskyddad informationssäkerhet), Informationssäkerhetsteknik – Grundläggande krav för cybersäkerhetsskydd på olika nivåer GB/T 22239-2019 (”Dengbao 2.0”); enligt Förvaltningsregler för informationssäkerhetsklassificering och -skydd (Gongtongzi [2007] nr 43) ska system på nivå 3 genomgå årlig klassificeringsrevision, medan system på nivå 2 normalt revideras vartannat år.

[^3]: Det är viktigt att skilja på tre olika saker: ① Artikel 24 i Förordningen om algoritmrekommendationer för internetinformations tjänster (i kraft 2022-03-01) (registrering av algoritmrekommendationer); ② Artikel 17 i Förordningen om hantering av djup syntes i internetinformationstjänster (i kraft 2023-01-10) (registrering av djup syntes); ③ Artikel 17 i Interimsåtgärder för hantering av generativa AI-tjänster (i kraft 2023-08-15) (generativa AI-tjänster som riktar sig till allmänheten och har opinionsbildande karaktär kräver säkerhetsbedömning – detta är en bedömning, inte en registrering). Koden som genereras av en app-generator i sig utlöser inte nödvändigtvis dessa tre kategorier, men om den genererade applikationen erbjuder generativa AI-tjänster externt eller innehåller algoritmrekommendations- eller djup syntes-funktioner, gäller motsvarande bestämmelser.

[^4]: Den allmänna ramen för ändringshantering följer ITIL 4 Change Enablement; inom finanssektorn är de senaste referenserna Föreskrifter om tillsyn över outsourcing av IT inom bank- och försäkringsinstitut (CBIRC [2021] nr 46) samt relevanta cirkulär från National Financial Regulatory Administration från 2024; för försäkringsbranschen tillkommer Vägledning för hantering av informatisering inom försäkringsinstitut (CIRC [2009] nr 17, reviderad 2024).

[^5]: Transaktionsregister: den faktiska källan är artikel 31 i den kinesiska e-handelslagen (plattformar måste registrera och lagra transaktionsdata i ≥ 3 år) plus artikel 26 i förordningen om övervakning av internethandel (som specificerar 3 år). För granskningsloggar: den kinesiska klass-2.0-standarden för informationssäkerhetsprotection (Dengbao, Kinas motsvarighet till ISO 27001) kräver att nätverksloggar bevaras i ≥ 6 månader (i enlighet med artikel 21 i den kinesiska cybersäkerhetslagen), men för kritiska system inom finanssektorn gäller vanligtvis ≥ 5 år enligt artikel 19 i bankväsendets datagovernance-riktlinjer och de allmänna riktlinjerna för internkontroll i kommersiella banker — 6 månader är bara ett golv, inte ett rekommenderat värde.