Claude Enterprise

What Claude Enterprise Is

Claude Enterprise is Anthropic's plan for an organisation rather than a person. What you buy is a tenancy: one administered space in which every member signs in with the company identity, meets the same Claude in every tool, and leaves behind a record you can audit. Since the unified experience reached general availability for Enterprise on 23 October 2026, a conversation that begins as ordinary chat can carry on in Cowork, an isolated cloud sandbox that opens files, runs code and comes back with results, and then return to chat without the user changing window. The seat also opens Claude Code for engineers, Claude Design, Docs and Slides, Claude for Microsoft 365, Claude in Chrome, Claude in Slack and Claude Security, together with Projects, Artifacts, memory, Skills, plugins and connectors.

How we know is simple, because the record is public and dated. Anthropic's announcement of 4 September 2024 introduced the plan with a larger context window, single sign-on, SCIM provisioning, audit logs, role-based permissions and a native GitHub integration. The plan page at claude.com lists what a seat includes today; the release notes and admin guides on support.claude.com put a date on every change since. The older "Claude for Work" label has been retired, and Team and Enterprise are sold as separate plans. Cite the date whenever you cite a feature: a risk register that says "Claude has audit logs" is weaker than one that says when you last checked.

What changed between 2024 and now is less the model than the shape. The first Enterprise was a very good chat window with corporate identity attached. The 2026 product is an agentic workspace. Cowork appeared as a research preview in January 2026, reached enterprise release with connectors and plugins in February, and became generally available on 9 April with an Analytics API and OpenTelemetry support. The admin side grew in step: custom roles that decide which connectors, and even which connector tools, a role may use (28 May 2026); spend limits by organisation, group and member; pooled group budgets announced on 23 October 2026; a Compliance API that feeds your SIEM.

Picture three buyers. A 4,000-person insurer in Zurich wants claims handlers drafting letters inside Word, with a chosen retention period and a complete audit trail. A British university wants researchers on Cowork but no network egress from the sandbox until information security has looked. A city council in Ohio wants a calm, cheap start: Sonnet by default, Efficient mode on, three use cases in the licensing office. All three buy the same tenancy and switch on different parts of it.

The popular myth is that an enterprise plan is the consumer product with a logo on it. It is not. The consumer product has no Compliance API, no SCIM, no retention you choose, no customer-managed keys, and no way to restrict what a sandbox may reach. The plan is the admin plane plus the models.

Try it: Subscribe to the release notes on support.claude.com and read the last ninety days before your first settings review; most surprises are already written down.

You are not buying a chatbot; you are buying a tenancy, and tenancies are governed.

One Seat, Many Doors

A seat on Claude Enterprise is one identity, not one application. The same person, signed in once through your identity provider, opens Claude in the browser at claude.ai, in the desktop app on macOS or Windows, on an iPhone or an Android phone, inside Excel, PowerPoint, Word and Outlook through Claude for Microsoft 365, in a Chrome side panel, in a Slack thread and, for engineers, in the terminal, the IDE or the web through Claude Code. Behind each door stand the same models, the same memory and Projects, and the same organisation policy. Anthropic's plan page lists the surfaces a seat includes; the admin guides on support.claude.com say how each is enabled, and the release notes date them: Claude for Excel entered beta on 24 November 2025, Claude in Chrome gained site allowlists and blocklists on 18 December 2025, and tagging Claude in Slack to delegate a task arrived on 23 June 2026.

Why so many doors? Because people do not change tools for a vendor; they change tools when the work demands it. The finance analyst in Rotterdam lives in Excel and will only use an assistant that lives there too. The in-house lawyer in Manchester works in Word with tracked changes and refuses to paste a contract into a browser. The support lead in Austin runs her day from Slack. The platform engineer in Bengaluru wants nothing between him and the terminal. The second consequence is quieter and more useful: one identity means one audit trail. Whether a document was drafted in Word or in chat, the Compliance API shows it under the same user.

More doors mean more places to configure. Claude in Chrome can browse and act on websites, so it carries its own allowlist. The Microsoft 365 connector's write tools, which let Claude send mail or edit files, need consent in Microsoft Entra and explicit admin enablement (7 July 2026), as does any connector that can act rather than merely read. The desktop app accepts MDM policy keys, so a device team can forbid local MCP servers or limit which folders Claude may open. None of this is difficult; all of it is a decision somebody must make.

Geography changes the keys, not the doors. Under the GDPR a connector that reads an employee's mailbox is a processing activity worth a line in your records; in Germany a tool that could monitor staff can trigger works council co-determination under section 87 of the Works Constitution Act; in the United States the first question is usually which state privacy law applies to the customer data sitting in that mailbox.

The myth to correct is that each surface is a separate product with its own data rules. It is one tenancy, one set of commercial terms, one retention setting, one audit log, and inputs and outputs are not used to train models by default on any of them.

Try it: Install the desktop app with your organisation sign-in and count the connectors already approved for you; that list is your admin's risk appetite in miniature.

The seat is the person; the doors are only where the work happens.

Team, Enterprise or the API

There are three ways into Claude, and the honest answer is that most organisations of any size end up with two of them. Team is the self-serve plan for small groups, roughly two to 150 people; it includes single sign-on and, since 16 January 2026, Claude Code on standard seats, but at the time of writing it does not include SCIM provisioning, audit logs or fine-grained roles. Enterprise is the governed tenancy this book is about: identity, compliance evidence, retention you choose, customer-managed keys, model and spend controls. The Claude Platform is the API, for software you build yourself, reached directly from Anthropic or through Amazon Bedrock, Microsoft Foundry and Google Cloud's Vertex AI, with zero data retention available by agreement.

How we know: the plan comparison on claude.com, the admin guides on support.claude.com, and each cloud provider's own documentation. The precise Team limits are the sort of detail that moves, so read the page on the day you decide, and keep a dated copy with the decision.

Choose by need, not size. Ask three questions. Who may join and who must leave, automatically? If the answer involves your HR system, you need SCIM, which means Enterprise. Who will ask us for evidence? If a regulator, an auditor, a client's security questionnaire or a works council will one day ask what was done with the tool, you need audit logs and the Compliance API. Are we building a product? If Claude will sit inside something your customers use, that is the Platform, with your own logging, your own keys and your own evals, which the sister volume Agents in Production covers.

Three illustrative buyers. A 40-person architecture practice in Copenhagen is well served by Team: everyone knows everyone, the managing partner adds and removes seats by hand, and nobody will ever ask for a log. A 12,000-person retailer with head offices in Leeds and Warsaw needs Enterprise, because the day a store manager leaves is the day their access must end, in both countries, without a ticket. A Toronto fintech runs the Platform through Bedrock for its customer-facing product and Enterprise for its 300 staff, two contracts, two bills, one Trust Center.

The myth is that Enterprise is for big companies. It is for organisations with obligations. A 60-person law firm bound by professional secrecy may need Enterprise more than a 600-person start-up that handles no personal data. In the European Union, a public body that must document a data protection impact assessment will want the audit trail from day one; in the United Kingdom the same logic follows the ICO's guidance; in the United States it is more often a client contract that forces the question.

Try it: Write your three admin questions on a card (who joins, who leaves, who can prove it) and see which plan page answers all three without a footnote.

Count the obligations you carry, not the people you employ.

The Models Behind the Seat

A seat does not give you a model; it gives you a family of them, and a set of dials. In late October 2026 the family is Opus 5.5, Sonnet 5.5 and Haiku 5.5, the 5.5 generation that arrived on 7 October 2026, alongside Fable 5.1 and a Mythos-class tier with restricted access. The dials are effort (how long the model is allowed to think before answering), the per-role entitlements that say which models a member may pick, and Efficient mode, which restricts the unified experience to Sonnet and Haiku and starts every new session on Sonnet 5.5 at low effort. How we know: the model pages on docs.claude.com, and the release notes for model and effort controls for members (beta, 1 July 2026) and for model defaults and entitlements by role (2 July 2026).

This book will not discuss benchmarks. For an organisation the useful frame is the task, and three honest trade-offs: capability, latency and cost per token. Classification, routing, extraction and first-pass triage of a thousand tickets a day belong to Haiku, which is quick and cheap enough to run at that volume. Daily drafting, analysis, summarising a forty-page report, and most Cowork sessions belong to Sonnet, which is why Efficient mode lives there. Long multi-step agentic work, difficult reasoning and anything where a wrong answer is expensive belong to Opus or Fable. The Mythos tier is restricted, so plan without it and treat access as a bonus.

Three illustrative settings. A Madrid insurer pins its claims-triage group to Haiku, because the job is sorting, not writing. A Dublin law firm entitles its lawyers to Opus for opinions and Sonnet for correspondence, and measures which they actually use. A Kraków city office turns on Efficient mode for 1,200 administrative staff and leaves the higher dials to a dozen analysts. Each of these is a role setting, made once by an admin, not a preference each person rediscovers.

Two myths deserve correcting. The first is that the biggest model is always best; for most office work the quality difference is invisible to the reader but visible on the invoice. The second is that model choice is a user preference. On Enterprise it is an entitlement, and entitlements are policy: they belong with the role, the budget and the risk appetite, not with the mood of the afternoon.

The evidence that matters is your own. Run a real task through two models, time it, and have colleagues rank the outputs without knowing which is which. A pilot measurement of that kind is worth more than any public leaderboard, and it is what the Evals in a Nutshell volume is for.

Try it: Take one genuine task, a two-page summary of a real document, run it on Haiku, Sonnet and Opus, time each, and ask three colleagues to rank the three outputs blind.

The right model is the cheapest one that does the job well, and the role, not the mood, should choose it.

How Anthropic Thinks About Safety

An enterprise buyer cannot inspect a model's weights, but can read what its maker has committed to in public, and that reading is worth an afternoon. There are four layers. The Responsible Scaling Policy, first published in September 2023 and revised since, is Anthropic's framework for catastrophic risk: it defines AI Safety Levels and commits the company to safeguards before training or deploying models past stated capability thresholds. Claude's constitution, published in January 2026 and running to around 23,000 words, describes how Claude is meant to think, behave and weigh competing goals. The usage policy and commercial terms govern your tenancy, including the commitment that inputs and outputs are not used to train models by default. The Trust Center at trust.anthropic.com holds the evidence: SOC 2 Type II, ISO 27001, and certification against ISO/IEC 42001, the AI management system standard, which Anthropic obtained in January 2025.

How we know is the point: every one of these is a dated document on anthropic.com or the Trust Center, and the certifications are issued by independent auditors against published standards. Read them as what they are. The scaling policy is about frontier risk, not your uptime or your data. The constitution is about model behaviour in general, not a guarantee for any single answer. The terms are a promise about your data. The certificates are evidence about the service's controls, not about your use of it.

That last distinction is where buyers trip. A SOC 2 report says the provider's controls operated as described over a period; it says nothing about whether your claims team should paste medical notes into a chat. ISO/IEC 42001 says the provider runs an AI management system with objectives, risk assessment and review; it does not run yours. The NIST AI Risk Management Framework (January 2023, with a Generative AI Profile in July 2024) makes the same point from the other side: the Govern and Map functions are the deployer's work.

Geography sets the frame. In the European Union, general-purpose model obligations under the AI Act have applied to providers since 2 August 2025, and the article 4 duty of AI literacy has applied to deployers, which means you, since 2 February 2025. In the United Kingdom there is no AI Act; the ICO's guidance and the UK GDPR do the work. In the United States, a hospital group asks for HIPAA, a federal agency asks for FedRAMP, and a bank asks for its regulator's model-risk guidance.

In the risk register, write each commitment as a control with five fields: the control, the source URL, the date you checked it, the owner and the next review. That is a dull sentence, and dull is what an auditor likes.

Try it: Request the SOC 2 Type II report through the Trust Center and file it, with the date, beside your existing ISO 27001 supplier review rather than in a new folder nobody opens.

A policy is a promise about behaviour; a certificate is evidence about a system; file both and confuse neither.

Per Seat, Plus Usage

The commercial shape of Claude Enterprise has two parts, and understanding both is more useful than knowing either price, which this book will not quote. The first part is the seat: a flat fee per person on an annual commitment, with a minimum number of seats stated on the pricing page. The second is usage: the tokens those people consume, billed at API rates, over and above the seat. You can buy sales-assisted, with an invoice and net terms, or, since 12 February 2026, self-serve online with a single seat type; you can also buy through AWS Marketplace and draw the cost down against an existing AWS commitment. How we know: the pricing and enterprise pages on claude.com and the self-serve release note; the shift from bundled to unbundled usage, reported in the trade press across late 2025 and early 2026, is best treated as context rather than quoted precisely.

Unbundled usage changes behaviour, and that is the reason to understand it. When usage is visible, heavy users become visible, and so do idle seats. In most pilots a small share of people account for most of the tokens, and they are usually the people doing the most valuable work, so the right response is rarely to stop them. The admin plane gives you the tools to manage rather than forbid: spend limits at organisation, group and member level; pooled group budgets, announced on 23 October 2026, so a department shares one cap instead of ten tiny ones; alerts at 75 and 90 per cent for admins, and at 75 and 95 per cent for users, who can request an increase; Efficient mode for groups whose work does not need the larger models.

Forecasting is a pilot exercise, not a spreadsheet guess. Run thirty days with a real group, export usage by user, and look at the distribution. A Birmingham council that pilots with 40 people in revenues and benefits will see a few heavy users and a long tail, and can budget the year from that shape. A Munich manufacturer will find that its works council takes an interest in per-user spend data, because a report that ranks employees by consumption is, under the Works Constitution Act, a technical system capable of monitoring performance, and needs agreement before it is used that way. A US software firm buying through AWS Marketplace cares mostly that the drawdown counts towards its commit.

Myth: the licence is the whole cost. It is not even the whole bill. Add usage, the time of the people who administer it, and the training and AI literacy that the EU AI Act now expects of deployers.

Try it: Export last month's usage by user from the analytics page, sort it, and see what share of spend the top tenth of people consumed; then ask what they were doing before you ask them to stop.

The seat is a cost you forecast; usage is a behaviour you manage.

Five Myths About Enterprise AI

Every rollout meets the same five myths in its first month, usually from intelligent people, and each has a dated answer. Myth one: it trains on our data. On Claude Enterprise, inputs and outputs are not used to train models by default; the commitment is in the commercial terms and documented on the Trust Center at trust.anthropic.com. How we know is the contract you signed, which is the best kind of knowing. The sensible follow-up is retention: you can set a custom period, with a minimum of thirty days, and you can ask about customer-managed keys and US-only inference if your regulator cares where the maths happens.

Myth two: it replaces the intranet. Claude reads your SharePoint, Drive or Confluence through connectors, and every connector respects the permissions the person already has in the source system. It is a very good reader; it is not a system of record. If the intranet is wrong, Claude will summarise the wrong thing fluently. A Dutch housing association that piloted a policy assistant learned this quickly: the first week's answers were impeccable summaries of a superseded tenancy policy, and the fix was to archive the old document, not to prompt harder. Treat that as illustrative, not reported.

Myth three: one licence per person is the whole cost. The seat is a flat fee, usage is billed on top at API rates, and the real cost includes an admin's time, a champion's time and training. The EU AI Act's article 4 has expected deployers to ensure AI literacy among staff since 2 February 2025; that is a cost, and a worthwhile one, in every member state, and a good idea in Leeds or Lyon regardless.

Myth four: switch everything on day one. Anthropic's own rollout guidance for the unified experience says the opposite: involve IT, security and procurement, do a security review, pilot with one role, review the settings, monitor for two to four weeks, then expand in waves. The product agrees with the guidance: the unified Claude was off by default for existing organisations when it launched on 23 October 2026, with the default changing on 16 November unless owners choose to keep it disabled.

Myth five: the AI team owns it. An AI lead can run the use-case inventory and the champions network, but the Primary Owner sits in IT, the audit logs belong to security, the DPIA belongs to the data protection officer, the budget belongs to finance and, in Germany, the works council has a legal seat at the table. The next two chapters are about that cast. Myths survive because nobody dates them; the moment you write "checked 29 October 2026, source: admin guide" beside a claim, it becomes a fact with a shelf life.

Try it: Ask five colleagues which of these five they believe, and keep the tally; it is your training needs analysis for free.

Put a date and a source on every claim, and the myth stops being one.

Decide What You Want First

The most expensive sentence in enterprise software is "let's switch it on and see what people do with it". It sounds open-minded; it is actually a decision not to decide, and it guarantees that six months later nobody can say whether the thing worked. The alternative fits on one page, and this chapter is about writing it. Call it the intent statement: three to five measurable goals, the non-goals, the risk appetite, the baseline measures, and a signature from an executive sponsor who will still be in post at the review.

How we know this works is not a vendor's claim but two standards and a lot of scar tissue. ISO/IEC 42001, the AI management system standard, requires an organisation to set AI objectives and plan how to achieve them (clause 6.2) and to evaluate performance against them (clause 9). The NIST AI Risk Management Framework puts Govern and Map before Measure and Manage for the same reason. Both are saying: write down what you want before you measure anything, or you will measure what the tool makes easy.

Goals should be outcomes, not features. "Deploy Claude to 2,000 staff" is a feature. "Cut the median time to draft a claims letter from forty minutes to fifteen" is an outcome; so are "reduce the backlog of policy queries by 30 per cent", "no increase in error rates found at quality review" and "staff report less drudgery in the quarterly survey". Pick measures you already collect, or can collect in the pilot's first two weeks; a baseline measured after the tool arrives is not a baseline.

Non-goals are the quiet heroes of the page. A Lyon hospital group writes "no patient records in year one", which settles a hundred later arguments and keeps the deployment out of HIPAA-style territory until the privacy work is done. A Toronto insurer writes "no autonomous sending of customer email", which decides the connector policy for Microsoft 365 before anyone has opened the settings. A UK university writes "no marking of student work", which is both a policy and a message to staff.

Risk appetite goes on the page in plain words, by category: low for anything that leaves the building under the organisation's name, medium for internal drafting, and a named person who can raise it. Then the signature. A sponsor who signs a page will turn up to the thirty-day review; a sponsor who approved a budget line will send a delegate.

Try it: Write the three goals, two non-goals and one line of risk appetite on a single page this week, and ask the sponsor to sign it before the kickoff rather than after.

A feature you did not ask for cannot deliver an outcome you never wrote down.

The People Who Make It Work

No setting in the admin console matters as much as the ten names on this page. Claude Enterprise is governed by people before it is governed by policy, and the first job of whoever is reading this is to fill in the roster. At the top sits the executive sponsor, who owns the intent statement from the previous chapter and turns up to the reviews. Beneath the sponsor are four pillars, and each pillar has a small cast.

The first pillar holds the keys. The Primary Owner is a real role in the product: the one account that can do everything, including billing and transfer of ownership, which is why it should belong to a person in IT and not to the most enthusiastic user. Since 2 June 2026, custom roles can carry admin permissions for areas such as billing and privacy without Owner status, so the Primary Owner can and should be a quiet role. The IT admin runs single sign-on, SCIM and the settings; the service desk handles seats and access requests through the directory, not through email.

The second pillar is the brakes. The security lead owns the audit logs, the Compliance API feed into the SIEM and the periodic settings review. The data protection officer, mandatory under the GDPR for most public bodies and many private ones, owns the data protection impact assessment and the retention decision. In Germany the works council is not a courtesy invitation: under section 87 of the Works Constitution Act, a technical system capable of monitoring employee conduct or performance needs its agreement, and usage analytics by user is exactly such a system. In the UK and the US there is no equivalent legal seat, but staff representatives consulted early turn into champions, and those consulted late turn into the grievance.

The third pillar is money: procurement for the contract, the data processing agreement and renewal; finance for spend caps, pooled budgets and the forecast; legal for the terms, intellectual property questions and, in the EU, the AI Act's deployer duties. The fourth pillar is value: the AI lead who runs the use-case inventory and the measures, one champion per department who teaches colleagues and reports friction, and the managers who must give people time to practise, because a tool nobody has an hour to learn is a tool nobody uses.

Who decides what is the sentence worth writing on the wall: the sponsor decides why, the Primary Owner decides who, security and privacy decide what may be done, finance decides how much, and the AI lead decides what to try first. How we know this cast works is the evidence of every rollout that failed without one: a pilot owned by an enthusiast with no sponsor, a rollout blocked at month four by a works council nobody had met, a renewal nobody had budgeted.

Try it: Print the roster with ten blank lines and fill in real names in a single meeting; any line that stays blank is a risk you have already accepted.

Ten names on one page; any blank is a risk you have already accepted.

Your First Thirty Days

The first month should be boring, and boring takes planning. Anthropic's own rollout guidance for the unified experience is a reasonable skeleton: involve IT, security and procurement; do a security review; pilot with one role; review the settings; monitor for two to four weeks; expand in waves. Here is that skeleton with dates on it, written for the admin who has to do it on Monday.

Week one is signing and connecting. The contract, the data processing agreement and, if you are a US healthcare organisation, the business associate agreement are done. Single sign-on is configured against your identity provider and tested with two accounts, one of them an admin. Domain capture is switched on so that colleagues with company email addresses are pulled into the tenancy rather than creating personal accounts. The Primary Owner is named, and it is someone in IT. Nothing else happens, and that is correct.

Week two is the pilot group. One SCIM group, one role, twenty to fifty people who share a job, so that the measurement means something: revenues and benefits in a council, claims handling in an insurer, a research group in a university. Defaults are conservative because changing them later is cheap and undoing them is not: the unified experience stays off until security has read the sandbox guide, network egress for cloud sessions stays off, memory is already off by default for Enterprise organisations since 25 August 2026, and connectors sit at "needs approval". Model entitlements are set for the role, and Efficient mode is a fair starting point for most non-technical groups.

Week three is two or three use cases, not twelve. Each team names one real piece of work, a house-style Skill is written for it, and a thirty-minute Monday review looks at what happened. Week four is measurement: usage analytics by group, a sample of the audit log read by the security lead, a short survey of the pilot, and the numbers against the baselines from the intent statement. At day thirty the sponsor decides, in a meeting that was in the calendar from week one: go wider, widen slowly, or pause and fix.

What not to do yet is as important as the plan. Do not open network egress to all domains. Do not approve every connector or install every plugin from the marketplace. Do not turn on "skip all approvals" for anyone. Do not share cloud sessions across the whole organisation. Every one of those is a legitimate setting for month three, once you know what the pilot actually did. A German organisation also uses this month to brief the works council before usage analytics by user is ever looked at; a UK or US organisation uses it to tell staff, in writing, what the tool is for and what it is not.

Try it: Put the day-thirty decision meeting in the sponsor's calendar today, with the three goals from the intent statement in the invitation, before a single seat is provisioned.

A month of small, deliberate switches beats a day of big ones.