AI in Fabrication: What It Can Do and How to Judge a Vendor Claim

"AI-powered" appears on more equipment marketing every year, and it means very different things depending on the product. Some of it describes real, established techniques. Some of it describes a rules-based feature that existed before anyone called it AI. This article sorts the two apart and gives a way to test a claim before you rely on it for a purchase decision.

What is genuinely established

A handful of applications of machine learning and computer vision in manufacturing have enough track record that they can be discussed without hedging on whether the underlying approach works:

• Nesting optimization. Software that arranges parts on a sheet to reduce scrap is a mature application of optimization algorithms. Some nesting tools now use learned heuristics to search the arrangement space faster; the underlying task — minimizing wasted material — is not new, and the gains depend heavily on part geometry and mix.
• Vision-assisted inspection. Camera systems trained to flag dimensional deviations or surface defects are used across manufacturing, including sheet metal fabrication. Their accuracy depends on the training images matching your actual parts, lighting and materials — a system trained on someone else's shop's parts is not automatically accurate on yours.
• Parameter recommendation. Cutting parameter libraries that suggest a starting point for a given material and thickness have existed for a long time as lookup tables; some vendors now market a learned model that refines these recommendations from cut outcomes. The practical difference from a well-built lookup table is often smaller than the marketing implies.
• Scheduling and quoting support. Software that estimates cut time, nests a job and proposes a schedule based on machine availability and due dates is a recognized category. Whether it uses classical scheduling algorithms or a learned model, its output is only as good as the job and machine-availability data fed into it.
• Condition monitoring. Tracking vibration, temperature or consumable wear against a baseline to flag drift before a fault is an established application, generally requiring sensors and a history of both normal and abnormal operation to be useful.

What requires more scrutiny

Some phrasing should prompt a specific question rather than acceptance:

• "AI-optimized cutting" with no explanation of what is being optimized, against what baseline, or using what data.
• "Predictive maintenance" offered as a feature on day one, with no mention of how the system was trained or what failure history it draws on.
• Any claim that a system "learns your shop" without describing what data it uses to do so, how much is required, or what it does before it has learned anything.

A checklist for testing an AI claim

Before treating a vendor's AI claim as a reason to buy, ask:

1. What data was the model trained on? Your own shop's data, the vendor's aggregated customer data, or a general dataset unrelated to your process? A model trained on someone else's parts and materials may not transfer to yours.
2. What does it do when it is wrong? Does it fail silently, flag low confidence, or require a human to confirm before it acts? A system with no visible failure mode is harder to trust, not easier.
3. Does it require ongoing connectivity to function? If the model runs in the vendor's cloud, a network outage may remove the capability entirely — a different risk profile than a model that runs locally.
4. Who owns the model's output and any data it generates from your operation? Confirm this in the contract, not in a sales conversation.
5. What happens to the capability and the data at the end of the contract? Does the feature stop working, and do you retain the data that fed it, if that data has value on its own?
6. Can you see a result on a process similar to yours, not a generic demo? A vendor confident in their claim should be able to show a comparable material and thickness, not only a best-case example.

The data gap between a demo and your shop floor

The gap between an AI feature working in a vendor's demo and working in your shop is a data gap far more often than an algorithm gap. Concretely, this means:

• Consistent, structured job records — material, thickness, program, actual cut time, scrap — rather than paper travelers or inconsistent spreadsheet fields.
• A labelled history of both normal operation and actual failures, not just alarms. A predictive maintenance model needs examples of what preceded a real failure, not only a log of when the machine was running.
• Enough volume of comparable jobs that a pattern is distinguishable from noise. There is no fixed threshold that applies across every shop and every application; a vendor claiming a specific number of parts or months as a universal minimum should be asked how that figure was derived for your process specifically.

A shop without these records is not disqualified from using AI-based tools, but should expect a period of building the underlying data before any learned system produces something more useful than a well-configured rules-based tool would.

Predictive maintenance needs a failure history

It is worth stating this plainly because vendors overstate it often: a system cannot predict a failure mode it has never seen labelled examples of. A vendor offering predictive maintenance on a machine type with little service history — yours or the vendor's aggregated fleet — is describing an aspiration, not a proven capability, until they can point to the failure data the model was built from. Asking to see that data, or at least a description of it, is a reasonable request before buying the feature.

Where this leaves a buyer

Rules-based automation — a well-maintained nesting engine, a documented parameter library, a scheduling tool driven by your actual job data — solves a large share of what a fabrication shop needs day to day, and it is easier to audit than a learned model. Machine learning adds value where the pattern is genuinely too complex for rules and where the shop has, or is willing to build, the data to support it. The distinction matters more to a purchase decision than whether a product uses the word "AI."

Rules-based automation is not a lesser option

It is worth stating plainly: a well-built rules-based system is not a placeholder until AI arrives. For many fabrication tasks — parameter lookup by material and thickness, scrap-minimizing nesting, due-date-driven scheduling — a documented, auditable rules engine is easier to trust and easier to fix when it is wrong than a learned model would be. Choosing rules-based automation over a marketed AI feature is a legitimate decision, not a compromise, when the rules-based tool is built on your own accurate process data.

What changes as a shop's data matures

A shop's ability to use machine-learning-based tools usefully tends to track its data maturity more than its equipment age. A shop with clean job records, a real fault history and a habit of recording outcomes consistently is in a position to evaluate a learned model on its own data before buying it. A shop still relying on paper travelers and inconsistent spreadsheets is better served spending the next budget cycle on record-keeping discipline than on an AI feature that has nothing reliable to learn from. That sequencing — data discipline before analytics — applies whether the analytics in question sits on a machine control, a scheduling package or a separate software product.

Sources

This source supports generic context on AI and machine learning research directions in manufacturing; it is not a description of any Mekotek product's capabilities.

• NIST, 2026 Roadmap for Artificial Intelligence and Machine Learning in Smart Manufacturing If you are weighing a connected or data-driven feature as part of a machine purchase, the question list in what to ask before networking a laser cutting machine covers the data-governance side of the same decision.