Three decisions stall most Claude rollouts. None of them is the model.
Claude for enterprise rarely fails on model quality. Pexon finds rollouts stall on three engineering decisions: whose permissions a request carries, which cloud tenant the inference runs in, and who owns the bill. This hub covers all three, from developer rollout through cost control to EU hosting.
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.
We build this way ourselves. The repository this site lives in carries an AGENTS.md because the model reads it before it writes anything, and in our own rollouts the blocking ticket is almost never “the model was wrong”. It is “who approved this agent reading that mailbox”, and it sits with somebody who was not in the pilot. Every cost model we have seen that was built on chat-era per-seat assumptions broke the first time agentic sessions arrived.
What actually stops the pilot expanding
Three decisions, three different owners. That is the mechanism: none of the three can approve alone, so the rollout waits for a meeting nobody has scheduled. Naming the owner next to the decision is usually worth more than another model evaluation.
| What stalls | Who owns the decision | What a passing answer looks like |
|---|---|---|
| Permission model | Identity / IAM | Every request runs as a named identity that is already governed, and the assistant can read nothing its caller could not read unaided. |
| Tenant boundary | Cloud platform and security | Inference runs in an account you own, under roles you issue, with invocation logs written to a destination your SOC already reads. |
| Cost model | Budget holder | Every call carries a team key, spend is attributable per team each month, and the budget is enforced at the gateway rather than discovered in the invoice. |
Two of the three can be settled with public documents before anyone books a workshop. Token prices are published per model and per million tokens on the Amazon Bedrock price list, so the cost question is arithmetic against your own expected volume rather than a vendor conversation. The compliance question has a statute to point at instead of an opinion: Regulation (EU) 2024/1689, the EU AI Act, whose obligations attach to how you deploy the system and not to which model you licensed.
Four places the work actually lands
Claude Code — Claude Code is the first place a rollout gets real, because it touches source control, CI and whatever secrets those hold. The questions are narrow and answerable: which repositories a session may read, whether a plan runs before an edit, what the tool may execute without a human in the loop, and what a developer seat actually costs once agentic sessions replace chat. Developer rollout, cost and security live there.
Cowork — Cowork moves the same capability to people who will never open a terminal: the finance team reconciling spreadsheets, the marketing team drafting from a brand archive. The failure mode inverts. The risk is no longer arbitrary code execution but arbitrary document access, so the work becomes classification, sharing rules and a default scope narrow enough to survive a works council. Non-developer workflows and the access model under them live there.
Cost — Cost is the argument that decides whether year two happens, and it is the one most companies cannot have, because the invoice arrives as a single line with no team behind it. That is where the arithmetic belongs: what published token prices mean at your volume, where prompt caching and batching change the answer, and how per-team attribution gets built before anyone has to defend a budget.
EU hosting and GDPR — Residency is where a rollout meets a lawyer, and the honest answer differs by cloud platform rather than by vendor promise. Which regions actually process a prompt, what the processing agreement says about retention and training, whether an EU-only path exists at all on your platform. Those get answered with the vendor documentation attached, because on this subject an assertion without a citation is worth nothing.
The three-question check
This is the gate we apply before a pilot is allowed to grow. It is deliberately short, and it is deliberately evidence-based: each answer is a screenshot, a policy document or a command output, never a reassurance in a status call. Paste it into the ticket that proposes the expansion.
CLAUDE ROLLOUT — PRE-EXPANSION CHECK
Three answers, each with evidence attached to the ticket. No prose.
1. IDENTITY — whose permissions does a request carry?
Evidence: the IdP group or IAM role the session assumes, plus one
denied request showing the assistant cannot read what its caller
cannot read.
2. TENANCY — which account runs the inference, and is it logged?
Evidence: account ID, the permitted region list, and the output of
aws bedrock get-model-invocation-logging-configuration --region eu-central-1
3. COST — which team is this billed to?
Evidence: the team or project key sent with every request, plus last
month's spend split by that key. "One line in the cloud invoice" fails.
Any question without evidence attached: the pilot does not expand.The AWS CLI call needs the bedrock:GetModelInvocationLoggingConfiguration permission and reports per Region, so run it once for every Region in your permitted list. On Azure the equivalent evidence is the diagnostic setting on the Foundry resource.
Pages in this cluster
hosting
Claude in Your Own Cloud Tenant — Bedrock or Azure
Claude deployed into your own AWS or Azure account: EU inference profiles on Bedrock, one IAM role per workload, and invocation logs where your SOC already looks.
LLM Gateway for Claude: One Route, Every Model
One gateway in front of Claude, open weights and everything else: per-team spend limits, audit-grade logging and a routing policy you can change without redeploying.
Common questions
What does Claude for enterprise mean beyond buying seats?
Seats give people a chat window. An enterprise rollout is the layer underneath it: which identity a request runs as, which cloud account the inference happens in, and which team the tokens are billed to. None of those three is answered by a licence, and each one has a different owner inside the company.
Why do Claude rollouts stall after the pilot?
Because the pilot runs on public context and the team's own files, where nobody has to decide anything. The moment the assistant reads a contract in SharePoint or a ticket in ServiceNow, three approvals appear at once — identity, tenancy and budget — and they usually sit with three people who have never been in the same meeting.
Can Claude run inside our own cloud tenant?
Yes. Claude is available through Amazon Bedrock and through Microsoft Foundry on Azure, so inference can run under IAM roles or Entra ID groups you issue, with invocation logs landing in an account your security team already audits. Whether an EU-only processing path exists depends on the platform, which is why hosting and residency are their own sub-cluster.
What does it cost to start a Claude rollout with Pexon?
The two-week Readiness Blueprint is fixed at €4,900 and returns the rollout path, the permission model and a costed plan. Model consumption is billed to you directly by Anthropic, AWS or Microsoft at their published rates — we do not resell tokens. A delivery pod afterwards starts at €7,500 per month. All prices are net and exclude VAT.
Should we start with Claude Code or with Cowork?
Both eventually, but not in the same month and not with the same controls. Claude Code touches source repositories, pipelines and the secrets those hold, so its blast radius is a permission problem. Cowork touches documents, mailboxes and spreadsheets, so its blast radius is a data classification problem. Running both openings at once usually means neither gets governed properly.
Does using Claude put us outside GDPR?
No, but it adds a processor to your record of processing activities. You need a data processing agreement with whoever you buy inference from, a documented position on retention and on training, and a defensible answer to where prompts and completions are processed. Those are contract and architecture questions rather than model questions.
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.