AI governance framework for Claude: roles and controls

TL;DR

An AI governance framework for Claude needs three parts: named owners with a RACI, an approval gate that sorts each use case into an AI Act risk tier, and technical controls that enforce the decision. On Claude Enterprise that means SSO, roles, spend limits and audit logs. On Bedrock and Vertex it means model allowlists in SCPs and org policies.

What does an AI governance framework for Claude have to cover?

A workable AI governance framework answers four questions for every Claude use case: who owns it, who approved it, which legal risk tier it sits in, and which technical control proves the decision is enforced. Policy documents without the fourth part fail an audit. Controls without the first three create shadow decisions inside the platform team.

The legal anchor in the EU is the AI Act. When your company uses Claude under its own authority, it is a “deployer” in the sense of Article 3(4) of the AI Act. Anthropic carries the model provider duties. Your duties depend on what you do with the model, which is why the approval gate matters more than the vendor choice. The full deployer checklist is in our EU AI Act guide for LLM deployers.

The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026, changed two things a governance board must know. First, Article 4 on AI literacy now asks providers and deployers to “take measures to support” literacy, and states that this does not require guaranteeing any specific level for an individual. Second, high-risk obligations for Annex III use cases apply from 2 December 2027 and for Annex I products from 2 August 2028. That gives you a window to build the framework before the hard duties hit.

GDPR sits next to the AI Act, not under it. Article 35(1) of the GDPR requires a data protection impact assessment before processing that uses new technologies and is likely to result in a high risk. Most Claude use cases with customer or employee data will trigger at least the screening question. We recommend running the AI Act tiering and the DPIA screening in one intake form, so the same facts feed both.

Which roles and which RACI do you need?

Five roles carry Claude governance in a mid-sized EU company: a business owner per use case, an AI governance lead, the data protection officer, information security, and the platform team that runs the Claude tenant or cloud accounts. In Germany add the works council. One person can hold two roles, but the approver must never be the requester.

The roles map to legal hooks. The DPO’s tasks under Article 39(1) GDPR include informing and advising the controller and monitoring compliance, so the DPO advises and checks but should not sign off business risk. Article 26(2) AI Act requires deployers of high-risk systems to assign human oversight to people with “the necessary competence, training and authority”, which is a named person per use case, not a committee. Article 26(7) requires employers to inform workers’ representatives before a high-risk system is used at the workplace.

Activity	Business owner	AI governance lead	DPO	Security	Platform team	Works council (DE)
Submit use case and data inventory	R/A	C	I	I	I
AI Act risk tiering	C	R/A	C
DPIA screening and DPIA	C	C	R (advises)	C
Approve model, region and access	C	A	C	R	R
Configure SSO, roles, allowlists, budgets	I	I		C	R/A
Employee monitoring check, co-determination	C	R	C			A (consent)
Human oversight in operation	R/A	C
Quarterly review and evidence pack	C	R/A	C	C	R	I

R = responsible, A = accountable, C = consulted, I = informed. This RACI is our recommendation, not a legal template. Adapt it to your existing ISMS roles instead of inventing a parallel structure.

How should the approval workflow for a new use case run?

Approve use cases, not tools. A request to “use Claude” is meaningless for risk; a request to “summarise inbound support tickets with Claude Sonnet via Bedrock EU” can be tiered in ten minutes. The workflow below sends low-risk cases through a fast lane and stops only what touches Annex III or personal data at scale.

1. Intake. The business owner describes purpose, users, data categories, the Claude surface (Enterprise chat, API, Claude Code, Bedrock, Vertex) and whether outputs affect decisions about people.
2. Risk tiering. The AI governance lead checks the AI Act tiers: prohibited practice, Annex III high-risk, transparency case, or minimal risk. Employment uses are explicit in Annex III point 4: recruitment and selection, decisions on promotion or termination, task allocation based on behaviour, and monitoring of performance. Creditworthiness checks of natural persons sit in point 5(b).
3. Data protection screening. The DPO decides whether a DPIA under Article 35 GDPR is required and whether the processor contract covers the chosen surface.
4. Security review. Security confirms the access model (SSO group, IAM role, service account), the region profile and logging.
5. Decision and record. The accountable approver signs, with an expiry date. We recommend 12 months for minimal risk and a shorter cycle for anything high-risk.
6. Enforcement. The platform team adds the model to the allowlist, maps the SSO group and sets a budget. No control change without a ticket that references the approval.
7. Review. At expiry or after a material change (new model, new data category, new user group), the case goes back to step 2.

Two outputs of step 2 change the workload. If the use case is Annex III and you are a public body or a private entity providing public services, Article 27 adds a fundamental rights impact assessment before deployment. If staff publish Claude-generated text to inform the public on matters of public interest, Article 50(4) requires disclosure unless the text went through human review and someone holds editorial responsibility.

Which Claude controls enforce the decisions?

Governance decisions only hold if a control enforces them. Claude Enterprise gives you identity, roles, spend limits and audit logs at the tenant level. Bedrock and Vertex give you organisation-wide model allowlists and request logging. Pick the controls by surface: chat users live in Claude Enterprise, applications live in your cloud account.

Claude Enterprise. The roles and permissions page lists four roles: Primary Owner (only one per organisation), Owner, Admin and User. On Enterprise, only Owners and Primary Owners manage SSO, request audit logs and manage data retention. Admins cannot invite or remove other admins or change roles, which is the separation of duties you want. Custom roles take permissions from group assignments. Groups can sync from your identity provider via SCIM (nested groups are ignored) and carry per-user monthly spend limits; an individual limit overrides a group limit. Audit logs are Enterprise only, an export covers the past 180 days, and the download link expires after 24 hours. Logs show identifiers, not chat titles or content. Organisations using customer-managed keys use the Compliance API instead. One residency note: the Enterprise overview lists US-only inference as an option; we found no EU-only inference option on that page.

Amazon Bedrock. AWS states that model access is enabled by default with the right Marketplace permissions in all commercial Regions. Governance therefore starts with a deny. AWS also notes that denying aws-marketplace:Subscribe alone does not block the first call, because Bedrock starts the subscription automatically. Deny bedrock:InvokeModel at SCP or IAM level instead. The deny-inference example can be used as an SCP, and denying InvokeModel also blocks Converse and StartAsyncInvoke. The inference profile docs show how to block global routing:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyGlobalRouting",
      "Effect": "Deny",
      "Action": ["bedrock:InvokeModel*"],
      "Resource": "*",
      "Condition": { "StringEquals": { "aws:RequestedRegion": "unspecified" } }
    },
    {
      "Sid": "DenyUnapprovedModel",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:CreateModelInvocationJob"
      ],
      "Resource": "arn:aws:bedrock:*::foundation-model/MODEL_ID_NOT_APPROVED"
    }
  ]
}

Test it in a sandbox OU before attaching it to production. Model invocation logging is disabled by default, writes only to S3 or CloudWatch in the same account and Region, and covers only the bedrock-runtime endpoint, not bedrock-mantle. Request and response bodies up to 100 KB sit inline in the log record. Which profiles keep data in the EU is covered in our Claude on AWS Bedrock EU guide.

Google Cloud (Vertex AI). Google now files this under Gemini Enterprise Agent Platform. The Model Garden policy uses the constraint vertexai.allowedModels at organisation, folder or project level. Without a policy, all models and actions are allowed. An explicit deny wins over an allow, each model must be listed individually, and a policy holds at most 500 values. Partner model features web_search and structured_outputs are off by default for projects in an organisation and are switched on through vertexai.allowedPartnerModelFeatures.

name: organizations/ORGANIZATION_ID/policies/vertexai.allowedModels
spec:
  rules:
    - values:
        allowedValues:
          - publishers/anthropic/models/APPROVED_MODEL_NAME:predict

An allow list implicitly denies every other model, which is the posture we recommend for production folders. EU endpoint choice for Claude on Google Cloud is in our Claude on Vertex AI Europe guide.

NIST AI RMF, ISO 42001 or the AI Act: which framework do you follow?

You follow the AI Act because it is law. You borrow structure from NIST AI RMF because it is free and practical. You adopt ISO/IEC 42001 if customers or auditors ask for a management system they can test. For most EU mid-sized companies we recommend AI Act duties as the floor and ISO 42001 as the target structure, with NIST as the workbook.

	EU AI Act	NIST AI RMF	ISO/IEC 42001
Nature	Regulation (EU) 2024/1689, binding	Voluntary framework	International standard with requirements
Published	OJ 2024; Omnibus 2026/1744 published 24 July 2026	AI RMF 1.0 on 26 January 2023; GenAI profile NIST AI 600-1 on 26 July 2024	Edition 1, December 2023, 51 pages
Cost to access	Free on EUR-Lex	Free	CHF 225 on iso.org
Core structure	Roles (provider, deployer), risk tiers, duties per tier	Four functions: Govern, Map, Measure, Manage	AI management system: establish, implement, maintain, improve
What it gives a Claude programme	Legal duties: literacy, transparency, high-risk deployer duties, logging	Risk vocabulary and actions, GenAI-specific risks	Auditable management system that fits next to ISO 27001
Penalty or consequence	Up to EUR 15 000 000 or 3 % of turnover for operator duties such as Article 26	None	No legal penalty

Two points from the sources. NIST states the AI RMF is “intended for voluntary use”. The ISO page describes 42001 as specifying requirements for establishing, implementing, maintaining and continually improving an AI management system, for organisations that provide or use AI. Neither replaces the AI Act. Article 99(4) fines for deployer duties under Article 26 reach EUR 15 000 000 or 3 % of worldwide annual turnover, whichever is higher.

Run it yourself or outsource?

Run the decisions yourself; outsource the plumbing if you lack the people. Accountability for approvals, risk tiering and human oversight cannot move to a vendor under the AI Act, because Article 26 binds the deployer. What can move is the recurring work: board preparation, control configuration, log reviews and evidence collection.

What operating Claude governance in-house involves, by our estimate for a company with 5 to 15 Claude use cases (not a sourced figure):

Recurring task	Owner	Our effort estimate
Intake triage and risk tiering	AI governance lead	1 to 2 hours per new use case
Governance board meeting	Lead, DPO, security, owners	Monthly, 1 hour plus preparation
Control changes (SSO groups, allowlists, budgets)	Platform team	2 to 4 hours per month
Audit log export and review	Security	Monthly; Claude exports cover 180 days, so a missed quarter loses data
Evidence pack for auditors	Lead plus platform team	2 to 3 days per year

Outsourcing makes sense when nobody internally can read both an SCP and Annex III, when you run Claude on several surfaces (Enterprise, Bedrock and Vertex at once), or when an ISO 42001 audit is due within months. It does not make sense for a single low-risk use case on Claude Enterprise; the built-in roles and audit logs are enough, and a provider adds a party to your data flows.

What to demand from a provider for this topic:

• Access model. Read-only access to audit logs and cloud configuration by default, write access only through your change process. No standing Owner role in your Claude tenant.
• Data processing agreement. A DPA under Article 28 GDPR if the provider sees prompts, logs or user data, plus a current subprocessor list.
• SLA. Response times for access revocation and incident support, and a fixed cadence for log reviews.
• Evidence ownership. Approvals, RACI and evidence packs stored in your systems, not the provider’s.
• Exit. Documented configuration (SCPs, org policies, SSO mappings) handed over in a format your team can apply without the provider.

For the cost side of the Claude surfaces themselves, see our comparison of Claude Enterprise and Bedrock in the EU.

FAQ

Does a company using Claude need an AI governance framework under the AI Act?

The AI Act does not use the term, but its deployer duties require the pieces. Article 4 asks for literacy measures, Article 26 asks high-risk deployers for named human oversight, log retention of at least six months and informing workers’ representatives. You cannot meet those without roles, an approval gate and logs.

What does AI governance for Claude cost?

The main cost is people time, not licences. NIST AI RMF and the AI Act text are free. ISO/IEC 42001 costs CHF 225 to buy on iso.org; implementation work and any external audit come on top. Claude Enterprise lists audit logs, SCIM and spend limits as features of the Enterprise plan.

NIST AI RMF vs ISO 42001: which one should an EU company pick?

Pick ISO/IEC 42001 if you already run ISO 27001 or customers ask for an auditable AI management system. Pick NIST AI RMF as a free workbook if you need structure fast without an audit. Both sit on top of the AI Act, which remains mandatory either way.

Who should approve a new Claude use case?

The AI governance lead or a governance board is accountable, the business owner requests it, and the DPO and security are consulted. The requester should never approve their own case. For employment uses listed in Annex III point 4 in Germany, involve the works council before rollout.

How long must we keep Claude logs?

For high-risk systems, Article 26(6) AI Act requires deployers to keep automatically generated logs under their control for at least six months, unless other law says otherwise. Claude Enterprise audit log exports reach back 180 days, so schedule exports. On Bedrock, invocation logs stay until you delete the logging configuration.

Does the works council have a say in Claude rollouts in Germany?

Often yes. Section 87(1) no. 6 of the Works Constitution Act gives co-determination on technical systems designed to monitor employee behaviour or performance, and Claude audit logs record user activity. For high-risk workplace systems, Article 26(7) AI Act adds a duty to inform workers’ representatives.

Sources

1. EUR-Lex: Regulation (EU) 2024/1689 (AI Act) (1 October 2026)
2. EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI) (1 October 2026)
3. EUR-Lex: Regulation (EU) 2016/679 (GDPR) (1 October 2026)
4. NIST: AI Risk Management Framework (1 October 2026)
5. ISO: ISO/IEC 42001:2023 (1 October 2026)
6. Claude Help Center: Roles and permissions (1 October 2026)
7. Claude Help Center: Access audit logs (1 October 2026)
8. Claude Help Center: Groups and group spend limits (1 October 2026)
9. Claude Help Center: What is the Enterprise plan? (1 October 2026)
10. AWS: Bedrock model access (1 October 2026)
11. AWS: Bedrock identity-based policy examples (1 October 2026)
12. AWS: Inference profile prerequisites (1 October 2026)
13. AWS: Bedrock model invocation logging (1 October 2026)
14. Gesetze im Internet: Section 87 BetrVG (1 October 2026)
15. Google Cloud: Control access to Model Garden models (1 October 2026)