AI Value Isn’t in the Org Chart. It’s in the Stop Button.

Most AI programs I have seen fail in a very predictable way. They do a lot of visible work. They build a central AI team, a governance council, and a dashboard. They run pilots. They write principles. Cost goes up. Throughput stays flat.

That failure mode is not about model quality. It is about ownership. AI value does not live in the org chart. It lives in three things: who owns the decision, who owns the metric, and who owns the stop button.

When I ran operations in electrification and energy storage, I had responsibility across engineering, production, supply chain, service, and operations. In that seat, you learn fast that a “smart” improvement that cannot be rolled back is not innovation. It is operational risk. And if nobody can answer “who decides” in one sentence, you do not have a system. You have theater.

My opinion is simple: if an AI use case touches a line, a process, or a customer-critical workflow, it must be treated like any other production change. Release. Control. Measurement. Rollback. Clear authority. Everything else is optional.

The only AI operating model that survives a turnaround

Turnarounds have a forcing function. You cannot afford parallel structures that do not move the constraint. You cannot afford ambiguous accountability. You also cannot afford fragile deployments that create downtime minutes you then debate in meetings.

In a turnaround, the useful question is not “what can AI do?” It is “which decisions, if we make them faster or better, will move throughput, yield, or working capital this quarter?” Then you assign decision rights as brutally as you would assign budget ownership.

When I ran a smart-building business unit with full P&L responsibility across several countries, the same rule applied even outside the factory: if a connected product or a cloud feature did not have a clear owner for quality, release, and customer impact, it created noise. Noise becomes churn. Churn becomes margin pressure. AI is no different. It just fails faster because it automates the decision-making.

If you want a timeless framing that holds under stress, use this: AI is an operating model change disguised as a software project.

Five decision rights that unlock most of the value

In industrial environments, I have found that most AI value is gated by a small number of decision rights. Not twenty. Usually three to five. Here are the ones I would insist on, with names attached, before I funded another pilot.

1. Who owns release-to-production for AI in a specific line or process?

   This is not “the AI team.” It is the operational owner of the process, with a clear technical counterpart. If nobody in operations can approve the release, you will never scale. If operations can approve without technical gates, you will ship risk.

2. Who can change setpoints or recipes, and who can roll them back?

   If a model influences control, it needs a hard rollback path. If your rollback plan is “we will monitor and intervene,” you do not have a rollback plan. You have hope.

3. Who signs off on data quality at source (sensor, PLC, SCADA), not in the cloud?

   In power electronics and industrial automation, I learned that upstream quality beats downstream heroics. If the sensor is drifting, your model is learning lies. Data quality is a production responsibility with engineering support, not an analytics clean-up job.

4. Who owns cost-of-poor-quality end-to-end?

   If scrap, rework, returns, and service are owned by different functions, AI becomes an argument generator. Put cost-of-poor-quality under one accountable owner with a single definition. Then you can decide whether a use case is worth shipping.

5. Who decides a model is “good enough” to ship versus “nice to have”?

   “More accurate” is not a business metric. “Good enough” must be defined against operational outcomes and risk. In practice, it is a joint decision: operations owns the outcome, engineering owns the technical risk, finance polices the definition.

Notice what is missing: a committee. Committees can advise. They cannot own the stop button. And in production, the stop button is the job.

Metrics that work (and metrics that create meetings)

AI teams love proxy metrics because they are easy to produce. Accuracy. F1 score. AUC. Model confidence. Those can matter, but they are not what boards fund.

The KPI definitions that consistently survive contact with reality are unsexy, operational, and finance-grade. Pick a small set and make them auditable.

• Throughput at the constraint: the only throughput that matters is at the bottleneck. If AI improves a non-constraint step, celebrate, but do not pretend you moved the system.
• Yield and first-pass yield: separate true yield from rework-hidden yield. If you cannot separate them, you will optimize the wrong behavior.
• Unplanned downtime minutes: track it like safety. Define it once. Enforce it everywhere.
• Scrap and rework cost: connect it to cost-of-poor-quality, not engineering pride.
• Forecast-to-plan adherence: in supply chain and production planning, the value is not in “a better forecast.” It is in fewer schedule changes, fewer expedites, and fewer surprises.

Ownership matters more than selection. These metrics should be owned by operations, with finance-grade definitions. Not a slide deck definition. A close-the-books definition.

Workflow controls: the unsexy part that makes AI real

I have rebuilt and scaled R&D organizations and owned QA across hardware and software. The pattern is always the same: you do not get reliability from talent alone. You get reliability from workflow. AI delivery needs the same discipline.

Here is the minimum control plane I would put in place.

• One queue of use cases tied to bottlenecks.

  If every plant manager and every function can start an AI project, you will drown in pilots. Run one queue. Force prioritization against the constraint and cost-of-poor-quality.

• Gated deployment with a hard rollback path.

  Deployment is not “push to production.” It is “introduce a new failure mode safely.” Treat model rollout like a process change. Stage it. Limit blast radius. Roll back fast.

• A weekly ops review where model drift is treated like process drift.

  Do not create a separate AI review cadence. Put it in the operational rhythm. If drift increases downtime minutes or scrap, it is handled the same week, with the same seriousness as a mechanical drift.

• Clear escalation when data breaks.

  Most AI outages are data outages in disguise. When data quality at source degrades, someone must be on the hook to fix the sensor, the PLC mapping, or the SCADA tag. Not the data scientist.

For edge deployments, I strongly prefer small, purpose-built models because they simplify control, latency, and failure modes. If you are shipping to constrained devices or plants with harsh conditions, revisit why small models are often the only sane way to ship AI to the edge.

A lived example: why “central AI” did not scale, but decision rights did

In my venture work, especially building IBHQ and Shopeno, I have the advantage of starting with a clean sheet. You can design workflows where the metric and the stop button are explicit from day one. If an automated decision touches pricing, risk, or customer experience, you define who can override it, and what triggers an automatic fallback. That is not optional. It is product design.

In larger industrial settings, you rarely get that luxury. The temptation is to create a central AI function to compensate for fragmented ownership. It feels efficient. In practice, it becomes a translation layer between the people who feel the pain and the people who build the model. Translation layers are expensive. They also fail at 2 a.m. when a line is down.

The move that worked better was always the same: push ownership to the operational edge, and standardize the controls. One release gate. One metric definition. One rollback mechanism. One queue tied to bottlenecks. Central teams can still exist, but as enablers, not owners.

This is the same mindset I applied when I owned QA and test across hardware and software. Quality did not improve because QA wrote better bug reports. It improved when release criteria were explicit and non-negotiable, and when the factory and engineering both respected the stop button.

AI needs that same contract. Not more dashboards.

The board-level checklist for this quarter

If you are a board member, owner, or operator, here is a practical lens you can use tomorrow. It fits on one page and forces clarity.

1. Name the 3 to 5 decisions AI will change, and tie each to one constraint metric (throughput, yield, downtime, scrap, forecast-to-plan).
2. Assign a single operational owner per decision. If two functions share it, nobody owns it.
3. Define “good enough to ship” in business terms, plus the technical risk gates. Put it in writing.
4. Require a rollback path before deployment. If rollback is hard, scope the use case down until it is safe.
5. Place data quality accountability at the source. Make sensor and tag integrity someone’s job, with escalation.
6. Run one use case queue tied to bottlenecks and cost-of-poor-quality. Kill projects that do not move the constraint.
7. Put drift into the weekly ops rhythm. Treat it like any other process drift, with corrective actions.

If you do these seven things, you will stop paying for AI theater. You will also find that the org chart matters a lot less. Because the system will tell people what to do.

My closing opinion is blunt: AI does not need a new department. It needs decision rights, metric discipline, and a stop button that operations is empowered to press. When you build that, the tools finally matter.

Related reliability thinking applies beyond AI. If you build connected products in the field, you might also care about ruggedization as a reliability contract and eSIM as a trust anchor in the IoT P&L.