Enterprise AI compliance: what IT and legal must sort out before day one
Before rolling out AI, compliance needs to be in place. SSO, data retention, EU AI Act, data processing agreement. The complete enterprise checklist.
Enterprise AI compliance comes down to five concrete requirements: access management via SSO, a data retention policy with EU-grounded processing, EU AI Act classification of your AI systems, a signed Data Processing Agreement with the vendor, and an internal AI usage policy. Get these five in place before day one. Not after. Not 'alongside.' Before.
Nearly every enterprise is rolling out AI tooling today. Claude Enterprise, Microsoft 365 Copilot, GitHub Copilot, Gemini for Workspace. The licences are approved, accounts are being provisioned, and IT is ready to deploy. Compliance will follow. That is exactly the sequence that causes problems.
Not dramatic problems — nobody wakes up to discover their AI tool is illegal. But real ones: audits asking for Data Processing Agreements that don't exist, employees unknowingly entering sensitive data into systems with no clear retention policy, and IT teams trying to reconstruct who had access to what after the fact.
The compliance layer beneath AI.
AI compliance is not a new discipline. It is a combination of privacy, security, and governance requirements that apply to every piece of enterprise software — with a few AI-specific additions introduced by the EU AI Act and GDPR. Understanding what that layer consists of is the starting point.
| Compliance pillar | Owner | Timeline |
|---|---|---|
| Access management (SSO, RBAC, MFA) | IT / Security | Before go-live |
| Data retention policy and EU processing | Privacy Officer / Legal | Before go-live |
| EU AI Act classification | Legal / IT | Before go-live |
| Data Processing Agreement (DPA) | Legal | Before go-live |
| Internal AI usage policy | HR / Legal / IT | Before go-live |
| DPIA (if high risk) | Privacy Officer | Before processing personal data |
Each pillar has an owner, a timeline, and a concrete output. We walk through each one below.
SSO and access management.
Single Sign-On is more than convenience. It is the foundation of your audit trail. Without SSO, you cannot retroactively determine who had access to an AI system and when. That is a governance problem.
What you want in place before day one:
- SSO integration with your identity provider (Azure AD, Okta, Google Workspace). Claude Enterprise supports SAML 2.0 and OIDC. Configure this before any accounts are created.
- Role-based access control (RBAC). Who can do what? Admins, standard users, and optionally read-only access for auditors. Document this in the vendor's admin console.
- MFA enforced for all accounts. Not optional. Claude Enterprise offers this setting at the organisation level.
- Offboarding protocol. When an employee leaves, their account is suspended immediately — not on Friday when HR finds time.
- Audit log exports. Save a monthly export of login activity into your own systems. Vendor platforms are not your audit trail.
Data retention and processing.
The most common AI compliance question: 'Does the vendor use our data for training?' The answer is vendor-specific, contract-dependent, and changes over time. Always verify — do not rely on what a website says.
For Claude Enterprise at the time of writing: Anthropic does not use Enterprise customer data for model training by default. This is contractually stipulated in the Enterprise agreement, not merely a policy statement. Always check the current DPA (see the Data Processing Agreement section).
Additional things to establish and document:
- Where is data stored? EU region or outside the EEA? Claude Enterprise offers EU data residency as an option for organisations that require it.
- How long are conversations retained? What is the default retention period in the platform logs? Can employees delete their own history?
- Who has read access? Can vendor support staff access conversation content for troubleshooting? Under what conditions?
- What may employees enter? Define clearly: no unanonymised customer personal data, no unpublished financial results, no information covered by confidentiality clauses in client contracts.
That last point matters at least as much as technical configuration. Employees who do not know what they should not enter make unintentional GDPR violations. A clear data classification scheme — public, internal, confidential, strictly confidential — combined with concrete examples per category, resolves this.
EU AI Act obligations.
The EU AI Act is fully applicable to high-risk AI systems from August 2026. But some obligations apply earlier — and they apply to organisations that use AI, not only to those that build it.
What applies to enterprises deploying AI:
- AI literacy (Article 4). Organisations deploying AI systems are required to ensure relevant staff have a baseline level of AI knowledge. This applies now. Document how you meet this obligation: training modules, mandatory onboarding, internal policy.
- Transparency to users. When employees or customers interact with an AI system, they must know they are interacting with AI. Not a footnote in terms of service — an active notification.
- Risk classification of your AI use. Are you using Claude to evaluate job applications, assess creditworthiness, or make decisions with significant impact on individuals? You may fall into the high-risk category with corresponding obligations.
- Prohibited uses. Real-time biometric identification, social scoring, subliminal manipulation — prohibited. Not relevant for most enterprise use cases, but verify explicitly if you are deploying AI in customer-facing processes.
“We are the provider of a general-purpose AI model, not a high-risk AI system deployer. Compliance responsibility for how you deploy it lies with you.”— Anthropic Enterprise documentation
In practice: Claude as a tool is not inherently high-risk. But if you deploy Claude in an HR decision process, a credit assessment procedure, or another context covered by Annex III of the EU AI Act, you as the deployer are classified as a high-risk deployer with corresponding obligations.
Data Processing Agreement.
A Data Processing Agreement (DPA) is required whenever a third party processes personal data on your behalf. If employees enter personal data into an AI tool — even if they are not supposed to — processing occurs. The DPA must exist.
A valid DPA for AI tooling must contain at minimum:
- Description of processing: purpose, nature, categories of data subjects, categories of personal data.
- Instruction binding: the processor only processes on instruction from the controller.
- Security measures: what technical and organisational measures are in place?
- Sub-processors: which third parties does the vendor engage? Are they also contractually bound?
- Data transfers: if data leaves the EEA — on what legal basis? Standard Contractual Clauses?
- Data subject rights: how does the vendor facilitate access, correction, and deletion requests?
- Data retention and deletion: how long is data retained, how is it deleted at the end of the relationship?
Anthropic provides a standard DPA for Enterprise customers through the Admin Console. Download it, have your privacy officer or legal counsel review it, and sign it before go-live. It is not a formality — it is a legal requirement.
IT checklist for go-live.
This is the consolidated checklist. Use it as a gate for your go-live decision. Only go live when all items are checked — or when there is a documented exception with an owner and deadline.
| # | Item | Owner | Status |
|---|---|---|---|
| 1 | SSO configured (SAML 2.0 or OIDC) | IT | |
| 2 | MFA enforced at organisation level | IT | |
| 3 | RBAC roles defined and configured | IT | |
| 4 | SCIM provisioning active (automated on/offboarding) | IT | |
| 5 | DPA signed with vendor | Legal | |
| 6 | Data residency verified (EU region if required) | Privacy Officer | |
| 7 | Data classification scheme communicated to employees | HR / Legal | |
| 8 | Internal AI usage policy published and signed by employees | HR / Legal | |
| 9 | EU AI Act risk category established for each AI use case | Legal / IT | |
| 10 | AI literacy programme documented (Art. 4 EU AI Act) | HR / IT | |
| 11 | DPIA completed where applicable | Privacy Officer | |
| 12 | Audit log procedure in place (export, storage, owner) | IT | |
| 13 | Incident response procedure updated for AI-related data breaches | Security |
Thirteen items. None are complex in execution. Most are combinations of existing processes — access management, contract management, privacy documentation — that you already run, now applied to AI tooling.
How we help.
We guide enterprises through setting up the full compliance layer for Claude Enterprise: DPA review, a tailored AI usage policy, data classification frameworks, EU AI Act risk assessment, and the technical configuration of access management and SSO. Delivered in three to five weeks. Fixed price. Nothing to fix after the fact.
Is AI tooling deployment on the agenda for this quarter? Get in touch via our contact form and describe your situation. We respond within one business day.