An industrial AI proof of concept should not try to prove that a technology “works” in general. Its purpose is narrower: determine whether a specific solution can assist an operating task under known conditions and controlled risk.
An ambiguous objective can make an attractive demo look successful while hiding weak data, fragile integrations or incompatible expectations. A useful PoC turns those uncertainties into documented decisions.
Express the use case as a decision
Describe a situation, a person and a decision. One practical structure is:
When a defined condition occurs, help a specific user make a concrete decision using authorized sources, without performing actions outside the agreed scope.
For example, a pilot might help maintenance reconstruct the sequence before a stop using historian data and alarms, without writing values to the PLC. The example still needs process-specific detail, but it already gives the team something testable.
If the objective only says “automate,” “predict” or “use AI,” the problem is not yet bounded.
Set the perimeter before building
The scope should identify:
- The process, line or asset included.
- Participating users and the decision they retain.
- Data sources and available period.
- The environment where the test will run.
- Actions explicitly excluded.
- The person who authorizes access and reviews results.
- Conditions that pause the evaluation.
This perimeter prevents the PoC from growing with every newly discovered possibility. It also distinguishes an offline analysis from an operational integration, which needs different controls.
Document how the task works today
Without a baseline, improvement is difficult to interpret. Observe how the team gathers evidence, checks procedures and validates a hypothesis before introducing the new tool.
The baseline does not need to collapse into one metric. It can include consistency of evidence, manual steps, consulted sources, common errors and how easily a decision can be justified. Choose measures with the people doing the work.
Review the data before the model
A data inventory should state who owns each source, how it is accessed and which transformations it has received. Review timestamps, missing periods, naming changes and document versions.
Available examples should include normal operation, known failures and ambiguous situations. Testing only simple or hand-picked episodes says little about real behavior.
Missing information is itself a valid result. A more complex model cannot replace a signal that was never recorded.
Define evaluation before tuning
Write the criteria before adjusting the solution. Depending on the use case, evaluate:
- Retrieval of relevant, authorized evidence.
- Correct ordering of events and states.
- Separation of facts, inferences and recommendations.
- Ability to abstain when information is insufficient.
- Traceability of sources, versions and inputs.
- Usefulness to the responsible user.
- Behavior when data or services are unavailable.
There is no universal percentage that makes an industrial AI system safe or useful. Thresholds belong to the plant team and the specific decision.
Reserve test cases that are not used during configuration, and record mistakes as carefully as successes.
Choose architecture in proportion to risk
Many PoCs can start outside the control cycle with authorized exports or replicas. If current information is required, read-only access keeps the initial scope smaller.
Separate the AI assistance layer from critical functions. Include permissions, activity records, configuration versions and defined behavior when a service is unavailable.
Any write capability requires additional analysis with automation, security and operations owners. It should not be added merely to make the demo look more impressive.
Validate with technical and operational users
Technical evaluation checks data, outputs and failure modes. Operational validation determines whether the information arrives at the right time, uses understandable terms and fits the actual workflow.
Record corrections in a structured way: which evidence was missing, which interpretation was wrong and which action followed. This helps distinguish interface, data, instruction and model problems.
Close with an explicit decision
The final review should allow three outcomes: proceed, adjust or stop. Proceeding means the criteria were met within scope. Adjusting requires new, testable conditions. Stopping can be the right result when data, control or operating value is missing.
Learning early that an idea is not viable is also a useful outcome.
What to validate in your plant
Before starting the PoC, confirm:
- The situation, user and decision that define the case.
- The technical perimeter and excluded actions.
- The current way the task is performed and justified.
- Data ownership, quality and representativeness.
- Required permissions, records and review.
- Reserved cases and acceptance criteria.
- Conditions to proceed, adjust or stop.
A well-designed PoC does not eliminate every uncertainty. It organizes uncertainty so the team can choose the next step without compromising the operation.