AI strategy and governance for multi-site manufacturers: a standard that travels, validation that is local, model review tied to your change process, and a safety line that is not negotiable.
Enterprise AI programmes in manufacturing are built on an assumption that does not hold: that a model proven at the lead plant can be rolled out to the others. The equipment is different, the materials are different, the process has been optimised locally for years, and the instrumentation was retrofitted at different times.
Each of these is ordinary industrial reality rather than a problem to be fixed. Together they explain why a model that performs well at one site behaves differently at the next, and why transferability has to be a governance position rather than an assumption.
Initiatives running at every plant
With no portfolio view and no shared standard.
Investment priorities set locally
So the same use case is funded three times.
Data maturity that varies by site
And a roadmap that assumed the best one.
AI risk discussed only as cyber risk
Which leaves the operational risk unowned.
Governance practices that differ by plant
So nobody can say what the group position is.
Pilots that worked and never scaled
Usually on transferability, not on technology.
Workforce adoption treated as training
When the issue is trust and job security.
Nobody named accountable for a model
A committee owns it, which means no one does.
Take a model that works at one plant and check whether the second plant records the same thing the same way. Stoppage reasons, defect codes, material designations, shift definitions. If the conventions differ, the model has partly learned a convention rather than a phenomenon, and that is discoverable in a day by comparing two months of records from each site. It is the cheapest transferability test available and almost nobody runs it before the rollout.
Manufacturing already governs change. An engineering change, a new supplier, a process parameter adjustment and a tooling change all go through a process with approvals, documentation and an owner. Those are also precisely the events that invalidate a model.
So rather than building a parallel AI governance process, we extend the one that exists. It has authority, people already follow it, and it fires on the right events, which a calendar-based review does not.
Step 1
Assess maturity per plant, not as a group average
Step 2
Identify opportunities with operations at each plant
Step 3
Establish what exists: built, bought, embedded, adopted directly
Step 4
Assess value and feasibility, with data readiness per site
Step 5
Prioritise use cases, then the portfolio, with a stop list
Step 6
Classify each use by what it affects, not by its technology
Step 7
Draw the safety line and keep it out of scope
Step 8
Extend the management of change process to cover models
Step 9
Define the ownership model: plant accountable, central standards
Step 10
Design validation as a local exercise with a group method
Step 11
Plan adoption with the workforce, honestly
Step 12
Establish monitoring, review triggers and group reporting
Add one line to your change order form: does this affect a model. A named owner receives it, decides whether a review is required, and records the answer. That is the whole implementation. It takes a form change and a nominated person, and it is worth more than a model monitoring dashboard because it fires on the events that actually invalidate models.
Grouped by what each part does. We design the governance and build what makes it operable. We do not build the AI on this page: the other four pages in this section do that, and this page is deliberately separate from them.
Strategy and portfolio
Enterprise manufacturing AI strategy tied to operational outcomes, with an explicit stop list
AI maturity assessment per plant rather than as a group average
Opportunity identification with operations at each site, including the AI already in use
Value and feasibility assessment, with data readiness assessed per site
Portfolio and investment management, so the same use case is not funded three times
Transferability assessment per use case: what travels and what has to be local
Operating model and governance
AI operating model: plant accountable for outcomes, central accountable for standards
Governance framework that extends your management of change rather than paralleling it
Classification by what a use affects rather than by its technology
Accountability assignment to a named person per use case, who has accepted it
AI policies and standards written so a plant engineer can apply them without escalating
Manufacturing AI Centre of Excellence on a federated model, with what it owns and does not own stated
Risk and responsible AI
Responsible AI framework defined so each principle can be tested rather than asserted
AI risk management integrated with your operational risk taxonomy, not only with cyber risk
The safety boundary, documented and kept out of scope, with functional safety involved
Third-party and vendor AI risk, including capability embedded in equipment you buy
IP protection for process knowledge, which is the manufacturing-specific exposure in section 7
Generative AI and agent governance, with the agent authority model on our AI Agents & Workflow Automation page
Lifecycle and engineering
Model inventory and registry covering anything that influences a decision, including embedded capability
Model lifecycle governance: approval, local validation, deployment, monitoring, review, retirement
Validation method per use case, designed once centrally and executed locally
Evaluation and testing capability, including evaluation sets for generative use cases
Monitoring and observability for performance, drift and the event triggers in section 3
Governance dashboards and group reporting, with the measures in section 8
These are the places manufacturing AI governance gets tested. The question is different in each, and naming it is more useful than describing a review board.
Predictive maintenance governance
Models predicting failure or recommending intervention on production equipment.
Production optimisation oversight
AI recommending process parameters, setpoints or sequencing.
Computer vision and inspection governance
Vision systems making determinations about product.
Supply chain forecasting governance
Demand and supply models driving inventory and procurement decisions.
Generative AI copilot governance
Assistants answering from technical documentation and operational records.
Autonomous workflow agent governance
Agents taking actions in business and operations systems.
Workforce and operational AI governance
AI that affects how work is allocated, measured or evaluated.
Enterprise AI portfolio oversight
The whole set across every plant, viewed as a portfolio.
Ask your maintenance team how many predictive alerts they attended last month and how many were real. If the second number is low and nobody is tracking it, the programme is on its way to being ignored and the dashboard will not show it. Both numbers are available from the maintenance records, and the ratio is the most honest health measure a predictive maintenance programme has.
Governance architecture is ordinary engineering in service of a few obligations: know what you have, see how it behaves, explain what it did, and be able to stop it. In manufacturing the first one has a complication the other industries do not share.
Model inventory and registry
Including capability embedded in equipment and software you bought.
Lifecycle management
Approval, local validation, deployment, review, retirement, with state per plant.
Monitoring and observability
Performance and drift, with the event triggers from section 3.
Evaluation and validation
A group method, executed and signed off locally.
Explainability
Enough for an engineer to agree or disagree with the output.
Decision traceability
What the model saw, what it produced, what was decided, by whom.
Human-in-the-loop controls
Built into the workflow, with disagreement captured.
Reporting
Per plant and per group, with governance effectiveness in section 8.
The NIST AI Risk Management Framework and its generative AI profile, which is the most widely used reference structure and is voluntary
ISO/IEC 42001 for an AI management system, where a certifiable structure is wanted
ISO/IEC 23894 for AI risk management guidance
Your existing quality management system and management of change process, which for a manufacturer are the most authoritative of the four because people already follow them
One boundary comes before every other consideration on this page, because it determines what the rest of the governance is for.
Responsible AI principles
Defined so each one can be tested rather than asserted.
Human oversight
With disagreement captured, per section 6.
Model reliability and operational risk
In your operational risk taxonomy, not only in cyber.
Data privacy and IP
Including process knowledge, which is the sub-section below.
Industrial cyber security
Segmentation and one-way flow, per our AI Agents page.
Transparency
Explainability at the level an engineer can act on.
Third-party and vendor AI
Including capability embedded in equipment.
Accountability
Named, accepted, and local to the plant that owns the outcome.
Model monitoring is well understood. Governance monitoring is not, and without it a framework becomes a set of documents describing an organisation nobody has checked against reality.
Performance against the measure agreed at approval, per plant rather than in aggregate
Input drift and population change, which in a plant usually traces to a material, a tool or a season
Output distribution change, which detects a generative or vendor model behaving differently after a change you did not make
False alarm rate where the model triggers action, and whether those alerts are still being attended promptly
Engineer disagreement rate, which is this page’s equivalent of an override measure and is also validation evidence
Incidents and exceptions, with a definition of what counts as an AI incident
AI risk indicators reported together as a set: models operating outside their validated range, overdue reviews, alerts no longer being attended, and accountability gaps. Individually each looks minor and together they describe the exposure
And value against the case the use was approved on, because a use case whose benefit never arrived should be retired rather than monitored indefinitely
Inventory completeness, including capability found in equipment after the inventory was declared complete, which is the honest test of whether registration works
Change orders that triggered a model review, against those that should have, which is the measure of whether section 3 actually operates
Reviews completed against reviews due, by classification
Models deployed at a second plant with local validation completed, which is the transferability measure
Accountability gaps: models with no named accountable person, which should trend to zero
Use cases stopped or rejected, which should not be zero. A governance process that has never said no has not been tested
Time from proposal to decision, since a slow route gets routed around and the routing-around is invisible
Ask how many AI use cases your organisation has stopped in the last year. If the answer is none, either everything proposed was appropriate, which is unlikely across several plants, or the process cannot say no. Both answers are worth knowing, and this one question tells an executive team more about their AI governance than any maturity assessment.
Outcomes depend on how many plants you run, how much AI is already in use and the state of your change process. These are the changes the work is aimed at.
One roadmap across the group, with a stop list, rather than initiatives at every plant
A clear split between what travels and what has to be local, so the second deployment is faster and the reason is understood
Model review triggered by engineering change rather than by a calendar
Stronger accountability
a named person per use case at the plant that owns the outcome, who has accepted it
Classification by what a use affects, applied by the people proposing it without escalation
An inventory that includes the capability embedded in equipment you bought
A stated IP position on what process data may leave the plant and what a vendor may do with it
A safety boundary that is documented and out of scope rather than debated per project
Governance effectiveness measured, including the measures nobody currently has
Operational and AI risk reduced where it actually sits
a model used outside its range, an alert nobody attends, a vendor feature sending data off site, and a use case with no owner
And an answer ready for the customer audit that asks what AI influences your product decisions
Bring us your AI estate as it actually is, including the pilots nobody sponsored and the features inside equipment you bought, and we will inventory it, map accountability, classify each use by what it affects, and tell you which of your use cases will not transfer to the second plant before you plan the rollout.
CaliberFocus designs AI strategy and governance for multi-site manufacturers around transferability. We separate what travels between plants from what has to be validated locally, extend your existing management of change so engineering changes trigger model reviews, classify each use by what it affects, and keep the safety line out of scope.
- A group standard that travels, with validation and sign-off at each plant
- Model reviews triggered by engineering change, not by a calendar
- Classification by what a use affects rather than by its technology
- An inventory that includes AI embedded in the equipment you buy
Security & Compliance
