AI in Manufacturing Doesn’t Fail on Models. It Fails on the Data Contract.

I have seen the same movie in factories, product organizations, and boardrooms. A team ships a promising AI pilot. The first dashboard looks impressive. The first model beats the baseline. Then the plant stops trusting it. Maintenance ignores it. Quality challenges it. Operations says the data is “dirty”. The program stalls, quietly.

My view is blunt: manufacturing AI rarely fails on algorithms. It fails because nobody wrote, funded, and enforced the data contract.

When I spent eleven years in power electronics across quality leadership, project management, application engineering, and R&D, the plants that performed best had one thing in common. They treated product and process requirements as contracts, with owners, tolerances, and escalation paths. Later, when I ran operations across Denmark and Ukraine in electrification and energy storage, the same rule held. If a requirement was not owned, measured, and reviewed, it decayed. Data is no different.

A data contract is not a document. It is an operating agreement between the plant and every system that touches the truth. It defines what “good” means, who owns it, how exceptions are handled, and how drift is detected before it becomes a firefight.

The real bottleneck is not “data quality”. It is data ownership.

In most plants, data is treated as exhaust. Something you collect because you can. AI then arrives and asks the plant to bet decisions on that exhaust. That is a governance problem, not a modeling problem.

In manufacturing, we already know how to run contracts. We do it with CTQs (critical to quality), control plans, calibration schedules, MSA, and nonconformance workflows. The mistake is thinking data is an IT asset. For AI, data is a production input. It belongs in the same discipline as yield, scrap, and uptime.

Here is the reframing that works with operators and boards: your AI system is only as reliable as the narrowest part of its measurement chain. If a sensor is mis-calibrated, if a PLC tag is repurposed without versioning, if a shift changes a manual code without training, the model is not “wrong”. The data contract was violated.

What a data contract must contain

• CTQs for data, not just product: define the handful of variables that drive the decision, and specify required completeness, timeliness, accuracy, and units.
• Named owners: one operational owner per CTQ, and one technical owner per pipeline. “Everyone” is not an owner.
• Lineage you can explain on a whiteboard: where the signal originates, how it is transformed, and where it is consumed.
• Standardized exception handling: what happens when a value is missing, out of range, duplicated, delayed, or manually overridden.
• Change control: how tag changes, recipe changes, and equipment upgrades propagate to features and thresholds.

If you cannot answer these in 10 minutes, do not scale the model. Fix the contract first.

Scaling AI is a plant rollout problem, not a data science rollout problem

Most AI programs are funded like innovation and governed like IT. Manufacturing does not work that way. Plants execute what is tied to their KPIs, reviewed in their cadence, and owned by people with authority to change the process.

When I was CEO of a smart-building and home-automation business unit, we built connected sensors and controls across multiple countries. The technology was never the hard part. The hard part was defining what “signal integrity” meant across markets, installers, firmware versions, and cloud releases. If you do not standardize exceptions, you do not have a product. You have demos.

In a factory, “exceptions” are not edge cases. They are Tuesday. A sensor fails. A line is stopped. A batch is split. A rework loop begins. If your AI assumes clean, continuous data, it is not designed for manufacturing. The data contract must encode the plant’s reality, not the lab’s.

The operator-first rollout sequence

1. Pick one decision, not one model. Example: “Hold or release a batch”, “Schedule maintenance this week or next”, “Reduce energy peak without violating takt”.
2. Define the minimum viable truth: the CTQs required to make that decision safely.
3. Instrument the exceptions: missing values, manual overrides, sensor faults, late arrivals. Make exceptions visible and count them.
4. Bind funding to the KPI: scrap reduction, first-pass yield, OEE, unplanned downtime, energy per unit. If the plant does not feel it, it will not sustain it.
5. Deploy with a kill switch: the plant must be able to revert to the previous standard work without drama.

This is why I like thinking in checklists. I wrote about this mindset in AI architecture as an operator’s checklist. Architecture is not a picture. It is a sequence of commitments that survive contact with reality.

Data CTQs: treat measurement like a product requirement

In quality, we do not argue whether a measurement is “good enough” in abstract. We define tolerances, we validate the method, and we audit drift. Do the same for AI inputs.

A practical template for data CTQs

• Definition: name, unit, sampling frequency, and source system of record (PLC, MES, SCADA, ERP, LIMS).
• Acceptable range and physics constraints: what values are impossible or unsafe.
• Freshness window: how late is “late” before the decision becomes invalid.
• Completeness threshold: what percentage of missing values is tolerated before the model output is suppressed.
• Reconciliation rule: what happens when MES and ERP disagree, or when a manual entry conflicts with an automated reading.
• Audit cadence: who reviews it weekly, and what triggers a corrective action.

If you do this well, the plant will trust the system because it behaves like a controlled process. If you do not, every anomaly becomes a debate, and debates do not scale.

Governance that works: make exceptions, lineage, and incentives visible

I do not like governance theater. Committees that discuss principles while operators fight fires do not change outcomes. Effective governance is an operating system: it turns data issues into tickets, owners, deadlines, and prevention.

Here is the governing question I used in leadership roles: “When the model is wrong, who gets woken up?” If the answer is unclear, the system is not governable.

The minimum governance stack for manufacturing AI

• A single metric scoreboard: AI adoption tied to plant KPIs, plus data contract health (exception rate, freshness breaches, schema drift events).
• Lineage that can be audited: not for compliance reasons first, but for troubleshooting at 2 a.m.
• Standard work for overrides: when operators override AI, they must select a reason code. Not to police them, but to learn systematically.
• Release discipline: feature changes and model updates follow the same seriousness as firmware changes in embedded systems.
• Budget that matches responsibility: if operations owns the KPI, they must co-own the budget for sensors, integration, and maintenance of pipelines.

This is also where applied AI becomes real. In my ventures like Shopeno and IBHQ, I think about AI as a product behavior, not a science experiment. The product must degrade gracefully, explain itself, and create an audit trail. Factories need the same properties, just with higher stakes and tighter feedback loops.

The board-level lens: fund the data contract like you fund reliability

If you sit on a board or you own the P&L, here is the trap to avoid. You fund an AI initiative as a project, then you expect compounding value. But the underlying data contract is a living system. It requires maintenance, like preventive maintenance for equipment.

My opinion: treat the data contract as reliability work. It should have a backlog, a cadence, and a clear ROI story linked to plant KPIs. If it is not funded, it will be “everyone’s problem” and nobody’s job.

If you want a simple diagnostic for this quarter, ask for three numbers at the next ops review:

• Exception rate: how often the AI pipeline sees missing, late, or invalid inputs.
• Mean time to innocence: how fast the team can prove whether an issue is sensor, integration, transformation, or model.
• Override learning loop: percentage of overrides that lead to a contract update, a training update, or a process change.

If those numbers are unknown, the model is not the bottleneck. The contract is.

My closing takeaway is simple. Stop asking, “Is the model accurate?” Start asking, “Is the data contract enforceable?” Manufacturing AI scales when data is treated as operational truth with CTQs, owners, lineage, and standardized exceptions. Everything else is a pilot.