Question 01
"What does your integration with our historian and PLC stack actually look like, three layers deep?"
The OT stack is not optional in manufacturing. If the AI vendor cannot read PI, Ignition, or Wonderware data in something close to real time, and cannot speak OPC-UA to the Rockwell or Siemens PLCs without re-architecting the network, the project will die in the integration phase nine months in. Most vendor decks show a logo grid implying full integration. The honest answer is usually "we have a connector that supports nightly batch export from PI."
Why most vendors get this wrong: they built first against the cloud-modern stack (AWS IoT, Azure IoT Hub) and use those screenshots to imply parity with the legacy historian and PLC layer. They don't have a working PI or Ignition integration. They have a partner who does, and the partner's scope hasn't been priced yet.
Right answer pattern: a working list of named PE-backed manufacturer customers running on the same OT stack, plus a named integration partner if the work is done by a third party. If the vendor can't name two customers in a phone call, the integration story isn't real yet.
Question 02
"Whose data trains the model, and what's the contractual line on shared learning?"
Multi-tenant AI vendors get smarter the more customers they have. A manufacturer's defect patterns, asset signatures, and process data are competitive assets. If that data flows into a shared training set, the portco is paying for the privilege of educating its future competitors.
Why most vendors get this wrong: they conflate "your data is private" with "your data does not train the model." Those are different statements. The first is about access. The second is about model weights. Many SaaS contracts permit the second under "aggregated and anonymized" clauses.
Right answer pattern: a clean contractual line saying model weights derived from the customer's data stay with the customer's instance and don't propagate to the shared base model. If the vendor pushes back with "that's not how we work," the answer is the answer, and it's the wrong one for a portco the sponsor wants to sell.
Question 03
"What's the all-in TCO including the sensor packs, the historian buildout, and the panel mods?"
The sticker price on a manufacturing AI deal is rarely the real price. Predictive maintenance needs sensor packs and panel modifications. Visual inspection needs camera mounts and station lighting. The historian buildout needed to feed the AI vendor is often six figures by itself. None of this is in the deck.
Why most vendors get this wrong: the SaaS line item is the only one with their name on it. They have no commercial reason to surface the integrator's scope, the panel work, or the network upgrade until you've already signed the SaaS contract. By that point, your negotiating room is gone.
Right answer pattern: a TCO worksheet covering SaaS, sensors, panel modifications, network upgrade, historian buildout, and the integration partner. Ask the vendor to put their name on a 24-month all-in number per site. If they will not, you do not have a TCO. You have a teaser.
Question 04
"When the vendor exits, who owns the model, the data, and the sensor inventory?"
The AI vendor landscape in industrial is going to consolidate hard in the next 36 months. Some of the names on the slide today will be acquired or wound down by 2028. The portco needs to know exactly what it owns on either outcome, before the platform shift happens, not after. Sensor packs that only work with one vendor's cloud are a stranded asset the day that vendor changes hands.
Why most vendors get this wrong: their team is incentivized to close the new logo. The exit-rights clause in their standard MSA is whatever legal thought was defensible at incorporation, not what is defensible for a PE-backed manufacturer at exit.
Right answer pattern: explicit data portability (full historical telemetry in a standard format), explicit model portability if the model is fine-tuned on customer data, sensor packs that can be re-pointed to a different platform, and a 12-month wind-down clause if the vendor is acquired or insolvent. Negotiate this at signing.
Question 05
"Why are we buying this instead of building it on the historian and data team we already pay for?"
A lot of manufacturers already have a Cognite, Seeq, or AVEVA PI historian, a data team that knows the schema, and a corporate analytics function on Snowflake or Databricks. For three of the five use cases above (scheduling, supplier quality, ECO copilot), the in-house build is the right answer if the team has 120 to 180 days of capacity. The SaaS vendor is selling speed-to-deploy, not capability the in-house team cannot match.
Why most vendors get this wrong: they pitch "AI is hard, you need us" when the honest answer is "the model is the easy part, your data team can do that. The hard part is the OT integration, and you need us for that." That's a more defensible pitch but a smaller scope, which is why they avoid it.
Right answer pattern: a build-versus-buy worksheet that compares 24-month TCO of the SaaS path versus a named in-house build, including the opportunity cost of the data team's time. For predictive maintenance and visual inspection, buy usually wins on time-to-value. For scheduling, supplier quality, and the ECO copilot, build is increasingly the right answer.