IBM Maximo Visual Inspection is one of the few AI-led MAS-suite components where the technology is not the hard part. The hard part is whether the inspectors trust the model and whether the audit trail holds up three years later when a regulator asks why a defect was classified the way it was. Both are won or lost in the implementation, not in the model.
This is what we have learned from running Visual Inspection in real safety-critical workflows.
Trust is built by the inspector who normally does the inspection
The single biggest predictor of success is whether the inspector who normally does the inspection helped build the model. Not the chief inspector who signs off the strategy. Not the safety lead who owns the regime. The person who actually walks the runway, checks the rolling-stock undercarriage, surveys the substation. They have to label the historical images, calibrate the model and challenge its early outputs.
When that happens, the inspector takes ownership of the model. They can explain its limits to colleagues. They notice when it drifts. They are part of the retraining cycle. The model is part of their work, not something done to them.
When that does not happen — when a generic model is trained off historical defect images by a third party and dropped on the workflow — the inspectors quietly stop trusting it. Override rates climb, the model retrains badly on the overrides, the override rate climbs further, and within six months the platform is operational but unused. The technology is fine. The implementation pattern was wrong.
Inter-inspector variability is the data quality problem
Two qualified inspectors will sometimes classify the same defect differently. This is not a flaw — it is the reality of subjective judgement on edge cases. It is also a real problem for the model, because if the training labels disagree, the model learns whichever inspector labelled the most images.
The discipline that works is to measure inter-inspector variability before the model is trained. Sample a defined set of historical images. Have multiple qualified inspectors label them independently. Where they disagree, work the disagreement out — sometimes the right answer is a clearer taxonomy, sometimes it is an additional defect class, sometimes it is calibration training for the inspectors themselves.
The model trained on the resulting labels will behave consistently. The model trained without this work will inherit whichever inspector’s judgement happened to dominate the training set, and the other inspectors will not trust it.
This work is unglamorous and impossible to skip. Every supplier that has tried has produced a model that drifts in the field.
The override flow has to be easier than the confirm flow on day one
The on-device workflow design is where models lose inspector trust fastest. If the inspector has to take three taps to override a wrong classification and one tap to confirm a right one, the overrides will silently disappear into the confirms. The model retrains thinking it was right, and starts being more wrong, more confidently.
The pattern that works is the inverse on day one. The override flow is at least as easy as the confirm flow. Overrides include a one-tap reason. As the model earns trust, the workflow can be retuned — but the early period has to be biased towards capturing reality, not towards confirming the model.
The audit trail is designed in, not bolted on
A safety-critical inspection regime eventually meets a regulator. The questions the regulator will ask, three years later, are predictable:
- Why was this defect classified as low-severity in March?
- Who saw it? When? On what model version?
- What was the inspector’s reasoning if they overrode the model?
- What training data produced the model that made the call?
If the audit trail can answer those questions reproducibly, the Visual Inspection programme strengthens the regulatory position. If it cannot, the programme is a liability — the operator has introduced an algorithmic decision into a safety-critical workflow without being able to explain its basis.
The audit trail design is straightforward but it has to be designed in from the start. Every classification recorded against the work order, the asset, the inspector, the timestamp and the model version. Every override recorded with reason. Every model version retained with its training data. This is not optional. It is what makes the programme defensible.
What earns trust in the field
Across Visual Inspection rollouts we have run, the patterns that build inspector trust look the same.
- The model is shown on shadow mode for a clear period before it goes live as part of the workflow. Inspectors see the model’s output alongside their own judgement and develop a feel for where it agrees with them and where it does not.
- False positives are tracked, communicated, and tuned out. The inspectors see the model getting better in response to their feedback.
- The chief inspector or safety lead publicly endorses the model’s role and limits — “this is the part of the inspection it helps with; this is the part it does not”. Ambiguity here corrodes trust.
- The retraining cadence is visible. Inspectors know when the model is being retrained, what changed, and what to expect.
None of this is technology. All of it is implementation.
Where Visual Inspection should not be deployed
For completeness — three patterns where deploying Visual Inspection is the wrong call.
- The defect class is not well-defined enough for a model to learn it. “Anything that looks wrong” is not a defect class. “Cracks longer than X mm in this surface” is.
- The inspection volume is too low for inter-inspector calibration to be meaningful. A model on a low-volume workflow is hard to validate and harder to retrain.
- The inspectors will not be in the room when the model is built. Every Visual Inspection programme that has failed in our experience failed for some version of this reason.
Deferring on these patterns is the right call. Pushing through them produces a model that nobody trusts and an audit trail nobody can defend.
Closing position
IBM Maximo Visual Inspection earns trust in safety-critical workflows when the inspectors who do the inspection help build the model, when inter-inspector variability is worked through before training, when the on-device workflow respects the realities of capturing overrides, and when the audit trail is designed in from day one. The technology is mature. The implementation discipline is what separates a programme that lands from one that becomes operational wallpaper.
For the implementation pattern in detail, see IBM Maximo Visual Inspection: implementation and managed services and the implementation guide for safety-critical workflows.