---
title: "Enterprise AI Governance Framework v1.0"
canonical: "https://hikariblue.com/governance-framework"
language: en
publisher: "Hikari Blue, a trademark of UNITED4 LLC"
version: "1.0"
date: "2026-09-25"
date_source: "page JSON-LD dateModified"
license: "CC BY 4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
generator: "scripts/build/make-llms.mjs from governance-framework.html, build date 2026-11-06; do not edit by hand"
---
1. [Home](https://hikariblue.com/)
2. [What is an AI operating layer?](https://hikariblue.com/ai-operating-layer)
3. Governance framework
Governance frameworkVersion 1.025 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.
[Book a 30‑min call](https://hikariblue.com/contact?engagement=call&intent=governance-framework) [How to cite this document](https://hikariblue.com/governance-framework#cite)
Policy and governance plane (C3): the rule in force applies at runtime; prior versions stay on file.
Version
1.0, 25 September 2026
Audience
Boards, CIOs, CISOs, CROs, DPOs and internal auditors
Catalogue
15 controls in 4 domains
License
CC BY 4.0, free to cite with attribution
Canonical web version: https://hikariblue.com/governance-framework. This Markdown is generated from that page at build time; the page prevails.
## A public, versioned governance model, testable by a third party.
### On this page
1. [Status and conventions](https://hikariblue.com/governance-framework#status)
2. [1. Principles](https://hikariblue.com/governance-framework#principles)
3. [2. Roles](https://hikariblue.com/governance-framework#roles)
4. [3. Decision rights](https://hikariblue.com/governance-framework#decision-rights)
5. [4.1 Domain P: policy and model selection](https://hikariblue.com/governance-framework#controls)
6. [4.2 Domain D: data and sovereignty](https://hikariblue.com/governance-framework#controls-data)
7. [4.3 Domain A: agent authorization and stop](https://hikariblue.com/governance-framework#controls-agents)
8. [4.4 Domain E: evidence and reporting](https://hikariblue.com/governance-framework#controls-evidence)
9. [5. Evidence and reporting](https://hikariblue.com/governance-framework#evidence)
10. [6. Cadence](https://hikariblue.com/governance-framework#cadence)
11. [7. Maturity model](https://hikariblue.com/governance-framework#maturity)
12. [8. Adoption path](https://hikariblue.com/governance-framework#adoption)
13. [9. Anti-patterns](https://hikariblue.com/governance-framework#anti-patterns)
14. [10. Versioning and citation](https://hikariblue.com/governance-framework#cite)
## A public, versioned governance model, testable by a third party.
0 · Status and conventions
[The AI Operating Layer Reference Architecture](https://hikariblue.com/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](https://hikariblue.com/ai-governance) 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](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), and Regulation (EU) 2016/679, the GDPR, on [EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj). The AI Act application calendar is tracked on the [definition page](https://hikariblue.com/ai-operating-layer), so this framework stays valid when the calendar moves.
## 8 principles, each tied to an architecture property or a legal duty.
1 · Principles
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.
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).
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.
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.
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.
05
### Stopping is cheap, restarting is deliberate
Any named operator or verifier can trigger a halt through the control plane, while restart needs the risk owner, matching the Article 14 duty to interrupt a system through a stop procedure.
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.
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.
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.
## 7 roles, one accountable name per decision.
2 · Roles and decision rights
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.
- [Named owner: the person who answers for an AI use The System owner, recorded by name: what the owner decides, and what the other roles decide.](https://hikariblue.com/glossary/named-owner)
- [AI operating model: who decides, funds and runs AI Roles, decision rights and cadence, and how they differ from the AI operating layer that enforces them.](https://hikariblue.com/glossary/ai-operating-model)
## 10 decisions, each with one accountable role.
3 · Decision rights
The table follows the RACI convention: one role is accountable, one is responsible for execution, others are consulted before or informed after. 2 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 |
### One consequential decision, as the trail records it.
Decision rights in practice: a named verifier approves, or a named operator triggers the kill switch, and either way the trail writes the record. Run the example to follow the approval, or press Kill switch to see the simulated stop path.
Execution traceOne governed decision through the 4 planes
Illustrative simulation. Example data, audit record format of Reference Architecture v1.0.
1. 14:02:07 UTCRequestAgent requests: approve vendor payment above threshold
2. 14:02:07 UTCPolicyPolicy `P-04` v3 applied · human approval required above threshold
3. 14:02:11 UTCDecisionA. Moreau, treasury operator, approved
4. 14:02:11 UTCRecordRecord #4127 · hash linked to #4126 · exportable
Simulation interrupted by the kill switch: in this example, tool permissions revoked, payment not released, halt recorded in #4128. Run example restarts the simulation.
Example, fictional data. A simulation, not the proof of a halt at a client.
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.
## 15 controls in 4 domains. Domain P: policy and model selection.
4.1 · Control catalogue · Domain P
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.
## Domain D: data and sovereignty.
4.2 · Control catalogue · Domain D
3 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](https://hikariblue.com/trust)
### 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.
## Domain A: agent authorization and stop.
4.3 · Control catalogue · Domain A
4 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 is designed to be halted in one action by a named operator or verifier, and the drill tests that path; 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.
[Measure your AI's Time to Stop in a tabletop Kill Switch Drill with KILLSWITCH by Hikari Blue.](https://hikariblue.com/killswitch/time-to-stop)
Tabletop exercise, timed and self-reported; not a measurement of a real stop.
- [AI agent identity: every agent under its own name and scope A distinct, revocable identity per agent, separate from the employee it works for, and what NIST is standardizing.](https://hikariblue.com/glossary/ai-agent-identity)
- [AI kill switch: a stop path built into the architecture What a stop must reach, why it is enforced below the application, and how its time to stop is measured.](https://hikariblue.com/glossary/ai-kill-switch)
## Domain E: evidence and reporting.
4.4 · Control catalogue · Domain E
4 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 9 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 6 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 4 controls C1 to C4 of the [reference architecture](https://hikariblue.com/reference-architecture#controls). 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.
- [NIST AI RMF implementation: the 15 controls, subcategory by subcategory Crosswalk to GOVERN, MAP, MEASURE and MANAGE, with the evidence each control produces and the US status on 21 October 2026.](https://hikariblue.com/governance-framework/nist-ai-rmf)
## 3 documents, all built from the trail, none written by hand.
5 · Evidence and reporting
The 9-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](https://hikariblue.com/trust). Our engagement baseline retains the trail per contract, 12 months minimum, above the Article 26 floor of 6 months.
- [AI audit trail: definition and EU AI Act mapping Each of the 9 fields, the provision of the EU AI Act it answers, retention and the export test.](https://hikariblue.com/glossary/ai-audit-trail)
- [AI literacy and Article 4 of the EU AI Act GOV-E-02 read against Article 4 as amended in July 2026: scope, enforcement and records by role.](https://hikariblue.com/glossary/ai-literacy-article-4)
## 5 rhythms, from every action to every year.
6 · Cadence
Governance that meets only once a quarter reviews history. The framework runs at 5 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. |
## 4 levels, each passed on evidence, not on declaration.
7 · Maturity model
Each level has pass criteria an internal auditor can verify from artefacts. The levels follow the 6 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 9-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](https://hikariblue.com/reference-architecture#due-diligence). 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 6 phases in detail](https://hikariblue.com/operating-system)
## 90 days, 3 blocks, one workflow first.
8 · Adoption path
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.
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 15 controls. Exit at maturity level 1.
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.
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 acculturation paths](https://hikariblue.com/training) that make Article 4 demonstrable. Level 4 depends on the transfer plan, not on the 90 days.
## 5 governance designs that pass a review and fail an incident.
9 · Anti-patterns
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.
## How to cite this document.
10 · Versioning and citation
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: 8 principles, 7 roles and 10 decision rights, 15 controls in 4 domains, evidence and reporting model, 5 cadences, 4 maturity levels, 90-day adoption path, 5 anti-patterns.
Editorial correction · 25 October 2026: license sentence aligned, scope and reservations stated.
Editorial correction · 25 October 2026: links added to the new reference pages.
**License.** Published under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/): free to cite, quote and reuse with attribution to Hikari Blue and a link to this page. The license covers Hikari Blue’s text, tables and diagrams on this page; it does not cover third-party data, quotations or legal texts, which keep their own terms, nor the Hikari Blue name and logo, trademarks of UNITED4 LLC.
Corrections and challenges to a control are welcome from boards, auditors, DPOs and regulators. Send them through the [compliance channel](https://hikariblue.com/contact?intent=compliance); accepted changes are credited in the changelog.
Next step: how Hikari Blue holds itself to these controls, with dates and statuses. [Trust Center](https://hikariblue.com/trust)
## Test your governance against the catalogue.
For boards, CIOs, CISOs, risk officers and DPOs
30 minutes with a named partner. We map the 15 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.
- The 15 controls mapped onto a workflow you already run
- Which controls pass, and which fail
- Who should own each gap
[Book a 30‑min call](https://hikariblue.com/contact?engagement=call&intent=governance-framework) [Or read the AI Operating Layer Reference Architecture](https://hikariblue.com/reference-architecture) [Verify Hikari Blue with a model we do not control](https://hikariblue.com/verify)