ADVNT FOUNDRY · We build AI-native companies · Flagship engagements start at $1M
    Whitepaper · v1.0For CISOs, GRC, AI Risk Committees

    The Enterprise AI Governance
    Framework for Claude.

    A practitioner's guide to standing up an AI governance framework that a regulator can query, a board can sign, and an engineering team can ship. Organized around a six-layer governance model — the same shape A/DVNT uses to deploy the AI Governance Layer for Claude inside enterprise perimeters.

    Layers
    L1 → L6
    Standards mapped
    NIST · ISO 42001 · EU AI Act
    Audit coverage
    100%
    Reading time
    ~14 min

    Most enterprises have an AI policy.
    Almost none have an AI governance framework.

    A policy is a document. A framework is the set of layers — principle, mapping, policy, runtime, audit, operations — that make the policy actually run, be proven, and survive a model change, a regulator visit, or a board challenge. Without all six, governance lives in slide decks while the AI lives in production.

    This guide describes a six-layer governance model: a reference architecture for enterprise AI governance, written for Claude deployments but model-agnostic in shape. Each layer has a single owner, a single artifact, and a single test for whether it exists.

    If you are standing up an AI Risk Committee, drafting a Claude governance program, or preparing for an ISO 42001 audit, the framework below is what you are trying to build.

    Six layers. One stack.

    Each layer is necessary; none is sufficient on its own. The framework reads from the top down (board to runtime) and proves from the bottom up (audit to principle).

    L1 · Governance Principles

    Why

    The non-negotiables. Human dignity, lawful purpose, data sovereignty, refusal-by-default for out-of-scope actions. Signed by the board, owned by the CISO. L1 doesn't change with the model or the quarter — it changes when the company changes.

    L2 · Regulatory Mapping

    What we must satisfy

    Each L1 principle is mapped to specific external obligations: NIST AI RMF (Govern / Map / Measure / Manage), ISO/IEC 42001 clauses, EU AI Act Annex III categories, SOC 2 / ISO 27001 controls, and sector rules (HIPAA, PCI, SR 11-7, NYDFS 500).

    L3 · Operating Policy

    What the AI may do

    Machine-readable rules. Categorizes every AI action as read / write / escalate / refuse. Defines per-domain scopes (finance, HR, customer data, source code) and the consent tier required for each. This is the layer policy teams edit.

    L4 · Runtime Enforcement

    How it gets enforced

    Code that sits between the prompt and the model — and between the model and every tool call. Evaluates each action against L3 before execution. Cannot be ignored, forgotten, or argued with. If L3 says no, the action does not execute.

    L5 · Audit & Evidence

    How we prove it

    Append-only log of every prompt, tool call, consent decision, output, and downstream side effect. Attributed to a human identity via your IdP. Persists on managed Postgres inside your perimeter on your retention schedule.

    L6 · Governance Operations

    Who holds the pen

    The human process around the stack: AI Risk Committee cadence, model-change review, incident response, periodic policy review, red-team scheduling, and the escalation path when an agent hits an L3 refusal.

    L1. Governance Principles.

    The non-negotiables. Human dignity, lawful purpose, data sovereignty, refusal-by-default for out-of-scope actions. Signed by the board, owned by the CISO. L1 doesn't change with the model or the quarter — it changes when the company changes.

    Artifact: Signed YAML preamble, board-attested, immutable in production without an L1 amendment vote.

    Test for existence: Can you produce a signed, board-attested document naming your AI governance principles? Yes or no.

    L2. Regulatory Mapping.

    Each L1 principle is mapped to specific external obligations: NIST AI RMF (Govern / Map / Measure / Manage), ISO/IEC 42001 clauses, EU AI Act Annex III categories, SOC 2 / ISO 27001 controls, and sector rules (HIPAA, PCI, SR 11-7, NYDFS 500).

    Artifact: Control-mapping matrix — every control row points to the L3 policy that enforces it and the L5 audit query that proves it.

    Test for existence: Can you produce a single matrix that maps every external obligation to a row in your internal framework? Yes or no.

    L3. Operating Policy.

    Machine-readable rules. Categorizes every AI action as read / write / escalate / refuse. Defines per-domain scopes (finance, HR, customer data, source code) and the consent tier required for each. This is the layer policy teams edit.

    Artifact: Signed, versioned policy bundle in Git. Change-controlled via pull request, reviewable by legal before deploy.

    Test for existence: Is your AI policy expressed as machine-readable, version-controlled rules — not paragraphs in a PDF? Yes or no.

    L4. Runtime Enforcement.

    Code that sits between the prompt and the model — and between the model and every tool call. Evaluates each action against L3 before execution. Cannot be ignored, forgotten, or argued with. If L3 says no, the action does not execute.

    Artifact: Policy engine running inside your VPC. Sub-50ms decision latency. Kill-switch propagates to running agents.

    Test for existence: If an AI action violates policy, is it blocked at runtime — not flagged after the fact? Yes or no.

    L5. Audit & Evidence.

    Append-only log of every prompt, tool call, consent decision, output, and downstream side effect. Attributed to a human identity via your IdP. Persists on managed Postgres inside your perimeter on your retention schedule.

    Artifact: Queryable audit tables. Pre-built evidence queries for each L2 control. Exportable to your SIEM.

    Test for existence: For any AI action in the last 90 days, can you produce actor, prompt, decision, output, and downstream effect in under five minutes? Yes or no.

    L6. Governance Operations.

    The human process around the stack: AI Risk Committee cadence, model-change review, incident response, periodic policy review, red-team scheduling, and the escalation path when an agent hits an L3 refusal.

    Artifact: Quarterly governance review pack auto-generated from L5 audit data. Standing AI Risk Committee charter.

    Test for existence: Is there a standing committee that reviews this framework on a fixed cadence, with attendance recorded? Yes or no.

    One framework. Every audit.

    L2 is where one internal framework becomes evidence for many external standards. Below is the standard mapping shipped with the A/DVNT deployment — each control row resolves to an L3 policy and an L5 audit query.

    NIST AI RMF

    Govern, Map, Measure, Manage. Govern maps to L1 + L6. Map maps to L2 + L3. Measure and Manage map to L4 + L5. Every RMF subcategory has a corresponding audit query.

    ISO/IEC 42001

    Clause 4 (context) and 5 (leadership) ride on L1. Clause 6 (planning) on L2. Clauses 7-8 (support, operation) on L3-L4. Clause 9 (performance evaluation) on L5. Clause 10 (improvement) on L6.

    EU AI Act

    High-risk system obligations (Annex III) — risk management, data governance, human oversight, accuracy, robustness — each have a designated L3 policy bundle and L5 evidence pack.

    SOC 2 · ISO 27001

    Existing IT control families (access, change, monitoring) extend to AI actions via L4 enforcement and L5 audit. AI inherits, rather than bypasses, the existing control plane.

    What governance without a framework looks like.

    Common failure modes — each one is a missing or collapsed layer.

    Policy without runtime

    L1, L2, L3 exist on paper. L4 doesn't exist. The rules are real, the enforcement is fiction. First incident proves it.

    Runtime without audit

    Guardrails block actions but nobody can prove what was blocked, who tried, or why. The auditor asks for evidence and you have logs in three different vendor consoles.

    Framework without owner

    Every layer exists but no L6 cadence. Constitution drifts, mappings rot, policy gets out of sync with reality. Framework decays into shelfware in twelve months.

    Compliance-only framing

    Designed solely to pass an audit. No governance principles. First time the business asks a question the audit didn't anticipate, the framework has no answer.

    How to stand it up. In a quarter.

    A realistic sequence for an enterprise standing up its first end-to-end AI governance framework for Claude.

    Weeks 1-2 · L1 + L6 charter

    Draft governance principles. Stand up the AI Risk Committee. Identify owners for each layer. Sign the L1 preamble.

    Weeks 3-4 · L2 mapping

    Map L1 to NIST AI RMF, ISO 42001, EU AI Act, and sector rules. Produce the control matrix. Identify gaps in existing IT controls.

    Weeks 5-8 · L3 + L4 deploy

    Author the policy bundle. Stand up the runtime inside your VPC. Wire auth to your IdP. Begin shadow-mode enforcement on a single Claude workspace.

    Weeks 9-12 · L5 evidence + go-live

    Light up audit. Pre-build evidence queries for each L2 control. Move runtime from shadow to enforcing. First quarterly governance review pack at day 90.

    // Questions

    Every question about pricing, deployment, governance, and platform mechanics lives on one page — filterable by theme.

    See the full FAQ →

    See the framework running.

    The six-layer governance model is the reference architecture. The AI Governance Layer for Claude is the deployment that ships all six layers — constitution, mapping, policy, runtime, audit, and the governance ops cadence on top — inside your perimeter, live in under 60 minutes.

    ADVNT FoundryDiscover · Build · Operate · Transfer

    Build the company. Operate the system.

    ADVNT designs, builds and operates AI-native companies, digital ecosystems and enterprise operating systems.

    Flagship engagements start at $1M · Qualified through briefing and SOW