System för datoranvändning tolkar skärmbilder eller tillgänglighetstillstånd och utför åtgärder i gränssnittet. Produktnamn och ytor förändras snabbt: OpenAI:s fristående Operator integrerades i ChatGPT agent under 2025, och OpenAI:s aktuella hjälpdokumentation hänvisar nu längre uppgifter till ChatGPT Work. Verifiera den aktuella ytan innan du publicerar installationsanvisningar.
De här systemen kan slutföra vissa gränssnittsuppgifter och misslyckas med andra. Artikeln är en granskning av dokumentation och hotmodell – inte ett bevis för att en viss leverantör, webbplats eller ett visst arbetsflöde når ditt framgångsmål. OpenAI:s ursprungliga tillkännagivande av Operator beskrev uttryckligen begränsningar, och den aktuella hjälpsidan för agenten visar varför produktanvisningar måste verifieras på nytt.
Vi behandlade grunderna i artikeln om webbläsaragenter och datoranvändning. Här går vi djupare: kriterier för produktionsmognad, fellägen och ett underlag för enhetsekonomin.
Verkligheten i produktion
Använd följande som designhypoteser att testa i en skuggdriftsättning:
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: Jämför inspelade arbetsflöden med självständig utforskning. Steg som definieras en gång och spelas upp med justeringar är enklare att resonera om, men tillförlitligheten måste ändå mätas mot de gränssnittsvarianter du riktar dig mot.
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.
Tillsammans utgör mönstren en konservativ kandidatarkitektur att pröva i ett skuggtest.
Kandidatarbetslaster för datoranvändning
Följande kategorier kan motivera ett experiment när ett API-stöd saknas. De är inget bevis för att datoranvändning är rätt verktyg:
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.
Tänkbara exempel:
- 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.
Jämför med en API-integration, deterministisk webbläsarautomation och den nuvarande manuella processen. Datoranvändning vinner bara om uppmätt kvalitet, risk, underhåll och kostnad är godtagbara.
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 kräver särskilt starka belägg innan de får användas 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
En produktionskandidat bör ha 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 att mäta: modellens in- och utdata, skärmbilder, webbläsarens körtid, proxyer, lagring, omförsök, misslyckade körningar, mänsklig granskning, incidenthantering och ingenjörsunderhåll.
Alternativ:
- Manuell process: använd organisationens fullt belastade rollkostnad och uppmätt handläggningstid.
- 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.
- Utkontrakterad process: använd faktisk avtalskostnad, kvalitet, ledtid och integritetsbegränsningar.
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
Mönster att utvärdera:
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).
Jämför tillförlitligheten mot självständig utforskning på samma testfall – utgå inte från att det inspelade receptet vinner i varje variant.
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. En omdesign kan göra selektorer, visuella antaganden eller inspelade steg ogiltiga. Upptäck det med kanariekörningar innan agenten kör mot kunder.
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 och fortsätter göra debiterade modell- eller webbläsaranrop. Tillämpa externa gränser för steg, tid och kostnad.
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.
Kontrollerna ovan minskar risken, men de gör inte varje fel möjligt att förebygga. Testa varje felläge och håll en namngiven ansvarig för återställningen.
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å.
Posterna nedan visar formeln – de är inte belägg om estniska portaler eller EU-portaler.
Manuell utgångspunkt: portaler × uppmätt handläggningstid × fullt belastad arbetskostnad.
Automatiserat:
- Lyckade körningar: volym × uppmätt kostnad per lyckad körning.
- Misslyckade körningar: volym × andel fel × sammanlagd kostnad för körning och återställning.
- Mänsklig granskning: granskad volym × granskningstid × arbetskostnad.
- Underhåll och incidenter: registrerad ingenjörs- och drifttid.
- Efterlevnad och leverantörskostnad: säkerhetsgranskning, datahantering, webbläsarinfrastruktur och avtalsåtaganden.
Nu till de två siffror som avgör om något av detta är verkligt.
Först framgångsfrekvensen och felens allvarlighetsgrad. Härled den godtagbara tröskeln ur den manuella utgångspunkten och er risktolerans – det finns ingen universell nollpunktsprocent. Mät den under en representativ skuggperiod.
Sedan underhållsdriften. Följ hur ofta målgränssnitten ändras och hur lång tid återställningen tar. Utse en ansvarig och sätt ett servicemål innan du förlitar dig på automatiseringen.
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
Produktionsmognad kräver snäva uppgifter, skyddsräcken i körmiljön, övervakning, mänskliga kontrollpunkter och uppmätt ekonomi.
Tänkbara uppgifter är datautvinning från webbplatser utan API:er, repetitiv formulärifyllning och arbetsflöden mellan program. Ett representativt skuggtest måste fastställa om systemet sparar tid eller pengar utan att öka fel eller risk.
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.
Ingenjörsarbetet består i att matcha tekniken med uppgiften och att behålla en deterministisk eller mänsklig reservlösning. Befordran till produktion bör bero på acceptansunderlag, inte på en demonstration.
