Enterprise AI governance for Claude Code at SME scale

For a European SME with ten developers and a security officer who is also the CTO, Claude Code governance is usually one of two problems: there is no policy, or there is a wiki page nobody follows. The individual developer already has excellent security documentation. The gap is the org layer — the shared usage charter, the MCP server approval workflow, the guardrail tiers, the CI/CD gates, the audit trail a NIS2 or SOC 2 auditor will ask to see. This post is the lean template a Spanish SME can adopt in a week, not a six-month governance programme.

Local usage vs. shared usage — where the risk actually changes

The first governance decision is to stop treating all Claude Code usage as one thing. A developer using Claude Code on their own laptop against their own scratch code is a very different risk posture from a team running Claude Code against a shared repo that touches customer data. Conflating the two produces the wiki page nobody follows — either too strict for the first case or too loose for the second.

For an SME in NIS2 scope under Directive (EU) 2022/2555, the shared-usage column is where compliance obligations land — cybersecurity risk management, incident handling, supply-chain security. The local column is a productivity tool; the shared column is a governed asset. Writing the policy around that split is the whole game.

The lean usage charter — five fields, one page

A usage charter that fits on one page gets read. A charter that reads like an ISO annex does not. The five fields the SME actually needs are:

1. Approved models and modes. Which Claude models are cleared, under which API path (Anthropic hosted, AWS Bedrock, etc.), and whether local-only mode is required for sensitive repos.
2. Data-handling rules. What can and cannot be sent to the model — a concrete list, not a principle. For a Spanish SME: “Never paste customer PII, customer-identifying logs, secrets, or content tagged confidential in the repo’s CODEOWNERS into a Claude Code session against a hosted model.”
3. MCP server allowlist. Which MCP servers are approved, who approved them, and the date of last review. MCPs are the supply-chain surface — an unvetted MCP is an unvetted dependency.
4. Prohibited usage. Explicit list of disallowed actions (auto-merge without human review, production database writes from a Claude Code session, running Claude Code against an air-gapped client’s code on a non-air-gapped machine).
5. Escalation path. Who approves exceptions, who owns incident response when a Claude Code session goes wrong, what the disclosure process looks like.

For the AI literacy obligation under Article 4 of the EU AI Act, the charter is also the artefact the SME points to when a supervisory authority asks how staff are trained on acceptable AI use. AESIA is the Spanish reference authority for AI oversight, and ENS-scope public-sector clients will ask about the charter directly during due diligence.

MCP governance, guardrail tiers, and CI/CD gates

MCP servers are where a lot of SME governance goes silently wrong. A developer installs a useful MCP, nobody reviews it, it reads the repo, and now the SME has a supply-chain dependency nobody knows about. The fix is a simple approval register — not bureaucracy, a single YAML file in the repo:

# .claude/mcp-registry.yml
approved_mcps:
  - name: github-official
    source: https://github.com/modelcontextprotocol/servers
    approved_by: cto@example.es
    approved_on: 2026-03-12
    last_review: 2026-04-12
    allowed_in: [local, shared]
  - name: jira-internal
    source: internal/mcp-jira
    approved_by: cto@example.es
    approved_on: 2026-04-02
    last_review: 2026-04-02
    allowed_in: [shared]

Guardrail tiers let one settings.json apply across multiple risk contexts. The tier defines which file patterns are write-denied, which commands are blocked, and which require approval:

• Tier 1 — Exploration. Local scratch work, generous defaults.
• Tier 2 — Product development. Most of the work. Deny list on secrets, infra configs, and migrations without approval.
• Tier 3 — Regulated repo. Customer-data handling, payment flows, GDPR-sensitive code. Deny list on all destructive ops; every change goes through review.
• Tier 4 — Air-gapped / ENS. No hosted model, no MCP external calls, local inference only.

CI/CD gates are the enforcement layer. A GitHub Action that blocks any PR touching .claude/settings.json or .claude/mcp-registry.yml without a CODEOWNER approval from the security officer is ten lines of YAML and prevents the most common governance drift.

For the audit trail, the same CI/CD pipeline can write a per-PR record of the Claude-Code-assisted commits into an append-only log — exactly what a NIS2 auditor or a NIST AI Risk Management Framework assessor will want to see when they ask how the SME tracks AI contributions to code.

The onboarding and quarterly-review cadence

Policy that isn’t reviewed decays. The lean cadence that works for a ten-person SME is:

• Onboarding (day one). New developer reads the charter, signs it, gets added to the Claude Code org with Tier 1 defaults. Their first PR includes a CODEOWNER review from the engineering lead.
• Tier graduation. Moving from Tier 1 to Tier 2 is automatic after two weeks of clean commits. Moving from Tier 2 to Tier 3 requires the security officer to confirm the developer has signed the data-handling annex.
• Quarterly review. MCP registry gets re-reviewed (is each MCP still in use, still maintained?). Incident log is scanned for patterns. Charter is amended based on actual failures, not hypothetical ones.

Spanish SMEs pursuing a Kit Digital deployment through an Agente Digitalizador can fold the governance artefact into the project deliverable — the Kit Digital IA/BI category covers documentation of AI-governance measures as part of a qualifying solution, which means the SME gets the charter and the voucher reimbursement in the same project.

Ready to get started?

Working on this yourself? J4SGON S.L. delivers Docebo Connect, HRIS, SSO and migration work for European organisations — see what a scoped engagement covers or describe your project and we will reply with a written scope.