AI governanceFor boards, CIOs and risk officers
AI governance that answers to a regulator, not a dashboard.
AI governance is the set of enforced policies, oversight roles and audit records that let a company run AI in production and answer for it. Not a framework on a slide, a control system that executes per task.
Governance is architecture, not a document.
AI governance decides which model runs a task, which human signs off, and what gets logged the moment it happens. 3 components make it enforceable, not aspirational.
Policy engine
Decides, at the moment of each task, which model runs, under which data residency, with which approval required before output ships. The enforcement point auditors examine first.
Human oversight loop
A named person reviews, overrides or stops an output before it reaches a consequential decision. Enforced per task under Article 14, not documented after the fact.
Board-ready audit trail
A record of every AI action, generated the moment it happens, append-only, tied to the human who verified it. The form a board hands a regulator without preparation.
What the audit trail holds, drawn.
Each action becomes a record, and each record carries the hash of the previous one. A regulator receives a scoped export of the chain; the board receives a report built from the same records.
- Evidence and audit planeC2 in Reference Architecture v1.0: one record per action.
- Records #4124 to #4127Append-only, 9 fields each; #4127 is the action of this example.
- Hash linksEach record carries the hash of the previous one: an edit or a deletion breaks the chain visibly.
- Regulator exportA scoped extract for one system and one period, shipped with the chain hashes (seal).
- Board reportBuilt from the trail; every figure links back to its records.
Text version
The evidence and audit plane holds 4 records, #4124 to #4127, each linked to the previous one by its hash. Below it, the oversight zone receives a regulator export carrying the chain hashes under a seal, and a board report built from the same records.
These 3 components are one property of a larger architecture, the AI operating layer. See the full operating layer definition
The roles, decision rights, controls and evidence of this governance are published as a versioned framework a third party can test. Read the Enterprise AI Governance Framework
A dashboard scores risk. It does not stop a task.
The governance market is crowded with 2 kinds of product: software that catalogs risk, and firms that recommend a framework. Neither one runs the workflow, and neither one answers when a regulator calls.
Not a GRC dashboard
A GRC platform catalogs AI systems and scores risk on a schedule. It does not decide, in real time, which model runs a task, or stop one that should not.
Not an advisory framework
Advisory firms recommend a framework, then leave. The difference shows on the day a regulator asks who enforces the policy, not who wrote it.
Not a compliance checklist
Generic guides recycle regulatory text into a list to complete once. Governance is not a form filed and forgotten, it is a control that runs every time a task executes.
The same test applies to strategy work: a recommendation is not an operating layer. When to choose Hikari Blue, and when not to
The EU AI Act names the deployer, not the model vendor.
The Digital Omnibus moved the high‑risk obligations to December 2, 2027. Article 50 transparency duties apply since August 2, 2026; general-purpose model obligations since August 2, 2025, under Commission enforcement since August 2, 2026. In our reading, the calendar moved and the exposure did not: every operational duty still lands on whoever runs the workflow in production, not on the company that trained the model.
Article 9 · Risk management
Continuous risk management across the system's lifecycle, not a one-time assessment before launch. The policy engine enforces the control point where risk is actually created: the task.
Article 12 · Logging
High‑risk systems generate logs automatically over their lifetime. A model API does not do this for your workflow. The layer running underneath it does.
Article 14 · Human oversight
A named person reviews, overrides or stops an output before it reaches a consequential decision. The oversight loop is scoped to task risk, fixed before deployment.
Article 26 · Deployer duties
Monitoring and human oversight fall on the deployer, not the model vendor. The obligation lands on whoever runs the workflow, with no exception for a regulated sector.
The full reference architecture behind these controls is published. See the Engineering page See how we operate
Governance ships with the workflow it governs: AI‑Enabled Operations, delivered by an on-site AI pod. For private equity funds: the Portfolio AI Program.
- AI audit trail: definition and EU AI Act mapping The 9 fields of the record, mapped to Articles 12, 19 and 26, with the dates set by the Digital Omnibus.
- AI literacy and Article 4 of the EU AI Act The duty as reworded in July 2026, who it covers, who enforces it and the records that show it is met.
- The EU AI Act for Swiss companies When the EU regulation reaches a company established in Switzerland, in which role and from which date.
- FINMA Guidance 08/2024 on AI, expectation by expectation The 7 areas FINMA assessed in supervised institutions, and the control and evidence that answer each.
The questions boards and risk officers actually ask.
What does AI governance actually require under the EU AI Act?
For high‑risk systems: Article 9 risk management, Article 12 automatic logging, Article 14 human oversight and Article 26 deployer monitoring, applicable from December 2, 2027 after the July 2026 Digital Omnibus deferral. Article 50 transparency duties apply since August 2, 2026, general-purpose model obligations since August 2, 2025 (under Commission enforcement since August 2, 2026), and Articles 4 and 5 since February 2, 2025. None of these are satisfied by a policy document. Each requires a control that runs inside the workflow, not a report written after it.
How is this different from buying a GRC or AI governance platform?
A GRC platform catalogs your AI systems and assesses risk on a schedule. It does not decide, in real time, which model runs a given task, or stop one that should not. Hikari Blue engineers and operates the enforcement layer the platform sits on top of, and stays accountable for it in production.
Who is accountable when the AI system gets it wrong?
A named partner, in writing, per engagement. Hikari Blue practices sign the work, not a logo or an account team. When a regulator or a board asks who approved a deployment, there is one name to answer, and an audit trail behind it. The practice model
How long before a board can see this working?
30 minutes maps the governance layer to one workflow already in production, with the audit trail a regulator would request. The board leaves with the diagram. No pilot required before the first artifact exists.
See the governance layer against your own workflows.
30 minutes with a named partner. We map the policy engine and audit trail to one workflow you already run, with the record your regulator would ask for. You leave with the diagram, whether or not we ever work together.
- One workflow you already run, mapped to the policy engine
- The record your regulator would ask for
- A diagram you keep, whether or not we work together