Demonstrationerna är fängslande. En AI navigerar genom ett komplext bokningsflöde, växlar mellan program, fyller i myndighetsblanketter och slutför flera timmar långa uppgifter på egen hand. Under 2024–2025 visade Anthropic Computer Use, OpenAI Operator, Google Project Mariner och en våg av uppstartsbolag upp agenter som använder datorer som människor.
År 2026 är de här verktygen verkliga. De fungerar. Vissa företag använder dem framgångsrikt i produktion. Men driftsättningarna ser inte ut som demonstrationerna. De är snävare, mer begränsade och omgärdade av skyddsräcken. Den här artikeln handlar om mönstren som skiljer produktion från demonstration.
Vi behandlade grunderna i en artikel på fortsättningsnivå. Här går vi djupare: produktionsmönstren, felen vi ser gång på gång, ekonomin och hur du lanserar ett system för datoranvändning som faktiskt är användbart i stor skala.
Verkligheten i produktion
Vi ser ett antal återkommande mönster i faktiska produktionsmiljöer:
Mönster 1: Snäva uppgifter dominerar. Produktionsdrift lyckas med specifika, väldefinierade uppgifter. Inte ”gör vad som helst”. Inte ”använd vilken webbplats som helst”. Specifika arbetsflöden på specifika webbplatser.
Mönster 2: Tydlig avgränsning. Uppgifterna avgränsas strikt. Agenten får bara utföra vissa åtgärder på vissa webbplatser. Allt utanför omfattningen leder till stopp, inte improvisation.
Mönster 3: Inspelade arbetsflöden framför självständig utforskning. Många produktionslösningar använder inspelade arbetsflöden (steg som definieras en gång och spelas upp igen med justeringar) i stället för helt självständiga agenter. Det är tillförlitligare och enklare att underhålla.
Mönster 4: Mänsklig kontroll vid betydande konsekvenser. Varje åtgärd med betydande konsekvenser (ekonomiska, juridiska eller kundrelaterade) går igenom mänsklig granskning.
Mönster 5: Intensiv övervakning. Varje åtgärd loggas. Avvikelser identifieras. Nödstopp finns. Driftteamet bevakar instrumentpaneler.
Mönster 6: Kostnadsdisciplin. Ekonomin spelar roll. Många teoretiska lösningar där ”AI gör allt” går inte ihop jämfört med alternativ som människor eller RPA.
Mönster 7: Specialiserat framför generellt. Produktionslösningar använder oftast specialiserade modeller (eller specialiserade konfigurationer) i stället för generella datoranvändningsmodeller till allt.
De här mönstren motsvarar hur AI i produktion vanligtvis ser ut – snävare omfattning och starkare skyddsräcken än marknadsföringen antyder.
Där agenter för datoranvändning utmärker sig i produktion
Följande uppgiftskategorier lämpar sig väl för datoranvändning:
1. Datautvinning från webbplatser utan API:er
Många företagsverktyg, myndighetsportaler och mindre B2B-tjänster saknar API:er. Eller så har de API:er med betydande luckor. Agenter för datoranvändning kan utvinna data genom att använda gränssnittet.
Exempel från produktion:
- Hämta fakturor från fler än 50 leverantörsportaler.
- Utvinna ärendedata från domstolsväsendets webbplatser.
- Samla in priser från konkurrenters webbsidor.
- Sammanställa data från portaler för regelefterlevnadsrapportering.
När alternativet är en människa som utför enformiga klick är datoranvändning en tydlig vinst.
2. Formulärifyllning i stor skala
Skicka in samma typ av formulär till många olika webbplatser. Varje webbplats skiljer sig något; ett API vore idealiskt men finns inte.
Exempel:
- Myndighetsansökningar (varje myndighet har sin egen portal).
- Inrapportering för regelefterlevnad.
- Registrering av kunder i leverantörssystem.
- Kontokonfiguration för SaaS-verktyg.
3. Testning av användargränssnitt och kvalitetssäkring
Agenter för datoranvändning fungerar bra som kvalitetstestare. De kan navigera i program, prova användarflöden och rapportera problem.
Exempel:
- Heltäckande testning av webbappar.
- Visuell regressionstestning.
- Tillgänglighetsgranskningar.
- Validering av användarflöden på flera enheter.
Detta ligger nära RPA, men har AI:ns flexibilitet att hantera ändringar i användargränssnittet.
4. Arbetsflöden mellan program
Uppgifter som sträcker sig över flera program utan en gemensam integrationspunkt.
Exempel:
- Hämta data från ett CRM-system, formatera dem och överföra dem till ett analysverktyg.
- Ta emot kundsupportärenden, skapa uppgifter i ett projektverktyg och uppdatera status i ett CRM-system.
- Sammanställa rapporter från flera interna verktyg.
När du inte kan eller vill integrera programmen direkt fungerar en agent som en flexibel brygga.
5. Repetitiva processer med flera steg
Uppgifter som samma person utför om och om igen.
Exempel:
- Introducera nya kunder genom en process med 30 steg.
- Stämma av data mellan två system varje vecka.
- Skapa periodiska rapporter som kräver att data hämtas från flera källor.
Om en process är väldefinierad, upprepas ofta och i dag utförs av människor som klickar är den en kandidat.
Där de fortfarande misslyckas
Den andra sidan: uppgifter som agenter för datoranvändning ännu inte är redo att hantera i produktion.
1. Uppgifter som kräver omdöme
”Hitta en bra leverantör åt mig.” Agenter kan navigera på leverantörers webbplatser, men de kan inte bedöma vilken leverantör som passar just dina behov.
2. Uppgifter med nya gränssnittsmönster
En ny webbplats som agenten aldrig har sett. Agenter har svårt att förstå ovanliga gränssnittskonventioner. De fungerar bättre med vanliga mönster (formulär, listor och navigeringsmenyer) än med specialritad design.
3. Uppgifter med kraftfulla åtgärder mot botar
Många webbplatser identifierar och blockerar aktivt automatisering. Agenter kan ibland kringgå detta (med ansträngning), men det är en ständig katt-och-råtta-lek. Ofta är det inte mödan värt.
4. Enskilda åtgärder med hög insats
Skicka en betalning, underteckna ett juridiskt dokument eller publicera något offentligt för någon annans räkning. Konsekvenserna av en felaktig åtgärd är stora; mänsklig granskning är avgörande.
5. Uppgifter som kräver verklighetsförankrat sammanhang
Agenten ser bara det som visas på skärmen. Den känner inte till din relation till kunden, vad som nyligen har hänt i teamet eller den politiska situationen. Uppgifter med otillräckligt sammanhang misslyckas.
6. Öppen utforskning
”Hitta det bästa erbjudandet” eller ”gör en grundlig undersökning av den här personen” – uppgifter utan tydliga slutkriterier. Agenter fortsätter antingen planlöst eller slutar för tidigt.
Arkitekturen
Ett produktionssystem för datoranvändning har följande lager:
┌─────────────────────────────────────┐
│ Orkestrering │ Schemaläggning, omförsök, eskalering
├─────────────────────────────────────┤
│ Uppgiftsdefinition + avgränsning │ Vad agenten gör och inte gör
├─────────────────────────────────────┤
│ Agentkörmiljö (Computer Use SDK) │ Anthropic / OpenAI / Browserbase
├─────────────────────────────────────┤
│ Webbläsar-/skrivbordsmiljö │ Isolerad, i sandlåda
├─────────────────────────────────────┤
│ Autentisering och session │ Inloggningsuppgifter, kakor, MFA-hantering
├─────────────────────────────────────┤
│ Resultathantering │ Samla in, validera, lagra
├─────────────────────────────────────┤
│ Övervakning + aviseringar │ Observerbarhet i realtid
└─────────────────────────────────────┘
Vi går igenom varje lager.
Uppgiftsdefinition
Det enskilt viktigaste steget. Definiera snävt vad agenten ska göra.
En bra uppgiftsdefinition omfattar:
Utlösare. Vad startar uppgiften? (Schema, händelse, manuell start.)
Indata. Vilka data har agenten? (En specifik post, strukturerade formulärdata.)
Omfattning. Vilka webbplatser, vilka åtgärder och vilka vägar genom användargränssnittet.
Framgångskriterier. Hur ser ett slutfört resultat ut?
Stoppvillkor. Vad avslutar uppgiften i förtid?
Utdata. Vilka data returnerar agenten?
Felsemantik. Hur kategoriseras och rapporteras fel?
En dåligt definierad uppgift: ”Skicka in vår veckovisa regelefterlevnadsrapport.”
En väldefinierad uppgift:
Uppgift: Skicka in den veckovisa regelefterlevnadsrapporten till portal X.
Utlösare: Cron, varje måndag kl. 9.
Indata:
- Rapportdatafil (CSV) från /reports/weekly.csv
- Uppgifter om insändaren från miljövariabler (namn, ID).
- Inloggningsuppgifter från hemlighetshanteraren.
Omfattning:
- Webbplats: https://portal.example.gov/submit (och underordnade sökvägar)
- Tillåtna åtgärder: navigera, klicka, skriva, överföra, skicka, ta skärmbild.
- Förbjudet: besöka externa webbplatser, ändra kontoinställningar, lämna inskickningsflödet.
Framgångskriterier:
- Ta emot en bekräftelsesida med inskicknings-ID.
- Samla in inskicknings-ID.
Stoppvillkor:
- Bekräftelse mottagen: lyckat.
- CAPTCHA: eskalera till människa.
- Inloggningsfel: eskalera till människa.
- Formulärvalideringsfel: rapportera och stoppa.
- Tidsgräns 5 minuter: rapportera och stoppa.
Utdata:
- Inskicknings-ID.
- Skärmbild av bekräftelsesidan.
- Tidsstämpel.
Fel:
- Validering: logga, meddela ägaren, försök inte igen.
- Autentisering: logga, meddela driften, försök inte igen.
- Nätverk: försök igen en gång, eskalera sedan.
Så här detaljerat ser det ut i produktion. ”Skicka in rapporten” är så det ser ut i demonstrationer.
Tillämpning av avgränsning
Omfattningen är inte bara en beskrivning, utan tillämpas i körmiljön.
Tillåtelselista för URL:er. Agenten kan bara navigera till URL:er som matchar ett angivet mönster. Navigering utanför tillåtelselistan blockeras.
Åtgärdsfiltrering. Endast vissa åtgärdstyper är tillåtna. Ett generellt tillstånd att ”använda datorn” ersätts av specifikt tillåtna åtgärder.
Elementfiltrering. Vissa sidor innehåller element som agenten aldrig ska interagera med (inställningar, utloggning, farliga knappar). Dessa kan filtreras bort från perceptionslagret.
Tidsgränser. Uppgifterna har fasta maximitider. Avbryt om uppgiften inte är klar inom N minuter.
Steggränser. Uppgifterna har ett maximalt antal steg. Samma princip som för agentslingor.
Implementeringen varierar mellan plattformar – Anthropic Computer Use, OpenAI Operator och Browserbase har alla olika mekanismer. Principen är universell: tillämpa avgränsningen i körmiljön, beskriv den inte bara i prompten.
Autentisering
En ständig utmaning. Produktionslösningar måste autentisera agentens session.
Förautentiserade sessioner. En människa loggar in en gång; sessionskakor och token samlas in; agenten arbetar i den sessionen. De förnyas vid behov.
Tjänstekonton. Särskilda konton för agenten (där webbplatsen stöder dem). Avgränsade behörigheter, revisionsloggning.
Inmatning av inloggningsuppgifter. Agenten får inloggningsuppgifter vid körning, använder dem för att logga in och raderar dem sedan. Säker lagring och hantering krävs.
MFA-hantering. En verklig utmaning. Alternativ:
- Använd TOTP-hemligheter som agenten kan beräkna.
- Skicka MFA till en människa för godkännande.
- Använd konton eller webbplatser som tillåter API-token i stället för MFA.
OAuth. För moderna webbplatser fungerar OAuth-flöden bra – agenten får en token från ett flöde som människan godkänner en gång.
Mönstret: agenter ska aldrig ha människoliknande åtkomst till dina konton. De ska ha avgränsade, granskningsbara och återkallbara inloggningsuppgifter.
Resultatvalidering
Validera när agenten uppger att uppgiften lyckades.
Samla in artefakter. Skärmbilder, nedladdade filer och utdata. Lita inte på agentens rapport; kontrollera underlaget.
Verifiera framgångskriterier. Skickades formuläret faktiskt in? Finns det en bekräftelse? Var uppgifterna korrekta?
Korskontrollera. Om du kan verifiera resultatet genom en annan kanal (ett API, en e-postbekräftelse eller en databaskontroll), gör det.
Avvikelseidentifiering. Tog körningen ovanligt lång eller kort tid, eller kostade den ovanligt mycket? Undersök avvikande värden.
Mönstret: utgå från att agenten kan ha fel. Använd verifiering som är oberoende av agentens egen rapport.
Felhantering
Uppgifter som utförs genom datoranvändning kan misslyckas på många sätt. Kategorisera och hantera vart och ett:
Nätverksfel. Webbplatsen är nere, tidsgränsen överskrids. Försök igen med exponentiell fördröjning.
Autentiseringsfel. Inloggningen misslyckades, sessionen har löpt ut. Förnya inloggningsuppgifterna eller eskalera.
Ändringar i användargränssnittet. Webbplatsen har ändrats; ett förväntat element hittades inte. Stoppa och meddela underhållsansvarig.
Valideringsfel. Formulärindata avvisades. Logga, meddela och försök inte blint igen.
Identifiering som bot. CAPTCHA-kontroller, blockeringar. Eskalera; överväg att svartlista webbplatsen.
Agentförvirring. Agenten fastnar, loopar eller avviker från instruktionerna. Stoppa, logga och undersök.
Kvot/hastighetsgräns. Webbplatsen har hastighetsbegränsat agenten. Vänta och försök igen, eller schemalägg till senare.
Varje kategori har olika hanteringsregler. Dåligt mönster: ”agenten misslyckades, försök igen”. Bra mönster: ”agenten misslyckades i kategori X, följ rutin X”.
Övervakning
Varje åtgärd loggas, varje körning följs upp och varje avvikelse synliggörs.
Loggar per körning:
- Start- och sluttidsstämplar.
- Alla utförda åtgärder.
- Alla skärmbilder.
- Resultat (lyckat/misslyckat/eskalerat).
- Kostnad.
- Prestandamått.
Instrumentpanel per körning: Driftteamet kan se aktiva körningar, senaste fel och ködjup.
Aggregerade mått:
- Framgångsfrekvens per uppgiftstyp.
- Latensfördelning.
- Kostnad per körning.
- Avvikelsefrekvens.
Aviseringar:
- Framgångsfrekvensen faller under tröskelvärdet.
- Kostnaden per körning ökar kraftigt.
- Vissa feltyper blir vanligare.
- Webbplatsens användargränssnitt kan ha ändrats (flera nya fel i samma steg).
Den här övervakningen fångar upp problem innan de blir incidenter.
Ekonomin
Den raka frågan: är datoranvändning billigare än alternativet?
Kostnader:
- Kostnad per körning: vanligtvis €0,50–€5 beroende på uppgiftens komplexitet (anrop till bildmodeller är dyra).
- Infrastruktur: hanterad körmiljö (Browserbase eller liknande) eller egen drift.
- Underhåll: uppgifter slutar fungera när webbplatser ändras. Visst löpande arbete krävs.
Alternativ:
- En människa för €30/timme: en uppgift på 10 minuter kostar €5. En uppgift på 1 minut kostar €0,50.
- RPA-verktyg: lägre kostnad per körning men kräver strukturerad automatisering.
- Direkt API-integration: mycket billigare per anrop, men förutsätter att ett API finns.
- Utkontraktering till lågkostnadsländer: €5–10/timme, med en kalkyl som liknar den för intern personal.
Ekonomin talar för datoranvändning när:
- Webbplatsen saknar API.
- Uppgiften är tillräckligt lång för att automatiseringen ska täcka de fasta kostnaderna.
- Volymen är tillräckligt hög för att människornas tidsåtgång ska bli betydande.
- Webbplatsen är relativt stabil (låg underhållsbörda).
Ekonomin talar inte för datoranvändning när:
- Det finns ett API (använd det).
- Uppgiften är kort och sällan förekommande.
- Webbplatsen ändras ständigt.
- Uppgiften har för många specialfall (stort underhållsbehov).
En användbar övning: uppskatta kostnaden per uppgift med datoranvändning respektive en människa. Multiplicera med volymen. Jämför.
Produktionsmönster som fungerar
Några mönster från framgångsrika produktionslösningar:
Mönster 1: Metoden med ett ”inspelat recept”
För snäva uppgifter med hög volym: spela in arbetsflödet en gång med explicita steg och låt sedan agenten upprepa det för varje indata med mindre justeringar.
Det här ligger närmare traditionell RPA, men har AI:ns flexibilitet att hantera mindre variationer (till exempel att en knapp har flyttats något eller att en extra bekräftelsedialog visas).
Betydligt tillförlitligare än helt självständig användning.
Mönster 2: Uppdelning i ”hämta och skicka”
Många arbetsflöden består av två faser:
- Hämta data någonstans ifrån.
- Skicka data någonstans.
Det blir renare att dela upp dessa i separata agentkörningar (eller recept). Varje fas får tydligare framgångskriterier. Fel i den ena förvärrar inte fel i den andra.
Mönster 3: Mänsklig kontrollpunkt
Agenten utför förberedelserna självständigt och visar sedan statusen ”klar för åtgärd” för mänskligt godkännande. En människa granskar och godkänner, varefter agenten utför åtgärden.
Används för betalningar, offentliga inlägg och känsliga inskick. Agenten sparar tid på förberedelserna; människan fångar upp fel.
Mönster 4: Specialistagent
Använd specialiserade agenter för specifika uppgifter i stället för en generell agent. Var och en är anpassad, testad och underhållen för sitt specifika arbetsflöde.
En generell agent som ska ”använda vilken webbplats som helst” är svår att underhålla. En agent som ska ”skicka in vår veckovisa regelefterlevnadsrapport” är okomplicerad.
Mönster 5: Reservlösning med RPA
För uppgifter där AI-flexibilitet egentligen inte behövs (webbplatsen är stabil och arbetsflödet är fast) kan du använda traditionell RPA (Playwright-skript, Selenium) som reservlösning. Det är billigare, snabbare och tillförlitligare i dessa fall.
Använd datoranvändning specifikt där AI:ns flexibilitet skapar värde.
Mönster 6: Satsvis körning
Kör inte agenter på begäran för uppgifter med hög volym. Samla arbetet i satser och kör agenter parallellt enligt ett schema.
Exempel: i stället för ”användaren skickar en begäran, agenten kör direkt” köar du begäranden och kör agenterna i 15-minuterssatser. Det jämnar ut belastningen och förenklar arkitekturen.
Vad som kan gå fel
En kort lista över vanliga fellägen:
Webbplatsen ändrades. Agenten fungerade perfekt i 6 månader. En omdesign av webbplatsen förstör allt. Utan övervakning får du veta det från arga användare.
Botidentifieringen hann ikapp. Webbplatsen införde botidentifiering. Agentkörningar misslyckas allt oftare. Till slut spärras kontot.
Kostnadsspiral för en uppgift som fastnat. Agenten loopar på en förvirrande sida. Varje varv innebär ett anrop till en bildmodell. €100 på en timme.
Fel åtgärd utfördes. Agenten klickade på fel knapp. Den avbröt en beställning i stället för att bekräfta den. Eller skickade ett meddelande till fel person.
Fastnade vid MFA. Agenten kommer inte förbi MFA. Produktionskörningar hopar sig. Kön växer.
Kontot spärrades. Webbplatsen upptäckte ovanlig aktivitet och stängde av kontot. Alla liknande uppgifter ligger nere tills kontot återställs.
Läckta inloggningsuppgifter. Agenten råkade exponera inloggningsuppgifter i en logg eller skärmbild. Säkerhetsincident.
Integritetsproblem. Agenten råkade samla in personuppgifter i skärmbilder som loggades.
De flesta av dessa problem kan förebyggas med mönstren ovan. Men vart och ett har inträffat i verkliga produktionsmiljöer. Bygg försvar därefter.
Ekonomin: en genomarbetad modell
Det här är ett modellerat scenario, inte ett kundfall, och vi betecknar det avsiktligt så: en ROI-modell som du kan köra om med dina egna siffror är bättre än ett ”anonymiserat fall” som du inte kan verifiera.
Uppgift: skicka återkommande regelefterlevnadsrapporter till 12 olika myndighetsportaler. I Estland kan du tänka på de portaler som fortfarande kräver manuell inmatning, formulär för formulär: deklarationer till e-MTA, enkäter från Statistik Estland och inrapportering på EU-nivå.
Manuell utgångspunkt: 12 portaler × 90 minuter = 18 timmar/vecka. Med en total arbetskostnad på €30/timme blir det €540/vecka.
Automatiserat:
- Agentkörningar: 12 × ~€2 (bildmodell + webbläsarinfrastruktur) = €24/vecka.
- Underhåll: ~2 utvecklartimmar/månad à €100 ≈ €50/vecka. Portaler ändras; budgetera för detta, annars slutar automatiseringen att fungera utan att någon märker det.
- Felhantering: med 92 % självständig framgångsfrekvens eskaleras ungefär en körning i veckan till en människa. Räkna med 30 minuters granskning: €15/vecka.
- Totalt: ~€90/vecka, vilket sparar ~€450/vecka ≈ €23 000/år.
Nu till de två siffror som avgör om något av detta är verkligt.
Först framgångsfrekvensen. Under cirka 85 % äter den mänskliga övervakningen upp besparingen. Mät den under en två veckor lång skuggperiod innan du litar på den; hämta den inte från en leverantörspresentation.
Sedan underhållsdriften. Varje omdesign av en portal orsakar ett avbrott, och i en miljö med 12 portaler inträffar flera sådana per år. Om du inte kan namnge den person som ansvarar för att åtgärda dem inom en arbetsdag var den manuella processen billigare.
Checklista för driftsättning
Om du driftsätter ett system för datoranvändning i produktion:
- Uppgiften är snäv och väldefinierad.
- Omfattningen tillämpas i körmiljön, inte bara beskrivs.
- Det finns budgetar för steg, tid och kostnad.
- Det finns en autentiseringsstrategi med säkra inloggningsuppgifter.
- Hänsyn tas till åtgärder mot botar (använd legitima konton; respektera hastighetsbegränsningar).
- Fel kategoriseras och hanteras.
- Resultatet valideras oberoende av agentens egen rapport.
- Det finns övervakning och aviseringar.
- Det finns nödstopp.
- En människa är med i loopen för åtgärder med betydande konsekvenser.
- Det finns revisionsloggning.
- Integritet och personuppgifter hanteras.
- Kostnadskalkylen är rimlig jämfört med alternativen.
- Det finns en underhållsplan för när webbplatser ändras.
Varje punkt är icke-trivial. Att hoppa över någon av dem skapar en risk.
Matcha tekniken med uppgiften
Datoranvändning och webbläsaragenter i produktion ser annorlunda ut än de virala demonstrationerna. Snäva uppgifter. Starka skyddsräcken. Omfattande övervakning. Mänskliga kontrollpunkter. Realistisk ekonomi.
För rätt uppgifter är de genuint användbara. Datautvinning från webbplatser utan API:er, formulärifyllning i stor skala, arbetsflöden mellan program och repetitivt arbete i användargränssnitt. Verkliga produktionslösningar sparar verklig tid och verkliga pengar.
För fel uppgifter – öppna bedömningar, nya användargränssnitt och enskilda åtgärder med hög insats – är de ännu inte redo. Försök inte tvinga dem.
Det viktiga är att matcha tekniken med uppgiften. Rätt utfört är agenter för datoranvändning ett användbart verktyg i produktionsstacken för AI. Fel utfört är de ett dyrt sätt att införa nya fellägen.
Välj snäva uppgifter. Bygg skyddsräckena. Övervaka obevekligt. Underhåll konsekvent. Så förtjänar agenter för datoranvändning sin plats i produktionssystem.
