The rollout stalls where the permissions start.
This cluster covers the engineering a Claude rollout needs once it leaves the pilot team: deployment inside your own AWS or Azure tenant, access mapped onto the identity system your security team already governs, internal systems connected through the Model Context Protocol, and usage measured per team instead of counted in seats.
Seats are not a rollout.
A pilot team is productive on public context and its own files, so the first weeks look easy. The work starts when the assistant has to read a contract in SharePoint or a ticket in ServiceNow, because then the question is not what the model can do but whose permissions the request carries and where the record of it lands.
Common questions
Why does rolling out Claude need engineering at all?
Buying seats is not the hard part. The moment the assistant has to reach a document management system, a ticket queue or an ERP table, somebody has to decide whose permissions apply to that request and where the evidence of it is written. Both are architecture decisions, and neither is answered by a licence.
Do we have to leave the Claude apps to do this?
No. Most companies run both: the Claude apps for general knowledge work, and an API deployment in their own cloud account for anything that touches internal systems. The second one is where identity, logging and data residency are decided, so that is where we start.
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.