När AI får flera inkorgar: skilj kontextkonto från handlingskonto

När AI får flera inkorgar: skilj kontextkonto från handlingskonto

Det farliga ögonblicket är inte när AI läser en kalender. Det är när den blandar ihop vilken kalender den läste, vilket konto den svarar från och om svaret borde ha varit ett utkast.

Det här har blivit mer än en teoretisk risk. Manus har lagt till stöd för flera Gmail- och Google Calendar-konton i samma uppgift och i schemalagda jobb. ChatGPT kan, för användare med ansluten Gmail eller Outlook, både skriva och skicka mejl från chatten. OpenAI låter arbetsytans administratörer styra när ChatGPT ska fråga före åtgärder i anslutna appar. Claude visar samtidigt hur AI-kopplingar börjar få egen driftuppföljning, och Mistrals publika dokumentation visar beta-slutpunkter för MCP-kopplingar.

Källa: Manus, Connect Multiple Gmail and Google Calendar Accounts on Manus

Källa: OpenAI, ChatGPT release notes

Källa: OpenAI, ChatGPT Enterprise & Edu release notes

Poängen är enkel: när AI börjar jobba i riktiga konton räcker det inte att fråga "fungerar integrationen?". Frågan blir: vilket konto får AI läsa, vilket konto får den agera från och vem ser vad som hände?

Två kontotyper som bör hållas isär

Ett kontextkonto är ett konto AI får läsa från för att förstå läget. Det kan vara en inkorg, kalender, projektmapp eller CRM-vy. Läsning kan fortfarande vara känslig, men den ändrar inget utanför systemet.

Ett handlingskonto är kontot AI använder när den gör något som någon annan märker. Den skickar ett mejl, skapar en kalenderbokning, uppdaterar ett ärende, delar en fil eller ändrar en rad i ett system.

Samma människa kan äga båda kontotyperna. Reglerna ska ändå vara olika.

Exempel från vardagen:

• AI får läsa "Work Gmail" och "Privat kalender" för att hitta ledig tid.
• Den får bara skapa ett utkast från "Work Gmail".
• Privatkontot får aldrig användas för att skicka.
• En kundbokning stoppas om kalendern innehåller en konflikt, en otydlig tidszon eller fler än ett möjligt mötesrum.

Det låter petigt. I praktiken är det där förtroendet byggs.

Nyheterna bakom principen

Manus beskriver det som att användaren kan ta in rätt inboxar och kalendrar i uppgiften och sedan välja vilket konto Manus ska agera från. Det är en bra produktfunktion, men också en bra styrmodell: läs brett när det behövs, agera smalt när det får konsekvenser.

OpenAI:s nya app permissions för Enterprise och Edu går åt samma håll. Administratörer kan välja om ChatGPT alltid ska fråga, fråga vid ändringar eller fråga vid "Important actions". OpenAI beskriver standardläget som att systemet kan läsa mer automatiskt men frågar före åtgärder som kan få effekt utanför ChatGPT, dela känslig information eller vara svåra att ångra.

Källa: OpenAI, ChatGPT Enterprise & Edu release notes

Claude-delen är en annan bit av samma pussel. Anthropic har lanserat en dashboard i public beta för publicerade AI-kopplingar där ägare kan se aktiva användare, verktygsanrop, fel, latens och användning över Claude, Claude Code och andra ytor. Det är inte ett allmänt analys-API. Det är ändå ett tecken på att AI-kopplingar börjar behandlas som små produkter som behöver ägare och driftuppföljning.

Källa: Claude, Connector Observability and In-App Directory Submission

Mistrals beta-dokumentation för AI-kopplingar pekar åt samma håll från API-sidan. MCP, Model Context Protocol, är en standard för att koppla AI-system till verktyg och datakällor. Mistrals publika dokumentation visar slutpunkter för att skapa AI-kopplingar, lista verktyg, hämta OAuth-URL:er, anropa verktyg och hantera inloggningsuppgifter för organisationer, arbetsytor och användare. Det betyder inte att varje kund ska börja bygga egna kopplingar imorgon. Det betyder att gränserna runt kopplingarna blir en affärsfråga, inte bara en teknisk inställning.

Källa: Mistral, beta connectors API reference

Fem regler innan AI får skicka eller boka

1. Döp kontona som människor faktiskt förstår

Skriv inte bara "Gmail 1" och "Calendar 2" i instruktioner. Använd namn som en kollega kan granska: "Work Gmail", "Kund A-inkorg", "Skoladministration kalender" eller "Privat kalender, läsning endast". För schemalagda jobb är namnen ännu viktigare, eftersom ingen sitter där och rättar prompten varje måndag morgon.

2. Börja med utkastläge

För mejl, kunduppföljning, elev- eller föräldrakontakt, avtal, fakturapåminnelser och personalplanering bör första versionen vara ett utkast. Inte för att AI är värdelös. För att konsekvensen av fel avsändare eller fel mottagare är onödigt dyr.

3. Skriv en läsregel och en handlingsregel separat

En bra instruktion kan se ut så här:

Läs Work Gmail, Kund A-inkorgen och Projektkalendern. Sammanfatta öppna frågor. Skapa bara utkast från Work Gmail. Skicka inget utan godkännande.

Den är kort. Den säger vad AI får läsa, vad den får producera och var gränsen går.

4. Kräv stopp vid osäker identitet

AI ska pausa om två konton verkar passa, om kunden har flera kontaktpersoner, om en tråd innehåller personuppgifter, om kalendern har konflikt eller om en bokning påverkar externa deltagare. Stoppregeln ska vara tråkigt tydlig: "fråga användaren".

5. Logga beslutet, inte bara resultatet

För varje återkommande jobb bör ni kunna se: vilka konton lästes, vilket konto användes för utkast eller åtgärd, om en människa godkände och varför jobbet pausade. Det behöver inte vara ett stort system. Ett enkelt fält för granskningsnotering räcker ofta i början.

En enkel startmall

Om ni vill prova detta utan att bygga ett stort governance-projekt, börja med en enda rutin. Till exempel veckoplanering, kunduppföljning eller frånvaro- och schemainformation.

Skriv upp:

• Vilka konton AI får läsa
• Vilka konton AI aldrig får agera från
• Vilka åtgärder som alltid blir utkast
• Vilka åtgärder som får ske direkt
• Vilka situationer som stoppar jobbet
• Var loggen hamnar
• Vem som äger regeln när arbetssättet ändras

Det här är ofta ett bättre första Tool Forge- eller Tankesmide-arbete än att bygga ännu en demo. När kontogränserna finns på papper blir det mycket lättare att automatisera tryggt.