AI Adoption Is Mostly Workflow Ownership, Not Models

I have a simple test for whether an organization is serious about AI: can you point to the workflow owner?

Not the product owner of a chatbot. Not the head of data. The operator who owns the end-to-end process, the error budget, and the escalation path when the AI gets it wrong.

In Denmark, you can see the difference between “AI theatre” and operational AI in the way a large insurer has treated AI as new colleagues that take routine tasks, freeing up time for the humans. It is not a moonshot narrative. It is years of workflow optimization, one routine task at a time, with continuous improvement and clear ownership.

That is the case I want more boards and operators to internalize. “AI adoption” is mostly workflow ownership plus controls. The controls are not a committee. They are the same things we industrialized decades ago in manufacturing: defined handoffs, defect definitions, and fast escalation. Then you measure what matters: claims cycle time, leakage, and complaint rate. Not demo applause.

The operator’s reframing: AI is a station in your process

When I spent eleven years in power electronics, quality was never a PowerPoint topic. It was a production reality. You designed the line so that the right work happened at the right station, with clear acceptance criteria. If a unit failed, you did not debate philosophy. You contained, reworked, and fixed root cause.

Most AI programs are missing that industrial instinct. They start with a model and then go hunting for a use case. Operators do the opposite. They start with a workflow that already exists, with known pain: backlog, rework, customer frustration, or leakage. Then they decide where AI can act as a station, and what “good” looks like at that station.

Three practical consequences follow:

• AI does not “transform” a function. It changes specific handoffs. That is where you win or lose.
• AI output is not a decision. It is an input to a decision-making chain with explicit responsibility.
• Controls are not overhead. They are what makes throughput sustainable.

This is also why I keep returning to an operator’s checklist view of AI. If you want the deeper technical framing, I wrote a complementary piece on why AI architecture is an operator’s checklist. The same mindset applies here, but at workflow level.

Define the human and AI handoffs, then write down the rules

If you only do one thing this quarter, do this: map one workflow end to end and mark every point where work changes hands. Human to human. System to human. Human to system. Then decide where AI sits, and what happens when it is uncertain.

I am deliberately using manufacturing language, because it forces clarity. In a factory, you would never say “the station will figure it out.” You specify it.

For knowledge work, the equivalent is a short set of operating rules:

1. Entry criteria: what inputs are required for AI to act? What is the minimum data completeness? What is the allowed freshness?
2. Exit criteria: what does an acceptable output look like? What fields must be populated? What evidence must be attached?
3. Handoff design: when does AI auto-complete versus draft versus only recommend? Who signs off?
4. Error budget: what types of errors are tolerable, and at what rate? What errors are never acceptable?
5. Escalation path: where does uncertain work go? How fast? To whom? With what context?

This is where most AI adoption efforts quietly die. Not because the model is weak, but because nobody wants to own the uncomfortable specifics. Especially the error budget.

Error budgets: stop pretending you can “eliminate mistakes”

Every real process has defects. The operator question is not whether defects exist. It is whether you have designed for them.

When I ran operations in industrial contexts, we used clear defect definitions and containment. In R&D and QA roles, we treated quality as a system property: prevention, detection, and correction. You do not get robust output by asking people to “be careful.” You get it by making the next action obvious and fast.

AI needs the same treatment. Define a few categories that matter operationally:

• Critical errors: wrong action with customer harm, regulatory risk, or financial loss. These require hard gates and human approval.
• Costly errors: issues that create rework, delays, or leakage. These require sampling, thresholds, and rapid model or rule updates.
• Cosmetic errors: formatting, wording, minor classification drift. These should not stop flow.

Then convert that into an explicit policy: when confidence is below X, route to human review. When the case type is Y, never auto-act. When the data is incomplete, ask for missing fields before proceeding. It is not sexy. It works.

Boards like to ask, “What is the risk?” A better question is, “What is our designed response when the AI is wrong?” If you cannot answer that, you do not have an AI system. You have a prototype in production.

Measure adoption like an operator: cycle time, leakage, complaint rate

If you measure AI by number of pilots, you will get pilots. If you measure it by demo satisfaction, you will get nice demos. Operators measure throughput and quality.

In insurance claims, that means metrics like cycle time, leakage, and complaint rate. In manufacturing, it is first-pass yield, scrap, and returns. In SaaS, it is resolution time, ticket deflection with no repeat contact, and churn signals. The domain changes. The operator logic is identical.

Here is a practical KPI set that translates well across industries:

• Cycle time: median and 90th percentile from intake to decision.
• Rework rate: percentage of cases that bounce back after an AI or human step.
• Leakage proxy: any measurable “value lost” in the process (overpayment, underbilling, missed recoveries, waived fees, unnecessary dispatch).
• Complaint rate: normalized per volume, with severity levels.
• Escalation volume: how often AI triggers human review, and why.

Two of these are the early warning system: rework and escalations. When they spike, you do not debate. You investigate the station. Input quality, prompt logic, model drift, user behavior, or unclear policy. Then you fix the process.

A lived example: I learned this the hard way building and scaling teams

When I rebuilt and scaled an R&D organization to around 22 specialists across embedded software, cloud, electronics, mechanics, and QA, the limiting factor was rarely raw talent. It was interfaces. Who owned the handoff from electronics to firmware? What was “done” for a release candidate? What happened when QA found a systemic issue late?

The moment we wrote down acceptance criteria and escalation paths, throughput improved. Quality improved. Stress went down. Not because people worked less, but because ambiguity decreased.

I apply the same mindset today in my ventures. When I build products like IBHQ or Shopeno, I treat applied AI as part of the operating system: what it is allowed to do, what it must never do, and what evidence it must attach so a human can quickly verify or override. The win is not “AI everywhere.” The win is fewer ambiguous handoffs and faster decisions with control.

This is also why I do not get excited when someone tells me they have “rolled out AI to the organization.” I ask: which workflow, which station, which error budget, which escalation owner, which metric moved?

The board and operator checklist for this quarter

If you want a concrete plan you can execute in 90 days, use this checklist.

1. Pick one workflow with volume. Claims intake. Invoice matching. Customer support triage. Supplier onboarding. One workflow, not a department.
2. Name the workflow owner. One person accountable for end-to-end flow and outcomes.
3. Map stations and handoffs. Where does work change hands, and where does it stall?
4. Insert AI as a station, not a layer. Define entry and exit criteria.
5. Write the error budget and escalation path. Include “never auto-act” cases.
6. Instrument the metrics. Cycle time, rework, leakage proxy, complaint rate.
7. Run weekly ops reviews. Like a production meeting. Top defects. Top escalations. Root causes. Fixes shipped.

If you need a mental model from another domain: in grid-scale energy, bankability is built on controls and predictable performance. The same operator discipline is why I wrote a playbook for making grid-scale storage bankable. AI is no different. Trust is engineered.

My opinion: stop buying AI. Start operating it.

The Danish case is “boring” in the best way. Years of optimizing workflows and freeing up time by putting AI on routine tasks, not as magic, but as a production capability you improve continuously.

That is the standard I want boards to demand. Not an innovation lab. Not a pile of pilots. A named workflow owner. Defined handoffs. Error budgets. Escalations. And metrics that hit the P&L and the customer experience.

When you do that, the models almost become the easy part. The hard part is leadership: owning the workflow like it is your production line, because it is.