The model is rarely the hard part. Getting its output to a controller reliably, at 3 a.m., without a person in the loop and without destabilising equipment that has run for fifteen years, is the work.
Start with the controls team
They own the risk and they will be there long after the project. Bring them in before the interface is designed, not at commissioning. In practice their constraints — segmentation, allowed protocols, change windows — determine the design more than any technical preference.
Keep the write path narrow
One reviewed interface writing a small number of well-defined tags is far easier to reason about, and to approve, than a system that reaches into the control layer in several places. Read broadly if you must; write narrowly.
Design the failure first
What does the process do when the vision system is unavailable, when the camera is obstructed, or when confidence is low? Falling through to existing behaviour with an alert is usually right. Whatever it is, decide before commissioning and test it during acceptance — this is the part that gets skipped and the part that matters at 3 a.m.
Bench test before the line
Prove the integration against a rig, so the first time it meets production is not the first time it runs. Line time is expensive and a failed commissioning burns goodwill you will need later.
Protocols in practice
OPC UA where it is available, Modbus TCP where it is not, and vendor-specific interfaces when the equipment predates both. None of this is exotic; it just has to be specified in writing so neither side guesses.