What should a manufacturer check before connecting AI to production systems?

Production environments differ from office systems in a way that changes the analysis. The systems are connected to things that move, the consequences of a wrong instruction are physical, and the timing assumptions are real: a process that tolerates a delayed response in an office context may not tolerate one on a line. That makes the first question not what the connection enables but what it can affect.

Write isolation is the first check and it should be structural rather than configured. Anything that can send an instruction to a controller, a scheduler or a machine is in a different category from anything that reads. A read-only path from production data to an analysis system is a well-understood arrangement; a bidirectional one is a control system, and it belongs to whoever is responsible for machine safety rather than to whoever is deploying the tool.

Behaviour under connection loss is the second and is the one most often unexamined. A cloud service will be unavailable at some point, and the question is what the process does during that interval: continues on the last instruction, stops, falls back to a local decision, or waits. Each is a legitimate answer and none of them is the default. Discovering the default during an outage is how a connectivity problem becomes a production problem.

Data leaving the site is the third and carries constraints that do not apply to ordinary business data. Production data frequently reveals customer designs, volumes and schedules, which are typically covered by confidentiality terms in the customer's purchase agreement. Some technical data carries export control obligations restricting who may access it and from where, and those obligations attach to the data rather than to the intent of the recipient. Both are questions to resolve before a connection exists, because they are not remediable afterwards.

Two smaller checks are worth adding. Whether the connection introduces a dependency the shop cannot see: an analysis that silently stops updating leaves people acting on a stale figure, which is worse than a visible outage. And whether the data being read is the data people think it is, since production systems accumulate fields that stopped being maintained years ago and an analysis built on one of those is confidently wrong.

The applications that avoid all of this are the ones worth doing first. Reading production data into an analysis nobody acts on automatically. Extracting information from incoming documents. Drafting the paperwork that follows a job. Each of these delivers real value with a read-only path and no timing dependency, which is a considerably better starting position than a connection to anything that moves.