Governance framework · v1.0 · 25 September 2026

Enterprise AI Governance Framework

This framework is the governance operating model that runs on the AI operating layer: roles, decision rights, controls, evidence and cadence. It turns the reference architecture into accountable decisions. It is written for boards, CIOs, CISOs, CROs, DPOs, internal auditors and every deployer carrying duties under the EU AI Act.

How to cite this document

0 · Status and conventions

A public, versioned governance model, testable by a third party.

The AI Operating Layer Reference Architecture specifies what the layer must do. This framework specifies who decides, who answers, and what evidence proves each decision was taken.

In this document, "we" means Hikari Blue, the firm that installs this framework on client engagements and hands it over. The word "must" marks a requirement; the word "should" marks a practice a deployer may replace with a recorded equivalent.

The AI governance page explains why governance is architecture. This document is the versioned, citable framework that page refers to: identifiers, owners, cadences and pass criteria.

Regulatory hooks cite Regulation (EU) 2024/1689, the EU AI Act, on EUR-Lex (opens in a new tab), and Regulation (EU) 2016/679, the GDPR, on EUR-Lex (opens in a new tab). The AI Act application calendar is tracked on the definition page, so this framework stays valid when the calendar moves.

1 · Principles

Eight principles, each tied to an architecture property or a legal duty.

A principle that maps to nothing enforceable is a value statement. Each principle below names the plane of the reference architecture that enforces it, or the obligation that requires it.

  1. 01

    Govern the action, not the model

    Governance applies to each task a model or agent performs, because the EU AI Act places operational duties on the deployer that runs the workflow (Article 26).

  2. 02

    No policy without an enforcement point

    Every written rule must correspond to a policy evaluated at runtime by the policy and governance plane, or it is recorded as an open gap.

  3. 03

    Evidence is produced at the moment of action

    The evidence and audit plane writes the record as the action happens, which is what Article 12 means by automatic recording over the system's lifetime.

  4. 04

    One named human per consequential decision

    A named verifier approves, rejects or overrides consequential outputs. That gives effect to the human oversight of Article 14 of the AI Act, and to the GDPR Article 22 limit on solely automated decisions about a person.

  5. 05

    Stopping is cheap, restarting is deliberate

    Any named operator or verifier can halt through the control plane, while restart needs the risk owner, matching the Article 14 duty to interrupt a system through a stop procedure.

  6. 06

    Provider choice is a governed, reversible decision

    The routing and runtime plane makes model choice a recorded configuration, which keeps ICT third-party concentration under control as DORA and NIS2 expect.

  7. 07

    Sovereignty is enforced per workload

    Residency corridors and key custody are declared per workload and enforced at runtime, giving the GDPR Article 35 impact assessment facts rather than intentions.

  8. 08

    Governance transfers with the layer

    Roles, controls and evidence move to the client team on a dated plan, because the operating model of the reference architecture ends with the client running the layer.

2 · Roles and decision rights

Seven roles, one accountable name per decision.

The framework defines roles, not job titles. One person may hold several roles in a small deployment, except that a verifier never approves an output of a workflow they own.

  • Board

    Sets the AI risk appetite, approves the use-case classes the enterprise accepts, and receives the quarterly board pack. It can ask for the records behind any figure.

  • Accountable executive

    One named member of the executive committee who answers for AI in production. Signs the board pack, owns regulator notifications, and arbitrates between business pressure and risk.

  • AI risk owner

    Second-line owner of the policy set, the risk classification and the incident register. Holds the authority to restart any system after a stop.

  • System owner

    First-line business owner of one workflow. Owns its agents, its routing choices, its instructions for use and the designation of its human verifiers.

  • Human verifier

    A named, trained person who approves, rejects or overrides a consequential output. The decision is written into the record, with identity and reason.

  • Operator

    The team that runs the layer: policy deployment, model changes, on call, kill switch drills. During an engagement it may include us; after transfer it is the client team.

  • Model provider

    An external supplier of foundation models, governed as an ICT third party. It supplies instructions for use and receives incident information; it never holds deployer duties.

3 · Decision rights

Ten decisions, each with one accountable role.

The table follows the RACI convention: one role is accountable, one is responsible for execution, others are consulted before or informed after. Two accountable names on one decision means none.

Decision Accountable Responsible Consulted · Informed
Set AI risk appetite and accepted use-case classes Board Accountable executive C: AI risk owner, DPO, CISO · I: internal audit
Approve a workflow for production Accountable executive System owner C: AI risk owner, DPO, CISO · I: board, through the board pack
Set or change a policy or residency corridor AI risk owner Operator C: DPO, CISO · I: system owner
Select or switch a model provider System owner Operator C: AI risk owner, CISO · I: model provider
Create an agent identity and its tool scope System owner Operator C: CISO · I: AI risk owner
Approve, reject or override a consequential output Human verifier Human verifier C: system owner · I: recorded in the trail
Trigger the kill switch Any named operator or verifier Operator I: system owner, AI risk owner, accountable executive
Restart after a stop AI risk owner Operator C: system owner · I: accountable executive
Notify a regulator or the provider of an incident Accountable executive AI risk owner C: DPO, CISO, legal · I: board, model provider
Issue the quarterly board pack Accountable executive AI risk owner C: internal audit · I: board

Internal audit stays independent of every row it is consulted on: it tests the controls, it never operates them. The split between first line, second line and internal audit follows the Institute of Internal Auditors' Three Lines Model (2020). The DPO role and its independence come from GDPR Articles 37 to 39.

4.1 · Control catalogue · Domain P

Fifteen controls in four domains. Domain P: policy and model selection.

Each control carries a stable identifier, a statement, the artefact that evidences it, an owner, a cadence and its regulatory hook. An auditor tests a control by asking for the artefact, never for a presentation about it.

  • GOV-P-01 · Use-case register and classification

    Statement. Every AI use case is registered and classified before build, including whether it is high-risk and whether a fundamental rights impact assessment applies.

    Evidence. The use-case register, with the classification rationale signed by the AI risk owner.

    Owner and cadence. AI risk owner; at intake, reviewed quarterly.

    Regulatory hook. AI Act Articles 26 and 27; Article 9 when the enterprise builds a high-risk system itself.

  • GOV-P-02 · Policy as code

    Statement. Every rule on model, data and approval is a versioned policy evaluated at runtime; a written rule without an enforcement point is logged as a gap.

    Evidence. The policy repository, its version history and the approval of each version.

    Owner and cadence. AI risk owner for content, operator for deployment; per change, reviewed quarterly.

    Regulatory hook. AI Act Article 9 risk management and Article 26 deployer duties.

  • GOV-P-03 · Model selection and change control

    Statement. Each task class declares a primary model, a fallback and a residency corridor; any change is an approved configuration change recorded in the trail.

    Evidence. The routing table, the model catalog and the change entries in the trail.

    Owner and cadence. System owner; per change, with a quarterly provider review.

    Regulatory hook. DORA ICT third-party risk management; NIS2 supply chain security measures.

  • GOV-P-04 · Instructions for use and transparency

    Statement. The deployer holds the provider's instructions for use, operates each workflow inside them, and informs affected people where the Act requires.

    Evidence. One instructions-for-use file per system and the notice texts shown to affected people.

    Owner and cadence. System owner; at onboarding and at each model version change.

    Regulatory hook. AI Act Article 13 transparency and Article 26 use in accordance with instructions.

4.2 · Control catalogue · Domain D

Domain D: data and sovereignty.

Three controls keep data where the enterprise decided it lives, and keep personal data out of the trail itself.

  • GOV-D-01 · Residency corridor per workload

    Statement. Every workload declares where compute, storage, inference and keys sit; the layer denies and logs any out-of-corridor call.

    Evidence. The residency map and the denial log.

    Owner and cadence. CISO, with the DPO consulted; enforced per action, denials reviewed weekly.

    Regulatory hook. GDPR Article 35; sector residency postures published in the Trust Center

  • GOV-D-02 · Impact assessments before production

    Statement. High-risk processing of personal data has a data protection impact assessment; deployers in scope complete a fundamental rights impact assessment before first use.

    Evidence. Signed assessments, linked to the use-case register entry they cover.

    Owner and cadence. DPO for the DPIA, AI risk owner for the FRIA; before production and on material change.

    Regulatory hook. GDPR Article 35; AI Act Article 27.

  • GOV-D-03 · Inputs by reference

    Statement. The trail stores inputs by reference or hash, and sensitive workloads run with zero cleartext data server-side where the architecture decision record requires it.

    Evidence. Record samples showing references only, and the architecture decision record.

    Owner and cadence. CISO; enforced per action, sampled quarterly.

    Regulatory hook. GDPR Article 35 measures addressing the risks identified.

4.3 · Control catalogue · Domain A

Domain A: agent authorization and stop.

Four controls make every agent attributable, bounded, supervised where consequence carries, and stoppable in one action.

  • GOV-A-01 · One identity per agent

    Statement. Every agent holds its own identity from the enterprise identity provider, never a shared service account, and appears in the agent register.

    Evidence. The agent register, reconciled against the identity provider.

    Owner and cadence. System owner; at creation, reconciled weekly.

    Regulatory hook. AI Act Article 12 traceability and Article 26 deployer monitoring.

  • GOV-A-02 · Declared scope and budget

    Statement. Each agent's tools, data and spend are declared; any call outside that scope is denied before execution and logged with the policy version that fired.

    Evidence. The permission matrix and the denial log.

    Owner and cadence. CISO; enforced per action, denials reviewed weekly.

    Regulatory hook. NIS2 cybersecurity risk management measures, including access control.

  • GOV-A-03 · Human verification of consequential outputs

    Statement. Outputs above a declared consequence threshold wait for a named verifier, who approves, rejects or overrides them before they take effect.

    Evidence. The human verification field of each record, and the verifier's competence record.

    Owner and cadence. System owner designates, verifier executes; per action.

    Regulatory hook. AI Act Articles 14 and 26; GDPR Article 22.

  • GOV-A-04 · Stop path and drill

    Statement. Every agent, model and workflow can be halted in one action by a named operator or verifier; restart requires the AI risk owner.

    Evidence. The kill switch runbook and its drill history, with measured halt times.

    Owner and cadence. Operator; per event, drilled quarterly.

    Regulatory hook. AI Act Article 14 stop procedure; Article 26 suspension of use when a risk appears.

4.4 · Control catalogue · Domain E

Domain E: evidence and reporting.

Four controls turn the trail into proof for a regulator, a board and an auditor, without manual assembly.

  • GOV-E-01 · Append-only, chained trail

    Statement. Each action writes one record with the nine fields of the reference architecture, chained by hash and retained no shorter than the legal floor.

    Evidence. The trail itself and the daily chain verification result.

    Owner and cadence. Operator; written per action, verified daily.

    Regulatory hook. AI Act Article 12 logging; Article 26 keeping of logs by deployers, at least six months.

  • GOV-E-02 · Dated literacy records

    Statement. Every person who operates or verifies holds a dated, role-resolved literacy record before access is granted.

    Evidence. Training records linked to the identities in the agent and operator registers.

    Owner and cadence. Accountable executive; before access, refreshed annually.

    Regulatory hook. AI Act Article 4 AI literacy.

  • GOV-E-03 · Monitoring and incident record

    Statement. Operation is monitored against declared thresholds; each incident opens a record with its notification decision per regime.

    Evidence. The incident register and the notifications sent to regulators and providers.

    Owner and cadence. AI risk owner; monitored daily, recorded per incident.

    Regulatory hook. AI Act Article 26 deployer monitoring and Article 72 provider post-market monitoring; DORA, NIS2 and GDPR incident reporting.

  • GOV-E-04 · Quarterly board pack

    Statement. A quarterly report is built from the trail, and every figure in it links to the records it aggregates.

    Evidence. The signed board pack and the board minute that received it.

    Owner and cadence. Accountable executive; quarterly.

    Regulatory hook. DORA management body responsibility for ICT risk; AI Act Article 26 monitoring.

The catalogue maps to the four controls C1 to C4 of the reference architecture. Domain P rests on C1, domain D on C3, domain A on C4, and domain E on C2. For a management-system certification path, the same controls sit inside ISO/IEC 42001:2023 and the Govern function of the NIST AI Risk Management Framework 1.0.

5 · Evidence and reporting

Three documents, all built from the trail, none written by hand.

The nine-field record of the reference architecture is the only primary source. The board pack, the regulator export and the incident record are views over it, so each figure can be traced to the actions it counts.

Document What it contains Record fields it draws on
Quarterly board pack Workflows in production and their risk class. Agents by identity and owner. Model mix by provider and corridor. Policy denials, human overrides and their trend. Kill switch drills with halt times. Incidents and notifications. Open control gaps, each with an owner and a date. All nine, aggregated. Every figure links to the records it counts, so a director can ask for the underlying evidence.
Regulator export Raw records for one system and one period, with the policy versions, the agent register and the literacy records in force at the time. All nine, unaggregated. The chain hashes travel with the file, so the recipient verifies integrity without trusting the sender.
Incident record Detection time, scope, stop action and halt time, notification decision per regime, root cause, fix, regression test, and a lessons-learned memo signed by a named person. A reference to the range of trail records concerned, never a copy. Actor identity, model and version, policy applied and timestamp locate the failure.

Notification windows under GDPR, DORA and NIS2 are pre-mapped per engagement and published in the Trust Center. Our engagement baseline retains the trail per contract, twelve months minimum, above the Article 26 floor of six months.

6 · Cadence

Five rhythms, from every action to every year.

Governance that meets only once a quarter reviews history. The framework runs at five rhythms, and the fastest one needs no meeting at all.

Cadence What happens Who
Per action Policy evaluated, corridor enforced, scope checked, record written, verification captured where required. The layer, automatically; human verifiers on consequential outputs.
Daily Hash chain verified, monitoring thresholds reviewed, open incidents triaged. Operator on call; AI risk owner on any breach.
Weekly Policy denials, residency denials and overrides reviewed; agent register reconciled with the identity provider. System owners with the operator; CISO on scope denials.
Quarterly Board pack issued, kill switch drill run, provider review held, policies and use-case classes re-approved. Accountable executive, AI risk owner, board.
Annual Risk appetite reset, literacy records refreshed, framework version reviewed, independent test of the control catalogue. Board, accountable executive, internal audit.

7 · Maturity model

Four levels, each passed on evidence, not on declaration.

Each level has pass criteria an internal auditor can verify from artefacts. The levels follow the six engagement phases: Diagnostic, Architecture, Build, Governance, Adoption, Run.

Level Pass criteria Phases
1 · Pilot Use-case register exists and classifies each case. Accountable executive and AI risk owner are named. The decision rights table is signed for one workflow. Diagnostic, Architecture
2 · Governed Policies run as code with enforcement points. Every agent has its own identity. The trail writes nine-field chained records. One kill switch drill is on record. DPIA and FRIA are signed where they apply. Build, Governance
3 · Operated Client operators and verifiers work on shift with dated literacy records. Weekly and quarterly cadences have run at least once. The first board pack is issued from the trail. Adoption
4 · Transferred The client team runs every control without vendor help, including a provider switch and a kill switch drill from the runbook alone. Internal audit has tested the catalogue. Run

Level 4 matches test 06, ownership rehearsal, in the due diligence protocol. A client that stops at level 3 still holds the code, runbooks and evidence: ownership transfers from day one, maturity measures who can run them. The six phases in detail

8 · Adoption path

Ninety days, three blocks, one workflow first.

The framework is installed on one workflow already in production, then extended. Each block closes on artefacts, so progress is measured in evidence rather than meetings.

  1. 01

    Days 1 to 30 · Map and assign

    Register and classify the use cases, name the accountable executive and the AI risk owner, and sign the decision rights table for the first workflow.

    Deliverables: use-case register, risk classification, signed decision rights, target architecture, gap list against the fifteen controls. Exit at maturity level 1.

  2. 02

    Days 31 to 60 · Enforce and record

    Turn the policies into code, give each agent its identity and scope, start the chained trail, and run the first kill switch drill.

    Deliverables: policy repository, agent register, permission matrix, live trail, drill record, signed DPIA and FRIA where they apply. Exit at maturity level 2.

  3. 03

    Days 61 to 90 · Operate and report

    Train and name the verifiers, run the weekly cadence, rehearse a regulator export, and issue the first board pack from the trail.

    Deliverables: dated literacy records, verifier roster, first board pack, export rehearsal report, maturity assessment and the transfer plan. Exit at maturity level 3.

Literacy records follow the dated, role-resolved training paths that make Article 4 demonstrable. Level 4 depends on the transfer plan, not on the ninety days.

9 · Anti-patterns

Five governance designs that pass a review and fail an incident.

Each anti-pattern produces documents a review accepts. Each one breaks on the day an agent misbehaves or a regulator asks for a record.

  • A committee without a stop path

    An AI committee meets monthly but nobody on call can halt an agent tonight. Oversight that cannot interrupt fails GOV-A-04 and Article 14.

  • Policy without an enforcement point

    A signed AI policy that no runtime evaluates. The policy describes intent while the workflow does something else, which fails GOV-P-02.

  • Evidence reconstructed after the fact

    Logs assembled before an audit from several systems. The file cannot prove it was not edited, so it fails GOV-E-01. It is not the automatic recording Article 12 describes.

  • Literacy training without dated evidence

    A course everyone attended and nobody can prove. Without dated, role-resolved records linked to identities, Article 4 cannot be demonstrated, which fails GOV-E-02.

  • Shared agent identities

    Several agents acting under one service account. No action is attributable and no agent can be stopped alone, which fails GOV-A-01 and GOV-A-04.

10 · Versioning and citation

How to cite this document.

This URL is permanent and always serves the current version. Each change to a control or a role increments the version and is listed in the changelog, so a citation stays traceable to the text it quoted.

  • Preferred citation

    Hikari Blue, "Enterprise AI Governance Framework v1.0", 25 September 2026, https://hikariblue.com/governance-framework

    Section anchors are stable: #principles, #roles, #controls, #evidence, #cadence, #maturity, #adoption, #anti-patterns, #cite. Control identifiers GOV-P-01 to GOV-E-04 are stable across versions.

  • Changelog

    v1.0 · 25 September 2026. First public version: eight principles, seven roles and ten decision rights, fifteen controls in four domains, evidence and reporting model, five cadences, four maturity levels, ninety-day adoption path, five anti-patterns.

    Licence. Published under CC BY 4.0: free to cite, quote and reuse with attribution to Hikari Blue and a link to this URL.

Corrections and challenges to a control are welcome from boards, auditors, DPOs and regulators. Send them through the compliance channel; accepted changes are credited in the changelog.

For boards, CIOs, CISOs, risk officers and DPOs

Test your governance against the catalogue.

Thirty minutes with a named partner. We map the fifteen controls onto one workflow you already run and show which pass, which fail, and who should own each gap. You leave with the map, whether or not we ever work together.

Book the diagnostic Or read the AI Operating Layer Reference Architecture