# Eteya — Fullständig Innehåll ## Hemsida **Titel:** Eteya — AI som driver ditt företag **Tagline:** Mindre manuellt. Mer tillväxt. **Beskrivning:** Vi bygger AI-automation som faktiskt levererar resultat — inte bara låter bra på möten. ### Vårt Erbjudande **AI Automation:** - AI-agenter som hanterar kundservice, order och support - Processautomation som eliminerar manuellt arbete - Custom AI-lösningar skräddarsydda för er verksamhet **Resultat vi levererar:** - 70-90% mindre manuellt arbete - 24/7 drift utan extra personal - Skalbarhet utan att anställa ### Case Studies **Telestore (E-handel):** - Automatiserad orderhantering, kundkommunikation och lagerflöden - Resultat: 85% mindre manuellt arbete **Nordicrank (Operations & Automation):** - 18 automatiserade flöden ersatte manuella Excel-listor: orderintag, status-tracking, QA, fakturor och rapporter - Resultat: 13,4 timmar/vecka tillbaka, ~99% färre felinmatningar **Sannegården (Restaurang):** - Inventory- och COGS-system för marginal per pizza i realtid + automatiska påfyllningsförslag varje söndag - Resultat: −32% matsvinn, +9 kr marginal per pizza, 6 h/vecka sparat på inventering **SKG Stockholm (Storköksgrossist):** - Personlig AI-assistent för VD:n — mail, kalender, uppföljningar - Resultat: 12 timmar/vecka befriade, 85% av mail hanterade automatiskt **TrainWithAlbert (Fitness):** - AI-personal trainer och medlemskommunikation - Resultat: 3x fler medlemmar hanterade per anställd ### Vanliga Frågor **Hur lång tid tar det att implementera en AI-lösning?** De flesta projekt går live inom 2–6 veckor. Vi börjar med en kort kartläggning för att förstå era behov och bygger sedan iterativt. Ni ser framsteg redan efter första veckan. **Behöver vi teknisk kunskap internt?** Nej. Vi hanterar hela den tekniska implementationen. Det enda vi behöver från er är kunskap om er verksamhet och tillgång till de system som ska integreras. **Vad kostar en AI-agent eller automation?** Varje projekt är unikt och priset beror på komplexitet och omfattning. Vi ger alltid en fast offert efter kartläggningen så att ni vet exakt vad det kostar innan vi börjar. **Hur hanterar ni vår data och GDPR?** Hanterar systemet personuppgifter skriver vi avtalet som lagen kräver, innan vi börjar. Era uppgifter används bara i ert system och aldrig för att träna AI-modeller. Vi säger också vilken AI-modell som används och i vilket land den körs. **Vilka verktyg och plattformar jobbar ni med?** Vi är verktygsoberoende och väljer det som passar bäst. Vanliga verktyg inkluderar OpenAI, Anthropic, Make, n8n samt custom-byggen med Python, TypeScript och moderna AI-ramverk. **Hur vet vi om AI passar vår verksamhet?** Om ni har repetitiva processer, hanterar stora volymer data eller vill skala utan att anställa finns det troligen en AI-lösning som sparar tid och pengar. Boka ett kostnadsfritt samtal så gör vi en snabb bedömning. **Erbjuder ni support efter leverans?** Ja. Varje projekt inkluderar dokumentation och överlämning. Vi erbjuder även löpande support, optimering och vidareutveckling så att lösningen växer med er verksamhet. --- ## Om Oss **Rubrik:** Människorna bakom Eteya ### Filip Thai — Grundare och CEO Startade Eteya för att bevisa att AI faktiskt levererar, inte bara låter bra på möten. ### Agit Akalp — Rådgivare Grundare av Telestore. Efter över 10 år som entreprenör vet han vad som funkar i verkligheten och vad som bara är Powerpoint. --- ## Blogg / Insikter (svenska) ### Automatisera kvartalsrapporten utan manuellt arbete **URL:** https://eteya.ai/sv/blogg/ai-automation/automatisera-kvartalsrapport **Sammanfattning:** Ditt företag är troligen inte skyldigt att lämna kvartalsrapport. Så bygger du ändå en som gör sig själv, och så vet du var automatiseringen tar slut. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' De flesta som sätter sig med kvartalssiffrorna tror att de gör något lagen kräver. Det gör de oftast inte. Ett onoterat svenskt aktiebolag har ingen skyldighet att lämna kvartalsrapport, och sedan 2016 har inte ens börsbolagen den skyldigheten. Ändå sitter tusentals företagare tre gånger om året och bygger ihop samma sammanställning för hand. Den här guiden visar vad som faktiskt krävs, vad som går att automatisera, och exakt var automatiseringen tar slut. Att automatisera kvartalsrapporten börjar därför inte i tekniken. Ordningen spelar roll: först skyldigheterna, eftersom de styr vilka datum du är låst vid. Sedan bygget. Sist gränserna, för det finns saker i ett svenskt ekonomiflöde som ingen maskin får göra åt dig. ## Måste svenska företag lämna kvartalsrapport? Nej. Ett onoterat aktiebolag ska upprätta årsredovisning, inget mer. Skyldigheten att lämna delårsrapport finns i [årsredovisningslagen](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/arsredovisningslag-19951554_sfs-1995-1554/) men träffar i praktiken bara finansiella koncerner som kreditinstitut, värdepappersbolag och försäkringsföretag. Enskilda firmor omfattas inte alls, och för de allra flesta svenska företag finns alltså ingen kvartalsrapport att lämna in någonstans. Det kontraintuitiva är att inte heller noterade bolag måste kvartalsrapportera längre. Kravet på delårsrapport för första och tredje kvartalet togs bort genom [proposition 2015/16:26](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/proposition/regelbunden-finansiell-information-och_h30326/html/), som följd av ändringar i EU:s öppenhetsdirektiv. Nasdaq Stockholm avskaffade därefter sitt eget krav, med motiveringen att minska administrativ börda och uppmuntra långsiktighet. Kvar i lagen finns årsredovisning och halvårsrapport. Trots det påstår flera svenska sidor fortfarande motsatsen, däribland svenska Wikipedias artikel om kvartalsrapport. Kontrollera alltid mot [Bokföringsnämndens sammanställning av vad som gäller för aktiebolag](https://www.bfn.se/redovisningsregler/vad-galler-for/aktiebolag/) innan någon säger till er att ni är skyldiga till något. Att skyldigheten saknas gör inte rapporten meningslös. Den gör den frivillig, och en frivillig rapport ska förtjäna sin tid. ## Vad tvingar ändå fram en kvartalsrytm? Skatteverkets deklarationsdatum. Momsen och arbetsgivardeklarationen ska in med fast frekvens oavsett vad ni tycker, och de kräver att bokföringen är i ordning på bestämda dagar. Rytmen finns alltså redan i verksamheten. Kvartalsrapporten är bara ett sätt att ta betalt för det arbete ni ändå gör. ### Momsen bestämmer takten Vilken period ni redovisar moms på styrs av omsättningen. [Skatteverkets regler för redovisningsperioder](https://www.skatteverket.se/foretag/moms/deklareramoms/narskajagdeklareramoms.4.6d02084411db6e252fe80008988.html) sätter tre nivåer: | Beskattningsunderlag | Period | Får ni välja? | |---|---|---| | Högst 1 miljon kr | Beskattningsår | Ja, månad eller kvartal går att välja | | Högst 40 miljoner kr | Kalenderkvartal | Ja, månad går att välja | | Över 40 miljoner kr | Kalendermånad | Nej | Ligger ni i mellanskiktet redovisar ni alltså moms kvartalsvis som huvudregel. Deklarationen ska vara inne senast den 12:e i den andra månaden efter perioden, med undantag för augusti då datumet är den 17:e. Infaller dagen på en helg flyttas den till nästa vardag. ### Arbetsgivardeklarationen kommer varje månad Har ni anställda gäller en annan takt. Arbetsgivaravgifter och avdragen skatt ska [deklareras månaden efter](https://www.skatteverket.se/foretag/arbetsgivare/lamnaarbetsgivardeklaration/narskajaglamnaarbetsgivardeklaration.4.361dc8c15312eff6fd13c11.html), varje månad, även när det inte finns något att redovisa. Då lämnar ni en nolldeklaration. Det betyder att lönedelen av bokföringen måste vara stängd tolv gånger om året medan momsdelen kanske bara stängs fyra. Ett automatiserat flöde måste hantera båda takterna, inte bara den ni råkar tänka på. ## Vad ska rapporten innehålla för att vara värd att göra? Det beror på vem som läser den. En bank vill se likviditet och skuldsättning. En styrelse vill se avvikelser mot plan. Ni själva vill oftast veta om marginalen håller och om pengarna räcker. En rapport som försöker svara alla tre blir för lång och läses av ingen. Börja med mottagaren och räkna baklänges. I praktiken landar de flesta småföretag på fyra block: resultatet för perioden med jämförelse mot samma kvartal i fjol, likviditeten just nu, de största avvikelserna med en förklaring i klartext, och en framåtblick. Det fjärde blocket är det som brukar saknas, och det är det enda som faktiskt påverkar beslut. En sammanställning av vad som redan hänt är historia. En prognos är ett underlag. ## Vad måste vara klart innan kvartalet kan stängas? Avstämningen. Innan siffrorna kan sammanställas måste bokföringen stämma mot verkligheten: banken mot bokfört saldo, utbetalningar mot ordrar, kundfordringar mot vad som faktiskt betalats. Automatiseras inte det steget spelar det ingen roll hur snygg rapporten blir, för den bygger på siffror ingen kontrollerat. Det är ett eget arbete med egen metod, och vi har skrivit om det separat. Säljer ni via flera kanaler går [hur du matchar ordrar mot utbetalningar](/sv/blogg/ai-automation/automatisera-avstamning-e-handel-ai) igenom protokollet steg för steg. Är ordrarna utspridda mellan system börjar det ännu tidigare, med [att samla orderflödet på ett ställe](/sv/blogg/ai-automation/automatisera-orderhantering-e-handel-ai). Frekvensen är viktigare än många tror. Rekommendationen från redovisningshåll är löpande avstämning enligt fasta rutiner, alltså månadsvis eller tätare. Sparar ni ihop tre månaders avvikelser till kvartalsskiftet får ni en hög att gräva i just den vecka ni har som minst tid. Automatiserad avstämning varje månad gör kvartalsstängningen till en sammanställning i stället för en utredning. Är AI-agenter nytt för er ger [vår genomgång av AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb) grunden innan ni går vidare här. ## Vilka uppgifter måste finnas på varje verifikation? Sju stycken, enligt [bokföringslagen 5 kap. 7 §](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/bokforingslag-19991078_sfs-1999-1078/). Det är den enskilt viktigaste listan i hela automatiseringsarbetet, eftersom varje punkt motsvarar ett fält som en maskinell avläsning måste få rätt för att underlaget ska hålla juridiskt. Lagen kräver att verifikationen innehåller: 1. När verifikationen sammanställdes 2. När affärshändelsen inträffade 3. Vad affärshändelsen avser 4. Vilket belopp den gäller 5. Vilken motpart den berör 6. Verifikationsnummer eller annat identifieringstecken 7. Övriga uppgifter som behövs för att sambandet mellan verifikationen och den bokförda affärshändelsen ska kunna fastställas utan svårighet De sex första klarar en modern dokumentavläsning bra. Datum, belopp, leverantör och fakturanummer läses av med hög träffsäkerhet ur en vanlig PDF. Punkt sju är den som fallerar. Sambandet mellan underlaget och den bokförda posten är inte något som står i dokumentet, utan något systemet måste skapa och spara. Ett kvitto som ligger i en mapp utan koppling till verifikationen uppfyller inte kravet, hur välläst det än är. Det är därför kopplingen tillbaka till bokföringen, inte avläsningen, är den svåra delen att bygga. ### Underlagen ska också finnas kvar Räkenskapsinformation ska bevaras till och med det sjunde året efter utgången av det kalenderår då räkenskapsåret avslutades. [Bokföringsnämnden](https://www.bfn.se/fragor-och-svar/arkivering/) är tydlig med att elektronisk form är fullt likställd med papper, och att företaget får välja form när underlaget kommer in i båda formerna i nära anslutning. Skannas pappret först långt senare räknas det som en överföring med striktare krav. En regeländring som få känner till gör det här enklare än förr. Genom [SFS 2024:342](https://svenskforfattningssamling.se/sites/default/files/sfs/2024-05/SFS2024-342.pdf), i kraft den 1 juli 2024, togs kravet bort på att spara originalet till och med fjärde året. Ett företag får nu förstöra pappershandlingen så snart informationen förts över, förutsatt att överföringen inte innebär risk för att något ändras eller försvinner. Det var den regeln som tidigare tvingade fram pärmar bredvid det digitala arkivet. Praktiskt betyder det att ett automatiserat flöde måste veta var underlaget hamnar och kunna visa det om sju år, inte bara läsa det i dag. ## Hur automatiserar du sammanställningen? Genom att hämta bokföringsdata direkt via bokföringsprogrammets API i stället för att exportera filer för hand. Både [Fortnox](https://apps.fortnox.se/apidocs) och [Visma](https://developer.vismaonline.com/docs/lets-get-started) har öppna gränssnitt för verifikationer, konton, räkenskapsår, kund- och leverantörsfakturor. Rapporten byggs sedan av kod, inte av kopierade celler. Tekniskt består det i att automatisera kvartalsrapporten av tre lager, och de flesta behöver inte fler. **Hämtning.** Ett schemalagt jobb som läser perioden ur bokföringen och sparar en normaliserad kopia. Räkna med begränsningar: Fortnox tillåter [300 anrop per minut per klient](https://www.fortnox.se/developer/guides-and-good-to-know/rate-limits-for-fortnox-api) med ett glidande fönster på fem sekunder, och svarar med felkod 429 när taket nås. Ett bygge som hämtar detaljer för hundratals verifikationer måste alltså köa och göra om försök, inte skjuta iväg allt på en gång. **Beräkning.** Nyckeltalen räknas fram deterministiskt ur kontoplanen, inte av en språkmodell. Omsättning, bruttomarginal, rörelseresultat och likviditet är summeringar över kontointervall. Handlar ni i utländsk valuta hämtas kurserna från [Riksbankens öppna API](https://www.riksbank.se/sv/statistik/rantor-och-valutakurser/hamta-rantor-och-valutakurser-via-api/) i stället för att slås upp för hand. **Presentation.** Här är språkmodellen på sin rätta plats: att förklara i klartext varför en post avviker mot förra kvartalet, och att skriva ihop sammanfattningen. Siffran kommer från koden. Formuleringen kommer från modellen. ## Var tar automatiseringen slut? Vid inlämningen. Momsdeklarationen kan förberedas maskinellt men inte skickas in utan en människa. Skatteverkets egen dokumentation för [inlämning via fil](https://skatteverket.se/foretag/moms/deklareramoms/skapaochskickainmomsdeklarationviafil.4.2fb39afe18dabf1e4d223cc.html) säger att kontaktuppgifter inte kan skickas med filen utan måste fyllas i manuellt, och att den som lämnar in måste identifiera sig med e-legitimation. Samma sak i bokföringsprogrammen. Vill ni skicka momsdeklarationen direkt från Fortnox krävs [en ombudsbehörighet hos Skatteverket](https://support.fortnox.se/produkthjalp/bokforing/skapa-momsrapport-fran-bokforing) som heter Momsdeklaration, ombud, och deklarationen går ändå iväg som ett utkast som signeras med e-legitimation. Det här är ingen brist i tekniken. Det är designat så, eftersom ansvaret ligger på företaget. En automatiserad kedja som lovar att sköta hela vägen fram till Skatteverket utan mänsklig signering beskriver antingen något annat än vad ni tror, eller något ni inte vill ha. Den praktiska konsekvensen: bygg för att korta arbetet fram till godkännandet, inte för att ta bort godkännandet. Rör systemet företagsdata är det också värt att läsa [vad GDPR kräver när AI hanterar era uppgifter](/sv/blogg/ai-agenter/ai-och-gdpr-sakerhet) innan ni kopplar ihop källorna. ## Hur bygger du en kassaprognos som uppdaterar sig själv? Genom att kombinera tre kända storheter: verkligt saldo i dag, kundfordringar med förfallodatum, och leverantörsskulder med betaldatum. Läggs återkommande poster som löner, hyra och skatter ovanpå får ni en rullande prognos utan att någon gissar. De flesta bygger tolv eller tretton veckor framåt. Två saker avgör om prognosen blir användbar eller vilseledande. Den första är att hålla isär bokfört och verkligt saldo. Bokföringen visar vad som är registrerat, banken visar vad som faktiskt finns. Skillnaden mellan dem är inte ett fel utan information, och ett system som slår ihop dem döljer just det ni behöver se. Den andra är att märka varje siffra med sin status. Bokfört, preliminärt eller prognos. En prognossiffra som ser ut som en bokförd siffra är farligare än ingen prognos alls, eftersom den inbjuder till beslut den inte bär. ## Vad lärde vi oss av att bygga det på riktigt? Att den svåra delen aldrig är avläsningen. I ett bygge åt en e-handlare läser systemet inkommande leverantörsfakturor ur mejlen, tolkar dem och kopplar dem mot rätt post i bokföringen. Modellen som läser dokumentet var klar på några dagar. Reglerna för när kopplingen får ske automatiskt tog flera gånger så lång tid att få rätt. ### Spärrar slår alltid tillstånd Automatisk koppling sker bara när flera villkor är uppfyllda samtidigt: hög säkerhet i matchningen, beloppsavvikelse under en krona, datum inom ett bestämt fönster, och avsändare på en godkänd lista. Brister ett enda villkor hamnar posten i en kö för mänsklig granskning i stället. Kontrollen mot dubbelkoppling är byggd så att den vid fel svarar att posten redan är kopplad, alltså det försiktiga svaret. Ett system som gissar åt fel håll skapar mer arbete än det sparar. ### Alla poster behöver inte underlag Den insikt som fick störst effekt var att sluta jaga allt. Långt ifrån varje verifikation kräver ett underlag att leta efter. Löneutbetalningar, avskrivningar, skatteöverföringar och interna omföringar skapar sina egna underlag eller har dem redan. Genom att läsa verifikationsraderna och avgöra utifrån vilka konton som berörs, i stället för att titta på texten, försvann större delen av det som först såg ut som saknade underlag. Kvar blev de poster som faktiskt behövde en människa. ### Systemet blir bättre av korrigeringarna När en människa bekräftar en koppling som maskinen var osäker på sparas sambandet mellan kontoutdragets kryptiska text och den verkliga leverantören. Efter två bekräftelser börjar det påverka framtida matchningar. Det kräver ingen omträning av någon modell, bara att man tar vara på besluten som ändå fattas. I vårt eget interna ekonomisystem gäller samma princip hela vägen: det hämtar, jämför och sammanställer, men bokför ingenting och skickar ingenting. Varje siffra bär en hänvisning tillbaka till sin källa. Det är den enda formen av automatisering som håller när någon frågar var en siffra kommer ifrån. ## Vad kostar det, och när lönar det sig inte? Ett avgränsat system som automatiserar rapportsammanställningen kostar från 45 000 kr i implementation, och drift ligger mellan 5 000 och 15 000 kr i månaden utan bindningstid. Ska flera system kopplas ihop till ett gemensamt flöde landar det i spannet 90 000 till 180 000 kr. Vad ett bygge kostar i detalj finns i [kostnadsguiden för AI-agenter](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). Räkna på tid som frigörs, inte på teknik som köps. Hos NordicRank, en svensk sökoptimeringsbyrå, ersatte 18 automatiserade processer manuella listor för order, projektuppföljning, fakturor och kundrapporter. Värdet är 13,4 sparade timmar per vecka och återbetalningen kom efter fyra månader. Men det lönar sig inte alltid. Tre lägen där ni bör vänta: - **Bokföringen är inte i ordning.** Automatisering av en process som inte fungerar ger samma fel snabbare. Städa först. - **Volymen är för låg.** Handlar det om tjugo verifikationer i månaden är det billigare att göra det för hand, hur ineffektivt det än känns. - **Rapporten läses inte.** Bygger ni en sammanställning ingen använder har ni automatiserat fel sak. Börja med att fråga vem som ska läsa den och vad de ska besluta. Det som talar för att göra kalkylen nu är att tidsåtgången och uppgiftslämnandet är ett dokumenterat problem, inte en känsla. I [Tillväxtverkets undersökning Företagens villkor och verklighet 2026](https://www.tillvaxtverket.se/tillvaxtverket/publikationer/publikationer2026/foretagensvillkorochverklighet2026.12421.html), som besvarats av 6 342 företag, uppger 62 procent av de företag som vill växa att de upplever minst ett stort tillväxthinder, där lagar och regler samt tiden det tar att följa dem hör till de största. [Företagarnas rapport Momslabyrinten](https://www.foretagarna.se/politik-paverkan/rapporter/2025/momslabyrinten/) pekar åt samma håll: tre av tio småföretagare anger att momsreglerna innebär krångel i ganska eller mycket hög utsträckning. Att automatisera kvartalsrapporten tar inte bort reglerna. Den tar bort tiden det tar att följa dem, och flyttar er insats från att leta siffror till att bestämma vad siffrorna ska leda till. ## Vanliga frågor --- ### Stämmer utbetalningarna? Automatisera avstämningen **URL:** https://eteya.ai/sv/blogg/ai-automation/automatisera-avstamning-e-handel-ai **Sammanfattning:** Får du betalt för allt du säljer? Så bygger du en AI-avstämning som matchar varje order mot utbetalning och flaggar det som saknas innan bokslutet stängs. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' Blocket, Klarna eller Tradera sätter in en klumpsumma på kontot. Ingenstans står det vilka ordrar pengarna gäller, vad plattformen dragit i avgifter, eller om en försäljning saknas helt. Att kontrollera det för hand tar timmar, så de flesta gör det aldrig – och missade pengar förblir missade. Den här guiden visar hur AI gör kontrollen åt dig: varje order matchas mot varje utbetalning, varje avvikelse flaggas, och du godkänner innan bokslutet stängs. Arbetsfördelningen genom hela guiden är enkel: du exporterar tre filer, AI-agenten gör steg 1 till 6, och du fattar besluten i steg 7. Du läser alltså för att förstå vad som händer under huven, inte för att sitta med filerna själv. ## Varför landar utbetalningen inte på samma summa som försäljningen? Utbetalningen skiljer sig från försäljningen eftersom tre olika källor beskriver samma affär på tre olika sätt: plattformens orderexport, din egen orderkälla och plattformens utbetalningsrapport. Var och en har sitt eget format, sin egen ordernyckel och sina egna avdrag. Manuell avstämning mellan dem tar timmar varje månad och missar ändå avvikelser en människa inte hinner se. Är du ny på AI-agenter, läs först vår [genomgång av AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). Var avstämningen hör hemma bland de andra e-handelsflödena ser du i [vår artikel om AI-agenter för e-handel](/sv/blogg/ai-agenter/ai-agent-for-e-handel). I praktiken ser det ofta ut så här: en order har ett ordernummer du satt själv, till exempel i Shopify eller WooCommerce. Betalleverantören, som Klarna eller Stripe, sätter i stället ett eget referensnummer på affären, och i utbetalningsrapporten kan samma order ligga utspridd på flera transaktionsrader. Säljer du även via Blocket eller Tradera upprepas mönstret där, fast med ett tredje namn på samma order. Formaten beskriver bara samma sak på var sitt språk. ## Vad behöver du innan du börjar? Du behöver tre datakällor per plattform: orderexporten, din egen orderkälla och utbetalningsrapporten i CSV eller PDF. Utan alla tre går varken matchning eller nettoberäkning att göra, eftersom varje källa bara visar en del av bilden. Är ordrarna redan samlade på ett ställe, som vi går igenom i [guiden om att automatisera orderhanteringen](/sv/blogg/ai-automation/automatisera-orderhantering-e-handel-ai), är halva jobbet redan gjort: den interna orderkällan finns och uppdateras löpande i stället för att jagas ihop i efterhand. Har du flera kanaler, till exempel en egen webbshop, Blocket och Tradera, körs hela protokollet nedan per plattform och samlas till slut i en enda mastertabell. Tre källor gånger tre plattformar blir nio filer i en fullständig månadsrevision, inte tre – varje plattform har sitt eget format, sin egen utbetalningstakt och sina egna undantag. ## Steg 1: Hur samlar du in de tre källorna? Först läses varje fil in och profileras: vilka kolumner den har, vilka datatyper, vilka fält som kan funka som ID, och i vilken enhet beloppen står. Det tar tid nu. Vinsten kommer senare: när resten av protokollet byggs vet du redan exakt vad varje källa innehåller. ### Tre filer, tre format I praktiken skiljer sig filerna åt på nästan varje punkt: - Plattformens orderexport har ofta ett referensnummer som inte liknar ditt eget ordernummer. - Den interna orderkällan har rätt ordernummer men saknar plattformens interna transaktions-ID. - Utbetalningsrapporten radar upp transaktioner, inte ordrar, ibland flera rader per order. Profileringen avslöjar också beloppsenheten. En del plattformar redovisar i minor units, där 229000 betyder 2 290,00 kronor, alltså en division med 100 innan något annat räknas. ### Varför den interna källan måste vara radvis [Skatteverket kräver att varje försäljning bokförs för sig](https://www.skatteverket.se/foretag/drivaforetag/branscher/ehandeltillprivatpersoner.4.96cca41179bad4b1aa8b90.html), inte bara som en nettosumma från en betaltjänst. Det är en anledning till att den interna orderkällan måste vara radvis per order redan från start, annars finns inget att stämma av mastertabellens rader mot i steg 4. Sitter uppgiften om moms, frakt och rabatt i olika kolumner i den interna källan men slås ihop till en summa hos plattformen, är det den interna filen som bär den detaljnivå du senare behöver för att förklara en avvikelse. Samma profilering avgör också vilka fält som duger som ID-kandidat. Ett ordernummer som återanvänds mellan år, eller ett kundnamn som stavas olika i två system, ser ut som en nyckel men håller inte i praktiken. ## Steg 2: Hur skapar du en gemensam ordernyckel? Nu byggs en gemensam ordernyckel som fungerar i alla tre källor, oavsett hur olika de ser ut från början. Nyckeln normaliseras, till exempel genom att strippa prefix och nollor, och testas sedan mot en verklig matchningsgrad innan du går vidare. En vanlig lösning är att låta det interna ordernumret vara facit och bygga en översättningstabell mot plattformens referenskolumn och utbetalningens transaktions-ID. Tabellen byggs en gång per plattform och återanvänds sedan varje månad, så att arbetet inte görs om från noll. Matchningsgraden är det första kvittot på om nyckeln håller. Ligger den nära hundra procent redan efter första testet vet du att normaliseringen fångat rätt fält. Ligger den lägre är det oftast ett tecken på att ett prefix, en bindestrecksvariant eller en gammal ordertyp inte normaliserats bort ännu. **Exempel från en riktig månadsrevision:** hos vår kund Telestore, som säljer begagnade telefoner via telestore.se, Blocket och Tradera, heter samma order "WGR12345" internt men ligger under plattformens eget referensnummer i orderexporten, och hos nästa kanal heter motsvarande order i stället "#10123". En översättningstabell byggd en gång per kanal löste matchningen. ## Steg 3: Hur normaliserar du beloppen? Härnäst normaliseras alla belopp till en gemensam SEK-standard, utbetalningsrader grupperas per order och nettobeloppet räknas ut: försäljning minus avgift minus retur. Utan det steget går siffror i olika format och olika valutaskrivning aldrig att jämföra rakt av. ### Minor units och separerade rader En vanlig utmaning när du stämmer av flera kanaler är att en plattform delar upp utbetalningen i separata SALE-, FEE- och RETURN-rader per order, i stället för en enda summa. Settlementet, plattformens ord för själva utbetalningen, blir då försäljning minus avgifter minus returer minus eventuell skatt, och alla rader måste grupperas till samma order innan nettot går att räkna. [Klarnas egen dokumentation för settlement-rapporter](https://docs.klarna.com/settlement-reports/) visar samma princip från en etablerad utbetalningsleverantör: varje betalning bryts ner i transaktionsrader som tillsammans förklarar hur summan på kontot blev vad den blev. **Exempel från en riktig månadsrevision:** en av Telestores tre kanaler redovisar i exakt det minor units-format som steg 1 beskrev, och delar samtidigt upp varje order i separata SALE-, FEE- och RETURN-rader. Utan divisionen med 100 och grupperingen till samma ordernyckel hade nettot sett ut att avvika från både orderlistan och utbetalningen, trots att allt stämde. ### Tusentalsavgränsare och direktavdrag En annan vanlig variant redovisar i engelskt talformat med tusentalsavgränsare, till exempel "5,499.00", och drar plattformens kommission direkt innan utbetalning: utbetalt blir brutto minus kommission, ofta med en månadssummering i PDF i stället för radvis CSV. Exakt kommissionssats varierar mellan plattformar och avtal, så den siffran får din egen utbetalningsrapport ge dig. ## Steg 4: Hur bygger du mastertabellen? Allt samlas sedan i en mastertabell: en rad per unik ordernyckel, med en flagga för om ordern finns hos varje källa, beloppet från var och en, och matchningsflaggor med noteringar. En rad kan se ut så här i praktiken: ordernyckeln, finns_internt (ja/nej), finns_hos_plattformen (ja/nej), finns_i_utbetalningen (ja/nej), beloppet från vardera källa, och en kolumn med matchningsstatus: grön för fullständig match, gul för beloppsavvikelse, röd för att ordern helt saknas i en källa. Det här är också den fil du sparar. Varje månad exporteras mastertabellen som CSV, tillsammans med de sex avvikelselistorna och en revisionsrapport i Markdown och Excel, så att den går att öppna, granska och arkivera utan att någon behöver fråga hur den byggdes. > En mastertabell som bara visar "matchar" eller "matchar inte" räcker inte. Den måste visa exakt vilken källa som avviker och med vilket belopp, annars flyttar du bara problemet ett steg och kallar det löst. Fördelen mot att jämföra tre kalkylark manuellt är att mastertabellen är sökbar och filtrerbar. Vill du se alla ordrar över ett visst belopp som saknar match, eller alla avvikelser från en specifik vecka, är det ett filter, inte en eftermiddag med tre öppna Excel-flikar bredvid varandra. ## Steg 5: Vilka avvikelselistor ska AI:n ta fram? Ur mastertabellen tar AI:n sedan fram sex avvikelselistor – en för varje typ av glapp som kan uppstå mellan de tre källorna. Varje lista är en färdig arbetslista för en människa, inte råmaterial. De sex listorna, var för sig: 1. Finns internt men saknas hos plattformen, ofta ett tecken på att en order aldrig synkats över huvud taget. 2. Finns hos plattformen men saknas internt, vanligt vid manuella ordrar eller ett integrationsfel som tystnat. 3. Finns i orderlistorna men saknas i utbetalningen, till exempel en order som väntar på nästa utbetalningsperiod. 4. Finns i utbetalningen men saknas i orderlistorna, den typ av avvikelse som lättast göms i en stor fil. 5. Beloppsdifferenser, där ordern finns överallt men summan inte stämmer mellan källorna. 6. Avbrutna eller returnerade ordrar, som behöver en egen kontroll eftersom de påverkar nettot i flera led samtidigt. En retur som dras i utbetalningen som en RETURN-rad, men aldrig registreras som retur internt, hamnar i just den fjärde listan: finns i utbetalningen men saknas i orderlistorna. **Exempel från en riktig månadsrevision:** det här är exakt den sortens fynd Telestores månadsrevision är byggd för att fånga. En retur som plattformen redan dragit av men som inte registrerats internt fastnar i lista fyra och utreds före bokslut, i stället för att dyka upp månader senare som en oförklarad differens. Hur en retur registreras korrekt från början, med rätt kontroll mot ångerrätt och öppet köp, går vi igenom i [guiden till AI-returhantering med human in the loop](/sv/blogg/ai-automation/ai-returhantering-kundtjanst). ## Steg 6: Hur verifierar du plattformens totalsummor? Sista räknekontrollen gäller plattformens egna totalsummor: summera transaktionsraderna själv och jämför mot plattformens summering, samtidigt som settlement-formeln verifieras rad för rad. Ett fel i summeringslogiken syns annars aldrig i en enskild order, bara i helheten. [Bokio beskriver samma princip för bankavstämning](https://www.bokio.se/hjalp/bokforing/kontrollera-bokforing/stamma-av-bokforing-mot-bankkonto/): stämmer summan i bokföringen mot saldot på kontot, är sannolikheten hög att resten också stämmer. Vänder man på ordningen och bara litar på plattformens egen summa riskerar man att ärva ett fel man aldrig själv upptäckt. [FAR:s vägledning till BFNAR 2013:2 slår fast att bokföringen ska stämmas av löpande enligt fasta rutiner](https://www.faronline.se/dokument/rattserien/redovisa-ratt/a/rr_avstamninglopandebokforing/), där frekvensen anpassas efter det enskilda företagets förhållanden. För en e-handel med daglig försäljning på flera kanaler landar den bedömningen nästan alltid på månadsvis, eller tätare. Att automatisera avstämningen förändrar inte den bedömningen, men den sänker priset för att göra den ofta. [Bokio radar upp samma poäng i sin genomgång av varför avstämning bör göras regelbundet](https://www.bokio.se/blogg/stam-av-din-bokforing/): ett fel som upptäcks efter en månad är billigt att rätta, samma fel efter ett år kan kräva konsulttimmar för att nysta upp. ## Steg 7: Var kommer människan in? Sist kommer kontrollkedjan: AI föreslår och flaggar, människan godkänner. En ren match blir grön och kräver inget beslut. Varje avvikelse kräver ett mänskligt beslut innan bokslutet stängs, och AI:n bokför aldrig något på egen hand. I praktiken betyder det att systemet aldrig skriver en rättelse i bokföringen. Det lägger fram underlaget och väntar på ett godkännande eller en instruktion. Själva körningen tar minuter. Människans jobb är att gå igenom avvikelselistorna, inte att leta efter dem. [Bokföringslagen (1999:1078)](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/bokforingslag-19991078_sfs-1999-1078/) lägger bokföringsansvaret på bolaget, inte på ett verktyg, och den ansvarsfördelningen ska synas i hur systemet är byggt, inte bara i ett avtal. Det är kärnan i att automatisera avstämningen utan att ge upp kontrollen: maskinen gör det tröttsamma arbetet med att läsa nio filer och jämföra dem rad för rad. Människan gör det enda AI:n aldrig ska göra: ta ansvar för siffran som till slut bokförs. När siffran väl är avstämd är nästa steg att [sammanställa kvartalsrapporten](/sv/blogg/ai-automation/automatisera-kvartalsrapport) på samma underlag. ## Vilken tech stack behöver du? En automatiserad avstämning byggs på tre lager: ett skriptlager som tuggar filerna, en AI-agent som förstår dem och en schemaläggning som ser till att det faktiskt händer varje månad. ### Tre lager, del för del - **Python och pandas** läser in filerna, normaliserar ordernycklar och belopp, och bygger mastertabellen samt de sex avvikelselistorna. Det är samma verktyg oavsett om källan är en Excel-export, en CSV eller en PDF-tabell som först behöver läsas ut. - **En AI-agent**, till exempel byggd på Claude eller en annan stor språkmodell, profilerar nya filformat automatiskt, skriver revisionsrapportens sammanfattning i klarspråk, och flaggar vilka avvikelser som ser ovanliga ut jämfört med tidigare månader. - **Schemaläggning** kör hela kedjan månadsvis, från insamling till färdig rapport. Resultatet varje månad är detsamma oavsett verktyg, klart att skicka vidare till den som ansvarar för bokslutet – oavsett om det landar i Fortnox, Visma eller ett annat bokföringsprogram. Vad ett sådant bygge brukar kosta, och när det lönar sig för just din volym, finns i [kostnadsguiden för AI-agenter](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige) och i vår [besparingskalkylator](/sv/ai-besparing). Ingen av de tre delarna kräver att du river upp något befintligt. Python och pandas körs mot filerna du redan exporterar, AI-agenten läggs till som ett skript i samma flöde, och schemaläggningen är en cron-rad, inte ett nytt system att lära ut till hela teamet. Det är samma pragmatiska princip som styr resten av det vi bygger: automatisera avstämningen ovanpå det som redan fungerar. ## Vanliga frågor --- ### Bygg AI-returhantering med human in the loop **URL:** https://eteya.ai/sv/blogg/ai-automation/ai-returhantering-kundtjanst **Sammanfattning:** Två returmejl kan se likadana ut men kräva olika svar. Så bygger du AI som kontrollerar ångerrätt och öppet köp, frågar när något saknas och lämnar över i tid. import FAQ from '@/components/blog/FAQ' "Hej, jag vill lämna tillbaka varan jag köpte." Två kunder kan skriva samma sak. Det ena ärendet kan systemet hantera direkt. Det andra behöver en människa. Skillnaden syns inte i mejlet. Den här guiden visar steg för steg hur du bygger en AI-returhantering där människan är inbyggd i flödet, det som ofta kallas *human in the loop*. Du får kontrollkedjans sju steg att följa: vad som är känt om köpet, vad lagen säger, vad butiken själv har lovat, och var gränsen går för när en människa tar över. En bra returhantering handlar lika mycket om att veta när systemet inte får gissa som om att svara snabbt. Är du ny på AI-agenter för kundtjänst, läs först vår [genomgång av AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). ## Varför syns inte skillnaden i mejlet? Meningen "jag vill lämna tillbaka varan" kan gälla ett köp på nätet med lagstadgad ångerrätt, ett köp i butik med ett frivilligt öppet köp, eller en trasig vara som ska reklameras. Vilket som gäller avgörs inte av orden i mejlet, utan av var köpet gjordes och när varan kom fram. Volymerna gör felen dyra. [Enligt Kustom-data för perioden augusti 2025 till april 2026 returneras 24,9 procent av modeköpen i svensk e-handel](https://it-retail.se/bakom-returerna-trogna-modekunder-returnerar-mer-och-unga-kvinnor-skickar-tillbaka-mest/), mot 5,9 procent för e-handeln som helhet. Med den volymen skalar ett fel lika snabbt som nyttan, oavsett om systemet godkänner fel retur eller nekar en retur kunden faktiskt hade rätt till. Kundtjänst och returer brukar ligga överst när man listar var en AI-agent gör mest nytta i en butik, något vi går igenom brett i [vår artikel om AI-agenter för e-handel](/sv/blogg/ai-agenter/ai-agent-for-e-handel). Resten av den här guiden går på djupet i just returflödet, steg för steg. ## Hur hänger kontrollkedjan ihop? En returhantering byggd bara för det enkla fallet, en oöppnad vara som skickas tillbaka i tid, klarar sig fint tills verkligheten avviker. Det är avvikelserna som avgör om systemet går att lita på, och det är därför stegen behöver komma i en bestämd ordning. Hela kedjan i en rad: **Kundens fråga → fakta → lag → företagets regler → följdfråga → automation eller människa** Vi kallar den här modellen *kontrollkedjan*. Det är samma grundflöde vi utgår från när vi bygger automationsflöden åt e-handlare, oavsett om ärendet gäller returer, ordrar eller något annat med regler i botten. Kedjan bryts ner i sju steg: 1. Bekräfta fakta om köpet. 2. Kontrollera vad lagen säger. 3. Kontrollera företagets egna villkor. 4. Hitta den uppgift som saknas. 5. Ställ en avgränsad följdfråga. 6. Matcha svaret mot en förhandsgodkänd regel. 7. Lämna över när något inte stämmer. Resten av guiden går igenom varje steg i tur och ordning. ## Steg 1: vilka fakta bekräftar du först? Innan svaret går att avgöra behöver systemet veta tre saker: vem kunden är och vilken order det gäller, vilken kanal köpet skedde i, och exakt när varan kom fram. Utan de tre går varken lagen eller butikens egna villkor att tillämpa korrekt. - **Rätt kund och order.** Matcha mot ordernummer eller kontouppgifter, gissa aldrig på ett namn i ett mejl. Ett ordernummer som inte matchar kundens uppgifter är inte ett detaljfel, det är en signal om att antingen fel person hör av sig eller att något i beställningen redan skiljer sig från vad systemet tror. - **Kanal.** Distansköp (nät, telefon, katalog) eller köp i fysisk butik avgör om lagstadgad ångerrätt finns över huvud taget. - **Mottagningsdatum.** Det datum som styr fristen, inte köpdatumet. ## Steg 2: vad säger lagen? Vid distansköp har kunden som huvudregel 14 dagars lagstadgad ångerrätt enligt [lag (2005:59) 2 kap. 10 §](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/). Fristen börjar enligt [2 kap. 12 §](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/) löpa dagen efter att kunden tog emot varan, inte från köpdagen. Ett system som räknar fel här kan neka en giltig retur, eller godkänna en retur som redan gått ut. Reklamation är en annan sak: att varan är felaktig, reglerat av ett eget regelverk, [konsumentköplagen (2022:260)](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/konsumentkoplag-2022260_sfs-2022-260/), med tre års felansvar. Ett system som blandar ihop ånger och reklamation, till exempel behandlar en trasig vara som en vanlig ångerretur, riskerar att ge kunden fel besked i båda riktningarna. ### Äkta undantag från ångerrätten Enligt [2 kap. 11 §](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/) försvinner ångerrätten helt för vissa varor: bruten försegling på produkter som av hälso- eller hygienskäl inte lämpligen kan lämnas tillbaka, specialtillverkade varor, och varor som snabbt försämras eller blir för gamla. Vilka varukategorier som omfattas och vilka underlag som krävs ska bestämmas i förväg. Tydliga standardfall kan hanteras mot de reglerna. Om underlaget är oklart eller kräver en bedömning lämnas ärendet till en människa. ### Värdeminskning i stället för förlorad rätt Här går många fel: att varan är använd eller uppackad tar inte automatiskt bort ångerrätten. Enligt [2 kap. 15 §](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/) kan butiken i stället göra ett avdrag för värdeminskning, alltså sänka återbetalningen snarare än att neka returen helt. Det förutsätter att kunden fått korrekt information om ångerrätten före köpet. [Konsumentverket förklarar principen med skor som testats inomhus](https://www.konsumentverket.se/fragor-och-svar/2863070/kan-jag-lamna-tillbaka-anvanda-skor/), och [ARN:s praxis om värdeminskning](https://www.arn.se/vanligafall/3.3.-vardeminskning/) ger konkreta exempel på var gränsen brukar dras. Skillnaden mellan värdeminskning och de äkta undantagen ovan är precis den typ av bedömning en AI-lösning måste hämta ur en förhandsgodkänd regel, aldrig ur en egen tolkning av lagen. ## Steg 3: vad har du själv lovat kunden? Köper kunden i en fysisk butik finns ingen lagstadgad ångerrätt. [Öppet köp och bytesrätt är helt frivilliga förmåner](https://www.konsumentverket.se/konsumentratt/oppet-kop-och-bytesratt/), och det är butiken själv som sätter villkoren. Systemet behöver därför känna till exakt vad just din butik lovar, inte bara vad lagen kräver. Företaget bestämmer själv villkoren för sitt frivilliga öppna köp. Villkoren kan ge kunden ytterligare rättigheter, men de får inte begränsa kundens lagstadgade rättigheter när de gäller. ## Steg 4: vilken uppgift saknas? Systemet har nu fakta om köpet, lagen och butikens egna villkor, men en bit information kan fortfarande saknas. Ett vanligt exempel vid öppet köp: villkoret kräver obruten förpackning, en regel butiken själv har satt, inte lagen, och kunden har inte skrivit om förpackningen är öppnad. Saknas svaret på just den frågan går ärendet varken att godkänna eller neka ännu. Systemet ska då varken gissa eller lämna över direkt. Nästa steg är att ställa en konkret följdfråga, kontrollera svaret mot butikens förhandsgodkända regler, och gå vidare bara om svaret är entydigt. ## Steg 5: hur ställer du följdfrågan? En bra följdfråga är avgränsad till exakt den uppgift som saknas, aldrig en allmän utfrågning om hela ärendet. Den ställs bara när en enskild uppgift, till exempel om en förpackning öppnats, avgör vilken regel som gäller. Kunden ska kunna svara på sekunder, inte fylla i ett formulär. Ett exempel på hur frågan kan se ut: > "Tack! För att vi ska kunna kontrollera vad som gäller för returen behöver vi veta om förpackningen har öppnats." Svaret kontrolleras mot regeln butiken godkänt i förväg, till exempel "obruten förpackning krävs för öppet köp". Stämmer svaret mot en tydlig regel går ärendet vidare som ett standardärende. Är svaret tvetydigt, eller passar det inte in i någon förhandsgodkänd regel, går ärendet i stället till en människa. Att hålla frågan smal spelar roll. [En Sifo-undersökning för Nets från 2022 visar att 51 procent av svenska konsumenter någon gång struntat i en retur](https://www.mynewsdesk.com/se/nets/pressreleases/besvaerligt-med-produktreturer-inom-e-handel-3199094) för att processen kändes för krånglig. Ett system som ber om en sak i taget, i stället för en lång formulär-lista, sänker den friktionen utan att sänka noggrannheten. Samma princip gäller andra saknade uppgifter, inte bara förpackningen. Saknas ett bekräftat mottagningsdatum kan systemet i stället fråga när paketet kom fram, eller be om spårningsnumret som avslöjar det. Fråga alltid om exakt den uppgift som fattas, aldrig om allt på en gång. ## Steg 6: när går ärendet vidare automatiskt? Är informationen komplett och regeln tydlig går ärendet vidare automatiskt, till exempel ett distansköp där mottagningsdatumet är bekräftat, ångerfristen fortfarande löper och inget förhandsgodkänt undantag gäller. Systemet behöver ingen människa när alla fakta redan pekar mot samma förhandsgodkända regel. Kund A skriver att hen vill returnera en vara. Ordernumret matchar, kunden tog emot varan för sex dagar sedan och inget förhandsgodkänt undantag gäller. Alla uppgifter pekar mot samma tydliga regel. Ångern registreras, kunden får nästa instruktion och ärendet går vidare utan att en människa behöver bedöma det. ## Steg 7: när tar en människa över? Är uppgifterna motsägande, faller de utanför en tydlig regel, eller kräver ärendet en bedömning, går det i stället till en människa. Kund B skriver exakt samma mening som Kund A. Ordernumret finns, men köpet gjordes i en fysisk butik utan något registrerat öppet köp, och kunden hävdar att en anställd muntligt lovat en längre frist. Ingen regel täcker ett muntligt löfte. Systemet kan inte avgöra vems minne som stämmer, så ärendet går till en människa med hela underlaget redan sammanställt: vad som är känt, vad som saknas och varför det inte gick att avgöra automatiskt. Det här är också skillnaden mellan att bara svara och att faktiskt agera. Ett system som enbart chattar kan berätta hur en retur går till. Ett system som registrerar returen, väljer rätt regel och skickar bekräftelsen agerar i stället för att bara informera. Den distinktionen går vi igenom i detalj i [jämförelsen mellan AI-agent och chatbot](/sv/blogg/ai-agenter/ai-agent-vs-chatbot). ### Gränsen AI:n aldrig får flytta själv Poängen är inte att AI:n ska tolka lagen fritt. Reglerna som styr beslutet – villkoren för öppet köp, undantagen, gränsvärdena – är förhandsgodkända av en människa i förväg. AI:n kontrollerar fakta mot de reglerna. Så fort ett ärende kräver en egen bedömning, en gråzon lagen eller villkoren inte täcker rakt av, är det en människa som avgör, inte systemet. Det är kärnan i human in the loop: människan är inte en reservutgång när något redan gått fel, utan en inbyggd del av flödet med ett tydligt ansvar: bedömningarna. ## Vilken tech stack behöver du? En returhantering med kontrollkedjan byggs på sex komponenter: en datakälla med ordrar, en AI-modell via API, en orkestrering som binder ihop stegen, en regelmotor för företagets villkor, en överlämningsväg till en människa och loggning av varje beslut. ### Sex komponenter, del för del - **Datakällan.** Ordersystemet eller e-handelsplattformen, till exempel Shopify eller WooCommerce, kopplas in via sitt API. Det är härifrån systemet hämtar ordernummer, kanal och mottagningsdatum, de tre fakta steg 1 kräver. - **AI-modellen.** En språkmodell som anropas via API läser mejlet, tolkar vad kunden frågar efter och formulerar följdfrågan. Modellen fattar inget beslut på egen hand, den matchar fakta mot regler. - **Orkestreringen.** Ett no-code-verktyg som n8n binder ihop stegen utan att ni skriver allt från grunden, och passar de flesta volymer. Har ni redan en utvecklingsavdelning och hög volym kan egen kod vara rätt väg i stället. Avvägningen mellan att [bygga en AI-agent själv eller anlita](/sv/blogg/ai-agenter/bygga-ai-agent-sjalv-vs-anlita) någon gäller lika mycket här, styrd av volym och intern kapacitet, inte av vad som låter mest avancerat. - **Regelmotorn.** Företagets regler, öppet köp-villkor, undantag och gränsvärden lagras som en versionerad konfiguration utanför själva modellen. De styrande reglerna ska inte vara beroende av att AI:n tolkar en fri instruktion. De ska gå att läsa, ändra och godkänna utan att röra modellen. En versionerad regelmotor gör det också enkelt att i efterhand visa exakt vilken regel som gällde den dag ett specifikt ärende avgjordes. - **Överlämningsvägen.** Ett helpdesk-system eller en bevakad mejl-kö tar emot eskalerade ärenden, med hela underlaget bifogat så att människan slipper börja om. - **Loggning och spårbarhet.** Varje beslut, automatiskt eller mänskligt, sparas i en databas med en tabellvy ovanpå för mänsklig granskning, till exempel Postgres och NocoDB. [Så ser det ut när vi byggt motsvarande i orderflödet](/sv/blogg/ai-automation/automatisera-orderhantering-e-handel-ai). Godkända återbetalningar måste också synas i utbetalningen för att avstämningen ska gå ihop, vilket [guiden om att stämma av ordrar mot utbetalningar](/sv/blogg/ai-automation/automatisera-avstamning-e-handel-ai) tar upp. Returhantering rör personuppgifter, ordernummer, adresser och betalinformation, samma krav på dataåtkomst som all annan AI-hantering av kunddata. [Vår guide till AI och GDPR](/sv/blogg/ai-agenter/ai-och-gdpr-sakerhet) går igenom vad som krävs för att hålla den delen i ordning från start. Vad ett sådant bygge brukar kosta finns i [kostnadsguiden för AI-agenter](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). ## Vad behöver finnas på plats innan du bygger? Tre saker behöver finnas innan returhanteringen kan byggas: en källa till orderdata som visar kanal och mottagningsdatum, skriftliga och godkända regler för öppet köp och undantag, och en tydlig väg för att lämna över ärenden till en människa. Utan de tre har systemet inget att kontrollera kundens svar mot. - **Orderdata med kanal och mottagningsdatum**, samlad på ett ställe systemet kan läsa. - **Skrivna, godkända regler** för öppet köp, undantag och gränsvärden, inte något som avgörs från fall till fall när ärendet redan ligger hos kunden. - **En tydlig överlämningsväg** dit ärenden går när uppgifterna inte räcker för ett automatiskt beslut. Oavsett om ni bygger själva eller anlitar någon är grundarbetet detsamma: skriv ner reglerna innan du bygger returhanteringen, inte medan den redan är i drift. Den som tar över ett överlämnat ärende börjar inte heller från noll. Underlaget är redan sammanställt: vad som är känt, vad som saknas och var det tog stopp. Bedömningen går snabbare än om ärendet hade legat manuellt från start. Bra automation handlar inte om att AI ska fatta så många beslut som möjligt. Det handlar om att varje ärende går vidare på rätt sätt: kontrollera det som är känt, fråga efter det som saknas, och lämna över när en människa faktiskt behöver bedöma. Det är human in the loop i praktiken. ## Vanliga frågor --- ### Automatisera orderhanteringen i din e-handel **URL:** https://eteya.ai/sv/blogg/ai-automation/automatisera-orderhantering-e-handel-ai **Sammanfattning:** Så automatiserar du orderhanteringen i din e-handel, från order och fraktsedel till lager och returer. Steg för steg, med riktigt exempel och dagens verktyg. import CaseLink from '@/components/blog/CaseLink' import FAQ from '@/components/blog/FAQ' import BlogTestimonial from '@/components/blog/BlogTestimonial' import BlogScreenshot from '@/components/blog/BlogScreenshot' Order in, fraktsedel ut, paket på väg, utan ett enda manuellt klick. Så ser en automatiserad orderhantering ut när allt klaffar. Det svåra, och det som faktiskt sparar pengar, är ordrarna som inte gör det. Den här guiden visar steg för steg hur du kan automatisera orderhanteringen, med Telestore som exempel: en svensk e-handel för begagnade telefoner där vi byggde 56 automationer. Vill du först se vad AI gör för en e-handel i stort, läs vår [översikt om AI-agenter för e-handel](/sv/blogg/ai-agenter/ai-agent-for-e-handel). ## Vad innebär det att automatisera orderhanteringen? Att automatisera orderhanteringen betyder att stegen mellan köp och leverans sköts av ett system i stället för en människa. Ordern fångas upp, kunddata hämtas, bekräftelse och fraktsedel skapas, lagret stäms av och avvikelser flaggas, utan manuella klick i varje led. Hos Telestore gick förut runt 2,5 timmar i veckan åt att felsöka manuella listor, och fel i ordrarna kostade både pengar och kunder. Det är den friktionen automationen tar bort. Poängen är inte att jaga bort människan. Det är att låta maskinen ta det repetitiva och förutsägbara, så att din tid går till de ärenden som faktiskt kräver omdöme. En bra automation gör de tråkiga 80 procenten själv och lämnar över de svåra 20 procenten till dig, på ett kontrollerat sätt. Orderhantering hör till det som lönar sig först att ta tag i, eftersom volymen är hög och stegen ser likadana ut varje gång. [Shopify tar upp orderhantering bland de processer AI kan ta över i e-handeln](https://www.shopify.com/se/blog/ai-inom-e-handel). ## Hur samlar du alla ordrar på ett ställe? Det första steget är att samla alla ordrar i ett system, oavsett vilken kanal de kommer från. Du kan inte automatisera ett flöde som ligger utspritt på fyra inloggningar. Allt börjar med att ordrarna landar på samma ställe. Hos Telestore såldes telefoner på tre ställen samtidigt: den egna sajten, Blocket och Tradera. Förut innebar det att personalen loggade in på var och en för att se och hantera ordrar. Nu är alla tre kopplade till samma system, så att varje order, oavsett varifrån den kom, dyker upp i ett enda flöde. Det är kärnan i ett orderhanteringssystem (OMS): en vy som äger orderflödet oavsett kanal. Tekniskt sker det via plattformarnas API:er: varje kanal skickar sina ordrar till samma databas, där de översätts till ett gemensamt format. Det låter trivialt, men det är här många manuella fel föds, när samma order finns i tre system med små skillnader. När allt i stället speglas till en källa blir resten av automationen pålitlig, eftersom den alltid läser från samma sanning. Det är den osynliga grunden: när ordern finns på ett ställe kan allt annat byggas ovanpå. ## Hur automatiserar du bekräftelse och frakt? När en order kommer in hämtar systemet kundens uppgifter, skapar en orderbekräftelse och beställer en fraktsedel automatiskt. Hos Telestore är sajten, Blocket och Tradera kopplade till PostNord, så att rätt fraktsedel genereras direkt utan att någon skriver in adressen för hand. Det här är steget där tiden faktiskt frigörs. På Telestore hanteras runt 34 ordrar i veckan, och själva orderhanteringen gick från cirka tio minuter till två per order. Fraktsedlarna, som tidigare skrevs en och en, sköts nu helt automatiskt. Tillsammans frigör de två stegen flera timmar varje vecka, tid som förut gick till klippa-klistra mellan system. För kunden blir det också bättre: bekräftelsen kommer på sekunden och paketet kan skickas samma dag, i stället för att vänta på att någon hinner skriva ut en sedel. ### Så ser ett automatiserat orderflöde ut När en order landar händer det här: - Ordern fångas upp från kanalen den kom in på, och kundens uppgifter hämtas. - En orderbekräftelse skapas och skickas till kunden direkt. - En fraktsedel beställs automatiskt hos fraktleverantören, hos Telestore PostNord. - Lagersaldot uppdateras och eventuella avvikelser flaggas för en människa. Inget av stegen kräver att någon loggar in och klickar. ### Rätt kunddata avgör allt Det här fungerar bara om kundens uppgifter stämmer. Eftersom de flesta betalar med Klarna eller liknande måste namn och adress matcha redan från start, annars går varken betalning eller leverans igenom. Automationen är därför bara så bra som datan den får in, vilket gör det första steget, att samla allt på ett ställe med rätt uppgifter, så viktigt. ## Hur ser du till att lagret aldrig tar slut? En order du inte kan leverera är en misslyckad order, så att hålla lagret fyllt hör till orderhanteringen. Här lönar det sig att automatisera bevakningen, men inte själva köpet. Hos Telestore finns ett larm som håller koll på saldot mot parametrar du själv sätter. Ett exempel: när skärmskydden till en viss modell går under fem i lager, lägger systemet automatiskt in rätt antal i leverantörens varukorg via deras API. Men det lägger inte ordern. En människa går in och buntar ihop flera varor till en beställning några dagar senare, så att du slipper betala frakt på varje liten påfyllning. Det är ett bra exempel på smart automation: maskinen sköter bevakningen och förberedelsen, människan tar det sista beslutet där det faktiskt sparar pengar. ## Vilken teknik bygger du det med? Du bygger det med en automationsmotor, en databas och kopplingar mot dina system. I dag är det smartaste valet ofta open-source-verktyg du kör själv, så att du slipper avgift per körning och låter kunddatan stanna hos dig. ### Stacket, del för del Så här ser en modern uppsättning du driver själv ut: - [**Coolify**](https://coolify.io) är värden. Ett öppet alternativ till Vercel eller Heroku som du kör på en egen server, där du startar resten med ett klick. - **n8n** är automationsmotorn, det som ersätter äldre verktyg som Make. [Den har starka AI-agent-noder](https://zapier.com/blog/n8n-vs-make/), tar ingen avgift per körning, och flödena ligger i din egen infrastruktur, vilket är en fördel för GDPR när du hanterar kunddata. - **Postgres** är databasen där ordrar, produkter och dina parametrar ligger. Den startas med ett klick i Coolify. - **NocoDB** lägger en tabell-vy ovanpå databasen, så att en människa enkelt kan se och ändra, till exempel sätta lågsaldo-trösklarna. Fördelen för en mindre e-handel är förutsägbar kostnad: du betalar för en server, inte per automation, och slipper se räkningen växa i takt med volymen. Telestore byggdes på sin tids verktyg, men skulle vi bygga om det i dag är det den här stacken vi väljer. En ärlig brasklapp: att köra det själv kräver teknik och löpande underhåll. Har du inte den kompetensen internt är det här en sån sak vi hjälper företag att bygga och driva. ## Varför är undantagen det svåraste, och viktigaste? En order som går perfekt är lätt att automatisera. Det riktiga jobbet ligger i ordrarna som strular, och det är där de flesta guider tystnar. En automation som bara klarar de perfekta fallen går sönder första gången verkligheten slår till. ### Exempel: returer och öppetköp När en kund vill utnyttja sitt öppetköp kollar systemet automatiskt om rätten finns kvar, genom att titta på när telefonen köptes och när den hämtades ut, mot butikens policy. Är det inom fönstret registreras returen automatiskt och kunden får ett mejl med rätt QR-kod för att skicka tillbaka varan. Är det utanför, eller oklart, eskaleras ärendet automatiskt till rätt person för en bedömning. Maskinen gör den exakta kontrollen mot datumen, människan tar ställning först när det faktiskt krävs omdöme. (Den svenska ångerrätten är 14 dagar enligt [distansavtalslagen](https://www.konsumentverket.se/konsumentratt-process/angerratt/), men din butik kan ge generösare öppetköp.) Samma princip gäller andra avvikelser: en adress som inte stämmer, en betalning som hänger sig, en kund som inte hör av sig. [Gartner förutspår att agentisk AI löser 80 procent av vanliga kundtjänstärenden till 2029](https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290), men de återstående tjugo är just de som kräver omdöme. Den som bygger uppföljningen för de här fallen, gärna med tester på exakt när en påminnelse ska gå ut, får ut långt mer än den som bara automatiserar den perfekta ordern. Retur-exemplet ovan är förenklat till öppet köp. Skillnaden mellan lagstadgad ångerrätt och ett frivilligt öppet köp, och hur systemet ska fråga när en uppgift saknas innan det lämnar över, går vi igenom steg för steg i [vår genomgång av kontrollkedjan för AI-returhantering](/sv/blogg/ai-automation/ai-returhantering-kundtjanst). ## Hur kommer du igång? Att automatisera orderhanteringen behöver inte vara ett stort projekt. Börja med det steg som tar mest manuell tid i dag, inte med allt på en gång. För de flesta e-handlar är det orderbekräftelse och frakt, eller att samla ordrarna på ett ställe. Mät hur lång tid steget tar innan du börjar, så att du kan visa vad du sparat efteråt. Ta ett steg, få det stabilt i drift, och bygg sedan ut till nästa. Ett vanligt nästa flöde är att stämma av utbetalningar mot ordrarna, vilket [guiden om att matcha ordrar mot utbetalningar](/sv/blogg/ai-automation/automatisera-avstamning-e-handel-ai) går igenom i detalj. Steget därefter är [den ekonomiska rapporteringen](/sv/blogg/ai-automation/automatisera-kvartalsrapport), där samma data sammanställs till kvartalets siffror. När grunden väl finns blir varje nytt flöde billigare att lägga till. Vill du räkna på vad det är värt för just din volym, använd vår [besparingskalkylator](/sv/ai-besparing), och behöver du veta vad ett bygge brukar kosta, läs [kostnadsguiden för AI-agenter](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). ## Vanliga frågor --- ### AI-agent för e-handel: vad den gör och kostar **URL:** https://eteya.ai/sv/blogg/ai-agenter/ai-agent-for-e-handel **Sammanfattning:** Vad gör en AI-agent i en e-handel, vad kostar den och när lönar den sig? Konkret genomgång av kundservice, order, lager och produkttexter för svenska butiker. import CaseLink from '@/components/blog/CaseLink' import FAQ from '@/components/blog/FAQ' En AI-agent för e-handel gör mer än att svara i chatten. Den hanterar hela ärenden: svarar kunder, ändrar och spårar ordrar, håller koll på lagret och skriver produkttexter i skala. Frågan för dig som driver en webbutik är inte längre om tekniken fungerar, utan var den lönar sig först och vad den faktiskt kostar. Den här guiden går igenom vad en AI-agent för e-handel gör, var nyttan är störst, vad den kostar i svenska kronor och hur du börjar utan att ta för stort kliv. Är du ny på AI-agenter kan det löna sig att först läsa [hur de fungerar för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). ## Vad gör en AI-agent för en e-handel? En AI-agent för e-handel kopplar ihop dina system och utför hela ärenden själv. Den svarar på kundfrågor, ändrar och spårar ordrar, uppdaterar lagersaldon och genererar produkttexter, och lämnar över till en människa när ärendet kräver omdöme. ### Var en AI-agent arbetar i en webbutik I praktiken arbetar den på fyra ställen: - **Kundservice och returer.** Svarar på leverans-, retur- och produktfrågor dygnet runt, och inleder en retur eller ett byte direkt i systemet. Var gränsen går mellan lagstadgad ångerrätt och ett öppet köp, och när AI:n ska fråga i stället för att gissa, beskriver vi i [en guide om AI-returhantering med människan i loopen](/sv/blogg/ai-automation/ai-returhantering-kundtjanst). - **Orderhantering.** Ändrar adresser, kombinerar leveranser, avbryter eller uppdaterar ordrar och håller kunden informerad. Hela det flödet, från order till fraktsedel och retur, går vi igenom i guiden om att [automatisera orderhanteringen](/sv/blogg/ai-automation/automatisera-orderhantering-e-handel-ai). - **Lager och påfyllnad.** Läser av försäljningstakt, flaggar för bristvaror och föreslår en färdig påfyllningsbeställning innan hyllan tar slut. - **Produkttexter i skala.** Skriver sökoptimerade produktbeskrivningar för hundratals artiklar mot din egen produktdata, i stället för att de skrivs en och en för hand. [Shopifys genomgång av AI inom e-handel](https://www.shopify.com/se/blog/ai-inom-e-handel) listar samma huvudområden plus prognoser, bedrägeridetektering och dynamisk prissättning. Det mesta av det här har funnits som separata verktyg i flera år. Det nya är att en AI-agent binder ihop dem och utför arbetet i stället för att bara föreslå det. ## Var i butiken gör en AI-agent störst nytta först? Störst nytta först ligger oftast i kundservice och returer, där volymen är hög och frågorna repetitiva. Därefter kommer orderhantering och lagerprognoser. Produkttexter i skala ger snabb effekt för butiker med tusentals artiklar. Logiken är enkel: börja där mycket tid binds i arbete som ser likadant ut varje dag. Kundservice är nästan alltid den platsen i en e-handel. [Shopify rapporterar att återförsäljare som använde AI-chatt under Black Friday 2024 såg en konverteringsökning på 15 procent](https://www.shopify.com/se/blog/ai-inom-e-handel), och att AI-driven efterfrågeprognos kan sänka lagernivåerna med 20 till 30 procent utan att servicegraden faller. Det är två olika sorters värde: det ena fångar fler köp, det andra frigör kapital som annars står bundet i hyllorna. Svenska handlare ligger inte efter. [Svensk Handel beskriver hur kedjor som ICA och Apotek Hjärtat](https://www.svenskhandel.se/nyhetscenter/nyheter/ai-revolutionen-som-formar-framtidens-handel/) tidigt började använda AI för kundservice och interna processer, och hänvisar till McKinsey-siffran att företag som inför AI proaktivt kan nå produktivitetslyft på upp till 40 procent. De stora kedjorna har resurserna att gå först. Poängen för en mindre butik är att samma teknik nu kostar en bråkdel av vad den gjorde 2023. Hur stor del av kundärendena en agent kan ta är inte längre en gissning. [Gartner förutspår att agentisk AI autonomt löser 80 procent av vanliga kundtjänstärenden till 2029](https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290). I en e-handel är de "vanliga ärendena" just det som dränker supporten i högsäsong: var är paketet, hur returnerar jag, finns varan i en annan storlek. Det är där en agent tjänar in sig snabbast. ## Vad skiljer en AI-agent från en vanlig chatbot eller plugin? Skillnaden är handling. En chatbot eller en plugin svarar inom sin ruta. En AI-agent agerar tvärs dina system, hämtar data från lager och CRM, uppdaterar ordern och slutför ärendet, tekniskt via API:er och det som kallas [MCP-protokollet](/sv/blogg/ai-agenter/mcp-protokoll-teknisk-guide). Det låter som en teknisk detalj, men i en butik blir den konkret. En chatbot kan berätta hur en retur går till, medan agenten registrerar returen, skapar fraktsedeln och lägger en återbetalning i kö. Där en plugin för orderspårning bara visar en spårningssida ser agenten att leveransen är försenad, bokar om den och meddelar kunden innan klagomålet kommer in. Vi använder en strikt definition: agera betyder AI-agent, bara svara betyder chatbot. Många verktyg marknadsförs i dag som "agenter" trots att de aldrig lämnar chatten. Skillnaden i vad du får ut är stor, och den styr både pris och nytta. Hela jämförelsen i åtta dimensioner, med priser och beslutsstöd, går vi igenom i guiden om [skillnaden mellan AI-agent och chatbot](/sv/blogg/ai-agenter/ai-agent-vs-chatbot). ## Vad kostar en AI-agent för en e-handel, och när lönar den sig? En AI-agent för e-handel kostar från 45 000 kr i implementation och 5 000 till 15 000 kr per månad i drift, beroende på hur många processer och system den rör, utan bindningstid. Den lönar sig när volymen den tar bort kostar mer att hantera för hand. Så här ser spannen ut för svenska implementationer 2026: | Omfattning | Implementation | Drift per månad | |---|---|---| | En process (till exempel returer) | från 45 000 kr | 5 000 kr | | Flera processer | från 180 000 kr | 15 000 kr | Driften av själva AI:n är försumbar: öre till enstaka kronor per ärende enligt modelleverantörernas prislistor. Det du betalar för är arbetet runt agenten, alltså bygget, integrationerna mot din plattform och underhållet, inte modellanropen i sig. Det som avgör om kalkylen går ihop är vad det manuella alternativet kostar. [SCB:s lönestatistik](https://www.scb.se/hitta-statistik/statistik-efter-amne/arbetsmarknad/loner-och-arbetskostnader/lonestrukturstatistik-hela-ekonomin/pong/tabell-och-diagram/genomsnittlig-manadslon-efter-sektor/) anger en genomsnittlig månadslön på 41 600 kr för 2024, vilket med sociala avgifter landar timkostnaden runt 300 till 350 kr. Ju mer volym som binds i manuellt arbete till den kostnaden, desto snabbare betalar sig automationen. ### Två byggen som visar ROI Två konkreta byggen visar mönstret, även om de inte är renodlad e-handel: **NordicRank** automatiserade 18 processer för 65 000 kr plus 4 500 kr i månaden, från rapportgenerering till fakturahantering. Resultatet blev 13,4 timmar i veckan i sparad arbetstid, vilket motsvarar cirka 380 000 kr om året i värde. Återbetalning: fyra månader. Det är samma sorts processautomation en e-handel har i bakgrunden, fast i en annan bransch. **Sannegårdens Pizzeria** lät en agent koppla ihop kassan med leverantörsfakturorna och föreslå en färdig påfyllningsbeställning varje vecka. Resultatet blev 32 procent mindre matsvinn och 6 timmar i veckan sparat på inventering, runt 315 000 kr om året i nettoeffekt. Principen, att låta AI:n förutse vad som behöver fyllas på, är exakt den en webbutik använder för sitt lager. Att tidiga införare faktiskt får tillbaka pengarna stöds av data. [En Google Cloud-studie med 3 466 företagsledare](https://www.googlecloudpresscorner.com/2025-09-04-Google-Cloud-Study-Reveals-52-of-Executives-Say-Their-Organizations-Have-Deployed-AI-Agents,-Unlocking-a-New-Wave-of-Business-Value,1) visar att 88 procent av de tidiga agent-införarna når positiv avkastning på minst ett användningsfall. För en djupare prisgenomgång med ROI-formler, läs vår [kostnadsguide för AI-agenter](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). ## Hur börjar du med en AI-agent i din e-handel? Börja med en enda process där volymen är hög och reglerna stabila. Mät utgångsläget innan ni går live, kör en pilot på en del av volymen och skala när siffrorna håller. Välj den process som dränker mest tid i dag och låt agenten ta just den. När du har sex veckors driftdata vet du vilken process som ska bli nästa. Tekniken är mogen för det: [Stanfords AI Index](https://hai.stanford.edu/ai-index/2025-ai-index-report) visar att 78 procent av organisationerna nu använder AI i minst en affärsfunktion, mot 55 procent året innan. Att vara tidig är inte längre ett risk-projekt. Ska du bygga själv eller anlita någon? Det beror på hur många system som ska kopplas in och hur mycket tid du har internt. Avvägningen, med för- och nackdelar, går vi igenom i guiden om att [bygga en AI-agent själv eller anlita](/sv/blogg/ai-agenter/bygga-ai-agent-sjalv-vs-anlita). Ett svenskt e-handelsbolag vi byggde tillsammans med är Telestore, som säljer begagnade telefoner. Där lät vi AI:n sköta prissättning, listning och lager. Varje telefon prissätts mot en marknad som rör sig vecka för vecka, publiceras automatiskt och stäms av mot lagersaldot, i stället för att skötas för hand. Det började med en avgränsad process och växte därifrån. ## Vilka misstag gör e-handlare när de inför en AI-agent? De vanligaste misstagen är att automatisera för brett, att inte mäta utgångsläget och att lämna agenten utan någon som äger uppföljningen. Lägg till smutsig produktdata, så fastnar projektet oavsett hur bra själva AI:n är. Fyra fällor vi ser oftare än andra: - **För bred ansats.** "Vi vill automatisera allt" blir ett projekt som aldrig går live, eftersom varje extra process mångdubblar testarbetet innan något kan släppas. - **Inget utgångsläge mätt.** Utan att veta vad ärendena kostar i tid och pengar i dag går det inte att visa vad agenten sparat efter ett halvår, och då blir nästa investering svår att motivera. - **Smutsig produktdata.** En AI-agent för e-handel är bara så bra som datan den läser. Fel lagersaldon, dubblerade artiklar eller luckor i produktattributen ger fel svar till kunden. I en webbutik är det här den vanligaste orsaken till att agenten "inte fungerar". - **Ingen som äger kontrollen.** Agenten lämnas på autopilot. Någon behöver granska de eskalerade ärendena varje vecka under första kvartalet, tills mönstret är inkört. Ingen av fällorna handlar om tekniken i sig. De handlar om förarbete och uppföljning, och det är där ett bygge antingen betalar sig eller rinner ut i sanden. ## Vad är "agentic commerce" och behöver du bry dig nu? Agentic commerce är när kundens egen AI-agent gör köpet åt hen, inte bara du som använder AI inne i butiken. Än så länge är det tidigt, men värt att förbereda för. Din produktdata behöver vara så ren och strukturerad att en maskin kan läsa och lita på den. Riktningen är tydlig. [Gartner förutspår att 60 procent av varumärkena använder agentisk AI för en-till-en-interaktioner till 2028](https://www.gartner.com/en/newsroom/press-releases/2026-01-15-gartner-predicts-60-percent-of-brands-will-use-agentic-ai-to-deliver-streamlined-one-to-one-interactions-by-2028). När en köpande agent jämför ditt sortiment mot en konkurrents är det din produktdata den läser, inte din formgivning. Butiker med korrekta priser, tydliga lagersaldon och maskinläsbara produktattribut blir lättare för en agent att välja. Du behöver inte bygga för agentic commerce i dag. Men de processer som gör en e-handel redo för det, ren produktdata och realtidsuppdaterade priser och lager, är samma processer som en AI-agent sköter åt dig redan nu. Du förbereder framtiden genom att lösa nuet. ## Vanliga frågor --- ### Vad är RAG (Retrieval-Augmented Generation)? **URL:** https://eteya.ai/sv/blogg/ai-agenter/vad-ar-rag-retrieval-augmented-generation **Sammanfattning:** RAG, eller Retrieval-Augmented Generation, låter en språkmodell svara utifrån dina egna dokument i stället för att gissa, för mer korrekta och spårbara svar. import FAQ from '@/components/blog/FAQ' Här är vad RAG är, hur det fungerar steg för steg, och när ditt företag behöver det. ## Hur fungerar RAG steg för steg? RAG arbetar i fyra steg: din fråga skickas till ett söksystem, de mest relevanta bitarna ur kunskapskällan hämtas, de skickas med som kontext till språkmodellen, och modellen skriver ett svar grundat i dem. Själva sökningen bygger oftast på så kallade embeddings. I grunden kombinerar RAG två sorters minne: modellens inbyggda minne, det den lärt sig under träningen, och ett externt minne, en kunskapsbas som den slår upp i vid varje fråga. Idén presenterades 2020 i en [forskningsartikel av Patrick Lewis med flera](https://arxiv.org/abs/2005.11401). Det inbyggda minnet är fryst vid träningstillfället; det externa kan du uppdatera när som helst, utan att röra modellen. Så här ser flödet ut: 1. Frågan översätts till en sökning, vanligtvis genom att omvandlas till en numerisk representation (en embedding). 2. Söksystemet hämtar de textstycken ur din kunskapskälla som ligger närmast frågan, ofta ur en vektordatabas. 3. De hämtade styckena skickas med som kontext till språkmodellen, tillsammans med själva frågan. 4. Modellen formulerar ett svar som bygger på de hämtade styckena, inte enbart på sin träning. Två delar gör jobbet. **Retrievern** (söksystemet) hittar rätt information, och **generatorn** (språkmodellen) skriver svaret. [Amazons genomgång av RAG](https://aws.amazon.com/what-is/retrieval-augmented-generation/) beskriver samma uppdelning. För att sökningen ska hitta rätt delas dokumenten oftast upp i mindre stycken i förväg, så att bara de relevanta bitarna följer med, inte hela dokument. ## Varför är RAG viktigt för företag? RAG gör AI användbar på din egen information. Det minskar risken för påhittade svar, ger aktuella uppgifter, och varje svar går att spåra tillbaka till ett specifikt dokument. Dessutom slipper du träna om modellen varje gång din data ändras. Det sista är poängen för de flesta företag. En språkmodell kan inget om dina interna rutiner, ditt sortiment eller förra veckans prislista, eftersom den aldrig sett dem. Med RAG pekar du modellen mot dina källor, och den svarar utifrån dem. [Google Clouds genomgång](https://cloud.google.com/use-cases/retrieval-augmented-generation) lyfter just det som RAG:s främsta nytta: färska, verifierbara svar utan omträning. Kontrollen är en underskattad fördel. Du bestämmer själv vilka källor AI:n får använda, och eftersom svaret kan kopplas till ett dokument går det att granska. [Salesforce lyfter](https://www.salesforce.com/se/agentforce/what-is-rag/) just spårbarheten som en av RAG:s främsta affärsnyttor, och [IBM](https://www.ibm.com/think/topics/retrieval-augmented-generation) beskriver grundningen i hämtade källor som det som håller nere påhittade svar. Det är skillnad mot en modell som svarar fritt ur minnet, där du inte vet var uppgiften kommer ifrån. ### Så bygger vi RAG Hos oss ligger sanningen i versionshanterad text, och RAG läggs ovanpå som ett härlett lager: det hjälper en agent att hitta och navigera i informationen, men det får aldrig tyst ersätta den dokumenterade källan. Praktiskt kombinerar vi strukturerad navigering, för att hitta rätt avsnitt och kunna peka på var ett svar kommer ifrån, med hybrid sökning, alltså vektorsökning plus vanlig textsökning, och en reranker som ordnar träffarna efter relevans. Varje svar ska gå att spåra tillbaka till sitt original. Principen: strukturerad navigering och källspårning först, bred RAG sedan. ![Eteyas RAG-flöde: en fråga går via hämtning, navigation och sökning till agentkontext och ett grundat svar, allt vilar på facit i versionshanterad text som källa till sanning.](/images/blog/eteya-rag-dataflode.webp) ## RAG eller finjustering: vad är skillnaden? Kort: RAG ger modellen ny kunskap, finjustering ändrar dess beteende. RAG matar in fakta och dokument vid frågetillfället, vilket passar aktuell och egen information. Finjustering tränar i stället om modellen för att ändra ton, format eller färdigheter. De löser olika problem. | Aspekt | RAG | Finjustering | |---|---|---| | Vad det ändrar | Vilken kunskap modellen når | Hur modellen beter sig (ton, format) | | Uppdatera | Byt ut dokumenten, gäller direkt | Träna om, tar tid och kostar | | Bäst för | Egna och aktuella fakta, källhänvisning | Stil, struktur, specialiserade uppgifter | | Spårbarhet | Svaret kan kopplas till en källa | Svårt att spåra var svaret kommer ifrån | För de allra flesta svenska företag är RAG det som behövs, inte finjustering. Vill du att AI:n ska kunna era produkter, rutiner och dokument är det kunskap, inte beteende, du är ute efter. De två går att kombinera, men börja med RAG: det är billigare, snabbare att uppdatera och lättare att granska. ## När behöver du RAG, och när inte? Använd RAG när svaren ska bygga på din egen eller aktuell kunskap: supportdokument, interna policys, produktkataloger, prislistor. Du behöver inte RAG för enkla uppgifter, eller när all information du behöver redan får plats i själva frågan. Tumregeln är enkel. Måste AI:n veta något specifikt om ditt företag eller något som ändras ofta, är RAG rätt. Räcker det modellen redan kan, eller får hela underlaget plats i prompten, lägger RAG bara till komplexitet i onödan. I praktiken är RAG ofta motorn bakom en AI-agent som svarar på frågor om just ditt företag. För helheten kring hur sådana agenter fungerar för svenska företag, läs vår [pelar-guide om AI-agenter](/sv/blogg/ai-agenter/ai-agenter-svenska-smb), eller definitionen av [vad en AI-agent är](/sv/blogg/ai-agenter/vad-ar-en-ai-agent). När agenten dessutom behöver läsa och skriva i dina system i realtid används ofta MCP-protokollet i stället: RAG hämtar kunskap, MCP kopplar mot system. ## Vanliga frågor --- ### AI-agenter och EU AI Act: vad gäller 2026? **URL:** https://eteya.ai/sv/blogg/ai-agenter/ai-agenter-eu-ai-act **Sammanfattning:** Är din AI-agent reglerad av EU AI Act? De flesta hamnar i begränsad risk med transparenskrav, inte högrisk. Så avgör du nivån och vad lagen kräver av dig. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' Marknaden är kluven i två läger som sällan möts. Det ena förklarar EU AI Act i detalj men nämner aldrig ordet AI-agent. Det andra hyllar AI-agenternas affärsnytta men hoppar över regelverket helt. Den här guiden kopplar ihop dem: räknas din AI-agent som ett reglerat AI-system, vilken risknivå hamnar den i, och vad kräver lagen av dig konkret? Den korta nyheten är lugnande för de flesta svenska företag. En kundvänd AI-agent är nästan aldrig högrisk. Men det finns plikter du behöver känna till, och ett par fällor när agenten börjar agera på egen hand. ## Är AI-agenter reglerade av EU AI Act? Ja, men inte som en egen kategori. EU AI Act har ingen särskild paragraf för AI-agenter. De bedöms efter samma regler som vilket annat AI-system som helst: utifrån vad de används till och vilken risk användningen medför. Det är användningen som avgör allt, inte tekniken i sig. Det här är inte en tolkning från vår sida. EU-kommissionens egen vägledning slår fast att AI-agenter inte är en egen kategori under förordningen, och att definitionen av ett AI-system räcker för att täcka dem. [Kommissionens AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/how-are-ai-agents-addressed-within-ai-act-0) skriver rakt ut att reglerna för AI-system och GPAI-modeller också gäller AI-agenter. Kommissionen kallar själv sin hållning preliminär, eftersom tekniken rör sig fort. Konsekvensen är viktig: samma agent kan vara nästan oreglerad i ett sammanhang och tungt reglerad i ett annat. En agent som föreslår påfyllningsbeställningar i ett lager är en sak. En agent som sållar jobbansökningar är en helt annan, trots att tekniken bakom kan vara identisk. EU AI Act är förordning (EU) 2024/1689. Den trädde i kraft 1 augusti 2024 och gäller direkt i Sverige, utan att riksdagen behöver omsätta den i svensk lag. För grunderna i hur en AI-agent faktiskt fungerar har vi en [fördjupande guide till AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). ## Vilken risknivå hamnar en AI-agent i? De flesta AI-agenter som svenska företag använder hamnar i begränsad risk, alltså transparensnivån, inte i högrisk. En kundtjänstagent, en bokningsagent eller en intern assistent är begränsad risk. Högrisk blir det först när agenten används i ett av lagens särskilt utpekade känsliga områden. Förordningen delar in AI i fyra nivåer: förbjuden, hög risk, begränsad risk och minimal risk. För en AI-agent är de två mittersta de intressanta. ### Var de vanliga agenterna landar En agent som pratar med kunder hamnar i begränsad risk. Då gäller transparenskravet i Artikel 50, men inte de tunga högrisk-skyldigheterna. En agent som bara jobbar i bakgrunden mot interna system, utan att påverka beslut om människor, ligger ofta i minimal risk och är i praktiken oreglerad. Högrisk är reserverat för områdena i lagens Annex III. Dit hör bland annat rekrytering, kreditbedömning, utbildning och hälsa. En agent som screenar jobbansökningar eller poängsätter låntagare är högrisk. En agent som svarar på frågor om öppettider är det inte. Själva metoden för att klassificera steg för steg, med roller och undantag, går vi igenom i [vår guide till riskklassificering enligt EU AI Act](/sv/blogg/eu-ai-act/eu-ai-act-risk-klassificering). Här räcker det att veta var en agent normalt landar, och att avgöra om din hör till de känsliga områdena eller inte. ## Vad kräver lagen av en kundvänd AI-agent? Den viktigaste plikten är transparens. Artikel 50 kräver att en AI-agent som pratar direkt med människor är byggd så att personen förstår att det är en AI den möter. Det ska framgå senast vid första interaktionen, om det inte redan är uppenbart för en vanligt uppmärksam person. I praktiken är det en kort rad: "Du chattar med vår AI-assistent." Kravet riktar sig mot den som bygger agenten, och den närmare regeln om att informationen ska vara tydlig och komma i tid finns i [Artikel 50](https://artificialintelligenceact.eu/article/50/). Transparenskraven gäller sedan 2 augusti 2026. Det här är den plikt som faktiskt träffar de flesta agenter, och den är billig att uppfylla. Vi bygger in upplysningen från start hos våra kunder. Den kostar ingenting, och den är ändå ett krav du inte kommer runt. ## När blir en AI-agent högrisk, och vad gäller då? En AI-agent blir högrisk när den används i ett av Annex III-områdena och faktiskt påverkar beslut om människor. Då gäller långt tyngre krav, med mänsklig tillsyn i centrum. Det handlar om en liten andel av alla agenter, men träffar du området är skillnaden stor. Det finns ett undantag som ofta missas. Även inom ett känsligt område slipper en agent högrisk-stämpeln om den bara utför en snäv, förberedande eller kompletterande uppgift och inte ersätter den mänskliga bedömningen. En agent som bara strukturerar inkomna ansökningar inför en mänsklig granskning kan falla utanför. Men det finns en hård gräns: agenten räknas alltid som högrisk om den profilerar fysiska personer, oavsett hur liten uppgiften ser ut. Regeln står i [Artikel 6](https://artificialintelligenceact.eu/article/6/). ### Vad mänsklig tillsyn betyder i praktiken Är agenten högrisk kräver [Artikel 14](https://artificialintelligenceact.eu/article/14/) att den byggs så att en människa effektivt kan övervaka den under hela driften. Personen ska förstå vad agenten kan och inte kan, kunna tolka vad den gör, säga nej till ett förslag, och stoppa agenten med en stoppfunktion. Autonomi är tillåtet, men aldrig utan en hand på spaken. För de tyngsta fallen, som biometrisk fjärridentifiering, skärps kravet ytterligare: inget beslut får fattas utifrån agentens utpekande om det inte bekräftats separat av minst två personer. ## Är ni leverantör eller användare av agenten? Det avgör vilka skyldigheter ni har. Köper ni en färdig AI-agent och använder den i verksamheten är ni oftast användare, eller tillhandahållare, med lättare krav. Bygger ni en egen, eller sätter ert eget namn på en, kan ni räknas som leverantör med fullt ansvar för att den följer lagen. Gränsen är praktisk. Använder du en standardtjänst som du inte ändrar i är du användare. Beställer du en agent som byggs runt era processer, eller bygger den själv, glider du mot leverantörsrollen. Hela rolluppdelningen med vad som följer av varje roll finns i [riskklassificerings-guiden](/sv/blogg/eu-ai-act/eu-ai-act-risk-klassificering). Poängen för en agent är att avgöra vilken sida du står på innan du skriver under något. ## Vem ansvarar när en autonom agent fattar fel beslut? Ansvaret ligger kvar hos företaget, inte hos agenten. Lagen utgår från att en människa kan förstå, övervaka och vid behov stoppa agenten, och att det går att se i efterhand vad den gjorde och varför. Autonomi tar inte bort ansvaret. Den höjer kraven på spårbarhet. Det här är frågan ingen annan svensk guide tar tag i, och den är värd att stanna vid. ### Beslutsstöd eller självständigt beslut? Den viktigaste gränsen går mellan en agent som föreslår och en agent som agerar. En agent som tar fram ett underlag som en människa sedan godkänner håller dig i den lättare delen av regelverket. En agent som fattar och verkställer beslut om en person på egen hand drar in tyngre krav, både Artikel 14 om tillsyn om det är högrisk, och dataskyddsreglerna. Fattar agenten helt automatiserade beslut om en person kan GDPR ge personen rätt till mänsklig inblandning. Hur dataskydd och AI hänger ihop går vi igenom i [guiden om AI och GDPR](/sv/blogg/ai-agenter/ai-och-gdpr-sakerhet). ### Spårbarhet är ditt skydd Det som låter dig svara för agenten är loggen. För högrisk-agenter är automatisk loggning ett uttryckligt krav. För övriga är det inte tvingande, men det är det enda som gör att du kan rekonstruera vad som hände den dag någon ifrågasätter ett beslut. Praktiskt bygger vi agenter med två saker på plats: en tydlig gräns för vad de får göra själva, och en logg över varje åtgärd de tar. ## Vad gäller 2026, och vad har ändrats? Fyra saker gäller redan. De förbjudna AI-metoderna sedan 2 februari 2025, reglerna för generella AI-modeller sedan 2 augusti 2025, och transparenskraven sedan 2 augusti 2026. Högrisk-reglerna, däremot, har fått mer tid. I november 2025 la kommissionen fram ett förändringspaket kallat Digital Omnibus. Efter en politisk överenskommelse i maj antogs det i juli 2026 som [förordning (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng), publicerad i EU:s officiella tidning 24 juli och i kraft 27 juli — fem dagar före den gamla deadlinen. Högrisk-reglerna för fristående system i Annex III-områdena flyttades därmed från 2 augusti 2026 till 2 december 2027. Läs det rätt: för en typisk kundtjänst- eller automationsagent ändrade Omnibus ingenting. Transparenskravet gäller, sedan 2 augusti 2026. Det som fick mer tid är högrisk-tillämpningarna — rekrytering, kreditbedömning och liknande. Bryter du mot reglerna kan böterna bli kännbara: upp till 35 miljoner EUR eller 7 procent av den globala omsättningen för förbjudna metoder, och upp till 15 miljoner EUR eller 3 procent för brott mot övriga krav, enligt [Artikel 99](https://artificialintelligenceact.eu/article/99/). I Sverige är [Post- och telestyrelsen samordnande marknadskontrollmyndighet](https://pts.se/ai/ai-forordningen/) enligt linjen i utredningen [SOU 2025:101](https://www.regeringen.se/pressmeddelanden/2025/10/utredning-foreslar-forbud-mot-vissa-ai-system-och-sanktioner-for-bristande-dokumentation-av-hogrisk-ai/); den kompletterande svenska lagen är per augusti 2026 ännu inte antagen, men förordningen gäller direkt. Hela tidslinjen, sanktionerna och den svenska tillsynen går vi igenom i [guiden till EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). ## Hur förbereder ni era AI-agenter? Börja med en enkel självskattning. Vad gör agenten, vem påverkar den, och hur självständigt agerar den? För de flesta agenter landar du i några få konkreta åtgärder, inte i ett stort regelverksarbete. Fem frågor räcker långt: 1. **Är det ett AI-system?** För en agent är svaret nästan alltid ja. 2. **Vilket område?** Vardaglig drift, eller ett känsligt Annex III-område som rekrytering eller kredit? 3. **Leverantör eller användare?** Bygger ni den, eller använder ni en färdig? 4. **Pratar den med människor?** Då lägger ni in upplysningen om att det är en AI. 5. **Påverkar den beslut om människor?** Då behövs mänsklig tillsyn och en logg. ### Ett exempel Säg att ni har en AI-agent som svarar kunder i chatten och bokar in möten. Kör frågorna: det är ett AI-system, den jobbar i vardaglig kundtjänst och inte i något Annex III-område, ni använder en färdig tjänst, den pratar med kunder, och den påverkar inga beslut om människor i lagens mening. Resultat: begränsad risk, en enda konkret åtgärd att göra, nämligen upplysningen om att det är en AI, plus en logg som god praxis. Byt nu ut mötesbokningen mot att agenten gallrar jobbansökningar, så ändras bilden helt. Rekrytering är ett Annex III-område, agenten påverkar beslut om människor, och profilering gör den högrisk oavsett hur snäv uppgiften ser ut. Samma teknik, helt annan regelbörda. Det är därför du alltid börjar med användningen, inte med själva agenten. Den som vill ha en bredare checklista för hela verksamheten hittar den i EU AI Act-guiden. Men för en enskild agent är det här tillräckligt för att veta var ni står. Regelverket är yngre än tekniken, och det rör på sig — Digital Omnibus-förordningen är beviset. Men grundlogiken är stabil: vet vad agenten gör, var ärlig om att den är en AI, och se till att en människa kan ta över. Gör du det är du redo, både för transparenskraven som gäller nu och för högriskkraven som kommer 2027. ## Vanliga frågor --- ### Bygga AI-agent själv eller anlita en konsult? **URL:** https://eteya.ai/sv/blogg/ai-agenter/bygga-ai-agent-sjalv-vs-anlita **Sammanfattning:** Att bygga en AI-agent själv kräver mer tid, kompetens och drift än det ser ut. Här är vad varje väg kostar, risken med interna byggen och när du bör anlita. import FAQ from '@/components/blog/FAQ' Frågan kommer nästan alltid i samma ögonblick: någon i teamet har byggt en fungerande demo på en eftermiddag, och nu undrar ledningen om ni inte lika gärna kan bygga hela AI-agenten internt i stället för att betala någon annan. Demon ljuger inte, men den döljer 90 procent av arbetet. Den här guiden går igenom vad varje väg faktiskt kostar, hur stor risken är att ett internt bygge stannar av, och när det lönar sig att bygga själv kontra att anlita. ## Vad betyder det egentligen att bygga en AI-agent själv? Att bygga en AI-agent själv betyder att ditt team äger hela kedjan: datakällor, integrationer mot era system, logik, säkerhet, övervakning och drift över tid. Själva språkmodellen är den enkla delen. Det som tar tid är allt runtomkring som gör att agenten faktiskt går att lita på i produktion. En demo svarar på en fråga i ett tomt fönster. En AI-agent i drift måste hämta rätt data ur era system, agera mot ett mål, hantera fel utan att ställa till skada, och göra det varje dag för riktiga kunder. Branschdata visar att dataförberedelse är den enskilt största posten i AI-projekt, och att integrationen mot era system plus test och säkerhet ofta väger tyngre än själva modellen. ### Det är inte en chatt – det är ett system De flesta underskattar att en AI-agent är infrastruktur, inte ett chattfönster. Den kräver minneslager, verktygsanrop, orkestrering av flöden och loggning av varje beslut. Vill du förstå den tekniska arkitekturen bakom på djupet har vi en separat [teknisk guide till MCP-protokollet](/sv/blogg/ai-agenter/mcp-protokoll-teknisk-guide) som visar hur en agent kopplas mot era verktyg på ett standardiserat sätt. Skillnaden mot en enkel bot är också värd att läsa på innan beslutet. Vi har gått igenom [vad som skiljer en AI-agent från en chatbot](/sv/blogg/ai-agenter/ai-agent-vs-chatbot) i åtta dimensioner, och det är ofta där förväntningarna spricker: en agent som ska agera självständigt är en helt annan ingenjörsuppgift än en bot som svarar på vanliga frågor. ## Vad kostar en AI-agent som du bygger internt? Internt bygge kostar mer än fakturan från en byrå, eftersom den dyraste posten är personen som bygger. En AI-utvecklare i Sverige ligger på ungefär 56 000 kronor i månaden, och en senior AI-ingenjör eller AI-konsult på 70 000–85 000 kronor enligt [lönestatistik för AI-roller 2026](https://teknoradar.se/karriar/ai-jobb-sverige/). Lägg till drift, och totalen växer snabbt. Den synliga kostnaden är lön och tid. Den osynliga är driften efteråt. Internationella uppskattningar för en AI-agent i produktion landar på betydande månadskostnader för modellanrop, infrastruktur, övervakning och löpande justering, och [analyser av total ägandekostnad](https://www.keyholesoftware.com/ai-software-development-cost-2026/) visar att drift lägger på 15–25 procent årligen ovanpå själva bygget. En agent som "är klar" är sällan klar. ### Räkneexemplet de flesta missar Säg att en utvecklare lägger tre månader på ett första internt bygge. Bara lönekostnaden blir runt 170 000 kronor, innan en enda kund har mött agenten. Sedan tillkommer drift och underhåll månad efter månad, plus den tid teamet inte lägger på er kärnprodukt under tiden. Alternativkostnaden är ofta den största posten av alla. Till jämförelse bygger vi en första AI-agent från 45 000 kronor, med en drift på 5 000–15 000 kronor i månaden beroende på omfattning och ingen bindningstid. Utan avtal betalar du bara för det agenten faktiskt förbrukar, från ören till enstaka kronor per ärende. Vill du se hela kostnadsbilden sida vid sida har vi brutit ner [vad en AI-agent kostar i Sverige](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige) med alla tre vägarna. ## Hur stor är risken att ett internt AI-bygge misslyckas? Risken är hög, och det är den faktor som väger tyngst i beslutet. RAND Corporation dokumenterade att drygt 80 procent av företagens AI-projekt aldrig levererar det affärsvärde de lovade, ungefär dubbelt så hög andel som vanliga IT-projekt utan AI. Siffrorna upprepar sig hos andra. Gartner konstaterade i april 2026 att [bara 28 procent av AI-projekt inom infrastruktur och drift levererar den utlovade avkastningen](https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns), och att vart femte projekt kollapsar helt. MIT:s forskningsinitiativ NANDA fann att 95 procent av organisationerna inte ser någon mätbar avkastning från sina generativa AI-piloter alls. ### Varför så många byggen stannar av Det intressanta i [genomgångar av varför projekten misslyckas](https://www.pertamapartners.com/insights/ai-project-failure-statistics-2026) är att orsaken sällan är tekniken. Felen handlar om otydligt syfte, svag datagrund och att ledningens engagemang rinner ut, inte om att modellen var för dum. Det är just den erfarenheten du köper när du anlitar någon som gjort det förut. En extern partner har redan gått in i de väggarna på andras bekostnad och vet var de sitter. ## När lönar det sig att bygga själv – och när att anlita? Bygg själv när AI-agenten är er kärnprodukt och en konkurrensfördel ni måste äga, och när ni redan har ett team som kan driva den i åratal. Anlita när ni vill ha resultat snabbt, saknar intern AI-kompetens, och vill ha en bevisad avkastning i stället för ett forskningsprojekt. Tumregeln är enkel. Bygger ni något som ska vara er hemlighet och er konkurrensfördel, och har råd att låta ett team lära sig under ett år, då är internt bygge rätt. Vill ni i stället automatisera en intern process och se besparingen i kvartalet, är det sällan värt att uppfinna hjulet. ### Tecken på att ni bör bygga internt Ni har redan ML-ingenjörer i huset, AI:n är en del av det ni säljer, och ni planerar att skala den över många år där ägandet av infrastrukturen sänker kostnaden på sikt. Då bär det interna bygget sin egen risk, eftersom kompetensen ändå ska finnas kvar. ### Tecken på att ni bör anlita Ni vill lösa ett konkret problem, inte starta en AI-avdelning. Ni har ingen som kan ta över driften om den som byggde slutar. Och ni vill veta vad det kostar och vad ni får innan ni börjar. Många företag väljer att anlita just för att undvika de höga felfrekvenserna och de utdragna tidsplanerna. ## Vad är en hybridmodell mellan att bygga och anlita? En hybridmodell betyder att du anlitar en partner för att få AI-agenten i drift snabbt, och bygger upp intern kompetens parallellt i lugnare takt. Du får värdet direkt och kan ta över driften själv senare, utan att börja från ett tomt blad med full risk. Det är ofta den klokaste vägen för ett företag som varken vill vänta ett år eller låsa in sig hos en leverantör. Du ber om en arkitektur som inte binder dig, och om dokumentationen som krävs för att någon annan ska kunna ta vid. Då blir överlämningen en planerad punkt, inte en kris den dag en nyckelperson slutar. Många företag gör just det här [som ett kombinerat upplägg](https://servicesground.com/blog/build-vs-buy-ai-agents/), inte ett slutgiltigt val. De köper sig tid och ett bevisat resultat, och flyttar hem det de vill äga den dag kompetensen finns på plats. Risken stannar hos den som redan har gått vägen, tills ni själva är redo att bära den. ## Vad får du när du anlitar Eteya i stället? Du får en AI-agent i drift på 2–6 veckor, byggd mot en fast omfattning, av någon som redan har bevisade resultat hos svenska företag. Du slipper rekrytera, slipper äga risken för ett bygge som stannar av, och betalar för en lösning som är gjord för att tjäna in sig snabbt. Det konkreta är lättast att se i siffrorna. Sannegårdens Pizzeria i Karlskoga minskade sitt matsvinn med 32 procent och sparar runt 315 000 kronor om året, med en återbetalning på under tre månader. NordicRank automatiserade 18 processer, frigjorde 13,4 timmar i veckan och fick en payback på fyra månader. Inget av det krävde att de anställde en enda AI-utvecklare. ### Du äger resultatet, inte bara koden En vanlig invändning mot att anlita är att du blir beroende. I praktiken är det tvärtom. Du får en agent som löser problemet, dokumentationen som hör till, och en partner som redan vet var fallgroparna sitter. Vill du fördjupa dig i helheten innan ni bestämmer er, börja med vår översikt över [hur AI-agenter fungerar för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). Beslutet bygga eller anlita handlar till slut inte om vem som skriver koden. Det handlar om var ni vill bära risken, och hur snabbt ni vill se resultatet. ## Vanliga frågor --- ### AI och GDPR: är det säkert för företag? **URL:** https://eteya.ai/sv/blogg/ai-agenter/ai-och-gdpr-sakerhet **Sammanfattning:** AI och GDPR: är det säkert att låta AI hantera företagets data? Så funkar laglig grund, de största riskerna, ChatGPT-fällan och en checklista att följa. import FAQ from '@/components/blog/FAQ' AI och GDPR är frågan som stoppar fler AI-projekt än någon teknik gör: vågar du släppa in AI på din kunddata? Det korta svaret är att AI inte är osäkert i sig. Risken sitter i hur datan flödar, vilken tjänst du väljer och vilka rutiner du har. Den här artikeln håller sig till dataskyddet i praktiken: vad GDPR faktiskt kräver, var data läcker, om ChatGPT är säkert att använda och en checklista du kan följa innan AI rör en enda personuppgift. Reglerna i EU:s AI-förordning är en egen sak, och dem går vi igenom i [guiden om EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). ## Är AI säkert för företag? AI är inte osäkert i sig. Säkerheten avgörs av vilken tjänst du väljer och vilka rutiner du sätter, inte av tekniken. Enligt [Integritetsskyddsmyndighetens vägledning om GDPR och AI](https://www.imy.se/verksamhet/dataskydd/innovationsportalen/vagledning-om-gdpr-och-ai/) gäller dataskyddsreglerna så snart personuppgifter behandlas när AI byggs eller används, och ditt företag är då normalt personuppgiftsansvarigt med ansvar för att det sker lagligt. Samma underliggande modell kan alltså vara både säker och osäker. ChatGPT i en gratis privat inloggning och samma modell via ett företagsavtal med datalagring i EU är tekniskt nästan identiska, men dataskyddsmässigt två helt olika världar. Det är där de flesta tänker fel: de frågar "är AI säkert?" när den verkliga frågan är "hur använder vi AI?". ### Vem bär ansvaret för datan? GDPR skiljer på personuppgiftsansvarig och personuppgiftsbiträde, och skillnaden avgörs av vem som bestämmer ändamålet, inte av vem som äger tekniken. Bestämmer du vad datan ska användas till är du ansvarig. AI-leverantören som behandlar uppgifterna åt dig är biträde. Ansvaret går alltså inte att outsourca till en leverantör genom att skylla på deras modell. Tumregeln för hela artikeln: när du kontrollerar dataflödet kontrollerar du risken. ## Vad säger GDPR om AI? GDPR ställer tre grundkrav innan AI rör personuppgifter: du behöver en rättslig grund (artikel 6), ett personuppgiftsbiträdesavtal med leverantören (artikel 28) och tekniska säkerhetsåtgärder (artikel 32). Europeiska dataskyddsstyrelsen (EDPB) slog dessutom i [yttrande 28/2024](https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en) fast att en AI-modell inte automatiskt räknas som anonym. ### Rättslig grund och dataminimering Innan en personuppgift matas in i ett AI-verktyg måste du ha en av de sex rättsliga grunderna i [artikel 6 i GDPR](https://eur-lex.europa.eu/legal-content/SV/TXT/HTML/?uri=CELEX:32016R0679). För företag är det oftast samtycke, fullgörande av avtal eller berättigat intresse. EDPB bekräftar att berättigat intresse kan funka, men då krävs en intresseavvägning i tre steg som du kan visa upp: att intresset är berättigat, att behandlingen verkligen är nödvändig för det, och att den inte väger tyngre än individens rättigheter. Hela bedömningen ska vara gjord innan du börjar, inte konstrueras i efterhand om någon klagar. De två principer som är svårast att hålla med AI är ändamålsbegränsning och uppgiftsminimering: mata in det modellen faktiskt behöver, inte allt som råkar finnas tillgängligt. Ett vanligt misstag är att ladda upp ett helt kundregister för en uppgift som bara kräver en kolumn. ### Biträdesavtal och faktiskt ansvar Så fort en leverantör behandlar personuppgifter åt dig krävs ett skriftligt [personuppgiftsbiträdesavtal](https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/personuppgiftsansvariga-och-personuppgiftsbitraden/personuppgiftsbitradesavtal/) som reglerar instruktioner, säkerhet och underbiträden. Att tillsynen är på riktigt visade italienska dataskyddsmyndigheten Garante, som bötfällde OpenAI 15 miljoner euro i december 2024, de första GDPR-böterna mot ett generativt AI-verktyg. Det är ingen skräcktaktik. Det visar bara att reglerna gäller även de största leverantörerna. ### Vad innebär säkerhetskraven i praktiken? Artikel 32 kräver lämpliga tekniska och organisatoriska åtgärder, och för AI betyder det några konkreta saker: kryptera data i transit och i vila, styr vem som får mata in och läsa, pseudonymisera där det går och granska regelbundet att skyddet fortfarande håller. Vad som är lämpligt avgörs av hur känslig datan är. Ett verktyg som sammanfattar offentliga texter behöver mindre skydd än ett som hanterar patientuppgifter, men någon nivå av åtgärd krävs alltid när personuppgifter är inblandade. Det är också här dokumentationen blir din vän: kan du visa vilka åtgärder du valt och varför, har du redan halva svaret om en kund eller myndighet frågar. ## Vilka är de största AI-säkerhetsriskerna? Den största läckan är sällan leverantören, utan medarbetaren som klistrar in kunddata i ett gratis AI-verktyg. Tänk i tre led: vilken data flödar in i AI:n, vad kan gå fel och hur reducerar du risken? [IBM:s rapport för 2025](https://www.ibm.com/think/insights/data-matters/cost-of-a-data-breach) visar att sådan ostyrd användning fanns med i ungefär 20 procent av alla dataintrång och drev upp kostnaden med i snitt 670 000 dollar per intrång. ### Sex ställen där data kan läcka Riskerna är konkreta och går att täppa till en i taget: - **Prompt-läckage:** känslig data klistras in i en prompt och hamnar utanför din kontroll. - **Träning på din input:** leverantören använder dina inmatningar för att förbättra modellen. - **Lagring och retention:** prompts och svar sparas längre än du tror. - **Underbiträden:** leverantören skickar vidare datan till en tredje part. - **Bristande åtkomstkontroll:** fler än nödvändigt kan mata in och läsa datan. - **Shadow-AI:** anställda använder egna, ostyrda verktyg på jobbdata. ### Shadow-AI: den dolda läckan Den sista punkten är den farligaste, just för att den är osynlig. När Samsungs ingenjörer 2023 klistrade in källkod i ChatGPT tre gånger på ungefär tre veckor införde företaget ett internt AI-förbud. Mönstret är brett: enligt flera kartläggningar matar omkring tre av fyra anställda som använder AI in arbetsdata i chatbottar, ofta via privata konton som arbetsgivaren inte ser. Det är sällan illvilja, utan bekvämlighet, och det är just därför ett rakt förbud sällan håller i längden. IBM noterar att en stor majoritet av de organisationer som drabbats av AI-relaterade intrång saknade grundläggande åtkomstkontroller. Lösningen är inte ett förbud, utan ett godkänt verktyg, en tydlig regel om vad som aldrig får klistras in, och ett enkelt alternativ som är lika smidigt som gratisverktyget. ## Är ChatGPT GDPR-säkert för företag? Det beror på vilken ChatGPT och hur du använder den. Konsumentversionen (Free, Plus och Pro) tränar på dina konversationer som standard om du inte stänger av det. Företagsversionerna (Enterprise, Business och Edu) och API:t tränar inte på din affärsdata som standard, och kan med biträdesavtal och datalagring i EU vara GDPR-förenliga. ### Stäng av träningen i konsumentversionen Använder teamet gratis-ChatGPT på riktig data är första åtgärden att stänga av modellträning under Inställningar, Datakontroller, så att dina chattar inte används för att förbättra modellen. Det är gjort på tio sekunder, men det måste faktiskt göras, och det löser bara en av riskerna ovan. ### Ingen träning är inte samma sak som ingen lagring Även när en tjänst inte tränar på din data kan den spara den. [OpenAI:s företagsvillkor](https://openai.com/enterprise-privacy/) beskriver att API-data kan sparas en kortare period för missbruksövervakning, med möjlighet till nollretention för behöriga kunder, samt datalagring och körning inom EU. Anthropic beskriver på motsvarande sätt att [Claude inte tränar på din affärsdata](https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training). De stora leverantörerna har dessutom byggt ut datalagring inom EU för företagskunder, och Claude går att köra i europeiska regioner via molnplattformar som AWS Bedrock och Google Vertex. Skillnaden mot konsumentversionen är alltså inte tekniken, utan avtalet, var datan lagras och vilka inställningar du valt. Den verkliga risken är inte verktyget, utan att det används ostyrt. ## Hur bygger du AI säkert med privacy by design? Bygg in skyddet från start i stället för att laga i efterhand: välj en leverantör med data inom EU, teckna biträdesavtal, stäng av träning, sätt en raderingsrutin och minimera uppgifterna innan de matas in. EDPB lägger ett tydligt ansvar på den som använder AI att kontrollera hur modellen byggts, så att ett brott längre upp i kedjan inte smittar av sig på dig. Praktiskt börjar privacy by design innan första prompten. Ta bort eller pseudonymisera namn och personnummer som modellen inte behöver, lägg känsliga uppgifter bakom en separat åtkomstkontroll och bestäm i förväg hur länge data får sparas. Det dyraste misstaget är att samla in allt med tanken att rensa sedan. Rensa i stället innan datan ens når AI:n, för det som aldrig matas in kan heller aldrig läcka. Vi är själva en AI-byrå, så vi får leva som vi lär. I praktiken betyder det att all data behandlas inom EU, att vi tecknar biträdesavtal vid behov, bygger med privacy by design och aldrig låter din data användas för att träna AI-modeller. Vi är dessutom verktygsoberoende, så valet av plattform styrs av vad som är säkrast för dig, inte av en licens vi råkar sälja. Det viktiga är inte att du väljer oss, utan att det här är kraven du bör ställa på vem du än anlitar. Hur ett AI-projekt ser ut från början till slut beskriver vi i [guiden om AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). ## Checklista: AI och dataskydd Här är en handfast lista att gå igenom innan AI rör personuppgifter. Ta den uppifrån och ner, för de första punkterna avgör de senare. 1. **Kartlägg dataflödet.** Lista vilka prompts, dokument och kund- eller personuppgifter som går in i AI:n och vart de tar vägen. Du kan inte skydda data du inte vet att du delar. 2. **Bestäm rättslig grund och minimera.** Fastställ grunden enligt artikel 6 innan AI rör data, och mata bara in det som faktiskt behövs. Känsliga uppgifter (hälsa, etnicitet) kräver dessutom ett uttryckligt undantag. 3. **Välj EU-data och teckna biträdesavtal.** Använd en leverantör som lagrar data inom EU eller EES och reglera behandlingen i ett DPA enligt artikel 28. Hamnar data utanför EU krävs giltig överföringsmekanism och en egen bedömning. 4. **Stäng av träning på din input.** Se till att det sker både i inställningen och i avtalet. En modell är inte automatiskt anonym, och risken att den memorerar uppgifter är reell. 5. **Sätt retention.** Bestäm hur länge prompts och data sparas, och kontrollera att radering faktiskt sker tekniskt. Många tjänster sparar historik som standard. 6. **Ge ett godkänt verktyg och utbilda.** Ett sanktionerat verktyg med en enkel regel om vad som aldrig får klistras in är det som faktiskt stoppar shadow-AI. 7. **Logga och begränsa åtkomst.** Styr vilka roller som får mata in vilken data, och logga användningen så att ett eventuellt intrång går att utreda. 8. **Gör en konsekvensbedömning vid behov.** Vid känsliga uppgifter, profilering eller storskalig behandling krävs en DPIA enligt artikel 35, gjord före driftsättning. 9. **Ha en incidentrutin.** Förbered [72-timmarsanmälan till IMY](https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/personuppgiftsincidenter/) och kräv i avtalet att leverantören larmar dig utan onödigt dröjsmål. 10. **Var transparent och granska leverantören.** Berätta för kunder och anställda hur AI används, och kontrollera att modellen inte uppenbart byggts på olagligt insamlad data. Går du igenom de tio punkterna har du inte bara minskat risken, du har också det underlag du behöver om en myndighet eller en kund frågar hur du hanterar data. Det är där säker AI går från känsla till något du kan visa. ## Vanliga frågor --- ### EU AI Act-sanktioner: vad företag faktiskt riskerar **URL:** https://eteya.ai/sv/blogg/eu-ai-act/eu-ai-act-sanktioner-och-undantag **Sammanfattning:** EU AI Act-sanktioner kan nå 35 miljoner euro, men ingen har bötfällts än. Här är vad svenska företag faktiskt riskerar 2026 och vilka undantag som sänker risken. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' Rubrikerna skrämmer: böter upp till 35 miljoner euro eller 7 procent av global omsättning. Men i juni 2026 har ingen enda bötfällts under hela EU AI Act, trots att de tyngsta reglerna gällt i över ett år. Den här guiden reder ut vad EU AI Act-sanktioner faktiskt innebär för ett svenskt företag, när de börjar bita, och vilka undantag som sänker din risk på riktigt. Det viktigaste först: lagen är skarp på pappret, men proportionalitet för småbolag är inbyggd, och flera undantag är gjorda för just er. ## Vad kostar det att bryta mot EU AI Act? EU AI Act-sanktioner regleras i [Artikel 99](https://artificialintelligenceact.eu/article/99/) och delas i tre nivåer: förbjudna AI-praktiker kostar upp till 35 miljoner euro eller 7 procent av global omsättning, andra brott upp till 15 miljoner euro eller 3 procent, och vilseledande information till myndighet upp till 7,5 miljoner euro eller 1 procent. För stora bolag gäller det högre av belopp och procent. Men för små och medelstora företag, inklusive startups, gäller enligt Artikel 99(6) det **lägre** av de två. Det är en medveten proportionalitetsregel som ska skydda mindre aktörer från att krossas av en bot. De tre nivåerna ser ut så här bredvid varandra: | Nivå | Tak stora bolag | Tak mindre företag (det lägre av) | Vad det täcker | Drabbar typiskt | |---|---|---|---|---| | Förbjudna praktiker | 35 M€ eller 7 % av global omsättning | 7 % av omsättningen | Överträdelse av Artikel 5 | den som kör manipulativ AI eller social poängsättning | | Övriga skyldigheter | 15 M€ eller 3 % av global omsättning | 3 % av omsättningen | brott mot hög-risk-kraven (Artikel 16–27) och GPAI-regler | den som driftsätter ett hög-risk-system utan att uppfylla kraven | | Vilseledande information | 7,5 M€ eller 1 % av global omsättning | 1 % av omsättningen | felaktiga eller ofullständiga uppgifter till myndighet | den som lämnar oriktig dokumentation vid tillsyn | Konkret: en svensk startup med 20 miljoner kronor i omsättning som bryter mot en förbjuden praktik riskerar 7 procent av omsättningen, alltså 1,4 miljoner kronor, inte 35 miljoner euro. Sanktionerna är fortfarande tunga, men taket följer din storlek. Det blir tydligare med flera storlekar bredvid varandra. Eftersom taket för ett mindre företag är procenten av omsättningen, inte eurobeloppet, skalar boten med hur stor du är och vilken nivå överträdelsen ligger på: | Omsättning | Förbjuden praktik (7 %) | Hög-risk-brott (3 %) | Vilseledande uppgift (1 %) | |---|---|---|---| | 20 Mkr (litet) | 1,4 Mkr | 600 000 kr | 200 000 kr | | 80 Mkr (medelstort) | 5,6 Mkr | 2,4 Mkr | 800 000 kr | | 200 Mkr (större) | 14 Mkr | 6 Mkr | 2 Mkr | Poängen är att eurotaken (35, 15 och 7,5 miljoner euro) i praktiken aldrig binder ett mindre svenskt företag. Det är procenten som styr, och då blir avståndet mellan nivåerna det som avgör risken: en förbjuden praktik kostar sju gånger mer än ett rent dokumentationsfel vid samma omsättning. Värt att förstå är vad de tre nivåerna faktiskt täcker, eftersom de flesta mindre företag aldrig hamnar i den översta. Den högsta nivån gäller de uttryckligen förbjudna praktikerna i Artikel 5, sådant som social poängsättning av medborgare eller manipulativ AI. Den mellersta nivån gäller brott mot skyldigheterna för hög-risk-system, alltså att man kör ett system i en känslig tillämpning utan att uppfylla kraven. Den lägsta nivån gäller att lämna felaktig eller vilseledande information till en myndighet under tillsyn. ### Vad de tre nivåerna täcker Ett typiskt mindre företag med standardverktyg, en kundtjänst-chatbot och intern produktivitets-AI, löper i praktiken ingen risk för den högsta nivån. Ett medelstort bolag med 80 miljoner kronor i omsättning som missar dokumentationskraven för ett hög-risk-system tittar på upp till 3 procent, alltså 2,4 miljoner kronor, och då bara om det går så långt som till en bot. Vi går igenom hela bötesregimen och de fyra risknivåerna i [vår grundguide till EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). ## Har någon faktiskt bötfällts än? Nej. Per juni 2026 har ingen bötfällts under hela EU AI Act, trots att förbudet mot vissa AI-praktiker (Artikel 5) gällt sedan 2 februari 2025. Det bekräftas av [EU-parlamentets utredningstjänst](https://epthinktank.eu/2026/03/18/enforcement-of-the-ai-act/) och av oberoende juristbevakning, som inte hittat ett enda avgjort tillsynsärende. Skälen är strukturella, inte en signal om att lagen är tandlös. Tillsynsmaskineriet är ännu inte på plats: enligt [EU-parlamentets utredningstjänst](https://epthinktank.eu/2026/03/18/enforcement-of-the-ai-act/) omfattade listan över utsedda kontaktpunkter i mars 2026 bara åtta stycken, av 27 medlemsstater, sju månader efter deadline den 2 augusti 2025. AI-kontorets fulla bötesrätt över generella AI-modeller aktiverades i augusti 2026, och hög-risk-kraven börjar gälla först i december 2027. Flera medlemsstater, däribland Sverige, har dessutom inte färdig nationell lagstiftning som pekar ut vem som får utfärda böterna. Det här är en övergångsfas, inte ett permanent läge. Förbjudna praktiker kan i teorin bötfällas redan i dag, och första gången en myndighet tar ett ärende hela vägen sätts en standard som resten följer. Erfarenheten från GDPR är tydlig: de första åren var lugna, sedan kom besluten. Mönstret syns i siffrorna. Under 2023 utfärdades runt 2,1 miljarder euro i GDPR-böter inom EU, mer än 2019, 2020 och 2021 sammanlagt, och snittboten steg från omkring 500 000 euro 2019 till 4,4 miljoner euro 2023 enligt [statistik från GDPR Enforcement Tracker sammanställd av Statista](https://www.statista.com/chart/30053/gdpr-data-protection-fines-timeline/). Den samlade bötessumman har enligt [CMS GDPR Enforcement Tracker Report](https://cms.law/en/int/publication/GDPR-Enforcement-Tracker-Report/numbers-and-figures) passerat 6 miljarder euro fördelat på över 2 600 beslut fram till mars 2026. Den som byggde sin GDPR-compliance under de lugna första åren slapp göra det under granskning. Samma fönster är öppet nu för AI Act-sanktioner. 2026 är med andra ord ett uppbyggnadsår. Slutsatsen för ett mindre företag är inte att ignorera lagen, utan att använda tidsfönstret till att bli klar i lugn och ro innan tillsynen växlar upp. De som väntar tills första boten faller får i stället bråttom under press. Och GDPR gäller redan parallellt med AI Act: hur du håller AI inom dataskyddet i praktiken går vi igenom i [guiden om AI och GDPR för företag](/sv/blogg/ai-agenter/ai-och-gdpr-sakerhet). ### Vad GDPR-parallellen säger om infasningen Ställer du de två regelverken bredvid varandra blir likheten konkret. Båda har ett högt maxtak, en trög start och en upptrappning som kommer först när tillsynen mognar: | | GDPR | EU AI Act | |---|---|---| | Gäller från | maj 2018 | februari 2025 (förbud), augusti 2026 (GPAI) | | Maxtak | 20 M€ eller 4 % av omsättning ([Artikel 83](https://gdpr-info.eu/art-83-gdpr/)) | 35 M€ eller 7 % av omsättning | | Första åren | låg aktivitet, snittbot omkring 500 000 € (2019) | ingen bot utfärdad per juni 2026 | | När det vände | 2,1 md € i böter under 2023, snittbot 4,4 M€ | tillsyn fasas in 2026–2028 | Tabellen är en egen sammanställning av siffrorna ovan, inte en officiell jämförelse. Den visar varför 2026 liknar GDPR:s år 2018: regelverket gäller, taken är höga, men besluten har inte börjat komma. Den som läser AI Act-sanktioner mot GDPR:s facit ser att lugnet är tillfälligt. ## När börjar EU AI Act-sanktioner bita på riktigt? Sanktionerna fasas in i takt med att kraven träder i kraft. Förbjudna praktiker är redan sanktionerbara sedan februari 2025. Sedan 2 augusti 2026 är AI-kontorets bötesrätt över generella AI-modeller aktiv och transparenskraven sanktionerbara. Hög-risk-kraven kommer först i december 2027. Här är tidslinjen som gäller för svenska företag: | Krav | Sanktionerbart från | |---|---| | Förbjudna AI-praktiker (Artikel 5) | 2 februari 2025 (gäller) | | AI-kunskapskravet (Artikel 4) | 2 februari 2025 (gäller) | | Generella AI-modeller, GPAI (Artikel 101) | 2 augusti 2026 (gäller) | | Transparens om AI-innehåll (Artikel 50) | 2 augusti 2026 (gäller); märkning av syntetiskt innehåll har övergångsfrist till 2 december 2026 | | Hög-risk fristående system (Annex III) | 2 december 2027 (beslutat genom Omnibus) | | Hög-risk i reglerade produkter (Annex I) | 2 augusti 2028 (beslutat genom Omnibus) | Senareläggningarna är beslutade sedan 27 juli 2026 och tabellen ovan visar de datum som gäller. Transparens och GPAI är redan sanktionerbara – planera dokumentationsarbetet därefter. Vill ni veta exakt vilken nivå ert system hamnar på, börja med [vår steg-för-steg-guide till riskklassificering](/sv/blogg/eu-ai-act/eu-ai-act-risk-klassificering). ## Hur fungerar EU AI Act-sanktioner för generella AI-modeller? Generella AI-modeller, som de stora språkmodellerna bakom ChatGPT och Claude, har en egen sanktionsregim i [Artikel 101](https://artificialintelligenceact.eu/article/101/). Här är EU-kommissionens AI-kontor ensam behörig myndighet, inte den svenska. Böterna ligger på upp till 15 miljoner euro eller 3 procent av global omsättning. Den här regimen spelar roll indirekt för de flesta svenska företag. Sanktionerna riktar sig mot dem som bygger och tillhandahåller modellerna, alltså de stora leverantörerna, inte mot företaget som använder ChatGPT i sin verksamhet. Som användare är ni tillhandahållare i lagens mening, med betydligt lättare skyldigheter än modellbyggaren. En detalj är ändå värd att känna till. Det finns en frivillig uppförandekod för generella AI-modeller, färdigställd i juli 2025. Den är inte tvingande, men en leverantör som ansluter sig och följer den riskerar lägre böter om en överträdelse ändå konstateras. Det säger något om hur tillsynen är tänkt att fungera: samarbete och dokumenterad god vilja väger tungt, både för modellbyggare och för vanliga företag. Den som kan visa att man försökt göra rätt behandlas mildare än den som ignorerat reglerna. ## Vad ändrar Digital Omnibus för svenska företag? Digital Omnibus är EU:s paket för att förenkla och senarelägga delar av AI-förordningen – och sedan den 27 juli 2026 är det gällande rätt. [Förordning (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng) publicerades i EU:s officiella tidning den 24 juli 2026, fem dagar före den gamla högrisk-deadlinen. För mindre företag innehåller förordningen två viktiga delar. Den första är senareläggningarna: hög-risk-systemen i Annex III skjuts till december 2027 och de i reglerade produkter till augusti 2028. Den andra är att en ny kategori, små midcap-bolag (**färre än 750 anställda och högst 150 miljoner euro i omsättning**), läggs till bredvid dagens definition av små och medelstora företag på 250 anställda och 50 miljoner euro. Fler företag får därmed del av proportionaliteten och de förenklade kraven, som förenklad dokumentation, prioriterad sandlådetillgång och anpassade bötestak. Paketet inför också ett nytt förbud, mot AI som skapar icke-samtyckt intimt material och övergreppsmaterial, med start 2 december 2026. Det visar att senareläggningarna inte betyder att lagen luckras upp överlag: deadlines flyttas där standarderna inte hunnit bli klara, samtidigt som de tydligaste riskerna skärps. Riktningen är förenkling av administrationen, inte mildare hållning mot faktiska skador. Paketet är nu publicerat och de nya datumen gäller. Men se senareläggningen som marginal, inte ledighet: transparenskraven och GPAI-tillsynen är redan skarpa, och dokumentationsarbetet för högrisk tar lika många timmar oavsett när ni börjar. Gjort i lugn takt blir det dessutom bättre. Använd tiden – förlita er inte på den. ## Vilka undantag finns för småföretag? Förordningen har inbyggda lättnader för företag utöver bötesproportionaliteten. Den viktigaste är förenklad teknisk dokumentation: enligt [Artikel 11](https://artificialintelligenceact.eu/article/11/) får små och medelstora företag som bygger hög-risk-system lämna dokumentationen i förenklad form, via en mall som kommissionen tar fram. Undantaget tar bort byråkratisk tyngd, men inte de substantiella kraven på att systemet ska vara säkert och granskningsbart. Ni slipper alltså inte tänka på risk, men ni slipper en del av pappersarbetet som annars är dimensionerat för storbolag. Utöver detta ska tillsynsmyndigheterna enligt förordningen ta särskild hänsyn till mindre företags ekonomiska livskraft när böter bestäms, och anpassa avgifter för sandlådor efter företagets storlek. ### Vad förenklingen betyder i praktiken I praktiken betyder förenklingen att ni dokumenterar samma sak som ett storbolag, fast med mindre formalia. En kort beskrivning av vad systemet gör, vilka data det använder och hur ni granskar det räcker längre för ett mindre bolag än för en koncern. Det undantaget får dock inte förväxlas med att slippa klassificera systemen. Ni måste fortfarande veta vilken risknivå varje AI-system ligger på, för det är den bedömningen som avgör om dokumentationskraven över huvud taget gäller er. De flesta system hos mindre företag landar i låg eller begränsad risk, där bördan är minimal från början. Den som vill veta exakt vad som måste dokumenteras hittar en färdig mall i [vår guide till EU AI Act-dokumentation](/sv/blogg/eu-ai-act/eu-ai-act-dokumentation-mall). ## Kan en regulatorisk sandlåda skydda er mot böter? Ja. En regulatorisk sandlåda enligt [Artikel 57](https://artificialintelligenceact.eu/article/57/) är en kontrollerad testmiljö där ni kan utveckla och pröva ett AI-system under myndighetens överinseende. Det starkaste skyddet är att inga administrativa böter ska dömas ut för överträdelser som sker inom sandlådan, så länge ni följer planen i god tro. Sandlådan ger tre saker: en skyddad miljö att testa i innan lansering, prioriterad tillgång för just mindre företag och startups, och en slutrapport från myndigheten som snabbar upp den slutliga efterlevnadsbedömningen. För ett mindre bolag är det här ett sätt att bygga och bevisa compliance utan att riskera en bot på vägen. Haken i augusti 2026 är att de flesta länder, inklusive Sverige, ännu inte har en fullt operativ AI-sandlåda. Omnibus-förordningen flyttade dessutom medlemsstaternas sandlåde-deadline till 2 augusti 2027. Den svenska linjen är att [PTS upprättar den obligatoriska sandlådan](https://pts.se/ai/ai-forordningen/), men den är inte i drift. Sandlådan är alltså en möjlighet att planera in, inte att använda i dag. För ett mindre företag som planerar ett system i en känsligare tillämpning är rådet att hålla sandlådan i åtanke som en framtida väg. När den svenska sandlådan väl öppnar blir den ett av de billigaste sätten att bygga och bevisa compliance, särskilt eftersom skyddet mot böter under testperioden tar bort det som annars är skrämmande med att lansera tidigt. Den som redan har sin riskklassificering och dokumentation klar kommer dessutom snabbare genom en sandlådeprocess, eftersom grundarbetet då redan är gjort. ## När gäller R&D- och öppen källkod-undantagen? Två generella undantag faller ofta företag till godo. Forsknings- och utvecklingsundantaget i [Artikel 2](https://artificialintelligenceact.eu/article/2/) innebär att aktiviteter före marknadsintroduktion inte träffas av förordningen. Öppen källkod-undantaget innebär att fritt licensierad AI inte regleras, så länge den inte är hög-risk, förbjuden eller transparenspliktig. R&D-undantaget är praktiskt viktigt: ni kan bygga och testa en prototyp internt utan full compliance-börda. Skyddet upphör i samma stund systemet sätts i drift eller släpps på marknaden, så det är ett utvecklingsfönster, inte en permanent frizon. Testning under verkliga förhållanden räknas dessutom som drift. ### Gränsen för öppen källkod Öppen källkod-undantaget har en tydlig gräns: licensen i sig räcker inte. Tar ni en öppen modell och bygger en hög-risk-tillämpning, till exempel kreditbedömning, gäller alla krav ändå. Undantaget skyddar delning av verktyg, inte riskfylld användning av dem. Samma logik gäller generella AI-modeller där öppna varianter utan systemrisk slipper en del av dokumentationskraven. Det finns dessutom ett snävare undantag för rent vetenskaplig forskning, där AI som uteslutande tas fram för forskningsändamål faller helt utanför förordningen. Gränsen går vid syftet: så fort något kommersiellt syfte tillkommer försvinner undantaget. För ett mindre företag är den praktiska lärdomen att undantagen är generösa i utvecklingsfasen men stängs i samma stund tekniken börjar tjäna pengar. Bygg och experimentera fritt, men räkna med att full compliance gäller från första skarpa kunden. Det är sällan en nackdel, eftersom det är då systemet ändå behöver vara säkert och granskningsbart. ## Hur undviker ni att bli testfallet? Det effektivaste skyddet är att inte vara den uppenbara överträdaren när tillsynen vaknar. Ett ärende inleds oftast genom ett klagomål: enligt [Artikel 85](https://artificialintelligenceact.eu/article/85/) kan vem som helst anmäla ett misstänkt AI-system till marknadskontrollmyndigheten, som ska beakta anmälan. I Sverige föreslår utredningen [Anpassningar till AI-förordningen (SOU 2025:101)](https://www.regeringen.se/pressmeddelanden/2025/10/utredning-foreslar-forbud-mot-vissa-ai-system-och-sanktioner-for-bristande-dokumentation-av-hogrisk-ai/), som lämnades till regeringen i oktober 2025, att [PTS får huvudansvaret](https://pts.se/ai/ai-forordningen/) som samordnande marknadskontrollmyndighet, medan IMY och Finansinspektionen delar ansvaret för hög-risk-AI. Totalt pekas elva myndigheter ut. De nya svenska reglerna är per augusti 2026 ännu inte antagna – deadlinen 2 augusti 2026 passerades utan färdig svensk lag. Förordningen gäller ändå direkt, så ni är bundna oavsett var den svenska lagstiftningen står. ### Driftstoppet kostar oftast mer än boten Den verkliga kostnaden för många mindre företag är inte botbeloppet utan driftstoppet. Marknadskontrollmyndigheten kan kräva att ett system dras tillbaka, återkallas eller förbjuds på marknaden, helt vid sidan av böterna. Ett system som plötsligt måste stängas mitt i drift kostar ofta mer i förlorad verksamhet än boten gör. När en bot väl bestäms väger myndigheten in en rad omständigheter enligt Artikel 99(7): hur allvarlig överträdelsen är, om den var avsiktlig, om ni samarbetat, och om ni själva åtgärdat felet. Den som upptäcker en brist, rättar den och berättar för myndigheten behandlas påtagligt mildare än den som blir påkommen och bortförklarar. Det gör tidig, dokumenterad egenkontroll till en konkret riskreducering, inte bara en formalitet. Tre saker håller er borta från testfalls-rollen: klassificera systemen rätt, dokumentera att ni gjort det, och informera kunderna när de möter AI. De som har den grunden på plats är inte de som myndigheten börjar med, och om något ändå skulle granskas är det de som har lättast att visa god vilja. Sammantaget är EU AI Act-sanktioner reella men hanterbara för ett företag som agerar i tid. Botbeloppen följer er storlek, ingen har bötfällts än, och flera undantag är skrivna för mindre företag. Tidsfönstret 2026 är till för att bli klar i lugn och ro, innan tillsynen växlar upp på allvar. För hela bilden av hur AI-agenter passar svenska företag inom regelverkets ramar finns [vår fördjupande guide till AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). ## Vanliga frågor --- ### EU AI Act-dokumentation: mall för svenska företag **URL:** https://eteya.ai/sv/blogg/eu-ai-act/eu-ai-act-dokumentation-mall **Sammanfattning:** Vad svenska företag måste dokumentera enligt EU AI Act, uppdelat på er roll. Plus en gratis ifyllbar mall: AI-systemregister, kunskapslogg och transparens-register. import FAQ from '@/components/blog/FAQ' import LeadMagnetForm from '@/components/blog/LeadMagnetForm' De flesta svenska små och medelstora företag tror att EU AI Act-dokumentation betyder hundratals sidor teknisk text. Det stämmer bara för en liten grupp. För resten handlar det om tre enkla register som tar en eftermiddag att fylla i. Den här guiden visar exakt vad ni måste dokumentera utifrån er roll, och ger er en gratis mall att utgå från. ## Vad kräver EU AI Act att svenska företag dokumenterar? EU AI Act-dokumentation innebär för de flesta svenska företag tre saker: ett register över era AI-system, en logg över personalens AI-kunskap, och en notering om var ni informerar användare att de möter AI. Den fullständiga tekniska dokumentationen gäller bara hög-risk-leverantörer. Lagen är [förordning (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng) och trädde i kraft 1 augusti 2024. Den klassificerar AI-system i fyra risk-kategorier, och dokumentationskraven växer med risken. EU-kommissionens egen konsekvensbedömning räknar med att bara 5–15 procent av alla AI-system landar i hög-risk, vilket [CEPS analys av regelverkets kostnader](https://www.ceps.eu/clarifying-the-costs-for-the-eus-ai-act/) sammanfattar som runt en tiondel av systemen. För de allra flesta företag blir dokumentationen därför lätt: bevisa att ni har koll, inte att ni byggt ett certifierat system. Den tyngden gör det värt att se hur kraven faktiskt skalar med risken innan ni öppnar mallen: | Risk-klass | Vad det är | Dokumentationskrav | |---|---|---| | Förbjudet | Otillåtna praktiker enligt Artikel 5 (social poängsättning, manipulativ AI) | Inget att dokumentera – systemet får inte användas alls | | Hög | Annex III-tillämpningar, t.ex. rekrytering eller kreditbedömning | Full teknisk dokumentation (leverantör) eller namngiven tillsyn, övervakning och loggar i minst 6 mån (tillhandahållare) | | Begränsad | Chatbots och AI-agenter som möter användare | Transparens enligt Artikel 50: informera att det är AI | | Minimal | Intern produktivitets-AI som ChatGPT och Copilot | Inget formellt krav; register och kunskapslogg är god praxis | Den här stegringen är hela artikelns röda tråd. Resten av guiden visar exakt vad varje nivå betyder för just er. Misstaget vi ser oftast är att företag antingen ignorerar dokumentation helt, eller drar igång ett enormt projekt som om de vore ett MedTech-bolag. Båda är fel. Rätt nivå av EU AI Act-dokumentation avgörs av två frågor: vilken roll har ni, och vilken risk-klass har systemet? ## Vilken dokumentation behöver ni utifrån er roll? Er roll avgör allt. Är ni **tillhandahållare** (ni använder ett färdigt AI-verktyg) räcker det med register, kunskapslogg och transparens. Är ni **leverantör** (ni bygger eller sätter ert namn på ett hög-risk-system) tillkommer fullständig teknisk dokumentation enligt Annex IV. ### Skillnaden mellan tillhandahållare och leverantör Skillnaden är stor och missförstås ofta. Att använda ChatGPT, en kundtjänst-chatbot eller AI inbäddad i ert CRM gör er till tillhandahållare, inte leverantör. Då har ni inga krav på teknisk produktdokumentation. Bygger ni däremot ett eget rekryterings- eller kreditbedömnings-system, eller köper ett white label-system som ni säljer under eget namn, blir ni leverantör med betydligt tyngre krav. Är ni leverantör men samtidigt ett mindre företag får ni lämna den tekniska dokumentationen i förenklad form, och eventuella böter vägs mot er storlek – vi går igenom [sanktionerna och lättnaderna för mindre företag](/sv/blogg/eu-ai-act/eu-ai-act-sanktioner-och-undantag) separat. Att tillhandahållar-rollen dominerar är ingen tillfällighet. Enligt [Eurostat](https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20241025-1) är 99 procent av EU:s företag mikro- och småföretag, och de allra flesta köper färdig AI snarare än bygger egen. Det är därför den lättare dokumentationen är normalfallet och leverantörs-kraven undantaget. > Att använda ett AI-verktyg och att bygga ett är två helt olika juridiska roller. Förväxla dem och ni dokumenterar antingen för lite eller fullständigt i onödan. De två rollerna ger två helt olika dokumentationsbördor: | Roll | Du är det om... | Dokumentation som krävs | Exempel | |---|---|---|---| | Tillhandahållare | du använder ett färdigt AI-verktyg som det är | Register, kunskapslogg och transparens | ChatGPT, kundtjänst-chatbot, AI inbäddad i ert CRM | | Leverantör | du bygger eller sätter ert namn på ett hög-risk-system | Allt ovan plus full teknisk dokumentation enligt Annex IV (förenklad form för mindre företag) | Eget rekryterings- eller kreditbedömnings-system, white label-system ni säljer vidare | Ett snabbt test: sätter ni ert eget varumärke på AI-systemet, eller ändrar ni väsentligt hur det fungerar? Då är ni sannolikt leverantör. Köper ni en färdig tjänst och använder den som den är, är ni tillhandahållare, oavsett hur avancerad tekniken bakom är. Tveksamma fall, som att finjustera en egen modell på era data, bör stämmas av med jurist innan ni bestämmer dokumentationsnivå. Innan ni dokumenterar något behöver ni alltså klassificera era system. Vi har en separat genomgång av [hur ni risk-klassificerar era AI-system steg för steg](/sv/blogg/eu-ai-act/eu-ai-act-risk-klassificering) som är det naturliga första steget före den här mallen. ## Vad ska ett AI-systemregister innehålla? Ett AI-systemregister är en enkel tabell som listar varje AI-system ni använder eller tillhandahåller, dess syfte, er roll, dess risk-klass och vilken åtgärd som krävs. Det är grunden i all EU AI Act-dokumentation och bör finnas även om inget system är hög risk. Registret är inget formellt lagkrav för minimal-risk-system, men det är den dokumentation som binder ihop allt annat och som en revisor eller myndighet först vill se. Lista brett: AI-agenter, chatbots, kundtjänstautomation, intern produktivitets-AI som ChatGPT och Copilot, prediktiv analys, marknadsförings-AI och AI som ligger inbäddad i SaaS-verktyg ni redan betalar för. ### Fälten registret behöver För varje system noterar ni: 1. **System och leverantör:** vad det heter och vem som tillhandahåller det 2. **Syfte:** vad ni använder det till, konkret 3. **Er roll:** tillhandahållare eller leverantör 4. **Risk-klass:** förbjudet, hög, begränsad eller minimal 5. **Åtgärd:** vad som är gjort eller behöver göras Just att hålla registret uppdaterat när nya verktyg tas i bruk är viktigare än hur snyggt det ser ut. Ett kalkylark som faktiskt underhålls slår en perfekt PDF som ingen rör. ## Hur fyller ett typiskt företag i registret? De flesta företag landar på tre till fem system i sitt register, oftast en kundtjänst-chatbot, intern produktivitets-AI och något som ligger inbäddat i ett SaaS-verktyg. Ett konkret exempel gör tydligt hur enkel EU AI Act-dokumentation faktiskt blir i praktiken. ### Tre system i praktiken Ta en svensk e-handlare med tio anställda och tre AI-system. **System ett** är en kundtjänst-chatbot från en extern leverantör. Roll: tillhandahållare. Risk: begränsad, eftersom den interagerar direkt med kunder. Åtgärd: lägg in en transparens-disclaimer enligt Artikel 50 vid första svaret. **System två** är ChatGPT, som teamet använder för produkttexter och mejlutkast. Roll: tillhandahållare. Risk: minimal. Åtgärd: ta upp verktyget i AI-kunskapsloggen och i den interna policyn om godkända verktyg. Inga tyngre krav tillkommer. **System tre** är ett verktyg som bedömer delbetalnings-risk i kassan. Roll: tillhandahållare. Risk: potentiellt hög, eftersom kreditbedömning av privatpersoner ligger i Annex III. Åtgärd: kontrollera leverantörens dokumentation, utse en namngiven mänsklig tillsyn och se till att loggarna sparas i minst sex månader. Ifyllt blir e-handlarens register en enda överskådlig tabell, exakt det format ni själva ska kopiera: | System och leverantör | Syfte | Roll | Risk-klass | Åtgärd | |---|---|---|---|---| | Kundtjänst-chatbot, extern leverantör | Svara på vanliga kundfrågor på webben | Tillhandahållare | Begränsad | Transparens-disclaimer enligt Artikel 50 vid första svaret | | ChatGPT | Produkttexter och mejlutkast | Tillhandahållare | Minimal | Tas upp i kunskapsloggen och policyn för godkända verktyg | | Delbetalnings-riskverktyg i kassan | Bedömer kreditrisk för privatpersoner | Tillhandahållare | Potentiellt hög | Granska leverantörens dokumentation, namngiven tillsyn, spara loggar i minst 6 mån | Hela övningen tar en eftermiddag, och resultatet besvarar de tre frågor en myndighet, kund eller investerare ställer: vilka AI-system har ni, vilken risk har de, och vad har ni gjort åt det. Lägg märke till att bara ett av tre system, kreditverktyget, drar några tyngre krav. Det är typiskt. Merparten av raderna i ett sådant register hamnar i minimal eller begränsad risk, och just därför blir dokumentationen hanterbar när ni väl klassificerat rätt. ## Måste ni dokumentera personalens AI-kunskap? Ja. [Artikel 4 om AI-kunskap](https://artificialintelligenceact.eu/article/4/) gäller alla som använder eller tillhandahåller AI och är i kraft sedan 2 februari 2025. Ni ska säkerställa att personalen har tillräcklig AI-kunskap, och utan dokumenterad utbildning kan ni inte bevisa att kravet är uppfyllt. Det här är den del som flest missar, just för att den redan gäller och inte väntar på någon framtida deadline. Kravet är medvetet flexibelt: nivån ska stå i proportion till hur ni använder AI och vilka som berörs. För ett litet bolag som använder ChatGPT internt räcker en kort internutbildning plus en enkel policy om vilka verktyg som är godkända. Det som behövs är en logg: vem som utbildats, när, och vad utbildningen omfattade. En rad per personalgrupp räcker. Poängen är inte byråkrati utan bevisbarhet. Om frågan ställs ska ni kunna peka på ett datum och ett innehåll, inte säga "vi pratade om det på ett möte". ## När krävs transparens-dokumentation? [Artikel 50](https://artificialintelligenceact.eu/article/50/) kräver att ni informerar användare när de interagerar med AI eller tar del av AI-genererat innehåll. Det gäller chatbots och AI-agenter, deepfakes, och AI-genererad text som publiceras i samhällsinformerande syfte. Dokumentera var och hur ni informerar. För de flesta mindre företag betyder det här en enda sak i praktiken: chatbotten eller AI-agenten på webben ska tala om att den är AI vid första kontakt. En mening räcker, till exempel "Du chattar med en AI-assistent. Skriv 'mänsklig agent' om du vill nå en person." Transparens-registret noterar bara vilket system det gäller, vilken typ av disclosure som krävs, och var texten visas. Genererar ni bilder, ljud eller video som är deepfakes, eller AI-text om nyheter och samhällsfrågor, tillkommer märkningskrav. Det är ovanligt för vanliga småföretag men värt att känna till om ni jobbar med marknadsföringsinnehåll. Den här typen av transparens är samma princip som vi byggde in när vi tog fram [Eteyas guide till EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). ## Vad gäller för tillhandahållare av hög-risk-system? Är ni tillhandahållare av ett hög-risk-system (Annex III, till exempel rekryterings- eller kreditbedömnings-AI) tillkommer tre konkreta och bevisbara skyldigheter enligt [Artikel 26](https://artificialintelligenceact.eu/article/26/): namngiven mänsklig tillsyn, övervakning av driften, och att spara systemets automatiska loggar i minst sex månader. Det här är en mindre grupp företag, men kraven är konkreta och bevisbara. Ni ska kunna peka ut en namngiven person med rätt kompetens och befogenhet att ingripa, beskriva hur ni övervakar systemet, och visa att loggarna sparas. Enligt en genomgång från [IAPP](https://iapp.org/news/a/eu-ai-act-deployer-evidence-gaps-smes-will-miss-before-2-aug-2026) är det just dessa bevis, namngiven tillsyn och sparade loggar, som flest tillhandahållare saknar inför att kraven börjar gälla. ### När FRIA tillkommer En liten undergrupp måste dessutom göra en konsekvensbedömning för grundläggande rättigheter, FRIA, enligt [Artikel 27](https://artificialintelligenceact.eu/article/27/). Den gäller offentliga organ, privata aktörer som levererar offentliga tjänster, och tillhandahållare av AI för kreditbedömning eller liv- och sjukförsäkring. Gäller inget av detta er, kan ni hoppa över FRIA helt. ## Hur länge ska dokumentationen sparas? Bygger ni hög-risk-system som leverantör ska den tekniska dokumentationen sparas i tio år efter att systemet satts på marknaden (Artikel 18). Som tillhandahållare av hög-risk-system sparar ni systemets loggar i minst sex månader (Artikel 26.6). För minimal-risk-system finns inget formellt krav, men ett levande register är god praxis. Samlat ser bevaringstiderna ut så här: | Dokumenttyp | Bevaringstid | Källa | |---|---|---| | Teknisk dokumentation, hög-risk-leverantör | 10 år efter marknadsintroduktion | [Artikel 18](https://artificialintelligenceact.eu/article/18/) | | Loggar, tillhandahållare av hög-risk-system | Minst 6 månader | [Artikel 26.6](https://artificialintelligenceact.eu/article/26/) | | Minimal-risk-system | Inget formellt krav, översyn årligen som god praxis | – | ### Vad Annex IV-dokumentationen täcker Den tekniska dokumentationen för hög-risk-leverantörer följer [Annex IV](https://artificialintelligenceact.eu/annex/4/) och täcker systembeskrivning, datastyrning, prestanda, riskhantering och loggning enligt [Artikel 12](https://artificialintelligenceact.eu/article/12/). Små företag och startups får lämna den i förenklad form, och EU-kommissionen ska ta fram en förenklad mall för ändamålet. Tills den publiceras räcker det att täcka rubrikerna i Annex IV proportionerligt mot er storlek. Sätt ett återkommande datum för översyn, minst en gång per år och vid varje lagändring. EU AI Act-dokumentation är inte en engångsuppgift utan ett levande underlag som ska spegla vilka system ni faktiskt kör. ## Vilka är de vanligaste misstagen i EU AI Act-dokumentation? De tre vanligaste misstagen är att överdokumentera som vanlig tillhandahållare, att glömma AI-kunskapsloggen trots att Artikel 4 redan gäller, och att behandla dokumentationen som en engångsuppgift istället för ett levande register som följer verksamheten när den förändras. ### De tre misstagen i tur och ordning Det första och dyraste misstaget är att dokumentera som om ni vore leverantör. Ett bolag som bara använder färdiga AI-verktyg drar ibland igång ett fullständigt Annex IV-projekt det inte alls behöver, med veckor av onödigt arbete. Klassificera rollen först, dokumentera därefter. Det andra misstaget är att hoppa över AI-kunskapsloggen. Eftersom Artikel 4 inte väntar på någon framtida deadline glöms den lätt bort i jakten på hög-risk-kraven. Det är samtidigt den enklaste delen att åtgärda, och ofta den första en motpart frågar efter eftersom den redan är skarp. Det tredje misstaget är att se dokumentationen som klar. Ett register som speglar förra årets verktyg är värdelöst. Nya AI-funktioner dyker upp i SaaS-verktyg ni redan betalar för, ofta utan att någon aktivt valt dem. Utan ett återkommande översynsdatum slutar registret stämma inom några månader, och då faller hela poängen. ## Behöver ni en AI-policy utöver registret? Ja, för de flesta företag är en kort intern AI-policy ett naturligt komplement till dokumentationen. Registret beskriver vad ni har, medan policyn styr hur personalen får använda AI. Tillsammans täcker de både EU AI Act-dokumentation och praktisk styrning. EU AI Act kräver ingen formell policy i sig, men Artikel 4 om AI-kunskap blir svår att uppfylla utan en. En policy på en sida räcker långt: vilka verktyg som är godkända, vilka data som aldrig får matas in i publika AI-tjänster, och vem man frågar vid tveksamheter. Det är samma princip som en informationssäkerhetspolicy, fast för AI. Policyn löser också det vanligaste praktiska problemet, skugg-AI. När personalen använder verktyg som ingen godkänt hamnar de utanför registret och utanför kontrollen. En tydlig policy med en enkel väg att föreslå nya verktyg håller registret aktuellt och minskar risken att ett okänt system bryter mot transparens- eller dataskyddskrav. Policyn och registret bör därför ses över vid samma tillfälle. ## När börjar kraven gälla? Förbjudna praktiker, GPAI-regler, AI-kunskap (Artikel 4) och transparenskraven (Artikel 50, sedan 2 augusti 2026) gäller redan idag. Hög-risk-kraven var satta till 2 augusti 2026, men Digital Omnibus-förordningen sköt upp fristående Annex III-system till 2 december 2027. Senareläggningen är beslutad: [förordning (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng) publicerades i EU:s officiella tidning 24 juli 2026 och trädde i kraft den 27 juli. Det praktiska rådet: använd tiden till december 2027, förlita er inte på den. Dokumentationsarbetet tar samma antal timmar oavsett när ni gör det — men gjort i lugn takt blir det bättre, och de delar som redan gäller kräver ändå sin dokumentation nu. Att börja ett halvår innan deadline är fortfarande minimum för att hinna utan stress. Att skjuta upp hög-risk-kraven ändrar dessutom ingenting för de delar som redan gäller. AI-kunskap, transparens och förbudet mot vissa praktiker påverkas inte av Omnibus. För majoriteten av mindre företag, som ändå mest berörs av just de delarna, är väntan alltså inte ett skäl att vänta med dokumentationen. ## Hur kommer ni igång på en eftermiddag? Avsätt fyra timmar och arbeta i fyra steg: klassificera era system efter roll och risk, fyll i AI-systemregistret, dokumentera personalens AI-kunskap i loggen och notera var era AI-kontakter informerar användarna. Boka samtidigt ett årligt översynsdatum, så är grunddokumentationen på plats. **Timme 1: inventera och klassificera.** Samla den som äger IT-frågorna och en person som använder verktygen dagligen. Lista allt med AI i: chatbots, produktivitetsverktyg, inbäddade SaaS-funktioner. Avgör roll och risk-klass per system enligt stegen tidigare i guiden. **Timme 2: fyll i registret.** Fem kolumner per system, inte fler. Skriv kort och konkret: "kundtjänst-chatbot, extern leverantör, tillhandahållare, begränsad risk, disclaimer tillagd". En rad som går att läsa på fem sekunder är målet. **Timme 3: kunskapsloggen.** Notera vilken utbildning personalen redan fått, även om det bara är en intern genomgång. Saknas allt: boka en timmes internutbildning inom en månad och skriv in datumet redan nu. Loggen får hellre visa en plan än vara tom. **Timme 4: transparens och översyn.** Kontrollera att chatbotten presenterar sig som AI vid första kontakt, notera var texten visas, och lägg in nästa översyn som ett återkommande kalenderdatum. Klart. Resultatet är inte perfekt dokumentation, utan tillräcklig och bevisbar. Det är exakt vad lagen kräver av er nivå, och det går att förbättra stegvis vid varje översyn. ## Vanliga frågor Att komma igång med EU AI Act-dokumentation är enklare än de flesta tror, så länge ni börjar i rätt ände: klassificera systemen, fyll i registret, logga kunskapen. Mallen ovan ger er strukturen. Behöver ni hjälp att klassificera era system rätt eller bygga AI som är dokumenterad från start, finns vi här. --- ### Riskklassificering enligt EU AI Act: steg för steg **URL:** https://eteya.ai/sv/blogg/eu-ai-act/eu-ai-act-risk-klassificering **Sammanfattning:** Så riskklassificerar ni era AI-system enligt EU AI Act: leverantör eller tillhandahållare, fyra nivåer, Artikel 6(3)-undantaget och vad varje kategori kräver. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' Riskklassificering är första steget mot EU AI Act-compliance, och det är där de flesta små och medelstora företag kör fast. Vår [guide om EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag) gav överblicken: de fyra kategorierna, deadlines och sanktioner. Den här artikeln går djupare och ger en konkret metod för att riskklassificera varje AI-system ni använder. Vi börjar med frågan de flesta hoppar över, går igenom nivåerna i rätt ordning, och förklarar Artikel 6(3)-undantaget som faktiskt avgör om ett system är hög-risk. Allt enligt förordning (EU) 2024/1689. ## Vad innebär riskklassificering enligt EU AI Act? Riskklassificering enligt EU AI Act betyder att placera varje AI-system i en av fyra nivåer (förbjudet, hög-risk, begränsad risk, minimal risk) och samtidigt avgöra om det är en generell AI-modell. Klassen avgör vilka krav som gäller och vem som bär ansvaret. ### Så fungerar den hierarkiska logiken Logiken är hierarkisk. Ni testar ett system mot den strängaste nivån först och arbetar er nedåt. Ett system kan bara hamna i en nivå, men en generell AI-modell (GPAI) följer ett eget spår vid sidan om trappan. Hela rättsakten finns hos [EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng) på 23 språk. Varför börja just med klassificeringen? För att den styr allt annat. Vilken dokumentation ni behöver, om systemet måste registreras, vilka transparenskrav som gäller och hur stor risk ni bär, allt följer av vilken nivå systemet hamnar i och vilken roll ni har. Klassificerar ni fel i början bygger ni antingen dokumentation i onödan eller missar krav som faktiskt gäller. För de flesta mindre företag landar merparten av systemen i de två lägsta nivåerna, men ni kan inte veta det utan att gå igenom varje system. Det är ett par timmars arbete för en typisk verksamhet, och det är tid som betalar sig flera gånger om. ### Vad Digital Omnibus inte ändrar En viktig sak att förstå direkt: **Digital Omnibus-förordningen ((EU) 2026/1744, i kraft 27 juli 2026) ändrar inte själva klassificeringen.** Det som flyttades var tidslinjerna – högriskkraven för fristående system gäller nu från 2 december 2027. Artiklarna 5, 6, 50 och 51 står oförändrade. Klassificeringsarbetet ni gör nu håller alltså fullt ut. För deadlines och sanktioner i detalj, se vår [EU AI Act-guide](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). ### De fyra nivåerna i en snabbreferens Innan vi går in i trappan steg för steg, här är de fyra nivåerna samlade. Tabellen är en sammanfattning av materialet längre ner och en översikt ni kan scanna när ni klassificerar ett system. Sanktionsexponeringen följer Artikel 99, där förbjuden praktik ligger högst och övriga överträdelser lägre. | Nivå | Exempel | Krav på er | Sanktionsexponering | |---|---|---|---| | Förbjudet (Artikel 5) | Känsloigenkänning på arbetsplatsen, manipulativa tekniker | Användningen ska upphöra omedelbart | Högst: upp till 35 MEUR eller 7 procent av global omsättning | | Hög-risk (Artikel 6) | Rekryterings-AI som rankar kandidater, kreditbedömning | Teknisk dokumentation, riskhanteringssystem, mänsklig övervakning, registrering | Upp till 15 MEUR eller 3 procent av omsättningen | | Begränsad risk (Artikel 50) | Kundtjänst-chatbot, AI-genererade marknadsföringsbilder | Transparens-disclaimer och märkning av syntetiskt innehåll | Samma intervall som hög-risk vid utebliven transparens | | Minimal risk | Intern ChatGPT utan kundkontakt, AI som räknar lager i bakgrunden | Inga särskilda krav, men AI-literacy enligt Artikel 4 | Ingen direkt riskexponering för själva användningen | För mindre företag gäller de lägre beloppen av belopp och procent enligt Artikel 99(6), tvärtemot huvudregeln för stora bolag. ## Steg 0: är ni leverantör eller tillhandahållare av systemet? Innan ni klassificerar risknivå måste ni avgöra er roll, för rollen styr vilka skyldigheter klassificeringen utlöser. En **leverantör** (provider) utvecklar ett AI-system eller sätter det på marknaden under eget namn. En **tillhandahållare** (deployer) använder ett system i sin yrkesverksamhet. De flesta företag är tillhandahållare. Skillnaden är avgörande. Köper ni en färdig AI-tjänst som SaaS är ni nästan alltid tillhandahållare, och de tunga dokumentationskraven ligger på leverantören. Bygger ni en egen modell, eller säljer vidare någon annans AI under ert eget varumärke, blir ni leverantör och ärver leverantörens fulla ansvar. ### Fallgropen med generella modeller En vanlig fallgrop gäller generella modeller. Att integrera en GPAI-modell som ChatGPT eller Claude gör er inte automatiskt till leverantör av modellen. Men finjusterar ni den väsentligt kan ni klassas som leverantör. EU-kommissionens [vägledning för GPAI](https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers) använder en tumregel kring en tredjedel av ursprunglig träningsberäkning som riktmärke för när ansvaret flyttar. Skriv ner för varje system: är vi leverantör eller tillhandahållare här? Det svaret behövs i varje senare steg. ## Steg 1: är systemet förbjudet enligt Artikel 5? Det första risktestet är det hårdaste. [Artikel 5](https://artificialintelligenceact.eu/article/5/) listar åtta förbjudna AI-praktiker som gäller sedan 2 februari 2025. Träffar ert system någon av dem är det förbjudet, oavsett er roll, och användningen ska upphöra omedelbart. De flesta företagssystem passerar det här steget utan problem, men det måste ändå kontrolleras först. För svenska företag är två förbud särskilt relevanta. Det första är **manipulativa tekniker** som utnyttjar psykologiska sårbarheter, exempelvis säljpsykologi riktad mot utsatta grupper. Det andra är **känsloigenkänning på arbetsplatsen**, alltså AI som läser av medarbetares humör via kamera eller röst. Båda är otillåtna oavsett hur väl de fungerar tekniskt. Resten av Artikel 5 handlar om social scoring, oriktad ansiktsskrapning och biometrisk kategorisering av känsliga egenskaper. De flesta företag rör aldrig dessa områden, men det tar två minuter att bekräfta och bör vara er tydliga nej-zon när ni utvärderar nya leverantörer. En notis om 2026: Digital Omnibus-förordningen införde nya förbud (bland annat mot AI-verktyg för att skapa övergreppsmaterial) som [börjar gälla 2 december 2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng). Sedan 27 juli 2026 är det beslutad rätt, inte ett förslag. ## Steg 2: räknas systemet som hög-risk enligt Artikel 6? Om systemet inte är förbjudet är nästa fråga om det är hög-risk. [Artikel 6](https://artificialintelligenceact.eu/article/6/) pekar ut två vägar in i kategorin: systemet är en säkerhetskomponent i en produkt som redan regleras (Annex I, exempelvis maskiner eller medicinteknik), eller så används det inom ett av de åtta områdena i Annex III. [Annex III](https://artificialintelligenceact.eu/annex/3/) listar de åtta hög-riskområdena: biometri, kritisk infrastruktur, utbildning, sysselsättning och rekrytering, tillgång till väsentliga tjänster (inklusive kreditbedömning och försäkring), brottsbekämpning, migration, samt rättsskipning och demokratiska processer. För svenska företag är två områden vanligast. **Rekryterings-AI** som filtrerar ansökningar eller rankar kandidater faller under sysselsättning. **Kreditbedömning och riskprissättning** inom försäkring faller under väsentliga tjänster. Bedrägeridetektering är uttryckligt undantaget från kreditpunkten. Använder ni AI på något av dessa sätt är utgångspunkten hög-risk, och då behöver ni gå vidare till nästa steg innan ni drar slutsatsen. ## Steg 3: gäller Artikel 6(3)-undantaget? Här ligger nyansen som de flesta missar. Även om ett system träffar Annex III är det **inte** hög-risk om det inte utgör en betydande risk för hälsa, säkerhet eller grundläggande rättigheter, och dessutom uppfyller minst ett av fyra villkor i [Artikel 6(3)](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6). De fyra villkoren är: 1. Systemet utför en **snäv procedurell uppgift**. 2. Systemet **förbättrar resultatet** av en redan avslutad mänsklig aktivitet. 3. Systemet **upptäcker mönster eller avvikelser** utan att ersätta eller påverka en mänsklig bedömning utan ordentlig granskning. 4. Systemet utför en **förberedande uppgift** inför en bedömning. Men det finns en hård gräns: ett system som **profilerar fysiska personer är alltid hög-risk**, oavsett villkoren ovan. Det är där många företag landar fel. Ett rekryteringsverktyg som bara konverterar ett CV till strukturerad text kan vara en snäv procedurell uppgift. Ett verktyg som rankar och gallrar kandidater profilerar dem, och är därmed alltid hög-risk. Ett villkor till: hävdar ni som leverantör att ett Annex III-system inte är hög-risk, kräver Artikel 6(4) att ni **dokumenterar bedömningen innan systemet släpps** och registrerar det. Undantaget är alltså inte en genväg förbi pappersarbetet, utan ett beslut ni måste kunna försvara. EU-kommissionen publicerade den 19 maj 2026 ett [utkast till riktlinjer för hög-risk-klassificering](https://digital-strategy.ec.europa.eu/en/library/draft-commission-guidelines-classification-high-risk-ai-systems) med konsultation öppen till 23 juni 2026. Det är fortfarande ett utkast, men ger den mest detaljerade vägledningen hittills om hur Artikel 6 ska tolkas. Följ den slutliga versionen innan ni fattar gränsfallsbeslut. ## Steg 4: träffas systemet av transparenskraven i Artikel 50? Är systemet varken förbjudet eller hög-risk kan det ändå omfattas av transparenskrav. [Artikel 50](https://artificialintelligenceact.eu/article/50/) reglerar fyra fall, och ansvaret är fördelat mellan leverantör och tillhandahållare. Kraven gäller sedan 2 augusti 2026 – det datumet flyttades inte av Omnibus – och för de flesta företag räcker det med en tydlig upplysning om att kunden möter ett AI-system. | Fall | Vem informerar | |---|---| | AI som interagerar direkt med personer (chatbots) | Leverantör | | Märkning av syntetiskt innehåll (bild, ljud, video, text) | Leverantör | | Känsloigenkänning eller biometrisk kategorisering | Tillhandahållare | | Deepfakes och AI-text i ämnen av allmänintresse | Tillhandahållare | Det vanligaste fallet för mindre företag är chatbots och AI-agenter som möter kunder. Personen ska få veta att den pratar med AI, om det inte är uppenbart. Skillnaden mot en intern automation är viktig: en kundtjänst-bot träffas av kravet, medan en AI som i bakgrunden räknar lager eller priser aldrig möter slutkunden och därför hamnar i minimal risk. Vill ni förstå var den gränsen går, läs vår [jämförelse av AI-agent och chatbot](/sv/blogg/ai-agenter/ai-agent-vs-chatbot). Transparenskravet träffar gränssnittet mot människan, inte logiken bakom. Hur hela EU AI Act träffar just AI-agenter, inklusive när de blir högrisk, går vi igenom i [AI-agenter och EU AI Act](/sv/blogg/ai-agenter/ai-agenter-eu-ai-act). ## Hur klassificeras generella AI-modeller (GPAI)? Generella AI-modeller följer ett eget spår vid sidan om risktrappan, reglerat i Artikel 51 till 55. Alla leverantörer av GPAI har dokumentationsskyldigheter sedan 2 augusti 2025. Modeller med så kallad systemisk risk får ytterligare krav på utvärdering, testning och incidentrapportering. Gränsen för systemisk risk går vid en träningsberäkning över 10^25 FLOP, enligt [kommissionens GPAI-vägledning](https://digital-strategy.ec.europa.eu/en/faqs/general-purpose-ai-models-ai-act-questions-answers). Det är en tröskel som bara de största modellbolagen passerar, inte svenska företag. ### Varför svenska företag aldrig blir GPAI-leverantör Tröskeln är inte bara hög på pappret, den ligger en bra bit utanför vad en vanlig verksamhet ens kan nudda. För att sätta storleksordningen: att träna en modell på den nivån kostar tiotals miljoner dollar i ren beräkningskraft, och de allra största modellerna kostar redan hundratals miljoner. [Epoch AI](https://epoch.ai/data-insights/models-over-1e25-flop) räknade i juni 2025 till drygt 30 modeller över 10^25 FLOP, byggda av sammanlagt tolv utvecklare i hela världen. Kommissionens egna preliminära riktlinjer uppskattar att [omkring elva leverantörer globalt](https://artificialintelligenceact.eu/providers-of-general-purpose-ai-models-what-we-know-about-who-will-qualify/) har modeller över tröskeln. Det är OpenAI, Google, Anthropic och en handfull till, inte ett svenskt företag. Skillnaden mot det ni faktiskt gör blir tydlig när ni jämför med finjustering. Att finjustera en befintlig modell på era egna data är en bråkdel av beräkningen som krävdes för grundmodellen, och kommissionen sätter gränsen för när finjustering gör er till leverantör vid ungefär en tredjedel av den ursprungliga träningsberäkningen. För att passera 10^25 FLOP via finjustering skulle ni alltså behöva lägga en summa i klass med ett helt grundbygge. Kommissionen konstaterar själv att europeiska företag som bygger ovanpå dessa modeller med stor sannolikhet hamnar utanför reglerna för GPAI med systemisk risk. Slutsatsen för er är enkel: planera aldrig compliance som om ni vore modellbyggare, utan som tillhandahållare av andras modeller. För er som använder ChatGPT, Claude eller Gemini internt är budskapet enkelt: skyldigheterna för själva modellen ligger på OpenAI, Anthropic och Google. Er roll är tillhandahållare. Det ni ansvarar för är hur ni använder modellen, alltså vilken risknivå ert egna användningsfall hamnar i enligt stegen ovan, plus AI-literacy bland personalen. ## Hur klassificeras fyra vanliga företagssystem i praktiken? Fyra konkreta exempel visar hur samma metod ger olika utfall: en kundtjänst-chatbot blir begränsad risk, ett CV-gallringsverktyg blir hög-risk, en intern ChatGPT blir minimal risk, och en bildgenerator för marknadsföring blir begränsad risk. Skillnaden ligger i vad systemet gör och vem det möter. Här är de fyra fallen sida vid sida som översikt. Prosan under tabellen förklarar varje rad och visar resonemanget bakom utfallet. | System | Roll | Utfall | Åtgärd | |---|---|---|---| | Kundtjänst-chatbot | Tillhandahållare | Begränsad risk | Tydlig upplysning om att kunden chattar med AI | | Verktyg som rankar jobbansökningar | Tillhandahållare | Hög-risk | Teknisk dokumentation, riskhantering, mänsklig övervakning, registrering | | Intern ChatGPT för utkast och analys | Tillhandahållare (av GPAI) | Minimal risk | AI-literacy enligt Artikel 4 plus en intern policy | | AI som genererar marknadsföringsbilder | Tillhandahållare | Begränsad risk | Maskinläsbar märkning och upplysning om AI-genererat innehåll | ### Fyra exempel sida vid sida **Exempel 1: kundtjänst-chatbot hos en e-handlare.** Roll: tillhandahållare, eftersom boten är en inköpt tjänst. Den är inte förbjuden, och kundtjänst finns inte bland Annex III-områdena, så den är inte hög-risk. Men den pratar direkt med kunder, vilket träffar Artikel 50(1). Utfall: begränsad risk. Åtgärd: en tydlig upplysning om att kunden chattar med en AI-assistent vid första kontakten. **Exempel 2: verktyg som gallrar och rankar jobbansökningar.** Roll: tillhandahållare. Inte förbjudet. Rekrytering finns i Annex III punkt 4, så utgångspunkten är hög-risk. Då prövar ni Artikel 6(3): utför systemet bara en snäv procedurell uppgift? Nej, det rankar och gallrar kandidater, vilket är profilering. Profilering av personer är alltid hög-risk. Utfall: hög-risk, med teknisk dokumentation, riskhanteringssystem, mänsklig övervakning och registrering. Detta är ett projekt på månader, inte en eftermiddag. **Exempel 3: ChatGPT internt för dokumentutkast och analys.** Roll: tillhandahållare av en generell modell. Inte förbjudet, inte i Annex III, ingen kundkontakt. Utfall: minimal risk. Leverantörsskyldigheterna för själva modellen ligger på OpenAI. Det enda kravet på er är AI-literacy hos personalen enligt Artikel 4, plus en intern policy för vilka system som är godkända att använda. **Exempel 4: AI som genererar bilder till marknadsföring.** Roll: tillhandahållare. Inte förbjudet, inte hög-risk. Men ni publicerar syntetiskt innehåll, vilket träffar Artikel 50. Leverantören ska märka materialet maskinläsbart, och ni ska avslöja att en bild eller video är AI-genererad där det är relevant. Utfall: begränsad risk med märkningsansvar. Lägg märke till att alla fyra systemen kan finnas i ett och samma företag, men hamnar i tre olika kategorier. Det är därför ni måste klassificera per system och per roll, inte dra en generell slutsats för hela verksamheten. ## Vilka misstag är vanligast vid riskklassificering? Fyra fel återkommer hos svenska företag: att hoppa över inköpt AI i inventeringen, att blanda ihop leverantör och tillhandahållare, att stämpla varje chatbot som hög-risk, och att luta sig på Artikel 6(3)-undantaget för ett system som i praktiken profilerar personer. Alla fyra går att undvika med metoden ovan. ### De fyra felen i detalj **Att hoppa över inköpt AI.** Många klassificerar bara system de byggt själva och glömmer AI som är inbyggt i CRM, HR-verktyg och bokföringsprogram. Allt ska med i inventeringen, även om kraven oftast landar på leverantören. Ni kan inte klassificera ett system ni inte vet att ni har. **Att blanda ihop rollerna.** Antar ni leverantörsansvar för en tjänst ni bara använder bygger ni dokumentation i onödan. Antar ni rollen som tillhandahållare när ni egentligen säljer vidare AI under eget varumärke missar ni krav som faktiskt gäller er. Rollen avgörs per system, inte en gång för hela företaget. **Att överklassificera chatbots.** En chatbot som pratar med kunder är begränsad risk, inte hög-risk. Den behöver en transparens-disclaimer, inte ett fullt riskhanteringssystem. Överklassificering kostar tid och pengar utan att minska någon verklig risk. **Att missa profileringsregeln.** Det allvarligaste felet är att åberopa Artikel 6(3)-undantaget för ett system som rankar eller bedömer personer. Rankar systemet kandidater eller kunder är det alltid hög-risk, oavsett hur snäv uppgiften ser ut på pappret. Här uppstår den verkliga compliance-risken. ## Vad gör ni när riskklassificeringen är klar? När varje system har en nivå och en roll vidtar ni åtgärderna som hör till. Dokumentera klassificeringen för alla system, särskilt om ni hävdar Artikel 6(3)-undantaget, eftersom den bedömningen måste kunna visas upp. Sedan följer ni kraven per kategori. Förbjudna system stoppas. Hög-risk-system kräver teknisk dokumentation, riskhanteringssystem, mänsklig övervakning och registrering, ett arbete på månader snarare än dagar. System med begränsad risk behöver tydliga transparens-disclaimers. Minimal risk kräver inga särskilda åtgärder, men en intern inventering är klok inför en eventuell granskning. Klassificeringen avgör också er exponering mot böter, och vilka undantag som kan gälla, vilket vi går igenom i [vår guide till EU AI Act-sanktioner och undantag](/sv/blogg/eu-ai-act/eu-ai-act-sanktioner-och-undantag). När klassificeringen sitter är nästa steg att dokumentera systemen, vilket vi går igenom i guiden om [EU AI Act-dokumentation med gratis mall](/sv/blogg/eu-ai-act/eu-ai-act-dokumentation-mall). ### Tre saker att formalisera direkt Oavsett kategori är tre saker värda att formalisera direkt. Utse en ansvarig person som äger AI-inventeringen och uppdaterar den när nya system tillkommer eller används på nya sätt. Spara varje klassificeringsbeslut skriftligt, med datum, vald kategori och en kort motivering, så att ni kan visa hur ni resonerade. Och se till att ni har AI-literacy enligt Artikel 4, som gäller oavsett risknivå: en kort internutbildning om vad era AI-system kan och inte kan räcker långt för de flesta företag. Det kostar nästan ingenting i tid nu, men är skillnaden mellan en lugn och en stressig dialog den dag en tillsynsmyndighet, en kund eller en investerare ställer frågor. Det viktigaste rådet är att bygga rätt från start. När ni utvecklar nya AI-flöden, designa dem med klassificeringen i åtanke, så slipper ni dyra ombyggnationer senare. Det är samma princip vi följer när vi bygger [AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb): transparens där det krävs och dokumentation som standard. En genomtänkt riskklassificering tidigt är billigare än en rättning under tidspress nära en deadline. ## Vanliga frågor --- ### MCP-protokoll: teknisk guide för utvecklare 2026 **URL:** https://eteya.ai/sv/blogg/ai-agenter/mcp-protokoll-teknisk-guide **Sammanfattning:** Hur du bygger en säker MCP-server från grunden: arkitektur, autentisering, testning och produktionsdrift. Steg för steg med TypeScript SDK och kodexempel. import FAQ from '@/components/blog/FAQ' MCP-protokoll har gått från Anthropic-experiment till industri-standard på 18 månader. För utvecklare och CTOs som vill bygga AI-agenter mot egna system är frågan inte längre **om** MCP, utan **hur** du implementerar det säkert i produktion. Den här guiden är teknisk: arkitektur, kod, autentisering och övervakning. Om du är ny till protokollet, läs först vår [grundläggande genomgång av MCP](/sv/blogg/ai-agenter/vad-ar-mcp-model-context-protocol). Den här guiden förutsätter att du vet vad MCP är och vill bygga något själv. ## Hur fungerar MCP-arkitekturen tekniskt? MCP-protokoll bygger på **JSON-RPC 2.0** över två transport-typer: stdio (lokala servrar) och HTTP med Server-Sent Events (remote servrar). Klienten initierar en handshake där server och klient utbyter capabilities, sedan flödar bidirektionell kommunikation med strukturerade meddelanden. ### De tre lagren i arkitekturen Arkitekturen har tre lager. Det **översta lagret** är klienten (Claude Desktop, Cursor, eller en egen app som använder Anthropic SDK). Det **mellersta lagret** är transportprotokollet som bär meddelanden, antingen via standard input/output för lokala processer eller HTTP+SSE för nätverkstjänster. Det **understa lagret** är själva MCP-servern som exponerar Resources, Tools och Prompts. Handshake-flödet är standardiserat. Klienten skickar `initialize` med sin protocol-version och vilka capabilities den stödjer. Servern svarar med samma fält + server-info. Båda sidor förhandlar vad de kan göra. Detta är dokumenterat i den [officiella protokoll-specifikationen](https://modelcontextprotocol.io/specification/2025-11-25). ### Tre skillnader mot REST Vad gör MCP-protokoll annorlunda från en vanlig REST-API? Tre saker som spelar roll i implementation: **Stateful sessions.** En MCP-anslutning har långlivad state. Klient och server kommer ihåg vad de förhandlat fram. REST är stateless per request – MCP är mer som WebSocket. **Capability negotiation.** Servern berättar för klienten exakt vilka Resources, Tools och Prompts den stödjer vid uppstart. Inga gissningar, ingen swagger-fil att underhålla separat. **Notifications-stöd.** Servern kan pusha uppdateringar till klienten (t.ex. "resurs X har ändrats"). REST kräver polling eller separata webhook-system. Gemensam nämnare för de tre är JSON-RPC, ett transportagnostiskt RPC-format definierat i den [officiella JSON-RPC 2.0-specifikationen](https://www.jsonrpc.org/specification). Eftersom protokollet är oberoende av transporten kan MCP köra identiska meddelanden över både stdio och HTTP utan att du skriver om logiken. ## Hur bygger du en MCP-server från grunden? Det enklaste sättet att bygga en MCP-server är **TypeScript SDK** från Anthropic. Du installerar paketet, definierar dina tools eller resources, och kör servern via stdio för lokala anrop eller HTTP för remote. En minimal server är cirka 30 rader kod. Installation: ```bash npm install @modelcontextprotocol/sdk ``` Här är en minimal MCP-server som exponerar ett enda tool för att hämta dagens datum: ```typescript import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js' import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js' import { z } from 'zod' const server = new McpServer({ name: 'datum-server', version: '1.0.0', }) server.tool( 'get_current_date', 'Hämtar dagens datum i ISO 8601-format', { timezone: z.string().optional().describe('IANA-timezone, t.ex. Europe/Stockholm'), }, async ({ timezone = 'Europe/Stockholm' }) => { const date = new Date().toLocaleString('sv-SE', { timeZone: timezone }) return { content: [{ type: 'text', text: date }], } } ) const transport = new StdioServerTransport() await server.connect(transport) ``` Koden gör tre saker. Skapar en server-instans med namn och version, registrerar ett tool med Zod-schema för input-validation, och kopplar servern till stdio-transporten. När Claude Desktop startar servern kommer användaren se `get_current_date` som ett tillgängligt verktyg. För att exponera **Resources** (data som klienten kan läsa) istället för Tools (funktioner som körs), använder du `server.resource()`. Skillnaden är semantisk: Resources är read-only data, Tools är actions som kan ha sideeffects. Den [officiella TypeScript SDK-dokumentationen](https://github.com/modelcontextprotocol/typescript-sdk) har exempel för båda mönstren. Python-utvecklare använder [Python SDK](https://github.com/modelcontextprotocol/python-sdk) med samma decorator-baserade pattern. Båda SDK:erna har bred uppslutning: [TypeScript SDK:n](https://github.com/modelcontextprotocol/typescript-sdk) ligger på cirka 12 700 GitHub-stjärnor och [Python SDK:n](https://github.com/modelcontextprotocol/python-sdk) på cirka 23 000 (stjärnsiffran syns på respektive repo-sida), och båda uppdateras regelbundet av Anthropic. För **production deployment** byter du transport från stdio till HTTP+SSE. Det kräver ett par extra rader för att starta en Express-server eller liknande HTTP-runtime. Då blir servern nåbar över nätverket istället för bara lokalt. ## Hur säkrar du auth och permissions i MCP? MCP-protokoll har inget inbyggt auth-lager. Säkerheten implementerar du i transportlagret eller per verktyg. Tre vanliga mönster: **API-key-baserad auth** för enkla scenarier, **OAuth 2.1** för enterprise och tredjepartsintegrationer, och **mTLS** för säker server-till-server-kommunikation inom samma interna infrastruktur. För lokala stdio-servrar är auth oftast inte ett problem eftersom användaren kör processen själv med sin egen behörighet. För HTTP-baserade remote-servrar blir auth kritiskt. Här är mönstret för API-nyckel i Bearer-token, som är det enklaste säkra alternativet: ```typescript import express from 'express' import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js' import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js' const app = express() app.use('/mcp', (req, res, next) => { const auth = req.headers.authorization const expected = `Bearer ${process.env.MCP_API_KEY}` if (!process.env.MCP_API_KEY) { return res.status(503).json({ error: 'MCP_API_KEY not configured' }) } if (auth !== expected) { return res.status(401).json({ error: 'Unauthorized' }) } next() }) const server = new McpServer({ name: 'protected-server', version: '1.0.0' }) // ...registrera tools här... const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: () => crypto.randomUUID() }) await server.connect(transport) app.use('/mcp', transport.handler) app.listen(3000) ``` Scoping är nästa lager. Inte alla klienter ska kunna anropa alla tools. Per-tool authorization kan implementeras genom att verifiera klientens identitet (via JWT-claims eller liknande) inne i tool-handlern och returnera permission-error om scope saknas. ### Scoping, OAuth och sandbox-isolering För **OAuth 2.1**-baserad auth följer du standard-flow med en separat OAuth-server som issues access-tokens. OAuth 2.1 är i sig ett pågående IETF-arbete som konsoliderar OAuth 2.0 och senare RFC:er till ett enklare kärndokument, definierat i [IETF-utkastet för OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1). MCP-protokoll har en [officiell auth-specifikation](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) som beskriver hur tokens passas i Bearer-headers. Anthropic rekommenderar OAuth för publik exponering av MCP-servrar. **Sandbox-isolering** är viktig för enterprise. Om din MCP-server kör mot en produktionsdatabas, sätt strikta SQL-permissions på den användaren som servern kör som. Aldrig SUPERUSER. Aldrig DROP TABLE. Standardprincipen är minsta möjliga privilegium per tool. ## Hur testar och debuggar du MCP-servrar? Det officiella verktyget är **MCP Inspector:** en webbaserad UI som låter dig anropa tools, inspektera responses, och se hela JSON-RPC-trafiken i realtid. Du installerar det med npm och pekar det mot din lokala eller remote server. Installation och uppstart: ```bash npx @modelcontextprotocol/inspector node ./dist/server.js ``` Detta startar Inspector på localhost:5173 och spawnar din server som child-process via stdio. UI:n visar en lista över alla registrerade tools, resources och prompts. Du kan anropa varje tool med custom-input och se exakt vad servern svarar. För **HTTP-baserade servrar** anger du URL och eventuell auth-header. Inspector hanterar SSE-streaming och visar request/response-paren i en tidslinje. Detta är ovärderligt för att felsöka capability-negotiation och tool-call-fel. Loggning på serversidan är lika viktigt som Inspector. Eftersom MCP-protokoll använder stdio för lokala servrar är vanliga `console.log`-anrop farliga. De korrumperar JSON-RPC-strömmen och bryter klientanslutningen omedelbart. Använd `console.error` (stderr) för all loggning eller en strukturerad logger som pino. För HTTP-servrar gäller vanlig request-loggning utan stdio-risken. ### Tre vanliga buggar i praktiken Tre vanliga buggar vi sett i konsultarbete för svenska mindre företag. De tre kommer i den ordning de brukar dyka upp, och timeout-buggen är den som stjäl mest felsökningstid eftersom symtomet (servern verkar svara, men klienten ger inget resultat) pekar åt fel håll. **Tool-schemas matchar inte verkligheten.** Den vanligaste och syns oftast redan första testdagen. En Tool deklarerar att `email` är required, men handlern crashar på `email: null`. Lösning: använd Zod (eller liknande) för strict input-validation, inte bara TypeScript-typing. **Long-running tools timeout:ar.** Den som kostar mest tid att felsöka, just för att den ser ut som något annat. MCP-klientens default-request-timeout är 60 sekunder: den konstant (`DEFAULT_REQUEST_TIMEOUT_MSEC = 60000`) ligger hårdkodad i SDK:n, vilket [SDK:ns API-dokumentation bekräftar](https://ts.sdk.modelcontextprotocol.io/v2/variables/_modelcontextprotocol_server.index.DEFAULT_REQUEST_TIMEOUT_MSEC.html). Gör din tool ett tungt API-call eller väntar på en extern process, hinner servern svara men klienten har redan slutat lyssna. Lösning: implementera progress-notifications via MCP:s notification-mekanism (de nollställer timeouten) eller bryt upp arbetet i mindre anrop. **Resource-URI:er kolliderar.** Sällsynt, men lömsk eftersom inget kraschar – fel data returneras tyst. Om två resources har samma URI överskrivs den ena. Lösning: använd hierarkisk URI-design (`db://customers/123` istället för `customer-123`). För djupare felsökning, läs [Inspector-dokumentationen på GitHub](https://github.com/modelcontextprotocol/inspector). ## Vad krävs för att köra MCP i produktion? Tre saker är kritiska i produktion: **rate-limiting** så en buggig klient inte hämtar 10 000 poster per minut, **felhantering** så fel inte läcker stack-traces till klienten, och **observerbarhet** så att du kan reagera på incidenter i tid. Rate-limiting implementerar du i transportlagret. För HTTP-baserade servrar fungerar standardbibliotek som `express-rate-limit` direkt. Sätt initialt 60–100 anrop per minut per API-nyckel och justera baserat på faktisk användning. För stdio-servrar är rate-limiting mindre kritiskt eftersom klienten kör lokalt och styrs av användaren. Error-handling i MCP-protokoll följer JSON-RPC-konventionen. Returnera ett strukturerat error-objekt med code, message, och valfritt data: ```typescript server.tool('fetch_customer', 'Hämta kunddata', { id: z.string() }, async ({ id }) => { try { const customer = await db.query('SELECT * FROM customers WHERE id = $1', [id]) if (!customer) { return { content: [{ type: 'text', text: `Kund med id ${id} hittades inte` }], isError: true, } } return { content: [{ type: 'text', text: JSON.stringify(customer) }] } } catch (err) { // Logga full error på server-sidan, returnera sanitized message console.error('fetch_customer error:', err) return { content: [{ type: 'text', text: 'Internt fel vid kundhämtning' }], isError: true, } } }) ``` Aldrig returnera raw exception-messages till klienten. De kan innehålla credentials, file-paths eller annan känslig info som AI-modellen sedan repeterar i sitt svar till slutanvändaren. ### Secrets, versionering och observerbarhet **Secrets-hantering** hör till samma kategori. API-nycklar och databas-credentials ska in via miljövariabler eller en secrets-manager (Vault, AWS Secrets Manager, Doppler), aldrig hårdkodade i server-koden eller i klientens config-fil. Kom ihåg att klientens MCP-config ofta ligger i klartext på användarens maskin: allt som står där ska betraktas som synligt för användaren. **Versionering** är nästa fråga. MCP-protokoll har protocol-version i handshaken (`2025-11-25` är aktuell daterad specifikation). Din servers egen version sätter du i `McpServer`-konstruktorn. Semantic versioning rekommenderas: breaking changes i tool-signaturer = major bump. **Observability**: logga varje tool-call med tool-name, klient-identifier, duration och success/failure. Detta gör att du kan se vilka tools som faktiskt används, vilka som är långsamma, och vilka som returnerar fel. Standard-loggers som Pino eller Winston fungerar utmärkt. För enterprise: skicka logs till Datadog, Honeycomb eller motsvarande. Konkret monitoring-pattern som fungerar i produktion: ```typescript import { performance } from 'perf_hooks' server.tool('fetch_data', 'Hämtar data', { id: z.string() }, async ({ id }) => { const start = performance.now() const clientId = process.env.MCP_CLIENT_ID ?? 'unknown' try { const result = await fetchFromSource(id) const duration = performance.now() - start logger.info({ tool: 'fetch_data', clientId, duration, status: 'success' }) return { content: [{ type: 'text', text: JSON.stringify(result) }] } } catch (err) { const duration = performance.now() - start logger.error({ tool: 'fetch_data', clientId, duration, status: 'error', err }) return { content: [{ type: 'text', text: 'Internt fel' }], isError: true } } }) ``` De fyra fält som spelar roll i monitoring: `tool` (vilket verktyg), `clientId` (vem anropade), `duration` (latency-mätning), och `status` (success/error). Med dessa kan du bygga dashboards som visar tool-usage per klient, p95-latencies per tool, och error-rates över tid. Detta är minimum för att kunna debugga incidenter och prioritera optimeringar i produktionen. ## Hur integrerar du MCP mot enterprise-system? Tre stora kategorier av enterprise-integrationer dominerar i konsultarbete: **relationsdatabaser** (Postgres, SQL Server), **interna REST-API:er** med befintlig SSO, och **SaaS-system** som Salesforce eller HubSpot. Varje typ har sitt eget mönster för autentisering, skrivskydd och loggning, och alla tre går att produktionssätta med wrapper-servrar. För **Postgres-integration** finns en officiell MCP-server i [github.com/modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers). Den exponerar tabeller som Resources och låter klienten köra read-only queries via Tools. För svenska företag är detta ofta tillräckligt: säljaren frågar Claude på naturlig svenska, Claude översätter till SQL, servern kör mot read-replica. För custom enterprise-API:er rekommenderar vi ett **wrapper-mönster**: skriv en MCP-server som internt anropar ert REST-API med ett tjänstekonto. Klienten ser MCP-tools, men under huven sker autentisering via OAuth eller mTLS mot er befintliga backend. Detta isolerar AI-modellen från interna implementationsdetaljer och låter er logga + auditera all AI-driven trafik centralt. För SaaS-integrationer kollar du först om det finns en officiell MCP-server. [MCP-registret](https://registry.modelcontextprotocol.io) listar tusentals publika servrar, inklusive officiella från Anthropic för Slack, GitHub och Google Drive. Är ditt SaaS inte täckt? Bygg en wrapper-server mot deras REST-API. Räkna med 1–2 dagar per integration för produktionskvalitet. Tre saker att tänka på vid enterprise-integration: **Audit-logging är inte valfritt.** Varje tool-call ska loggas med klient-identitet, payload och resultat till en separat audit-trail. Detta är ofta krav från compliance/säkerhetsteamet. För svenska företag som omfattas av GDPR är detta särskilt viktigt. För djupare genomgång av regelverkskraven, läs vår [guide om EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). **Sandbox-databas för demo.** Innan en MCP-server går mot produktion, testa mot en sandbox-kopia. AI-genererade SQL-queries kan vara kreativa på sätt som överraskar. **Begränsa scope per role.** En MCP-server som exponerar hela CRM ger AI-modellen tillgång till hela CRM. Vill du begränsa till "bara denna users konton"? Implementera scoping i tool-handler baserat på klient-identitet. ## Vad kostar enterprise-grad MCP-implementation? Realistisk kostnad för ett mindre företag ligger på **32–56 utvecklartimmar för första MCP-servern**, plus hosting och drift på 200–2 000 SEK per månad beroende på trafik. Den första servern är dyrast eftersom infrastrukturen byggs då, medan server två och tre tar 8–15 timmar var. Anledningen är konkret: auth-skelettet, den strukturerade loggningen och deploy-pipelinen byggs en gång och återanvänds rakt av. Det som återstår på server två är de nya tools-specifika anropen och deras input-validering, inte grundplattan. När vi i konsultarbete sätter upp en andra server mot samma kunds infrastruktur är det i praktiken bara affärslogiken som är ny. Kostnadsfördelningen för en typisk enterprise-MCP-server: | Komponent | Timmar | Förklaring | |---|---|---| | Server-skelett + tools | 8–12 | Grunduppsättning, första 3–5 tools | | Auth + scoping | 6–10 | OAuth eller API-nyckel + behörigheter per tool | | Felhantering + loggning | 4–8 | Strukturerad loggning, audit-trail | | Testning + Inspector-verifiering | 6–10 | Enhetstester + end-to-end via Inspector | | Produktionssättning | 4–8 | Containerisering, secrets-hantering, övervakning | | Dokumentation + överlämning | 4–8 | README, runbooks, utbildning för intern personal | | **Totalt** | **32–56** | Första servern, ett system | För att översätta timmarna till kronor behöver du ett timpris. Svenska konsulttimmar kostar enligt verklig avtalsdata kring 824–852 kr per timme för utvecklarroller på [Brainvilles marknadsplats](https://www.brainville.com/Statistics/Rates), och [Keymans prisbarometer](https://www.keyman.se/sv/prisbarometern/) över förseglade avtal visar snitt från 845 kr upp till 1 535 kr per timme för seniora roller. Multiplicerar du tabellens 32–56 timmar mot det spannet landar en första server någonstans mellan cirka 27 000 och 86 000 kr i ren utvecklingstid, beroende på senioritet. Det är inte en offert, men det ger dig en marknadsförankrad ribba att jämföra mot. Tilläggskostnader varierar. **Hosting**: en MCP-server på Vercel/Railway/Fly.io kostar 100–500 SEK per månad för rimlig trafik. **Övervakning**: Datadog eller motsvarande adderar 500–2 000 SEK per månad. **Säkerhetsgranskning**: en intern granskning lägger 8–16 timmar till första leveransen, lägre för efterföljande. För en kostnadsöverblick av AI-agent-projekt i bredare bemärkelse, läs vår [kostnadsguide för AI-agenter i Sverige](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). MCP-server är ofta en delkostnad i ett större AI-agent-projekt. När det gäller skillnaden mellan att bygga en MCP-server och att använda en färdig chatbot-lösning, läs vår [jämförelse av AI-agent vs chatbot](/sv/blogg/ai-agenter/ai-agent-vs-chatbot). MCP-protokoll är vad som skiljer en riktig autonomous agent från en wrapped LLM-call. För en bredare introduktion till hur de här delarna hänger ihop för svenska företag, se vår [pillar-artikel om AI-agenter för svenska företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). Är MCP-protokoll värt investeringen? För Claude-baserade arbetsflöden är svaret tydligt ja. För OpenAI-tunga organisationer är svaret "vänta tills OpenAI släpper officiellt stöd, eller bygg en proxy-server om ni inte kan vänta". Tidsspannet är konkret: Anthropic [lanserade MCP den 25 november 2024](https://www.anthropic.com/news/model-context-protocol), så när den här guiden skrivs har protokollet bakom sig runt arton månaders adoption, och kurvan pekar uppåt. Att signalen inte bara är Anthropics egen syns i oberoende mätningar. I Stackloks branschstudie [State of Model Context Protocol in Software 2026](https://stacklok.com/wp-content/uploads/2026/01/State-of-MCP-in-Software-2026_FINAL.pdf), som i december 2025 frågade 300 seniora tekniska beslutsfattare i stora företag, uppgav 45 procent av mjukvarurespondenterna att de redan har MCP-servrar i begränsad eller bred produktion. För ett protokoll som är drygt ett år gammalt är det en ovanligt brant produktionskurva, och det är ett oberoende underlag att väga in vid sidan av leverantörens egna siffror. ## Vanliga frågor --- ### Vad är MCP (Model Context Protocol)? **URL:** https://eteya.ai/sv/blogg/ai-agenter/vad-ar-mcp-model-context-protocol **Sammanfattning:** MCP är Anthropics öppna standard för hur AI-agenter pratar med externa system. Här är vad det är, vilka stödjer det 2026, och om det är produktionsmoget. import FAQ from '@/components/blog/FAQ' MCP står för Model Context Protocol. Det är en öppen standard från Anthropic som låter AI-modeller koppla sig till externa system (filer, databaser, API:er) på ett standardiserat sätt. För små och medelstora företag betyder det att en AI-agent kan läsa ditt CRM, kolla din kalender och uppdatera din databas utan att du bygger en custom integration för varje system. Den här guiden förklarar vad MCP är, hur det skiljer sig från OpenAI:s function calling, vilka leverantörer som stödjer det 2026, och om det faktiskt är produktionsmoget för svenska företag just nu. ## Vad är MCP egentligen? MCP är ett **öppet protokoll** (MIT-licens) som standardiserar hur AI-modeller hämtar data och anropar verktyg i externa system. Anthropic lanserade det den **25 november 2024** för att lösa ett konkret problem: varje AI-agent-bygge krävde tidigare custom-integration mot varje system. Arkitekturen är enkel: en MCP-klient (din AI-app, t.ex. Claude Desktop) kopplar mot en MCP-server (en process som exponerar resurser från ett underliggande system). Kommunikationen sker via [JSON-RPC enligt den officiella specifikationen](https://modelcontextprotocol.io/). ### Tre byggstenar i en MCP-server Tre **primitives** definierar vad en MCP-server kan exponera: - **Resources:** data som AI-modellen kan läsa: filer, databasrader, API-svar - **Tools:** funktioner som AI-modellen kan anropa: skicka mejl, skapa Git-commit, query Postgres - **Prompts:** fördefinierade kontextmallar som AI-modellen kan använda Allt är öppet och dokumenterat på [GitHub-organisationen modelcontextprotocol](https://github.com/modelcontextprotocol), som har den officiella specifikationen, Python-SDK och TypeScript-SDK. Intresset är stort: enbart [referensserver-repot](https://github.com/modelcontextprotocol/servers) hade passerat 86 000 stjärnor i maj 2026 och [specifikationsrepot](https://github.com/modelcontextprotocol/modelcontextprotocol) runt 8 400. Exakta tal är färskvara och rör sig snabbt uppåt. Projektet drivs sedan 2025 under Linux Foundation, inte längre enbart av Anthropic. ## Hur skiljer sig MCP från OpenAI Function Calling? Skillnaden är **standardisering vs vendor-specifikt**. OpenAI Function Calling är en proprietär feature i OpenAI:s API. MCP är ett öppet protokoll som vilken AI-modell som helst kan implementera, och vilken utvecklare som helst kan [bygga en MCP-server](/sv/blogg/ai-agenter/mcp-protokoll-teknisk-guide) för. | Aspekt | MCP | OpenAI Function Calling | |---|---|---| | Standard | Öppen (MIT-licens) | Proprietär OpenAI | | Återanvändning | En MCP-server fungerar med vilken MCP-klient som helst | Function-definitioner skrivs per OpenAI-projekt | | Discovery | Inbyggd capability-listing | Manuell deklaration per anrop | | Ekosystem | 200+ community-kurerade servrar via [awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers) | Inget delat ekosystem | | Vendor lock-in | Inget | Bunden till OpenAI | I praktiken: bygger du mot OpenAI och vill senare byta till Claude måste du skriva om alla function-definitioner. Med MCP byter du bara klient. Alla MCP-servers fungerar fortfarande. Samma logik mot Anthropic, LangChain Tools, eller egna REST-API:er: ingen återanvändning utanför sitt eget ekosystem. ## Vilka leverantörer stödjer MCP 2026? Per 2026 stöds MCP av alla tre stora modell-leverantörer. Det är produktionsmoget i Claude-ekosystemet, OpenAI anammade det officiellt 2025 och Google har byggt in stöd i Gemini. Anthropic driver protokollet och har flest färdiga servrar, men det är inte längre Claude-bundet. Det är den ärliga statusen, inte hypen. - **Claude Desktop** (Anthropics egen app) har fullt native MCP-stöd sedan november 2024 - **Cursor IDE** har native MCP-integration enligt [Cursors egen dokumentation](https://cursor.com/docs/mcp), med stöd för både MCP-verktyg och resources - **Continue.dev** stödjer MCP natively enligt [deras dokumentation](https://docs.continue.dev/customize/deep-dives/mcp), liksom **Cline** och flera andra utvecklarverktyg - **OpenAI** anammade MCP officiellt i mars 2025 och rullade ut fullt MCP-stöd i ChatGPT i september 2025; utrullningen beskrivs i [InfoQ:s genomgång](https://www.infoq.com/news/2025/10/chat-gpt-mcp/) - **Google DeepMind** anslöt sig i april 2025, och stödet finns numera i Gemini-ekosystemet ### Statusen har ändrats under 2025 Bilden ovan har förskjutits snabbt. När den här guiden först skrevs var MCP i praktiken Claude-bundet, men under 2025 anslöt sig de andra stora aktörerna. OpenAI integrerade MCP brett under 2025 och kallar det numera "a key part of how we build", enligt protokollets [ettårsrapport](https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/), och även Google och Microsoft har byggt in stöd. Slutsatsen för dig: MCP är inte längre ett Claude-only-protokoll, utan en standard som de tre största modell-leverantörerna stödjer. Det innebär att skälet att välja MCP, att slippa låsa sig vid en leverantör, har blivit starkare än när protokollet var Claude-bundet. ### Storleken på ekosystemet Det [officiella MCP-registret](https://registry.modelcontextprotocol.io) startade som ett gräsrotsprojekt i februari 2025 och lanserades i [förhandsversion 8 september 2025](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/). Tidslinjen är alltså: protokollet i november 2024, registret ett knappt år senare. Registret innehöll runt [9 600 servrar i maj 2026](https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol), och Anthropic uppgav i december 2025 över 10 000 aktiva publika servrar. Bland dem finns officiella servrar från Anthropic för filsystem, Git, Slack, GitHub, Postgres, SQLite och Google Drive. Notera att de två siffrorna i den här guiden mäter olika saker: tabellen ovan anger 200+ servrar i awesome-mcp-servers, en community-kurerad lista där någon manuellt valt ut intressanta servrar, medan registret räknar alla publicerade servrar i det officiella registret. Det är två mätpunkter, inte en motsägelse. För en bredare introduktion till hur AI-agenter fungerar (där MCP är ett centralt protokoll), läs vår [guide om vad en AI-agent är](/sv/blogg/ai-agenter/vad-ar-en-ai-agent). MCP kopplar modellen mot system; ett annat sätt att ge den kunskap är [RAG, som hämtar svar ur dina egna dokument](/sv/blogg/ai-agenter/vad-ar-rag-retrieval-augmented-generation). ## Vilka användningsfall passar svenska företag? Tre konkreta användningsfall ger redan värde åt svenska företag: koppla en AI-assistent mot affärssystemet för uppslag i realtid, automatisera rapporter från interna databaser, och låta supporten hämta kunddata utan att byta verktyg. De är sorterade nedan från lägst till högst implementationskomplexitet. ### Tre exempel sorterade efter komplexitet **1. Konsultbyrå med GitHub + Slack i Claude.** En 5-personers konsultbyrå installerar MCP-servrar för GitHub och Slack lokalt på Claude Desktop. Konsulterna kan be Claude "summera senaste 24 timmars Slack-diskussion i kanalen #klient-projekt-x och skapa en GitHub-issue för uppföljning". Tid sparad: 10-15 minuter per dag per konsult. Risk: låg, allt kör lokalt. **2. E-handel med Postgres MCP för katalog och lager.** En e-handlare med 15 000 produkter exponerar produktdatabasen via Postgres MCP-server. Säljteamet frågar Claude på naturlig svenska: "Vilka produkter i kategorin elektronik har lager under 10 och inte sålt något senaste 30 dagarna?". Får svar med konkreta produkt-IDn. Risk: medium, kräver DPA om kunddata exponeras. **3. Marknadsföringsbyrå med Google Drive + Notion för proposal-generation.** En byrå kopplar Drive (för existerande proposals) och Notion (för kundnotes) till Claude via MCP. Frågar Claude "bygg ett proposal-utkast för Klient X baserat på senaste mötes-notesna och vår senaste liknande proposal från Q3". Tid sparad: 1-2 timmar per proposal. Risk: medium-hög, kräver DPA + tydlig data-access-policy. ### Vad ett MCP-bygge kostar konkret hos oss Siffrorna ovan är generiska. Det vi själva kan svara på är vad det kostar att gå från idé till driftsatt MCP-koppling för ett svenskt företag, eftersom det är arbete vi säljer. Ett MCP-bygge är i grunden samma sak som ett vanligt AI-agent-bygge: en avgränsad integration mot ett eller flera system. Prisnivåerna följer därför våra ordinarie implementationsnivåer. | Implementationsnivå | Engångskostnad | Vad det räcker till med MCP | |---|---|---| | Avgränsat system | från 45 000 kr | en lokal MCP-server mot ett system, t.ex. filsystem eller en databas | | Verksamhetssystem | 90 000–180 000 kr | två till tre servrar med autentisering, t.ex. Postgres och Slack med OAuth | | Produktionssystem | från 180 000 kr | många system, telefoni och löpande vidareutveckling | Leveranstiden ligger på 2-6 veckor beroende på antal integrationer, och drift kostar 5 000–15 000 kr per månad om du vill ha ett avtal, utan bindningstid. Vill du bara ha en sak byggd och sedan klara dig själv betalar du i princip bara AI-förbrukningen efteråt. För hela kostnadsbilden, inklusive att bygga själv och färdiga verktyg, finns [vår guide om vad AI-agenter kostar för svenska företag](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). ## Hur kommer ditt företag igång med MCP? Det enklaste sättet att börja med MCP är **Claude Desktop + en lokal MCP-server** för ett specifikt användningsfall. Det kräver ingen utvecklare och tar under 30 minuter att sätta upp. Därifrån kan ni utöka till fler servrar och tyngre integrationer när nyttan väl är bevisad. Konkreta steg: 1. Ladda ner Claude Desktop från [claude.ai/download](https://claude.ai/download). Pro-prenumeration krävs för MCP-användning. 2. Välj en officiell MCP-server från [github.com/modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers). Filesystem-server är enklast att börja med. 3. Konfigurera servern i Claude Desktops `claude_desktop_config.json` enligt instruktionerna. 4. Starta om Claude Desktop. Servern är nu tillgänglig, och Claude kan läsa och skriva till valda kataloger. ### När du behöver en utvecklare För skalning behövs sannolikt en utvecklare. Postgres MCP, Slack MCP och Google Drive MCP kräver API-nycklar, OAuth-flöden och säkerhetsgenomgång. I våra egna byggen tar en sådan server normalt ett par till en handfull timmar att konfigurera produktionssäkert, medan resten av tiden går till att testa kantfall och få behörigheterna rätt. Den kostnaden landar i prisnivåerna i tabellen ovan. För GDPR-aspekter och EU AI Act-implikationer, läs vår [guide om EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). Är MCP en hype-teknologi eller produktionsmogen? Ärligt svar: **produktionsmogen, och inte längre Claude-bunden**. Under 2025 anslöt sig både OpenAI och Google, så MCP stöds numera av de tre största modell-leverantörerna. Mognaden varierar fortfarande mellan klienterna, så testa det specifika stödet i ditt verktyg innan du bygger skarpt, men inlåsningsargumentet mot MCP håller inte längre. Det är just bredden av stöd som gör protokollet intressant. ## Vanliga frågor --- ### EU AI Act 2026 – guide för svenska företag + checklist **URL:** https://eteya.ai/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag **Sammanfattning:** EU AI Act 2026 för svenska SMB: 4 risk-kategorier, beslutade deadlines efter Omnibus-förordningen, sanktioner per Artikel 99, plus gratis checklist. import FAQ from '@/components/blog/FAQ' import LeadMagnetForm from '@/components/blog/LeadMagnetForm' **EU AI Act är EU:s första AI-lag.** För de flesta svenska SMB betyder den ingen revolution. Cirka 95 procent av era AI-system hamnar i kategorin "minimal risk" med få eller inga krav. Sommaren 2026 antog EU dessutom Omnibus-förordningen som senarelägger högriskkraven till december 2027, medan transparenskraven gäller sedan 2 augusti 2026. Den här guiden visar vad som gäller idag, vad som skjutits upp, och de fem konkreta stegen ni ska ta nu. ## Vad är EU AI Act i 60 sekunder? EU AI Act är förordning (EU) 2024/1689, den första heltäckande AI-regleringen i världen. Lagen trädde i kraft 1 augusti 2024 och klassificerar AI-system i fyra risk-kategorier med olika krav. Alla företag som använder AI inom EU berörs, även icke-EU-bolag som säljer till EU-marknaden. Lagen bygger på en enkel princip: ju högre risk för människors säkerhet och rättigheter, desto strängare krav. Förordningen tar inspiration från GDPR i sin struktur men har en bredare ambition. Den reglerar inte bara dataskydd utan hela kedjan från AI-system till slutanvändare. För svenska SMB innebär detta att ni behöver [klassificera era AI-system](/sv/blogg/eu-ai-act/eu-ai-act-risk-klassificering), förstå vilken kategori de tillhör, och vidta passande åtgärder. För de allra flesta är åtgärderna minimala. Hela lagtexten finns hos [EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng) på 23 EU-språk. Jämfört med GDPR är EU AI Act mer specifik i sin riskbedömning. GDPR bygger på generella principer (laglighet, transparens, ändamål) och kräver att företag själva tolkar hur de tillämpas. EU AI Act listar i stället konkreta scenarier som är förbjudna, hög-risk eller transparenskrav. Det gör lagen lättare att förstå men också striktare när den gäller. GDPR gäller dessutom parallellt med AI Act, och hur du håller AI inom dataskyddet i praktiken går vi igenom i [guiden om AI och GDPR för företag](/sv/blogg/ai-agenter/ai-och-gdpr-sakerhet). ## Vilka deadlines gäller och vad försenas just nu? EU AI Act är uppbyggd i faser med flera deadlines mellan 2025 och 2028. Förbjudna AI-praktiker, GPAI-regler och AI-literacy-kravet gäller redan sedan 2025. Hög-risk AI hade ursprungligen deadline 2 augusti 2026, men Digital Omnibus-förordningen ((EU) 2026/1744, i kraft 27 juli 2026) sköt upp den till 2 december 2027. Transparenskraven i Artikel 50 flyttades inte – de gäller sedan 2 augusti 2026. Tidsplanen är uppbyggd i faser. Vissa delar gäller redan, transparenskraven gäller sedan 2 augusti 2026, och högriskkraven är uppskjutna genom Digital Omnibus-förordningen. **Redan i kraft:** - **2 februari 2025**: förbjudna AI-praktiker (Artikel 5) gäller. Ingen försening föreslagen. - **2 augusti 2025**: krav på General-Purpose AI-modeller (OpenAI, Anthropic, Mistral och liknande) gäller. - **AI-literacy (Artikel 4)**: gäller sedan februari 2025. All personal som hanterar AI-system ska ha tillräcklig kunskap. **Beslutat genom Omnibus-förordningen:** - **2 augusti 2026**: transparenskraven (Artikel 50) och AI-kontorets bötesrätt över generella AI-modeller gäller – det här datumet flyttades aldrig. - **24 juli 2026**: Digital Omnibus publiceras i EU:s officiella tidning som **förordning (EU) 2026/1744** och träder i kraft 27 juli. Högrisk-deadline för fristående system (Annex III) flyttas till **2 december 2027**. - **2 december 2026**: nya förbud börjar gälla (bland annat AI-verktyg för övergreppsmaterial), och övergångsfristen för märkning av syntetiskt innehåll löper ut. - **2 augusti 2028**: hög-risk AI inbäddad i reglerade produkter (Annex I). Senareläggningen är beslutad och publicerad: [förordning (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng) trädde i kraft den 27 juli 2026 – fem dagar före den gamla högrisk-deadlinen. Samtidigt [inledde kommissionen tillsynen](https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august) av transparenskraven den 2 augusti 2026. Det som gäller nu är alltså inte en paus: transparens och GPAI-tillsyn är skarpa, det är högriskkraven som fått mer tid. Vad betyder detta praktiskt? Förbjudna praktiker, GPAI-regler, AI-literacy och transparenskraven är **i kraft** och sanktionerbara. Det är bara hög-risk-bestämmelserna som fått mer tid – använd den till att dokumentera i lugn takt. ## Vilka är de fyra risk-kategorierna och hur skiljer de sig? EU AI Act klassificerar AI-system i fyra kategorier baserat på risk för människor: förbjudet, hög-risk, begränsad risk, och minimal risk. Förbjudet stoppas helt, hög-risk kräver omfattande dokumentation och registrering, begränsad risk kräver transparens-disclaimer, och minimal risk har inga särskilda krav. Här är vad varje kategori innebär praktiskt för svenska SMB. ### Förbjudna AI-system (Artikel 5) Vissa praktiker är helt förbjudna sedan 2 februari 2025. Det handlar om åtta typer av AI som anses oacceptabla i ett demokratiskt samhälle, alla listade i [Artikel 5 av lagen](https://artificialintelligenceact.eu/article/5/): - Manipulativa AI-tekniker som utnyttjar psykologiska sårbarheter - Sociala betygssystem (typ Kinas social credit) - Realtids-biometrisk identifiering i offentliga rum (med få polisundantag) - Känsloigenkänning på arbetsplatsen eller i utbildning - Biometrisk kategorisering baserad på ras, religion eller politisk åsikt - Prediktiv polisarbete baserat enbart på profilering - Oselektiv skrapning av ansiktsbilder från internet för biometriska databaser - AI-system som klassificerar personer baserat på vissa sociala drag För svenska SMB är de mest relevanta förbjudna praktikerna **manipulativa tekniker** (säljpsykologi som utnyttjar sårbara personer) och **känsloigenkänning på personal** (övervakning av medarbetares humör genom kameror eller röstanalys). Använd dessa områden som tydlig "nej-zon" när ni utvärderar nya AI-leverantörer. ### Hög-risk AI (Annex III) Hög-risk-kategorin är där dokumentationskraven blir omfattande. Annex III i lagen listar [åtta användningsområden](https://artificialintelligenceact.eu/annex/3/) som klassas som hög-risk: - Biometri utöver det som är förbjudet - Kritisk infrastruktur (energi, transport) - Utbildning och yrkesträning - Rekrytering och HR-beslut - Kreditbedömning, försäkring och socialförsäkring - Brottsbekämpning - Migration, asyl och gränskontroll - Demokratiska processer och rättssystemet För svenska SMB är de två relevanta områdena **rekryterings-AI** (CV-screening, kandidatutvärdering) och **kreditbedömning**. Använder ni AI som filtrerar jobbansökningar eller bedömer en kunds betalningsförmåga? Då är ni i hög-risk-kategorin. Kraven inkluderar registrering i EU-databas, teknisk dokumentation, riskhanteringssystem, mänsklig övervakning och kvalitetskontroll av träningsdata. Förbered budget och tid för detta som ett projekt på flera månader, inte en helg. ### Begränsad risk: transparenskrav (Artikel 50) [Artikel 50](https://artificialintelligenceact.eu/article/50/) reglerar AI-system som måste vara transparenta gentemot användaren. Det handlar om tre typer: - **Chatbots och AI-agenter** som pratar med människor. Personen ska informeras om att den interagerar med AI. - **Deepfakes** (AI-genererat bild, video eller ljud). Tydlig märkning krävs. - **AI-genererat textinnehåll i offentligt intresse**. Måste märkas, om inte en människa har granskat och tagit redaktionellt ansvar. Detta är där de flesta Eteya-kunder hamnar, fast nyansen spelar roll. En kundtjänst-chattbot eller en röst-bot som svarar gäster måste tydligt deklarera "Du pratar med en AI-assistent" vid första interaktionen. En intern AI-agent som räknar kostnad per pizza eller föreslår påfyllningsbeställningar (som inventory-systemet på Sannegårdens Pizzeria) hamnar däremot i minimal risk, eftersom slutkunden aldrig möter den direkt. Budskapet: transparens-kravet träffar gränssnittet mot människan, inte automationen i bakgrunden. Vad lagen betyder specifikt för AI-agenter, och vem som bär ansvaret när de agerar självständigt, går vi igenom i [AI-agenter och EU AI Act](/sv/blogg/ai-agenter/ai-agenter-eu-ai-act). ### Minimal risk: inga särskilda krav Den fjärde kategorin är alla andra AI-system. Här finns inga specifika krav från EU AI Act. Cirka 95 procent av AI-system i svenska SMB-företag hamnar här: process-automation, intern produktivitets-AI, AI-baserad rapportering och automatiserade workflows som inte interagerar direkt med kunder. För dessa system är det "business as usual", men ni bör fortfarande dokumentera vilka system ni använder och i vilket syfte om en revisor eller myndighet skulle fråga. ## Är ert AI-system hög-risk? Snabbtest för svenska SMB Snabbtest för svenska SMB: gå igenom fem frågor i ordning för att avgöra ert AI-systems risk-kategori. Använder ni AI för rekrytering eller kreditbedömning hamnar ni i hög-risk. Chatbot eller AI-agent som pratar med kunder är begränsad risk. ChatGPT internt utan kundkontakt är minimal risk. Här är frågorna: ### Fråga 1: Använder ni AI för beslut om människor? Områden att kolla: - Rekrytering (CV-screening, kandidat-ranking, intervju-analys) - Kreditbedömning eller försäkringsbeslut - Sjukvård (diagnos, behandlingsförslag) - Utbildning (bedömning, antagning) - Brottsbekämpning eller migration Om JA: **hög-risk**. Börja förbered dokumentation och riskhanteringssystem. ### Fråga 2: Manipulerar AI känslor eller psykologi? Övervakar AI medarbetares humör på arbetsplats eller skola, eller utnyttjar psykologiska sårbarheter? Om JA: **förbjudet** enligt Artikel 5. Stoppa användningen omedelbart. ### Fråga 3: Är det en chatbot, AI-agent eller media-generator? Pratar AI-systemet direkt med människor, eller skapar det bild, video eller ljud som visas för människor? Om JA: **begränsad risk**. Lägg till transparens-disclaimer ("Du chattar med AI" eller liknande). ### Fråga 4: GPAI-modell internt utan kundkontakt? Använder ni ChatGPT, Claude, Gemini eller liknande internt för produktivitet, kodning, eller analys utan att slutkunden möter AI:n? Om JA: **minimal risk** för er som deployer. Provider-skyldigheterna ligger på modell-bolagen (OpenAI, Anthropic, Google). ### Fråga 5: Inget av ovan? Då är ert system **minimal risk**. Inga specifika EU AI Act-krav, men dokumentera ändå vilka system ni använder för intern översikt och eventuell framtida revision. ## Sanktioner: vad kostar det att inte följa lagen? Sanktionerna för EU AI Act-brott regleras i [Artikel 99](https://artificialintelligenceact.eu/article/99/) och är substantiella. Förbjudna praktiker kostar upp till 35 miljoner EUR eller 7 procent av global omsättning, andra brott upp till 15 miljoner EUR eller 3 procent, och vilseledande information till myndighet upp till 7,5 miljoner EUR eller 1 procent. - **Brott mot förbjudna AI-praktiker (Artikel 5):** upp till **35 miljoner EUR** eller **7 procent av global årsomsättning**. Det högre av de två. - **Brott mot andra skyldigheter** (Artikel 16, 22, 23): upp till **15 miljoner EUR** eller **3 procent av omsättningen**. - **Vilseledande information** till myndighet: upp till **7,5 miljoner EUR** eller **1 procent**. För svenska SMB gäller dock ett viktigt undantag. Enligt Artikel 99(6) ska boten för små och medelstora företag (inklusive startups) sättas till **det lägre** av belopp och procent, inte det högre som för storbolag. Detta är medvetet för att inte krossa innovation hos mindre aktörer. Konkret räkne-exempel: ett svenskt SMB med 50 miljoner kronor i omsättning som bryter mot förbjudna praktiker riskerar 7 procent av omsättningen (3,5 MSEK), inte 35 miljoner EUR. För andra brott är taket 3 procent av omsättningen (1,5 MSEK). Sanktionerna är fortfarande tunga, men proportionalitet för småbolag är inbyggd i lagen. Tilläggas bör att marknadskontrollmyndigheten (i Sverige troligen PTS eller IMY beroende på fall) kan kräva åtgärder utöver böter: tvångsföreläggande att stoppa AI-systemet, krav på återkallelse, eller temporärt förbud att placera produkten på marknaden. För många SMB är det driftstoppet som blir den tunga kostnaden, inte botbeloppet. Vi går igenom vad som faktiskt händer vid tillsyn, och vilka undantag som sänker risken, i [vår fördjupning om EU AI Act-sanktioner och undantag](/sv/blogg/eu-ai-act/eu-ai-act-sanktioner-och-undantag). ## Vem är svensk tillsynsmyndighet för EU AI Act? Sverige har per augusti 2026 ännu inte antagit den kompletterande nationella lagen. Linjen från utredningen SOU 2025:101 gäller dock: [PTS är samordnande marknadskontrollmyndighet](https://pts.se/ai/ai-forordningen/) och nationell kontaktpunkt, IMY har ansvar för bland annat förbjudna praktiker och biometri, och Finansinspektionen för finanssektorn. Förordningen är direkt tillämplig – ni är bundna av den oavsett var den svenska lagstiftningen står. [SOU 2025:101](https://www.regeringen.se/pressmeddelanden/2025/10/utredning-foreslar-forbud-mot-vissa-ai-system-och-sanktioner-for-bristande-dokumentation-av-hogrisk-ai/), utredningen som lämnades till regeringen 6 oktober 2025, föreslår följande uppdelning: - **PTS (Post- och telestyrelsen)** som primär samordnare och marknadskontrollmyndighet - **IMY (Integritetsskyddsmyndigheten)** för förbjudna praktiker, biometri, brottsbekämpning, och områden som överlappar med GDPR - **Finansinspektionen** för finanssektor (kreditbedömning, försäkring) - **Övriga sektorsmyndigheter** för specifika branscher (Läkemedelsverket, Transportstyrelsen, och liknande) [IMY har själva bekräftat](https://www.imy.se/verksamhet/ai/ai-forordningen/) att de förbereder rollen som tillsynsmyndighet inom sina ansvarsområden, men understryker att "det finns inga beslut än" om den slutgiltiga strukturen. [PTS publicerar löpande vägledning](https://pts.se/ai/ai-forordningen/) på sin webbplats. För svenska SMB är rekommendationen: håll koll på både IMY:s och PTS:s officiella kanaler för uppdateringar under sommaren 2026. ## Vilka är de vanligaste missförstånden om EU AI Act? Många svenska SMB tror EU AI Act är mer omfattande och strängare än den faktiskt är. Vi möter dagligen fyra missförstånd: att all AI-användning kräver EU-godkännande, att intern ChatGPT-användning måste rapporteras, att allt AI-genererat innehåll måste märkas, och att hög-risk-förseningen betyder att inget behöver göras. Alla fyra är fel. ### Missförstånd 1: "All AI-användning kräver godkännande från EU" Fel. Inget AI-system kräver formellt godkännande, inte ens hög-risk. Hög-risk-system kräver registrering i EU-databasen och dokumentation, men ingen myndighet "godkänner" systemet innan användning. Ansvaret för korrekt klassificering och dokumentation ligger på er som företag. ### Missförstånd 2: "Vi använder ChatGPT så vi måste rapportera till EU" Fel. Att använda en GPAI-modell (ChatGPT, Claude, Gemini) internt för produktivitet räknas som minimal risk för er som deployer. Det är OpenAI, Anthropic och Google som har provider-skyldigheterna att rapportera och dokumentera modellen. ### Missförstånd 3: "Vi måste märka allt AI-genererat innehåll på webbplatsen" Delvis fel. Artikel 50 kräver märkning av AI-genererat innehåll i offentligt intresse, men det finns ett tydligt undantag. Om en människa redigerar texten och tar redaktionellt ansvar krävs ingen särskild märkning. Marketing- och blogg-innehåll med redaktionell granskning är vanligtvis OK utan disclaimer. ### Missförstånd 4: "Hög-risk-systemen försenas, alltså behöver vi inte göra något" Fel. Förbjudna praktiker (Artikel 5) gäller redan sedan februari 2025. GPAI-regler (Artikel 53) gäller sedan augusti 2025. AI-literacy (Artikel 4) gäller sedan februari 2025. Och transparenskraven (Artikel 50) gäller sedan 2 augusti 2026. Det är bara hög-risk-bestämmelserna som fått mer tid – till 2 december 2027 genom Omnibus-förordningen. ## Vilka fem steg ska svenska SMB ta nu? Svenska SMB ska ta fem konkreta steg för EU AI Act-compliance: inventera alla AI-system, klassificera dem efter risk-kategori, lägga in transparens-disclaimers på chatbots och AI-agenter, börja dokumentation om ni har hög-risk-system, och träna personalen i AI-literacy. Här är handlingsplanen baserad på rekommendationer från [PwC](https://cee.pwc.com/eu-ai-act-compliance-and-transformation.html), [Deloitte](https://www.deloitte.com/cz-sk/en/services/consulting/services/cyber-risk/eu-ai-act.html) och [Vinge](https://www.vinge.se/nyheter/utredningen-om-ai-forordningen-har-lamnat-over-sitt-betankande-till-regeringen/). ### Steg 1: Inventera alla AI-system ni använder Lista varje system: AI-agenter, chatbots, kundtjänst-automation, intern produktivitets-AI (Copilot, ChatGPT, Claude), prediktiv analys, marketing-AI. Inkludera även AI som är inbyggt i SaaS-verktyg ni redan använder (CRM, HR-system, accounting-program). ### Steg 2: Klassificera varje system i en av de fyra kategorierna Använd snabbtestet ovan eller vår gratis checklist (länk längre ner). Notera vilken artikel i lagen som styr ert specifika fall. ### Steg 3: Lägg in transparens-disclaimers på chatbots och AI-agenter För alla system som faller under begränsad risk: säkerställ att användare informeras om AI vid första kontakt. En enkel mening räcker. Exempel: "Du chattar med en AI-assistent. Behöver du nå en människa, skriv 'mänsklig agent'." ### Steg 4: Om ni har hög-risk-system, börja dokumentation nu Även om hög-risk-deadlinen nu är flyttad till december 2027, är dokumentations- och riskhanteringskraven omfattande. Att börja sex månader innan är minimum för att undvika stress. Använd vår [mall för EU AI Act-dokumentation](/sv/blogg/eu-ai-act/eu-ai-act-dokumentation-mall) för att komma igång med inventering och register. ### Steg 5: Träna personalen i AI-literacy Kravet om AI-literacy enligt Artikel 4 har gällt sedan 2 februari 2025. Det betyder att personal som använder AI-system ska ha tillräcklig kunskap för att förstå dess kapacitet och begränsningar. För SMB räcker det med basal utbildning: en internutbildning på en timme om grundläggande AI-koncept räcker långt. ## Hur kan Eteya hjälpa er navigera EU AI Act? Eteya har implementerat över 100 AI-system åt svenska SMB med compliance-fokus från dag ett: transparens där det krävs, dokumentation som standard, och arkitektur som är lätt att uppdatera när regler ändras. Vi hjälper er kartlägga era system, klassificera dem mot EU AI Act, och bygga rätt från början. Behöver ni hjälp med kartläggning, klassificering, eller implementering? Boka ett kostnadsfritt 30-min strategimöte så går vi igenom era system tillsammans. ## Vanliga frågor --- ### Vad är skillnaden mellan AI-agent och chatbot? **URL:** https://eteya.ai/sv/blogg/ai-agenter/ai-agent-vs-chatbot **Sammanfattning:** AI-agent agerar autonomt mot mål, chatbot svarar på frågor. Här är skillnaden i kostnad, ROI, GDPR och 8 dimensioner. Konkret beslutsguide för svenska företag. import CaseLink from '@/components/blog/CaseLink' import FAQ from '@/components/blog/FAQ' En AI-agent agerar autonomt mot ett mål. En chatbot svarar på frågor. Det är den korta versionen, men beslutet mellan dem påverkar kostnad, implementationstid, GDPR-exponering och hur mycket arbete tekniken faktiskt tar bort från ditt team. Den här guiden bryter ner skillnaden mellan AI-agent och chatbot i åtta dimensioner som spelar roll för svenska företagsledare. Du får konkreta SEK-priser, beslutsstöd från våra verkliga implementationer, och en tydlig matris för "i din situation, börja med X". Om du först behöver definitionen, läs vår guide om [vad en AI-agent är](/sv/blogg/ai-agenter/vad-ar-en-ai-agent). ## Vad är den korta skillnaden mellan AI-agent och chatbot? En **chatbot** svarar på frågor inom ett avgränsat ämnesområde, oftast via fördefinierade flöden eller en språkmodell utan exekverande förmåga. En **AI-agent** kombinerar resonemang med tool-use, tekniskt via [MCP-protokollet](/sv/blogg/ai-agenter/mcp-protokoll-teknisk-guide), och utför hela ärenden själv. Den kan boka, beställa, uppdatera CRM och eskalera till människa när det behövs. Skillnaden är inte storleken på språkmodellen. Det är om systemet kan **agera i externa system** eller bara generera text. [Anthropics distinktion mellan workflow och agent](https://www.anthropic.com/research/building-effective-agents) sammanfattar det väl: ett "workflow" följer en förutbestämd kedja av steg, medan en "agent" själv väljer hur den når målet baserat på det den ser i ärendet. Chatbots är ofta workflows. Agenter är resonerande system med autonomi. För svenska små och medelstora företag som har funderat på AI-projekt sedan 2023 har skillnaden i praktiken varit mindre tydlig än den är 2026. Chatbots med LLM-baksida (typ ChatGPT-anslutna kundsupport-bottar) har börjat kallas "agenter" i marknadsföring även när de inte agerar utanför chatten. Den här guiden använder strikt definition: agera = AI-agent, bara svara = chatbot. ## Hur jämförs de dimension för dimension? Den enklaste jämförelsen är åtta dimensioner som faktiskt spelar roll när du fattar beslutet. Vi rangordnar dem efter relevans för mindre företag, inte efter tekniskt djup. Det är affärsvärdet, inte arkitekturen, som styr vilken som passar. Tabellen nedan sammanfattar var de skiljer sig mest: funktion, ROI och compliance-börda. | Dimension | Chatbot | AI-agent | |---|---|---| | **Vad den gör** | Svarar på frågor | Agerar mot mål | | **Use-case-passform** | FAQ-volym, repetitiva svar | Multi-step-ärenden, kombinerar system | | **Implementations-tid** | 1–2 veckor | 2–6 veckor | | **Total kostnad år 1 (SEK)** | ca 17 000–180 000 | ca 105 000–360 000 | | **GDPR / EU AI Act-exponering** | Lägre (begränsad scope) | Högre (tool-use + data-access) | | **Integrationer** | 1–2 system | 3–10+ system | | **Autonomi & risk** | Regelbaserat, låg risk | Autonomt, kräver guardrails | | **ROI-mönster** | Cost-saver (sparar tid) | Revenue-driver (skapar nya intäkter) | [Salesforce har en grundläggande genomgång av AI-agent kontra chatbot](https://www.salesforce.com/se/agentforce/ai-agent-vs-chatbot/) ur ett CRM-perspektiv. Det vi gör annorlunda i tabellen ovan är att rangordna efter "vad du får ut", inte efter teknisk autonomi – för svenska företag är ROI-mönster nästan alltid den dimension som styr beslutet, inte arkitektur-djupet. År-1-totalen i rad fyra är härledd ur artikelns egen prissektion längre ner, inte ett löst marknadsspann. Den räknar implementation plus tolv månaders drift: en chatbot landar på 5 000–60 000 kr i bygge plus 1 000–10 000 kr i månaden, en agent på från 45 000 kr (en process) till 180 000 kr och uppåt (flera processer) plus 5 000–15 000 kr i månaden. Interna timmar för processkartläggning tillkommer i båda fallen och ligger utanför dessa siffror. Notera särskilt rad fyra och åtta. År-1-spannen överlappar mer än man tror: en enkel agent på en process kan landa lägre än en custom-byggd LLM-chatbot, eftersom implementationsarbetet och antalet integrationer styr priset mer än etiketten "chatbot" eller "agent". Den verkliga skillnaden ligger i rad åtta. En AI-agent skapar oftast nya intäkter (ärenden som tidigare gick förlorade), medan en chatbot mest sparar tid på existerande arbete. Det är två olika investeringskalkyler. När en kund säger "vi vill ha AI" är första frågan vi ställer alltid: handlar det om att spara tid på ärenden ni redan löser, eller om att fånga upp ärenden ni missar idag? Svaret styr nästan alltid valet mellan chatbot och agent. Att en autonom agent kan flytta hela kostnadskalkylen är inte bara vår erfarenhet. Gartner förutspår att [agentic AI autonomt löser 80 procent av vanliga kundtjänstärenden till 2029](https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290) och då sänker driftkostnaderna med 30 procent. Det är just den kombinationen, fler lösta ärenden utan mänsklig insats, som gör agenten till en intäktsdrivare snarare än bara en kostnadsbesparare. ## När räcker en chatbot, när behöver du en AI-agent? Tumregeln vi använder med klienter: om uppgiften kan beskrivas i ett tydligt flöde-schema och bara kräver svar inom en kanal, räcker en chatbot. Om den kräver att system uppdateras, data hämtas från flera ställen, eller hela ärenden hanteras från start till klar, behövs en AI-agent. Konkreta volymtrösklar från våra implementationer: - **Chatbot räcker:** Under 50 FAQ-ärenden per dag, regler relativt stabila, en kommunikationskanal (chat eller mejl), ingen integration mot CRM/ERP behövs - **AI-agent behövs:** Över 100 ärenden per dag, multi-step-flöden (exempelvis bokning som kräver kalender-koll och CRM-uppslag), integrationer mot 2+ system, säsongs-spikar som kräver auto-skalning [IBM:s tröskelresonemang kring AI-agenter](https://www.ibm.com/think/topics/ai-agents) bekräftar detta från enterprise-perspektiv. Skillnaden är inte chatbot vs agent som binärt val. Det är när komplexiteten i ärendet kräver att systemet själv kombinerar information från flera källor och fattar beslut om vad det ska göra härnäst. För en restaurang som tar emot beställningar via telefon behövs agent. Beställningen är multi-step (meny-uppslag, lager-koll, leveransadress från CRM, POS-insättning, SMS-bekräftelse). För en e-handelssajt som besvarar leverans-frågor och returer räcker oftast chatbot, om volymen är under 100 per dag. Vill du se var en agent gör störst nytta i en webbutik, läs vår guide om [vad en AI-agent gör i en e-handel](/sv/blogg/ai-agenter/ai-agent-for-e-handel). För en fördjupande genomgång av hur AI-agenter passar svenska företag i olika branscher, läs vår [pillar-artikel om AI-agenter för mindre företag](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). ## Vad kostar de i Sverige? En chatbot kostar typiskt 5 000–60 000 kr att bygga och några tusen kronor i månaden. En konsultbyggd AI-agent kostar från 45 000 kr i implementation och 5 000–15 000 kr per månad i drift, beroende på omfattning och utan bindningstid. Agenten kostar mer för att den utför hela ärenden, inte bara svarar. Så här ser spannen ut för svenska implementationer 2026: | Typ | Implementation | Drift per månad | |---|---|---| | Regelbaserad chatbot | 5 000–15 000 kr | 1 000–3 000 kr | | LLM-chatbot (custom) | 25 000–60 000 kr | 4 000–10 000 kr | | AI-agent (en process) | från 45 000 kr | 5 000 kr | | AI-agent (flera processer) | från 180 000 kr | 15 000 kr | Driftkostnaden för själva AI:n är försumbar: öre till enstaka kronor per ärende enligt modelleverantörernas prislistor. [Anthropics egen prissida](https://platform.claude.com/docs/en/about-claude/pricing) visar i ett räkneexempel att 10 000 hanterade supportärenden kostar ungefär 37 USD på deras effektiva Haiku-modell, alltså runt 4 öre per ärende. Även en agent med verktygsanrop som drar fler tokens stannar i kronor per ärende. Det du betalar för är arbetet runt AI:n, alltså bygge, integrationer och underhåll, inte modellanropen i sig. Två konkreta case för referens: **Sannegårdens Pizzeria** kostade 52 000 kr i implementation plus 3 500 kr/månad i drift. AI-agenten kopplar ihop kassasystemet med leverantörsfakturorna, räknar kostnad per pizza i realtid och föreslår en färdig påfyllningsbeställning varje söndag. En chatbot hade aldrig kunnat göra det här jobbet, eftersom det kräver autonomt agerande mot flera system samtidigt och proaktiva beslut snarare än reaktiva svar. Värde: 32 procent mindre matsvinn, 9 kr i höjd marginal per pizza och 6 timmar i veckan sparat på inventering, vilket landar på cirka 315 000 kr/år i nettoeffekt. Återbetalning: under tre månader. **NordicRank** kostade 65 000 kr för 18 automatiserade processer (rapportgenerering, klient-onboarding, leverantörsuppföljning, fakturahantering) plus 4 500 kr/månad drift. Värde: 13,4 timmar/vecka sparad arbetstid, vilket räknat mot lönekostnad är cirka 380 000 kr/år. Återbetalning: fyra månader. Det som avgör om kalkylen går ihop är vad det manuella alternativet kostar. En handläggare som tar ärendena för hand kostar lön plus sociala avgifter. [SCB:s lönestatistik](https://www.scb.se/hitta-statistik/statistik-efter-amne/arbetsmarknad/loner-och-arbetskostnader/lonestrukturstatistik-hela-ekonomin/pong/tabell-och-diagram/genomsnittlig-manadslon-efter-sektor/) anger en genomsnittlig månadslön på 41 600 kr för 2024, och med sociala avgifter landar timkostnaden runt 300–350 kr. Det är den siffran en chatbot eller agent ställs mot. Ju dyrare det manuella arbetet är, och ju mer volym som binds i det, desto snabbare betalar sig automationen. För djupare prisgenomgång med ROI-formler och alla kostnads-faktorer, läs vår [dedikerade kostnadsguide för AI-agenter](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). Generellt: en AI-agent som hanterar volym + skapar nya intäkter betalar sig oftast på 2-6 månader. En chatbot betalar sig på 6-12 månader genom sparad tid. ## Hur lång tid tar implementation? Implementationstiden skiljer sig dramatiskt beroende på komplexitet. En regelbaserad chatbot är klar på en vecka, medan en komplex AI-agent med flera integrationer tar fyra till sex veckor. Skillnaden ligger i antalet system som ska kopplas in och hur många kantfall som måste testas innan driftstart. Här är typisk tid från första möte till live drift: ### Chatbot (1-2 veckor) - Vecka 1: Discovery + design av flöden + bygga - Vecka 2: Test + go-live på sajten ### AI-agent (2-6 veckor) - Vecka 1: Discovery + prioritering. Vi väljer EN process att börja med – inte tio - Vecka 2-3: Design + utveckling. Specificera exakt flöde, integrera mot system, bygga i testmiljö - Vecka 4: Pilot på 10-20 % av volymen, mäta hit-rate och eskaleringsrate - Vecka 5-6: Skalning till full volym. Människan tar de eskalerade ärendena Om du vill bygga något själv finns alternativ. [Microsoft Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/) erbjuder en låg-kod-väg som kan komma igång på några dagar för en chatbot, men kräver fortfarande betydande arbete för en multi-step-agent med integrationer mot interna system. Det som har förändrats 2026 är att AI-agenter inte längre är ett risk-projekt. [Stanford AI Index](https://hai.stanford.edu/ai-index/2025-ai-index-report) visar att efterfrågan på agentic AI-kompetens i jobbannonser växte mer än 280 procent på ett enda år, och att 78 procent av organisationerna nu använder AI i minst en affärsfunktion mot 55 procent året innan. Tekniken är produktionsmogen. Den största risken idag är inte tekniken, utan att inte mäta baseline innan agenten går live så att man inte kan visa ROI efter sex månader. ## Hur påverkar GDPR och EU AI Act ditt val? Båda kräver att du deklarerar för kunder att de pratar med AI. Men en AI-agent har högre risk-exponering eftersom den hanterar mer data och tar autonoma beslut. Det betyder att GDPR-kraven blir hårdare och dokumentationen kräver mer arbete. Konkreta krav 2026: - **Transparens** (EU AI Act art. 50): "Du pratar nu med vår AI-assistent" räcker oftast i början av samtalet - **DPA-avtal** med leverantör om kunddata processas - **EU-databehandling**: använd Anthropic, OpenAI EU-region eller Azure Sweden Central - **Loggning + retention**: typiskt 30 dagar för debug, sedan automatisk radering - **Rätt att eskalera till människa**: kunden ska alltid kunna be om en mänsklig handläggare [Integritetsskyddsmyndigheten (IMY)](https://www.imy.se/verksamhet/ai/ai-forordningen/) är auktoriteten i Sverige som tolkar GDPR-tillämpning på AI-system. Deras vägledning under 2025 har förtydligat att lagligheten i grunden inte skiljer sig mellan chatbot och AI-agent, men dokumentationen behöver vara mer omfattande för agenter eftersom de gör fler beslut och hanterar fler integrationer. [Merparten av EU AI Act börjar gälla 2 augusti 2026](https://artificialintelligenceact.eu/implementation-timeline/). För de flesta implementationer hos mindre företag hamnar både chatbots och agenter i kategorin "begränsad risk" som bara kräver transparens. Men om din agent fattar beslut om kreditbedömning, anställning, eller hälso-relaterade ärenden hamnar du i "hög risk"-kategorin som kräver betydligt mer compliance-arbete. Värt att veta är att förordningen har proportionalitet inbyggd för mindre aktörer. Bötesbeloppen vägs mot företagets storlek, dokumentationen får lämnas i förenklad form för småföretag som bygger hög-risk-system, och flera undantag är skrivna för just den storleken. Vad som faktiskt händer vid tillsyn, och vilka lättnader som sänker risken, går vi igenom i [vår guide till EU AI Act-sanktioner och undantag](/sv/blogg/eu-ai-act/eu-ai-act-sanktioner-och-undantag). Praktiskt: om du redan kör manuell kundtjänst med personal som kan dataskyddslagstiftning så är steget till chatbot eller agent mindre än det verkar. Det handlar mest om att översätta existerande processer till AI-kontexten och lägga till tydlig kommunikation om att en AI är inblandad. Den största fallgropen vi ser i implementations-fasen är inte juridik, utan otydlig data-access-policy. Många företag ger AI-system bredare behörigheter än de hade gett en mänsklig junior-anställd. Det är en risk som blir uppenbar först vid en granskning eller ett kund-klagomål. ## När är hybrid det rätta svaret? Hybrid-modellen är ofta starkare än antingen-eller. En chatbot ligger framme för enkla FAQ-ärenden, och en AI-agent tar över när ärendet kräver handling eller kombinerar information från flera system. Det här mönstret blir allt vanligare 2026 eftersom det löser volym billigt och komplexitet pålitligt, i stället för att tvinga en enda teknik att göra allt. Konkret arkitektur: - **Chatbot tier-1:** Hanterar 60-80 % av inkommande ärenden direkt. Leverans-frågor, öppettider, returer, fakturor - **AI-agent tier-2:** Tar över när chatten innehåller nyckelord som "boka", "ändra min order", "kombinera leveranser", eller när kunden ber om något som kräver CRM-uppdatering - **Människa tier-3:** Eskalering för komplexa klagomål, krisartade situationer, eller förhandlingar Det här är samma logik som "agent supervisor"-arkitektur som beskrivs av Anthropic och IBM. En orkestrator som dirigerar ärenden till rätt nivå. Skillnaden mot bara-chatbot är att tier-2 inte bara svarar utan agerar. Skillnaden mot bara-agent är att du inte behöver bygga 100 % autonomi från dag ett. Att tier-1 och tier-2 tillsammans tar runt 80 procent av volymen är inte en siffra vi hittat på. Gartners prognos att autonom AI löser 80 procent av vanliga kundtjänstärenden till 2029 pekar åt samma håll, och stämmer med vad vi mäter i hybriduppställningar: de flesta inkommande ärenden är repetitiva nog att lösas utan en människa, och bara en mindre svans kräver tier-3. Hybrid är ofta också billigare totalt. Chatbots löser volym billigt, agenter löser komplexitet. Att försöka få en agent att hantera ALLT (även banala FAQ) blir både dyrare och mindre tillförlitligt än att låta en regelbaserad chatbot ta de enkla ärenden den kan. En annan praktisk fördel med hybrid: du kan rulla ut chatbot på dag 7 och börja samla driftdata medan agenten byggs i parallell. När agenten är live i vecka 5 har du redan 4 veckors data om vilka ärenden chatboten klarar och vilka som faktiskt behöver agentens autonomi. Det gör skalningen mer datadriven. ## Vad rekommenderar Eteya baserat på sina implementationer? Här är vår rekommendationsmatris baserad på våra implementationer hos svenska företag. Den är inte vetenskaplig utan empirisk, byggd på vad som faktiskt fungerat hos kunder i olika storlek och bransch. Utgå från din ärendevolym och hur många system varje ärende rör, så pekar matrisen oftast rätt: ### Matrisen efter volym och integrationer **Du har under 50 FAQ-ärenden per dag, inga integrationer behövs:** Chatbot. Implementationskostnad 5 000–15 000 kr, drift 1 000–3 000 kr/månad. ROI på sparad tid inom 6–9 månader. Du börjar enkelt och kan uppgradera senare. **Du har 50–150 ärenden per dag, en eller två integrationer (CRM eller kalender):** AI-agent för en process. Det här är "sweet spot" för svenska mindre företag. Implementation från 45 000 kr, drift 5 000 kr/månad, ingen bindningstid. ROI inom 2–6 månader genom kombination av sparad tid och nya intäkter. **Du har över 150 ärenden per dag, flera system, säsongstoppar:** AI-agent för flera processer eller hybrid. Här tjänar man mest på automation. Implementation från 180 000 kr, drift 15 000 kr/månad. ROI inom 3–6 månader. Det här är ofta restauranger, bokningstjänster och e-handel över 50 MSEK. **Du behöver båda men är osäker:** Hybrid med pilot. Vi börjar med en agent på en specifik process (typ telefon-beställningar), kopplar in en enkel chatbot för FAQ, mäter pilot-data i 4-6 veckor, och skalar baserat på vad data säger. Enligt en [Google Cloud-studie med 3 466 företagsledare i 24 länder](https://www.googlecloudpresscorner.com/2025-09-04-Google-Cloud-Study-Reveals-52-of-Executives-Say-Their-Organizations-Have-Deployed-AI-Agents,-Unlocking-a-New-Wave-of-Business-Value,1) når 88 procent av de tidiga agent-införarna positiv avkastning på minst ett användningsfall. Vi ser samma mönster i våra svenska case när tre saker stämmer: tydligt avgränsad process, baseline mätt innan go-live, och 2-3 månaders inkubationsperiod efter rollout. ### Tre fallgropar som får projekt att fastna Tre anti-pattern vi sett misslyckas: 1. **"Vi vill automatisera ALLT"**. För bred scope. Välj EN process först, mät, expandera 2. **Ingen baseline mätt**. Kunden vet inte vad de sparat efter sex månader. Mät volym, kostnad, kundnöjdhet INNAN go-live 3. **Ingen som äger guardrails**. Agenten lämnas på autopilot. Någon måste granska eskalerade ärenden veckovis under första kvartalet Vad som har hänt med våra första klienter efter 12 månader är intressant. De som började med chatbot uppgraderar nu till agent när FAQ-volymen ökat. De som började med agent expanderar till multi-process. Ingen har gått tillbaka från agent till chatbot. Det säger något om hur tekniken mognat under 2025-2026: när du väl har en fungerande agent vill du inte tappa autonomin. ## Vanliga frågor --- ### Vad kostar AI-agenter för svenska företag 2026? **URL:** https://eteya.ai/sv/blogg/ai-agenter/ai-agent-kostnad-sverige **Sammanfattning:** En AI-agent kostar hundralappar per månad om du bygger själv, cirka 10 kr per löst ärende som färdigt verktyg och från 45 000 kr konsultbyggd. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' De flesta prisguider om AI-agenter klumpar ihop tre helt olika köp i ett enda spann. Det gör siffrorna oanvändbara. Den här guiden delar upp kostnaden i de tre vägar som faktiskt finns: bygga själv, köpa ett färdigt verktyg eller anlita någon som bygger åt dig. Varje siffra nedan är antingen hämtad från leverantörernas officiella prissidor, från verklig svensk avtalsdata, eller från våra egna fakturor. Inga uppskattningar utan källa. Det viktigaste att veta innan vi börjar: själva AI:n har blivit nästan gratis. Det du betalar för 2026 är arbetet runt den. ## Vad kostar en AI-agent egentligen? En AI-agent kostar olika beroende på vilken av tre vägar du väljer: bygger du själv betalar du hundralappar per månad i AI-kostnad men mycket egen tid. Ett färdigt verktyg kostar cirka 10 kr per löst ärende. En konsultbyggd agent kostar från 45 000 kr i implementation plus 5 000 till 15 000 kr per månad. Så här ser de tre vägarna ut bredvid varandra: | Väg | Engångskostnad | Löpande per månad | Passar dig som | |---|---|---|---| | Bygga själv | 0 kr (din arbetstid) | 20–400 kr i AI-kostnad | har teknisk kompetens internt och en enkel, avgränsad process | | Färdigt verktyg | 0 kr i startkostnad | från ca 500 kr, ca 10 kr per löst ärende | har standardiserad kundtjänst på en befintlig helpdesk | | Konsultbyggt | från 45 000 kr | 5 000–15 000 kr | vill ha en agent anpassad till era system och processer, utan eget tekniskt ansvar | Resten av guiden går igenom varje rad i tabellen, vad som driver priset upp eller ner, och vad två riktiga svenska implementationer faktiskt kostade och gav tillbaka. ## Vad kostar det att bygga en AI-agent själv? Själva AI-användningen är försumbar: 20–400 kr per månad räcker för 500–5 000 ärenden enligt modelleverantörernas officiella prislistor. Den verkliga kostnaden när du bygger själv är din egen arbetstid, plus ansvaret för drift och underhåll som aldrig tar slut. Siffrorna går att räkna ut exakt. [Anthropics officiella prissida](https://platform.claude.com/docs/en/about-claude/pricing) anger 1 USD per miljon input-tokens för den effektiva Haiku-modellen, och deras eget räkneexempel visar att 10 000 hanterade supportärenden kostar ungefär 37 USD totalt, alltså runt 4 öre per ärende. [OpenAI:s prislista](https://developers.openai.com/api/docs/pricing) ligger i samma härad för motsvarande modellklass. Även om en agent med verktygsanrop och dokumentsökning drar fem till tio gånger fler tokens per ärende landar AI-kostnaden i hundralappar, inte tusenlappar. Det betyder att om någon offererar "AI-kostnader" på flera tusen kronor i månaden för låg volym, så betalar du i själva verket för något annat: plattform, arbete eller marginal. Det kan vara helt rimligt, men det ska kallas vad det är. Vad behöver du då faktiskt bygga? Fyra delar: 1. Ett konto hos en modelleverantör med EU-databehandling 2. En systemprompt som beskriver agentens uppgift och gränser 3. Kopplingar till de system agenten ska läsa och skriva i 4. Loggning, så att du kan se vad agenten gjorde och varför Det första fungerande utkastet tar en kunnig utvecklare en till två dagar. Det som tar veckor är resten: felhantering, kantfall, och att agenten beter sig rätt även när kunden skriver något oväntat. Så när är det rätt att bygga själv? När tre saker är sanna samtidigt: - Ni har en person som kan programmera och vill äga lösningen - Processen är enkel, med högst en integration - Ni accepterar att personen ansvarar för övervakning, felhantering och uppdateringar så länge agenten lever Saknas någon av de tre brukar totalkostnaden i arbetstid snabbt passera vad de andra två vägarna kostar. Vi går igenom hela avvägningen i [bygga en AI-agent själv eller anlita en konsult](/sv/blogg/ai-agenter/bygga-ai-agent-sjalv-vs-anlita). ## Vad kostar färdiga AI-agentverktyg? Färdiga verktyg har bytt till resultatprissättning: du betalar per ärende som AI:n faktiskt löser. Intercoms Fin kostar 0,99 USD per löst ärende, cirka 10 kr, med ett minimum på 50 ärenden per månad. Ingångskostnaden är alltså runt 500 kr per månad, utan startavgifter. Så här ser de två största alternativen ut enligt deras egna prissidor: ### Intercom Fin Tar [0,99 USD per "outcome"](https://fin.ai/pricing) och debiterar bara när agenten löser ärendet helt eller utför en definierad procedur. Inga integrations-, setup- eller plattformsavgifter när den körs ovanpå er befintliga helpdesk som Zendesk eller Salesforce. Vid 500 lösta ärenden i månaden blir det ungefär 5 000 kr, vid 2 500 ärenden cirka 25 000 kr. ### Zendesk AI agents Ingår i alla [Suite-planer](https://www.zendesk.com/pricing/) (från 55 USD per agentlicens och månad) och debiterar därutöver per "automated resolution", alltså ärenden som AI:n löser utan att en människa kopplas in. Planerna inkluderar bara en handfull lösta ärenden per licens och månad enligt Zendesks egen dokumentation: fem på Team-planen, tio på Growth och Professional, femton på Enterprise. Verklig volym kräver alltså alltid tillköp. En sak att granska innan du skriver på: hur leverantören definierar "löst ärende". Hos Intercom kan ett ärende räknas som löst även när kunden bara slutar svara, inte enbart när kunden bekräftar att problemet är ur världen. Det är inte fusk, men det betyder att din faktura kan inkludera ärenden där kunden gav upp. Be alltid om definitionen skriftligt och stäm av den mot er egen statistik första månaden. Verktygsvägen passar bäst när er kundtjänst är standardiserad och redan bor i en stor helpdesk-plattform. Begränsningen är anpassning: ska agenten prata med ert affärssystem, ert lager eller er bokningskalender är ni utanför vad verktygen klarar som standard. Och enterprise-alternativen i kategorin, som Decagon, börjar på motsvarande en halv miljon kronor per år och är byggda för en helt annan storlek av organisation. ## Vad kostar en konsultbyggd AI-agent? En konsultbyggd AI-agent kostar från 45 000 kr i implementation för ett avgränsat system, och växer med omfattningen. Löpande kostar drift 5 000 kr per månad för ren övervakning, upp till 15 000 kr för avancerade system med vidareutveckling varje månad. Ingen bindningstid. Vill du inte ha avtal är driften nära noll. Det här är vägen vi själva säljer, så siffrorna ovan är våra egna. För att du ska kunna jämföra dem mot marknaden: svenska konsulttimmar kostar enligt verklig avtalsdata 824–906 kr per timme för utvecklarroller på [Brainvilles marknadsplats](https://www.brainville.com/Statistics/Rates), och [Keymans prisbarometer](https://www.keyman.se/sv/prisbarometern/) över 24 000 förseglade avtal visar snitt från 845 kr upp till 1 535 kr per timme för seniora roller. En implementation är i grunden timmar gånger timpris, så ett bygge på 45 000–180 000 kr motsvarar någonstans mellan en knapp veckas och en dryg månads konsultarbete. Så här fördelar sig nivåerna i praktiken: | Nivå | Implementation | Drift per månad | Exempel | |---|---|---|---| | Avgränsat system | 45 000–90 000 kr | 0 kr (utan avtal) eller 5 000 kr | en process, en integration, t.ex. automatisk fakturahantering | | Verksamhetssystem | 90 000–180 000 kr | 9 500 kr | kundtjänst tier-1 eller bokningar, två till tre integrationer | | Produktionssystem | från 180 000 kr | 15 000 kr | telefoni, många system, löpande vidareutveckling | Två saker skiljer vägen från de andra. Den första: agenten byggs runt era system och er process, inte tvärtom. Den andra: underhållsavtalet är valbart. En kund som bara vill ha en sak byggd och sedan klara sig själv betalar i princip bara AI-förbrukningen efteråt, alltså hundralappar. ## Vilka faktorer styr priset? Fyra variabler styr nästan hela prislappen, oavsett väg: ärendevolym, antal system agenten ska prata med, hur komplex varje konversation är och vilka compliance-krav som gäller. Tumregeln är att du betalar för komplexitet, inte för intelligens. - **Volym.** Fler ärenden ger lägre kostnad per ärende eftersom grundarbetet är detsamma. För verktygsvägen är sambandet omvänt: där betalar du per löst ärende, så hög volym höjer månadsfakturan linjärt. - **Antal integrationer.** Varje system som agenten ska läsa eller skriva i (CRM, ERP, kalender, telefoni, kassasystem) är arbete vid implementation och en punkt som ska underhållas. En agent som rör ett system är ett litet bygge. En som rör fem är ett projekt. - **Konversationskomplexitet.** Att svara på "har ni öppet?" kostar bråkdelar av ett öre. Att kvalificera ett B2B-lead med tolv frågor, slå upp i CRM och boka möte drar tusentals tokens och flera verktygsanrop per ärende. Det handlar fortfarande om kronor per ärende, inte hundralappar. - **Compliance.** GDPR och [EU AI Act](https://artificialintelligenceact.eu/implementation-timeline/) kräver EU-databehandling, biträdesavtal och loggning. [Integritetsskyddsmyndigheten](https://www.imy.se/) är svensk tillsynsmyndighet för GDPR-tillämpningen. Kraven går att uppfylla med alla stora modelleverantörer men begränsar billiga genvägar. - **Ägande.** Den femte faktorn som sällan står i offerten: ett färdigt verktyg hyr du, och slutar du betala försvinner agenten. En konsultbyggd agent äger du, och kan byta leverantör eller ta över driften själv. Egenbygget äger du helt, inklusive allt ansvar. Ägandefrågan avgör hur inlåst du är den dag priserna eller behoven ändras. ## Hur räknar man kostnad per ärende? Dela totalkostnaden per månad med antalet hanterade ärenden, och jämför mot vad samma ärende kostar manuellt. En administrativ handläggare som hanterar 12–15 ärenden i timmen kostar 17–21 kr per ärende vid 250 kr i timkostnad, baserat på [SCB:s lönestatistik](https://www.scb.se/) inklusive sociala avgifter. Det enklaste sättet att se vad det betyder är ett konkret scenario. Säg att din kundtjänst hanterar 500 ärenden i månaden: | Väg | Månadskostnad vid 500 ärenden | Att tänka på | |---|---|---| | Manuellt | 8 500–10 500 kr i arbetstid | personalen frigörs till annat arbete | | Bygga själv | 20–100 kr i AI-kostnad | plus 2–4 timmar egen övervakning per månad | | Färdigt verktyg | ca 5 000 kr (vid lösta ärenden à 10 kr) | 0 kr i startkostnad, men löser bara standardärenden | | Konsultbyggt | 9 500 kr i drift | engångskostnad från ca 90 000 kr först | En traditionell chatbot ser billig ut per interaktion men eskalerar de flesta ärenden till en människa, så den effektiva kostnaden per löst ärende blir ofta högre än AI-agentens. Lägg märke till hur olika strukturerna är. Verktyget är dyrast per månad men kräver inget startkapital. Konsultbygget kostar mest första dagen men minst över tid. Egenbygget är billigast i kronor och dyrast i egen tid. ROI-formeln vi använder med klienter ser ut så här: ``` Årlig besparing = (timmar/vecka sparat × 50 × timpris) + (extra intäkter från ökad kapacitet) - (drift × 12) - implementation (år 1) Återbetalningstid = implementation / (månatlig nettonytta) ``` För en agent som sparar 10 timmar i veckan åt en person som kostar 350 kr i timmen, med drift på 5 000 kr i månaden, blir räkningen: 10 × 50 × 350 = 175 000 kr per år i tidsvärde, minus 60 000 kr i drift = 115 000 kr per år i nettonytta. En implementation på 45 000 kr betalar sig då på under fem månader. ## Vad kostade det på riktigt hos svenska företag? Två implementationer där vi kan visa hela kalkylen: Sannegårdens Pizzeria betalade 52 000 kr i implementation och 3 500 kr per månad i drift, och sparar runt 315 000 kr per år. NordicRank betalade 65 000 kr plus 4 500 kr per månad och sparar 13,4 timmar i veckan. ### Sannegårdens Pizzeria, Karlskoga En AI-agent som räknar kostnad per pizza i realtid och föreslår påfyllningsbeställningar mot leverantörsfakturor. Innan systemet räknade VD Kerem Çelik marginal för hand och söndagens beställning sattes på magkänsla, vilket gjorde att runt 10 procent av råvarorna gick i sopor varje vecka. Resultatet: 32 procent mindre matsvinn, 9 kr i höjd marginal per pizza efter omprissättning, och cirka 6 sparade timmar per vecka. Nettoeffekt runt 315 000 kr per år, med återbetalning på under tre månader. ### NordicRank, sökoptimering 18 automatiserade processer: rapportgenerering, klient-onboarding, leverantörsuppföljning och fakturahantering. Värdet är 13,4 sparade timmar per vecka, vilket räknat mot lönekostnad är cirka 380 000 kr per år, med återbetalning på fyra månader. Mönstret känns igen i en [Forrester-studie publicerad av Google Cloud](https://cloud.google.com/transform/the-roi-of-gen-ai-leaders-share-their-success-metrics) där 88 procent av implementationerna når positiv ROI. Ett ärligt förbehåll: båda byggdes 2025, innan den senaste generationens billigare AI-modeller. Implementationsarbetet kostar ungefär detsamma idag, men driftdelen av motsvarande bygge ligger lägre nu. Priserna i den här guiden rör sig åt ett håll, och det är nedåt. ## Vad kostar det att vänta? Att skjuta upp beslutet har också en prislapp: det manuella arbetet fortsätter kosta fullt pris varje månad medan du väntar. En process som binder 10 timmar i veckan kostar cirka 175 000 kr om året i arbetstid, och den kostnaden försvinner inte för att AI-priserna sjunker. Det vanligaste argumentet för att vänta är att tekniken blir billigare och bättre. Det stämmer, men det är driftdelen som sjunker, alltså den minsta delen av kalkylen. Implementationsarbetet (förstå processen, koppla systemen, testa kantfall) kostar ungefär lika mycket oavsett modellgeneration. Den som väntar ett år på en agent som sparar 139 000 kr per år har betalat ungefär den summan för väntan, och får sedan göra samma implementationsarbete ändå. Det betyder inte att allt ska automatiseras nu. Det betyder att kalkylen ska göras nu, så att beslutet att vänta är ett beslut och inte en slump. Ett praktiskt mellanläge är att börja med ett avgränsat system: en enda process, från 45 000 kr, som testar kalkylen på riktigt innan ni skalar till fler processer. För hela bilden av hur AI-agenter fungerar och vilka processer de passar för finns [vår fördjupande guide till AI-agenter för svenska SMB](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). ## Vanliga frågor om pris --- ### Vad är en AI-agent? Komplett guide 2026 **URL:** https://eteya.ai/sv/blogg/ai-agenter/vad-ar-en-ai-agent **Sammanfattning:** AI-agent: ett mjukvarusystem som planerar, fattar beslut och agerar autonomt mot ett mål. Tre egenskaper definierar dem, fyra steg styr körningen. Här är allt. import CaseLink from '@/components/blog/CaseLink' import FAQ from '@/components/blog/FAQ' Kort sagt: en AI-agent är ett mjukvarusystem som tar emot ett mål, planerar hur det ska nås, använder verktyg för att hämta information och utföra handlingar, och levererar resultat utan att en människa styr varje steg. Det skiljer en AI-agent från en chatbot, en språkmodell eller en automation som följer ett förutbestämt manus. Den här guiden förklarar vad en AI-agent är, hur den fungerar i praktiken, hur den skiljer sig från andra AI-verktyg, när den passar och inte, och hur du kommer igång. Innehållet är skrivet för svenska företagsledare som vill förstå tekniken på 10 minuter. ## Vad är en AI-agent egentligen? En AI-agent är ett mjukvarusystem som **uppfattar, resonerar, agerar och följer upp** autonomt mot ett mål du har gett den. Den kombinerar en språkmodell med verktygsanvändning (tool-use) så den kan boka möten, hämta data och uppdatera system själv. ### De tre definierande egenskaperna Tre egenskaper definierar en riktig AI-agent: - **Autonomi.** Agenten fattar beslut utan mänsklig instruktion för varje steg. - **Verktygsanvändning.** Agenten kan interagera med externa system: kalender, CRM, databas, mejl, telefoni. För att svara utifrån era egna dokument används ofta [RAG](/sv/blogg/ai-agenter/vad-ar-rag-retrieval-augmented-generation). - **Iterativt resonemang.** Om något går fel mitt i en uppgift kan agenten revidera planen och försöka igen. Saknas någon av dessa är det troligen en chatbot, ett RPA-flöde eller bara en språkmodell utan exekverande förmåga. Enligt [Anthropics forskning om effektiva agenter](https://www.anthropic.com/research/building-effective-agents) är skillnaden mellan en "workflow" (förutbestämd kedja) och en "agent" (autonomt resonerande) kritisk för att förstå vad tekniken faktiskt klarar. Samma tre egenskaper går igen i [IBM:s definition av AI-agenter](https://www.ibm.com/think/topics/ai-agents): ett system som självständigt resonerar, planerar sin egen arbetsgång och kallar på externa verktyg utan att en människa godkänner varje steg. Två oberoende auktoriteter, samma kärna. ## Hur fungerar en AI-agent i praktiken? En AI-agent följer fyra steg som upprepas tills uppgiften är löst: **intag, klassificering, verktygsanvändning och respons**. Mönstret är detsamma oavsett om agenten tar emot ett samtal, ett mejl eller ett formulär. Bara verktygen och beslutsreglerna varierar. ### De fyra stegen i praktiken Konkret exempel från Sannegårdens Pizzeria i Karlskoga, där en AI-agent sköter inventering och kostnadsräkning autonomt: 1. **Intag.** En leverantörsfaktura landar i mejlen, eller köket registrerar nya kvällsförsäljningar i kassan. 2. **Klassificering.** Agenten avgör om det är en prisuppdatering på en råvara, en ny menypost eller ett förbrukningsdataset som ska analyseras. 3. **Verktygsanvändning.** Agenten matchar fakturaraderna mot receptdatabasen, räknar om kostnad per pizza, jämför mot menypriset, flaggar olönsamma poster i rött och bygger ett påfyllningsförslag från senaste fyra veckornas förbrukning. 4. **Respons.** Söndag eftermiddag landar ett färdigt förslag i mobilen. VD Kerem Çelik godkänner med ett tryck, och systemet skickar beställningen vidare. Svinnlarm per ingrediens går separat om något ligger högt. Samma logik bakom alla AI-agent-implementationer. På en e-handelssajt hämtar agenten data från lager-API:et istället för leverantörsfakturor. En AI-säljkvalificerare kollar prospekt mot CRM istället för recept mot kassasystem. Det som har förändrats 2026 är att modellerna nu klarar dessa flöden pålitligt i produktion. Tidigare kraschade de på kantfall. Dagens modellgeneration klarar flerstegsflöden med verktygsanrop stabilt nog för skarp drift. ## Vad är skillnaden mellan AI-agent och chatbot? En chatbot svarar på frågor med fördefinierade svar eller mallar och agerar inte i externa system. En AI-agent kombinerar resonemang med verktygsanvändning och utför hela ärenden själv. Det är skillnaden mellan att svara och att agera. | | Chatbot | AI-agent | |---|---|---| | Svarar på frågor | Ja | Ja | | Använder externa system | Nej | Ja | | Fattar beslut autonomt | Nej (regelbaserat) | Ja (resonerande) | | Reviderar plan vid fel | Nej | Ja | | Hanterar hela ärenden | Sällan | Standard | [Salesforce har en bra grundläggande genomgång av AI-agent kontra chatbot](https://www.salesforce.com/se/agentforce/ai-agent-vs-chatbot/) för svenska företag. Tabellen ovan visar grundskillnaden i fem dimensioner. För en djupare jämförelse med konkreta beslutsfaktorer för små och medelstora företag, läs vår dedikerade [jämförelse av AI-agent vs chatbot](/sv/blogg/ai-agenter/ai-agent-vs-chatbot). Gränsen mot RPA (Robotic Process Automation) ser ofta tydlig ut på papper men avgörs i praktiken. Fakturahanteringen hos Sannegården är ett bra exempel. Att läsa in en faktura och uppdatera ett pris låter som ett klassiskt RPA-jobb, alltså ett inspelat klickflöde. Problemet är att leverantörsfakturor ser olika ut, en ny menypost dyker upp, en råvara byter namn. Ett inspelat makro stannar vid första avvikelsen. Det här blev en agent just för att den behövde tolka rader den aldrig sett förut och matcha dem mot rätt recept själv. Tumregeln vi landat i: är inputens form stabil räcker RPA, varierar den behövs en agent som kan resonera. ## När passar en AI-agent inte? En AI-agent passar **inte** när uppgiften kräver mänskligt omdöme, när reglerna är otydliga, eller när konsekvensen av fel är för stor för automatisering. Tumregeln är: om uppgiften kan beskrivas i ett tydligt flödesschema passar den. Annars inte. ### Tre lägen att undvika Tre situationer där AI-agent inte är rätt val: - **Komplexa klagomål eller arga kunder.** Eskalera till människa direkt. Agenten ska identifiera tonläge och koppla över utan att försöka lösa. - **Krisartade situationer.** Matförgiftning, säkerhetsfrågor, akuta ärenden. Agenten ska känna igen nyckelord och alltid skicka till människa. - **Förhandlingar och undantag.** Rabattering, specialarrangemang, avvikelser från policy. Mänskligt arbete. Strategiska beslut ska heller aldrig delegeras. Ingen AI bör bestämma riktning för affären – det är ledningens ansvar. ## Hur kommer ditt företag igång? Att komma igång med en första AI-agent tar **2–6 veckor** från första möte till live i drift, om processen är tydlig från början. Vecka 1 går till discovery, vecka 2–3 till design och utveckling, vecka 4 till pilot på 10–20 procent av volymen, och vecka 5–6 till full utrullning. Siffrorna pekar åt rätt håll. I en [studie från Google Cloud](https://www.googlecloudpresscorner.com/2025-09-04-Google-Cloud-Study-Reveals-52-of-Executives-Say-Their-Organizations-Have-Deployed-AI-Agents,-Unlocking-a-New-Wave-of-Business-Value,1) med 3 466 företagsledare i 24 länder uppger 88 procent av de tidiga agent-införarna att de ser positiv avkastning på minst ett användningsfall, mot 74 procent bland alla organisationer. Vad det faktiskt landar på i kronor beror på er volym och ert manuella alternativ. Vi har räknat igenom hela kalkylen i [vad en AI-agent kostar i Sverige](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). ### Det viktigaste innan start Det viktigaste innan du börjar: - Identifiera EN process med tydlig volym och tydliga regler. Börja inte brett. - Mät baslinjen INNAN agenten går live, annars vet du inte vad du sparat. - Räkna med 2–3 månaders påverkan innan ni märker full effekt. Agenter blir bättre med tid. - Välj en leverantör som visar siffror, inte bara koncept. För en fullständig guide om hur AI-agenter passar mindre företag (med konkreta användningsfall, kostnader och implementationsvägar) läs vår [fördjupande pillar-artikel om AI-agenter](/sv/blogg/ai-agenter/ai-agenter-svenska-smb). Regelverket EU AI Act rullas ut i [faser med flera deadlines](https://artificialintelligenceact.eu/implementation-timeline/): förbudet mot vissa AI-praktiker (Artikel 5) och kravet på AI-kunskap hos personalen gäller redan sedan 2 februari 2025, medan hög-risk-bestämmelserna genom Digital Omnibus-förordningen (i kraft sedan 27 juli 2026) fått flyttad deadline till 2 december 2027; transparenskraven gäller sedan 2 augusti 2026. Vad det betyder för dig som planerar AI-agent reder vi ut i [vår guide till EU AI Act för svenska företag](/sv/blogg/eu-ai-act/eu-ai-act-svenska-foretag). ## Vanliga frågor --- ### AI-agenter för svenska SMB: så fungerar de i praktiken **URL:** https://eteya.ai/sv/blogg/ai-agenter/ai-agenter-svenska-smb **Sammanfattning:** AI-agenter går från hype till produktion 2026. Praktisk guide för svenska SMB: vad de är, hur de fungerar, vad de kostar, ROI, och hur du implementerar. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' En AI-agent är ett autonomt mjukvarusystem som tar emot uppgifter, fattar beslut, använder verktyg och levererar resultat utan att en människa behöver styra varje steg. För svenska SMB är detta första gången tekniken faktiskt sparar tid i produktion, inte bara på demo-möten. Den här guiden förklarar vad AI-agenter är, hur de fungerar i praktiken, vilka processer som passar dem, vad de kostar och hur du kommer igång. Verifierat hos svenska företag mellan 10 och 200 anställda. ## Vad är en AI-agent? En AI-agent är ett mjukvarusystem som kan **uppfatta**, **resonera**, **agera** och **följa upp** autonomt mot ett mål du gett den. Det skiljer den från både chattbotar och rena språkmodeller, som saknar förmågan att själva utföra arbete i andra system. **En chatbot** svarar på frågor med fördefinierade svar eller mallar. Den agerar inte i andra system. **En LLM (språkmodell)** som ChatGPT eller Claude kan generera text och resonemang, men gör inget på egen hand utan en människa som promptar. **En AI-agent** kombinerar en LLM med **verktygsanvändning** (tool-use), tekniskt möjliggjort av [Model Context Protocol (MCP)](/sv/blogg/ai-agenter/vad-ar-mcp-model-context-protocol). Det innebär att agenten kan boka möten i din kalender, hämta data från ditt CRM, skicka mejl, uppdatera databaser och eskalera ärenden till människor. Den orkestrerar uppgifter över flera system. Tre egenskaper definierar en riktig AI-agent: - **Autonomi:** den fattar beslut utan mänsklig styrning för varje steg - **Verktygsanvändning:** den kan interagera med externa system, inte bara prata - **Iterativt resonemang:** den kan revidera sin plan om något går fel mitt i ett ärende Om något av dessa saknas är det troligen en chatbot eller ett RPA-flöde, inte en AI-agent. [Anthropics forskning kring effektiva agenter](https://www.anthropic.com/research/building-effective-agents) skiljer specifikt mellan en "workflow" (förutbestämd kedja) och en "agent" (autonomt resonerande system). Den distinktionen är avgörande för att förstå vad tekniken faktiskt klarar. ## Hur fungerar AI-agenter i praktiken? En AI-agent fungerar enligt fyra steg som upprepas tills uppgiften är löst: intag, klassificering, verktygsanvändning och respons. Agenten tar emot något som händer, avgör vad det är, utför arbetet i de system den är kopplad till och levererar ett resultat eller eskalerar till en människa. Det enklaste sättet att förstå det är via ett konkret exempel. På Sannegårdens Pizzeria i Karlskoga räknade VD Kerem Çelik marginalen på varje pizza för hand i Excel, ibland efter stängning kl 23. Söndagens inköpsbeställning sattes på magkänsla. Resultatet: runt 10 procent av råvarorna åkte i sopor varje vecka, och flera populära menyposter visade sig vara olönsamma när siffrorna till slut stämdes av. Idag kör de en AI-agent som löpande räknar kostnad per pizza mot kassan och leverantörsfakturorna. Så här går det till: 1. **Intag.** En ny faktura kommer in via mejl eller leverantörsportal, alternativt en menypost skapas i kassasystemet. 2. **Klassificering.** Agenten avgör vad inputen är: kostnadsuppdatering på en råvara, ny menypost, eller veckans förbrukningsdata. 3. **Verktygsanvändning.** Agenten matchar mot receptdatabasen, räknar om kostnad per pizza, jämför med menypris, flaggar olönsamma poster i rött, och sammanställer ett påfyllningsförslag baserat på de senaste fyra veckornas förbrukning. 4. **Respons.** Söndag 17.00 får Kerem ett färdigt påfyllningsförslag i mobilen. Ett tryck för godkänd beställning, ingredienser med oväntat svinn flaggas separat. Det är samma logik bakom alla våra AI-agent-implementationer. Det är bara verktygen och beslutsreglerna som varierar. En [AI-agent på en e-handelssajt](/sv/blogg/ai-agenter/ai-agent-for-e-handel) hämtar data från lagrets API i stället för leverantörsfakturor. En AI-säljkvalificerare kollar prospekt mot CRM i stället för recept mot kassasystem. Mönstret är identiskt. **Det som har förändrats 2026** är att modellerna nu klarar de här flödena pålitligt i produktion. Tidigare kraschade de på kantfall och krävde konstant övervakning. Dagens modellgeneration hanterar flerstegsflöden med verktygsanrop stabilt nog för skarp drift utan ständig barnvakt. Den utvecklingen följs i [Stanford AI Index Report](https://aiindex.stanford.edu/report/), som dokumenterar hur verktygsanvändning och flerstegsresonemang gått från forskningsprototyp till produktionsmognad. ## Vilka processer passar AI-agenter? AI-agenter passar bäst för **strukturerade, repetitiva ärenden där reglerna är tydliga**, oavsett om de kommer in via telefon, mejl, formulär eller chatt. Ju högre volym och ju tydligare regler, desto snabbare betalar sig agenten i praktiken. De fyra mest värdefulla användningsområdena vi ser hos svenska SMB: **Kundtjänst tier-1.** Frågor om leverans, retur, lager, öppettider och fakturor. I våra implementationer faller cirka 70–80 procent av all inkommande kundkontakt på en typisk e-handel eller restaurang i den här kategorin. AI-agenten löser dem helt utan människa och eskalerar resten. **Order- och bokningshantering.** Beställningar med standardalternativ, bokningar (datum, tid, antal), prenumerationsändringar. Volymtunga ärenden där felfrekvensen måste vara nära noll. För e-handel går vi igenom hela flödet i guiden om att [automatisera orderhanteringen](/sv/blogg/ai-automation/automatisera-orderhantering-e-handel-ai). Nästa steg när ordern är i hamn är att pengarna faktiskt stäms av mot den, vilket [guiden om att automatisera avstämning i e-handeln](/sv/blogg/ai-automation/automatisera-avstamning-e-handel-ai) beskriver steg för steg. **Säljkvalificering.** När webbformulär eller kalla samtal kommer in kvalificerar agenten via specifika frågor mot CRM, klassificerar leadkvalitet och bokar möte direkt med rätt säljare. Det sparar säljarens tid till varma leads. **Intern operations.** Fakturahantering, leverantörsuppföljning, rapportgenerering, onboarding av nya anställda. Processer som idag äter timmar varje vecka. Hos NordicRank, en svensk SEO-byrå, automatiserade vi 18 sådana processer: månadsrapporter som tidigare byggdes för hand genereras nu automatiskt, nya klienter får onboarding-material och systemuppsättning utan manuella steg, och fakturaunderlag sammanställs direkt från projektdata. Samma princip går att lyfta till den ekonomiska rapporteringen, där vi går igenom hur du kan [automatisera kvartalsrapporten](/sv/blogg/ai-automation/automatisera-kvartalsrapport) i stället för att bygga ihop den för hand. En praktisk tumregel för urvalet: räkna ärenden per vecka och minuter per ärende. En process som tar 100 ärenden i veckan à 5 minuter binder runt 36 timmar i månaden. Det är där kalkylen blir intressant, långt före de spektakulära användningsfallen. ### När du INTE ska använda AI-agent - Komplexa klagomål där kunden är arg eller har en specifik situation. Eskalera till människa direkt. - Krisartade situationer (matförgiftning, allergisk reaktion på beställd mat, säkerhetsfrågor). Agenten ska identifiera nyckelord och koppla över. - Förhandlingar. Rabattering, specialarrangemang och undantag från policy är fortfarande mänskligt arbete. - Strategiska beslut. Ingen AI ska bestämma riktning för affären. Tumregeln: **om en uppgift kan beskrivas i ett tydligt flödesschema, passar AI-agent. Om den kräver omdöme på riktigt, passar den inte.** Vi reder ut gränsdragningen mer ingående i [vår jämförelse av AI-agent vs chatbot](/sv/blogg/ai-agenter/ai-agent-vs-chatbot). [Salesforce har en bra grundläggande genomgång av AI-agent kontra chatbot](https://www.salesforce.com/se/agentforce/ai-agent-vs-chatbot/) som komplement till denna lista. De täcker samma logik från ett CRM-perspektiv. Retur är ett bra exempel på just den gränsen i praktiken: två nästan identiska returmejl kan kräva olika svar beroende på köpkanal och regelverk. Vi går igenom hela kontrollflödet, inklusive var AI:n måste fråga eller lämna över, i [guiden om AI-returhantering med human in the loop](/sv/blogg/ai-automation/ai-returhantering-kundtjanst). ## Vad kostar AI-agenter? En konsultbyggd AI-agent kostar från 45 000 kr i implementation för ett avgränsat system, upp till 180 000 kr och mer för produktionssystem. Drift kostar 5 000–15 000 kr per månad beroende på nivå, ingen bindningstid. Själva AI-förbrukningen är försumbar: öre till enstaka kronor per hanterat ärende. Det är ett stort spann, så vi bryter ner det. Konsultbyggt är dessutom bara en av tre vägar: den som har teknisk kompetens internt kan [bygga själv](/sv/blogg/ai-agenter/bygga-ai-agent-sjalv-vs-anlita) för i princip bara AI-kostnaden, och den som har standardiserad kundtjänst i en stor helpdesk kan köpa ett färdigt verktyg som debiterar cirka 10 kr per löst ärende. För en fullständig kostnadsguide med tabeller, räkneexempel och jämförelse mellan alla tre vägarna, se [vad en AI-agent kostar i Sverige](/sv/blogg/ai-agenter/ai-agent-kostnad-sverige). **Driftkostnad per ärende.** Den faktiska AI-kostnaden för ett enskilt ärende mäts i öre, inte kronor. [Anthropics officiella prissida](https://platform.claude.com/docs/en/about-claude/pricing) visar i sitt eget räkneexempel att 10 000 hanterade supportärenden kostar runt 37 USD totalt. Ett komplext flöde med många verktygsanrop, som säljkvalificering med uppslag i CRM och mötesbokning, drar fem till tio gånger mer, men landar fortfarande i enstaka kronor per ärende. **Implementationskostnad.** Engångskostnad för att designa, bygga, integrera och testa agenten. Den beror nästan helt på antalet integrationer mot befintliga system. En agent som använder ett enda API är ett avgränsat system från 45 000 kr. En som integrerar med ERP, CRM, kalender och telefoni är ett projekt en bit över 180 000 kr. **Drift.** Valbart avtal, ingen bindningstid. Ren övervakning kostar 5 000 kr per månad, avancerade system med löpande vidareutveckling upp till 15 000 kr. Utan avtal betalar du i princip bara AI-förbrukningen. ### ROI räknat på riktiga kunder På Sannegården kostade implementationen 52 000 kr. Driftkostnaden är cirka 3 500 kr per månad. Värdet kommer från tre håll: 32 procent mindre matsvinn, 9 kr i höjd marginal per pizza, och 6 timmar i veckan som inte längre går åt till manuell inventering och kostnadsräkning. Nettoeffekten landar på **runt 315 000 kr per år**. Återbetalningstid: under 3 månader. På NordicRank automatiserade vi 18 processer för 65 000 kr. Driftkostnaden är cirka 4 500 kr per månad. Tidsbesparingen blev **13,4 timmar per vecka**, vilket räknat mot deras lönekostnad är runt 380 000 kr per år. ### Det som påverkar priset mest - Volym (fler ärenden ger lägre kostnad per ärende eftersom grundarbetet är detsamma) - Antal integrationer (varje system som ska kopplas in är arbete) - Konversationskomplexitet (enkla beställningar eller komplexa rådgivningssamtal) - Språkstöd (svenska + engelska kostar lite mer, fler språk växer) För en SMB med en specifik flaskhals (typ "vi slänger råvaror för X kr i veckan" eller "manuell fakturering tar Y timmar") är ROI nästan alltid självklar inom 3–6 månader. Enligt en [studie från Google Cloud (Forrester 2024)](https://cloud.google.com/transform/the-roi-of-gen-ai-leaders-share-their-success-metrics) når 88 procent av företag som implementerar AI-agenter positiv ROI, med en genomsnittlig avkastning på 171 procent. Det är siffror som ligger i linje med vad vi ser hos våra svenska implementationer. ## Vilka misstag är vanligast när SMB inför AI-agenter? Det vanligaste misstaget är att automatisera för många processer samtidigt. Därefter kommer att sakna baslinjemätning, att välja process efter teknik i stället för affärsvärde, att hoppa över pilotfasen och att sakna tydlig eskaleringsväg till människa. Alla fem går att undvika med planering. Så här ser de ut i praktiken, och så undviker du dem: - **För bred start.** Tio processer på en gång betyder att ingen blir klar. Välj den process som har högst volym och tydligast regler, och kör den hela vägen till mätbar effekt innan nästa påbörjas. - **Ingen baslinje.** Den som inte mäter hur lång tid processen tar manuellt före driftstart kan aldrig visa vad agenten sparade. Mät minst två veckor innan bygget startar. - **Teknik före affärsvärde.** En agent som imponerar på demo men löser ett problem ingen har kostar lika mycket som en som betalar sig. Börja i flaskhalsen, inte i teknikens möjligheter. - **Hoppad pilot.** Att gå direkt till 100 procent av volymen gör varje kantfall till ett kundproblem. En pilot på 10–20 procent av volymen hittar felen medan de fortfarande är billiga. - **Otydlig eskalering.** En agent utan definierad väg till människa skapar frustrerade kunder i exakt de ärenden som betyder mest. Definiera eskaleringsreglerna före driftstart, inte efter första klagomålet. Mönstret bakom alla fem är detsamma: misstagen handlar om process och styrning, inte om tekniken. Det är också därför de går att undvika utan teknisk kompetens internt. ## Hur kommer ditt företag igång? Att komma igång med en AI-agent tar **2–6 veckor** från första möte till live i drift, om processen är tydlig från början. Här är vägen vi typiskt går med svenska SMB, vecka för vecka från kartläggning till full utrullning. **Vecka 1: Discovery och prioritering.** Vi kartlägger 5–10 kandidater för automation tillsammans. Vad har högst volym? Var är reglerna tydligast? Var smärtar det mest idag? Vi väljer EN process att börja med — inte tio. Att försöka automatisera för mycket samtidigt är som sagt det vanligaste implementationsmisstaget. Det enda du behöver förbereda inför veckan är tre saker: någon som kan beskriva processen i detalj (oftast den som gör jobbet idag, inte chefen), en lista över vilka system processen rör, och baslinjesiffror på hur lång tid den tar manuellt. Med det på plats räcker två arbetsmöten för hela kartläggningen. **Vecka 2–3: Design och utveckling.** Vi specificerar exakt flöde: vad agenten ska kunna, vilka system den ska integrera mot, var den ska eskalera till människa. Bygger agenten i en testmiljö. Kör 50–100 simulerade ärenden för att hitta kantfallen. **Vecka 4: Pilot i skarp drift.** Agenten går live på 10–20 procent av volymen. Resten hanteras fortfarande manuellt. Vi mäter lösningsgrad (hur ofta löste agenten ärendet?), eskaleringsgrad (hur ofta behövde en människa rätta något?) och kundnöjdhet. **Vecka 5–6: Utrullning till 100 procent.** När pilotdata ser bra ut (typiskt över 85 procent lösningsgrad) skalar vi till full volym. Människan tar de eskalerade ärendena. ### Efter driftstart Justeringar och förbättringar. En agent blir inte färdig vid driftstart. Den blir bättre under de första 3 månaderna när vi lärt oss vilka kantfall som faktiskt händer i verkligheten. ### Vad du bör tänka på innan du börjar - Identifiera EN process som har tydlig volym och tydliga regler. Börja inte brett. - Mät baslinjen INNAN agenten går live. Annars vet du inte vad du sparat. - Räkna med 2–3 månaders intrimning innan ni märker full effekt. Agenter blir bättre med tid. - Välj en leverantör som visar siffror, inte bara koncept. Be om data från andra implementationer i din storleksklass. Och tänk på regelverket parallellt: [EU AI Act träder i full kraft den 2 augusti 2026](https://artificialintelligenceact.eu/implementation-timeline/), vilket betyder att svenska företag som planerar AI-agent bör kalibrera sin compliance-strategi nu, inte i sista stund. Vad lagen betyder specifikt för AI-agenter, och var de hamnar i risktrappan, går vi igenom i [AI-agenter och EU AI Act](/sv/blogg/ai-agenter/ai-agenter-eu-ai-act). Ett konkret första steg är att [dokumentera era AI-system enligt EU AI Act](/sv/blogg/eu-ai-act/eu-ai-act-dokumentation-mall) med en färdig mall. Lika viktigt är dataskyddet: innan en agent rör kunddata bör du läsa hur du [håller AI säkert under GDPR](/sv/blogg/ai-agenter/ai-och-gdpr-sakerhet). ## Vanliga frågor --- ## Blog / Insights (English) ### Automate quarterly reports without manual work **URL:** https://eteya.ai/en/blog/ai-automation/automate-quarterly-reports **Sammanfattning:** How to stop building the quarterly report by hand: what the law actually requires, how to automate the compilation, and where the automation has to stop. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' Most people who sit down with the quarterly numbers believe they are doing something the law requires. Usually they are not. An unlisted Swedish limited company has no obligation to produce a quarterly report, and since 2016 not even listed companies have that obligation. Yet thousands of business owners spend three or four weeks a year assembling the same summary by hand. This guide covers what the law actually requires before you automate quarterly reports, what can be automated, and exactly where the automation stops. The order matters. Obligations first, because they decide which dates you are locked into. Then the build. Limits last, because there are things in a Swedish finance process that no machine is allowed to do for you. ## Do Swedish companies have to file a quarterly report? No. An unlisted limited company has to produce an annual report, nothing more. The obligation to produce an interim report exists in the [Swedish Annual Accounts Act](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/arsredovisningslag-19951554_sfs-1995-1554/) but in practice only covers financial groups such as credit institutions, securities companies and insurance undertakings. Sole traders are not covered at all, so for the vast majority of Swedish businesses there is no quarterly report to file anywhere. The counterintuitive part is that listed companies no longer have to report quarterly either. The requirement for interim reports covering the first and third quarter was removed through [government bill 2015/16:26](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/proposition/regelbunden-finansiell-information-och_h30326/html/), following changes to the EU Transparency Directive. Nasdaq Stockholm then dropped its own requirement, arguing that it would reduce administrative burden and encourage long-term thinking. What remains in law is the annual report and a half-year report. Several Swedish sources still claim the opposite, including the Swedish Wikipedia article on quarterly reports. Always check against the [Swedish Accounting Standards Board summary of what applies to limited companies](https://www.bfn.se/redovisningsregler/vad-galler-for/aktiebolag/) before anyone tells you that you are obliged to do something. The absence of an obligation does not make the report pointless. It makes it voluntary, and a voluntary report has to earn the time it takes. ## What forces a quarterly rhythm anyway? Tax filing deadlines. VAT and employer declarations have to be filed at a fixed frequency regardless of what you think, and they require the books to be in order on specific dates. The rhythm already exists in the business. The quarterly report is simply a way to get paid for work you are doing anyway. ### VAT sets the pace Which period you report VAT for is decided by turnover. The [Swedish Tax Agency rules on reporting periods](https://www.skatteverket.se/foretag/moms/deklareramoms/narskajagdeklareramoms.4.6d02084411db6e252fe80008988.html) set three levels: | Taxable base | Period | Any choice? | |---|---|---| | Up to 1 million SEK | Tax year | Yes, monthly or quarterly can be chosen | | Up to 40 million SEK | Calendar quarter | Yes, monthly can be chosen | | Above 40 million SEK | Calendar month | No | If you sit in the middle band you report VAT quarterly by default. The declaration is due by the 12th of the second month after the period, with August as an exception at the 17th. If the date falls on a weekend it moves to the next working day. ### Employer declarations come every month If you have employees, a different pace applies. Employer contributions and withheld tax must be [declared the month after](https://www.skatteverket.se/foretag/arbetsgivare/lamnaarbetsgivardeklaration/narskajaglamnaarbetsgivardeklaration.4.361dc8c15312eff6fd13c11.html), every month, even when there is nothing to report. In that case you file a zero declaration. That means the payroll side of the books has to be closed twelve times a year while the VAT side may only close four times. An automated flow has to handle both rhythms, not just the one you happen to think about. ## What should the report contain to be worth producing? It depends on who reads it. A bank wants liquidity and debt levels. A board wants variances against plan. You yourself usually want to know whether margins are holding and whether the cash will last. A report trying to answer all three gets long and ends up read by nobody. Start with the reader and work backwards. In practice most smaller companies land on four blocks: the result for the period compared to the same quarter last year, liquidity right now, the largest variances explained in plain language, and a forward view. The fourth block is the one usually missing, and it is the only one that actually changes decisions. A summary of what has already happened is history. A forecast is a basis for action. ## What has to be finished before the quarter can close? Reconciliation. Before the numbers can be compiled, the books have to match reality: bank against booked balance, payouts against orders, receivables against what has actually been paid. If that step is not automated it does not matter how polished the report looks, because it rests on numbers nobody checked. That is a separate job with its own method, and we have written about it separately. If you sell through several channels, [how to match orders against payouts](/en/blog/ai-automation/automate-reconciliation-ecommerce) walks through the protocol step by step. If your orders are scattered across systems it starts even earlier, with [getting the order flow into one place](/en/blog/ai-automation/automate-order-handling-ecommerce). Frequency matters more than many assume. The accounting profession recommends ongoing reconciliation under fixed routines, meaning monthly or more often. If you save up three months of variances until quarter end, you get a pile to dig through in exactly the week you have the least time. Automated monthly reconciliation turns quarter close into a compilation rather than an investigation. If AI agents are new to you, [our overview of AI agents for smaller businesses](/en/blog/ai-agents/ai-agents-for-smbs) gives you the foundation before going further here. ## Which details must every accounting record contain? Seven of them, under [the Swedish Bookkeeping Act, chapter 5 section 7](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/bokforingslag-19991078_sfs-1999-1078/). It is the single most important list in the whole automation effort, because each point corresponds to a field that machine extraction has to get right for the documentation to hold up legally. The law requires the record to contain: 1. When the record was compiled 2. When the business transaction took place 3. What the transaction refers to 4. The amount involved 5. Which counterparty it concerns 6. A record number or other identifier 7. Any other details needed to establish the connection between the record and the booked transaction without difficulty Modern document extraction handles the first six well. Dates, amounts, suppliers and invoice numbers are read from an ordinary PDF with high accuracy. Point seven is where it fails. The connection between the document and the booked entry is not something written in the document. It is something the system has to create and store. A receipt sitting in a folder without a link to the accounting record does not meet the requirement, however well it was read. That is why the link back to the books, not the reading itself, is the hard part to build. ### The documents also have to survive Accounting information must be kept through the seventh year after the end of the calendar year in which the financial year ended. The [Swedish Accounting Standards Board](https://www.bfn.se/fragor-och-svar/arkivering/) is clear that electronic form is fully equivalent to paper, and that a company may choose the form when the document arrives in both around the same time. Scanning the paper much later counts as a transfer with stricter requirements. One rule change few know about makes this easier than it used to be. Through [SFS 2024:342](https://svenskforfattningssamling.se/sites/default/files/sfs/2024-05/SFS2024-342.pdf), in force on 1 July 2024, the requirement to keep the original until the fourth year was removed. A company may now destroy the paper document as soon as the information has been transferred, provided the transfer carries no risk of anything being changed or lost. That rule was what used to force a binder to sit next to the digital archive. In practice it means an automated flow has to know where the documentation ends up and be able to produce it seven years later, not just read it today. ## How do you automate the compilation? By pulling accounting data straight from the accounting software API instead of exporting files by hand. Both [Fortnox](https://apps.fortnox.se/apidocs) and [Visma](https://developer.vismaonline.com/docs/lets-get-started) expose interfaces for records, accounts, financial years, customer and supplier invoices. The report is then built by code, not by copied cells. Technically, the work to automate quarterly reports comes down to three layers, and most companies do not need more. **Retrieval.** A scheduled job that reads the period from the books and stores a normalised copy. Expect limits: Fortnox allows [300 calls per minute per client](https://www.fortnox.se/developer/guides-and-good-to-know/rate-limits-for-fortnox-api) on a five second sliding window, and responds with error code 429 when the ceiling is hit. A build fetching details for hundreds of records has to queue and retry rather than firing everything at once. **Calculation.** Key figures are derived deterministically from the chart of accounts, not by a language model. Revenue, gross margin, operating result and liquidity are sums over account ranges. If you trade in foreign currency, rates come from [the Riksbank open API](https://www.riksbank.se/sv/statistik/rantor-och-valutakurser/hamta-rantor-och-valutakurser-via-api/) instead of being looked up by hand. **Presentation.** This is where a language model belongs: explaining in plain language why an item deviates from last quarter, and writing the summary. The number comes from the code. The wording comes from the model. ## Where does the automation stop? At filing. A VAT return can be prepared by machine but not submitted without a human. The Tax Agency documentation for [filing by file](https://skatteverket.se/foretag/moms/deklareramoms/skapaochskickainmomsdeklarationviafil.4.2fb39afe18dabf1e4d223cc.html) states that contact details cannot be included in the file and have to be entered manually, and that whoever files must identify themselves with an electronic ID. The same applies inside the accounting software. Filing a VAT return directly from Fortnox requires [an agent authorisation with the Tax Agency](https://support.fortnox.se/produkthjalp/bokforing/skapa-momsrapport-fran-bokforing) called Momsdeklaration, ombud, and the return still goes out as a draft that is signed with an electronic ID. This is not a shortcoming in the technology. It is designed that way, because responsibility sits with the company. An automated chain promising to handle everything up to the tax authority without human signing either describes something other than what you think, or something you do not want. The practical consequence: build to shorten the work up to the approval, not to remove the approval. If the system touches company data it is also worth reading [what GDPR requires when AI handles your information](/en/blog/ai-agents/ai-and-gdpr-security) before connecting the sources. ## How do you build a cash forecast that updates itself? By combining three known quantities: the actual balance today, receivables with due dates, and payables with payment dates. Add recurring items such as salaries, rent and taxes on top and you get a rolling forecast without anyone guessing. Most builds project twelve or thirteen weeks ahead. Two things decide whether the forecast is useful or misleading. The first is keeping the booked and actual balance apart. The books show what has been recorded, the bank shows what is actually there. The difference between them is not an error but information, and a system that merges them hides exactly what you need to see. The second is labelling every number with its status. Booked, preliminary or forecast. A forecast figure that looks like a booked figure is more dangerous than no forecast at all, because it invites decisions it cannot carry. ## What did we learn from building it for real? That the hard part is never the reading. In a build for an online retailer, the system reads incoming supplier invoices from email, interprets them and links them to the right entry in the books. The model that reads the document was working within days. The rules for when the link may happen automatically took several times longer to get right. ### Blocks always beat permissions Automatic linking happens only when several conditions hold at once: high confidence in the match, an amount difference under one krona, a date inside a set window, and a sender on an approved list. If a single condition fails, the item goes into a queue for human review instead. The check against double linking is built so that on failure it answers that the item is already linked, which is the cautious answer. A system that guesses in the wrong direction creates more work than it saves. ### Not every entry needs documentation The insight with the biggest effect was to stop chasing everything. Far from every accounting entry needs a document to hunt for. Salary payments, depreciation, tax transfers and internal reclassifications either create their own documentation or already have it. By reading the entry lines and deciding based on which accounts are involved, rather than looking at the description text, most of what first looked like missing documentation disappeared. What remained were the entries that genuinely needed a human. ### The system improves from corrections When a person confirms a link the machine was unsure about, the connection between the cryptic bank statement text and the real supplier is stored. After two confirmations it starts influencing future matching. That requires no retraining of any model, only making use of decisions that are being made anyway. Our own internal finance system follows the same principle throughout: it retrieves, compares and compiles, but books nothing and sends nothing. Every figure carries a reference back to its source. That is the only form of automation that holds up when someone asks where a number came from. ## What does it cost, and when is it not worth it? A bounded system automating the report compilation starts at 45,000 SEK in implementation, with operations between 5,000 and 15,000 SEK a month and no lock-in period. Connecting several systems into one shared flow lands in the 90,000 to 180,000 SEK range. What a build costs in detail is covered in [the cost guide for AI agents](/en/blog/ai-agents/ai-agent-cost-guide). Base the calculation on time released, not technology purchased. At NordicRank, a Swedish SEO agency, 18 automated processes replaced manual lists for orders, project tracking, invoices and client reports. The value is 13.4 hours saved per week, with payback after four months. But it is not always worth it. Three situations where you should wait: - **The books are not in order.** Automating a broken process delivers the same errors faster. Clean up first. - **The volume is too low.** With twenty accounting entries a month it is cheaper to do it by hand, however inefficient that feels. - **Nobody reads the report.** If you build a summary no one uses, you have automated the wrong thing. Start by asking who will read it and what they will decide. What argues for doing the calculation now is that the time spent and the reporting burden are documented problems, not a feeling. In [the Swedish Agency for Economic and Regional Growth survey of business conditions 2026](https://www.tillvaxtverket.se/tillvaxtverket/publikationer/publikationer2026/foretagensvillkorochverklighet2026.12421.html), answered by 6,342 companies, 62 percent of the businesses that want to grow report at least one major growth obstacle, with laws and regulations and the time it takes to comply among the largest. [The Swedish Federation of Business Owners report on VAT complexity](https://www.foretagarna.se/politik-paverkan/rapporter/2025/momslabyrinten/) points the same way: three in ten small business owners say VAT rules cause administrative hassle to a fairly or very high degree. Choosing to automate quarterly reports does not remove the rules. It removes the time it takes to comply with them, and moves your effort from hunting for numbers to deciding what the numbers should lead to. ## Frequently asked questions --- ### Do your payouts add up? Automate reconciliation **URL:** https://eteya.ai/en/blog/ai-automation/automate-reconciliation-ecommerce **Sammanfattning:** Do you get paid for everything you sell? Build an AI reconciliation that matches every order to its payout and flags what's missing before the books close. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' Blocket, Klarna, or Tradera deposits a lump sum in the account. Nowhere does it say which orders the money covers, what fees the platform deducted, or whether a sale is missing entirely. Checking that by hand takes hours, so most people never do it, and missed money stays missed. This guide shows how AI does the check for you: every order is matched against every payout, every mismatch is flagged, and you approve before the books close. The division of labor throughout this guide is simple: you export three files, the AI agent handles steps 1 through 6, and you make the decisions in step 7. You're reading this to understand what happens under the hood, not to sit with the files yourself. ## Why doesn't the payout land on the same amount as your sales? The payout differs from the sales because three separate sources describe the same transaction in three different ways: the platform's order export, your own order source, and the platform's payout report. Each has its own format, its own order key, and its own deductions. Reconciling them by hand takes hours every month and still misses mismatches a human doesn't have time to catch. New to AI agents, start with our [overview of AI agents for SMBs](/en/blog/ai-agents/ai-agents-for-smbs). Where reconciliation fits among the other e-commerce flows is covered in [our article on AI agents for e-commerce](/en/blog/ai-agents/ai-agent-for-ecommerce). In practice it often looks like this: an order has an order number you set yourself, for example in Shopify or WooCommerce. The payment provider, such as Klarna or Stripe, instead assigns its own reference number to the sale, and in the payout report the same order can be spread across several transaction rows. If you also sell through Blocket or Tradera, the same pattern repeats there, just under a third name for the same order. The formats each describe the same thing in their own language. ## What do you need before you start? You need three data sources per platform: the platform's order export, your internal order source, and the platform's payout report in CSV or PDF. Without all three, neither matching nor net calculation can happen, since each source only shows part of the picture. If your orders are already gathered in one place, as covered in [our guide to automating order handling](/en/blog/ai-automation/automate-order-handling-ecommerce), half the job is already done: the internal order source exists and updates continuously instead of being pieced together after the fact. With several channels, such as your own webshop, Blocket, and Tradera, the whole protocol below runs per platform and finally rolls up into a single master table. Three sources times three platforms becomes nine files in a full monthly audit, not three – every platform has its own format, its own payout cadence, and its own exceptions. ## Step 1: how do you collect the three sources? First, every file you've collected is read and profiled: which columns it has, which data types, which fields can work as an ID, and what unit the amounts are in. It takes time now. The payoff comes later: once the rest of the protocol is built, you already know exactly what each source contains. ### Three files, three formats In practice, the files differ on almost every point: - The platform's order export often has a reference number that doesn't resemble your own order number. - The internal order source has the right order number but lacks the platform's internal transaction ID. - The payout report lists transactions, not orders, sometimes several rows per order. Profiling also reveals the amount unit. Some platforms report in minor units, where 229000 means SEK 2,290.00, meaning a division by 100 before anything else gets counted. ### Why the internal source has to be row-level [The Swedish Tax Agency (Skatteverket) requires each sale to be booked individually](https://www.skatteverket.se/foretag/drivaforetag/branscher/ehandeltillprivatpersoner.4.96cca41179bad4b1aa8b90.html), not just as a net sum from a payment provider. That's one reason the internal order source has to be row-level per order from the start, otherwise there's nothing to reconcile the master table's rows against in step 4. If VAT, shipping, and discount sit in separate columns in the internal source but get merged into one sum at the platform, the internal file is what carries the level of detail you'll need later to explain a mismatch. The same profiling also decides which fields qualify as an ID candidate. An order number reused across years, or a customer name spelled differently in two systems, looks like a key but doesn't hold up in practice. ## Step 2: how do you build a shared order key? Now a shared order key is built that works across all three sources, however different they look at the start. The key is normalized, for example by stripping prefixes and leading zeros, then tested against a real match rate before you move on. A common approach is to let the internal order number be the source of truth and build a translation table against the platform's reference column and the payout's transaction ID. The table is built once per platform and reused every month, so the work isn't redone from scratch. The match rate is the first receipt for whether the key holds up. If it's close to a hundred percent after the first test, the normalization caught the right fields. If it's lower, that's usually a sign a prefix, a hyphen variant, or an old order type hasn't been normalized away yet. **Example from a real monthly audit:** at our client Telestore, which sells used phones through telestore.se, Blocket, and Tradera, the same order is called "WGR12345" internally but sits under the platform's own reference number in the order export, while the equivalent order on the next channel is instead called "#10123." A translation table built once per channel solved the matching. ## Step 3: how do you normalize the amounts? Next, every amount is normalized to a shared SEK standard, payout rows are grouped per order, and the net amount is calculated: sales minus fees minus returns. Without that step, figures in different formats and different currency notations can never be compared directly. ### Minor units and separate rows A common challenge when reconciling several channels is that a platform splits the payout into separate SALE, FEE, and RETURN rows per order, instead of a single sum. Settlement then becomes sales minus fees minus returns minus any tax, and all rows have to be grouped to the same order before the net can be calculated. [Klarna's own documentation for settlement reports](https://docs.klarna.com/settlement-reports/) shows the same principle from an established payout provider: each payment is broken down into transaction rows that together explain how the amount in the account became what it is. **Example from a real monthly audit:** one of Telestore's three channels reports in exactly the minor-units format step 1 described, while also splitting every order into separate SALE, FEE, and RETURN rows. Without dividing by 100 and grouping the rows to the same order key, the net would have looked like it differed from both the order list and the payout, even though everything actually matched. ### Thousand separators and direct deductions Another common variant reports in English number format with thousand separators, for example "5,499.00," and deducts the platform's commission directly before payout: the amount paid out is gross minus commission, often with a monthly summary in PDF instead of row-level CSV. The exact commission rate varies by platform and agreement, so that figure has to come from your own payout report. ## Step 4: how do you build the master table? Everything is then gathered into a master table: one row per unique order key, with a flag for whether the order exists at each source, the amount from each, and match flags with notes. A row can look like this in practice: the order key, exists_internally (yes/no), exists_at_platform (yes/no), exists_in_payout (yes/no), the amount from each source, and a match status column: green for a full match, yellow for an amount mismatch, red for the order being entirely missing from a source. This is also the file you save. Every month the master table is exported as CSV, along with the six mismatch lists and an audit report in Markdown and Excel, so it can be opened, reviewed, and archived without anyone having to ask how it was built. > A master table that only shows "matches" or "doesn't match" isn't enough. It has to show exactly which source is off and by what amount, otherwise you're just moving the problem one step and calling it solved. The advantage over comparing three spreadsheets by hand is that the master table is searchable and filterable. Want to see every order above a certain amount with no match, or every mismatch from a specific week? That's a filter, not an afternoon with three Excel tabs open side by side. ## Step 5: what mismatch lists should the AI produce? From the master table, AI then produces six mismatch lists – one for each type of gap that can appear between the three sources. Each list is a ready-made work list for a human, not raw material. The six lists, one by one: 1. Exists internally but missing at the platform, often a sign an order never synced across at all. 2. Exists at the platform but missing internally, common with manual orders or an integration error that went silent. 3. Exists in the order lists but missing from the payout, for example an order waiting for the next payout period. 4. Exists in the payout but missing from the order lists, the kind of mismatch that hides easiest in a large file. 5. Amount differences, where the order exists everywhere but the sum doesn't match between sources. 6. Canceled or returned orders, which need their own check since they affect the net at several points at once. A return that's deducted in the payout as a RETURN row, but never registered as a return internally, ends up in exactly the fourth list: exists in the payout but missing from the order lists. **Example from a real monthly audit:** this is exactly the kind of finding Telestore's monthly audit is built to catch. A return the platform has already deducted but that was never registered internally lands in list four and is investigated before the books close, instead of surfacing months later as an unexplained difference. How a return is registered correctly from the start, checked against the right of withdrawal and a store's own return policy, is covered in [our guide to AI returns handling with a human in the loop](/en/blog/ai-automation/ai-returns-handling-customer-service). ## Step 6: how do you verify the platform's totals? The final arithmetic check covers the platform's own totals: sum the transaction rows yourself and compare against the platform's own summary, while verifying the settlement formula row by row. An error in the summing logic otherwise never shows up in a single order, only in the whole. [Bokio, a Swedish accounting platform, describes the same principle for bank reconciliation](https://www.bokio.se/hjalp/bokforing/kontrollera-bokforing/stamma-av-bokforing-mot-bankkonto/): if the sum in the books matches the balance in the account, the odds are high the rest matches too. Flip the order and rely only on the platform's own total, and you risk inheriting an error you never caught yourself. [FAR, the institute for the accountancy profession in Sweden, states in its guidance to BFNAR 2013:2 (a general recommendation from Sweden's Accounting Standards Board) that bookkeeping should be reconciled on an ongoing basis under fixed routines](https://www.faronline.se/dokument/rattserien/redovisa-ratt/a/rr_avstamninglopandebokforing/), with the frequency adjusted to the individual company's circumstances. For an e-commerce store with daily sales across several channels, that judgment almost always lands on monthly, or more often. Automating reconciliation doesn't change that judgment, but it lowers the cost of doing it often. [Bokio makes the same point in its own piece on why reconciliation should happen regularly](https://www.bokio.se/blogg/stam-av-din-bokforing/): an error caught after a month is cheap to fix, the same error after a year can take consultant hours to untangle. ## Step 7: where does the human come in? Last comes the control chain: AI proposes and flags, the human approves. A clean match turns green and needs no decision. Every mismatch needs a human decision before the books close, and the AI never posts anything on its own. In practice that means the system never writes a correction into the books. It presents the material and waits for an approval or an instruction. The run itself takes minutes. The human's job is to review the mismatch lists, not to hunt for them. [Sweden's Bookkeeping Act (bokföringslagen, 1999:1078)](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/bokforingslag-19991078_sfs-1999-1078/) places bookkeeping responsibility on the company, not on a tool, and that division of responsibility has to show in how the system is built, not just in a contract. That's the core of how to automate reconciliation without giving up control: the machine does the tedious work of reading nine files and comparing them row by row. The human does the one thing AI should never do: take responsibility for the number that actually gets booked. Once the number is reconciled, the next step is [turning it into the quarterly report](/en/blog/ai-automation/automate-quarterly-reports) on the same underlying data. ## What tech stack do you need? An automated reconciliation is built on three layers: a script layer that chews through the files, an AI agent that understands them, and a schedule that makes sure it actually happens every month. ### Three layers, one by one - **Python and pandas** read in the files, normalize order keys and amounts, and build the master table plus the six mismatch lists. It's the same tool whether the source is an Excel export, a CSV, or a PDF table that first needs extracting. - **An AI agent**, for example built on Claude or another large language model, profiles new file formats automatically, writes the audit report's summary in plain language, and flags which mismatches look unusual compared with previous months. - **Scheduling** runs the whole chain monthly, from collection to a finished report. The output every month is the same regardless of tooling, ready to send on to whoever owns the books – whether that lands in Fortnox, Visma, or another accounting program. What a build like this usually costs, and when it pays off for your own volume, is in the [cost guide for AI agents](/en/blog/ai-agents/ai-agent-cost-guide) and in our [savings calculator](/en/ai-savings). None of the three parts requires tearing anything existing down. Python and pandas run against the files you already export, the AI agent is added as a script in the same flow, and the scheduling is a cron line, not a new system to teach the whole team. It's the same pragmatic principle behind everything else we build: automate reconciliation on top of what already works. ## Frequently asked questions --- ### Build AI returns handling with a human in the loop **URL:** https://eteya.ai/en/blog/ai-automation/ai-returns-handling-customer-service **Sammanfattning:** Two return emails can look identical but need different answers. This guide shows how to build AI returns handling that checks the law and hands off in time. import FAQ from '@/components/blog/FAQ' "Hi, I'd like to return the item I bought." Two customers can write exactly the same thing. One case the system can handle directly. The other needs a human. The difference does not show in the email. This guide walks step by step through building AI returns handling where the human is built into the flow, what is often called *human in the loop*. You get the control chain's seven steps to follow: what is known about the purchase, what the law says, what the store itself has promised, and where the line is for when a human takes over. Good returns handling is as much about knowing when the system must not guess as about answering fast. If you are new to AI agents for customer service, start with our [overview of AI agents for SMBs](/en/blog/ai-agents/ai-agents-for-smbs). ## Why doesn't the difference show in the email? The sentence "I want to return the item" can apply to an online purchase with a statutory right of withdrawal, an in-store purchase with a voluntary return policy, or a faulty item that needs a warranty claim. Which one applies is not decided by the wording of the email, but by where the purchase was made and when the item arrived. Volumes make the mistakes expensive too. [According to Kustom data for the period August 2025 to April 2026, 24.9 percent of fashion purchases in Swedish e-commerce are returned](https://it-retail.se/bakom-returerna-trogna-modekunder-returnerar-mer-och-unga-kvinnor-skickar-tillbaka-mest/), against 5.9 percent for e-commerce as a whole. At that volume, a mistake scales exactly as fast as the benefit, regardless of whether the system approves the wrong return or denies a return the customer actually had a right to. Customer service and returns tend to sit at the top when listing where an AI agent does the most good in a store, something we cover broadly in [our article on AI agents for e-commerce](/en/blog/ai-agents/ai-agent-for-ecommerce). The rest of this guide goes deep on the returns flow itself, step by step. ## How does the control chain fit together? Returns handling built only for the easy case, an unopened item sent back on time, holds up fine until reality deviates. It is the exceptions that decide whether the system can be trusted, which is why the steps need to come in a fixed order. The whole chain in one line: **The customer's question → facts → law → your own terms → follow-up question → automation or a human** We call this model the control chain. It is the same underlying flow we start from when we build automation flows for e-commerce businesses, whether the case involves returns, orders, or something else with rules at its core. The chain breaks down into seven steps: 1. Confirm the facts about the purchase. 2. Check what the law says. 3. Check the store's own terms. 4. Find the missing piece of information. 5. Ask a narrow follow-up question. 6. Match the answer against a pre-approved rule. 7. Hand off when something doesn't add up. The rest of the guide goes through each step in turn. ## Step 1: what facts do you confirm first? Before the answer can be determined, the system needs to know three things: who the customer is and which order is involved, which channel the purchase was made through, and exactly when the item arrived. Without these three, neither the law nor the store's own terms can be applied correctly. - **The right customer and order.** Match against the order number or account details, never guess from a name in an email. An order number that does not match the customer's details is not a minor detail, it is a signal that either the wrong person is reaching out or something about the order already differs from what the system assumes. - **Channel.** A distance purchase (online, phone, catalogue) or a purchase in a physical store decides whether a statutory right of withdrawal exists at all. - **Delivery date.** The date that governs the deadline, not the purchase date. ## Step 2: what does the law say? For distance purchases, the customer has a statutory 14-day right of withdrawal as a general rule under [Chapter 2, Section 10 of Sweden's Distance Contracts Act (distansavtalslagen)](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/). Under [Chapter 2, Section 12](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/), the period starts on the day after the customer received the item, not on the purchase date. A system that gets this wrong can deny a valid return, or approve a return that has already expired. A warranty claim is a different matter: the item being defective, governed by its own set of rules, [Sweden's Consumer Sales Act (konsumentköplagen, 2022:260)](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/konsumentkoplag-2022260_sfs-2022-260/), with three years of liability for defects. A system that conflates withdrawal and a warranty claim, for example treating a defective item as an ordinary withdrawal return, risks giving the customer the wrong answer in both directions. ### Genuine exceptions to the right of withdrawal Under [Chapter 2, Section 11](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/), the right of withdrawal disappears entirely for certain items: broken seals on products that, for health or hygiene reasons, cannot reasonably be returned, custom-made items, and items that deteriorate or expire quickly. The applicable product categories and required evidence should be defined in advance. Clear standard cases can be handled against those rules. If the evidence is unclear or requires judgment, the case goes to a human. ### A value deduction instead of a lost right of withdrawal This is where many go wrong: an item being used or unpacked does not automatically remove the right of withdrawal. Under [Chapter 2, Section 15](https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/lag-200559-om-distansavtal-och-avtal-utanfor_sfs-2005-59/), the store can instead make a deduction for reduced value, lowering the refund rather than denying the return outright. That assumes the customer received correct information about the right of withdrawal before the purchase. [Sweden's Consumer Agency, Konsumentverket, explains the principle using shoes tried on indoors](https://www.konsumentverket.se/fragor-och-svar/2863070/kan-jag-lamna-tillbaka-anvanda-skor/), and [rulings on value deductions from Sweden's National Board for Consumer Disputes (ARN)](https://www.arn.se/vanligafall/3.3.-vardeminskning/) give concrete examples of where the line is usually drawn. The difference between a value deduction and the genuine exceptions above is exactly the kind of judgment an AI solution must pull from a pre-approved rule, never from its own interpretation of the law. ## Step 3: what have you promised the customer yourself? If the customer buys in a physical store, no statutory right of withdrawal applies. [A store return policy and exchange rights are entirely voluntary benefits](https://www.konsumentverket.se/konsumentratt/oppet-kop-och-bytesratt/), and it is the store itself that sets the terms. The system therefore needs to know exactly what your store promises, not just what the law requires. The store sets the terms of its voluntary return policy. Those terms can give the customer additional rights, but they cannot restrict statutory rights when those rights apply. ## Step 4: what information is missing? The system now has the facts about the purchase, the law, and the store's own terms, but one piece of information can still be missing. A common example under a return policy: the terms require unopened packaging, a rule the store itself set, not the law, and the customer has not said whether the packaging has been opened. Without an answer to that exact question, the case can be neither approved nor denied yet. The system should then neither guess nor hand off immediately. The next step is to ask one concrete follow-up question, check the answer against the store's pre-approved rules, and move forward only if the answer is unambiguous. ## Step 5: how do you ask the follow-up question? A good follow-up question is narrowed to exactly the piece of information that is missing, never a general interrogation about the whole case. It is only asked when a single detail, for example whether packaging has been opened, decides which rule applies. The customer should be able to answer in seconds, not fill in a form. An example of what that question can look like: > "Thanks! To check what applies to your return, we need to know whether the packaging has been opened." The answer is then checked against the rule the store approved in advance, for example "unopened packaging required for this return policy." If the answer matches a clear rule, the case moves forward as a standard case. If the answer is ambiguous, or does not fit any pre-approved rule, the case goes to a human instead. Keeping the question narrow matters. [A 2022 Sifo survey for Nets found that 51 percent of Swedish consumers have at some point skipped a return](https://www.mynewsdesk.com/se/nets/pressreleases/besvaerligt-med-produktreturer-inom-e-handel-3199094) because the process felt too complicated. A system that asks for one thing at a time, instead of a long form, lowers that friction without lowering accuracy. The same pattern applies to other missing information, not just packaging. If a confirmed delivery date is missing, the system can instead ask when the parcel arrived, or request the tracking number that reveals it. Always ask about exactly the piece of information that is missing, never about everything at once. ## Step 6: when does the case move forward automatically? If the information is complete and the rule is clear, the case moves forward automatically, for example a distance purchase with a confirmed delivery date, an active withdrawal period, and no applicable pre-approved exception. The system needs no human when all the facts already point to the same pre-approved rule. Customer A writes that they want to return an item. The order number matches, the customer received the item six days ago, and no pre-approved exception applies. Every fact points to the same clear rule. The withdrawal is registered, the customer receives the next instruction, and the case moves forward without requiring human judgment. ## Step 7: when does a human take over? If the details are contradictory, fall outside a clear rule, or require judgment, the case goes to a human instead. Customer B writes exactly the same sentence as Customer A. The order number exists, but the purchase was made in a physical store with no registered return policy, and the customer claims an employee verbally promised a longer deadline. No rule covers a verbal promise. The system cannot judge whose memory is correct, so the case goes to a human with the full picture already compiled: what is known, what is missing, and why it could not be resolved automatically. This is also the difference between simply answering and actually acting. A system that only chats can explain how a return works. A system that registers the return, picks the right rule, and sends the confirmation acts instead of merely informing. We cover that distinction in detail in our [comparison of AI agents and chatbots](/en/blog/ai-agents/ai-agent-vs-chatbot). ### The line the AI can never move on its own The point is not for the AI to freely interpret the law. The rules that govern the decision, the terms of the return policy, the exceptions, the thresholds, are pre-approved by a human in advance. The AI checks facts against those rules. As soon as a case requires its own judgment, a gray area the law or the terms do not cover directly, it is a human who decides, not the system. That is the core of human in the loop: the human is not an emergency exit for when something has already gone wrong, but a built-in part of the flow with one clear responsibility, the judgment calls. ## What tech stack do you need? Returns handling built on the control chain rests on six components: a data source with orders, a language model called via API, an orchestration layer that ties the steps together, a rule engine for the store's terms, a handoff path to a human, and logging of every decision. ### Six components, one by one - **The data source.** The order system or e-commerce platform, for example Shopify or WooCommerce, is connected via its API. This is where the system pulls the order number, channel, and delivery date, the three facts Step 1 requires. - **The AI model.** A language model called via API reads the email, interprets what the customer is asking for, and formulates the follow-up question. The model makes no decision on its own, it matches facts against rules. - **The orchestration.** A no-code tool such as n8n ties the steps together without you writing everything from scratch, and suits most volumes. If you already have a development team and high volume, your own code can be the right path instead. The trade-off between [building an AI agent yourself or hiring someone](/en/blog/ai-agents/build-vs-buy-ai-agent) applies just as much here, driven by volume and in-house capacity, not by what sounds the most advanced. - **The rule engine.** The store's rules, return policy terms, exceptions, and thresholds are stored as a versioned configuration outside the model itself. The governing rules must not depend on the AI freely interpreting a prompt. They need to be readable, editable, and approvable without changing the model. A versioned rule engine also makes it easy to show, after the fact, exactly which rule applied on the day a specific case was decided. - **The handoff path.** A helpdesk system or a monitored mail queue receives escalated cases, with the full picture attached so the human does not have to start over. - **Logging and traceability.** Every decision, automatic or human, is saved in a database with a table view on top for human review, for example Postgres and NocoDB. [Here's what it looks like when we built the equivalent for order handling](/en/blog/ai-automation/automate-order-handling-ecommerce). Approved refunds also need to show up in the payout for the reconciliation to add up, which [our guide to reconciling orders against payouts](/en/blog/ai-automation/automate-reconciliation-ecommerce) covers. Returns handling touches personal data, order numbers, addresses, and payment information, the same demands on data access as any other AI handling of customer data. [Our guide to AI and GDPR](/en/blog/ai-agents/ai-and-gdpr-security) covers what it takes to keep that part in order from the start. What a build like this usually costs is in our [cost guide for AI agents](/en/blog/ai-agents/ai-agent-cost-guide). ## What needs to be in place before you build? Three things need to be in place before the returns handling can be built: a source of order data that shows channel and delivery date, written and approved rules for the return policy and its exceptions, and a clear path for handing off cases to a human. Without these three, the system has nothing to check the customer's answer against. - **Order data with channel and delivery date**, gathered in one place the system can read. - **Written, approved rules** for the return policy, exceptions, and thresholds, not something decided case by case once the case already sits with the customer. - **A clear handoff path** for cases where the information is not enough for an automatic decision. Whether you build it yourself or hire someone, the groundwork is the same: write down the rules before you build the returns handling, not while it is already live. Whoever takes over a handed-off case does not start from zero either. The groundwork is already compiled: what is known, what is missing, and where it stalled. The judgment call goes faster than if the case had been manual from the start. Good automation is not about the AI making as many decisions as possible. It is about every case moving forward the right way: check what is known, ask about what is missing, and hand off when a human genuinely needs to make a judgment call. That is human in the loop in practice. ## Frequently asked questions --- ### Automate order handling in your e-commerce store **URL:** https://eteya.ai/en/blog/ai-automation/automate-order-handling-ecommerce **Sammanfattning:** How to automate order handling in your e-commerce store, from orders and shipping labels to inventory and returns. Step by step, with a real Telestore example. import CaseLink from '@/components/blog/CaseLink' import FAQ from '@/components/blog/FAQ' import BlogTestimonial from '@/components/blog/BlogTestimonial' import BlogScreenshot from '@/components/blog/BlogScreenshot' Order in, shipping label out, parcel on its way, without a single manual click. That is what automated order handling looks like when everything lines up. The hard part, and the part that actually saves money, is the orders that do not. This guide shows step by step how to automate order handling, with Telestore as the example: a Swedish e-commerce store for used phones where we built 56 automations. If you first want to see what AI does for an e-commerce business in general, read our [overview of AI agents for e-commerce](/en/blog/ai-agents/ai-agent-for-ecommerce). ## What does automating order handling mean? To automate order handling means the steps between purchase and delivery are run by a system instead of a person. The order is captured, customer data is fetched, a confirmation and a shipping label are created, inventory is reconciled, and exceptions are flagged, without manual clicks at every step. At Telestore, around 2.5 hours a week used to go to troubleshooting manual lists, and errors in the orders cost both money and customers. That is the friction the automation removes. The point is not to chase the human away. It is to let the machine take the repetitive and predictable, so your time goes to the cases that genuinely need judgment. A good automation does the boring 80 percent itself and hands the hard 20 percent over to you, in a controlled way. Order handling is among the first things worth tackling, because the volume is high and the steps look the same every time. [Shopify lists order handling among the processes AI can take over in e-commerce](https://www.shopify.com/se/blog/ai-inom-e-handel). ## How do you bring all orders into one place? The first step is to gather all orders in one system, no matter which channel they come from. You cannot automate a flow that is spread across four logins. It all starts with the orders landing in the same place. At Telestore, phones were sold in three places at once: their own site, Blocket, and Tradera. Before, that meant staff logged in to each one to see and handle orders. Now all three are connected to the same system, so every order, wherever it came from, shows up in a single flow. That is the core of an order management system (OMS): one view that owns the order flow regardless of channel. Technically it happens through the platforms' APIs: each channel sends its orders to the same database, where they are translated into a common format. It sounds trivial, but this is where many manual errors are born, when the same order exists in three systems with small differences. When everything is mirrored to one source instead, the rest of the automation becomes reliable, because it always reads from the same truth. That is the invisible foundation: once the order lives in one place, everything else can be built on top. ## How do you automate confirmation and shipping? When an order comes in, the system fetches the customer's details, creates an order confirmation, and orders a shipping label automatically. At Telestore, the site, Blocket, and Tradera are connected to PostNord, so the right shipping label is generated directly without anyone typing the address by hand. This is the step where time actually frees up. Telestore handles around 34 orders a week, and the order handling itself went from about ten minutes to two per order. The shipping labels, which used to be written one by one, are now handled fully automatically. Together the two steps free up several hours a week, time that used to go to copy-pasting between systems. It is better for the customer too: the confirmation arrives in seconds and the parcel can ship the same day, instead of waiting for someone to print a label. ### What an automated order flow looks like When an order lands, this happens: - The order is captured from the channel it came in on, and the customer's details are fetched. - An order confirmation is created and sent to the customer immediately. - A shipping label is ordered automatically from the carrier, PostNord in Telestore's case. - The inventory level is updated and any exceptions are flagged for a human. None of the steps require anyone to log in and click. ### The right customer data decides everything This only works if the customer's details are correct. Since most pay with Klarna or similar, name and address have to match from the start, otherwise neither payment nor delivery goes through. The automation is therefore only as good as the data it gets in, which is what makes the first step, gathering everything in one place with the right details, so important. ## How do you keep stock from running out? An order you cannot fulfill is a failed order, so keeping stock filled is part of order handling. Here it pays to automate the monitoring, but not the purchase itself. At Telestore there is an alert that watches the stock level against parameters you set yourself. One example: when the screen protectors for a certain model drop below five in stock, the system automatically adds the right quantity to the supplier's cart via their API. But it does not place the order. A human steps in and bundles several items into one order a few days later, so you avoid paying shipping on every small restock. It is a good example of smart automation: the machine handles the monitoring and the preparation, the human makes the final decision where it actually saves money. ## What do you build it with? You build it with an automation engine, a database, and connections to your systems. Today the smartest choice is often open-source tools you run yourself, so you avoid a per-run fee and let the customer data stay with you. ### The stack, part by part Here is what a modern setup you run yourself looks like: - [**Coolify**](https://coolify.io) is the host. An open alternative to Vercel or Heroku that you run on your own server, where you start the rest with one click. - **n8n** is the automation engine, the part that replaces older tools like Make. [It has strong AI-agent nodes](https://zapier.com/blog/n8n-vs-make/), takes no per-run fee, and the flows live in your own infrastructure, which is an advantage for GDPR when you handle customer data. - **Postgres** is the database where orders, products, and your parameters live. It is started with one click in Coolify. - **NocoDB** puts a table view on top of the database, so a human can easily see and change things, for example set the low-stock thresholds. The advantage for a smaller e-commerce store is predictable cost: you pay for a server, not per automation, and avoid watching the bill grow with the volume. Telestore was built on the tools of its time, but if we rebuilt it today this is the stack we would choose. An honest caveat: running it yourself takes technical skill and ongoing maintenance. If you do not have that expertise in-house, this is the kind of thing we help companies build and run. ## Why are the exceptions the hardest part, and the most important? An order that goes perfectly is easy to automate. The real work is in the orders that go wrong, and that is where most guides fall silent. An automation that only handles the perfect cases breaks the first time reality hits. ### Example: returns and the right of withdrawal When a customer wants to use their return right, the system automatically checks whether the right still applies, by looking at when the phone was bought and when it was collected, against the store's policy. If it is within the window, the return is registered automatically and the customer gets an email with the right QR code to send the item back. If it is outside, or unclear, the case is escalated automatically to the right person for a judgment call. The machine does the exact check against the dates, the human only steps in when judgment is genuinely needed. (Sweden's right of withdrawal is 14 days under the [Distance Contracts Act](https://www.konsumentverket.se/konsumentratt-process/angerratt/), but your store can offer a more generous return policy.) The same principle applies to other exceptions: an address that does not match, a payment that hangs, a customer who does not respond. [Gartner predicts that agentic AI will resolve 80 percent of common customer service issues by 2029](https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290), but the remaining twenty are exactly the ones that need judgment. Whoever builds the follow-up for these cases, ideally with tests on exactly when a reminder should go out, gets far more out of it than whoever only automates the perfect order. The return example above is simplified down to the right of withdrawal. The difference between the statutory right of withdrawal and a voluntary return policy, and how the system should ask when information is missing before it hands off, is covered step by step in [our walkthrough of the AI returns handling control chain](/en/blog/ai-automation/ai-returns-handling-customer-service). ## How do you get started? To automate order handling does not have to be a big project. Start with the step that takes the most manual time today, not with everything at once. For most e-commerce shops that is order confirmation and shipping, or gathering the orders in one place. Measure how long the step takes before you begin, so you can show what you saved afterward. Take one step, get it stable in production, then expand to the next. One common next flow is reconciling payouts against orders, which is exactly what [our guide to matching orders against payouts](/en/blog/ai-automation/automate-reconciliation-ecommerce) walks through. The step after that is [financial reporting](/en/blog/ai-automation/automate-quarterly-reports), where the same data is compiled into the quarterly figures. Once the foundation is there, every new flow becomes cheaper to add. If you want to calculate what it is worth for your own volume, use our [savings calculator](/en/ai-savings), and if you need to know what a build usually costs, read the [cost guide for AI agents](/en/blog/ai-agents/ai-agent-cost-guide). ## Frequently asked questions --- ### AI agent for e-commerce: what it does and costs **URL:** https://eteya.ai/en/blog/ai-agents/ai-agent-for-ecommerce **Sammanfattning:** What does an AI agent do in e-commerce, what does it cost, and when does it pay off? A concrete look at customer service, orders, inventory, and product copy. import CaseLink from '@/components/blog/CaseLink' import FAQ from '@/components/blog/FAQ' An AI agent for e-commerce does more than answer in the chat. It handles entire cases: replies to customers, changes and tracks orders, keeps an eye on inventory, and writes product copy at scale. The question for you running a webshop is no longer whether the technology works, but where it pays off first and what it actually costs. This guide covers what an AI agent for e-commerce does, where the value is greatest, what it costs in Swedish kronor, and how to start without overreaching. If you're new to AI agents, it helps to first read [how they work for smaller companies](/en/blog/ai-agents/ai-agents-for-smbs). ## What does an AI agent do for an e-commerce? An AI agent for e-commerce connects your systems and handles entire cases itself. It answers customer questions, changes and tracks orders, updates inventory levels, and generates product copy, then hands over to a human when the case needs judgment. ### Where an AI agent works in a webshop In practice it works in four places: - **Customer service and returns.** Answers delivery, return, and product questions around the clock, and starts a return or exchange directly in the system. Where the line falls between a statutory right of withdrawal and a store's own return policy, and when the AI should ask instead of guessing, is covered in [a guide to AI returns handling with the human kept in the loop](/en/blog/ai-automation/ai-returns-handling-customer-service). - **Order handling.** Changes addresses, combines deliveries, cancels or updates orders, and keeps the customer informed. We walk through that whole flow, from order to shipping label and return, in the guide on [automating order handling](/en/blog/ai-automation/automate-order-handling-ecommerce). - **Inventory and restocking.** Reads the sales pace, flags low-stock items, and proposes a finished restock order before the shelf runs empty. - **Product copy at scale.** Writes search-optimized product descriptions for hundreds of items against your own product data, instead of writing them one by one by hand. [Shopify's walkthrough of AI in e-commerce](https://www.shopify.com/se/blog/ai-inom-e-handel) lists the same main areas plus forecasting, fraud detection, and dynamic pricing. Most of this has existed as separate tools for years. What's new is that an AI agent binds them together and does the work rather than just suggesting it. ## Where does an AI agent deliver the most value first? The most value first usually sits in customer service and returns, where volume is high and questions repetitive. After that come order handling and inventory forecasting. Product copy at scale gives quick effect for shops with thousands of items. The logic is simple: start where a lot of time is tied up in work that looks the same every day. Customer service is almost always that place in an e-commerce. [Shopify reports that retailers using AI chat during Black Friday 2024 saw a 15 percent increase in conversion](https://www.shopify.com/se/blog/ai-inom-e-handel), and that AI-driven demand forecasting can cut inventory levels by 20 to 30 percent without service levels falling. Those are two different kinds of value: one captures more purchases, the other frees up capital otherwise tied up on the shelves. Swedish retailers are not behind. [Svensk Handel describes how chains like ICA and Apotek Hjärtat](https://www.svenskhandel.se/nyhetscenter/nyheter/ai-revolutionen-som-formar-framtidens-handel/) started early with AI for customer service and internal processes, and references the McKinsey figure that companies adopting AI proactively can reach productivity gains of up to 40 percent. The large chains have the resources to go first. The point for a smaller shop is that the same technology now costs a fraction of what it did in 2023. How large a share of customer cases an agent can take is no longer a guess. [Gartner predicts that agentic AI will autonomously resolve 80 percent of common customer service issues by 2029](https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290). In an e-commerce, the "common cases" are exactly what drowns support in peak season: where is the parcel, how do I return this, is the item available in another size. That's where an agent pays for itself fastest. ## What separates an AI agent from a regular chatbot or plugin? The difference is action. A chatbot or a plugin answers within its box. An AI agent acts across your systems, fetches data from inventory and CRM, updates the order, and finishes the case, technically via APIs and what is called the [MCP protocol](/en/blog/ai-agents/mcp-protocol-technical-guide). It sounds like a technical detail, but in a shop it becomes concrete. A chatbot can explain how a return works, while the agent registers the return, creates the shipping label, and queues a refund. Where a plugin for order tracking only shows a tracking page, the agent sees the delivery is delayed, reschedules it, and informs the customer before the complaint comes in. We use a strict definition: act means AI agent, only answer means chatbot. Many tools are marketed today as "agents" even though they never leave the chat. The difference in what you get is large, and it drives both price and value. The full comparison across eight dimensions, with pricing and decision support, is in our guide on the [difference between AI agent and chatbot](/en/blog/ai-agents/ai-agent-vs-chatbot). ## What does an AI agent for e-commerce cost, and when does it pay off? An AI agent for e-commerce costs from 45,000 SEK in implementation and 5,000 to 15,000 SEK per month in operation, depending on how many processes and systems it touches, no lock-in period. It pays off when the volume it removes costs more to handle by hand. Here is how the ranges look for Swedish implementations in 2026: | Scope | Implementation | Operating per month | |---|---|---| | One process (for example returns) | from 45,000 SEK | 5,000 SEK | | Several processes | from 180,000 SEK | 15,000 SEK | The operation of the AI itself is negligible: fractions of a krona to single SEK per case according to the model vendors' price lists. What you pay for is the work around the agent, meaning the build, the integrations against your platform, and the maintenance, not the model calls themselves. What decides whether the calculation works out is what the manual alternative costs. [Statistics Sweden's wage data](https://www.scb.se/hitta-statistik/statistik-efter-amne/arbetsmarknad/loner-och-arbetskostnader/lonestrukturstatistik-hela-ekonomin/pong/tabell-och-diagram/genomsnittlig-manadslon-efter-sektor/) puts the average monthly salary at 41,600 SEK for 2024, which with social contributions lands the hourly cost around 300 to 350 SEK. The more volume tied up in manual work at that cost, the faster the automation pays for itself. ### Two builds that show ROI Two concrete builds show the pattern, even though they aren't pure e-commerce: **NordicRank** automated 18 processes for 65,000 SEK plus 4,500 SEK per month, from report generation to invoice handling. The result was 13.4 hours per week of saved work time, which corresponds to around 380,000 SEK per year in value. Payback: four months. It's the same kind of process automation an e-commerce runs in the background, only in a different industry. **Sannegårdens Pizzeria** had an agent connect the POS with supplier invoices and propose a finished restock order every week. The result was 32 percent less food waste and 6 hours per week saved on inventory, around 315,000 SEK per year in net effect. The principle, letting AI anticipate what needs restocking, is exactly the one a webshop uses for its inventory. That early adopters actually get their money back is supported by data. [A Google Cloud study of 3,466 executives](https://www.googlecloudpresscorner.com/2025-09-04-Google-Cloud-Study-Reveals-52-of-Executives-Say-Their-Organizations-Have-Deployed-AI-Agents,-Unlocking-a-New-Wave-of-Business-Value,1) shows that 88 percent of early agent adopters reach positive returns on at least one use case. For a deeper price walkthrough with ROI formulas, read our [cost guide for AI agents](/en/blog/ai-agents/ai-agent-cost-guide). ## How do you start with an AI agent in your e-commerce? Start with a single process where volume is high and rules are stable. Measure the starting point before going live, run a pilot on part of the volume, and scale when the numbers hold. Choose the process that drowns the most time today and let the agent take exactly that one. Once you have six weeks of operating data, you know which process should be next. The technology is ready for it: [the Stanford AI Index](https://hai.stanford.edu/ai-index/2025-ai-index-report) shows that 78 percent of organizations now use AI in at least one business function, up from 55 percent the year before. Being early is no longer a risk project. Should you build it yourself or hire someone? It depends on how many systems need connecting and how much time you have internally. The trade-off, with pros and cons, is in our guide on [building an AI agent yourself versus hiring](/en/blog/ai-agents/build-vs-buy-ai-agent). One Swedish e-commerce we built together with is Telestore, which sells used phones. There we let the AI handle pricing, listing, and inventory. Each phone is priced against a market that moves week to week, published automatically, and reconciled against stock levels, instead of being handled by hand. It started with one defined process and grew from there. ## What mistakes do e-commerce owners make when adopting an AI agent? The most common mistakes are automating too broadly, not measuring the starting point, and leaving the agent without anyone owning the follow-up. Add dirty product data, and the project gets stuck no matter how good the AI itself is. Four traps we see more often than others: - **Too broad a scope.** "We want to automate everything" becomes a project that never goes live, because every extra process multiplies the testing work before anything can ship. - **No starting point measured.** Without knowing what the cases cost in time and money today, there's no way to show what the agent saved after six months, which makes the next investment hard to justify. - **Dirty product data.** An AI agent for e-commerce is only as good as the data it reads. Wrong stock levels, duplicate items, or gaps in product attributes give the customer wrong answers. In a webshop, this is the most common reason the agent "doesn't work". - **No one owning control.** The agent is left on autopilot. Someone needs to review the escalated cases every week during the first quarter, until the pattern is settled. None of the traps is about the technology itself. They're about preparation and follow-up, and that's where a build either pays off or never reaches the finish line. ## What is "agentic commerce" and do you need to care now? Agentic commerce is when the customer's own AI agent makes the purchase for them, not just you using AI inside the shop. It's still early, but it's worth preparing for: your product data needs to be clean and structured enough that a machine can read and trust it. The direction is clear. [Gartner predicts that 60 percent of brands will use agentic AI for one-to-one interactions by 2028](https://www.gartner.com/en/newsroom/press-releases/2026-01-15-gartner-predicts-60-percent-of-brands-will-use-agentic-ai-to-deliver-streamlined-one-to-one-interactions-by-2028). When a buying agent compares your range against a competitor's, it's your product data it reads, not your design. Shops with accurate prices, clear stock levels, and machine-readable product attributes become easier for an agent to choose. You don't need to build for agentic commerce today. But the processes that make an e-commerce ready for it, clean product data and real-time prices and inventory, are the same processes an AI agent handles for you right now. You prepare for the future by solving the present. ## Frequently asked questions --- ### What is RAG (Retrieval-Augmented Generation)? **URL:** https://eteya.ai/en/blog/ai-agents/what-is-rag-retrieval-augmented-generation **Sammanfattning:** RAG, or Retrieval-Augmented Generation, lets a language model answer from your own documents instead of guessing, for more accurate and traceable answers. import FAQ from '@/components/blog/FAQ' Here is what RAG is, how it works step by step, and when your business needs it. ## How does RAG work step by step? RAG works in four steps: your question goes to a search system, the most relevant pieces of the knowledge source are retrieved, they are passed to the language model as context, and the model writes an answer grounded in them. The search itself usually relies on so-called embeddings. At its core, RAG combines two kinds of memory: the model's built-in memory, what it learned during training, and an external memory, a knowledge base it looks things up in for every question. The idea was introduced in 2020 in a [research paper by Patrick Lewis and others](https://arxiv.org/abs/2005.11401). The built-in memory is frozen at training time; the external one you can update whenever you like, without touching the model. Here is the flow: 1. The question is turned into a search, typically by converting it into a numerical representation (an embedding). 2. The search system retrieves the text passages from your knowledge source that sit closest to the question, often from a vector database. 3. The retrieved passages are passed to the language model as context, along with the question itself. 4. The model produces an answer based on the retrieved passages, not only on its training. Two parts do the work. The **retriever** (the search system) finds the right information, and the **generator** (the language model) writes the answer. [Amazon's overview of RAG](https://aws.amazon.com/what-is/retrieval-augmented-generation/) describes the same split. For the search to hit the mark, the documents are usually broken into smaller chunks beforehand, so only the relevant pieces come along, not whole documents. ## Why does RAG matter for businesses? RAG makes AI useful on your own information. It lowers the risk of made-up answers, gives current facts, and every answer can be traced back to a specific document. On top of that, you avoid retraining the model every time your data changes. That last point is the one that matters for most companies. A language model knows nothing about your internal routines, your product range or last week's price list, because it never saw them. With RAG you point the model at your sources, and it answers from them. [Google Cloud's overview](https://cloud.google.com/use-cases/retrieval-augmented-generation) highlights exactly that as RAG's main benefit: fresh, verifiable answers without retraining. Control is an underrated advantage. You decide which sources the AI may use, and because the answer can be linked to a document, it can be reviewed. [Salesforce highlights](https://www.salesforce.com/agentforce/what-is-rag/) traceability as one of RAG's main business benefits, and [IBM](https://www.ibm.com/think/topics/retrieval-augmented-generation) describes grounding in retrieved sources as what keeps made-up answers down. That is a difference from a model that answers freely from memory, where you do not know where the information came from. ### How we build RAG For us, the source of truth lives in version-controlled text, and RAG sits on top as a derived layer: it helps an agent find and navigate the information, but it must never quietly replace the documented source. In practice we combine structured navigation, to find the right section and point to where an answer comes from, with hybrid search, that is vector search plus ordinary text search, and a reranker that orders the hits by relevance. Every answer has to be traceable back to its original. The principle: structured navigation and source-tracing first, broad RAG second. ![Eteya's RAG flow: a question goes via retrieval, navigation and search to agent context and a grounded answer, all resting on the version-controlled source of truth.](/images/blog/eteya-rag-dataflow.webp) ## RAG or fine-tuning: what is the difference? In short: RAG gives the model new knowledge, fine-tuning changes its behaviour. RAG feeds in facts and documents at question time, which suits current and proprietary information. Fine-tuning instead retrains the model to change its tone, format or skills. They solve different problems. | Aspect | RAG | Fine-tuning | |---|---|---| | What it changes | Which knowledge the model can reach | How the model behaves (tone, format) | | Updating | Swap the documents, applies right away | Retrain, takes time and costs | | Best for | Proprietary and current facts, citations | Style, structure, specialised tasks | | Traceability | The answer can be linked to a source | Hard to trace where the answer came from | For most businesses RAG is what is needed, not fine-tuning. If you want the AI to know your products, routines and documents, it is knowledge you are after, not behaviour. The two can be combined, but start with RAG: it is cheaper, faster to update, and easier to review. ## When do you need RAG, and when not? Use RAG when the answers should build on your own or current knowledge: support documents, internal policies, product catalogues, price lists. You do not need RAG for simple tasks, or when all the information you need already fits inside the question itself. The rule of thumb is simple. If the AI must know something specific about your business, or something that changes often, RAG is the right call. If what the model already knows is enough, or the whole input fits in the prompt, RAG just adds complexity for no reason. In practice, RAG is often the engine behind an AI agent that answers questions about your specific business. For the bigger picture of how such agents work for businesses, read our [pillar guide on AI agents](/en/blog/ai-agents/ai-agents-for-smbs), or the definition of [what an AI agent is](/en/blog/ai-agents/what-is-an-ai-agent). When the agent also needs to read and write in your systems in real time, the MCP protocol is often used instead: RAG retrieves knowledge, MCP connects to systems. ## Frequently asked questions --- ### AI agents and the EU AI Act: what applies 2026? **URL:** https://eteya.ai/en/blog/ai-agents/ai-agents-eu-ai-act **Sammanfattning:** Is your AI agent regulated by the EU AI Act? Most fall under limited risk with transparency duties, not high-risk. How to judge the level and what to do. import FAQ from '@/components/blog/FAQ' import CaseLink from '@/components/blog/CaseLink' The market is split into two camps that rarely meet. One explains the EU AI Act in detail but never mentions the word AI agent. The other celebrates the business value of AI agents but skips the rules entirely. This guide connects them: does your AI agent count as a regulated AI system, what risk level does it land in, and what does the law actually require of you? The short answer is reassuring for most companies. A customer-facing AI agent is almost never high-risk. But there are duties you need to know, and a couple of traps once the agent starts acting on its own. ## Are AI agents regulated by the EU AI Act? Yes, but not as a category of their own. The EU AI Act has no dedicated clause for AI agents. They are assessed under the same rules as any other AI system: by what they are used for and what risk that use carries. The use decides everything, not the technology itself. This is not our interpretation. The European Commission's own guidance states that AI agents are not a separate category under the regulation, and that the definition of an AI system is enough to cover them. The [Commission's AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/how-are-ai-agents-addressed-within-ai-act-0) writes plainly that the rules for AI systems and GPAI models also apply to AI agents. The Commission calls its own position preliminary, since the technology is moving fast. The consequence matters: the same agent can be nearly unregulated in one setting and heavily regulated in another. An agent that suggests restock orders in a warehouse is one thing. An agent that screens job applications is another, even though the technology behind them may be identical. The EU AI Act is Regulation (EU) 2024/1689. It entered into force on 1 August 2024 and applies directly in Sweden, without the parliament having to turn it into national law. For the basics of how an AI agent actually works, see our [in-depth guide to AI agents for SMBs](/en/blog/ai-agents/ai-agents-for-smbs). ## What risk level does an AI agent land in? Most AI agents that companies use land in limited risk, the transparency tier, not in high-risk. A customer-service agent, a booking agent or an internal assistant is limited risk. It only becomes high-risk when the agent is used in one of the law's specifically flagged sensitive areas. The regulation sorts AI into four levels: prohibited, high-risk, limited risk and minimal risk. For an AI agent, the two middle ones are what matter. ### Where the common agents land An agent that talks to customers lands in limited risk. Then the transparency duty in Article 50 applies, but not the heavy high-risk obligations. An agent that only works in the background against internal systems, without affecting decisions about people, often sits in minimal risk and is effectively unregulated. High-risk is reserved for the areas in the law's Annex III. These include recruitment, credit scoring, education and health. An agent that screens job applications or scores borrowers is high-risk. An agent that answers questions about opening hours is not. The method for classifying step by step, with roles and exemptions, is covered in our [guide to risk classification under the EU AI Act](/en/blog/eu-ai-act/eu-ai-act-risk-classification). Here it is enough to know where an agent normally lands, and to decide whether yours belongs to the sensitive areas or not. ## What does the law require of a customer-facing AI agent? The most important duty is transparency. Article 50 requires that an AI agent interacting directly with people is built so the person understands they are dealing with an AI. It must be clear at the latest at the first interaction, unless it is already obvious to a reasonably observant person. In practice it is one short line: "You are chatting with our AI assistant." The duty falls on whoever builds the agent, and the closer rule that the information must be clear and timely sits in [Article 50](https://artificialintelligenceact.eu/article/50/). The transparency duties have applied since 2 August 2026. This is the duty that actually reaches most agents, and it is cheap to meet. We build the disclosure in from the start with our clients. It costs nothing, and it is a requirement you cannot get around anyway. ## When does an AI agent become high-risk, and what applies then? An AI agent becomes high-risk when it is used in one of the Annex III areas and actually affects decisions about people. Then far heavier requirements apply, with human oversight at the centre. This covers a small share of all agents, but where it hits, the difference is large. There is an exemption that is often missed. Even within a sensitive area, an agent escapes the high-risk label if it only performs a narrow, preparatory or supplementary task and does not replace the human judgment. An agent that merely structures incoming applications ahead of a human review can fall outside. But there is a hard line: the agent always counts as high-risk if it profiles natural persons, however small the task looks. The rule is in [Article 6](https://artificialintelligenceact.eu/article/6/). ### What human oversight means in practice If the agent is high-risk, [Article 14](https://artificialintelligenceact.eu/article/14/) requires it to be built so a human can effectively oversee it throughout operation. The person must understand what the agent can and cannot do, be able to interpret what it does, be able to disregard a suggestion, and be able to stop the agent with a stop function. Autonomy is allowed, but never without a hand on the lever. For the heaviest cases, such as remote biometric identification, the requirement tightens further: no decision may be taken on the agent's identification unless it is separately confirmed by at least two people. ## Are you the provider or the user of the agent? This decides which obligations you carry. If you buy a finished AI agent and use it in your operation, you are usually the user, or deployer, with lighter requirements. If you build your own, or put your own name on one, you can count as the provider with full responsibility for compliance. The line is practical. Use a standard service you do not modify and you are the user. Order an agent built around your processes, or build it yourself, and you drift toward the provider role. The full breakdown of roles and what follows from each is in the [risk classification guide](/en/blog/eu-ai-act/eu-ai-act-risk-classification). The point for an agent is to work out which side you are on before you sign anything. ## Who is responsible when an autonomous agent makes a wrong decision? Responsibility stays with the company, not with the agent. The law assumes a human can understand, oversee and if needed stop the agent, and that it is possible to see afterwards what it did and why. Autonomy does not remove responsibility. It raises the bar on traceability. This is the question no other Swedish guide tackles, and it is worth pausing on. ### Decision support or independent decision? The most important line runs between an agent that suggests and an agent that acts. An agent that produces a draft a human then approves keeps you in the lighter part of the rules. An agent that makes and carries out a decision about a person on its own pulls in heavier requirements, both Article 14 oversight if it is high-risk, and the data protection rules. If the agent makes fully automated decisions about a person, the GDPR can give that person the right to human involvement. How data protection and AI fit together is covered in our [guide to AI and GDPR](/en/blog/ai-agents/ai-and-gdpr-security). ### Traceability is your protection What lets you answer for the agent is the log. For high-risk agents, automatic logging is an explicit requirement. For the rest it is not mandatory, but it is the only thing that lets you reconstruct what happened the day someone questions a decision. In practice we build agents with two things in place: a clear boundary for what they may do on their own, and a log of every action they take. ## What applies in 2026, and what has changed? Four things already apply. The prohibited AI practices since 2 February 2025, the rules for general-purpose AI models since 2 August 2025, and the transparency duties since 2 August 2026. The high-risk rules, however, have been given more time. In November 2025 the Commission tabled a reform package called the Digital Omnibus. After a political agreement in May, it was adopted in July 2026 as [Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng), published in the EU's Official Journal on 24 July and in force on 27 July — five days before the old deadline. The high-risk rules for stand-alone systems in the Annex III areas thereby moved from 2 August 2026 to 2 December 2027. Read this correctly: for a typical customer-service or automation agent, the Omnibus changed nothing. The transparency duty applies, since 2 August 2026. What got more time are the high-risk applications — recruitment, credit scoring and the like. Break the rules and the fines can bite: up to EUR 35 million or 7 percent of global turnover for prohibited practices, and up to EUR 15 million or 3 percent for breaches of other requirements, under [Article 99](https://artificialintelligenceact.eu/article/99/). In Sweden, the [Post and Telecom Authority acts as coordinating market surveillance authority](https://pts.se/ai/ai-forordningen/) in line with the government inquiry [SOU 2025:101](https://www.regeringen.se/pressmeddelanden/2025/10/utredning-foreslar-forbud-mot-vissa-ai-system-och-sanktioner-for-bristande-dokumentation-av-hogrisk-ai/); the complementary Swedish act has, as of August 2026, not yet been enacted, but the regulation applies directly. The full timeline, the sanctions and Swedish supervision are covered in our [guide to the EU AI Act for companies](/en/blog/eu-ai-act/eu-ai-act-guide). ## How do you prepare your AI agents? Start with a simple self-assessment. What does the agent do, who does it affect, and how independently does it act? For most agents you land in a few concrete actions, not in a compliance project. Five questions go a long way: 1. **Is it an AI system?** For an agent the answer is almost always yes. 2. **Which area?** Everyday operations, or a sensitive Annex III area like recruitment or credit? 3. **Provider or user?** Are you building it, or using a finished one? 4. **Does it talk to people?** Then you add the notice that it is an AI. 5. **Does it affect decisions about people?** Then it needs human oversight and a log. ### A worked example Say you have an AI agent that answers customers in chat and books meetings. Run the questions: it is an AI system, it works in everyday customer service and not in any Annex III area, you use a finished service, it talks to customers, and it does not affect decisions about people in the sense of the law. Result: limited risk, one single concrete action to take, namely the notice that it is an AI, plus a log as good practice. Now swap the booking for the agent filtering job applications, and the picture changes completely. Recruitment is an Annex III area, the agent affects decisions about people, and profiling makes it high-risk however narrow the task looks. Same technology, an entirely different compliance burden. That is why you always start with the use, not with the agent itself. Anyone wanting a broader checklist for the whole operation will find it in the EU AI Act guide. But for a single agent, this is enough to know where you stand. The rules are younger than the technology, and they keep moving — the Digital Omnibus regulation is proof of that. But the underlying logic is stable: know what the agent does, be honest that it is an AI, and make sure a human can take over. Do that and you are ready, both for the transparency duties that apply now and for the high-risk requirements arriving in 2027. ## Frequently asked questions --- ### Build an AI agent yourself or hire a consultant? **URL:** https://eteya.ai/en/blog/ai-agents/build-vs-buy-ai-agent **Sammanfattning:** Building an AI agent yourself takes more time, skill and upkeep than it looks. Here is what each path costs, the risk of in-house builds and when to hire. import FAQ from '@/components/blog/FAQ' The question almost always lands in the same moment: someone on the team built a working demo in an afternoon, and now leadership wonders whether you should just build the whole AI agent in-house instead of paying someone else. The demo does not lie, but it hides 90 percent of the work. This guide walks through what each path actually costs, how high the risk is that an in-house build stalls, and when it pays to build yourself versus hire. ## What does it really mean to build an AI agent yourself? Building an AI agent yourself means your team owns the whole chain: data sources, integrations into your systems, logic, security, monitoring and operations over time. The language model itself is the easy part. What takes time is everything around it that makes the agent something you can actually trust in production. A demo answers a question in an empty window. An AI agent in production has to pull the right data from your systems, act toward a goal, handle errors without causing harm, and do it every day for real customers. Industry data shows that data preparation is the single largest item in AI projects, and that integrating with your systems plus testing and security often weighs heavier than the model itself. ### It is not a chat, it is a system Most people underestimate that an AI agent is infrastructure, not a chat window. It needs a memory layer, tool calls, workflow orchestration and logging of every decision. If you want to understand the technical architecture in depth, we have a separate [technical guide to the MCP protocol](/en/blog/ai-agents/mcp-protocol-technical-guide) that shows how an agent is connected to your tools in a standardized way. The difference from a simple bot is also worth reading up on before you decide. We have gone through [what separates an AI agent from a chatbot](/en/blog/ai-agents/ai-agent-vs-chatbot) across eight dimensions, and that is often where expectations break: an agent meant to act on its own is a completely different engineering task than a bot that answers common questions. ## What does an AI agent you build in-house cost? An in-house build costs more than the invoice from an agency, because the most expensive line item is the person doing the building. An AI developer in Sweden sits at roughly 56,000 SEK a month, and a senior AI engineer or AI consultant at 70,000 to 85,000 SEK according to [salary statistics for AI roles in 2026](https://teknoradar.se/karriar/ai-jobb-sverige/). Add operations, and the total grows fast. The visible cost is salary and time. The invisible one is the upkeep afterward. International estimates for an AI agent in production land on significant monthly costs for model calls, infrastructure, monitoring and ongoing tuning, and [total-cost-of-ownership analyses](https://www.keyholesoftware.com/ai-software-development-cost-2026/) show that operations add 15 to 25 percent annually on top of the build itself. An agent that "is done" is rarely done. ### The calculation most people miss Say a developer spends three months on a first in-house build. The salary cost alone comes to around 170,000 SEK before a single customer has met the agent. Then come operations and maintenance month after month, plus the time the team is not spending on your core product meanwhile. The opportunity cost is often the largest item of them all. By comparison, we build a first AI agent from 45,000 SEK, with operations of 5,000 to 15,000 SEK a month depending on scope and no lock-in period. Without an agreement you only pay for what the agent actually consumes, from cents to single kronor per case. If you want the full cost picture side by side, we have broken down [what an AI agent costs in Sweden](/en/blog/ai-agents/ai-agent-cost-guide) across all three paths. ## How big is the risk that an in-house AI build fails? The risk is high, and it is the factor that weighs heaviest in the decision. The RAND Corporation documented that just over 80 percent of company AI projects never deliver the business value they promised, roughly twice the share of ordinary IT projects without AI. The numbers repeat elsewhere. Gartner found in April 2026 that [only 28 percent of AI projects in infrastructure and operations deliver the promised return](https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns), and that one in five collapses entirely. MIT's research initiative NANDA found that 95 percent of organizations see no measurable return from their generative AI pilots at all. ### Why so many builds stall The interesting part of [reviews of why projects fail](https://www.pertamapartners.com/insights/ai-project-failure-statistics-2026) is that the cause is rarely the technology. The failures are about unclear purpose, a weak data foundation and leadership commitment that drains away, not about the model being too dumb. That is exactly the experience you buy when you hire someone who has done it before. An external partner has already walked into those walls at someone else's expense and knows where they sit. ## When does it pay to build yourself, and when to hire? Build yourself when the AI agent is your core product and a competitive edge you have to own, and when you already have a team that can run it for years. Hire when you want results fast, lack in-house AI skill, and want a proven return rather than a research project. The rule of thumb is simple. If you are building something that should be your secret and your competitive edge, and can afford to let a team learn over a year, then an in-house build is right. If instead you want to automate an internal process and see the saving within the quarter, it is rarely worth reinventing the wheel. ### Signs you should build in-house You already have ML engineers on staff, the AI is part of what you sell, and you plan to scale it over many years where owning the infrastructure lowers the cost over time. Then the in-house build carries its own risk, because the skill needs to stay anyway. ### Signs you should hire You want to solve a concrete problem, not start an AI department. You have no one who can take over operations if the person who built it leaves. And you want to know what it costs and what you get before you start. Many companies choose to hire precisely to avoid the high failure rates and the drawn-out timelines. ## What is a hybrid model between building and hiring? A hybrid model means you hire a partner to get the AI agent into production fast, and build up in-house skill in parallel at a calmer pace. You get the value right away and can take over operations yourself later, without starting from a blank page with full risk. It is often the smartest path for a company that wants neither to wait a year nor to lock itself in with one vendor. You ask for an architecture that does not tie you down, and for the documentation needed for someone else to take over. Then the handover becomes a planned point, not a crisis the day a key person leaves. Many companies do exactly this [as a combined setup](https://servicesground.com/blog/build-vs-buy-ai-agents/), not a final choice. They buy themselves time and a proven result, and bring home what they want to own the day the skill is in place. The risk stays with whoever has already walked the path, until you are ready to carry it yourselves. ## What do you get when you hire Eteya instead? You get an AI agent in production in 2 to 6 weeks, built against a fixed scope, by someone who already has proven results at Swedish companies. You skip recruiting, skip owning the risk of a build that stalls, and pay for a solution made to earn itself back fast. The concrete part is easiest to see in the numbers. Sannegårdens Pizzeria in Karlskoga cut its food waste by 32 percent and saves around 315,000 SEK a year, with a payback under three months. NordicRank automated 18 processes, freed up 13.4 hours a week and reached a payback of four months. None of it required hiring a single AI developer. ### You own the result, not just the code A common objection to hiring is that you become dependent. In practice it is the opposite. You get an agent that solves the problem, the documentation that goes with it, and a partner who already knows where the pitfalls sit. If you want to dig into the whole picture before you decide, start with our overview of [how AI agents work for businesses](/en/blog/ai-agents/ai-agents-for-smbs). The build-or-hire decision is ultimately not about who writes the code. It is about where you want to carry the risk, and how fast you want to see the result. ## Frequently asked questions