AGENTISKA WEBBLÄSARE PÅ JOBBET: STYRNING, BEHÖRIGHET OCH ANSVAR NÄR AI:N KLICKAR SIG FRAM
Microsofts agentiska surfning i Edge for Business och Perplexity Comet kan navigera på webbplatser, fylla i uppgifter och utföra arbetsflöden åt en medarbetare. Det är ett annat styrningsproblem än en internbyggd AI-agent med en admin-godkänd koppling. Vilka sajter och konton verktyget når beror på produktens aktuella kontroller och på hur organisationen har konfigurerat dem. Den här artikeln ger en praktisk checklista för behörighet, spårbarhet, godkännandegrindar och de första stegen när verktyget klickar eller skickar fel.
AI-förordningen gäller stegvis
Artikel 50:s transparensregler tillämpas sedan 2 augusti 2026. Leverantörer ansvarar bland annat för information vid direkt AI-interaktion och maskinläsbar märkning av syntetiskt innehåll. Tillhandahållare ansvarar bland annat för information vid känsloigenkänning och biometrisk kategorisering samt för upplysning om deepfakes och viss text om frågor av allmänt intresse. Undantagen i artikeln måste bedömas i det konkreta fallet.
För system som fanns på marknaden före 2 augusti 2026 har endast leverantörskravet i artikel 50.2 övergång till 2 december 2026. Kapitel III avsnitt 1–3 tillämpas från 2 december 2027 för högrisksystem enligt artikel 6.2 och bilaga III och från 2 augusti 2028 för system enligt artikel 6.1 och bilaga I.
Använd EUR-Lex konsoliderade lydelse per 27 juli 2026 för dagens regler. Läs ändringsförordning (EU) 2026/1744 när du behöver se vad Digital Omnibus ändrade.
Vad den här artikeln är till för
Artikeln är skriven för chefer, IT-ansvariga och andra med ett styrningsansvar på en svensk arbetsplats där medarbetare använder eller överväger ett färdigt agentiskt webbläsarverktyg — inte ett internbyggt system, utan exempelvis Microsofts agentiska surfning i Edge for Business eller Perplexity Comet. Texten bygger på leverantörernas egen produktdokumentation, kontrollerad 2026-09-19, samt gällande svensk och europeisk rätt. Produktfunktioner och tillgänglighet ändras snabbt: kontrollera alltid den aktuella inställningen och regionstillgången i er egen tjänst innan ni fattar beslut.
Skillnaden mot en agent ni redan har styrning kring
Vår genomgång av AI-agentens behörigheter handlar om en agent som ansluts till namngivna system — mejl, filer, en kanal — genom en koppling en administratör har godkänt och kan begränsa till en mapp, ett konto eller en åtgärd. En agentisk webbläsare fungerar tvärtom: den öppnar sajter på den öppna webben och kan där logga in med de konton medarbetaren redan har, fylla i formulär och klicka på knappar, ungefär som medarbetaren själv skulle gjort. Vilka system den når bestäms alltså inte av en administratörs koppling, utan av vilka tjänster medarbetaren råkar vara inloggad på i webbläsaren den dagen — leverantörssystem, kundportaler, myndighetstjänster, bankkonton.
Det gör frågan om behörighet, spårbarhet och godkännande till ett delvis nytt problem, även om er organisation redan har en policy för internbyggda agenter. En policy skriven för "vår agent som läser SharePoint" täcker sällan "medarbetarens webbläsare som nu kan handla åt henne på leverantörens webbplats".
Två aktuella produkter — och en avvecklad
Det är lätt att anta att "en agentisk webbläsare" är en enhetlig kategori med samma riskprofil. Så är det inte. Utifrån leverantörernas egen dokumentation, kontrollerad 2026-09-19:
- Microsofts agentiska surfning med Copilot i Edge for Business är i begränsad förhandsvisning. IT kan styra var funktionen får köras genom policy och godkända sajter. Copilot pausar när lösenord eller kortnummer ska anges, och Microsoft uppger att Purviews dataskyddspolicyer fortsätter att gälla under körningen. Förhandsvisningen är enligt Microsoft inte tillgänglig inom Europeiska ekonomiska samarbetsområdet (EES), vilket omfattar Sverige.
- Perplexity Comet Enterprise låter administratörer blockera domäner, kräva webbläsargodkännanden och begränsa vilka uppgifter agenten får utföra. Perplexity uppger också att produkten har inbyggd telemetri och granskningsloggar. Kontrollera vilka loggfunktioner som ingår i er plan innan ni gör dem till en del av incidentrutinen.
- OpenAI Atlas är avvecklat. Produkten slutade stödjas den 9 augusti 2026, och OpenAI flyttade webbläsarbaserat agentarbete till ChatGPT och Codex. Atlas tidigare säkerhetsgränser ska därför inte användas som underlag för ett nytt införandebeslut. Kontrollera dokumentationen för den ChatGPT- eller Codex-funktion ni faktiskt använder.
Slutsatsen är inte att en produkt är "säkrast". Slutsatsen är att ni måste fråga varje leverantör konkret om agenten återanvänder medarbetarens befintliga inloggade sessioner eller arbetar i en isolerad, allowlist-styrd kontext — och verifiera svaret i produktens egen adminkonsol, inte bara i marknadsmaterialet.
Bestäm vilket konto agenten faktiskt agerar som
Innan en agentisk webbläsare släpps in i en verklig arbetsuppgift, avgör konkret: agerar den under medarbetarens vanliga, privilegierade konto — med samma åtkomst medarbetaren byggt upp under flera år — eller under en avgränsad identitet skapad för uppgiften? Ett exempel: en agent ombeds beställa kontorsmaterial hos en leverantör. Om agenten återanvänder medarbetarens vanliga inloggning kan den, beroende på produkt, hamna på fel leverantörssida, logga in med samma konto som används för större inköp, och skicka en beställning ingen hunnit se. Om produkten i stället kräver en separat, avgränsad inloggning för agentuppgifter blir felet lättare att begränsa och lättare att stänga av.
Prov ni kan göra: be IT eller leverantören visa exakt var i adminkonsolen ni ser och begränsar vilka sajter eller kontotyper agenten får arbeta mot. Finns ingen sådan begränsning, eller finns bara en allmän på/av-knapp för hela verktyget, är det ett observandum värt att skriva ner innan piloten går vidare — inte ett skäl att avbryta automatiskt, men ett skäl att sätta en snävare uppgift och en kortare pilotperiod.
Anta inte att er befintliga loggning redan täcker verktyget
Det vanligaste antagandet är att en agentisk webbläsare, precis som andra företagsverktyg, automatiskt syns i organisationens vanliga efterlevnadsloggar — Compliance API, SIEM, eDiscovery. Det går inte att anta. OpenAI dokumenterade exempelvis att det numera avvecklade Atlas inte skickade loggar till Compliance API och saknade SIEM- och eDiscovery-integration. Perplexity uppger däremot att Comet Enterprise har telemetri och granskningsloggar. Produktnamnet säger alltså inget säkert om vilken spårbarhet ni faktiskt får.
Prov ni kan göra redan idag: be IT hämta en enda loggpost för en agentisk webbläsaråtgärd som utfördes igår — vilken sajt, vilket klockslag, vilken åtgärd — och kontrollera om den syns i organisationens ordinarie säkerhetsloggning. Går det inte att hitta posten har ni ett spårbarhetsglapp nu, medan det går att åtgärda, i stället för mitt i en incident. Kontrollera detta direkt i er egen miljö; en generell produktsida visar inte vilka loggfunktioner som är aktiverade i just er plan och konfiguration.
Leverantörens paus är inte er organisations definition av känsligt
Microsoft uppger att Copilot pausar när lösenord eller kortnummer ska anges. Comet Enterprise erbjuder enligt Perplexity webbläsargodkännanden och begränsningar av agentuppgifter. Det är bra som grundskydd, men det är produktens och administratörens konfiguration av känsligt — inte automatiskt er organisations fullständiga lista. En agent som får i uppdrag att "svara på kundens reklamation" eller "acceptera leverantörens nya villkor" kan fortfarande vara en åtgärd ni vill att en människa ser innan den sker.
Definiera därför själva, innan piloten startar, en kort lista över åtgärder som alltid ska kräva ett uttryckligt mänskligt godkännandeklick oavsett vad produkten själv pausar för: att skicka något till en kund eller motpart, att acceptera villkor eller ett avtal, att göra en betalning eller beställning över ett belopp ni bestämmer, och att ändra behörigheter eller kontouppgifter. Provet: ge agenten en avsiktligt tvetydig instruktion, till exempel just "svara på kundens reklamation", och observera om den stannar för godkännande eller skickar direkt. Gör det innan en verklig kund är inblandad, inte första gången det händer på riktigt.
När webbläsaren klickade eller skickade fel
Vår generella första-timmen-checklista för AI-incidenter gäller även här: stoppa, dokumentera fakta i stället för antagen orsak, och bedöm om det är en personuppgiftsincident. En agentisk webbläsare har två egenheter som gör att den generella listan behöver kompletteras:
- Stäng agentsessionen direkt — stoppa den aktiva körningen och stäng av agentfunktionen för medarbetaren enligt den aktuella produktens administratörsrutin, inte bara webbläsarfliken. Kontrollera samtidigt om inloggade sessioner eller autentiseringsuppgifter bör återkallas, särskilt om felet kan bero på att en manipulerad webbsida försökt styra agenten genom promptinjektion.
- Räkna med att motparten är extern. Till skillnad från en agent som bara arbetar i era egna system kan en agentisk webbläsares fel synas hos en tredje part — en leverantörs orderformulär, en kundportal, en myndighetstjänst. Första timmen behöver därför inkludera bedömningen om ni behöver kontakta den externa parten, inte bara frysa era interna flöden.
Hämta därefter agentens egen körlogg om den finns (se föregående avsnitt), dokumentera i er AI-beslutslogg vad som hände och vem som fattade nästa beslut, och följ 72-timmarsbedömningen för personuppgiftsincidenter enligt IMY:s vägledning om ärendet gäller personuppgifter.
Samma ansvarsprincip som för andra AI-agenter — inte en ny lag
AI-förordningen skiljer på leverantör och tillhandahållare; en arbetsgivare som sätter en agentisk webbläsare i arbete är normalt tillhandahållare av verktyget. Tillhandahållarens särskilda skyldigheter enligt artikel 26 — bland annat mänsklig tillsyn och sexmånaders loggbevarande — gäller uttryckligen AI-system som är klassade som högrisk, och ingen av produkterna i den här artikeln är generellt klassad som ett högriskssystem enligt AI-förordningen; en konkret klassificering beror på det faktiska användningsfallet och är inte gjord här.
Skadeståndslagen ger inte en enda regel för alla ekonomiska följder av ett felklick. Enligt 3 kap. 1 § svarar arbetsgivaren för person- och sakskada som en arbetstagare vållar genom fel eller försummelse i tjänsten, medan ren förmögenhetsskada enligt samma paragraf förutsätter brott. Avtalskrav och det allmännas ansvar följer andra regler. Se Vem bär ansvaret när AI-agenten gör fel på jobbet? för den fullständiga genomgången.
En sista punkt: sökningar hos IMY och PTS den 19 september 2026 gav ingen särskild vägledning om transparens för agentiska webbläsare. Det ska inte tolkas som att ingen reglering gäller — AI-förordningens generella regler och GDPR gäller redan — utan bara att det inte finns någon särskild, riktad webbläsarvägledning att luta sig mot. Kontrollera imy.se och pts.se på nytt inför ett större beslut.
Checklista att gå igenom före en pilot
Vanliga frågor om agentiska webbläsare på jobbet
Är en agentisk webbläsare samma sak som en intern AI-agent?
Nej. En internbyggd agent kopplas normalt till namngivna system genom admin-styrda integrationer med avgränsade rättigheter. En agentisk webbläsare arbetar i stället i medarbetarens vanliga webbläsare och kan agera på hela den öppna webben under de konton medarbetaren råkar vara inloggad på, om produkten inte uttryckligen är begränsad till en godkänd lista av sajter.
Loggar alla agentiska webbläsare vad de gjort?
Nej, inte lika. Produkterna skiljer sig åt i om agentaktivitet skickas till organisationens vanliga efterlevnadsloggar (till exempel Compliance API, SIEM eller eDiscovery). Kontrollera varje produkts egen dokumentation i stället för att anta att befintlig loggning täcker den nya funktionen.
Räcker vendor-produktens inbyggda godkännandepaus?
Inte automatiskt. Leverantörernas inbyggda pauser (till exempel vid lösenord eller kortnummer) speglar leverantörens definition av känsligt, inte nödvändigtvis er organisations. Definiera egna åtgärder som alltid kräver mänskligt godkännande innan piloten startar.
Vem bär ansvaret om den agentiska webbläsaren skickar eller beställer fel?
Det beror på vilken skada och vilket rättsförhållande det gäller. Enligt 3 kap. 1 § skadeståndslagen svarar arbetsgivaren för person- och sakskada som arbetstagaren vållar genom fel eller försummelse i tjänsten; ren förmögenhetsskada enligt samma paragraf förutsätter brott. Avtalskrav bedöms enligt andra regler. Se vår fördjupning om ansvarsfrågan för en fullständig genomgång.
Källor och vidare läsning
- OpenAI: Introducing ChatGPT Atlas (öppnas i ny flik)
- OpenAI Help Center: Evolving Atlas into ChatGPT for browser-based agentic work (öppnas i ny flik)
- Microsoft Edge Blog: New in Edge for Business — AI for work, safe from day one, 20 maj 2026 (öppnas i ny flik)
- Perplexity: Comet Enterprise — kontroller, telemetri och granskningsloggar (öppnas i ny flik)
- IMY: Hantering av personuppgiftsincidenter (öppnas i ny flik)
- PTS: AI-förordningen (kontrollerad 2026-09-19) (öppnas i ny flik)
- Sveriges riksdag: Skadeståndslag (1972:207), 3 kap. och 4 kap. (öppnas i ny flik)
- AI-agentens behörigheter: skydda mejl och filer
- Vem bär ansvaret när AI-agenten gör fel på jobbet?
- AI-incident: första timmens checklista på jobbet