Add TechGraph on Google
An industrial AI project can produce a convincing demonstration before anyone has answered its most expensive questions. Who can access the production data? What happens when an integration fails? Can an operator challenge the model’s decision? Who maintains the system when the original development team moves on?
Those questions belong in vendor selection. A team that trains a model may be a good research partner, but a production system also needs reliable software, usable interfaces and a clear operating model. For buyers in manufacturing, logistics and other industries with complex data, the shortlist should reflect that wider responsibility.
The following seven checks provide a practical way to compare proposals. They are a buyer’s framework, not a ranking of suppliers or a claim that one company fits every project.
1. Start with the decision the system will support
“Add AI to quality control” leaves too much open. A more useful brief identifies a particular decision: flag a component for inspection, prioritise an exception, or help an engineer find the evidence behind an alert.
Ask each prospective partner to explain the current workflow before proposing a model. Who makes the decision today? What information do they use? What is the consequence of an incorrect recommendation? A good discovery process should also identify when conventional software or a simple rule would be sufficient.
Request: a one-page workflow showing the input, proposed output, responsible person, and next action. If two vendors are solving different problems, their estimates are not yet comparable.
2. Inspect the data plan before comparing model choices
Production data is rarely a neat collection of examples. It may be spread across equipment, databases, spreadsheets, and images with incomplete labels. Access restrictions can matter as much as volume.
Ask how the partner will determine whether the data represents the operating conditions the system will face. For image inspection, that may include different lighting, suppliers, and product variants. For operational analytics, it may include missing readings and changes to equipment identifiers.
The proposal should name who supplies the data, who validates labels, and how development and evaluation sets will be kept separate. It should also explain what happens if the available evidence is insufficient.
Request: a data inventory with access dependencies and a small feasibility test. Treat an estimate that assumes clean, complete data as conditional until those assumptions have been checked.
3. Ask for the integration boundary
A prediction becomes useful when the surrounding workflow can act on it. A quality team may need an inspection queue in an existing application. A planner may need a recommendation alongside inventory and order information. A maintenance engineer may need the relevant asset history, not another isolated dashboard.
Ask the vendor to identify which systems it will read from, which systems it will write to, and which team owns each connection. The design should describe expected delays, retries, duplicate events, and the behaviour during an outage.
Request: an architecture sketch and an interface responsibility list. For a first release, a clearly bounded read-only integration can be easier to evaluate than a proposal that immediately changes production decisions.
4. Compare the evidence behind the case study
Relevant delivery evidence is more useful than a long list of technologies. Look for a named use case, the supplier’s actual role and an explanation of what reached production. Separate the vendor’s software contribution from the customer’s product and domain expertise.
For example, the published Cybord case study describes Go Wombat’s work on an electronics quality-control platform combining inspection and component traceability. The useful point for a buyer is the connection between AI and a larger operational product; it is not a promise that another factory will achieve the same outcome.
Request: a walkthrough of one comparable delivery, including an integration problem and how the team resolved it. Ask what evidence can be shared without breaching the customer’s confidentiality.
5. Define acceptance in terms of mistakes and workload
One headline accuracy number is a weak acceptance criterion. A system may identify many routine examples correctly while missing the exceptions that matter most. It may also generate so many false alerts that operators stop using it.
Before development, agree on the types of errors to measure and the workflow cost of each. Depending on the use case, the evaluation might include missed defects, false alarms, review time, latency and behaviour on unfamiliar inputs. Keep a separate test set and record the conditions under which the results were measured.
The NIST AI Risk Management Framework organises risk work around governance, context, measurement and management. It provides a useful reference for the questions buyers should ask; mentioning it does not establish that a vendor or product has been certified by NIST.
Request: a written acceptance plan with measurable tests, human review responsibilities and a clear stop condition.
6. Make ongoing operation part of the proposal
Models and integrations need attention after launch. Product variants change, data pipelines break, dependencies are updated and people need support. A proposal that ends at deployment leaves those responsibilities unresolved.
Ask who monitors the service, investigates alerts and approves model updates. Find out how the team will record model versions and reproduce an earlier result. The operating plan should include a way to revert a change and a person who can make that decision.
Request: a concise operating plan with ownership, monitoring, escalation, and handover deliverables. Separate the initial build from recurring infrastructure and support costs so the comparison remains meaningful.
7. Buy the next piece of evidence
A staged engagement can give a buyer useful information before a larger commitment. The first stage might establish that the required data is accessible, that a representative sample supports the proposed approach, and that one integration path is practical.
Define what each stage delivers even if the project stops. That could include a data assessment, evaluation results, source files and a prioritised implementation plan. Discuss access to repositories, datasets and deployment accounts as part of the handover arrangement.
Request: a first milestone with a decision at the end: proceed, narrow the scope or stop. A milestone should resolve uncertainty, not merely consume a set number of development days.
A shortlist you can actually compare
Put the seven checks into a shared review sheet. For each supplier, record the evidence received, the unanswered questions and the owner of each dependency. Avoid turning unknowns into an invented score: “not demonstrated” is more useful than a confident-looking number.
The right partner is the one whose capabilities, responsibilities and delivery approach fit the problem you can describe. If your project needs both AI development and integration with operational software, review Go Wombat’s AI services and bring a concrete workflow, a sample of the available data, and the decision you want to improve to the first conversation.