Category definition · For boards, CIOs and risk officers
What is an AI operating layer?
The AI operating layer for the regulated enterprise. We engineer governance, audit and runtime between foundation models and your business workflows. Multi-model by architecture, sovereign by construction, defensible to your board, your regulator, your operators.
The definition
The layer between the model and the work.
An AI operating layer is the combination of governance, audit and runtime engineered between foundation models and business workflows. It decides which model handles which task, under which policy, with which data residency. It records every action in an immutable audit trail. It gives the enterprise a kill switch that works as architecture, not as a feature.
-
Not an integrator
Integrators wire systems together and leave. The operating layer stays and runs. It is accountable for the workflow in production, not for the handover document.
-
Not a consultancy
Consultancies recommend. The operating layer executes. The difference shows the day a regulator asks for the audit trail, not for the strategy deck.
-
Not a model vendor
The layer is model-agnostic by design. A regulated enterprise can never be captive to one provider's roadmap, pricing or jurisdiction.
The market converged in 2026: MIT Technology Review described enterprise AI as an operating layer in April, and Anthropic and OpenAI stood up implementation businesses the same quarter. Read the analysis
Why it exists now
Regulation attached the obligations to the layer, not the model.
The EU AI Act applies to high-risk AI systems from August 2, 2026. Almost none of the operational duties fall on the model provider. They fall on the layer that runs it, meaning the enterprise.
-
Article 12 · Logging
High-risk systems must generate logs automatically over their lifetime. A model API does not do this for your workflow. The operating layer does.
-
Article 19 · Records
Period of use, input data, reference databases checked, identity of the humans who verified results. That is the audit trail the layer produces natively.
-
Article 26 · Deployer duties
Monitoring and human oversight fall on the deployer, not the vendor. The oversight loop is an operating-layer function, enforced per task.
Our newsroom tracks the enforcement timeline: what actually lands on August 2 govern the action, not the model
The three properties
What qualifies a layer as an operating layer.
Many products claim the word. Three properties are the test, and each one is architectural: it cannot be added later as a feature.
-
Multi-model by architecture
The layer orchestrates several foundation models under one governance. Model choice is a routing decision per task, reversible at any time. If removing one provider breaks the system, it is a wrapper, not an operating layer.
-
Audit by architecture
Every action is recorded at the moment it happens, immutably, with the context Article 19 requires. An audit trail reconstructed after the fact is documentation, not audit. The difference is what a regulator accepts.
-
Sovereign by construction
Data residency, model jurisdiction and access control are decided by the enterprise and enforced by the layer, with zero cleartext data server-side where the architecture demands it. Sovereignty bolted on is a policy statement, not a property.
The full reference architecture, integration matrix and stack policy are published. See the Engineering page See how we operate
Direct answers
The questions senior buyers actually ask.
What is an AI operating layer?
An AI operating layer is the governance, audit and runtime engineered between foundation models and business workflows. It decides which model runs, under which policy, with which audit trail, and gives the enterprise a kill switch that works at the architecture level, not as a feature.
How is it different from an AI platform or a model vendor?
A model vendor sells intelligence. A platform sells tooling. The operating layer is what makes either of them defensible in production: policy enforcement per task, an immutable audit trail per action, and model-agnostic architecture so the enterprise is never captive to one provider. When to choose Hikari Blue, and when not to
Who operates it?
Operators, not consultants. Hikari Blue engagements are run by four named practices: Engineering, Strategy, Talent and Run, each signed by a named partner. The practice model Sector depth
Where does it run?
In your environment or in a sovereign deployment, under your identity provider and your policy engine. Deployment options and the reference architecture are documented on the Engineering page
For boards, CIOs and risk officers
See the operating layer against your own workflows.
Thirty minutes with a named partner. We map the layer to one workflow you already run, with the audit trail your regulator would ask for. You leave with the diagram, whether or not we ever work together.