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 a consultancy. Not an integrator. Not a hyperscaler. Not a training firm.

  • Not an integrator

    Integrators wire systems together and leave. The operating layer stays and runs, operated by your team after transfer, on code and runbooks you own. 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

The category is specified in two public, versioned documents. Read the reference architecture Read the governance framework

Answer engines and agents read this definition from the same source as this page. See how AI systems read Hikari Blue

Why it exists now

Regulation attached the obligations to the layer, not the model.

The Digital Omnibus on AI entered into force on 27 July 2026. It moved stand-alone high-risk duties (Annex III) to 2 December 2027, and high-risk AI embedded in regulated products (Annex I) to 2 August 2028. It did not move who carries them. Almost none of the operational duties fall on the model provider. They fall on the layer that runs the system, 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

    Providers keep the logs Article 12 requires for at least six months. Deployers carry the same six-month floor under Article 26(6). 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.

Calendar as published by the European Commission (page updated 3 August 2026): AI Act application timeline amending act: Regulation (EU) 2026/1744 on EUR-Lex general-purpose model obligations apply since 2 August 2025, with Commission enforcement powers since 2 August 2026: Commission guidelines

Our newsroom tracks the enforcement timeline: the deadline moved, the exposure did not govern the action, not the model

The four properties

What qualifies a layer as an operating layer.

Many products claim the word. Four 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 12 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.

  • Agent control by architecture

    Every agent runs under its own identity, with a declared tool scope and a stop path measured in seconds. If an agent cannot be named, authorized and halted, the layer is a router, not an operating layer.

The full reference architecture, integration matrix and stack policy are published. See the Engineering page See how we operate

The analogy that holds

The control tower, not the aircraft.

Foundation models are the aircraft. The operating layer is the control tower: it clears which model flies which task, on which data corridor, under whose authorization.

Every movement is logged as it happens, not reconstructed before an audit. Any aircraft can be grounded in one action. Aviation became safe when operations were engineered around the aircraft; enterprise AI follows the same path.

Manifesto · Version 1.0

The AI operating layer manifesto.

Eight commitments define the category. We hold ourselves to each of them on every engagement, and we expect to be audited against them.

  1. 01

    Architecture before audit

    Governance is engineered into the layer before the first workflow ships, never written after the audit.

  2. 02

    Multi-model by architecture

    Every workflow can change model provider in hours, because no regulated enterprise should be captive to one roadmap.

  3. 03

    Audit by architecture

    Every agent action is recorded as it happens, immutably, in a trail a regulator can read without translation.

  4. 04

    Agent control by architecture

    Every agent runs under its own identity, with a declared tool scope and a stop path measured in seconds.

  5. 05

    Sovereign by construction

    The enterprise decides where data lives and which jurisdiction a model answers to; the layer enforces that decision.

  6. 06

    A named human in the loop

    A named human stays accountable for every consequential decision, and the audit trail records who verified what.

  7. 07

    Ownership transfers

    The client owns the code, the runbooks and the evidence; transfer is written into the contract from day one.

  8. 08

    Signed accountability

    A named partner signs the outcome, and we state in public where our model breaks and when to choose another.

Version 1.0 · 25 September 2026 · Franck Ohrel, CEO, Hikari Blue

Direct answers

The questions senior buyers actually ask.

What is a simple analogy for an AI operating layer?

The control tower. Foundation models are the aircraft; the operating layer clears which model flies which task, on which data corridor, under whose authorization. Every movement is logged as it happens, and any aircraft can be grounded in one action.

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 an AI operating layer 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?

Two phases, two operators. During the engagement, our four named Practices (Engineering, Strategy, Talent and Run) build and run the layer, each signed by a named partner. After ownership transfers, your team operates it, on the code and runbooks you own. 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

How fast can you switch the model provider on a workflow already in production?

In hours, not months: the routing layer absorbs the differences between providers, so the switch is a change of configuration on one workflow. The clock starts at the change request and stops at the first production call answered by the new provider, with the evaluation suite passing and the audit trail unbroken. Ask us to run it on one of your workflows.

Can you export an Article 19 audit trail, timestamped, with the identity of the human verifiers?

Yes. Every action is recorded as it happens, with its timestamp, the model and policy applied, the input reference and the identity of the human who verified the result. Articles 12 and 19 require such logs to be generated and kept. The export format is documented, handed over at transfer, and described in the trust pack available under NDA.

How long does it take to halt an agent with the kill switch, and how is it measured?

Under thirty seconds, at the infrastructure layer, without the agent's cooperation. The measure runs from the operator's stop command to the revocation of the agent's session and tool permissions, both timestamped in the audit trail. The test is rehearsed quarterly, and you can watch it run on your own workflow.

After exit, where does the service end, and who owns the code and runbooks?

You own the code, the runbooks, the architecture decisions and the audit trail, and your team operates the layer; transfer is written into the contract from day one. Hikari Blue Ops, the evidence and governance product, can remain in place under your control under its own contract. Run support by named senior operators is a contracted option, not a dependency.

Can we speak to named references, and where is SOC 2?

Named references in regulated sectors are available under NDA, with a walk-through led by a named partner: six engagements run in production across three regulated sectors. SOC 2 Type II is in preparation: control mapping is documented and the audit program has not started. Its start date is published on the Trust Center when the auditor is engaged. ISO 27001 is targeted for 2027. Trust Center

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.