Hur låter man en AI-agent uppdatera ett CRM utan att den förstör något?

Varför det här är den svåra frågan

Att låta en AI-agent läsa i ett CRM är enkelt och ofarligt. Det värsta som händer är ett dåligt svar. Att låta den skriva är något annat. En modell som får uppdatera poster fritt kommer förr eller senare att skriva över ett korrekt telefonnummer med ett gammalt från en mailsignatur, slå ihop två kontakter som bara hette likadant, eller radera något den tolkade som en dubblett.

Det beror inte på att modellen är dålig. Den gör det den uppmanas till, med den information den har. Felet ligger i att systemet låter den göra det. Därför ska skyddet ligga i systemet och inte i en instruktion om att ”vara försiktig”.

Vi har kört en AI-agent med skrivrättigheter i vårt eget CRM, Altu Central Command, varje dag sedan i somras. Den har fler än 50 verktyg via MCP. Här är reglerna vi landat i.

1. Agenten agerar som en verklig person, aldrig som systemet

Den vanligaste genvägen är en API-nyckel med fulla rättigheter som agenten använder åt alla. Då kan agenten mer än någon av de människor som använder den, och loggen säger bara ”agenten”.

Gör tvärtom. Varje anrop ska köras som den person som startade agenten, med den personens roll. Hos oss loggar man in med OAuth, och agenten når exakt det personen når i appen: inte mer. Slutar någon, eller stängs av, slutar deras agent fungera i samma ögonblick, utan att någon behöver komma ihåg att dra in en nyckel.

2. Klassa varje verktyg: läsa, skriva eller ta bort

Varje funktion som agenten får anropa registreras en gång, med en klassning. ”Hämta bolag” är läsning. ”Uppdatera kontakt” är skrivning. ”Ta bort kontakt” är borttagning. Klassningen styr vad som får hända, och användaren kan ge sin agent bara läsrätt om hen vill.

Det låter byråkratiskt men är det som gör resten möjligt. Utan en klassning finns det ingen plats att sätta reglerna på.

3. Tomt fält: skriv direkt. Befintligt värde: fråga först

Det här är kärnregeln, och den är enklare än den låter:

• Fältet är tomt. Agenten fyller i det direkt. Att lägga till en webbadress eller en titel som saknades förstör ingenting.
• Fältet har redan ett värde. Ändringen hamnar i en godkännandekö. En människa ser det gamla och det nya värdet bredvid varandra och godkänner eller avslår.
• Något ska tas bort. Det köas alltid.

Resultatet är att kön förblir kort. Om varje skrivning krävde godkännande skulle ingen orka läsa den, och då är en kö samma sak som ingen kö.

4. Kontrollera behörigheten innan du visar skillnaden

Den här lärde vi oss den hårda vägen. Godkännandekön visar före- och efter-värden. Men om systemet läser ”före”-värdet med fulla rättigheter, och först därefter kontrollerar om personen fick se posten, kan agenten få tillbaka en kollegas privata data i själva diffen.

Ordningen ska därför vara: kontrollera att personen når posten, och svara ”hittades inte” om den inte gör det. Först därefter jämförs värden. Samma sak gäller regler per rad. Hos oss är ett utlägg skaparens, och en prospektlista är personlig. Det gäller i appen, och därför gäller det för agenten.

5. Allt loggas, även det som gick igenom

Varje skrivning hamnar i en logg, oavsett om den gjordes direkt, väntade i kön eller avslogs: vem, vilket verktyg, vilken post, före och efter. Hos oss är loggen och godkännandekön samma tabell, med ett statusfält. Det gör att frågan ”vem ändrade det här?” alltid har ett svar, också när svaret är ”Claude, åt Anna, i tisdags”.

6. Godkänn mot nuläget, inte mot det som gällde när förslaget gjordes

En ändring kan ligga i kön en stund. Under tiden kan någon annan ha ändrat posten, eller så har den bytt status. Ett godkännande ska därför tillämpas mot posten som den ser ut nu, och vägra om förutsättningarna ändrats.

Ett konkret exempel från oss: agenten får skriva utkast till artiklar på altu.se, men aldrig publicera. Ett förslag som köades innan en artikel publicerades får inte skriva om den publicerade texten när någon senare godkänner det. Därför filtreras sådana godkännanden på att texten fortfarande är ett utkast.

7. Vissa saker ska agenten inte kunna göra alls

Den enklaste spärren är ett verktyg som inte finns. Hos oss kan agenten:

• skriva artikelutkast, men inte publicera dem
• registrera kvitton som utlägg, men inte attestera eller bokföra dem i Fortnox
• föreslå en uppdatering av kulturdokumentet, men inte spara den

Det som påverkar kunder, pengar eller det offentliga avslutas av en människa. Ett undantag är när det redan finns ett attestflöde efter. Agenten får till exempel föra in timmar i personens egen tidrapport, eftersom veckan ändå skickas in och godkänns av någon annan.

Hur det fungerar i vardagen

En säljare skriver i Claude: ”Gå igenom mina möten den här veckan, lägg in anteckningarna på rätt bolag och sätt uppföljningar.” Agenten läser kalendern och CRM:et. Den lägger till aktiviteter och uppföljningar direkt, eftersom det är nya poster. Den föreslår att byta kontaktpersonens titel, eftersom det fanns en titel sedan tidigare. Det förslaget ligger i kön tills säljaren eller en administratör godkänner det.

Säljaren har sparat en halvtimme. Ingenting som en kollega skrivit har ändrats utan att någon tittat på det.

Vad det betyder för er

Det här går att bygga på ett CRM ni redan har, om det har ett API och en databas ni kommer åt. Det enklaste är ändå att bygga det i ett system ni äger, eftersom reglerna då kan ligga i samma lager som datan. Vi går igenom tekniken mer i MCP för svenska bolag och beskriver vad vi bygger för kunder på Claude och MCP.

Vill ni låta en agent arbeta i er data utan att tappa kontrollen? Hör av er, så visar vi hur det ser ut i vårt eget system.