Varför betalar vi för mjukvara som AI kan bygga gratis?

Er ekonomichef har sett demonstrationerna. Microsofts Copilot som skapar finansiella dashboards i Excel utan att någon skriver en formel. Anthropics Claude Cowork som frågar “Let’s knock something off your list” och sedan sorterar filer, bygger kalkylark från kvitton, eller skriver rapporter medan ni gör annat. Någon på LinkedIn som byggde ett CRM på en eftermiddag (se ordlista: vibe coding). Det ser ut som att all programvara ni betalar för kan ersättas av AI, gratis, på en eftermiddag.

Bild: Anthropics Claude Cowork (claude.com/product/cowork). Det här är vad era anställda ser när de öppnar verktyget.

Bild: Microsofts Copilot Agent Mode i Excel (microsoft.com/microsoft-365-copilot). AI:n bygger en komplett finansiell rapport med diagram och analys.

Marknaden drog sin egen slutsats. I januari 2026 missade Microsoft sina förväntningar på Azure-tillväxt, samtidigt som investerarna prisat in att AI-investeringarna redan betalade sig.¹ Samma vecka visade Anthropic att deras AI kunde koppla direkt mot Salesforce, HubSpot, Jira, Slack och Excel.² Ungefär 285 miljarder dollar försvann ur mjukvarubörsen på några veckor. Wall Street döpte det till “SaaSpocalypse”.³

Paniken handlade inte om att AI ersätter verktygen. Den handlade om pengar. Om AI-agenter gör jobbet som idag kräver mänskliga användare behöver företag färre licenser. Om AI blir gränssnittet mot systemen spelar det mindre roll vems system det är under huven. Och budgetarna som går till AI-kapacitet tas någonstans ifrån. Mjukvarulicenser är ett uppenbart ställe att skära.⁴ Verktygen försvinner inte, men pengaflödet krymper.

Någon i er ledningsgrupp har sett samma demos. Frågan har ställts, eller kommer att ställas: varför betalar vi tiotusentals kronor per år för program när AI kan göra dem gratis?

Det korta svaret: skälen att betala för mjukvara har aldrig handlat om att bygga version 1 är svårt. Det har handlat om totalkostnad, riskhantering och styrning. Det gällde före AI. Det gäller med AI. Den enda skillnaden är att AI gör version 1 billigare, vilket gör det lättare att glömma allt som kommer efter.

För vissa program stämmer det att bygga (med AI) är rätt val. För andra är det en feltänkt kalkyl. Och sedan finns det en tredje fråga som de flesta missar helt.

När bygga faktiskt är rätt svar

AI kan bygga fungerande program snabbt. Det är inte hype.

Gergely Orosz, redaktör för ett av teknikvärldens mest lästa nyhetsbrev, ersatte ett verktyg han betalat 1 200 kronor om året för. Det tog 20 minuter.⁵ Det fungerade. Ett teknikföretag (med många egna utvecklare) i Australien byggde ett eget CRM-liknande system på tio dagar med AI och det sparade dem tiotusentals kronor i månaden.⁶

För enkla, fristående verktyg utan känslig data och utan compliance-krav kan det vara rätt beslut att bygga. En intern rapport som annars körs manuellt. En kalkyl som lever i Excel och ingen äger. Här är kostnaden för att bygga lägre än kostnaden för att köpa, och komplexiteten tillräckligt låg för att hantera utan ett dedikerat teknikteam. Här är det som att ge enskilda medarbetare eller team superkrafter.

När kalkylen ser bättre ut än den är

Problemet är att det ser likadant ut i alla demos oavsett vad som faktiskt byggs.

En grundare som dokumenterade sju månaders AI-assisterad programutveckling beskriver det:

“Pure AI coding gets you maybe 60% there.”⁷

De 40 procenten som återstår är databasproblem som dyker upp med fler användare, säkerhetsluckor som inte syns förrän de utnyttjas, och integrationer som slutar fungera när ett externt API ändras (se ordlista: API).

Tidig forskning pekar åt samma håll. En granskning av sju AI-byggda prototyper fann 970 säkerhetsproblem (se ordlista: säkerhetsluckor), varav 801 allvarliga.⁸ Veracode fann att nära hälften av all AI-genererad kod innehöll sårbarheter.⁹

Forskarna rekommenderar att behandla AI-genererad kod som ett första utkast som måste granskas av kunniga personer innan det körs i produktion.¹⁰

Det är råd till programmerare. Men den som bygger är inte alltid en programmerare.

Problemet är inte kostnaden för ett system. Det är vad som händer när ni har fem, eller 50.

Varje AI-byggt verktyg som når produktion behöver någon som förstår det, felsöker det, och uppdaterar det när en integration ändras. Det är inte ett heltidsjobb för ett verktyg. Men för fem stycken börjar det likna det.

Och den personen är troligtvis samma person som byggde allt. En junior systemutvecklare kostar ungefär 750 000 kronor om året.¹¹ Men kostnaden är inte det värsta. Det värsta är att när tre saker går sönder samtidigt, och det gör de, hittar den personen snabbt ett nytt jobb.

Anish Acharya på riskkapitalfirman Andreessen Horowitz skriver om det: “Software value compounds; content value decays.”¹² Det är en bra formulering av varför ett etablerat system är svårt att kopiera.

Den fråga ni inte ställde

Här är det som de flesta CFO:er inte tänker på när de ser demon.

En branschundersökning från en ledande no-code-leverantör, med tydlig bias i resultaten, frågade hundratals programmerare och verksamhetsutvecklare om deras AI-vanor i början av 2026. 60 procent av de som byggt något med AI hade gjort det utanför IT-avdelningens kontroll.¹³ 35 procent av organisationerna hade redan ersatt minst ett köpt program med ett eget bygge.

Det är inte praktikanter som experimenterar. 64 procent av de som byggt utanför officiella kanaler var chefer eller högre. De gick runt IT för att det gick snabbare (31 procent), för att befintliga program inte räckte till (25 procent), för att IT-processen var för långsam (18 procent), för att verktygen inte integrerade med varandra (10 procent), eller för att IT saknade kapacitet (10 procent).

Frågan er CFO ställer är “ska vi bygga istället för att köpa?” Den frågan förutsätter att ni kontrollerar vad som byggs. Det gör ni kanske inte. Någon på ekonomiavdelningen kanske redan byggt något med kunddata som ingen annan vet om. Det kallas shadow IT (se ordlista). Det är inte nytt. Det är bara mycket lättare att skapa nu. Vi har skrivit en fördjupning om hur det ser ut i praktiken: Shadow AI: chefer bygger egna verktyg utan IT:s vetskap.

Sex månader efter att verktyget byggts finns det i produktion, kopplat mot riktiga system, med kunddata, och utan att någon på IT vet om det. Personen som byggde det har kanske slutat. IT kan inte stoppa program de inte känner till.

Och så är det säkerheten

Det finns fler problem än att IT inte vet vad som körs.

Exfiltrering - hur enkelt AI hackas att läcka data

Säkerhetsforskare visade i januari 2026 att Claude Cowork kunde luras att skicka alla filer i en mapp till en angripare utan att användaren märkte något.¹⁴ Anthropics egna hjälpsidor avrår från att ge Cowork tillgång till känsliga filer.¹⁵ Deras säkerhetsdokumentation säger rakt ut att verktyget inte passar för reglerade branscher.¹⁶

Privata konton vs företagskonton

Er anställde med en privat $20-prenumeration har inget avtal mellan er organisation och Anthropic. Inget dataskyddsavtal, ingen kontroll.

Med ett privat konto tränar Anthropic sina modeller på det den anställde skriver, om inte användaren själv stänger av det.¹⁷ Data lagras i USA. Överföringen sker via standardavtalsklausuler, inte via EU-US Data Privacy Framework som Anthropic inte är certifierade under.¹⁸ Företagskonton har biträdesavtal. Privata konton har ingenting.

GDPR är fortfarande en lag

Er organisation är sannolikt fortfarande personuppgiftsansvarig för den kunddata som passerar genom sessionen. Det är er data, era register, era kunder. Men ni har inget biträdesavtal med den som behandlar den.¹⁹ Ni kan inte granska. Ni kan inte stoppa vidaredelning. Och datan tränar modellen om ingen stängt av det. Språkmodeller kan repetera träningsdata ordagrant. Era affärshemligheter, kunduppgifter eller strategiska dokument kan dyka upp i svar som modellen ger till vem som helst på planeten som ställer rätt fråga.

ISO 42001 - ledningssystem för AI

ISO 42001 är en internationell standard för ledningssystem för AI, publicerad 2023. Den finns till exakt för det här scenariot: för att ge organisationen kontroll över vad som används, av vem, med vilka data, och vem som ansvarar om något går fel.

Standardens kontroller träffar shadow AI direkt:²⁰

• En dokumenterad policy för hur AI-system får användas (A.2.2)
• Definierade roller: vem äger frågan när något går fel (A.3.2)
• Konsekvensbedömning: vem påverkas om verktyget behandlar kunddata och det uppstår ett fel (A.5.2)
• Godkännandeprocesser för ansvarsfull användning (A.9.2)
• Leverantörsbedömning, för OpenAI och Anthropic är era leverantörer när era anställda använder deras verktyg med er data (A.10.3)

Det är samma logik som ISO 9001 för kvalitet eller ISO 27001 för informationssäkerhet. Inte byråkrati för byråkratins skull.

EU AI Act gäller redan

Det juridiska skälet är större än de flesta tror.

EU:s AI-förordning, artikel 4, kräver att alla organisationer som använder AI-system ser till att berörd personal har tillräcklig AI-kompetens. Det gäller sedan 2 februari 2025. Men artikel 4 är bara den första bestämmelsen. Den 2 augusti 2026 börjar resten gälla.²¹

Ta ett konkret scenario. En rekryteringsansvarig ber ChatGPT jämföra två kandidaters CV:er och ge en rekommendation. Det ser oskyldigt ut. Det tar trettio sekunder.

Förordningens bilaga III, punkt 4a listar det som högrisk: “AI systems intended to be used for the recruitment or selection of natural persons, in particular to … evaluate candidates.” Det spelar ingen roll att det inte är ett dedikerat rekryteringsverktyg. Det spelar ingen roll att det var en engångsföreteelse. Förordningen ser på användningsområdet, inte på etiketten.

Artikel 25(1)(c) gör det värre. Tar ni ett generellt AI-system som ChatGPT och ändrar dess användningsområde så att det blir högrisk, blir er organisation leverantör i förordningens mening. Inte användare. Leverantör. Med det följer teknisk dokumentation, kvalitetsledning, CE-märkning och conformity assessment.

En anställds agerande på trettio sekunder kan rimligtvis göra er till leverantör av ett högrisk-AI-system med alla skyldigheter det innebär. Artikel 26 kräver mänsklig tillsyn, att ni informerar berörda anställda, och konsekvensbedömning enligt GDPR. Samma krav gäller om någon vibe-codar ett verktyg som poängsätter kunder för kreditvärdighet eller automatiserar vilka ärenden som ska eskaleras. Bilaga III listar alla områdena: anställning, kreditbedömning, tillgång till samhällstjänster.

Och om en anställd publicerar AI-genererad text externt utan att redovisa att den är AI-genererad? Artikel 50 kräver transparens för AI-genererad text som publiceras i allmänhetens intresse, om inte en människa har granskat och tagit redaktionellt ansvar. Shadow IT gör den granskningen omöjlig.

Böterna följer samma skala som GDPR: upp till 15 miljoner euro eller 3 procent av global omsättning för brott mot leverantörs- och användarskyldigheter. För SME-företag gäller det lägre av belopp eller procent.

ISO 42001 är frivillig, EU AI Act är bindande. Inte samma sak. Men ISO 42001 täcker varje skyldighet som just listades: konsekvensbedömning (A.5.2) mappar mot artikel 26, avsedd användning (A.9.4) mot instruktionskraven, information till användare (A.8.2) mot transparenskraven i artikel 50.

Standarden ger er ett strukturerat sätt att möta regler som börjar gälla om sex månader.

Ska ni bygga eget med AI eller köpa? Det beror på vad det är. Men börja med att ta reda på vad folk redan har byggt utan att ni vet om det. Det är den frågan som borde hålla er CFO vaken.

Om ni vill se hur AmpliFlow hanterar det i ett ledningssystem: boka en genomgång.

---

Ordlista

Vibe coding: Att beskriva vad man vill ha i vanlig text till ett AI-verktyg, som sedan skriver koden. Ingen programmeringskunskap krävs för att komma igång, men det räcker inte för att hålla igång det som byggs.

API (Application Programming Interface): Det som låter två program prata med varandra. När ert bokföringsprogram hämtar betalningar från er bank gör det det via ett API. Om API:et ändras och ingen uppdaterar koden slutar det fungera.

Shadow IT: Program eller verktyg som används inom ett företag utan att IT-avdelningen vet om det eller har godkänt det. Problemet är gammalt. Vad som är nytt är hur lite ansträngning det kräver att skapa sådana verktyg idag.

Säkerhetsluckor: Svagheter i koden som gör det möjligt för utomstående att komma åt data de inte ska ha tillgång till. Uppstår ofta utan att den som byggt verktyget vet om det, och syns inte förrän de utnyttjas.

ISO 42001: En internationell standard för hur företag ska styra och kontrollera sin användning av AI. Publicerad av ISO 2023. Ger ett ramverk för vem som ansvarar för vad när AI används i verksamheten.

---

Den här artikeln skrevs i februari 2026, mitt i ett av de snabbaste teknologiskiftena på länge. Mycket av det vi skriver om här kan se annorlunda ut om ett år. Vi är nyfikna på hur det håller.

Footnotes

1. Dave Vellante, “Microsoft investors fret as capital spending and Azure growth decouple”, SiliconAngle, 1 februari 2026. Azure-tillväxten nådde inte analytikernas förväntningar, marknaden ifrågasatte om AI-investeringarna ger avkastning tillräckligt snabbt. Källa. ↩

2. Anthropic, “Cowork plugins”, 30 januari 2026. Elva plugins publicerade som öppen källkod. Källa. Källkod: GitHub. ↩

3. Jonathan Barrett, “Is the share market headed toward a ‘SaaS-pocalypse’?”, The Guardian, 20 februari 2026. Termen “SaaSpocalypse” myntades av analytiker på investmentbanken Jefferies. Källa. ↩

4. John Furrier, “The SaaSpocalypse mispricing: Why markets are getting the AI-software shakeout wrong”, SiliconAngle, 10 februari 2026. Thomson Reuters -16%, RELX -13%, LegalZoom -20% på plugindagen. Källa. ↩

5. Gergely Orosz, “I replaced a $120/year micro-SaaS in 20 minutes with LLM-generated code”, The Pragmatic Engineer, 2026. Källa. ↩

6. Hypergen, “SaaS: The Build vs Buy Equation Just Changed”, 2025. Källa. ↩

7. Reddit, r/EntrepreneurRideAlong, “7 months of vibe coding a SaaS and here’s what I learned”, 2025. Källa. ↩

8. M Waseem, A Ahmad, KK Kemell, J Rasku, “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use”, arXiv:2512.11922 (preprint, inlämnad till IEEE Software), december 2025. Säkerhetssiffrorna baseras på scanning av 7 egna MVPs, illustrativt urval. Källa. ↩

9. Veracode, citerat i Waseem et al. arXiv:2512.11922. Originalrapporten: Veracode State of Software Security Report. ↩

10. M Waseem et al., arXiv:2512.11922. Verbatim: “Based on our experience, we recommend treating AI-generated code as a first draft that must pass strict automated gates such as linting, type checks, and tests before merging.” Erfarenhetsbaserad rekommendation, inte ett mätresultat. ↩

11. Unionen marknadslöner 2024, systemutvecklare, ingångslön 36 000–45 000 kr/mån. Källa. Totalkostnad 750 000 kr/år: Unionens lönesiffra plus arbetsgivaravgifter (31,42%) plus uppskattade kringkostnader (semester, pension, utrustning). Beräkning baserad på Unionens publicerade data. ↩

12. Anish Acharya, “Software’s YouTube moment is happening now”, Andreessen Horowitz, 2026. Källa. ↩

13. Retool, “The build vs. buy shift: how vibe coding and shadow IT have reshaped enterprise software”, februari 2026. Undersökning med 817 respondenter, Retool-kunder och builders, sampelbias mot de som redan bygger egna system. Källa. ↩

14. Prompt Armor, “Claude Cowork Exfiltrates Files”, 14 januari 2026. Källa. Se även: Simon Willison, simonwillison.net/2026/Jan/14/claude-cowork-exfiltrates-files/. ↩

15. Anthropic, “Use Cowork safely”, Claude Help Center (2026). Verbatim: “Avoid granting access to local files with sensitive information, like financial documents.” Källa. ↩

16. Anthropic, “Use Cowork safely”, Claude Help Center (2026). Verbatim: “Cowork activity is not captured in audit logs, Compliance API, or data exports. Do not use Cowork for regulated workloads.” Källa. Se även: Using Agents According to Our Usage Policy. ↩

17. Anthropic, Privacy Policy (gäller från 12 januari 2026), §2: konsumentkonton (Free/Pro) används för modellträning som standard. Användare kan stänga av det i kontoinställningarna. Företagskonton (API, Team, Enterprise) tränas aldrig på kunddata per Commercial Terms §B. Källa. ↩

18. Anthropic, Data Processing Addendum (gäller från 24 februari 2025). SOC 2 Type II, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, CSA STAR. Årlig oberoende säkerhetsrevision (DPA Schedule 2, §D.2). Årlig penetrationstest av externa assessorer (DPA Schedule 2, §G.2). Granskningsrätt för kunder med DPA (DPA §F). Källa. Certifieringar listade på claude.com/regional-compliance. ↩

19. Europaparlamentets och rådets förordning (EU) 2016/679 (GDPR), artikel 28: behandling av ett biträde ska regleras av ett avtal eller en annan rättsakt. Utan ett sådant avtal saknas den rättsliga grunden för att en tredje part behandlar personuppgifter på den personuppgiftsansvariges vägnar. ↩

20. ISO/IEC 42001:2023, Annex A (normative), kontroller A.2.2 (AI policy), A.3.2 (roller och ansvar), A.5.2 (konsekvensbedömning), A.8.2 (information till användare), A.9.2 (ansvarsfull användning), A.9.4 (avsedd användning) och A.10.3 (leverantörer). ↩

21. Europaparlamentets och rådets förordning (EU) 2024/1689 om artificiell intelligens (EU AI Act). Artiklar som citeras i texten: 4 (AI-kompetens, gäller sedan 2 feb 2025), 25(1)(c) (ändrad användning gör dig till leverantör), 26 (skyldigheter vid högrisk: mänsklig tillsyn, informera anställda, DPIA), 50(4) (transparens för AI-genererad text), 99(4)(6) (böter upp till 15M EUR / 3% av omsättning, lägre för SME). Bilaga III listar högriskområden: anställning, kreditbedömning, samhällstjänster. Artiklarna 25, 26, 50 gäller från 2 aug 2026. Fulltext, OJ L 2024/1689. ↩