An automotive body shop inspection system. A paint shop defect detection camera. An assembly verification application. An engine shop component identification system.

In most large manufacturing plants, each of these is a separate deployment. Separate hardware. Separate AI models. Separate data storage. Separate maintenance contracts. Separate governance.

They were built this way because that is how vision AI was adopted. One application at a time, in one area at a time, driven by a specific quality problem with a specific budget and a specific team. The approach made sense at the time. Each application works. Each delivers some return.

The problem surfaces when you step back and look at all of them together. The GPU infrastructure serving the body shop inspection is sitting idle during the shift change while the paint shop inspection system is running at full capacity on separate hardware. A defect pattern that appears in body shop data and correlates with a root cause visible in paint shop data cannot be identified because the two applications have never been connected. A new vision application in the assembly shop requires the same infrastructure procurement, the same model training process, and the same deployment effort as the first application did three years ago. Nothing has been shared. Nothing has been reused.

This is the fragmentation problem that a centralized AI vision platform solves.

What a Centralized AI Vision Platform Actually Is

A centralized AI vision platform is shared infrastructure and shared management for all vision AI applications across a manufacturing facility.

It has five components that distinguish it from a collection of individual vision AI deployments.

• Shared compute and GPU infrastructure:

Instead of each vision AI application running on dedicated hardware, the compute resources are pooled. Applications draw from shared GPU capacity based on current demand. When the body shop application needs more compute during a quality audit, it draws from the shared pool. When it is idle, that capacity is available to other applications. Hardware utilisation improves. Hardware cost reduces. The need to provision dedicated hardware for each new application disappears.

• Centralized AI model lifecycle management:

In a fragmented deployment, each application manages its own model. When the defect taxonomy changes, or when new product variants require model retraining, each application's model is updated independently. In a centralized platform, model versions, training runs, performance metrics, and deployment history are managed in one place. A model update is validated once and deployed consistently. Model lineage is tracked across the facility. Rollback to a previous version, if a new model performs unexpectedly in production, happens at the platform level rather than application by application.

• Standardised deployment and monitoring framework:

Deploying a new vision AI application in a fragmented environment means starting from scratch. In a centralized platform, new applications deploy to a standard framework. The infrastructure is already there. The integration patterns are already established. The monitoring dashboards already exist. The time from a new vision AI use case to production deployment reduces from months to weeks.

• Common data storage and governance:

All inspection data, from all applications across all manufacturing zones, flows into a common data layer. This makes it possible to identify patterns that span multiple areas of the plant. A correlation between a specific supplier batch, a body shop welding anomaly, and a paint shop adhesion defect is visible only when the data from all three applications is in the same place. In a fragmented environment, this correlation is invisible. In a centralized platform, it is detectable and actionable.

• Edge inferencing with centralized management:

This is the architectural principle that makes centralized vision AI viable in a manufacturing environment. The AI inference, the actual processing of camera images and generation of inspection results, happens at the edge, close to the production line, with the low latency that real-time inspection requires. But the model management, the training, the versioning, the governance, and the performance monitoring happen centrally. The edge devices run models deployed from the central platform. They send their results back to the central data layer. They receive model updates from the central management system. The processing is distributed. The intelligence is centralized.

Why the Fragmented Approach Has Hidden Costs

The case for centralisation becomes clear when the true cost of fragmentation is calculated.

An automotive paint shop where human inspectors catch 78% of surface defects under fixed lighting leaves 22% advancing to final assembly. Each defect caught at final assembly rather than at the paint exit costs $3,200 in disassembly, re-paint, and reassembly labour. The 1-10-100 rule in automotive quality management states that a defect caught at the stamping press costs $1 to address, the same defect after paint costs $10, and after final assembly and customer delivery, the cost exceeds $100. US passenger vehicle manufacturers paid $13.4 billion in warranty claims in 2025, up 8% year on year.

These are the costs that fragmented vision AI cannot address fully. Individual applications catch defects in their specific area. They cannot catch the defect patterns that span multiple areas. They cannot identify the root causes that are visible only when body shop, paint shop, and assembly data are analysed together. They cannot continuously improve their detection capability by learning from the full facility's inspection history.

Fragmentation also has infrastructure and maintenance costs that are easy to underestimate at the start and difficult to ignore at scale. Each independent application requires its own hardware refresh cycle, its own software updates, its own model retraining process, and its own technical expertise to maintain. When the number of applications grows from three to ten to thirty, the maintenance burden scales with it. The central IT and operations team that was capable of supporting three applications is not capable of supporting thirty without significant additional resource.

The Specific Governance Problem That Fragmentation Creates

The EU AI Act classifies many industrial vision AI systems as high-risk. IATF 16949, the international quality management standard for automotive production, requires traceability of inspection results. These governance requirements cannot be satisfied efficiently when each vision AI application maintains its own audit trail, its own model documentation, and its own compliance records.

A regulatory audit that requires evidence of model lineage, inspection record completeness, and defect taxonomy documentation across all vision AI applications in a facility has to gather this evidence from multiple independent systems. The process is slow, error-prone, and reveals gaps in documentation that exist because there was no shared standard.

A centralized platform satisfies these requirements structurally. Model lineage is tracked in one system. Inspection records are stored in one data layer. Compliance documentation follows a consistent format because the platform enforces it. A regulatory audit becomes a query on the central platform rather than a manual aggregation exercise across ten independent systems.

What Building a Centralized Vision AI Platform Actually Requires

The technology for centralized vision AI platforms is proven in 2026. NVIDIA's Industrial AI Cloud, Siemens' Industrial Edge platform, and several specialist providers have demonstrated that the infrastructure and management layer required for centralisation works at manufacturing scale.

The obstacle, as research on automotive AI adoption consistently finds, is not technology. It is organisational.

Each existing vision AI application in a fragmented environment was procured, deployed, and is maintained by a specific team in a specific manufacturing zone. That team has operational accountability for their zone's quality. They have chosen their hardware, their software, and their AI model. Moving to a centralized platform means giving up some of that control in exchange for shared infrastructure they did not procure and shared management they do not control.

This is a change management challenge as much as a technical one. The central IT team needs the authority and the credibility to take on management of applications they did not build. The zone teams need confidence that a centralized platform will maintain the performance they rely on for quality assurance. Both require a deployment approach that works inside the operational environment rather than imposing a new architecture from the outside.

Three technical requirements need to be satisfied before centralisation is possible.

• Network infrastructure between zones:

Edge devices in multiple manufacturing zones need reliable, low-latency connectivity to the central management layer. In older facilities, this network infrastructure may not exist or may not have the capacity required. Assessing and upgrading network infrastructure is typically the longest-lead-time element of a centralisation project.

• Standardised edge hardware or an abstraction layer:

Different existing applications may run on different edge hardware platforms. A central management layer needs either standardised hardware across the facility or a software abstraction layer that can manage heterogeneous devices consistently. Planning this before beginning centralisation avoids a hardware replacement cost that was not in the original project scope.

• Integration with MES and ERP:

The value of centralized inspection data depends on it being connected to the manufacturing execution system and ERP where production decisions are made. Defect data that improves the quality dashboard but does not connect to production scheduling, supplier management, or warranty management has captured only part of its potential value.

What to Expect From a Centralisation Project

A centralized vision AI platform is not a rip-and-replace project. Existing applications continue to operate. The centralisation adds a management and infrastructure layer above them, progressively migrating applications to the shared platform as each one is due for a hardware or software refresh.

This phased approach is both more practical and more commercially sound than a big-bang migration. It avoids the operational risk of changing multiple systems simultaneously. It generates early returns from the first applications migrated while the project continues. And it builds the organisational confidence in the central platform that makes subsequent phases easier to execute.

The first application to migrate should be chosen carefully. It should be significant enough to demonstrate the value of centralisation, simple enough that the migration is low-risk, and operated by a team that is willing to work collaboratively on the process. A successful first migration builds the case for subsequent ones. A difficult first migration creates resistance that slows the whole programme.

Vishleshan AI's forward deployed engineering (FDE) approach is specifically suited to centralized vision AI platform deployments in manufacturing. Working inside the client's actual manufacturing environment, understanding the existing application landscape, the network infrastructure, the governance requirements, and the organisational dynamics that determine whether centralisation succeeds, is the only way to design an architecture that works in practice rather than in theory. Our experience spans automotive manufacturing and industrial production environments where vision AI is part of the quality and operational architecture. Book a Consultation