3. Going into production without freezing a line

The real question is not whether the model is high-performing. The real question is how long it will remain so without its creators. It is this constraint that must dictate the method, and it forbids the Big Bang mode: you do not switch a workshop over to an automated decision just to prove a concept.

Axis 1: start from the action, not the model. Before any data, name the decision that the model is supposed to change, and the operational indicator that measures it — downtime, scrap rate, diagnostic duration. An acceptance criterion expressed in model performance points never translates on its own into workshop gains. A criterion expressed in avoided minutes of downtime, however, does.

Axis 2: industrialize data capture before the algorithm. This is the reverse of the natural order of projects, and it is what makes the difference eighteen months down the line. Standard and replaceable hardware, written installation procedures, documented measurement conditions, a reference database designed to scale. A mediocre model on a mastered data capture process can be corrected; the reverse is a project that has to be restarted from scratch.

Axis 3: treat the model as a piece of equipment. A reference, versions, a requalification procedure after a process modification, a log of what it has produced. This is software craftsmanship applied to a statistical object: it does not enter production because it works, it enters production because it is maintainable.

These three axes have a common implication, often discovered too late: the model's output must land in an already existing workflow. A score displayed on a new screen creates an extra consultation workload, and it loses against production. The same score pre-filling a maintenance ticket, a non-conformance report, or an intervention order enters the digital flow of the workshop without asking anything of anyone. This is the point where an AI project ceases to be a demonstration: when no one goes to look at it anymore, because it comes to them on its own.

This is the logic of the industrial Shazam, which akawan built in an aeronautical context where manual diagnostics cost downtime. The technical pipeline relies on sound capture using standard microphones, key feature extraction from the signal by a model from the Akoustik framework, and a real-time comparison with a scalable vector database: the database is enriched as cases arise, making usage the source of improvement rather than a maintenance burden. On this scope, the Industrial Shazam sheet indicates that 95% of anomalies identified in flight are resolved upon arrival.

4. Three conditions for the model to survive its creator's departure

A designated business owner. Not a technical point of contact: a production or quality manager who is accountable for the indicator that the model is supposed to improve. This is the form of cross-functional governance that holds up best over time, because it is backed by a responsibility that already existed.

A written shutdown criterion established in advance. Decide, before commissioning, what would make you suspend the model: a rate of false signals, a process change, a period of time without requalification. Without this criterion, a drifting model remains in service because shutting it down looks like an admission of failure.

These first two conditions cost neither budget nor rare expertise. They cost a decision, taken before commissioning rather than after the first incident. This is also what makes the subject accessible to a mid-sized company (ETI): there is no critical size required to appoint an owner and write a shutdown criterion.

A review aligned with the industrial rhythm. Drift is not monitored continuously through a dashboard that nobody opens. It is addressed in an existing ritual — quality review, maintenance meeting — just like the calibration of a measuring instrument. This iterative rationalization through value is what distinguishes a model that ages well from a model that ages alone. Our positions on this point are detailed in our Artificial Intelligence expertise and our AI Diagnostic approach.

A model is not a deliverable, it is a piece of equipment

If your pilots do not go into production, the most likely explanation is neither the model, nor the data, nor the maturity of your teams. It is that they have been managed like research projects, with an end date, whereas they produce an object that requires a lifecycle. A demonstrator ends; a piece of equipment is maintained.

The target state, therefore, does not look like a portfolio of use cases. It looks like a short list of models in service, each with an owner, an indicator, a requalification procedure, and a shutdown criterion. It is less spectacular than a roadmap with fifteen use cases, and yet it is the configuration in which AI finally shows up in the income statement rather than in the budget.