Skip to content
NEURIXIS

Sector

AI on the shop floor

Your plants have been producing data for years. Data is rarely what is missing. What is missing is a model that holds the cycle time, an integration into the PLC, and a technical file that survives conformity assessment.

The context

An instrumented plant already produces everything you need: PLCs, MES, CMMS, sensors, historians. The problem is not volume, it is alignment. Signals are sampled at different rates, timestamped against clocks that are not synchronised, and locked inside proprietary historians with slow exports. The first month of a serious project goes into rebuilding a common time base, not into picking a model.

The second constraint is cycle time. In-line quality control has to return a verdict at machine pace, often a few hundred milliseconds, on hardware sitting in a cabinet with no outbound connection. That rules out a whole class of architectures, starting with anything that assumes a call to a remote service. Edge inference is a scoping question, not a go-live question.

The third is statistical. Expensive defects are rare. At a scrap rate of a few per thousand, overall accuracy is meaningless: a model that always answers "conforming" scores well on it. You work in recall on the defect class at a fixed precision, and you negotiate with production how many false alarms a line can absorb per shift. That number is an input to the project, not an output.

The fourth is drift. New batch, new material supplier, camera moved, summer daylight: the distribution shifts. A vision model trained in spring will not hold in autumn unless someone has planned the retraining procedure, the qualification set, and who is accountable for triggering it.

Industrial machine running on a production line.

Regulatory constraints

An AI function embedded in a machine is not a software project sitting next to the product. It belongs in the product’s technical file. Here is what shapes the work.

  • Machinery Directive 2006/42/EC and Regulation (EU) 2023/1230

    Regulation (EU) 2023/1230 replaces the Machinery Directive from 20 January 2027, with a transition period until then. It explicitly addresses machinery with digital elements and evolving behaviour, which the 2006 directive did not. The direct consequence: if your AI function contributes to machine safety, it falls under the product’s risk assessment and technical documentation, and shipping a model update after placing on the market is not a neutral act.

  • CE marking and conformity assessment

    One question has to be settled at scoping, and it is easy to phrase and expensive to get wrong: is the AI function a safety component, or a monitoring tool sitting beside the safety chain? The answer determines the level of evidence required, the nature of the conformity assessment and the cost of the project. As a safety component, the assessment may involve a third party and the burden of proof rises; as a monitoring tool beside the chain, it stays documentary and internal. It is settled with your machine safety lead, before the first line of code.

  • AI Act, Annex I

    An AI system that is a safety component of a product covered by the Union harmonisation legislation in Annex I, subject to third-party conformity assessment, is classified as high risk. Machinery legislation is on that list. That brings the high-risk obligations: risk management, training data governance, technical documentation, logging, human oversight, and demonstrated accuracy and robustness. Most of this overlaps with the machine file you already produce: the useful work is converging the two, not maintaining two files.

  • NIS2, Directive (EU) 2022/2555

    Several manufacturing activities fall within the essential or important entities covered by NIS2, with obligations on cyber risk management, supply chain security and incident reporting. In practice this bears on one precise architectural decision: any gateway that moves shop floor data out to an external inference service has to be justified, logged and contracted for. It is one of the reasons we default to running inference on your own infrastructure.

AI systems ranked from most to least regulated: unacceptable risk, high risk, limited risk, minimal risk.Most regulatedLeast regulatedUnacceptable riskBanned in the UnionHigh riskAnnex III, heavy obligationsLimited riskTransparency obligationsMinimal riskFree use

Use cases

  • In-line visual quality control

    The problem
    Final inspection is human and sampled. Defects surface after several value-adding operations, sometimes after shipping, and the cost of non-quality lands on the customer.
    The approach
    Supervised detection or segmentation on annotated images where defects are catalogued, anomaly detection on conforming parts where they are too rare to label. Inference on embedded GPU or smart camera, inside the cycle time, with no outbound network. Acquisition protocol frozen before training: position, lighting, cadence.

    Success criterion

    Recall on critical defects at a false alarm rate agreed with production, measured on a qualification batch annotated independently of the training batch. Plus 95th percentile inference time against the line’s real cycle time. Both numbers are written down before we start.

  • Predictive maintenance on critical equipment

    The problem
    Unplanned downtime dictates the schedule and the team’s workload. The CMMS records interventions, which is to say consequences, not the signals that precede them.
    The approach
    Multivariate time series on vibration, current, temperature, pressure. Unsupervised anomaly detection to bootstrap when labelled failures are too few, then a supervised model once history allows. The prediction horizon is not the model’s choice: it is set by the lead time to source the part and mobilise the team.

    Success criterion

    Share of failures caught with more warning than the mobilisation lead time, and alerts per machine per week against what the maintenance team can actually investigate. An alert nobody opens is a false alert, however statistically sound it is.

  • Demand and production load forecasting

    The problem
    The master plan runs on moving averages and the planner’s judgement. Stockouts and dead stock coexist in the same warehouse, sometimes on the same SKU.
    The approach
    Time series models with exogenous variables (calendar, promotions, order book), benchmarked against gradient boosting on lagged and rolling-window features. Always evaluated against a naive baseline, seasonal where seasonality exists, and on a period after the training window.

    Success criterion

    Forecast error per SKU and per horizon, on a period after the training window, against the naive baseline and against the forecast in use today, at comparable volume and scope. If the model does not beat the planner’s moving average, we say so and we stop.

  • Extraction from production records and supplier documents

    The problem
    Material certificates, inspection reports, delivery notes and work orders arrive as scanned PDFs. Rekeying consumes qualified time and introduces its own errors.
    The approach
    OCR on semi-structured documents, field extraction by a language model constrained to an explicit schema, cross-checks between documents in the same file (material references, quantities, dates), and a human queue for anything below the confidence threshold, each field keeping a link to its source.

    Success criterion

    Field-level extraction accuracy on an annotated test set, separating fields that carry a consequence (heat number, measured value) from context fields. Plus the share of documents processed with no human rework at the chosen threshold, measured over a month of real flow.

A two-by-two matrix crossing integration effort with estimated annual gain, with four named quadrants.Quick winHigh gain, low effortStructural projectHigh gain, high effortGadgetLow gain, low effortTrapLow gain, high effortEstimated annual gainhighlowIntegration effortlowhigh

What makes projects fail here

What follows is not a list of theoretical risks. These are the ways industrial AI projects actually die.

  • The pilot runs on a dedicated workstation parked next to the line, with no link to the PLC or the SCADA. It works, it demos well, and nobody knows what to do with the verdict when the engineer is not there. Integration is not the last step of the project, it is its precondition.
  • Training images come from a single campaign: one batch, one camera, one lighting setup, one shift. The model learns the campaign. The first real variation breaks it, and no retraining loop was planned or budgeted.
  • Annotation is outsourced to people who cannot recognise the defect. Disagreement between annotators on borderline cases ends up larger than the performance gap you are trying to measure, and the numbers stop meaning anything.
  • The success criterion is written as accuracy on an artificially rebalanced set. In production, at the real defect rate, the same model floods the line with false alarms and the operators stop looking within a fortnight.
  • Production and quality do not agree on what counts as an acceptable defect. The model inherits the disagreement and makes it visible. That is an arbitration to secure before starting, not an algorithm problem.
  • OT and IT do not talk to each other. The shop floor network is segregated for good reasons, and the question of crossing it is opened three weeks before go-live.
The closed MLOps loop: train, deploy, monitor, detect drift, retrain.TrainDeployMonitorDetect driftRetrain

What we do, and what we do not do

What we do

  • Scoping happens on the shop floor, with operators, quality and maintenance, not in a meeting room.
  • We write the annotation protocol, build an independent qualification set, and record the baseline before the first line of code.
  • We train vision and time series models on your data, and deploy them at the edge or on your infrastructure.
  • We integrate with what exists: PLC, MES, historian, SCADA, and we surface verdicts and logs inside your own tools.
  • We produce the documentation that feeds the technical file and the AI Act file: data provenance, model versions, limits of use, human oversight arrangements.
  • We train your methods and maintenance teams on operation, drift monitoring and retraining.

What we do not do

  • We are not a systems integrator. We do not install robots and we do not modify your PLC program. We work with your integrator, not instead of them.
  • We are not a notified body. We produce the technical documentation. We do not certify and we do not sign off your conformity.
  • We do not sell a platform and we do not charge licence fees. The code and the models are yours.
  • We do not take an engagement without a named sponsor and an accessible baseline. We would have no way of proving anything at the end.
  • There are two of us. We take one site at a time. A simultaneous rollout across fifteen plants is not a project for us, and we say so before the proposal, not after.

Other sectors

Frequently asked questions

  • Can inference run without any shop floor data leaving the plant?

    Yes, and it is often the right call. In-line quality control returns a verdict within the cycle time, on hardware sitting in a cabinet with no outbound connection: edge inference, on an embedded GPU or a smart camera, meets that constraint. It also avoids the gateway that would move shop floor data out to an external service, which has to be justified and logged under NIS2 anyway. The question is settled at scoping, not at go-live.

  • Does our AI function have to be part of the machine’s CE marking?

    It depends on one question to settle at scoping: is the AI function a safety component of the machine, or a monitoring tool sitting beside the safety chain? The answer sets the level of evidence required and the nature of the conformity assessment. If the function contributes to safety, it falls under the product’s risk assessment and technical file, and shipping a model update after placing on the market is not a neutral act. That call is made with your machine safety lead, before the first line of code.

  • How do you integrate with our PLCs and our supervision?

    A pilot sitting next to the line, with no link to the PLC, is useless: nobody knows what to do with the verdict when the engineer is away. We integrate into the existing stack, PLC, MES, historian, supervision, feeding verdicts and logs back into your tools. We are not integrators and we do not modify your PLC program: we work with your integrator, not in their place.

  • Will the model hold when production changes?

    Not on its own, and it is a point we address at scoping. New batch, new material supplier, camera moved, seasonal daylight: the distribution shifts, and a vision model trained in spring will not hold in autumn if nobody planned the retraining. We hand over the retraining procedure, the qualification set and who is accountable for triggering it. Without that loop, a vision project degrades in silence.

Let us talk about your use case.

An hour is enough to tell whether your subject stands up. If it does not, we will tell you then, not after three months of project.

Contact usBook an AI Quick Wins Workshop