What AI In A Manufacturing System Should And Should Not Do

Manufacturing software has acquired a lot of AI in a short time, and much of it is a conversational interface for retrieving manufacturing information. That is not useless, but it is not where the value is either.

Where It Helps

The genuinely useful application is standing checks. Nobody has time to interrogate a system continuously, so problems are found when somebody happens to look. A system that checks its own records on a schedule and raises what it finds can help teams identify issues between manual reviews.

Explanation is the second one. A finding phrased in plain language, with the records attached, is faster to act on than a report you have to interpret.

Where It Should Be Kept Out

• Changing records. AI output should be labelled, traceable and approved by a person before anything is written.
• Inferring urgency. A system may show recorded priority; inventing one is a judgement it is not qualified to make.
• Controlling machinery. This should be structurally impossible, not merely discouraged.
• Being the only path to an answer. If a model outage means nobody can find out what is late, the design is wrong.

Questions For A Vendor

• What happens to the checks when the AI provider is unavailable?
• Is detection deterministic, or does the model decide what counts as a problem?
• Can I see which records produced a given finding?
• Where does the model run, and what leaves our network?
• Can it act on anything without a person approving it?

The One That Matters Most

Ask what happens when the provider is down. If the answer is that findings stop appearing, ask whether rule-based checks continue independently of the provider and how failed runs are reported — the model was deciding what counted as a problem, and a quiet screen means an outage rather than a healthy factory.

Keystone AI and Factory Watch · Machine telemetry and MRP