The COO announces the AI deployment at the all-hands. Slide deck, a demo of the vision system flagging a surface defect in real time, production numbers trending up. Applause. Three weeks later the defect pattern shifts—subtle, a new combination of material variance and lighting condition the model was never trained on—and the quality director finds out from a customer complaint. The system had been auto-dispositioning parts for eleven days. Nobody told it to stop. Nobody was watching.

The sponsorship gap

Trade publications keep arguing that leadership is the real barrier to smart manufacturing adoption. Culture and skills, supposedly. That framing lets the structural problem off the hook. Leaders do not lack vision. Operators do not lack digital literacy. Digital transformation budgets create executive sponsors who own the rollout milestone—and nobody owns the quality outcome when the model makes a bad call.

I have watched this pattern repeat across plants. A sponsor gets assigned to "drive AI adoption." Their KPI is deployment speed, lab accuracy, user uptake. The dashboard they present to the steering committee shows sensors installed, models running, inspections automated. Then a batch escapes and the question becomes: whose problem is that? The sponsor has moved on to the next initiative. IT says the model performed within its stated confidence interval. The quality team did not know the system was live in their area. The defect has no owner. The AI has a sponsor with a completed deliverable.

Last week a report from Opsin Labs suggested that 60% of enterprise AI agents are over-permissioned. In a manufacturing context, that statistic translates directly into disposition authority. If an AI agent can reject a part, adjust a parameter, or reroute a batch, someone approved that permission level. That person rarely appears on the 8D when the defect reaches the customer.

When the AI decides, who answers

In a traditional process control environment, authority chains are explicit because they have to be. IATF 16949 and AS9100 both demand it. An operator flags a deviation. A process engineer reviews it. A quality manager approves disposition. The signature trail is clean. Insert an AI system into that chain without redefining who holds authority at each node, and you create a gap that a standard audit will not catch until something fails externally.

When the AI adjusts a torque parameter at 02:00 and first-piece inspection passes but capability drifts over the next four hours, the responsibility question has no clean answer. The engineer who configured the control limits, the data scientist who built the model, the plant manager who signed off on deployment—in my experience the real answer is "all of them and none of them." Which is how you end up in a customer escalation with no corrective action owner.

I have built and deployed autonomous multi-agent AI systems. Not training foundation models—architecting the integration where multiple models coordinate decisions in real time. The hardest part was never the orchestration logic or the consensus layer. The hardest part was sitting down with a blank RACI matrix and deciding, line by line, which decisions an agent could make autonomously, which required human confirmation, and who that human was by name and job title. Skip that exercise and you have not deployed intelligence. You have deployed liability with a polished interface.

What ownership actually looks like

When I led quality across a multi-site operation with over 2,000 people, we hit a stretch with zero critical customer escalations in a full quarter. Not because of a clever algorithm or a new piece of software. Because authority lines were explicit. Every disposition decision had a named owner. Every escalation path had a defined trigger and a named receiver. When we ran QRQC and A3 problem-solving, the first field on the template was always the same: who owns this?

AI-driven decisions require the same discipline, applied with more rigour because the decision velocity is higher and the audit trail is thinner. The executive sponsor owns the deployment milestone and the budget. They do not own quality outcomes unless they also carry the quality title—and they almost never do. Every AI-driven process decision needs a human authority node. Not a "human-in-the-loop" abstraction that nobody can point to on an org chart. An actual person, named in the control plan, who receives the decision and can override it before it touches product. Parameter adjustments made by AI systems need the same change-control documentation as any engineering change: PFMEA updated, control plan revised, revision history clean. The auditor will ask. You should have the answer before they do.

If your AI can change a process parameter but your organisation cannot name the person who owns that parameter's outcome, you have automated ambiguity.

Disposition calls—accept, reject, reroute—need a confidence threshold below which the system escalates rather than decides. That threshold is a quality engineering determination, not a data science one. Setting it requires someone who understands what a field failure costs in euros, not just what a false positive costs in throughput.

Key takeaways

  • An AI sponsor with a deployment KPI is not a quality owner. If the sponsor's success metric stops at go-live, quality accountability has already been orphaned.
  • Every AI-driven decision in a production environment needs a named human authority node in the control plan—not a role description, a person.
  • Parameter changes made by AI systems are engineering changes. Treat them with the same change-control rigour your auditor expects for any manual adjustment.
  • The confidence threshold at which an AI escalates instead of deciding is a quality engineering call. It should be set by someone who knows the cost of an escape, not the cost of a false reject.

Deploy the AI. Compress your lead times, automate your inspection, let the models coordinate. But if you cannot name the person who owns the quality outcome—by name, not by committee—you have distributed risk across your organisation and called it capability. The customer who receives the escape will not care about your dashboard. They will care about who answers the phone.