«Claude kan håndtere IT-support» — som hvem, egentlig?
Det høres bra ut i seg selv: en ansatt trenger passordet sitt tilbakestilt, eller lurer på om lisensen deres dekker en bestemt app, og i stedet for å vente på en IT-tikett, spør de en AI-assistent og får svar med det samme.
Men det interessante spørsmålet er ikke om Claude kan gjøre dette. Det er som hvem den gjør det, og hvilken tilgang den faktisk har mens den gjør det. Det er her de fleste løsninger vi ser, blir vage — og det er nøyaktig der vi har lagt mest arbeid da vi bygde vår egen IT-support-assistent.
Hva vi har bygget
Løsningen kobler Claude til Microsoft 365 gjennom Azure Bot Service, og bruker Microsoft Graph API til å gi Claude tilgang til å utføre konkrete support-handlinger: tilbakestille passord, sjekke og administrere lisenser, slå opp gruppemedlemskap, og andre rutineoppgaver som normalt havner i en IT-support-kø.
Dette er ikke et konsept eller en demo. Det er noe vi bruker selv internt, hver dag, ved siden av at vi bygger det for kunder.
Boten har sin egen identitet — ikke din, ikke en delt admin-konto
Her er poenget som skiller dette fra de fleste "AI + Graph API"-oppsett vi ser andre bygge i hastverk: boten har sin egen identitet i Entra ID. Ikke en delt tjenestekonto alle handlinger går gjennom uten sporbarhet. Ikke en konfigurasjon der boten impersonerer en administrator for å få tilgangen den trenger.
Hvorfor betyr dette noe? Fordi det gjør boten til en ordentlig aktør i tilgangsstyringen deres — ikke et smutthull utenfor den. Rollebasert tilgangsstyring (RBAC), som vi bygger inn i alle leveranser uansett, gjelder for boten på nøyaktig samme måte som for en ansatt. Boten får de rollene og tilgangene den faktisk trenger for jobben sin, verken mer eller mindre — og alt den gjør er sporbart tilbake til nettopp den identiteten, ikke gjemt bak en generisk service-konto.
Conditional Access gjelder også boten
De fleste tenker på Conditional Access — betingede tilgangsregler basert på blant annet lokasjon, enhet og risikoscore — som noe som gjelder mennesker som logger inn. Det er mindre kjent, men like relevant, at de samme reglene kan settes på en bots identitet.
I praksis betyr det at boten ikke får en frikort-tilgang bare fordi den er en AI. Den er underlagt akkurat de samme betingelsene dere allerede stiller til alt annet som får tilgang til systemene deres. Skulle noe uvanlig skje — en handling fra en uventet kontekst, for eksempel — gjelder de samme sikkerhetsmekanismene som ville stoppet eller flagget en menneskelig bruker.
Dette er, etter vår erfaring, det de fleste bedrifter ikke tenker på når de first vurderer AI-agenter i M365: spørsmålet er ikke bare "hvilken tilgang gir vi boten", men "hvilke betingelser gjelder for den tilgangen, akkurat som for alle andre".
Lesehandlinger går av seg selv. Skrivehandlinger spør først.
Den siste brikken er kanskje den viktigste i praksis: boten skiller mellom å lese og å skrive.
Å sjekke en lisensstatus, slå opp gruppemedlemskap eller hente informasjon — det gjør boten selvstendig, fordi det ikke endrer noe. Men i det øyeblikket en handling faktisk skal gjøre noe — tilbakestille et passord, endre en tilgang, fjerne noen fra en gruppe — stopper boten og ber om eksplisitt godkjenning før den utfører den.
Dette er samme prinsipp som vi har skrevet om tidligere med Claude Live: et menneske med hånden på rattet. Ikke fordi vi ikke stoler på modellen, men fordi det er sånn ansvarlig AI-bruk skal fungere i en bedrift — jo mer konsekvens en handling har, jo tydeligere skal et menneske være involvert i beslutningen.
Vi bruker det selv
Dette er ikke bare noe vi selger. Vi kjører vår egen IT-support delvis gjennom akkurat dette oppsettet internt. Det er en av grunnene til at vi er trygge på å anbefale det videre — vi har testet det på vår egen drift først, ikke bare på en kundes.
Vil dere ha noe tilsvarende?
En IT-support-assistent bygget på denne måten — egen Entra-identitet, Conditional Access, og skille mellom lese- og skrivehandlinger — er nøyaktig typen leveranse vi bygger under Enterprise-løsninger: tenant-klargjøring, Claude-baserte agent-blueprints i M365, og automasjon satt opp med samme governance-tenkning som resten av bedriften deres allerede er underlagt.
Poenget som gjentar seg
En AI-assistent som kan gjøre noe i systemene deres, er ikke automatisk et sikkerhetsproblem. Men den er heller ikke automatisk trygg bare fordi den er nyttig. Forskjellen ligger i om den er bygget med en egen, sporbar identitet, underlagt de samme reglene som alt annet — eller om den bare fikk tilgangen den ba om, fordi det var raskest.
AI starter ikke med teknologi. Den starter med struktur.
Ta kontakt for en gratis AI Ready-kartlegging →
Les også: Claude i nettleseren er ikke en AI-strategi · MCP: Broen mellom Claude og systemene deres