Claude Enterprise: the architectural decisions that determine the success of your AI project

This article addresses this first project, the one without which the second does not hold.

With its Enterprise offering, Anthropic provides the building blocks to answer these questions. But building blocks do not make an architecture. This article describes the study and design work to be carried out during a deployment of Claude Enterprise, and the decisions that need to be made before opening the service.

Security functions exist. What is almost always lacking is the decision to configure them, in the right order, and in coherence with the rest of the information system.

Why is a generative AI deployment primarily an architecture project?

Because the AI assistant is not an isolated tool. It connects to the company's directory, receives sometimes sensitive documents, produces traces that are of interest for compliance and security, and stores data with a third party.

Specifically, five requirements appear in all specifications:

• fine access controls, by role - Role-Based Access Control (RBAC) ;
• automatic provisioning of accounts from the directory - System for Cross-domain Identity Management(SCIM) ;
• audit logs and a compliance API, integrated with security tools like Microsoft Purview ;
• configurable data retention ;
• client-managed encryption keys - Customer-Managed Encryption Keys (CMEK).

Each of these requirements has a technical response. But each also raises questions of organisation, compliance, and trade-offs. This is where the success of the project is determined.

Step 1 — Study the existing setup before designing the target

Before configuring anything, it is necessary to understand the environment in which the tool will be integrated.

• Identity : which directory (Entra ID, Okta…)? Is SSO and SCIM already in use? Are there groups by profession?
• Security : does the company have Purview licenses? A SIEM? An internal or outsourced SOC?
• Data : which categories will be entrusted to AI? Is there a classification or sensitivity labels?
• Obligations : NIS2, regulated sector, contractual clauses, data localisation requirements?
• Current uses : are employees already using AI tools with personal accounts?

This last point is often the most revealing. The "shadow AI" is rarely null. The deployment of an official tool is also an opportunity to address it.

Step 2 — Design the target architecture

The architecture is organised around three pillars :

• the directory, the source of truth for identities and groups ;
• the Claude Enterprise platform, where roles and policies apply ;
• the client's security environment, which leverages logs and, where applicable, holds the keys.

Access control : reason by group, never by user

Rights are managed through custom roles attached to groups. One group per business profile, one role per group, the bare minimum for each.

Administrative roles, however, should remain limited to a few named individuals.

Provisioning : SCIM rather than on-the-fly creation

Creating accounts "on first login" is tempting, as it is simple. It has a major flaw: it never deletes accounts.

With SCIM, the directory becomes the sole source of truth. A departure in the directory, and access disappears automatically. Order matters: domain verification, SSO tested and then enforced, and only then SCIM.

Traceability : one source, two professions

This is often the most misunderstood point.

The administration console allows exporting audit logs. But the structuring tool is the compliance API of Anthropic (Compliance API) : it exposes audit events and the content of conversations, and it is this that third-party tools use.

As long as the compliance API is not activated, nothing is recorded. And this gap cannot be filled. It activates on the first day.

Should we then feed Microsoft Purview, a SIEM, or both? It all depends on who in the company will exploit this data:

• Purview serves compliance. It looks at what is written: personal data pasted into a conversation, a shared confidential document. It is the DPO's tool.
• The SIEM serves security. It looks at who does what, from where and when, and correlates these events with the rest: a connection from abroad just after a failed authentication, followed by a massive export. It is the SOC's tool.

So it is not a duplicate: the same data serves two functions. A small business without a SOC will make do with Purview, or a simple archive. An organisation subject to NIS2 and equipped with a SOC will need both.

Retention: two policies, not one

The retention period is configurable, with a minimum of 30 days. But beware: conversations and projects follow distinct policies, and projects are retained indefinitely by default.

Only adjusting the retention of conversations therefore lets slip everything that is stored in projects. And a deletion is permanent: if there is an archiving obligation, it must be exported before the purge.

Step 3 — Mastering risks: the case of encryption keys

Client-managed encryption keys are often presented as the pinnacle of security. They are. But they come at a cost, and that cost must be known before signing.

What CMEK brings

The client encrypts their stored data with their own key, hosted in their vault (AWS, Google Cloud or Azure). They can trace each use of the key and revoke it.

What it costs

As of the date of writing, according to Anthropic's documentation:

• activation is permanent and does not apply to data already present;
• it covers the entire organisation, without exception per user;
• encryption operations are processed in US regions, a point to examine closely in light of the localisation requirements of a European company;
• several functions disappear: searching in conversations, certain tools like Claude Code on the web, exporting logs from the console, public sharing of artifacts…
• a revocation makes encrypted data permanently unreadable, in less than an hour.

CMEK is not a reflex. It is a governance decision, which falls to the CISO and the DPO.

Three options generally present themselves: CMEK for all, no CMEK with short retention and strong traceability, or a separation between a sensitive population and others. None is better in absolute terms. The one that fits depends on the actual obligations of the company, not on intuition.

Step 4 — Deploy in the right order

The order of operations is not a detail. Several decisions are irreversible or non-retroactive.

1. Identities : domain, enforced SSO, SCIM and groups.
2. Traceability : activation of the compliance API, before the first users.
3. Encryption : CMEK decision, then activation if retained, before any sensitive data.
4. Rights : custom roles, validated on a pilot group.
5. Retention : policies aligned with the DPO and archiving.
6. Exploitation : connection to Purview and/or the SIEM.
7. Compliance : processing register, impact analysis if necessary.

Next comes the gradual extension to more users and the opening to complementary tools: connectors, agents, development tools. Each deserves to be evaluated in light of the choices made above, as the CMEK, in particular, conditions what remains available.

And what about change management ?

A perfectly secure architecture that is not adopted is useless.

Deployment must be accompanied by training for administrators, clear usage rules for employees (which data to trust, which never), and a few business ambassadors who will keep the tool alive. This is also what allows the transition from a pilot group to all teams without losing control.

And after the foundation?

Once the platform is secured, the real potential opens up: identification of high-impact use cases, connectors to your tools, agents, automation of recurring tasks, measurement of gains.

How OPNEO supports you

OPNEO acts as a part-time or transitional CIO. For this type of project, we provide :

• a study of the existing : identity, security, data, obligations and current uses of AI ;
• the design of the target architecture and the configuration of the platform ;
• a risk register and decision notes for structural choices, CMEK first ;
• the management of deployment, in the right order, with internal teams and providers ;
• compliance : GDPR, NIS2, AI Act, consistency with an ISMS ISO 27001 ;
• high-value AI use cases: from identification to deployment, once the foundation is in place;
• change management : training, usage rules, support for early users until generalisation.

Our conviction is simple: generative AI is a tremendous lever, provided it is deployed like any critical component of the information system. Methodically.

Are you preparing a deployment of Claude Enterprise, or another AI assistant? Let's talk about it.