AI governance copied IT security. It should have copied APQP.

Here is an uncomfortable observation. I have sat through every audit the automotive and aerospace sectors can produce — IATF 16949 surveillance, AS9100 renewals, VDA 6.3 process audits, customer PPAP reviews. Not once did a lead auditor ask who held the login credentials. They asked what the process decides. How it can fail. Which control catches that failure before it reaches the customer. That distinction is the gap in enterprise AI governance, and the frameworks being sold to close it were copied from the wrong discipline.

Recent coverage frames the problem as governance falling behind technology. Shadow AI has moved past chatbots into operational corners where nobody is watching. ERP infrastructure is multi-cloud and AI-native. The diagnosis, everywhere, is the same: frameworks fell behind. Wrong. They were copied from IT security when they should have been copied from APQP.

Access events vs decision events

Every AI governance framework I have reviewed in manufacturing and aerospace was written by people whose mental model is IT security. Access controls. Approval workflows. Role-based permissions. Data residency. Audit logs. Mechanisms for governing who touches a system. Necessary — and for a chatbot on an intranet endpoint, sufficient.

Autonomous agents making operational decisions are not access events. They are decision events. When I build a PFMEA under AS9100 or IATF 16949, nobody on my team confuses a password policy with a failure mode. We enumerate every process function, map how each can fail, rate severity, occurrence, and detection, then put control plans in place that catch failures at the point of origin. Not after they propagate downstream. I drove a 50% reduction in EASA audit findings in one cycle — not by tightening access rules, but by tightening how decisions are validated before they become actions.

What an agent PFMEA looks like

Start with decision paths. An agent authorised to adjust maintenance scheduling in a plant has at least four function categories: data ingestion, parameter interpretation, recommendation generation, and autonomous action execution. Each fails differently. Sensor data arrives stale or corrupted. Model weights drift from the distribution they were deployed against. A confidence threshold set too low during integration. An escalation path to a human reviewer that exists in the documentation but was never wired into the pipeline.

A proper agent PFMEA enumerates these modes per decision path, assigns severity and occurrence ratings, and defines control limits on authority. In manufacturing we call this stop-authority. An operator can stop the line. A machine exceeding its control limit triggers an andon. Agents need the same mechanism: a degradation curve where confidence below a validated threshold strips autonomous authority and routes the decision to a human. Not after the fact. Before the action is committed.

Validation runs are not optional. Before an agent goes live on any operational decision, it runs against a qualified test set of historical scenarios with known outcomes and pass criteria defined in advance. If you would not release a new welding process without a capability study, you should not deploy an agent without a qualification gate. I have built greenfield QA/QC organisations for 900+ employees from nothing. The principle does not change when the decision-maker is software.

The question was never who let the agent decide. The question was always what the agent decides when it is wrong.

Consensus is governance, not performance

I designed MultiPS to run 63+ models in parallel with consensus synthesis. Most people who see the platform assume the architecture is for accuracy. It is not. The platform exists because no single model is validated for every operational context. Models drift. Contexts shift. A model performing reliably on supplier risk scoring can hallucinate on specification compliance checks. Running multiple models with divergent architectures, then synthesising their outputs through a structured consensus protocol, is a control mechanism. When models converge, confidence is high. When they diverge, the system has flagged a problem with the input or the operational context — and the consensus layer holds the decision for human review before it becomes an action.

This is the same logic as cross-functional quality review. You do not trust a single inspector on a critical characteristic. You build redundancy into the inspection system because the cost of a miss is asymmetric with the cost of redundancy.

As a Certified Ethical Hacker, I know exactly where access-control thinking breaks. IT security asks: was the request authenticated? Was the action within authorised scope? Was the session logged? Valid questions for a chatbot. Useless when an agent is flagging a production batch for scrap versus rework, adjusting safety stock on components with five-year lead times, or routing a quality escalation between sites. The relevant question is not whether the agent was permitted to act. It is whether the decision was sound — and which control caught it when it wasn't. Access control has no vocabulary for that question. Process validation has spent sixty years building one.

The frameworks labelled obsolete are not behind on technology. They are behind on engineering discipline. Aerospace and automotive learned this decades ago — at a cost measured in recalls, groundings, and lives. If your governance cannot describe, in operational terms, how your agents fail — the specific failure modes, the control limits, the stop-authority thresholds, the validation evidence behind the qualification gate — it is not governance. It is a compliance certificate with better branding.