AI tool governance: 4 tiers for European SMEs

A regulated Spanish SME running Claude Code in production has a problem most blog posts skip: nobody can tell them which controls are excessive and which are required. The default advice — “use a deny list” — is true for everyone and useful to nobody. This piece walks through a 4-tier governance model that tells SME ops leads exactly which controls to apply at which risk level, with concrete checklists drawn from GDPR Article 30 and ENS (Esquema Nacional de Seguridad) requirements.

Why uniform controls produce shadow IT

The fastest way to produce shadow IT in a 25-person company is to apply Tier-4 regulated-environment controls to a developer’s personal scratch project. Engineers route around restrictive policies, the org loses visibility, and the policy fails the only test that matters. The opposite mistake is equally common: a Spanish SME taking on a public-sector client under ENS Medio compliance keeps using its starter-tier configuration and trips the first audit.

The fix is to match the control level to the actual risk surface. A solo developer iterating on a local Python script that never sees production needs CLAUDE.md guidelines and a hook that blocks rm -rf /. A finance app that processes Spanish citizen data needs everything that scratch project has, plus a deny list, plus an approval workflow, plus a session audit trail, plus mapped controls for ENS, EU AI Act Article 14 human oversight, and the GDPR records-of-processing register.

The 4-tier model below is the routing table that tells you which controls to apply where.

The 4 tiers and the controls each one adds

flowchart TD
    A[What are you governing?] --> B{Risk surface}

    B --> P[Personal dev<br/>Local, throwaway]
    B --> T[Team codebase<br/>Shared repo, not prod]
    B --> PR[Production<br/>Customer-facing, real data]
    B --> REG[Regulated<br/>ENS, GDPR Art. 9, finance, health]

    P --> T1[Tier 1: Starter<br/>CLAUDE.md + dangerous-actions hook<br/>10 min setup]
    T --> T2[Tier 2: Standard<br/>Shared settings.json + MCP registry<br/>+ PR gates + audit log]
    PR --> T3[Tier 3: Strict<br/>Permission deny list<br/>+ approval workflow<br/>+ session audit trail]
    REG --> T4[Tier 4: Regulated<br/>All of above<br/>+ compliance audit trail<br/>+ ENS / SOC 2 / ISO 27001 mapping]

Tier 1 is for a single operator working on code that does not touch production data. Setup is 10 minutes: a CLAUDE.md with team conventions and a hook that blocks destructive shell commands. Anyone tightening this further is solving a problem they do not have.

Tier 2 adds shared configuration — settings.json checked into the repo, an MCP registry that lists which tool servers the team has approved, and CI gates that block PRs which violate the conventions. The audit log here is lightweight: who ran what, when, against what branch.

Tier 3 hardens the surface for production. The deny list is explicit — no shell access to credentials directories, no network calls to non-allowlisted hosts, no auto-execution of database migrations. An approval workflow gates any AI-initiated change to infrastructure. Session audit trails capture every prompt and response for incident reconstruction.

Tier 4 is the regulated tier and adds the documentation layer. Every Tier 3 control gets mapped to an external framework — ENS Medio for Spanish public-sector work, SOC 2 Trust Service Criteria for international clients, ISO 27001 for buyers that ask. The compliance audit trail is queryable by date range and exportable to whatever evidence format the auditor wants.

What you can and cannot control

This boundary matters for SME governance because it determines what sits in policy versus what sits in tooling. The things you cannot technically prevent — personal API keys, personal projects, personal ~/.claude config — get covered by the acceptable-use policy and the employment contract, not by deny lists. The things you can technically prevent get covered by the deny lists and the CI gates, and the policy just points at them.

For Spanish SMEs working under Kit Digital Categoría Inteligencia Artificial (vouchers up to €12,000), the audit-trail requirement maps directly to Tier 2 or higher — Tier 1 will not satisfy a digitising agent’s evidence package. Build for Tier 2 from day one if you intend to claim the voucher.

How to walk a real SME up the tiers

Most 10-50-person Spanish companies start at Tier 1, move to Tier 2 when their second engineer joins the codebase, and pause there. They reach Tier 3 the day they take a contract that involves customer data — usually 12-18 months in. They reach Tier 4 only if they take regulated work; many never do, and that is fine.

The mistake to avoid is jumping tiers. Going from Tier 1 to Tier 4 in one weekend produces a config nobody on the team understands, which means nobody can debug it, which means the first awkward error gets resolved by disabling the controls. Step through Tier 2 and Tier 3, get the team comfortable with each level, and only then add the regulatory mapping.

The second mistake is treating tier selection as a developer decision. The risk surface is a business question — does this codebase touch customer data? does this client require ENS? — and the answer should come from the founder or the compliance lead, not from whoever is fastest at writing settings files.

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.